TCP / Transmission Control Protocol

■ TCP。Transmission Control Protocol。

  伝送制御プロトコル。

  IPによるデータ運搬を
  個々のアプリケーションが適切に利用できるようにするインターフェース。
  OSI参照モデルではトランスポート層の機能に相当し、
  IETFによりRFC793として標準化されている。プロトコル番号は6。

  TCPは、コネクション型プロトコルであり、
  通信に先立って3ウェイハンドシェイクで相手先TCPと仮想回線を確立する。
  またTCPはシーケンス制御、フロー制御、誤り検知、再送制御などの機能を持っており、
  非常に信頼性が高い通信を実現することができる。

  このためTCPは、メールやファイル転送などに適しており、
  HTTP、SMTP、FTP、TELNETなど、多くのアプリケーションが、
  TCPを利用した通信を行なっている。

  しかしTCPには欠点もある。
  高機能なためにオーバヘッドが大きく、帯域を比較的多く使うということである。
  このため、リアルタイムデータの転送等には、UDPを用いる場合が多い。

■ ヘッダフォーマット。

  TCPのヘッダは20バイトからなる。
  ヘッダフォーマットは下記の通り。
  個々のフィールドの機能については、順を追って記述する。

  

■ ポート番号。Port Number。

  同一マシン上で、
  複数のアプリケーションが同時に通信するために、
  IPアドレスの下に設けられたサブ(補助)アドレス。
  TCPとUDPが認識するサービス識別番号。

  ポート番号は16ビットからなり、
  0から65535の値を取ることができるが、
  これらは3つの領域に分類される。
  すなわち、特権ポート、登録済みポート、プライベートポートである。

  (1) 特権ポート。Privileged Ports。

    ポート番号 0〜1023。
    特定の上位プロトコルのために予約されている番号。
    ウェルノウンポートとも呼ばれ、RFC1700に規定されている。
    FTPが使用する20番と21番、TELNETの23番、SMTPの25番、DNSの53番、
    HTTPの80番などが代表的なもの。

    

  (2) 登録済みポート。Registerd Ports。

    ポート番号 1024〜49151。
    特権ポート以外で、IANAが一元的に管理している番号帯。
    ベンダが固有のアプリケーションなどを登録することができる。
    
  (3) プライベートポート。Private Ports。

    ポート番号 49152〜65535。
    自由に利用できる番号帯。
    上位プロトコルが、送信元ポート番号として通信の都度動的に割当てる。
    ダイナミックポートともいう。

■ シーケンス番号。Sequense Number。

  今回送信したTCPセグメントに含まれているデータが
  同一コネクション内で送信するデータ全体の中でどの位置にあたるのかを、
  バイト数で示したもの。
  TCPヘッダの中で32ビットを占める。
  
  TCPは、アプリケーションから受け取ったデータが大きい場合、
  決まった大きさ(MSSという)の複数のデータフラグメントに分割して、
  ネットワーク層プロトコルに渡す。

  このときTCPは、各セグメントにデータの順番をつけておく。
  つまり、このセグメントが格納しているデータフラグメントは、
  元データのどの部分に当たるかが分かるようにし、
  あとから順番に並べ替えられるようにするのである。

  このシーケンス番号は、必ずしも1から始まる数字ではない。
  初期シーケンス番号はコネクション確立時に乱数で決定され、
  データを送信するたびにバイト数が加算される。
  そしてコネクションが終われば、シーケンス番号はリセットされる。

  受信側のTCPは、セグメントを受け取ると、
  シーケンス番号を参照してデータフラグメントの順番を確認する。
  もしも伝送遅延によりデータフラグメントの着順が変わったり、
  再送により同じデータフラグメントを重複して受信したら、
  適切に並べ替えて、ふたたび元のアプリケーションデータを復元する。

  TCPによるこの一連の動作を、シーケンス制御という。
  この機能はTCPに固有であり、UDPにはこの機能がない。
  すなわち、TCPヘッダにあるシーケンス番号フィールドは、
  UDPには存在しない。

■ 確認応答番号。Acknowledgement Number。

  ACK番号ともいう。

  相手側から送信されたデータフラグメントを
  受信側のTCPが正しく受信できたことを示すために
  送信側に返す応答番号のこと。
  TCPヘッダの中で32ビットを占める。

  受信側のTCPは到着するデータフラグメントを監視しており、
  データフラグメントが届くと、
  そのシーケンス番号に次のフラグメントのバイト長(MSS)を加算し、
  これを送信側のTCPに通知する。

  ここで通知されるのがACK番号であり、
  要するにACK番号は、
  受信側が次に受信したいフラグメントのシーケンス番号
  を表している。

  こうして送信側TCPは、
  送信したフラグメントが正しく受信できたのかどうか、
  次はどこからデータを送信すればよいのかを知ることができ、
  これを確認すると、次のデータの送信をする。

  なお送信側TCPでは、
  1つフラグメントを送るごとにタイマーを起動しているので、
  一定時間たってもACKが返ってこない場合には、
  同じデータフラグメントを再送する。

  何度もこのような事態に陥った場合には、
  通信が切断されたと判断してTCPのコネクションを切断する。

  こうした一連の動作はTCPだけのものであり、UDPではできない。
  すなわち、TCPヘッダにあるACK番号フィールドは、
  UDPには存在しない。

  → こちらも参照のこと。

■ コードビット。Code Bit。

  TCPヘッダに含まれる6ビットのフィールド。
  個々のビットは特定の意味を持つフラグとして使用され、
  0または1のどちらかの値を取る。

  コードビットの中身。全6ビット。
  +-----+-----+-----+-----+-----+-----+
  | URG | ACK | PSH | RST | SYN | FIN |
  | (1) | (1) | (1) | (1) | (1) | (1) |
  +-----+-----+-----+-----+-----+-----+
 
  (1) URG。Urgent Flag。
