送りすぎない仕組み — フロー制御と輻輳制御の違い

前回まで、失われたデータをどう取り戻すかを見てきました。残っているのは、その手前の問いです。そもそも、どれだけの速さで送ってよいのか。

送りすぎる先が2か所ある、というのがこの話の出発点です。

ひとつは相手です。受信側にはデータを貯めておく受信バッファがあり、アプリケーションがそこから読み出します。読み出しが追いつかなければ溢れます。

もうひとつは途中です。送信側と受信側の間にはいくつものルータとリンクがあり、流れきれない量を送り込めば待ち行列が伸び、やがてパケットが捨てられます。

この2つはまったく別の事情です。相手のPCが重くてバッファを読み出せないことと、経路上のルータが混んでいることの間には何の関係もありません。片方が空いていても、もう片方が詰まっていることがあります。

だから TCP は、上限を2つ持ちます。相手の都合に合わせるのがフロー制御、途中の道の都合に合わせるのが輻輳制御です。名前が似ているうえに、どちらも「送る量を抑える」という同じ結果をもたらすので、しばしば混同されます。しかし抑える理由が違い、抑える量の決め方はもっと違います。

「上限が2つあって、小さい方が効く」と聞くと、対等な2つの値が並んでいる絵を思い浮かべます。その絵が、いちばんの誤解の元です。

この2つは、そもそも情報の出どころが違います。

              rwnd(受信ウィンドウ)        cwnd(輻輳ウィンドウ)
誰が決めるか    受信側                        送信側
どう伝わるか    TCPヘッダのWindowフィールド    伝わらない
              で広告される
パケットに      現れる                        現れない
出るか
何を表すか      受信バッファの空き            経路が耐えられる量の推定値
確かさ          相手が実際に測った値          送信側が推測した値

rwnd は、相手から届く値です。 受信側は自分のバッファの空きを知っているので、その値をTCPヘッダのWindowフィールドに書いて送ってきます。送信側は受け取ったパケットを見るだけでよく、推測は要りません。

cwnd は、誰も教えてくれない値です。 従来の TCP では、経路の途中にいるルータが「私はいま混んでいます」と知らせることはなく、送信側は損失や ACK の遅れから推定します。明示的な通知の仕組み(ECN、RFC 3168。ルータが IP ヘッダの ECN 欄に CE を立てる)もありますが、経路と両端が対応している場合に限られます。そしてどちらの場合も、ヘッダに輻輳ウィンドウの値そのものを書く欄はありません。cwnd は送信側のメモリ上にあるだけの変数で、パケットのどこにも現れないのです。

この非対称性から、決定的な違いが生まれます。rwnd は観測できるが、cwnd は推定するしかない。 では何から推定するのでしょうか。送信側が手にできる唯一の手がかりは、ACKの返り方です。送ったデータのACKが順調に返ってくるなら、経路はまだ余裕があるのだろう。ACKが返らない、あるいは重複ACKが届くなら、どこかで捨てられたのだろう——この間接的な証拠だけを頼りに、cwnd を上げ下げし続けます。

初期ウィンドウから先、cwnd をどう増やすか。最初に使われるのがスロースタートです。

名前で損をしているアルゴリズムです。「スロー」と付いているので「ゆっくり送る方式」だと思われがちですが、増え方は指数的です。ACKが返ってくるたびに cwnd を増やしていくため、ラウンドトリップごとにウィンドウはおおよそ倍々に膨らみます。

なぜ小さく始めるのでしょうか。知らないからです。 いきなり大量に送って詰まらせるより、小さく試して反応を見るほうが安全です。反応が良ければ急いで上げる。控えめなのは最初の一歩だけで、探り方はむしろ大胆です。