TCPはIPを使用する必要がありますか？

TCPはTCP / IPの略で、同じことを意味するのは本当ですか？

TCPをIP以外の別のプロトコルの上に構築することは可能ですか？

TCPとIP（v4＆v6）は完全に分離可能であり、TCP over IPX（RFC 1791）の例で証明されているように、一方は他方を意味しません。

しかし、TCPは、ちょうど上に構築することができない任意のネットワークプロトコル。2つの理由：

1. TCPヘッダーにセグメントサイズフィールドはありません（TCPヘッダーのサイズを提供するデータオフセットのみ）。したがって、TCPは、TCPセグメントのサイズ（つまり、下位層プロトコルのペイロードサイズ）を計算するのに十分な情報を含む下位層プロトコルでのみ動作します。この仮定は、IPv4（RFC 791）、IPv6（RFC 2460）、およびIPX（RFC 1791）に当てはまります。しかし、一般的には真実ではありません。たとえば、鳥類のキャリア（RFC 1149）についてはそうではありません（注aを参照）。
2. TCPは、コネクションレス型ネットワークプロトコル上でのみ動作するように設計されています。TCPは、特定の接続指向のネットワークプロトコル（ATM固定ビットレートサービスなど）では効果的に機能しません。2つのファイティングレート制御機能により、パフォーマンスが非常に低下または予測不能になるためです。別の縮退した例は、TCPトンネルを介したTCPです。

TCP仕様、RFC 793は、この質問を決定するのに適した情報源ではありません。なぜなら、下位層とのインターフェースがほとんど指定されていないことを認めているからです。

注a）TCPが小さな紙に印刷されたデータグラムを再構築するには（ハトまたはよりインテリジェントなネットワークによって運ばれる）、ペイロードのサイズを標準の場所に書き込む必要があります。あるいは、適応レイヤーが発見的にセグメントサイズを決定することもできます。鳥類のキャリア仕様（RFC 1149）のホストスタックの実装で使用される光学スキャナーには、このような発見的適応レイヤーが含まれていましたが、文書化されていません。

RFC全体を読んだことはありませんが、セクション1.4の言語は、「下位レベル」プロトコルを使用できることを示唆しているようです。

TCPと下位レベルのプロトコル間のインターフェイスは、2つのレベルが互いに非同期で情報を渡すことができるメカニズムがあると想定されることを除いて、基本的に指定されていません。通常、低レベルのプロトコルがこのインターフェイスを指定することが期待されます。TCPは、相互接続されたネットワークの非常に一般的な環境で動作するように設計されています。このドキュメント全体で想定される下位レベルのプロトコルは、インターネットプロトコルです。

インターネットプロトコルスイート

TCPはTCP / IPの短縮形ではありません。

TCP / IPは、多くの場合、「インターネットプロトコルスイート」の略語として使用され、通常は他の標準プロトコルが含まれます。人々がTCP / IPと言うとき、それらは通常、UDP over IP（TCPの代わりにUDPが使用される）とARP、ICMP、DNS、SNMPおよび他のアプリケーション層プロトコルなどの非常に多くの他のプロトコルを含みます。

アプリケーション層

アプリケーションは、SMTP（電子メール用）などのアプリケーション層プロトコルを使用します。これらは、TCPとUDPの2つのトランスポートレイヤープロトコルのいずれかにあります。いくつかのアプリケーション層プロトコルはUDPとTCPのいずれかまたは両方を使用しますが、ほとんどは1つのトランスポート層プロトコルのみで使用されます。

トランスポート層

TCPとUDPは、インターネットプロトコルスイートで使用される2つのトランスポート層プロトコルです。他の人がいる場合、私はそれらを知らず、他の人はごくわずかな専門家の使用を表しています。 他のトランスポート層プロトコルが定義されています-それらの使用は、おそらくグローバルIPトラフィックのごく一部にすぎません †

インターネットワーク層

理論的にはIP以外でTCPを使用することは可能かもしれませんが、実際には、TCPは常にIP（インターネットプロトコル）上で使用されます。IPはネットワーク間でパケットを移動します（IPは複数のLANを接続していると考えてください）

ネットワークインターフェース層

イーサネットは、TCP / IPが伝送される低レベルのリンク層プロトコルの最も人気のあるファミリにすぎませんが、TCP / IPはATMなどで広く使用されています。

付録1-トランスポート層プロトコルに関する注意

インターネットプロトコルスイートを使用するネットワークで使用されるトランスポートレイヤプロトコルは、TCPとUDPのみです。

†楽しみのために、NetBIOS（over TCP）、SSH、Rsync、電子メール、ソフトウェアの更新、DNS、一般的なWindowsボックスチャッター、およびその他のいくつかの種類のトラフィックを含む（非常に）小さなLANのトラフィックを測定しました。

