最大限度地减少与远程服务器交换消息的网络时间
我寻求帮助的情况是这样的：美国东海岸的一家企业，以随机的时间间隔，通过公共互联网向一组订阅这些消息的监听分包商发布消息。每条消息都宣布可分包的工作单元的可用性。第一个以接受消息进行响应的订阅者随后将被授予该工作，该接受消息表明其具有立即执行该工作的能力。一家分包商位于美国中西部。另一个在美国西海岸。由于消息通过互联网到达西海岸分包商以及其响应返回东海岸所需的时间稍长，西海岸分包商尝试接受所提供的工作单元通常为时已晚（即使西海岸分包商也有能力完成这项工作，即较近的分包商已表示接受并获得了这项工作。我正在寻找改善运输时间的最佳方法，以克服西海岸分包商的距离劣势（通过 T1 线路连接到互联网）。有什么建议吗？ （如果这个问题的论坛是错误的，欢迎提出更好的论坛的建议。）
The situation I seek help with is this: A business on the east coast of the US, at random intervals, posts messages via the public internet to a set of listening subcontractors who subscribe to these messages. Each message announces availability of a unit of work to be subcontracted. The first subscriber who responds with an acceptance message indicating it has immediate capacity to perform the work is then awarded that work. One subcontractor is located in the US midwest. Another on the US west coast. Due to the slightly longer time it takes for the messages to reach the west coast subcontractor via the internet, and for its responses to get back to the east coast, the west coast subcontractor's attempts to accept an offered unit of work are often too late (i.e. the nearer subcontractor has already signaled acceptance and been awarded the work) even though the west coast subcontractor also has capacity to do the work. I'm looking for the best way to improve transit time to overcome the distance disadvantage for the west coast subcontractor (connected to the internet via a T1 line). Any suggestions? (If this is the wrong forum for this question, suggestions for a better one would be welcomed.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您不会对答案感到满意。
没有实际的方法可以提高互联网上数据包的速度。如果经过的路由器不受您的控制，则无法可靠地获得更高的速度。互联网基于尽力而为，这意味着没有路由器可以保证您的数据包到达，无论何时或以何种顺序。这就是 TCP 被发明的原因。如果您发送两个数据包，则这两个数据包很可能采用两条不同的路由到达目的地。没有办法告诉您和远程位置之间的路由器优先或更快速地处理您的数据包。有些协议理论上可以加速数据包传输，但大多数标头会在途中被剥离（在大多数情况下，在您控制的最后一个路由器之后）。有 QOS（服务质量）和 TCP 紧急标头，但这些都不能真正保证任何东西。您可以尝试设置这些标头并使用这些协议，但您无法判断您的数据包已获得优先级。
我知道这无论如何都不能令人满意，但反过来想一想。如果数据包实际上在其标志上进行了优先级排序和处理速度更快，那么每个人都只需设置这些，一切都会像现在一样快。您可以尝试，但我可以告诉您，大多数跃点只是公然忽略这些标志。
老实说，更快到达那里的唯一方法是让服务器物理上靠近，并减少中间的网络跃点。如果您可以在同一个服务器中心获得一台服务器，那就太好了。在同一条街上，很好。在同一个城市，好吧。在同一个国家，也可以。没有真正其他方法可以到达那里。您在物理上和网络上的距离越近越好。
You will not be happy with the answer.
There is no actual way to improve the speed of your packets over the internet. If the passing routers are not under your control, there is just no way to reliably get more speed. The internet is based upon best-effort, which means, that no router guarantees that your packets arrive, neither when nor in which order. This is why TCP was invented. If you send two packets, you have a good chance that these two take two different routes to the destination. There is just no way to tell the routers inbetween you and the remote place to handle your packets prioritized or faster. There are some protocols that would theoretically speed up the packet transmission, but most of the headers are stripped on the way (in most cases, after the last router under your control.). There is QOS (Quality-of-Service) and the TCP Urgent header, but non of these really guarantee anything. You can try setting these headers and using these protocols, but there is just no way that you can tell, that your packets get prioritized.
I know that this is not satisfying in any way, but think about it the other way around. If packets were actually prioritized and handled faster on their flags, everyone would just set these, and everything would be as fast as now. You can try, but I can tell you, that most hops just blatantly ignore the flags.
Honestly, the only way to get there faster is to get a server physically close, and reduce network hops inbetween. If you can get a server in the same server center, great. On the same street, good. In the same city, ok. In the same country, also, ok. There will not be really another way to get there. The closer you can get physically and networkwise, the better.