LANファイル転送

WebRTC を使用して同一 LAN 内のデバイス間でファイルやテキストを直接転送。サーバー不要

LANファイル転送とは？

LAN ファイル転送は、同じローカルネットワーク上にある 2 台の端末間で、WebRTC のピアツーピア通信を使ってファイルやテキストを送受信するツールです。接続が確立されると、外部ストレージに一度アップロードするのではなく、ブラウザー同士で直接データをやり取りできます。オフィスの PC、検証端末、自宅ネットワーク、教室、研究室などで、USB メモリ、クラウドフォルダー、チャット添付が面倒なときに便利です。速度は LAN の状態、ブラウザー対応、端末性能に左右されます。機密ファイルでは相手端末を確認し、転送後に一時セッションを閉じることが重要です。

使い方

あるデバイスで「接続を作成」をクリックすると、システムが接続情報を含むQRコードを生成します
別のデバイスでQRコードをスキャンすると、ページが自動的に開き応答コードが生成されます
最初のデバイスで応答コードをスキャンすると、WebRTC接続が確立されます
接続後、両当事者はテキストメッセージと任意の種類のファイルを交換できます

転送のヒント

ファイル転送中は両デバイスをスリープ状態にせず、到達可能なネットワークに接続したままにしてください。タブを閉じたりデバイスをスリープさせたりするとWebRTCセッションが中断されます。
非常に大きいファイルや重要なファイルの場合は、ブラウザのメモリ・ネットワーク品質・デバイスの制限が信頼性に影響するため、転送後にダウンロードしたファイルを検証してください。

利用シーン

サーバーアップロードなしで近くのデバイスにファイルを送信するWebRTC接続を作成し、生成されたQRコードやリンクを同じネットワーク上の別のデバイスと共有してから、チャットエリアにファイルをドラッグします。ファイルチャンクはDataChannelを経由して転送され、受信側はブラウザから再構成されたBlobをダウンロードします。データがピアツーピアで移動するため、転送中にリレーサーバー、クラウドドライブ、ファイルストレージ仲介が内容を見ることはありません。

マシン間で簡易テキストメモをやり取りするピア接続が確立されると、このツールは軽量なローカルチャットのように動作します。メッセージングアプリやクラウドクリップボードが利用できない場合に、コマンド、URL、ワンタイムコード、短いメモをデスクトップからスマホに渡すのに便利です。メッセージはDataChannel上に留まり、外部サーバーを一切経由しないため、チャット履歴の同期やデバイスバックアップに表示されることはありません。

ブラウザ間の直接接続をテストするOffer/Answerフローでは、待機中、接続済み、失敗、切断などの接続状態が表示され、ネゴシエーションが失敗した際のリセットパスも用意されています。ピア接続は設定済みのICEサーバーを使用しないため、任意のインターネットトラバーサルではなくローカルまたは到達可能なピアに最適で、LAN専用トポロジの検証にまさに適しています。

チャット添付のサイズ制限を超えるファイルを転送するWebRTC DataChannelはストリームをチャンクに分割するため、数百MBの動画やログアーカイブもメール、Slack、ほとんどのメッセンジャーアプリのサイズ制限に引っかかることなくブラウザ間で直接移動できます。受信側がBlobを再構成してダウンロードする際にチャットエリアにプログレスイベントが表示され、ローカルネットワーク経由のパスはクラウドの往復を大幅に上回るスループットを維持します。

ハンドオフ後にセッションを閉じてOfferリンクを無効化する交換が完了したらリセットボタンでピア接続を切断し、QRコードやリンクの共有を停止して、遅れてきたピアがオープンなルームに接続できないようにします。機密ファイルの場合は、受信デバイスのブラウザダウンロード履歴もクリアし、Offer SDPを無効化してクリップボードからのリプレイを防いでください。

仕組み

