数年前からUDPへの言及が増えてきたようです。実際には海外でよく使われており、北米では2000年初期だけでもゲームサーバーと動画サービスの主要プロトコルはUDPが使用されていました。まだ大半の商用ゲームサーバーは、UDPを主要プロトコルとして使用しています。
UDPが頻繁に言及され始めた時期は、2013年にGoogleが発表したQuicと、海外の商用ゲームネットワークライブラリとサービスが国内に公開されてからのようです。ゲーム関連のサービスやライブラリは、Apple、GoogleのP2PのマルチプレイヤーゲームAPIとPhoton、RakNet、UnityのUNetなどが代表的です。そしてTCPとUDPの両方が実装されている推奨プロトコルはUDPです。
ここでは、UDPを使用するときに考慮すべき内容について紹介したいと思います。

マルチプレキシング

マルチプレキシングを使用する主な理由は、head of blockingを防止するためです。1つのTCPは、単一チャネルを使用するので、意味単位またはドメインが他のデータの遅延やパケット損失に影響を与えます。そのため複数のチャネルを使用して不必要な遅延を防ぐ手法です。Webブラウザの場合、たくさんのHTTP要請を処理するため、一般的に6個程度のTCPソケットを使用します。6個より多くTCP接続を使用することになれば、性能的な問題を引き起こすことになるでしょう。しかし、UDPを用いると性能的に多くの利点があります。ゲームも各ゲームオブジェクトに別途チャネルを割り当てて性能向上を期待することができます。

様々なQoSに対応

TCPは1つのタイプのQoSを提供するプロトコルです。すべてのデータは、信頼性の高い順番に配信されます。つまり、TCPが提供するQoSは、すべてのアプリケーションに適用できますが、すべてのアプリケーションに最適のプロトコルであるとは限りません。様々な形態のQoSがありますが、代表的なものとしてゲームの音声やビデオ通話でよく使用されているQoSでは、信頼性がありませんが、順番に配信される方式を使っています。もちろんゲームやビデオ通話の実装は、アプリケーションの特性に合わせて異なります。つまり、UDPでアプリケーションとデータの特性に合わせてプロトコルを実装できます。

速いconnection establishment

TCPでSSLを使用する場合、3-wayハンドシェイクを実行して、暗号化のためにデータ交換が行われた後、接続が成立するため、4回のRound tripが発生します。これに対してUDPを使用する場合、1回のRound Tripで完了させることができます。HTTPプロトコルを想定すると非常に有用な技術です。1回のRound Tripで接続を成立させるのは特別な技術も必要なく、それほど難しくはありません。問題はWebサービスではなく、他のタイプのサービスに適用したとき、IOの側面からパフォーマンスの問題を引き起こすことがないかということです。

混雑回避アルゴリズム

TCPが使用する代表的な混雑回避アルゴリズムは、Cubic、Renoなどがあります。TCPの混雑制御アルゴリズムは、カーネルレベルで駆動するため、混雑回避アルゴリズムを変更するには、カーネルレベルの変更が必要になります。サーバーは可能ですが、クライアント環境においては、決して容易ではないでしょう。さらに、モバイル環境が普及するにつれ、ネットワーク環境によって動作する混雑回避アルゴリズムは、時によって適合しない可能性があり、リソースの浪費につながる場合があります。しかし、UDPの場合、混雑制御アルゴリズムをユーザーレベルで実装するため、状況に応じて混雑制御アルゴリズムを変形できる大きな利点があります。

Forward error correction

FECは、無線通信やVoIPでよく使用される技術です。データ量が多くなく、無線通信のようにデータの送受信コストが高い場合、FECを使って当該区間の再送信を減らす技術です。アプリケーションの特性が一度に送信するデータが約400byte以下の場合、非常に効率的に動作します。

Wi-Fi Cellular handover

モバイル環境において、Wi-FiネットワークとCellularネットワークの切り替えは頻繁に発生します。TCPはIPに基づいて接続を維持するので、このような環境変化に対応するには多少不向きですが、UDPを使用すると、IPの変化に柔軟に対応できます。少なくともCellularからWi-Fiへの切り替えは、非常に簡単に行われます。しかし、Parking-lot problemと呼ばれるユーザーが、Wi-FiからCellularにゆっくりと移動するシナリオを処理するのは容易ではありません。

暗号化

暗号化は、ネットワークプロトコルとは区別されていますが、必要不可欠な要素として同様に使用されるため、一般的にネットワークライブラリに含めて提供されます。実際のところ、機能の独立性のため、TCPでネットワーク接続とTLSを別々に実行する動作は、機能不足ではなく合理的であると言えます。しかし、UDPを使用すると不要なRound tripを減らすことができます。暗号化の適用形態にもよりますが、Quicは暗号化を内蔵して、全体のデータに対して暗号化を行うことで知られていますが、ゲームのようにデータの遅延に敏感なアプリケーションの場合は、一般的に必要な場合のみ暗号化を行えるように提供しています。大半の暗号化アルゴリズムは、ディフィー – ヘルマン鍵交換アルゴリズムを実行した後、一回限りの対称キーを生成して、暗号化を実行します。

これまでの内容で、UDPは実装だけでなく、場合によっては使うことも容易ではないことが分かりましたね。さらに、UDPは特定の環境で動作しないことがあります。それでも、モバイル環境とグローバル進出を考慮すれば、一度は検討するに値するでしょう。しかし、UDPを考慮する前に、適用するアプリケーションの特性について理解することが先行されるべきで、適用したときに得られる長所と短所を予め把握しておくことが重要です。