3 Minutes NetWorking
No.41

3Minutes NetWorking

第41回レイヤ4 TCP ウィンドウ

■ TCPおさらい・ふたたび

インター博士

さて、まだまだTCPの話は続く。
今日は「ウィンドウ」の話だ。

ネット助手

うぃんどう。
OSのことですか?

インター博士

いや、あれはウィンドウ「ズ」だからな。
今回のものはTCP内部での「窓」だ。

ネット助手

はぁ。

インター博士

まず、TCPヘッダのおさらいからいこう。

送信元ポート番号(16)宛先ポート番号(16)
シーケンス番号(32)
確認応答番号(32)
データオフセット(4)予約(6)制御ビット(6)ウィンドウ(16)
チェックサム(16)緊急ポインタ(16)
オプション

[Table39-01:TCPヘッダ]

インター博士

ちゃんと「ウィンドウ」という項目がある。
今回は、このウィンドウシーケンス番号確認応答番号の3つを使って説明していく。

ネット助手

シーケンス番号と確認応答番号は前回でてきましたよね。
え〜っと。大きなデータを分割して届ける際に使う番号でしたね。

インター博士

うむ。
シーケンス番号は、送るデータの先頭バイトの番号だ。

ネット助手

確認応答番号は受け取った際に返す確認応答につける次の送られてくる(予定の)データの先頭バイトの番号でした。

インター博士

うむうむ、そうだ。
では、1回のデータ転送で送るデータ量のことをなんといったかね?

ネット助手

え〜。
MSSでしたよね。分割したものがセグメント

インター博士

うむ。
これはTCPのデータ受け渡しが開始されるスリーウェイハンドシェイクで決定される。

ネット助手

でした。

インター博士

つまり一連の流れは、以下の図のようになる。

シーケンス・確認応答の流れ

[Figure40-05:シーケンス・確認応答の流れ]

ネット助手

確実・正確に送ると。

インター博士

そうだ。それがTCPの謳い文句だからな。
だが、その「確実・正確」のための技術はこれだけではない。

ネット助手

これだけじゃない?
なんかもう、十分な気がするんですけど。

■ ウィンドウサイズ

インター博士

まず。前回やった、「セグメント送信 → 確認応答」という流れだが。
これは手間がかかりすぎる。

ネット助手

手間がかかりすぎるって。
それはそうですけど、「正確・確実」なためには必要なものなんでしょう?

インター博士

うむ。
それはそうなのだが。実際はもうちょっと効率のよい送り方をしないと、時間だけがかかりすぎる。

ネット助手

はぁ。

インター博士

「セグメント送信 → 確認応答」という流れは一緒だが。
複数のセグメント転送 → 確認応答」という形にする。そうすれば、時間的にだいぶ効率がよくなる。

効率のよい送り方

[Figure41-01:効率のよい送り方]

インター博士

このように、左の方式に比べると、同じ3つのセグメントを送るにも右の方式はだいぶ時間的に短縮できる。

ネット助手

複数のセグメント送信?
セグメント送信とACKが入れ違いになってますけど。

インター博士

前回で説明したのは「ACKで受信を確認したら次のセグメント」という方式だったわけだ。
これを「ACKを待たずに複数のセグメントを送る」方式にしたわけだ。

ネット助手

ええぇ? でもそれだと、「確実・正確」の謳い文句がおかしくなってしまいませんか?
一気に送って、後々になって届かなかったことがわかってしまう、とか。

インター博士

うむ、その可能性はある。
なので、「確実・正確」に、かつ効率よく送るためにTCPはウィンドウ制御というものを行う。

ネット助手

うぃんどう制御。
窓の制御?

インター博士

何故「ウィンドウ」という名前がついたかは、後で話そう。
まず、前にバッファというものを話したよな。

ネット助手

第38回で出てきた奴ですか?
受け取ったデータを一時的に保管しておく場所でしたっけ?

インター博士

そうだ。
送られてきたデータはバッファに溜め置かれて、そこから処理される。

ネット助手

処理よりも、データ転送が早いとバッファに溜まっていって、あふれ出ちゃうんでしたよね。

インター博士

うむ。TCPではこのあふれ出る(オーバフロー)を防がなければならない。データの損失だからな。
なので、相手に自分がどれだけのバッファ量を持つか教える必要がある。

ネット助手

ははぁ、さすがTCP。
きめ細かいですね。

インター博士

このサイズのことをウィンドウサイズという。

ネット助手

うぃんどうさいず。

インター博士

これは、MSSと同じように、スリーウェイハンドシェイクで初期値を決定する。

[Figure41-02:ウィンドウサイズの決定]

ネット助手

シーケンス番号、確認応答番号やMSSと一緒に相手に教えるんですね。

■ ウィンドウ制御

インター博士

ウィンドウサイズは、相手のバッファの量だ。
つまり、ウィンドウサイズまでのデータは一度に送っても相手はオーバフローしないということがわかるわけだ。

ネット助手

えっと、そう、なるのかな?

インター博士

なるのだ。
つまり、ウィンドウサイズとは確認応答を待たずに送ることのできるデータ量ということになる。

ネット助手

相手がオーバフローしないのと、確認応答を待たなくってよいってのは別問題ではないんですか?

インター博士

