伝送制御プロトコル

伝送制御プロトコル
プロトコルスタック
略語TCP
開発者ヴィント・サーフとボブ・カーン
導入1974 （1974年）
に基づくトランスミッション制御プログラム
OSI層トランスポート層（4）
IP番号6
RFC(s)9293

伝送制御プロトコル( TCP ) は、インターネット プロトコル スイートの主要なプロトコルの 1 つです。これは、インターネット プロトコル(IP)を補完する初期のネットワーク実装に由来します。そのため、スイート全体は一般にTCP/IPと呼ばれます。TCP は、 IP ネットワーク経由で通信するホスト上で実行されているアプリケーション間で、オクテット(バイト)ストリームの信頼性の高い、順序付けられた、エラー チェックされた配信を提供します。ワールド ワイド ウェブ、電子メール、リモート管理、ファイル転送、ストリーミング メディアなどの主要なインターネット アプリケーションは、 TCP/IP スイートのトランスポート層の一部である TCP に依存しています。SSL /TLS は多くの場合 TCP 上で実行されます。今日でも、TCP はほとんどのインターネット通信のコア プロトコルであり、さまざまなネットワーク間で信頼性の高いデータ転送を保証しています。[ 1 ]

TCP はコネクション指向であり、送信側と受信側は合意したパラメータに基づいてまず接続を確立する必要がある。これは 3 ウェイハンドシェイク手順によって行われる。[ 2 ]接続が確立される前に、サーバーはクライアントからの接続要求を待機している (パッシブ オープン) 必要がある。3 ウェイ ハンドシェイク (アクティブ オープン)、再送、およびエラー検出によって信頼性は向上するが、待ち時間が長くなる。信頼性の高いデータ ストリームサービスを必要としないアプリケーションでは、代わりにユーザー データグラム プロトコル(UDP)を使用することもできる。UDP は、信頼性よりも時間を優先するコネクションレス型データグラムサービスを提供する。TCP はネットワーク輻輳回避を採用している。しかし、TCP には、サービス拒否、接続ハイジャック、TCP 拒否、リセット攻撃などの脆弱性がある。

歴史的起源

1974年5月、Vint CerfとBob Kahnは、ネットワークノード間でパケット交換を使用してリソースを共有するインターネットワーキングプロトコルを説明しました。 [ 3 ]著者は、Gérard Le Lannと協力して、フランスのCYCLADESプロジェクトの概念を新しいネットワークに取り入れていました。[ 4 ]その結果生まれたプロトコルの仕様であるRFC 675 (インターネット伝送制御プログラムの仕様) は、Vint Cerf、 Yogen Dalal、Carl Sunshineによって書かれ、1974年12月に出版されました。 [ 5 ]そこには、インターネットワークの略語として、インターネットという用語が初めて証明された使用法が含まれています。

伝送制御プログラムは、ホスト間のコネクション指向リンクとデータグラムサービスの両方を組み込んでいました。バージョン4では、モノリシックな伝送制御プログラムは、伝送制御プロトコルとインターネットプロトコルで構成されるモジュールアーキテクチャに分割されました。[ 6 ] [ 7 ]この結果、 TCP/IPと呼ばれるようになったネットワークモデルが生まれましたが、正式には国防総省インターネットアーキテクチャモデル（略してDoDモデル）やDARPAモデルなどと呼ばれていました。[ 8 ] [ 9 ] [ 10 ]後に、インターネットプロトコルスイートの一部となり、同義になりました。TCPは進化を続けており、増分更新とベストプラクティスがRFC 9293（2022）などのRFCで正式化されています。[ 11 ]

以下のインターネット実験ノート（IEN）文書はTCPの現代版への進化について説明しています。[ 12 ]

  • IEN #5インターネット伝送制御プログラム TCP バージョン 2 の仕様(1977 年 3 月)
  • IEN #21インターネットワーク伝送制御プログラム TCP バージョン 3 の仕様(1978 年 1 月)
  • IEN #27 TCPバージョン3.1ヘッダーフォーマットの提案（1978年2月）
  • IEN #40伝送制御プロトコル ドラフト バージョン 4 (1978 年 6 月)
  • IEN #44最新のヘッダーフォーマット（1978年6月）
  • IEN #55インターネットワーク伝送制御プロトコルバージョン4の仕様（1978年9月）
  • IEN #81伝送制御プロトコル バージョン 4 (1979 年 2 月)
  • IEN #112伝送制御プロトコル（1979年8月）
  • IEN #124 DOD標準伝送制御プロトコル（1979年12月）

TCP は 1980 年 1 月に RFC 761 として標準化されました。

2004年、ヴィント・サーフとボブ・カーンはTCP/IPの基礎研究によりチューリング賞を受賞した。 [ 13 ] [ 14 ]

ネットワーク機能

伝送制御プロトコル（TCP）は、アプリケーションプログラムとインターネットプロトコル（IP）間の中間レベルで通信サービスを提供します。インターネットモデルのトランスポート層において、ホスト間接続を提供します。アプリケーションは、リンクを介して別のホストにデータを送信するための特定のメカニズム（例えば、伝送媒体の最大伝送単位に対応するために必要なIPフラグメンテーションなど）を意識する必要はありません。トランスポート層では、TCPがすべてのハンドシェイクと伝送の詳細を処理し、通常はネットワークソケットインターフェースを介してネットワーク接続の抽象化をアプリケーションに提供します。

プロトコルスタックの下位レベルでは、ネットワークの輻輳、トラフィックの負荷分散、あるいは予測不可能なネットワーク動作などにより、IPパケットが失われたり、重複したり、順序通りに配信されなかったりすることがあります。TCPはこれらの問題を検出し、失われたデータの再送を要求し、順序が乱れたデータを並べ替え、さらにはネットワークの輻輳を最小限に抑えて他の問題の発生を抑えます。それでもデータが配信されない場合、送信元にこの失敗が通知されます。TCP受信側は、最初に送信されたオクテットのシーケンスを再構成し、それを受信側アプリケーションに渡します。このように、TCPはアプリケーションの通信を、基盤となるネットワークの詳細から 抽象化します。

TCPは、タイムリーな配信よりも正確な配信に最適化されており、順序が乱れたメッセージや失われたメッセージの再送を待つ間に、比較的長い遅延（数秒単位）が発生する可能性があります。そのため、Voice over IPなどのリアルタイムアプリケーションには特に適していません。このようなアプリケーションでは、通常、ユーザーデータグラムプロトコル（UDP）上で動作するリアルタイムトランスポートプロトコル（RTP）などのプロトコルが推奨されます。 [ 15 ]

TCPは、受信したすべてのバイトが送信したバイトと同じ順序で、かつ同一であることを保証する信頼性の高いバイトストリーム配信サービスです。多くのネットワークにおけるパケット転送は信頼性が低いため、TCPは再送を伴う肯定確認応答と呼ばれる技術を用いてこれを実現します。この技術では、受信側はデータを受信すると確認応答メッセージで応答する必要があります。送信側は送信した各パケットの記録を保持し、パケット送信時のタイマーを維持します。確認応答を受信する前にタイマーが切れた場合、送信側はパケットを再送信します。このタイマーは、パケットが失われたり破損したりした場合に備えて必要です。[ 15 ]

IP が実際のデータ配信を処理する一方で、TCP はセグメントを管理します。セグメントとは、ネットワークを効率的にルーティングするためにメッセージを分割したデータ転送の個々の単位です。たとえば、Web サーバーから HTML ファイルが送信されると、そのサーバーの TCP ソフトウェア層はファイルをセグメントに分割し、ネットワーク スタックのインターネット層に個別に転送します。インターネット層ソフトウェアは、送信先IP アドレス(およびその他のデータ) を含むヘッダーを追加することで、各 TCP セグメントを IP パケットにカプセル化します。送信先コンピューターのクライアント プログラムがそれを受信すると、トランスポート層の TCP ソフトウェアがセグメントを再構成し、ファイルの内容を受信側アプリケーションにストリーミングする際に、セグメントが正しく順序付けられ、エラーがないことを確認します。

TCPセグメント構造

伝送制御プロトコル（TCP）は、データストリームからデータを受け取り、それをチャンクに分割し、TCPヘッダーを追加してTCPセグメントを作成します。TCPセグメントはその後、インターネットプロトコル（IP）データグラムにカプセル化され、ピア間で交換されます。[ 16 ]

TCPパケットという用語は、非公式および公式の両方の用法で使用されていますが、より正確な用語では、セグメントはTCPプロトコルデータユニット（PDU）、データグラム[ 17 ]はIP PDU、フレームはデータリンク層PDU を指します。

プロセスはTCPを呼び出し、データバッファを引数として渡すことでデータを送信します。TCPはこれらのバッファからのデータをセグメントに分割し、インターネットモジュール（例：IP）を呼び出して各セグメントを宛先TCPに送信します。[ 18 ]

TCPセグメントは、セグメントヘッダーとデータセクションから構成されます。セグメントヘッダーには、10個の必須フィールドと、オプションの拡張フィールド（オプション、表の背景色が砂色）が含まれます。データセクションはヘッダーに続き、アプリケーションのために伝送されるペイロードデータです。[ 19 ]データセクションの長さはセグメントヘッダーでは指定されません。IPヘッダーで指定されるIPデータグラムの総長から、セグメントヘッダーとIPヘッダーの合計長を差し引くことで計算できます。

TCPヘッダーフォーマット[ 19 ]
オフセットオクテット0 1 2 3
オクテット 少し0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 送信元ポート宛先ポート
4 32 シーケンス番号
8 64 確認応答番号（ACKビットがセットされている場合に意味を持つ）
12 96 データオフセット予約済みCWR欧州経済委員会うわさ話確認PSHRSTシンフィンウィンドウ
16 128 チェックサム緊急ポインタ（URGビットがセットされているときに意味を持つ）[ 20 ]
20 160 (オプション) 存在する場合、データ オフセットは 5 より大きくなります。データ オフセットは 4 オクテットのワードをカウントするため、32 ビットの倍数になるようにゼロが埋め込まれます。
⋮ ⋮
56 448
60 480 データ
64 512
⋮ ⋮
送信元ポート: 16ビット
送信ポートを識別します。
宛先ポート: 16ビット
受信ポートを識別します。
シーケンス番号: 32ビット
2つの役割があります:
  • SYNフラグがセットされている場合（1）、これが初期シーケンス番号となります。実際の最初のデータバイトのシーケンス番号と、対応するACKで確認応答された番号は、このシーケンス番号に1を加えたものになります。
  • SYN フラグが設定されていない場合 (0)、これは現在のセッションのこのセグメントの最初のデータ バイトの累積シーケンス番号です。
