这是一个创建于 1880 天前的主题，其中的信息可能已经有所发展或是发生改变。
https://blog.cloudflare.com/http3-the-past-present-and-future/
电信还好，移动真的是不把 UDP 当人。
HTTP2 虽然实现了多路复用，但是由于是基于 TCP，只要发生重传，整个连接都要等待。
HTTP3 就解决了这个问题。
虽然 HTTP3 还远未普及，但是 Google 系部署 QUIC 已经很久了，相较于 HTTP2，真的是有人体感官可感知的显著性能提升。
电信还好，移动真的是不把 UDP 当人。
HTTP2 虽然实现了多路复用，但是由于是基于 TCP，只要发生重传，整个连接都要等待。
HTTP3 就解决了这个问题。
虽然 HTTP3 还远未普及，但是 Google 系部署 QUIC 已经很久了，相较于 HTTP2，真的是有人体感官可感知的显著性能提升。
第 1 条附言 · 2019-10-22 11:40:28 +08:00
有没有提升你们都不愿意自己实践一下的吗？
UDP 科学了之后（当然不能是那种 UDP over TCP ），在 Chrome 和 App 上看 YouTube 能明显感知到更快了，顶着 200+ms 的延时体感和有本地 CDN 加持的国内视频站一样快甚至更快（指等待时间加载速度等指标而非带宽）。
UDP 科学了之后（当然不能是那种 UDP over TCP ），在 Chrome 和 App 上看 YouTube 能明显感知到更快了，顶着 200+ms 的延时体感和有本地 CDN 加持的国内视频站一样快甚至更快（指等待时间加载速度等指标而非带宽）。
 |
1
shuiyingwuhen 2019-10-19 13:08:06 +08:00
先关注着吧
不知道以后会被弄残成啥样子 |
 |
2
loukky 2019-10-19 13:13:17 +08:00 via Android
我的小站已经通过 cf 开通了这个 HTTP3，不过没感受到明显区别
|
 |
3
cest 2019-10-19 13:35:20 +08:00
这时候就该说这是给 5G edge 设计的,拚那最後 1ms 的速度
|
 |
4
sujin190 2019-10-19 13:45:09 +08:00 via Android
就算用 udp 丢包重传不也照样存在？就算用 udp 不照样需要重排重组重传算法，有啥区别，或许在多个请求间增加一点点性能，但也不可能很大吧，最大省的应该是连接的三次握手吧，现在这网络速度还能有人体感知提升你幻觉了吧
|
 |
6
yyfearth 2019-10-19 13:59:01 +08:00
@sujin190 TCP 丢包会阻碍后面所有的包 QUIC 丢包没这么大的影响 更何况 HTTP2 是管道复用 自然会影响后面的请求
本来 HTTPS 是 TCP 握手+TLS 握手 现在省了 |
 |
7
iPhoneXI 2019-10-19 14:00:38 +08:00
针对运营商 QOS UDP 的情况 是时候发明一个自适应 HTTP 算法了
检测到 QOS 严重时客户端服务端协商主动切到 TCP，丢包严重时切换到 QUIC （滑稽 |
|
8
sujin190 2019-10-19 14:18:30 +08:00
@yyfearth #6 你认真的么？不重传丢了是要就挂了还是把一半请求数据直接返回浏览器了，还是认为一个请求都可以扔在一个 udp 包了，这怎么可能，现在这时代，一个网页大部分图片视频，能有多少用一个 udp 包就能解决的，或许在多个请求之间能减少一些相互影响，但时间效果远比现象的小，我倒是觉得 http3 完全是为了未来更复杂应用更复杂交互设计的，或许未来进入一个网页有几万个请求的时候，这个确实可以大幅改善性能，但就眼下 web 来说，不会有多少效果，新版本 http 协议普及本来就慢，现在就设计一个限制更少的协议是更好的
|
 |
12
binux 2019-10-19 16:28:59 +08:00 via Android
现代的网络能有多少重传？
|
|
13
yyfearth 2019-10-19 17:04:13 +08:00  3
@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 就是 “ 改善用户体验，加强开发实力，节省网络开支，掌控技术标准” |
 |
