8月20日(木)1コマ目
今日、やったこと
パケット解析(TCPヘッダに注目)
解析するパケット
|
|
図 パケット① |
|
| 図 パケット② |
|
| 図 パケット③ |
|
| 図 パケット④ |
|
| 図 パケット⑤ |
|
| 図 パケット⑥ |
| 図 パケット⑦ |
|
| 図 パケット⑧ |
今日のホワイトボード
各パケットの解析結果をホワイトボードに書きました。
パケット① 172.16.14.160->172.16.8.10 コネクション確立要求
|
|
図 パケット①の解析結果 |
コントロールフラグのSYNビットが１からコネクション確立要求です。
TCPでは、データ送信をする前にまずコネクション確立を行います。
パケット② 172.16.8.10->172.16.14.160 コネクション確立要求+応答番号有効
|
|
図 パケット②の解析結果 |
コントロールフラグのSYNビットが１からコネクション確立要求です。
パケット③ 172.16.14.160->172.16.8.10 応答番号有効
写真撮影し忘れてました。
| Source Port(送信元ポート番号) | 52556 |
|---|---|
| Destination Port(宛先ポート番号) | 80 |
| TCP Segment Len(TCPヘッダ以降のデータ長) | 0 |
| Sequence Number(シーケンス番号) | 1 |
| Acknowledgement Number(確認応答番号) | 1 |
| Flags(コントロールフラグ) | 0x010 |
パケット④ 172.16.14.160->172.16.8.10 データ送信
|
|
図 パケット④の解析結果 |
このパケットで330バイトのデータを送信しています。
キャプチャ結果からはわからないのですが、データ部(TCPヘッダ以降)はHTTPのGETコマンドでホームページをリクエストしています。
パケット⑤ 172.16.8.10->172.16.14.160 ④の受信応答
|
|
図 パケット⑤の解析結果 |
172.16.8.10は④の330バイトを受信したため、確認応答番号を331にして受信応答を送信しています。
172.16.14.160はこのパケットをみて、④は受信できたことがわかります。
パケット⑥ 172.16.8.10->172.16.14.160 データ送信 その１
|
| 図 パケット⑥の解析結果 |
172.16.8.10は④でリクエストしたホームページの内容を返信しています。
データ量が多いため、分割して送っているようで、このパケットは1バイト目(シーケンス番号からわかる)から1460バイト目(データサイズからわかる)までを送信しています。
パケット⑦ 172.16.8.10->172.16.14.160 データ送信 その２
|
| 図 パケット⑦の解析結果 |
④でリクエストしたホームページの内容を返信しています。
データ量が多いため、分割して送ってます。分割データの2つ目です。
このパケットは1461バイト目(シーケンス番号からわかる)から2920バイト目(データサイズからわかる)までを送信しています。
パケット⑧ 172.16.8.10->172.16.14.160 データ送信 最終
|
| 図 パケット⑧の解析結果 |
④でリクエストしたホームページの内容を返信しています。
データ量が多いため、分割して送ってます。
このパケットは8761バイト目(シーケンス番号からわかる)から1000バイト分(データサイズ)を送信しています。
⑦のシーケンス番号は1461、データサイズは1460から⑦のパケットは1461バイト目から2920バイト目まで送信しています。
⑧のシーケンス番号は8761から2921バイト目から8760バイト目までを送信したパケットが⑦と⑧のあいだにあることが推測できます。
パケット⑨ 172.16.14.160->172.16.8.10 ⑥～⑧の受信応答
|
| 図 パケット⑨の解析結果 |
⑧の確認応答番号が9761から9760バイト受信したことがわかります。
⑥から⑧まで172.16.8.10は受信応答を受け取ることなく、データを送信し続けています。
⑨はこれらのパケットの受信応答をまとめて行っています。
疑問
パケット⑥、⑦と1460バイトのデータを送信しています。
どうやら1460バイトでデータを区切って送信しているようですが、たまたまなのか、理由があるのか？
コメント