確認応答番号: 32ビット
ACKフラグが設定されている場合、このフィールドの値はACKの送信者が期待する次のシーケンス番号です。これは、それ以前のすべてのバイト（もしあれば）の受信を承認するものです。[ 21 ]それぞれの端末から送信される最初のACKは、相手側の最初のシーケンス番号自体を承認しますが、データは送信しません。[ 22 ]
データオフセット （DOffset）：4ビット
TCPヘッダーのサイズを32ビットワード単位で指定します。ヘッダーの最小サイズは5ワード、最大サイズは15ワードです。つまり、最小サイズは20バイト、最大サイズは60バイトとなり、ヘッダーには最大40バイトのオプションを含めることができます。このフィールドの名前は、TCPセグメントの先頭から実際のデータまでのオフセットでもあることから付けられています。
予約済み （Rsrvd）: 4ビット
将来使用するために、ゼロに設定する必要があります。追加の仕様と実装がない場合は、送信者はこれらを設定してはならず、受信側は設定されていても無視する必要があります。
2003年から2017年にかけて、最後のビット（ヘッダーのビット103）は、実験的なRFC 3540（ECN-nonce）によってNS（Nonce Sum）フラグとして定義されました。ECN-nonceは広く使用されることはなく、RFCは歴史的ステータスに移行しました。[ 23 ]
RFCドラフト[ 24 ]では、このビットの新しい用途が提案されています。現在、このビットはAccurate ECNの使用をネゴシエートするために使用されます。
フラグ: 8ビット
以下のように8つの1ビットフラグ（制御ビット）が含まれます。tcpdump を使用する場合、設定されたフラグは括弧内の文字で示されます。
CWR  （W）：1ビット
輻輳ウィンドウ縮小（CWR）フラグは送信ホストによって設定され、ECEフラグが設定されたTCPセグメントを受信し、輻輳制御メカニズムで応答したことを示します。[ 25 ] [ a ]
ECE  （E）：1ビット
ECN-Echoは、SYNフラグの値に応じて2つの役割を果たします。これは以下のことを示します。
  • SYNフラグが設定されている場合（1）、TCPピアはECNに対応しています。[ 26 ]
  • SYNフラグが設定されていない場合（0）、IPヘッダーに輻輳経験フラグが設定されている（ECN=11）パケットが通常の送信中に受信された。[ a ]これは、TCP送信者にネットワーク輻輳（または差し迫った輻輳）の兆候を示す。[ 27 ]
URG  (U): 1ビット
緊急ポインタ フィールドが重要であることを示します。
ACK  (.): 1ビット
確認応答フィールドが重要であることを示します。クライアントが送信した最初のSYNパケット以降のすべてのパケットには、このフラグがセットされている必要があります。[ 28 ]
PSH  (P): 1ビット
プッシュ機能。バッファリングされたデータを受信側アプリケーションにプッシュするよう要求します。
RST  (R): 1ビット
接続をリセットする
SYN  （S）：1ビット
シーケンス番号を同期します。このフラグは、各端末から送信される最初のパケットにのみ設定する必要があります。他のフラグやフィールドは、このフラグに基づいて意味が変わります。フラグが設定されている場合にのみ有効なものもあれば、フラグがクリアされている場合にのみ有効なものもあります。
FIN  (F): 1ビット
送信者からの最後のパケット
ウィンドウ: 16ビット
受信ウィンドウのサイズ。これは、このセグメントの送信者が現在受信を希望しているウィンドウサイズ単位[ b ]の数を指定します。 [ c ]（§ フロー制御と§ ウィンドウスケーリングを参照してください。）
チェックサム：16ビット
16ビットのチェックサムフィールドは、TCPヘッダー、ペイロード、およびIP擬似ヘッダーのエラーチェックに使用されます。擬似ヘッダーは、送信元IPアドレス、宛先IPアドレス、 TCPプロトコルのプロトコル番号（6）、およびTCPヘッダーとペイロードの長さ（バイト単位）で構成されます。
緊急ポインタ: 16ビット
URG フラグが設定されている場合、この 16 ビット フィールドは、最後の緊急データ バイトを示すシーケンス番号からのオフセットです。
オプション (TCP オプション): 可変 0 ～ 320 ビット (32 ビット単位)。size(Options) == (DOffset - 5) * 32
このフィールドの長さはデータオフセットフィールドによって決定されます。TCPヘッダーパディングは、TCPヘッダーが32ビット境界で終了し、データが始まることを保証するために使用されます。パディングはゼロで構成されます。[ 18 ]
オプションには、オプション種別（1 バイト）、オプション長（1 バイト）、オプション データ（可変）の最大 3 つのフィールドがあります。オプション種別フィールドはオプションの種類を示し、オプションでない唯一のフィールドです。オプション種別値に応じて、次の 2 つのフィールドが設定されます。オプション長はオプションの合計長を示し、オプション データには、該当する場合、オプションに関連付けられたデータが含まれます。たとえば、オプション種別バイトが 1 の場合、これはパディングのみに使用される無操作オプションであり、その後にオプション長またはオプション データ フィールドが続かないことを示します。オプション種別バイトが 0 の場合、オプションの終了を示し、これも 1 バイトのみです。オプション種別バイトが 2 の場合、最大セグメント サイズ オプションを示すために使用され、その後に MSS フィールドの長さを指定するオプション長バイトが続きます。オプション長は、オプション種別フィールドとオプション長フィールドを含む、指定されたオプションフィールドの全長です。したがって、MSS値は通常2バイトで表現されますが、オプション長は4バイトになります。例えば、値0x05B4を持つMSSオプションフィールドは、 TCPオプションセクションでは( 0x02 0x04 0x05B4 )とコード化されます。
一部のオプションは、SYN が設定されている場合にのみ送信されます[SYN]。これらは、以下に Option-Kind として示され、標準の長さは (Option-Kind, Option-Length) として示されます。
オプションの種類 オプションの長さ オプションデータ 目的 注記
0 該当なし該当なしオプションリストの終了
1 該当なし該当なし操作なし これを使用すると、オプション フィールドを 32 ビット境界に揃えてパフォーマンスを向上できます。
2 4 SS 最大セグメントサイズ 詳細については、§ 最大セグメント サイズを参照してください。[SYN]
3 3 S ウィンドウスケール 詳細については、 §ウィンドウスケーリングを参照してください。[ 29 ][SYN]
4 2 該当なし選択的確認応答が許可される 詳細については§選択的謝辞を参照。 [ 30 ][SYN]
5 N（10、18、26、または34） BBBB、EEEE、… 選択的確認応答（SACK）[ 31 ]最初の 2 バイトの後に、選択的に確認される 1 ～ 4 個のブロックのリストが続き、32 ビットの開始/終了ポインタとして指定されます。
8 10 TTTT、EEEE タイムスタンプと前のタイムスタンプのエコー 詳細については、 §TCPタイムスタンプを参照してください。[ 29 ]
28 4 該当なしユーザータイムアウトオプション RFC  5482を参照してください。
29 北 該当なしTCP 認証オプション (TCP-AO) メッセージ認証については、もともとBGPセッションを保護するために設計されたMD5認証（オプション19）を置き換えます。[ 32 ] RFC  5925を参照してください。
30 北 該当なしマルチパスTCP (MPTCP) 詳細については、マルチパス TCP を参照してください。
残りのオプション種別値は、歴史的、廃止、実験的、まだ標準化されていない、または未割り当てです。オプション番号の割り当ては、インターネット割り当て番号局（IANA）によって管理されています。[ 33 ]
データ: 変数
TCPパケットのペイロード

プロトコル操作

簡略化されたTCP状態図

TCPプロトコルの動作は3つのフェーズに分けられます。接続確立は、データ転送フェーズに入る前に接続を確立する、複数段階のハンドシェイクプロセスです。データ転送が完了すると、接続終了によって接続が閉じられ、割り当てられたすべてのリソースが解放されます。

TCP接続は、通信のローカルエンドポイントを表すリソースであるインターネットソケットを介してオペレーティングシステムによって管理されます。TCP接続の存続期間中、ローカルエンドポイントは一連の状態変化を経験します。[ 34 ]

TCPソケットの状態
州 終点 説明
聞く サーバ 任意のリモート TCP エンドポイントからの接続要求を待機しています。
シンセント クライアント 接続要求を送信した後、一致する接続要求を待機しています。
SYN受信 サーバ 接続要求の受信と送信が完了したら、接続要求の確認応答を待機します。
設立 サーバーとクライアント 接続がオープン状態です。受信したデータはユーザーに配信できます。接続のデータ転送フェーズにおける通常の状態です。
フィンウェイト1 サーバーとクライアント リモート TCP からの接続終了要求、または以前に送信された接続終了要求の確認応答を待機しています。
フィンウェイト2 サーバーとクライアント リモート TCP からの接続終了要求を待機しています。
クローズ-待機 サーバーとクライアント ローカル ユーザーからの接続終了要求を待機しています。
終わりに サーバーとクライアント リモート TCP からの接続終了要求の確認応答を待機しています。
ラストACK サーバーとクライアント 以前にリモート TCP に送信された接続終了要求の確認応答 (その接続終了要求の確認応答を含む) を待機しています。
時間待ち サーバーまたはクライアント 接続上の残りのパケットの有効期限が切れたことを確認するために、十分な時間が経過するまで待機します。
閉店 サーバーとクライアント まったく接続状態がありません。

接続の確立

クライアントがサーバーに接続しようとする前に、サーバーはまずポートをバインドしてリッスンし、接続を待機する必要があります。これはパッシブオープンと呼ばれます。パッシブオープンが確立されると、クライアントは3ウェイ（または3ステップ）ハンドシェイクを使用してアクティブオープンを開始することで接続を確立できます。

  1. SYN : アクティブオープンは、クライアントがサーバーにSYNを送信することで実行されます。クライアントはセグメントのシーケンス番号をランダムな値Aに設定します。
  2. SYN-ACK : サーバーはSYN-ACKで応答します。確認応答番号は受信したシーケンス番号より1つ大きい値（A+1）に設定され、サーバーがパケットに選択するシーケンス番号は別の乱数（B）となります。
  3. ACK : 最後に、クライアントはサーバーにACKを返します。シーケンス番号は受信した確認応答値（A+1）に設定され、確認応答番号は受信したシーケンス番号より1大きい値（B+1）に設定されます。

ステップ1と2では、一方向（クライアントからサーバー）のシーケンス番号を確立し、確認応答します。ステップ2と3では、他方向（サーバーからクライアント）のシーケンス番号を確立し、確認応答します。これらのステップが完了すると、クライアントとサーバーの両方が確認応答を受信し、全二重通信が確立されます。

接続終了

接続終了
詳細なTCP close()シーケンス図

接続終了フェーズでは4ウェイハンドシェイクが用いられ、接続の各側は独立して終了します。一方のエンドポイントが接続の片側を停止する場合、FINパケットを送信し、もう一方のエンドポイントはACKで確認応答します。したがって、典型的な切断では、各TCPエンドポイントからFINセグメントとACKセグメントのペアが必要です。最初のFINを送信した側が最後のACKで応答した後、タイムアウトを待ってから最終的に接続を閉じます。タイムアウト中は、ローカルポートは新規接続に利用できません。この状態では、TCPクライアントはACKが転送中に失われた場合に備えて、最終確認応答をサーバーに再送信できます。タイムアウト時間は実装に依存しますが、一般的な値は30秒​​、1分、2分です。タイムアウト後、クライアントはCLOSED状態に入り、ローカルポートは新規接続に利用できるようになります。[ 35 ]

3ウェイハンドシェイクによって接続を終了することも可能であり、ホストAがFINを送信し、ホストBがFINとACK（2つのステップを1つにまとめたもの）で応答し、ホストAがACKで応答する。[ 36 ]

Linux [ 37 ]などの一部のオペレーティングシステムは、半二重のクローズシーケンスを実装しています。ホストが未読の受信データがまだ残っている状態で接続をアクティブに閉じる場合、ホストはFINではなくRST信号（受信データは失われます）を送信します。これにより、TCPアプリケーションはデータ損失があったことを認識できます。[ 38 ]

