伝送制御プロトコル

伝送制御プロトコル

プロトコルスタック
略語	通信プロトコル
開発者	ヴィント・サーフとボブ・カーン
導入	1974年; 50年前 （1974年）
に基づく	トランスミッション制御プログラム
OSI層	トランスポート層(4)
RFC(複数)	9293

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

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

1974 年 5 月、Vint CerfとBob Kahn は、ネットワーク ノード間でパケット交換を使用してリソースを共有するインターネットワーキングプロトコルを説明しました。 ^[2]著者は、Gérard Le Lannと協力して、フランスのCYCLADESプロジェクトの概念を新しいネットワークに組み込む作業を行っていました。 ^{[3]結果として得られたプロトコルの}仕様であるRFC 675 (インターネット伝送制御プログラムの仕様) は、Vint Cerf、Yogen Dalal、Carl Sunshine によって作成され、1974 年 12 月に公開されました。 ^{[4]この仕様には、}インターネットワークの略語としてインターネットという用語が初めて使用されました。^[要出典]

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

以下のインターネット実験ノート（IEN）文書はTCPの現代版への進化について記述している：^[10]

• IEN 5インターネット伝送制御プログラム TCP バージョン 2 の仕様 ( 1977 年 3 月)。
• IEN 21インターネットワーク伝送制御プログラム TCP バージョン 3 の仕様 ( 1978 年 1 月)。
• 27 インド
• 40 インド
• 44 条
• 55 国際
• 81 国際
• 112 言語
• 124 インド

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

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

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

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

TCP は、 World Wide Web (WWW)、電子メール、ファイル転送プロトコル、セキュア シェル、ピアツーピア ファイル共有、ストリーミング メディアなど、多くのインターネット アプリケーションで広く使用されています。

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

TCP は、受信したすべてのバイトが送信したものと同じ順序で同じであることを保証する信頼性の高いバイト ストリーム配信サービスです。多くのネットワークによるパケット転送は信頼性が低いため、TCP は再送信による肯定応答と呼ばれる手法を使用してこれを実現します。この手法では、受信側はデータを受信すると、肯定応答メッセージで応答する必要があります。送信側は送信する各パケットの記録を保持し、パケットが送信された時点からのタイマーを維持します。タイマーが期限切れになって肯定応答を受信しなかった場合、送信側はパケットを再送信します。タイマーは、パケットが失われたり破損したりした場合に必要です。^[13]

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

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

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

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

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

送信元ポート: 16 ビット

送信ポートを識別します。

宛先ポート: 16 ビット

受信ポートを識別します。

シーケンス番号: 32 ビット

2つの役割があります:

• SYN フラグが設定されている場合 (1)、これが初期シーケンス番号です。実際の最初のデータ バイトのシーケンス番号と対応する ACK の確認応答番号は、このシーケンス番号に 1 を加えたものになります。
• SYN フラグが設定されていない場合 (0)、これは現在のセッションのこのセグメントの最初のデータ バイトの累積シーケンス番号です。

確認番号: 32 ビット

ACKフラグが設定されている場合、このフィールドの値はACKの送信者が期待する次のシーケンス番号です。これは、以前のすべてのバイト（ある場合）の受信を確認します。^[19]各エンドから送信される最初のACKは、相手側の最初のシーケンス番号自体を確認しますが、データは確認しません。^[20]

