☰

特定のサイトからページを取得するときに大きな遅延が発生する

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 秒後」と「2 分後」は、私にとっては 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 にエスカレーションする必要があります。

答え2

問題は「MTU」の問題のようです。「windows 設定 mtu」を Google で検索すると、この理論をテストし、必要に応じて MTU を下げる方法を示す回答がいくつか見つかるはずです。(Linux ルーターを使用している場合は、これを動的に実行する IPTables コマンドを作成できますが、私は Windows を「扱いません」。)

答え3

あなたのパケットキャプチャを繰り返してみましたが、私の側では次のようになっています:

画像をキャプチャ

実際には、パケットが再構成される間に、検出できない程度のわずかな一時停止が発生しますが、あなたの場合ほど長くはありません。また、すべての IP アドレスと HTML も検証しましたが、すべてが正しく、非常にシンプルで無害に見えます。

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

可能性を絞り込むためにできることは次のとおりです。

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

[編集]

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

ここで奇妙なのは、ISP が ETag リクエストを送信するときになぜ遅くならないのかということです。説明としては、限られた時間だけ haskell.org に行くのではなく、ISP 自身のキャッシュからリクエストを満たしているということが考えられます。

答え4

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

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

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

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

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

関連情報