web-dev-qa-db-ja.com

過剰な「TCP Dup ACK」および「TCP Fast Retransmission」により、ネットワークで問題が発生します。これは何が原因ですか？

MetroEthernetリンクを介してファイルを転送すると、TCP Dup ACK and TCP Fast Retransmission when our transfer over MetroEthernet link。2つのサイトが1つのsonicwallで接続されていますルーターなので、サイトは1ホップしか離れていません。

ここ はWiresharkからのスクリーンショットであり、 ここ はキャプチャ全体です。このキャプチャでは、クライアントは192.168.2.153で、サーバーは192.168.1.101です。ここに、私のシステムからサーバーへのtracerouteがあります（ping時間は通常10ミリ秒未満で安定しています）。

user@pc567:~$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:e0:b8:c8:0c:7e  
          inet addr:192.168.2.153  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::2e0:b8ff:fec8:c7e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:244994 errors:0 dropped:0 overruns:0 frame:0
          TX packets:149148 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:319571991 (319.5 MB)  TX bytes:12322180 (12.3 MB)
          Interrupt:16 

user@pc567:~$ traceroute -n 192.168.1.101
traceroute to 192.168.1.101 (192.168.1.101), 30 Hops max, 60 byte packets
 1  192.168.2.254  0.747 ms  0.706 ms  0.806 ms
 2  192.168.1.101  8.995 ms  9.217 ms  9.477 ms
user@pc567:~$

これを引き起こしている原因についての助けがあれば役に立ちます！必要に応じて詳細を投稿できます。

更新：これが始まって以来、私はsonicwallを1800 Ciscoルーターに置き換えました。インストールされたパケットキャプチャでも同じ結果が得られました。メトロイーサネット回線であるため、ルーターは必要ありません。そのため、両方のサイトでサービスプロバイダーの機器に直接ラップトップに接続し、それらを同じサブネットに配置することも試みました。パケットキャプチャは、この方法で同じように見えます。これは私がメトロイーサネット回線に問題があると私に信じさせます。

tcpwiresharkpacket
7
Ingram

この回答は単純化されており、希望するほど明確ではないことを理解しています。そのため、ステップについて質問がある場合は、質問してください！

Wiresharkでこのファイルを開いて少し下にスクロールすると、いくつかのフレームが異なる色で表示されます。本当に悪いですね。まあ、それはそれほど悪くはありません。待って、そこに着くよ。

SYNパケット（フレーム37）を確認すると、TCPオプションにSACKとウィンドウスケーリングが表示されます。良い。SYN/ ACK（フレーム38）と同じです。SA​​CKとWindowsスケーリング。すごい。 SACKに関して奇妙なことは何もありません。

アンロードされたRTTの推定値は、SYNパケットと最初のACK（フレーム39）の間の時間です。約9.3ミリ秒で、これは検出結果と一致します。 SYN/ACKとACKの間の時間（フレーム38と39）は、SYNとSYN/ACKの間（37と38）よりもはるかに短いことに注意してください。これは、このキャプチャファイルが受信側で取得されることを意味します。これが理想的でない理由を確認するには、学校に戻る必要があります。

送信側と受信側の間には、最小のネットワークパスの一部があり、帯域幅を制限します。ハンドシェイクから取得したRTT見積もりから、このネットワークパスの長さの見積もりが得られます。このパイプに収めることができるパケット数の測定値は パイプ容量または帯域幅遅延積 -PC [ビット] = R [ビット/秒] * RTT [秒]で、Rは最小帯域幅。その場合、パイプ容量は体積の測定値です。

庭のホースを想像してみてください。測定された体積は、長さと幅によって同じように定義されますか？それから最大限の水を取り出すには、水で完全に満たす必要があります。そうしないと、水の流れを制限するエアギャップが生じます。完全に埋めることができた場合、オーバーフローする可能性があります。床を濡らさないようにバケツを使用できます。バケツがオーバーフローしても水流に影響はありません。

これは、ネットワークパスでもまったく同じであることがわかります。パイプを埋める必要があります...つまり、パイプ容量は、最小の帯域幅を完全に利用する送信側と受信側の間の飛行中の最小バイト数（パイプ+バケットにある水の量）です（原因にはなりません）。エアギャップ）。ですから、処理中のバイト数> PCであれば、問題ありません。

