プロダクトエンジニアリング部の関川です。 最近リモートワークを行う上で欠かせないツールがリアルタイムコミュニケーションツール。 ZoomやDiscordなどの製品はそれぞれの方法でリアルタイムコミュニケーションを可能にしてきましたが 民主化された技術の一つとして、WebRTCという技術があります。 この記事はWebRTCに調べる機会があったので、基本的なWebRTCについてとその仕組みについて備忘録のような形でまとめました。 インフラ初心者でもわかりやすいように心がけて書きました。 触りやこんな技術なんだということをお伝えできれば幸いです。
WebRTCってなに？
WebRTCのRTCは Real Time Communicationの略で、文字通りwebにおけるリアルタイムコミュニケーションを実現する技術です。 ブラウザ間での映像、音声などのデータを相互にやり取りのできるように作られており、2012年頃にGoogleによってオープンソース化されました。 専用のアプリケーションを必要とせず、ウェアラブルデバイスとの通信に用いられたりと幅広い利用がされています。 強みとしては、レイテンシーの少なさと多くのブラウザが標準対応を行っていることで、特にChromeやSafariに新たに機能追加など行うことなく利用できる点は 導入へのハードを大きく下げ、誰でも簡単にリアルタイムコミュニケーションができることへの貢献になりました。
さて、このWebRTCを支える基礎技術についての説明をします。
WebRTCを支えるネットワーク技術(基礎)
P2P通信とは？
P2P通信はPeer to Peerの略です。Peerとは英語で対等、同等の意味を持つ単語で文字通り、対等同士の通信ということになります。
よく比較されるのが、サーバークライアント型の通信です。サーバーに問い合わせて、情報もらう形式などサーバーから送られる情報とクライアントから送られる情報とでは
かなりの差があるのに対して、P2P型は対等な立場で情報を共有するという特徴を持っています。
大きな差としてはサーバークライアント型と比べて負荷分散がされている点と回線が非常に軽いです。
UDP
UDPとはユーザ データグラム プロトコルの略で、これは名前での理解はなかなか難しいですね笑 ちなみにプロトコルとは各々が統一性のない好き勝手な情報を伝えないように取り決めた約束事のことです。 では何の約束事かというと、UDPはデータを送るための形式の定義です。 UDPの話をするときに必ず出てくるといっても過言ではないのがTCP（トランスミッション コントロール プロトコル）です。 この2つはよく比較されますが、その違いを端的に言うと、データをどれだけ確実に送りたいかです。 情報の欠落などの不具合を避けるためTCPはコネクションを作成し、送られてきたデータの順番に間違いや欠落がないかを確認して、正しく送られてきたかを常に確認します。 一方UDPはコネクションの手順などを省き、受ける側がデータを受け取ったかを確認する作業も省略します。 これだけ聞くとTCPの方が優れているように思えますが、リアルタイム性を求める場合はUDPの方が早いことは確かです。 通常のコミュニケーションでも一言一言に対して、「今の聞こえた？」「聞こえたよ」と確認することはないため、WebRTCとの相性はよいのです。 WebRTCは音声や映像はただ伝えるだけという特徴を生かしてUDPに対して独自の再送制御を作って、リアルタイムコミュニケーションを実現しています。
WebRTCの基本構成
どのようにWebRTCがつながるのか続いて説明します。
ここではP2P通信を前提として話を進めていきます。
WebRTCの構成はこのような構成になります。
P2P通信するといっても
「P2P通信ってことはサーバーレスなんでしょ？なんでサーバーが必要なの？」と上の図を見て感じた方もいるのではないでしょうか？ 確かにP2P通信はサーバーを必要としませんが、それは相手について知っていたらの話です。 いざブラウザ同士でP2P通信するぞとなっても、相手はネットのどこかにいる名前も住所もしゃべる言語も知らない相手です。 特定することは難しいでしょう。 そのため必要なのがシグナリングサーバーです。
シグナリングサーバー
シグナリングサーバーとは通信するために必要な情報を相手に伝えるためのサーバーです。 各ブラウザはシグナリングサーバーを経由してプロトコルの交換や通信経路の探索など行うための情報を共有します。 その時に用いられるのがSDP (Session Description Protocol)です。 SDPとは、通信を行う際、お互いがどのような映像・音声のコーデックを使えるかなど通信における取り決めをやりとりするためのプロトコルで 様々な情報を含んでいますがまず重要なのが以下の二つです。
セッションを構成するメディア
そのメディアを受信するために必要な情報(アドレス、ポート、形式など)
これらの情報をシグナリングサーバー経由で互いに送りあうことで、P2P通信のための準備を整えていきます。
P2P通信確立の流れとしては
① SDPをブラウザAが作成して、それをシグナリングサーバーに送信し、ブラウザBに送る。これをoffer SDPといいます。
② もう片方のブラウザが受け取り、その中で自分も使えそうななどを探し、通信できるものを返す。これをanswer SDPといいます。
これで双方がどうのように通信するのかは確立できます。 ただし、これだけではまだP2P通信は確立できないのです。
通信の壁、NAT
確できない理由をNATの説明とともに行います。 NATとはネットワークアドレス変換のことを意味し、一般家庭などではブロードバンドルーターやWiFiルーターがその役割を果たしています。 1つのグローバルIPアドレスを、複数のPCやデバイスで共有することができるようにする仕組みです。 また複数のPC/デバイスが同時に通信できるように、ポートマッピングによるポート変換も行っています。 このNATを超える作業がP2P通信を行う上で非常に重要になります。
ブラウザは基本知りうる情報はNAT内部のこと つまり
ローカルネットワークのIPアドレス
自分のUDPポート ですがローカルネットワークのＩＰアドレスを相手に伝えたところで通信できるはずがありません。 たとえば、マンションの部屋番号がわかっていても、住所がわからないのでは相手に物を送ることはできません。 そのため、ネットワークの外から見た情報（グローバルIP、NATによって割り当てられたUDPポート）を得る必要があるのです。
STUNサーバー
グローバルIPアドレスがわからなければ誰かに教わる必要があります。そのために必要なのがSTUNサーバーです。
STUNとはSession Traversal Utilities for NATsの略です。
これは通称"NAT越え"を行う際に用いられる手段で、ネットワークの外から見た自分の情報を教えてくれるサーバーです。
よく鏡のような役割と例えられます。（自分を写してくれる的な意味で）
③ STUNサーバーから得られた情報をシグナリングサーバー経由に送り、相手の SDP で受信したリストから候補となる IP/ポートのペアを取得し、そこに STUN リクエストを送信する。
④ 相手のブラウザから応答が返ってきた場合、発信元のブラウザはチェックが成功したと見なして、その IP/ポートのペアを有効な接続候補として認定する。
この接続候補をICE Candidateといいます。ICEとはInteractive Connectivity Establishmentの略で、 ブラウザを取り巻く環境は人それぞれ違うため、互いにP2Pの通信のできそうなIPやポートをかき集めて、相手と共有し、接続確認を行うためのプロトコルです。
基本的にはこのICE Candidateで通信可能経路を見つけることができれば晴れてP2P通信が可能な状態になります。 ただし、この際UDPホールパンチングを行うため、それが可能な環境でなくてはP2P通信を確立できません。 ここまでのP2P通信前提のWebRTCは、STUNによりNATを超えることができなかった場合には、基本的に通信は困難なものになります。
TURNサーバー
STUNでも超えられないNATを超えるために必要なのがTURNサーバーです。TURNはTraversal Using Relay around NATの略称で
パブリックIPアドレス上に TURN サーバーを置き、 UDP 通信を行うブラウザ同士は直接的には TURN サーバーにデータを送信し、 TURN サーバーは受け取ったデータをそのままもう一方へとリレーする、という仕組みです。
P2P通信ができないと判断した場合に補助的に用いる場合もありますがTURNでデータをやり取りする場合は基本的にはP2P通信ではなくなります。
まとめ
上記の内容は基本的にはWebRTCの初めの一歩なものです。皆様の役に立てば幸いです。 個人的には将来的にはVRデバイスなども用いた開発ができると面白いことができるだろうなと感じました。 この技術を勉強することは通信やインフラの知識をつけるという観点でもおすすめの技術なので、試しに触ってみてください。 またそこから安定性などを求めたりすると数多くのプロトコルやハードウェアや回線などの戦いができる初心者でも楽しめて、なおかつやりこみ要素の高い技術です。
LIFULLでは一緒に働く仲間を募集しています。よろしければこちらも合わせてご覧ください。
