devkuma – HTTP

HTTP 紹介

kc@example.com (kc kim) — Tue, 06 Nov 2018 01:34:33 +0900

HTTP 概要

HTTP(HyperText Transfer Protocol)は、WWW で Web サーバーとクライアント(ブラウザー)の間でデータ(Web ページなど)を送受信するためのプロトコルである。基本的にはテキストメッセージリソースを交換し、そのほかにも .jpeg などのさまざまなリソースを交換できる。

HTTP はアプリケーションレベルのプロトコルで、TCP/IP で構成されたプロトコルである。
HTTP は状態を持たない Stateless プロトコルである。
Method、Path、Version、Headers、Body などで構成される。

HTTP バージョンごとに以下の仕様書が公開されている。

HTTP Messages

HTTP メッセージには 2 つの種類がある。

HTTP リクエストメッセージ: クライアントがサーバーにリソースを要求する。
HTTP レスポンスメッセージ: サーバーがクライアントに HTTP リクエストの結果を応答する。

HTTP Request (リクエスト)

kc@example.com (kc kim) — Tue, 06 Nov 2018 01:34:33 +0900

HTTP Request messages (リクエストメッセージ)

ブラウザーで Web ページを開くと、ブラウザーはサーバーに次のようなリクエストメッセージを送信する。

GET / HTTP/1.1
Accept: image/gif, image/jpeg, */*
Accept-Language: ko
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (Compatible; MSIE 6.0; Windows NT 5.1;)
Host: www.xxx.zzz
Connection: Keep-Alive

リクエストメッセージは次の構文で構成される。

HTTP Request line(リクエストライン)

GET / HTTP/1.1

HTTP Request Header(リクエストヘッダー)

Accept: image/gif, image/jpeg, */*
Accept-Language: ko
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (Compatible; MSIE 6.0; Windows NT 5.1;)
Host: www.xxx.zzz
Connection: Keep-Alive

HTTP Body(本文)

メッセージ本文(POST メソッドなどを使用)

Start line (リクエスト開始ライン)

HTTP リクエストの開始行には次の 3 つの要素がある。

HTTP メソッド
リクエスト対象(パス名)
HTTP プロトコルバージョン

リクエストラインは次の形式で表示される。

リクエストライン

[HTTP メソッド] [リクエスト対象] [HTTP プロトコルバージョン]

パス名は通常 /aaa/bbb/ccc.html のようなもので、スラッシュで始まるパス名、または http:// で始まる URL が指定される。バージョンは現在 1.1 が一般的に使用される。

HTTP Method (メソッド)

HTTP/1.0、HTTP/1.1 でサポートされるメソッドは次のとおりである。

メソッド	HTTP/1.0	HTTP/1.1	説明
GET	◎	◎	最も一般的に使われるメソッドである。ブラウザーはサーバーにページの取得を要求する。
HEAD	◎	◎	ヘッダー専用情報を要求する。サーバーは GET メソッドと HEAD メソッドを必ずサポートしなければならない。
POST	○	○	`method="POST"` を指定したフォームに入力したデータをサーバーへ送信するときに使われる。
PUT	○	○	ファイルをサーバーへアップロードするときに使われる。
DELETE	○	○	指定されたリソースの削除をサーバーに要求する。
CONNECT	×	○	プロキシサーバー経由で SSL 通信するときなどに使う。
OPTIONS	×	○	サーバーがサポートしているメソッドやオプションを照会するときに利用する。
TRACE	×	○	HTTP リクエストがどのプロキシサーバーを経由して送信されるかなど、HTTP の動作を追跡するときに利用する。
LINK	○	×	指定した URL とリソースにリンク関係を接続する。HTTP/1.1 ではもう使われない。
UNLINK	○	×	指定された URL とリソース間のリンク関係を解除する。HTTP/1.1 ではもう使われない。

(◎: 必須、○: サポート、×: 未サポート)

Apache は上記以外にも PATCH、PROPFIND、PROPPATCH、MKCOL、COPY、MOVE、LOCK、UNLOCK などのメソッドをサポートしている。

GET

GET リクエスト方式は URI(URL)が持つ情報を取得するためにサーバー側へ要求する形式である。

POST

