sockets - 信頼できる UDP が必要な場合、何を使用しますか?

Question

TCP 接続が遅すぎる可能性があり、UDP '接続' の信頼性が低すぎる可能性がある場合、何を使用しますか? さまざまな標準の信頼できる UDP プロトコルがありますが、それらについてどのような経験がありますか?

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

ここでのさまざまなオプションに興味があります。TCP はスケールの一方の端にあり、UDP はもう一方の端にあります。さまざまな信頼性の高い UDP オプションが利用可能で、それぞれが TCP のいくつかの要素を UDP にもたらします。

多くの場合、TCP が正しい選択であることはわかっていますが、代替案のリストを用意しておくと、その結論に達するのに役立つことがよくあります。Enet や RUDP などの UDP 上に構築されたものにはさまざまな長所と短所がありますが、それらを使用したことがありますか?

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

score 27 · Accepted Answer

SCTPはどうですか。IETF（RFC 4960）による標準プロトコルです。

速度を上げるのに役立つチャンク機能があります。

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

更新：素敵な紹介記事。

score 25 · Accepted Answer

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

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

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

しかし、単一のパケットの損失を許容できない場合は、tcpがすでに持っている信頼性のための技術のタイプを導入し始める必要があります。また、妥当な量の作業を行わなくても、これらの要素をユーザースペースソリューションに組み込み始めており、それに伴う固有の速度の問題がすべて含まれていることに気付く場合があります。

score 24 · Accepted Answer

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

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

ENET は、データの複数の「チャネル」を送信するオプションと、送信されるデータを信頼できないもの、信頼できるもの、または順序付けするオプションを提供します。また、キープアライブとして機能する前述のピアツーピア ping も含まれます。

score 14 · Accepted Answer

UDT (UDP ベースのデータ転送) ( http://udt.sourceforge.net/を参照) を使用している防衛産業の顧客がおり、非常に満足しています。友好的なBSDライセンスも持っていることがわかりました。

score 11 · Accepted Answer

上記のリストでは不十分であり、独自の信頼できる UDP を開発したいと判断した場合は、Google QUIC 仕様を確認する必要があります。これは、多くの複雑なコーナーケースと潜在的なサービス拒否攻撃をカバーしているためです。私はまだこれの実装を試していないので、それが提供するすべてのものを望んでいない、または必要としていないかもしれませんが、新しい「信頼できる」UDP 設計に着手する前に、ドキュメントを読む価値があります。

QUIC の良い出発点は、こちらの Chromium ブログです。

最新の QUIC 設計ドキュメントは、ここにあります。

score 10 · Accepted Answer

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

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

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

キープアライブに関しては ENet よりもわずかに構成可能に見えますが、それほど多くのオプションはありません (つまり、すべてのデータは信頼でき、決定したビットだけでなくシーケンス化されます)。実装はかなり簡単に見えます。

score 9 · Accepted Answer

他の人が指摘しているように、あなたの質問は非常に一般的であり、何かが 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");

score 4 · Accepted Answer

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

Linux で実装されているようです。

score 4 · Accepted Answer

TCP 接続が遅すぎる可能性があり、UDP '接続' の信頼性が低すぎる可能性がある場合、何を使用しますか? さまざまな標準の信頼できる UDP プロトコルがありますが、それらについてどのような経験がありますか?

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

UDP から信頼性を得たい場合は、基本的に UDP の上に TCP の機能の一部を再実装することになります。これにより、最初に TCP を使用するよりも速度が低下する可能性があります。

score 3 · Accepted Answer

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

score 2 · Accepted Answer

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

前述のとおり、問題の正確な性質に関する情報は不足していますが、データを圧縮して転送すると役立つ場合があります。

score 2 · Accepted Answer

RUDP。ゲーム用のソケットサーバーの多くは、似たようなものを実装しています。

sockets - 信頼できる UDP が必要な場合、何を使用しますか?

15 に答える 15

Related

Reference