TCP trace統計を見る-> TCP StreamGraph-> Time Sequence Graph（ tcptrace）Y軸にバイト、X軸に時間を表示できます。この曲線の導関数はバイト/秒、またはスループットです。黒い「線」がどのように見えるかに注意してくださいフラット、スループットが安定していることを意味します！ただし、青い線で数回中断されます（重複したACKのSACK範囲です）が、見てわかるように、スループットには影響しません。

右下の灰色の実線（少し拡大して、ACKです）が実際にどのように黒に近いかを確認してくださいTCPセグメント？TCPセグメントとACKはRTTです。これはほぼ0です！これは、このキャプチャポイントを通過した飛行中のセグメントが少ないことを意味します。これは、これを使用して飛行中のバイトを推定できないことを意味します。これが理由です。送信側のパケットキャプチャの方がはるかに優れています。

ここのパケットは、キャプチャポイントの前で自然に失われます。損失時に飛行中であった各データセグメントは、重複ACKをトリガーします。したがって、重複したACKの数を使用して、パケット損失時に飛行中のバイトを推定できます。ここでは、約9、16、23のセグメントが表示されます。各セグメントには1448バイトのデータがあるため、13kと33kの間のバイトが処理されます。ここでのスループットは約3 Mbit/s（IOグラフから）であり、3T6 [ビット/ s] * 10e-3 [s]/8バイト= 3750バイト、または3セグメント未満。

これらの損失時に飛行中のバイトは実際には同じではないため（サンプルが少ないため、ここではわかりにくい）、これらがランダムな損失（悪い悪い悪い）であるか、キューが原因で発生する損失であるかは、実際には言えません/ bucketはオーバーフローしますが、処理中のバイト数> PCのときに発生するため、スループットに影響はありません。

あなたの答えは、それらが実際にランダムであったことを示しているようですが、スループットが低くなるほど多くはありません。

4
bytesinflight

ちょうど今私が見つけたものを投稿しています。 MetroEthernetプロバイダーが土曜日に本社に来ました。彼らはそこでネットワークを切断し、近くの支店にも誰かがいた。彼らは両端にネットワークテスト機器を接続し、実際に問題があるかどうかをすばやく判断できました。数時間後、彼らは問題を特定することができました。これは、プロバイダーのセントラルオフィスからメインオフィスへの銅線の問題でした。彼らはフレームが狂ったように落ちていたと言い、それが再送信の原因でした。彼らは本社で銅線の問題を修正しました（彼らは一度に1本ずつ引き離さなければならないと言いました。BSのように聞こえます）本社でこれを行った後、問題は解決しました。

3
Ingram

あなたが提供したキャプチャを見てください（そうしてくれてありがとう！）最初にかなり古典的な再送信パターンが見えます。パケット50の周りでそれを見ることができます。51と52の間にパケットがありません。何が起こっているのですか？

  1. ->パケット50データ
  2. <-パケット51 ACKパケット50。
  3. ->パケット52データ
  4. <-パケット53 ACKパケット50。
  5. ->パケット54データ
  6. <-パケット55 ACKパケット50。

データパケットがドロップされました。受信者は、これまでに見られたものまでパケットにACKを送信し続けることでこれを示しています。ここで興味深いのは、両側にTCP SACK Permitted Option = True接続をネゴシエートしたときに設定されるため、パケット55にはSACKヘッダーが含まれているはずですが、含まれていません。選択的確認応答により、受信者は「私は51まですべてを見たが、53〜55も見た」ことを示すことができます。

SACKを使用できないので、何が起こっているのかというと、標準にフォールバックするということですTCP「50まで見た」という再送信方法を繰り返し、反対側がそれを理解してすべてを再送信します。 50以降。

パケット66には再送信があり、直後にパケット56までのACKが続きます。2回目の再送信（パケット72）の後、接続は軌道に戻ります。

まず、SACKヘッダーがsonicwallによって取り除かれている可能性が高いため、再送信がネゴシエートしたのと同じ速さで回復できなくなっています。個人的には、SACKのストリッピングは無意味だと私は思うが、他の人は反対するかもしれない。

このキャプチャでわかることから、TCP接続が通常の再送信プロトコルを通過する原因となっているパケットの損失が時々あります。ファイアウォールは再送信方法として邪魔になっています交渉された両側は許可されていません。

2
sysadmin1138