POST リクエスト方式は、リクエスト URI(URL)にフォーム入力を処理するために構成したサーバー側スクリプト(ASP、PHP、JSP など)または CGI プログラムへ Form Action とともに送信される。このときリクエスト情報はヘッダー情報に含まれず、データ部分に入る。

HEAD

HEAD リクエスト方式は GET と似ているが、Web サーバーはヘッダー情報以外のデータを送信しない。Web サーバーの稼働確認(Health Check)や Web サーバー情報(バージョンなど)を得るために使われる。

OPTIONS

rfc2616
このメソッドでシステムがサポートしているメソッドの種類を確認できる。

PUT

POST と似た転送構造を持つため、ヘッダー以外にメッセージ(データ)も送信される。リモートサーバーに指定したコンテンツを保存するために使われ、ホームページ改ざんに悪用されることも多い。

PATCH

PUT と似て、要求されたリソースを修正(UPDATE)するときに使う。PUT はリソース全体を更新する意味だが、PATCH は該当リソースの一部を置き換える意味で使われる。

DELETE

リモート Web サーバーのファイルを削除するために使われ、PUT とは反対の概念のメソッドである。

TRACE

リモートサーバーに Loopback(ループバック)メッセージを呼び出すために使われる。

CONNECT

Web サーバーにプロキシ機能を要求するときに使われる。

リクエスト対象(パス名)

リクエスト対象は URL、パス、クエリ文字列などを含む。

リクエスト対象形式	形式例	説明
origin form	- POST / HTTP/1.1 - GET /background.png HTTP/1.0 - HEAD /test.html?query=alibaba HTTP/1.1 - OPTIONS /anypage.html HTTP/1.0	一般的な形式
absolute form	GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1	プロキシで GET するときに使用
authority form	CONNECT developer.mozilla.org:80 HTTP/1.1	CONNECT で使用
asterisk form	OPTIONS * HTTP/1.1	OPTIONS で使用

HTTP プロトコルバージョン

HTTP バージョンを示す。一般的には HTTP/1.1 または 2.0 である。

HTTP Header (リクエストヘッダー)

リクエストヘッダーには 3 つの種類がある。

ヘッダータイプ	説明	例
リクエストヘッダー	リクエスト本文のデータとは関係しないヘッダー	- Host - User-Agent - Accept - - If- - Referer
一般ヘッダー	取得するリソース	- Date - Cache-Control
エンティティヘッダー	リクエスト本文に適用	- Content-Type - Content-Length - Expires

HTTP Body (リクエスト本文)

HTTP リクエスト本文はリクエストで送るデータである。
一般的に GET、HEAD、DELETE、OPTIONS にはリクエスト本文がない。リソースを照会または削除する場合にだけ使う。
リクエスト本文は POST、PUT などでリソースにデータを送信する場合に利用する。

HTTP Response (レスポンス)

kc@example.com (kc kim) — Tue, 06 Nov 2018 01:34:33 +0900

HTTP Response messages (レスポンスメッセージ)

サーバーはリクエストを受け取ると、次のようなレスポンスメッセージを返す。

HTTP/1.1 200 OK
Date: Sun, 11 Jan 2014 16:06:23 GMT
Server: Apache/1.3.22 (Unix) (Red-Hat/Linux)
Last-Modified: Sun, 07 Dec 2013 12:34:18 GMT
ETag: "1dba6-131b-3fd31e4a"
Accept-Ranges: bytes
Content-Length: 4891
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

<!DOCTYPE html>
<html>
  :
</html>

レスポンスメッセージは、レスポンス行(状態行)、HTTP レスポンスヘッダー、ヘッダーの終わりを意味する空行、HTTP 本文で構成される。

改行コードは Windows 形式の CR LF("\r\n") である。最初の行にはリクエスト行またはレスポンス行があり、ヘッダーは複数行、空行は 1 行、メッセージボディは複数行である。

Start line (レスポンス開始ライン)

HTTP レスポンスの開始ライン(状態ライン)には次の 3 つの要素がある。

HTTP プロトコルバージョン(HTTP リクエストメッセージと同じ)
Response Status Code(レスポンス状態コード)
状態文字列

レスポンス開始ラインは次の形式で表示される。

[HTTP プロトコルバージョン] [レスポンス状態コード] [状態文字列]

