HTTP的前世今生详解( 四 ) _网络教程

【HTTP的前世今生详解】
所以，QUIC 是一个在 UDP 之上的伪 TCP +TLS +HTTP/2 的多路复用的协议。
但是对于 UDP 还是有一些挑战的，这个挑战主要来自互联网上的各种网络设备，这些设备根本不知道是什么 QUIC，他们看 QUIC 就只能看到的就是 UDP，所以，在一些情况下，UDP 就是有问题的，

比如在 NAT 的环境下，如果是 TCP 的话，NAT 路由或是代理服务器，可以通过记录 TCP 的四元组（源地址、源端口，目标地址，目标端口）来做连接映射的，然而，在 UDP 的情况下不行了。于是，QUIC 引入了个叫 connection id 的不透明的 ID 来标识一个链接，用这种业务 ID 很爽的一个事是，如果你从你的 3G/4G 的网络切到 WiFi 网络（或是反过来），你的链接不会断，因为我们用的是 connection id，而不是四元组。

然而就算引用了 connection id，也还是会有问题，比如一些不够“聪明”的等价路由交换机，这些交换机会通过四元组来做 hash 把你的请求的 IP 转到后端的实际的服务器上，然而，他们不懂 connection id，只懂四元组，这么导致属于同一个 connection id 但是四元组不同的网络包就转到了不同的服务器上，这就是导致数据不能传到同一台服务器上，数据不完整，链接只能断了。所以，你需要更聪明的算法（可以参看 Facebook 的 Katran 开源项目）

好了，就算搞定上面的东西，还有一些业务层的事没解，这个事就是 HTTP/2 的头压缩算法 HPACK，HPACK 需要维护一个动态的字典表来分析请求的头中哪些是重复的，HPACK 的这个数据结构需要在 encoder 和 decoder 端同步这个东西。在 TCP 上，这种同步是透明的，然而在 UDP 上这个事不好干了。所以，这个事也必需要重新设计了，基于 QUIC 的 QPACK 就出来了，利用两个附加的 QUIC steam，一个用来发送这个字典表的更新给对方，另一个用来 ack 对方发过来的 update 。
目前看下来，HTTP/3 目前看上去没有太多的协议业务逻辑上的东西，更多是 HTTP/2 + QUIC 协议。但，HTTP/3 因为动到了底层协议，所以，在普及方面上可能会比 HTTP/2 要慢的多的多。但是，可以看到 QUIC 协议的强大，细思及恐，QUIC 这个协议真对 TCP 是个威胁，如果 QUIC 成熟了，TCP 是不是会有可能成为历史呢？