HTTP/3就要来了，先看看我的解读

TCP虽然也是很老的协议，但应用广泛，操作系统内核中有对应的处理代码，BBR之类的新特性也可以大幅提升TCP的性能。但是QUIC放弃了TCP，据Google的文档，恰恰是因为TCP太稳定了，内核里的代码更新特别麻烦。此外，因为Linux内核设计之初并没有考虑多核的扩展问题，在多核(core)情况下反而会产生反复的陷核，造成进程阻塞，严重影响性能。

针对上面的问题，不少新的方案都把网络协议栈放到用户态处理，QUIC也顺应了这种大潮流。唯一的问题是，UDP的协议栈似乎还没有现成的让人满意的方案，或许我们还得再等待一段时间，才能用上可靠高效的方案。

第三个问题是服务端推送。

虽然很多人很想要这个特性，而且HTTP/2也确实加入了它，但关于它的应用仍然存在许多争议。简单说，HTTP/2的推送打破了HTTP传统的“一问一答”的通讯模式，在客户端没有请求的时候，服务端就可以给客户端发送数据，这难免被滥用(想想随处可见的那些最喜欢“在商言商”，最不喜欢谈“道德”的留言吧)，尽管Chrome的开发人员说它们会检查推送并阻止恶意内容，那也是要在收到推送数据之后进行，这个方案并不完善。

同时，服务端也可能不顾客户端的缓存，执意重复推送，造成带宽浪费。HTTP/3保留了推送，但机制有所不同。客户端需要先同意，服务端才可以推送。而且，客户端可以设置服务端推送上限，超过上限的推送会出错。尽管如此，推送如何能妥善利用，目前还没有公认明确的答案。

最后一个问题来自调试和支持的工具。

任何技术要想大规模工程应用，靠“标准实现”单打一肯定是不行的，因为无法切片，无法细粒度调试。在经典的HTTP技术栈中，各层都有对应的工具，比如IP层有ping和traceroute，传输层有telnet，应用层有curl，正是有这些工具簇拥着，开发人员才可以很方便地定位问题所处的层次和细节。HTTP/2虽然有改动，但调试工具也不少，curl可以支持，还有nghttp2、h2c等工具，初步形成了完整的体系。HTTP/3的改动很大，如果没有对应的调试支持工具，可以想象部署和迁移都不会容易。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!