状態文字列は OK や Not Found のような状態番号の意味と詳細を補うメッセージを返す。

Response Status Code(レスポンス状態コード)と状態文字列

HTTP/1.1 の状態コード定義は RFC 2616 に規定されており、簡単にまとめると次のとおりである。

レスポンスコード	意味	説明
1xx	Informational	情報提供
2xx	Successful	成功レスポンス
3xx	Redirection	追加作業(リダイレクト)
4xx	Client Error	クライアント側エラー
5xx	Server Error	サーバー側エラー

1xx、2xx、3xx コードはサーバーと User Agent 間の状態を表すため、一般ユーザーがその内容を見ることは少ないが、4xx、5xx コードは一般ユーザーもよく目にする内容である。

レスポンスコード	意味	説明
100	Continue	クライアントから一部のリクエストを受け取り、残りの情報を続けて要求する。
101	Switching protocols	プロトコル切り替え。
200	OK	リクエストが正常に実行された。
201	Created	リクエストが成功し、サーバーが新しいリソースを作成した。
202	Accepted	Web サーバーがリクエストを受け付けたが、まだ処理していない。
204	No content	サーバーがリクエストを正常に処理したが、コンテンツを提供しない。
206	Partial content	サーバーが GET リクエストの一部だけを正常に処理した。
301	Moved permanently	要求したデータが変更後の別 URL に移動した。
302	Found temporarily	要求したデータを一時 URL で見つけた。
304	Not modified	更新されておらず、ローカルキャッシュ情報を利用した。
400	Bad request	リクエストが不正である。
401	Unauthorized	認証されていない。
403	Forbidden	アクセスが許可されていない。
404	Not found	要求したページがない。
405	Method not allowed	許可されていない HTTP Method を使用した。
408	Request timeout	リクエストがタイムアウトした。
500	Internal server error	サーバー内部エラー。
502	Bad Gateway	ゲートウェイが不正である。
503	Service unavailable	サービス提供不可。
504	Gateway timeout	ゲートウェイがタイムアウトした。
505	HTTP version not supported	その HTTP バージョンはサポートされていない。

HTTP Header (レスポンスヘッダー)

レスポンスヘッダーには次の 3 つの種類がある。

ヘッダータイプ	説明	例
レスポンスヘッダー	レスポンス本文のデータとは関係しないヘッダー	- Location
一般ヘッダー	取得するリソース	- Date - Cache-Control
エンティティヘッダー	レスポンス本文に適用	- Content-Type - Content-Length - Expires

HTTP Body (レスポンス本文)

リソース(ファイル)の内容を含む。

HTTP Header (ヘッダー)

kc@example.com (kc kim) — Tue, 06 Nov 2018 01:34:33 +0900

HTTP Header (ヘッダー)

HTTP ヘッダーは、HTTP リクエストとレスポンスで交換されるメタデータである。メッセージの解釈方法、キャッシュ、受け入れ可能なコンテンツタイプ、認証情報、接続動作、Content-Length やエンコーディングなどのエンティティ情報を表す。

カテゴリ	リクエスト	レスポンス	ヘッダー
一般ヘッダー	○	○	Cache-Control, Connection, Date, Pragma, Trailer, Transfer-Encoding, Upgrade, Via, Warning
リクエストヘッダー	○	×	Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, Expect, From, Host, If-Match, If-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since, Max Forwards, Proxy-Authorization, Range, Referer, TE, User-Agent
レスポンスヘッダー	×	○	Accept-Ranges, Age, ETag, Location, Proxy-Authenticate, Retry-After, Server, Vary, WWW-Authenticate
エンティティヘッダー	○	○	Allow, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Expires, Last-Modified, extension-header

主なリクエストヘッダー

