サーバーからの遅い転送速度のデバッグ
私はこれをできるだけ簡単に説明しようとしていますが、可能な限り文書化しています。 これはこのサーバーまたは私の現在のISPに限定されません。異なるISPを使用し、サーバーに異なるプロバイダー（米国ではGoDaddy、カナダではiWebおよびGloboTech）を使用しているときに、何年にもわたってまったく同じ問題が発生しました。それが一般的だった唯一のものは、Windows Server OS（2003および2008 r2）です。しかし、今、私の現在のサーバーと私の現在のISPだけを見てみましょう。
問題：
ローカルワークステーションとリモート専用サーバー間の転送速度が非常に遅い。私のサーバーは100 Mbpsポート上にあり、ローカルワークステーションは光ファイバーを介した50 Mbps対称接続にあります。
症状：
米国とメキシコのさまざまなサーバーと場所に対してspeedtest.netでテストを行うと、サーバーとワークステーションの両方で（接続速度に非常に近い）優れた結果が得られます。 Dropboxからサーバーまたはワークステーションに大きなファイルをダウンロードすると、1つの接続でそれぞれ10 MBpsと5 MBpsの転送速度が得られます。これは、100 Mbpsと50 Mbpsの各接続速度に応じて正しくなります。そっと。
それでも、サーバーから（HTTPまたはFTPを介して）ファイルをワークステーションに転送した場合、50 Mbpsの速度（5 MBpsの転送速度）にも近づきませんが、代わりに3 Mbpsと同等の速度が得られます。 （300 KBpsの転送速度）。
なぜ転送速度が遅いのかを理解しようとしています。デバッグ方法がわかりません。ホスティングプロバイダーの問題についてチケットを上げると、トレーサーの出力を要求され、最後にサーバーの真ん中のせいにします。しかし、私が最初に言ったことを考慮に入れると、それは正しくないようです：GoDaddy、iWeb、GloboTechを搭載したサーバーを使用していて、非常に異なるタイプのインターネットサービス上の異なるISP。サーバー領域のどこかに固定された設定のように見えます。
私が行ったテスト：
[〜＃〜] speedtest [〜＃〜]
これらは、別のリモートサーバーに対して私の専用サーバーで実行された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
Mexico City（自分のISPのデータキャンター内のサーバー）：ダウンロード用に92.99 Mbps、アップロード用に95.39 Mbps http://www.speedtest.net/my-result/ 3470810269
ローカルワークステーションから同じサーバーに対してこれらのテストを実行すると、50 Mbps接続に近い速度も得られます。
[〜＃〜] tracert [〜＃〜]
これは、ワークステーションから専用サーバーに実行された最近の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
[〜＃〜] pathping [〜＃〜]
これは、ワークステーションから専用サーバーに実行されたパスコマンドの出力です。
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サーバー上の大きなファイル
HTTP経由でダウンロードできる5 GBのファイルをサーバーに配置しました。あなたはそれをここで見つけることができます： http://www.marveldns.com/transfer_test/
Speedtest MINIアプリ
サーバーに「speedtest mini」テストを設定しました。あなたはそれにアクセスして、私のサーバーと自分自身の中でダウンロードとアップロードの両方のために得ていると言っている速度を見ることができます。あなたはそれをここで見つけることができます： http://www.marveldns.com/speedtest/
最後に：
前に言ったように、私は全体を理解する助けを得ようとしています。私はTCP/IPやトップエンドネットワーキングの専門家ではありません。正直なところ、問題を解決するためにtracert、iperf、またはpingpathの結果をどのように使用するかは明確にわかりませんが、この問題について話すときは常に尋ねられるので、それらを含めます。
私の質問に改善すべき点が不足している場合は、単に反対票を投じるのではなく、何が悪いのか、または何か助けを求めるために何か追加できることを知らせてください。ありがとうございました。
そのURLにアクセスするときに私が見るボトルネックは、明らかにウィンドウサイズにあります。
サーバーからダウンロードしようとすると、555KB /秒になります。私は108msの往復時間を持っています。計算すると、ウィンドウサイズは555KB/s * 108ms = 59.94KBになります。
データセンターのホストから実行する限り、非常に一貫したスループットと往復が得られます。さらに、2つのダウンロードを同時に開始すると、それぞれ555KB/sになります。それはまさに、ボトルネックがウィンドウサイズであるときに見られる症状です。
ウィンドウスケーリングがない場合、ウィンドウは64KBを超えることはできません。しかし、ウィンドウスケーリングはネゴシエートされるので、より高いスループットが可能になるはずです。これにより、調査すべき2つの仮説が残ります。
- クライアントからサーバーへのパスでウィンドウスケーリングオプションを変更しているものが原因で、サーバーはウィンドウが1倍にスケーリングされていると認識します。
- サーバーは、各接続で60KBを超える送信ウィンドウを使用しないように構成できます。
1つ目は、サーバーでパケットキャプチャを実行できるかどうかを簡単に確認できます。着信SYNパケットのスケーリングオプションを見て、1よりも大きいスケーリング係数がサーバーによって受信されているかどうかを確認してください。トラフィックの分析にはWiresharkの使用をお勧めします。
2番目の仮説を検証するには、使用しているオペレーティングシステムの知識が必要です。あなたはたまたま私には知られていないオペレーティングシステムを選択したので、私は手伝うことができません。だから私はネットワーキングの専門知識しか手伝うことができません。