　    緊急に処理するべきデータを送るときに1を立てる。

  (2) ACK。Acknowledgement Flag。
　    ACKメッセージを送るときに1を立てる。
      このビットが1の時は確認応答フィールドが有効である。
      基本的にはいつでも1になっている必要がある。

  (3) PSH。Push Flag。
　    受信したデータのバッファリングの可否を表す。
      このビットが1のときはバッファリング不可。
      すぐ上位アプリケーションにデータを渡さないといけない。

  (4) RST。Reset Flag。
　    コネクションを強制的に切断するときに1を立てる。
      たとえば使用されていないポート番号に接続要求が来たとき、
      1を立てて返信する。

  (5) SYN。Synchronize Flag。
　    コネクションの確立を要求するときに1を立てる。。
      SYN=1がセットされたセグメントをSYNセグメントと呼ぶ。
      SYNセグメントにはシーケンス番号の初期値が格納される。

  (6) FIN。Fin Flag。
      コネクションの切断を要求するときに1を立てる。
      FIN=1がセットされたセグメントをFINセグメントと呼ぶ。
　    もう送信するデータがないことを表している。

■ ウィンドウサイズ。

  TCP通信において、
  確認応答なしに連続して送受信できるデータ量を、
  バイト数で表したもの。

  1つのセグメントを送信するごとに
  そのセグメントに対するACKが返ってくるのを待って、
  それから次のセグメントを送信するのでは、
  データの転送速度が遅くなってしまう。

  これでは困るので、TCPでは、確認応答を待つことなく
  いくつかのセグメントをまとめて送ることができる。
  ここで送れる最大サイズがウィンドウサイズである。
  そして受信側のTCPは、それらのセグメントに対して、
  まとめて1つだけACKを返送する。

  こうしてTCPは、ACK待ちを減らし、
  転送効率をアップしている。これをウィンドウ制御という。
  一般には、ウィンドウサイズを大きく取れば取るほど、
  スループットを向上させることができる。

  さらにTCPの場合は、セグメントがすべて揃わなくても、
  ウィンドウの最初の方のセグメントが到着しさえすれば、
  その部分だけ先にACKを返す。
  すると送信側が、ACKが返ってきた分だけ、新しいセグメントを送信する。
  この仕組みをスライディングウィンドウという。

  TCPのウィンドウサイズは、
  コネクションごとに最初のハンドシェイクの際に双方で確認するが、
  1つのTCPコネクションの中で、
  動的にウィンドウサイズを変更することもできる。

  たとえば、送信TCPが勝手にデータを送ると、
  受信側TCPでバッファがいっぱいになることがある。
  すると受信側TCPは、より小さいウインドウサイズを指定して、
  まとめて送るデータ量を減らすように送信側に要請する。

  これを受けた送信側TCPは、
  要求にしたがって送信量を抑制するため、
  受信側のバッファあふれを未然に防ぐことができるのである。  
  こうした一連の処理をフロー制御という。  

  ※ TCPが、ウィンドウサイズを変更するのは、
     ネットワークの輻輳を制御するためではない。
     TCPは、ATMやフレームリレーと違って、
     網の輻輳情報を通知するヘッダ情報を持っていない。

■ チェックサム。

  誤り検出用の符号を格納し、
  送受信の間にセグメントが壊れていないか確かめるための。
　16ビットで構成される。

  TCPは下位層を信頼しないので、
  TCPヘッダとデータ領域の全てをチェックの対象とする。

■ MSS。Maximum Segment Size。

  最大セグメント長。

  セグメントに格納されるデータの最大バイト長。
  TCPは上位アプリケーションからのデータを複数に分割するが、
  その分割後のデータの長さをいう。
  セグメント長というが、TCPヘッダの大きさは含まれない。

  TCPでは、データ転送の前にコネクションを確立するが、
  そのとき同時に、このMSSの決定も行っている。

  すなわち送信側のTCPは、
  自ら接続されたデータリンクのMTUの値から、可能なMSSの値を計算し、
  これをSYNセグメントに含めて、相手先に通知する。

  たとえばイーサネットに接続されている場合には、
  MTUは1500バイトなので、IPヘッダの20バイトと
  TCPヘッダの20バイトを除いた1460を、希望するMSSとして通知する。

  受信側のTCPは、SYNセグメントに書かれているMSSと、
  自分の方で受信可能なMSSとを比較して、
  小さいほうの値を採用し、採用したほうをACKセグメントで通知する。

■ コネクションの確立シーケンス。

  TCPは、コネクションの確立を行なうとき、
  3ウェイハンドシェイクという方法をとる。
  3回キャッチボールしてから、データの転送を始める。
  といった感じである。

  (1) ホストAがコネクション確立要求を出す(SYN)。
  (2) ホストBがこれに同意し、Aにコネクション確立要求を返す(SYN/ACK)。
  (3) ホストAがこれに同意する(ACK)。

  

■ コネクションの切断シーケンス。

  一方、コネクションを切断する場合には、2ウェイを2回行う。

  (1) ホストAがコネクション切断要求をホストBに投げる(FIN)。
  (2) ホストBがこれに同意する(FIN)。
  (3) ホストBがコネクション切断要求をホストAに投げる(FIN)。
  (4) ホストAがこれに同意する(ACK)。

  ホストAがデータの送信を終わって切断要求を出した場合でも、
  ホストBからの切断要求がない限りコネクションは維持されたままである。

  

以上。

2004/03/20 pm