Accept: ブラウザーが受信できるデータ形式(MIME タイプ)をサーバーに伝える。* は「すべて」を意味する。
Accept-Charset: ブラウザーが受信可能な文字セットをサーバーに伝える。
Accept-Encoding: ブラウザーが受信可能なエンコーディング方式をサーバーに伝える。
Accept-Language: ブラウザーが受信可能な言語をサーバーに伝える。
Authorization: 認証が必要なリソースへの認証情報を伝える。
Host: リクエストが送信されるサーバーのホスト名とポート番号を指定する。HTTP/1.1 で唯一の必須ヘッダーである。
If-Match、If-None-Match、If-Modified-Since、If-Unmodified-Since、If-Range: キャッシュ検証や部分リクエストで使われる条件付きリクエストヘッダーである。
Range: サーバーにエンティティの一部だけを要求する。
Referer: このリクエストの元になったページの URL を伝える。
User-Agent: クライアントアプリケーション名、ブラウザー、OS、バージョン、プラットフォームなどの情報を伝える。

主なレスポンスヘッダー

Accept-Ranges: Range リクエストで使用可能な単位をクライアントに伝える。
Age: エンティティが生成されてからの推定経過時間(秒)を示す。
ETag: エンティティとそのバージョンを一意に識別する識別子を示す。
Location: リダイレクト先 URL を示す。
Proxy-Authenticate: プロキシサーバーとクライアント間で認証が必要であることを示す。
Retry-After: 503 Service Unavailable や 3xx リダイレクトとともに返され、再試行時期を示す。
Server: サーバー情報をブラウザーに返す。
Vary: サーバー主導型ネゴシエーションで使用されたヘッダー情報を示す。
WWW-Authenticate: 認証が必要であることを示す。

主なエンティティヘッダーと一般ヘッダー

Allow: リクエスト URL に示されたリソースで使用できるメソッド一覧を提供する。
Cache-Control: キャッシュに関する指示を示す。
Connection: Keep-Alive や close など、持続接続の動作を示す。
Content-Encoding: gzip などのコンテンツエンコーディング方式を示す。
Content-Language: コンテンツの言語を示す。
Content-Length: コンテンツ(メッセージ本文)の長さをバイト単位で示す。
Content-Location: コンテンツが別 URL でもアクセス可能な場合、その URL を示す。
Content-MD5: 通信中にコンテンツが変更されていないか確認するためのチェックデータを示す。
Content-Range: 送信するコンテンツの範囲を示す。
Content-Type: リソースの MIME タイプを示す。
Date: レスポンスを返す時刻を示す。
Expires: エンティティの有効期限を示す。
Last-Modified: エンティティが最後に更新された時刻を示す。
Transfer-Encoding: 転送に使用されるエンコーディング形式を示す。
Via: メッセージの伝達経路を示す。
Warning: 状態行に追加される警告コードとメッセージを伝える。

仮想ホスト

HTTP/1.1 では仮想ホストがサポートされる。HTTP/1.1 のクライアントは Host ヘッダーでホスト名を送信しなければならない。サーバーは仮想ホストに対応するコンテンツを応答する。これにより 1 台のサーバーで複数の Web サイトをサポートできる。

持続的な接続(Keep-Alive)

初期の HTTP は、HTTP リクエストを送るたびに新しいソケット接続を作っていた。この方法は効率的ではない。持続接続は、1 つの接続内で複数のリクエストを送ることでこの非効率を解決する。

チャンク(chunked)

CGI 結果の返却でコンテンツを生成するときにコンテンツ長が分からない場合など、サーバーはチャンク形式のデータを返すことができる。チャンク形式のデータでは、連続データのバイト数が 16 進数で示される。0 はデータの終わりを意味する。

BASIC 認証

HTTP Basic 認証を使用すると、サーバーはクライアントのリクエストに対して WWW-Authenticate ヘッダーを返す。クライアントはログイン名とパスワードを入力させ、それをエンコードして再度コンテンツを要求する。

HTTP Cookie (クッキー)

kc@example.com (kc kim) — Mon, 27 Dec 2021 18:02:00 +0900

概要

Cookie(クッキー)は次のような機能を作るために使用する。

訪問者がそのページに何回訪問したかを記録して表示する。
Web サービスで訪問者が最近訪問したページを記録し、次回訪問時にそのページを表示する。
掲示板やチャットで入力したユーザー名を記録し、次回訪問時にユーザー名の入力を省略する。
ログインでセッションを維持する。

以下の仕様書が公開されている。

RFC2109 (1997 年 2 月)
RFC2965 (2000 年 10 月)
RFC6265 (2011 年 4 月)

