伝送制御プロトコル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

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

歴史的起源

1974年5月、VintCerfBobKahnは、ネットワークノード間でパケット交換を使用してリソースを共有するためのインターネットワーキングプロトコルについて説明しました。[1]著者は、ジェラール・ル・ランと協力して、フランスのCYCLADESプロジェクトのコンセプトを新しいネットワークに組み込んでいました。[2]結果として得られたプロトコルの仕様RFC675インターネット伝送制御プログラムの仕様)は、Vint Cerf、Yogen Dalal、Carl Sunshineによって作成され1974年12月に公開されました。これにはインターネットという用語の最初の証明された使用法が含まれています。 インターネットワークの省略形として。[3]

このモデルの中心的な制御コンポーネントは、コネクション型リンクとホスト間のデータグラムサービスの両方を組み込んだ伝送制御プログラムでした。モノリシック伝送制御プログラムは、後に伝送制御プロトコルインターネットプロトコルで構成されるモジュラーアーキテクチャに分割されましたその結果、非公式にTCP / IPとして知られるようになったネットワークモデルが生まれましたが、正式には国防総省(DOD)モデルやARPANETモデル、そして最終的にはインターネットプロトコルスイートとも呼ばれていました。

2004年、VintCerfBobKahnは、TCP / IPの基礎的な作業に対してチューリング賞を受賞しました。[4] [5]

ネットワーク機能

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

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

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

TCPは、タイムリーな配信ではなく正確な配信用に最適化されており、順序が正しくないメッセージや失われたメッセージの再送信を待機している間、比較的長い遅延(秒単位)が発生する可能性があります。したがって、 Voice overIPなどのリアルタイムアプリケーションには特に適していませんこのようなアプリケーションでは、通常、ユーザーデータグラムプロトコル(UDP)上で動作するReal-time Transport Protocol(RTP)などのプロトコルが代わりに推奨されます。[6]

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

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

TCPセグメント構造

Transmission Control Protocolは、データストリームからデータを受け取り、それをチャンクに分割し、TCPヘッダーを追加してTCPセグメントを作成します。次に、TCPセグメントはインターネットプロトコル(IP)データグラムにカプセル化され、ピアと交換されます。[7]

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

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

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

TCPセグメントヘッダー
オフセット オクテット 0 1 2 3
オクテット 少し  7  6  5  4  3  2  1  0  7  6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
0 0 ソースポート 宛先ポート
4 32 シーケンス番号
8 64 確認番号(ACKが設定されている場合)
12 96 データオフセット 予約済み
00 0
NS
CWR
ECE
URG
ACK
PSH
RST
SYN
フィン
ウィンドウサイズ
16 128 チェックサム 緊急ポインタ(URGが設定されている場合)
20
160
オプション(データオフセット> 5の場合。必要に応じて、最後に「0」ビットが埋め込まれます。)
60 480
ソースポート(16ビット)
送信ポートを識別します。
宛先ポート(16ビット)
受信ポートを識別します。
シーケンス番号(32ビット)
二重の役割があります:
  • SYNフラグが設定されている場合(1)、これは初期シーケンス番号です。実際の最初のデータバイトのシーケンス番号と対応するACKの確認済み番号は、このシーケンス番号に1を加えたものになります。
  • SYNフラグがクリア(0)の場合、これは現在のセッションのこのセグメントの最初のデータバイトの累積シーケンス番号です。
確認番号(32ビット)
ACKフラグが設定されている場合、このフィールドの値は、ACKの送信者が予期している次のシーケンス番号です。これにより、前のすべてのバイト(存在する場合)の受信が確認されます。各エンドによって送信される最初のACKは、もう一方のエンドの初期シーケンス番号自体を確認しますが、データは確認しません。
データオフセット(4ビット)
TCPヘッダーのサイズを32ビットワードで指定します。最小サイズのヘッダーは5ワード、最大サイズは15ワードであるため、最小サイズは20バイト、最大サイズは60バイトであり、ヘッダーに最大40バイトのオプションを使用できます。このフィールドの名前は、TCPセグメントの開始から実際のデータへのオフセットでもあるという事実から付けられています。
予約済み(3ビット)
将来の使用のために、ゼロに設定する必要があります。
フラグ(9ビット)
次のように9つの1ビットフラグ(制御ビット)が含まれています。
  • NS(1ビット):ECN-ノンス-隠蔽保護[a]
  • CWR(1ビット):輻輳ウィンドウ削減(CWR)フラグは、ECEフラグが設定されたTCPセグメントを受信し、輻輳制御メカニズムで応答したことを示すために送信ホストによって設定されます。[b]
  • ECE(1ビット):ECN-Echoには、SYNフラグの値に応じて2つの役割があります。それは次のことを示しています。
  • SYNフラグが設定されている場合(1)、TCPピアはECN対応です。
  • SYNフラグがクリア(0)の場合、IPヘッダーにCongestion Experiencedフラグが設定されているパケット(ECN = 11)が、通常の送信中に受信されたことを示します。[b]これは、TCP送信側へのネットワーク輻輳(または差し迫った輻輳)の指標として機能します。
  • URG(1ビット):緊急ポインタフィールドが重要であることを示します
  • ACK(1ビット):確認応答フィールドが重要であることを示します。クライアントによって送信された最初のSYNパケット以降のすべてのパケットには、このフラグを設定する必要があります。
  • PSH(1ビット):プッシュ機能。バッファリングされたデータを受信側アプリケーションにプッシュするように要求します。
  • RST(1ビット):接続をリセットします
  • SYN(1ビット):シーケンス番号を同期します。このフラグを設定する必要があるのは、両端から送信される最初のパケットだけです。他のいくつかのフラグとフィールドは、このフラグに基づいて意味を変更し、設定されている場合にのみ有効なものと、クリアされている場合にのみ有効なものがあります。
  • FIN(1ビット):送信者からの最後のパケット
