バイナリTCPDUMPファイルからパケット損失を計算する方法
インターネットを介したポート80の1つのリモートサーバーへの接続が正しく機能していません。 （時々それは機能していますが、機能しないこともあります）
他のクライアントからは問題がないので、それはある種のパケット損失であるに違いありません。これは、1つのクライアントからリモートサーバーに発生しているだけです。
通常、pingでパケット損失を測定しますが、リモートサーバーがICMPをブロックしています。
バイナリTCPDUMPファイルを作成しました。パケット損失があるかどうかを確認するにはどうすればよいですか？
キャプチャはクライアントで行われました。リモートサーバーへのsshアクセスがありません。
重複するシーケンス番号の数を数えることにより、クライアントからサーバーへのパケットの再送信を測定できます。
サーバーからクライアントへのパケットの再送信は、重複するAck番号をカウントすることで測定できます。
再送信は、完全な損失（=タイムアウト）以外の原因でトリガーされることに注意してください。リモートマシンがパケットを拒否した場合、またはパケットが破損した場合は、ローカルマシンも再送信する必要があります。
tshark can filter 再送信、ACKの重複、セグメントの喪失、.。
$ tshark -r file.pcap -q -z io,stat,1,\
"COUNT(tcp.analysis.retransmission) tcp.analysis.retransmission",\
"COUNT(tcp.analysis.duplicate_ack)tcp.analysis.duplicate_ack",\
"COUNT(tcp.analysis.lost_segment) tcp.analysis.lost_segment",\
"COUNT(tcp.analysis.fast_retransmission) tcp.analysis.fast_retransmission"
結果の例を次に示します。
IO Statistics
Interval: 1.000 secs
Column #0: COUNT(tcp.analysis.retransmission) tcp.analysis.retransmission
Column #1: COUNT(tcp.analysis.duplicate_ack)tcp.analysis.duplicate_ack
Column #2: COUNT(tcp.analysis.lost_segment) tcp.analysis.lost_segment
Column #3: COUNT(tcp.analysis.fast_retransmission) tcp.analysis.fast_retransmission
| Column #0 | Column #1 | Column #2 | Column #3
Time | COUNT | COUNT | COUNT | COUNT
000.000-001.000 0 0 0 0
001.000-002.000 0 0 0 0
002.000-003.000 0 0 0 0
003.000-004.000 0 0 0 0
004.000-005.000 0 0 0 0
005.000-006.000 0 0 0 0
006.000-007.000 1 2 1 0
007.000-008.000 3 1 0 0
008.000-009.000 0 0 0 0
009.000-010.000 1 0 1 0
010.000-011.000 0 0 0 0
011.000-012.000 0 0 0 0
012.000-013.000 0 0 0 0
013.000-014.000 1 0 0 0
====================================================================================