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

[newshbb]

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

[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 真的假的？有相关的测试文档没