接続は半オープン状態になることがあります。これは、片側が接続を終了しているが、もう片側がまだ終了していない状態です。終了した側は接続にデータを送信できなくなりますが、もう片側は送信できます。終了側は、もう片側も終了するまでデータの読み取りを継続する必要があります。[ 39 ] [ 40 ]

リソースの使用

ほとんどの実装では、セッションと実行中のオペレーティングシステムプロセスをマッピングするテーブルにエントリを割り当てます。TCPパケットにはセッション識別子が含まれていないため、両方のエンドポイントはクライアントのアドレスとポートを使用してセッションを識別します。パケットを受信するたびに、TCP実装はこのテーブルを参照して宛先プロセスを見つける必要があります。テーブルの各エントリは、伝送制御ブロック（TCB）と呼ばれます。TCBには、エンドポイント（IPとポート）、接続の状態、交換されるパケットに関する実行データ、およびデータの送受信用のバッファに関する情報が含まれています。

サーバー側のセッション数はメモリによってのみ制限され、新しい接続が到着するにつれて増加しますが、クライアントはサーバーに最初のSYNを送信する前に、一時的なポートを割り当てる必要があります。このポートは通信中ずっと割り当てられたままであり、各クライアントのIPアドレスからの送信接続数を効果的に制限します。アプリケーションが不要な接続を適切に閉じることができない場合、クライアントはリソース不足に陥り、他のアプリケーションからのTCP接続も含めて、新しい接続を確立できなくなる可能性があります。

両方のエンドポイントは、未確認パケットと受信済み（ただし未読）データ用のスペースも割り当てる必要があります。

データ転送

伝送制御プロトコルは、ユーザー データグラム プロトコルと比較して、いくつかの重要な機能が異なります。

  • 順序付きデータ転送：宛先ホストはシーケンス番号に従ってセグメントを並べ替える[ 15 ]
  • 失われたパケットの再送：確認応答されなかった累積ストリームは再送される[ 15 ]
  • エラーのないデータ転送：破損したパケットは失われたものとして扱われ、再送信される[ 16 ]
  • フロー制御：送信側のデータ転送速度を制限し、信頼性の高い配信を保証する。受信側は送信側に受信可能なデータ量を継続的に通知する。受信側ホストのバッファがいっぱいになると、次の確認応答で転送が一時停止され、バッファ内のデータの処理が開始される。[ 15 ]
  • 輻輳制御：パケット損失（輻輳によるものと推定）によりデータ配信速度が低下する[ 15 ]

信頼性の高い伝送

TCPは、データの各バイトを識別するためにシーケンス番号を使用します。シーケンス番号は、各コンピュータから送信されたバイトの順序を識別するため、順序が乱れた配信が発生しても、データを正しい順序で再構成することができます。最初のバイトのシーケンス番号は、最初のパケット（SYNフラグ付き）の送信側によって選択されます。この番号は任意に設定できますが、 TCPシーケンス予測攻撃を防ぐには、実際には予測不可能である必要があります。

確認応答（ACK）は、データの受信側から送信側に指定されたバイトまでのデータが受信されたことを通知するために、シーケンス番号とともに送信されます。ACKは、データがアプリケーションに配信されたことを意味するのではなく、受信側がデータの配信責任を負うようになったことを示すだけです。

信頼性は、送信側が失われたデータを検出し、再送信することで実現されます。TCPは、損失を特定するために主に2つの手法を使用します。再送信タイムアウト（RTO）と重複累積確認応答（DupAcks）です。

TCPセグメントが再送されると、元の配信試行と同じシーケンス番号が保持されます。配信順序と論理的なデータ順序の混同により、再送後に確認応答を受信した場合、送信者は元の送信に対する確認応答なのか再送に対する確認応答なのかを判断できなくなります。これはいわゆる再送の曖昧性です。[ 41 ] TCPは再送の曖昧性によって複雑さを招きます。[ 42 ]

重複ACKベースの再送信

ストリーム内の単一のセグメント（セグメント番号 100 とします）が失われた場合、受信側は累積 ACK を使用するため、そのセグメント番号 (100) を超えるパケットを確認できません。そのため、受信側は別のデータ パケットを受信すると、パケット 99 を再度確認します。この重複した確認応答は、パケット損失の信号として使用されます。つまり、送信側が重複した確認応答を 3 つ受信した場合、最後の未確認パケットを再送信します。ネットワークがセグメントの順序を入れ替えて重複した確認応答を引き起こす可能性があるため、しきい値を 3 に設定します。このしきい値により、順序入れ替えによる不要な再送信を回避できることが実証されています。[ 43 ]一部の TCP 実装では、選択的確認応答(SACK) を使用して、受信したセグメントに関する明示的なフィードバックを提供します。これにより、TCP が正しいセグメントを再送信する能力が大幅に向上します。

重複確認応答しきい値を超える順序変更がある場合、再送の曖昧さにより、誤った高速再送や輻輳回避が発生する可能性があります。[ 44 ]過去20年間で、インターネット上でパケットの順序変更がより多く観測されており[ 45 ]、LinuxカーネルなどのTCP実装では、重複確認応答しきい値を調整するためのヒューリスティックな方法を採用しています。[ 46 ]最近では、重複ACKベースの高速再送を完全に廃止し、タイマーベースのものに置き換える取り組みが行われています。[ 47 ] （以下で説明する従来のRTOと混同しないでください）。Recent Acknowledgment（RACK） [ 48 ]と呼ばれる時間ベースの損失検出アルゴリズムは、LinuxとWindowsのデフォルトのアルゴリズムとして採用されています。[ 49 ]

タイムアウトベースの再送信

送信者はセグメントを送信する際、確認応答の到着時刻を控えめに見積もったタイマーを初期化する。タイマーが満了すると、セグメントは再送され、新しいタイムアウトしきい値は以前の値の2倍に設定され、指数関数的なバックオフ動作となる。通常、タイマーの初期値は平滑化されたRTT + max( G , 4 × RTT変動)であり、Gはクロック粒度である。[ 50 ]これは、中間者攻撃（DoS）などの欠陥のある、あるいは悪意のある攻撃者による過剰な送信トラフィックを防ぐ。

正確な RTT 推定は損失回復に重要であり、送信者は十分な時間が経過した後 (つまり、RTO 時間を決定した後)、確認応答のないパケットは失われたと想定できるためです。[ 51 ]再送のあいまいさにより、送信者の RTT 推定が不正確になる可能性があります。[ 51 ] RTT が可変の環境では、誤ったタイムアウトが発生する可能性があります。[ 52 ] RTT が過小評価されている場合、RTO が起動し、不要な再送とスロースタートがトリガーされます。誤った再送の後、元の送信の確認応答が到着すると、送信者はそれが再送を確認したと信じ、元の送信と再送の間に送信されたセグメントが失われたと誤って結論付け、リンクが実際に輻輳するほどの不要な再送を引き起こします。[ 53 ] [ 54 ]選択的確認応答により、この影響を軽減できます。[ 55 ] RFC 6298では、実装はRTTを推定する際に再送セグメントを使用してはならないと規定されている。[ 56 ] Karnのアルゴリズムは、 RTOを調整する前に明確な確認応答があるまで待つことで、最終的に良好なRTT推定値が生成されることを保証する。[ 57 ]しかし、誤った再送の後には、そのような明確な確認応答が到着するまでにかなりの時間がかかり、その間パフォーマンスが低下する可能性がある。[ 58 ] TCPタイムスタンプもRTOの設定における再送の曖昧性の問題を解決しますが、[ 56 ]必ずしもRTT推定値を改善するわけではありません。[ 59 ]

エラー検出

シーケンス番号により、受信側は重複したパケットを破棄し、順序が乱れたパケットを適切な順序に並べることができます。確認応答により、送信側は失われたパケットをいつ再送信するかを判断できます。

正確性を保証するためにチェックサムフィールドが含まれています。詳細は「チェックサムの計算」を参照してください。TCPチェックサムは現代の標準では弱いチェックであり、通常はTCPとIPの両方の下層である第2層でCRC整合性チェックと組み合わせて使用​​されます。これはPPPやイーサネットフレームで使用されています。しかし、CRCで保護されたホップ間でパケットにエラーが発生することはよくあり、16ビットのTCPチェックサムはこれらのエラーのほとんどを検出します。[ 60 ]

フロー制御

TCPは、送信側がTCP受信側で確実に受信・処理できないほど高速にデータを送信することを避けるために、エンドツーエンドのフロー制御プロトコルを使用します。フロー制御のメカニズムは、ネットワーク速度の異なるマシンが通信する環境では不可欠です。例えば、PCが受信データの処理速度が遅いスマートフォンにデータを送信する場合、スマートフォンは過負荷にならないようにデータフローを調整する必要があります。[ 15 ]

TCPはスライディングウィンドウフロー制御プロトコルを使用します。各TCPセグメントにおいて、受信側は受信ウィンドウフィールドに、接続中にバッファリング可能な追加受信データ量（バイト単位）を指定します。送信側ホストは、受信側ホストからの確認応答と受信ウィンドウの更新を待つ前に、指定されたデータ量までしか送信できません。

TCPシーケンス番号と受信ウィンドウは、時計のように動作します。受信ウィンドウは、受信側が新しいデータセグメントを受信し、確認応答するたびに変化します。シーケンス番号がなくなると、シーケンス番号は0に戻ります。

受信側がウィンドウサイズ0をアドバタイズすると、送信側はデータの送信を停止し、持続タイマーを開始します。持続タイマーは、受信側からの後続のウィンドウサイズ更新が失われ、送信側が受信側から新しいウィンドウサイズ更新を受信するまでデータを送信できない場合に発生する可能性のあるデッドロック状態からTCPを保護するために使用されます。持続タイマーが期限切れになると、TCP送信側は小さなパケットを送信することで回復を試みます。受信側は、新しいウィンドウサイズを含む別の確認応答を送信することで応答します。

受信側が受信データを少しずつ処理している場合、小さな受信ウィンドウを繰り返し通知することがあります。これは「シリーウィンドウ症候群」と呼ばれます。TCPヘッダーのオーバーヘッドが比較的大きいことを考えると、TCPセグメントで数バイトのデータだけを送信するのは非効率的だからです。

輻輳制御

TCPの最後の主要な側面は輻輳制御です。TCPは、高いパフォーマンスを実現し、輻輳崩壊（ネットワークパフォーマンスが著しく低下するグリッドロック状態）を回避するために、いくつかのメカニズムを採用しています。これらのメカニズムは、ネットワークに入るデータの速度を制御し、データフローを崩壊を引き起こす速度以下に抑えます。また、フロー間の割り当てを ほぼ最大最小公平なものにします。

送信側は、送信データに対する確認応答、あるいは確認応答がないことを手がかりに、TCPの送信側と受信側間のネットワーク状況を推測します。タイマーと組み合わせることで、TCPの送信側と受信側はデータフローの動作を変更できます。これは一般的に輻輳制御または輻輳回避と呼ばれます。

現代のTCPの実装には、スロースタート、輻輳回避、高速再送、高速回復という4つの相互に関連したアルゴリズムが含まれています。[ 61 ]

