这是一个创建于 241 天前的主题，其中的信息可能已经有所发展或是发生改变。
tcp 的传输其中要考虑的两个方面
一个是考虑 对端 的 接收缓冲区大小 如果对端的缓冲区已经满了 你还一直发数据 那你发过去的包只能被对端丢掉
另外一个考虑 是发过去的包 到达性并不好 也就是说 发三个包过去 只有一个包 对面回复说收到了。 也就是 a 和 b 之间网络情况不好 那么这个时候 就要考虑 发包频率 控制一下 减慢
第一个问题 也就是 流量控制 这个好解决 我们把接收缓冲区开大点
第二个问题 a 和 b 之间的网络 好不好 取决于很多东西 理想情况下来说 路宽车少
那么 a 和 b 的网络就会比较好
如果晚高峰 车多 那么 a 和 b 之间的网络到达性 可能就比较差
然后 a 和 b 之间有没有一个网络瓶颈点 就是 a 和 b 中间 某一跳 由于设备问题 车多的问题等等
这一跳丢包率高
关于第二个问题 应该是跟延迟没有关系
延迟一方面是取决于路的长短 物理距离比较长 延迟可能就比较高 但是延迟高 物理距离长 也一样可以 是路宽车少的情况 这并不关联
选择什么样的线路 也就是选择 车少的路 宽的路
物理距离长 延迟高 如果 a 和 b 之间的通信 是交互性的
也就是说 什么叫交互性的 比如像 ssh 这样的
a 发一个命令 然后 b 响应 就像回合制游戏一样的
这个时候 如果物理距离长 延迟高 就会非常难受了
如果交互是单向的 比如说 看 youtube 视频 或者下载
都是 b 一直单方面向 a 发数据 那么这个时候 物理距离虽然长 延迟比较高
也不影响
不知道我的理解对不对
7 条回复 • 2024-04-30 19:38:05 +08:00
 |
1
uiiytwyfsdtr OP 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 小于某个值的时候，整个链路的速率就受限于带宽了。 |
 |
2
kandaakihito 241 天前
@theshy2025 感觉第一种场景，中国内用户在带宽充足的前提下裸连海外流媒体网站之所以慢的主要原因，是由于丢包率很高，不断的重传导致滑动窗口一直往前滑不动
|
 |
3
qinze113 241 天前
视频流不都是 UDP 吗
|
|
4
uiiytwyfsdtr OP |
|
5
uiiytwyfsdtr OP 丢包重传注定要面对「头部阻塞」。如果一个 TCP 连接中某个数据包丢失，那么整个 TCP 数据流必须暂停，丢失的数据包需要重新传输，然后数据流才能继续。
TCP 这个协议 对于代理来说 是很不好的 因为代理一般来说 都有 延迟 因为你的代理服务器都是在国外的 随随便便 60ms 100 多毫秒的延迟 总是 ack 之后再发下一个包的话 带宽的利用率 就被延迟 严重阻碍了 延迟高 就会导致 带宽的利用率 上不去 或者最起码是开始的时候上不去 tcp 的慢启动特性 对于延迟高的来说 带宽一开始的利用率就会很低 |
 |
6
YekongTAT 240 天前
@theshy2025 udp qos 大不大还是建议自己测试，我这边 UDP 单线程可以拉满带宽，但是 TCP 就不行
|
|
7
uiiytwyfsdtr OP @YekongTAT 是哪个地方的电信吗 大概多大的流量能跑多久 晚高峰有没有丢包比较厉害？
|
Select Language