QUIC 协议基于 UDP， UDP 不可靠， QUIC 如何保证可靠性的呢

[lrs]

最近写代码练手，写一个网络发送文件的小程序，可选 TCP 或 UDP 为传输方案。写到 UDP 传输方案的时候发现丢包检测重传之类的逻辑越写越乱越写越复杂，于是准备看下 QUIC 怎么实现的。翻了翻 QUIC 的 RFC 文档，看的我头大。
比较好奇的是，既然 UDP 会丢包，包含传输控制信息的包也是会丢的。控制信息要是丢了，岂不就是 hang 在那里了啊。如果采用超时机制来保证控制信息的重传，这效率（传输速度）就没法保证了。
所以，QUIC 是如何做的呢

[binux]

你知道 TCP 是如何保证可靠性的吗？

[v2tudnew]

QUIC 好像有类似 RAID5 的校验机制，会多发一些包以用于修复，而且会根据丢包率多发多少包的。非专业人士只是看过介绍。

[chenset]

也是类似 TCP 的 ack 机制, 不过 TCP 是网卡硬件实现的,几乎不消耗 CPU. QUIC 目前是软件实现的, CPU 性能消耗非常大.

[sujin190]

tcp 的重传流控都已经搞了无数 paper 了，基础逻辑肯定是用超时、数据包到达顺序来做的，但是怎么做就不是一两句话说得清了，QUIC 用的还是这些重传流控方案，比如 CUBIC 或是 BBR，区别就是 QUIC 用户 http 这种短小数据量的可以不使用慢速开始，在现在网络较 http 请求传输量来说普遍十分高了，取消慢速开始可以显著提高初始传输速度和延迟

而且流控方案被实现在了用户空间，那么你也可以依据请求的类型啥的选择或动态改变重传流控方式，比如可以给视频使用抗拥塞但是网页请求用低延时的重传流控方案，也可以在请求时协商使用啥重传流控方案，tcp 的重传流控被实现的内核，通过内核参数控制，完全不可控啊也是坑死人

[nicebird]

重新实现一套 tcp 机制

[shyling]

重新实现 tcp

[ch2]

"如果采用超时机制来保证控制信息的重传，这效率（传输速度）就没法保证了"
要不然你以为为什么网络不好的时候 tcp 下载文件会掉速？

[PeakFish]

谁告诉你 udp 不可靠了

[raaaaaar]

@PeakFish ？

[des]

@chenset 没听说过网卡还干这活

[raaaaaar]

TCP 就是用不可靠的底层协议，来实现可靠传输的

[lrs]

@binux 具体不是很了解。

@v2tudnew 哦，就是冗余啊。感觉是在碰运气，因为不知道哪个会丢。

@chenset
@nicebird
好的(笑哭) 这回复言简意赅，一下就看懂了。

@sujin190 感谢花费篇幅解释。慢速开始是指 TCP 开始的几次握手吗？所以重点是流控方案，感觉要弄明白得花时间了。

@ch2 明白了。细想之后我有了一个新疑问：正常网络里，如果忽略硬件产生的问题和人为的因素（比如 QOS ），是什么引起的丢包呢，也就是不可靠的源头是什么？

[ch2]

@lrs #12 就跟送快递一样，路上中间某一个路由器某一时刻需要发的包实在太多了，堵在上面来不及发出去，超时了。更深层次的原因是，网络拥堵情况是动态的，不能使用固定的发包速率，所以发包的人需要试探一个理论上的发送速率最大值

[zengming00]

貌似单个包的大小如果小于 MTU 值还是比较可靠的

[v2tudnew]

确实属于碰运气，谷歌的意思应该是减少延迟、额外开销之类的，然后加上校验降低重传率（这样就不用等超时了），我个外人感觉还是可以的，如果对 UDP 和 TCP 都一样 QOS 公正的话。

[caola]

@lrs 现在 http/3 很快就要正式发布了，
nginx 目前可以通过其官方的 h3 补丁来增加支持，go 语言有 quic-go 包
至于如何实现的，建议你可以去查看源代码

QUIC 以后会慢慢取代 TCP 的地位

[Tianao]

TCP 协议基于 IP，IP 不可靠，TCP 如何保证可靠性的呢

[sujin190]

@lrs #12 并不是，满开始是 tcp 连接不知道网络有多少带宽可用，所以握手成功后，先发几个包，成功受到确认没有丢包才会慢慢增加发包数量，通俗点就是连接探测可用带宽的过程，现在宽带、4g 、5g 带宽都很大，对于 http 这种大多数情况下不会发送大量数据造成持久性网络拥塞的，已经没啥必要做慢开始过程了

[robot1]

看 kcp 文档

[GuuJiang]

@PeakFish ？？？