さらに、送信者は、送信者と受信者の間の推定往復時間(RTT) と、この往復時間の変動に基づいた再送タイムアウト(RTO) を採用している。 [ 62 ] RTT の推定には微妙な点がある。例えば、送信者は再送パケットの RTT サンプルを計算する際には注意が必要である。通常、送信者はKarn のアルゴリズムまたは TCP タイムスタンプを使用する。[ 29 ]これらの個々の RTT サンプルはその後、時間の経過に沿って平均化され、 Jacobson のアルゴリズムを使用して平滑化された往復時間 (SRTT) が作成される。この SRTT 値が往復時間の推定値として使用される。

TCPの強化により、損失を確実に処理し、エラーを最小限に抑え、輻輳を管理し、超高速環境での高速化を実現することは、現在も研究と標準化が進められている分野です。その結果、TCP輻輳回避アルゴリズムには様々なバリエーションが存在します。

最大セグメントサイズ

最大セグメント サイズ(MSS) は、TCP が 1 つのセグメントで受信するデータの最大量 (バイト単位) です。最高のパフォーマンスを得るには、パケット損失や過度の再送につながるIP フラグメンテーションを回避できる程度に MSS を小さく設定する必要があります。これを実現するために、通常 MSS は TCP 接続の確立時に MSS オプションを使用して各側から通知されます。オプションの値は、送信側と受信側が直接接続されているネットワークのデータ リンク層の最大転送単位(MTU) サイズから導出されます。TCP の送信側は、パス MTU 検出を使用して送信側と受信側の間のネットワーク パスに沿った最小 MTU を推測し、それを使用して MSS を動的に調整してネットワーク内の IP フラグメンテーションを回避できます。

MSSアナウンスはMSSネゴシエーションとも呼ばれますが、厳密に言えばMSSはネゴシエートされません。TCP接続では、双方向のデータフローに対して、完全に独立した2つのMSS値が許可されるため、[ 63 ] [ 18 ]、双方向接続において共通のMSS設定について合意する必要はありません。

選択的謝辞

オリジナルのTCPで採用されていた累積確認応答方式のみに依存すると、パケットが失われた際に非効率になる可能性があります。例えば、シーケンス番号1,000から10,999までのバイトが、同じサイズの10個の異なるTCPセグメントで送信され、2番目のセグメント（シーケンス番号2,000から2,999）が伝送中に失われたとします。純粋な累積確認応答プロトコルでは、受信側は累積ACK値として2,000（受信データの最後のシーケンス番号の直後のシーケンス番号）しか送信できず、3,000から10,999までのバイトを正常に受信したと判断できません。そのため、送信側はシーケンス番号2,000から始まるすべてのデータを再送しなければならない可能性があります。

この問題を緩和するために、TCP はRFC 2018で 1996 年に定義された選択的確認応答 (SACK)オプションを採用しています。これにより、受信側は、基本的な TCP 確認応答と同様に、連続して受信した最後の連続バイトの最後のシーケンス番号の直後のシーケンス番号に加えて、正しく受信した不連続なパケット ブロックを確認することができます。確認応答には複数のSACK ブロックを含めることができ、各 SACK ブロックはブロックの左端(ブロックの最初のシーケンス番号) とブロックの右端(ブロックの最後のシーケンス番号の直後のシーケンス番号) によって伝達され、ブロックは受信側が正しく受信した連続した範囲です。上記の例では、受信側は累積 ACK 値が 2,000 の ACK セグメントと、シーケンス番号 3,000 と 11,000 の SACK オプション ヘッダーを送信します。したがって、送信者は、シーケンス番号が 2,000 から 2,999 の 2 番目のセグメントのみを再送信します。

TCP送信側は、順序が乱れたセグメントの配信を損失セグメントと解釈することがあります。その場合、TCP送信側は順序が乱れたパケットの前のセグメントを再送信し、その接続におけるデータ配信速度を低下させます。この問題は、2000年5月にRFC 2883で定義されたSACKオプションの拡張である重複SACKオプションによって解決されます。TCP受信側が2つ目の重複パケットを検出すると、セグメントが損失していないことを示すD-ACKを送信し、TCP送信側はより高い伝送速度を回復できます。

SACKオプションは必須ではなく、双方がサポートしている場合にのみ機能します。これは接続確立時にネゴシエートされます。SACKはTCPヘッダーオプションを使用します（詳細は「TCPセグメント構造」を参照）。SACKの使用は広く普及しており、主要なTCPスタックはすべてSACKをサポートしています。選択的確認応答は、ストリーム制御伝送プロトコル（SCTP）でも使用されます。

選択的確認応答は「破棄」される可能性があり、この場合、受信者は選択的に確認応答されたデータを一方的に破棄します。RFC 2018ではこのような動作は推奨されていませんが、例えばバッファスペースが不足した場合などに受信者が破棄するオプションを許可するため、これを禁止していませんでした。[ 64 ]破棄の可能性は、送信者と受信者の両方にとって実装の複雑さにつながり、送信者にメモリコストを課します。[ 65 ]

ウィンドウのスケーリング

高帯域幅ネットワークをより効率的に利用するために、より大きなTCPウィンドウサイズを使用できます。16ビットのTCPウィンドウサイズフィールドはデータフローを制御し、その値は65,535バイトに制限されています。サイズフィールドはこの制限を超えて拡張できないため、スケーリング係数が使用されます。RFC 1323で定義されているTCPウィンドウスケールオプションは、最大ウィンドウサイズを1ギガバイトに拡張するために使用されるオプションです。TCPチューニングには、このような大きなウィンドウサイズへのスケーリングが必要です。

ウィンドウスケールオプションは、TCP 3ウェイハンドシェイク中にのみ使用されます。ウィンドウスケール値は、16ビットのウィンドウサイズフィールドを解釈する際に左シフトするビット数を表します。ウィンドウスケール値は、各方向ごとに独立して0（シフトなし）から14まで設定できます。どちらの方向でもウィンドウスケールを有効にするには、両側ともSYNセグメントでこのオプションを送信する必要があります。

一部のルーターやパケットファイアウォールは、送信中にウィンドウスケーリング係数を書き換えます。これにより、送信側と受信側で異なるTCPウィンドウサイズが想定されます。その結果、トラフィックが不安定になり、非常に遅くなる可能性があります。この問題は、故障したルーターの背後にある一部のサイトで確認されています。[ 66 ]

TCPタイムスタンプ

1992年にRFC 1323で定義されたTCPタイムスタンプは、TCPがパケットの送信順序を判断するのに役立ちます。TCPタイムスタンプは通常、システムクロックに同期されておらず、ランダムな値から始まります。多くのオペレーティングシステムは、経過ミリ秒ごとにタイムスタンプを増分しますが、RFCでは、刻みは秒数に比例するべきであるとのみ規定されています。

タイムスタンプ フィールドは 2 つあります。

  • 4バイトの送信者タイムスタンプ値（私のタイムスタンプ）
  • 4 バイトのエコー応答タイムスタンプ値 (ユーザーから受信した最新のタイムスタンプ)。

TCPタイムスタンプは、 Protection Against Wrapped Sequence Numbers（PAWS）と呼ばれるアルゴリズムで使用されます。PAWSは、受信ウィンドウがシーケンス番号のラップアラウンド境界を越えた場合に使用されます。パケットが再送された可能性がある場合、「このシーケンス番号は最初の4GBにあるか、それとも2番目の4GBにあるか」という問いに答え、タイムスタンプがその答えを決定します。

また、アイフェル検出アルゴリズムはTCPタイムスタンプを使用して、再送信がパケットの損失または順序の乱れによって発生しているかどうかを判断します。[ 67 ]

TCPタイムスタンプはLinuxではデフォルトで有効になっています[ 68 ]。Windows Server 2008、2012、2016ではデフォルトで無効になっています[ 69 ]。

最近の統計によると、Windows Server 2008以降Windows Serverがサポートを終了したため、TCPタイムスタンプの採用率は約40%で停滞しています。[ 70 ]

帯域外データ

キューに入れられたストリームの終了を待つ代わりに、ストリームを中断または中止することができます。これは、データを緊急として指定することで行われます。これにより、送信は帯域外データ（OOB）としてマークされ、受信側プログラムに直ちに処理するように指示されます。終了すると、TCPはアプリケーションに通知し、ストリームキューを再開します。例えば、TCPをリモートログインセッションに使用する場合、ユーザーはキーボードシーケンスを送信することで、リモートで実行中のプログラムが現在の転送を完了するのを待たずに、そのプログラムを中断または中止することができます。[ 15 ]

緊急ポインタはリモートホスト上の処理を変更するだけで、ネットワーク自体の処理を高速化することはありません。この機能はシステムによって実装が異なったり、不十分であったり、サポートされていない場合もあります。この機能が利用可能な場合でも、OOBデータの1バイトのみが確実に処理されると想定するのが賢明です。[ 71 ] [ 72 ]この機能は頻繁に使用されないため、一部のプラットフォームでは十分にテストされておらず、WinNukeなどの脆弱性と関連付けられています。

データ配信の強制

通常、TCP は完全なデータ パケットを送信するまで 200 ミリ秒待機します ( Nagle アルゴリズムは小さなメッセージを 1 つのパケットにグループ化しようとします)。この待機は、ファイル転送中に頻繁に繰り返されると、小さいながらも深刻な遅延を引き起こす可能性があります。たとえば、一般的な送信ブロックは 4 KB、一般的な MSS は 1460 であるため、10 Mbit/s イーサネットでは 2 つのパケットがそれぞれ約 1.2 ミリ秒かけて送信され、その後、TCP がバッファがいっぱいになるのを待つ 197 ミリ秒の一時停止の後に、残りの 1176 を運ぶ 3 番目のパケットが送信されます。telnet の場合、ユーザーがキー入力を行うたびに、それが画面に表示される前に、サーバーによってエコー バックされます。この遅延は非常に煩わしいものになります。

ソケットオプションを設定すると、TCP_NODELAYデフォルトの200ミリ秒の送信遅延が上書きされます。アプリケーションプログラムは、このソケットオプションを使用して、文字または文字列を書き込んだ後に出力を強制的に送信します。

RFC 793ではPSH、プッシュビットは「受信TCPスタックにこのデータを受信アプリケーションに直ちに送信するように指示するメッセージ」と定義されています。 [ 15 ]バークレーソケットを使用してユーザー空間でプッシュビットを指示または制御する方法はなく、プロトコルスタックによってのみ制御されます。[ 73 ]

脆弱性

TCPは様々な方法で攻撃を受ける可能性があります。TCPの徹底的なセキュリティ評価の結果と、特定された問題に対する可能な緩和策は2009年に公開され[ 74 ] 、 IETF内で2012年まで検討されました[ 75 ]。注目すべき脆弱性には、サービス拒否攻撃、接続ハイジャック、TCP拒否、TCPリセット攻撃などがあります。

サービス拒否

攻撃者は偽装IPアドレスを使用し、意図的に組み立てたSYNパケットとそれに続く多数のACKパケットを繰り返し送信することで、偽の接続を追跡するためにサーバーに大量のリソースを消費させることができます。これはSYNフラッド攻撃として知られています。この問題の解決策として提案されているものには、 SYNクッキーや暗号パズルなどがありますが、SYNクッキーには独自の脆弱性が存在します。[ 76 ] Sockstressも同様の攻撃であり、システムリソース管理によって軽減できる可能性があります。[ 77 ] TCP持続タイマーを悪用した高度なDoS攻撃は、Phrack No. 66で分析されています。[ 78 ] PUSHフラッドとACKフラッドは、他の亜種です。[ 79 ]

接続ハイジャック

TCPセッションを盗聴し、パケットをリダイレクトできる攻撃者は、TCP接続をハイジャックすることができます。攻撃者は、進行中の通信からシーケンス番号を取得し、ストリーム内の次のセグメントに見せかけた偽のセグメントを偽造します。単純なハイジャックでは、片方の端末で1つのパケットが誤って受け入れられる可能性があります。受信側ホストが偽のセグメントに確認応答すると、同期が失われます。[ 80 ]ハイジャックは、攻撃者がTCP接続を恒久的に制御することを可能にするARPスプーフィングやその他のルーティング攻撃と組み合わせられる可能性があります。

RFC 1948以前は、初期シーケンス番号が容易に推測可能だったため、別の IP アドレスを偽装することは難しくありませんでした。以前の実装では、攻撃者は ARP 攻撃やルーティング攻撃による通信傍受を必要とせず、受信者が別の IP アドレスから送信されたと信じるパケットシーケンスを盲目的に送信できました。偽装された IP アドレスの正当なホストがダウンしていることを確認するか、サービス拒否攻撃によってダウン状態に陥らせるだけで十分でした。そのため、初期シーケンス番号は現在ランダムに選択されています。

TCP拒否

次に送信するパケットの盗聴とサイズ予測が可能な攻撃者は、既存の接続を中断することなく、受信側に悪意のあるペイロードを受け入れさせることができます。攻撃者は、次に送信されると予想されるパケットのシーケンス番号とペイロードサイズを持つ悪意のあるパケットを挿入します。最終的に正当なパケットを受信すると、既に受信したパケットと同じシーケンス番号と長さであることが判明し、通常の重複パケットとして暗黙のうちに破棄されます。つまり、正当なパケットは悪意のあるパケットによって拒否されるのです。コネクションハイジャックとは異なり、接続が同期解除されることはなく、悪意のあるペイロードが受け入れられた後も通信は通常どおり継続されます。TCP拒否により、攻撃者は通信に対する制御力が低下しますが、攻撃の検出は特に困難になります。受信側が何か異常があるという唯一の証拠は、IPネットワークでは通常発生する単一の重複パケットです。拒否されたパケットの送信者は、攻撃の証拠を一切見ることができません。[ 81 ]

TCPポート

TCP接続は、送信元アドレス、送信元ポート、宛先アドレス、宛先ポートの4つの組によって識別されます。 [ d ] [ 82 ] [ 83 ]ポート番号は、異なるサービスを識別し、ホスト間の複数の接続を許可するために使用されます。[ 16 ] TCPは16ビットのポート番号を使用し、送信元ポートと宛先ポートのそれぞれに65,536の可能な値を提供します。[ 19 ]接続の識別がアドレスに依存するということは、TCP接続が単一のネットワークパスにバインドされていることを意味します。TCPは、マルチホームホストが利用できる他のルートを使用できず、エンドポイントのアドレスが変更されると接続が切断されます。[ 84 ]

ポート番号は、ウェルノウン、登録済み、および動的またはプライベートの 3 つの基本カテゴリに分類されます。ウェルノウン ポートは、Internet Assigned Numbers Authority (IANA) によって割り当てられ、通常、システム レベルのプロセスで使用されます。サーバーとして実行され、接続を受動的にリッスンする既知のアプリケーションは、通常、これらのポートを使用します。例としては、FTP (20 および 21)、SSH (22)、TELNET (23)、SMTP (25)、HTTP over SSL/TLS (443)、HTTP (80) などがあります。[ e ]登録済みポートは、通常、エンドユーザー アプリケーションがサーバーに接続するときに一時的なソース ポートとして使用されますが、サード パーティによって登録された名前付きサービスを識別することもできます。動的ポートまたはプライベート ポートもエンドユーザー アプリケーションで使用できますが、通常、これらのポートは特定の TCP 接続以外では意味を持ちません。

ネットワーク アドレス変換(NAT) は、通常、パブリック側で動的ポート番号を使用して、パブリック ネットワークとプライベートサブネット間を通過するトラフィックのフローを明確にし、サブネット上の多数の IP アドレス (およびそのポート) を 1 つのパブリック アドレスで処理できるようにします。

発達

TCPは複雑なプロトコルです。長年にわたり大幅な機能強化が行われ、提案されてきましたが、最も基本的な動作は、1974年の最初の仕様RFC 675 、および1981年9月に公開されたv4仕様RFC 793以来、大きく変わっていません。1989年10月に公開されたRFC 1122では、TCPプロトコルの実装要件がいくつか明確化されました。8つの必須仕様と20を超える強く推奨される機能強化のリストは、RFC 7414で参照できます。このリストに含まれるRFC 2581（TCP輻輳制御）は、近年の最も重要なTCP関連RFCの1つであり、過度の輻輳を回避する更新されたアルゴリズムについて説明しています。2001年には、輻輳回避シグナリングメカニズムである明示的輻輳通知（ECN）について説明するRFC 3168が執筆されました。

オリジナルの TCP 輻輳回避アルゴリズムはTCP Tahoeとして知られていましたが、その後多くの代替アルゴリズムが提案されてきました ( TCP Reno、TCP Vegas、FAST TCP、TCP New Reno、TCP Hyblaなど)。

マルチパスTCP（MPTCP）[ 85 ] [ 86 ]はIETFで現在も行われている取り組みで、TCP接続で複数のパスを使用することでリソース使用率を最大化し冗長性を高めることを目的としています。無線ネットワークにおいてマルチパスTCPが提供する冗長性により、異なるネットワークを同時に使用できるようになり、スループットの向上とハンドオーバー機能の向上がもたらされます。また、マルチパスTCPはデータセンター環境においてもパフォーマンス上の利点をもたらします。[ 87 ]マルチパスTCPのリファレンス実装[ 88 ]はLinuxカーネルで開発されました。[ 89 ]マルチパスTCPはiPhone、iPad、MacのSiri音声認識アプリケーションをサポートするために使用されています。[ 90 ]

tcpcryptは、2010年7月に提案された、TCP自体にトランスポートレベルの暗号化を直接提供する拡張です。透過的に動作し、設定を一切必要としないように設計されています。TLS（SSL）とは異なり、 tcpcrypt自体は認証を提供しませんが、アプリケーションが認証を行うためのシンプルなプリミティブを提供します。tcpcryptのRFCは、2019年5月にIETFによって公開されました。[ 91 ]

TCP Fast Openは、2つのエンドポイント間の連続したTCP接続の開始を高速化するための拡張機能です。暗号化Cookieを用いて3ウェイハンドシェイクを省略することで機能します。これは、セキュリティ上の問題から広く採用されなかったT/TCPと呼ばれる以前の提案に似ています。 [ 92 ] TCP Fast Openは2014年にRFC 7413として公開されました。 [ 93 ]

2013年5月に提案された比例レート削減（PRR）は、Googleのエンジニアによって開発されたTCP拡張機能です。PRRは、回復後のTCPウィンドウサイズがスロースタートしきい値に可能な限り近づくようにします。[ 94 ]このアルゴリズムは回復速度を向上させるように設計されており、Linux 3.2以降のカーネルではデフォルトの輻輳制御アルゴリズムとなっています。[ 95 ]

非推奨の提案

TCP Cookie Transactions（TCPCT）は、2009年12月に提案された拡張機能であり[ 96 ]、サービス拒否攻撃からサーバーを保護することを目的としています。SYN Cookieとは異なり、TCPCTはウィンドウスケーリングなどの他のTCP拡張機能と競合しません。TCPCTは、サーバーが多数の短命TCP接続を処理する必要があるDNSSECの必要性から設計されました。2016年、TCPCTはTCP Fast Openに取って代わられ、廃止されました。元のRFCのステータスは歴史的に変更されました。[ 97 ]

ハードウェア実装

TCPの処理能力要件を克服する一つの方法は、TCPオフロードエンジン（TOE）として広く知られるハードウェア実装を構築することです。TOEの主な問題は、コンピューティングシステムへの統合が難しく、コンピュータやデバイスのオペレーティングシステムに大幅な変更が必要になることです。

TCP低電力（TCPlp）は、UDPベースのCoAPが優先されるリソースが限られた環境で動作することが実証されています。[ 98 ] [ 99 ]

ワイヤー画像と骨化

TCP のワイヤデータは、プロトコル メタデータがクリアテキストで送信されるため、経路上の観察者に重要な情報収集および変更の機会を提供します。[ 100 ] [ 101 ]この透明性はネットワーク オペレータ[ 102 ]や研究者[ 103 ]には有用ですが、プロトコル メタデータから収集された情報によってエンド ユーザのプライバシーが低下する可能性があります。[ 104 ]メタデータのこの可視性と柔軟性により、TCP の拡張が困難になっています。これはプロトコルの骨化の一例であり、任意の中間ノード (「ミドルボックス」) がそのメタデータに基づいて決定を下したり、メタデータを変更したりできるため、[ 105 ] [ 106 ]エンドツーエンドの原則が破られています。[ 107 ]ある測定によると、インターネット上のパスの 3 分の 1 が TCP メタデータを変更する少なくとも 1 つの仲介者に遭遇し、パスの 6.5% が仲介者からの有害な骨化の影響を受けています。[ 108 ]中継者による拡張性ハザードを回避することはMPTCPの設計に大きな制約を課し、[ 109 ] [ 110 ]中継者によって生じる困難はウェブブラウザへの TCP Fast Open の導入を妨げてきた。[ 111 ]もう一つの骨化の原因は、エンドポイント、典型的にはオペレーティングシステムカーネル[ 112 ]またはTCP オフロードエンジンを備えたハードウェアにおけるTCP 機能の変更の難しさである。[ 113 ]

パフォーマンス

TCP は信頼性の高いバイト ストリームの抽象化をアプリケーションに提供するため、行頭ブロッキングの影響を受ける可能性があります。つまり、パケットの順序が変わったり失われたりして再送が必要になった場合 (つまり順序​​が変わった場合)、ストリームの後のほうのデータが、前のほうのデータの受信前に受信されることがあります。ただし、後のデータは通常、前のデータが受信されるまで使用できないため、ネットワーク レイテンシが発生します。複数の独立した上位レベルのメッセージがカプセル化され、単一の TCP 接続に多重化されている場合、行頭ブロッキングにより、後に送信され完全に受信されたメッセージの処理が、前に送信されたメッセージの配信を待つことになる可能性があります。[ 114 ] Web ブラウザは、複数の並列接続を開くことで行頭ブロッキングを軽減しようとします。これにより、接続を繰り返し確立するコストが発生するだけでなく、エンドポイントでそれらの接続を追跡するために必要なリソースも増加します。[ 115 ]並列接続では、情報をまとめて監視し、観測されたネットワーク状況に迅速に対応するのではなく、互いに独立して動作する輻輳制御も備えている。[ 116 ] TCPの積極的な初期送信パターンは、複数の並列接続が開かれた場合に輻輳を引き起こす可能性がある。また、接続ごとの公平性モデルは、このアプローチを採用するアプリケーションによるリソースの独占につながる。[ 117 ]

