連載第4回
TCP/IPアレルギー撲滅ドリル【下位レイヤ編】

ウィンドウは主導権と良心のはざまで

福永勇二
インタラクティブリサーチ
2004/4/27


素朴な疑問
もー、やってらんない!なってときは
  1. やってもやっても仕事が片付きません
忙しさを伝えて無理難題から逃れる
  1. いつでも受信できるとは限りません!
  2. 腐らせないためにはどうすればいい?
  3. 忙しさを知らせる方法を教えてください
  4. 駐車場(ウィンドウ)の大きさが変わる?

渋滞防止に協力する

  1. ほかに原因はないか
  2. 道が込んだらどうしましょう。あきらめる?

渋滞を防ぐ2つの秘策

  1. 手立ては1つだけ?
  2. 送信量の減らし方は?
  3. 送信量を増やすときのポイントは?
  4. 2つの仕組みがごっちゃになりそうですが……

 渋滞防止に協力する

ほかに原因はないのでしょうか?

 通信を確実に行えない原因が、常に送信側や受信側にあるとは限りません。その間を結ぶ通信回線に問題がある場合、そこを通り抜けるのが大幅に遅れたり、場合によっては送り届けられないケースもあります。

 トラックの例でいえば、道路の渋滞は典型的なケースです。荷物配達が遅れるのはもちろん、渋滞がひどいと、その荷物を送り届けることはできないかもしれません。

 もちろんトラックの通行を妨げる原因は、このほかにもいろいろ考えられます。ただ現実世界を見る限りは、到着が遅れる原因の大部分は渋滞といっても大きな間違いはなさそうです。

 ややこしいのは、渋滞自体が、さらに渋滞を呼ぶ性質を持っている点でしょう。渋滞でトラックが届かなければ、焦った送り主は別のトラックを走らせるかもしれません。その結果、渋滞はさらに深刻になってゆきます(図5)。

 

 

 

図5 通信路の渋滞も正確な通信の邪魔をする

 

道が込んだらどうしましょう。あきらめる?

 そうできればいいのですが、なかなかそうはいきません。この事情は通信回線でも似ています。そこでTCPは、通信回線からデータが届かなくなると、通信回線が込み合っているものだと仮定して、それを和らげるために自分が送信するデータの量を減らします。渋滞を発生させないよう普段から気配りすることで、社会基盤としての道路の混乱を防ぎ、結果として自らにも利益が得られるという考え方です。これは私たちも少し見習うところがあるかもしれません。

 渋滞を防ぐ2つの秘策

手立ては1つだけですか?

 渋滞の発生を防ぐため、TCPには大きく2つの手立てが用意されています。1つは先に説明したとおり、データが到着しなくなったら、データの送信量ぐんと減らすやり方です。具体的には、受け取り確認が来なくなったら、送信元が自主的に減らす方法を取ります。別の言葉でいえば「お忙しそうなので、送信は遠慮しておきます」といったところです。TCPの用語では「スロースタート」と呼ばれます。

 もう1つは通信開始時や、渋滞が解消して普通に通信できるようになったとき、いきなり大量のデータを送らず、徐々にスピードアップしていくやり方です。これは一般社会でいう「様子見」に当たる考え方といえるでしょう。このような人間くさいアプローチがTCPに組み込まれていると思うと、何だか親近感がわいてきて、理解もしやすいというものです。

送信量の減らし方を教えてください

 もう少し具体的に見てゆきましょう。受け取り確認が到着しないと送信元は自主的にデータを送る量を減らすと書きました。一体何をどのくらい減らすのでしょうか。

 答えは「ウィンドウサイズを、送信先から知らされている値の半分だと見なす」という動作をします(図6)。ウィンドウサイズが半分になると、送信元が受け取り確認なしで送り出すデータ量は半分になります。その結果、一定時間の間に通信回線を流れるデータも半分になり、渋滞は少し解消します。

図6 渋滞状況を想像して送信量をコントロール

 もしそれでも受け取り確認が到着しないとき、送信元は、ウィンドウサイズサイズをさらに半分だと見なします。

 これを繰り返していき、最後はウィンドウサイズがトラック1台分までに減ります。こうなると送信側は、受け取り確認を受信するたびに1台分ずつしか送信しませんから、一番ゆっくり送信している状態になります。ひいては、通信回線の渋滞解消の大きな手助けになるというわけです。

送信量を増やすときのポイントは?

 データを送り始めるときはどうでしょうか。これは減らすときのアイデアと逆のことを行います。送信先のウィンドウサイズを、取りあえず1と見なして、トラック1台分から送信を始めます。受け取り確認が正常に届けば、ウィンドウサイズを毎回2倍にしていきます。これを送信先から知らされているウィンドウサイズになるまで行います。こうすることで、一気にドカンと送信が始まることを防ぐことができるわけです。

 さらに、ウィンドウサイズがある値を超えたら、倍々ゲームはやめ、それ以降は1ずつしか増やしません(図6)。増やすときに少し慎重なのは、急に増やしてまた渋滞が発生して、その結果また速度が落ちて……、という繰り返しが起こるのを防ぐ意味があります。この辺りからも「様子見」のニュアンスをお分かりいただけると思います。

 ちなみに、一般的なTCPの書籍では、通信回線に発生した渋滞を「輻湊(ふくそう)」と呼びます。「渋滞」というよりも「それらしく」聞こえますので、覚えておくとよいでしょう。

2つの仕組みがごっちゃになりそうですが……

 フロー制御と渋滞防止の2つが、それぞれ原理も目的も違うことは先の説明で理解できたと思います。でも、ちょっと待ってください。どちらも最終的に変化させるのはウィンドウサイズです。混乱することはないのでしょうか。

 結論からいえば、混乱することはありません。フロー制御は「受信側が自分の処理能力に合わせて行うウィンドウサイズの調整」であり、スロースタートは「送信側がネットワークの状況に合わせて行うウィンドウサイズの調整」です。

 データを送信する側は、受信側から知らされたウィンドウサイズを上限にして、さらに自分の判断で、ネットワークの状況に合わせてウィンドウサイズを調整します。この考え方をしていれば、受信側の指定したウィンドウサイズを超えることはありませんから、取りこぼしも起きないというわけです。実によくできていますね。

次回は、データの抜けや重複などがあったとき、どうやってそれを修復し、正確な通信を実現するのかを紹介します。

 

もー、やってらんない!なってときは

TCP/IPアレルギー撲滅ドリル【下位レイヤ編】(4)目次
1  もー、やってらんない!なってときは
 忙しさを伝えて無理難題から逃れる
2  渋滞防止に協力する
 渋滞を防ぐ2つの秘策


関連リンク
  連載:TCP/IPアレルギー撲滅ドリル【超実践編】(上位レイヤ編)
連載:インターネット・プロトコル詳説

連載:ルータの仕組みを学ぼう
ホストのネット接続は正しく行われているか? 〜netstatによるネットワーク設定の確認〜

「Master of IP Network総合インデックス」


Master of IP Network フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Master of IP Network 記事ランキング

本日 月間