7月19日(水)1コマ目

今日、やったこと

TCPヘッダのウィンドウサイズ

今日のホワイトボード

データを連続送信する

今まで確認したパケットでは受信応答を待たずにデータを連続して送信する場合もあった。

結論から言えば、連続送信はTCPヘッダのウィンドウサイズと確認応答番号で制御されている。


ウィンドウサイズ

TCPヘッダ中のウィンドウサイズは空きバッファのサイズ。

図 受信データはバッファで一時保存

受信データはバッファに一時保存される。このバッファの上限まではデータを送ってもオーバーフローすることはない。TCPヘッダのウィンドウサイズで空きバッファのサイズを相手に伝えている。

ケース1

⑧でバッファ(空きバッファサイズ65535)へデータ811バイト受信。

空きバッファサイズは65535-811=64724になる。

⑨のウィンドウサイズ64724で空きバッファサイズが64724になったことを伝える。

図 空きバッファサイズとTCPヘッダのウィンドウサイズ①

ケース2

⑪でバッファ(空きバッファサイズ64724)へデータ638バイト受信。

空きバッファサイズは64724-638=64086になる。

⑫のウィンドウサイズ64086で空きバッファサイズが64086になったことを伝える。

図 空きバッファサイズとTCPヘッダのウィンドウサイズ②

相手のウィンドウサイズまで連続送信可能

相手のウィンドウサイズ(空きバッファサイズ)までは受信応答を待たずに連続送信ができる。
これを簡単に処理できるように
 相手の確認応答番号からウィンドウサイズ分が送信可能なデータ
のように処理をしている。
図 確認応答番号からウィンドウサイズ分は連続送信可能
この送信可能な部分(緑枠の部分)を窓と考えるとわかりやすい。
窓が開いている部分のデータが送信可能。

受信応答を受け取ると

受信応答を受け取ると、同じように確認応答番号からウィンドウサイズ分が送信可能になる。
図 送信可能分(窓)がスライドする

データ送信可能部分(先ほどの窓)がスライドしているように見えるので、スライディングウィンドウとも呼ぶ。

次回は

連続送信の流れをもう少しやります。




 

このブログの人気の投稿

7月5日(水)4コマ目

6月26日(月)2コマ目

6月5日(月)2コマ目