ウェブユーザーが経験する遅延の主な要因は、接続の確立である。[ 118 ] [ 119 ] TCP の 3 ウェイ ハンドシェイクでは、データを送信する前に接続を確立する際に 1 RTT の遅延が発生する。[ 119 ]フローが短い場合、これらの遅延は極めて重大である。[ 120 ]トランスポート層セキュリティ(TLS) では、接続確立時に鍵交換のために独自のハンドシェイクが必要である。階層化設計のため、TCP ハンドシェイクと TLS ハンドシェイクは順番に進行し、TCP ハンドシェイクが完了するまで TLS ハンドシェイクは開始できない。[ 121 ] TCP 経由のTLS 1.2で接続を確立するには 2 RTT が必要である。[ 122 ] TLS 1.3では、状況によってはゼロ RTT の接続再開が可能だが、TCP 上に階層化されている場合は、TCP ハンドシェイクに 1 RTT が必要であり、これでは初期接続を支援できない。ゼロRTTハンドシェイクは、効率的でリプレイセーフかつ前方セキュアな非対話型鍵交換が未解決の研究課題であるため、暗号技術上の課題も提示している。[ 123 ] TCPファストオープンは、初期（SYNおよびSYN-ACK）パケットでデータの送信を許可し、接続確立時の遅延を1RTT削減する。[ 124 ]しかし、TCPファストオープンはプロトコルの骨化のために導入が困難であり、2020年時点で、これをデフォルトとして使用しているWebブラウザはない。 [ 111 ]

TCPスループットはパケットの並べ替えの影響を受けます。並べ替えられたパケットは重複した確認応答の送信を引き起こし、それが閾値を超えると、不要な再送と輻輳制御を引き起こします。また、範囲の先頭で並べ替えられたパケットを受信すると、広い範囲が一度に確認応答されるため、送信動作がバースト的になることもあります（ヘッドオブラインブロッキングがアプリケーションに与える影響に似ています）。[ 125 ] Blanton & Allman (2002)は、スループットは並べ替えの量と反比例関係にあり、ある閾値を超えるとすべての並べ替えが不要な再送を引き起こすことを発見しました。[ 126 ]並べ替えの軽減は、送信者が不要な再送を送信したことを判断できるかどうか、つまり再送の曖昧さを解消できるかどうかに依存します。 [ 127 ]並べ替えによって引き起こされる不要な再送を減らすと、真の損失からの回復が遅れる可能性があります。[ 128 ]

選択的確認応答はスループットに大きなメリットをもたらす可能性があり、Bruyeron、Hemon、Zhang (1998)は最大45%の向上を測定した。[ 129 ]この改善の重要な要因は、選択的確認応答によって損失後のスロースタートを回避できる頻度が高くなり、利用可能な帯域幅をより有効に活用できることである。[ 130 ]しかし、TCPは最大3つのシーケンス番号ブロックしか選択的に確認応答できない。これにより再送速度が制限され、損失回復が困難になったり、特に損失が大きい環境では不必要な再送が発生したりする可能性がある。[ 131 ] [ 132 ]

TCP は元々、パケット損失がネットワーク輻輳の結果であると考えられ、予防措置として輻輳ウィンドウ サイズが大幅に削減される有線ネットワーク用に設計されたものです。しかし、無線リンクでは、フェーディング、シャドウイング、ハンドオフ、干渉、およびその他の無線の影響 (厳密には輻輳ではない) により、散発的で通常は一時的な損失が発生することが知られています。無線パケット損失による輻輳ウィンドウ サイズの (誤った) バックオフ後、輻輳回避フェーズでウィンドウ サイズが控えめに削減される場合があります。これにより、無線リンクが十分に活用されなくなります。これらの有害な影響に対抗するための広範な研究が行われてきました。提案されているソリューションは、クライアントまたはサーバーでの変更を必要とするエンドツーエンド ソリューション、[ 133 ]セルラー ネットワークの無線リンク プロトコルなどのリンク層ソリューション、またはエンド ノードを変更せずにネットワークに何らかの変更を必要とするプロキシベースのソリューションに分類できます。[ 133 ] [ 134 ]無線問題を解決するために、 Vegas、Westwood、Veno、Santa Cruz などの代替輻輳制御アルゴリズムが提案されている。

加速度

TCPアクセラレータの考え方は、ネットワークプロセッサ内でTCP接続を終端し、データをエンドシステムへの2番目の接続に中継することです。送信元から発信されたデータパケットはアクセラレータノードでバッファリングされ、アクセラレータノードはパケット損失が発生した場合にローカル再送信を実行します。これにより、パケット損失が発生した場合、送信元と受信元間のフィードバックループがアクセラレータノードと受信元間のフィードバックループに短縮され、受信側へのデータ配信速度が向上します。[ 135 ]

TCPはレート適応型プロトコルであるため、TCP送信側がネットワークにパケットを投入するレートは、ネットワーク内の現在の負荷状態と受信側の処理能力に正比例します。ネットワーク内の現在の負荷状態は、送信側が受信した確認応答に基づいて判断されます。アクセラレーションノードは、送信側と受信側の間のフィードバックループを分割することで、パケットあたりのラウンドトリップ時間（RTT）の短縮を保証します。RTTが短いほど、ネットワークの変化への応答時間が短縮され、送信側がこれらの変化に迅速に対応できるようになるため、メリットがあります。

この方法の欠点は、TCPセッションをアクセラレータ経由で送信する必要があることです。つまり、ルーティングが変更され、アクセラレータがパス上に存在しなくなると、接続が切断されます。また、TCP ACKメカニズムのエンドツーエンド特性も損なわれます。つまり、送信側がACKを受信して​​も、パケットはアクセラレータによって保存されており、受信側には配信されていないのです。

デバッグ

パケットスニファーは、ネットワークリンク上のTCPトラフィックを傍受し、リンクを通過するパケットをエンジニアに表示することで、ネットワーク、ネットワークスタック、およびTCPを使用するアプリケーションのデバッグに役立ちます。一部のネットワークスタックはSO_DEBUGソケットオプションをサポートしており、setsockoptを使用してソケットで有効にすることができます。このオプションは、そのソケット上のすべてのパケット、TCP状態、およびイベントをダンプするため、デバッグに役立ちます。Netstatもデバッグに使用できるユーティリティです。

代替案

多くのアプリケーションでは、TCPは適切ではありません。アプリケーションは通常、失われたパケットの再送信コピーを受信するまで、失われたパケットの後に続くパケットにアクセスできません。これは、ストリーミングメディア、リアルタイムマルチプレイヤーゲーム、Voice over IP (VoIP) などのリアルタイムアプリケーションでは問題を引き起こします。これらのアプリケーションでは、すべてのデータを順番に取得するよりも、ほとんどのデータをタイムリーに取得する方が一般的に有用です。

歴史的およびパフォーマンス上の理由から、ほとんどのストレージエリアネットワーク（SAN）は、ファイバーチャネル接続を介してファイバーチャネルプロトコル（FCP）を使用しています。組み込みシステム、ネットワークブート、そして多数のクライアントからの単純なリクエストを処理するサーバー（DNSサーバーなど）では、TCPの複雑さが問題となる場合があります。NAT （STUNなどのシステムを使用）の背後にある2つのホスト間でデータを転送するようなトリックは、TCPのような比較的複雑なプロトコルを介さずに実行できるため、はるかに簡単です。

一般的に、TCPが適さない場合は、ユーザーデータグラムプロトコル（UDP）が使用されます。UDPは、TCPと同じアプリケーション多重化とチェックサムを提供しますが、ストリームや再送は処理しません。そのため、アプリケーション開発者は状況に応じて適切な方法でコーディングしたり、前方誤り訂正やエラー隠蔽などの他の方法に置き換えたりすることができます。

ストリーム制御伝送プロトコル（SCTP）は、TCPに類似した信頼性の高いストリーム指向サービスを提供するプロトコルです。TCPよりも新しく、かなり複雑なため、まだ広く普及していません。しかし、信頼性と準リアルタイム性が重視される状況での使用を目的として設計されています。

Venturi トランスポート プロトコル (VTP) は、ワイヤレス データ転送に関連する非効率性を克服するために TCP を透過的に置き換えるように設計された 特許取得済みの独自プロトコルです。

TCP輻輳回避アルゴリズムは、データの送信元が事前に分からないアドホック環境では非常に有効に機能します。環境が予測可能な場合は、非同期転送モード（ATM）などのタイミングベースのプロトコルを使用することで、TCPの再送オーバーヘッドを回避できます。

UDPベースのデータ転送プロトコル（UDT）は、帯域幅遅延積が大きいネットワークではTCPよりも効率と公平性に優れています。[ 136 ]

多目的トランザクション プロトコル(MTP/IP) は、さまざまなネットワーク状況、特に TCP が非効率であると認識される状況で、高いスループットとトランザクション パフォーマンスを適応的に実現するように設計された特許取得済みの独自ソフトウェアです。

チェックサム計算

IPv4のTCPチェックサム

TCPがIPv4上で動作する場合、チェックサムを計算する方法は次のように定義されます。[ 18 ]

チェックサムフィールドは、ヘッダーとテキストに含まれるすべての16ビットワードの1の補数の合計の1の補数です。チェックサム計算では、合計するデータの16ビットアライメントを確保する必要があります。セグメントに含まれるヘッダーとテキストのオクテットの数が奇数の場合、最後のオクテットの右側にゼロをパディングしてチェックサム用の16ビットワードを形成することで、アライメントを実現できます。パディングはセグメントの一部として送信されません。チェックサムの計算中、チェックサムフィールド自体はゼロに置き換えられます。

つまり、適切なパディングの後、すべての16ビットワードが1の補数演算を用いて加算されます。そして、その合計がビットごとに補数化され、チェックサムフィールドとして挿入されます。チェックサム計算に使用されるIPv4パケットヘッダーを模倣した疑似ヘッダーは次のとおりです。

チェックサム計算用の TCP 疑似ヘッダー (IPv4)
オフセットオクテット0 1 2 3
オクテット 少し0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 送信元アドレス
4 32 宛先アドレス
8 64 ゼロプロトコル (6)TCP 長さ
12 96 送信元ポート宛先ポート
16 128 シーケンス番号
20 160 確認番号
24 192 データオフセット予約済み旗ウィンドウ
28 224 チェックサム緊急ポインタ
32 256 （オプション）
36 288 データ
40 320
⋮ ⋮

チェックサムは次のフィールドで計算されます。

送信元アドレス: 32ビット
IPv4ヘッダーの送信元アドレス
宛先アドレス: 32ビット
IPv4ヘッダーの宛先アドレス
ゼロ: 8ビット
すべてゼロ
プロトコル: 8ビット
TCP のプロトコル値:6
TCP長さ: 16ビット
TCPヘッダーとデータの長さ（オクテット単位）。例えば、合計長が次のIPv4パケットがあるとします。200バイト、IHL値は5で、長さは5ビット × 32ビット=160ビット=20バイト。TCPの長さは（合計長）−（IPv4ヘッダー長）として計算でき、つまり200−20となり、180 バイト。

IPv6のTCPチェックサム

TCPがIPv6上で動作する場合、チェックサムを計算する方法が変更されます。[ 137 ]

チェックサム計算に IP ヘッダーのアドレスを含めるトランスポートまたはその他の上位層プロトコルは、IPv6 で使用するために、32 ビットの IPv4 アドレスではなく 128 ビットの IPv6 アドレスを含めるように変更する必要があります。

