TURN

TURN(Traversal Using Relay around NAT)について



TURNは、NATやファイアウォールを越えて通信を行うための通信プロトコルであり、特にマルチメディアアプリケーションの接続において重要な役割を果たします。従来のTCPやUDPトラフィックでは接続が困難な対称型NAT環境にいるクライアントに対し、TURNを利用することで効率的なデータ通信が実現可能となります。このプロトコルは、RFC 5766で標準化されており、IPv6に対応するためのアップデートもRFC 6156に含まれています。さらに、TURNによって使用されるURIスキームはRFC 7065で詳述されています。

NATとその課題



NAT(Network Address Translator)は、通信において多くの利点を提供しますが、同時にいくつかの欠点も抱えています。その中でも、NATの存在は、多くの既存のIPアプリケーションに影響を及ぼすため、通信を行う上での障壁となります。特に、新しいIPアプリケーションの普及を妨げる要因にもなっているため、適切なプロトコルの設計が必要とされています。有名なプロトコルの一つであるSTUN(Session Traversal Utilities for NAT)は、NATを越えるための手段を提供していますが、全てのピアに対するアドレスが常に通用するわけではなく、ネットワークのトポロジーに依存しています。そのため、STUN単独では、全ての通信シナリオに対する完全な解決策とは言えません。

TURNの機能と役割



TURNは、完全な解決を提供するために設計されたプロトコルで、特にインターネット上のサーバを介してIPアドレスとポート番号を割り当てることが可能です。このプロトコルを通じて、クライアントはあらゆるピアからのデータを受け取るためのトランスポートアドレスを獲得します。全体の通信がTURNサーバを介して行われるため、TURNは高確率で通信の接続性を実現しますが、TURNサーバの運用にはコストがかかるため、通常は必要に応じてSTUNなどの他の手段を優先します。

TURNプロトコルの流れ



プロトコルを利用する際には、まずクライアントがTURNサーバに「割り当て(Allocate)」のリクエストを送ります。これにより、サーバがリレー用のアドレスをクライアントに割り当てると、サーバから「Allocation Successful」とのレスポンスが返却されます。次に、クライアントはTURNサーバに対し、CreatePermissionリクエストを行い、宛先との通信を認証するための許可を求めます。

データを送信するに際しては、クライアントは主に2つの方法、すなわち「Send」メカニズムまたは「ChannelBind」リクエストを選択します。Sendメカニズムは直接的な通信方法ですが、転送データのヘッダが大きくなるため、帯域幅に影響を与える可能性があります。一方、ChannelBindでは、軽量なヘッダでの通信が可能ですが、事前にチャネルを確保する必要があります。

TURNサーバは、クライアントからデータを受信し、宛先に向けてリレーします。宛先からのデータは再びTURNサーバを介してクライアントに戻される仕組みです。

TURNの利点と限界



TURNは、対称型NATを超えての通信を可能とするスタンダードなプロトコルであり、STUNプロトコルと比較して、より堅牢な通信を提供します。しかし、全てのトラフィックがTURNサーバを経由するため、バンド幅の負担が大きくなるという欠点もあります。そのため、ICE(Interactive Connectivity Establishment)プロトコルでは、まずSTUNを使い、必要に応じてTURNを利用することが推奨されます。これにより、最適な接続性が提供され、無駄なリソースの消費を防ぐことができます。

結論



TURNは、NAT環境でも信頼性のある通信を実現するための重要な手段ですが、正しい使用方法を選択することで、効率的なデータ伝送が可能となります。NAT越えにおいての課題に対し、TURNは有効なソリューションを提供し、現代のマルチメディア通信において不可欠な要素となっています。

もう一度検索

【記事の利用について】

タイトルと記事文章は、記事のあるページにリンクを張っていただければ、無料で利用できます。
※画像は、利用できませんのでご注意ください。

【リンクついて】

リンクフリーです。