このようなデータは CGI などを利用してサーバー側に記録することもあるが、Cookie を利用することでクライアント側、つまりブラウザーを起動する側のハードディスクに Cookie 情報データを記録することもある。

Cookie 情報が保存されるファイルは OS やブラウザーのバージョンによって異なる。

Windows の場合は次のようなフォルダーやファイルに記録される。

- C:\Document and Settings\(UserName)\Cookies
- C:\Program Files\Netscape\Users\(UserName]\cookies.txt
- C:\Program Files\Netscape\Navigator\cookies.txt
- C:\Windows\Cookies\~.txt

macOS の Chrome の場合は以下に保存される。

- ~/Library/Application Support/Google/Chrome/Default/Cookies

JavaScript を使用して Cookie を設定するときは次のようにする。

document.cookie = "~";

HTML で指定する場合は次のようにする。この方法は推奨されない。

<meta http-equiv="Set-Cookie" content="~">

~ 部分には次の形式の文字列を指定する。

NAME=値; expires=値; domain=値; path=値; secure

NAME=値; 以外は任意である。

パラメーター	意味
`NAME=値`	任意の名前に任意の値を指定する。セミコロン、カンマ、空白文字、日本語や韓国語などを使う場合は適切な形式でエンコードする。
`expires=値`	クライアント側に記録される Cookie の有効期限を `Thu, 1-Jan-2030 00:00:00 GMT` のような形式で指定する。省略するとブラウザー終了時まで有効である。
`domain=値`	Cookie を発行する Web サーバー名を指定する。
`path=値`	ここで指定したパス名と一致するページを閲覧するとき、ブラウザーは保存された Cookie 情報をサーバーへ送る。
secure	この変数を入れると、サーバーとの接続が安全な場合にだけ Cookie 情報が送信される。

最も簡単な書き込み例は次のとおりである。

Set-Cookie: NAME=devkuma;

有効期限を指定する場合は次のようにする。

Set-Cookie: NAME=devkuma; Tue, 31-Dec-2030 23:59:59;

JavaScript を使用して Cookie 値を読むには、document.cookie の値を参照する。

alert(document.cookie);

HTTPS

kc@example.com (kc kim) — Thu, 18 Aug 2022 18:04:25 +0900

HTTP と HTTPS

HTTP

HTTP はテキストの交換であり、HTML ページもテキストである。
バイナリデータではなく単純なテキストを送受信するため、誰かがネットワーク上で信号を傍受すると内容が露出する。このようなセキュリティ上の問題を解決するために生まれたものが HTTPS である。

HTTPS

HTTPS は、インターネット上の情報を暗号化する SSL(Secure Socket Layer)プロトコルを利用して、クライアントとサーバーがデータを送受信する通信規約である。
HTTPS は HTTP テキストを暗号化するものである。
HTTPS の S は Secure Socket、つまり安全な通信網を意味する。

HTTPS 暗号化の原理

HTTP の暗号化原理の核心は公開鍵暗号方式である。

証明書を発行し、送信するメッセージを公開鍵で暗号化するようにしている。
暗号化されたメッセージは秘密鍵がなければ復号できないため、途中で誰も元データを得ることはできない。

HTTPS の特徴

HTTPS は SSL/TLS の上に HTTP を実装したものである。

主な機能

暗号化(Encryption)
認証(Authentication)
変更検知など

URI Scheme 接頭辞

https

使用ポート

URL が http ではなく https URI Scheme 接頭辞を持つ場合、通常の HTTP 80 番ではなく HTTPS 443 番ポートを使用する。

標準

RFC 2818

SSL/TLS

HTTP 通信で暗号化方式である SSL(Secure Sockets Layer)や TLS(Transport Layer Security)を利用することで、Web サイトを安全に使用できる。

SSL と TLS は同じものである。Netscape によって SSL が発明され、広く使われるようになった後、標準化機関である IETF の管理に移行し、TLS という名前に変わった。TLS 1.0 は SSL 3.0 を継承する。ただし TLS という名前より SSL という名前の方がはるかに多く使われている。

HTTPS の安全確保の仕組み

SSL/TLS では、以下の 3 つの仕組みによって Web サイトの安全性を確保する。

盗聴防止(暗号化通信)

