Baud
ENJA
プロトコル一覧

HTTP/1.1

Web の言語。読めるテキスト、リクエスト行、ヘッダ、空行。

リクエスト

すべてのバイトが読めるテキストです。16 進の下の ASCII の行で、文字を確認できます。

HTTP/1.1 リクエスト・72 バイトのテキスト01632486447G45E54T20 2F/20 48H54T54T50P2F/3112E.3110DCR0ALF48H6Fo73s74t3A:20 65e78x61a6Dm70p6Cl65e2E.63c6Fo6Dm0DCR0ALF55U73s65e72r2D-41A67g65e6En74t3A:20 63c75u72r6Cl2F/3882E.3440DCR0ALF41A63c63c65e70p74t3A:20 2A*2F/2A*0DCR0ALF0DCR0ALFメソッドスペースターゲッ…スペースバージョン改行Host ヘッダUser-Agent ヘッダAccept ヘッダ空行フィールドをクリックして中身を見る

フレーム全体

リクエスト全体が読める ASCII です。リクエスト行、ヘッダ 3 つ、空行。長さのフィールドはなく、空行が区切りです。

フィールド位置例の値意味
メソッド0–2 バイト目GETリソースに対して何をするか。GET = 取得。ほかに POST（データ送信）、PUT（置き換え）、DELETE、HEAD（ヘッダのみ）など。
スペース3 バイト目0x20リクエスト行の各部分は、半角スペース 1 つ（0x20）で区切ります。
ターゲット4 バイト目/要求するパス（とクエリ）です。'/' はサイトのルート。
スペース5 バイト目0x20もう 1 つの区切り。
バージョン6–13 バイト目HTTP/1.1プロトコルのバージョンを ASCII で書き下したものです。
改行14–15 バイト目0D 0A改行（CR + LF、0D 0A）が各行の終わりです。HTTP/1.1 はテキストのプロトコルで、生の TCP 接続に手で打ち込むこともできます。
Host ヘッダ16–34 バイト目Host: example.com「名前: 値」の行がヘッダです。HTTP/1.1 で必須なのは Host だけで、多数のサイトを置くサーバに、IP アドレスだけでは伝わらない「どのサイトか」を伝えます。
User-Agent ヘッダ35–56 バイト目User-Agent: curl/8.4クライアントソフトを識別します。サーバは統計や、送る内容の判断材料に使います。
Accept ヘッダ57–69 バイト目Accept: */*クライアントが扱えるコンテンツの種類。*/* は何でも可。
空行70–71 バイト目0D 0A空行（CRLF だけ）がヘッダの終わりを示します。GET にボディはないのでここで終わりで、POST ならボディが続きます。

概要

HTTP/1.1 は、1997 年からブラウザとサーバが使ってきたテキスト形式です。リクエストは、リクエスト行（メソッド・パス・バージョン）、ヘッダ、空行、任意のボディ。レスポンスはステータス行から始まる同じ形です。ボディまでは ASCII の平文で、各行は CRLF で終わります。

HTTP/2 と HTTP/3 は符号化（バイナリフレーム、ヘッダ圧縮、QUIC）を変えましたが、メソッド・ステータスコード・ヘッダという考え方は同じです。

基本情報

トランスポート
TCP (80, or 443 with TLS)
符号化
ASCII テキスト、CRLF 区切り
方式
リクエスト / レスポンス
必須ヘッダ
Host
ボディ長
Content-Length or chunked
規格
RFC 9112 / 9110

レスポンス

ステータス行、ヘッダ、空行、そしてちょうど Content-Length バイトのボディ。

HTTP/1.1 レスポンス・78 バイト01632486448H54T54T50P2F/3112E.31120 32230030020 4FO4BK0DCR0ALF43C6Fo6En74t65e6En74t2D-54T79y70p65e3A:20 74t65e78x74t2F/70p6Cl61a69i6En0DCR0ALF43C6Fo6En74t65e6En74t2D-4CL65e6En67g74t68h3A:20 3113330DCR0ALF0DCR0ALF48H65e6Cl6Cl6Fo2C,20 77w6Fo72r6Cl64d21!バージョンスペースステータスコードスペース理由句改行Content-Type ヘッダContent-Length ヘッダ空行ボディフィールドをクリックして中身を見る

フレーム全体

ステータス行、ヘッダ、空行、ボディ。Content-Length が、ボディを何バイト読むかを正確に伝えます。

フィールド位置例の値意味
バージョン0–7 バイト目HTTP/1.1サーバの HTTP バージョン。
スペース8 バイト目0x20区切り。
ステータスコード9–11 バイト目200結果を表す数字。2xx 成功、3xx リダイレクト、4xx クライアント側エラー（404 は見つからない）、5xx サーバ側エラー。
スペース12 バイト目0x20区切り。
理由句13–14 バイト目OKコードの人間向けの説明です。プログラムは無視して、数字のほうを見ます。
改行15–16 バイト目0D 0A改行（CR + LF、0D 0A）が各行の終わりです。HTTP/1.1 はテキストのプロトコルで、生の TCP 接続に手で打ち込むこともできます。
Content-Type ヘッダ17–42 バイト目Content-Type: text/plainボディがどんな種類のデータかを示し、クライアントが解釈の仕方を決められるようにします（text/plain、text/html、application/json、image/png など）。
Content-Length ヘッダ43–62 バイト目Content-Length: 13ボディの長さ（バイト）です。接続が次のリクエストのために開いたままになりうるので、クライアントはこれでボディの終わりを知ります。
空行63–64 バイト目0D 0Aヘッダの終わり。
ボディ65–77 バイト目Hello, world!内容そのもの。ちょうど Content-Length バイトです。

1 つの接続の上のリクエスト

キープアライブは TCP 接続を使い回します。

ブラウザ192.168.1.20:51234Web サーバ203.0.113.50:80GET /Host: example.com200 OKContent-Length: 13GET /logo.pngsame connectionTCP connectedTCP connected

やり取りの全体

HTTP は、信頼できる TCP ストリームの上で、リクエストとレスポンスを順に交わす仕組みです。

  1. 1リクエスト

    確立済みの TCP 接続の中で送られます（その前のハンドシェイクは TCP のページを参照）。

  2. 2レスポンス

    サーバは同じ接続で答えます。HTTP/1.1 のキープアライブでは接続が開いたままなので、次のリクエストはハンドシェイクを省けます。

  3. 3次のリクエスト。ハンドシェイクなし

    接続を使い回すとリクエストごとに 1 往復を節約できます。HTTP/2 と HTTP/3 はさらに進んで、多数のリクエストを同時に交互に流します。

使われる場面

  • あらゆる Web サイトと、ほぼすべての Web API（REST、JSON over HTTP）
  • `curl -v` はまさにこれらの行を出力します。HTTP を見る最短の方法です
  • Webhook、パッケージのダウンロード、ソフトウェア更新

つまずきやすい点

  • CRLF の代わりに LF だけだったり、空行が欠けていたりすると、厳密なサーバは 400 Bad Request を返します。
  • Content-Length はボディの文字数ではなくバイト数に一致する必要があります。マルチバイト文字は素朴な長さの計算を壊します。
  • 平文の HTTP は経路上の誰にでも読めます。HTTPS は同じテキストを TLS で包みます。

出典・規格

  • RFC 9112: HTTP/1.1
  • RFC 9110: HTTP Semantics

関連するプロトコル

TCPDNSMQTT