Yuki's Tech Blog

仕事で得た知見や勉強した技術を書きます。

【Webを支える技術】第3部 6章 HTTPの基本をざっくりまとめてみた

目次

プロトコルとは何か?

プロトコルとは、コンピュータ同士がネットワークを用いて通信するために決められた「約束ごと」です。異なるメーカーのCPUや異なるOSのコンピュータ同士でも、同じプロトコルを使用していれば通信できます。コンピュータ同士が互いに通信するためには、両者が同じプロトコルを理解し、処理する必要があります。

HTTPとは何か?

HTTPとは、ブラウザとサーバの通信で用いられるプロトコルです。このプロトコルを使うことで、HTML文書・画像・音声・動画・JavaScriptプログラム・ドキュメントファイル等のコンテンツの送受信ができます。

TCP/IPとは何か?

TCP/IPとは、TCPやIPに深く関係する多くのプロコトル群の総称です。通信プロトコルの総称とも言えます。TCPとIPの2つのプロトコルだけを指す言葉ではありません。

TCP/IPプロトコル 具体的なプロトコル
アプリケーションプロトコル HTTP, SMTP, FTP, TELNET, SNMP
トランスポートプロトコル TCP, UDP
インターネットプロトコル IP, ICMP, ARP
経路制御プロトコル RIP, OSPF, BGP

イーサネットとは何か?

イーサネットとは、LANケーブルの通信に関する決まり事です。イーサネットは、物(LANケーブル)に対しての決まり事です。

ポート番号とは何か?

ポート番号とは、TCPで接続したコネクションで転送するデータが、どのアプリケーションプログラムに渡されるのかを決定する番号です。サーバ側のよく使われているポート番号にはデフォルトの番号が振られており、HTTPはデフォルトで80番ポートを使用します。

クライアントは1つのリクエストを送信しレスポンスを受信する際に何をやっているのか?

  1. リクエストメッセージの構築
  2. リクエストメッセージの送信
  3. レスポンスが返るまで待機
  4. レスポンスメッセージの受信
  5. レスポンスメッセージの解析
  6. クライアントの目的を達成するために必要な処理(ブラウザであればHTMLをレンダリングする)

Tips

  • レンダリングとは、元になるデータを整形してウインドウに表示することです。

リクエスト・レスポンスの中でサーバは何をやっているのか?

  1. リクエストの待機
  2. リクエストメッセージの受信
  3. リクエストメッセージの解析
  4. サーバ内で適切なアプリケーションプログラムへの処理の委譲
  5. サーバはアプリケーションプログラムから結果(HTML)を取得
  6. 適切なヘッダを付加して、レスポンスメッセージを構築
  7. レスポンスメッセージの送信

Tips

  • HTTPメッセージを構築したら送信しています。またHTTPメッセージを受信したら解析しています。

HTTPメッセージとは何か?

HTTPメッセージとは、リクエストメッセージとレスポンスメッセージのことです。リクエスト・レスポンスが行われるときは、必ずHTTPメッセージが作成されます。

HTTPメッセージ 意味
リクエストメッセージ クライアントがサーバ側へ送る要求を表す
レスポンスメッセージ サーバ側がクライアント側へ送る結果を表す
HTTPメッセージの中身 行目  意味 備考
スタートライン 1行目 リクエストラインの場合、どのリソースに対して、どんな方法を使ってリクエストを出すかを表します。ステータスラインの場合、リクエストが成功したかどうかを表します。 スタートラインは、リクエストメッセージの場合はリクエストライン、レスポンスメッセージの場合はステータスラインと言います。
ヘッダ 2行目以降 メッセージのメタデータ メッセージは複数のヘッダを持つことができる。リクエストメッセージの場合、リクエスト先のホストを表すHostヘッダを必ず書きます。
空行 ヘッダ終わりの次の行 ヘッダの終了を表す目印のような1行
ボディ 空行の次の行 メッセージを表す本質的な情報(リソースの表現)が入ります リクエスト・レスポンスの種類によっては、ボディが存在しない場合があります。ボディにはHTMLやJSON等のリソースの表現が入ります。

アプリケーション状態とは何か?

アプリケーション状態(セッション状態)とは、クライアントで開いているアプリケーションの状態のことです。ステートレスなサーバはクライアントのアプリケーション状態を記憶せず、クライアント側が自らのアプリケーション状態を記憶します。クライアント側では全てのリクエストに必要な情報を含めます。こうすることで、ステートレスなサーバに対して、ステートフルな通信をすることができます。Railsの場合、セッションidやユーザーが送って来た情報等のセッション情報を暗号化してブラウザのクッキーに保存させています。ブラウザはリクエストのたびにそのクッキーを送ることで、前のリクエスト内容を保持しながらリクエストを出すことができます。サーバ側でクライアントの情報を保持する必要がないので、サーバはリクエストを処理することに集中できます。

Cookieを用いたセッション管理

ステートフルな通信をするためには、Cookieを用いてセッション管理をする必要があります。

Cookieとは

Cookieとは「ブラウザに保存される小さな情報またはその領域」のことです。ファイルのようなものです。

セッションとは

セッションとは「サーバ側で一時的に保持できる情報またはその領域」のことです。セッションはよく「一連の処理の始まりから終わりまでを表す概念」と言われることが多いですが、個人的にはこのように認識した方がわかりやすいので、そうしてます。

Cookieでセッション管理するときに気をつけるべきこと

サーバーからsession_idのような識別番号が渡され、それがブラウザのCookieに保存されます。このとき気をつけるべきことは、この識別番号に推測されやすい番号を使ってはならないと言うことです。ブラウザのCookieは誰でも値を自由にセットできます。そのため、推測されやすい番号(user_idなど)を識別番号として使うと、Cookieに適当に値をセットしてリクエストを出すと、ログインできてしまいます。識別番号に推測されやすい番号(user_id等)は絶対に使ってはダメです。また、識別番号が漏洩しないように設定することも大事です。

なぜステートレスが普及し、ステートフルは普及しなかったのか?

HTTPがステートレスなプロトコルなので、ステートレスが普及しました。しかし、なぜステートレスが採用されたのでしょうか?ステートレスなサーバはクライアントの状態を保持しないので、クライアントが増えてもサーバを増やすだけでシステムをスケールできます。しかしステートレスにはデメリットもあります。サーバをステートレスにするために、クライアントは毎回必要な情報を全て送信する必要があります。そのため、送信するデータ量が多くなります(ステートフルなサーバの場合、前回のリクエストメッセージとの差分を送れば良かった)。

参考記事

https://wa3.i-3-i.info/word1539.html

https://wa3.i-3-i.info/word1359.html

Session管理とRailsのcookie store

【Rails】Sessionの使い方について - Qiita

Railsのセッション管理には何が最適か - Qiita

Cookieとセッションってなに?ゼロからわかりやすく解説 - YouTube