ACKレコードが重複する原因は何ですか？
いくつかのクライアントマシンからのWiresharkキャプチャを確認します。複数の重複したACKレコードが表示され、再送信とシーケンス外のパケットがトリガーされます。
これらは、次のスクリーンショットに示されています。 .26はクライアント、.252はサーバーです。
ACKレコードが重複する原因は何ですか？
それが役立つなら、より多くの背景：
特定のクライアントサイトでのネットワークスループットの問題を調査しています。ユーザーインターフェイスの観点から認識されている問題は、十分に活用されていない1gbps WAN接続にもかかわらず、データの送信が遅いことです。
ほとんどすべてのクライアントマシンに同じ問題があり、20台以上のマシンでテストされています。問題のないマシンが2つ見つかりました。現在、構成の違いを特定しているところです。問題のない2台のマシンでは、重複したACKレコードが1つしか見られないことに気づきました。問題のあるマシンには通常、3つの重複したACKレコードがあります。注目すべき違いの1つは、正常に動作するマシンはすべてネットワーク運用チームのメンバーに属し、他のすべてのマシンは「正規」の従業員用であるということです。マシンは標準であるはずですが、ネットワーク管理者はローカルシステムに変更を加えている可能性があります。これは、私たちが調査しているもう1つの側面です。
サーバーの TcpMaxDupAcks 設定を変更してみましたが、実際に必要な値は5で、有効な範囲は1〜3のみです。
サーバーはWindows Server 2003です。クライアントはすべてエンタープライズ管理のWindows XPです。 2つの有効なクライアントを含むすべてのクライアントにSymantecアンチウイルスがインストールされています。
これは、この問題を示した数百のうちの唯一のクライアントサイトです。
pathpingは、問題のあるマシンからでも、56ミリ秒のRTTと一貫した0/100パケット損失を示しています。
おかげで、
サム
注：このキャプチャはクライアントマシンで行われたと想定しています。
TCPシーケンスの概要：TCPは、2つのアプリケーション間でバイトストリームを確実に配信します。この場合の「確実な」とは、とりわけ、TCPが異常なデータをリスニングアプリケーションに配信しないことを保証することを意味します。
順序番号を使用することにより、順序正しく信頼できる配信が実装されます。各ストリームのすべてのパケットには32ビットのシーケンス番号が割り当てられます（TCPは事実上2つの独立したデータストリーム、A-> BおよびB-> Aであることを思い出してください）。 AがACKをBに送信する場合、ACKフィールドの値は、AがBから見ると予期する次のシーケンス番号です。
上記から、サーバーからクライアントに送信されている少なくとも1つのTCPセグメントが失われたようです。シーケンス内の3つの重複ACKは、クライアントが 高速再送信 をトリガーしようとする試みです。 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サンプリングを長時間（通常は1時間）行います。これには mtr または ping plotter freeware を使用できます。いくつかのホップで一貫してパケットを失い続け、その後すべてのホップが多くまたはそれ以上緩んでいる場合は、ネットワークに疑いがある可能性があります。デバイスのICMPレート制限により、一部のホップでパケットが失われたように見える可能性があることに注意してください...そのため、そのホップから始まるトレンドとそれに続くトレンドを探します。
注1 トラフィックを並べ替える場合、wiresharkが提供する expert info フィールドにかなり早く表示されます
多くの[再構成されたPDUのTCPセグメント]がACKなしで表示される-これらのACKは[TCP Dup ACK ...]Selective Acknowledgment（aka SACK）behavior が原因です。
例：
クライアントはデータ部分を送信します（...、0、1、2、3、4、5、6、...）
サーバーは確認応答（0）、受信（2、4、3）、次に（5）、次に（6）、受信されなかった（1）
上記のシナリオでは、サーバーは（2-4）範囲を最初に確認し、次に（2-5）範囲、次に（2-6）範囲を確認することを正当に選択できます。 "（AB）range ack"パケットの形成中-サーバーは最後に確認された部分（0）をTCPヘッダーで指定する必要があります。Wiresharkは範囲確認（SACK）を[TCP Dup ACK ...]これらすべての範囲確認応答は、TCP header（Ack = 872619（あなたの場合））。
重複したACKと遅いネットワークパフォーマンスの組み合わせは、ネットワークの輻輳問題のように聞こえます。ネットワーク上のブロードキャストトラフィックの量とレートを確認します。物理層とネットワーク層のブロードキャストおよびマルチキャストを必ず確認してください。