1:HTTP基本概念 超文本 传输 协议
2:常见状态码 1xx 提示信息 2xx 成功 3xx 重定向 4xx 客户端错误 5xx 服务器错误
3:HTTP常见的字段 host 指定服务器的域名 Content-Length 回应的数据长度 Connection 长连接(Keep-Alive)
Content-Type 响应数据格式(text/html; Charset=utf-8) Content-Encoding 数据压缩格式(gzip)
4:get和post的区别 get安全、幂等、可被缓存 post不安全(请求的参数只允许 ASCII 字符),不幂等,(大部分实现)不可缓存
RFC规范 POST的语义是根据请求负荷(报文body)对指定的资源做出处理
GET请求可以带body吗? 任何请求都可以带 body的 只是因为RFC规范定义的GET请求是获取资源,所以根据这个语义不需要用到body
5:HTTP缓存技术
强制缓存:强缓存指的是只要浏览器判断缓存没有过期,则直接使用浏览器的本地缓存,决定是否使用缓存的主动性在于浏览器这边。
响应头部相关参数:200 状态码,但在 size 项中标识的是from disk cache,Cache-Control和Expires表示资源在客户端缓存的有效期
协商缓存:就是与服务端协商之后,通过协商结果来判断是否使用本地缓存。
响应头部相关参数:304状态码 If-Modified-Since和Last-Modified(资源最后修改时间),If-None-Match和ETag(唯一标识响应资源)
6:HTTP/1.1特性
优点:简单(HTTP 基本的报文格式就是 header + body,头部信息也是 key-value)
灵活和易于扩展(各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死,允许开发人员自定义和扩充)
应用广泛和跨平台(从台式机的浏览器到手机上的各种 APP)
缺点:
无状态双刃剑(好:服务器不用记忆HTTP的状态,减轻服务器的负担。坏:没有记忆能力,完成有关联性的操作时会非常麻烦),解决:cookie
明文传输双刃剑(好:方便阅读。坏:被抓包,信息裸奔)
不安全(通信使用明文,不验证通信方的身份,无法证明报文的完整性),解决:HTTPS
性能:
长连接(一次TCP连接,多次请求响应)
管道网络传输(连续发送请求,不必等其响应。服务器必须按照接收请求的顺序发送对这些管道化请求的响应。HTTP/1.1管道解决了请求的队头阻塞,但是没有解决响应的队头阻塞)
队头阻塞(当顺序发送的请求序列中的一个请求因为某种原因被阻塞时,在后面排队的所有请求也一同被阻塞了,会招致客户端一直请求不到数据)这也是后续的HTTP/2和HTTP/3在优化HTTP的性能的方向
7:HTTP和HTTPS的区别 HTTPS 则解决 HTTP 不安全的缺陷,在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议,使得报文能够加密传输
HTTP 默认端口号是 80,HTTPS 默认端口号是 443
HTTPS 是如何解决上面的三个风险的?(窃听风险、篡改风险、冒充风险)
混合加密(对称加密和非对称加密结合,密钥)、摘要算法+数字签名(哈希算法+非对称双向加解密)、数字证书(身份验证,CA 数字证书认证机构)
8:HTTPS是如何建立连接的?其间交互了什么?HTTPS 的应用数据是如何保证完整性的?(略)https://xiaolincoding.com/network/2_http/http_interview.html#https-%E6%98%AF%E5%A6%82%E4%BD%95%E5%BB%BA%E7%AB%8B%E8%BF%9E%E6%8E%A5%E7%9A%84-%E5%85%B6%E9%97%B4%E4%BA%A4%E4%BA%92%E4%BA%86%E4%BB%80%E4%B9%88
9:HTTPS 一定安全可靠吗?
HTTPS 协议本身到目前为止还是没有任何漏洞的,即使你成功进行中间人攻击,本质上是利用了客户端的漏洞(用户点击继续访问或者被恶意导入伪造的根证书),并不是 HTTPS 不够安全
如何避免被中间人抓取数据?通过 HTTPS 双向认证
10:HTTP/1.1、HTTP/2、HTTP/3 演变
HTTP/1.1
改进:长连接的方式改善了短连接造成的性能开销、支持管道网络传输 减少整体的响应时间
瓶颈:请求头部未经压缩就发、发送冗长的首部、队头阻塞、没有请求优先级控制、请求只能从客户端开始 服务器只能被动响应
HTTP/2
改进:头部压缩、二进制格式、并发传输、服务器主动推送资源
缺点:HTTP/2 通过 Stream 的并发能力,解决了 HTTP/1 队头阻塞的问题,看似很完美了,但是 HTTP/2 还是存在“队头阻塞”的问题,只不过问题不是在 HTTP 这一层面,而是在 TCP 这一层
HTTP/2 是基于 TCP 协议来传输数据的,TCP 是字节流协议,TCP 层必须保证收到的字节数据是完整且连续的,这样内核才会将缓冲区里的数据返回给 HTTP 应用,那么当「前 1 个字节数据」没有到达时,后收到的字节数据只能存放在内核缓冲区里,只有等到这 1 个字节数据到达时,HTTP/2 应用层才能从内核中拿到数据,这就是 HTTP/2 队头阻塞问题。
HTTP/3
改进:HTTP/2 队头阻塞的问题是因为 TCP,所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP!
大家都知道 UDP 是不可靠传输的,但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。
QUIC有以下3个特点
:无队头阻塞(当某个流发生丢包时,只会阻塞这个流,其他流不会受到影响,因此不存在队头阻塞问题)
:更快的连接建立(QUIC 内部包含了 TLS, QUIC 使用的是 TLS/1.3,因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商)
:连接迁移(基于 TCP 传输协议的 HTTP 协议,由于是通过四元组(源 IP、源端口、目的 IP、目的端口)确定一条 TCP 连接,当移动设备的网络从 4G 切换到 WIFI 时,意味着 IP 地址变化了,那么就必须要断开连接,然后重新建立连接,QUIC 协议通过连接 ID 来标记通信的两个端点,P 地址变化了,只要仍保有上下文信息(比如连接 ID、TLS 密钥等),就可以“无缝”地复用原连接,消除重连的成本,没有丝毫卡顿感,达到了连接迁移的功能)
问答环节
问:“https 和 http 相比,就是传输的内容多了对称加密,可以这么理解吗?”
答:建立连接时候:https 比 http多了 TLS 的握手过程;
传输内容的时候:https 会把数据进行加密,通常是对称加密数据;
问:“ 我看文中 TLS 和 SSL 没有做区分,这两个需要区分吗?”
答:这两实际上是一个东西。
SSL 是洋文 “Secure Sockets Layer” 的缩写,中文叫做「安全套接层」。它是在上世纪 90 年代中期,由网景公司设计的。
到了1999年,SSL 因为应用广泛,已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS(是 “Transport Layer Security” 的缩写),中文叫做 「传输层安全协议」。
很多相关的文章都把这两者并列称呼(SSL/TLS),因为这两者可以视作同一个东西的不同阶段。
问:“为啥 SSL 的握手是 4 次?”
答:SSL/TLS 1.2 需要 4 握手,需要 2 个 RTT 的时延,就是 4 次握手:另外, SSL/TLS 1.3 优化了过程,只需要 1 个 RTT 往返时延,也就是只需要 3 次握手: