web-dev-qa-db-ja.com

信頼できるUDPが必要な場合は何を使用しますか？

TCP接続が遅すぎる可能性があり、UDP「接続」が信頼できない可能性がある場合は、何を使用しますか？さまざまな標準の信頼できるUDPプロトコルがあり、どのような経験がありますかあなたは彼らと一緒にいますか？

返信ごとに1つのプロトコルについて話し合ってください。使用しているプロトコルについて他の誰かが既に言及している場合は、必要に応じて投票し、コメントを使用して詳細を検討してください。

ここでさまざまなオプションに興味があります。TCPはスケールの一端にあり、UDPは他端にあります。さまざまな信頼できるUDPオプションが利用可能で、それぞれがTCP to UDP。の要素

多くの場合、TCPが正しい選択ですが、選択肢のリストがあると、その結論に達するのに役立つことがよくあります。UDP上に構築されたEnet、RUDPなどには、長所と短所、あなたはそれらを使用しましたか、あなたの経験は何ですか？

誤解を避けるために、これ以上の情報はありません。これは仮説的な質問であり、意思決定を行う必要のある人が利用できるさまざまなオプションと代替手段を詳述した回答のリストを引き出すことを望みます。

socketstcpnetwork-programmingudp
89
Len Holgate

問題の領域に関する追加情報がなければ、この質問に答えることは困難です。たとえば、使用しているデータの量はどれくらいですか？どのくらいの頻度で？データの性質は何ですか？ （たとえば、一意のデータか、1回限りのデータか、それともサンプルデータのストリームかなど）。どのプラットフォーム用に開発していますか？ （例：desktop/server/embedded）「遅すぎる」という意味を判断するために、どのネットワークメディアを使用していますか？

ただし、（非常に！）一般的に言えば、送信しようとしているデータについていくつかの厳しい仮定を立てることができない限り、速度のためにtcpを打つために本当に一生懸命努力する必要があると思います。

たとえば、送信しようとしているデータが単一パケットの損失を許容できるものである場合（たとえば、サンプリングレートが信号の帯域幅よりも何倍も高い定期的にサンプリングされたデータ）、おそらくデータ破損を検出できるようにすることで、伝送の信頼性をいくらか犠牲にします（たとえば、適切なcrcを使用して）

ただし、単一のパケットの損失を許容できない場合は、tcpが既に持っている信頼性のための技術の種類の導入を開始する必要があります。そして、合理的な量の作業を行わずに、固有の速度の問題をすべて伴うユーザー空間ソリューションにこれらの要素を構築し始めていることに気付くかもしれません。

25
Andrew Edgecombe

[〜＃〜] sctp [〜＃〜] についてはどうですか。 IETF（RFC 4960）による標準プロトコルです

速度を上げるチャンク機能があります。

更新：a TCPとSCTP の比較は、2つのインターフェイスを使用できない限り、パフォーマンスが同等であることを示します。

更新：a 素敵な紹介記事 。

27
philant

ENET- http://enet.bespin.org/

信頼性のあるUDPプロトコルとしてENETを使用し、サーバーで使用している私のクライアント向けに非同期ソケット対応バージョンを作成しました。これは非常にうまく機能しますが、ピアツーピアpingがアイドル接続に追加するオーバーヘッドが好きではありません。多数の接続がある場合、それらすべてに定期的にpingを実行すると、多くの忙しい作業になります。

ENETには、複数の「チャネル」のデータを送信するオプションと、送信されるデータの信頼性が低く、信頼性が高い、またはシーケンス化されるオプションがあります。また、キープアライブとして機能する前述のピアツーピアpingも含まれています。

20
Len Holgate

UDT（UDPベースのデータ転送）を使用する防衛業界のお客様がいます（ http://udt.sourceforge.net/ を参照）。これには非常に満足しています。フレンドリーBSDライセンスも持っていると思います。

14
Chris Markle

RUDP- 信頼できるユーザーデータグラムプロトコル

これにより、以下が提供されます。

  • 受信したパケットの確認
  • ウィンドウ処理と輻輳制御
  • 失われたパケットの再送信
  • オーバーバッファリング（リアルタイムストリーミングより高速）

キープアライブに関してはENetよりも少し設定しやすいように見えますが、多くの選択肢はありません（つまり、すべてのデータは信頼できるものであり、決められたビットだけでなくシーケンスされます）。実装はかなり簡単です。

10
Len Holgate

他の人が指摘したように、あなたの質問は非常に一般的であり、何かがTCPよりも「速い」かどうかはアプリケーションの種類に大きく依存します。

TCPは一般に、あるホストから別のホストへのデータの信頼できるストリーミングのために取得する速度と同じです。ただし、アプリケーションが多数の小さなトラフィックのバーストを実行し、応答を待機している場合、遅延を最小限に抑えるにはUDPの方が適切な場合があります。

簡単な中間点があります。 Nagleのアルゴリズム は、TCPの一部です。これにより、送信者が大量のデータストリームの受信者を圧倒し、輻輳とパケット損失が発生しないようにします。

TCPの信頼できる順序どおりの配信、およびUDPの高速応答が必要で、大量のデータストリームの送信による輻輳を心配する必要がない場合は、Nagleのアルゴリズムを無効にできます。

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");
9
smo

上記のリストだけでは不十分であり、OWNの信頼できるUDPを開発したいと考えている人は、Google QUIC仕様を確認する必要があります。私はまだこの実装を試していません。あなたはそれが提供するものすべてを必要としないかもしれませんが、ドキュメントは新しい「信頼できる」UDPデザインに着手する前に読む価値があります。

QUICの出発点として適切なのは、Chromiumブログの here です。

現在のQUIC設計ドキュメントは here にあります。

7
Len Holgate

RFC 434 、「Datagram Congestion Control Protocol」で標準化されたプロトコルDCCPは、あなたが探しているものかもしれません。

Linuxで実装 のようです。

4
bortzmeyer

TCP接続が遅すぎる可能性があり、UDP「接続」が信頼できない可能性がある場合は、何を使用しますか？さまざまな標準の信頼できるUDPプロトコルがあり、どのような経験がありますかあなたは彼らと一緒にいますか？

あなたの文章のキーワードは「潜在的に」です。プロトコルの信頼性が必要な場合、TCPは実際にはニーズに対して遅すぎることを自分で証明する必要があると思います。

UDPの信頼性を確保したい場合は、基本的にUDPの一部のTCP機能を再実装します。これにより、最初のTCP場所。

4
17 of 26

RFC 5405 の場合、「アプリケーション設計者向けのユニキャストUDP使用ガイドライン」が役立ちます。

3
bortzmeyer

データの圧縮を検討しましたか？

上記のように、問題の正確な性質に関する情報は不足していますが、データを圧縮して転送することで解決できる場合があります。

2
philant

[〜＃〜] rudp [〜＃〜] 。ゲーム用のソケットサーバーの多くは、同様のものを実装しています。

2
Engineer