Zenn
🐕

ローカルネットワーク内のPeer同士がサーバーなしでP2P通信を行うLocal Peer-to-Peer APIがIntelから提案された

2024/02/13に公開
Web
WebTransport
tech

Local Peer-to-Peer API について

技術概要

Local Peer-to-Peer API は、現在 Intel や Twintag の方が検討中の Web ブラウザー API で、概要としてはこちらの Local Peer-to-Peer API Explainedがわかりやすい。細かい仕様は W3C の Local Peer-to-Peer API 記事に記載されている。

Local Peer-to-Peer API は、ブラウザー上でサーバーを用いずにローカルネットワーク上の Peer 同士が P2P 通信するための技術である。
WebRTC を利用しても P2P 通信は実現可能だが、signaling サーバーや TURN サーバーが必要であり、真にサーバーを使わずに P2P を実現することはできない。

以下の画像のように、Wireless Access Points を経由して直接通信したい場合に適切な技術が存在しないので、Local Peer-to-Peer API が提案されている。

引用: https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md

使用ユースケース 1: クロスデバイスワークフロー

1 人のユーザーが複数デバイスを利用し、ファイルやテキストをやり取りする。

例えば、iPhone に入っている画像や動画を Windows PC に送りたいようなケースが考えられる。
こういった状況では、クラウドのストレージ(Google Drive や Box, iCloud)を利用したり、Slack や LINE などのメッセージツールを使って転送することが多いだろう。
しかし、通信量上限があるテザリングなどを利用しているユーザーにとっては「ギガを使ってしまう」ため、あまり使いたくない方法である。また、通信量上限がない契約であったとしても、インターネットを経由する関係で、転送速度が遅いといった問題も発生する。

このようなユースケースでは、ローカルネットワーク上で P2P 通信が実現できると、高速な転送が可能となる。

使用ユースケース 2: オフラインコラボレーション

インターネット障害が発生したりインターネット通信が不可能な際に、インターネットを介さずに複数人でアプリケーションを利用する。

例えば、地震が発生してインターネットに障害が発生している状況の中で、メモを取りたいケースが考えられる。
こういった状況では個々人が紙やメモアプリでメモを取ると思われるが、これらのツールでは情報の共有が難しい。特に、避難所など大人数が収容されているような環境では、情報の共有は非常に重要である。

このようなユースケースでは、インターネットを必要としないコラボレーションツールが実現出来ると、情報共有の質が向上する。

技術概要を見た上での感想

WebRTC は確かに signaling サーバーや STUN サーバー、TURN サーバーといったサーバー群が必要だが、ローカル P2P 通信を前提としシグナリングの方法さえ工夫すればサーバーを用意せずに通信することは可能である。

具体的には、以下のシーケンスで実現できそうだ。

  • WebRTC で ice candidate(Private IP)を収集し画面に表示する
  • ファイルを転送したい 2 者がアプリケーションにアクセスし、Private IP を口頭で交換する
  • アプリケーション上で対向の IP アドレスを入力する
  • WebRTC DataChannel を使って対向と P2P 通信を行い、ファイルを転送する

WebRTC を利用したアプリケーションの場合、Private IP を共有する部分が面倒なのは事実なので、Local Peer-to-Peer API を利用することで AirDrop のようにデバイス検知出来るようになると UX 的にも高そうだ。

想定フローも以下の画像のように AirDrop ライクになっている。

引用: https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md

とはいえ、これが必要なユーザー(ユースケース)がどのくらい存在しているかは結構疑問で、優先順位が上がってくるかは気になるところ。
災害時の利用など非常に価値のある API だが、これによって発生するビジネスもそこまで多くないので、ブラウザーベンダー的にはビジネス上必要にならなければ開発したがらないのではないだろうか。
ブラウザーベンダーの回答を確認していきたい。

API の設計とサンプルコード

  1. LP2PReceiver インスタンスを初期化することで自身を他の Peer から検出できる状態にする
