HTTP とブラウザ

HTTP は、ブラウザ（クライアント）がサーバーにリクエストを送り、サーバーがレスポンスを返すやりとりの決まりです。リクエストは「メソッド・URL・ヘッダー・本文」、レスポンスは「ステータスコード・ヘッダー・本文」でできています。

GET /api/users/42 HTTP/1.1
Host: example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{"id":42,"name":"Sato"}

HTTP/1.1 はこのとおりテキストで送り、HTTP/2・3 は同じ意味の内容をバイナリのフレームにして送ります。どの版でも「メソッド・URL・ヘッダー・本文」と「ステータス・ヘッダー・本文」という形は同じなので、まずこの形を読めるようにします。開発者ツールの Network タブで、実際のリクエストとレスポンスのヘッダーを見るのが一番の練習です。

HTTP キャッシュ

安全＝サーバーの状態を変えない、冪等（べきとう）＝何回送っても結果が同じ、という意味です。リトライしてよいかの判断に使います。

GET で削除や更新をしてはいけません。リンクの先読みやクローラーが勝手に GET を送るからです。

PUT は「この内容で丸ごと置き換える」ので、何回送っても同じ状態になります。PATCH は「1 増やす」のような書き方にすると冪等ではなくなります。

冪等性とリトライ

4xx は「クライアントが直す」、5xx は「サーバーが直す」です。エラーなのに 200 を返すと、監視やリトライの判断ができなくなります。

迷いやすいのは 401 と 403（ログインしていない／権限がない）と、400 と 422（形式が壊れている／中身が不正）です。チームで使い分けを決めて API 全体でそろえます。

ヘッダーは、本文とは別に付ける「付け札」です。役割ごとに覚えると整理しやすくなります。

押さえる要点

• Content-Type：本文の形式（application/json など）。Accept：欲しい形式。
• Authorization：認証情報（Bearer トークン）。Cookie / Set-Cookie：セッション。
• Cache-Control・ETag・If-None-Match：キャッシュ。
• Location：リダイレクト先・作成したリソースの URL。
• Origin・Access-Control-Allow-Origin：CORS。

独自のヘッダーは X- を付けない名前が今は推奨されていますが、既存の X-Request-Id などはそのまま使われています。

Web ページの表示の速さは、サーバーの処理だけでなく、HTML・CSS・JavaScript・画像といった何十ものファイルをどう運ぶかでも大きく変わります。HTTP の版の違いは、その運び方の違いです。

フロントエンドの性能改善で「昔の工夫（ドメインの分割・ファイルの結合）がまだ要るか」を判断するときや、面接の「HTTP/2 と HTTP/3 の違い」に答えるときに使います。

HTTP には大きく3つの版があり、中身（メソッド・ヘッダー・ステータス）の意味は同じで、運び方が違います。

HTTP/1.1 の時代は、同時に取れるファイル数が少なかったので、ドメインを分けて接続数を増やしたり、画像を1枚に結合（CSS スプライト）したり、JS を1ファイルにまとめたりしました。HTTP/2 以降は1本の接続で多数のファイルを同時に取れるので、これらは不要になり、むしろドメインを分けると DNS・TLS のやり直しで遅くなります。今は CDN やロードバランサーで HTTP/2・HTTP/3 を有効にしておくのが普通です。

下の「ブラウザで試す」の図では、同じ画像6枚を読み込むときに、HTTP/1.1 が1本の接続で1つずつ送る様子、HTTP/2 が1本の TCP 接続の中で多重化する様子、パケットが1つ失われると全部のストリームが待たされる様子（TCP の HOL ブロッキング）、HTTP/3 が QUIC でストリームごとに独立して進む様子を、順に見られます。表の「パケットが失われたとき」の行を、3つ目と5つ目の手順で確かめてください。ブラウザが Alt-Svc ヘッダーで HTTP/3 が使えると知ってから QUIC でつなぎ直す点にも注目します。

「デプロイしたのに古い画面のまま」「他人のマイページが表示された」は、どちらも HTTP キャッシュの指定が原因になりうる障害です。キャッシュは、うまく使えば表示を速くし、サーバーの負荷と転送の料金を減らしますが、指定を間違えると古い内容や他人の内容を配ってしまいます。

レスポンスごとに「どこに・どれだけの間保存してよいか」を決めるのは、サーバーを書く Web エンジニアです。

HTTP キャッシュは、一度取ったレスポンスをブラウザや CDN にとっておき、次は通信せずに（または軽い確認だけで）使う仕組みです。どう扱うかはサーバーが Cache-Control ヘッダーで指示します。

期限が切れたあとの確認の仕組み（ETag と 304）と、長期キャッシュを安全にするファイル名の付け方は、次のトピックで説明します。

よくある失敗：ログイン中のユーザー向けのページに public を付けて CDN に保存され、他人に表示される事故があります。ユーザーごとに変わる内容は private か no-store にします。

SRE の「キャッシュ（HTTPキャッシュと多層キャッシュ）」

下の「ブラウザで試す」の図では、ハッシュ付きの名前の画像を CDN が S3 から取ってきて保存し、ブラウザも同じ Cache-Control に従って保存する様子、期限内はブラウザが通信せずにキャッシュを使う様子、ハッシュの付かないファイルを ETag で確かめて 304 が返る様子を、順に見られます。後半の「キャッシュしない応答」は、上の「よくある失敗」を private, no-store でどう防ぐかの手順です。

304 と ETag

サーバーは中身の版を表す ETag（または Last-Modified）を返します。期限が切れたブラウザは If-None-Match: "その値" を付けて確認し、変わっていなければサーバーは本文なしの 304 Not Modified を返します。通信量が減ります。

ファイル名にハッシュを付けて長期キャッシュ

ビルドツールは app.3f9a1c.js のように、中身から作ったハッシュをファイル名に付けます。中身が変わると名前も変わるので、古いキャッシュを気にせず長く保存させられます。入口の HTML は短く（または毎回確認）します。

# JS・CSS・画像（ハッシュ付き）
Cache-Control: public, max-age=31536000, immutable
# HTML
Cache-Control: no-cache
# ログイン後の API
Cache-Control: private, no-store

この2つを組み合わせると、「ハッシュ付きの JS・CSS は1年キャッシュ」「HTML は毎回 ETag で確認」となり、デプロイ直後でも新しい HTML が新しいファイル名を指すので、古い画面が残りません。

HTTP は1回ごとのやりとりで、前のリクエストを覚えていません。ログイン状態を保つため、サーバーは Cookie にセッション ID を入れてブラウザに預け、ブラウザは同じサイトへのリクエストに毎回付けて送ります。

セッション ID の流れ

• ログインに成功したら、サーバーは推測できない乱数のセッション ID を作り、ユーザー ID と結びつけて DB や Redis に保存する。
• Set-Cookie: sid=ランダムな値; HttpOnly; Secure; SameSite=Lax; Path=/ を返す。
• 以降のリクエストには Cookie: sid=… が付くので、サーバーは保存先を引いてユーザーを特定する。
• ログアウトしたらサーバー側のセッションを消す（Cookie を消すだけでは足りない）。

ログインした直後はセッション ID を作り直します。ログイン前の ID をそのまま使うと、攻撃者が仕込んだ ID でログインさせられる「セッション固定攻撃」が起こります。

CSRF 対策：Cookie は自動で送られるので、罠サイトからのリクエストにもログイン状態が付いてしまいます。SameSite=Lax 以上にすると多くを防げますが、それだけに頼らず、更新系のリクエストには CSRF トークンや Origin ヘッダーの確認を組み合わせます。

CSRF

オリジンは「スキーム＋ホスト＋ポート」の組です（https://app.example.com:443）。ブラウザは同一オリジンポリシーにより、JavaScript が別オリジンのレスポンスを読むことを止めます。他サイトの JS があなたのログイン状態で API を読めたら困るからです。CORS は、サーバーが「このオリジンからなら読んでよい」とヘッダーで許可する仕組みです。

単純なリクエストとプリフライト

