Wireshark の TCP SACK および DSACK: PCAP でのパケット損失、sack_perm オプション、および再送信を診断する
Wireshark PCAP の TCP SACK、DSACK、および sack_perm オプションを診断します。選択的確認応答、パケット損失回復、並べ替え、重複 ACK、および偽の再送信をカバーします。
選択的確認応答が利用できる場合、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 分析は分析ではありません。
デバッグチェックリスト
このワークフローを使用します。
- TCPハンドシェイクを維持します。
- SACK が許可されていることを確認します。
- 最初の重複 ACK を見つけます。
- SACK ブロックをデコードします。
- SACK 範囲をデータ パケットにマッピングします。
- 再送信されたシーケンス範囲を特定します。
- DSACK を確認します。
- 再注文による損失を分離します。
- キャプチャ ポイントを確認し、コンテキストをオフロードします。
- 回復イベント前後のパケットを保存します。
最終診断
TCP SACK および DSACK は、パケット損失、並べ替え、重複配信、および偽の再送信に対する正確な証拠を提供します。重要なのは、ハンドシェイク オプション、ACK のみのパケット、SACK ブロック、および再送信されるシーケンス範囲を保持することです。
PCAP 手術は証拠を完全な状態に保つのに役立つため、TCP 損失分析は一般的な重複 ACK カウントを超えて行うことができます。