この記事について
『プロになるためのWeb技術入門』を読み、理解を深めるために自分なりに咀嚼した内容を記します。 この記事に出てくるポイントは以下の通りです。
リクエスト、レスポンスについて
あるユーザーが見たいサイトのリンクをクリックしたとしましょう。
ブラウザはクリックされたリンクに記されたURL（サイトの住所みたいなもの）を元にして、サーバに「このサイトの情報をください！」と要求します。
ユーザーからサーバに要求することをリクエストといいます。
これに対し、サーバがユーザーに返すサイトやサイトの情報のことを、レスポンスといいます。
URLについて
前項ではURLのことを"サイトの住所みたいなもの"と称しましたが、もう少し詳しく見ていきます。
例えば以下は、このブログのある記事のURLです。
https://wsigma.hatenablog.com/entry/2023/06/17/214105
このURLは3つの要素に分けることができます。
- 「https://」スキーム
- 「wsigma.hatenablog.com」：ホスト名
- 「entry/2023以下」：パス名
スキームは、情報を得る手段を表します。
スキームで一番有名なのはhttpでしょう。httpsは、httpをよりsecure（セキュア・安全）にしたものです。
ホスト名は、その情報が存在するホスト（サーバ）の名前を表しています。
パス名は、そのサーバのどこに記事が格納されているかを表しています。
つまり、上記のURLをクリックするということは、「wsigma.hatenablog.com」というホスト名のサーバに、「entry/2023/06/17/214105」という記事を、「https」という手段でくれ、と要求しているということです。
プロトコルについて
前項で述べた通り、スキームは単にどのような手段で通信するか？を表しているに過ぎません。具体的な通信のルールはプロトコルで定めています。
ちなみに、スキーム名とプロトコル名は同じ場合もあります（http, https, ftpなど）が、全く別のものもあります。mailtoがその例です。
ポート番号について
プロトコルにはポート番号がセットで存在します。
ポート番号は、サーバの受付窓口の番号のようなものです。
代表的なプロトコルの場合は予めポート番号が決まっています。これをウェルノウンポートといいます。
| ポート番号 | プロトコル |
|---|---|
| 20,21 | ftp（ファイル転送） |
| 80 | HTTP |
| 443 | HTTPS |
これにより、クライアントはサーバのどのポート番号にリクエストを送ればよいか迷わなくて良いことになります。 HTTPSの場合、443番のポート番号にリクエストを送れば、サーバはHTTPS通信だと認識し、HTTPSのプロトコルに従って解釈して処理を行えるというわけです。
ウェルノウンポートの場合はポート番号が省略できるため、大抵のURLでは省略されています。先ほど挙げたURLでも省略していますが、ポート番号も含めて書いてみると以下のようになります。
https://wsigma.hatenablog.com:443/entry/2023/06/17/214105
ステートフル、ステートレスについて
ここからは、ログイン認証があるお買い物サイトを例に、ステートフル、ステートレス、Cookie、セッションについて見ていきます。
なお、本来は安全に通信を行うためHTTPSを用いるべきですが、ここでは話を簡単にするため、HTTP通信を用いるものとします。
ユーザーがログインした後、商品をカートに入れるという状況を考えてみます。
商品がカートに入った時、サーバは"誰がカートに入れたのか"を認識する必要があります。そのためには、ユーザーがログインした時の認証情報をサーバに維持したまま処理を継続してもらえば良いわけです。こんなふうに。
ステートフルな通信はクライアントにとっては楽で、一見何の問題もなさそうに見えますが、そうでもありません。
上記の例はクライアントとサーバが一対一でしたが、クライアントの数が増えたら、サーバはクライアントごとに全ての手順を維持したまま処理を継続しなければいけなくなります。となると、クライアントが増加するたびにサーバの負荷が増大していきます。結果的に、クライアントの待ち時間も発生してしまうという事態になるでしょう。
このような理由もあり、HTTP通信はステートフルではなく、相手の状態を維持しないステートレスなやり方を取っています。つまり、サーバは直近のクライアントのリクエストに対してレスポンスを返すだけで、それ以前のやりとりについては維持しません。
しかしこれでは、困ったことになります。商品がカートに入った時、誰がカートに入れたのかわからないですよね。
Cookie、セッションについて
ユーザーのログインが成功した時、サーバはレスポンスの一部として、ユーザーIDとパスワードを組み合わせたCookieを送ります。ブラウザはそのCookieを受け取り保存しておきます。
そこで、ユーザーの認証情報を保持したまま、より安全にステートレスな通信を実現するための仕組みとして、セッションが生まれました。
ログイン認証後のレスポンスの時、サーバはCookieにユーザーIDとパスワードの代わりにセッションIDを入れます。そして、その後クライアントは、CookieにセッションIDを入れてリクエストします。セッションではクライアントの処理の流れをサーバ側で保持しているので、サーバはCookieに含まれるセッションIDを見て、必要な処理を行うことができるのです。
