TURN サーバでよくある間違い

ライセンス

Creative Commons — 表示 - 非営利 - 改変禁止 4.0 国際 — CC BY-NC-ND 4.0

前提

TURN サーバを間違って理解している人が多いので雑にまとめておく。

TURN プロトコル自体を知りたい場合

WebRTC で利用されいる TURN プロトコルの解説

著者

• 商用 WebRTC SFU 開発者
• 商用 TURN サーバ実装者 (WebRTC SFU に組み込み)
• WebRTC プロトコルスタック実装者

よくある間違い

• TURN サーバはリレーするパケットの中身を見ることができる
  • TURN サーバを通るもともとのパケットを復号化したりしない
  • ただ通信が暗号化されていなければ見ることはできる
• TURN サーバはスケールが難しい
  • 1 接続事に独立しているので TURN サーバ同士で状態を共有する必要はないので難しくない
  • Username / Credential は RDB や KVS などに保存する必要があるのでそこはスケールがいるが、それは普通の話
• TURN サーバは Proxy を超えられない
  • HTTP-Proxy を超えるかどうかは TURN クライアント側の実装依存
• 同じ TURN サーバに接続しないと繋がらない
  • TURN サーバは個々の接続の「代理」を行うので、接続事にどれに繋いでもよい
• TURN サーバは WebRTC 専用
  • もっと昔からあった仕組み
  • モンストとかにも使われている
    • モンスターストライクのリアルタイム通信を支える技術 - ログミーTech
    • https://github.com/coturn/coturn/blob/master/README.turnserver の AUTHORS をどうぞ
• P2P 専用
  • 主に P2P に利用されるが UDP を利用できない場合のフォールバックとしてクライアントサーバモデルでも使われる
  • WebRTC SFU を立てても TURN サーバが必要な場合などもある
• 先に TURN-UDP を試して 、それがダメなら TURN-TCP 、そして TURN-TLS とフォールバックしていく
  • 実装依存かもしれないが、自分が今まで見てきた限り全て同時に試し、一番先に確立したのを利用するという仕組み

間違ってそうだけど正しい

• TURN プロトコルは暗号化されていない
  • TURN-TLS や TURN-DTLS を利用しない限り、パケットをそのままリレーするだけなの暗号化はされない
  • TURN は安全な通信を目的とするのが第一ではない
  • もともとのパケットを暗号化して送れば問題ない
• TURN-TCP と TURN-UDP over TCP がある
  • 正確には WebRTC で利用されるのは TURN-UDP over TCP であって TURN-TCP ではない
  • TURN-TCP は RFC 自体が別
  • RFC 6062 - Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
  • コントロールとデータで別々に TCP セッションを張る

蛇足

• 転送量がかかる
  • サーバ経由になるのだから当たり前
• TURN サーバを導入しても繋がらない
  • TURN-UDP / TURN-TCP / TURN-TLS で TCP/TLS を 443 番にして繋がらない場合はどう頑張っても繋がらないことがほとんどなので諦めるしかない