WebRTCファイル転送を使うと、2つのブラウザが、クラウドストレージにアップロードすることなく互いにファイルを 送れます。簡単そうに聞こえますが、インターネットは家庭のパソコン同士が直接やり取りするようにはつくられて いませんでした。このガイドでは、StrongFolderを例に、実際に何が起きているのか — シグナリング、NAT、STUN、 ICE、TURN、DTLS、データチャネル — をわかりやすく解説します。
WebRTCとは何ですか？
WebRTC（Web Real-Time Communication）は、W3CとIETFが標準化した、ブラウザ間の リアルタイム接続のためのブラウザAPIとネットワークプロトコルの集まりです。Chrome、Edge、Firefox、Safari、 Operaのすべてが対応しています。ビデオ通話や音声通話のためにつくられましたが、あらゆるバイナリデータを運ぶ データチャネルも備えています。ファイルとは、まさにそのバイナリデータです。
重要なのは、WebRTC接続がいったん確立すると、データはサーバーのストレージではなく2つの端末の間を流れる ことです。これがブラウザでのP2Pファイル転送を可能にしています。
なぜ2つのブラウザは単純に直接つながれないのですか？
自分専用のパブリックアドレスを持っているデバイスがほとんどないからです。あなたのノートパソコンは、家庭の ルーター、オフィスのファイアウォール、携帯キャリアのネットワークの内側にあります。ルーターは NAT（Network Address Translation）を行い、多数のプライベートなデバイスで1つのパブリック IPアドレスを共有し、内側から送ったものへの応答だけを通します。
そのため、2つのブラウザは、ファイルのデータを流す前に3つの問題に直面します。
- 互いに到達する方法がわからない — どちらも相手の存在を知らない。
- 自分のパブリックアドレスがわからない — 知っているのは192.168.1.20のようなプライベートアドレスだけ。
- ルーターが要求していない外部からの通信をブロックするかもしれない。
WebRTCは、それぞれの問題を別々の仕組みで解決します。
WebRTCファイル転送はステップごとにどう動きますか？
「共有」をクリックしてから最後の1バイトまでの全体の流れは次のとおりです。
Sender browser Servers Recipient browser
────────────── ─────── ─────────────────
1. Choose files ──── metadata ──▶ Signaling server
◀──────── 2. Open link ────────
3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP)
4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?"
5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates
6. ICE checks: try LAN → direct internet → TURN relay
7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake
8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk
ステップ1〜2 — シグナリング。 送信者がファイルを選び、サービスはリンクに必要なメタデータを記録します。 受信者がリンクを開くと、両方のブラウザがシグナリングサーバーに接続します。WebRTCは シグナリングの方式を定めていません。StrongFolderはPeerJSと独自のシグナリングサーバーを使っています。
ステップ3 — オファーとアンサー。 一方のブラウザが、SDP（Session Description Protocol）でオファーを 作成します。「データチャネルを使いたい。これが私の暗号化のフィンガープリントと機能です」という内容です。 もう一方はアンサーで応えます。どちらもシグナリングサーバーを通って送られます。
ステップ4 — STUN。 各ブラウザはSTUNサーバーに「私はどのアドレスとポートから来て いるように見えますか？」と尋ねます。その答えが、ルーターによって割り当てられたパブリックアドレスです。 STUNサーバーが扱うのはごく小さなリクエストだけで、ファイルのデータは扱いません。StrongFolderは、Googleの ものを含む公開STUNサーバーと独自のSTUNサーバーを使っています。
ステップ5 — ICE候補。 各ブラウザは、自分に到達できる可能性のある方法、つまり候補を集めます。 ローカルネットワークのアドレス（host）、STUNで得たパブリックアドレス（server-reflexive）、TURNリレー上の アドレス（relayed）です。これらの候補をシグナリング経由で交換します。
ステップ6 — 接続チェック。 ICE（Interactive Connectivity Establishment）が候補の 組み合わせを試し、使えるもののうち最適なものを選びます。両方のデバイスが同じWi-Fiにあれば、ローカルの経路が 選ばれます。ルーターが許せば、インターネット上の直接経路（「ホールパンチング」）が選ばれます。直接の経路が どれも使えなければ、リレー経由の経路が使われます。
ステップ7 — DTLS。 データが流れる前に、ブラウザ同士はDTLSハンドシェイク （UDP向けに調整されたTLS）を行い、証明書のフィンガープリントがオファーとアンサーに含まれるものと一致するかを 確認します。これ以降、すべてが暗号化されます。
ステップ8 — データチャネル。 DTLSの上ではSCTPが動き、データチャネルに確実で順序どおりの配信を 提供します。StrongFolderでは、受信者のブラウザがファイルを要求し、送信者のブラウザがディスクからファイルを 少しずつ読み込んで送り、受信者は届いた断片を順にディスクに書き込みます。そのため、非常に大きなファイルでも メモリに収める必要はありません。
STUN、TURN、ICEなどの用語はどういう意味ですか？
| 用語 | 役割 | ファイルのデータが見えるか | 標準 |
|---|---|---|---|
| シグナリング | ブラウザ間でオファー、アンサー、候補を受け渡す | 見えない | 標準化されていない（アプリごと） |
| NAT | 1つのパブリックIPを多数のデバイスで共有するルーターの機能 | — | — |
| STUN | ブラウザに自分のパブリックアドレスとポートを伝える | 見えない | IETF RFC 8489 |
| ICE | 候補を集めて使える経路を選ぶ | 見えない | IETF RFC 8445 |
| TURN | 直接の経路が使えないときに通信を中継する | 暗号化されたパケットのみ | IETF RFC 8656 |
| DTLS | 接続を暗号化する（UDP向けのTLS） | 暗号化する | IETF RFC 9147（1.3）、RFC 6347（1.2） |
| SCTPデータチャネル | 断片を確実に順序どおり届ける | 運ぶ（暗号化された状態で） | IETF RFC 8831 |
これらはすべて用語集で簡単に説明しています。
TURNリレーはいつ使われ、何が見えるのですか？
リレーはあくまで代替手段であり、標準ではありません。ICEがリレーを使うのは、直接の候補の組み合わせが どれもつながらない場合だけです。典型的には、シンメトリックNATのネットワーク（一部の携帯キャリア）、 外向きのUDPをブロックする企業のファイアウォール、特定のVPNなどです。
直接接続できない場合（厳しい企業ファイアウォールや一部のモバイル回線など）、暗号化された ストリームはStrongFolderのリレー（TURN）サーバーを経由します。リレーはデータを中継する だけで、保存はしません。
リレーはDTLSで暗号化されたパケットを受け取り、そのまま転送します。リレーにわかるのは、通信が流れていること、 その量とタイミングであり、中身ではありません。リレー経由の転送は、すべてのバイトがリレーを余分に往復する ため、直接の転送より遅くなることがあります。転送が異常に遅い場合は、別のネットワークを試してください。 オフィスのネットワークでは直接つながらなくても、スマートフォンのテザリングや自宅のWi-Fiなら直接つながる ことがよくあります。
無料 · ブラウザで · 登録不要
WebRTCの暗号化はどのくらい安全ですか？
WebRTCでは暗号化が必須で、暗号化されていないデータチャネルを開く方法はありません。DTLSは2つのブラウザが 取り決めた最新の暗号方式を使い、接続ごとに新しい鍵が作られます。
ただし、すべてのWebRTCサービスに当てはまる注意点が1つあり、正直にお伝えします。2つのブラウザは、 シグナリングサーバーを通じて交換された証明書のフィンガープリントで互いを確認します。つまり、サービスの シグナリングがそれを改ざんしないことを信頼していることになります。だからこそStrongFolderは、自社の保護を 転送中の暗号化と説明しており、あなたが鍵を持つエンドツーエンド暗号化とも、「ゼロ知識」とも呼んで いません。「安全」の意味をより広く知りたい方は、安全なファイル共有と セキュリティとプライバシーをお読みください。
なぜ送信者のブラウザを開いたままにする必要があるのですか？
送信者のブラウザこそがファイルの送り元だからです。代わりに頼れるサーバー上のコピーはありません。データ チャネルが送信者のディスクから断片を読み込めるのは、タブが開いていてデバイスが起動している間だけです。 受信者のダウンロードが終わるまで、送信者のブラウザタブを開いたままオンラインにしておく必要があります。ファイルはサーバーではなく送信者のデバイスから届くためです。 これにどう備えるかは 送信者がオンラインでいる理由で解説しています。
WebRTCファイル転送の速度はどのくらいですか？
決まった速度はありません。上限は経路上で最も遅い区間、多くの場合は送信者の上り速度で決まります。目安として、 1 GBは50 Mbpsで約2.7分、100 Mbpsで約80秒、高速なローカルネットワークなら1分を大きく下回ります。実際の転送は、 プロトコルのオーバーヘッド、ディスクの速度、そしてリレーを使う場合は余分な経由によって、これらの数値より やや遅くなります。1つのリンクを複数の受信者が開けます。各受信者は送信者から直接ダウンロードします。 同時に複数のダウンロードがあると、送信者の上り帯域を分け合います。
まとめ
WebRTCファイル転送は、短い交渉と、その後に続く長い暗号化されたストリームでできています。シグナリングが ブラウザ同士を引き合わせ、STUNとICEがNATを越える経路を探し、最後の手段としてTURNが中継し、DTLSで暗号化 されたデータチャネルがファイルをディスクからディスクへ運びます。送信者として実際に何を意味するのかを知るには、 まずブラウザでのP2Pファイル転送と StrongFolderの仕組みをお読みください。