TURNサーバー：その概要、動作方法、使用場所

TURNサーバーとは

TURNサーバー（Traversal Using Relays around NAT）は、RFC 5766で定義されRFC 8656で更新されたネットワークサービスで、NATやファイアウォールの制限により直接のP2P接続が不可能な場合に、2つのクライアント間でUDPおよびTCPトラフィックを中継します。WebRTCアーキテクチャにおいて、TURNサーバーは最終的なフォールバックメカニズムとして機能し、あらゆるネットワーク条件下での接続性を保証します。

単にクライアントに外部アドレスを通知するSTUNとは異なり、TURNサーバーはデータ送信に積極的に関与します。各ピアはTURNサーバーとの接続を確立し、メディアデータを送信します。TURNサーバーはそのデータを相手のピアに転送します。結果として、ピア間に直接の接続はなく、すべてのトラフィックがリレーサーバーを通過するため、最も厳しいNAT制限下でも配信が保証されます。

TURNプロトコル

TURNはSTUNプロトコルの拡張です。TURNメッセージは同じ20バイトのヘッダーと属性メカニズムを使用します。主な違いは、TURNが新しいメッセージタイプ（Allocate、Refresh、Send、Data、CreatePermission、ChannelBind）とリレー割り当て管理に必要な属性を定義することです。クライアントはAllocateメッセージを介してTURNサーバーに割り当てを作成し、中継転送アドレス（relayed transport address）を取得して、サーバーを介したデータの送受信に使用します。

TURNサーバーの仕組み

TURNサーバーは次の一連のステップで動作します。クライアントは認証情報（username、credential）を添えてAllocate Requestを送信します。サーバーは認証情報を検証し、割り当て（クライアントに対する中継アドレス（TURNサーバー上のIP:ポート）の一時的なバインディング）を作成します。サーバーは中継転送アドレスを含むAllocate Responseを返します。これは、他のピアがTURNサーバーを介してこのクライアントにデータを送信するために使用するアドレスです。

割り当てが作成された後、クライアントはSend Indicationメッセージまたはチャネル（ChannelBind）を介してTURNサーバー経由でデータを送信できます。クライアントからデータを受信すると、TURNサーバーはパーミッション（特定のピアへのデータ送信の承認）を確認し、データを対象ピアに中継します。着信データを受信するには、クライアントは事前にデータを期待するピアのパーミッションを作成する必要があります。そうしないと、TURNサーバーは着信パケットを破棄します。パーミッションは、ピアのIPアドレスを指定してCreatePermissionメッセージを介して作成されます。

割り当てと有効期間

TURNサーバー上の割り当てには有効期間が設定されており、デフォルトは10分です。クライアントは割り当てを延長するために定期的にRefresh Requestを送信する必要があります。有効期間はLIFETIME属性で秒単位で指定されます。Refreshを受信しない場合、サーバーは割り当てを削除し、中継アドレスを解放します。推奨リフレッシュ間隔 — Refreshパケット損失に備えて5分（300秒）です。

WebRTCでのTURNサーバー設定

WebRTCでは、TURNサーバーはiceServers配列内のRTCPeerConnection設定を介して構成されます。TURNサーバーはUDP、TCP、またはTLSトランスポートを使用できます。認証は通常、アプリケーションサーバーで制限付きの有効期間で生成される時間制限付き認証情報（TURNクレデンシャル）を使用します。

JavaScriptでのHMAC-SHA1トークン認証を使用したTURNサーバー設定の例を考えてみましょう。

async function createPeerConnection(turnServerUrl) {
    const credentials = await fetchTurnCredentials();

    const config = {
        iceServers: [
            {
                urls: "stun:stun.l.google.com:19302"
            },
            {
                urls: turnServerUrl,
                username: credentials.username,
                credential: credentials.credential
            }
        ],
        iceTransportPolicy: "all"
    };

    return new RTCPeerConnection(config);
}

async function fetchTurnCredentials() {
    const response = await fetch("/api/turn-credentials");
    return response.json();
}

const turnUrl = "turn:turn.example.com:3478";
const pc = await createPeerConnection(turnUrl);

