☰

从特定网站获取页面时延迟很大

tag-icon • tag-icon http
从特定网站获取页面时延迟很大

我遇到以下问题：当我从哈卡吉，我遇到了很大的延迟（大约 30 秒）。其他请求都很快，但如果我在几分钟内没有连接，问题又会再次出现。

这个问题的有趣之处在于：

  • 它是特定于这个特定网站（Hackage）的——我在任何其他网站上都没有遇到类似的问题（而且我访问了不少网站）；
  • 这似乎是我的 ISP 特有的问题——当我从其他地方连接时，没有这样的问题；

  • 这与 DNS 或连接问题无关 — — 事实上，TCP 连接建立得很快；HTTP 响应时间太长，从以下示例数据包捕获中可以看出：

      1 0.000000000 192.168.1.101 -> 66.193.37.204 TCP 66 41518 > http [SYN] Seq=0 Win=13600 Len=0 MSS=1360 SACK_PERM=1 WS=16
  2 0.205708000 66.193.37.204 -> 192.168.1.101 TCP 66 http > 41518 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1440 SACK_PERM=1 WS=128
  3 0.205759000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=1 Ack=1 Win=13600 Len=0
  4 0.205846000 192.168.1.101 -> 66.193.37.204 HTTP 158 GET /packages/hackage.html HTTP/1.1 
  5 0.406461000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [ACK] Seq=1 Ack=105 Win=5888 Len=0
  6 28.433860000 66.193.37.204 -> 192.168.1.101 TCP 1494 [TCP segment of a reassembled PDU]
  7 28.433904000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=1441 Win=16480 Len=0
  8 28.434211000 66.193.37.204 -> 192.168.1.101 HTTP 1404 HTTP/1.1 200 OK  (text/html)
  9 28.434228000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=2791 Win=19360 Len=0
 10 28.434437000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [FIN, ACK] Seq=105 Ack=2791 Win=19360 Len=0
 11 28.635146000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [FIN, ACK] Seq=2791 Ack=106 Win=5888 Len=0
 12 28.635191000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=106 Ack=2792 Win=19360 Len=0

    （使用 pcap-ng 格式捕获数据包）。此捕获显示了在简单的过程中发生的情况curl http://hackage.haskell.org/packages/hackage.html。

即使我在路由器后面也没关系——直接连接也一样。连接类型是 PPPoE。

我在运行 Linux 和 Windows 的 3 台计算机上重现了该问题。

如何诊断这样的问题？

答案1

对我来说，“30 秒”和“两分钟后”与 DNS 问题完全一样。

如果我们假设您连接的页面对连接 IP 执行了类似 DNS 查询的操作，并且该查询由于某种原因失败，您将看到：

  • TCP 连接几乎即时建立，因为服务器没有进行 DNS 检查
  • 该脚本运行 DNS 查询并被卡住。
  • 30 秒后，默认超时到期，脚本继续运行（您现在处于“未知”状态）
  • 在后续查询中，负面 DNS 命中仍会被缓存，并且第一阶段会立即传递
  • 负超时到期（RFC 2308）后，即 2 到 5 分钟之间的任何时间，将在下一次连接时发出新的查询，然后重复该过程。

...这些正是您所描述的症状。

您可以尝试在从 ISP1 获得的 IP 上运行来自另一个 ISP（例如 ISP2）的 DNS 查询。这并非 100% 可靠，但我预计查询很可能需要 30 秒才能完成。这意味着 ISP1 DNS 服务器在响应查询时遇到了问题从外部。

另一个可能的原因可能是 ISP1 的 DNS 因某种（可能是错误的）原因被 Hackage 防火墙阻断（例如我的装备，原因可能是“一个好战的网络管理员”，我可以说出名字）。在这种情况下，你的诊断会困难得多，因为通过 ISP2 进行的任何测试都不会返回任何异常；你必须将此事上报给 Hackage。

答案2

问题听起来像是“MTU”的问题。如果您在 Google 上搜索“windows 设置 mtu”，您应该会得到许多答案，它们将向您展示如何测试此理论，并根据需要降低 MTU。（如果您使用的是 Linux 路由器，我可以生成一个 IPTables 命令来为您动态执行此操作，但我不会“使用”Windows。）

答案3

我已经重复了你的数据包捕获，在我的看来是这样的：

捕获图像

实际上，在重新组装数据包时，确实存在一个无法察觉的短暂停顿，但不会像您的那样长。我还验证了所有 IP 地址和 HTML，一切都正确无误，而且看起来非常简单且无害。

简而言之，就互联网而言，这种延迟是没有理由的。结论是您的 ISP 有问题。

你可以采取以下措施来缩小可能性：

  1. 尝试连接到另一个 haskell.org 包看看是否有类似的延迟
  2. 尝试使用您所在位置的另一个路由器，并让多台计算机使用不同的网络适配器
  3. 尝试让您所在地区的人使用相同的ISP 重复连接
  4. 尝试让您所在地区的人使用其他ISP 重复连接
  5. 有了这些信息，如果您仍然无法解释这种延迟的原因，请联系您的 ISP 的支持人员询问发生了什么事情。

[编辑]

我注意到 haskell.org 发送了一个电子标签，这就解释了为什么第一次访问很慢但接下来的访问很快：因为只要 ETag 有效，页面实际上就来自浏览器的缓存。

这里奇怪的是为什么 ISP 在传输 ETag 请求时速度不慢。一个解释可能是，在有限的时间内，他们从自己的缓存中满足请求，而不是转到 haskell.org。

答案4

听起来像是服务器问题。对我来说，加载速度很快。要测试服务器是否不喜欢你，请尝试从代理（例如 TOR 或 HideMyAss.com）访问它。如果速度很快，那么 haskell.org 和你家之间就存在问题。

您可以运行的另一个测试是在该网站上找到资源，例如 HTML 文件、CSS 文件或 XML 文件，然后将该链接传递给 HTML 验证器等。如果第三方服务需要很长时间才能获取，那么服务器就有问题。

另一个测试：清除 DNS 缓存。查找 haskell.org 的 IP 地址可能需要很长时间。ipconfig /flushdns还可以从命令行尝试ping hackage.haskell.org查看查找 IP 地址需要多长时间。

另一项测试：使用 Chrome（及其他浏览器）打开私人浏览会话，以避免发送 cookie。

另一项测试：在 Chrome 或 Opera 中打开 F12，转到“网络”选项卡，然后转到站点查看每个资源的时间。

相关内容