今日、やったこと

今日のホワイトボード

受信データは一旦バッファに保存され、順に処理される。

このバッファの空き容量を伝えることで、相手はバッファの空き容量までは受信応答を待たずにデータ送信ができる。

バッファの空き容量を伝えるのが、TCPヘッダのウィンドウサイズ。

図　相手のウィンドウサイズまでは受信応答なしで送信可能

図　相手のウィンドウサイズまでは受信応答なしで送信可能　実際のパケット①

②で172.16.8.11のバッファの空きサイズは5840バイトと通知。

これを受信することで、172.16.4.253は5840バイトまでは受信応答なしで連続してデータ送信が可能と判断。

④、⑤でそれぞれ1460バイト、171バイトと受信応答なしで連続してデータを送信。

　相手のウィンドウサイズまでは受信応答なしで送信可能　実際のパケット②

⑧で172.16.8.11は空きバッファサイズを11680バイトと通知。

⑨で172.16.8.11は723バイトのデータを受信。これで空きバッファサイズは

　空きバッファサイズ = 11680 - 723 = 110957バイト

と推測できる。

が、⑩で172.16.8.11はウィンドウサイズが14600バイトと通知。

172.16.8.11はバッファのデータを処理＋バッファサイズの拡大をしている。

始めはバッファサイズを少なめに通知して、大量にデータが送信されることを防ぐこともある。で、ちょっとずつバッファを拡大していく。

172.16.8.11はこの方式を取り入れている模様。

データを送信する際、「相手のウィンドウサイズはxxxバイトで、今はxxxバイトを送信したから、あとxxxxバイト送信できる」と計算をしながら送信するのはめんどくさい。

スライディングウィンドウと呼ばれる仕組みで簡単に、かつ間違いなく送っている。

図　スライディングウィンドウ

受信した確認応答番号から同じく受信したウィンドウサイズ分のエリアが送信可能なデータ。このエリアに窓を作るイメージ。窓の空いているデータを送信する。

データを送信すると、受信応答が返ってくる。受信応答の確認応答番号、ウィンドウサイズに合わせて窓を動かす。窓の中に未送信のデータがあれば、送信する。

受信応答を受信すると、窓が移動する。窓がスライドしているように見えるので、スライディングウィンドウと呼んでいる。

テストをします。