Web サイトの閲覧では複数のサーバーを経由するため、第三者は比較的簡単に通信内容を傍受できる。
仮に傍受されても内容を解読できないようにデータを暗号化して転送することで、第三者からの盗聴を防止する。

改ざん防止

インターネットショッピングで商品の個数を書き換えるようなデータ改ざん対策として「メッセージダイジェスト」が利用される。
メッセージダイジェストは特定データから固有の短いデータ(ハッシュ値)を求める計算である。データ送受信時にハッシュ値を比較することで改ざんを検出できる。

なりすまし防止

Web サーバーに「SSL サーバー証明書」という電子証明書を配置し、接続時に検証することで Web サイト運営者の身元を確認できる。
信頼できない発行元の証明書が利用されている場合、Web ブラウザー上に警告画面が表示される。

HTTPS のセキュリティ動作方式

クライアント(Web ブラウザー)で通常の http ではなく https Scheme を持つ URL アドレスを入力すると、Web サーバーの 80 番ではなく 443 番ポートへ TCP 接続し、バイナリ形式のいくつかのセキュリティパラメーターを交換する(ハンドシェイク、鍵交換)。その後、関連する HTTPS コマンドが実行される。

HTTPS 交換

HTTPS で通信を開始するには、大きく 4 つのフェーズの交換を行う。

暗号化方式の決定
通信相手の証明
鍵交換
暗号化方式の確認

HTTPS におけるこの 4 段階の相互作用を「SSL/TLS ハンドシェイク」と呼ぶ。

HTTPS のサーバー証明書

サーバー証明書は、サーバーとクライアント間で暗号化通信を行うための電子証明書であり、認証局から発行される。

X.509 に基づく証明書で、証明書に Web サイト情報が追加される。

サーバー証明書に含まれる主なフィールド

証明書シリアル番号および有効期間
Web サイトの名前
Web サイトの DNS ホスト名(FQDN)
Web サイトの公開鍵
署名機関(認証局)の名前
署名機関(認証局)のデジタル署名など

参考

HTTP 2.0

kc@example.com (kc kim) — Fri, 12 Aug 2022 07:47:00 +0900

HTTP 2.0

HTTP 2.0 とも呼ばれる HTTP/2 は Hypertext Transfer Protocol Version 2 の略で、2015 年に IETF によって正式に発表された HTTP/1.1(既存標準)の次期バージョンである。

IETF: Internet Engineering Task Force は国際インターネット標準化機構を意味し、インターネットの運用、管理、開発について協議し、プロトコルや構造的な事項を分析する標準化作業機関である。

HTTP/2 はサーバーとクライアント間の TCP コネクション上で動作する。この TCP コネクションを初期化するのはクライアントである。HTTP/2 のリクエストとレスポンスは、長さが定義された 1 つ以上のフレームに格納される。フレーム内のリクエストとレスポンスはストリームを通じて送られ、1 つのストリームが 1 組のリクエストとレスポンスを処理する。1 つのコネクション上に複数のストリームを同時に作成できるため、複数のリクエストとレスポンスを同時に処理できる。

SPDY(スピーディー)

SPDY は Google が開発した非標準ネットワークプロトコルである。Web 環境が変化し続ける中で、パケット圧縮と Multiplexing を基盤にインターネット上の転送遅延(latency)問題を解決し、HTTP を高速化するために考案された。

HTTP/2 はこの SPDY に基づき、HTTP プロトコル Layer の下位の TCP 通信レイヤーに新しい Binary 階層を導入して、HTTP の基盤である TCP 接続の効率性を追求した。

SPDY の特徴は次のとおりである。

常に TLS 上で動作
HTTP ヘッダー圧縮
テキストではなくバイナリプロトコル
Multiplexing
Full-duplex interleaving & Prioritization
Server Push

SPDY は HTTP/2 の参考規格となったため、多くの構造が似ており、上記の特徴の多くは HTTP/2 にも存在する。

主な特徴

主な特徴は性能向上を目的としている。

Packet Capsulation - パケットカプセル化

HTTP/2 のパケットはより小さな単位にカプセル化され、Frame、Message、Stream という概念が導入される。

