TCP（Transmission Control Protocol）

rfc793

TCP Header Format

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            TCP Header Format

ポート番号

ICANN

シーケンス番号

コネクションが確立された後、両端はシーケンス番号、確認応答番号（相手のシーケンス番号）を保持している。パケットを送信するとき、自分が保持しているシーケンス番号、確認応答番号をヘッダに格納する。その後、送信側は自分が保持しているシーケンス番号にデータのオクテット数を加算する。コネクション確立フェーズのSYNフラグ、コネクション切断フェーズのFINフラグも、1バイト分のデータと見なしてシーケンス番号に加算される。シーケンス番号、確認応答番号のサイズは4バイトであり、32ビット値が巡回的に使用される。

確認応答番号

次に受信すべきシーケンス番号。送信側は、返された確認応答番号と次に送るシーケンス番号が同じであることを確認すれば、正常に通信が行われているか確認することができる。

データオフセット

TCPセグメント内のデータ開始位置。事実上、ヘッダ長と同じ意味。単位は4オクテット。オプションがなければ、TCPヘッダは20バイトなので、「0x05」が格納される。

コードビット

Control Bits:  6 bits (from left to right):

  URG:  Urgent Pointer field significant

  ACK:  Acknowledgment field significant

  PSH:  Push Function

  RST:  Reset the connection

  SYN:  Synchronize sequence numbers

  FIN:  No more data from sender

• URG

　このビットが立っている場合、緊急に処理すべきデータが含まれていることを示す。ホストが緊急データ受信すると、受信アプリケーションの割り込みが入るので、アプリケーションは緊急データをただちに処理する。

• ACK

　このビットが立っている場合、確認応答番号のフィールドが有効である。コネクション確立フェーズで最初に送られるパケット以外は、このビットは必ず「1」になる。

• PSH

　このビットが立っている場合、受信したデータはバッファリングされずに、ただちに上位アプリケーションに渡される。例えば、HTTPではサーバへファイル取得を要求するが、サyoーバから返信されるTCPセグメントには、PSHがセットされている。よって、クライアントOSは、受信したデータをブラウザに渡すことができる。

• RST

　このビットが立っている場合、コネクションが強制的にリセットされる。

• SYN

　コネクション確立フェーズで使用する。このビットが立っている場合、コネクション確立要求を示す。

• FIN

　コネクション切断フェーズで使用する。このビットが立っている場合、コネクション切断要求を示す。

ウィンドウサイズ

受信確認を待たずに送信できるデータサイズの最大値。（「受信バッファの空き容量」とも言える。）通常、ウィンドウサイズの初期値はTCPのMSS（Max Segment Size）を整数倍した値が設定されるが、通信中の受信状態に応じて変動する。ホストは、送信時に現在の空き容量をウィンドウサイズに格納して相手に通知する。相手ホストは、通知されたウィンドウサイズに達するまで、確認応答を待たずにデータを連続転送することができる。確認応答パケットを受けると、次はそのパケットに格納されているウィンドウサイズまでデータを連続転送する。そのパケットに格納されている確認応答番号は、次に受信すべきシーケンス番号を示しているので、送信側から見た連続転送可能なデータ範囲は、確認応答番号を起算点とするウィンドウサイズ分となる。確認応答のたびに、連続転送可能な範囲がウィンドウで示され、これが次第に移動（スライド）していく。この方式をスライディングウィンドウ方式と呼ぶ。

受信側ホストのウィンドウサイズが「0」と通知されることがある。この場合、送信側ホストはこれ以上パケットを送信できない。この状態を「ゼロウィンドウ」という。受信側ホストは、ウィンドウサイズが0より大きくなったら送信側ホストに通知する。これを「ウィンドウ更新」といい、データを格納しない確認応答パケットが用いられ、ウィンドウ領域に更新された値がセットされてる。このしく仕組みにより、送信を再開できる。ウィンドウ更新パケットが消失するリスクに備えて、送信側ホストは定期的にウィンドウプローブと呼ばれる、1オクテット分のデータを格納したパケットを送信して、確認応答パケットの返信を促す。その確認応答パケットのウィンドウサイズが「0」より大きな値に更新されていれば送信を再開する。

チェックサム

TCPセグメント（TCPヘッダとTCPデータ）のビットレベルの整合性チェックを行う。

緊急ポインタ

TCPセグメント内の緊急データの一を示す。

TCPコネクション

TCP通信の３フェーズ

１．コネクション確立フェーズ

The synchronization requires each side to send it's own initial

sequence number and to receive a confirmation of it in acknowledgment

from the other side.  Each side must also receive the other side's

initial sequence number and send a confirming acknowledgment.

    1) A --> B  SYN my sequence number is X

    2) A <-- B  ACK your sequence number is X

    3) A <-- B  SYN my sequence number is Y

    4) A --> B  ACK your sequence number is Y

Because steps 2 and 3 can be combined in a single message this is

called the three way (or three message) handshake.

The simplest three-way handshake is shown in figure 7 below.  

      TCP A                                                TCP B

  1.  CLOSED                                               LISTEN

  2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED

  3.  ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED

  4.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>       --> ESTABLISHED

  5.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED

          Basic 3-Way Handshake for Connection Synchronization

                                Figure 7.

In line 2 of figure 7, TCP A begins by sending a SYN segment indicating that it will use sequence numbers starting with sequence number 100.  In line 3, TCP B sends a SYN and acknowledges the SYN it received from TCP A.  Note that the acknowledgment field indicates TCP B is now expecting to hear sequence 101, acknowledging the SYN which occupied sequence 100.

At line 4, TCP A responds with an empty segment containing an ACK for TCP B's SYN; and in line 5, TCP A sends some data.  Note that the sequence number of the segment in line 5 is the same as in line 4 because the ACK does not occupy sequence number space (if it did, we would wind up ACKing ACK's!).

2．通信フェーズ

送信側のアプリケーションデータは、受信側のアプリケーションに順番通りに受信される。データのオクテット数がMSSより大きい場合、MSSに収まるよう、複数個のパケットに分割されて送信される。このとき、相手に順番どおりデータが送られることを保証するため、シーケンス番号と確認応答番号が用いられる。

データを送信した後、送信側は自分のシーケンス番号に送信データのオクテット数を加算した値を保持する。
データを受信したとき、受信側は自分が保持しているシーケンス番号とパケットの確認応答番号、及び自分が保持している確認応答番号とパケットのシーケンス番号が、ともに一致していることを確認する。正常に受信したことを確認できると、自分の確認応答番号に受信データのオクテット数を加算した値を保持する。

次の図は、ホストAから1,000バイト、ホストBから2,000バイトを送信している。イーサネットの場合は、MSSが1,460バイトなので、2,000バイトを送信するため2パケットを要する。連続転送が可能なデータの範囲は、受信した確認応答パケットに格納されている確認応答番号とウィンドウサイズの値から決定される。つまり、確認応答番号を起算点としたウィンドウサイズ分が、連続転送可能なデータの範囲となる。この範囲は、確認応答パケットを受信するたびに更新される。

通常、TCPはデータパケットを受信したとき、すぐには確認応答パケットを返信しない。これを遅延ACKという。遅延ACKの仕組みにより、そのACKと同じ方向にデータを送信する場合、そのデータパケットに便乗して確認応答番号を通知することができる。これをピギーバック（piggy-back: 便乗）という。この遅延ACKはタイムアウト値をもっており、多くの実装では200ミリ秒に設定されている。つまり、この時間以内にピギーバックできなければ、確認応答パケットを返信する。

通信フェーズでエラーが発生した際の再送制御には大きく分けて、「再送タイムアウトによる方法」と「高速再転送による方法」がある。

送信したパケットに対するACKパケットが返ってこなかった場合、途中経過でパケットが消失したか、受信側で何らかのトラブルが発生してACKが返せなかったためと考えられる。このとき、送信側は一定期間待ってからパケットを再送する（再送するまでの時間をRTO（Retransmission Time Out: 再送タイムアウト）と呼ぶ。）再送が繰り返し行われる場合は途中経路で輻輳が発生していることが考えられる。RTOの値は再送のたびに2倍になり、最大で64秒になる。

もう一方の高速再転送は、連続転送している状況下で特定のTCPセグメントだけが欠落した場合、受信ホストから送信ホストに対し、当該TCPセグメントを再送するよう通知する仕組みである。その際、3回以上連続してACKを再送する。

3. コネクション切断フェーズ

CLOSE is an operation meaning "I have no more data to send."  The notion of closing a full-duplex connection is subject to ambiguous interpretation, of course, since it may not be obvious how to treat the receiving side of the connection.  We have chosen to treat CLOSE in a simplex fashion.  The user who CLOSEs may continue to RECEIVE until he is told that the other side has CLOSED also.  Thus, a program could initiate several SENDs followed by a CLOSE, and then continue to RECEIVE until signaled that a RECEIVE failed because the other side has CLOSED.  We assume that the TCP will signal a user, even if no RECEIVEs are outstanding, that the other side has closed, so the user can terminate his side gracefully.  A TCP will reliably deliver all buffers SENT before the connection was CLOSED so a user who expects no  data in return need only wait to hear the connection was CLOSED successfully to know that all his data was received at the destination TCP.  Users must keep reading connections they close for sending until the TCP says no more data.

