|
|
|
|
 |
4.9 TCP-効率的なデータ転送のために-
4.9.1 フロー制御(流量制御)
送信ホストでは勝手に自分の都合でデータを送るが、受信ホストでは他の処理で負荷が高くなってしまっているようなときはデータを受信しきれないときがある。もし送信したデータを受信ホストが取りこぼすと、受信ホストはそのデータを再送しなければならず、無駄が増える結果になってしまう。
そのようなことを防ぐため、TCPでは受信ホストが送信ホストに受信可能なデータサイズを通知するようになっている。このサイズがすなわち前節で説明したウインドウサイズである。ウインドウサイズは、受信ホストの都合で決めるのである。
TCPのヘッダにはウインドウサイズを通知するためのフィールドがある。ウインドウサイズが大きいほど転送効率が良くなるが、受信側でバッファがいっぱいになりそうな状態になると、このウインドウサイズを小さくして送信側に送信量を減らすように要請する。このようにして、送信ホストは受信ホストの要求にしたがって送信量を制御する。この処理をフロー制御(流量制御)という。
フロー制御の例を図4.9.1に示す。
|
4.9.2 輻輳(ふくそう)制御
ウインドウ制御により、確認応答が多少到着しなくても大量のデータを連続的に送信できる。しかし、通信開始時にいきなり大量のパケットを送信することは一般的ではない。ネットワークはたくさんのコンピュータが利用している。すると、他のコンピュータの通信でネットワークが混雑している可能性がある。ネットワーク上にいきなり大量のパケットを流すとトラフィックの増大によりネットワークがパンクしてしまう可能性があり、他の人に迷惑がかかることになる。
そこでTCPではこのような事態を防ぐため、通信開始時にはスロースタートと呼ばれるアルゴリズムでデータの送信量の制御が行われる。
図4.9.2を見てもらうとわかるように、最初は少ない量のデータを送信し、だんだん増やしていくようになっている。これは自動車が少しずつスピードを加速するようなイメージである。
|
4.9.3 遅延確認応答
データを受信したホストがすぐにACKを返すとウインドウサイズとして小さな値を返してくることがある。これは受信したばかりのデータで受信バッファがいっぱいになってしまったためである。小さなウインドウサイズを通知された送信ホストがその大きさでデータを送るとネットワークの利用効率が悪くなるので、受信側ではデータを受信してもすぐにACKを返さずに、ちょっと待ってからACKを返す方法をとっている。これを遅延確認応答という。
具体的にどういう処理をしているかというと、次のようになっている。
- 2×最大セグメント長のデータを受信するまで確認応答をしない
- そうでない場合は確認応答を最大で0.5秒間遅延させる
ウインドウ制御の再送制御で説明したように、確認応答は全てのセグメントについて返ってこなくても大丈夫だった。よって遅延確認応答ではこのことを利用して、始めから全てのセグメントには確認応答を返さず、2個に1個の確認応答を返せば、その分流通するセグメントが減りネットワークの使用効率が良くなる。
|
4.9.4 ピギーバック
アプリケーションによっては送信したデータに対して、相手が処理をして返事を返すようなものがある。たとえば、FTPの制御コネクションや、TELNETで入力した文字列のエコーバック("a"と入力したらクライアントの画面にも"a"と表示されるような処理)も送信したデータに対する返事といえる。
このような通信の場合にはTCPではACKと返事のデータを同一のセグメントで送ることができる。この処理をピギーバックという。この処理により、送受信するセグメントの数を減らすことができる。
|
|
|
|
|
|
