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

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 由网络底层的实现的功能被搬到了应用层
那么修改和改进起来就不需要经过等待操作系统以及网络设备的的更新来实现（也就不需要通过操作系统开发商和网络运营商的准许）获得了更大的自由度和控制力以及将来更大的改进空间

yyfearth

2019-10-20 16:34:52 +08:00

@iwtbauh 我说的底层主要是说操作系统的底层网络方面应该说是相对于 HTTP 应用层而言是相对底层的
另外我说的网络设备不一定是“中间网际路由器”或者那些工作在 L2/3/4 的设备现在已经很多网络设备是工作在 L7 的了所以 payload 不一定是透明的
正是因为目前这些设备已经会去感知 TCP 甚至 HTTP 所以很难去推动他们他们会去感知 QUIC 那也是之后的事情那么在这个还没有被感知的阶段里面 Google 就获得了足够的自由去修改
我同意你说这个是“政治问题” 至少对 Google 而言是的但是同时也是“技术问题” 如果一个技术发展的足够成熟稳定想要继续突破和改进就只能另辟蹊径

对于性能我是真去听过 Google 的专门的 QUIC 讲座的（虽然我没有能力亲自去验证毕竟我不是做网络或者 OS 的）
至少我也是学过操作系统的另外也了解了一些网络应用在操作系统实现的一些基本概念
之所以说性能更好是因为减少了系统调用导致的在内核空间和用户空间频繁切换的问题
如果所有功能全部有系统核心来处理当然会比全部由应用层处理快
但是现实是由于 TCP 很多功能是由核心处理的但是 HTTP 也有很多功能是有应用层实现的
反倒导致处理 HTTP 的时候需要频繁的做切换导致了一些性能的瓶颈（所以有了 User-Space TCP Stack 这样的方案和 QUIC 的想法就很类似）
而 UDP 在这方面就简单很多系统核心基本上就只管收发减少了切换的损耗也获得了更大的改进空间减少了对系统更新的依赖

jedihy

2019-10-21 02:45:11 +08:00

@sujin190 怎么会没有丢包？？你就是局域网多对一的发都会丢。这个 4G，5G 有什么关系，Wi-Fi，ethernet 都有可能出现丢包，这是拥塞或是链路错误造成的。

QUIC 是用来替代传输层的，上面跑 HTTP，SMB，FTP 都可以。当然要与现有的传输层比才有意义。

chinawrj

2019-10-21 08:31:10 +08:00

@sujin190 多看看 TCP 的拥塞控制，你就不这样说了

chinawrj

2019-10-21 08:33:03 +08:00

看完了 sujin190 的回复。建议大家放弃对他的治疗。等他自我疗伤之后再说

sujin190

2019-10-21 09:37:27 +08:00

@chinawrj #25 搞的换成 udp 就不需要拥塞控制是的，扯不扯

sujin190

2019-10-21 09:37:54 +08:00

@jedihy #24 问题不是丢不丢包，是丢包多大比率的问题

chinawrj

2019-10-21 16:31:28 +08:00

@sujin190 再见。

iwtbauh

2019-10-21 20:28:00 +08:00

@yyfearth #23

“之所以说性能更好是因为减少了系统调用导致的在内核空间和用户空间频繁切换的问题”

然而这是不可能的，即使你使用 quic，数据还是需要以某种形式传递给内核，还是需要调用基本同样数量的系统调用。TCP 的时候，你打开 TCP 套接字，然后调用 read/write 及变种（或 recv/send 及变种）来传递数据，现在虽然换到用户层实现流量控制，拥塞控制，但是 quic 发送时还是要对 UDP 套接字调用 read/write 及变种（或 recv/send 及变种）来传递数据。要想没有这方面的开销，唯一的办法就是无操作系统或者单用户操作系统。

由于将更多逻辑放到用户层，性能反而比内核层中实现性能有一些下降。

如果你说因为 quic 因为更先进的算法 /或者某种 offload 而导致比 TCP 快，倒是有可能的（但我个人不认为 quic 能在这方面超过 TCP 太多），你要是说因为放到用户层所以快，这个我是不能认同的。

至于放到用户层灵活性更好，这一点我没有意见，这也是我同意的 quic 的一种优势。

loong0xf

2019-10-21 23:17:05 +08:00

@sujin190

"我想说的是任何技术方案的进步和思考都是有好处的，我钦佩他们的工作和思考"

这句是否可以理解为：你倾佩他们的工作和思考，但是不赞成他们的方向。

“在简单应用网络条件又日趋良好的环境下确实带来非常大收益，但在应用交互日趋复杂的趋势下，这个改进却又是明显利大于弊的，任何技术方案的思考进步都不可能是没有负面的，这再正常不过了”

“回到丢包的问题 Google 也和你一样基于网络条件越来越好的前提下觉得重传应用层去做就可以了没必要 TCP 那样那么底层来保证 TCP 的有序分包传输和重传阻碍对于多路复用是个不小的障碍”

这应该是对第一段主题的进一步说明。

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

这段说的是在座的各位都不是好技术人，不能做出理性细致独立思考。google 做的尝试性工作虽然带来了带来的性能提升和价值收益，但成果不具备广泛适用性。

这段言下之意是各位的发言没有经过独立思考，没能认识到到 http3 的局限性。谷歌的尝试值得鼓励，但可惜没有选择更正确的方向。

loong0xf

2019-10-21 23:37:33 +08:00

@iwtbauh

系统调用带来性能提主要是依靠实现用户态网络协议栈。gquic，iquic 大都是基于系统协议栈，CPU 占用是比 TCP 高。性能优异是得益于流控以及多数据流互相不阻塞等特性。以后硬件提供 offload 后性能还有提升空间。

iwtbauh

2019-10-22 01:39:12 +08:00

@loong0xf #42

我反复读了你这段话，愣是没看明白你什么意思

“系统调用带来性能提主要是依靠实现用户态网络协议栈。”
系统调用带来什么性能提升，系统调用从来都是拖慢性能的地方。而且这和用户态协议栈又有什么关系。

“gquic，iquic 大都是基于系统协议栈，CPU 占用是比 TCP 高。”
前后的因果关系也太牵强了吧。基于系统协议栈，所以 CPU 占用高？你要是说 offload 的话，TCP 不 offload CPU 占用也高。

“性能优异是得益于流控以及多数据流互相不阻塞等特性。”
什么叫“互相不阻塞等待性”？

“以后硬件提供 offload 后性能还有提升空间。”
说的好像 TCP 不能 offload 一样

loong0xf

2019-10-22 11:21:18 +08:00

应该为“减少系统调用带来性能提主要是依靠实现用户态网络协议栈。”，复制上文的时头部没保存下来。

“前后的因果关系也太牵强了吧。基于系统协议栈，所以 CPU 占用高？你要是说 offload 的话，TCP 不 offload CPU 占用也高。”

这不是我自己拍脑袋推断出的结果，而是事实。

“什么叫“互相不阻塞等待性”？”

是指在一个链接多路复用时，互相不会阻塞。（ http2 多路复用，任意一个包发生阻塞，在同一链接上的多个流就都阻塞了）

“以后硬件提供 offload 后性能还有提升空间。”
这是说 quic 没有厂商愿意在协议定下来前做 offload （所以 QUIC 协议 CPU 占用高），不理解你如何能从这句话推断出我说 tcp 不能 offload。