HTTP基礎
HTTP
HTTP（Hypertext Transfer Protocol）は、インターネット・WEB(World Wide Web ) で使用されるハイパーテキストを転送する最も一般的なアプリケーションプロトコル
主な特徴
- リクエスト／レスポンスモデル: クライアント（Webブラウザなど）がHTTPリクエストをサーバーに送信し、サーバーが要求されたコンテンツとHTTPステータスコードで応答する
- ステートレス: 各リクエストは独立しており、以前のやり取りに関する情報は保持されない
- メッセージベース: サーバーとブラウザ間の通信方法をメッセージベースで行う
HTTPの流れ
- ブラウザのアドレスボックスにURL（例：http://www.nowhere123.com/index.html ）を入力
- ブラウザはプロトコルに従ってURLをHTTPリクエストに変換
- HTTPリクエストを目的のサーバーに送信
- HTTPリクエストがサーバーに到達し、サーバーはいずれかのアクションを実行し適切なHTTPレスポンスを返す
- 要求を解釈し、要求されたファイルをクライアントに返す
- リクエストを解釈し、プログラムを実行し、プログラムの出力をクライアントに返す
- 要求を満たすことができないため、サーバーはエラーメッセージを返す
URL・URI・TCP/IP
URL
URL (Uniform Resource Locator) は、Web上のリソースを一意に識別するために使用されるとしてRFC 2396 で定義されている
構文は次のとおりで4つの部分がある
プロトコル : // ホスト名 : ポート番号 / パスとファイル名
例を http://www.nowhere123.com/docs/index.html とすると
-
プロトコル
クライアントとサーバーが使用するアプリケーションプロトコルを指定 (例: HTTP、HTTPS、FTP、telnet)
例でのプロトコルはHTTPを使用 -
ホスト名
サーバーのDNSドメイン名 (例:www.nowhere123.com) または IP アドレス (例: 192.128.1.2)
例でのホスト名は www.nowhere123.com -
ポート番号
サーバーがクライアントからの受信要求をリッスンしているTCP ポート番号
例ではポート番号はURLで指定されていないため、デフォルトのポート番号（HTTP の場合は TCP ポート 80 ）を使用 -
パスとファイル名
サーバーディレクトリ下の、ドキュメントベースの要求されたリソースの名前と場所
例でのリソースのパスとファイル名は "/docs/index.html"
URL の他の例は次のとおり
ftp://www.ftp.org/docs/test.txtmailto:user@test101.comnews:soc.culture.Singaporetelnet://www.nowhere123.com/
エンコードURL
URLには、空白や'~'などの特殊文字をそのまま含めることはできないため
特殊文字は%xxのような、%とASCII16進数で表したバイト列xxを組み合わせた形式で安全にエンコードされる
例えば、'~'は%7e、'+'は%2bとして、空白は%20または'+'としてエンコードされる
URI
URI（Uniform Resource Identifier）は、URLよりも広い概念であり、Web上にある、あらゆるファイルを認識するための識別子の総称としてRFC3986で定義されている
URI構文は次の例を用いて説明する
http://host:port/path?request-parameters#nameAnchor
- URL構造
プロトコル : // ホスト名 : ポート番号 / パスとファイル名
例では http://host:port/path - リクエストパラメータ
名前=値のペアの形式で、URLと'?'で区切られ、名前=値のペアは'&'で区切られる
例では ?request-parameters - フラグメント
アンカーとも呼ばれ、部分や代替表現を指定しておりhttpでは、サーバーから送られた情報を処理する
例では #nameAnchor
TCP/IP 経由の HTTP
TCP/IP (Transmission Control Protocol/Internet Protocol) は、トランスポート層およびネットワーク層プロトコルのセットであり、HTTPは基本的に利用します
動作はマシン間の接続を確立するプロトコル(TCP)とネットワークのアドレス指定とルーティングプロトコル(IP)を組み合わせたネットワークを介して相互に通信する仕組みです
TCP/IP 経由で通信するには、(a) IP アドレスまたはホスト名、(b) ポート番号を知る必要があることは気に留める必要がある
TCPはIPマシン内でアプリケーションを多重化することができ、各IPマシンに対してTCPはポート番号0から65535まで、最大65536個のポート（またはソケット）をサポートできる
TCPポート80はHTTPのデフォルトのHTTPポート番号としてあらかじめ割り当てられているが、テストサーバーなどで、ユーザーが割り当てた他のポート番号（1024～65535）（例えば8000、8080など）でHTTPサーバーを実行することもある
HTTP リクエスト
ウェブクライアントが取得したいデータをインターネットサーバーにリクエストするためのもの
インターネット上で送信される各HTTPリクエストには、様々な種類の情報を含んだ一連のエンコードされたデータが含まれています
典型的なHTTPリクエストには以下のものが含まれます
- リクエストライン
- HTTPメソッド
- HTTPバージョンタイプ
- URL
- HTTPリクエストヘッダー
- HTTPリクエストボディ
GET /docs/index.html HTTP/1.1
Host: www.nowhere123.com
Accept: image/gif, image/jpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
name=John&Doe
リクエストライン
ヘッダーの最初の行はリクエストラインと呼ばれ、その後にリクエストヘッダーなどが続く
リクエスト ラインの構文は次のとおり
request-method-name request-URI HTTP-version
例では GET /docs/index.html HTTP/1.1
- request-method-name
GET、POST、HEAD、OPTIONSといった一連のリクエストメソッドを定義されており
メソッドのいずれかを使用してサーバーにリクエストを送信
例ではGETメソッドを利用 - request-URI
要求されたリソースを指定
例では/docs/index.html - HTTP バージョン
現在、HTTP/1.0 と HTTP/1.1やHTTP/2 などいくつかのバージョンが使用される
例ではHTTP/1.1を使用
HTTPリクエストメソッド
HTTPプロトコルは、一連のリクエストメソッドを定義している
クライアントはリクエストメソッドのいずれかを使用して、HTTPサーバーにリクエストメッセージを送信できる
最も一般的なHTTPメソッドには「GET」と「POST」の2つがある
「GET」リクエストは情報（通常はウェブサイトの形式）の返答を期待し、「POST」リクエストは通常、クライアントがウェブサーバーに情報（フォーム情報、例えばユーザー名とパスワードなど）を送信することが多い
メソッドの種類は以下のとおり
-
GET
クライアントは GET 要求を使用して、サーバーから Web リソースを取得 -
POST
Web サーバーにデータを投稿するために使用される - HEAD
GETリクエストで取得されるはずのヘッダーを取得できる
ヘッダーにはデータの最終更新日が含まれているため、ローカルキャッシュコピーと照合するために使用 - PUT
サーバーにデータの保存を依頼 - DELETE
サーバーにデータの削除を依頼 - TRACE
サーバーに実行したアクションの診断トレースを返すように要求 - CONNECT
プロキシに別のホストへの接続を確立し、解析やキャッシュを行なわずにコンテンツを返信するよう指示するために使用
プロキシ経由でSSL接続を確立する際によく使用される
「GET」リクエストメソッド
最も一般的なHTTPリクエストメソッドで、HTTPサーバーからリソースを要求または取得する
GETリクエストの構文は以下のとおり
GET request-URI HTTP-version
(optional request headers)
(optional request body)
- GETは大文字と小文字が区別されるため、大文字で入力する必要がある
- GETリクエストメッセージには、クエリ文字列 (後述) を含むオプションのリクエストボディがある
「POST」リクエストメソッド
POSTリクエストメソッドは、サーバーに追加データを投稿するために使用される
（例：HTMLフォームデータの送信、ファイルのアップロード）
POST リクエストの構文は次のとおり
POST request-URI HTTP-version
Content-Type: application/x-www-form-urlencoded
Content-Length: length
(request body)
- POSTリクエストをトリガーするには、HTMLフォームを使用するか、独自のネットワークプログラムを作成する必要がある
- 送信したいデータはURLエンコードされたクエリ文字列でなく、リクエストボディで送信される点が異なる
リクエストヘッダー
ヘッダーには、キーと値のペアで保存されたテキスト情報が含まれており、すべてのHTTPリクエスト（およびレスポンス）に含まれている
クライアントが使用しているブラウザや要求されているデータといったコア情報を伝達する
ヘッダー名の構文は、先頭が大文字の単語をダッシュ( -)で連結（例：Content-Length, If-Modified-Since）
HTTPリクエストヘッダーの例:
Request header (リクエストヘッダー) - MDN Web Docs 用語集 | MDN
GET /home.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/testpage.html
Connection: keep-alive
Upgrade-Insecure-Requests: 1
If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT
If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"
Cache-Control: max-age=0
リクエストヘッダーの種類
Host
Host: domain-name
リクエストが送信される先のサーバーのホスト名とポート番号を指定
Accept
Accept: mime-type-1, mime-type-2, ...
クライアントが理解できるコンテンツタイプを MIME タイプで伝える
Accept-Language
Accept-Language: language-1, language-2, ...
サーバーに処理可能な言語または優先する言語を伝える
複数のバージョン（例：英語、中国語、フランス語）を持っている場合、このヘッダーをチェックしてどのバージョンを返すかを決定
Accept-Charset
Accept-Charset: Charset-1, Charset-2, ...
処理可能な文字セットまたは優先する文字セットを伝える
文字セットの例としては、ISO-8859-1、ISO-8859-2、ISO-8859-5、BIG5、UCS2、UCS4、UTF8など
Accept-Encoding
Accept-Encoding: encoding-method-1, encoding-method-2, ...
クライアントが理解することができるコンテンツのエンコーディング（ふつうは圧縮アルゴリズム）を示す
Content-Encoding レスポンスヘッダーを使用してクライアントに選択結果を知らせる
Connection
Connection: Close か Keep-Alive
サーバーに、リクエスト後に接続を閉じるか、別のリクエストのために接続を維持するかを指示
Referer
Referer: referer-URL
リクエストのリファラーを示す
Webページ1からリンクをクリックしてWebページ2にアクセスした場合、Webページ1がWebページ2へのリクエストのリファラーとなる
このヘッダーは信頼性が低く、簡単に偽装される可能性があります。Referrerが「Referer」と誤って表記されていることに注意
あれ？スペルミス？ Referer ヘッダーの歴史を紹介
User-Agent
User-Agent: browser-type
リクエストに使用されたブラウザの種類を識別
サーバーはこの情報を使用して、ブラウザの種類に応じて異なるドキュメントを返す
Content-Length
Content-Length: number-of-bytes
POST リクエストによって使用され、リクエスト本体の長さをサーバーに通知
Content-Type
Content-Type: mime-type
POST リクエストによって使用され、リクエスト本体のメディアタイプをサーバーに通知
Cache-Control
Cache-Control: no-cache|...
プロキシサーバーでページをキャッシュする方法を指定
no-cacheは、ローカルにキャッシュされたコピーが利用可能であっても、プロキシが元のサーバーから新しいコピーを取得することを要求
Authorization
Authorization: <認証タイプ> <認証情報>
保護されたリソースにアクセスするために、クライアントが資格情報（ユーザー名/パスワード）を提供するために使用
APIセキュリティの要：HTTP Authorizationヘッダーの使い方
Cookie
Cookie: cookie-name-1=cookie-value-1, cookie-name-2=cookie-value-2, ...
クライアントはこのヘッダーを使用して、サーバーが状態管理のために設定したCookieを返す
HTTP リクエストボディ
リクエストボディは、リクエストが転送する情報の「本体」を含む部分。ユーザー名やパスワード、フォームに入力されたその他のデータなど、Webサーバーに送信されるあらゆる情報が含まれる
HTTP レスポンス
ウェブクライアント（多くの場合ブラウザ）がHTTPリクエストに対する応答としてインターネットサーバーから受け取るもの
一般的な HTTP レスポンスには以下が含まれます。
- ステータスライン
- HTTPバージョン
- HTTPステータスコード
- HTTPステータスコードテキスト
- HTTPレスポンスヘッダー
- HTTPレスポンスボディ
HTTP/1.1 200 OK
Date: Sun, 18 Oct 2009 08:56:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Sat, 20 Nov 2004 07:16:26 GMT
ETag: "10000000565a5-2c-3e94b66c2e680"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/html
X-Pad: avoid browser bug
<html><body><h1>It works!</h1></body></html>
ステータスライン
最初の行はステータス ラインと呼ばれ、その後にオプションの応答ヘッダーが続く
ステータス ラインの構文は次のとおりです。
HTTP-version status-code reason-phrase
例では HTTP/1.1 200 OK
- HTTP-version
HTTPバージョン: このセッションで使用されるHTTPバージョン
例では HTTP/1.1 - status-code
リクエストの結果を反映するためにサーバーによって生成される 3 桁の数字
例では 200 - reason-phrase
ステータス コードの簡単な説明を示す
例ではOKです
HTTP ステータスコード
HTTPリクエストが正常に完了したかどうかなどの要求の結果を示すためにサーバーによって生成される3桁のコードです
ステータスコードは以下の5つのブロックに分かれており
「xx」は00から99までの異なる数字を表す
- 1xx (情報): 要求を受信しました。サーバーはプロセスを続行
- 2xx (成功): リクエストは正常に受信され、理解され、受け入れられ、処理された
- 3xx (リダイレクト): 要求を完了するには、さらにアクションを実行する必要がある
- 4xx (クライアントエラー): 要求に不正な構文が含まれているか、理解できません
- 5xx (サーバーエラー): サーバーは明らかに有効な要求を処理できなかった
数字「2」で始まるステータスコードは成功を示している
例えば、クライアントがウェブページをリクエストした後、最もよく見られるレスポンスのステータスコードは「200 OK」で、リクエストが正常に完了したことを示す
レスポンスが「4」または「5」で始まる場合、エラーが発生し、ウェブページは表示されない
「4」で始まるステータスコードは、クライアント側のエラーを示す
「5」で始まるステータスコードは、サーバー側で何らかの問題が発生したことを意味する
ステータスコードの種類
- 100 Continue
- 続行: サーバーは要求を受信し、応答を送信中
- 200 OK
- OK: リクエストが完了
- 301 Moved Permanently
- 恒久的移動: 要求されたリソースは新しい場所に恒久的に移動
- クライアントは新しい場所への新しいリクエストを発行する必要があり
- アプリケーションは、この新しい場所へのすべての参照を更新する必要がある
- 302 Found
- 発見＆リダイレクト（または一時移動）: 301と同じですが、新しい場所は一時的なもの
- クライアントは新しいリクエストを発行する必要があり
- アプリケーションは参照を更新する必要はなし
- 400 Bad Request
- 不正なリクエスト: サーバーがリクエストを解釈または理解できなかった
- リクエスト メッセージに構文エラーがある可能性
- 401 Unauthorized
- 認証が必要です: 要求されたリソースは保護されており、クライアントの認証情報（ユーザー名/パスワード）が必要
- クライアントは認証情報（ユーザー名/パスワード）を指定してリクエストを再送信する必要がある
- 403 Forbidden
- 禁止: クライアントの ID に関係なく、サーバーはリソースの提供を拒否
- 404 Not Found
- 見つかりません: 要求されたリソースがサーバー内に見つからない
- 405 Method Not Allowed
- メソッドが許可されていません: 使用されたリクエストメソッド（例：POST、PUT、DELETE）は有効なメソッド
- サーバーは要求されたリソースに対してそのメソッドを許可していません。
- 408 Request Timeout
- リクエストタイムアウト:
- 500 Internal Server Error
- 内部サーバー エラー: サーバーが混乱しています
- 要求に応答するサーバー側プログラムのエラーによって発生することがある
- 502 Bad Gateway
- Bad Gateway: プロキシまたはゲートウェイが、アップストリームサーバーから不正な応答を受信したことを示す
- 503 Service Unavailable
- サービスは利用できません: サーバーが過負荷またはメンテナンスのため応答できない
- クライアントはしばらくしてから再試行する
- 504 Gateway Timeout
- ゲートウェイ タイムアウト: プロキシまたはゲートウェイは、アップストリーム サーバーからタイムアウトを受信したことを示す
HTTP レスポンスヘッダー
レスポンス本文で送信されるデータの言語や形式などの重要な情報を伝達するヘッダーが付属
ヘッダー名の構文は、先頭が大文字の単語をダッシュ( -)で連結（例：Content-Length, If-Modified-Since）
HTTPレスポンスヘッダーの例
Response header (レスポンスヘッダー) - MDN Web Docs 用語集 | MDN
200 OK
Access-Control-Allow-Origin: *
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Mon, 18 Jul 2016 16:06:00 GMT
Etag: "c561c68d0ba92bbeb8b0f612a9199f722e3a621a"
Keep-Alive: timeout=5, max=997
Last-Modified: Mon, 18 Jul 2016 02:36:04 GMT
Server: Apache
Set-Cookie: mykey=myvalue; expires=Mon, 17-Jul-2017 16:06:00 GMT; Max-Age=31449600; Path=/; secure
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
X-Backend-Server: developer2.webapp.scl3.mozilla.com
X-Cache-Info: not cacheable; meta data too large
X-kuma-revision: 1085259
x-frame-options: DENY
HTTP レスポンス本文
GETリクエストに対する成功したHTTPレスポンスには通常、要求された情報を含むボディが含まれる
Webリクエストでは、WebブラウザがWebページに変換するHTMLデータが多い
HTTPS
参考動画 SSL, TLS, HTTPS Explained - YouTube
参考資料 【図解で解説】HTTP、HTTPS、SSL、TLSについて詳しく解説します
HTTP: ブラウザとサーバー間の通信がプレーンテキストで行われる
HTTPS: TLS（Transport Layer Security）を使用して暗号化された形式でデータを送信
SSL（Secure Sockets Layer）は、インターネット通信にセキュリティを提供するために使用される暗号化プロトコル
TLS（Transport Layer Security）もSSLと同様でインターネット通信にセキュリティを提供するために使用される暗号化プロトコルで、いわばSSLの進化系
TLSハンドシェイク
- TCP HandShake (TCP接続の確立)
HTTPの場合と同様に、ブラウザはサーバーとのTCP接続を確立 - Certificate Check （証明書のチェック）
- Client Hello
クライアントは、サーバーにTLS通信を開始するリクエストを送る- クライアントがサポートするTLSバージョン
- 暗号スイート（使用可能な暗号アルゴリズムのリスト）
- Server Hello
サーバーはクライアントのリクエストに応答し、情報を送る- サーバーが選択したTLSバージョン
- サーバーが選択した暗号スイート
- Certificate
サーバーは自分のデジタル証明書をクライアントに送る- サーバーの公開鍵（上記画像の水色の鍵アイコン）
- サーバーの識別情報（ドメイン名、会社情報など）
- 認証局（CA）による署名
- Certificate Check
クライアントは受け取った証明書の検証を行う- 証明書が信頼された認証局（CA）によって署名されているかを確認
- サーバー証明書が中間証明書を経由して、信頼できるルートCAに連なるかどうかをチェック
- 証明書の対象ドメイン名が、実際にアクセスしているサーバーのドメイン名と一致するかを確認
- Client Hello
- Key Exchange （鍵交換）
- Client Key Exchange
クライアントがセッション鍵を作成し、サーバーの公開鍵を使って暗号化してサーバーに送信
セッション鍵は対象暗号（AESなど）で使用されるキー
RSA方式: 最も理解しやすい鍵交換方式の例 - Change Cipher Spec
サーバーの秘密鍵で復号してセッション鍵を利用できるして、クライアントに通知
鍵交換後の通信は新しいセッションキーによって暗号化されることを通知 - Finished
クライアントとサーバーの双方がハンドシェイクプロセス全体が正常に完了したことを確認するためにサーバーが「Finished」メッセージを送信
- Client Key Exchange
- Data Transmission （データ送信）
セッション鍵を使用して、双方向の安全な暗号化通信を開始- クライアントはセッション鍵を使用してデータを暗号化し、サーバーに送信
- サーバーは受け取った暗号化データをセッション鍵で複合し、データを解釈
- 改ざんチェックでハッシュ値を用いられる
HTTPバージョンの歴史と進化
参考動画 HTTP/1からHTTP/2、そしてHTTP/3へ - YouTube
参考資料 HTTP の進化 - HTTP | MDN
HTTP/0.9 – ワンラインプロトコル
- リクエストは使用可能なメソッド GET で、リソースへのパスが後に続く1行で構成
- HTTP ヘッダーがなく、HTML ファイルだけが転送可能
- ステータスやエラーのコードもなし
リクエスト
GET /my-page.html
レスポンス
<html> テキストのみのウェブページ </html>
HTTP/1.0 – 拡張性を築く（1996年）
- バージョン情報は各リクエストの中で送信
- ステータスコード行もレスポンスの始めに送られる
- リクエストとレスポンスの両方に、HTTP ヘッダーの概念が導入
- 接続方式: 同じサーバーへの各リクエストに対して個別のTCP接続が必要
リクエスト
GET /my-page.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
レスポンス
HTTP/1.0 200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
<IMG SRC="/my-image.gif">
</HTML>
HTTP/1.1 – 標準化されたプロトコル（1997年）
- Keep-Alive機能: 接続を再利用して複数のリクエストを処理可能
- パイプライン: リクエストに対する回答が完全に送信される前に、2つ目のリクエストを送信できるので、通信の待ち時間を短縮
- 遅延の削減: 毎回のTCPハンドシェイクが不要になり、リクエスト遅延を削減
リクエスト
GET /en-US/docs/ HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:141.0) Gecko/20100101 Firefox/141.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
レスポンス
HTTP/1.1 200 OK
accept-ranges: none
content-encoding: br
date: Tue, 01 Jul 2025 08:32:50 GMT
expires: Tue, 01 Jul 2025 09:26:50 GMT
cache-control: public, max-age=3600
age: 1926
last-modified: Sat, 28 Jun 2025 00:47:12 GMT
etag: W/"b55394ed2f274eea5d528cf6c91e1dcf"
content-type: text/html
vary: Accept-Encoding
content-length: 26178
[26178 バイトの HTML]
リクエスト
GET /static/css/main.9e7d1ce5.css HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:141.0) Gecko/20100101 Firefox/141.0
Accept: text/css,*/*;q=0.1
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
レスポンス
HTTP/1.1 200 OK
content-encoding: br
content-length: 43694
date: Mon, 30 Jun 2025 21:13:12 GMT
expires: Mon, 30 Jun 2025 21:47:29 GMT
cache-control: public, max-age=31536000
age: 42704
last-modified: Mon, 30 Jun 2025 00:33:45 GMT
etag: W/"d4f4d0955482844ad842986a9bcb7e8a"
content-type: text/css
vary: Accept-Encoding
[43694 バイトの CSS]
リクエスト
GET /static/js/main.a918a4e7.js HTTP/1.1
Host: developer.mozilla.org
HTTP/2 – 高パフォーマンスなプロトコル（2015年）
主な機能
- HTTPストリーム: 単一のTCP接続で複数のリクエストストリームを送信可能
- 独立性: 各ストリームは独立しており、送信・受信順序に依存しない
- アプリケーション層での改善: Head-of-Line Blocking問題をアプリケーション層で解決
- サーバープッシュ: 新しいデータが利用可能になった際、クライアントのポーリングなしでサーバーからクライアントに更新を送信可能
HTTP/3 - HTTP over QUIC（2022年6月標準化）
- QUICプロトコル: TCPの代わりにQUICを基盤トランスポートプロトコルとして使用
- UDP基盤: QUICはUDPをベースとして構築
- ファーストクラスストリーム: トランスポート層でストリームを第一級市民として導入
- 共有接続: QUICストリームは同じQUIC接続を共有し、新しいストリーム作成に追加のハンドシェイクが不要
- 独立配信: パケットロスが1つのストリームに影響しても、他のストリームには影響しない
参考資料
公式ドキュメント・標準
技術解説・チュートリアル
ヘッダー・認証関連
- Request header (リクエストヘッダー) | MDN
- Response header (レスポンスヘッダー) | MDN
- Bearer認証について #Web - Qiita
- APIセキュリティの要：HTTP Authorizationヘッダーの使い方
- あれ？スペルミス？ Referer ヘッダーの歴史を紹介
Discussion