WebRTCの定義

WebRTCは、2つのブラウザ間でP2P接続を確立し、音声やビデオなどのデータを交換できるようにするJavaScript API のセットで、音声やビデオ通話機能を持つアプリケーションを作成することができます。

WebRTCの特徴は、一度接続が確立されると、サーバーにタッチすることなく、ブラウザ間で直接リアルタイムにデータを転送できることです。サーバーを介さないことで、データがサーバーを経由する必要がないため、待ち時間が短縮されます。このため、WebRTCは音声やビデオの交換に最適です。

詳細なビデオチュートリアルは「WebRTC はどのように機能するのか？」を参照ください。

WebRTCとWebSocketsの比較

WebRTCがどのように機能するかを説明する前に、WebRTCとWebSocketsの比較を見てみましょう。

WebSocketsを使えば、ピア間の接続を確立してリアルタイムでデータを交換することもできますが、この接続はクライアントとサーバーの間で行われます。つまり、私があるピアにメッセージを送ると、そのメッセージはまずサーバーに送られ、次にサーバーがそのメッセージを他のピアに送ります。このやりとりは通常とても速く行われるので、多少の遅延があっても、チャットメッセージや何らかの通知を送信している場合は、おそらく気づかないほどでしょう。

さて、WebSocketsを使って音声やビデオを交換したいとしましょう。

ここで問題なのは、オーディオやビデオに関しては、わずかな遅延も非常に目立ち、多くの問題を引き起こす可能性があることです。つまり、ビデオデータがサーバーに到達し、ピアに戻るまでに、かなりの遅延が発生することになります。

そこで、WebRTCが意味を持つのです。2 つのブラウザ間で接続を確立してデータを交換することで、サーバーが追加する可能性のある遅延をなくすことができます。WebRTC はまた、UDP（User Datagram Protocol）を使用しています。UDP はデータを高速に転送するのに適していますが、これについては後ほど説明します。

WebRTCが高速なのに、Websocketsを併用する理由は？

WebRTCには一定の制限があるため、一般的にはWebsocketを併用したWebRTCを使うことが多くなっています。

まず、WebRTCはUDPを使用してますが、UDPは重要なデータを転送するための信頼できるプロトコルではありません。UDPはデータを高速に送信することには長けていますが、データを受信しているかどうかをチェックすることはありません。そのため、UDPはデータが高速に転送され、数フレームが失われたとしても大きな問題にはならないので、ビデオには最適ですが、ファイルを送信する必要がある場合、数バイトのデータが失われると、ファイル全体が破損してしまう可能性があります。

また、WebRTC には信号が組み込まれていないため、単独でP2P接続を確立することはできません。WebRTC は接続が確立されるとすべてを処理しますが、2つのピアを接続するための初期データの送信方法はP2P各拠点が担うことになります。

どのような仕組みなのか

接続を確立するために、ピア1はピア2に対して何らかのメッセージを送信します。

ピア2は、ピア1からこの情報を受け取ると、接続を受け入れる機会を得ます。ピア2が承諾すると、自分のネットワークとその接続方法に関する情報を収集し、その情報をピア1に送り返します。

両者が互いの情報を取得すると、接続が確立され、サーバーを介さずにブラウザ間で直接オーディオやビデオのデータなど、送信したいものの交換を開始することができるようになります。

2つのクライアント間で何が、どのように送信されるのか

まず、情報の送信方法は通常、シグナリングと呼ばれるプロセスを介して行われます。2つのピアはお互いを知らないため、通常、WebSocketやサードパーティのシグナリングサービスなどを使用して、2つのピアを1つのチャネルにまとめる方法があります。

それらを同じチャネルまたは部屋に持ち込むと、接続の詳細を介して信号を送ることができるようになります。これらの接続の詳細は、セッション記述プロトコル（SDP）およびICE候補の形式で提供されます。

SDP ：セッション記述プロトコル（SDP）は、コーデック、アドレス、メディアタイプ、オーディオ、ビデオなどのセッション接続に関する情報を含むオブジェクトです。両方のピアがSDPを交換するため、相互に接続する方法を理解できます。1つはSDPオファーの形式で、もう1つはSDPアンサーの形式です。

Ice Candidates ： ICE候補は、データを受信するアドレスである可能性のあるパブリックIPアドレスおよびポートです。各ユーザーは通常、STUNサーバーに一連のリクエストを行うことで収集された複数のICE候補を持っています。

最初に、2つのピアは、何かしらのシグナリング方法を使用してSDPを交換します。2つのSDPが交換されると、ピアは接続されますが、まだデータを送信できません。

2つのピア間でデータを交換するには、データを送信する必要があります。ここでの問題は、現在ほとんどのデバイスがファイアウォールとNATデバイスの背後にあるため、パブリックIPアドレスの検出を調整するためにICEと呼ばれる方法を使用することです。

したがって、バックグラウンドでSDPオファーが交換されると、各ピアはSTUNサーバーに一連の要求を行い、使用するICE候補のリストを生成します。STUNサーバーは安価でメンテナンスが簡単で、無料のサービスがたくさんあるので、セットアップについて心配する必要はありません。

ピア1がこれらのICE候補をSTUNから取得すると、それらはピア2に送信され、ネットワークが使用するのに最適な候補を決定できるようになります。ピア2は、ICE候補を要求してから、ピア1に送信することで同じことを行います。

これらの情報が交換され、最適なパスが検出されると、2つのピア間でデータが流れ始める可能性があります。

ICE候補取得時の問題

ICE候補を取得するプロセスには、時間がかかるという問題があります。そこで、STUNサーバーからICE候補を受信したら、それを1つずつ送っていく「Trickle ICE」という方法をよく使います。

動作確認

シグナリングサーバーなしでSDP転送プロセスがどのように 動作するかを確認できるデモを作成しました。このライブデモでは、2つのタブを並べて開き、2つのピア間でSDPオファーとアンサーを作成し、転送します。ICE候補は作成時にSDPオファーに追加されるため、ICE候補の問題に対処する 必要はありません。