HTTPとは
クライアント側とサーバ側がデータを送受信する際につかう、通信上の約束事のこと
階層型プロトコル
ネットワークプロトコルは階層型になってる
層ごとに抽象化して実装すれば、物理的なケーブルに左右されることなく上位層を実装できる
上位層
↓
下位層
の順に書いていきます
アプリケーション層(HTTP、NTP、SSH、SMTP、DNS)
メール、DNS、HTTPなどの具体的なインターネットアプリケーションを実現する部分です。
TCPでは、ソケットと呼ばれるライブラリを使うことが一般的
ソケットはネットワークでのデータのやり取りを抽象化したAPIで、接続、送信、受信、切断など基本的な機能を備えています。
トランスポート層(UDP、TCP)
インターネット層が保証しなかった、データの転送部分を保証する部分(TCP/IPではTCPの部分)
相手にコネクションを張って、データの抜け漏れをチェックします。
どのアプリケーションに渡るのかを決定するのがポート番号で、サーバ側でHTTPのデフォルトとしてよく使われるのは、80番(ポート番号: 1~65535番)
インターネット層(IP)
ネットワークで実際にデータをやり取りする部分(TCP/IPではIPの部分)
IPアドレスを指定して、パケットで送り出すことだけを保証しています。
ネットワークインターフェイス層(イーサネット)
物理的なケーブル、ネットワークアダプタに相当する部分です。
HTTPのバージョン
HTTP 0.9
1990年、Berbers-Leeが1990年にWebを開発したときに使っていたプロトコル
・ヘッダがない
・HTTPメソッドはGETのみ
HTTP 1.0
1993-1996年のブラウザ戦争が一番激しかった時期に仕様策定作業が行われたため、「インターネット標準」としてではなく、「インターネット全体に周知が必要な情報」として公開されました。
・ヘッダの導入
・GET以外のメソッドの追加
HTTP 1.1
1997年に策定されたものの改訂版です
・チャンク転送
・Acceptヘッダによるコンテントネゴシエーション
・複雑なキャッシュコントロール
・持続的接続
HTTP 2
2015年に仕様策定が進められ、RFC化を果たしました。
リッチコンテンツの需要拡大により、一度のアクセスで多くのリクエストを投げられることが増えたため、よりWebを高速化するために仕組みを変えようとしたのが誕生のきっかけです。
・ストリームの多重化
・ストリームの優先度
・ヘッダの圧縮
・フロー制御
Webのアーキテクチャスタイル
これにはクライアント/サーバが採用されています。
クライアント(Webブラウザ)がサーバ(Webサーバ)に接続してリクエストを出して、レスポンスを受け取る仕組みです。
このようなプロトコルのことをリクエスト/レスポンス型のプロトコルと呼びます。
サーバでの処理に時間がかかっても、リクエストを出したクライアントはレスポンスが返ってくるまで待機するこれはHTTPが同期型のプロトコルだからです。
このリクエストメッセージとレスポンスメッセージを合わせてHTTPメッセージと呼びます。
リクエストメッセージ
リクエストライン(1行目)
ヘッダ(2行目以降)
ボディ(ヘッダの次)
レスポンスメッセージ
ステータスライン(1行目)
ヘッダ
ボディ
↓ 2つのメッセージはこんなつくり
スタートライン(1行目)
ヘッダ(2行目以降)
空行(ヘッダの終わりを表す)
ボディ
HTTPのステートレス性
ステートレス性とは、サーバがクライアントのアプリケーション状態(ログインからログアウトするまでの一連の操作)を保存しないことです。
では、どうして保存しないのか?
ステートフルの場合、クライアントの数が増えるにしたがって難しくなってくるから。
クライアントの処理を100台までできるサーバがあったとしたら、101台目からは2台…となってしまいます。これでは、不特定多数のクライアントを全て対処することは難しいです。
その点、ステートレスでは、1回のリクエストで全ての情報を持っているので、サーバ側は前の内容を覚えている必要がなくなります。その代わりにクライアントが自分のアプリケーション状態を覚えてメッセージを送信するんです。
この、リクエスト処理に必要な情報が全て含まれているメッセージのことを「自己記述的メッセージ」といいます。
しかしステートレス性にも欠点はしっかり存在します。
ステートレスの欠点
パフォーマンスの低下
送信するデータ量の増加、承認など、サーバに負荷のかかる処理が繰り返されるため。
通信エラー時の対処
ネットワークトラブウが起きたときに、そのリクエストが処理されたのかどうかがわからない。
それでも今採用されてる、というのは利点の方が強かったからでしょうね…
HTTPの8つのメソッド
GET リソースの取得
POST 子リソースの作成、リソースへのデータの追加、そのほかの処理
PUT リソースの更新、リソースの作成
DELETE リソースの削除
HEAD リソースのヘッダ(メタデータの取得)
OPTIONS リソースがサポートしているメソッドの取得
TRACE プロキシ動作の確認(ほとんど使われてない)
CONNECT プロキシ動作のトンネル接続への変更(ほとんど使われてない)
「CRUD(クラッド)」を満たす代表的なメソッド
Create(作成) POST/PUT
Read(読み込み) GET
Update(更新) PUT
Delete(削除) DELETE
あまり使われていないTRACE, CONNECT以外のメソッドができることの簡単な紹介を…
GET
指定したURIの情報を取得する
POST
子リソースの作成
リソース絵のデータの追加
ほかのメソッドでは対応できない処理
PUT
リソースの更新
リソースの作成
DELETE
リソースの削除
HEAD
リソースのヘッダの取得
OPTION
リソースがサポートしているメソッドの取得
ステータスコードの分類と意味
ステータスコード
HTTPはリクエスト/レスポンス型のプロトコルなので、何か送れば絶対何かが返ってきます。
ステータスコードは返ってくる方、つまりレスポンスの中に含まれています。
ステータスライン
→プロトコルバージョン ステータスコード テキストフレーズ
(このステータスラインは、レスポンスメッセージの1行目の部分です。)
ステータスコードは、レスポンスメッセージが一体何を伝えたいかを表しているのです。
以下、大まかな分類になります。
1xx: 処理中
処理が継続していることを示す
2xx: 成功
リクエストが成功したことを示す
3xx: リダイレクト
ほかのリソースhwのリダイレクトを示す
4xx: クライアントエラー
クライアントエラーを示す
5xx: サーバーエラー
サーバーエラーを示す
その他有名なステータスコード
200 OK
リクエスト成功
201 Created
リソースの作成成功
301 Moved Permanently
リソースの恒久的な移動(新しいURIに移動)
302 See Other
別のURIの参照
401 Unauthorized
アクセス権不正
404 Not Found
リソースの不在
500 Internal Server Error
サーバ内エラー
503 Service Unavailable
サービス停止
404 Not Foundって何か調べてるときとかにたまにでてきますよね。
元々なかったのか、消されたのかってことですかね…
HTTPヘッダ
ヘッダはメタデータで、これを見てクライアントやサーバはメッセージに対する挙動を決めます。
・リソースへのアクセス権を設定する承認
・クライアントとサーバの通信回数と量を減らすキャッシュなどの機能
をヘッダで実現しています。
承認やキャッシュなどの機能は、ヘッダをメソッドやステータスコードと組み合わせて実現できるようにしています。
HTTPヘッダのすっごく簡単な紹介です。
リクエストメッセージやレスポンスメッセージの、「: 」で区切られた左側にいるやつです。
Date
日時
Content-Type
メディアタイプを指定する
charsetパラメータ
文字エンコーティングを指定する
Content-Language
言語タグ
Accept
処理できるメディアタイプを伝える
Accept-Charset
処理できるエンコーディングを伝える
Accept-Language
処理できる言語を伝える
Content-Length
ボディの長さを指定する
Transfer-Encoding
チャンク転送 ボディを分割して転送する
キャッシュ用ヘッダ
Pragma
キャッシュを抑制する
Expires
キャッシュの有効期限を示す
Cache-Xontrol
詳細なキャッシュ方法を指定する
条件付きGET
If-Modified-Since
リソースの更新日時を条件にする
If-None-Match
リソースのETagを条件にする
Connection
持続的接続
Content-Disposition
ファイル名を指定する
Slug
ファイル名のヒントを指定する
書いてて私が少しずつ理解できてきました。
もっと勉強しなきゃですねー…
「Webを支える技術」著者 山本陽平 2010年5月1日 初版
http://blog.redbox.ne.jp/http2-cdn.html