１-１ ウィンドウ制御
TCPでは、１つのデータ送信に対して、１つの応答を返すのが基本。しかし、大量のデータを送るような場合には、１つ１つのデータを逐一応答をしているようでは、非常に効率が悪くなる。
「TCPヘッダ」には、「ウィンドウズサイズ」というフィールドがある。「ウィンドウサイズ」は確認応答を待たずに送信することができるデータ量。
この「ウィンドウサイズ」を使用してデータの送信量を決定する処理を「ウィンドウ制御」という。これによって、セグメントをまとめて送信してから確認応答を待つことで転送速度を上げることができる。
ウィンドウサイズはスリーウェイハンドシェイク時にお互いに通知する。
■ スライディングウィンドウ
TCPでは、「スライディングウィンドウ」という方法を使用して、転送の効率化を図っている。スライディングウィンドウとは、１つのデータに対する確認応答を待ってから次のデータを送るのではなく、確認応答を待たずにデータを先送りしてしまうこと。また、確認応答は、１つのデータごとにではなく、まとめて送り返すことができる。
この様な方法をとることで、応答パケット量を減らすことができ、さらにデータの転送効率を向上させることができる。
例を出すと、MSSが「１０００バイト」、ウィンドウサイズが「４０００バイト」の場合を考えてみる。
送信側は、「１０００バイト」ずつ、４回までデータを送信することができるが、「４０００バイト」で受信側のバッファが一杯になるため、確認応答の到着を待つ間、データを送信することができなくなる。
スライディングウィンドウでは、受信側はデータを受信するごとに確認応答を送信し、送信側は、確認応答を受信するごとに、受信済みのデータ量をバッファからクリアする。
受信側のバッファが一杯になる前に確認応答が到着すれば、さらにもう１回、続けてデータを送ることができるようになる。
これを繰り返すことによって、データを連続的に送信することが可能になる。
1-2 フロー制御
受信側のホストで、受信したパケットの処理に時間がかかり、次のパケットが処理できないような場合、送信側のホストから送られてくるデータは、受信バッファに蓄積される。
受信側のホストで受信したパケットの処理が、送られてくるデータに追いつかない場合には、受信バッファには、送られてくるデータが、次から次へと蓄積されていってしまう。このままの状態だと受信バッファは「オーバーフロー」になってしまう。
ＴＣＰでは、この様な事態を避けるために、通信中に、受信側のバッファに空きがなくなると、受信側はウィンドウサイズを「０」にした確認応答で伝える。
確認応答を受け取った送信側のホストは、データ送信は一時中断し、その後、バッファに余裕ができるとウィンドウサイズを徐々に大きくする。
その後、受信側のホストで、受信したパケットの処理が進み、受信バッファに空きができたら、受信側のホストは送信側のホストに対し、ウィンドウを通知するメッセージを送信し、このメッセージにより、送信側のホストは、パケットの送信を再開する。
この様に、送受信データの量を調整する仕組みを「フロー制御」という。
