信頼性のあるUDP（アプリケーション層で実装）がTCPの代わりにならないのはなぜですか？

TCPはトランスポート層で信頼性を提供しますが、UDPは提供しません。したがって、UDPは高速です。ただし、アプリケーション層のプロトコルは、UDPを使用しながら信頼性の高いメカニズムを実装できます。

この意味で、信頼性が必要なのにUDPがTCPより速い場合、なぜ信頼性のあるUDP（アプリケーション層に実装されている）がTCPの代替ではないのでしょうか？

TCPは、信頼性の特性を備えたものを作成できるほど高速です。たとえば、シーケンスとエラー検出だけが必要な場合は、UDPを完璧に機能させることができます。これは、音声やビデオストリーミングなど、ほとんどのリアルタイムプロトコルの基礎であり、「絶対的な」エラー修正よりも遅延やジッターの方が重要です。

基本的に、TCPはストリームが最終的に信頼できると言っています。それがどのくらい速いかは、さまざまなタイマー、速度などに依存します。エラーを解決するのにかかる時間は予測できませんが、基本的な操作は、エラーがない場合は実行可能な限り高速です。システムが発生する可能性のあるエラーの種類について何かを知っている場合、TCPでは不可能なことを実行できる可能性があります。たとえば、シングルビットエラーが特に発生する可能性がある場合は、それらのビットエラーに対してエラー修正コーディングを使用できます。ただし、これはリンクレイヤーに実装する方がはるかに優れています。別の例として、パケット全体の損失の短いバーストが一般的である場合、損失を待たずに複数の伝送でこれに対処できますが、明らかにこれは帯域幅が高価です。または、エラー確率が無視できるようになるまで速度を遅くします。帯域幅も高くなります。最終的には、

実装の観点から見ると、TCPに投資したプログラマー世紀は、TCPが一般的な余裕のあるものよりも高速になり、不明瞭なエッジの場合に信頼性が高まることがわかります。

TCPは、ユビキタスな接続方法（通信システムに共通の制御が存在しない場合に必須）であり、任意の距離のマルチホップネットワークで輻輳制御を備えた、信頼性の高い、順序付けされた（重複排除された）双方向のウィンドウ化されたバイトストリームを提供します。

アプリケーションがユビキタスを必要としない場合（ソフトウェアが両側で実行される場合）、またはTCPのすべての機能を必要としない場合、多くの人は他のプロトコル（多くの場合UDP上）を有益に使用します。例には、TFTP（最小限の、非常に非効率的なエラー処理を伴う、オーバーヘッドを減らすように設計されたQUIC（まだ実験的としてマークされています）、および必要な信頼性機能をきめ細かく制御するlidgrenなどのライブラリが含まれます。 ]

信頼性のあるUDPは、確かにTCPの代わりになります。すでにその例があります：QUICと呼ばれます。

ウィキペディアから：

他のアプリケーションの中でも、QUICは現在TCPを使用している接続指向のWebアプリケーションのパフォーマンスを向上させます。これは、User Datagram Protocol（UDP）を介して2つのエンドポイント間に多数の多重化接続を確立することによりこれを行います。

UDPを使用することと、まったく新しいトランスポートレイヤープロトコルを作成することの利点は、ルーターや他のネットワークデバイスが既にそれを理解していることです。

UDPを使用して、アプリケーション層でTCP機能を実装できます（信頼性、適応性）。アプリケーションで本当に必要なことがTCPでできないのでない限り、そもそもTCPを使用することもできます。これらの機能を自分で実装すると、TCPを使用した場合よりもはるかに悪化する可能性が高くなります。オーバーヘッドが追加されると、全体的な効率も低下します。

TCPは低速ではありません。送信する前にハンドシェイクと、チャネルに適応するための送信ウィンドウが必要です。手元の伝送チャネルへのスループットを非常にうまく形成し、フロー中の変化に適応することができますが、UDPがすべては（それ自体では）できません。

ただし、トランスポート層より上のプロトコルは、ここではトピック外です。

クリーンなネットワークでは、それらはほぼ同等です。TCPが一定期間ハングする場合があります（ロード時にHTTP画面がフリーズするのを見たことがありますか？）

UDPを使用すると、非常に多くの作業が必要になりますが、アプリケーション層でトラフィックをより詳細に制御できます。

あなたの質問への答えは、時々それはそのように行われます。低レイテンシを必要とするゲームは、多くの場合、まさにそれを行います。多くの作業が必要ですが、未処理のパケットの数と再試行の頻度を正確に制御する機能は価値があります。

全体的な違いは、TCPが非常に優れた汎用実装であるということですが、UDPがそのTCPを実行できる特定の目的があります。

• 決してあきらめない（TCPでは接続がハングすることがあり、接続を切断して再起動する必要があります）
• 返信が不要なパケットの高速ストリームを送信し、ときどき見逃すことを気にしない（最新のパケットのみが重要であり、他のパケットは破棄できます）-ゲームの位置の更新を考えてみてください。各ステップではなく「ジャンプ」しますが、同じ結果がより速く、より確実に得られます。
• パケットのドロップを分析し、再試行の頻度と再試行を動的に変更することにより、iffyネットワークに対処します。最大パケットサイズも可能です。

しかし、一般的にそれは価値がありません、TCPは非常に最適ですので、なぜすべての余分な仕事に行き、バグとセキュリティ欠陥を追加する（大きな）チャンスを追加しますか？

UDPはUDPであるため高速ではありません。TCPはTCPなので低速ではありません。

両方のプロトコルは特定の保証付きで設計されており、生のTCPには生のUDPよりも多くの保証があります。

