web-dev-qa-db-ja.com

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

ハードウェアまたはカーネル構成（すべてのデフォルト設定、OSの新規インストール、Linuxカーネル3.11 TCP/IPスタック）に異常なことをしていないため、TCPを通じて1秒あたり平均約383万メッセージを送信しています。私は、UDPを介して1秒あたり平均75万メッセージしか平均化していません。これは、私が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であり、NUMAコントローラを介してCPUと通信するマザーボードのPCIe 3.0 x8スロットに接続されています。

networkingperformancetcpudp
15
elleciel

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

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

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

あなたの期待に関しては、UDPの方が優れているはずです：なぜすべての主要なファイル転送（ftp、http、...）がTCPベースのプロトコルで行われるのですか？理由。

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

  • リアルタイムデータ（Voice over IPなど）では、古いメッセージを気にする必要がないため、送信者がメッセージをより大きなパケットに結合してリンクを効果的に使用することは望ましくありません。そして、あなたはむしろ、パケットが遅すぎるよりもパケットが失われることを受け入れます。
  • （衛星のような）高レイテンシリンクでは、TCP）のデフォルトの動作はリンクを効果的に使用するのに最適ではありません。この場合、一部の人々はUDPに切り替えて信頼性を再実装しますTCPのレイヤーと高遅延リンク用に最適化する一方で、他の既存のTCPスタックを調整してリンクをより有効に活用します。
  • 「破棄」データ：ログメッセージ（syslog）のように、データを送信し、パケット損失を気にしないことがより重要な場合があります。
  • 短い対話：TCPを使用すると、接続を確立し、状態を維持する必要があります。これは、クライアントとサーバーで時間とリソースを消費します。短い対話（短い要求と応答など）の場合、これは多すぎる可能性があります。このため、このDNSは通常UDPで行われますが、UDPの上に再試行が組み込まれています。
29
Steffen Ullrich