如何解决国际链路上的 TCP 超时问题?

如何解决国际链路上的 TCP 超时问题?

我有一个使用 HTTP 进行通信的客户端/服务器应用程序。服务器与某些客户端位于地球的另一侧。服务器和客户端通信的流量带宽非常低。

晚上,全球任何地方的连接都还算正常,但不算很好,但白天海外连接就很差。只有居住在国内的用户才能连接,其他用户都会遇到 TCP 超时、重传等问题。我认为这是因为高峰时段网络流量增加导致延迟。

重新定位服务器是一个昂贵的选择。我想为运行客户端的用户提供一个方便的解决方案,而无需他们重新配置 Windows 超时等。我认为一个解决方案可能是在用户附近安装一个代理,它可以接受 TCP 连接,并且在连接到服务器时更加耐心。或者可能切换到 UDP。(然而,UDP 会很麻烦。)

也许我全都错了?是什么原因导致 HTTP 连接从 0:00UTC 到 9-11 UTC 一直良好,然后在一天的剩余时间里变得不稳定?在 Wireshark 中,我看到许多重复的 ACK、TCP 重新传输、丢失的段等。与服务器位于同一国家/地区的客户端没有抱怨。我已经测试过本地连接到我的服务器以及通过一些在线 Web 代理 (hidemyass.com),前者始终有效,而后者取决于一天中的时间。

编辑:我将 HTTP 流量从端口 8080 切换到端口 80,似乎有帮助!沿途的某个路由器是否可能对端口 80 流量的处理方式与端口 8080 不同?我也尝试了端口 81,但连接性也很差。有人听说过这样的事情吗?

答案1

如果您的服务器的带宽利用率在最糟糕的连接时间内没有达到峰值,
那么问题可能不在您的服务器本身,而很可能是在路径上;正如您所说。

您是否已向您的 ISP 咨询过此事?
如果您的共享连接在共享区域达到峰值,则您可能会损失可用带宽,但服务器测量结果中仍不会显示峰值利用率。

由于您在白天发现连接不良,我预计您上行链路附近的其他人会阻塞它 - 听起来很像您的邻居正在主动使用共享链接。


更新:回答评论中的问题,

  1. 重新检查您的 ISP 协议——保证的上传和下载带宽是多少?
  2. 与您的 ISP 讨论该问题(从客户支持开始并逐步升级)
  3. 检查您周围的其他 ISP,并尝试与他们的销售人员交谈以描述此问题。
    他们对此有何看法?
    他们有什么建议?
    (很多时候,了解情况的当地人对此类情况有更好的信息和解决方案)
  4. 尝试与另一家适合您的 ISP 讨论交易/协议。
    您应该寻找的是
    • 上传及下载带宽保证报价(针对报价)
    • 您可以随时检查的交付证明
      (例如,您那部分链接的 MRTG 数据;
      即使您有共享链接,最低带宽数字也是可引用的,应该是可测量的)
  5. 上一点也可以与你现在的 ISP 讨论
  6. 最后,如果你能从另一家 ISP 那里得到一个好的报价,
    你可以将其作为对当前 ISP 的最后筹码。
    如果失败了,你可以努力转向新的 ISP。

答案2

您需要更多信息。

作为故障排除步骤,我建议将连续的 tracert 转储到文件中。将其运行到多个目的地(城市、大陆)以隔离主要的 Internet 路径。如果您有可用的远程网络资源,那么您可以运行或安排吞吐量测试,以查看世界各地不同地点在一天中不同时间的性能情况。iPerf 是进行此类测试的好工具。

然后第二天查看/绘制结果,看看是否有模式表明问题可能发生在哪里。当然,由于跟踪路由是低优先级流量,并且被许多防火墙阻止,因此预计某些跳数会出现一定程度的丢失。如果可能,也从反方向运行相同的测试。您可能会面临不对称路径或其他奇怪的路由条件。有了这些信息,您可以在与 ISP 的对话中更加具体。

您使用的 ISP 可能不拥有国际连接,也可能是其他 ISP 造成了问题。将 ISP 切换到拥有通往主要国家/大陆的整个路径的 ISP 可能是合适的。

尼尔

相关内容