経験則として、保証の価格はパフォーマンスです。

UDPを介したTCP保証の実装を禁止するものは何もありません。しかし、その後、より多くの保証が得られるため、価格を支払う必要があります。したがって、パフォーマンスはTCPに低下するか、UDPオーバーヘッドにより低下します。より適切なTCP実装を知っている場合を除き、これはほとんどありません。そして、もしあなたがそれを（願わくば）あなたがそれを明らかにすれば、私たちは標準TCPをより速くします。そして、私たちは始めたところに戻りました。:)

これらの保証も利用できます。これを少し修正し、わずかに修正します。そして、UDP上にあるQUICのようなプロトコルになり、TCP + TLS に非常に似ています。多くの場合、TCPよりも高速ですが（この記事では最大5％の遅延と最大15％のバッファリングによりIMOは大した問題ではありません）、一部のシナリオ（信頼性の高いネットワークや暗号化の必要なし）では実際に遅いです（こちらの説明をご覧ください）。

また、これらの保証を弱めることもできます。たとえば、ストリーミングしているので、古いパケットは面白くないとしましょう。最新のもののみ。しかし、混雑は依然として重要です。したがって、すべてではなく、TCPからいくつかの保証を取得します。そして、はい、人々は実際にそれを行います（リアルタイムゲームなど）。これにより、いくつかの保証がありますが、パフォーマンスが向上します。

あなたのアイデアは深宇宙で良いでしょう。

正解は「依存する」と「ネットワーク全体に損傷を与えるため」です。TCP / IPはネットワークに非常に優しく、高速になるように適切な速度に自動的に調整されますが、ICMPリターンパケットのトンを生成しません。

RAMが不足しているルーターが、たとえばTsunami、Bittorrent、FDTなどから大量のパケットを突然受信した場合、ルーターはそれをドロップし、小さな障害確認応答パケットを送信者に送り返します。UDPサーバーは、その部分を手動で追跡して再送信する必要があります。いくつかのISPルーターがBittorrentを形作っているので、これが津波を傷つけていますか？

Tsunamiプロトコルは、TCPの制御チャネルでUDPを使用します。http://tsunami-udp.sourceforge.net/ FDTと呼ばれるものよりも遅いことを示す研究を見つけました。

CERNの伝説的な高速データ転送（FDT）プロトコルは、複数のTCPストリームを使用してあらゆるネットワークを飽和させることができます。おそらく、それはネットワークに非常に多くのUDPをフラッディングするTsunamiの再送信が少なくなるため、より高速になります。

UDPは信頼性の低いアプリケーションで使用されます。ストリーミングオーディオ、ゲームの入力/更新IO、「ping」は実際にはICMPですが、保証されていません。奇妙な欠落パケットを気にせず、即座に「追いつく」ことができるもの。

TCP / IPは本当にアプリの開発者が設定して忘れてしまうことを可能にするキラーの発明でした。ソケットはIPアドレスとポートのペアであり、再接続せずにセットアップして数時間、数日、さらには数週間維持できるように設計されています。メール、ウェブ、IRC、文字通りすべてのキラーアプリはTCPを使用します。しかし、ダウンロード中に突然停止する奇妙な一時停止が発生する可能性があります...そして深宇宙では、接続がタイムアウトして、星間ファイル転送に最適な津波スタイルの転送が行われる可能性があります-あなたはそこにいる可能性があります!!

証拠は、この科学研究の抜粋の最後の発言にあります。これは、私が行っている距離の増加について言及していますre：deep space From：https : //uscholar.univie.ac.at/get/o : 300623.pdf

輻輳がない場合、TCPを使用したFDTおよびGridFTPのパフォーマンスは、津波およびUDTよりも高くなります。FDTの最大スループットは2.34 Gb / sで、RTTは1ミリ秒ですが、リンクFTPがリンクRTTが100ミリ秒よりも長い場合、FDTよりもパフォーマンスが優れているため、100ミリ秒後に急速に減少します。興味深いことに、津波のスループットはRTTの増加に伴って減少することはなく、RTTの増加とともに最も効果的な輻輳制御を示しています。

繰り返しますが、実際には、スペースに適した電子メールによく似たスペースプロトコルがあります。アプリは、永遠などのタイムアウト値を気にする必要はありません。

TCP！= UDP +信頼性

TCPは、信頼性が追加された単なるUDPではありません。TCPは、単なる信頼性以上の機能を提供します。それらについては、多くのRFCで読むことができます。

これらの機能はすべて、アプリケーション層で実装できます。最終的には、車輪の再発明を開始するポイントになります。

TCPのいくつかの機能に名前を付けるには...

• 接続の作成と終了：ハンドシェイクと接続の閉鎖を実行します

• フロー制御：送信者と受信者が両方がデータレートを処理できるレートで送信することを保証します。

• エンドツーエンドの輻輳制御：エンドノードが損失に基づいてスループットを調整できるようにします。スロースタート、輻輳回避、および高速リカバリについてお読みください。

私の経験では、速度が信頼性よりも懸念される場合にUDPが使用されます。アプリケーションレベルで、TCPほど100％信頼性の低いレベルの信頼性を追加できます。たとえば、依然として高速なパフォーマンスが必要な場合は、データを複数回送信する前方誤り訂正（FEC）を実装できます。パケットを失くすためのすべての往復チャットがなくても、良好なパフォーマンスとある程度の信頼性（かなりのTCP信頼性に注意）が得られます。トレードオフは、ネットワークの利用率を高めることですが、ゲームやストリーミングなどのリアルタイムアプリケーションに適している場合があります。