UDP vs TCP、どれくらい速いですか？[閉まっている]

一部のパケット損失を許容できる一般的なプロトコルメッセージ交換用。UDP over TCPはどれほど効率的ですか？

UDPはTCPよりも高速であり、単純な理由は、TCPウィンドウサイズとラウンドトリップ時間を使用して計算された一連のパケットを確認するTCPではなく、継続的なパケットストリームを許可するその存在しない確認パケット（ACK）が原因です。 （RTT）。

詳細については、シンプルですが非常にわかりやすいSkullboxの説明（TCPとUDP）をお勧めします

TCPがあなたに与える主なものは信頼性だと人々は言っています。しかし、それは本当ではありません。TCPが提供する最も重要なことは輻輳制御です。DSLリンク全体で100のTCP接続をすべて最高速度で実行できます。100の接続はすべて、利用可能な帯域幅を「感知」するため、生産的です。100種類のUDPアプリケーションを使用して、すべてのパケットを可能な限り高速にプッシュしてみてください。

より大規模な場合、このTCPの動作は、インターネットが「輻輳の崩壊」に陥らないようにするものです。

アプリケーションをUDPに向ける傾向があるもの：

• グループ配信のセマンティクス：TCPのポイントツーポイントの確認応答よりもはるかに効率的に、人々のグループに信頼性の高い配信を行うことができます。

• 順不同の配信：多くのアプリケーションでは、すべてのデータを取得する限り、どの順序でデータが届くかは関係ありません。順不同ブロックを受け入れることで、アプリレベルのレイテンシを削減できます。

• 親しみやすさ：LANパーティーでは、ネットワークの更新をできるだけ速くブリットしている限り、Webブラウザーが適切に機能するかどうかは気にしないでしょう。

しかし、パフォーマンスを気にしているとしても、UDPを使いたくないでしょう。

• 現在、信頼性の問題に取り組んでおり、信頼性を実装するために行うことの多くは、TCPがすでに行っているよりも遅くなる可能性があります。

• これでネットワークに不便になり、共有環境で問題が発生する可能性があります。

• 最も重要なのは、ファイアウォールによってブロックされることです。

複数のTCP接続を一緒に「トランキング」することにより、TCPのパフォーマンスと遅延の問題を克服できる可能性があります。iSCSIは、ローカルエリアネットワークの輻輳制御を回避するためにこれを行いますが、低遅延の「緊急」メッセージチャネルを作成することもできます（TCPの「緊急」動作は完全に壊れています）。

一部のアプリケーションでは、TCPはUDPよりも高速です（スループットが優れています）。

これは、MTUサイズに比べて大量の小さな書き込みを行う場合です。たとえば、300バイトのパケットのストリームがイーサネット（1500バイトのMTU）を介して送信され、TCPがUDPより50％高速であるという実験を読みました。

その理由は、TCPがデータをバッファリングしてネットワークセグメント全体を埋め、利用可能な帯域幅をより効率的に使用するためです。

一方、UDPは、パケットをすぐに回線に送信するため、大量の小さなパケットでネットワークを混雑させます。

特別な理由がない限り、UDPを使用しないでください。特に、Nagleアルゴリズムを無効にすることで、TCPにUDPと同じ種類の遅延を与えることができるため（たとえば、リアルタイムのセンサーデータを送信していて、大量の小さなパケットでネットワークが輻輳する心配がない場合）。

損失耐性あり

「ロストレランスあり」という意味ですか？

基本的に、UDPは「ロストレラント」ではありません。あなたは誰かに100パケットを送ることができます、そして彼らはそれらのパケットの95しか得ないかもしれません、そしていくつかは間違った順序にある​​かもしれません。

ビデオストリーミングやマルチプレーヤーゲームなど、パケットの背後にある他のすべてのパケットを遅延させるよりもパケットを逃した方がよい場合、これは明白な選択です。

ただし、他のほとんどの場合、欠落または再配置されたパケットは重要です。何かが失敗した場合に再試行するためにUDP上で実行する追加のコードをいくつか記述し、正しい順序を強制する必要があります。これにより、特定の場所でわずかなオーバーヘッドが追加されます。

ありがたいことに、一部の非常に賢い人々がこれを行い、彼らはそれをTCPと呼んでいました。

このように考えてください：パケットが欠落した場合、できるだけ早く次のパケットを取得して続行するか（UDPを使用）、または実際に欠落したデータが必要ですか（TCPを使用）。本当にエッジケースのシナリオでない限り、オーバーヘッドは問題になりません。

