我有一个使用 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 咨询过此事？
如果您的共享连接在共享区域达到峰值，则您可能会损失可用带宽，但服务器测量结果中仍不会显示峰值利用率。
由于您在白天发现连接不良，我预计您上行链路附近的其他人会阻塞它 - 听起来很像您的邻居正在主动使用共享链接。
更新：回答评论中的问题，
- 重新检查您的 ISP 协议——保证的上传和下载带宽是多少？
- 与您的 ISP 讨论该问题（从客户支持开始并逐步升级）
- 检查您周围的其他 ISP，并尝试与他们的销售人员交谈以描述此问题。
他们对此有何看法？
他们有什么建议？
（很多时候，了解情况的当地人对此类情况有更好的信息和解决方案） - 尝试与另一家适合您的 ISP 讨论交易/协议。
您应该寻找的是- 上传及下载带宽保证报价（针对报价）
- 您可以随时检查的交付证明
（例如，您那部分链接的 MRTG 数据；
即使您有共享链接，最低带宽数字也是可引用的，应该是可测量的）
- 上一点也可以与你现在的 ISP 讨论
- 最后，如果你能从另一家 ISP 那里得到一个好的报价，
你可以将其作为对当前 ISP 的最后筹码。
如果失败了，你可以努力转向新的 ISP。
答案2
您需要更多信息。
作为故障排除步骤，我建议将连续的 tracert 转储到文件中。将其运行到多个目的地（城市、大陆）以隔离主要的 Internet 路径。如果您有可用的远程网络资源，那么您可以运行或安排吞吐量测试，以查看世界各地不同地点在一天中不同时间的性能情况。iPerf 是进行此类测试的好工具。
然后第二天查看/绘制结果，看看是否有模式表明问题可能发生在哪里。当然，由于跟踪路由是低优先级流量，并且被许多防火墙阻止，因此预计某些跳数会出现一定程度的丢失。如果可能，也从反方向运行相同的测试。您可能会面临不对称路径或其他奇怪的路由条件。有了这些信息，您可以在与 ISP 的对话中更加具体。
您使用的 ISP 可能不拥有国际连接，也可能是其他 ISP 造成了问题。将 ISP 切换到拥有通往主要国家/大陆的整个路径的 ISP 可能是合适的。
尼尔