TCPの代わりにUDPを使用することが適切なのはいつですか？[閉まっている]

TCPはパケット配信を保証し、したがって「信頼できる」と見なすことができるため、UDPは何も保証せず、パケットが失われる可能性があります。TCPストリームではなく、アプリケーションでUDPを使用してデータを送信する利点は何ですか？どのような状況でUDPの方が適していますか？なぜですか？

UDPはストリームを作成および維持するオーバーヘッドがないため、より高速であると想定していますが、一部のデータが宛先に到達しない場合、それは無関係ではありませんか？

これは私のお気に入りの質問の1つです。UDPはとても誤解されています。

本当に簡単に別のサーバーに簡単に答えたい場合は、UDPが最適です。一般的には、1つの応答パケットに回答を含める必要があり、信頼性のために独自のプロトコルを実装するか、再送信する準備ができています。DNSは、この使用例の完全な説明です。接続設定のコストが高すぎます（ただし、DNSはTCPモードもサポートしています）。

もう1つのケースは、入ってくる新しいデータが以前のデータ/状態を置き換えるために失われる可能性があるデータを配信している場合です。気象データ、ビデオストリーミング、株価情報サービス（実際の取引には使用されません）、またはゲームデータが思い浮かびます。

もう1つのケースは、膨大な量の状態を管理していて、OSがその数のセッションを処理できないためにTCPの使用を避けたい場合です。これは今日ではまれなケースです。実際、アプリケーションライターがそのTCP状態に必要なリソースをより細かく制御できるように、ユーザーランドのTCPスタックを使用できるようになりました。2003年以前は、UDPが町で唯一のゲームでした。

もう1つのケースは、マルチキャストトラフィックの場合です。UDPは複数のホストにマルチキャストできますが、TCPはこれをまったく行えません。

TCPパケットが失われた場合、再送されます。これは、リアルタイムで特定の順序で処理されるデータに依存するアプリケーションには便利ではありません。

例としては、ビデオストリーミング、特にVoIP（Skypeなど）があります。ただし、これらの例では、ドロップされたパケットはそれほど重要ではありません。私たちの感覚は完全ではないため、気付かないこともあります。これが、これらのタイプのアプリケーションがTCPではなくUDPを使用する理由です。

UDPの「信頼性の欠如」は形式主義です。送信は完全に保証されているわけではありません。実際問題として、彼らはほとんどいつも通り抜けます。タイムアウト後、確認されず再試行されるだけです。

TCPソケットのネゴシエーションとTCPパケットのハンドシェイクのオーバーヘッドは非常に大きくなります。本当に巨大です。目に見えるUDPオーバーヘッドはありません。

最も重要なのは、TCPよりもオーバーヘッドの少ない信頼できる配信ハンドシェイクでUDPを簡単に補完できることです。これを読んでください：http : //en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

UDPは、パブリッシュサブスクライブ型のアプリケーションで情報をブロードキャストするのに役立ちます。IIRC、TIBCOは、状態変化の通知にUDPを頻繁に使用します。

その他の種類の一方向の「重要なイベント」または「ロギング」アクティビティは、UDPパケットで適切に処理できます。ソケット全体を構築せずに通知を送信したい。さまざまなリスナーからの応答は期待できません。

システムの「ハートビート」または「I'm alive」メッセージも適切な選択です。欠けているのは危機ではありません。半ダース（行）が欠落しています。

クライアントとサーバー間のUDP（IP）とTCP / IPの両方の通信をサポートする製品に取り組んでいます。15年以上前のIPXから始まり、13年前にIPサポートが追加されました。3年か4年前にTCP / IPサポートを追加しました。予想外の問題：UDPとTCPのコード比はおそらく約80/20です。製品はデータベースサーバーであるため、信頼性が重要です。他の回答で既に言及されているUDPによって課されるすべての問題（パケット損失、パケット倍加、パケット順序など）を処理する必要があります。ほとんど問題はありませんが、時々発生するため、処理する必要があります。UDPをサポートすることの利点は、UDPを自分の使用法に合わせて少しカスタマイズし、それからもう少しパフォーマンスを調整できることです。

