HTTP 协议发展史
HTTP 是浏览器与服务端之间最主要的通信协议，HTTP 是应用层协议（7层），应用层产生的数据会通过传输层协议作为载体来传输到互联网上的其他主机中，而其中的载体就是 TCP 协议（3.0使用UDP），基于 TCP 协议进行连接，然后传输对应内容信息。
20 世纪 60 年代，美国国防部高等研究计划署（ARPA）建立了 ARPA 网，这被认为是互联网的起源。70 年代，研究人员基于对 ARPA 网的实践和思考，发明出了著名的 TCP/IP 协议。该协议具有良好的分层结构和稳定的性能，并在 80 年代中期进入了 UNIX 系统内核，促使更多的计算机接入了网络。
1989 年，蒂姆伯纳斯-李博士发表了一篇论文，提出了在互联网上构建超链接文档系统的构想。在篇文章中他确立了三项关键技术：URI、HTML、HTTP。
基于这三项技术，可以把超文本系统完美地运行在互联网上，李博士把这个系统称为“万维网”（World Wide Web）。于是HTTP协议开始在互联网上流行，目前最常见的就是HTTP/1.1 以及 HTTP/2.0。
其实每一代 HTTP 协议的迭代都是建立在上一代 HTTP 的缺点上进行优化。
HTTP/0.9
1991 年 HTTP（HyperText Transfer Protocol，超文本传输协议）正式诞生，当时的版本是 0.9。从名字可以看出，该协议的作用是传输传输超文本内容 HTML。协议定义了客户端发起请求、服务端响应请求的通信模式。请求报文内容只有 1 行：GET + 请求的文件路径，由于没有区分消息类型，故此只有文本信息。
HTTP/1.0
随着互联网的发展以及浏览器的出现，单纯的文本内容已经无法满足用户需求了，浏览器希望通过 HTTP 来传输脚本、样式、图片、音频和视频等不同类型的文件，所以在 1996 年 HTTP 更新的 1.0 版本中引入了如下特性：
- 增加了 HEAD、POST 等新方法
- 增加了响应状态码，标记可能的错误原因
- 引入了协议版本号概念
- 引入了 HTTP Header（头部）的概念，让 HTTP 处理请求和响应更加灵活
- 传输的数据不再局限于文本
其中最核心的改变是增加了头部设定，头部内容以键值对的形式设置。请求头部通过 Accept 字段来告诉服务端可以接收的文件类型，响应头部再通过 Content-Type 字段来告诉浏览器返回文件的类型。头部字段不仅用于解决不同类型文件传输的问题，也可以实现其他很多功能如缓存、认证信息等。
HTTP/1.1
随着互联网的迅速发展，HTTP/1.0 也已经无法满足需求，最核心的就是连接问题，具体来说就是 HTTP/1.0 每进行一次通信，都需要经历建立连接、传输数据和断开连接三个阶段。当一个页面引用了较多的外部文件时，这个建立连接和断开连接的过程就会增加大量网络开销。
在HTTP/1.1中已经默认使用Connection: keep-alive，避免了连接建立和释放的开销，但服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。通过字段来判断当前请求的数据是否已经全部接收。不允许同时存在两个并行的响应。
为了解决 HTTP/1.0 的问题，1999 年推出的 HTTP/1.1 有以下特点：
- 长连接（Connection：keep-alive）：引入了 TCP 连接复用，即一个 TCP 默认不关闭，可以被多个请求复用
- 并发连接：对一个域名的请求允许分配多个长连接（缓解了长连接中的「队头阻塞」问题）
- 引入管道机制，一个 TCP 连接，可以同时发送多个请求。（响应的顺序必须和请求的顺序一致，因此不常用）
- 增加了 PUT、DELETE、OPTIONS、PATCH 等新的方法
- 新增缓存字段（cache-control E-tag）
- 请求头中引入了 range 字段，支持断点续传
- 允许响应数据分块（chunked），利于传输大文件
- 强制要求 Host 头，让互联网主机托管称为可能
HTTP/2.0
HTTP/1.1 通过长连接减少了大量创建/断开连接造成的性能消耗，但是它的并发能力受到限制，表现在两个方面：
- HTTP/1.1 中使用持久连接时，一个连接中同一时刻只能处理一个请求。当前的请求没有结束之前，其他的请求只能处于阻塞状态，这种情况被称为「队头阻塞」
- 浏览器为了减轻服务器的压力，限制了同一个域名下的 HTTP 连接数，即 6 ~ 8 个
2015 年正式发布的 HTTP/2 默认不再使用 ASCII 编码传输，而是改为二进制数据，来提升传输效率。
客户端在发送请求时会将每个请求的内容封装成不同的带有编号的二进制帧（Frame），然后将这些帧同时发送给服务端。服务端接收到数据之后，会将相同编号的帧合并为完整的请求信息。同样，服务端返回结果、客户端接收结果也遵循这个帧的拆分与组合的过程。
有了二进制分帧后，对于同一个域，客户端只需要与服务端建立一个连接即可完成通信需求，这种利用一个连接来发送多个请求的方式称为「多路复用」。每一条路都被称为一个 stream（流）。
HTTP/2.0 的主要改动包括：
- 数据通过二进制协议传输，不再是纯文本
- 多路复用，废弃了 1.1 中的管道
- 使用专用算法压缩头部，减少数据传输量
- 通过设置数据帧的优先级，让服务器优先处理某些请求
- 允许服务器主动向客户推送数据
- 头部字段全部改为小写；引入了伪头部的概念，出现在头部字段之前，以冒号开头
- 增强了安全性，“事实上”要求加密通信 SSL
HTTP/2.0 虽然已经发布了这么多年，不过由于 HTTP/1.1 实在太过经典和强势，目前 HTTP/2.0 的普及率还比较少，仍然有很多网站使用的是 HTTP/1.1 版本。
HTTP/3.0
当然 HTTP/2 也并非完美，如果客户端或服务端在通信时出现数据包丢失，或者任何一方的网络出现中断，那么整个 TCP 连接就会暂停。
HTTP/2 由于采用二进制分帧进行多路复用，通常只使用一个 TCP 连接进行传输，在丢包或网络中断的情况下后面的所有数据都被阻塞。
但对于 HTTP/1.1 来说，可以开启多个 TCP 连接，任何一个 TCP 出现问题都不会影响其他 TCP 连接，剩余的 TCP 连接还可以正常传输数据。这种情况下 HTTP/2 的表现就不如 HTTP/1 了。
2018 年 HTTP/3 将底层依赖的 TCP 改成 UDP，从而彻底解决了这个问题。UDP 相对于 TCP 而言最大的特点是传输数据时不需要建立连接，可以同时发送多个数据包，所以传输效率很高，缺点就是没有确认机制来保证对方一定能收到数据，于是 Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上，目前许多游览器与硬件厂商已经开始尝试兼容 HTTP/3.0协议。
QUIC 协议
QUIC 的小写是 quic，谐音 quick，意思就是快。它是 Google 提出来的一个基于 UDP 的传输协议，所以 QUIC 又被叫做 "快速 UDP 互联网连接"。QUIC 的第一个特征就是快，为什么说它快，它到底快在哪呢？
我们大家知道，HTTP 协议在传输层是使用了 TCP 进行报文传输，而且 HTTPS 、HTTP/2.0 还采用了 TLS 协议进行加密，这样就会导致三次握手的连接延迟：即 TCP 三次握手（一次）和 TLS 握手（两次），如下图所示。
对于很多短连接场景，这种握手延迟影响较大，而且无法消除。毕竟 RTT 是人类和效率的终极斗争。
相比之下，QUIC 的握手连接更快，因为它使用了 UDP 作为传输层协议，这样能够减少三次握手的时间延迟。而且 QUIC 的加密协议采用了 TLS 协议的最新版本 TLS 1.3，相对之前的 TLS 1.1-1.2，TLS1.3 允许客户端无需等待 TLS 握手完成就开始发送应用程序数据的操作，可以支持1 RTT 和 0 RTT，从而达到快速建立连接的效果。
我们上面还说过，HTTP/2.0 虽然解决了队头阻塞问题，但是其建立的连接还是基于 TCP，无法解决请求阻塞问题。
而 UDP 本身没有建立连接这个概念，并且 QUIC 使用的 stream 之间是相互隔离的，不会阻塞其他 stream 数据的处理，所以使用 UDP 并不会造成队头阻塞。
在 TCP 中，TCP 为了保证数据的可靠性，使用了序号+确认号机制来实现，一旦带有 synchronize sequence number 的包发送到服务器，服务器都会在一定时间内进行响应，如果过了这段时间没有响应，客户端就会重传这个包，直到服务器收到数据包并作出响应为止。
那么 TCP 是如何判断它的重传超时时间呢？
TCP 一般采用的是自适应重传算法，这个超时时间会根据往返时间 RTT 动态调整的。每次客户端都会使用相同的 syn 来判断超时时间，导致这个 RTT 的结果计算的不太准确。
虽然 QUIC 没有使用 TCP 协议，但是它也保证了可靠性，QUIC 实现可靠性的机制是使用了 Packet Number，这个序列号可以认为是 synchronize sequence number 的替代者，这个序列号也是递增的。与 syn 所不同的是，不管服务器有没有接收到数据包，这个 Packet Number 都会 + 1，而 syn 是只有服务器发送 ack 响应之后，syn 才会 + 1。
比如有一个 PN = 10 的数据包在发送的过程中由于某些原因迟迟没到服务器，那么客户端会重传一个 PN = 11 的数据包，经过一段时间后客户端收到 PN = 10 的响应后再回送响应报文，此时的 RTT 就是 PN = 10 这个数据包在网络中的生存时间，这样计算相对比较准确。
虽然 QUIC 保证了数据包的可靠性，但是数据的可靠性是如何保证的呢？
QUIC 引入了一个 stream offset 的概念，一个 stream 可以传输多个 stream offset，每个 stream offset 其实就是一个 PN 标识的数据，即使某个 PN 标识的数据丢失，PN + 1 后，它重传的仍旧是 PN 所标识的数据，等到所有 PN 标识的数据发送到服务器，就会进行重组，以此来保证数据可靠性。到达服务器的 stream offset 会按照顺序进行组装，这同时也保证了数据的顺序性。
众所周知，TCP 协议的具体实现是由操作系统内核来完成的，应用程序只能使用，不能对内核进行修改，随着移动端和越来越多的设备接入互联网，性能逐渐成为一个非常重要的衡量指标。虽然移动网络发展的非常快，但是用户端的更新却非常缓慢，我仍然看见有很多地区很多计算机还仍旧使用 xp 系统，尽管它早已发展了很多年。服务端系统不依赖用户升级，但是由于操作系统升级涉及到底层软件和运行库的更新，所以也比较保守和缓慢。
QUIC 协议的一个重要特点就是可插拔性，能够动态更新和升级，QUIC 在应用层实现了拥塞控制算法，不需要操作系统和内核的支持，遇到拥塞控制算法切换时，只需要在服务器重新加载一边即可，不需要停机和重启。
我们知道 TCP 的流量控制是通过滑动窗口来实现的。
而 QUIC 也实现了流量控制，QUIC 的流量控制也是使用了窗口更新 window_update，来告诉对端它可以接受的字节数。
TCP 协议头部没有经过加密和认证，所以在传输的过程中很可能被篡改，与之不同的是，QUIC 中的报文头部都是经过认证，报文也经过加密处理。这样只要对 QUIC 的报文有任何修改，接收端都能够及时发现，保证了安全性。
总的来说，QUIC 具有下面这些优势
- 使用 UDP 协议，不需要三次连接进行握手，而且也会缩短 TLS 建立连接的时间。
- 解决了队头阻塞问题。
- 实现动态可插拔，在应用层实现了拥塞控制算法，可以随时切换。
- 报文头和报文体分别进行认证和加密处理，保障安全性。
- 连接能够平滑迁移。
连接平滑迁移指的是，你的手机或者移动设备在 4G 信号下和 WiFi 等网络情况下切换，不会断线重连，用户甚至无任何感知，能够直接实现平滑的信号切换。目前QUCI 协议已经被写在了 RFC 9000 中。
相信在未来的发展中，HTTP3.0应该会在越来越多的场景被使用。