TURN

角度の単位については「turn (角度)」をご覧ください。

TURN (Traversal Using Relay around NAT) とは、マルチメディアアプリケーションがNATやファイアウォールを超えて通信することを補助するための通信プロトコルである。TURNが一番役立つのは、TCP, UDPを使って対称型NAT (Symmetric NAT) 装置により隠蔽（マスカレード）されたプライベートネットワークに接続されたクライアントを利用する場合である。一方、NATの背後におかれたwell-knownポートを使って動作するサーバに接続��る目的には利用できない。TURNはNATの背後にあるシングルピアのユーザ、例えばIP電話、に接続する際に役立つプロトコルである。

TURNはRFC 5766で標準化されており、IPv6用のアップデートはRFC 6156である。TURNが使うURIスキームはRFC 7065に記述されている。

NAT (Network Address Translators) には多くのメリットがある一方で、多くの欠点も持っている。一番厄介な欠点は、多くの現存するIPアプリケーションに弊害をもたらし、また新しいIPアプリケーションの普及に障害となることである。どのようにすればNATの下でも機能するプロトコルが作れるかを記述したガイドラインが数多く開発されてきた。しかし、多くのプロトコルがそれらのガイドラインに沿って作ることができなかった。構築できなかったプロトコルの例としては、マルチメディアアプリケーションやファイル共有関連のプロトコルがある。

STUN (Session Traversal Utilities for NAT) は、アプリケーションがNATを越えるための1つの方法を提供する。STUNはクライアントがピアからのパケットを受信するために利用するトランスポートアドレス（IPアドレスとポート）を入手することを可能にする。しかしながら、STUNによって入手されたアドレスはすべてのピアに対して利用可能ではないかもしれない。それらのアドレスは、ネットワークのトポロジー的状況に依存して機能する。そのため、STUNはそれ自身ではNAT超えについて完全な解決を提供することはできない。

完全な解決には、インターネットにパケットを送信することができるあらゆるピアから、クライアントがメディアを受けることができるトランスポートアドレスを入手できることが必要である。これは、インターネット上に存在するサーバを通過したデータに頼ることによってのみ達成することができる。この仕様はTURN、つまり上記のようなサーバを通過したデータからのIPアドレスやポートをクライアントが獲得することを可能にする通信規格を記述している。

TURNはほとんどの場合にクライアントに接続性を提供するが、それはTURNサーバの提供者にとって高いコストがかかる。それゆえ、STUNなどの他の手段が利用可能な場合はそちらを利用し、TURNを最終手段として利用することが望ましい。この方法を達成するために、ICE (Interactive Connectivity Establishment) という方法は、接続性の最適な方法を発見するために使うことができる。

データ転送のためにクライアントコンピュータが宛先のコンピュータに通信するとき、クライアントと宛先の双方がそれぞれNATの背後にいて、通信ができないという状況が始まりである。対称型NAT（STUNと互換性のないNATタイプ）の場合、TURNを用いなければならない。

最初、クライアントはTURNサーバに「割り当て (Allocate)」要求を出す。割り当て要求とは、クライアントが宛先に通信するためにTURNサーバにリソースを割り当てることを依頼するものである。もし割り当てが可能ならば、TURNサーバはリレー用のアドレスを割り当てたうえで、クライアントに対し「Allocation Successful」レスポンスを返す。このレスポンスの中にはリレー用にTURNサーバに割り当てたトランスポートアドレスが入っている。

次に、クライアントはTURNサーバに対し、CreatePermission要求を出し、宛先とTURNサーバ間の通信のための認証システムを作ることを要求する。このチェックシステムは、サーバが宛先に通信し、宛先からリレーのためにTURNサーバに送り返してきた情報が、正当な通信であることを確認するために用いる。

通信が許可された後、クライアントには実際のデータを送るにあたって、2つの選択肢がある。

1. Send機構を使う。
2. ChannelBind要求を出し、チャネルを確保する。

Send機構は直接的な方法であるが、36バイトと大きなヘッダを必要とし、TURNによるリレー通信のためのバンド幅を無視できない程度に増加させてしまう。これに対し、ChannelBindによる手法は軽量であり、ヘッダは4バイトのみであるしかし、チャネルを確保しておく必要があり、そのために定期的にリフレッシュが必要である。

SendまたはChannelBindのどちらの手法を使うにせよ、TURNサーバはクライアントからデータを受け取り、UDPデータグラムを使って宛先に転送する。データの中にはソースアドレスとして、割り当てられた転送用トランスポートアドレスが含まれている。宛先はデータ���受け取り、再びUDPデータグラムを転送プロトコルとして用いてTURNサーバのリレー用アドレスに送る。

TURNサーバは宛先からUDPデータグラムを受け取り、認証をチェックしもし正当であれば、これをクライアントに送る。

この方法により、対称型NATの問題を回避することができる。クライアントと宛先の双方とも転送用に割り当てたIPアドレスを持つTURNサーバに対してだけ通信を行えばよいためである。

様々なNATを超えた通信ができるという意味で、TURNはSTUNよりも堅牢であるがTURNでは全通信がTURNサーバを経由するため、STUNプロトコルよりもサーバに必要なバンド幅が大きい。そのため、ICEプロトコルにおいては、まず最初にSTUNを採用することが必須条件であり、TURNは対称型NATやその他のSTUNでは解決できない状況を解決するために用いられる。

• STUN
• Interactive Connectivity Establishment (ICE)
• NAT traversal

（すべて英文）

• RFC 5766: Traversal Using Relays around NAT (TURN)
• Yahoo! - Director of Engineering explaining STUN and TURN (Video)

• Numb is a free STUN/TURN server.
• TurnServer - OpenSource TURN server.