QUIC 能够多大程度提高系统吞吐量

[newshbb]

现在面临 QUIC 与常规 TCP 的选型，现在的一个考量是对服务器资源的要求，比如 1core / 1G 可以支持多少并发连接，我们的连接场景是有几百万保活长连接，未来会突破千万，但是数据量极少，主要流量也就是维持个心跳。当前我们使用 raw udp ，没有流控，一台 2core 的 VPS 勉强可以维持百万连接，虽然很省，但是缺点也很明显。也许大家会说硬件不值钱，不过我们的确很穷，让大家见笑了

大家误会了， 这里不是要跟 raw udp 比，是要跟 tcp 比，另外请不要讨论技术之外的东西

[opengps]

说硬件不值钱不是让你死命的优化提升软件，而是你业务总有涨到单硬件扛不住的程度，当你一台扛不住时候，你有必要去设计成支持集群的结构来增加服务器硬件。
换句话说，不太好听，硬件增加成本要比软件的优化成本低很多

[newshbb]

@opengps 说了不讨论这个

[Kinnice]

udp ？ 维持连接？

[zzhaolei]

几百万甚至突破千万的保活怎么还会没钱？业务不挣钱？

[newshbb]

@Kinnice 逻辑意义上的连接

[newshbb]

请大家讨论技术

[zengxs]

quic 不会比 udp 吞吐量更高，你这种场景基本上没啥能优化的了，raw udp 基本上就是吞吐量最大的方案
其他的优化看看调调内核参数管不管用吧

[zengxs]

#4 楼说的也没毛病，完全不赚钱的业务可以考虑砍掉或者降低发包频率
技术都是为业务服务的，完全脱离业务讨论技术不现实

[DefoliationM]

理论上 quic 可以连接数更多，quic 只需要监听一个 udp 端口，连接由自己生成的 id 确定，不像 tcp 需要 socket 四元组绑定。

[PureWhiteWu]

技术上说，quic 性能开销比 raw udp 大不知道多少。。。。

raw udp 已经是开销最低的方案了。

[PureWhiteWu]

或者这么说吧：
tcp 和 udp 一样是四层的，udp 论开销和性能比 tcp 强；
quic/http3 是 7 层协议，并且强绑定 TLS 1.3 （不然没法用），这开销不是一个量级的。

[ShinichiYao]

硬件增加成本要报账，码农优化代码成本 0 ，但总有再怎么抽码农鞭子也挤不出硬件资源的时候。回到技术：QUIC 可以比 TCP 提高吞吐量，你甚至可以基于实际业务手搓一个 MUIC 协议来最大化吞吐量，不过既然当前已经都 UDP 了再怎么优化也提高不了多少

[pengtdyd]

Google 声称 QUIC 将 Google 搜索响应的延迟减少了 3.6%

所以为了这点百分比，真的要花大力气切到 QUIC 吗？

[PureWhiteWu]

说 QUIC 性能好延迟低，是外网弱网环境下，和基于 TCP 的 HTTP/HTTP2 + TLS 对比，而不是和 raw udp 对比。

可以先了解一下 QUIC 发明的背景和要解决的问题。

[kuituosi]

QUIC 协议非常复杂，简单业务场景根本不划算

[0o0O0o0O0o]

感觉哪怕相对于基于 TCP 的 TLS ，QUIC 应该也没有理由在节省成本方面有优势，没有内核支持没有硬件加速，需要消耗更多的 CPU ，宣传重点似乎都在客户端一侧（减少 rtt 提升用户体验），看一些大厂分享的 QUIC 性能优化的经验文章也是尽可能减少用户空间的开销。何况你是和 raw udp 比。

- https://github.com/lxin/quic
- https://github.com/microsoft/net-offloads/blob/main/quic-encryption-offload.md
- https://lwn.net/Articles/903826/
- https://developer.volcengine.com/articles/7268132377786843147

没有实测的条件和需求，理解有误请纠正我

[0o0O0o0O0o]

@0o0O0o0O0o #16

补充：
- https://news.ycombinator.com/item?id=34207089
- https://news.ycombinator.com/item?id=19476439
- https://news.ycombinator.com/item?id=33455497
- https://news.ycombinator.com/item?id=34849229

[victorc]

一台 8core vps 一个月 1000 块钱，一个高级马龙一天的工资都不止这个数，做生意要会算账

[tulongtou]

@victorc 高级张继科的工资止这个数么🐶

[ZSeptember]

细说 raw udp 的问题是什么。
什么方案都要看业务场景，能用 udp 说明可靠性就没那么重要，为什么要换呢。

[newshbb]

@0o0O0o0O0o 谢谢，非常受用

[lloovve]

套方案？这个相当于一千块做个淘宝出来可以吗？目前这个连接水平感觉应该想当不错了

[inhzus]

之前工作的有限回忆：QUIC 仅适合作为 TCP 的备用通道，提升用户移动端网络条件较差情况下的使用体验，资源使用率（ CPU 等）是 TCP 的 1.5 倍以上。除非有优化需要，否则直接用 TCP

[newshbb]

@0o0O0o0O0o 我们的场景与 https://www.emqx.io/docs/en/latest/mqtt-over-quic/introduction.html#quic-vs-tcp-tls-test-comparisons 基本一致

[guazao]

即使移除 QUIC 中的 TLS1.3 协商流程 性能损耗也是异常的高于 TCP
可以参考我实现的 quic-fiber
https://github.com/hankai17/quic-fiber

[newshbb]

@guazao 你觉得这篇文章 https://segmentfault.com/a/1190000042239884/en 里的测试客观嘛？

[ttvast]

udp 何来连接数一说？

[Immunize]

QUIC-GO 上千连接数基本就是极限了。

[bv]

@Immunize #28 真的假的？有相关的测试文档没