Tcp 连接中断,对于串行来说太快了吗?

Tcp 连接中断,对于串行来说太快了吗?

我一直很难让 TCP 连接与我的 Web 服务器一起工作。我认为问题可能与数据包的速度或顺序有关,因为连接似乎一开始管理正常,但过了一会儿就失败了。我通过我编写的程序运行所有这些流量,然后通过旧的 SLIP 协议通过串行线路运行。我几乎没有找到有关如何使 TCP 连接变慢的信息​​,似乎其他人都在尝试另一种方法。如何限制 TCP 连接的速度?我想我需要降低每一方一次尝试发送的数量以及它们决定重新发送的速度。

另外,有人知道我该如何降低 Windows 7 电脑上的窗口大小吗?(充当尝试连接到服务器的客户端)因为我认为这可能有助于减慢速度。我尝试了所有注册表值,但似乎没有效果,我关闭了缩放和启发式方法,但它仍然使用 65500 的窗口。

以下是来自客户服务器端

答案1

由于我所从事的业务,我实际上通过高延迟情况对应用程序进行了相当多的测试......(我们使用各种 200 - 1400ms 延迟链接进行测试)

通常,我会设置一个 Linux 路由器并用它tc来模拟延迟和数据包丢失(等等)...但在 Windows 中,我从来没有费心去尝试。不过,我确实找到了一些可能对您的环境有用的东西...

http://jagt.github.io/clumsy/index.html

显然,您可以添加延迟、抖动、重复数据包等来模拟您正在寻找的任何内容。

... 话虽如此... 我非常怀疑排序/速度是否会导致 Windows 平台上的 tcp 连接出现严重问题。Windows 中的网络堆栈对无序或丢失的数据包非常可靠。连接更有可能由于缺少确认而终止... 或由于不活动而终止。更有可能的是,您没有让 Windows 维护 TCP 会话... 而是实现了您自己的 ACK/SYN/等... 并且没有实现故障安全超时。

市面上有一些 WAN 优化设备,它们可能会导致 TCP 会话人为保持活动状态,但会话已终止的问题。(例如,Riverbeds 就可能导致这种情况。)这些问题的排除可能变得非常复杂……但从我从您的数据包捕获中收集到的信息来看……Riverbed 不太可能在这里发挥作用。

最后要注意的是,请不要依赖截断的 pcap。如果使用,tcpdump请不要忘记指定-s 0捕获整个数据包,而不仅仅是截断的数据包。

相关内容