1
binux 2021-05-19 10:44:18 +08:00 via Android
你知道 TCP 是如何保证可靠性的吗?
|
2
v2tudnew 2021-05-19 11:09:21 +08:00
QUIC 好像有类似 RAID5 的校验机制,会多发一些包以用于修复,而且会根据丢包率多发多少包的。非专业人士只是看过介绍。
|
3
chenset 2021-05-19 11:18:41 +08:00
也是类似 TCP 的 ack 机制, 不过 TCP 是网卡硬件实现的,几乎不消耗 CPU. QUIC 目前是软件实现的, CPU 性能消耗非常大.
|
4
sujin190 2021-05-19 11:27:37 +08:00 3
tcp 的重传流控都已经搞了无数 paper 了,基础逻辑肯定是用超时、数据包到达顺序来做的,但是怎么做就不是一两句话说得清了,QUIC 用的还是这些重传流控方案,比如 CUBIC 或是 BBR,区别就是 QUIC 用户 http 这种短小数据量的可以不使用慢速开始,在现在网络较 http 请求传输量来说普遍十分高了,取消慢速开始可以显著提高初始传输速度和延迟
而且流控方案被实现在了用户空间,那么你也可以依据请求的类型啥的选择或动态改变重传流控方式,比如可以给视频使用抗拥塞但是网页请求用低延时的重传流控方案,也可以在请求时协商使用啥重传流控方案,tcp 的重传流控被实现的内核,通过内核参数控制,完全不可控啊也是坑死人 |
5
nicebird 2021-05-19 11:42:00 +08:00
重新实现一套 tcp 机制
|
6
shyling 2021-05-19 11:43:35 +08:00
重新实现 tcp
|
7
ch2 2021-05-19 11:49:30 +08:00 1
"如果采用超时机制来保证控制信息的重传,这效率(传输速度)就没法保证了"
要不然你以为为什么网络不好的时候 tcp 下载文件会掉速? |
8
PeakFish 2021-05-19 12:01:05 +08:00
谁告诉你 udp 不可靠了
|
11
raaaaaar 2021-05-19 12:11:29 +08:00 via Android
TCP 就是用不可靠的底层协议,来实现可靠传输的
|
12
lrs OP |
13
ch2 2021-05-19 12:19:37 +08:00
@lrs #12 就跟送快递一样,路上中间某一个路由器某一时刻需要发的包实在太多了,堵在上面来不及发出去,超时了。更深层次的原因是,网络拥堵情况是动态的,不能使用固定的发包速率,所以发包的人需要试探一个理论上的发送速率最大值
|
14
zengming00 2021-05-19 12:20:48 +08:00
貌似单个包的大小如果小于 MTU 值还是比较可靠的
|
15
v2tudnew 2021-05-19 12:22:23 +08:00
确实属于碰运气,谷歌的意思应该是减少延迟、额外开销之类的,然后加上校验降低重传率(这样就不用等超时了),我个外人感觉还是可以的,如果对 UDP 和 TCP 都一样 QOS 公正的话。
|
16
caola 2021-05-19 12:28:26 +08:00
@lrs 现在 http/3 很快就要正式发布了,
nginx 目前可以通过其官方的 h3 补丁来增加支持,go 语言有 quic-go 包 至于如何实现的,建议你可以去查看源代码 QUIC 以后会慢慢取代 TCP 的地位 |
17
Tianao 2021-05-19 12:29:43 +08:00 via iPhone
TCP 协议基于 IP,IP 不可靠,TCP 如何保证可靠性的呢
|
18
sujin190 2021-05-19 14:20:01 +08:00 1
@lrs #12 并不是,满开始是 tcp 连接不知道网络有多少带宽可用,所以握手成功后,先发几个包,成功受到确认没有丢包才会慢慢增加发包数量,通俗点就是连接探测可用带宽的过程,现在宽带、4g 、5g 带宽都很大,对于 http 这种大多数情况下不会发送大量数据造成持久性网络拥塞的,已经没啥必要做慢开始过程了
|
19
robot1 2021-05-19 14:26:46 +08:00
看 kcp 文档
|
21
jim9606 2021-05-19 17:02:21 +08:00
如果你只是搞上层应用,别自己写,直接搬别人的实现就是了。
( https://github.com/lucas-clemente/quic-go ) 真要深入研究这个你得先把 TCP 的设计搞清楚,这玩意往大的说,能写一本厚书了。 |
22
wellsc 2021-05-19 18:06:29 +08:00
64 位 id + 重传
|
23
tiddarabbit 2021-05-19 20:21:26 +08:00
@chenset "TCP 是网卡硬件实现的,几乎不消耗 CPU" 😵😵😵😵😵
|
24
Love4Taylor 2021-05-19 21:00:20 +08:00 via iPhone
@des 他说的应该是 TCP 卸载
|
26
joyqi 2021-05-19 21:12:55 +08:00
质不够量来凑
|
27
chenset 2021-05-19 21:42:15 +08:00
#3 严重错误, 请忽略
|
28
ysc3839 2021-05-19 23:07:01 +08:00 via Android
你是想自己实现一个 UDP 可靠传输协议吗?
还是说只是希望自己写的小程序走 UDP 传输的同时保证可靠? 如果是后者,建议使用 KCP 之类现成的协议。 |
29
msg7086 2021-05-20 05:09:04 +08:00 1
@lrs #12 丢包的本源就是缓冲区满了。(这个在计算机网络课程里应该有讲到。)
#13 的快递比喻基本是正确的,但是丢包一般是因为缓冲区满了。 缓冲区就相当于快递集散点的仓库,短时间内快递多,可以先堆着慢慢送,但是如果遇到过节大甩卖,快递多到仓库都堆不下了,爆仓了,那么对于硬件设备来说就是直接丢弃掉了。 因为丢弃的包不会有回传消息,所以在软件这边看来就是等待直到超时。 因为超时对发送流量的影响更大,所以一般的流控会选择主动减速,空出缓冲区,保证发出去的包都不会因为爆仓而丢弃。但是这个减速的机制则需要微调个几十年。 |
30
wanguorui123 2021-05-20 07:29:31 +08:00 via iPhone
纠错算法了解下
|
31
lrs OP @PeakFish #8 我是在网上看的好多地方描述 UDP 的时候都写 unreliable
@shyling #6 @raaaaaar #11 @v2tudnew #15 @robot1 #19 @jim9606 #21 @wellsc #22 @wanguorui123 #30 好的,多谢指点 @ch2 #13 @sujin190 #18 @msg7086 #29 明白了,感谢解释 @zengming00 #14 一般都是小于 MTU 的吧 @caola #16 嗯,已经找了 quinn 的代码在看 @Tianao #17 哈哈哈,不要这样造句啦 @joyqi #26 嗯,然后凑也是有讲究 @ysc3839 #28 只是写着玩儿,后来发现 UDP 做可靠性挺复杂,自己实现一个感觉不大现实,还没那么强做不到呐。多谢指点,我去找下 KCP 文档看看 |