PR

【IT用語解説】WebSocketとは?HTTPとの違いと使いどころを初心者向けに解説

WebSocketの記事アイキャッチ。チャットのイラストとWebSocketの文字。 IT-Skills

WebSocketとは、ブラウザとサーバーが1本の接続を開いたまま、双方向にメッセージを送り合うための通信技術です。

通常のHTTP通信では、ブラウザがリクエストを送り、サーバーがレスポンスを返す、という往復が基本です。一方でWebSocketでは、接続を開いた後、ブラウザからサーバーへも、サーバーからブラウザへも、必要なタイミングでデータを送ることが可能。

WebSocketは「ページを表示するための仕組み」ではなく、「開いた接続で会話を続ける仕組み」と考えると理解しやすくなります。

この記事では、WebSocketの意味、HTTPやREST APIとの違い、接続開始の流れ、JavaScriptでの最小コード、使いどころと注意点を初心者向けに整理します。

スポンサーリンク

まず結論:WebSocketは双方向のリアルタイム通信

WebSocketの一番大事な特徴は、双方向通信です。双方向通信とは、クライアント側から送るだけでなく、サーバー側からもクライアントへデータを送れる通信のことです。

ここでいうリアルタイム通信は、厳密に遅延がゼロという意味ではありません。ユーザーが待って更新ボタンを押さなくても、サーバー側の変化を短い遅延で画面へ届けられる、という意味で使われます。

チャットで相手の発言がすぐ表示される、管理画面に新しい通知がすぐ出る、共同編集で他の人の変更が反映される。こうした「サーバー側で起きた変化を画面へすぐ届けたい」場面でWebSocketが候補になります。

次の図で、WebSocketを「ブラウザとサーバーが1本の接続で会話を続ける仕組み」として見てください。

ブラウザとサーバーが1本のWebSocket接続で双方向にメッセージを送受信する図
WebSocketは、ブラウザとサーバーが接続を開いたまま、双方からメッセージを送れる通信です。

HTTPとの違い

HTTPは、Webページの表示やAPI呼び出しで広く使われる通信の基本です。ブラウザが「このページをください」「このデータをください」と依頼し、サーバーが返事をする形で進みます。

HTTPの基本はHTTPとは?HTTPSとは?の記事で要チェック!

WebSocketも最初の接続開始ではHTTPの仕組みを利用します。しかし、接続が確立した後は、毎回HTTPリクエストを作るのではなく、開いた接続の上で小さなメッセージをやり取りします。

次の比較図では、HTTPは「依頼して返事をもらう」、WebSocketは「開いた接続で会話を続ける」と読み分けてください。

HTTPのリクエストレスポンス型通信とWebSocketの双方向通信を比較する図
HTTPは用事ごとに依頼して返事を受け取り、WebSocketは接続を保ったまま双方から送信できます。
観点HTTPWebSocket
通信の基本リクエストとレスポンス接続を開いたまま双方向通信
サーバーからの通知基本はクライアントの依頼後に返すサーバー側から送れる
向いている場面ページ表示、通常のAPI、検索、登録チャット、ライブ通知、共同編集
初心者向けの見方用事ごとの問い合わせ開いた回線で会話を続ける

WebSocketの接続はどう始まるか

WebSocketは、いきなり独自の通信だけで始まるわけではありません。一般的なWebの文脈では、最初にHTTPのリクエストとして接続を始め、サーバーがWebSocketへ切り替える流れを受け入れると、その後WebSocketの通信へ進みます。

RFC 6455では、WebSocketプロトコルは接続開始のハンドシェイクと、その後のメッセージフレーミングから成り、TCP上で動くものとして説明されています。初心者の段階では、まず「最初に握手して、接続ができたらメッセージを送り合う」と押さえれば十分です。

次の図では、WebSocket接続が始まる順番を確認してください。HTTPのUpgrade、切り替え成功、その後のメッセージ交換という3段階で見ます。

WebSocket接続がHTTP Upgradeの流れで始まり、その後メッセージフレームをやり取りする図
WebSocketは、接続開始の手続きが通った後、双方向のメッセージ通信へ進みます。

JavaScriptで見るWebSocketの最小コード

ブラウザのJavaScriptでは、WebSocketオブジェクトを作ってサーバーへ接続します。URLは、暗号化なしならws://、TLSで保護するならwss://を使います。実務のWebサイトでは、基本的にwss://を選ぶと考えてください。

const socket = new WebSocket("wss://example.com/chat");

socket.addEventListener("open", () => {
  socket.send("こんにちは");
});

socket.addEventListener("message", (event) => {
  console.log("受信:", event.data);
});

socket.addEventListener("close", () => {
  console.log("接続が閉じました");
});

socket.addEventListener("error", (event) => {
  console.error("通信エラー", event);
});

このコードでは、openで接続開始、sendで送信、messageで受信、closeで切断、errorでエラーを扱っています。

ただし、このコードだけをブラウザに貼っても、接続先のWebSocketサーバーがなければ動きません。WebSocketは、ブラウザ側のコードとサーバー側の受け口がセットで必要になる通信です。

ここで重要なのは、messageイベントです。WebSocketでは、サーバー側からメッセージが届いたタイミングで処理を実行できます。通常のREST APIのように、毎回こちらから取得しに行く発想とは少し違います。