ウィンドウサイズ(16ビット)
受信ウィンドウのサイズ。これは、このセグメントの送信者が現在受信しようとしているウィンドウサイズ単位[c]の数を指定します。[d]§フロー制御および§ウィンドウスケーリングを参照してください。)
チェックサム(16ビット)
16ビットのチェックサムフィールドは、TCPヘッダー、ペイロード、およびIP疑似ヘッダーのエラーチェックに使用されます。疑似ヘッダーは、送信元IPアドレス宛先IPアドレス、TCPプロトコルのプロトコル番号(6)、およびTCPヘッダーとペイロードの長さ(バイト単位)で構成されます。
緊急ポインタ(16ビット)
URGフラグが設定されている場合、この16ビットフィールドは、最後の緊急データバイトを示すシーケンス番号からのオフセットです。
オプション(変数0〜320ビット、32ビット単位)
このフィールドの長さは、データオフセットによって決まります分野。オプションには、最大3つのフィールドがあります。Option-Kind(1バイト)、Option-Length(1バイト)、Option-Data(変数)。Option-Kindフィールドはオプションのタイプを示し、オプションではない唯一のフィールドです。Option-Kindの値によっては、次の2つのフィールドが設定される場合があります。Option-Lengthはオプションの全長を示し、Option-Dataには、該当する場合、オプションに関連付けられたデータが含まれます。たとえば、Option-Kindバイトが1の場合、これはパディングにのみ使用される操作なしのオプションであり、その後にOption-LengthまたはOption-Dataフィールドがないことを示します。Option-Kindバイト0は、オプションの終わりを示し、1バイトのみです。2のOption-Kindバイトは、最大セグメントサイズオプションを示すために使用され、その後にMSSフィールドの長さを指定するOption-Lengthバイトが続きます。Option-Lengthは、Option-KindフィールドとOption-Lengthフィールドを含む、指定されたオプションフィールドの全長です。したがって、MSS値は通常2バイトで表されますが、Option-Lengthは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 ウィンドウスケール 詳細については、 §ウィンドウスケーリングを参照してください[10] [SYN]
4 2 該当なし 選択的承認が許可されました 詳細については、 §選択的謝辞を参照してください[11][SYN]
5 N(10、18、26、または34) BBBB、EEEE、..。 選択的確認(SACK)[12] これらの最初の2バイトの後には、32ビットの開始/終了ポインターとして指定された、選択的に確認応答される1〜4ブロックのリストが続きます。
8 10 TTTT、EEEE 以前のタイムスタンプのタイムスタンプとエコー 詳細については、§TCPタイムスタンプを参照してください[13]
残りのOption-Kind値は、履歴、廃止、実験的、まだ標準化されていない、または割り当てられていません。オプション番号の割り当ては、IANAによって維持されます。[14]
パディング
TCPヘッダーのパディングは、TCPヘッダーが32ビット境界で終了し、データが開始されるようにするために使用されます。パディングはゼロで構成されます。[15]

プロトコル操作

簡略化されたTCP状態図。ESTABLISHED状態内の状態を含むより詳細な状態図については、TCPEFSM図を参照してください。

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

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

TCPソケットの状態
終点 説明
聞く サーバ リモートTCPエンドポイントからの接続要求を待機しています。
SYN-SENT クライアント 接続要求を送信した後、一致する接続要求を待機しています。
SYN受信 サーバ 接続要求の受信と送信の両方を行った後、接続要求の確認応答を待機しています。
設立 サーバーとクライアント オープン接続で、受信したデータをユーザーに配信できます。接続のデータ転送フェーズの通常の状態。
FIN-WAIT-1 サーバーとクライアント リモートTCPからの接続終了要求、または以前に送信された接続終了要求の確認応答を待機しています。
FIN-WAIT-2 サーバーとクライアント リモートTCPからの接続終了要求を待機しています。
クローズウェイト サーバーとクライアント ローカルユーザーからの接続終了要求を待機しています。
閉鎖 サーバーとクライアント リモートTCPからの接続終了要求の確認応答を待機しています。
LAST-ACK サーバーとクライアント 以前にリモートTCPに送信された接続終了要求の確認応答(接続終了要求の確認応答を含む)を待機しています。
タイムウェイト サーバーまたはクライアント リモートTCPが接続終了要求の確認応答を受信したことを確認するために、十分な時間が経過するのを待っています。[e]
閉まっている サーバーとクライアント 接続状態はまったくありません。

接続確立

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

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

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

接続終了

接続の終了

接続終了フェーズでは、接続の両側が個別に終了する4方向ハンドシェイクを使用します。エンドポイントが接続の半分を停止したい場合、エンドポイントはFINパケットを送信し、もう一方の端はACKで確認します。したがって、通常のティアダウンには、各TCPエンドポイントからのFINセグメントとACKセグメントのペアが必要です。最初のFINを送信した側が最後のACKで応答した後、タイムアウトを待ってから最終的に接続を閉じます。その間、ローカルポートは新しい接続に使用できません。これにより、前の接続に関連付けられた遅延パケットが後続の接続中に配信された場合に発生する可能性のある混乱を防ぐことができます。

ホストAがFINを送信し、ホストBがFINとACK(2つのステップを1つに結合)で応答し、ホストAがACKで応答する場合、3ウェイハンドシェイクによって接続を終了することもできます。[17]

LinuxHP-UXなどの一部のオペレーティングシステム[要出典]は、半二重のクローズシーケンスを実装しています。ホストがアクティブに接続を閉じ、未読の着信データを利用できる場合、ホストはFINではなく信号RST(受信データを失う)を送信します。これにより、TCPアプリケーションがデータの損失を認識していることが保証されます。[18]

接続はハーフオープン状態にすることができます。その場合、一方の側は接続を終了しますが、もう一方の側は終了しません。終了した側は接続にデータを送信できなくなりますが、反対側は送信できます。終了側は、もう一方の側も終了するまでデータの読み取りを続行する必要があります。[要出典]

リソース使用量

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

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

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

データ転送

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

  • 順序付けられたデータ転送:宛先ホストは、シーケンス番号[6]に従ってセグメントを再配置します。
  • 失われたパケットの再送信:確認応答されていない累積ストリームは再送信されます[6]
  • エラーのないデータ転送:破損したパケットは失われたものとして扱われ、再送信されます[19]
  • フロー制御:送信者がデータを転送する速度を制限して、信頼できる配信を保証します。受信者は、受信できるデータの量を送信者に継続的に通知します。受信側ホストのバッファがいっぱいになると、次の確認応答によって転送が一時停止され、バッファ内のデータを処理できるようになります。[6]
  • 輻輳制御:失われたパケット(輻輳が原因と推定される)は、データ配信速度の低下を引き起こします[6]

信頼性の高い送信

TCPは、シーケンス番号を使用してデータの各バイトを識別します。シーケンス番号は、各コンピューターから送信されるバイトの順序を識別します。これにより、発生する可能性のある順不同の配信に関係なく、データを順番に再構築できます。最初のバイトのシーケンス番号は、SYNのフラグが立てられた最初のパケットの送信機によって選択されます。この数は任意である可能性があり、実際、 TCPシーケンス予測攻撃から防御するために予測できないはずです。

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

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

Dupackベースの再送信

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

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

送信者がセグメントを送信すると、確認応答の到着時間の控えめな見積もりでタイマーが初期化されます。タイマーが期限切れになると、セグメントは前の値の2倍の新しいタイムアウトしきい値で再送信され、指数バックオフ動作が発生します。通常、タイマーの初期値は、 どこクロックの粒度です。[21]これは、 man-in-the-middle サービス拒否攻撃者 などの欠陥のあるまたは悪意のあるアクターによる過剰な送信トラフィックから保護します。

エラー検出

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

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

フロー制御

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

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

TCPシーケンス番号と受信ウィンドウは、時計のように動作します。受信ウィンドウは、受信者がデータの新しいセグメントを受信して​​確認するたびにシフトします。シーケンス番号がなくなると、シーケンス番号は0にループバックします。

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

受信者が着信データを少しずつ処理している場合、小さな受信ウィンドウを繰り返しアドバタイズする可能性があります。TCPヘッダーのオーバーヘッドが比較的大きいため、TCPセグメントで数バイトのデータのみを送信するのは非効率的であるため、 これは愚かなウィンドウ症候群と呼ばれます。

輻輳制御

TCPの最後の主要な側面は、輻輳制御です。TCPは、ネットワークパフォーマンスが数桁低下する可能性がある、高いパフォーマンスを実現し、輻輳の崩壊を回避するために、いくつかのメカニズムを使用しています。これらのメカニズムは、ネットワークに入るデータの速度を制御し、データフローを崩壊を引き起こす速度以下に保ちます。また、フロー間 でほぼ最大最小の公平な割り当てが得られます。

送信されたデータの確認応答、または確認応答の欠如は、TCP送信者と受信者の間のネットワーク状態を推測するために送信者によって使用されます。タイマーと組み合わせると、TCP送信者と受信者はデータフローの動作を変更できます。これは、より一般的には、輻輳制御および/またはネットワーク輻輳回避と呼ばれます。

TCPの最新の実装には、スロースタート輻輳回避高速再送信、および高速リカバリの4つの絡み合ったアルゴリズムが含まれています(RFC5681)。

さらに、送信者は、送信者と受信者の間の推定ラウンドトリップ時間(またはRTT)、およびこのラウンドトリップ時間の変動に基づく再送信タイムアウト(RTO)を採用します。このタイマーの動作はRFC6298で指定されています。RTTの見積もりには微妙な点があります。たとえば、送信者は、再送信されたパケットのRTTサンプルを計算するときに注意する必要があります。通常、カーンのアルゴリズムまたはTCPタイムスタンプを使用します(RFC 1323を参照)。次に、これらの個々のRTTサンプルを時間の経過とともに平均して、Jacobsonのアルゴリズムを使用してSmoothed Round Trip Time(SRTT)を作成します。このSRTT値は、最終的にラウンドトリップ時間の見積もりとして使用される値です。

TCPを強化して、損失を確実に処理し、エラーを最小限に抑え、輻輳を管理し、非常に高速な環境で高速化することは、研究と標準開発の継続的な分野です。その結果、TCP輻輳回避アルゴリズムのバリエーションがいくつかあります。

最大セグメントサイズ

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

MSSの発表は、「MSSネゴシエーション」とも呼ばれます。厳密に言えば、MSSは発信者と受信者の間で「ネゴシエート」されません。これは、発信者と受信者の両方が、接続の両方向のすべての通信に適用される単一の統合MSSをネゴシエートして合意することを意味するためです。実際、TCP接続のデータフローの2つの方向に対して、MSSの2つの完全に独立した値が許可されています。[23]この状況は、たとえば、接続に参加しているデバイスの1つが、着信TCPセグメントを処理するために予約されているメモリの量が非常に限られている場合(おそらく検出されたパスMTU全体よりもさらに少ない場合)に発生する可能性があります。

選択的な謝辞

元の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月にRFC2883で定義されたSACKオプションの拡張であるduplicate-SACKオプションは、この問題を解決します。TCP受信者はD-ACKを送信して、セグメントが失われていないことを示します。その後、TCP送信者はより高い伝送速度に戻すことができます。

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

ウィンドウスケーリング

高帯域幅ネットワークをより効率的に使用するために、より大きなTCPウィンドウサイズを使用できます。TCPウィンドウサイズフィールドはデータのフローを制御し、その値は2〜65,535バイトに制限されます。

サイズフィールドは拡張できないため、倍率が使用されます。RFC 1323で定義されているTCPウィンドウスケールオプションは、最大ウィンドウサイズを65,535バイトから1ギガバイトに増やすために使用されるオプションです。より大きなウィンドウサイズへのスケールアップは、TCPチューニングに必要なものの一部です。

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

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

TCPタイムスタンプ

1992年にRFC1323で定義されたTCPタイムスタンプは、TCPがパケットが送信された順序を判別するのに役立ちます。TCPタイムスタンプは通常、システムクロックに合わせられておらず、ランダムな値で開始されます。多くのオペレーティングシステムは、経過したミリ秒ごとにタイムスタンプをインクリメントします。ただし、RFCは、ティックは比例する必要があると述べているだけです。

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

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

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

また、Eifel検出アルゴリズム(RFC 3522)は、TCPタイムスタンプを使用して、パケットが失われたため、または単に順序が狂ったために再送信が発生しているかどうかを判断します。

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

TCPタイムスタンプはLinuxカーネルではデフォルトで有効になっており[26]、Windows Server 2008、2012、2016ではデフォルトで無効になっています。[27]

帯域外データ

ストリームが終了するのを待つ代わりに、キューに入れられたストリームを中断または中止することができます。これは、データを緊急として指定することによって行われます。これは、受信プログラムに、残りの緊急データとともに、それをすぐに処理するように指示します。終了すると、TCPはアプリケーションに通知し、ストリームキューに戻ります。たとえば、リモートログインセッションにTCPが使用されている場合、ユーザーは、もう一方の端でプログラムを中断または中止するキーボードシーケンスを送信できます。これらの信号は、リモートマシン上のプログラムが正しく動作しない場合に最も頻繁に必要になります。プログラムが現在の転送を終了するのを待たずに、信号を送信する必要があります。[6]

TCP帯域外データは、最新のインターネット用に設計されていません。緊急ポインタは、リモートホストでの処理を変更するだけで、ネットワーク自体での処理を促進しません。リモートホストに到達するとき、プロトコルの2つのわずかに異なる解釈があります。これは、1バイトのOOBデータのみが信頼できることを意味します。これは、最も一般的に使用されていないプロトコル要素の1つであり、実装が不十分である傾向があるため、信頼性が高いことを前提としています。[28] [29]

データ配信の強制

通常、TCPはデータの完全なパケットが送信されるまで200ミリ秒待機します(Nagleのアルゴリズムは小さなメッセージを単一のパケットにグループ化しようとします)。この待機は、ファイル転送中に絶えず繰り返される場合、小さいながらも深刻な遅延を引き起こす可能性があります。たとえば、一般的な送信ブロックは4 KB、一般的なMSSは1460であるため、2つのパケットが10 Mbit / sイーサネットで送信されます。バッファがいっぱいになるのを待っています。

telnetの場合、ユーザーが画面に表示する前に、各ユーザーのキーストロークがサーバーによってエコーバックされます。この遅延は非常に厄介になります。

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

RFCは、PSHプッシュビットを「このデータを受信側アプリケーションにすぐに送信するための受信側TCPスタックへのメッセージ」と定義しています。[6]バークレーソケットを使用してユーザースペースでそれを示したり制御したりする方法はなく、プロトコルスタックによってのみ制御されます[30]

脆弱性

TCPはさまざまな方法で攻撃される可能性があります。TCPの徹底的なセキュリティ評価の結果は、特定された問題の可能な緩和策とともに、2009年に公開され[31]、現在は[いつ?] IETF内で追求されています。[32]

サービス拒否

スプーフィングされたIPアドレスを使用し、意図的に組み立てられたSYNパケットを繰り返し送信し、その後に多数のACKパケットを送信することにより、攻撃者はサーバーに偽の接続を追跡するために大量のリソースを消費させる可能性があります。これはSYNフラッド攻撃として知られています。この問題に対して提案されている解決策には、SYN Cookieと暗号化パズルが含まれますが、SYNCookieには独自の脆弱性があります。[33] Sockstressも同様の攻撃であり、システムリソース管理によって軽減される可能性があります。[34] TCP Persist Timerの悪用を含む高度なDoS攻撃が、Phrack#66で分析されました。[35] PUSHおよびACKフラッドは他のバリアントです。[36]

接続ハイジャック

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

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

TCP拒否

送信される次のパケットのサイズを盗聴して予測できる攻撃者は、既存の接続を中断することなく、受信者に悪意のあるペイロードを受け入れさせる可能性があります。攻撃者は、次に予想されるパケットのシーケンス番号とペイロードサイズを使用して悪意のあるパケットを挿入します。正当なパケットが最終的に受信されると、すでに受信されたパケットと同じシーケンス番号と長さであることがわかり、通常の重複パケットとしてサイレントにドロップされます。正当なパケットは悪意のあるパケットによって「拒否」されます。接続ハイジャックとは異なり、悪意のあるペイロードが受け入れられた後、接続が非同期化されることはなく、通信は通常どおり続行されます。TCP拒否権を使用すると、攻撃者は通信を制御できなくなりますが、攻撃は特に検出されにくくなります。ACKストームによるネットワークトラフィックの大幅な増加は回避されます。何かが間違っているという受信者への唯一の証拠は、IPネットワークで通常発生する単一の重複パケットです。拒否されたパケットの送信者は、攻撃の証拠を見ることはありません。[38]

もう1つの脆弱性は、TCPリセット攻撃です。

TCPポート

TCPとUDPは、ポート番号を使用して、インターネットソケットと呼ばれることが多いホスト上のアプリケーションエンドポイントの送受信を識別しますTCP接続の両側には、送信または受信アプリケーションによって予約された16ビットの符号なしポート番号(0〜65535)が関連付けられています。到着するTCPパケットは、そのソケット、つまり、送信元ホストアドレス、送信元ポート、宛先ホストアドレス、および宛先ポートの組み合わせによって、特定のTCP接続に属していると識別されます。これは、クライアントが異なる送信元ポートから1つの宛先ポートへの同時接続の開始を処理する限り、サーバーコンピューターが複数のクライアントに複数のサービスを同時に提供できることを意味します。

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

ネットワークアドレス変換(NAT)は通常、(「インターネット向け」)パブリック側で動的ポート番号を使用して、パブリックネットワークとプライベートサブネットワークの間を通過するトラフィックの流れを明確にし、それによって多くのIPアドレス(およびそれらのポート)は、単一の公開アドレスによってサービスされるサブネット上にあります。

開発

TCPは複雑なプロトコルです。ただし、長年にわたって大幅な機能強化が行われ、提案されてきましたが、その最も基本的な操作は、1974年の最初の仕様RFC675および1981年9月に公開されたv4仕様RFC793以降大幅に変更されていません。RFC1122、インターネットのホスト要件ホストは、TCPプロトコルの実装要件の数を明確にしました。RFC 7414には、8つの必要な仕様と20を超える強く推奨される拡張機能のリストがあります。このリストの中にRFC 2581があり、近年最も重要なTCP関連RFCの1つであるTCP輻輳制御は、過度の輻輳を回避する更新されたアルゴリズムについて説明しています。 。2001年に、RFC 3168は、輻輳回避シグナリングメカニズムである 明示的輻輳通知( ECN )を説明するために作成されました。

元のTCP輻輳回避アルゴリズムは「TCPタホ」として知られていましたが、その後、多くの代替アルゴリズムが提案されています(TCP RenoTCP VegasFAST TCPTCP New RenoTCP Hyblaなど)。

TCP Interactive(iTCP)[39]は、アプリケーションがTCPイベントにサブスクライブし、アプリケーション支援の輻輳制御を含むさまざまな目的でアプリケーションを起動できるハンドラーコンポーネントを登録できるようにするTCP拡張機能の研究です。

マルチパスTCP(MPTCP)[40] [41]は、TCP接続が複数のパスを使用してリソース使用量を最大化し、冗長性を高めることを目的としたIETF内の継続的な取り組みです。ワイヤレスネットワークのコンテキストでマルチパスTCPによって提供される冗長性により、異なるネットワークの同時利用が可能になり、スループットが向上し、ハンドオーバー機能が向上します。マルチパスTCPは、データセンター環境でもパフォーマンス上の利点をもたらします。[42]マルチパスTCPのリファレンス実装[43]は、Linuxカーネルで開発されています。[44] マルチパスTCPは、iPhone、iPad、およびMacでSiri音声認識アプリケーションをサポートするために使用されます[45]

tcpcryptは、TCP自体で直接トランスポートレベルの暗号化を提供するために2010年7月に提案された拡張機能です。透過的に動作するように設計されており、構成は必要ありません。TLS (SSL)とは異なり、tcpcrypt自体は認証を提供しませんが、それを行うための単純なプリミティブをアプリケーションに提供します。2010年の時点で、最初のtcpcrypt IETFドラフトが公開されており、いくつかの主要なプラットフォームに実装が存在します。

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

2013年5月に提案されたProportionalRate Reduction (PRR)は、 Googleのエンジニアによって開発されたTCP拡張機能です。PRRは、リカバリ後のTCPウィンドウサイズがスロースタートしきい値に可能な限り近いことを保証します。[48]このアルゴリズムは、リカバリの速度を向上させるように設計されており、Linux3.2以降のカーネルのデフォルトの輻輳制御アルゴリズムです。[49]

非推奨の提案

TCP Cookie Transactions(TCPCT)は、サービス拒否攻撃からサーバーを保護するために2009年12月に提案された拡張機能です。SYNクッキーとは異なり、TCPCTはウィンドウスケーリングなどの他のTCP拡張機能と競合しませんTCPCTは、サーバーが多数の短期間のTCP接続を処理する必要があるDNSSECの必要性に基づいて設計されました。2016年、TCPCTは廃止され、TCP FastOpenが採用されました。元のRFCのステータスが「履歴」に変更されました。[50]

ワイヤレスネットワーク上のTCP

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

ワイヤレスの問題を解決するために、 VegasWestwood、Veno、SantaCruzなどのいくつかの代替輻輳制御アルゴリズムが提案されています。[要出典]

ハードウェアの実装

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

デバッグ

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

代替案

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

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

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

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

Stream Control Transmission Protocol(SCTP)は、TCPと同様の信頼性の高いストリーム指向サービスを提供する別のプロトコルです。これはTCPよりも新しく、かなり複雑であり、まだ広く展開されていません。ただし、信頼性とほぼリアルタイムの考慮事項が重要な状況で使用するように特に設計されています。

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

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

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

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

チェックサム計算

IPv4のTCPチェックサム

TCPがIPv4で実行される場合、チェックサムの計算に使用される方法はRFC793で定義されています。

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

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

チェックサム計算用のTCP疑似ヘッダー(IPv4)
ビットオフセット 0〜3 4–7 8〜15 16〜31
0 送信元アドレス
32 宛先アドレス
64 ゼロ プロトコル TCPの長さ
96 ソースポート 宛先ポート
128 シーケンス番号
160 確認番号
192 データオフセット 予約済み フラグ
224 チェックサム 緊急ポインタ
256 オプション(オプション)
256/288 +  
データ
 

送信元アドレスと宛先アドレスは、IPv4ヘッダーのものです。TCPのプロトコル値は6です(IPプロトコル番号のリストを参照)。TCP長さフィールドは、TCPヘッダーとデータの長さです(オクテットで測定)。

IPv6のTCPチェックサム

TCPがIPv6で実行される場合、RFC 2460に従って、チェックサムの計算に使用される方法が変更されます。

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

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

チェックサム計算用のTCP疑似ヘッダー(IPv6)
ビットオフセット 0〜7 8〜15 16〜23 24〜31
0 送信元アドレス
32
64
96
128 宛先アドレス
160
192
224
256 TCPの長さ
288 ゼロ 次のヘッダー
=プロトコル
320 ソースポート 宛先ポート
352 シーケンス番号
384 確認番号
416 データオフセット 予約済み フラグ
448 チェックサム 緊急ポインタ
480 オプション(オプション)
480/512 +  
データ
 
  • 送信元アドレス:IPv6ヘッダーにあるアドレス
  • 宛先アドレス:最終宛先。IPv6パケットにルーティングヘッダーが含まれていない場合、TCPはIPv6ヘッダーの宛先アドレスを使用します。それ以外の場合、発信元ノードでは、ルーティングヘッダーの最後の要素のアドレスを使用し、受信ノードでは、 IPv6ヘッダーの宛先アドレスを使用します。
  • TCPの長さ:TCPヘッダーとデータの長さ
  • 次のヘッダー:TCPのプロトコル値

チェックサムオフロード

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

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

RFCドキュメント

  • RFC  675 –インターネット伝送制御プログラムの仕様、1974年12月バージョン
  • RFC  793 – TCP v4
  • STD 7 –伝送制御プロトコル、プロトコル仕様
  • RFC  1122 –TCPのエラー修正が含まれています
  • RFC  1323 –高性能のためのTCP拡張[RFC7323で廃止]
  • RFC  1379 –トランザクション用のTCPの拡張—概念[RFC6247で廃止]
  • RFC  1948 –シーケンス番号攻撃に対する防御
  • RFC  2018 –TCP選択的確認応答オプション
  • RFC  5681 –TCP輻輳制御
  • RFC  6247 –アンデプロイされたTCP拡張機能RFC 1072、RFC 1106、RFC 1110、RFC 1145、RFC 1146、RFC 1379、RFC 1644、およびRFC1693を履歴ステータスに移動
  • RFC  6298 –TCPの再送信タイマーの計算
  • RFC  6824 –複数のアドレスを使用したマルチパス操作のためのTCP拡張
  • RFC  7323 –高性能のためのTCP拡張
  • RFC  7414 –TCP仕様書のロードマップ

