8月27日(木)1コマ目

 今日、やったこと

• TCPのシーケンス番号初期値
• TCPのフロー制御

今日のホワイトボード

キャプチャパケットの解析

解析するパケットは以下。

図　パケット①、パケット②

図　パケット③、パケット④

図　パケット⑤、パケット⑥

図　パケット⑦、パケット⑧

図　パケット⑨、パケット⑩

図　パケット⑪、パケット⑫

図　パケット⑬、パケット⑭

図　パケット⑮、パケット⑯

パケットの解析をすると

コネクション確立要求のシーケンス番号が0ではない

パケット①、②でそれぞれコネクション確立要求(SYN=1)を送信しています。

以前解析したときは、これらのパケットのシーケンス番号は0でした。

が、今回のパケットは

　パケット①(172.16.4.253=>172.16.8.11)シーケンス番号:70668

　パケット②(172.16.8.11=>172.16.4.253)シーケンス番号:92019

とともに0ではありません。

そもそもシーケンス番号は0でスタートせずに、乱数で生成された値を0相当として使います。

よって、コネクション確立要求のパケットで送信するシーケンス番号が0相当の値になります。

　172.16.4.253のシーケンス番号0相当の値：70668(パケット①より）

　172.16.8.11のシーケンス番号0相当の値：92019(パケット②より）

そのあとに送信されるパケットのシーケンス番号も

　172.16.4.253発なら、①のシーケンス番号(70668)を引いた値

　172.16.8.11発なら、②のシーケンス番号(92019)を引いた値

が何バイト目かを表します。

図　シーケンス番号初期値（0相当に値）

受信応答なしで連続してデータ送信している

パケット④、⑤ともに172.16.4.253=>172.16.8.11のデータ送信パケットです。

パケット④でMSS(最大受信セグメント長:1460バイト)まで、パケット⑤で残りを送信しています。

本来ならパケット④を送信後、受信応答をもらって、パケット⑤を送信ですが、なぜか受信応答を待たずに連続してデータを送信しています。

実は、データを受信すると、バッファと呼ばれるメモリ上のエリアに一時的に保存し、順に処理を行います。(受信、即処理ではない)

このバッファがオーバーフローするまでは、受信応答を待たずに送信できるはずです。

そこで、空きバッファサイズをTCPヘッダのウィンドウサイズで相手に通知しています。相手は直近に受信したウィンドウサイズ未満なら、受信応答を待たずに連続してデータ送信を行います。

図　バッファサイズ未満なら受信応答を待たずに送信

次回は

テストをやります。