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

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

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

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

多くの場合、TCPが正しい選択ですが、代替案のリストを用意しておくと、その結論に到達するのに役立ちます。UDPに基づいて構築されたEnetやRUDPなどには、さまざまな長所と短所があります。それらを使用したことはありますか、あなたの経験は何ですか？

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

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

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

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

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

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

チャンク機能があり、速度の向上に役立ちます。

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

更新：素敵な紹介記事。

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

私はENETを信頼性の高いUDPプロトコルとして使用し、サーバーでそれを使用している私のクライアント向けに非同期ソケットフレンドリーバージョンを作成しました。これはかなりうまく機能しますが、ピアツーピアpingが他の方法でアイドル状態の接続に追加するオーバーヘッドが好きではありません。たくさんの接続があり、それらすべてに定期的にpingを送信すると、忙しい作業になります。

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

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

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

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

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

キープアライブに関してはENetよりも少し構成しやすいように見えますが、それほど多くのオプションはありません（つまり、すべてのデータは信頼できるものであり、必要なビットだけでなく順序付けられています）。実装はかなり簡単に見えます。

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

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

QUICのためのポイントオフに良いジャンプがあり、ここを超えるクロムブログで、。

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

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

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

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

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

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

かもしれRFC 5405、「アプリケーションデザイナーのためのユニキャストUDPの使用上の注意事項は、」あなたのために有用であろう。

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

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

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

UDPを使用して信頼性を実現する最良の方法は、アプリケーションプログラム自体に信頼性を構築することです（たとえば、確認応答と再送信のメカニズムを追加することにより）。