7月7日(木)1コマ目
今日、やったこと
パケット解析
今日のホワイトボード
[前回の続き]パケット解析
前回はNo.6~No.10のパケットの解析をしました。
| No. | パケットの内容 |
|---|---|
| 6 | 172.16.14.160から172.16.8.10へのコネクション確立要求 172.16.14.160のシーケンス番号初期値、MSSを通知 |
| 7 | 172.16.8.10から172.16.14.160へのコネクション確立要求 172.16.8.10のシーケンス番号初期値、MSSを通知 確認応答番号1で1バイト目リクエスト |
| 8 | 172.16.8.10へ確認応答番号1で1バイト目リクエスト ここまでがコネクション確立要求 |
| 9 | 172.16.14.160から172.16.8.10へHTTPのGETコマンド送信 GETコマンドでWebページをリクエスト |
| 10 | 172.16.8.10から172.16.14.160へNo.9の受信応答 |
No.11~No.17 Webページのデータ
No.9で172.16.14.160が172.16.8.10へWebページリクエスト(HTTPのGetコマンド)を送信しました。
No.11はそのWebページリクエストに対する応答(Webページのデータ)のうち、1バイト目から1460バイト目までを送信しています。
No.12からNo.17もWebページのデータです。
この7個のパケットで合計9760バイトのWebページのデータを送信しています。
![]() |
| 図 No.11~No.18のパケット |
No.11からNo.16のデータサイズは1460バイトですが、これはMSSが1460バイトのためです。コネクション確立時にお互いのMSSを通知しています。ここで通知するMSSの最小値を今後のやり取りのMSSとして採用します。(今回は両方とも1460バイトだったため、MSSは1460バイトになった)
コネクション確立後、MSSを超えるデータを送信する際は、MSSで区切って送信することになります。
配布した資料にはNo.13からNo.16のパケットキャプチャツールの画面がありませんが、MSSが1460バイトであることから、シーケンス番号は上図のように推測することができます。
No.18 No.11~17への応答
No.18のパケットはNo.11~No.18に対する受信応答です。確認応答番号が9761になっていることから9760バイトまでは受信したことになります。
9760バイトはNo.11からNo.18で送信したデータサイズと一致することからNo.11からNo.18は受信できたことがわかります。
パケット解析 第2弾
前回とは異なるパケットキャプチャツールでキャプチャしたパケットを解析します。
①~③ コネクション確立
①から③の3つのパケットでコネクション確立をしています。
①では172.16.4.253のシーケンス番号初期値、MSSを通知しています。
②では172.16.8.10のシーケンス番号、MSSを通知しています。
前回のキャプチャツールと異なり、①、②のシーケンス番号初期値が0になっていません。
実際のパケットはこのキャプチャツールの表示内容とおりシーケンス番号初期値は0ではなく、ランダムな値になっています。
④、⑤データ送信
172.16.4.253から172.16.8.10へ送信したいデータがMSS(1460バイト)を超えるため、2つのパケットに分割して送信しています。
![]() |
| 図 ④、⑤のパケット(1631バイトのデータ送信) |
④、⑤で合計1631バイトのデータを送信しています。
⑥、⑦受信応答
⑥の確認応答番号(72129)から④(シーケンス番号:70669、データサイズ:1460バイト)の受信応答だとわかります。
⑦も確認応答番号(72300)から⑤(シーケンス番号:72129、データサイズ:171バイト)の受信応答だとわかります。
![]() |
| 図 ⑥、⑦のパケット(④、⑤の受信応答) |
次回は
このパケット解説の続きをやります。
そのうち、テストもします。


