ar099968 Asked: 2016-07-02 08:38:46 +0800 CST2016-07-02 08:38:46 +0800 CST 2016-07-02 08:38:46 +0800 CST 与服务器距离的影响 772 我在爱尔兰（亚马逊 AWS）有一个网络服务器。该服务器在德国（橙色线）看起来很快，但在美国（黑色线）看起来很慢。用于测试的 HTTP 请求是相同的。 我认为这是正常的。爱尔兰和美国之间的距离比德国到爱尔兰的距离要大，但差距似乎太大了。 除了到服务器的距离之外，还有其他可能的原因吗？ performance domain-name-system networking 3 个回答 Voted Best Answer Peter Green 2016-07-02T12:19:52+08:002016-07-02T12:19:52+08:00 假设图表是 http 请求时间，这对我来说似乎相当合理。 一个 http 请求（在没有 keepalive、fastopen 等的情况下）通常需要至少两次往返。 客户端发送 syn 服务器接收syn并发送syn-ack 客户端收到 syn-ack 并发送 ack 和 request。 服务器发送响应。 光纤中的光速约为每秒 2*10^8 米。据谷歌称，从“爱尔兰到美国”的距离为 6,629 公里*，这意味着往返时间约为 66 毫秒。 但这假设设备没有延迟，并且数据路由遵循最短的路径。欧洲主机和美国主机之间的实际往返时间通常为 100 到 150 毫秒。因此，大约 250 毫秒的 http 请求时间是完全正常的。 更令人担忧的是图中的尖峰，它们表明服务器和测试客户端之间的某个地方出现了网络拥塞。 * 显然，这取决于美国的哪个点和爱尔兰的哪个点，但谷歌选择的点似乎在美国中部的某个地方，并且 OPs 图表显示“us-mid”。 user9517 2016-07-02T08:41:33+08:002016-07-02T08:41:33+08:00 除了与服务器的距离之外，还有其他可能的原因吗？ 数据包采用的路径。 Law29 2016-07-02T14:28:51+08:002016-07-02T14:28:51+08:00 在Google 上搜索ping "us-mid"得到 Monitis.com 及其在达拉斯的 IP，他们在法兰克福也有一个 DE IP。从法国连接良好的服务器上，我用 9 毫秒 ping RTT 到 DE IP，用 111 毫秒 ping RTT 到 US-MID IP。对于 HTTP 响应时间，我希望加倍加上服务器的响应时间，为了争论，假设可能是 26 和 230。这与你的值没有太大不同，因为在爱尔兰你可能是一个更远的网络- 明智的从两个地方。 正常接受这些值并监控与它们的偏差，以查看您的站点或您的 ISP 是否存在问题。除非您正在运行一个对响应时间非常关键的全球服务，否则做更多是没有用的。如果您是，请将服务器放在世界各地或（更好地）与专门从事此操作的托管服务商签订合同。
假设图表是 http 请求时间，这对我来说似乎相当合理。
一个 http 请求（在没有 keepalive、fastopen 等的情况下）通常需要至少两次往返。
光纤中的光速约为每秒 2*10^8 米。据谷歌称，从“爱尔兰到美国”的距离为 6,629 公里*，这意味着往返时间约为 66 毫秒。
但这假设设备没有延迟，并且数据路由遵循最短的路径。欧洲主机和美国主机之间的实际往返时间通常为 100 到 150 毫秒。因此，大约 250 毫秒的 http 请求时间是完全正常的。
更令人担忧的是图中的尖峰，它们表明服务器和测试客户端之间的某个地方出现了网络拥塞。
* 显然，这取决于美国的哪个点和爱尔兰的哪个点，但谷歌选择的点似乎在美国中部的某个地方，并且 OPs 图表显示“us-mid”。
数据包采用的路径。
在Google 上搜索
ping "us-mid"得到 Monitis.com 及其在达拉斯的 IP，他们在法兰克福也有一个 DE IP。从法国连接良好的服务器上，我用 9 毫秒 ping RTT 到 DE IP，用 111 毫秒 ping RTT 到 US-MID IP。对于 HTTP 响应时间，我希望加倍加上服务器的响应时间，为了争论，假设可能是 26 和 230。这与你的值没有太大不同，因为在爱尔兰你可能是一个更远的网络- 明智的从两个地方。正常接受这些值并监控与它们的偏差，以查看您的站点或您的 ISP 是否存在问题。除非您正在运行一个对响应时间非常关键的全球服务，否则做更多是没有用的。如果您是，请将服务器放在世界各地或（更好地）与专门从事此操作的托管服务商签订合同。