GoogleのQUICプロトコルに関するFAQのこの声明にも注意してください。

UDPを使用するのではなく、まったく新しいプロトコルを作成しなかったのはなぜですか？現在のインターネット上の中央のボックスは、TCPまたはUDPトラフィックでない限り、一般的にトラフィックをブロックします

（私の強調）

TCP / IPが（UDP / IPやSCTP / IPとは対照的に）そのような一般的な略語である理由は、2つのプロトコルが一緒に設計されたためであり、Vint CerfとBob Kahnによるオリジナルの論文では、 1つのプロトコルにまとめられます。その後すぐに、ルーティング制御を提供するIPとフロー制御、多重化、エラー検出などを提供するTCPに分割されました。6年後、UDPが導入されて、「軽量」多重化レイヤーが残りの部分なしで提供されましたTCPに関連するオーバーヘッド。

それでも、TCPとIPは2つの別個のものであり、完全に意図的に独立しています。TCPがIPを必要としないという事実は、TCPが2つの完全に異なるプロトコルであるIPv4とIPv6の両方で変更なしで実行できるという事実からすぐに明らかになります。

ちょっとした作業で、同じ目的に役立つIPへの競合プロトコルを作成できますが、おそらく同じ機能のすべてではないにしてもほとんどを含める必要があり、おそらくIPによく似たものになるでしょう。IPへの拡張（IPSecなど）は、実質的に代替のレイヤー3プロトコルであると主張することができます。

IPを別のものに置き換えることができます。実際、TCP over IPv6を使用しているとき、まさにそれがあなたがしていることです。TCPは引き続きTCPですが、IPはv4ではなくv6です。

私の知る限り、他のレイヤ3プロトコルを作成して、その上でTCPを使用することはできませんが、できなかった理由はありません。

TCPとIPは、バターオーバーパンのようなものです。

どちらのプロトコルでも動作するものは何でもペアにできますが、これら2つは非常に相補的であるため、データを転送しておなかをインターネットデータで満たすためのおいしい信頼できる方法です。このペアリングをサポートするために、チューブにグリースを塗り、他の乾燥食品とデータハンドシェイクを同様に許可します。しかし、決して排他的ではありません。

Q ただし、IP以外のプロトコルの上にTCPを構築することはできませんか？

A はい、可能です。IPのないTCPのモールス符号と鳩の例が好きです。

TCPはTCP / IPの略だといつも聞いています。

実際には、Internet Protocol over Transmission Protocolの略です。

そして、それらは同じことを意味します。

それは正しくありません。

まず、イーサネットは、実際のハードウェア部品の機能を制御する低レベルのハードウェアシステムです。

次に、IPを電話システムまたは交通標識と考えてください。システムの2点を接続する基本的な制御を提供します。

一方、TCPは、メッセージ/車を正しいポイントに導くメッセージングシステムまたは交通管制官に似ています。

まとめると、TCP / IPは、接続された2つのデバイスとの間でデータを確実に転送するシステムを提供します。

インターネットでは、データを送信または受信する場合、システムのIP部分は、実際のハードウェアとワイヤー（または無線波）の接続を制御する部分です。システムのTCP部分は、データを取得して分割し、送信し、受信したデータを再組み立てし、必要に応じてデータを確認して再送信するソフトウェアです。

特にビデオ形式では、類似点や技術的な詳細を含む説明が無数にあります。DifferenceBetween.netは、この正確な主題について特に良いものを持っています。

ただし、TCPをIP以外の別のプロトコルの上に構築することはできませんか？

はい、IPを使用するTCPの代替システムを実際に作成できます。詳細については、インターネットプロトコルスイートをご覧ください。

TCPはレイヤー4プロトコルです。コンピューター上の1つのプロセスから、同じコンピューターまたは別のコンピューター上の別のプロセスへ、順序付けられたストリームの形式でデータの転送を保証します。

IPはレイヤー3プロトコルです。あるホストから別のホストへの輸送を提供します。

データをホスト間で転送できるプロトコルがあれば、TCPは機能します。

したがって、TCPは任意のプロトコルで実装できますが、IPのみを作成しました。IPはシンプルで、機能します。

別のレイヤ3プロトコルは必要ありません。

ネットワークを設計するとき、さまざまな「レイヤー」（異なる抽象レベルとして想像できる、ネットワーク設計者が好むもの）ごとに、プロトコルのセット（基本的にはマシン間の通信ルールのセット）を選択する必要がありますプロトコルを作成および結合する際には注意してください）。

より簡単なバージョン：プロトコルは、メッセージを入れるボックスのようなものです。これらのボックスにはさまざまなサイズがあり、メッセージを最小のボックスに入れてから、少し大きいボックスに最小のボックスなどを入れます。メッセージを囲むレイヤー」。

TCPとIPは、一緒に作成され、一緒に使用できる2つの独立したレイヤーのプロトコルです。しかし、他のプロトコルで非常にうまく使用できます。これはかなり頻繁に発生します。非TCPプロトコルと一緒にIPを使用するか、非IPプロトコルと一緒にTCPを使用できます。

TCP / IPがこのような一般的な略語である理由は、これら2つのプロトコルが一緒になってインターネットの基礎を形成し、その成功の鍵となったためです。

（TCPとIPには、一緒に機能するように特別に設計されたいくつかの機能があります。これは、純粋主義者がしばしば不満を言うものですが、実際に他のプロトコルとのインターフェイスを妨げるものではありません）

レトロにしたい場合は、IPXトランスポートを介してTCPを実行することが可能だと思います。

ただし、TCPをIP以外の別のプロトコルの上に構築することはできませんか？

古典的なTCP / IPv4とTCP / IPv6のほかに、いくつかの実験プロトコルが設計されています。例えば：

ほぼTCP over UDP（atou）

高速で遅延の大きいネットワークでのバルク転送を改善するNet100およびプローブの取り組みの一環として、UDP上で動作する調整可能なTCPのバージョンを開発しました。UDP TCPのようなトランスポートは、TRenoと同様のアプリケーションレベルでTCPのようなコントロールを試すためのテストハーネスとして機能します。

そしてiproxy：UDP上でTCPサービスを実行して、より楽しいです、：

iproxyは、クライアント側プロキシとサーバー側プロキシで構成され、任意のTCP / IPサービスをブロードキャスト、マルチキャスト、またはユニキャストUDPで実行できます。もともとは、Webベースのインターフェイスを使用して、LAN上でIPアドレスが与えられていないサーバーを構成する方法として考案されました。

つまり、ユニキャストUDP上のTCP、さらにはブロードキャストUDPまたはマルチキャストUDP上のTCP です！

私の知る限り、TCP / IPv4とTCP / IPv6のみが大規模な展開を楽しんでいます。

答えはノーです！たとえば、TCP over IPXを説明する古いRFCがあります：http : //tools.ietf.org/html/rfc1791

短い記憶を持つ人々にとって、IPXはNovell Netwareプロトコルでした：http : //en.wikipedia.org/wiki/Internetwork_Packet_Exchange

基本的なデータグラムのトランスポートをサポートするさまざまなプロトコル上でのTCPの実装はすでに存在します。実際、ルーティング情報を指定する必要さえありません（TCPはIPを使用する必要さえありません。暗黙の受信者とのセリラリンクで十分です）。

TCPをUDPの上に実装しました（利点：「サーバー」側で単一のポートを使用するか、さまざまな多重化チャネルを転送する既存の接続に埋め込むことができます）。IPレベルのみがルーティングを提供しますが、TCPはそれを必要としません。重要なのは、MTUの概念が下位層によって提供されることです。

これにより、プロトコルは、特定のホストのUPnP変換ポートを登録することなく、NATトラバーサルの制限を回避できます。MTUとMSSの独立したチューニングが可能になり、各中間共有ルーターではなく各クライアントに最適化されます。他のルーティングプロトコルが可能です（マルチキャストおよびブロードキャストネットワークを介した配信を含む）。また、セキュリティメカニズムを選択できます。

使用例はGogo6.netです（これはTCP over UDP v4の再実装を使用してTCPセッションでIPv6トランスポートチャネルを実装します） ;実行されていない場合でも、アプリケーション固有の一定のポート番号を使用してユーザーが構成する必要はありません）

他の例は、TCP over HTTP（またはHTTPS）バージョン1.1をネイティブの「ストリーミング」拡張機能でカプセル化することです。インターネットを介したネットワークのブリッジングを許可するほとんどのVPNは同じことを行います。ブリッジは複数のプロトコルをカプセル化することもできます：イーサネット、PPP、IPv4およびIPv6（ローカルLANまたはイーサネットセグメントのみを拡張）、NetBEUI / LanMan、ルーター検出（ブリッジネットワーク内）、rawモード（DHCPv4またはDHCPv6を許可）を含むブリッジされたネットワーク。HTTPSを使用するのは、HTTPSを介したカプセル化により、ブリッジの確立と保護のための暗号化と認証も許可されますが、ブリッジネットワークを介したクライアントとサーバーのエンドツーエンド認証/暗号化が不要であり、ルーターがHTTPに対して高度に最適化されているためですおよびHTTPS。

通信パスはルーターなどを介してルーティングされないシリアルタイプの接続であるため、IPではなくTCPを使用する軍隊の通信システムの例があります。IPフィールドでヘッダー化される前にTCPパケットを見ると、 「ルーティング」プロトコルが異なる場合、IPを使用しないことは簡単に考えられます。