从特定站点获取页面时出现较大延迟

11

我有以下问题：从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。

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

如何诊断这样的问题？

http

— 罗马切普利亚卡
source

嗨，我认为您需要使用启用了开发人员工具的浏览器来查看HTTP级别对话框，而不是IP级别对话框。我们需要查看造成延迟的原因，您只能通过查看页面的HTTP交互的总集合来做到这一点。相反，您可以使用GMetrix。

— 朱利安·奈特

在该网站上运行GMetrix给我带来了相当不错的效果，并带来了一些重大期望，这可能会为您指明正确的方向。

— 朱利安·奈特

@JulianKnight：问题中有指向完整捕获文件的链接-它具有所有信息

— Roman Cheplyaka

您的链接是PCAP，我指的是更高层次的内容。请使用基于浏览器的开发人员分析或GMetrix或同时使用两者进行报告。

— 朱利安·奈特

1

@JulianKnight：让我重复一遍-CSS在这里无关紧要，我们正在谈论单个HTTP请求的30秒延迟。

— Roman Cheplyaka

5

“ 30秒”和“两分钟后”对我来说是DNS问题的致命一击。

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

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

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

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

另一个可能的原因可能是出于某些原因（可能是错误的原因），Hackage将ISP1的DNS防火墙了（在我看来，原因可能是“触发快乐的网络管理员”，我可以命名）。在这种情况下，您将很难进行诊断，因为通过ISP2进行的任何测试都不会返回异常。您必须将其升级为Hackage。

— 塞尔尼
source

这看起来很合理！让我验证一下。

— Roman Cheplyaka

对于第一个原因，我尝试使用匿名代理进行haskell，而且速度很快，这可能表明该原因不太可能。对于第二个，从任何ISP访问haskell时都希望有相同的暂停，因此也不大可能。DNS可能仍然是原因，但解释起来可能更复杂。

— harrymc

@harrymc：这很简单。我负责反向DNS的ISP的DNS服务器已关闭。因此，尝试进行反向解析超时。试试这个：dig +trace -x 80.90.233.38。我95％确信这是原因，只是在等待确认黑客确实执行了反向DNS查找。

— Roman Cheplyaka

0

问题听起来像是“ MTU”的问题。如果您用Google搜索“设置MTU的窗口”，您应该给出一些答案，这些答案将向您展示如何检验这一理论，并适当降低MTU。（如果您使用的是Linux路由器，则可以生成IPTables命令来为您动态地执行此操作，但我不“使用” Windows。）

— 大卫
source

根据Wireshark指南，“重组后的PDU的TCP段”实际上并不对应于IP分段，而只是表示响应有效地包含了多个数据包，就像您在网页中所期望的那样。

— 朱利安·奈特

它似乎不是MTU。我通过直接通过以太网连接并将mtu设置为1000进行了测试。问题仍然存在。

— Roman Cheplyaka

0

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

拍摄影像

实际上，在重新组装数据包时会有一个轻微的无法察觉的暂停，但是没有您的时间长。我还验证了所有IP地址和HTML，所有内容都是正确的，并且看起来非常简单和无害。

简而言之，就互联网而言，没有任何延迟的原因。结论是您的ISP有问题。

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

尝试连接到另一个haskell.org程序包，看看是否存在类似的延迟
尝试从您的位置将另一台路由器与使用不同网络适配器的多台计算机一起使用
尝试让您所在地区的使用相同 ISP的人重复连接
尝试让您所在地区的人使用另一个 ISP重复连接
有了这些信息，如果您仍然没有对此延迟的解释，请联系您的ISP支持以询问发生了什么情况。

[编辑]

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

奇怪的是，为什么在传输ETag请求时ISP不会变慢。一种解释可能是，他们在有限的时间内满足了自己缓存中的请求，而不是去了haskell.org。

— 哈里奇
source

1.对于所有黑客页面而言都是相同的。2.正如我所说，我在多台计算机上使用了几台路由器（并且没有一台）尝试了此操作。4.如果在我所在的地区使用其他ISP，则该问题不存在。

— Roman Cheplyaka

现在，ISP问题确实看起来像是唯一可行的解决方案，但是那是什么问题呢？他们甚至可能都不怀疑黑客的存在，因此这不是故意的。如果我告诉他们“嘿，这个站点对我不起作用（但其他站点都对我有用）”，那么他们不会听。

— Roman Cheplyaka

我在上面添加了一个解释，说明为什么只有第一次访问很慢。与ISP交谈之前，第3点仍然需要答案。他们的问题可能与他们使用的安全软件有关，由于某种原因，它很难检查haskell.org的有效性。

— harrymc

Etag无关紧要，因为我使用curl进行测试。无论如何，关于反向DNS的答案很可能是正确的答案。

— Roman Cheplyaka

-2

听起来像是服务器问题。它为我快速加载。要测试服务器是否不喜欢您，请尝试从代理（例如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，转到“网络”选项卡，然后转到站点以查看每种资源的时间。

— 克洛伊
source

使用代理时，问题就消失了。您的其他建议已在问题本身中得到解决。

— Roman Cheplyaka

服务器不喜欢你。无论出于何种原因，它都会限制您的IP。您无能为力。

— Chloe