ネットワークはそれぞれ異なりますが、UDP通信プロトコルは一般的に少し高速です。懐疑的な読者は、私たちがすべてを正しく実装したかどうかを正しく質問します。さらに、2桁の担当者から何を期待できますか？それにもかかわらず、私は今、好奇心からテストを実行しました。このテストでは、100万件のレコードを読み取りました（sometableから*を選択）。個々のクライアント要求ごとに返すレコード数を1、10、次に100（各プロトコルで3つのテスト実行）に設定しました。サーバーは、100Mbit LAN上で2ホップしか離れていませんでした。数値は、他の人が過去に発見したものと一致しているようです（ほとんどの状況で、UDPは約5％高速です）。この特定のテストの合計時間はミリ秒単位でした。

1. 1件
   • IP：390,760ミリ秒
   • TCP：416,903ミリ秒
2. 10件
   • IP：91,707ミリ秒
   • TCP：95,662ミリ秒
3. 100件
   • IP：29,664ミリ秒
   • TCP：30,968 ms

送信される総データ量は、IPとTCPの両方でほぼ同じでした。TCP / IPで「無料」で入手できるものと同じもの（チェックサム、シーケンス番号など）があるため、UDP通信には余分なオーバーヘッドがあります。たとえば、Wiresharkは、次のレコードセットのリクエストがUDPでは80バイト、TCPでは84バイトであることを示しました。

ここにはすでに良い答えがたくさんありますが、要約だけでなく非常に重要な要素を1つ追加したいと思います。UDPは、輻輳制御を採用していないため、適切なチューニングではるかに高いスループットを実現できます。TCPの輻輳制御は非常に重要。接続の現在の容量を推定することにより、ネットワークの輻輳を最小限に抑えるために、接続のレートとスループットを制御します。コアネットワークなどの信頼性の高いリンクを介してパケットが送信される場合でも、ルーターのバッファーのサイズは制限されています。これらのバッファーは容量いっぱいになり、パケットはドロップされます。TCPは、受信された確認応答の欠落を通じてこのドロップに気づき、それにより、接続の速度が容量の見積もりに抑制されます。TCPもスロースタートと呼ばれるものを採用していますが、スループット（実際には輻輳ウィンドウ））は、パケットがドロップされるまでゆっくりと増加し、その後低下し、パケットがドロップされるまでゆっくりと増加します。これにより、TCPスループットが変動します。大きなファイルをダウンロードすると、これがはっきりとわかります。

UDPは輻輳制御を使用していないため、ドロップポイントまでバッファーを最大化しようとしないため、高速であり、遅延も少なくなります。つまり、UDPパケットはバッファー内で費やされる時間が短く、遅延が少なくて速く到達します。UDPは輻輳制御を採用していませんが、TCPは採用しているため、UDPフローに譲るTCPから容量を奪う可能性があります。

ただし、UDPは依然として輻輳やパケットドロップに対して脆弱であるため、アプリケーションは、おそらく再送信やエラー修正コードを使用して、これらの複雑な問題を処理できるように準備する必要があります。

その結果、UDPは次のことが可能になります。

• ネットワークドロップ率がアプリケーションが処理できる制限内である限り、TCPよりも高いスループットを実現します。
• TCPよりも速く、遅延が少ないパケットを配信します。
• 接続をセットアップするための初期ハンドシェイクがないため、接続をより速くセットアップ
• マルチキャストパケットを送信しますが、TCPは複数の接続を使用する必要があります。
• 固定サイズのパケットを送信するのに対し、TCPはデータをセグメントで送信します。300バイトのUDPパケットを転送すると、相手側で300バイトを受信します。TCPを使用すると、送信ソケットに300バイトを供給することができますが、受信機は100バイトしか読み取らないため、途中でさらに200バイトあることを何らかの方法で把握する必要があります。これは、アプリケーションがバイトストリームではなく固定サイズのメッセージを送信する場合に重要です。

要約すると、UDPは、適切な再送信メカニズムも実装している限り、TCPが使用できるすべてのタイプのアプリケーションに使用できます。UDPは非常に高速で、遅延が少なく、接続ベースの輻輳の影響を受けず、固定サイズのデータ​​グラムを送信し、マルチキャストに使用できます。

UDPはオーバーヘッドが少なく、オーディオやビデオなどのリアルタイムデータのストリーミングなど、データが失われても問題ない場合に適しています。