UDPとTCPのどちらのプロトコルが（スループットの点で）パフォーマンスが優れているかは、実際にはネットワークの特性とネットワークトラフィックによって異なります。たとえば、Robert S. Barnesは、TCPのパフォーマンスが向上するシナリオ（小さいサイズの書き込み）を指摘しています。ここで、ネットワークが混雑していて、TCPトラフィックとUDPトラフィックの両方があるシナリオを考えてみます。TCPを使用しているネットワーク内の送信者は、「輻輳」を感知し、送信速度を削減します。ただし、UDPには輻輳回避または輻輳制御メカニズムがありません。UDPを使用する送信者は、同じレートでデータを送り込み続けます。徐々に、TCP送信側は送信速度を最低限に下げ、UDP送信側がネットワーク経由で送信するのに十分なデータを持っている場合、使用可能な帯域幅の大部分を占有します。したがって、このような場合、UDP送信者は、ネットワーク帯域幅のパイが大きくなるため、スループットが向上します。実際、これは活発な研究トピックです-UDPトラフィックの存在下でTCPスループットを改善する方法。私が知っている1つの方法は、どのTCPアプリケーションを使用してスループットを向上できるかは、複数のTCP接続を開くことです。これにより、各TCP接続のスループットが制限される場合でも、すべてのTCP接続のスループットの合計が、UDPを使用するアプリケーションのスループットよりも大きくなる可能性があります。

「何が速い」と言えば、少なくとも2つの非常に異なる側面があります。それは、スループットと待ち時間です。

スループットについて言えば、（他の回答で述べたように）TCPのフロー制御は非常に重要であり、UDPで同等のことを行うことは、確かに可能ですが、大きな頭痛の種です。その結果、スループットが必要なときにUDPを使用しても、（TCPよりも不当なアドバンテージを得たい場合を除き）良いアイデアと見なされることはめったにありません。

ただし、レイテンシについて言えば、全体が完全に異なります。パケット損失がない場合、TCPとUDPは非常によく似た動作をします（違いはあるとしても、限界です）-パケットが失われた後、パターン全体が大幅に変化します。

パケットが失われた後、TCPは再送信を少なくとも200ミリ秒待機します（RFC6298の段落2.4ごとに1秒ですが、実際の最新の実装では200ミリ秒に減少する傾向があります）。さらに、TCPを使用すると、宛先ホストに到達したパケットであっても、欠落したパケットが受信されるまでアプリに配信されません（つまり、通信全体が約200ミリ秒遅れます）。 -ラインブロッキングは、TCPまたは信頼性+順序付きUDPのいずれであっても、すべての信頼性のある順序付きストリームに固有です。さらに悪いことに、再送信されたパケットも失われた場合は、約600ミリ秒の遅延について話します（いわゆる指数バックオフのため、最初の再送信は200ミリ秒、2番目の再送信は200 * 2 = 400ミリ秒です）。私たちのチャネルのパケット損失が1％の場合（これは今日の標準では悪くありません）、また、毎秒20回の更新があるゲームがあります。このような600ミリ秒の遅延は、平均して8分ごとに発生します。そして、600ミリ秒はテンポの速いゲームであなたを殺すのに十分すぎるほどです-まあ、それはゲームプレイにとってかなり悪いです。これらの効果こそが、ゲーム開発者がTCPよりもUDPを好むことが多い理由です。

ただし、UDPを使用してレイテンシを削減する場合は、単に「UDPを使用する」だけではレイテンシを大幅に改善できないため、UDPをどのように使用しているかを理解することが重要です。特に、RUDPライブラリは通常、その「指数バックオフ」を回避し、再送信時間を短くしますが、「信頼性のある順序付けされた」ストリームとして使用する場合、ヘッドオブラインブロッキングの影響を受ける必要があります（したがって、二重の場合）パケット損失、その600msの代わりに約1.5 * 2 * RTTを取得します-またはかなり良い80ms RTTの場合、それは〜250ms遅延であり、これは改善ですが、それでも改善することは可能です）。一方、使用した技術はで説明している場合http://gafferongames.com/networked-physics/snapshot-compression/および/またはのhttp：// ithareを。 、Head-of-Lineブロッキングを完全に排除することができます（20更新/秒のゲームのダブルパケット損失の場合、RTTに関係なく遅延は100ミリ秒になります）。

そして、サイドノートとして-あなたは（あなたのクライアントがUDPをブロック醜いファイアウォールの6から9パーセントの一つの背後にある場合、ブラウザのように、または）のみTCPが、無UDPへのアクセス権を持って起こる場合-そこに思えるへの道であることをレイテンシをあまり発生させずにUDP-over-TCPを実装します。ここを参照してください：http : //ithare.com/almost-zero-additional-latency-udp-over-tcp/（必ずコメントも読んでください（！））。

