常见批评

UDP永远不会通

很多企业、运营商和组织对53端口(DNS)以外的UDP流量进行拦截或者限流,因为这些流量近来常被滥用于攻击。特别是一些现有的UDP协议和实现易受放大攻击(amplification attack)威胁,攻击者可以控制无辜的主机向受害者投放发送大量的流量。

QUIC内置了对放大攻击的缓解处理。它要求初始数据包不小于1200字节,并且协议中限制,服务器在未收到客户端回复的情况下,不能发送超过请求大小三倍的响应内容。

内核处理UDP很慢

我们必须承认这在2018年的今天是一个事实。当然,UDP技术会发展,这些年开发者对UDP的重视程度也不够,这些东西都自不必说了。

对于大多数客户端来说,这个程度的“缓慢”从未被觉察到。

QUIC太吃CPU

类似上文的“UDP很慢”,一部分原因是TCP和TLS长期以来的成熟发展、改进,以及得到硬件协助,造成UDP看上去比较慢。

我们有理由期望这会随着时间得到改善。问题在于,这额外的CPU占用会对部署者带来多大的影响。

只有Google在弄

并非如此。Google通过大规模的部署证明,通过UDP部署这种协议可以正常运行且表现良好,这为IETF带来了初始的规范。

在那之后,很多公司和组织的人员都在这个利益方中立的IETF组织下推进标准化。在这个阶段,虽然Google的雇员也有参与,但Mozilla、Fastly、Cloudflare、Akamai、微软、Facebook、苹果等等很多公司的员工也参与进来,共同推进互联网的传输层协议。

进步太小

这个是一个观点,而不是批评。也许进步是很小,这可能与相距HTTP/2的发布很近有着关系,时间太短了。

HTTP/3在高丢包的网络中可能表现更好,它提供了更快的握手,所以能改善可感知和实际的延迟。这些进步足够推动人们在服务器和服务上部署HTTP/3的支持吗?时间以及未来的性能测试会给我们答案!

Last updated