■ TCPおさらい・みたび

まだまだTCPの話だ。
前回までのことは覚えているか？

えぇ、まあ、たぶん。

ふむ。
自信なさげで大変よろしい。

よろしいんですか、それって？

自信あふれるネット君などというものは、物理的に存在し得ないものだからな。
「自信あります」などと言われたら、物理法則が捻じ曲がるところだ。

ううぅ。

さて、まずはお約束。
TCPヘッダを見てもらおう。

このウィンドウとシーケンス番号と確認応答番号の３つを使って、前回説明したのはなんだった？

スラインディング・ウィンドウ？

そうだ。
相手の処理できるスピードと一時的な保持領域(バッファ)を考慮して、データを送る。
つまりフロー制御だ。

ふろー。
「流れ」という意味ですよね。

うむ。
つまり、「データの流れ」を制御するのだな。
この制御は、先ほども言ったが相手のバッファ量に応じた制御を行うわけだ。

まだ処理していないデータを入れておくバッファの量ですね。

そうだ。
バッファが満タンに近い場合は、それ以上送るとあふれ出てパケットが破棄されてしまう。なので、満タンになりそうだったら、あまり送らない。

逆に、空いている時は一気に送りつけるんでしたよね。

その一気に送り付けれる量の事を、ウィンドウサイズという。
先ほどのTCPヘッダにその項目がちゃんとあるだろう？

ありますね。
16ビットです。

この「フロー制御」以外にも、TCPはまだまだ制御を行う。
それが今回の輻輳制御だ。

前回も聞きましたけど。
なんて読むんです？

■ 輻輳

ふむ。
「車ヘン」を抜いて読んでみたまえ。

「副」「福」と同じだから、「ふく」？
後ろは「奏」だから「そう」？

正解。
「ふくそう」と読む。

やりぃ。
で、なんなんです、それって？

「渋滞によるデータ破棄」と説明するのが一番簡単だろう。
まあ、正確にはちょっと違うが。

はぁ。
渋滞によるデータ破棄…。

これは普通の電話でも起きることだ。
大災害が発生すると、そこに電話がつながりにくくなるだろう？

なりますね。
安否の確認のため電話しますものね。

そうだ。
集中した呼び出しが交換機の処理能力を超えると、繋がらなくなる。その状態を輻輳という。

ははぁ。
人気チケットの電話予約とかでも起きますよね。

とまぁ、これは電話の輻輳の話だ。
より詳しくはNTTの説明ページでも読んでくれ。▼ link

電話での話ってことは。
ネットワークでは違うってことですか？

いやまあ、似たようなものだ。
ルータの処理速度を超えたパケット量がきた場合や。そもそも回線のスピードを上回るパケットを送信しようとした場合などで起こる。

ルータの処理速度を超えるパケット…。
え〜っと、ルータは受け取ったパケットを一時保管するバッファを持たないのですか？

もちろん、持っている。
ただ、パケットが集中するとバッファがあふれるのだ。

じゃあ、TCPみたいにフロー制御をすれば…。

ネット君。
TCPのフロー制御とはどういうものだ？

え？
え〜っと、お互いに相手のウィンドウサイズを教えあって…。

そうだ。はっきりいって、手間のかかる方式だ。
途中で経由するルータがいくつあるかわからないのに、そこまでやるのは現実的ではない。

う、う〜ん。
そういわれれば、そうかも。

基本的にネットワークは運ぶ以外の仕事をしたがらない。
レイヤ３以下を考えてみたまえ。
誰が、何処にデータを送る以上のことを考えているかね？

そうですね。
…。そういわれると、ないかも。

運ぶ以外のことを考え出すと、ネットワーク自体に負荷がかかりすぎる。全体の送受信量が増えるわけだ。
さらに、現在のネットワークはあまりにも多種多様なアプリケーションが存在する。

はぁ。

どれか１つに最適化、などできようもない。いつどこで輻輳が発生するかも、予測できない。
なので、端末側で制御するのだ。

端末側で制御、ということは。
送る、受け取るパソコンで行うってことですか？

■ スロースタートアルゴリズム