LANファイル転送はWebRTC（Web Real-Time Communication）上に構築されています。WebRTCはRFC 8825-8835で定義されたW3C/IETF標準で、もともとはブラウザベースのリアルタイム音声・映像通信用に設計されました。同じピアツーピアの仕組みがRTCDataChannel APIを支えており、2つのブラウザ間でリレーサーバーを経由せず任意のバイナリペイロードを転送できます。チャネルを開くシグナリングはQRコードのハンドシェイクで行われます。オファー側がSDP（Session Description Protocol、RFC 8866）を作成し、メディアとデータ機能を記述したSDPをURLまたはQRコードにエンコードし、アンサー側が対向のSDPを返します。双方がリモートの記述を適用すると、ICE（Interactive Connectivity Establishment、RFC 8445）が候補トランスポートアドレスを収集します。各候補は（IP、ポート、プロトコル）のタプルに優先度を付加したものです。ホスト候補（デバイス自身のLAN IP）は同一ネットワーク上で通常優先されますが、srflx（サーバー反射、STUNバインディングリクエストから取得）やrelay（TURN中継、RFC 8656）の候補も優先度順に試行されます。接続性チェックとして候補間にSTUNバインディングリクエストが送信され、最初に成功したペアが選択された候補ペアとなります。ICEが接続状態に達すると、DTLS（Datagram Transport Layer Security、RFC 6347、RFC 5246/8446のTLS 1.2/1.3のUDP向け亜種）がSDP内の証明書ハッシュを使って双方のピアをフィンガープリント検証し、1-RTTハンドシェイクを実行します。DTLSセッションキーがその上のすべてのSCTP（Stream Control Transmission Protocol、RFC 4960/RFC 9260）パケットを保護し、各DataChannelは単一のDTLSアソシエーション上で動作するSCTPストリームのペアとなります。大きなファイルはDataChannel上でチャンクに分割して送信されます。ブラウザのSCTPレイヤーは各メッセージを約16KBのレコードに断片化し（デフォルトのSCTP MTUからDTLS + SCTP + チャンクヘッダーのオーバーヘッドを引いた値で、実装により異なり多くの場合16KBまたは64KB）、受信側はそれらを順序通りに再構成します。フロー制御と輻輳制御（RFC 4960 §6）が受信側の溢れを防ぎます。cwndはACK時に加算的に増加し、ロス時に乗算的に縮小するTCPのAIMDと同じ形状ですが、SCTPアソシエーション単位で適用されます。ギガビットLANでは、エンドツーエンドのスループットはワイヤ速度ではなくブラウザのメインスレッドでのエンコードコスト（各チャンクをArrayBufferビューに変換してSCTPスタックにプッシュする処理）により通常200〜400MB/sに制限されます。ページは受信チャンクを単一のBlobに再構成してダウンロードとして提供するため、受信側はピーク時にギガバイト単位のデータをメモリ上に保持せずに済みます。データはDTLS-SRTPスタイルの暗号化でピアツーピアに流れるため、中間ルーターおよびリレーサーバーは暗号文しか見えず、ページ運営者が平文を見ることはありません。またアップロードステップも存在しません。トレードオフはSDP交換に必要なシグナリングサーバーです。このページではQRコードとコピーペーストリンクを手動のサーバーレスシグナリングチャネルとして使用しており、これが2回のスキャンが必要な理由です。

WebRTCはW3C/IETF標準（RFC 8825-8835）で、ネゴシエーション用のSDP、候補収集用のICE、トランスポートセキュリティ用のDTLS-SRTP/DTLS-SCTPの3つのエンジンを束ねています。
QRコードハンドシェイクはサーバーレスのシグナリングです。オファー側がSDPオファーを公開し、アンサー側がSDPアンサーを返すだけで、中央サーバーがデータパスを見ることはありません。
ICE（RFC 8445）はホスト、srflx（STUN反射）、prflx（ピア反射）、relay（TURN、RFC 8656）の候補を収集し、接続性チェックに合格した最高優先度のペアが選択されたトランスポートとなります。
DTLS（RFC 6347）はSDPに固定された証明書ハッシュを使ったフィンガープリント検証付きの1-RTTハンドシェイクを行い、ワイヤ上のすべてのバイトを暗号化します。平文のHTTPやWebSocketへのフォールバックはありません。
DataChannelはSCTP-over-DTLS上で動作し、生のUDPではありません。SCTPはUDPソケットの上に順序付き・信頼性あり・メッセージ指向のストリームと輻輳制御（RFC 4960 §6）を提供します。
チャンクサイズはデフォルトで約16KB（ブラウザにより異なり、64KBの場合もあります）。受信側はチャンクを単一のBlobに再構成し、ファイル全体をメモリに保持しないためダウンロードをトリガーします。
ブラウザのメモリが実際の上限です。1GBのファイルは約1GBのArrayBuffer処理を伴うため、モバイル端末では実用的な上限は通常ネットワーク速度ではなく転送ごとに200〜500MB程度です。
WebRTCのNATトラバーサルにはネットワークをまたぐピア間でSTUN/TURNサーバーが必要ですが、このページは同一LAN内のトポロジを想定しているため、ホスト候補（LAN IP）が通常優先され、STUNサーバーは参照されません。

