Wiresharkでみるときの、１回のパケット

Question

Wiresharkでみるときの、１回のパケットを追う方法を探してます。

TCP通信にて、通信確立後にデータのやり取りをしている通信を数時間tcpdumpにて取得し、
Wiresharkで流れをみています。そのときに、1回のデータのやり取りと見るために方法を教えてください。

クライアントからのリクエストとサーバからのレスポンスで、

1回目クライアントからデータ送信し、
複数かいやり取りして、終了（200 OKを返却して）

2回目クライアントからデータ送信し、
複数かいやり取りして、終了（200 OKを返却して）

という動作を繰り返してますが、

この1回目がここからここまでのパケット、2回目がここからここまでのパケットと知りたいのです。

なんとなくみると、ストリームNoなどもありますが、
ストリームNoが1回の通信後とのNoかとおもったら、
ストリームNoでフィルタしたら、
1回目5回目8回目・・と複数回のものが同じストリームNoであり、
どうゆうことだとうと疑問になってます。

詳しい方よろしくお願いします。

notnot · Accepted Answer

No1です。
＞TCPストリーム単位でも複数のやりとりがあるのか？わからなくて悩んでます。

昔のHTTP/0.9というプロトコルでは、リクエストに対してレスポンスがあればそれでストリームを終わらせてましたが、現在のHTTP/1.1では１つのTCPストリームで複数のリクエストーレスポンスを行うのが普通です。
また、レスポンスを待たずに複数のレスポンスを続けて投げることも可能です。

Moryouyou · Answer

おつかれさまです。No.2です。

うまく表示できるかわかりませんが、Wiresharkの
キャプチャサマリ情報を貼ってみますので参考にしてください。
このページを取得した時のキャプチャです。

まず
SourceDestinationProtocolLengthInfo
clientqa_serverTCP6654982 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
qa_serverclientTCP66http > 54982 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1382 SACK_PERM=1 WS=128　ここまでコネクションの確立
clientqa_serverTCP5454982 > http [ACK] Seq=1 Ack=1 Win=66336 Len=0
clientqa_serverHTTP2688GET /qa/8387659.html HTTP/1.0 ＰＣからのQAの画面のリクエスト（GET）

qa_serverclientTCP1436[TCP segment of a reassembled PDU]以下QA画面のHTMLの受信　ずぅ～と続きます。1436バイトに分割されてとんできます。
qa_serverclientTCP1436[TCP segment of a reassembled PDU]
qa_serverclientTCP1436[TCP segment of a reassembled PDU]
　　　　　　　　　　途中略
qa_serverclientTCP1436[TCP segment of a reassembled PDU]
qa_serverclientTCP1436[TCP segment of a reassembled PDU]
clientqa_serverTCP5454982 > http [ACK] Seq=2635 Ack=70483 Win=66336 Len=0
clientqa_serverTCP5454982 > http [ACK] Seq=2635 Ack=73247 Win=66336 Len=0
qa_serverclientHTTP832HTTP/1.1 200 OK  (text/html)以上QA画面のHTMLの受信　終わり　●ここまでひとくくり。
clientqa_serverTCP5454982 > http [ACK] Seq=2635 Ack=74026 Win=65556 Len=0
clientqa_serverTCP5454982 > http [FIN, ACK] Seq=2635 Ack=74026 Win=65556 Len=0　コネクションの開放
qa_serverclientTCP60http > 54982 [ACK] Seq=74026 Ack=2636 Win=20224 Len=0

イーサネットの仕様でパケットは1500バイト単位に区切られます。
ヘッダなど除くとデータ部は1400バイトぐらい。
htmlが大きいと、上記のように分割されて送られてくるのです。
[TCP segment of a reassembled PDU]の表示は分割された
パケットのひとつと考えてください。
Wiresharkの機能でhttpの分割されたパケットの最後に
正常に受信できた印として
HTTP/1.1 200 OK  (text/html)と見出しをつけています。

tcpdumpを読み込ませるとこうしたWiresharkの便利機能が
効かないんですかね？

またSYN~FINは上記のパターンのように一区切りで出るとは
限りません。keepaliveという機能により複数の会話を
してから、FINとなるケースもあります。

いかがでしょうか？

Moryouyou · Answer

結構厄介なことをされてますね。お察しします。A^^;)

>１回のパケットを追う方法を探してます。
ここで言われてる『パケット』というキーワードが
何を意図しているかが分かりません。

本来パケットはイーサネット上に流れる最小単位の
電文を言います。
簡単に言うとWiresharkで表示される１レコードが
１パケットです。約1500バイト　MTU長で1460バイト
とかが一般的です。

文面から判断すると、Wiresharkで見ている電文は
httpのプロトコルでWebアプリの画面処理の単位で
電文をくくりたいのかと読み取れます。

冒頭厄介といったのはこのあたりです。
Webアプリの作り方（方式設計）やブラウザ上の
画面設計により内部的に複雑なやりとりが、
並行に動いたりします。

方式はJSPやServletですか？
画面はフレームで分割されていたりしますか？

例えば画面上のボタンをクリックすると
POSTが飛んで、そのパラメタにサーバのアプリの
起動とアプリへの指示（コマンド）、画面上入力
したデータが仕込まれています。
サーバアプリによりその結果のHTMLが生成され
クライアントに送信されます。
その時に並行して別フレームのボタンイメージや
画面の変更のためのhtmlを要求するGETが飛んだり
します。

あとApacheの通信環境や負荷分散装置も
キャプチャデータに影響してきます。

トータルでこのあたりが見えていないと
答えは出てこないのが厄介なんです。

キャプチャから処理のイメージを明確にするのに
ひとつ良い方法があります。

おっしゃられている、200 OKまでの送信パケットを
ヘッダ部分を外してひとつに結合すると
HTMLができあがります。
これをブラウザでひらくと画面イメージが復元
できます。（Wiresharkで意外に簡単にできた
と思います）
その画面から何の処理をしているのか開発者など
からヒヤリングしていけば、処理の単位
（1回のデータのやり取りといわれている単位）が
判断できると思います。

いかがでしょうか？

notnot · Answer

まず、「パケット」という言葉の意味を誤解しています。
パケットというのは、Wiresharkでウィンドウの表示される1行1行がそれぞれ1パケット(IPパケット)です。
複数のIPパケットが連なってTCPストリームになります。

文脈からすると、HTTPのリクエストとレスポンスの組の区切りを知りたいようですが、
IPやTCPのヘッダにはそういう情報は無いので、無理です。
HTTPのヘッダやデータの中を解析する必要があります。

パケットを右クリックして、Follow TCP Stream を選ぶと、そのパケットが属するTCPストリームをまとめて表示できるので、HTTPプロトコルの知識を持った上でそれを読んでください。

基本的には、リクエストは連続した改行まで。
レスポンスは、HTTPレスポンスヘッダか、データの中に長さ情報があるので、その長さが尽きたところが終わりです。

Wiresharkでみるときの、１回のパケット

No1です。

おつかれさまです。

結構厄介なことをされてますね。

まず、「パケット」という言葉の意味を誤解しています。

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング