SSE・WebSocketをスッキリ理解する
こんにちは！
35歳未経験からWebエンジニアの世界に飛び込んだ者です。
突然ですが、LINEなどのチャットアプリで、自分が何も操作していないのに「ポンッ」と新しいメッセージが表示されるのって、不思議に思ったことはありませんか？
実はこれ、「サーバープッシュ」という技術のおかげなんです。
この記事では、「サーバー側から勝手にお知らせを送ってくれる魔法の仕組み」について、スッキリ解説します！
この記事はこんな人におすすめ
・チャットアプリや株価のリアルタイム更新の仕組みが気になる方
・「WebSocket」や「プロトコル」と聞くだけで苦手意識がある方
・リアルタイム通信をどう実装すればいいのかイメージが湧かない方
結論（先にシンプルに）
サーバープッシュ技術の本質を一言でいうと
「毎回注文しなくても、お店（サーバー）から勝手におかわりを持ってきてくれるシステム」
大きく分けて2つの方法があります。
・SSE（Server-Sent Events）： 一方通行の「わんこそば」方式
・WebSocket： 双方向の「トランシーバー（電話）」方式
これだけ頭の片隅に置いて、次へ進みましょう！
1. 昔のWebとサーバープッシュの違い
まずは前提から。通常のWeb通信（HTTP）は「一問一答」のキャッチボールです。
お客さん（ブラウザ）が「これください」と言ったら、お店（サーバー）が「はいどうぞ」と渡して、それで通信はパタンと終わります。
これだと「新しいメッセージ来てないかな？」と、お客さんが数秒に1回お店に聞きに行かないといけません。
そこで生まれたのが、お店のほうから「新しいの入ったよ！」と送ってくれる
サーバープッシュ技術です。
2. SSE（Server-Sent Events）によるプッシュ配信
まずは、「SSE」という技術です。
一言でいうと
「一度のリクエストに対して、サーバーが少しずつ連続してデータを返し続ける仕組み」
より正確には
「サーバーからクライアントへの一方向のストリーミング通信」です。
具体例：連続で提供される「わんこそば」
これは「HTTPストリーミング」や「チャンク転送」という技術がベースになっています。
チャンク（Chunk）とは「塊」という意味。本来なら1杯の大きなラーメンとして出すところを、一口サイズの「塊」に分けて、連続でドンドンお椀に入れていくイメージです。
SSEのすごいところは、ブラウザ側に「わんこそば専用の受け皿（標準API）」が用意されているため、受信の処理がめちゃくちゃ簡単に書けることです。
【いつものHTTP（毎回注文）】
👨私「ラーメンちょうだい！」 ➔ 🍜店「はいよ！」（ここで関係終了）
👨私「水ちょうだい！」 ➔ 💧店「はいよ！」（ここで関係終了）
【SSE（チャンク転送・わんこそば方式）】
👨私「わんこそばよろしく！」 ➔ 🍜店「はいよ！」
（接続したまま） ➔ 🍜店「はいよ！」
（まだまだ終わらない） ➔ 🍜店「どんどん！」
⚠️ SSEの注意点
超便利なSSEですが、落とし穴があります。
ブラウザはHTTP/1.1の仕様上、同一ドメインへの同時接続数に制限（一般的に6接続）があります。
そのためSSEを多用すると、この制限に引っかかり通信が詰まる可能性があります。
3. WebSocketの登場
次は、リアルタイム通信の真打ち「WebSocket（ウェブソケット）」です。
一言でいうと
「双方向・高頻度・大量の通信をするために作られた、全く新しい通信ルール（プロトコル）」
※TCP上で動作する、HTTPとは別の専用プロトコルです
具体例：手紙から「電話」への切り替え
SSEが「サーバーからのわんこそば（一方通行）」だったのに対し、WebSocketは「お互いにいつでも喋れる電話（双方向）」です。
オンラインゲームのように、自分も「右に動いた！」と頻繁に送信し、サーバーからも「敵が出た！」と頻繁に受信するような場面で大活躍します。
ここで面白いのが、WebSocketの通信の始め方（ハンドシェイク）です。
最初はいつものHTTP（手紙）で挨拶をしておいて、途中から「プロトコルアップグレード」という仕組みを使います。
「最初は日本語（HTTP）で挨拶したけど、ここからは英語（WebSocket）で話そうぜ！」と、途中で言語（ルール）を切り替えるんです。
【プロトコルアップグレードの流れ】
👨私（HTTP）「WebSocketで話しませんか？」（ハンドシェイク）
💻鯖（HTTP）「OK！ここからはWebSocketで話そう！」
↓
⚡（切り替え完了！ここからは繋ぎっぱなしの爆速トーク）⚡
👨私「右に移動！」 ⇔ 💻鯖「敵が出現！」
👨私「攻撃！」 ⇔ 💻鯖「命中！」
💡 【補足】なぜ最初からWebSocketで話さないの？
ここまで読んで、「アップグレードとか面倒なことしないで、最初からWebSocketのルールで通信すればいいじゃん！」と思ったかもしれません。
一言でいうと、これには「ネットの通り道にいる『厳しい警備員』をスルーするため」という切実な理由があります。
インターネット上には、ファイアウォールやプロキシサーバーと呼ばれる「通信の安全を守る警備員」がたくさんいます。彼らはとても頭が固く、「いつも出入りしている『HTTP』という業者しかビルに入れない」というルールを持っています。
もし最初から「WebSocket」という見知らぬ業者がやってきたら、「誰だお前！怪しい言語を話すな！」と門前払い（通信ブロック）されてしまいます。
だからWebSocketは、最初は「どうも〜！いつものHTTP宅急便でーす！」と普通のフリをして警備員の前を通過するのです。そして、無事に目的の担当者（サーバー）のところへ辿り着いた瞬間に、「実はWebSocketです。ここからは専用回線でいきましょう」と制服を脱ぎ捨てて切り替えます。
既存のルール（HTTPしか通さない環境）を壊さずに、新しい通信を実現するための賢い工夫なんですね。
⚠️ WebSocketの課題
電話の「繋ぎっぱなし」は便利な反面、お店（サーバー）側からすると「ずっと電話口に店員を立たせておかないといけない」という負担になります。
そのため、以下のような課題と常に向き合う必要があります。
・同時接続数の問題（何万人と同時に電話を繋げるか？）
・プロキシサーバーの問題（途中の仲介役が電話のルールを理解できないことがある）
・負荷分散や認証（どの店員が誰の電話の対応をしているか分からなくなる）
まとめ
今回は、サーバープッシュ技術の2つの主役について解説しました！
長くなりましたが、以下の3点です。
1. サーバープッシュ は、お店（サーバー）から勝手に情報を送ってくれる仕組み
2. SSE（Server-Sent Events） は、受信専用の「わんこそば」
通知・ログ配信・株価など「サーバー → クライアント」だけで十分な場合
3. WebSocket は、最初だけHTTPで挨拶して切り替える、超高速の「双方向電話」
チャット・ゲームなど「双方向でリアルタイム性が重要」な場合
チャットやゲームなど「もっとリアルタイムに！」というニーズから生まれたのが、これらの技術です。
大事なのは
「リアルタイム通信を使うこと」ではなく、「その場面に合った手段を選べること」です。
SSEで十分なのか、それともWebSocketが必要なのか。
この判断ができれば、もう迷うことはありません。
それではまた、次回の記事で！