画面をリアルタイムに更新するには、ポーリング、SSE、WebSocket をどう選びますか

3 つのやり方

• ポーリング画面が決まった間隔で「新しい物はありますか」とふつうの HTTP で聞きに行きます。作りはいちばん簡単で、今のサーバーのままで動きます。そのかわり、間隔のぶん遅れ、何も無いときの問い合わせも無駄に増えます
• SSE (Server-Sent Events) 画面が 1 本の HTTP の接続を開けたままにし、サーバーがそこへ知らせを流し続けます。ブラウザは EventSource で受け、応答の型は text/event-stream です。切れたら、ブラウザが既定で自動でつなぎ直します。向きはサーバーから画面への一方向だけで、画面から送るときはふつうの HTTP の要求を別に使います
• WebSocket 最初は HTTP の要求で「WebSocket に切り替えたい」と頼み (Upgrade)、サーバーが 101 で応じたあとは、同じ接続の上で両方向にいつでも送れます。これは HTTP/1.1 で始める場合の手順で、HTTP/2 や HTTP/3 の上で WebSocket を使う決まりもあり、その場合は始め方が違います (TCP そのものの話は別の問いに渡します)。暗号つきの wss と、暗号なしの ws があります

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

(HTTP/1.1 で始める場合の、要求と応答の主な行だけを抜き出した例です。実際には鍵の確かめのための行も付きます)

選び方の目安

決め手は「誰から誰へ送るか」と「どれくらい頻繁か」です。

• 知らせが数分に 1 回で、少しの遅れが困らない → ポーリング
• サーバーから画面へ流すだけ (進み具合、通知、LLM の答えを少しずつ出す) → SSE。LLM の答えを少しずつ画面に出す仕組みにもよく使われます
• 画面からも頻繁に送る (チャット、共同編集、対戦のゲーム) → WebSocket

SSE には数の限りがあります。HTTP/2 を使わないときは、ブラウザごと、ドメインごとに同時につなげる数が 6 本までです。タブを何枚も開くと足りなくなることがあるので、HTTP/2 で配るか、1 本にまとめる工夫をします。

つなぎっぱなしの弱点

SSE と WebSocket は遅れが小さいかわりに、次の手間を引き受けます。

• 切れたときの手当てスマホが電波の悪い所に入れば接続は切れます。WebSocket ではつなぎ直しを自分で作り、切れていた間の知らせを取り直す方法 (最後に受けた番号を送って続きをもらう、など) も決めます
• 認証と順番 WebSocket では、誰の接続かの確かめや、知らせの順番をどう扱うかを、アプリの側で約束として決めて作ります
• サーバーの台数を増やすとき 接続はある 1 台につながっています。ほかの台が受けた知らせを、その接続を持つ台へ届ける仕組み (台の間で知らせを配る中継) が要ります。ロードバランサーが長い接続を途中で切らない設定かも確かめます

だから、要件が「数秒遅れてよい」なら、まずポーリングで出し、遅れや問い合わせの量が問題になってから SSE や WebSocket に移る、という順も十分に良い選択です。

自分が関わったサービスで、どの仕組みを選び、なぜほかを選ばなかったかを 1 つ用意して話すと伝わります。架空の例なら「注文の進み具合を出す画面は、サーバーから流すだけなので SSE にし、つなぎ直しはブラウザに任せた」のように話せます。