リアルタイム性の高い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の通信量比較

仮定

  1. HTTPのヘッダ長は200 byte
  2. 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 対応ライブラリ

※一部のみ抜粋。上記以外にも「対象言語 + WebSocket」でググればいろいろ情報出てきます。

WebRTCについて

WebRTC(Real-Time Communication) とは、Webブラウザ間のテキストチャット/ボイスチャット/ビデオチャット/P2Pファイル共有などが、プラグイン無しで行えるリアルタイムコミュニケーション用のAPI定義です。

単一の規格ではなく、WebでRTCを行うための仕様群

WebRCTを構成する仕様

  • 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 のようなプラットフォームを活用すれば比較的カンタンに環境は構築できそう

参考文献