確認応答は「受け取りました」という意味だろう? 相手のウィンドウサイズを知ることは「受け取れなかった原因」の1つであるオーバフローの可能性を失くすわけだから、確認応答なしでもいいことになる。

ネット助手

「受け取れなかった原因」の「1つ」。
他にも受け取れなかった原因はあるんですよね。その場合はどうするんですか?

インター博士

うむ。それはちゃんと後で説明する。
とりあえず、ウィンドウ制御を説明しよう。

[Figure41-03:ウィンドウ制御]

ネット助手

はわ〜。

インター博士

「枠」には「現在送信中で確認応答が返ってきていないもの」が入る。
この枠は順々に下に下がっていくわけだ。

ネット助手

「再送されることがないので、枠からはずします」っていうのは?

インター博士

うむ。「確認応答が届いた」=「相手にそのセグメントは届いた」だろう?
なのでもう送る必要がないので、送っているものが入る「枠」からはずすのだよ。

ネット助手

ははぁ。

インター博士

このように、「枠(ウィンドウ)」が「ずれる(スライド)」ので、この方式をスライディングウィンドウ方式という。

ネット助手

すらいでぃんぐうぃんどう。
スライドするウィンドウですか。

インター博士

もうちょっとわかりやすく、簡略化したものを見てもらったほうがいいかな。

[Figure41-04:スライディングウィンドウ]

ネット助手

あ〜、なるほど。
送るデータ全体のうち、今送信中のデータだけが見える窓(ウィンドウ)なわけですか。

インター博士

そうだ。だからウィンドウと呼ばれる。
これがスライドするから、スライディングウィンドウ、だな。

ネット助手

ははぁ、なるほど。

■ ウィンドウ制御・エラーの場合

インター博士

しかし、上の例は非常に上手くいった場合なわけだ。
処理速度が速くて、いつもバッファは空なわけだからな。

ネット助手

そうですね。いつもウィンドウサイズ=3000ですからね。

インター博士

では、バッファが埋まっていった場合の例を出そう。

[Figure41-05:バッファがたまった場合]

ネット助手

ははぁ。なかなか見事なものですねぇ。

インター博士

うむ。相手のバッファのサイズに合わせるのだ。
絶対にバッファフローを起こさせないためにな。

ネット助手

フロー制御って言うんでしたよね。

インター博士

うむうむ。その通り。
さて、次は転送中のエラーの場合を考えてみよう。

[Figure41-06:転送中のエラーの場合]

ネット助手

はわ〜。

インター博士

基本は、確認応答が返ってこなかったら再送するだ。

ネット助手

え〜っと。
でも同じ確認応答が3回きても再送するんですね。

インター博士

うむ。途中のセグメントが抜けた場合、そうなる。
前のセグメントが来ないのに、後のセグメントばかり来るからな。

ネット助手

「いいから、前のやつをよこせ」と何度も確認応答を送りつけるわけですね。
でも、なんで3回なんですか?

インター博士

ううむ。これを説明しだすと長いのだが。
簡単に言えば、「2回では再送が多発しすぎる。4回では無駄が多くなりすぎる」からだ。

ネット助手

ははぁ。

インター博士

もう1つ覚えておいて欲しいのは。
バッファ内の並べ替えだ。

ネット助手

え〜っと、例では。1001〜2000が来なかったため、2001以降のセグメントがあっても処理を保留してましたよね。
それで1001〜2000のセグメントがきたら、並べ替えた、と。

インター博士

そうだ。
TCPでは必ず番号順に処理を行う。これはセグメントが届かなかった場合以外でも起きうる。

ネット助手

そうなんですか?

セグメントの遅延

[Figure41-07:セグメントの遅延]

インター博士

途中の回線での遅延などにより、先に送ったものが後につく場合もあるのだよ。
よって、この場合もバッファ内の並べ替えを行って、番号順に処理を行う。

ネット助手

ははぁ。
しかし、こうしてみると、TCPってしっかりとした作りになってるんですねぇ。

インター博士

そうだな。
何度も言うように、正確・確実だからな。

ネット助手

ですね。

インター博士

さて、まだまだTCPには、正確・確実に送るための制御がある。

ネット助手

まだあるんですか。

インター博士

うむ、それは長いから次回にするが。
輻輳制御というやつだ。

ネット助手

…?
なんて読むんですか、それ?

インター博士

ふふふ。それは次回のお楽しみという奴にしておこう。

ネット助手

う〜、気になるぅ〜。
3分間ネットワーキングでした〜♪

ウィンドウサイズ
[window size]
オーバフロー
[over flow]
スライディングウィンドウ
[sliding window]
ネット助手ネット君の今日のポイント
  • TCPはウィンドウ制御というもので、バッファフローを防ぐ。
  • 相手のバッファサイズ=ウィンドウサイズを確かめつつ送受信を行う。
  • ウィンドウサイズの分までは確認応答を受信しなくても一度に送れる。
  • 相手のウィンドウサイズによって、送るセグメントを変えていく。この方式をスライディングウィンドウという。
  • 受け取った順ではなく、シーケンス番号順に処理を行うため、処理を保留したり並べ替えたりする。

3 Minutes NetWorking No.41

管理人:aji-ssz(at)selene.is.dream.jp