使用例

スマホからパソコンへ写真を送信

1. パソコン側で「接続を作成」をクリックして QR コードを生成
2. スマホでスキャンするとページが開き、応答コードが生成される
3. パソコン側で応答コードをスキャンしてハンドシェイクを完了
4. 送信したい写真を選択して送信ボタンをクリック

パソコンからスマホへファイルを送信

接続が確立したら、パソコン側で「ファイルを送信」をクリックし、ドキュメント、アーカイブ、動画などを選択。
スマホ側に通知が届き、ワンタップでファイルが保存されます。

テキストメッセージのやり取り

接続後、双方とも入力欄に文字を入力して送信できます。
追加のアプリは不要 - ブラウザ上でシンプルに双方向チャットが可能です。

よくある質問

ファイル転送はどのように動作しますか？

同じローカルネットワーク上の 2 台のデバイスが WebRTC ピアツーピアで接続します。シグナリングで接続が確立された後、ファイルはブラウザ間を直接やり取りされ、中間サーバーを通りません。速度はローカルネットワーク (Wi-Fi または有線) に依存します。一般的な Wi-Fi では 30〜150 Mbps が出ます。

ファイルはローカルネットワークから出ますか？

WebRTC 接続が確立されれば、いいえ。ファイルのバイトは 2 台のデバイス間でのみ流れます。接続が立ち上がる前に、小さなシグナリング手順 (セッション記述の交換) が調整サーバーを介して行われますが、その交換はメタデータであってファイル内容ではありません。

2 台のデバイスが接続できないのはなぜですか？

両方のデバイスが同じ Wi-Fi ネットワークまたは LAN セグメント上にある必要があります。企業ネットワークではピアツーピア接続をブロックしていることが多く、ゲスト Wi-Fi ではクライアント間が分離されている (「クライアント分離」) ことがよくあります。個人用の Wi-Fi やテザリングを試してください。どちらかのデバイスで VPN が動作していると直接ピア接続が阻害されることもあります。

ファイルサイズの上限はありますか？

WebRTC にプロトコル上の制限はありませんが、実用上の制限はブラウザのメモリとタブの稼働時間です。デスクトップではマルチ GB の転送は通常動作しますが、モバイルブラウザはタブをサスペンドして転送が中断することがあります。大きな転送中は両方のタブをフォアグラウンドに置いてください。

転送されるファイルは暗号化されますか？

はい。WebRTC のデータチャネルは DTLS-SRTP 暗号化をエンドツーエンドで使用します。同じ Wi-Fi にいる攻撃者でもファイル内容を読み取れません。シグナリング手順は調整サーバーへの HTTPS を使用します。両方のエンドポイントが信頼できる限り、転送はプライベートとして扱えます。

技術に詳しくないユーザーでも使えますか？

はい。ルームコードや URL を相手に共有すれば、相手はブラウザで開くだけで自動的に接続されます。アプリのインストールは不要です。インターフェースはプラットフォーム制限のない AirDrop のような感覚で、iOS Safari、Android Chrome、Windows Edge、macOS Firefox 間などで動作します。

複数のデバイスに同時送信できますか？

ほとんどのビルドは 1 対 1 のルームをサポートしています。複数の受信者に送るには転送を繰り返すか、マルチキャストツールを使用してください。WebRTC によるグループ転送は実装可能ですが、アップロード帯域幅を N 倍消費します。

LANファイル転送