UDPはコネクションレス型プロトコルであり、SNMPやDNSなどのプロトコルで使用されます。このプロトコルでは、順序が狂って到着するデータパケットは許容可能であり、データパケットの即時送信が重要です。

SNMPで使用されるのは、ネットワークにストレスがかかっているとき、つまり信頼性の高い、輻輳制御のデータ転送を実現するのが難しいときに、ネットワーク管理を行う必要があることが多いためです。

これは接続の確立を含まないため、DNSで使用され、接続の確立の遅延を回避します。

乾杯

この質問に対して私が知っている最良の答えの1つは、Hacker NewsのユーザーzAy0LfpBZLC8mACからのものです。この答えはとても良いので、そのまま引用します。

TCPは完全な順序どおりの配信を保証するため、head-of-queueブロッキングを備えています。そのため、送信中にパケットが失われた場合、欠落したパケットの再送信を待つ必要がありますが、UDPはパケットが到着するとアプリケーションにパケットを配信します。 、重複を含み、パケットが到着するか、またはパケットが到着するという保証はありません（実際には、ポート番号と（オプションで）ペイロードチェックサムが追加されたIPです）が、通常はテレフォニーに適しています。数ミリ秒のオーディオが欠落している場合は問題になりませんが、遅延は非常に煩わしいので、再送信に煩わされることはありません。重複を削除し、並べ替えられたパケットを数百ミリ秒のジッターバッファーの正しい順序に並べ替えます。 、そしてパケットが時間内にまたはまったく表示されない場合、それらは単にスキップされ、コーデックでサポートされている場所で補間される可能性があります。

また、TCPの主要な部分はフロー制御であり、可能な限りスループットを確保しますが、ネットワークに過負荷をかけません（これは冗長です。過負荷のネットワークはパケットをドロップするため、これを行う必要があります）再送信するとスループットが低下します）、UDPにはそのようなものはありません-これはテレフォニーのようなアプリケーションでは理にかなっています通話が速くなることはありません。

リアルタイム/低レイテンシアプリケーションに加えて、UDPは、DNSルックアップなどの非常に小さなトランザクションに適しています。これは、TCPコネクションの確立とティアダウンオーバーヘッドがないためです。リクエストが一般的なMTUよりも小さく、応答もおそらく小さい場合は、サーバーで状態を維持する必要がなく、フロー制御の順序付けなど、1回のラウンドトリップで実行できます。そのような用途にも。

そしてもちろん、UDPを使用して独自のTCP置換を構築することもできますが、ネットワークダイナミクスをある程度理解していなければ、それはおそらく良い考えではありません。最新のTCPアルゴリズムはかなり洗練されています。

また、SCTPやDCCPのように、UDPやTCPだけではないことにも触れておきたいと思います。現在の唯一の問題は、（IPv4）インターネットがNATゲートウェイでいっぱいであり、エンドユーザーアプリケーションでUDPおよびTCP以外のプロトコルを使用できないことです。

ビデオストリーミングは、UDPを使用する完璧な例です。

既に述べたように、UDPはオーバーヘッドが低いため、ビデオやオーディオなどのストリーミングに適しています。パケットを失うだけで、再送信して追いつくことをお勧めします。

TCP配信の保証はありません。ソケットが切断された場合、または基本的にデータが到着しない場合に通知されます。それ以外の場合は、そこに到達したときに到達します。

人々が忘れている大きなことは、udpはパケットベースであり、tcpはバイトストリームベースであることです。送信した「tcpパケット」がもう一方の端に表示されるパケットであるという保証はなく、多くのパケットに分解できます。ルーターとスタックが望むように。したがって、ソフトウェアには、バイトを解析して使用可能なデータのチャンクに戻すというオーバーヘッドがあり、かなりのオーバーヘッドがかかる可能性があります。UDPが故障している可能性があるため、必要に応じてパケットに番号を付けるか、他のメカニズムを使用してパケットの順序を変更する必要があります。しかし、そのudpパケットを受け取った場合、同じバイトがすべて同じ順序で残り、変更はありません。したがって、udpパケットという用語は意味がありますが、tcpパケットは必ずしもそうではありません。TCPには、アプリケーションから隠された独自の再試行および順序付けメカニズムがあります。