• 単純なリクエスト：GET・HEAD・POST で、Content-Type が application/x-www-form-urlencoded・multipart/form-data・text/plain のどれか、独自ヘッダーなし。ブラウザはそのまま送り、レスポンスの Access-Control-Allow-Origin を見て JS に渡すか決めます。
• プリフライト：それ以外（application/json の POST、Authorization ヘッダー付き、PUT・DELETE など）。本番の前に OPTIONS で「送ってよいか」を聞きます。

OPTIONS /api/orders
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, authorization

204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: content-type, authorization
Access-Control-Max-Age: 600

Cookie を送る場合は、クライアント側で credentials: 'include'、サーバー側で Access-Control-Allow-Credentials: true が要り、Allow-Origin に * は使えません。許可するオリジンは一覧で決め打ちにし、届いた Origin をそのまま返す書き方はしません。

SRE の「CORSとオリジン」

CORS（オリジン間リソース共有）は、ある画面（例：https://app.example.com）の JavaScript が、別のオリジン（スキーム・ホスト・ポートの組。例：https://api.example.com）の API を呼ぶとき、ブラウザが「サーバーが許可しているか」を確かめる仕組みです。

画面と API のドメインが分かれている構成では、開発中にも本番の障害でも CORS エラーに出会います。エラーの文言だけを見て設定を変えて回ると、本当の原因を見落とします。ここでは、調べる順番を決めておきます。

ブラウザのコンソールに CORS エラーと出ても、原因が CORS 設定とは限りません。サーバーが 500 や 502 を返したとき、そのエラー応答には CORS ヘッダーが付いていないことが多く、ブラウザは「許可がない」と表示します。本当の原因が隠れるのです。

サーバーの応答は curl -i -X OPTIONS -H 'Origin: https://app.example.com' -H 'Access-Control-Request-Method: POST' … で直接確かめられます。

CORS はブラウザの仕組みなので、curl やサーバー同士の通信には関係ありません。API を守る仕組みではない点にも注意します。

下の「ブラウザで試す」の図では、画面の読み込み → プリフライト（OPTIONS）→ サーバーが許可を返す → 本番のリクエスト → レスポンスにも許可ヘッダー、の順に進みます。上の表の「OPTIONS が 401・403」はプリフライトの段階、「200 なのに CORS エラー」はレスポンスの許可ヘッダーの段階で起きている、と対応させて見てください。後者ではサーバーは処理を終えているので、注文などがもう作られていることがある点にも注目します。

ブラウザは HTML を受け取ってから、次の順で画面を作ります。この最初に表示するまでの道のりをクリティカルレンダリングパスと呼びます。

• HTML を読んで DOM（要素の木）を作る。
• CSS を読んで CSSOM（スタイルの木）を作る。
• 2つを合わせて、表示する要素とスタイルを決める。
• レイアウト：それぞれの位置と大きさを計算する。
• ペイント：色や文字を描き、重ね合わせて（合成）画面に出す。

CSS は読み終わるまで描画を止めるので、最初の表示に必要な CSS は小さくします。

リフローとリペイント

• リフロー（レイアウトのやり直し）：幅・高さ・位置が変わると起きる。周りの要素も計算し直すので重い。
• リペイント：色など見た目だけが変わると起きる。リフローより軽い。
• transform と opacity のアニメーションは合成の段階だけで済むので軽い。top・width を動かすより滑らかです。
• JS で「書く→読む」を繰り返す（style を変えた直後に offsetHeight を読む、をループする）と、毎回リフローが起きます。読むのをまとめてから書きます。

JavaScript が描画を止める理由

JS は DOM を書き換えられるので、ブラウザは普通の <script> を見つけると HTML の解析を止め、ダウンロードと実行を待ちます。

面接の定番の質問です。段階を順番に挙げ、それぞれで「何が起きて、どこで遅くなりうるか」を一言ずつ添えると、理解の深さが伝わります。

2回目以降は、DNS のキャッシュ・接続の使い回し（keep-alive）・HTTP キャッシュが効くので、ずっと速くなります。

SRE の「URL入力から表示まで（話す順番）」