WebSocketを使う場面

WebSocketは、どんなWeb開発でも必ず使うものではありません。強みが出るのは、サーバー側で起きた変化を、クライアント側へすぐ届けたい場面です。

次の図では、WebSocketが向いている代表的な場面を確認してください。見るポイントは「サーバー側の変化を待たずに画面へ届けたいか」です。

チャット、ライブ通知、共同編集などWebSocketが向く場面を示す図
WebSocketは、チャットやライブ通知のように、サーバーからの即時更新が重要な場面で使われます。
  • チャットや問い合わせ画面で、新しいメッセージをすぐ表示したい
  • 注文、障害、監視、株価などのライブ通知を表示したい
  • 共同編集ツールで、他の人の変更をリアルタイムに反映したい
  • ゲームやダッシュボードで、状態変化を継続的に受け取りたい

反対に、普通の記事ページを表示する、検索結果を返す、フォームの登録結果を返す、といった処理ではHTTPやREST APIで十分なことが多いです。

REST APIやポーリングとの使い分け

REST APIは、クライアントが必要なタイミングでサーバーへ問い合わせ、結果を受け取る設計でよく使われます

参考 REST APIとは何か?

ポーリングは、一定間隔でサーバーへ問い合わせる方法です。たとえば5秒ごとに「新着はありますか?」と聞き続けます。実装は分かりやすい一方で、何も変化がないときも通信が発生します。

方式向いている場面注意点
REST API通常の取得、登録、更新、削除サーバーから自発的には送れない
ポーリング簡単な定期更新無駄な問い合わせが増えやすい
WebSocketリアルタイムな双方向通信接続管理と再接続を考える必要がある

判断に迷ったら、まず「サーバー側の変化をすぐ画面に届ける必要があるか」を見ます。必要がなければREST APIで十分なことが多く、必要があるならWebSocketを検討します。

参考 APIとは?APIとWeb APIの違い

Socket.IOとは何が違う?

WebSocketを調べていると、Socket.IOという名前もよく出てきます。ここで混同しやすいのは、WebSocketが通信プロトコルであるのに対し、Socket.IOはリアルタイム通信を扱いやすくするためのライブラリだという点です。

Socket.IOは、再接続、イベント名付きの送受信、環境に応じた通信方式の切り替えなどを助けます。一方で、ブラウザ標準のWebSocket APIとはそのまま互換ではありません。Socket.IOを使う場合は、サーバー側もSocket.IOに対応している必要があります。

初心者の段階では、まずWebSocketを通信の考え方として理解し、その後で「実装を楽にする選択肢としてSocket.IOがある」と分けておくと混乱しにくくなります。

初心者が誤解しやすいポイント

誤解正しい見方
WebSocketはHTTPの上位版役割が違う。HTTPは通常の取得や更新、WebSocketは継続的な双方向通信に向く
WebSocketなら必ず速い用途次第。接続管理のコストもある
REST APIは不要になる通常のCRUDや検索ではREST APIの方が自然なことが多い
接続したらずっと安心切断、再接続、認証、権限、エラー処理が必要

WebSocketは便利ですが、アプリケーション設計のすべてを置き換えるものではありません。画面表示、通常のデータ取得、ログイン、履歴取得などはHTTPやREST APIで行い、リアルタイム更新部分だけWebSocketにする構成もよくあります。

セキュリティと運用で見るポイント

WebSocketを実務で使うときは、接続できることだけでなく、誰が接続しているのか、どのメッセージを許可するのか、切断時にどう復旧するのかを考える必要があります。

  • wss://を使い、通信をTLSで保護する
  • 接続時やメッセージ処理時に認証・認可を確認する
  • 予期しない切断に備えて再接続の設計をする
  • サーバー側で接続数、送信頻度、メッセージサイズを制御する
  • ブラウザやネットワーク環境による切断を前提にログを残す

特に重要なのは、WebSocket接続が長く続くことです。通常のHTTPリクエストよりも、接続数や切断時の処理が運用に影響しやすくなります。

既存記事とあわせて読む順番

WebSocketを理解するには、HTTP、クライアントサーバー、APIの順に土台を確認してから読むとつながりやすくなります。

公式情報と関連リンク

仕様を深く確認する場合は、IETFのRFC 6455とMDNのWebSocket APIリファレンスを参照します。初心者の段階では、RFCを最初からすべて読む必要はありません。この記事で全体像を押さえた後、実装時に必要なイベント、メソッド、接続開始の仕様を確認すると効率的です。

まとめ

WebSocketは、ブラウザとサーバーが1本の接続を開いたまま、双方向にメッセージを送り合うための通信技術です。

  • WebSocketはリアルタイムな双方向通信に向いている
  • HTTPは用事ごとのリクエストとレスポンス、WebSocketは接続を保った会話として見る
  • チャット、ライブ通知、共同編集などで使われる
  • REST APIを置き換えるものではなく、用途で使い分ける
  • 実務では認証、切断、再接続、接続数の管理も重要

最初は「WebSocketは、サーバーからもブラウザへすぐ送れる通信」と覚えるだけで十分です。そのうえで、HTTPやREST APIと役割を分けて考えると、どの場面で使うべきか判断しやすくなります。

タイトルとURLをコピーしました