こんにちは、@24guchiaです。
掲題の通り、イベントに登壇しました。
イベント URL はこちら。 WebRTC Meetup Online #1
登壇資料はこちら。
誰にも飲まれないようにありたい
こんにちは、@24guchiaです。
オライリーのハイパフォーマンスブラウザネットワーキングを読み終わりました。去年の 11 月に買って、なかなか難しく、積んだりしてたら時間かかりました。だいたい 350 ページくらいなので、それなりの文量です。
ハイパフォーマンスブラウザネットワーキング、他の本読んだり、積んだりしてたけど、やっと読み終わった!カバーよれよれ、ドッグイヤーしまくり、書き込みまくりボロになった。何回も前の記述読んで思い出さないといけないからなかなか大変だったわ。まとめてブログに載っけよう pic.twitter.com/I7ooD2J69O
— 24guchi (@24guchia) May 31, 2020
やっと読み終わって嬉しくてツイートしてしまったw
読み始めるきっかけは WebRTC を使って開発する上での基礎力作りです。
こんにちは、@24guchiaです。
Deploy your own video collaboration app in five minutes or less
Twilio Video が使えて、かんたんにビデオチャットができる OSS が Twilio 社よりでました。
特長としては、
というわけでやってみました。
こんにちは、@24guchiaです。
入社エントリーにある通り、bellFaceに入社しました。
bellFaceはOpenTokを使っているので、
チュートリアルをニート期間中にやってみましたのでまとめておきます。
なお、内容は執筆時点(2019年10月25日)のもののため、
最新の情報はドキュメントを参照してください。 “OpenTokのチュートリアルやってみた” の続きを読む
こんにちは、@24guchiaです。
先日参加したWebRTCミートアップの参加レポートです。
https://atnd.org/events/105581
聞く側兼、話す側でした。
このイベント、話す側もしたのは年始に書いた記事で
Twilio以外のコミュニティに顔出ししたいと書いた目標のためです。
引き続きやっていきたい。 “WebRTC Meetup Tokyo #21 参加レポート” の続きを読む
こんにちは、@24guchiaです。
Webの記事何本かと本2冊買って読んでみたので、一度、現状の理解を書いてみます。
ちなみに買った本は下の本と、
わか(った気にな)るWebRTCの電子版です。
https://booth.pm/ja/items/504677
読む順番としては、わか(った気にな)るWebRTCを読んで、
ざっくり概要を頭に入れてわかった気になってから、リックテレコムのWebRTCの本を読むと良いと思います。
いきなりリックテレコムから入ると心が折れること間違い無し。
最近、リックテレコムから販売されている本を買うことが増えてきた。
この記事は古いので、こちらの記事も参考にしてください。(2020年7月10日 追記)
WebRTCってそもそも何か、どういうところで使われてて、
どんなプロトコルが用意されているかが分か(った気にな)るようになります。
Twilioを使うにあたって、Twilioがそのあたり難しい部分を吸収したライブラリやSDKを用意してくれてるけど、
デバッグするにあたってあまりにも分からないことが多すぎたため。
Twilio使わないから知らなくても良いや〜って思わず、ネットワークについての勉強になるし、
最近ではiOS11からWebRTC対応されスマホ全般で使える技術となったので、
Web系の開発をしている人は押さえておくべき技術になっていくでしょう。
Web Real Time Communicationの略。名前の通り、
ブラウザでのリアルタイム性を持つコミュニケーション全般を取り扱います。
コミュニケーションは具体的に、音声通話や動画(ビデオチャット)などを指します。
特長はインターネット回線につながっているブラウザさえあれば、
上記コミュニケーションを行える点です。
もう電話機や専用のソフトウェアは必要なくなります。
Twilio
appear.in
Slack音声通話
などがあります。使ったことがあるサービスがあると思います。
はい、難しいですね
接続の確立について、オファーアンサーネゴシエーションという
ローカルとリモートの設定を交換する手法があります。
セキュリティを高めるためのファイアウォールや
NATの存在が接続の確立にあたっては障害となる。
その回避を行うため、特別なプロトコルが用意されています。
Network Address Translatorの略。
IPアドレスは有限の資源であり、資源の有効活用のために使われる。
グローバルIPをNAT機能持ちルータで、ルータ内のプライベートIPとの変換を行う技術。
NAPTであることがほとんどで、ポートの変換も行うことが多い。
正確にはNAPTだけど、一旦NATで統一します。
ピア同士が接続されるWebRTCだが、
NATの存在のため、接続先ピアがどのプライベートIPを持っているかが
外側からは分からないため、下記NAT越えが行われる。
上記問題への対応のため、ピアに直接パケットを送るために行われる手法・技術。
具体的には、ホールパンチという手法でNATを透過したテストパケットを送れるかどうかを試す。
NATの外から、プライベートIPアドレスとポート番号のペアを知るために行われる手法。
具体的には下記手法を試していく。
Interactive Connectivity Establishmentの略。プロトコルのひとつ。
NAT越えを行うための手法の一つ。ICEでは下記を行う。
上記が純粋な手法で、よくあるICEではSTUNプロトコルとTURNプロトコルを使い、
ピア同士の接続の確立を試みます。
また、VanillaとTrickleという拡張がある。
標準のICEを指す。拡張であるTrickleが出来たため、標準がVanillaと呼ばれる。
VanillaはすべてのIPアドレスとポート番号のペアを収集してから
すべて接続を試し、接続確立されたものから使用するペアを選択する。
バニラという単語自体には標準という意味がある。
ICEという名前のためのシャレみたいなもんでしょうね。
標準のICEに対し、拡張されたICEを指す。
Vanillaに対し、Trickleではペアを順次交換し、接続成功した時点で処理が終了されるので、
接続確立までがVanillaよりも速くできる可能性がある。
現時点ではChrome/Firefoxと一部ブラウザでしか対応していないため、
使用する際には最新の情報を調べてください。
Trickleは滴り落ちるという意味なので、ペアを少しずつ試すという点が
アイスが滴り落ちるのと様子に似ているからこの名前なんだと思います。
Session Traversal Utilities for NAT の略。プロトコルのひとつ。
これもNAT越えのための手法のひとつ。
STUNで対象のピアのネットワーク上にNATが存在するかどうかを確認するプロトコル。
テストパケットをSTUNサーバに送り、自分のIPが外部のネットワーク上からどういうIPで見えるかを確認します。
自分のIPと一致していれば、NATは存在しません。
NATが存在しなければ、NAT越えの必要なくパケットを送ることが出来ます。
存在する場合は、NATが一つ以上存在し、一番外側のNATの情報が取得できます。
STUNでアドレスとポートのマッピングを取得します。
このマッピング情報をもとにピア同士で接続するのがSTUNです。
Traversal Using Relays around NAT の略。プロトコルのひとつ。
TURNはSTUNの拡張プロトコル。ICEがホールパンチに失敗した場合、メディアリレーを行う。
ブラウザに実装されているTURNクライアントと、NATの外にあるTURNサーバと
接続先のピアがTURNサーバを経由し、メディア情報を交換している。
STUNとの違いはSTUNはピア同士で接続するのに対し、
TURNはピアとピアの間にTURNサーバが存在し、
TURNサーバ経由で接続する点が異なります。
同じNAT超えをしているし最初どういう関係かわかりませんでしたが、
iwashiさんからTwitterでリプライいただけたので書いておきます。
各プロトコルは独立している。TURNはSTUNの拡張プロトコル。
ICEはICE自身でのアドレスとポートのマッピングを行い、
さらにTURNとSTUNも利用するプロトコルです。
これらのプロトコルを用いて、ピア同士で接続できれば晴れてリアルタイムコミュニケーションが楽しめます。
Twilioではこの辺り難しいところを何も考えずに使える点が良いですね。
音声通話はもちろん、最近ではビデオチャット機能も充実してきているとのことなので、
手っ取り早くWebRTCに触れてみたい方はTwilioをさわってみてはどうでしょう。
どういう構成だとSTUNでつなぐことが出来て、