14
br00k 2019-10-19 17:31:46 +08:00 via iPhone
运营商大不了默认端口不限速咯。
|
|
16
sujin190 2019-10-20 12:01:43 +08:00
@jedihy #15 不要人云亦云啊，事实上这个问题是有，但是就现在网络宽带 4g 马上 5g 情况下，几乎不丢包，这个影响几乎没有，在较大数据传输的视频播发中几乎都从独立 cdn 获取，也不会和网页公用连接，用处比较大估计也就是跨国请求了，理论归理论，工程实现则会更看实际效果，就实际性能提升来说还是没有三次握手更有效果吧
|
|
17
yyfearth 2019-10-20 14:33:10 +08:00
@sujin190 先不说丢包的问题了 对于你的观点说是 “http3 完全是为了未来更复杂应用更复杂交互设计的”
其实 Google 仅仅是想从各个方面改进 HTTPS 这个他赖以生存的技术 并且作为这个标准的主要制定者 说 HTTP2/SPDY 是对 HTTP/HTTPS 网络应用层的修改 基本上面目全非 那么 HTTP3/QUIC |
 |
18
loong0xf 2019-10-20 14:34:39 +08:00
sujin190 是不是觉得 Google 以及 ietf 的人都没有你考虑的全面，所以浪费时间开发 http3 ？
|
|
19
sujin190 2019-10-20 15:30:43 +08:00
@loong0xf #18
@yyfearth #17 我想说的是任何技术方案的进步和思考都是有好处的，我钦佩他们的工作和思考，但这不是 0 或者 1 的问题，没有任何一个技术方案会成为银弹，能够在任何场景都带来良好的效果的方案是不存在的，良好技术方案是基于细致理论和工程限制选择取舍的结果 http 使用广泛不止在于浏览器端，其良好的适用性也在于其协议十分简单，这即代表这协议结构简单同时也是实现简单和协议状态管理的简单，用 udp 取代 tcp 多路复用带来了三次握手和多个请求间头部阻塞的性能提升，但是同时由应用层实现的重排重组重发 ack 算法必然增加协议实现的复杂性，有协议实现来实现的连接管理也使得 http 简单的无状态变成部分有状态化，在简单应用网络条件又日趋良好的环境下确实带来非常大收益，但在应用交互日趋复杂的趋势下，这个改进却又是明显利大于弊的，任何技术方案的思考进步都不可能是没有负面的，这再正常不过了 人云亦云，不能对技术方法实现以及现实场景做出理性细致独立思考不是一个好技术人，这也不利于自身进步，谷歌是跨国公司巨大的浏览器占有量和 web 跨国访问量，udp 取代 tcp 以及应用层实现的所带来的性能提升和价值收益是显而易见的，其所做工作和尝试并不能被否认，但是其是否具备广泛适用性和把 http 协议变成一个更复杂协议是否适合确实值得思考 @yyfearth #17 关于丢包这个问题我觉得你可以多去看看底层 ip tcp 再下结论，tcp 存在丢包重传，udp 仍然存在，基于现实甚至可能更为严重，这个是任何协议都无法规避的问题 |
 |
20
iwtbauh 2019-10-20 15:56:43 +08:00 via Android
@yyfearth #13
“比如你不能指望网络上面的路由器全部更新到新版本的 TCP 这种事情” 原来现在人都被惯的 TCP 都成了底层了哦，根据端到端原则，中间网际路由器不应该涉及 TCP 层，TCP 数据流应被看作是透明的 payload。 换句话说，既然中间节点可以不遵守端到端原则而感知 TCP，你又怎么能保证它们不会感知 quic 呢，所以这说到底不是技术问题而是政治问题。 “把很多本来依赖系统底层内核空间实现的功能 放到用户空间应用层来实现 性能上和灵活性都会好很多” 灵活性当然会好很多，但是性能这个你是认真的？不如再去学习一个操作系统课程。在保证其他特性相同的情况下，计算机世界里几乎没有性能和灵活性兼得的情况。 |
 |