Frame
- HTTP/2 の通信最小単位で、すべてのパケットには 1 つの Frame Header が含まれる。
Message
- 論理的なリクエストまたはレスポンスメッセージに対応するフレーム全体のシーケンスデータである。
Stream
- 接続の流れを意味し、構成された接続内で伝達されるバイトの双方向フローである。

Request Multiplexing - 並列リクエスト

HTTP/2 は 1 つの TCP 接続を通じて複数のデータリクエストを並列に送受信できる。

従来の HTTP/1.x では、1 つの TCP コネクションでリクエストを送ると、そのレスポンスが到着するまで同じ TCP コネクションで次のリクエストを送れなかった。しかし HTTP/2 では 1 つのコネクションに複数のストリームを同時に開けるため、複数のリクエストを同時に送れる。

Header Compression - ヘッダー圧縮

HTTP/1.1 までの HTTP ヘッダーは圧縮なしでそのまま送信されていた。HTTP/2 では HTTP メッセージのヘッダーを圧縮し、重複するフィールドを再送信しないように変更された。

Binary Protocol - バイナリプロトコル

HTTP/2 はテキストプロトコルからバイナリプロトコルへ変更された。HTTP/1.x はリクエストレスポンスサイクルを完了するためにテキスト命令を処理したが、HTTP/2 はバイナリ命令を使用して同じ作業を実行する。

Server Push - サーバープッシュ

HTTP/2 は、サーバーが 1 つのリクエストに対して、クライアントが明示的に要求していない JavaScript、CSS、Font、画像ファイルなど必要になる特定ファイルをレスポンス時に一緒に送信できる。

Stream Prioritization - ストリーム優先順位

ストリームは優先順位を持つことができる。クライアントは好ましいレスポンス受信方式を指定してレスポンスを受け取ることができる。

参照

CORS

kc@example.com (kc kim) — Thu, 27 May 2021 10:59:45 +0900

概要

現在の Web ブラウザーでは、1 つの Web サイトが持つ情報が別の悪意ある Web サイトに悪用されることを防ぐため、Same-Origin Policy(同一オリジンポリシー)が適用される。

たとえば、異なるドメインのバックエンド API とフロントエンド間で通信してリソースを要求すると、Origin(ドメイン、プロトコル、ポート番号)が異なるためエラーが発生する。https://api.devkuma.com/ の Web ページから XHR や Fetch API で https://www.devkuma.com/ のデータを HTTP(S) で読み込もうとするとエラーになる。

しかし、信頼関係のある Web サイトまで制限してしまうと不便であるため、データアクセスを許可できる Web サイトについては Origin が異なってもアクセスできるようにする CORS(Cross-Origin Resource Sharing)が必要になる。

CORS とは？

Cross-Origin Resource Sharing の略で、オリジン間のリソース共有を意味する。
ブラウザーは異なるオリジン間の通信を原則として禁止しているが、CORS 設定により別オリジン間でも通信できる。
ブラウザーで見ているページとは別のドメインからデータを受け取ることを許可する方式である。
セキュリティ上、クロスサイトスクリプティングを防ぐために使用される。

Origin(オリジン)とは？

Web コンテンツの Origin は、そのコンテンツへアクセスするために使われる URL のスキーム(プロトコル)、ホスト(ドメイン)、ポートによって定義される。スキーム、ホスト、ポートがすべて一致する場合にのみ、2 つは同じ Origin と言える。

同一 Origin の例

http://www.devkuma.com/app1/index.html
http://www.devkuma.com/app2/index.html

異なる Origin の例

http://devkuma.com/app1
https://devkuma.com/app2

http://devkuma.com
http://www.devkuma.com

http://www.devkuma.com
http://www.devkuma.com:8080

なぜ CORS が必要なのか？

ブラウザーはセキュリティ上の理由で同一オリジンポリシーを採用している。他の出所から自分のリソースに勝手にアクセスできないようにするためである。

もし自分がサービスしていないサイトからセッションのリクエストを取得できるなら、そのサイトはセッションを奪取して悪用する可能性がある。ブラウザーはこのようなリクエストを防いでいる。

CORS はどのように動作するか

ブラウザーがリソースを要求するとき、追加ヘッダーに Origin、使用するメソッド、含めるヘッダー情報を入れてサーバーへ送信する。サーバーは応答可能な Origin をヘッダーに入れてブラウザーへ返す。ブラウザーはこのヘッダーを確認し、その Origin から要求できるならリソース転送を許可し、不可能ならエラーを発生させる。

