ACKレコードの重複の原因は何ですか？

複数の重複したACKレコードを表示している少数のクライアントマシンからのWiresharkキャプチャを確認しています。これにより、再送信パケットとシーケンス外パケットがトリガーされます。

これらは、次のスクリーンショットに示されています。.26はクライアントで、.252はサーバーです。

ACKレコードが重複する原因は何ですか？

それが役立つ場合の背景：

特定のクライアントサイトでのネットワークスループットの問題を調査しています。ユーザーインターフェイスの観点から認識される問題は、1 gbpsのWAN接続が十分に活用されていないにもかかわらず、データがゆっくりと送信されることです。

ほとんどすべてのクライアントマシンに同じ問題があり、20台を超えるマシンでテストされています。問題のない2台のマシンが見つかりました。現在、構成の違いを特定しています。問題のない2台のマシンで、ACKレコードが重複するのは最大で1つしか見られなかったことに気付きました。通常、問題のあるマシンには3つの重複したACKレコードがあります。注目すべき違いの1つは、正常に動作するマシンはすべてネットワーク運用チームのメンバーに属し、他のすべてのマシンは「正社員」用であることです。マシンは標準であるはずですが、ネットワーク管理者はローカルシステムに変更を加えることもできました。これは、私たちが調査しているもう1つの側面です。

サーバーのTcpMaxDupAcks設定を変更しようとしましたが、実際に必要な値は5で、有効な範囲は1〜3のみです。

サーバーはWindows Server 2003です。クライアントはすべてエンタープライズ管理のWindows XPです。2つの正常に動作するクライアントを含むすべてのクライアントに、Symantecアンチウイルスがインストールされています。

これは、この問題を示した数百のクライアントサイトの中で唯一のものです。

pathping 問題のマシンからでも56ms RTTと一貫した0/100パケット損失を示しています。

おかげで、

サム

注：このキャプチャはクライアントマシンで行われたと想定しています。

TCPシーケンスの概要：TCPは、2つのアプリケーション間でバイトストリームを確実に配信します。この場合の「信頼できる」とは、とりわけ、TCPが順番の異なるデータをリスニングアプリケーションに配信しないことを保証することを意味します。

順序番号を使用して、順序どおりの信頼できる配信が実装されます。各ストリームのすべてのパケットには32ビットのシーケンス番号が割り当てられます（TCPは事実上、A-> BおよびB-> Aの2つの独立したデータストリームであることに注意してください）。AがBにACKを送信する場合、ACKフィールドの値は、AがBから見ると予想される次のシーケンス番号です。

上記から、サーバーからクライアントに送信されている少なくとも1つのTCPセグメントが失われたようです。順番の3つの写しACKsはクライアントによる速い再送信を引き起こす試みです。TCP送信者が同じデータに対して3つの重複した確認応答（つまり、最後に送信されたデータではない同じセグメントに対する4つのACK）を受信すると、ACKされたセグメントの直後のセグメントが失われたと合理的に想定できますネットワーク内で、すぐに再送信されます。

この場合、再送信が行われ、Wiresharkによって異常として識別されます。

joeqwertyで述べたように、パケット損失はほとんどの場合輻輳によって引き起こされます。また、インターフェイスカードの不良、ケーブルのゆるみなどによるリンク上のCRCまたはその他のエラーの結果である可能性があります。パスに沿ったすべてのリンクの統計を調べて、使用率が高いか、または多数のエラーが発生しています。

明らかな候補が見当たらない場合は、パスの複数のポイントで同時パケットキャプチャを実行して、損失が発生している場所を特定してください。

ここではどのようなWAN接続が使用されていますか？専用回線ですか？MPLS VPNリンク？パブリックインターネット上のIPsec VPN 他に何か？

問題がどこにあるかを特定している間、パケットダンプは症状の1つに過ぎないと考えてください...類推として、誰かが胸の痛みで診察室に入った場合、医師は3時間かけてその性質を調査しません痛み。彼はそのことに約2分を費やし、原因の95％が胸焼けまたは狭心症であることを知っています...同様に、重複したACKが表示された場合、すぐに痕跡の雑草に穴を開けないでください。

接続が確立された後、TCPのパフォーマンスが低下するのは、中継ネットワークの問題が常に原因とは限りません。サーバーのCPUまたはディスクの制限の結果として発生することもありますが、クライアントPCの問題が原因で発生することもあります。Wiresharkトレースの雑草を数週間掘り下げて、mtrを使用して比較的迅速に問題を見つけるか、CPUやディスクI / Oなどの他のホストメトリックを確認しました。

最初のタスクは、これがネットワークの問題なのかホストレベルの問題なのかを証明することです。ネットワークを介して実際のトラフィックを送信することに焦点を当て、キューイング/ルーズ/リオーダーを行っているかどうかを確認して^{ください注1}。これは、このような潜在的なネットワークの問題の最終結果です。

私はどうなるpingのスループットの問題が起こっている間に、クライアントとサーバーの間で長時間のサンプリング（私のために通常は時間）。これには、mtrまたはpingプロッターフリーウェアを使用できます。あるホップでパケットが常に失われ、その後すべてのホップがそれ以上失われる場合、潜在的なネットワークの疑いがあります。デバイスのICMPレート制限により、パケットが失われているように見えるホップが発生する可能性があることに注意してください。そのため、そのホップから続くトレンドを探したいのです。

^注1トラフィックを並べ替える場合、wiresharkが提供するエキスパート情報フィールドにかなり早く表示されます

ACKのない[再構築されたPDUのTCPセグメント]をたくさん見ることによって、それらのACKはSelective Acknowledgment（別名SACK）動作のために[TCP Dup ACK ...]として表示される可能性が高いと思います。

例：

• クライアントはデータ部分を送信します（...、0,1,2,3,4,5,6、...）

• サーバーは（0）を確認してから（2,4,3）を受信し、（5）、（6）を受信し、（1）

上記のシナリオでは、サーバーは最初に（2-4）範囲、次に（2-5）範囲、次に（2-6）範囲にackすることを正当に選択できます。「（AB）範囲ack」パケットの形成中に、サーバーはTCPヘッダーの最後に確認された部分（0）を指定する必要があります。Wiresharkは、range-ack（SACK）を[TCP Dup ACK ...]としてマークします。これは、これらのrange-ackのすべてがTCPヘッダーで同じlast-ackedパーツ値を持っているためです（あなたの場合はAck = 872619）。

ACKの重複と遅いネットワークパフォーマンスの組み合わせは、ネットワークの輻輳の問題のように思えます。ネットワーク上のブロードキャストトラフィックの量と速度を確認します。物理層とネットワーク層のブロードキャストとマルチキャストを必ず確認してください。