簡単にまとめてみますが、詳しくは以下のＴＣＰヘッダーの説明以降で解説します。
- 信頼性が高いコネクション型の通信
- スリーウェイハンドシェイク（3 way handshake）
- 順序制御
- 誤り訂正と再送
- フロー制御と輻輳制御
- 単一ホストでも複数のポート番号を使用することで仮想通信路を複数のアプリケーションに提供する。
ＴＣＰにおける仮想通信路をコネクションと呼びます。
下位プロトコルのＩＰにはない機能です。
スリーウェイハンドシェイク、順序制御、誤り訂正と再送、及び、フロー制御と輻輳制御によって、信頼性の確保を行っています。
信頼性が高いコネクション型の通信である反面、相手ホストへの接続に時間がかかったり、同じトランスポート層のプロトコルであるＵＤＰ（User Datagram Protocol）より通信速度が遅いです。
従って、信頼性より高速性を要求される通信には向きません。
| |||||||||||||
| |||||||||||||
| シーケンス番号 (32 bit) | |||||||||||||
| 確認応答番号 (32 bit) | |||||||||||||
| |||||||||||||
| |||||||||||||
| ＴＣＰオプションとパディング (32 bit) |
表１
上記の表１に書いたＴＣＰヘッダーの説明をします。
- 送信元ポート番号
-
１６ビットの長さなでの、0〜65535までのポート番号を設定し、この番号は送信元を表しています。
ただし、０のポート番号は予約されています。
また、ポート番号は、皆さんが良く知っているアプリケーションプログラムなどで予約されている番号がたくさんあります。
独自のネットワークアプリケーションプログラムを開発する際、これらの番号は避けなければなりません。
つまり、１０２３番以下は勝手に使えないということです。
例えば、Ｗｅｂサーバーなら８０番、電子メールの配達に必要なＳＭＴＰサーバーは２５番を使っています。
- 宛先ポート番号
-
0〜65535までのポート番号を設定し、この番号は宛先を表しています。
- シーケンス番号
-
ネットワークにどんどん出て行くＴＣＰセグメントにシーケンス番号という番号を付与します。
一連のＴＣＰセグメントの流れをストリームと言いまして、この流れの中で１つのＴＣＰセグメントがどの位置に相当するかがわかるように番号が付与されます。
シーケンス番号は送信側で処理されます。
シーケンス番号は、確実に相手にパケットを届けるためには必要となります。
- 確認応答番号
-
確認応答番号は、どの位置まで受信したかを表す数値で、位置はオクテット単位で示されます。
確認応答番号を見ると、次に受信するＴＣＰセグメントのシーケンス番号がわかります。
- ヘッダー長
-
ＴＣＰヘッダーの長さが設定されます。
ただし、４ビットしかないフィールドなので、長さがオクテット単位でそのまま設定できるわけがなく、０〜１５までの値しか設定できません。
そこで、３２ビット（４オクテット）単位で設定されます。
これだと、１５×４＝６０オクテットまでＴＣＰヘッダーの長さを設定できるため、一番最後のＴＣＰオプションがどんなに長くなっても６０オクテットということになります。
- 予約
-
予約されているフィールドです。
通常０を設定します。
- フラグ
- ＵＲＧ（Urgent Pointer）
-
このビットが１だと、緊急に処理しなければならないデータがＴＣＰセグメントに含まれていることを示します。
緊急に処理する必要があるデータ自体は、後述の緊急ポインターのフィールドに設定されます。
緊急モードに関する規定は、行われていないことから実装するシステムの開発者に任されています。
実際に使用しているアプリケーションプログラムはほとんどないようです。
- ＡＣＫ（Acknowledgment）
-
確認応答番号フィールドが有効な場合は、このビットに１が設定されますが、このビットにはほとんどの場合１が設定されます。０が設定されることはほとんどありません
ただし、ＴＣＰコネクション確立の際、最初のＴＣＰセグメントだけは違います。
最初のＴＣＰセグメントの場合は、確認応答番号フィールドが意味を持たないため、このビットは０になります。
- ＰＳＨ（Push Function）
-
このビットが１の時、受信したＴＣＰセグメントを上位のアプリケーションプログラムに引き渡すことになります。
０の時は、引き渡さずバッファリングされます。
上位のアプリケーションプログラムがＴｅｌｎｅｔのような端末プログラムの場合は、条件にもよりますが、このビットを１にした方がアプリケーションプログラムの応答性が良い場合もあります。
逆に、上位のアプリケーションプログラムがブラウザや電子メールソフトなどの場合は、このビットを０にすることで一旦バッファに溜める方が処理性能を向上させることができます。
- ＲＳＴ（Reset the connection）
-
コネクションを中断したい時にこのビットを１に設定します。
受信側では、コネクションを拒否し、強制終了する必要があります。
- ＳＹＮ（Synchronization）
-
コネクションを通すことを要求する時、このビットを１に設定します。
- ＦＩＮ（Finish）
-
ＴＣＰセグメントの転送を終了する時、このビットを１に設定します。
- ウィンドーサイズ
-
ウィンドーサイズは、ＲＷＩＮとも呼ばれています。
ウィンドーサイズは、後述のスライディング・ウィンドーやフロー制御に使用します。
ウィンドーサイズは、どのくらいデータを受信できるかを示すゆとりのようなものです。
ウィンドーサイズは、ＴＣＰの伝送効率に大きく影響するため、適切なサイズに設定されていないと、十分な通信速度が出ません。
ウィンドーサイズが小さいと、送信側と受信側の間で確認応答が行われる場合、送信側で待ち時間が発生する回数が増加し、確認応答のＴＣＰセグメントが頻繁に転送され、オーバーヘッドが大きくなり、全体のデータ転送効率が低下しま。す。
逆に、ウィンドーサイズを大きくすれば全体のデータ転送効率が向上します。
しかし、ウィンドーサイズが大きいと、回線状態が悪いネットワーク環境では、エラーが頻発し、再送信しなければならないデータ量が増加し、かえってデータ転送効率が低下してしまう結果になる場合があります。
ところで、古いWindows®を使っている場合、ウィンドーサイズやＭＴＵの初期設定値が非常に小さいです。
最近のWindows® XP、Windows® 2000(SP3)などでは、ＭＴＵが１５００オクテット、ウィンドーサイズが６４２４０オクテットと、十分な値なので問題ありません。
しかし、Windows® MeやWindows® 98などの古いWindows®では、特にウィンドーサイズが小さいので、レジストリの設定を変更する必要があります。
なお、ＭＴＵに関しては、後述の「ＴＣＰオプションとパディング」を参照して下さい。
- チェックサム
-
ＴＣＰセグメントのチェックサムがここに設定され、データの誤り検出に使われます。
チェックサムは、送られてきたにＴＣＰセグメントの内容が破壊されていないかどうかを確認することを目的としてあります。
具体的には、データの誤りをチェックするために使われる値です。
データの誤りの検査のための決まった計算方法があります。
この計算を行って検査を行うことで、データの信頼性を保証します。
チェックサムの計算を行うために、ＴＣＰ擬似ヘッダー（Pseudo Header）という以下の表に示した特殊なヘッダーを使用します。
ＴＣＰ擬似ヘッダーの先頭からの位置 長さ（オクテット） 項目内容 ０ ４ 送信元ＩＰアドレス ４ ４ 宛先ＩＰアドレス ８ １ パディング（未使用：０） ９ １ プロトコル番号（ＴＣＰを表す番号：６） １１ ２ ＴＣＰセグメントの長さ
送信側では、チェックサムの計算の際に、一時的にこのＴＣＰ擬似ヘッダーをＴＣＰセグメントの先頭に入れます。
ＴＣＰセグメントの先頭には、当然本物のＴＣＰヘッダーがあります。
次に、ＴＣＰ擬似ヘッダーとＴＣＰセグメントのサイズの合計を１６ビットの倍数にする必要があります。
そこで、半端な数になった場合、ＴＣＰセグメントの最後に０を追加しておきます。
一方、ＴＣＰヘッダーのチェックサムのフィールドには０を設定しておき、１６ビット単位に１の補数和を計算をします。
次に、１の補数和を計算した結果を反転してチェックサムのフィールドに設定します。
送信側はこれだけです。
次に、受信側です。
受信側では、ＴＣＰセグメントを受信し、ＩＰヘッダーにあるＩＰアドレスを取り出して、ＴＣＰ擬似ヘッダーに設定し、ＴＣＰ擬似ヘッダーを完成させます。
そして、チェックサムの再計算を行います。
最終的にすべてのデータを合計した値が０になっていれば、正しい内容のＴＣＰセグメントを受信したことになります。
以下のページで、ＩＰヘッダーのチェックサムの例ですが、プログラムで実際にチェックサムの計算を行うための方法を解説しました。
チェックサムの具体的な計算方法の紹介
ＩＰヘッダーのチェックサムの計算でも、１の補数和が利用されているので計算方法はだいたい同じです。
対象ヘッダーやデータが違うくらいです。
１の補数和についての説明も「チェックサムの具体的な計算方法の紹介」のページに書かれています。
- 緊急ポインター
-
緊急性がある情報の通知に使われます。
例えば、処理の中断を通信相手に要求したい場合などがあります。
- ＴＣＰオプションとパディング
-
ＴＣＰオプションは、可変長で任意の個数のオプションを設定できます。
代表的なＴＣＰオプションにＭＳＳ（Maximum Segment Size）があります。
ＭＳＳは、ＴＣＰセグメントの最大サイズのことで、ＭＴＵから４０を引いた値です。
例えば、イーサーネットでは、ＭＴＵが１５００オクテットなので、これからＩＰヘッダー（２０オクテット）とＴＣＰヘッダー（２０オクテット）を際し引きます。
そうすると、ＭＳＳは１４６０オクテットになります。
ＭＴＵとは、Maximum Transmission Unitの略で、１回で送信可能なパケットの最大値のことを言います。
ＭＳＳの値は、ＭＴＵに基づいて自動的に決定されます。
ネットワークの途中にもっと小さなＭＴＵのネットワークが存在すると、ＭＳＳの値をもっと小さくしなければなりません。
ＭＳＳに関しては、ＲＦＣ８７９に記載されています。
ＴＣＰやＴＣＰオプションについては、ＲＦＣ７９３に記載されています。
ＲＦＣの詳細は、以下のサイトで御覧下さい。
IETF RFC Page
JPNIC RFC-JP（社団法人：日本ネットワークインフォメーションセンター）
ＲＦＣ７９３の日本語訳
ＭＳＳのオプション長は４オクテットです。
ＴＣＰヘッダーは、３２ビットの倍数で区切られています。
そこでこの長さになるまでＴＣＰオプションの後ろの方は、パディング（padding）という０を設定したフィールドが付きます。
以下に代表的なＴＣＰオプションの一覧を表にまとめておきました。
タイプ 意味 ０ ＴＣＰオプションの終了。
オプション長は１オクテット。１ オペレーションなし。
特別な意味を持たず、ＴＣＰヘッダーを３２ビット単位に揃えるためにある。
オプション長は１オクテット。２ ＭＳＳの値。
受信可能なＴＣＰセグメントの最大サイズ。
オプション長は４オクテット。３ ウィンドースケール
６４ＫＢより大きいウィンドーサイズを使用したい時に指定します。
これについては、以下のＲＦＣ１３２３で記載されています。
ＲＦＣ１３２３
しかし、前述のWindows® XPなどではウィンドーサイズの初期値が６４２４０オクテットになっていて、６４ＫＢを超えておらず、この程度で十分なので、このオプションが使われることはほとんどありません。
【図１】スリーウェイハンドシェイク
ＴＣＰでは、まず相手のコンピュータと接続をする際に、【図１】のような手順で接続します。
接続を開始したいコンピュータがあった場合、(1) SYNというＴＣＰセグメントを最初に送信します。
この中身のＴＣＰヘッダーを見ると、ＳＹＮのフラグがセットされています。
次に、これを受信したコンピュータは、(2) SYN+ACKを送り返してきます。
これを受信したコンピュータは、確認応答として(3) ACKを送信します。
この３段階の通信で接続処理が完了します。
この手順をスリーウェイハンドシェイクと言います。
すいている回線ならあっという間に終わりそうですが、混雑している回線では、接続に時間がかかる場合があります。
【図２】コネクションのクローズ処理
こんなに何度もＴＣＰセグメントを送信しあわなくても良さそうに思えますが、接続時より多い４つもＴＣＰセグメントを送受信します。
接続を終了したいコンピュータがあった場合、(1) FINというＴＣＰセグメントを最初に送信します。
この中身のＴＣＰヘッダーを見ると、ＦＩＮのフラグがセットされています。
次に、これを受信したコンピュータは、(2) ACKを送り返してきます。
連続して、もう一つ(3) FINを送ってきます。
この二つのＴＣＰセグメントを受信したコンピュータは、最後に確認応答として(3) ACKを送信します。
この４段階の通信でクローズ処理が完了します。
最後に、スライディング・ウィンドーについて説明します。
【図３】スライディング・ウィンドーを使用した場合と使用しない場合の処理の流れ
左側がスライディング・ウィンドーなしの場合で、右側がスライディング・ウィンドーありの場合です。
スライディング・ウィンドーなしの場合は、データを１個送っては肯定応答のＴＣＰセグメント（上の図のAck）を返します。
最後のデータを送って最後の応答を受け取るまでキャッチボールのような動作が続きます。
大量のデータを送る必要がある場合、何度も送らなければならないので、非常に非効率的です。
たくさん送らなければならないデータがある場合、下位のＭＡＣフレームのサイズに制限があるため、上位のＩＰパケットやＴＣＰセグメントも当然分割されることになります。
そこで、スライディング・ウィンドーありの場合のようにします。
この場合は、最初のデータを１個送ってもAck1を待たずに、次のデータを送ります。
ただし、上の図は一例にすぎず、このように決められているわけではありません。
上の例では、青い★マークのデータまでがAck1を確認せずに送信できるということになります。
つまり、★マークのデータまで確認応答を待たずに送れることになります。
この最後のデータまでの合計サイズがウィンドーサイズの値になります。
上の例では、Data2を送ったところまででウィンドーサイズを満たしたことになります。
例えば、上の図の例よりもっと大きなウィンドーサイズだったとして、このサイズがＴＣＰセグメント３つ分に相当したとしたら、上の図で説明するとData3まで一気に送信できることになります。
その後、Ack1が確認応答として返されます。
ＴＣＰヘッダーに含まれるウィンドーサイズの値が一気に送信できるＴＣＰセグメントの数と関係します。
ＴＣＰでは、このウィンドーサイズを調整することで、確認の応答が来るのを待たずにＴＣＰセグメントを続けて送れるようになっています。
ウィンドーサイズは、確認応答が来るまで送り続けることが可能なデータサイズとなります。
つまり、何オクテットまで送り続けることができるかをこのウィンドーサイズに設定された値が示しているわけです。
この値は、ただ大きければ良いというわけではなく、利用する回線の状態にもよります。
低速な回線やいつも混雑している回線では、小さめな値にするのが理想的です。
このような状況以外なら大きい値が理想的です。
ウィンドーとは、受信側で用意しなければならないバッファを指し、ウィンドーサイズとはそのバッファのサイズを意味します。
ウィンドーサイズは可変長で、自由に調整できます。
このウィンドーサイズを動的に変化させることをスライディング・ウィンドーと言います。
ウィンドーサイズのフィールドは１６ビットなので、これを越える値の場合はウィンドースケールというＴＣＰオプションで指定します。
では、このウィンドーサイズをいつ相手に通知するのでしょうか。
「私のウィンドーサイズは〜だけど、あなたのウィンドーサイズは幾つですか。」と接続時に送信側が受信側に尋ねることになります。
【図１】の(1) SYNのＴＣＰセグメントを送る際、その中身のＴＣＰヘッダーを見ると、ＳＹＮのフラグがセットされて、ウィンドーサイズに送信側のウィンドーサイズの値が設定されています。
これで受信側に送信側のウィンドーサイズを通知できます。
このＴＣＰセグメントの戻りとして来る(2) SYN+ACKのＴＣＰセグメントの中身にあるＴＣＰヘッダーに含まれるウィンドーサイズには、受信側のウィンドーサイズの値が設定されています。
これでお互いのウィンドーサイズがわかったことになります。
後は相手に合わせてウィンドーサイズの値になるまでＴＣＰセグメントを連続して送っては確認応答を受け取れば良いことになります。
このように、ＴＣＰでは、スライディング・ウィンドーを採り入れることで、確認応答を待たずに一度にたくさんのデータを連続して伝送することで効率的な通信を行っています。
- フラグ処理
-
ＴＣＰヘッダーに含まれるフラグは、通信を行う両サイドのコンピュータが受け取った後何をしたら良いかを示します。
これによって、どのような伝送制御手順で通信を行うかをお互いが理解し合えます。
各フラグの役割に関しては、上の方に書いたＴＣＰヘッダーのフラグの項目を参照して下さい。
- ウィンドー処理
-
前述のＴＣＰヘッダーのウィンドーサイズの項目での説明と、上記のスライディング・ウィンドーの説明を参照して下さい。
また、ウィンドー処理は、フロー制御との関係もあるので、以下のフロー制御と輻輳制御の項目も参照して下さい。
- フロー制御と輻輳制御
-
まず、フロー制御について説明します。
ＴＣＰは、フロー制御をウィンドーサイズを動的に変更することで実現しています。
送信先から送信元に送信される確認応答のＴＣＰセグメントに変更後のウィンドーサイズの値が含まれているので、送信元はこの値に基づいて送信するデータ量を調整しています。
受信側は、受信したデータを一旦受信バッファの中に入れて、これをソケットインターフェイスと呼ばれるＡＰＩ（Application Programming Interface）を通じてアプリケーションプログラムに渡します。
しかし、何事もいつもうまくいくとは限りません。
アプリケーションプログラムは四六時中通信処理をしているわけではありません。
様々な周辺機器とデータのやりとりをしています。
計算をずっとやっている時もあります。
繰り返しが多いＣＰＵ内部の処理だけを集中的に行っている場合もあります。
従って、アプリケーションプログラムがビジー状態の時もあり、アプリケーションプログラムが処理中に作成者のミスから発生するバグと呼ばれる不具合のせいなどが原因して処理を続行できなくなる場合もあります。
このような状態がずっと続くと、受信バッファにどんどんデータが溜まり、最終的にバッファの空きがなくなり、オーバーフローしてしまうことがあります。
こうなってしまうと、受信側はこれ以上データを受信してバッファに溜めることができなくなり、ウィンドーサイズの値を変更して送信側に通知し、送信側からの送信データの量を制御することができます。
前述のように、受信バッファの空きがまったくなくなった場合、何も受信できなくなるので、ウィンドーサイズに０の値を設定して送信側に通知し、送信を止めます。
次に、輻輳制御の説明に移ります。
輻輳は、ふくそうと読みます。
ネットワークは、利用者が殺到して混雑することがあります。
ネットワークは、回線の速度や伝送能力によっても左右されます。
回線の能力が低いと、すぐ混雑してしまう場合があります。
また、ネットワークの途中にあるルーターは、まるで道路の交差点のようなもので、ここも混雑します。
ルーターの処理能力にもよりますが、性能が悪いルーターだったり、株などのインターネット取引が限られたサーバーに集中し、このサーバーへの経路上にあるルーターの処理が追いつかなくなったりします。
回線の伝送能力を上回るくらいデータを送ったり、ルーターがＴＣＰセグメントを処理したり転送したりできなくなるほど処理が追いつかなくなり、途中で頻繁にＴＣＰセグメントが破棄されるような状態が発生することがあります。
このような状態を輻輳（congestion）と言います。
一度輻輳になると、この状態から抜けることが困難になります。
ＴＣＰでは、途中でＴＣＰセグメントが失われると、再送を試みます。
そして、何度もＴＣＰセグメントロストが発生すると、再送が頻発します。
このままでいると、最悪送ってはロストという悪循環に陥り、ネットワークがダウンしてしまいます。
このことを輻輳崩壊と言います。
これを回避し、問題なく通信を行うための手段がいろいろ考案されました。
幾つか、アルゴリズムが考案されました。
このことは、以下に示したＲＦＣ２００１にまとめられています。
ＲＦＣ２００１の日本語訳
ＲＦＣ２００１の原文
ＲＦＣ２００１の原文の冒頭に「TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms」と書かれていますが、これは、「スロースタート及び輻輳回避、即時再送及び即時回復のアルゴリズム」という意味です。
これらのアルゴリズムについては、上記のＲＦＣ２００１の日本語訳が参考になります。
この訳文の内容はなかなか良いと思います。
これを読むと、輻輳制御について、だいたいわかると思います。
インターネットでも、輻輳制御について簡単に説明しているサイトは幾つかあります。
- ＴＣＰオプション処理
-
ＴＣＰオプションに関しては、ＴＣＰが実装されているシステムに依存します。
実装されていないＴＣＰオプションは、処理できないので正しく機能しません。
つまり、パソコンやそれ以外のコンピュータ、組み込み機器、ＯＳなど実装系が異なるとサポートされているＴＣＰオプションも異なります。
ＴＣＰオプションに関する詳細は、前述の「ＴＣＰオプションとパディング」を参照して下さい。