下載經常暫停和超時
我是新的系統和網路管理員。我的經驗是系統和伺服器的硬體和軟體，網路部分對我來說很新。我熟悉將數字插入網路配置，但如果你問我關於子網劃分或丟包 (;) 的問題，你會看到我臉上閃過這種真正失落的表情。我在學。
這是我的問題：
在接管這里大約兩個月前，以前的網路管理員報告說他們在下載大文件時遇到了問題。好吧，不僅僅是大文件，大文件更令人沮喪。現在我是負責下載的人（從隨機驅動程序到我們的 Technet 訂閱和許可協議中的最新發行版和 SP，再到我們各個部門的數 GB 工程軟體包），我必須“照看”下載，讓我一次被鎖在辦公桌上幾個小時。
如果我不暫停並在下載失敗之前重新啟動下載，下載將開始正常並到達從幾 K 到幾 G 的隨機點，然後下載將停止並失敗。有時暫停/重新啟動會立即起作用，下載會加快速度並在循環重複之前進行一點。有時我必須經過幾個暫停/重新啟動循環才能開始下載實際再次下載。
網路和 ISP 詳細資訊：
- 由我們的 ISP 提供的光纖網際網路連接（我們當地的城市是我們的 ISP）。下載速度通常在 1.1Mbps 左右，峰值高達 1.6Mpbs。有時在暫停/重啟週期中，我們會看到速度低至幾百 Kbps，但在幾個週期之後，它會再次加速。來自不同主機的速度非常一致。
- 我們的內部網路中沒有代理，也沒有我知道阻止連接的防火牆。我們使用 Cisco 1811W 作為我們的網關，但之前沒有遇到任何問題。
這個問題是在 9 月左右首次注意到的，我們可以將其歸因於那個時候我們方面沒有任何變化。
我應該進行哪些測試、檢查等，以確定問題出在我們這邊還是 ISP？
更新：
我正在觀看為大型下載的 TCP 流過濾的 Wireshark 提要，這幾天我遇到了麻煩。大多數流量幀都被標記…
持續或非 HTTP 流量
…我認為這只是包含下載的後續數據包。然而，相對頻繁（每 3-20 秒之間）並且與 Firefox 報告的下載速度的任何下降幾乎完全對應的是標記為…
$$ TCP Retransmission $$持續或非 HTTP 流量
還有一些隨機幀，通常在重傳數據包周圍散佈，兩邊各有幾十幀，標記為…
$$ TCP Previous segment lost $$持續或非 HTTP 流量
…而且 whadayaknow，下載在 3.2GB 文件的一半左右就失敗了。最後一幀是 TCP Previous Segment Lost 幀。這是在我不得不暫停下載並嘗試重新啟動它之後立即出現的：隊列立即失敗。
下載的最後一幀是http$$ ACK $$接著是http$$ FIN, ACK $$，我相信這表明了一個“優雅的” TCP 連接關閉。
我沒有看到任何其他跡象表明中間人打斷了我。
更新 2
在所有下載的瀏覽器和應用程序中都觀察到該問題，並且在所有允許暫停/重新啟動的應用程序中，暫停/重新啟動功能在 99% 的時間內都有效。特定的應用程序和瀏覽器我可以很容易地複制它：Firefox（目前版本）、IE（9）、iTunes（為 iOS 設備下載應用程序和更新）。我不確定這些是否都對下載中的暫停/恢復功能使用相同的功能。
iTunes 從所有允許重新啟動的伺服器下載（iOS 更新文件除外），因此我暫停下載多長時間並不重要。我從（MS、PTC、Solidworks、AutoDesk）下載大文件的大多數網站不支持恢復停止/取消的下載（MS 支持但僅從那里基於 java 的下載管理器），所以我只能暫停大約 15 秒max before download 將在嘗試恢復時立即失敗。
更新 3
使用 mturoute（感謝 Tom H），我發現一致的路由最大 MTU 在分段之前為 1500 字節，並且路徑承載 ICMP 有效負載，端到端分段為 10000 字節，沒有太多問題，包括通過我的 ISP 設備的躍點。所以問題似乎不是碎片或不兼容的 MTU 設置。
ICMP 也沒有被我的 ISP 阻止，BitTorrent 也沒有，儘管我沒有使用 BT 下載這些文件。
更新 4
因此，從 WireShark 日誌來看，我需要研究的是如何確定重傳和前段失去幀的原因。我將如何隔離這些可能的來源？
通常，您可以通過系統地證明網路的各個部分良好來隔離和解決問題。這是一個自信的過程！
- 如果您可以在連接到乙太網和無線的設備中複製問題，則可以將問題隔離在網路 <=> Cisco 1811W <=> DSL 光纖 <=> ISP <=> 和 Internet 之間的最終鏈路中
- 如果您只在有線網路或無線設備中看到問題，那麼您可以針對 Cisco 1811W 上的有線乙太網或無線配置。然後，您可以在下一步中查看問題段的通用設置。
- 通常，在測試某些設備時，重新安裝任何常用連接的乙太網電纜，並嘗試更換 DSL 電纜（如果有）。
- 檢查路由器上為 DSL 設置的 MTU 和自動協商設置，查看來自 IOS 的路由器日誌文件。
路由器將執行 IOS 12 或類似的系統，它將有一些通過 ssh 訪問的好命令行工具來檢查協商設置。
使用該
show interfaces命令查看錯誤統計資訊，例如重新發送和丟棄的數據包。它甚至可能有一個 Web 界面（但我目前沒有使用 cisco IOS 設備，所以這不是僅從我對解決 cisco 網路故障所做的一些筆記中測試的）但是，您應該能夠使用從 cisco 控制台提取每個埠錯誤統計資訊的表
# show interfaces status # show interfaces counter errors對於特定的埠，例如
# show interface GigabitEthernet 5/28 status # show interface GigabitEthernet 0/24 switchport編輯：這是一些人的小影片，展示瞭如何使用 ios“顯示介面計數器錯誤”來解決問題。它實際上非常酷，但它可能過於深入，但它為您提供了檢測雙工不匹配或自動協商設置所需的資訊。
ps您可以通過將替代DSL路由器插入光纖連接來證明連接的路由器部分，如果下載工作找到它們，您就知道問題出在這一端，而不是ISP端。
一些 ISP 做出了一個奇怪的決定，即在其交換機或防火牆上阻止所有 ICMP 數據包。這會阻止路徑 MTU 的計算，這意味著當它們通過具有較低 MTU 的路由時，會出現更多碎片數據包。也許你看到了這個結果。
碎片數據包必須重新組裝，如果您也有封包遺失，這可能是一個問題！鑑於您正在嘗試下載大文件，碎片和封包遺失將是一個更大的問題。路徑 MTU 發現旨在減少碎片。
那麼，您如何知道您的 ISP 是否對您這樣做了呢？你可以問他們——但是，根據我的經驗，ISP 更願意讓你在幾天/幾週內進行基本的故障排除，而不是承認他們可能做錯了什麼。當然，有時他們是對的！
您應該收集資訊以向他們展示您所看到的。像您在 Wireshark 中所做的或在防火牆處收集的數據包擷取很有幫助，因為它們通常會顯示碎片級別。
tracepath您可以使用(*nix) 或mturoute(Windows)檢查路徑 MTU 發現是否正常工作。如果您確實發現 pMTU 無法正常工作，則可能是您的 ISP 或您嘗試下載的站點的 ISP。如果您發現從多個站點下載的問題，很可能是您的 ISP。
當然，它也可能是一大堆其他的東西:-) 祝你好運！