web技術雑記
備忘録的にHTTPやWebAPIのことを書き加えていきます。
HTTPの概要
クライアントとサーバーをつなぐ通信技術。
頭に認証情報なんかを張り付けて走りこんでくる。
クライアント→サーバー(リクエスト)
サーバー→クライアント(レスポンス)
TCPやTLSを使って送信されるアプリケーション層のプロトコル
HTTP自体はステートレスである。Cookieやキャッシュを用いることでステートフルを実現。
クライアントとサーバーの間にはプロキシサーバーと呼ばれるものがいくつもある。
HTTPの構成要素
主にウェブブラウザが担う役割、ほかには開発者がデバッグ用に使用するアプリがある
常にリクエストを生成する側
仮想的には1台に見えるが、複数のサーバーの集合体である場合もある。
これらは負荷 (負荷分散)、あるいは他のコンピューター (キャッシュ、データベースサーバー、電子商取引サーバーなど) に問い合わせを行う複雑なひとまとまりのソフトウェアを分け合って、リクエストに応じて全面的または部分的に文書を生成している。
HTTP/1.1 と Host ヘッダーによって、同じ IP アドレスを共有できる
-
そのまま転送する場合と、リクエストに変更を加える場合がある。
プロキシは様々な機能を実行する。- キャッシュ (キャッシュは共用、あるいはブラウザーキャッシュのように個人用にできます)
- フィルタリング (アンチウィルススキャンやペアレンタルコントロールなど)
- 負荷分散 (複数のサーバーが別々のリクエストに対応できるようにする)
- 認証 (さまざまなリソースへのアクセスを制御する)
- ログ記録 (履歴情報の保管を可能にする)
HTTPメッセージ
HTTP メッセージはリクエストとレスポンスの 2 種類あり、それぞれ固有の形式になっています。
HTTPリクエスト(クライアント→サーバー)
GET /index.html HTTP/1.1
Host: localhost:8000
...
開始行+ヘッダー+(本文)で構成されています。
- 開始行
アクションを始めるためにクラアントからサーバーへ送られる。以下の要素で構成されている。- HTTPメソッド
GET、POSTなど実行するアクションを表す。例えばGETはリソースを取り込むこと、POSTはデータをサーバーへ送信することを表す。 - リクエスト対象
通常はURLだが、HTTPメソッドによって形式は異なる - HTTPバージョン
言葉のままの意味。レスポンスで使用することを想定しているバージョンを示す役割もある。
- HTTPメソッド
- ヘッダー
リクエストのHTTPヘッダーは認証情報などの様々な情報をサーバーに送信する。 - 本文
リソースを取り込むメソッドであるGET、HEAD、DELETEなどは通常本文は不要。
本文は大きく分けて2種類に分類される。- 単一リソースの本文。1 個のファイルで構成され、Content-Type と Content-Length の 2 つのヘッダーで定義される。
- 複数リソースの本文。マルチパートの本文で構成され、それぞれが異なる情報を持つ。これは主に、 HTML フォームと関連付けられる。
HTTPレスポンス(サーバー→クライアント)
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Connection: Keep-Alive
...
リクエスト同様、開始行+ヘッダー+(本文)で構成されています。
- 開始行(ステータス行)
HTTPレスポンスの開始行はステータス行と呼ばれ、以下の要素で構成されている。- プロトコルバージョン
通常、HTTP/1.1です。 - ステータスコード
リクエストが成功したか失敗したかをコードで示す。一般的なステータスコードは200, 404, 302 - ステータス文字列
ステータスコードをテキストで説明する。
- プロトコルバージョン
- ヘッダー
レスポンスのHTTPヘッダーは認証情報などの様々な情報を返す。 - 本文
201 Created や 204 No Content といったステータスコードのレスポンスは通常、本文がない。- 大きさが判明している単一リソースの本文。1 個のファイルで構成され、Content-Type と Content-Length の 2 つのヘッダーで定義される。
- 大きさが不明な単一リソースの本文。1 個のファイルで構成され、 Transfer-Encoding を chunked に設定して、 chunked 形式でエンコードされる。
- 複数リソースの本文。マルチパートの本文で構成され、それぞれが異なる情報のセクションを持つ。
HTTPの機能
過去に取得したリソース(画像や文章など)を再利用して、遅延を削減しウェブサイトの応答性を高める技術。プライべートキャッシュと共有キャッシュの二つがある。
共有キャッシュは複数のユーザーが再使用するためにレスポンスを保存するキャッシュ(プロキシに保存されるキャッシュ)
プライベートキャッシュはその反対、一人のユーザーのためのキャッシュ(ブラウザに保存されるキャッシュ)
何をどれだけの間キャッシュするのかクライアントに対して指示できる。
これはHTTPヘッダーのCache-Controlで制御できる。
キャッシュの容量は有限なので、すべての情報を永続的に保存することはできない。
また、サーバー上で変更されたリソースを更新しないといつまでも古い情報を表示することになるので、キャッシュ・エビクションという処理で定期的にリソースの削除が行われる。
ヘッダーで設定した有効期限をもとに優先順位をつけたり、リソースが新鮮かどうかを検証したりして行われる。
ウェブブラウザはセキュリティの観点から、同一オリジンのページだけがウェブページのすべての情報にアクセスできるが、CORSを使用することによってこの制約を緩和することができる。これにより、様々なドメインから、情報を取得することが可能となるがセキュリティ上の問題がある(CORS脆弱性)
特定のユーザーしかアクセスできないようなページへのアクセスはWWW-Authenticateヘッダーを使用して基本的な認証を行える(Basic認証など)が、情報を盗み見られる可能性があるため、https/TLSを使用する必要がある
HTTP Cookieを使用(セッションIDをCookieに保存して検証)してリクエストとサーバーのセッションを関連付ける。これにより、ユーザー個別の情報(設定やショッピングバスケットなど)を出力内容に反映できる。