レッスン phase1-introduction-what-is-websocket

初級 1時間

WebSocketとは何か

📋 前提知識

JavaScript基礎HTTP基本理解ブラウザ開発者ツール使用経験

🎯 このレッスンで学ぶこと

WebSocketの基本定義と従来のHTTP通信との違い
ブラウザ標準WebSocket APIから学ぶ理由
リアルタイム通信が必要になる背景
WebSocketの歴史と標準化の意義

WebSocketの基本定義

WebSocketとは

WebSocketは、クライアント（ブラウザ）とサーバー間で持続的な双方向通信を可能にするWeb技術です。
従来のHTTPのように、リクエストとレスポンスを逐一やり取りする必要がなく、効率的なデータ伝送を実現します。

従来のHTTP通信との根本的違い

従来のHTTP通信では、以下のような制限がありました。

リクエスト・レスポンス型：クライアントからの要求に対してサーバーが応答する一方向通信
ステートレス：各リクエストは独立しており、接続は毎回確立・切断される
オーバーヘッド：HTTPヘッダーによる通信データの増大

WebSocketの特徴

WebSocketは、これらの制限を解決します。

双方向通信：クライアント・サーバー双方からメッセージを送信可能
持続的接続：一度確立した接続を維持し続ける
低オーバーヘッド：最小限のフレーム構造で効率的な通信
リアルタイム性：遅延の少ない即座のデータ交換

WebSocket通信の仕組み

WebSocket通信フロー

WebSocketの通信は、以下の3つの段階で構成されます。

図表を生成中...

1. 接続確立フェーズ

HTTP Upgrade Request
クライアント（ブラウザ）がサーバーに対して、通常のHTTP接続をWebSocket接続にアップグレードするよう要求します。
この段階では、まだHTTPプロトコルを使用しています。

HTTP 101 Switching Protocols
サーバーが要求を承認し、プロトコルをWebSocketに切り替えることを通知します。
ステータスコード101「Switching Protocols」により、以降の通信がWebSocketプロトコルになります。

2. 持続的双方向通信フェーズ

接続が確立されると、クライアントとサーバーはどちらからでもメッセージを送信できるようになります。

従来のHTTP：クライアント→サーバーの一方向のみ
WebSocket：クライアント↔サーバーの双方向通信

この段階では、HTTPヘッダーのような重いオーバーヘッドはなく、メッセージのやり取りが効率的に行われます。

3. 接続終了フェーズ

通信が完了したら、Close Frameを送信して接続を正常に終了します。
どちらか一方が切断を開始し、相手がそれに応答することで、クリーンな接続終了が実現されます。

WebSocket通信の重要な特徴

永続接続：一度確立すれば、明示的に切断するまで接続を維持
低遅延：接続確立のオーバーヘッドが初回のみ
フレーム効率：最小限のヘッダーでメッセージを送信
プロトコル独立：テキストまたはバイナリデータを自由に送信可能

なぜブラウザ標準WebSocket APIから学ぶのか

学習戦略の理由

このカリキュラムでは、Socket.IOのようなライブラリより先にブラウザ標準WebSocket APIを学習します。

1. 基礎理解の重要性

WebSocketプロトコルの本質的な仕組みを理解
ライブラリの抽象化に隠された動作を把握
トラブルシューティング能力の向上

2. 移植性とパフォーマンス

どのモダンブラウザでも動作する標準技術
ライブラリ依存なしの軽量実装
最適化された通信効率

3. 学習の段階的進行

Phase 1: 標準WebSocket APIの完全理解
Phase 2: より高度なパターンと実装技術
Phase 4: Socket.IO等の高水準ライブラリ（オプション）

実践デモ

デモで確認できること

接続プロセスの観察

接続確立：「接続」ボタンでWebSocket接続を開始
双方向通信：メッセージの送受信を実時間で確認
接続状態管理：接続・切断・エラー状態の変化
ブラウザ開発者ツール：Network タブでWebSocket通信を観察

実行手順

上記のデモで「接続」をクリック
ブラウザ開発者ツールのNetworkタブを開く
WebSocketフィルターを選択
接続とメッセージの詳細を確認

体験してみよう！

WebSocket基本接続デモ

実際にWebSocket接続を確立し、メッセージのやり取りを体験してみましょう。

🌐 WebSocketサービス選択

接続状態: 切断

💬 メッセージ送信

📝 通信ログ

0件 | 送信: 0 | 受信: 0

🔗

WebSocketに接続すると通信ログが表示されます

🎓 フェーズ1学習ポイント

• 🌐 パブリックWebSocketサービスの利用
• 🔄 自動フォールバック機能
• 📊 接続メトリクスの監視
• 📡 WebSocket ReadyStateの理解
• 📢 エコーサーバーでの即座レスポンス
• ⏱️ レイテンシ測定とパフォーマンス解析

WebSocketの歴史と発展

技術的背景

WebSocket登場の背景

2008年以前：リアルタイム通信の課題

ポーリング：定期的なHTTPリクエストによるサーバー負荷
ロングポーリング：接続の維持による複雑性
Comet技術：ブラウザの制限による不安定性

2008年：WebSocketプロトコルの提案

Ian Hickson氏によるHTML5の一部として提案
リアルタイムWeb通信の標準化への第一歩

2011年：RFC 6455として標準化

IETFによる正式な標準として確立
モダンブラウザでの実装開始

WebSocketが解決する現実的課題

実用的な適用場面

従来技術では困難だったユースケース

1. リアルタイムチャット

従来の課題

HTTPポーリングによる遅延とサーバー負荷
新着メッセージの即時通知が困難
複数ユーザー間の同期に時間差が発生

WebSocketによる解決

サーバーからクライアントへの即座のプッシュ通知
双方向通信によるリアルタイムメッセージ交換
複数ユーザー間の同時通信を効率的に実現

2. 協調編集システム

従来の課題

文書の変更内容を他ユーザーに即時共有できない
競合状態（同時編集）の検出と解決が困難
定期的な保存・更新による作業効率の低下

WebSocketによる解決

文字入力と同時に他ユーザーへリアルタイム反映
操作の順序保証と競合回避を効率的に実装
継続的な双方向データ同期による快適な協調作業

3. ライブデータ表示

従来の課題

株価・為替レートの頻繁な更新にHTTPリクエストが追従できない
ポーリング間隔の調整が困難（頻繁すぎるとサーバー負荷、遅すぎるとデータ遅延）
IoTデバイスからの大量データ受信に非効率

WebSocketによる解決

データ変更時の即座のプッシュ配信
持続接続による効率的なデータストリーミング
センサーデータの連続受信と低遅延表示

4. オンラインゲーム

従来の課題

プレイヤーの操作同期に致命的な遅延
HTTPリクエスト・レスポンスサイクルによるゲーム体験の断続
リアルタイム性が求められるマルチプレイヤー要素の実装困難

WebSocketによる解決

プレイヤー操作の即時同期と低遅延通信
継続的な双方向通信による滑らかなゲーム体験
複数プレイヤー間の同時アクション処理を効率化

🎉 レッスン完了

このレッスンの内容を理解できましたら、完了マークをつけて次のレッスンに進みましょう。

学習を継続しましょう

次のレッスン

phase1-introduction-http-limitations: HTTPの限界とWebSocketの優位性

次のレッスンに進む

または Phase 1 概要に戻って他のレッスンを確認する

💡 学習のコツ

• 理解できない部分があれば、前のレッスンに戻って復習しましょう
• 実際に手を動かして、コードを書いて確認することが重要です
• インタラクティブデモは何度でも試してみてください
• 疑問点があれば、参考資料やドキュメントを確認しましょう