HTTPとは？
HTTP（HyperText Transfer Protocol）は、インターネット上で情報を送受信するためのプロトコル（通信の取り決め）です。一般的には、ウェブブラウザ（例えばGoogle ChromeやFirefox）とウェブサーバー（ウェブページやその他のデータを保管しているコンピューター）の間でデータの送受信を行う際に使用されます。
HTTPは、ウェブブラウザがウェブページを表示するために必要なデータ（HTML、CSS、画像、JavaScriptなど）を要求し、ウェブサーバーがそれを提供する、といったやり取りを可能にします。
ウェブブラウザは、ユーザーがウェブページのURLを入力すると、そのURLに対応するウェブサーバーにHTTPリクエスト（要求）を送ります。このリクエストは、「GET」リクエストと呼ばれ、特定のウェブページのデータを要求します。
ウェブサーバーは、このリクエストを受け取り、要求されたデータをHTTPレスポンス（応答）としてブラウザに送り返します。ブラウザはこのレスポンスを受け取り、その内容を解析してウェブページとして表示します。
また、HTTPはステートレスと呼ばれる特性を持っています。これは、各リクエストとレスポンスがそれぞれ独立しており、過去のリクエストやレスポンスの状態を記憶しないという意味です。例えば、あるページを表示した後に別のページを表示すると、サーバーは前のページの要求と結果を覚えていません。これにより、ウェブは単純で効率的に動作しますが、ユーザーが行う一連の操作を追跡するための追加の技術（例えば、クッキーやセッション）が必要になります。
HTTPがステートレスの理由
HTTPがステートレスな設計になっている理由は主に以下の2つです：
-
シンプルさと効率性：各リクエストが互いに独立しているため、ウェブサーバーは過去のリクエストやその状態を管理する必要がありません。これにより、サーバーは単純で効率的に動作できます。
-
スケーラビリティ：ステートレス性により、各リクエストが独立しているため、リクエストはどのサーバーにも送信できます。これは、サーバーのロードバランシング（負荷分散）と呼ばれ、多くのユーザーが同時にアクセスした場合にもシステムがスムーズに動作することを可能にします。
これらの特性により、HTTPは大量のリクエストを高速に処理し、大規模なインターネットトラフィックを効果的にサポートすることが可能となります。
ただし、ステートレスな設計には以下のようなデメリットもあります：
-
状態管理の難しさ：各リクエストが独立しているため、ユーザーの一連のアクション（例えば、ショッピングカートにアイテムを追加する）を追跡するためには、追加の技術（例えば、クッキーやセッション）が必要になります。
-
パフォーマンスの問題：ステートレスなプロトコルでは、各リクエストに全ての必要な情報（認証情報など）を毎回送信しなければならない場合があります。これは、一部のケースでオーバーヘッドを生じさせ、パフォーマンスを低下させる可能性があります。
以上のように、HTTPのステートレスな設計には、効率性とスケーラビリティというメリットと、状態管理の難しさや一部のパフォーマンス問題というデメリットが存在します。
ステートフルにしたらどうなる？
ステートフルな通信プロトコルでは、過去のリクエストとレスポンスの状態（情報）が保存され、それらが後続のリクエストとレスポンスに影響を与えます。つまり、過去の通信が現在の通信に影響を与える状態を持つことができます。これには以下のような特性があります：
-
ユーザー体験の向上：ユーザーのアクション（例えば、ログイン状態、ショッピングカートの内容など）が追跡されるため、よりパーソナライズされた体験を提供することが可能になります。
-
エフィシエンシー：既に取得または送信した情報を再利用できるため、同じ情報を繰り返し送信する必要がなくなり、通信が効率的になる可能性があります。
一方で、ステートフルな設計には以下のようなデメリットもあります：
-
リソースの消費：過去の状態を保存し管理するために、サーバーやネットワークのリソース（メモリ、ストレージ、処理能力）を大量に消費する可能性があります。
-
スケーラビリティの問題：すべての状態を一つのサーバーで管理しようとすると、そのサーバーに過度な負荷がかかる可能性があります。また、ユーザーの状態が特定のサーバーに依存すると、そのサーバーがダウンした場合に問題が生じる可能性があります。
-
複雑性の増加：ステートフルなシステムは、ステートレスなシステムに比べて設計、開発、テスト、デバッグがより複雑になります。
ウェブのコンテキストでは、HTTP自体はステートレスですが、クッキーやセッションといった技術を使ってサーバーサイドまたはクライアントサイドで状態を管理し、ステートフルな振る舞いを実現しています。このように、ステートレスとステートフルな設計はそれぞれの利点と欠点があり、適切なバランスで組み合わせて使用されます。
ステートフルなプロトコルWebSocketとは？
WebSocketとは、インターネット上でデータをやり取りするための技術の一つです。通常、ウェブブラウザ（クライアント）とウェブサーバーとの間で行われます。
通常のHTTP通信と異なり、WebSocketは「双方向通信」を可能にします。つまり、クライアントとサーバーが同時にデータを送受信できるようになります。これは、電話のような通信に例えることができます。電話では、話す人と聞く人が同時に存在し、いつでも会話を始めることができます。
一方、通常のHTTP通信は「単方向通信」で、これは手紙に例えることができます。あなたが手紙を送るとき、まず手紙を書いて郵便局に送り、相手がそれを受け取って返信するまで待つ必要があります。
WebSocketの利点はリアルタイム性にあります。例えば、チャットアプリケーションでは、ユーザーがメッセージを送信した瞬間に他のユーザーに表示することが求められます。また、リアルタイムのオンラインゲームでは、プレイヤーの動きをすぐに他のプレイヤーに反映させる必要があります。このような場合にWebSocketは非常に有用です。
また、WebSocketは「接続の維持」も可能です。一度接続が確立されると、クライアントとサーバーは接続が閉じられるまで通信を続けることができます。これにより、必要なときにすぐにデータを送受信できます。
ただし、WebSocketは他の通信方式と比べて少し複雑なため、必要な場合やリアルタイム性が重要な場合にのみ使用されます。
HTTPとWebSocketの比較
HTTPとWebSocketは、どちらもクライアント（通常はウェブブラウザ）とサーバーとの間でデータをやり取りするためのプロトコルですが、その動作の仕組みは大きく異なります。
HTTP
HTTPは「リクエスト-レスポンス」のモデルを使用します。これは、クライアントがサーバーにリクエストを送信し（例えば、ウェブページの要求）、サーバーがそれに対するレスポンスを返す（該当のウェブページのコンテンツ）という一方的な通信方式です。レスポンスが送信された後、そのHTTP接続は通常は閉じられます。
また、HTTPは「ステートレス」なプロトコルであり、それぞれのリクエスト-レスポンスのペアは独立しています。これはサーバーがクライアントの状態を保持しないことを意味します。しかし、クッキーやセッションといった技術を用いて、ステートフルな振る舞いを実現することも可能です。
WebSocket
WebSocketは「フルデュプレックス」の通信モデルを使用します。これは、一度接続が確立されると、クライアントとサーバーが同時にデータを送受信できることを意味します。これにより、サーバーが新たな情報をクライアントにプッシュすることが可能になり、リアルタイムの通信が可能となります。
WebSocket接続は、クライアントがHTTPリクエストを送信することで開始されます。このリクエストには「Upgrade: websocket」ヘッダーが含まれ、これによりサーバーにHTTP接続をWebSocket接続に「アップグレード」するよう要求します。サーバーがこの要求を受け入れると、接続はWebSocket接続になり、その接続は手動で閉じられるまで開いたままとなります。
これらの違いから、HTTPはウェブページやAPIの要求に適していますが、WebSocketはリアルタイムの通信が必要なアプリケーション（チャットアプリケーション、オンラインゲームなど）に適しています。しかし、これらのプロトコルは共存して使用され、多くの現代のウェブアプリケーションでは両方が利用されています。
