TCPスループットがUDPスループットよりもはるかに大きいのはなぜですか？

ハードウェアまたはカーネル構成（すべてのデフォルト設定、OSの新規インストール、Linuxカーネル3.11 TCP / IPスタック）に異常なことはしておらず、平均0.75しかありませんがTCPを介して毎秒平均約383万メッセージを処理していますUDPを介して毎秒100万メッセージ。これは、2つのプロトコルに期待することを完全に無視しているようです。

劇的な違いの最も可能性の高い原因は何ですか？また、Ubuntu 13.10でどのように診断できますか？

#TCP RESULTS
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB   us/KB

87380  65536     64    10.00      1963.43   32.96    17.09    5.500   2.852

#UDP RESULTS
Socket  Message  Elapsed      Messages                   CPU      Service
Size    Size     Time         Okay Errors   Throughput   Util     Demand
bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB

4194304      64   10.00     7491010      0      383.5     28.97    24.751
212992            10.00     1404941              71.9     25.03    21.381

このテストでは、同一の10Gクロスケーブルを介して直接接続された2つのテストサーバーがあります。この場合に使用されるNICは、すぐに使用できる構成のIntel X520であり、マザーボードのPCIe 3.0 x8スロットに接続され、NUMAコントローラーを介してCPUと通信します。

— エルシエル
ソース

ベンチマークはどうでしたか？あなたがそれらのパッケージを送ったものに対して？

— Braiam 14年

netperfベンチマーク、UDP_STREAMおよびTCP_STREAMテストに使用し、同じCPUに固定し、64バイトのメッセージサイズを使用しました。

— エルシエル14年

@Braiamの質問には答えません。ここでは、ネットワークトポロジが重要であり、詳細なテスト方法が重要です。

— パベルシメルダ14年

@PavelŠimerda申し訳ありませんが、彼はテスト方法論のみを求めていると思いました。ネットワークトポロジに関しては、2つのテストサーバーは同一であり、10Gクロスオーバーケーブルを介して直接接続されています。この場合に使用されるNICは、すぐに使用できる構成のIntel X520であり、マザーボードのPCIe 3.0 x8スロットに接続され、NUMAコントローラーを介してCPUと通信します。これはあなたの質問に答えますか？

— エルシエル14年

はい、@ elleciel、それは間違いなく私の質問に答えます。この場合、直接接続されたマシンの答えをあなたに提供する専門知識はありませんが。質問自体を修正したと思いますが、これはすばらしいことです。今私も興味がありますので質問をします。

— パベルシメルダ14年

テストのセットアップに関する詳細な情報が得られないことを除けば、主な問題は、64バイトのメッセージサイズを使用していることです。これは通常の1500バイトのMTUから遠く離れており、UDPを非常に非効率にします。TCPは複数の送信をワイヤ上の単一のパケットにマージし（TCP_NODELAYが設定されている場合を除く）、リンクを効率的に使用しますが、各UDPメッセージは別のパケット。数字では、サイズ64バイトの約23のメッセージがMTUサイズの単一のTCPパケットに結合されますが、同じデータ量のUDPには23の単一パケットが必要になります。これらの各パケットは、ホストからの送信、有線での送信、ピアによる受信のオーバーヘッドを意味します。そしてあなたの場合に見られるように、あなたのハードウェアはこれらすべてのパケットを送受信するのに十分に速くないので、UDPパケットの約80％が失われます。

したがって、このベンチマークから学べることは次のとおりです。

UDPは信頼できません（80％のパケット損失）
UDPは、MTUをはるかに下回るパケットサイズで使用すると非効率です
TCPはリンクを最大限に活用するために高度に最適化されています

あなたの期待に関しては、そのUDPはより良いはずです：すべての主要なファイル転送（ftp、http、...）がTCPベースのプロトコルで行われる理由を疑問に思いましたか？ベンチマークはその理由を示しています。

では、なぜUDPを使用するのでしょうか？

リアルタイムデータ（Voice over IPなど）では、古いメッセージを気にしないため、送信者がメッセージを大きなパケットに結合してリンクを効果的に使用することは望ましくありません。そして、パケットが遅れて到着するよりも、パケットが失われることを受け入れます。
待ち時間の長いリンク（サテライトなど）では、TCPのデフォルトの動作は、リンクを効果的に使用するには最適ではありません。そのため、この場合はUDPに切り替えてTCPの信頼性レイヤーを再実装し、高遅延リンク用に最適化する人もいれば、既存のTCPスタックを調整してリンクをより有効に活用する人もいます。
「捨てる」データ：ログメッセージ（syslog）のように、データを捨ててパケット損失を気にしないことが重要な場合があります。
短い相互作用：TCPでは、接続を確立して状態を維持する必要があり、クライアントとサーバーで時間とリソースがかかります。短い相互作用（短い要求と応答など）の場合、これはオーバーヘッドが大きすぎる可能性があります。このため、DNSは通常UDPを使用して行われますが、UDPの上に再試行を構築しました。

— ステフェン・ウルリッヒ
ソース

UDPを使用した場合の80％のパケット損失も確認する必要があります。お使いのハードウェアは、送信するのと同じ速度でパケットを処理するのに十分な速度ではないようです。TCPはこの種のパケット損失に速度を落として適応しますが、UDPは同じ速度で送信し、パケットを失います。しかし、最終的には、どれだけ速く送信できるかではなく、何を受け取るかは関係ありません。

— ステフェンUllrich 14年

他の要因となる可能性があるのは、ネットワークカードへのTCPアクセラレーション/オフロードです（サポートされている場合）。

— cpugeniusmv 14年

特に最後のパケットが割り込み駆動の場合、パケット送信は受信よりも効率的です。

— ステフェンUllrich 14年

人々はまた、UDPを使用して組み込みデバイスに有線で収集するデータをブロードキャストし、接続設定に煩わされません

— ラチェットフリーク14年

ほとんどの場合、PCIエクスプレスバスにIOがバインドされています。ネットワークカードでは、おそらくTCPセグメントのオフロードが有効になっています。これは、TCP転送が1つの大きなブロックとしてカードに送信され、その後、カードがパケットにスライスしてさいの目に切り分けて、回線上に置くことを意味します。UDPに相当するものはないため、結果は各パケットに対して1つのPCIeトランザクション（および関連するすべてのオーバーヘッド）になります。

— alex.forencich 14年