データオフセット (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はHistoricステータスに移行しました。^[21]

フラグ: 8 ビット

次のように 8 つの 1 ビット フラグ (制御ビット) が含まれます。

CWR: 1 ビット

輻輳ウィンドウ縮小（CWR）フラグは、送信ホストによって設定され、ECEフラグが設定されたTCPセグメントを受信し、輻輳制御メカニズムで応答したことを示します。^{[22] [a]}

ECE: 1 ビット

ECN-Echo は、SYN フラグの値に応じて 2 つの役割を果たします。次のことを示します。

• SYNフラグが設定されている場合（1）、TCPピアはECNに対応しています。^[23]
• SYNフラグが設定されていない場合（0）、IPヘッダーに輻輳フラグが設定されている（ECN=11）パケットが通常の送信中に受信された。^[a]これは、TCP送信者にネットワーク輻輳（または差し迫った輻輳）を示すものである。^[24]

URG: 1 ビット

緊急ポインター フィールドが重要であることを示します。

ACK: 1ビット

確認応答フィールドが重要であることを示します。クライアントが送信した最初のSYNパケット以降のすべてのパケットにはこのフラグが設定されている必要があります。^[25]

PSH: 1 ビット

プッシュ機能。バッファリングされたデータを受信側アプリケーションにプッシュするように要求します。

RST: 1 ビット

接続をリセットする

SYN: 1 ビット

シーケンス番号を同期します。各端から送信される最初のパケットのみにこのフラグを設定する必要があります。他のフラグとフィールドは、このフラグに基づいて意味が変わります。フラグが設定されている場合にのみ有効なものもあれば、フラグがクリアされている場合にのみ有効なものもあります。

FIN: 1 ビット

送信者からの最後のパケット

ウィンドウ: 16 ビット

受信ウィンドウのサイズ。これは、このセグメントの送信者が現在受信しようとしているウィンドウサイズ単位^[b]の数を指定します。 ^[c] (§ フロー制御および§ ウィンドウスケーリングを参照してください。)

チェックサム: 16ビット

16ビットのチェックサムフィールドは、TCPヘッダー、ペイロード、およびIP疑似ヘッダーのエラーチェックに使用されます。疑似ヘッダーは、送信元IPアドレス、宛先IPアドレス、 TCPプロトコルのプロトコル番号（6）、およびTCPヘッダーとペイロードの長さ（バイト単位）で構成されます。

緊急ポインタ: 16 ビット

URG フラグが設定されている場合、この 16 ビット フィールドは、最後の緊急データ バイトを示すシーケンス番号からのオフセットです。

オプション (TCP オプション): 可変 0～320 ビット、32 ビット単位; サイズ (オプション) == (DOffset - 5) * 32

このフィールドの長さはデータオフセットフィールドによって決定されます。TCPヘッダーパディングは、TCPヘッダーが32ビット境界で終了し、データが始まることを保証するために使用されます。パディングはゼロで構成されています。^[16]

オプションには、オプション種別 (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) として示されます。

残りのオプション種別値は、歴史的、廃止、実験的、まだ標準化されていない、または未割り当てです。オプション番号の割り当ては、インターネット割り当て番号機関（IANA）によって管理されています。^[30]

データ: 変数

TCPパケットのペイロード

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

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

クライアントがサーバーに接続しようとする前に、サーバーはまずポートにバインドしてリッスンし、接続用にポートを開く必要があります。これはパッシブ オープンと呼ばれます。パッシブ オープンが確立されると、クライアントは 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 では、他方向 (サーバーからクライアント) のシーケンス番号を確立して確認します。これらのステップが完了すると、クライアントとサーバーの両方が確認を受信し、全二重通信が確立されます。

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

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

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

接続は半オープン状態になることがあります。その場合、片側は接続を終了していますが、もう一方は終了していません。終了した側は接続にデータを送信できなくなりますが、もう一方は送信できます。終了側は、もう一方も終了するまでデータの読み取りを継続する必要があります。^{[引用が必要]}

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

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

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

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

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

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

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

信頼性は、送信者が失われたデータを検出し、それを再送信することによって実現されます。TCP は、損失を識別するために、再送信タイムアウト (RTO) と重複累積確認応答 (DupAcks) という 2 つの主な手法を使用します。

TCPセグメントが再送されると、元の配信試行と同じシーケンス番号が保持されます。配信と論理データ順序のこの融合は、再送後に確認応答を受信したときに、送信者が元の送信と再送のどちらが確認されているかを判断できないことを意味し、いわゆる再送の曖昧さです。^[35] TCPは再送の曖昧さのために複雑さを招きます。^[36]

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

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

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

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

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

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

TCPはエンドツーエンドのフロー制御プロトコルを使用して、送信側がデータを送信しすぎてTCP受信側が確実に受信して処理できない状態になることを回避します。フロー制御のメカニズムは、さまざまなネットワーク速度のマシンが通信する環境では不可欠です。たとえば、PCが受信したデータをゆっくりと処理しているスマートフォンにデータを送信する場合、スマートフォンは圧倒されないようにデータフローを調整できる必要があります。^[13]

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

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

受信側が受信データを少しずつ処理している場合、小さな受信ウィンドウを繰り返し通知することがあります。TCP ヘッダーのオーバーヘッドが比較的大きいことを考慮すると、TCP セグメントで数バイトのデータのみを送信するのは非効率的であるため、これはSilly ウィンドウ シンドロームと呼ばれます。

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

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

現代のTCPの実装には、スロースタート、輻輳回避、高速再送、高速回復という4つの絡み合ったアルゴリズムが含まれています。^[55]

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

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

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

MSSアナウンスはMSSネゴシエーションとも呼ばれるが、厳密に言えばMSSはネゴシエートされない。TCP接続では、2つの方向のデータフローに対して2つの完全に独立したMSS値が許可されるため、^{[57] [16]}、双方向接続に共通のMSS構成について合意する必要はない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RFC ^{[ which? ]}PSHでは、プッシュビットを「受信側 TCP スタックにこのデータを受信側アプリケーションに直ちに送信するためのメッセージ」と定義しています。 ^[13] Berkeley ソケットを使用してユーザー空間でプッシュビットを指定または制御する方法はありません。プッシュビットはプロトコルスタックによってのみ制御されます。^[67]

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

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

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

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

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

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

ポート番号は、ウェルノウン、登録済み、動的またはプライベートの 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 で参照できます。このリストには、近年の最も重要な TCP 関連 RFC の 1 つである RFC 2581 (TCP 輻輳制御) があり、過度の輻輳を回避する更新されたアルゴリズムについて説明しています。2001 年には、輻輳回避シグナリング メカニズムで ある明示的輻輳通知(ECN) について記述する RFC 3168 が作成されました。

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

マルチパスTCP（MPTCP）^{[79] [80]}はIETF内で進行中の取り組みであり、TCP接続が複数のパスを使用してリソースの使用率を最大化し、冗長性を高めることを目指しています。ワイヤレスネットワークのコンテキストでマルチパスTCPが提供する冗長性により、異なるネットワークを同時に使用することができ、スループットが向上し、ハンドオーバー機能が向上します。マルチパスTCPは、データセンター環境でもパフォーマンス上の利点をもたらします。^[81]マルチパスTCPのリファレンス実装^[82]は、Linuxカーネルで開発されました。^[83]マルチパスTCPは、iPhone、iPad、MacのSiri音声認識アプリケーションをサポートするために使用されます。^[84]

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

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

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

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

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

TCPのワイヤデータは、プロトコルメタデータがクリアテキストで送信されるため、経路上の観察者に重要な情報収集および変更の機会を提供します。^{[92] [93]この透明性はネットワークオペレータ[94]}や研究者^[95]には有用ですが、プロトコルメタデータから収集された情報によってエンドユーザのプライバシーが損なわれる可能性があります。^[96]このメタデータの可視性と柔軟性により、TCPは拡張が困難になっています。これはプロトコルの骨化の一例であり、中間ノード（「ミドルボックス」）はメタデータに基づいて決定を下したり、メタデータを変更したりできるため、^{[97] [98]}エンドツーエンドの原則が破られます。^[99]ある測定によると、インターネット上のパスの3分の1は、TCPメタデータを変更する少なくとも1つの仲介者に遭遇し、パスの6.5%は仲介者による有害な骨化の影響に遭遇しています。^{[100]仲介者による拡張性ハザードを回避することは、} MPTCPの設計に大きな制約を課し、^{[101] [102]仲介者によって引き起こされる困難は、}ウェブブラウザでのTCP Fast Openの展開を妨げてきました。^{[103]骨化のもう1つの原因は、エンドポイント、通常は}オペレーティングシステムカーネル^[104]またはTCPオフロードエンジンを備えたハードウェアでのTCP機能の変更の難しさです。^[105]

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

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

TCP スループットはパケットの並べ替えの影響を受けます。並べ替えられたパケットは重複した確認応答の送信を引き起こし、しきい値を超えると、偽の再送信と輻輳制御がトリガーされます。また、範囲の先頭で並べ替えられたパケットを受信すると、大きな範囲が一度に確認応答されるため、送信動作がスムーズでなくなり、バースト的になることもあります (ヘッドオブライン ブロッキングがアプリケーションに及ぼす影響と同様です)。^[117] Blanton と Allman (2002) は、スループットは並べ替えの量と反比例関係にあり、並べ替えのすべてが偽の再送信をトリガーする限界に達することを発見しました。^[118]並べ替えの緩和は、送信者が偽の再送信を送信したことを判断できるかどうか、つまり再送信のあいまいさを解決できるかどうかに依存します。^[119]並べ替えによって引き起こされる偽の再送信を減らすことは、真の損失からの迅速な回復とトレードオフになります。^[120]

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

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

無線問題を解決するために、 Vegas、Westwood、Veno、Santa Cruzなどの代替輻輳制御アルゴリズムが数多く提案されている。 ^{[引用が必要]}

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

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

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

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

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

歴史的およびパフォーマンス上の理由から、ほとんどのストレージ エリア ネットワーク(SAN)では、ファイバー チャネル接続を介してファイバー チャネル プロトコル(FCP)が使用されます。

また、組み込みシステム、ネットワーク ブート、および膨大な数のクライアントからの単純な要求を処理するサーバー ( DNSサーバーなど) では、TCP の複雑さが問題になることがあります。最後に、 NAT ( STUNまたは同様のシステムを使用)の背後にある 2 つのホスト間でデータを送信するなどのトリックは、TCP のような比較的複雑なプロトコルを介さない方がはるかに簡単です。

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

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

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

TCP は、高帯域幅の環境でも問題を抱えています。TCP輻輳回避アルゴリズムは、データの送信者が事前にわからないアドホック環境では非常にうまく機能します。環境が予測可能な場合は、非同期転送モード(ATM)などのタイミングベースのプロトコルによって、TCP の再送信オーバーヘッドを回避できます。

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

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

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

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

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

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

送信元アドレス: 32 ビット

IPv4ヘッダーの送信元アドレス

宛先アドレス: 32 ビット

IPv4 ヘッダー内の宛先アドレス。

ゼロ: 8 ビット; ゼロ == 0

すべてゼロです。

プロトコル: 8 ビット

TCP のプロトコル値: 6。

TCP 長さ: 16 ビット

TCP ヘッダーとデータの長さ (オクテット単位で測定)。たとえば、合計長が 200 バイトで IHL 値が 5 の IPv4 パケットがあるとします。これは、長さが 5 × 32 ビット = 160 ビット = 20 バイトであることを示します。TCP の長さは、つまりとして計算でき、結果はバイトになります。${\displaystyle {\text{合計長}}-{\text{IPv4 ヘッダー長}}}$${\displaystyle {\text{200}}-{\text{20}}}$${\displaystyle 180}$

TCPがIPv6上で実行される場合、チェックサムを計算するために使用される方法が変更されます。^[129]

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

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

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

送信元アドレス: 128 ビット

IPv6 ヘッダー内のアドレス。

宛先アドレス: 128 ビット

最終宛先。IPv6 パケットにルーティング ヘッダーが含まれていない場合、TCP は IPv6 ヘッダー内の宛先アドレスを使用します。それ以外の場合、発信元ノードではルーティング ヘッダーの最後の要素内のアドレスを使用し、受信側ノードでは IPv6 ヘッダー内の宛先アドレスを使用します。

TCP 長さ: 32 ビット

TCP ヘッダーとデータの長さ (オクテット単位で測定)。

ゼロ: 24 ビット; ゼロ == 0

すべてゼロです。

次のヘッダー: 8 ビット

TCP のプロトコル値: 6。

多くの TCP/IP ソフトウェア スタック実装では、ネットワークに送信する前、またはネットワークから受信して検証するときに、ハードウェア アシスタンスを使用してネットワーク アダプタでチェックサムを自動的に計算するオプションが提供されています。これにより、OS がチェックサムを計算するために貴重な CPU サイクルを使用する必要がなくなります。したがって、全体的なネットワーク パフォーマンスが向上します。

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

• Cerf, Vint ; Dalal, Yogen ; Sunshine, Carl (1974年12 月)。インターネット伝送制御プログラムの仕様、1974 年 12 月バージョン。doi : 10.17487/ RFC0675。RFC 675 。
• Postel, Jon (1981 年 9 月). インターネット プロトコル. doi : 10.17487/RFC0791 . RFC 791.
• Postel, Jon (1981 年 9 月). 伝送制御プロトコル. doi : 10.17487/RFC0793 . RFC 793.
• Braden, Robert編(1989 年 10 月)。インターネット ホストの要件 - 通信層。doi : 10.17487/ RFC1122。RFC 1122 。
• Jacobson , Van ; Braden, Bob ; Borman, Dave (1992 年 5 月)。高パフォーマンスのための TCP 拡張。doi : 10.17487/ RFC1323。RFC 1323 。
• Bellovin, Steven M. (1996 年5月)。シーケンス番号攻撃に対する防御。doi : 10.17487/ RFC1948。RFC 1948 。
• Mathis, Matt; Mahdavi, Jamshid; Floyd, Sally; Romanow, Allyn (1996 年 10 月)。TCP 選択的確認応答オプション。doi : 10.17487 / RFC2018。RFC 2018 。
• Allman, Mark; Paxson, Vern ; Stevens, W. Richard (1999 年 4 月)。TCP 輻輳制御。doi : 10.17487 / RFC2581。RFC 2581 。
• Floyd, Sally ; Mahdavi, Jamshid; Mathis, Matt; Podolsky, Matthew (2000 年 7 月)。TCP の選択的確認応答 (SACK) オプションの拡張。doi : 10.17487 / RFC2883。RFC 2883 。
• Ramakrishnan, KK; Floyd, Sally ; Black, David ( 2001 年 9 月)。IP への明示的輻輳通知 (ECN) の追加。doi : 10.17487/ RFC3168。RFC 3168 。
• Ludwig , Reiner; Meyer, Michael (2003 年 4 月)。TCP の Eifel 検出アルゴリズム。doi : 10.17487/ RFC3522。RFC 3522 。
• Spring , Neil; Weatherall, David; Ely, David (2003 年 6 月)。ノンスを使用した堅牢な明示的輻輳通知 (ECN) シグナリング。doi : 10.17487/ RFC3540。RFC 3540 。
• Allman, Mark; Paxson, Vern ; Blanton, Ethan (2009 年 9 月)。TCP 輻輳制御。doi : 10.17487 / RFC5681。RFC 5681 。
• Simpson, William Allen (2011 年 1 月). TCP Cookie トランザクション (TCPCT). doi : 10.17487/RFC6013 . RFC 6013.
• Ford, Alan; Raiciu, Costin; Handley, Mark ; Barre, Sebastien; Iyengar, Janardhan ( 2011 年 3 月)。マルチパス TCP 開発のアーキテクチャ ガイドライン。doi : 10.17487/ RFC6182。RFC 6182 。
• Paxson, Vern ; Allman, Mark; Chu, HK Jerry; Sargent, Matt (2011 年 6 月)。TCP の再送信タイマーの計算。doi : 10.17487/ RFC6298。RFC 6298 。
• Ford, Alan; Raiciu, Costin; Handley, Mark ; Bonaventure, Olivier ( 2013 年 1 月)。複数アドレスでのマルチパス操作のための TCP 拡張。doi : 10.17487/ RFC6824。RFC 6824 。
• Mathis, Matt; Dukkipati, Nandita; Cheng, Yuchung (2013 年 5 月)。TCP の比例レート削減。doi : 10.17487 / RFC6937。RFC 6937 。
• Borman, David; Braden, Bob ; Jacobson, Van (2014 年 9 月). Scheffenegger, Richard (編). 高性能のための TCP 拡張. doi : 10.17487/RFC7323 . RFC 7323.
• Duke, Martin; Braden, Robert ; Eddy, Wesley M.; Blanton, Ethan; Zimmermann, Alexander (2015 年 2 月)。伝送制御プロトコル (TCP) 仕様ドキュメントのロードマップ。doi : 10.17487 / RFC7414。RFC 7414 。
• チェン、ユチュン。チュー、ジェリー。ラダクリシュナン、シヴァサンカール。ジャイナ教、アルビンド（2014 年 12 月）。 TCP高速オープン。土井: 10.17487/RFC7413。RFC 7413。
• Zimmermann , Alexander; Eddy, Wesley M.; Eggert, Lars (2016 年 4 月)。古くなった TCP 拡張機能および TCP 関連ドキュメントを履歴または情報ステータスに移行する。doi : 10.17487/ RFC7805。RFC 7805 。
• Fairhurst, Gorry、 Trammell , Brian、Kuehlewind, Mirja 編 (2017 年 3 月)。IETF トランスポート プロトコルおよび輻輳制御メカニズムによって提供されるサービス。doi : 10.17487/ RFC8095。RFC 8095 。
• Cheng, Yuchung; Cardwell, Neal; Dukkipati, Nandita; Jha, Priyaranjan , 編 (2021 年 2 月)。TCP の RACK-TLP 損失検出アルゴリズム。doi : 10.17487/ RFC8985。RFC 8985 。
• Deering , Stephen E. ; Hinden, Robert M. (2017 年 7 月)。インターネット プロトコル バージョン 6 (IPv6) 仕様。doi : 10.17487/ RFC8200。RFC 8200 。
• Trammell , Brian; Kuehlewind, Mirja (2019 年 4 月)。ネットワーク プロトコルのワイヤ イメージ。doi : 10.17487/ RFC8546。RFC 8546 。
• Hardie, Ted 編 (2019 年 4 月)。トランスポート プロトコル パス信号。doi : 10.17487 / RFC8558。RFC 8558 。
• Iyengar, Jana; Swett, Ian 編 (2021 年 5 月)。QUIC 損失検出および輻輳制御。doi : 10.17487 / RFC9002。RFC 9002 。
• Fairhurst, Gorry; Perkins, Colin (2021 年 7 月)。トランスポート ヘッダーの機密性、ネットワーク操作、およびインターネット トランスポート プロトコルの進化に関する考慮事項。doi : 10.17487 / RFC9065。RFC 9065 。
• Thomson , Martin; Pauly, Tommy (2021 年 12 月)。プロトコル拡張メカニズムの長期的な実行可能性。doi : 10.17487/ RFC9170。RFC 9170 。
• Eddy, Wesley M. 編 (2022 年 8 月)。伝送制御プロトコル (TCP)。doi : 10.17487 / RFC9293。RFC 9293 。

• Allman, Mark; Paxson , Vern (1999 年 10 月)。「エンドツーエンドのネットワーク パス プロパティの推定について」。ACM SIGCOMM Computer Communication Review。29 (4): 263–274。doi : 10.1145 /316194.316230。hdl : 2060/20000004338。
• Bhat, Divyashri; Rizk, Amr; Zink, Michael (2017 年 6 月)。「それほど QUIC ではない: QUIC 上の DASH のパフォーマンス調査」。NOSSDAV'17 : デジタル オーディオおよびビデオのネットワークとオペレーティング システムのサポートに関する第 27 回ワークショップの議事録。pp. 13–18。doi : 10.1145 /3083165.3083175。S2CID 32671949  。
• Blanton, Ethan; Allman, Mark (2002 年 1 月)。「TCP をパケットの並べ替えに対してより堅牢にする方法」( PDF)。ACM SIGCOMM Computer Communication Review。32 : 20–30。doi : 10.1145 /510726.510728。S2CID  15305731。
• Briscoe, Bob; Brunstrom, Anna; Petlund, Andreas; Hayes, David; Ros, David; Tsang, Ing-Jyh; Gjessing, Stein; Fairhurst, Gorry; Griwodz, Carsten; Welzl, Michael (2016). 「インターネット遅延の削減: 技術とそのメリットの調査」. IEEE Communications Surveys & Tutorials . 18 (3): 2149–2196. doi :10.1109/COMST.2014.2375213. hdl : 2164/8018 . S2CID  206576469.
• Bruyeron, Renaud; Hemon , Bruno; Zhang, Lixa (1998 年 4 月)。「TCP 選択的確認応答の実験」。ACM SIGCOMM コンピュータ通信レビュー。28 ( 2): 54–77。doi : 10.1145 /279345.279350。S2CID  15954837。
• Chen, Shan; Jero, Samuel; Jagielski, Matthew; Boldyreva, Alexandra; Nita-Rotaru, Cristina (2021). 「セキュア通信チャネルの確立: TLS 1.3 (Over TCP Fast Open) と QUIC」。Journal of Cryptology . 34 (3). doi : 10.1007/s00145-021-09389-w . S2CID  235174220。
• Corbet, Jonathan (2015 年 12 月 8 日)。「チェックサム オフロードとプロトコルの骨化」。LWN.net。
• Corbet, Jonathan (2018 年 1 月 29 日)。「プロトコルの骨化に対する解決策としての QUIC」。LWN.net。
• Edeline, Korian; Donnet, Benoit (2019)。トランスポート層の骨化に関するボトムアップ調査。2019 ネットワーク トラフィック測定および分析会議 (TMA)。doi :10.23919/TMA.2019.8784690。
• Ghedini, Alessandro (2018 年 7 月 26 日)。「QUIC への道」。Cloudflare。
• Gurtov, Andrei; Floyd, Sally (2004 年 2 月)。非 SACK TCP における確認応答の曖昧さの解決(PDF)。次世代テレトラフィックおよび有線/無線高度ネットワーキング (NEW2AN'04)。
• Gurtov, Andrei; Ludwig, Reiner (2003)。TCP での誤ったタイムアウトへの対応(PDF)。IEEE INFOCOM 2003。IEEE コンピュータおよび通信学会の第 22 回年次合同会議。doi : 10.1109/INFCOM.2003.1209251。
• Hesmans, Benjamin; Duchene, Fabien; Paasch, Christoph; Detal, Gregory; Bonaventure, Olivier (2013). TCP 拡張機能はミドルボックス耐性がありますか? HotMiddlebox '13. CiteSeerX  10.1.1.679.6364 . doi :10.1145/2535828.2535830.
• IETF HTTP ワーキング グループ。「HTTP/2 よくある質問」。
• Karn, Phil ; Partridge, Craig (1991年11 月)。「信頼性の高いトランスポート プロトコルにおける往復時間の推定値の改善」。ACM Transactions on Computer Systems。9 ( 4): 364–373。doi : 10.1145/118544.118549。
• Ludwig, Reiner、Katz, Randy Howard (2000 年 1 月)。「Eifel アルゴリズム: 誤った再送信に対して TCP を堅牢にする」ACM SIGCOMM Computer Communication Review。doi : 10.1145 /505688.505692。
• Marx, Robin (2020 年 12 月 3 日)。「QUIC および HTTP/3 におけるヘッドオブライン ブロッキング: 詳細」。
• Paasch , Christoph; Bonaventure, Olivier (2014 年 4 月 1 日)。「マルチパス TCP」。Communications of the ACM。57 ( 4): 51–57。doi :10.1145/2578901。S2CID 17581886  。
• Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna; Grinnemo, Karl-Johan; Hurtig, Per; Khademi, Naeem; Tüxen, Michael; Welzl, Michael; Damjanovic, Dragana; Mangiante, Simone (2017). 「インターネット トランスポート層の骨化の解消: 調査と今後の展望」. IEEE Communications Surveys & Tutorials . 19 : 619–639. doi :10.1109/COMST.2016.2626780. hdl : 2164/8317 . S2CID  1846371.
• Rybczyńska, Marta (2020 年 3 月 13 日)。「HTTP/3 の QUIC の概要」。LWN.net。
• Sy, Erik; Mueller, Tobias; Burkert, Christian; Federrath, Hannes; Fischer, Mathias (2020). 「TCP Fast Open 経由の TLS のパフォーマンスとプライバシーの強化」プライバシー強化技術に関する議事録。2020 (2): 271–287。arXiv : 1905.03518。doi : 10.2478/popets-2020-0027。
• Zhang, Lixia (1986 年8月 5 日)。「TCP タイマーがうまく動作しない理由」。ACM SIGCOMM Computer Communication Review。16 ( 3): 397–405。doi :10.1145/1013812.18216。

• スティーブンス、W. リチャード(1994-01-10)。TCP/IP 図解、第 1 巻: プロトコル。Addison-Wesley Pub. Co. ISBN 978-0-201-63346-7。
• Stevens, W. Richard; Wright, Gary R (1994)。TCP/IP Illustrated, Volume 2: The Implementation。Addison- Wesley。ISBN 978-0-201-63354-2。
• Stevens, W. Richard (1996)。TCP /IP Illustrated、第 3 巻:トランザクション、HTTP、NNTP、および UNIX ドメイン プロトコルの TCP。Addison -Wesley。ISBN 978-0-201-63495-2。**

• ロバート・E・カーン氏による口述歴史インタビュー
• IANA ポート割り当て
• IANA TCP パラメータ
• John Kristoff による TCP の概要 (TCP の背後にある基本概念と、2 つのエンドポイント間でデータを転送するために TCP がどのように使用されるか)
• チェックサムの例