212

ある程度のパケット損失を許容できる一般的なプロトコル メッセージ交換用。UDP over TCP はどれくらい効率的ですか?

4

14 に答える 14

282

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

より大きな規模では、この TCP の動作が、インターネットが「輻輳の崩壊」に陥るのを防いでいます。

アプリケーションを UDP にプッシュする傾向があるもの:

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

  • 順不同の配信: 多くのアプリケーションでは、すべてのデータを取得する限り、データがどのような順序で到着するかは気にしません。順不同のブロックを受け入れることで、アプリ レベルのレイテンシを減らすことができます。

  • 不親切: LAN パーティーでは、できる限り速くネットワークに更新をブリットしている限り、Web ブラウザーがうまく機能するかどうかは気にしないかもしれません。

しかし、パフォーマンスを気にしていても、おそらく UDP を使いたくないでしょう:

  • 現在、信頼性を確保する必要があり、信頼性を実装するために行う多くのことは、TCP が既に行っていることよりも遅くなる可能性があります。

  • あなたはネットワークに優しくなく、共有環境で問題を引き起こす可能性があります.

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

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

于 2008-09-11T20:06:52.377 に答える
96

一部のアプリケーションでは、TCP は UDP よりも高速です (スループットが向上します)。

これは、MTU サイズに比べて小さい書き込みを多数実行する場合に当てはまります。たとえば、300 バイトのパケットのストリームがイーサネット (1500 バイトの MTU) 経由で送信され、TCP が UDP よりも 50% 高速であるという実験を読みました。

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

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

特別な理由がない限り、おそらく UDP を使用すべきではありません。特に、 Nagle アルゴリズムを無効にすることで、TCP に UDP と同じ種類の遅延を与えることができるため(たとえば、リアルタイムのセンサー データを送信していて、多数の小さなパケットでネットワークが混雑することを心配していない場合)。

于 2009-03-12T12:41:50.667 に答える
91

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

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

于 2008-09-06T23:03:04.773 に答える
33

耐損失性あり

「損失許容度あり」ということですか?

基本的に、UDP は「ロス トレラント」ではありません。誰かに 100 個のパケットを送信できますが、それらのパケットは 95 個しか受信できず、一部は間違った順序になっている可能性があります。

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

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

ありがたいことに、何人かの非常に賢い人々がこれを行い、TCP と呼んでいました。

次のように考えてみてください: パケットが失われた場合、できるだけ早く次のパケットを取得して続行するか (UDP を使用)、それとも失われたデータが実際に必要か (TCP を使用) しますか? 本当にエッジケースのシナリオでない限り、オーバーヘッドは問題になりません。

于 2008-09-07T20:19:52.940 に答える
20

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

于 2012-02-28T13:59:55.100 に答える
13

各 TCP 接続では、データを送信する前に最初のハンドシェイクが必要です。また、TCP ヘッダーには、さまざまなシグナルやメッセージ配信の検出を目的とした多くのオーバーヘッドが含まれています。メッセージ交換の場合、わずかな失敗の可能性が許容される場合は、UDP で十分でしょう。受信を確認する必要がある場合は、TCP が最適なオプションです。

于 2008-09-06T22:52:33.677 に答える
11

私は物事を明確にします。 TCP/UDPは、道路を走っている 2 台の車です。交通標識と障害物がエラーであると仮定すると、TCPは交通標識を気にかけ、周囲のすべてを尊重します。車に何かが起こるかもしれないので、ゆっくり運転してください。UDPはただ走り去りますが、全速力で道路標識を無視します。何もない、狂った運転手。UDPにはエラー回復機能がありません。障害物がある場合は、障害物と衝突して続行します。TCPはすべてのパケットが完全に送受信されることを確認しますが、エラーがないため、車は衝突することなく障害物を通過します。これが、ゲームでUDPが好まれる理由を理解するための良い例になることを願っています。ゲームにはスピードが必要です。 ダウンロードではTCPが優先されます。そうしないと、ダウンロードしたファイルが破損する可能性があります。

于 2016-09-05T04:21:32.930 に答える
7

私の経験では、UDP はわずかに高速ですが、それほどではありません。パフォーマンスではなく、メッセージの内容と圧縮技術を選択する必要があります。

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

于 2008-09-06T22:52:04.817 に答える
5

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

SCTP

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

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

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

これに関する 1 つの問題は、接続の確立が複雑である (そのためプロセスが遅い) ことです。

その他似たようなもの

もう1つの同様の独自の実験的なもの

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

于 2013-08-02T10:02:14.260 に答える
5

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

于 2008-09-06T23:04:51.167 に答える
4

まだ通信していない 2 つの IP 間でネットワークを介してメッセージをすばやく送信する必要がある場合、UDP は少なくとも 3 倍速く、通常は 5 倍速く到着します。

于 2011-06-30T11:06:01.720 に答える
1

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

議論に追加したい3つのこと:

  1. ゲーム開発のコンテキストでの TCP と UDP に関する非常に優れた記事をここで見つけることができます。
  2. さらに、iperf ( GUI を使用したjperf拡張 iperf ) は、測定することで質問に答えることができる非常に優れたツールです。
  3. Python でベンチマークを実装しました (この SO の質問を参照してください)。平均 10^6 回の反復で、8 バイトを送信する場合の差は、UDP の場合、約 1 ~ 2 マイクロ秒です。
于 2015-09-18T06:56:59.647 に答える