読者です 読者をやめる 読者になる 読者になる

MogLog

メモというか日記というか備忘録というか

『Webを支える技術』 第6章 HTTPの基本 まとめメモ

 久しぶりに『Webを支える技術』を読んでみると、忘れている箇所や知識が曖昧な箇所が出てきたので、記憶定着のために重要だと思ったところを簡潔にまとめておく(第6章 HTTP 「HTTPの基本」のみ)。


HTTPの基本
・HTTPはRESTの重要な特徴である統一インターフェース、ステートレスサーバー、キャッシュなどを実装している、Webの基盤となるプロトコルである

・HTTPはTCP / IPをベースにしている

・Webはアーキテクチャスタイルに「クライアント・サーバー」を採用している。これは、クライアント(Webブラウザ)が情報を提供しているサーバー(Webサーバー)に接続し、各種のリクエストを出してレスポンスを受け取る

・HTTPは同期型のプロトコルである。そのため、サーバーがリクエストを処理するのに時間がかかっている場合でもクライアントはレスポンスが返ってくるまで待機する

・クライアントとユーザーエージェント
RFCの定義では、リクエストを送信する目的でサーバーとのコネクションを確立するプログラムがクライアントで、サーバーに対してリクエストを発行するのはユーザーエージェントと区別をしている。しかし、殆どの場合は大差が無いため、同じ意味で用いられることも多い

・クライアントが1つのリクエストを送信し、レスポンスを受信する際のフロー
1.リクエストメッセージの構築
2.リクエストメッセージの送信
3.(レスポンスが返ってくるまで待機)
4.レスポンスメッセージの受信
5.レスポンスメッセージの解析
6.クライアントの目的を達成するために必要な処理

・クライアントからリクエストを受けたサーバーの処理フロー
1.(リクエストの待機)
2.リクエストメッセージの受信
3.リクエストメッセージの解析
4.適切なアプリケーションプログラムへの処理の委譲
5.アプリケーションプログラムから結果を取得
6.レスポンスメッセージの構築
7.レスポンスメッセージの送信



HTTPメッセージ
・リクエストメッセージとレスポンスメッセージをまとめて「HTTPメッセージ」と呼ぶ

・HTTPメッセージの1行目はスタートラインと総称される
 →リクエストの場合はここがリクエストメッセージになり、レスポンスの場合はステータスラインとなる。

・スタートラインに続いてヘッダが続く。ヘッダの終了は空行で識別する。

・ヘッダは省略することができる

・ヘッダに続けてボディが続く。ボディは省略することもできる

・ボディにはテキストだけでなく、バイナリデータも入れることができる

■リクエストメッセージ
・リクエストメッセージは「リクエストライン」と「リクエストヘッダ」と「リクエストボディ」の最大3要素で構成される。

・リクエストライン

  • リクエストメッセージの1行目。
  • リクエストラインはHTTPメソッド、リクエストURI、プロトコルバージョンから成る。
  • リクエストURIにはパスと絶対URIの両方を使うことができる。パスを使った場合は、リクエストヘッダにHostの指定が必須となるが、絶対URIを使った場合はHostを省略することができる。

(例)リクエストURIにパスを使った場合
GET /test HTTP/1.1

(例)リクエストURIに絶対URIを使った場合
GET http://example.jp/test HTTP/1.1

・リクエストヘッダ

  • リクエストメッセージの2行目以降はリクエストヘッダが続く。
  • ヘッダはメッセージのメタデータである。メタデータとは、データを記述するデータのことで、データについてのデータという意味。
  • 1つのメッセージは複数のヘッダを持つことができる。
  • 各ヘッダは「名前:値」という構成をしている。

・リクエストボディ

  • ヘッダのあとにボディが続くこともある(続かないこともある)。
  • ヘッダとボディは空行で区切られる。
  • ボディにはそのメッセージの本質を表す情報が入る。例えばリソースを新しく作成したり、更新したりするときは、リクエストのボディにリソースの表現そのものが入る。

・リクエストメッセージの例
GET / HTTP/1.1
Host: gihyo.jp
User-Agent: Mozilla/5.0 (Windows.........
Accept: text/html, application/xhtml+xml, application/xml;......
Accept-Language: ja,en-US;q=0.7;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: Shift_JIS,utf-8;..........
Keep-Alive: 300
Connection: keep-alive

■レスポンスメッセージ
・レスポンスメッセージは「ステータスライン」と「レスポンスヘッダ」と「レスポンスボディ」の最大3要素で構成される

・ステータスライン

  • レスポンスメッセージの1行目はステータスラインになる。プロトコルバージョン、ステータスコード、テキストフレーズの3つがはいる。
  • ステータスコードはリクエストの結果をプログラムで処理可能な数値コードで表現する。

(例)HTTP/1.1 200 OK
(例)HTTP/1.1 500 Internal ServerError

・レスポンスヘッダ

  • レスポンスメッセージの2行目以降はリクエストメッセージと同様にヘッダとなる。

(例)
Connection: Keep-Alive
Content-Encoding: gzip
Content-Length: 10kB
Content-Type: text/html;charset=UTF-8
Date: 2013 Aug 3 13:33:34
Keep-Alive: timeout=2, max=100
Set-Cookie: .....
Vary: Accept-Encoding, User-Agent

・レスポンスボディ
ヘッダとボディは空行で区切られる。
htmlファイルをリクエストした場合、ここにhtmlやcssといったデータが入って返ってくる

・レスポンスメッセージの例
HTTP /1.1 200 OK
Date: Sun, 3 Jan 2010 19:00:00 GMT
Server: Apache
P3P: CP="NOI NID ADMa.........."
Cache-Control: private, must-revalidte
Connection-Encoding: gzip
Vary: Accept-Encoding
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8



HTTPのステートレス性
・HTTPはステートレスなプロトコルとして設計されている
・ステートレスとは「サーバーがクライアントのアプリケーション状態を保存しない」制約のこと
・ステートレスの反対はステートフル
・システムにログインしてからログアウトするまでの一連の操作をまとめて「セッション」と呼ぶ。アプリケーション状態とセッション状態はほぼ同義
・ステートフルプロトコルの代表はFTPである。FTPではクライアントがFTPサーバにログインしてからログアウトするまで、そのクライアントがどのディレクトリにいるかというアプリケーション状態をサーバーが管理する
 → そのため、クライアントはディレクトリの移動などで相対パスを指定することができる
・ステートフルなアーキテクチャでは、クライアントの数が増えた場合にスケールアウトさせにくくなってしまう
・ステートレスプロトコルでは、クライアントが1度の通信で必要な情報を全て記述する必要がある。このため、サーバーの負担が軽くなり、システムも単純になる。