Add comprehensive WebSocket learning curriculum with 12 progressive steps

README.md

@@ -1 +1,116 @@
-# WebSocket-Learn
+# WebSocket 学習レポ
+
+**題材:** 10人同期のブラウザ蛇ゲーム（Slither.io風）
+**対象:** WebSocketほぼ初心者 / 素のJavaScriptで進める
+**ゴール:** WebSocketの基本から、リアルタイム同期・状態管理・遅延対策・簡易スケーリングまで理解する
+
+---
+
+## このリポジトリについて
+
+「動いた」で終わらせず、**「なぜそう設計するのか」を説明できる**状態を目指す学習教材です。
+
+初心者が詰まる原因は大体この3つです。
+
+1. HTTPとWebSocketの違いが曖昧
+2. 入力と状態を混同する
+3. クライアント側に真実を持たせて壊れる
+
+このカリキュラムでは、そこを順番に潰していきます。
+
+---
+
+## 技術スタック
+
+| 分類 | 技術 |
+|---|---|
+| フロント | HTML / CSS / 素のJavaScript / Canvas API |
+| バックエンド | Go + echo + gorilla/websocket |
+| 実装では使わないもの | React, TypeScript, Redux, DB |
+| 概念として触れるもの | Redis（Step 12 で Pub/Sub の役割のみ解説、実装なし） |
+
+> **注:** Redis は Step 12 で「複数サーバー構成ではどう使うか」を概念レベルで説明します。
+> Step 0〜11 の実装コードには登場しません。
+
+理由は単純で、**理解前に道具を増やすと本質が見えなくなるから**です。
+
+---
+
+## ステップ一覧
+
+| Step | テーマ | フォルダ |
+|---|---|---|
+| Step 0 | HTTPとWebSocketの違いを理解する | [step-00-http-vs-websocket](./step-00-http-vs-websocket/) |
+| Step 1 | まずは1本つなぐ（エコーサーバー） | [step-01-echo](./step-01-echo/) |
+| Step 2 | 複数人に配る（ブロードキャスト） | [step-02-broadcast](./step-02-broadcast/) |
+| Step 3 | メッセージではなく「入力」を送る | [step-03-input](./step-03-input/) |
+| Step 4 | サーバーで状態を持つ | [step-04-server-state](./step-04-server-state/) |
+| Step 5 | ゲームループを入れる | [step-05-game-loop](./step-05-game-loop/) |
+| Step 6 | 蛇ゲームにする | [step-06-snake](./step-06-snake/) |
+| Step 7 | 遅延と同期ズレを体験する | [step-07-lag](./step-07-lag/) |
+| Step 8 | 補間と予測を入れる | [step-08-interpolation](./step-08-interpolation/) |
+| Step 9 | 10人部屋を作る | [step-09-rooms](./step-09-rooms/) |
+| Step 10 | 切断・再接続に対応する | [step-10-reconnect](./step-10-reconnect/) |
+| Step 11 | 最適化を考える | [step-11-optimization](./step-11-optimization/) |
+| Step 12 | 上級発展：1台を超える設計へ | [step-12-advanced](./step-12-advanced/) |
+
+---
+
+## 進め方のルール
+
+各ステップでやることは4つです。
+
+1. **概念理解** — READMEを読む
+2. **最小実装** — コードを自分で打ち込む（コピペではなく）
+3. **動作確認** — 実際に動かす
+4. **言語化** — 以下を自分の言葉で書く
+
+毎ステップ必須のアウトプット：
+- 「何を学んだか」
+- 「なぜその設計にしたか」
+- 「どこがまだ分からないか」
+- 「次のステップで何が増えるか」
+
+---
+
+## おすすめの進め方
+
+```
+Step 0〜2 → 最速で終わらせる（接続の感触をつかむ）
+Step 3〜5 → 本質理解（ここが最重要）
+Step 6    → ゲームらしさを入れる
+Step 7〜8 → 「リアルタイムの現実」を学ぶ
+Step 9〜12 → 設計者の視点に上げる
+```
+
+**一番大事なのは Step 4 と Step 5 です。**
+ここが曖昧なまま進むと、用語を眺めるだけになります。
+
+---
+
+## 各ステップのフォルダ構成（Step 1〜11）
+
+```
+step-XX-name/
+├── README.md      # 概念説明・コード解説・練習問題
+├── server/
+│   └── main.go   # Goサーバー
+└── client/
+    └── index.html # フロントエンド
+```
+
+---
+
+## 最終到達イメージ
+
+このカリキュラムを終えたら、最低でも以下が言える状態を目指します。
+
+- [ ] WebSocketの接続と基本イベントを説明できる
+- [ ] ブロードキャストの仕組みを実装できる
+- [ ] 入力送信と状態同期の違いを説明できる
+- [ ] サーバー権威型の設計を理解している
+- [ ] tickベースのゲームループを実装できる
+- [ ] 遅延やカクつきの原因を説明できる
+- [ ] 補間の役割を理解している
+- [ ] 10人部屋の基本設計を考えられる
+- [ ] 切断・再接続・ルーム分割など、現実の問題を意識できる

