調試來自伺服器的緩慢傳輸速率
我試圖盡可能簡單地解釋這一點，但要盡可能地記錄在案。這不是此伺服器或我目前的 ISP 獨有的。多年來，我在使用不同的 ISP 並使用不同的提供商（美國的 GoDaddy、加拿大的 iWeb 和 GloboTech）時遇到了同樣的問題。唯一常見的是 Windows Server OS（2003 和 2008 r2）。但是現在讓我們只看一下我目前的伺服器和我目前的 ISP。
問題：
我的本地工作站和遠端專用伺服器之間的傳輸速度非常慢。我的伺服器位於 100 Mbps 埠上，而我的本地工作站位於通過光纖的 50 Mbps 對稱連接上。
症狀：
在 speedtest.net 上針對美國和墨西哥的不同伺服器和位置進行測試時，伺服器和工作站都獲得了出色的結果（非常接近它們的連接速度）。如果我從 Dropbox 下載大文件到我的伺服器或工作站，我在單個連接上分別獲得 10 MBps 和 5 MBps 的傳輸速率，根據 100 Mbps 和 50 Mbps 的每個連接速度，這是正確的分別。
然而，如果我將一個文件從我的伺服器（通過 HTTP 或 FTP）傳輸到我的工作站，我什至沒有接近我應該獲得的 50 Mbps 速度（5 MBps 傳輸率），但我得到了相當於 3 Mbps 的速度（300 KBps 傳輸速率）。
我試圖理解為什麼我的傳輸速度這麼慢。我不確定如何調試它。每當我向託管服務提供商提出問題時，他們都會要求我提供 tracert 輸出，最後只是將其歸咎於中間的某個伺服器。但這似乎是不正確的，如果我們考慮到我一開始所說的話：我在使用 GoDaddy、iWeb 和 GloboTech 的伺服器時看到了這個確切的速度/問題，同時我自己使用不同的 ISP 非常不同類型的網際網路服務。它看起來確實像是伺服器區域某處的固定設置。
我做過的測試：
速度測試
這些是來自 speedtest.net 的速度測試，在我的專用伺服器中針對不同的遠端伺服器執行，包括我在墨西哥城的 ISP 數據中心中的伺服器：
加拿大：下載 94.64 Mbps，上傳 94.87 http://www.speedtest.net/my-result/3470801975
加利福尼亞州聖何塞：下載速度為 93.58 Mbps，上傳速度為 95.48 Mbps http://www.speedtest.net/my-result/3470805341
墨西哥城（我自己的 ISP 的數據中心中的伺服器）：下載 92.99 Mbps，上傳 95.39 Mbps http://www.speedtest.net/my-result/3470810269
如果我從本地工作站對相同的伺服器執行這些測試，我的速度也會接近我的 50 Mbps 連接。
示踪劑
這是最近從我的工作站執行到我的專用伺服器的 tracert 輸出：
1 <1 ms <1 ms <1 ms 192.168.7.254 2 2 ms 1 ms 1 ms 10.69.32.1 3 * 3 ms 2 ms 10.5.50.174 4 3 ms 2 ms 2 ms 10.5.50.173 5 * 5 ms 3 ms fixed-203-69-2.iusacell.net [189.203.69.2] 6 32 ms 32 ms 32 ms 8-1-33.ear1.Dallas1.Level3.net [4.71.220.89] 7 33 ms 33 ms 33 ms ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145] 8 33 ms 33 ms 33 ms ae13.dal33.ip4.tinet.net [77.67.71.221] 9 76 ms 76 ms 157 ms xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41] 10 72 ms 72 ms 72 ms te2-2.cr2.mtl3.gtcomm.net [67.215.0.160] 11 72 ms 72 ms 72 ms ae2.csr2.mtl3.gtcomm.net [67.215.0.134] 12 72 ms 72 ms 73 ms te3-4.dist1.mtl8.gtcomm.net [67.215.0.83] 13 72 ms 72 ms 72 ms ns1.marveldns.com [173.209.57.82]IPERF
這是使用我的專用伺服器作為伺服器和我的工作站作為客戶端執行的 iperf 測試：
------------------------------------------------------------ Client connecting to ns1.marveldns.com, TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.7.2 port 60339 connected with 173.209.57.82 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.3 sec 5.62 MBytes 4.59 Mbits/sec鋪路
這是從我的工作站執行到我的專用伺服器的路徑命令的輸出：
Tracing route to ns1.marveldns.com [173.209.57.82] over a maximum of 30 hops: 0 ws1 [192.168.7.2] 1 192.168.7.254 2 10.69.32.1 3 * 10.5.50.174 4 10.5.50.173 5 fixed-203-69-2.iusacell.net [189.203.69.2] 6 8-1-33.ear1.Dallas1.Level3.net [4.71.220.89] 7 ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145] 8 ae13.dal33.ip4.tinet.net [77.67.71.221] 9 xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41] 10 te2-2.cr2.mtl3.gtcomm.net [67.215.0.160] 11 ae2.csr2.mtl3.gtcomm.net [67.215.0.134] 12 te3-4.dist1.mtl8.gtcomm.net [67.215.0.83] 13 ns1.marveldns.com [173.209.57.82] Computing statistics for 325 seconds... Source to Here This Node/Link Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address 0 ws1 [192.168.7.2] 0/ 100 = 0% | 1 0ms 0/ 100 = 0% 0/ 100 = 0% 192.168.7.254 0/ 100 = 0% | 2 1ms 0/ 100 = 0% 0/ 100 = 0% 10.69.32.1 0/ 100 = 0% | 3 3ms 0/ 100 = 0% 0/ 100 = 0% 10.5.50.174 0/ 100 = 0% | 4 2ms 0/ 100 = 0% 0/ 100 = 0% 10.5.50.173 0/ 100 = 0% | 5 4ms 20/ 100 = 20% 20/ 100 = 20% fixed-203-69-2.iusacell.net [189.203.69.2] 0/ 100 = 0% | 6 34ms 0/ 100 = 0% 0/ 100 = 0% 8-1-33.ear1.Dallas1.Level3.net [4.71.220.89] 0/ 100 = 0% | 7 34ms 0/ 100 = 0% 0/ 100 = 0% ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145] 0/ 100 = 0% | 8 33ms 0/ 100 = 0% 0/ 100 = 0% ae13.dal33.ip4.tinet.net [77.67.71.221] 0/ 100 = 0% | 9 79ms 0/ 100 = 0% 0/ 100 = 0% xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41] 2/ 100 = 2% | 10 73ms 14/ 100 = 14% 12/ 100 = 12% te2-2.cr2.mtl3.gtcomm.net [67.215.0.160] 0/ 100 = 0% | 11 72ms 2/ 100 = 2% 0/ 100 = 0% ae2.csr2.mtl3.gtcomm.net [67.215.0.134] 2/ 100 = 2% | 12 72ms 18/ 100 = 18% 14/ 100 = 14% te3-4.dist1.mtl8.gtcomm.net [67.215.0.83] 0/ 100 = 0% | 13 72ms 4/ 100 = 4% 0/ 100 = 0% ns1.marveldns.com [173.209.57.82] Trace complete.你可以自己嘗試的事情
如果您想嘗試一下，這些是我在伺服器中設置的一些用於測試目的的東西：
HTTP 伺服器上的大文件
我在我的伺服器中放置了一個 5 GB 的文件，可以通過 HTTP 下載。你可以在這裡找到它：http: //www.marveldns.com/transfer_test/
Speedtest MINI 應用程序
我在我的伺服器上設置了一個“speedtest mini”測試。你可以訪問它，看看它說你在我的伺服器和你自己中下載和上傳的速度是多少。你可以在這裡找到它：http: //www.marveldns.com/speedtest/
最後：
正如我之前所說，我試圖幫助理解整個事情。我不是 TCP/IP 或高端網路方面的專家。老實說，我什至不清楚如何使用 tracert、iperf 或 pingpath 的結果來解決問題，但我將它們包括在內，因為當我談論這個問題時，我總是被要求提供它。
如果我的問題沒有更好的地方，請不要只是投反對票，讓我知道它有什麼問題，或者我可以添加什麼來獲得幫助。謝謝你。
我在訪問該 URL 時看到的瓶頸顯然是由於視窗大小。
當我嘗試從您的伺服器下載時，我得到 555KB/s。我的往返時間為 108 毫秒。算一下，我得到以下視窗大小：555KB/s * 108ms = 59.94KB。
只要我從數據中心的主機上執行此操作，我就可以獲得非常一致的吞吐量和往返。此外，如果我同時開始兩次下載，每次下載速度為 555KB/s。當瓶頸是視窗大小時，這正是您將看到的症狀。
如果沒有視窗縮放，視窗不能大於 64KB。但我確實看到視窗縮放是經過協商的，因此應該可以實現更高的吞吐量。這留下了兩個需要研究的假設：
- 某些東西正在破壞從客戶端到伺服器的路徑上的視窗縮放選項，使伺服器認為視窗被縮放了 1 倍。
- 伺服器可以配置為在每個連接上從不使用超過 60KB 的發送視窗。
第一個很容易驗證您是否可以在伺服器上執行數據包擷取。只需查看傳入 SYN 數據包的縮放選項，即可了解伺服器是否接收到大於 1 的縮放因子。我可以推薦使用 Wireshark 來分析流量。
驗證第二個假設需要對您正在使用的作業系統有所了解。你碰巧選擇了一個我不知道的作業系統，所以我無能為力。所以我只能提供網路方面的專業知識。