☰

從特定網站取得頁面時出現較大延遲

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。

我在 3 台運行 Linux 和 Windows 的電腦上重現了該問題。

如何診斷這樣的問題？

答案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。

答案2

問題聽起來像是「MTU」的問題。如果您搜尋“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，前往網路標籤，然後前往網站查看每個資源的時間。

相關內容