7月10日（月）2コマ目
今日、やったこと
- [確認テスト]シーケンス番号・確認応答番号
- TCPパケットの確認
今日のホワイトボード
TCPパケットの確認
実際にネットワーク上をやり取りしている９このパケットをキャプチャし、TCPに関する内容にフォーカスをあてて確認をした。
9個のパケットはホームページのやり取りを行っている。ホームページのやり取りはHTTPに従って処理する。HTTPはTCPを使い、ポート番号は80を利用する。
 |
| 図 9個のパケットのやり取りの概要 |
①(No.6)
172.16.14.160から172.16.8.10へのコネクション確立要求。
TCPヘッダのSYNフラグが1になっているため、コネクション確立要求。
また、コネクション確立要求で最大セグメントサイズを相手に通知している。
 |
| 図 コネクション確立時の最大セグメント長のやりとり |
②(No.7)
172.16.8.10から172.16.14.160へのコネクション確立要求＋確認応答番号の通知。
①と同じように、TCPヘッダのSYNフラグが1になっているため、コネクション確立要求。
また、コネクション確立要求で最大セグメントサイズを相手に通知している。
①、②で最大セグメントサイズが1460バイトに決定。
TCPヘッダのACKフラグが1になっているため、確認応答番号を相手に通知している。
③(No.8)
172.16.14.160から172.16.8.10へ確認応答番号の通知。
ここまでがコネクション確立。
④(No.9)
172.16.140.160から172.16.8.10へ1バイト目(シーケンス番号:1)から330バイトのデータ送信。
宛先ポート番号が80からこのデータはHTTPのデータと思われる。
⑤(No.10)
172.16.8.10から172.16.14.160へ④の受信応答。
確認応答番号が331になっていることから、④の1バイト目から330バイト目までのデータを受信したことを伝えている。
⑥(No.11)
172.16.8.10から172.16.14.160へ1バイト目(シーケンス番号:1)から1460バイト目までのデータを送信。
①、②のコネクション確立で最大セグメント長が1460バイトに決まった。この2台のやり取りでは、1460バイトで分割して送信することになる。
⑦(No.12)
172.16.8.10から172.16.14.160へ1461バイト目(シーケンス番号:1461)から2920バイト目までのデータを送信。
1460バイトで分割したデータの第2弾。
このあとNo.13からNo.16までは1460バイトに分割したデータを連続して送信している。
本来なら、⑥を受信した172.16.14.160から受信応答(確認応答番号:1461)を172.16.8.10が受信して⑦を送信するはず。
しかし、データ送信、受信応答、データ送信、・・だと効率が悪いため、受信応答をまたずに連続してデータを送信する仕組みがTCPにはある。
次回は
つづきをやります。
