リアルタイム性の高いWebアプリケーションを作りたい時のヒントになれば
ex. テキストチャット、複数ユーザーが同時編集するようなサービス
キーワード
- Polling
- WebSocket
- WebRTC
Pollingについて
Polling は、一般的なHTTPリクエストを使用した手法で一番取り組みやすい手法。
- Polling: Ajaxを使用して、クライアント起因で定期的にサーバーに接続を行う
- Long Polling(Comet): アクションはPollingと同じだが、サーバーからのレスポンスを一定時間引き延ばすことにより、Ajaxより、より多くのデータを取得できる可能性がある
WebSocketについて
WebSocket は、コンピュータネットワーク用の通信規格の一つ。
URIスキームは ws:
と wss:
メリット
- 要求がクライアント側のみでなく、サーバー側からも行える
- HTTPレスポンスヘッダに比べて、フレームサイズが小さい
- データ送信の多様性
- クライアント・サーバー、双方向から任意のデータを送信可能
- 送信完了前に、別の送信を開始可能
- 送信がクロスしても、問題ない
デメリット
- 未対応ブラウザの可能性がある
- ただし、モダンブラウザの多くで対応済み
- WebSocketプロトコルに未対応のネットワーク機器が多い
-
wss://~
(https://~
のようなもの)を用いれば解決。TLS/SSLで暗号化後のレイヤなので、通信経路上では見分けが付かない。
-
HTTPとWebSocketの通信量比較
仮定
- HTTPのヘッダ長は200 byte
- WebSocketはマスク有り(4 byteのMasking-keyあり)
本文が10 byteの場合
- HTTP
- 200 + 10 = 210 byte
- WebSocket
- 基本ペイロード長の範囲に収まる
- 6 + 10 = 16 byte
本文が1024 byteの場合
- HTTP
- 200 + 1024 = 1224 byte
- WebSocket
- 拡張ペイロード長で+2 byte
- 8 + 1024 = 1032 byte
まとめ
- 本文が小さいほど、HTTPとの差が顕著
- 小さいメッセージを頻繁にやり取りするケースで、WebSocketは特に有利
言語別 WebSocket 対応ライブラリ
- Node.js
- Golang
- Scala
※一部のみ抜粋。上記以外にも「対象言語 + WebSocket」でググればいろいろ情報出てきます。
WebRTCについて
WebRTC(Real-Time Communication) とは、Webブラウザ間のテキストチャット/ボイスチャット/ビデオチャット/P2Pファイル共有などが、プラグイン無しで行えるリアルタイムコミュニケーション用のAPI定義です。
単一の規格ではなく、WebでRTCを行うための仕様群
WebRTCを構成する仕様
- PeerConnection
- クライアント同士をP2Pで接続するための仕様
- 下位層はUDP
- DataChannel
- 任意のデータをPeerConnection経由で送るための仕様
- テキストメッセージ・ドキュメント・写真等、使い方は自由
- MediaStream
- ブラウザから、マイクやカメラへアクセスするための仕様
- MediaCaputureで取得したStreamを、PeerConnection経由で通信相手とやり取り
- 正確には、WebRTCの一部ではない
PeerConnectionについて
- STUNサーバ(STUN:Simple Traversal of UDP through NAT、別名:UDPホールパンチング)
- NATの内側にあるノードから、グローバルなIP/Portを確認して「穴」を開ける仕組み
- シンメトリックNAT
- 「内側から外へアクセスした時の相手先からのアクセス」のみポートマッピングが有効
- それ以外は遮断
- STUNサーバでないクライアントは、STUNサーバ向けに開けられたIP/Portを使っても別クライアントへ接続できない
- 「内側から外へアクセスした時の相手先からのアクセス」のみポートマッピングが有効
- TURNサーバ(TURN:Traversal Using Relay NAT)
- NATの内側にあるノードに対して、透過的な経路(トンネル)を提供する
- すべての通信をパススルーするので、ノードが増えるほどTURNサーバーの帯域が消費される
- STUNサーバに比べ、運用コストが高い
- ICE(Interactive Connectivity Establishment)
- 常にSTUNを使うと、シンメトリックNATの場合に、到達できない
- 常にTURNを使うと、コストが高い
- ICEは、STUNが使えない時だけ、TURNへフォールバックする仕組み
まとめ
- Web APIに比べて、ネットワーク周りのハードルが高い
- SkyWay のようなプラットフォームを活用すれば比較的カンタンに環境は構築できそう
参考文献
- 「WebSocket / WebRTCの技術紹介」
- 「リアルタイムなwebアプリを実現する方法(ポーリング、Comet、Server Sent Events、WebSocket)」
さいごに
個人ブログにオリジナル(日本語&英語)をUPしています。
この記事が良いと感じた方は、そちらにもリアクション頂けると嬉しいです
https://blog.n11sh1.com