リアルタイム性の高いWebアプリケーションを作るために必要そうな技術

リアルタイム性の高い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 対応ライブラリ

• Node.js
  • Socket.IO
• Golang
  • gorilla/websocket
• Scala
  • Play Framework

※一部のみ抜粋。上記以外にも「対象言語 + 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の技術紹介」
  • https://www.slideshare.net/mawarimichi/websocketwebrtc
• 「リアルタイムなwebアプリを実現する方法(ポーリング、Comet、Server Sent Events、WebSocket)」
  • https://www.kimullaa.com/entry/2016/01/17/231359

さいごに

個人ブログにオリジナル（日本語＆英語）をUPしています。
この記事が良いと感じた方は、そちらにもリアクション頂けると嬉しいです
https://blog.n11sh1.com