そうだ。
TCPではスロースタートアルゴリズムというものを使う。

すろーすたーと？
遅いスタートですか？

うむ。
仕組みはこうだ。

最初は１つ？

うむ。
それで確認応答が届くうちは一度に送る数を増やしていく。

１つ。２つ。４つ…、倍ですか？

いや、ある程度までいったら、１ずつだ。
なので、グラフにすると、以下のようになる。

最初は、小さい数のセグメントを送り、倍々で送る数を増やしていく。
だが、多く送ると、それだけ輻輳の可能性が増える。

一度に多く送ると渋滞するかもしれないってことですか。

うむ。
なので、ある一定値までいったら、ゆっくりと増やしていく。「輻輳が起きそうだな〜」とゆっくりと。

輻輳が起きた場合はどうなるんです？

輻輳が発生した場合、つまり確認応答が１つでも帰ってこなかった場合、いったん送る数を減らす。
グラフにすると、以下のような形だ。

１まで戻るんですか。

そうだ。
基本は１まで戻す形になる。１まで戻せば連続して輻輳は発生しないからな。

確かにそうですね。
でも、「基本は」ってことは、応用もあるんですか？

ふむ、なかなかいいツッコミだ。
確かに１まで戻せば、連続して輻輳は発生しないが、また多く送ることができるまでに時間がかかる。なので、応用は以下のグラフになる。

ははぁ。半分にする、と。

つまり、スロースタートアルゴリズムとは、送る数を増やしつつ、輻輳が起きる送信数を手探りで探していく方法だ、と考えてもらうといい。

手探りで探す…。あぁ、なんとなくわかります。
こう、順に増やしつつ送っていって、ポイントを探すみたいな。

そうだな。
輻輳が起こりうる送信数は事前にはわからないから、ちょっとずつ送って反応を確かめるのだよ。

■ フロー制御と輻輳制御

でも博士。
これって前回のフロー制御と矛盾しませんか？

どこがだね？

だって、ウィンドウによるフロー制御は、ウィンドウサイズまで送るって話だったじゃないですか。

確かにそうだ。
だが、前回のフロー制御は、あくまでもバッファフローを起こさせないための制御だ。
今回は、輻輳でパケットが破棄されないための制御だ。

？

つまり。
TCPでは最初はスロースタートアルゴリズムで始まる。最初は１個。次は倍々で送っていくわけだ。

はい。

それで、輻輳が起きなかったら、最終的にはウィンドウサイズまでセグメントを送ることができるようになる。
倍々に増えていくといっても、無限に増えていくわけではない。

それはそうですね。
で、輻輳が起きたら？

輻輳が起きたら、一時的に送る数を減らして、輻輳を回避する。

ふむむ〜？
ウィンドウサイズまで送ることができるはずなのに？

そうだ。
相手のバッファだけを見れば、ウィンドウサイズまで送ることが可能だ。だが、ネットワークの状態がそれを拒否するわけだ。

輻輳が発生したから？

そう。
バッファフローだろうが、輻輳だろうがパケットの破棄という点では同じだ。それは、TCPでは起きてはいけないことだ。

正確・確実、ですね。

そういうことだ。
つまり、フロー制御でバッファフローを。

スロースタートアルゴリズムで輻輳を。

この２つで送るセグメント数を制御して、パケットの破棄を防ぐということだ。

ははぁ。

■ TCP・まとめ

今回で、TCPの話は終わりなのでまとめといこう。

はい。

TCPは、スリーウェイハンドシェイクでコネクションを確立する。

コネクションを確立して、お互いに確実に送受信が可能であることを示すわけですね。

そして、相手に確実に送ったことを、確認応答で確かめることをしながら、セグメントを送るわけだ。

シーケンス番号と、確認応答番号でしたっけ。

送るときは、フロー制御と輻輳制御を行う。

パケットの破棄が起きないように、確実に送るんですね。

うむ、そうだ。

なんか確実って言葉ばっかりですね。

それがTCPの謳い文句だからな。

ははぁ。

さて、次回はポート番号の説明をする。

了解。
３分間ネットワーキングでした〜♪