（转发）论导致 QUIC 失败的因素

wlj00339515

当今QUIC协议异常火爆，一片叫好声，看到前期有专家分析QUIC的缺点，泼泼冷水，希望它后续更加完善，特转发分享！
《转发》

新的 QUIC 和 HTTP/3 协议即将到来，这是可谓是网络发展的精华所在。 结合过去30年来网络实践中的经验和教训，新一代的协议栈针对性能、隐私、安全和灵活性方面，均有大幅的提升、改进。

当前，关于 QUIC 发展潜力的讨论，大都是基于此前 Google 进行的早期版本 QUIC的实验结果 。然而，其潜在的缺陷却很少有人讨论；此外，对于即将发布的标准版的功能特性，我们依然知之甚少。尽管大家对 QUIC 极其乐观和期待，但是，本文将一反常态，以“唱反调”的观点，探讨 QUIC 和 HTTP/3 在实践中可能失败的种种因素。为了尽可能客观、公正的陈述观点，在我的每一条观点后面，我将列举出若干的反对意见。希望读者能在两方的辩驳中，思考判断，得出自己的一些观点来。

注意：如果你尚不清楚 QUIC 和 HTTP/3 的具体情况，建议花点时间，快速了解下。以下这些资源，对你快速了解，或将有些帮助：

Mattias Geniar 的博客文章
Cloudflare 的文章
Robert Graham 评论
Daniel Stenberg(@bagder) 的 HTTP/3 详解
Patrick McManus 的邮件列表和博客文章
以及今年我本人在 DeltaVConf的探讨

1. 端到端 UDP 加密？

QUIC 的卖点之一，便是其端到端加密。在现有的 TCP 协议中，大部分的传输信息都是公开的，只有数据部分是加密的；而 QUIC 几乎对所有内容进行加密处理，并且应用数据完整性保护（图 1 ）。这将极大地提高隐私保护和数据安全性，避免数据被网络中间设备篡改。上述的改进，是 QUIC 采用 UDP 的主要原因之一：改进 TCP 太过困难了，牵一发而动全身。

图 1：TCP 和 QUIC 中（加密）字段的简化概念表示

• 网络运营商和 spin bit
  现今，网络运营商极少去优化和管理网络。他们无法确认某个数据包是 ACK 包还是重传包；对于拥塞控制/发送速率控制，除了丢包，他们别无它法。所以，对于某个给定的连接，要估算其 RTT（若该时间增大，意味着拥塞或 bufferbloat（缓冲区膨胀）） ，更是困难。
  

关于将这些标记添加回可见的 QUIC 头部已经有很多讨论，但最终结果是，只有 1 bit 用于 RTT 测算—— spin bit。这个“轮转位”的概念的是这样的：在每次往返时改变一次值，从而使得网络中间设备可以观察到变化并以这种方式估算 RTT，参见 图 2。虽然有点帮助，但是仍然地限制了运营商，特别是初始标识是 Chrome 和 Firefox 不支持的“轮转位”。QUIC 唯一支持的其他选项是“显式拥塞提醒”，它采用 IP 级别的标识来表示拥塞。

图 2：“轮转位”工作原理简述

• UDP 拦截、alt-svc
  不知道你会怎样做？但如果我是一个网络运营商，如果我正在进行 TCP 网络优化或者在应用特殊的安全措施，我会非常想要彻底地封锁 QUIC。对于网页浏览来说，拦截 443 端口上的 UDP 流量，并不会有什么问题。在开发 QUIC 时，Google 也认识到了该问题。为了搞清楚当前网络对 UDP/QUIC 的封锁情况，他们研究得出 3-5% 的网络不允许 QUIC 流量通过。结果看起来还不错，不过该数据并未包含不计其数的企业网络；此外，更重要的问题是，这种状况还会一直延续下去吗？如果 QUIC 应用的更加广泛后，这些网络会停止对 QUIC 的主动拦截吗（至少是在他们更新他们的防火墙和网络管理工具后）？
  在使用 quick-tracker conformance 工具测试我们自己的 QUIC 实现时，发生一个“有趣”的小故事：当测试一台在加拿大的服务器时，大部分测试突然失效。更进一步测试发现，一些 IP 段主动阻塞 QUIC 流量，导致了测试的失败。
  

拦截 QUIC 流量并不会对浏览网页的终端用户带来任何影响–网站照常访问。因为，无论如何浏览器（和服务器）必须要解决 UDP 阻塞问题。为此，他们总是把 TCP 留为备用措施，而不是干等着 QUIC 连接 timeout。
服务器将采用 alt—svc 机制提供对 QUIC 的支持，但浏览器只能在一定程度上信任它；因为快速变化的网络环境意味着 QUIC 随时有可能被拦截。在 QUIC 流量被拦截的企业网络里，网络管理员无需处理用户的各种问题同时还可以维持对网络的有力控制，他们何乐而不为呢？他们还无需为此额外地维护一个独立的 QUIC/HTTP3 协议栈。

最后，有人可能会问了：为什么这些巨头比如 Google 即使是极其不容易的情况下，还要开发部署 QUIC 协议呢？在我看来，像 Google 这样的巨头公司对他们从服务器到各个边缘网络的链路，有着绝对的掌控，同时，还与其他网络运营商有联系。他们或多或少是知道网络上的问题的，并通过调整负载均衡，路由和服务器来缓解这些问题。为了解决这些问题，在开发 QUIC 时，他们可能会做点手脚，比如在 QUIC 的非加密部分编码一些信息 – 连接 ID。该 18 字节长的域可以编码负载均衡信息在里头。他们还可以设想为其数据包添加额外的包头，一旦流量离开企业网络就将其剥离。所以，这样看来，在这个游戏中，这些巨头可能会失去一些，但是那些服务器提供商或是小公司会失去更多。

反对观点

• 由于其优秀的性能，终端用户迫切希望用上 QUIC ；
• 基于其自身的拥塞控制及快速启动配置，QUIC 并不需要性能增强的中间设备；
• 大部分网络并没有阻挡 QUIC 流量，大的变革同时也意味着大的机会；
• 运行 QUIC + HTTP/3 只需在现有的 TCP + HTTP/2 的服务器配置文件添加若干行配置即可。