HTTP3 已经来了，运营商还要继续劣化 UDP 吗？

[cwbsw]

https://blog.cloudflare.com/http3-the-past-present-and-future/
电信还好，移动真的是不把 UDP 当人。
HTTP2 虽然实现了多路复用，但是由于是基于 TCP，只要发生重传，整个连接都要等待。
HTTP3 就解决了这个问题。
虽然 HTTP3 还远未普及，但是 Google 系部署 QUIC 已经很久了，相较于 HTTP2，真的是有人体感官可感知的显著性能提升。

[shuiyingwuhen]

先关注着吧

不知道以后会被弄残成啥样子

[loukky]

我的小站已经通过 cf 开通了这个 HTTP3，不过没感受到明显区别

[cest]

这时候就该说这是给 5G edge 设计的,拚那最後 1ms 的速度

[sujin190]

就算用 udp 丢包重传不也照样存在？就算用 udp 不照样需要重排重组重传算法，有啥区别，或许在多个请求间增加一点点性能，但也不可能很大吧，最大省的应该是连接的三次握手吧，现在这网络速度还能有人体感知提升你幻觉了吧

[cwbsw]

@sujin190
别云，多学习，多实践。

[yyfearth]

@sujin190 TCP 丢包会阻碍后面所有的包 QUIC 丢包没这么大的影响 更何况 HTTP2 是管道复用 自然会影响后面的请求
本来 HTTPS 是 TCP 握手+TLS 握手 现在省了

[iPhoneXI]

针对运营商 QOS UDP 的情况 是时候发明一个自适应 HTTP 算法了
检测到 QOS 严重时客户端服务端协商主动切到 TCP，丢包严重时切换到 QUIC
（滑稽

[sujin190]

@yyfearth #6 你认真的么？不重传丢了是要就挂了还是把一半请求数据直接返回浏览器了，还是认为一个请求都可以扔在一个 udp 包了，这怎么可能，现在这时代，一个网页大部分图片视频，能有多少用一个 udp 包就能解决的，或许在多个请求之间能减少一些相互影响，但时间效果远比现象的小，我倒是觉得 http3 完全是为了未来更复杂应用更复杂交互设计的，或许未来进入一个网页有几万个请求的时候，这个确实可以大幅改善性能，但就眼下 web 来说，不会有多少效果，新版本 http 协议普及本来就慢，现在就设计一个限制更少的协议是更好的

[love]

@sujin190 不要在这里意淫，看看为什么 HTTP3 为什么要用 UDP 再来说话

[alphatoad]

@sujin190 你说的有一定道理，我这边确实用 caddy 反代，测试结果发现基本没有区别

[est]

@sujin190 亲，这边建议你把 QUIC 白皮书过一遍哦。

[binux]

现代的网络能有多少重传？

[yyfearth]

@sujin190 丢包自然要重传 但是 TCP 是在底层实现的 而且只要丢包 再收到重传之前 后面所有的包都会被阻塞
而 HTTP3/QUIC 基于 UDP 就没有这个问题 丢包重传那个包 不会影响已经收到的或者还未收到的后面的包
这一点在 HTTP2 场景下尤为重要 因为管道复用 丢包严重的话 还不如 HTTP 1.1 多个 TCP 一起去拿了

HTTP3 完全不是只为了未来来设计的 现在就有这个需求 但是前提下是不对 UDP 进行劣化
尤其是当下的移动场景 TCP 一旦网络 IP 有变 就不得不断掉重来握手 UDP 没有这个问题

除此之外 TCP 大部分的功能是在系统底层以及网络设备硬件来实现和保证的 这一方面改进起来十分困难（比如你不能指望网络上面的路由器全部更新到新版本的 TCP 这种事情）
另一方面对系统网络核心的实现依赖大（比如搞个 BBR 算法改进还要等 Linux Kernal 更新） 而且系统调用切换频繁 HTTP3/QUIC 把很多本来依赖系统底层内核空间实现的功能 放到用户空间应用层来实现 性能上和灵活性都会好很多
比如更新一个 HTTP3/QUIC 的功能 只要浏览器自己或者服务器本身更新就可以做到 不用等系统或者网络硬件来实现
这样一来实现就很大程度上脱离了对底层系统的依赖