// Peer A
const receiver = new LP2PReceiver({
  nickname: "Peer A",
});

receiver.onconnection = (e) => {
  const conn = e.connection;
  console.log("Receiver: Got a connection!");
};

ローカルネットワーク上の Peer を検出する部分はプレゼンテーション APIにインスピレーションを受けており非常によく似ている。
プレゼンテーション API は、開いているプレゼンテーションページを別の端末(スマートフォンなど)から操作できるようにする API で、Local Peer-to-Peer API の思想とかなり似た技術である。
ちなみにプレゼンテーション API は 2024 年 2 月時点で Chrome/Edge は対応しているが、Firefox/Safari は対応しておらず、一般的な API ではない。

  1. 対向の PeerB が PeerA を発見し、コネクションを貼る
// Peer B
const request = new LP2PRequest({
  nickname: "Peer B",
});

const conn = await request.start();
console.log("Requester: Got a connection!");

コネクションを貼る際にはローカル HTTPSという手法を用いて、ローカルネットワーク上の Peer 間で相互に TLS 通信を確立する。
本来、HTTPS の通信には自己署名証明書かクラウドプロキシサービスが利用されるが、これらはクラウドサービスに依存した技術であるため、Local Peer-to-PeerAPI の前提と合わない。そこで、Local Peer-to-Peer API の中でローカル HTTPS という技術についても議論が進められている。
この仕様はまだ議論中で定まっていない。

  1. PeerA と PeerB 間でデータをやり取りする
// Peer A
conn.ondatachannel = (e) => {
  const channel = e.channel;

  channel.send("Good day to you, requester!");
};

// Peer B
const channel = conn.createDataChannel("My Channel");

channel.onmessage = (e) => {
  console.log(`Receiver: Received message: ${e.data}`);
};

データを送信する部分は WebRTC の RTCDataChannel API にインスピレーションを受けており非常によく似ている。

WebTransport への対応

WebTransport(QuicTransport)の対応も考えているようだ。

WebTransport を利用する場合でも、API の使用感はあまり変わらない。
LP2PRequest/LP2PReceiver インスタンスを LP2PQuicTransport/LP2PQuicTransportListenerに与えるだけである。
従来の Local Peer-to-Peer を利用する場合はローカル HTTPS によって相互の TLS 通信が確立されるが、QuicTransport を使った場合は相互の QUIC 通信が確立される。

// Peer A
const request = new LP2PRequest({
  nickname: "example-request",
});

const transport = new LP2PQuicTransport(request);

await transport.ready;

// Peer B
const receiver = new LP2PReceiver({
  nickname: "example-receiver",
});

const listener = new LP2PQuicTransportListener(receiver);

for await (const transport of listener.incomingTransports) {
  // Blocks until transport is ready.
  await transport.ready;
}

Local Peer-to-Peer API という技術において、QUIC を利用する価値があるかは正直わからない。
「低オーバーヘッドでより詳細なストリーム制御を必要とする通信のために WebTransport セッションを開くことができます」とドラフトに記載があるが、ローカルネットワーク内の通信においてそこまでオーバヘッドを追求したいかは不明。IoT の分野など、非常に大量のデータをやり取りするケースを考えると、オーバーヘッドが少ないことが効いてくるのかもしれない。

まとめ

  • インターネットを介さず、ローカルネットワーク上の Peer 同士で P2P 通信を実現する Local Peer-to-Peer API が Intel から提案された
    • これによりデバイス間のデータ転送を効率よく行ったり、災害時のコラボレーションツールの利用などができる
  • 合わせて Local HTTPS という技術も議論中
  • (感想) 提案されたがブラウザーベンダーが実装しないこともよくあるので、この API が実際に使えるようになるかは不明。価値はありそうだが、ビジネス的な側面ではブラウザーベンダーに旨みがなさそうで、優先順位は後ろになりそうな気がする

参照

Discussion