各TCP接続では、データが送信される前に初期ハンドシェイクが必要です。また、TCPヘッダーには、さまざまな信号とメッセージ配信の検出を目的とした多くのオーバーヘッドが含まれています。メッセージ交換の場合、障害が発生する可能性が少しでもあれば、UDPで十分です。受信を確認する必要がある場合は、TCPが最適なオプションです。

@Andrew、私は違うと頼みました。UDPは、パフォーマンス要件のため、一部の種類のアプリケーションで選択されます。古典的な例の1つはビデオ会議です。この種のアプリケーションはTCP制御にうまく応答しません。

考慮すべき他の側面は、マルチキャストが必要になる場合です。その場合は、UDPを使用してください。

まだ話されていない2つのIP間でネット上のメッセージをすばやくブラストする必要がある場合、UDPは少なくとも3倍、通常は5倍早く到着します。

はっきりさせておきます。 TCP / UDPは、2台の車が路上で運転されているということです。交通標識と障害物がエラーであると仮定しますTCPは交通標識を扱い、周りのすべてを尊重します。車に何かが起こる可能性があるため、運転が遅い。一方でUDPはちょうどオフに駆動し、フルスピードには道路標識に尊重していません。何も、狂った運転手。UDPにはエラー回復機能がありません。障害がある場合、UDPはそれに衝突して続行します。一方で、TCPはすべてのパケットが送信されると完全に受信されていることを確認し、ノー・エラーは、そう、車はちょうど衝突することなく障害物を渡します。これが、ゲームでUDPが推奨される理由を理解するための良い例であることを願っています。ゲームにはスピードが必要です。 ダウンロードではTCPが優先されるか、ダウンロードされたファイルが破損する可能性があります。

私の経験では、UDPは少し高速ですが、それほど高速ではありません。選択はパフォーマンスではなく、メッセージの内容と圧縮技術に基づいて行う必要があります。

メッセージ交換を伴うプロトコルの場合、TCPを使用した場合のわずかなパフォーマンスヒットは、それだけの価値があることをお勧めします。必要なすべてを提供する2つのエンドポイント間の接続が与えられます。自分がやっていることに本当に自信がない限り、UDPの上に信頼できる独自の双方向プロトコルを試して製造しないでください。

TCPは通常、複数のメッセージを送信し続けることに注意してください。これをUDPで実装したい場合、確実に実行したい場合は、かなりの作業が必要になります。ソリューションの信頼性が低下するか、速度が低下するか、作業量が信じられないほどになります。UDPの有効なアプリケーションはありますが、この質問をしている場合、おそらくそうではありません。

プログラマーが両方のメリットを享受できるようにするために、いくつかの作業が行われています。

SCTP

これは独立したトランスポート層プロトコルですが、UDPを介して追加の層を提供するライブラリーとして使用できます。通信の基本単位はメッセージです（1つ以上のUDPパケットにマップされます）。組み込みの輻輳制御があります。プロトコルには、スイッチを入れるためのノブとひねりがあります

• メッセージの配信
• ユーザー定義のパラメーターを使用した、失われたメッセージの自動再送信

特定のアプリケーションでこれが必要な場合。

これに関する1つの問題は、接続の確立が複雑である（したがって処理が遅い）ことです。

他の同様のもの

• https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol

同じような独自の実験的なもの

• https://en.wikipedia.org/wiki/QUIC

これはまた、TCPのトリプルウェイハンドシェイクを改善し、高速回線をより適切に処理するように輻輳制御を変更しようとします。

ネットワークの状態を考慮せずにTCPまたはUDPについて話すことは無意味です。2点間のネットワークの品質が非常に高い場合、UDPはTCPよりも絶対的に高速ですが、GPRSネットワークなど他の場合では、TCPはUDPよりも高速で信頼性が高い場合があります。

ネットワークのセットアップは、あらゆる測定にとって重要です。ローカルマシンのソケットを介して、または世界の反対側と通信している場合、それは大きな違いを生みます。

ディスカッションに追加したい3つのこと：

1. ゲーム開発のコンテキストでのTCPとUDPに関する非常に優れた記事がここにあります。
2. さらに、iperf（jperfはGUIを使用してiperfを強化します）は、測定によって自分の質問に答えるための非常に優れたツールです。
3. 私はPythonにベンチマークを実装しました（このSO質問を参照）。UDPの場合、平均10 ^ 6回の反復で8バイトを送信する場合の差は約1〜2マイクロ秒です。