对HTTP的理解

中文释义：超文本传输协议
超文本是用超链接的方法，将各种不同空间的文字信息组织在一起的网状文本。

完整请求流程

HTTP/0.9特点

• 只有请求行，没有请求头和请求体
  
• 服务器只返回数据
  
• 文件支持HTML类型，ASCII编码。
  

HTTP/1.0特点

• 新增请求头和请求体，传输更多信息给服务器
  
• 新增响应头，响应行状态码
  
• 新增缓存机制
  

HTTP/1.0 发送多个同域名请求， 每次请求都需要重新建立 TCP 连接和断开连接的操作，这无疑增加了网络开销，同时也延迟了页面显示。

HTTP/1.1特点

• 新增持久连接 Connection: keep-alive
  
• 新增Host字段，用于支持虚拟主机
  
• 通过引入 Chunk transfer 机制来支持动态内容：服务器会将数据分割成若干个任意大小的数据块，每个数据块发送时会附上上个数据块的长度，最后使用一个零长度的块作为发送数据完成的标志。
  
• 引入了客户端 Cookie 机制和安全机制
  

HTTP/1.1 为网络效率做了大量的优化，最核心的有如下三种方式：**

• 增加了持久连接；
  
• 浏览器为每个域名最多同时维护 6 个 TCP 持久连接；
  
• 使用 CDN 的实现域名分片机制。
  

带宽利用率不理想，原因如下：

• TCP慢启动
  
• 多条TCP连接竞争固定带宽，JS、CSS等关键资源应该优先下载，而这一点无法实现。
  
• 队头阻塞问题。共用一个TCP管道，前面的请求慢，后面的请求需要等。
  

HTTP/2
多路复用： 浏览器针对同一域名的资源，只建立一个 TCP 连接通道，所有的针对这个域名的请求全部都在这个通道中完成；
不再使用文本，而是用二进制。
可以设置请求的优先级，如JS和CSS优先。
服务器推送。服务器解析HTML里引用的资源，如CSS和JS，主动推送给浏览器。
头部压缩。使用HPACK压缩算法对请求头和响应头压缩。

解决了什么问题
因为只使用一个 TCP 连接，所以减少了由于 TCP 慢启动而消耗的时间，另外也由于只有单条 TCP 连接，所以不存在不同的 TCP 争夺网络带宽的问题。
客户端发送的请求经过二进制分帧层后，不再是一个个完整的 HTTP 请求报文，而是一堆乱序的帧（即不同流的帧是乱的，但是同一条流的帧数顺序传输的**），
所以就不会按顺序传输，也就不存在等待，从而解决了 HTTP 对头阻塞问题。

增加了一个二进制分帧层， 请求头在header帧，请求体在data帧。使用请求ID编号区分，服务器收到所有帧以后将相同ID的帧组合成完整的请求。

依然存在的问题：

• TCP队头阻塞，多个请求是跑在一个 TCP 连接中的，如果某个数据流中出现了丢包的情况，就会阻塞该 TCP 连接中的所有请求。
  
• TCP建立连接的延时。 在传输数据之前，需要进行 TCP 的 3 次握手，需要花费 1.5 个 RTT；如果是 HTTPS，那还需要进行 TLS 连接，又需要 1 ~ 2 个 RTT。
  
• TCP协议僵化。中间设备和操作系统的TCP存在很多特性，更新起来不方便。
  

HTTP/3

QUIC协议

• 实现了类似 TCP 的流量控制、传输可靠性的功能。
  
• 集成了 TLS 加密功能。
  
• 实现了 HTTP/2 中的多路复用功能。和 TCP 不同，QUIC 实现了在同一物理连接上可以有多个独立的逻辑数据流。实现了数据流的单独传输，就解决了 TCP 中队头阻塞的问题。
  
• 实现了快速握手功能。由于 QUIC 是基于 UDP 的，所以 QUIC 可以实现使用 0-RTT 或者 1-RTT 来建立连接，这意味着 QUIC 可以用最快的速度来发送和接收数据，这样可以大大提升首次打开页面的速度。
  

HTTP/3 的挑战

• 从目前的情况来看，服务器和浏览器端都没有对 HTTP/3 提供比较完整的支持。Chrome 虽然在数年前就开始支持 Google 版本的 QUIC，但是这个版本的 QUIC 和官方的 QUIC 存在着非常大的差异。
  
• 部署 HTTP/3 也存在着非常大的问题。因为系统内核对 UDP 的优化远远没有达到 TCP 的优化程度，这也是阻碍 QUIC 的一个重要原因。
  
• 中间设备僵化的问题。这些设备对 UDP 的优化程度远远低于 TCP，据统计使用 QUIC 协议时，大约有 3%～7% 的丢包率。