チェックサムの計算のために IPv6 ヘッダーを模倣した疑似ヘッダーを以下に示します。

チェックサム計算用の TCP 疑似ヘッダー (IPv6)
オフセットオクテット0 1 2 3
オクテット 少し0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 送信元アドレス
4 32
8 64
12 96
16 128 宛先アドレス
20 160
24 192
28 224
32 256 TCP 長さ
36 288 ゼロ次のヘッダー (6)
40 320 送信元ポート宛先ポート
44 352 シーケンス番号
48 384 確認番号
52 416 データオフセット予約済み旗ウィンドウ
56 448 チェックサム緊急ポインタ
60 480 （オプション）
64 512 データ
68 544
⋮ ⋮

チェックサムは次のフィールドで計算されます。

送信元アドレス: 128ビット
IPv6 ヘッダー内のアドレス。
宛先アドレス: 128ビット
最終的な宛先。IPv6 パケットにルーティング ヘッダーが含まれていない場合、TCP は IPv6 ヘッダー内の宛先アドレスを使用します。それ以外の場合、発信元ノードではルーティング ヘッダーの最後の要素内のアドレスを使用し、受信ノードでは IPv6 ヘッダー内の宛先アドレスを使用します。
TCP 長さ: 32 ビット
TCP ヘッダーとデータの長さ (オクテット単位で測定)。
ゼロ: 24 ビット;Zeroes == 0
すべてゼロです。
次のヘッダー: 8ビット
TCP のプロトコル値:6 .

チェックサムオフロード

多くのTCP/IPソフトウェアスタック実装では、ネットワークへの送信前、またはネットワークからの受信時に検証のためにネットワークアダプタ内でハードウェア支援を利用してチェックサムを自動計算するオプションが提供されています。これにより、チェックサム計算に伴うCPU負荷が軽減され、ネットワーク全体のパフォーマンスが向上する可能性があります。

この機能により、チェックサムオフロードの使用を認識しない、または不確実なパケットアナライザが、ネットワークアダプタにまだ到達していない送信パケットに無効なチェックサムを報告する可能性があります。 [ 138 ]これは、ネットワークアダプタによって送信される前に傍受されたパケットに対してのみ発生します。ネットワークアダプタによって回線上で送信されるすべてのパケットには有効なチェックサムが含まれます。[ 139 ]この問題は、同じホスト上の仮想マシン間で送信されるパケットを監視するときにも発生する可能性があります。この場合、仮想デバイスドライバは、チェックサムが後で VM ホストカーネルまたはその物理ハードウェアによって計算されることがわかっているため、最適化としてチェックサムの計算を省略する可能性があります。

参照

注記

  1. ^ a b RFC 3168によってヘッダーに追加された
  2. ^ウィンドウのサイズ単位は、デフォルトではバイトです。
  3. ^ウィンドウ サイズは、確認応答フィールドのシーケンス番号によって識別されるセグメントを基準とします。
  4. ^同様に、送信元と送信先のネットワークソケットのペアで、それぞれアドレスとポート番号から構成されます。
  5. ^最新の標準であるHTTP/3では、トランスポートとして TCP の代わりにQUICが使用されます。