も参照してください

メモ

  1. ^ 実験的:RFC3540を参照
  2. ^ a b RFC3168によってヘッダーに追加されました
  3. ^ Windowsサイズの単位は、デフォルトではバイトです。
  4. ^ ウィンドウサイズは、確認応答フィールドのシーケンス番号で識別されるセグメントを基準にしています。
  5. ^ RFC 793によると、接続は2つの最大セグメントライフタイム(MSL)として知られる最大4分間TIME-WAITにとどまることができます

参考文献

  1. ^ ヴィントン・G・サーフ; ロバートE.カーン(1974年5月)。パケットネットワーク相互通信のプロトコル(PDF)通信に関するIEEEトランザクション22(5):637–648。土井10.1109 /tcom.1974.10922592016年3月4日にオリジナル(PDF)からアーカイブされました。
  2. ^ ベネット、リチャード(2009年9月)。「変化のために設計された:エンドツーエンドの議論、インターネットの革新、およびネット中立性の議論」(PDF)情報技術イノベーション財団。p。11 2017年9月11日取得
  3. ^ サーフ、ヴィントン; ダラル、ヨーゲン; サンシャイン、カール(1974年12月)、 RFC 675インターネット伝送制御プロトコルの仕様 
  4. ^ 「ロバートEカーン-AMチューリング賞受賞者」amturing.acm.org
  5. ^ 「ヴィントンサーフ-AMチューリング賞受賞者」amturing.acm.org
  6. ^ a b c d e f g h i Comer、Douglas E.(2006)。TCP / IPを使用したインターネットワーキング:原則、プロトコル、およびアーキテクチャ1(第5版)。プレンティスホール。ISBN 978-0-13-187671-2
  7. ^ 「TCP(伝送制御プロトコル)」2019年6月26日取得
  8. ^ "RFC 791 –セクション2.2"
  9. ^ 伝送制御プロトコルIETF1981年9月。doi10.17487 / RFC0793RFC793_
  10. ^ 高性能のためのTCP拡張2.2。RFC1323_ 
  11. ^ 「RFC2018、TCP選択的確認応答オプション、セクション2」
  12. ^ 「RFC2018、TCP選択的確認応答オプション、セクション3」
  13. ^ 「RFC1323、高性能のためのTCP拡張、セクション3.2」
  14. ^ 「伝送制御プロトコル(TCP)パラメータ:TCPオプションの種類番号」IANA。
  15. ^ RFC793セクション3.1
  16. ^ RFC793セクション3.2
  17. ^ タネンバウム、アンドリューS.(2003-03-17)。コンピュータネットワーク(第4版)。プレンティスホール。ISBN 978-0-13-066102-9
  18. ^ RFC 1122、セクション4.2.2.13 
  19. ^ 「TCP定義」2011年3月12日取得
  20. ^ マティス; マシュー; セムケ; マハダビ; オット(1997)。「TCP輻輳回避アルゴリズムの巨視的動作」。ACMSIGCOMMコンピューターコミュニケーションレビュー27(3):67–82。CiteSeerX10.1.1.40.7002_ 土井10.1145 /263932.264023S2CID1894993_  
  21. ^ Paxson、V。; オールマン、M。; Chu、J。; サージェント、M。(2011年6月)。「基本的なアルゴリズム」TCPの再送信タイマーの計算IETFp。2.秒 2. doi10.17487 / RFC6298RFC6298 _ 2015年10月24日取得
  22. ^ 石; パートリッジ(2000)。「CRCとTCPチェックサムが一致しない場合」ACM SIGCOMM Computer Communication Review:309–319。CiteSeerX10.1.1.27.7611_ 土井10.1145 /347059.347561ISBN  978-1581132236S2CID9547018 _
  23. ^ 「RFC879」
  24. ^ 「TCPウィンドウスケーリングと壊れたルーター[LWN.net]」
  25. ^ デビッドマレー; テリーコジニエック; セバスティアン・ザンダー; マイケルディクソン; Polychronis Koutsakis(2017)。「変化するエンタープライズネットワークトラフィック特性の分析」(PDF)第23回アジア太平洋通信会議(APCC 2017)2017年10月3日取得
  26. ^ 「IPsysctl」Linuxカーネルのドキュメント2018年12月15日取得
  27. ^ 王、イブ。「TCPタイムスタンプが無効になっています」Technet-Windows Server 2012Essentialsマイクロソフト。2018年12月15日にオリジナルからアーカイブされました2018年12月15日取得
  28. ^ ゴント、フェルナンド(2008年11月)。「TCP緊急データの実装について」第73回IETF会議2009年1月4日取得
  29. ^ ピーターソン、ラリー(2003)。コンピュータネットワークモーガンカウフマン。p。 401ISBN 978-1-55860-832-0
  30. ^ リチャードW.スティーブンス(2011年11月)。TCP / IPの図解。1、プロトコルアディソン-ウェスリー。pp。第20章ISBN 978-0-201-63346-7
  31. ^ 「伝送制御プロトコル(TCP)のセキュリティ評価」(PDF)2009年3月6日にオリジナルからアーカイブされました2010年12月23日取得 {{cite web}}: CS1 maint: bot: original URL status unknown (link)
  32. ^ 伝送制御プロトコル(TCP)のセキュリティ評価
  33. ^ ヤコブ・レル。「SYNCookieを使用したクイックブラインドTCP接続のなりすまし」2014年2月5日取得
  34. ^ 「最近のTCPDoS(サービス拒否)の脆弱性に関するいくつかの洞察」(PDF)
  35. ^ 「TCPと永続タイマーの無限大の活用」
  36. ^ 「プッシュおよびACKフラッド」f5.com
  37. ^ 「LaurentJoncheray、TCPに対する単純なアクティブ攻撃、1995」
  38. ^ ジョンT.ハーゲン; バリーE.マリンズ(2013)。TCP拒否権:新しいネットワーク攻撃とそのSCADAプロトコルへの応用革新的なスマートグリッドテクノロジー(ISGT)、2013 IEEEPESpp。1–6。土井10.1109 /ISGT.2013.6497785ISBN 978-1-4673-4896-6S2CID25353177 _
  39. ^ 「TCPインタラクティブ」www.medianet.kent.edu
  40. ^ RFC 6182
  41. ^ RFC 6824
  42. ^ Raiciu; バレ; Pluntke; Greenhalgh; Wischik; Handley(2011)。「マルチパスTCPによるデータセンターのパフォーマンスと堅牢性の向上」ACMSIGCOMMコンピューターコミュニケーションレビュー41(4) 266。CiteSeerX10.1.1.306.3863土井10.1145 /2043164.20184672020-04-04にオリジナルからアーカイブされました2011年6月29日取得 
  43. ^ 「マルチパスTCP-Linuxカーネルの実装」
  44. ^ Raiciu; パーシュ; バレ; フォード; ホンダ; デュシェーヌ; ボナヴェントゥラ; Handley(2012)。「それはどれほど難しいか?展開可能なマルチパスTCPの設計と実装」Usenix NSDI:399–412。
  45. ^ ボナヴェントゥラ; ソ(2016)。「マルチパスTCP展開」IETFジャーナル
  46. ^ マイケル・ケリスク(2012-08-01)。「TCPファストオープン:Webサービスの促進」LWN.net
  47. ^ ユー・チョン・チェン; ジェリーチュー; Sivasankar Radhakrishnan&Arvind Jain(2014年12月)。「TCPファストオープン」IETF 2015年1月10日取得 {{cite journal}}: Cite journal requires |journal= (help)
  48. ^ マティス、マット; Dukkipati、ナンディタ; チェン、ユチュン(2013年5月)。「RFC6937-TCPの比例レート削減」2014年6月6日取得 {{cite journal}}: Cite journal requires |journal= (help)
  49. ^ Grigorik、Ilya(2013)。高性能ブラウザネットワーク(1. ed。)。北京:オライリー。ISBN 978-1449344764
  50. ^ 「「履歴」ステータスへの移行」古いTCP拡張機能とTCP関連ドキュメントを履歴または情報ステータスに移動します。IETF2016.p。4.秒 2.1。土井10.17487 / RFC7805RFC7805_
  51. ^ a b "CDMA2000RLPを介したTCPパフォーマンス"2011年5月3日にオリジナルからアーカイブされました2010年8月30日取得
  52. ^ Muhammad Adeel&Ahmad Ali Iqbal(2004)。CDMA2000パケットデータネットワークのTCP輻輳ウィンドウの最適化情報技術に関する国際会議(ITNG'07)pp。31–35。土井10.1109 /ITNG.2007.190ISBN 978-0-7695-2776-5S2CID8717768 _
  53. ^ Yunhong Gu、Xinwei Hong、およびRobert L.Grossman。 「増加が減少するAIMDアルゴリズムの分析」2004年。
  54. ^ 「Wireshark:オフロード」Wiresharkは、パケットがネットワークアダプタに送信される前にパケットをキャプチャします。まだ計算されていないため、正しいチェックサムは表示されません。さらに悪いことに、ほとんどのOSはこのデータをわざわざ初期化しないため、おそらく、すべきではないメモリの小さなチャンクが表示されます。Wireshark 1.2以降の新規インストールでは、デフォルトでIP、TCP、およびUDPチェックサム検証が無効になります。必要に応じて、これらの各ディセクタでチェックサム検証を手動で無効にすることができます。
  55. ^ 「Wireshark:チェックサム」チェックサムのオフロードは、チェックサムが実際に計算される前に、送信されるネットワークパケットがWiresharkに渡されるため、混乱を引き起こすことがよくあります。Wiresharkは、これらの「空の」チェックサムを取得し、後でネットワークハードウェアを離れるときにパケットに有効なチェックサムが含まれている場合でも、無効として表示します。

さらに読む

外部リンク