21
iRiven 2019-10-20 16:04:41 +08:00 via Android
会变成 Python 2 和 Python 3
|
|
22
yyfearth 2019-10-20 16:06:07 +08:00
@sujin190 没写完不小心发出去了
说 HTTP2/SPDY 是对 HTTP/HTTPS 网络应用层的修改 基本上面目全非 那么 HTTP3/QUIC 是对 TCP + TLS 这层的修改 那么就相当于直接推到从来了 但是 Google 没办法直接大规模改进和 TCP 和 TLS 并且快速推广 你看看要弄个 BBR 有多麻烦就知道 更不要说更底层的东西 比如这个丢包重传的机制等等 基本上不可能从根本上改变 于是 Google 就直接基于 UDP 重新实现一遍类似 TCP 的功能 协议变得复杂 这个在所难免 关键在于是否值得 对于终端用户而言 他们只需要把浏览器或者客户端更新就好 对于服务的提供商而言 可以增强用户体验 以及有可能节省一些网络开销 而且这些都是公开的标准 而且也有开源的实现 只有在中间的网络提供商没有从中获益 相反可能有不利 这个也是推广最大的风险所在 另外 HTTP 1.1/2/3 之间不一定是一个互相取代的关系 就像现在 USB 2.0 / 3.0 / 3.1 / 3.2 / 4 标准一样 要支持高版本 不一定要抛弃对低版本的支持 高版本功能和性能更好但是更复杂 对于键盘鼠标等低速设备 2.0 足够了 那么对于某些场景 HTTP 1.1 就足够了 但是要求高的场景自然需要更好的版本 那么 HTTP 用 TCP 还是 UDP 其实也应该只是一个选择 上层的应用接口可以是一样的 一般情况下除非有不可修复的安全因素或者实在太过时 不太可能直接淘汰掉现有版本 回到丢包的问题 Google 也和你一样 基于网络条件越来越好的前提下 觉得重传应用层去做就可以了 没必要 TCP 那样那么底层来保证 TCP 的有序分包传输和重传阻碍 对于多路复用是个不小的障碍 但是对于 Google 和网络开发者而言 HTTP3 用 UDP 一个巨大的优势就是 很多 TCP 由网络底层的实现的功能被搬到了应用层 那么修改和改进起来就不需要经过等待操作系统以及网络设备的的更新来实现（也就不需要通过操作系统开发商和网络运营商的准许） 获得了更大的自由度和控制力 以及将来更大的改进空间 |
|
23
yyfearth 2019-10-20 16:34:52 +08:00 1
@iwtbauh 我说的底层主要是说操作系统的底层 网络方面应该说是相对于 HTTP 应用层而言是相对底层的
另外我说的网络设备不一定是“中间网际路由器”或者那些工作在 L2/3/4 的设备 现在已经很多网络设备是工作在 L7 的了 所以 payload 不一定是透明的 正是因为目前这些设备已经会去感知 TCP 甚至 HTTP 所以很难去推动他们 他们会去感知 QUIC 那也是之后的事情 那么在这个还没有被感知的阶段里面 Google 就获得了足够的自由去修改 我同意你说这个是“政治问题” 至少对 Google 而言是的 但是同时也是“技术问题” 如果一个技术发展的足够成熟稳定 想要继续突破和改进就只能另辟蹊径 对于性能 我是真去听过 Google 的专门的 QUIC 讲座的（虽然我没有能力亲自去验证 毕竟我不是做网络或者 OS 的） 至少我也是学过操作系统的 另外也了解了一些网络应用在操作系统实现的一些基本概念 之所以说性能更好 是因为减少了系统调用导致的在内核空间和用户空间频繁切换的问题 如果所有功能全部有系统核心来处理当然会比全部由应用层处理快 但是现实是由于 TCP 很多功能是由核心处理的 但是 HTTP 也有很多功能是有应用层实现的 反倒导致处理 HTTP 的时候 需要频繁的做切换 导致了一些性能的瓶颈（所以有了 User-Space TCP Stack 这样的方案 和 QUIC 的想法就很类似） 而 UDP 在这方面就简单很多 系统核心基本上就只管收发 减少了切换的损耗 也获得了更大的改进空间 减少了对系统更新的依赖 |
 |
24
jedihy 2019-10-21 02:45:11 +08:00 via iPhone
@sujin190 怎么会没有丢包？？你就是局域网多对一的发都会丢。这个 4G，5G 有什么关系，Wi-Fi，ethernet 都有可能出现丢包，这是拥塞或是链路错误造成的。
QUIC 是用来替代传输层的，上面跑 HTTP，SMB，FTP 都可以。当然要与现有的传输层比才有意义。 |
 |
