从特定站点获取页面时的大延迟

Question

我有以下问题：当我从Hackage检索页面时，我得到了很大的延迟（大约 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。

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

如何诊断这样的问题？

Answer 1

“30 秒”和“两分钟后”对我来说是 DNS 问题的死铃声。

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

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

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

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

另一个可能的原因可能是 ISP1 的 DNS 由于某些（可能是错误的）原因被 Hackage 防火墙挡住了（在我的装备中，原因是“一个触发快乐的网络管理员”，我可以命名名称）。在这种情况下，您的诊断会困难得多，因为通过 ISP2 进行的任何测试都不会返回任何异常；您必须将此升级到 Hackage。