TCPとUDPの速度差は実際のネットワークでどのくらい違うのか

Question

ネットワークの学習をしていて気になりました。
TCPは「相手に届いたか確認」「届かなかったら再送」「順番も揃える」みたいな丁寧な通信をする。
UDPは「届いたか確認しない」「順番も気にしない」「再送もしない」
といった認識です。

物によると思いますが、実際のネットワークでは、どれくらい速度差が出るのでしょうか？どこかの記事ではDNSはUDPと書かれていましたが、速度差はそこまで気にならないならTCPで良いのではないかなと思いました。
ゲームや音声では速度差変わりそうな気はしてます。

また、TCPからUDPへの変更などは可能でしょうか？変更したいケースを経験したことはありませんが、気になったためご存知でしたら教えていただきたいです。

Answer 1

いま良さげな環境が手元にないので実験できないのですが、その昔
LAN内での通信確認に「NetMi」というフリーソフトを使用していた
ことがあります。(検索するとvectorとかいろいろ出てきます。
今どきのWindowsで正常に動作するかどうかはわかりません。)

ご承知の通りTCPは確認手順が入るのでそこそこの速度になりますが、
UDPでは経路や受信側の都合に関係なく投げっぱなしなので、送信側は
PCとプログラム(NetMi)の性能の限りパケットを送信しまくっているように
見えました。
アホみたいな速度が表示されるのでおもしろいといえばおもしろいの
ですが、もちろん受信側では大量に取りこぼしています。そんな数字だけ
見て「UDP超高速！」とか言われましても…ってなりますよね、たぶん。

想定している用途がまるで違うのと、既出回答の通り実装や環境依存が
大きいので、単純に何倍とかいう比較には意味がない気がしますね。

Answer 2

物によると思いますが、実際のネットワークでは、どれくらい速度差が出るのでしょうか？

7〜8年ほど前にIBMのAsperaという製品(高速ファイル転送ソフトウェア)を利用したことがあります。

IBM Aspera
Aspera 高速転送の使用 | IBM Cloud 資料

Aspera クライアントによって転送が開始されると、クライアントは指定された TCP ポートで SSH サーバーへの SSH セッションを開き、データの転送に使用する UDP ポートをネゴシエーションします。デフォルトでは、Aspera クライアントおよびサーバーは UDP ポート 33001 を使用するように構成されています。セッション開始ステップの後、クライアントとサーバーの両方が、ネゴシエーションされたポートで UDP トラフィックを送受信します。

以下のウェブページにある解説を読むと、「FTPより25倍も速い」と書かれていますが、RTTが200ms〜300msでの結果なのでネットワークの応答性があまりよろしくないという状況では高速転送が見込める、ということなのでしょう。(同ページの「FTPとの比較」ではTCPでのパケットロス検知による転送速度の自動調整(輻輳制御)によってスループットが低下する状況を想定しています)

高速ファイル転送ソフトウエア [ IBM® Aspera ]｜ネットワークソリューション：エイチ・シー・ネットワーク

実際、RTTが10〜20msでパケットロス率が0.03%以下なネットワーク(日本国内、回線距離は約600km)でAsperaを利用したのですが、rsyncコマンド(TCP)を使用した場合の転送速度と差はありませんでした。

ちなみに、TCPで長距離高速通信を行う場合には以下の文書が参考になるかと思います。

SINET5で変わる長距離高速通信テクニック 平成28(2016)年10月14日

TCPで長距離高速通信を行うには:
・ノード間遅延(RTT)の最小化
・ウィンドウサイズ(Win)を大きく保つ → パケットロスの防止

Answer 3

TCP/UDP どっちが、について回答しづらいですね。なぜならば、TCP/UDP 両方 OK なプロトコルがあるなら比較できるけど、そういうものはほぼないので比較がしづらい。

強いて言うなら DNS なんでしょうけど、一般の名前解決において TCP/UDP 比較して速度計測している人はほぼいないのではと思います (普通はまず UDP を使い、レスポンスが 512バイト越えの場合に truncated で返ってくるので、それを受けて TCP でリクエストしなおします。しかし最初から TCP で投げても RFC 的には OK。なので速度比較はできなくはない)。

あとついでに言うと、高速ファイル転送をうたうアプリはだいたい UDP を使っている印象があります。TCP が担う再送・エラー対応・ウィンドウサイズなどを独自実装することで高速化しているのでしょう。これは想像ですが、ファイル転送の場合は人が操作するわけではないので即時性を捨て、大量データの高速転送に全振りしていると思われます。

順序性も信頼性もなくていいなら UDP がもちろん速いが、世の中そんなデータはなかなかない。だって音声チャットですらデータ欠落したら嫌でしょ。なので普通は TCP がよいけど、ユースケースを限定できるなら UDP+自前実装 もあり、というところかなと。

ただ今どきルータなりファイアウォールなりで UDPが通らないことも多いので、どこでも繋がることを重視するためにはどうしても 80/TCP か 443/TCP に乗っかる形にならざるをえないのではと思います (QUIC は 443/UDP ですけど、繋がらない環境もまだまだあるはず)

Answer 4

どこかの記事ではDNSはUDPと書かれていましたが

いえ、DNSはTCPを使うこともあります。

• UDPのパケット長の限度である512バイトを超える場合
• HTTPSやTLSに載せて暗号化を行う場合

TCPからUDPへの変更などは可能でしょうか？

実際に、GoogleがHTTPSをUDP上で実現するために「QUIC」というプロトコルを作成して、のちに標準化されHTTP/3となっています。とはいえ、TCPで行ってきたことをUDPで実現するには、差となる機能性を自前で実装する必要が出てきます。

Answer 5

速度差とは、秒とかの話ですか？ハードウェアの環境に依りますし、送信データの具体的な中身にも依ります。また、tcpの場合、受領確認ができなければ無限に時間がかかります。

要するに条件次第です。あくまでも、tcpとudpは中間層のものであり、ネットワーク利用者からすれば手段に過ぎないものです。アプリケーションプログラム設計時に、目的に応じて使い分けるべきであり、一概に物理量で比較することは困難です。

tcpとudpの切り替えは、プログラム設計の段階で想定していない限り困難です。dnsをtcpにすべきだったとは昔から言われておりますが、もう修正困難だそうです。そもそもtcpは双方向通信が前提であり、単方向ネットワークや同報通信では利用できません。

ちなみにudpだとしても、アプリケーション層レベルで疎通確認をするプログラムを作れば高信頼化可能です。アプリケーションプログラマからみれば、tcpは疎通確認を出来あえ機能に任せているだけです。通信速度が求められないならば作りやすさでtcp、udpを選ぶというケースが多いのが正直なところです。