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

質問

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

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

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

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

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

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

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

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

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

回答No.4

notnot · ベストアンサー

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

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

回答No.3

Moryouyou

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

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

まず
Source Destination Protocol Length Info
client qa_server TCP 66 54982 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
qa_server client TCP 66 http > 54982 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1382 SACK_PERM=1 WS=128　ここまでコネクションの確立
client qa_server TCP 54 54982 > http [ACK] Seq=1 Ack=1 Win=66336 Len=0
client qa_server HTTP 2688 GET /qa/8387659.html HTTP/1.0 ＰＣからのQAの画面のリクエスト（GET）

qa_server client TCP 1436 [TCP segment of a reassembled PDU] 以下QA画面のHTMLの受信　ずぅ～と続きます。1436バイトに分割されてとんできます。
qa_server client TCP 1436 [TCP segment of a reassembled PDU]
qa_server client TCP 1436 [TCP segment of a reassembled PDU]
　　　　　　　　　　途中略
qa_server client TCP 1436 [TCP segment of a reassembled PDU]
qa_server client TCP 1436 [TCP segment of a reassembled PDU]
client qa_server TCP 54 54982 > http [ACK] Seq=2635 Ack=70483 Win=66336 Len=0
client qa_server TCP 54 54982 > http [ACK] Seq=2635 Ack=73247 Win=66336 Len=0
qa_server client HTTP 832 HTTP/1.1 200 OK (text/html) 以上QA画面のHTMLの受信　終わり　●ここまでひとくくり。
client qa_server TCP 54 54982 > http [ACK] Seq=2635 Ack=74026 Win=65556 Len=0
client qa_server TCP 54 54982 > http [FIN, ACK] Seq=2635 Ack=74026 Win=65556 Len=0　コネクションの開放
qa_server client TCP 60 http > 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となるケースもあります。

いかがでしょうか？

回答No.2

Moryouyou

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

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

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

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

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

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

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

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

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

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

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

いかがでしょうか？

お礼

回答ありがとうございます。

期待動作として、
HTTPにてリクエストをなげて、200 OKを返すのが通常ですが、
そのやり取りの中で、TCPにてデータの送受信があるように見えます。
たまにエラーになってしまうケースもあり、

HTTPにてリクエストをなげてからOK又はエラーになるまでの
流れのやり取りがどこからどこまでか知りたいのです。

またTCPストリームはどんなくくりなのか理解できてなくて、
TCPストリームって、応答返信の最小単位ではないのかと、
TCPストリーム単位でも複数のやりとりがあるのか？わからなくて悩んでます。

回答No.1

notnot

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

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

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

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

お礼

回答ありがとうございます。

期待動作として、
HTTPにてリクエストをなげて、200 OKを返すのが通常ですが、
そのやり取りの中で、TCPにてデータの送受信があるように見えます。
たまにエラーになってしまうケースもあり、

HTTPにてリクエストをなげてからOK又はエラーになるまでの
流れのやり取りがどこからどこまでか知りたいのです。

＞複数のIPパケットが連なってTCPストリームになります。
このTCPストリームはどんなくくりなのか理解できてなくて、
TCPストリームって、応答返信の最小単位ではないのかと、
TCPストリーム単位でも複数のやりとりがあるのか？わからなくて悩んでます。