There are essentially three cases:

  1) The user initiates by telling the TCP to CLOSE the connection

  2) The remote TCP initiates by sending a FIN control signal

  3) Both users CLOSE simultaneously

 

フロー制御と輻輳制御

コネクション確立フェーズ中に、ホストは互いにウィンドウサイズの最大値を通知し合う。また、通信フェーズ中、スライディングウィンドウ機構により通知された受信可能なウィンドウサイズは動的に変化する。これをフロー制御という。

更に、輻輳を回避するため、ホストは「輻輳ウィンドウ」と呼ばれる変数を管理している。最小値は１×MSS、最大値はウィンドウサイズ最大値である。ホストは、輻輳を回避するように輻輳ウィンドウの値を調整する。これを輻輳制御という。

実際に送信されるオクテット数は、輻輳ウィンドウの値と、通知された受信可能ウィンドウサイズの値を比較し、小さい方が採用される。

スロースタートアルゴリズム

ホスト同士が同じLAN上に存在しておらず、途中経路にルータや低速な回線が存在しているとき、ウィンドウサイズの最大値で通信するならば、通信能力の最大値を超えて輻輳が発生する可能性がある。そこで、輻輳を生じさせずに十分な伝送効率が得られる適切なウィンドウサイズを探し出すため、スロースタートアルゴリズムが用いられる。

通信フェーズ開始時、輻輳ウィンドウを１×MSSから開始する。その後、確認応答パケットを受信した個数だけ、輻輳ウィンドウをMSSずつ増やしていく。

具体的に数値を使って、この仕組みを説明する。最初は、輻輳ウィンドウ：1，送信パケット：1個である。確認応答パケット：1個を受信すると、輻輳ウィンドウ：2に更新される（輻輳ウィンドウ：1＋確認応答パケット：1）。次に、輻輳ウィンドウ：2、送信パケット：2個である。確認応答パケット：2個を受信すると、輻輳ウィンドウ：4に更新される（輻輳ウィンドウ：2＋確認応答パケット：2）。以降、輻輳ウィンドウは、8、16、32という具合に指数関数的に増加する（ただし、送信パケット数＝確認応答パケット数の場合）。

輻輳回避アルゴリズム

重複ACK（3回以上連続した同じACK）を受け取ると、輻輳が発生したと判断し、ウィンドウサイズをいったん半分に縮小してから、輻輳ウィンドウを徐々に（直線的に）増やしていく。これを「輻輳回避アルゴリズム」という。この仕組みにより、輻輳がすぐに再発しないようにしている。

一方、再送タイムアウトが発生した場合は、スロースタートからやり直し、再送タイムアウトが発生した時点のウィンドウサイズの半分に到達してからは、輻輳回避フェーズに入る。

TCP接続のリセット

コネクション確立フェーズ又は通信フェーズで、受信したTCPセグメントのヘッダに解決不能のパラメタが存在している場合、TCP接続がリセットさる。その代表例は、コネクション確立フェーズにおいて、最初の確立要求パケットの宛先ポート番号が、宛先ホスト上で実行されているアプリケーションで対応していない場合である。このとき、RST/ACKフラグをセットしたパケットが返信される。

As a general rule, reset (RST) must be sent whenever a segment arrives

which apparently is not intended for the current connection.  A reset

must not be sent if it is not clear that this is the case.

TCP Reset参考記事 

TCP通信のスループット

TCP通信の実効転送速度は、次の式で求まる。ここで、ラウンドトリップ時間とは、パケットの往復時間のことである。

実効転送速度＝ウィンドウサイズ/ラウンドトリップ時間

ホストAがホストBに向けてパケットを連続転送している様子を例に、解説する。

ホストAは、送信したいデータ量がウィンドウサイズ以下であれば、確認応答を待たずにデータを連続転送できる。しかし、送信したいデータ量がウィンドウサイズを超えている場合、ウィンドウサイズの分まで連続転送した後は、ホストBから最初のパケットへの確認応答を受信するまで、後続するパケットを転送できない。これ例からわかるように、ラウンドトリップ時間に送信できるデータ量の上限値は、ウィンドウサイズ分となる。したがって、TCP通信のホスト間の実行転送速度は上の式で求まる。

通信フェーズの開始直後は、スロースタートアルゴリズムが作用し、ウィンドウサイズは小さい。例えば、Web通信のように数往復でファイルの取得を終えてしまう通信の場合、ラウンドトリップが大きいと通信回線の帯域を十分に使いきれないことがある。現在、この問題を改良するために方式がいくつか提唱されており、一部ではあるが、対応しているOSもある。