这些改进 对于一个技术快速迭代的时代尤为重要 Google 作为 HTTP 网络 Web 应用的最主要的内容提供者和受益者 自然要竭尽所能改进它所依赖的这些技术
所以对于 Google 来说 开发和推广 HTTP2/3 就是 “ 改善用户体验，加强开发实力，节省网络开支，掌控技术标准”

[br00k]

运营商大不了默认端口不限速咯。

[jedihy]

@sujin190 Head of line blocking。多路复用造成的问题。

[sujin190]

@jedihy #15 不要人云亦云啊，事实上这个问题是有，但是就现在网络宽带 4g 马上 5g 情况下，几乎不丢包，这个影响几乎没有，在较大数据传输的视频播发中几乎都从独立 cdn 获取，也不会和网页公用连接，用处比较大估计也就是跨国请求了，理论归理论，工程实现则会更看实际效果，就实际性能提升来说还是没有三次握手更有效果吧

[yyfearth]

@sujin190 先不说丢包的问题了 对于你的观点说是 “http3 完全是为了未来更复杂应用更复杂交互设计的”
其实 Google 仅仅是想从各个方面改进 HTTPS 这个他赖以生存的技术 并且作为这个标准的主要制定者
说 HTTP2/SPDY 是对 HTTP/HTTPS 网络应用层的修改 基本上面目全非
那么 HTTP3/QUIC

[loong0xf]

sujin190 是不是觉得 Google 以及 ietf 的人都没有你考虑的全面，所以浪费时间开发 http3 ？

[sujin190]

@loong0xf #18
@yyfearth #17 我想说的是任何技术方案的进步和思考都是有好处的，我钦佩他们的工作和思考，但这不是 0 或者 1 的问题，没有任何一个技术方案会成为银弹，能够在任何场景都带来良好的效果的方案是不存在的，良好技术方案是基于细致理论和工程限制选择取舍的结果

http 使用广泛不止在于浏览器端，其良好的适用性也在于其协议十分简单，这即代表这协议结构简单同时也是实现简单和协议状态管理的简单，用 udp 取代 tcp 多路复用带来了三次握手和多个请求间头部阻塞的性能提升，但是同时由应用层实现的重排重组重发 ack 算法必然增加协议实现的复杂性，有协议实现来实现的连接管理也使得 http 简单的无状态变成部分有状态化，在简单应用网络条件又日趋良好的环境下确实带来非常大收益，但在应用交互日趋复杂的趋势下，这个改进却又是明显利大于弊的，任何技术方案的思考进步都不可能是没有负面的，这再正常不过了

人云亦云，不能对技术方法实现以及现实场景做出理性细致独立思考不是一个好技术人，这也不利于自身进步，谷歌是跨国公司巨大的浏览器占有量和 web 跨国访问量，udp 取代 tcp 以及应用层实现的所带来的性能提升和价值收益是显而易见的，其所做工作和尝试并不能被否认，但是其是否具备广泛适用性和把 http 协议变成一个更复杂协议是否适合确实值得思考

@yyfearth #17 关于丢包这个问题我觉得你可以多去看看底层 ip tcp 再下结论，tcp 存在丢包重传，udp 仍然存在，基于现实甚至可能更为严重，这个是任何协议都无法规避的问题

[iwtbauh]

@yyfearth #13

“比如你不能指望网络上面的路由器全部更新到新版本的 TCP 这种事情”
原来现在人都被惯的 TCP 都成了底层了哦，根据端到端原则，中间网际路由器不应该涉及 TCP 层，TCP 数据流应被看作是透明的 payload。
换句话说，既然中间节点可以不遵守端到端原则而感知 TCP，你又怎么能保证它们不会感知 quic 呢，所以这说到底不是技术问题而是政治问题。

“把很多本来依赖系统底层内核空间实现的功能 放到用户空间应用层来实现 性能上和灵活性都会好很多”
灵活性当然会好很多，但是性能这个你是认真的？不如再去学习一个操作系统课程。在保证其他特性相同的情况下，计算机世界里几乎没有性能和灵活性兼得的情况。