参考文献

  1. ^ Comer, DE (2021). 『TCP/IPによるインターネットワーキング（第6版）』ピアソン.
  2. ^ラブラドール、ミゲル・A.、ペレス、アルフレド・J.、ワイトマン、ペドロ・M. (2010).位置情報に基づく情報システム：リアルタイム追跡アプリケーションの開発. CRC Press. ISBN 9781000556803。
  3. ^ Vinton G. Cerf; Robert E. Kahn (1974年5月). 「パケットネットワーク相互通信のためのプロトコル」(PDF) . IEEE Transactions on Communications . 22 (5): 637– 648. Bibcode : 1974ITCom..22..637C . doi : 10.1109/tcom.1974.1092259 . 2016年3月4日時点のオリジナル(PDF)からのアーカイブ。
  4. ^リチャード・ベネット（2009年9月）「Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate」（PDF）。情報技術イノベーション財団（ITI）11ページ。2019年8月29日時点のオリジナルよりアーカイブ（PDF） 。 2017年9月11日閲覧。
  5. ^ RFC 675。
  6. ^ラッセル、アンドリュー・ローレンス（2008年）。「産業立法府」：第二次および第三次産業革命におけるコンセンサス標準化（論文）。Abbate著『インターネットの発明』129-30ページ、Vinton G. Cerf著（1980年10月）「相互接続パケットネットワークのプロトコル」ACM SIGCOMMコンピュータ通信レビュー10 （ 4）：10-11ページを参照。; およびRFC 760。doi : 10.17487 /RFC0760。「
  7. ^ Postel, Jon (1977年8月15日), Comments on Internet Protocol and TCP , IEN 2, 2019年5月16日アーカイブ, 2016年6月11日閲覧,階層化の原則に違反することで、インターネットプロトコルの設計は失敗に終わります。具体的には、TCPを2つの目的で使用しようとしています。1つはホストレベルのエンドツーエンドプロトコルとして機能させること、もう1つはインターネットパッケージングおよびルーティングプロトコルとして機能することです。これら2つの機能は、階層化されモジュール化された方法で提供されるべきです。
  8. ^ Cerf, Vinton G. (1980年4月1日). 「スタンフォード大学TCPプロジェクト最終報告書」 .
  9. ^ Cerf, Vinton G; Cain, Edward (1983年10月). 「国防総省のインターネットアーキテクチャモデル」. Computer Networks . 7 (5): 307– 318. doi : 10.1016/0376-5075(83)90042-9 .
  10. ^ 「TCP/IPガイド - TCP/IPアーキテクチャとTCP/IPモデル」 www.tcpipguide.com . 2020年2月11日閲覧。
  11. ^ Eddy, Wesley (2022年8月).伝送制御プロトコル (TCP) . doi : 10.17487/RFC9293 . RFC 9293 .
  12. ^ 「インターネット実験ノートインデックス」www.rfc-editor.org . 2024年1月21日閲覧。
  13. ^ “Robert E Kahn – AM Turing Award Laureate” . amturing.acm.org . 2019年7月13日時点のオリジナルよりアーカイブ。 2019年7月13日閲覧。
  14. ^ “Vinton Cerf – AM Turing Award Laureate” . amturing.acm.org . 2021年10月11日時点のオリジナルよりアーカイブ。 2019年7月13日閲覧。
  15. ^ a b c d e f g h i Comer, Douglas E. (2006). Internetworking with TCP/IP: Principles, Protocols, and Architecture . 第1巻 (第5版). Prentice Hall. ISBN 978-0-13-187671-2。
  16. ^ a b c RFC 9293、2.2 . 主要なTCP概念。
  17. ^ RFC 791、5～6ページ。
  18. ^ a b c d RFC 9293。
  19. ^ a b c RFC 9293、3.1 . ヘッダーフォーマット。
  20. ^ RFC 9293、3.8.5緊急情報の伝達。
  21. ^ RFC 9293、3.4 . シーケンス番号。
  22. ^ RFC 9293、3.4.1 . 初期シーケンス番号の選択。
  23. ^ 「RFC 3540「ノンスを使用した堅牢な明示的輻輳通知（ECN）シグナリング」をHistoricに変更」。datatracker.ietf.org。2023年4月18日閲覧。
  24. ^ Briscoe, Bob; Kühlewind, Mirja; Scheffenegger, Richard (2025年3月10日). TCPにおけるより正確な明示的輻輳通知（AccECN）フィードバック. ID draft-ietf-tcpm-accurate-ecn . 2025年10月24日閲覧。
  25. ^ RFC 3168、13～14ページ。
  26. ^ RFC 3168、15ページ。
  27. ^ RFC 3168、18～19ページ。
  28. ^ RFC 793。
  29. ^ a b c RFC 7323。
  30. ^ RFC 2018、2 . Sack-Permitted オプション。
  31. ^ RFC 2018、3 . Sack オプション形式。
  32. ^ Heffernan, Andy (1998年8月). TCP MD5署名オプションによるBGPセッションの保護. IETF. doi : 10.17487/RFC2385 . RFC 2385. 2023年12月30日閲覧。
  33. ^ 「伝送制御プロトコル（TCP）パラメータ：TCPオプション種別番号」 IANA。2017年10月2日時点のオリジナルよりアーカイブ。 2017年10月19日閲覧。
  34. ^ RFC 9293、3.3.2 . ステートマシンの概要。
  35. ^黒瀬, James F. (2017).コンピュータネットワーキング：トップダウンアプローチ. Keith W. Ross (第7版). イギリス、ハーロウ. p. 286. ISBN 978-0-13-359414-0. OCLC  936004518 .{{cite book}}: CS1 メンテナンス: 場所の発行元が見つかりません (リンク)
  36. ^ Tanenbaum, Andrew S. (2003-03-17).コンピュータネットワーク（第4版）. Prentice Hall. ISBN 978-0-13-066102-9。
  37. ^ "linux/net/ipv4/tcp_minisocks.c at master · torvalds/linux" . GitHub . 2025年4月24日閲覧。
  38. ^ RFC 1122、4.2.2.13 . 接続の終了。
  39. ^ 「TCP（伝送制御プロトコル）– 伝送プロトコルの説明」 IONOSデジタルガイド. 2020年3月2日. 2025年4月24日閲覧。
  40. ^ 「TCP/IPガイド - TCP接続終了」 www.tcpipguide.com . 2025年4月24日閲覧。
  41. ^カーン＆パートリッジ 1991、364ページ。
  42. ^ RFC 9002、4.2 . 単調に増加するパケット番号。
  43. ^ Mathis; Mathew; Semke; Mahdavi; Ott (1997). 「TCP輻輳回避アルゴリズムのマクロ的な挙動」. ACM SIGCOMM Computer Communication Review . 27 (3): 67– 82. CiteSeerX 10.1.1.40.7002 . doi : 10.1145/263932.264023 . S2CID 1894993 .  
  44. ^ RFC 3522、4ページ。
  45. ^ Leung, Ka-cheong; Li, Victor Ok; Yang, Daiqin (2007). 「伝送制御プロトコル（TCP）におけるパケット順序変更の概要：問題、解決策、課題」IEEE Transactions on Parallel and Distributed Systems . 18 (4): 522– 535. Bibcode : 2007ITPDS..18..522L . doi : 10.1109/TPDS.2007.1011 .
  46. ^ Johannessen, Mads (2015). Linux TCPにおける順序変更の調査（修士論文）. オスロ大学.
  47. ^ Cheng, Yuchung (2015). RACK: TCPのための時間ベースの高速損失検出 draft-cheng-tcpm-rack-00 (PDF) . IETF94. 横浜: IETF.
  48. ^ RFC 8985。
  49. ^ Cheng, Yuchung; Cardwell, Neal; Dukkipati, Nandita; Jha, Priyaranjan (2017). RACK: 時間ベースの高速損失回復 draft-ietf-tcpm-rack-02 (PDF) . IETF100. 横浜: IETF.
  50. ^ RFC 6298、2ページ。
  51. ^ a b張 1986、399ページ。
  52. ^カーン＆パートリッジ 1991、365ページ。
  53. ^ Ludwig & Katz 2000、31–33ページ。
  54. ^ Gurtov & Ludwig 2003、2ページ。
  55. ^ Gurtov & Floyd 2004、1ページ。
  56. ^ a b RFC 6298、p.4。
  57. ^カーン＆パートリッジ 1991、370–372ページ。
  58. ^オールマン＆パクソン 1999、268ページ。
  59. ^ RFC 7323、7ページ。
  60. ^ Stone; Partridge (2000). 「CRCとTCPチェックサムが一致しない場合」 .コンピュータ通信のためのアプリケーション、テクノロジー、アーキテクチャ、プロトコルに関する会議議事録. ACM SIGCOMM コンピュータ通信レビュー. pp.  309– 319. CiteSeerX 10.1.1.27.7611 . doi : 10.1145/347059.347561 . ISBN  978-1581132236. S2CID  9547018 . 2008年5月5日時点のオリジナルよりアーカイブ。2008年4月28日閲覧。
  61. ^ RFC 5681。
  62. ^ RFC 6298。
  63. ^ RFC 1122。
  64. ^ RFC 2018、10ページ。
  65. ^ RFC 9002、4.4 . 契約破棄の禁止。
  66. ^ Corbet, Jonathan (2004年7月7日). 「TCPウィンドウスケーリングと壊れたルーター」 . LWN.net . 2020年3月31日時点のオリジナルよりアーカイブ。 2016年7月21日閲覧。
  67. ^ RFC 3522。
  68. ^ "IP sysctl" . Linuxカーネルドキュメント. 2016年3月5日時点のオリジナルよりアーカイブ。 2018年12月15日閲覧。
  69. ^ Wang, Eve. 「TCPタイムスタンプが無効です」 . Technet – Windows Server 2012 Essentials . Microsoft. 2018年12月15日時点のオリジナルよりアーカイブ。 2018年12月15日閲覧。
  70. ^ David Murray、Terry Koziniec、Sebastian Zander、Michael Dixon、Polychronis Koutsakis (2017). 「変化する企業ネットワークトラフィック特性の分析」(PDF) . 第23回アジア太平洋通信会議 (APCC 2017). 2017年10月3日時点のオリジナルよりアーカイブ(PDF) . 2017年10月3日閲覧。
  71. ^ Gont, Fernando (2008年11月). 「TCP緊急データの実装について」 . 第73回IETF会議. 2019年5月16日時点のオリジナルよりアーカイブ。2009年1月4日閲覧。
  72. ^ピーターソン、ラリー (2003).コンピュータネットワーク. モーガン・カウフマン. p.  401. ISBN 978-1-55860-832-0。
  73. ^ Richard W. Stevens (2011年11月). TCP/IP Illustrated. 第1巻 プロトコル. Addison-Wesley. 第20章. ISBN 978-0-201-63346-7。
  74. ^ 「伝送制御プロトコル（TCP）のセキュリティ評価」（PDF） 。 2009年3月6日時点のオリジナル（PDF）からアーカイブ。 2010年12月23日閲覧。
  75. ^伝送制御プロトコル（TCP）実装のセキュリティ強化方法の調査。ID draft-ietf-tcpm-tcp-security。
  76. ^ Jakob Lell (2013年8月13日). 「SYN Cookieを使用したクイックブラインドTCP接続スプーフィング」 . 2014年2月22日時点のオリジナルよりアーカイブ。2014年2月5日閲覧。
  77. ^ 「最近のTCP DoS（サービス拒否）脆弱性に関する考察」（PDF） 。 2013年6月18日時点のオリジナル（PDF）からアーカイブ。 2010年12月23日閲覧。
  78. ^ 「TCPとPersistタイマーの無限性を利用する」。2010年1月22日時点のオリジナルよりアーカイブ。2010年1月22日閲覧。
  79. ^ 「PUSHとACKフラッド」 . f5.com . 2017年9月28日時点のオリジナルよりアーカイブ。2017年9月27日閲覧。
  80. ^ Laurent Joncheray (1995). TCPに対する単純なアクティブ攻撃(PDF) . 第5回USENIX UNIXセキュリティシンポジウム. 2023年6月4日閲覧。
  81. ^ John T. Hagen; Barry E. Mullins (2013). TCP veto: 新しいネットワーク攻撃とSCADAプロトコルへの応用. 2013 IEEE PES Innovative Smart Grid Technologies Conference (ISGT). pp.  1– 6. doi : 10.1109/ISGT.2013.6497785 . ISBN 978-1-4673-4896-6. S2CID  25353177 .
  82. ^ RFC 9293、4 . 用語集。
  83. ^ RFC 8095、6ページ。
  84. ^パーシュ & ボナベンチャー 2014、p. 51.
  85. ^ RFC 6182。
  86. ^ RFC 6824。
  87. ^ Raiciu; Barre; Pluntke; Greenhalgh; Wischik; Handley (2011). 「マルチパスTCPによるデータセンターのパフォーマンスと堅牢性の向上」 . ACM SIGCOMM Computer Communication Review . 41 (4): 266. CiteSeerX 10.1.1.306.3863 . doi : 10.1145/2043164.2018467 . 2020年4月4日時点のオリジナルよりアーカイブ。 2011年6月29日閲覧。 
  88. ^ 「MultiPath TCP – Linuxカーネル実装」 2013年3月27日時点のオリジナルよりアーカイブ。2013年3月24日閲覧。
  89. ^ Raiciu; Paasch; Barre; Ford; Honda; Duchene; Bonaventure; Handley (2012). 「How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP」 . Usenix NSDI : 399– 412. 2013年6月3日時点のオリジナルよりアーカイブ。 2013年3月24日閲覧。
  90. ^ Bonaventure; Seo (2016). 「Multipath TCP Deployments」 . IETF Journal . 2020年2月23日時点のオリジナルよりアーカイブ。 2017年1月3日閲覧。
  91. ^ TCPストリームの暗号化保護（tcpcrypt） . 2019年5月. doi : 10.17487/RFC8548 . RFC 8548 .
  92. ^ Michael Kerrisk (2012年8月1日). 「TCP Fast Open: 高速Webサービス」 . LWN.net . 2014年8月3日時点のオリジナルよりアーカイブ。 2014年7月21日閲覧。
  93. ^ RFC 7413。
  94. ^ RFC 6937。
  95. ^ Grigorik, Ilya (2013).高性能ブラウザネットワーキング（第1版）. 北京: O'Reilly. ISBN 978-1449344764。
  96. ^ RFC 6013。
  97. ^ RFC 7805。
  98. ^ Kumar, Sam; P Andersen, Michael; Kim, Hyung-Sin; E. Culler, David (2020).低電力ワイヤレスネットワーク向け高性能TCP NSDI '20. USENIX.
  99. ^ Kumar, Sam (2023). Rethinking System Design for Expressive Cryptography (PDF) (Ph.D. thesis). University of California, Berkeley. 2025年10月13日時点のオリジナルよりアーカイブ(PDF) 。
  100. ^ RFC 8546、6ページ。
  101. ^ RFC 8558、3ページ。
  102. ^ RFC 9065、2 . ネットワーク内でのトランスポートヘッダーの現在の使用法。
  103. ^ RFC 9065、3 . 研究、開発、および展開。
  104. ^ RFC 8558、8ページ。
  105. ^ RFC 9170、2.3 . マルチパーティインタラクションとミドルボックス。
  106. ^ RFC 9170、A.5. TCP。
  107. ^ Papastergiou et al. 2017、p. 620。
  108. ^ Edeline & Donnet 2019、175–176 ページ。
  109. ^ Raiciu et al. 2012、p.1。
  110. ^ヘスマンス他 2013、p.1。
  111. ^ a b Rybczyńska 2020 .
  112. ^ Papastergiou et al. 2017、p. 621。
  113. ^コーベット 2015 .
  114. ^ブリスコーら。 2016、29–30 ページ。
  115. ^ Marx 2020、HTTP/1.1でのHOLブロッキング。
  116. ^ Marx 2020、ボーナス：交通渋滞制御。
  117. ^ IETF HTTP ワーキング グループ、「なぜ TCP 接続が 1 つだけなのか?」
  118. ^コーベット 2018 .
  119. ^ a b RFC 7413、3ページ。
  120. ^ Sy et al. 2020、p.271。
  121. ^チェンら。 2021、8–9 ページ。
  122. ^ゲディーニ 2018 .
  123. ^チェンら。 2021、3–4 ページ。
  124. ^ RFC 7413、1ページ。
  125. ^ブラントン＆オールマン 2002年、1～2頁。
  126. ^ブラントン＆オールマン 2002年、4～5頁。
  127. ^ブラントン＆オールマン 2002年、3～4頁。
  128. ^ブラントン＆オールマン 2002年、6～8頁。
  129. ^ Bruyeron、Hemon、Zhang 1998、67ページ。
  130. ^ Bruyeron、Hemon、Zhang 1998、72ページ。
  131. ^ Bhat、Rizk & Zink 2017、p. 14.
  132. ^ RFC 9002、4.5 . ACK範囲の追加。
  133. ^ a b「CDMA2000 RLPにおけるTCPパフォーマンス」 。 2011年5月3日時点のオリジナルよりアーカイブ。2010年8月30日閲覧。
  134. ^ Muhammad Adeel、Ahmad Ali Iqbal (2007). 「CDMA2000パケットデータネットワークにおけるTCP輻輳ウィンドウ最適化」第4回国際情報技術会議 (ITNG'07) . pp.  31– 35. doi : 10.1109/ITNG.2007.190 . ISBN 978-0-7695-2776-5. S2CID  8717768 .
  135. ^ 「TCPアクセラレーション」 。 2024年4月22日時点のオリジナルよりアーカイブ。2024年4月18日閲覧。
  136. ^ Yunhong Gu; Xinwei Hong; Robert L. Grossman (2004). 「減少増加を伴うAIMDアルゴリズムの分析」(PDF) . 2016年3月5日時点のオリジナルよりアーカイブ(PDF) 。
  137. ^ RFC 8200。
  138. ^ 「Wireshark: オフロード」。2017年1月31日アーカイブ。 2017年2月24日閲覧。Wiresharkは、ネットワークアダプタに送信される前のパケットをキャプチャします。チェックサムはまだ計算されていないため、正しいチェックサムは表示されません。さらに悪いことに、ほとんどのOSはこのデータを初期化しないため、本来表示されるべきではないメモリの小さなチャンクが表示される可能性があります。Wireshark 1.2以降の新規インストールでは、IP、TCP、UDPのチェックサム検証がデフォルトで無効になっています。必要に応じて、各解析ツールのチェックサム検証を手動で無効にすることができます。
  139. ^ 「Wireshark: チェックサム」。2016年10月22日アーカイブ。 2017年2月24日閲覧。チェックサムオフロードは、送信するネットワークパケットが実際にチェックサムを計算する前にWiresharkに渡されるため、しばしば混乱を引き起こします。Wiresharkはこれらの「空の」チェックサムを取得し、無効として表示しますが、パケットがネットワークハードウェアから送信される際には有効なチェックサムが含まれているにもかかわらずです。

参考文献

ご意見のお願い

その他の文書

さらに読む

ウィキバーシティには伝送制御プロトコルに関する学習リソースがあります
ウィキメディア コモンズには、伝送制御プロトコルに関連するメディアがあります。
「 https://en.wikipedia.org/w/index.php?title=Transmission_Control_Protocol&oldid=1332899817#Connection_establishment」より取得