UDPは、基本的にはポイントツーポイント接続を作成して維持する必要がないため、両端でコードを書く方がはるかに簡単です。私の質問は通常、TCPオーバーヘッドが必要な状況はどこですか？そして、受信したtcp「パケット」が送信された完全なパケットであると想定するようなショートカットを使用する場合、あなたの方がいいですか？（長さ/内容を確認するのに面倒な場合は、2つのパケットを破棄する可能性があります）

ビデオゲームのネットワーク通信は、ほとんどの場合UDP経由で行われます。

速度は最も重要であり、各更新にはプレーヤーが見ることができる完全な現在の状態が含まれているため、更新が欠落していても問題にはなりません。

重要な質問は、「UDPの方がどのような状況に適しているか（tcpより）」に関連しています。

上記には多くの素晴らしい答えがありますが、欠けているのは、TCPパフォーマンスに対するトランスポートの不確実性の影響の正式で客観的な評価です。

モバイルアプリケーションの大幅な成長と、それに伴う「時折接続される」または「時々切断される」パラダイムにより、接続が困難な場合にTCPが接続を維持しようとするとオーバーヘッドが強くなる状況が確かにあります。 UDPとその「メッセージ指向」の性質のケース。

今、私はこれに数学/研究/数値を持っていませんが、接続が一般に貧弱で古いTCPであるときにTCPで達成できるよりも、UDPでACK / NAKおよびメッセージ番号付けを使用してより確実に機能するアプリを作成しました時間を費やしただけで、クライアントのお金は接続しようとしました。あなたは多くの西洋諸国の地方と農村地域でこれを得ます...

他の人が強調したいくつかのケースでは、パケットの到着の保証は重要ではないため、UDPの使用は問題ありません。UDPよりもTCPの方が望ましい場合もあります。

TCPの代わりにUDPを使用したいユニークなケースの1つは、別のプロトコル（トンネル、仮想ネットワークなど）でTCPをトンネリングする場合です。TCP over TCPをトンネリングすると、それぞれの輻輳制御が相互に干渉します。したがって、一般に、UDP（またはその他のステートレスプロトコル）経由でTCPをトンネルすることを好みます。TechRepublicの記事：TCP over TCPの理解：エンドツーエンドのスループットと待機時間に対するTCPトンネリングの影響を参照してください。

UDPは、アプリが正確なデータ複製ではなく「リアルタイム」データを重視する場合に使用できます。たとえば、VOIPはUDPを使用でき、アプリはパケットの並べ替えを心配しますが、最終的にはVOIPがすべてのパケットを必要とするわけではありませんが、さらに重要なのは、それらの多くの連続フローが必要です。多分あなたはここに音声品質の「グリッチ」がありますが、主な目的はメッセージを受け取ることであり、反対側で完全に再現されることではありません。UDPは、接続の作成とTCPとの同期の費用がペイロードを上回る状況でも使用されます。DNSクエリは完璧な例です。クエリごとに1つのパケットが送信され、1つのパケットが返されます。TCPを使用する場合、これはより集中的になります。DNS応答が返されない場合は、再試行してください。

速度が必要な場合はUDP、パケットが必要でない場合は精度、精度が必要な場合はTCP。

UDPは、パケットの精度に依存しないようにプログラムを記述しなければならないという点で、しばしばより困難です。

常に明確であるとは限りません。ただし、損失のない正しい順序でパケットの配信を保証する必要がある場合は、TCPがおそらく必要です。

一方、UDPは、情報のシーケンスがそれほど重要でない場合や、データが単一のパケットに収まる場合に、情報の短いパケットを送信するのに適しています。

同じ情報を多くのユーザーにブロードキャストする場合にも適しています。

それ以外の場合は、シーケンスされたデータを送信する場合に適していますが、一部のデータが欠落しても、心配する必要はありません（VOIPアプリケーションなど）。

一部のプロトコルは、TCPの機能の一部（すべてではない）が必要なため、より複雑ですが、UDPが提供する機能よりも複雑です。これは、アプリケーション層が追加機能を実装する必要がある場所です。これらの場合、UDPも適切です（たとえば、インターネットラジオ、順序は重要ですが、すべてのパケットが通過する必要があるわけではありません）。

使用例/使用例1）LAN上の多数のマシンに正しい時刻をブロードキャストするタイムサーバー。2）VOIPプロトコル3）DNSルックアップ4）LANサービスの要求（例えば、どこにいるのですか？）5）インターネットラジオ6）その他多数...

