共计 3101 个字符，预计需要花费 8 分钟才能阅读完成。
| 导读 | 本文简单介绍了 HTTP 协议，以及介绍了 HTTP 的成长，不同 HTTP 解决的问题等方面，详细讲解了 HTTP3，感兴趣的小伙伴一起来看看吧 |
很多小伙伴可能还沉浸在 HTTP1.1 的世界无法自拔，但是时代的洪流已经带领我们来到了 HTTP3 的世界了。是的，你在桥上看风景，而桥边的房子上有人正在看你。
为了不被时代所抛弃，今天给大家讲解一下 HTTP3 的新特性。
HTTP 的全名叫做超文本传输协议，是万维网所基于的应用层传输协议。最初的版本是 HTTP 0.9，是在 80 年的后期产生的，后面在 1996 年升级到了 1.0.
但是 HTTP1.0 满足不了日益增长的物质文化需求和对美好世界的向往。所以在 1997 年出现了 HTTP1.1，随后到 2014 年，HTTP1.1 都一直都在更新。
然后到了 2015 年，为了适应快速发送的 web 应用和现代浏览器的需求，在 Google 的 SPDY 项目基础上发展出了新的 HTTP2 协议。
又过了 4 年，在 2019 年，Google 又开发出了一个新的协议标准 QUIC 协议，它就是 HTTP3 的基石，其目的是为了提高用户与网站和 API 交互的速度和安全性。
不同 HTTP 协议解决的问题也是不同的，HTTP1.1 有什么问题呢？
1. 因为 HTTP1.1 一个连接中数据是顺序传输的，所以会有 Head-of-line Blocking 的问题，如果前面是一个大的数据包，则会导致后续数据包的阻塞。
2.HTTP1.1 无法对请求头和 cookie 进行压缩，所以传输效率会比较低。
3. 为了保证缓冲区不会溢出，HTTP1.1 有一个 TCP 慢启动的功能，作为拥塞控制措施，协议反复探测网络以计算可用容量，但是这样就会导致多次数据的传输，从而导致消息的延时。
对于 HTTP2 来说，它使用二进制进行消息传输，并且将消息拆分成一个个的 stream，在 stream 中又包含了多个 frame，允许资源通过多路复用使用同一个连接发送，解决了行头阻塞的问题，并且还支持数据包的优先级和服务器推送。
但是 HTTP2 的服务器推送会导致应用程序变得复杂，TCP 级别的头阻塞的问题在数据包丢失并且必须重新以正确的顺序重新发送时，仍然可能发生。
要注意，HTTP/ 2 是 HTTP/1.1 的扩展，而不是它的替代品。应用程序语义保持不变，具有相同的 HTTP 方法、状态代码、URI 和标头字段。所以 HTTP/ 2 可以被用在任何使用 HTTP/1.1 的地方。
HTTP/ 2 在客户端和服务器之间使用单个 TCP 连接，该连接在交互期间保持打开状态。
虽然 HTTP/ 2 支持并发，但是过多的并发会导致 HTTP/ 2 服务器接收到大批量的请求，从而导致请求超时。
HTTP/ 3 的目标是通过解决 HTTP/ 2 的传输相关问题，在所有形式的设备上提供快速、可靠和安全的 Web 连接。为此，它使用了一种不同的传输层网络协议，称为 QUIC，该协议最初由 Google 开发的。
感慨一下，虽然最近中国在系统的应用方面有了一定的进步，但是看看这些底层的协议，还都是外国人搞出来的。
HTTP/ 2 和 HTTP/ 3 的根本区别在于，HTTP/ 2 底层使用的是 TCP 协议，而 HTTP/ 3 使用的是 QUIC，而 QUIC 的底层使用的是 UDP 协议。
我们看一下 HTTP/ 2 和 HTTP/ 3 的协议栈对比：
TCP 协议主要保证服务的可靠性和有序交付，但是 TCP 需要同握手来建立连接，这样做是为了确保客户端和服务器都存在并且他们愿意并且能够交换数据。但是，它也需要一个完整的网络往返才能完成，然后才能在连接上完成任何其他操作。如果客户端和服务器端相距比较远，那么就需要花费较多的时间来进行连接。
我们知道 UDP 是无连接的，所以它要比 TCP 简单很多。它不需要 TCP 这种建立多次连接的步骤，只需要发送数据包出去就够了。
所以使用 QUIC 的优点就在于减少了系统的延时，适用于可以容忍一些数据丢包的情况，比如在线游戏、广告竞价、在线视频、实时流等地方。
另外因为 UDP 支持广播，所以 HTTP3 还适用于广播应用中，如精确时间协议和路由信息协议等。
另外 HTTP3 还可以用在物联网、大数据和 VR 等方面。
既然 HTTP3 使用的是 QUIC 协议，那么 QUIC 到底是什么呢？
通常来说 QUIC 是一种通用传输协议，与 TCP 非常相似。为什么要打造一套新的协议呢？这是因为现有的 TCP 协议扩展起来非常困难，因为已经有太多太多的设备使用了各种不同的 TCP 协议的版本，如果想直接在现有的 TCP 协议上进行扩展非常困难，因为需要给这么多台设备进行升级几乎是不可能完成的任务。
所以 QUIC 在选择在 UDP 协议之上进行构建。QUIC 使用 UDP，主要是因为希望能让 HTTP/ 3 更容易部署，因为它已经被互联网上的所有设备所知并已实现.
QUIC 实际上就是在 UDP 基础上重写了 TCP 的功能，但是又比 TCP 更加智能，更高效的实现了 TCP 的核心功能。
接下来我们看下 QUIC 具体有哪些特征。
TLS 主要用来保证客户端和服务器端在数据传输过程的数据安全性，可以对明文数据进行加密传输。TLS1.3 是 TLS 协议的最新版本，在旧的版本如 TLS1.2 中，客户端和服务器端的握手至少需要两次网络往返，但是在 TLS1.3 中，将其减少到只有一次往返。
虽然在 HTTP/ 2 中是支持无加密传输模式，但是默认情况下所有的现代浏览器都不支持这种模式，所以 HTTP/ 2 必须配合 HTTPS 一起使用。长远看来 HTTPS 肯定是未来的趋势，所以在 QUIC 中，直接就使用了 TLS 1.3 协议。QUIC 本身就封装了 TLS1.3。
这样做的好处就是 QUIC 没办法运行明文，所以更加的安全。并且 QUIC 内置了加密协议，将传输和加密握手合二为一，节省了往返。
因为 QUIC 是全程加密的，所以对于某些 ISP 和中间网络来说，无法再对网络数据进行分析和统计，所以可能会限制它的使用。并且因为 QUIC 是单独对每个数据包进行加密的，在高并发的情况下，可能会造成性能问题。
传统的 HTTP1.1 和 HTTP2 底层协议是 TCP，虽然 HTTP2 在应用层可以将不同文件的数据拆分成一个个的 stream 放在同一个连接中进行传输。但是对于 TCP 本身来说，它并不知道这些 stream 属于不同的文件，它会将其当成同一个文件。所以如果发送数据丢包的情况，TCP 会重新发送所有的文件包。从而导致 HOL 阻塞的问题。
而 QUIC 更加细粒度一点，它可以在每个流的基础上执行丢包检测和恢复逻辑。从而只会重发失败的流，而不是整个文件。
在 TCP 中，如果我想要建立客户端和服务器端的连接，需要知道这 4 个元素：客户端 IP 地址 + 客户端端口 + 服务器 IP 地址 + 服务器端口。
如果这 4 个元素中有一个发送了变化，则需要重新建立 TCP 连接。并且需要根据应用程序级协议，重新启动进程中的操作。
比如你正在下载一个大的文件，但是网络地址突然发生了变化，则可能需要重新请求该文件。
为了解决这个问题，QUIC 引入了一个名为连接标识符 (CID) 的概念。每个连接都在上述 4 个元素中额外分配一个编号，用于标记客户端和服务器端的唯一连接。
因为这个 CID 是由 QUIC 定义的，所以不会随着网络迁移的变化而变化。从而不需要新的握手，这种情况被称为连接迁移。
好了，今天的 HTTP/ 3 和 QUIC 就介绍到这里，虽然我们没有涉及到底层的更多细节，但是相信大家应该都听得明白了，再总结一下，QUIC 实际上行就是在 UDP 协议之上，再造了一个更加高级有效的 TCP 协议。
