Posted inDevelopment

WebRTCマスター：Node.jsでゼロからP2Pビデオ通話アプリを構築する

Development tutorial - IT technology blog
Development tutorial - IT technology blog

なぜビデオ通話は多くの開発者にとって「悪夢」なのか？

ZoomやGoogle Meetが数百万の通話を同時に処理する方法を不思議に思ったことはありませんか？そのスムーズなインターフェースの裏側には、レイテンシ（遅延）、帯域幅、そして非常に厄介なNAT越え（NAT traversal）といった「マトリックス」のような用語が隠れています。最大の課題は映像を表示することではありません。本当の難しさは、異なるネットワークにある2つのデバイスが、どのようにお互いを「見つけ出し」、直接データをやり取りするかという点にあります。

従来のクライアント・サーバーモデルでは、すべてのデータがサーバーを介す必要があります。これにより、サーバーの運用コストが急増し、遅延も500msを超えることが多く、ユーザーに強い不快感を与えます。最適なソリューションはPeer-to-Peer（P2P）接続です。これにより、データはブラウザ間を直接行き来し、安定したネットワーク環境下では遅延を100ms未満に抑えることができます。

WebRTC：ブラウザが「仲介役」を務める時

WebRTC (Web Real-Time Communication) は、直接的な通信の課題を解決するために誕生しました。しかし、魔法のように勝手につながるわけではありません。P2P通話を確立するには、2つのブラウザが互いのIPアドレスと、相手がサポートしているビデオ/オーディオコーデック（H.264やVP8など）の情報を知る必要があります。

ここで矛盾が生じます。サーバーなしで直接接続するために、最初の情報を交換するためのサーバーが…やはり必要になるのです。これをシグナリングサーバー (Signaling Server)と呼びます。

1. シグナリングサーバー：静かなる案内人

見知らぬ人に電話をかけるシーンを想像してみてください。共通の連絡帳がなければ、相手の番号を知ることはできません。シグナリングサーバーはその連絡帳の役割を果たします。両者がお互いの構成を理解するためのSDP (Session Description Protocol)と、接続に使用できるネットワーク「座標」のリストであるICE Candidatesを交換する手助けをします。

2. NAT và STUN/TURN：ファイアウォールの壁を越える

私たちの多くは、ルーター (NAT) の背後でウェブを閲覧しています。ローカルIPアドレス（192.168.1.xなど）は、パブリックなインターネット環境では全く役に立ちません。本当のIPアドレスを見つけるために、ブラウザはSTUNサーバーに問い合わせます。統計によると、STUNは一般的な接続パターンの約80〜90%を解決できます。

残りの10%はどうでしょうか？非常に厳しいファイアウォール（Symmetric NAT）を備えた企業ネットワークなどでは、STUNは機能しません。この場合、データを転送（リレー）するためにTURNサーバーを使用することが必須となります。リソースは消費しますが、通話を途切れさせないための最後の「救命ボート」となります。

教訓： 日本のクライアント向けの実際のプロジェクトで、Googleの無料STUNサーバーだけを使っていたことがありました。その結果、クライアントが社内ネットワークでテストした際、ビデオが読み込み中のまま接続エラーになってしまいました。商用製品を開発する場合は、Coturnなどの独自のTURNサーバーの設定を絶対に怠らないでください。

コードを書き始める：ビデオ通話アプリの構築

Node.jsをシグナリングサーバーとしてSocket.ioを使い、ブラウザに標準搭載されている純粋なWebRTC APIを組み合わせて構築します。

ステップ 1: シグナリングサーバーのセットアップ

まず、プロジェクトを初期化し、環境を構築します：

mkdir webrtc-app && cd webrtc-app
npm init -y
npm install express socket.io

server.js ファイルは、ユーザー間のメッセージを転送するハブの役割を果たします：

const express = require('express');
const app = express();
const http = require('http').createServer(app);
const io = require('socket.io')(http);

app.use(express.static('public'));

io.on('connection', (socket) => {
    socket.on('join', (roomName) => socket.join(roomName));

    socket.on('offer', (offer, roomName) => {
        socket.to(roomName).emit('offer', offer);
    });

    socket.on('answer', (answer, roomName) => {
        socket.to(roomName).emit('answer', answer);
    });

    socket.on('ice-candidate', (candidate, roomName) => {
        socket.to(roomName).emit('ice-candidate', candidate);
    });
});

http.listen(3000, () => console.log('サーバーが http://localhost:3000 で起動しました'));

ステップ 2: クライアント側のWebRTCロジックの実装

インターフェース public/index.html には、2つのシンプルなビデオ枠が必要です：

<!DOCTYPE html>
<html>
<body>
    <video id="local" autoplay muted style="width: 45%; border: 2px solid #333;"></video>
    <video id="remote" autoplay style="width: 45%; border: 2px solid #007bff;"></video>
    <script src="/socket.io/socket.io.js"></script>
    <script src="main.js"></script>
</body>
</html>

「魂」となる部分は public/main.js にあります。非同期データストリームの処理方法に注目してください：

const socket = io();
let localStream, peerConnection;
const config = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };

async function init() {
    // カメラとマイクへのアクセス権限を取得
    localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
    document.getElementById('local').srcObject = localStream;
    
    socket.emit('join', 'room-1');
    peerConnection = new RTCPeerConnection(config);

    // トラックを接続に追加
    localStream.getTracks().forEach(track => peerConnection.addTrack(track, localStream));

    peerConnection.ontrack = e => document.getElementById('remote').srcObject = e.streams[0];
    
    peerConnection.onicecandidate = e => {
        if (e.candidate) socket.emit('ice-candidate', e.candidate, 'room-1');
    };
}

// シグナリングイベントの処理
socket.on('offer', async (offer) => {
    if (!peerConnection) await init();
    await peerConnection.setRemoteDescription(new RTCSessionDescription(offer));
    const answer = await peerConnection.createAnswer();
    await peerConnection.setLocalDescription(answer);
    socket.emit('answer', answer, 'room-1');
});

socket.on('answer', a => peerConnection.setRemoteDescription(new RTCSessionDescription(a)));

socket.on('ice-candidate', c => peerConnection.addIceCandidate(new RTCIceCandidate(c)));

init();

デプロイ時によく接続が「切れる」のはなぜか？

数多くのWebRTCプロジェクトをデバッグしてきた経験から、最も一般的な3つの原因をまとめました：

  • HTTPS의 잊어버림: ブラウザはSSLを使用していない場合、カメラなどの機密性の高いAPIを完全にブロックします。本番サーバーではHTTPSが必須です。
  • レースコンディション (実行順序のエラー): remoteDescription が設定される前に ICE candidate を追加しようとするケースです。常に次の手順を守ってください：Offer受信 -> Remote設定 -> Answer作成 -> Local設定。
  • 企業のファイアウォール: シグナリングは正常に動作している（SDPの交換ができている）のにビデオが真っ暗な場合、100%データをリレーするためのTURNサーバーが必要です。

おわりに

Offer -> Answer -> ICE Candidates というシグナリングの流れをしっかり把握すれば、ビデオ通話の実装は難しくありません。しかし、数千人のユーザーが利用する安定した製品にするためには、ビットレートの最適化や再接続処理についてさらに深く掘り下げる必要があります。まずはこの小さな例から始めて、複雑なシステムに挑戦する前にリアルタイム通信の本質を理解しましょう！

Share:
Tags: