计算机网络系列http真的只能够使用tcp协议吗？

Posted 2021-07-11 猿猿HHH

前言：2018年，谷歌发布了http3.0协议，该协议使用的传输协议是以UDP为底层开发的QUIC协议，这意味着http协议首次“抛弃”tcp协议。

1、TCP协议到底怎么了？

现时的互联网应用中，Web平台（准确地说是基于HTTP及其延伸协议的客户端/服务器应用）的数据传输都基于 TCP 协议。
但TCP 协议在创建连接之前需要进行三次握手（相关过程本人博客中已经有不少文章介绍，在这就不赘述了），如果需要提高数据交互的安全性，既增加传输层安全协议（TLS），还会增加更多的更多握手次数。

TLS的初始化握手原理：

由此可见，TCP 协议连接建立的成本相对较高。

所以，一般的稳定网络传输都是通过TCP，但是在网络基建本身就已经越来越完善的情况下，TCP设计本身的问题便暴露了出来，特别是在弱网环境下，让我们不得不考虑一些新的可能性。

2、QUIC协议

QUIC 是 Quick UDP Internet Connections 的缩写，谷歌发明的新传输协议。

与 TCP 相比，QUIC 可以减少延迟。

QUIC 协议可以在 1 到 2 个数据包（取决于连接的服务器是新的还是已知的）内，完成连接的创建（包括 TLS）。

QUIC 协议握手原理图：

从表面上看：QUIC 非常类似于在 UDP 上实现的 TCP + TLS + HTTP/2。由于 TCP 是在操作系统内核和中间件固件中实现的，因此对 TCP 进行重大更改几乎是不可能的（TCP 协议栈通常由操作系统实现，如 Linux、Windows 内核或者其他移动设备操作系统。修改 TCP 协议是一项浩大的工程，因为每种设备、系统的实现都需要更新）。但是，由于 QUIC 建立在 UDP 之上，因此没有这种限制。QUIC 可以实现可靠传输，而且相比于 TCP，它的流控功能在用户空间而不在内核空间，那么使用者就不受限于 CUBIC 或是 BBR，而是可以自由选择，甚至根据应用场景自由调整优化。

QUIC 与现有 TCP + TLS + HTTP/2 方案相比，有以下几点主要特征：

1）利用缓存，显著减少连接建立时间；

2）改善拥塞控制，拥塞控制从内核空间到用户空间；

3）没有 head of line 阻塞的多路复用；

4）前向纠错，减少重传；

5）连接平滑迁移，网络状态的变更不会影响连接断线。

从图上可以看出，QUIC 底层通过 UDP 协议替代了 TCP，上层只需要一层用于和远程服务器交互的 HTTP/2 API。这是因为 QUIC 协议已经包含了多路复用和连接管理，HTTP API 只需要完成 HTTP 协议的解析即可。

3、QUIC协议的目标

QUIC 协议的主要目的，是为了整合 TCP 协议的可靠性和 UDP 协议的速度和效率。

对于 Google 来说优化 TCP 协议是一个长期目标，QUIC 旨在创建几乎等同于 TCP 的独立连接，但有着低延迟，并对类似 SPDY 的多路复用流协议有更好的支持。 如果 QUIC 协议的特性被证明是有效的，这些特性以后可能会被迁移入后续版本的 TCP 和 TLS 协议（它们都有很长的开发周期）。

值得注意的是，虽然理论上来说，如果 QUIC 的特性被证明是有效的，这些特性以后可能会被迁移到后续版本的 TCP 协议中，但鉴于TCP协议长达几十年在互联网通信里的垄断地位，以及这么多年积累下来的沉重历史报复，想要根本性地优化或改进TCP协议，难度相当大（或许，有些事情，只能是想想而已，IPV6还喊了这么多年呢，不是一样没普及。。。）。

4、QUIC协议这么好，可以大规模切换为QUIC吗？

理想和现实总是有一定的差距：虽然经过多年的推广的应用，但QUIC协议目前仍未达到大量普及的阶段，在 IETF上的QUIC 依然还是草稿，并且还存在Google QUIC与IETF QUIC两类不稳定的协定。

而且，QUIC还面临以下挑战：

1）小地方，路由封杀UDP 443端口（ 这正是QUIC 部署的端口）；

2）UDP包过多，由于QS限定，会被服务商误认为是攻击，UDP包被丢弃；

3）无论是路由器还是防火墙目前对QUIC都还没有做好准备。