UNIXでは、grep udp / etc / servicesと入力して、今日実装されているUDPプロトコルのリストを取得できます。

StevenのUnixネットワークプログラミングのセクション22.4 「TCPの代わりにUDPを使用する場合」をご覧ください。

また、UDPは常にTCPよりも速いという誤解については、この別のSOの回答を参照してください。

スティーブンの言うことは次のように要約することができます：

• ブロードキャストとマルチキャストにはUDPを使用してください。これが唯一のオプションです（新しいアプリにはマルチキャストを使用してください）。
• 単純な要求/応答アプリにはUDPを使用できますが、独自の確認応答、タイムアウト、再送信を組み込む必要があります
• バルクデータ転送にUDPを使用しないでください。

UDPはコネクションレス型プロトコルであることを知っているので、

1. 単純な要求/応答通信を必要とするプロセスに適しています。
2. 内部フロー、エラー制御があるプロセスに適しています
3. ブロードキャスティングとマルチキャストに適しています

具体的な例：

• SNMPで使用
• RIPなどの一部のルート更新プロトコルに使用されます

TCPとUDPを比較すると、UDPのようなコネクションレスプロトコルは速度を保証しますが、パケット伝送の信頼性は保証しません。たとえば、ビデオゲームでは通常、信頼性の高いネットワークは必要ありませんが、速度が最も重要であり、ゲームにUDPを使用すると、ネットワークの遅延を減らすことができます。

途中で一部のデータが失われても送信されるデータが完全に損なわれない場合に、UDP over TCPを使用します。その使用法の多くは、ゲーム（FPSなど）のようなリアルタイムアプリケーションで使用されます。FPSでは、すべてのプレーヤーが常にどこにいるかを知る必要がなく、途中でいくつかのパケットを失うと、新しいデータはプレーヤーがどこにいるのかを正しく伝えます）、リアルタイムビデオストリーミング（1つの破損したフレームが表示エクスペリエンスを台無しにすることはありません）。

私たちは、何千ものwinformsクライアントを同じ数のPCに持つWebサービスを持っています。PCはDBバックエンドとは接続されておらず、すべてのアクセスはWebサービスを介して行われます。そこで、UDPポートでリッスンする中央ログサーバーを開発し、すべてのクライアントがXMLエラーログパケットを（log4net UDPアペンダーを使用して）送信し、受信時にDBテーブルにダンプされるようにしました。いくつかのエラーログが見落とされても何も気にしないので、何千ものクライアントでは、メインのWebサービスを読み込まない専用のログサービスで高速です。

TCPが機能する可能性がある場合に、UDPを提案することに少し消極的です。問題は、TCPがなんらかの理由で機能していない場合、接続が遅すぎるか輻輳しているため、UDPを使用するようにアプリケーションを変更しても役に立たないことです。悪い接続はUDPにとっても悪いです。TCPはすでに輻輳を最小限に抑えるという非常に優れた機能を果たしています。

UDPが必要なのは、ブロードキャストプロトコルの場合だけです。アプリケーションに2つの既知のホストが含まれる場合、UDPは、コードの複雑さの大幅に増加したコストに対して、限界のパフォーマンス上の利点しか提供しない可能性があります。

UDPは、自分が何をしているか本当にわかっている場合にのみ使用してください。今日、UDPは非常にまれなケースですが、UDPをどこにでも貼り付けようとする（非常に経験豊富な）専門家の数は不釣り合いのようです。おそらく、エラー処理と接続保守のコードを自分で実装することを楽しんでいます。

チェックサムインプリントと呼ばれるものにより、最近のネットワークインターフェイスカードではTCPがはるかに高速になることが期待されます。驚くべきことに、高速接続速度（1Gbpsなど）では、チェックサムの計算はCPUにとって大きな負荷になるため、インプリント用のTCPパケットを認識するNICハードウェアにオフロードされ、同じサービスを提供しません。

UDPは、データパケットを送信する必要があるVoIPに最適であり、信頼性は低くなります...ビデオチャットはUDPの例です（ビデオチャット中にWiresharkネットワークキャプチャで確認できます）。また、TCPは動作しません。 DNSおよびSNMPプロトコル。UDPにはオーバーヘッドがありませんが、TCPには多くのオーバーヘッドがあります。