WebRTCと言えば時雨堂さん。
記事もたくさん書いていただいてて感謝しかない。
WebRTCについていちから知りたいという方への読み進め方のメモ、の転記。

注釈のついたものはその先のURLに詳細が書かれている。

まずはこのページを一読し、注釈1の「WebRTC コトハジメ」を読む。
次に概要を深堀りしたいなら、注釈から詳細のページへ。
最新動向を知りたいなら参考リンクの「WebRTC の未来」へ。
読み物やよりDeep Diveしたい場合は、参考リンクから各ページへ。

概要*1

WebRTC (Web Real-Time Communication)。
P2P、ブラウザ同士を前提とした技術で作られており、既存プロトコルなどの組み合わせで実現される。
P2Pを使わないことやブラウザ以外でのやりとりも不可能ではない。
映像、音声以外に、データの送受信もできる。
通信はデフォルトでDTLS(データグラム向けTLS)で暗号化されている。
NAT超えのためのプロトコルにSTUN/TURN、それらを組み合わせたICEと呼ばれる仕組みを採用。

WebRTCは具体的に定義されたプロトコルではなく、目的を達成するために数多くのプロトコルを利用して実現する抽象概念やその集合体。
マイクやカメラなどのデバイス管理やスクリーンキャプチャ、圧縮、P2Pや通信などもWebRTCの一部となる。
これらをブラウザから扱えるようにしたのがWebRTC API。
用意されたAPIを使う分には難しくないが、その範囲を逸脱するとハードルが突然上がる。

ブラウザへ標準搭載されるようになり利用の手軽さ、普及率がこれまでとは段違い。
Chromeで5年以上の実績があり安定している。
基本的な技術はすべて無料、オープンソース。

WebRTCはGoogleによってオープンソース化されていて、W3CとIETFで標準化が進められている。
リファレンス実装がフリーソフトウェアとして公開されているが、実現するための具体的な仕様がきめられていないため、様々な技術によって実装されていたりする。

チャネル

映像と音声のメディアチャネルと、なんでもOKなデータチャネルがある。

シグナリング *2

P2Pでセッションを確立するまでの事前準備をやり取りする仕組み、サーバーで、必ず必要。

STUNサーバー*3

NATを超えなければいけないかどうかを判断するプロトコル。
P2Pを前提とするならNAT越えで必要。

TURNサーバー*4

実際に NAT 越えを実現するプロトコル。
中身は複雑な動作をしている。
特定のネットワーク環境でつながらない場合に接続確率を上げる、それ以外では不要。
80 % は TURN が無くても繋がり、 10 % は TURN-UDP があれば繋がり、のこり 10 % は TURN-TCP と TURN-TLS があれば繋がるという話がある。