特定のサイトからページを取得する際の大きな遅延

次の問題があります：Hackageからページを取得すると、大きな遅延（約30秒）が発生します。それ以降のリクエストは高速ですが、数分間接続しないと、問題が再発します。

この問題の興味深い点は次のとおりです。

• それはこの特定のサイトに固有のものです（ハック）—他のサイトでも同様の問題は発生しません（そして、私はかなりの数を訪れます）。
• 私の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台のコンピューターで問題を再現しました。

このような問題を診断する方法は？

「30秒」と「2分後」は、私にとってDNSの問題の死んだ呼び出し音です。

接続先のページが接続IPでDNSクエリのようなものを実行し、そのクエリが何らかの理由で失敗すると仮定すると、次のように表示されます。

• サーバーがDNSチェックを行っていないため、 TCP接続はほぼ瞬時に行われます
• スクリプトはDNSクエリを実行し、スタックします。
• 30秒後にデフォルトのタイムアウトが期限切れになり、スクリプトが実行されます（「不明」になりました）
• 後続のクエリでは、負のDNSヒットはまだキャッシュされ、ステージ1がすぐに渡されます
• 負のタイムアウトが切れると（RFC 2308）、2分から5分の間で、次の接続で新しいクエリが発行され、ストーリーが繰り返されます。

...これらはまさにあなたが説明している症状です。

ISP1から取得したIPで、別のISP（ISP2など）からDNSクエリを実行してみてください。100％の証拠ではありませんが、クエリが完了するまでに30秒かかる可能性が高いと予想しています。それはISP1 DNSサーバーが外部から質問に答える問題を抱えていることを意味するでしょう。

別の考えられる原因としては、ISP1のDNSが何らかの理由で（おそらく誤解されている）ハッカーによってファイアウォールで保護されている可能性があります（私の服装では、理由は「トリガーハッピーネット管理者」で、名前を付けることができます）。その場合、ISP2を介したテストは異常な結果を返さないため、診断がはるかに困難になります。これをHackageにエスカレートする必要があります。

問題は「MTU」の問題のように聞こえます。「windows setting mtu」をグーグルで検索する場合、この理論をテストする方法を示す多くの応答を考え出し、必要に応じてMTUを下げる必要があります。（Linuxルーターを使用している場合、IPTablesコマンドを作成してこれを動的に行うことができますが、Windowsを「実行」しません。）

私はあなたのパケットキャプチャを繰り返しました。

事実上、パケットが再構築されている間、わずかな検出不可能な一時停止がありますが、あなたのものほど長くはありません。また、すべてのIPアドレスとHTMLを検証しましたが、すべてが正しく、非常にシンプルで無害に見えます。

要するに、インターネットに関する限り、この遅延の理由はありません。結論は、ISPに問題があるということです。

可能性を絞り込むためにできることは：

1. 別のhaskell.orgパッケージに接続して、同様の遅延があるかどうかを確認してください
2. 異なるネットワークアダプターを使用する複数のコンピューターで、別のルーターを使用してみてください
3. 同じ ISP を使用している地域の誰かに接続を繰り返してもらう
4. 別の ISP を使用している地域の誰かに接続を繰り返してもらう
5. この情報を使用しても、この遅延の説明がまだない場合は、ISPのサポートに連絡して、何が起こっているのかを尋ねてください。

[編集]

haskell.orgがETagを送信することに気づいたので、最初のアクセスは遅いが、次のアクセスは速い理由を説明します。ETag が有効である限り、ページは実際にはブラウザーのキャッシュから取得されるためです。

ここで奇妙なのは、ISPがETagリクエストを送信するときに遅くない理由です。説明は、haskell.orgに行くのではなく、限られた時間内に自分のキャッシュからの要求を満たすというものかもしれません。

サーバーの問題のようです。速くロードされました。サーバーがあなたを嫌うかどうかをテストするには、TORやHideMyAss.comなどのプロキシからアクセスしてみてください。速い場合は、haskell.orgとあなたの家の間に問題があります。

実行できるもう1つのテストは、HTMLファイル、CSSファイル、XMLファイルなど、そのサイト上のリソースを見つけ、そのリンクをHTMLバリデーターなどに渡すことです。サードパーティのサービスが取得に時間がかかる場合は、サーバーに問題があります。

別のテスト：DNSキャッシュをクリアします。haskell.orgのIPアドレスの検索には長い時間がかかる可能性があります。ipconfig /flushdns。またping hackage.haskell.org、コマンドラインからIPアドレスの検索にかかる時間を確認してください。

別のテスト：Cookieの送信を回避するために、Chrome（およびその他）でプライベートブラウジングセッションを開きます。

別のテスト：ChromeまたはOperaでF12を開き、[ネットワーク]タブに移動してから、サイトに移動して各リソースの時間を確認します。