この例では、TURNサーバーはSTUNサーバーとともに単一のICE設定で指定されています。ICEプロセスは最初にhost候補とSTUNから取得したsrflx候補を使用しようとします。直接接続が失敗した場合、ICEは自動的にTURNサーバーから取得したrelay候補に切り替えます。パラメータiceTransportPolicy: "all"はrelay候補を有効にします。代替値"relay"はTURN以外のすべての候補を無効にし、テストに役立ちます。

TURNサーバー認証

不正使用を防ぐため、TURNサーバーは認証を必要とします。標準的なアプローチは、HMAC-SHA1を使用してアプリケーションサーバーで生成される時間制限付き認証情報です。アプリケーションサーバーはTURNサーバーの秘密鍵でユーザー名を暗号化し、usernameとcredentialをクライアントに返します。クライアントはそれらをRTCPeerConnection設定に渡し、ブラウザはTURNサーバー上で割り当てを作成する際にそれらを使用します。認証情報の有効期限が切れると、クライアントはアプリケーションサーバーから新しいものを取得します。

TURN vs STUN：比較

TURNとSTUNは関連するNATトラバーサルタスクを解決しますが、メカニズムとコストが根本的に異なります。TURNはトラフィックを中継し、仲介役として機能しますが、STUNは直接P2P接続のための外部アドレスの特定のみを支援します。どちらを選択するかは、ピアのNATタイプとパフォーマンス要件によって決まります。

実際には、TURNサーバーはP2Pが不可能な接続にのみ使用されます。Google（WebRTC統計、2023年）によると、すべてのWebRTC接続の約15～20%がTURN中継を必要とします。残りの80～85%はSTUNまたはローカルのhost候補を介して接続性を確立します。アプリケーションを設計する際、ユーザー層に企業ネットワークや厳しいNAT制限のある地域のユーザーが含まれる場合は、総メディア量の15～20%をTURNトラフィックに割り当てる必要があります。

TURNサーバーのコストとパフォーマンス

TURNサーバーはすべてのメディアトラフィックが通過するため、多大なリソースを消費します。TURN中継を使用する各アクティブコールは、総メディアトラフィックスループット（着信＋発信ストリーム）に等しいサーバー帯域幅を使用します。HDビデオ通話（720p）の場合、各方向で接続あたり1.5～2.5 Mbps、TURNサーバーを通過する総トラフィックは3～5 Mbpsになります。

TURNインフラストラクチャの展開にはいくつかのオプションがあります。無料のパブリックTURNサーバーは、品質とセキュリティの保証がないため、本番環境では推奨されません。商用プロバイダー（Twilio Network Traversal Service、Xirsys、Metered）は、ギガバイト単位の料金でTURNをサービスとして提供しています。標準的なコストはギガバイトあたり$0.005～0.02です。coturn（オープンソースTURNサーバー）を使用したセルフホスティングには、十分な帯域幅容量と監視設定を備えたサーバーが必要です。

• coturn — 最も人気のあるオープンソースTURNサーバーで、ほとんどの本番システムで使用され、UDP、TCP、TLS、DTLSトランスポートをサポートします。
• Twilio — トラフィックベースの料金と時間制限付きトークンによる認証を提供する商用TURN + STUNサービス。
• Xirsys — グローバルサーバーネットワークと詳細な使用状況分析を備えた専門TURNプロバイダー。
• Metered.ca — 月間最大50GBの無料枠とそれを超える分の従量課金制のTURNサービス。
• セルフホストcoturn — 設定を完全に制御できますが、サーバー管理と監視設定が必要です。

TURNサーバーソリューションを選択する際は、ユーザーの地理的条件、トラフィックコスト、セキュリティ要件を考慮してください。数千の同時通話を処理するアプリケーションの場合、広帯域（1+ Gbps）のサーバー上のセルフホストcoturnは商用プロバイダーよりも費用対効果が高い可能性があります。数十ユーザーの小規模プロジェクトの場合、管理と監視のオーバーヘッドがないため、商用TURNサービスの方が望ましいです。