Wireshark の TCP SACK および DSACK: PCAP でのパケット損失、sack_perm オプション、および再送信を診断する

Wireshark PCAP の TCP SACK、DSACK、および sack_perm オプションを診断します。選択的確認応答、パケット損失回復、並べ替え、重複 ACK、および偽の再送信をカバーします。

TCPサック, dsack, 選択的ACK, 重複した袋, パケットロス, reordering, pcap 分析

選択的確認応答が利用できる場合、TCP 再送信分析はより正確になります。トレースに重複 ACK、再送信、および順序の乱れたパケットが示されているものの、根本原因が不明な場合、ユーザーは「TCP SACK pcap」、「DSACK Wireshark」、「重複 SACK」、「スプリアス再送信」、「TCP 順序変更とパケット損失」、および「選択的 ACK パケット キャプチャ」を検索します。

PCAP 手術は、SACK 証拠が TCP オプションで伝送されるため便利です。間違ったパケットを削除したり、ハンドシェイクを失ったり、データから ACK を分離したりすると、診断は弱くなります。

SACK が追加するもの

従来の TCP ACK は、次に予期されるバイトを確認します。 1 つのセグメントが欠落していても、その後のセグメントが到着した場合、受信側はギャップに対して ACK を続けることしかできません。

SACK を使用すると、受信者に「この前の範囲はまだ受信できませんが、後の範囲は受信しました」と伝えることができます。

これは以下を区別するのに役立ちます。

  • 実際のパケット損失。
  • 注文外の配送。
  • パケットが重複しています。
  • 受信者の動作。
  • 送信者の回復動作。

SACKは交渉する必要がある

SACK 機能は SYN および SYN-ACK でネゴシエートされます。ハンドシェイク後にキャプチャが開始された場合、SACK が許可されたかどうかがわからない可能性があります。

常に次のものを保存します。

  • SYN.
  • SYN-ACK.
  • SACK 許可オプション。
  • ウィンドウスケールオプション。
  • タイムスタンプ オプション (存在する場合)。

これが、「再送信周りの小さな pcap」が不十分である可能性がある理由です。

SACK ブロックを含む重複 ACK

重複した ACK はすべて同じことを意味するわけではありません。 SACK ブロックを含む重複 ACK は、送信者に、どのバイト範囲が後で到着したかを正確に伝えることができます。

検査する証拠:

  • ACK 番号。
  • SACKの左端と右端。
  • 繰り返される SACK ブロック。
  • 新しいSACK情報。
  • 欠落したデータが後で表示されるかどうか。
  • 再送信がギャップを埋めるかどうか。

これは、単に重複した ACK をカウントするよりもはるかに強力です。

パケットロスと並べ替え

セグメントが遅れて到着したが失われたわけではない場合、SACK では後のデータがすでに受信されていたことが示される場合があります。送信者が再送信すると、元のパケットも到着する可能性があります。それは乱雑に見えるかもしれません。

質問:

  • 元のセグメントの到着が遅れましたか?
  • 再送信が先に到着しましたか?
  • DSACK は後で重複データを報告しましたか?
  • パケットを並べ替えるパスはありますか?
  • バーストは複数のリンク、トンネル、または負荷分散されたパスを横断していますか?

PCAP 手術は、正確なシーケンス範囲を分離し、パケット順序を比較するのに役立ちます。

DSACKの意味

重複 SACK は、重複データを受信したことを報告できます。これは、偽の再送信や並べ替えを特定するのに役立ちます。

DSACK の証拠は次のことを示唆している可能性があります。

  • 送信者が不必要に再送信しました。
  • ネットワークが元のデータを遅れて配信しました。
  • キャプチャポイントソーの複製。
  • 受信者は元のバイトと再送信されたバイトの両方を取得しました。
  • ミドルボックスのパケットが重複しました。

それは「パケットが失われた」とは異なる結論です。

偽の再送信

再送信は必ずしも損失の証拠となるわけではありません。次のような要因によって引き起こされる可能性があります。

  • Reordering.
  • 遅延 ACK 動作。
  • オフロード アーティファクトをキャプチャします。
  • 再送信タイムアウトが小さすぎます。
  • ACK 圧縮。
  • 仮想化のタイミング。
  • パスの非対称性。

SACK と DSACK は、データが本当に欠落しているのか、単に遅れているだけなのかを証明するのに役立ちます。

キャプチャポイントが重要

pcap が一方的な場合、または NAT の背後で取得される場合、SACK の解釈は困難になる可能性があります。パケットはキャプチャ ポイントには存在しないが、受信側には存在する可能性があります。

役立つ練習:

  • 送信側と受信側のキャプチャを比較します。
  • タイムスタンプを同期させます。
  • シーケンス番号を保持します。
  • ACK のみのパケットを削除しないでください。
  • オフロードとキャプチャの場所をメモします。

ACK パケットのない SACK 分析は分析ではありません。

デバッグチェックリスト

このワークフローを使用します。

  1. TCPハンドシェイクを維持します。
  2. SACK が許可されていることを確認します。
  3. 最初の重複 ACK を見つけます。
  4. SACK ブロックをデコードします。
  5. SACK 範囲をデータ パケットにマッピングします。
  6. 再送信されたシーケンス範囲を特定します。
  7. DSACK を確認します。
  8. 再注文による損失を分離します。
  9. キャプチャ ポイントを確認し、コンテキストをオフロードします。
  10. 回復イベント前後のパケットを保存します。

最終診断

TCP SACK および DSACK は、パケット損失、並べ替え、重複配信、および偽の再送信に対する正確な証拠を提供します。重要なのは、ハンドシェイク オプション、ACK のみのパケット、SACK ブロック、および再送信されるシーケンス範囲を保持することです。

PCAP 手術は証拠を完全な状態に保つのに役立つため、TCP 損失分析は一般的な重複 ACK カウントを超えて行うことができます。