tcp 的传输其中要考虑的两个方面
一个是考虑 对端 的 接收缓冲区大小 如果对端的缓冲区已经满了 你还一直发数据 那你发过去的包只能被对端丢掉
另外一个考虑 是发过去的包 到达性并不好 也就是说 发三个包过去 只有一个包 对面回复说收到了。 也就是 a 和 b 之间网络情况不好 那么这个时候 就要考虑 发包频率 控制一下 减慢
第一个问题 也就是 流量控制 这个好解决 我们把接收缓冲区开大点
第二个问题 a 和 b 之间的网络 好不好 取决于很多东西 理想情况下来说 路宽车少
那么 a 和 b 的网络就会比较好
如果晚高峰 车多 那么 a 和 b 之间的网络到达性 可能就比较差
然后 a 和 b 之间有没有一个网络瓶颈点 就是 a 和 b 中间 某一跳 由于设备问题 车多的问题等等
这一跳丢包率高
关于第二个问题 应该是跟延迟没有关系
延迟一方面是取决于路的长短 物理距离比较长 延迟可能就比较高 但是延迟高 物理距离长 也一样可以 是路宽车少的情况 这并不关联
选择什么样的线路 也就是选择 车少的路 宽的路
物理距离长 延迟高 如果 a 和 b 之间的通信 是交互性的
也就是说 什么叫交互性的 比如像 ssh 这样的
a 发一个命令 然后 b 响应 就像回合制游戏一样的
这个时候 如果物理距离长 延迟高 就会非常难受了
如果交互是单向的 比如说 看 youtube 视频 或者下载
都是 b 一直单方面向 a 发数据 那么这个时候 物理距离虽然长 延迟比较高
也不影响
不知道我的理解对不对
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.