关于 tcp 的流量控制和拥塞控制

tcp 的传输其中要考虑的两个方面

一个是考虑对端的接收缓冲区大小如果对端的缓冲区已经满了你还一直发数据那你发过去的包只能被对端丢掉

另外一个考虑是发过去的包到达性并不好也就是说发三个包过去只有一个包对面回复说收到了。也就是 a 和 b 之间网络情况不好那么这个时候就要考虑发包频率控制一下减慢

第一个问题也就是流量控制这个好解决我们把接收缓冲区开大点

第二个问题 a 和 b 之间的网络好不好取决于很多东西理想情况下来说路宽车少

那么 a 和 b 的网络就会比较好

如果晚高峰车多那么 a 和 b 之间的网络到达性可能就比较差

然后 a 和 b 之间有没有一个网络瓶颈点就是 a 和 b 中间某一跳由于设备问题车多的问题等等

这一跳丢包率高

关于第二个问题应该是跟延迟没有关系

延迟一方面是取决于路的长短物理距离比较长延迟可能就比较高但是延迟高物理距离长也一样可以是路宽车少的情况这并不关联

选择什么样的线路也就是选择车少的路宽的路

物理距离长延迟高如果 a 和 b 之间的通信是交互性的

也就是说什么叫交互性的比如像 ssh 这样的

a 发一个命令然后 b 响应就像回合制游戏一样的

这个时候如果物理距离长延迟高就会非常难受了

如果交互是单向的比如说看 youtube 视频或者下载

都是 b 一直单方面向 a 发数据那么这个时候物理距离虽然长延迟比较高

也不影响

不知道我的理解对不对

uiiytwyfsdtr

241 天前

1 ，简要说明

对于 TCP 传输，出口带宽和网络带宽都很高，传输速率就比如很大吗？

答案是：不一定。

考虑这样一种场景：有一个主播在美国推流，国内用户观看直播，拉流速率很小，视频非常卡顿。分析发现，带宽其实并不小，只是延时比较大（大于 300ms ）。

所以说速率跟延时相关，延时大会导致速率变下。

2 ，速率跟延时的关系推导

由于 TCP 的滑动窗口特性，已发送出去的一组数据必须 ACK 之后（经过一个 RTT)，滑动窗口才会滑动，才可以发送下一组数据，一组数据大小为 SWND ，1S 之内可以发送 1000/RTT 组数据，于是速度为：

Rate = SWND*8*1000 / RTT

所以速率跟发送窗口成正比，跟 RTT 成反比；

其中：SWND(发送窗口) = min ｛ RWND(接收窗口), CWND(拥塞窗口)｝； RTT：往返延时

还有一个问题：跟进上面推到公式，如果 RTT 无线接近 0 那速率就无限大了吗？显然不会，但 RTT 小于某个值的时候，整个链路的速率就受限于带宽了。

uiiytwyfsdtr

240 天前

丢包重传注定要面对「头部阻塞」。如果一个 TCP 连接中某个数据包丢失，那么整个 TCP 数据流必须暂停，丢失的数据包需要重新传输，然后数据流才能继续。

TCP 这个协议对于代理来说是很不好的

因为代理一般来说都有延迟

因为你的代理服务器都是在国外的随随便便 60ms 100 多毫秒的延迟

总是 ack 之后再发下一个包的话带宽的利用率就被延迟严重阻碍了

延迟高就会导致带宽的利用率上不去

或者最起码是开始的时候上不去 tcp 的慢启动特性

对于延迟高的来说带宽一开始的利用率就会很低