CORS preflight リクエスト

HTTP ヘッダーの送受信で構成される仕組みであり、ブラウザーがオリジンを越えた要求への応答にフロントエンド JavaScript コードがアクセスできるかどうかを決定する。

Request Header 一覧

Origin: どの Origin からアクセスしているかを示す。
Access-Control-Request-Method: preflight リクエスト時に、実際のリクエストで使用するメソッドをサーバーに知らせる。
Access-Control-Request-Headers: preflight リクエスト時に、実際のリクエストで使用するヘッダーをサーバーに知らせる。

Response Header 一覧

Access-Control-Allow-Origin: ブラウザーが該当 Origin からリソースへアクセスできるよう許可する。
Access-Control-Expose-Headers: 応答の一部として公開してよいヘッダーを示す。
Access-Control-Max-Age: preflight リクエスト結果をキャッシュできる時間を示す。
Access-Control-Allow-Credentials: credentials が true のとき、リクエストへの応答を公開できるかを示す。
Access-Control-Allow-Methods: preflight リクエストへの応答として許可されるメソッドを示す。
Access-Control-Allow-Headers: 実際のリクエストで使用できる HTTP ヘッダーを示す。

CORS 使用例

https://api.devkuma.com に対して、別 Web サイト https://www.devkuma.com からの HTTP(S) アクセスを許可する場合を例に説明する。

単純に GET と POST を許可するには、サーバーが HTTP レスポンスヘッダーに次を追加する。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.devkuma.com

Cookie を許可する場合は、ブラウザーとサーバーの両方で設定が必要である。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.devkuma.com
Access-Control-Allow-Credentials: true

GET、POST、HEAD 以外のメソッドやカスタムヘッダーを使う場合は、実際の HTTP リクエスト前に OPTIONS の preflight request が行われる。

devkuma – HTTP

HTTP 紹介

HTTP 概要

HTTP Messages

HTTP Request (リクエスト)

HTTP Request messages (リクエストメッセージ)

Start line (リクエスト開始ライン)

HTTP Method (メソッド)

GET

POST

HEAD

OPTIONS

PUT

PATCH

DELETE

TRACE

CONNECT

リクエスト対象(パス名)

HTTP プロトコルバージョン

HTTP Header (リクエストヘッダー)

HTTP Body (リクエスト本文)

HTTP Response (レスポンス)

HTTP Response messages (レスポンスメッセージ)

Start line (レスポンス開始ライン)

Response Status Code(レスポンス状態コード)と状態文字列

HTTP Header (レスポンスヘッダー)

HTTP Body (レスポンス本文)

HTTP Header (ヘッダー)

HTTP Header (ヘッダー)

主なリクエストヘッダー

主なレスポンスヘッダー

主なエンティティヘッダーと一般ヘッダー

仮想ホスト

持続的な接続(Keep-Alive)

チャンク(chunked)

BASIC 認証

HTTP Cookie (クッキー)

概要

Cookie 情報が保存されるフォルダーとファイル

Cookie の書き込み

Cookie 書き込み例

Cookie の読み取り

HTTPS

HTTP と HTTPS

HTTP

HTTPS

HTTPS 暗号化の原理

HTTPS の特徴

SSL/TLS

HTTPS の安全確保の仕組み

盗聴防止(暗号化通信)

改ざん防止

なりすまし防止

HTTPS のセキュリティ動作方式

HTTPS 交換

HTTPS のサーバー証明書

サーバー証明書に含まれる主なフィールド

参考

HTTP 2.0

HTTP 2.0

SPDY(スピーディー)

主な特徴

Packet Capsulation - パケットカプセル化

Request Multiplexing - 並列リクエスト

Header Compression - ヘッダー圧縮

Binary Protocol - バイナリプロトコル

Server Push - サーバープッシュ

Stream Prioritization - ストリーム優先順位

参照

CORS

概要

CORS とは？

Origin(オリジン)とは？

同一 Origin の例

異なる Origin の例

なぜ CORS が必要なのか？

CORS はどのように動作するか

CORS preflight リクエスト

Request Header 一覧

Response Header 一覧