26
chinawrj 2019-10-21 08:33:03 +08:00
看完了 sujin190 的回复。建议大家放弃对他的治疗。等他自我疗伤之后再说
|
|
30
iwtbauh 2019-10-21 20:28:00 +08:00 via Android
@yyfearth #23
“之所以说性能更好 是因为减少了系统调用导致的在内核空间和用户空间频繁切换的问题” 然而这是不可能的，即使你使用 quic，数据还是需要以某种形式传递给内核，还是需要调用基本同样数量的系统调用。TCP 的时候，你打开 TCP 套接字，然后调用 read/write 及变种（或 recv/send 及变种）来传递数据，现在虽然换到用户层实现流量控制，拥塞控制，但是 quic 发送时还是要对 UDP 套接字调用 read/write 及变种（或 recv/send 及变种）来传递数据。要想没有这方面的开销，唯一的办法就是无操作系统或者单用户操作系统。 由于将更多逻辑放到用户层，性能反而比内核层中实现性能有一些下降。 如果你说因为 quic 因为更先进的算法 /或者某种 offload 而导致比 TCP 快，倒是有可能的（但我个人不认为 quic 能在这方面超过 TCP 太多），你要是说因为放到用户层所以快，这个我是不能认同的。 至于放到用户层灵活性更好，这一点我没有意见，这也是我同意的 quic 的一种优势。 |
|
31
loong0xf 2019-10-21 23:17:05 +08:00
@sujin190
"我想说的是任何技术方案的进步和思考都是有好处的，我钦佩他们的工作和思考" 这句是否可以理解为：你倾佩他们的工作和思考，但是不赞成他们的方向。 “在简单应用网络条件又日趋良好的环境下确实带来非常大收益，但在应用交互日趋复杂的趋势下，这个改进却又是明显利大于弊的，任何技术方案的思考进步都不可能是没有负面的，这再正常不过了” “回到丢包的问题 Google 也和你一样 基于网络条件越来越好的前提下 觉得重传应用层去做就可以了 没必要 TCP 那样那么底层来保证 TCP 的有序分包传输和重传阻碍 对于多路复用是个不小的障碍” 这应该是对第一段主题的进一步说明。 “人云亦云，不能对技术方法实现以及现实场景做出理性细致独立思考不是一个好技术人，这也不利于自身进步，谷歌是跨国公司巨大的浏览器占有量和 web 跨国访问量，udp 取代 tcp 以及应用层实现的所带来的性能提升和价值收益是显而易见的，其所做工作和尝试并不能被否认，但是其是否具备广泛适用性和把 http 协议变成一个更复杂协议是否适合确实值得思考” 这段说的是在座的各位都不是好技术人，不能做出理性细致独立思考。google 做的尝试性工作虽然带来了带来的性能提升和价值收益，但成果不具备广泛适用性。 这段言下之意是各位的发言没有经过独立思考，没能认识到到 http3 的局限性。谷歌的尝试值得鼓励，但可惜没有选择更正确的方向。 |
|
32
loong0xf 2019-10-21 23:37:33 +08:00
@iwtbauh
系统调用带来性能提主要是依靠实现用户态网络协议栈。gquic，iquic 大都是基于系统协议栈，CPU 占用是比 TCP 高。性能优异是得益于流控以及多数据流互相不阻塞等特性。 以后硬件提供 offload 后性能还有提升空间。 |
|
33
iwtbauh 2019-10-22 01:39:12 +08:00 via Android
@loong0xf #42
我反复读了你这段话，愣是没看明白你什么意思 “系统调用带来性能提主要是依靠实现用户态网络协议栈。” 系统调用带来什么性能提升，系统调用从来都是拖慢性能的地方。而且这和用户态协议栈又有什么关系。 “gquic，iquic 大都是基于系统协议栈，CPU 占用是比 TCP 高。” 前后的因果关系也太牵强了吧。基于系统协议栈，所以 CPU 占用高？你要是说 offload 的话，TCP 不 offload CPU 占用也高。 “性能优异是得益于流控以及多数据流互相不阻塞等特性。” 什么叫“互相不阻塞等待性”？ “以后硬件提供 offload 后性能还有提升空间。” 说的好像 TCP 不能 offload 一样 |
|
34
loong0xf 2019-10-22 11:21:18 +08:00
应该为“减少系统调用带来性能提主要是依靠实现用户态网络协议栈。”， 复制上文的时头部没保存下来。
“前后的因果关系也太牵强了吧。基于系统协议栈，所以 CPU 占用高？你要是说 offload 的话，TCP 不 offload CPU 占用也高。” 这不是我自己拍脑袋推断出的结果，而是事实。 “什么叫“互相不阻塞等待性”？” 是指在一个链接多路复用时，互相不会阻塞。 （ http2 多路复用，任意一个包发生阻塞，在同一链接上的多个流就都阻塞了） “以后硬件提供 offload 后性能还有提升空间。” 这是说 quic 没有厂商愿意在协议定下来前做 offload （所以 QUIC 协议 CPU 占用高）， 不理解你如何能从这句话推断出我说 tcp 不能 offload。 |
|
35
loong0xf 2019-10-22 11:24:25 +08:00
CPU 占用高不只是因为没有 offload，和 QUIC 调度复杂以及安全性要求都有关系。
|
Select Language