Cometとは何か？リアルタイムWebの歴史と実装パターン完全ガイド
エバープレイ編集部Cometとは — 概要と定義
Comet（コメット）とは、Webブラウザとサーバ間で「サーバからクライアントへリアルタイムに近い形でデータを送る」ための一連の技術／手法の総称です。従来のリクエスト／レスポンス型（クライアントが要求してサーバが応答する）とは逆に、サーバ側で発生したイベントをクライアントにプッシュすることを目的としています。厳密な単一プロトコルではなく、長時間接続やストリーミングといったHTTPの応用テクニック群を指す呼称です。
歴史的背景と用語の成立
Cometという呼び名は2000年代中頃に普及しました。Webがよりインタラクティブになり、チャットや通知、株価更新など「サーバ側の変化を即座に反映したい」ニーズが高まる中で、従来のポーリングだけでは遅延や無駄な通信が増える問題が顕在化しました。これに対して、ブラウザ側での定期的なポーリングではなく長時間の接続を維持してサーバから随時データを送る手法群が広まり、Cometと総称されるようになりました。
代表的な実装パターン
長いポーリング（Long Polling / Reverse-Ajax）
クライアントがサーバへリクエストを行い、サーバは新しいデータがあるまで応答を遅らせる。サーバがデータを返すとクライアントは再びリクエストを送る。疑似的にサーバからの「プッシュ」を実現するもっとも広く使われた技術です。実装は比較的簡単で、既存のHTTPインフラと互換性が高い一方で、接続断再接続のオーバーヘッドやスケーラビリティの課題があります。
HTTPストリーミング（Chunked Transfer / Streaming）
HTTPのチャンク転送（Transfer-Encoding: chunked）やレスポンスのフラッシュを利用して、単一のHTTPレスポンスを継続的に更新してクライアントが部分的に読み続ける方式です。ブラウザ側で受信したデータを都度処理することで、低レイテンシのプッシュに近づけます。ただしプロキシや中間機器がバッファリングすると動作しなくなる場面があります。
Forever Frame（Hidden iframe）
古いInternet Explorer向けに用いられた手法で、非表示のiframeのsrcに長時間応答するページを読み込ませて、サーバからスニペットを随時出力する方式です。クロスドメイン制約を回避する工夫など歴史的な背景がありますが、モダンなブラウザでは一般に使用されません。
multipart/x-mixed-replace などのコンテンツ置換
HTTPの特定のContent-Typeを使ってレスポンスを複数パートで送り、クライアントが切り替えて表示する古典的なテクニック。主に画像ストリーミングなどで歴史的に使われてきました。
Cometと関連技術の位置づけ
Server-Sent Events（SSE / EventSource）
SSEはHTML5で定義された仕組みで、サーバからクライアントへの一方向ストリーミングを標準API（EventSource）で提供します。Cometのアイデアを標準化したものと見ることができます。接続は単純で自動再接続・イベントIDなどが標準でサポートされますが、双方向通信はできません。
WebSocket
双方向通信に対応した新しいプロトコル（RFC 6455）。コネクション確立後はフルデュプレックスなメッセージ交換が可能で、Cometの多くの用途を置き換えました。低レイテンシかつオーバーヘッドが小さいため、リアルタイムアプリケーションの主流になっています。ただしプロキシやファイアウォールの影響を受ける場合があり、フォールバックとして長いポーリングなどが残っています。
技術的な注意点とHTTPの扱い
プロキシ／ゲートウェイのバッファリング：多くのリバースプロキシ（例：NGINX、Squid）やCDNはレスポンスをバッファリングするため、ストリーミングやチャンク転送が期待通りに動作しないことがある。対処としてプロキシ設定でバッファリングをオフにする、適切なヘッダを付与する等が必要。
接続の持続とリソース：従来のスレッド／プロセスモデルのWebサーバは多数の同時長時間接続を捌けない。イベント駆動（ノンブロッキングI/O）なサーバ（Node.js、Tornado、Nginx + push モジュール等）が必要になることが多い。
タイムアウトやネットワーク切断：ブラウザや中間機器が一定時間無通信で接続を切る場合があるため、心拍（heartbeat）や短時間ごとの短いメッセージ送信で接続維持を行うことが一般的。
HTTPヘッダとチャンク：Transfer-Encoding: chunkedで小分けにデータを送る、Content-Typeを適切に決める（SSEなら text/event-stream）等、プロトコルレベルの仕様を守ることが重要。
ライブラリやプロトコル
Comet時代には多くのライブラリとプロトコルが登場しました。Bayeuxプロトコル（CometD実装によく用いられる）、Atmosphere（Java向けのリアルタイムフレームワーク）、Socket.IO（当初はWebSocket環境でのフォールバックとして長いポーリング等を提供）などが代表例です。これらは接続の管理、再接続、イベントディスパッチ、フォールバック戦略などを抽象化してくれます。
ユースケース
- チャット・メッセージング
- リアルタイム通知（SNSの通知、アラート）
- 協調編集やコラボレーションツールのリアルタイム同期
- 市場データやログのストリーミング表示
- オンラインゲームの一部用途（ただし双方向性が重要なゲームはWebSocketが適する）
利点と欠点
利点
既存のHTTP基盤で比較的簡単に「プッシュ」に近い挙動を実現できる。古いブラウザでも工夫次第で対応可能。SSEのように一方向ストリーミングを標準APIで扱える手段がある。
欠点
接続のスケーリングが課題（多数の長時間接続を捌くためには非同期I/Oや特殊なインフラが必要）。中間機器によるバッファリングやタイムアウト、HTTPの制約（ヘッダやプロキシの挙動）により挙動が不安定になることがある。双方向通信が必要な場合はWebSocketの方が効率的。
ベストプラクティス
- ユースケースに応じて技術を選ぶ：単方向の通知はSSE、双方向はWebSocket、古い互換性が重要なら長いポーリングやライブラリでのフォールバックを検討。
- 再接続とバックオフ：接続喪失時に即時再接続するのではなく指数バックオフを用いる。SSEのEventSourceは自動再接続機能を持つ。
- 心拍（ping/pong）を実装して中間機器の切断を防ぐ。
- 認証：Cookieベースの場合はCSRF対策、トークン（JWT等）をヘッダで送る場合はCORSの設定に注意する。
- プロキシ設定：Nginx等を利用する場合はproxy_bufferingをオフにするなどストリーミング向けの設定を行う。
- 負荷試験を行い、同時接続数に対するサーバ挙動を確認する。
セキュリティの観点
Comet系の接続は通常のHTTP接続と同様にTLSの利用（HTTPS）を行うべきです。長時間接続は認証トークンの有効期限やローテーションの取り扱い、認証情報漏洩のリスクを考慮する必要があります。また、クロスサイトスクリプティング（XSS）やクロスサイトリクエストフォージェリ（CSRF）への対処、CORSポリシーの適正な設定が重要です。
現在の立ち位置と移行
CometはWebのリアルタイム機能を実現するための「過渡期」の技術群とも見なせます。SSEやWebSocketの標準化・普及に伴って、Cometの手法は徐々に置き換えられてきました。ただし現実にはプロキシや古いブラウザの存在、企業内システムの制約などから長いポーリングなどのフォールバック技術は今でも有用です。多くのモダンライブラリはWebSocketを第一選択としつつ、必要ならComet系のフォールバックを自動的に使う形で互換性を保っています。
まとめ
Cometは「サーバからクライアントへデータをプッシュする」ためのHTTPベースの技術群を指す概念で、長いポーリングやHTTPストリーミング、iframeを利用した古典的な手法などを含みます。SSEやWebSocketの登場でその位置づけは変化しましたが、実務上はまだ考慮すべき課題（プロキシ、スケーリング、フォールバック）があり、導入時には用途に応じた技術選定とインフラ設計が求められます。
参考文献
- Comet (programming) — Wikipedia
- Server-sent events (MDN)
- WebSocket (MDN)
- RFC 6455 — The WebSocket Protocol
- CometD — Bayeux プロトコル実装
- Server-sent events — Wikipedia
- NGINX as a WebSocket proxy (NGINX Blog) — プロキシとストリーミングの注意点
投稿者プロフィール