step-00-http-vs-websocket/README.md

@@ -0,0 +1,193 @@
+# Step 0: HTTPとWebSocketの違いを理解する
+
+## このステップの目標
+
+WebSocketが何のために存在するのかを理解する。
+コードはまだ書かない。まず「なぜ必要か」を頭に入れる。
+
+---
+
+## 1. HTTPとは何か
+
+HTTPは **リクエスト／レスポンス** モデルです。
+
+```
+クライアント → 「このページをください」   → サーバー
+クライアント ←  「はい、どうぞ」          ← サーバー
+（接続が閉じる）
+```
+
+特徴：
+- クライアントが「聞く」、サーバーが「答える」の一方通行
+- 1回のやり取りで接続が終わる（または Keep-Alive でも原則クライアント発）
+- サーバー側から突然クライアントに話しかけることが**できない**
+
+---
+
+## 2. WebSocketとは何か
+
+WebSocketは **全二重通信（Full-Duplex）** です。
+
+```
+クライアント ←→ サーバー  （接続を維持したまま、どちらからでも送れる）
+```
+
+特徴：
+- 接続が確立したら、どちらからでも好きなタイミングで送れる
+- 接続は明示的に閉じるまで維持される
+- オーバーヘッドが少ない（HTTPヘッダーを毎回送らない）
+
+---
+
+## 3. 比較表
+
+| 項目 | HTTP | WebSocket |
+|---|---|---|
+| 通信の開始 | クライアントのみ | どちらからでも |
+| 接続の持続 | 原則1回で終了 | 明示的に閉じるまで維持 |
+| サーバーからのプッシュ | できない（工夫が必要） | できる |
+| オーバーヘッド | 毎回ヘッダーが発生 | 初回接続時のみ |
+| 向いている用途 | Webページ取得、REST API | チャット、ゲーム、株価など |
+| 向いていない用途 | リアルタイム更新 | 単純なデータ取得 |
+
+---
+
+## 4. なぜチャットや対戦ゲームでWebSocketが使われるのか
+
+### HTTPだけでチャットを作ろうとすると…
+
+方法1: **ポーリング（Polling）**
+```
+クライアントが1秒ごとに「新しいメッセージありますか？」と聞き続ける
+→ サーバーへの無駄なリクエストが大量発生
+→ 「ありません」という返答ばかり
+→ リアルタイム性が低い（最大1秒の遅延）
+```
+
+方法2: **ロングポーリング（Long Polling）**
+```
+クライアントが「新しいメッセージが来るまで待ってください」とリクエスト
+→ サーバーはメッセージが来るまでレスポンスを保留
+→ メッセージが来たらレスポンスを返し、すぐ次のリクエストを送る
+→ マシだが、コネクション管理が複雑
+```
+
+### WebSocketなら…
+```
+一度接続したら、サーバーから即座にメッセージをプッシュできる
+→ 遅延がほぼない
+→ 無駄なリクエストなし
+→ 実装がシンプル
+```
+
+---
+
+## 5. リアルタイムゲームでWebSocketが有効な理由
+
+蛇ゲームを例に考えます。
+
+```
+10人が同時にプレイしている場合：
+
+毎100msごとに全員の位置を更新したい
+→ 1秒に10回、10人分の位置データを全員に送る必要がある
+
+HTTPポーリングなら：
+  - 10人 × 10回 = 毎秒100回のリクエスト
+  - それぞれにHTTPヘッダーが付く
+  - 遅延も不規則
+
+WebSocketなら：
+  - 接続は10本だけ
+  - サーバーから一方的に位置データをプッシュ
+  - 無駄がない
+```
+
+---
+
+## 6. WebSocketを使っても遅延はゼロにならない
+
+これは大事なポイントです。
+
+```
+WebSocketを使っても遅延が発生する理由：
+
+1. 物理的な距離（東京→大阪でも数ms）
+2. ルーターや回線の混雑
+3. OSのパケット処理時間
+4. アプリケーションの処理時間
+5. クライアント端末の性能
+
+TCPベースのWebSocketは：
+  - パケットの順序を保証してくれる（順番通りに届く）
+  - 届いたことを確認してくれる（再送制御あり）
+  - しかし、「速く届く」は保証しない
+```
+
+つまり、**WebSocketはリアルタイム通信を「可能にする」ものであって、「遅延ゼロを保証する」ものではない**。
+
+後のステップで、遅延があっても「滑らかに見せる」技術（補間・予測）を学びます。
+
+---
+
+## 7. WebSocketを使わなくていいケース
+
+WebSocketは便利ですが、万能ではありません。
+
+| ケース | 適切な技術 |
+|---|---|
+| ブログの記事を読む | HTTP（普通のREST API） |
+| フォームを送信する | HTTP |
+| 1時間に1回データを取得 | HTTP（ポーリング） |
+| 株価のリアルタイム表示 | WebSocket または SSE |
+| チャット | WebSocket |
+| オンラインゲーム | WebSocket（または WebRTC/UDP系） |
+
+---
+
+## 8. WebSocketの接続確立の仕組み（補足）
+
+WebSocketは実はHTTPから始まります。
+
+```
+1. クライアントがHTTPで「WebSocketに切り替えたい」とリクエスト
+   → これを「ハンドシェイク（handshake）」と言う
+
+2. サーバーが「OK、切り替えます」と返す（ステータス 101）
+
+3. 以降はWebSocketプロトコルで通信
+```
+
+これをアップグレード（Upgrade）と言います。
+だからWebSocketのURLは `ws://` または `wss://`（SSL対応）を使います。
+
+---
+
+## 理解チェック
+
+以下の質問に自分の言葉で答えてみてください。
+
+1. HTTPとWebSocketの一番大きな違いは何ですか？
+2. なぜチャットアプリにHTTPポーリングは向いていないのですか？
+3. WebSocketを使えば遅延はゼロになりますか？なぜそう思いますか？
+4. `ws://` と `wss://` の違いは何ですか？
+5. 蛇ゲームでHTTPだけを使うと何が困りますか？具体的に説明してください。
+
+---
+
+## 手を動かす課題
+
+1. HTTPとWebSocketの違いを自分なりの表にまとめる
+2. 「蛇ゲームでHTTPだけを使うと何が困るか」を200字以上で書く
+3. ブラウザの開発者ツール（DevTools）でWebSocket通信を確認する
+   - Chrome/Firefox → F12 → Network タブ → WS フィルター
+
+---
+
+## 次のステップへ
+
+Step 1では実際にWebSocket接続を試します。
+ブラウザとサーバーを繋いで、文字を送受信してみます。
+
+「概念は分かった、でも実際どう動くの？」という疑問が出てきたら正解です。
+それを確かめるのが次のステップです。