← 研修トップ
Webを支えるソフトウェア
リクエストがアプリに届くまでに、途中のソフトウェアは何を見て何を決めているのか。取り次ぎ・配り分け・暗号の終端・キャッシュ・検査を、設定ファイルの1行が読める粒度まで降りて扱います。
- 1約 8 分リクエストは何段の手を経るのか — 全体地図ブラウザからアプリまでの間には、いくつもの中継役がいます。各段は自分の担当する情報だけを見て次へ渡し、その内側には踏み込みません。第2期で見た層の構造が、そのまま装置の並びとして現れます。
- 2約 9 分リバースプロキシ — なぜ自分で返さず取り次ぐのか取り次ぎ役を1段挟むと、外から見える窓口と、実際に処理する実体とを切り離せます。窓口の側で受け口の規則を決められるので、実体を触らずに配置や経路を変えられます。
- 3約 7 分負荷分散の選び方 — どの実体へ配るかHTTPやTLSのRFCは負荷分散方式を規定していません(ほかの標準文書までは確かめていません)。名称も挙動もベンダ実装依存です。
- 4約 7 分死活監視 — 壊れた実体を外す仕組み無償版 nginx の死活監視は in-band(パッシブ)のみで、実リクエストの失敗を数えます。定期的に監視要求を送るアクティブ監視は商用版の機能です。
- 5約 7 分Nginx設定を読む — locationはどれが選ばれるか最長一致した prefix は勝者ではなく「記憶」されるだけの暫定候補です。後から検査される正規表現が一致すれば逆転されます。
- 6約 6 分Nginx設定を書く — proxy_pass とスラッシュ`proxy_pass` の行末にスラッシュを付けるかどうかで、上流に渡るパスが変わります。URIを伴えば location に一致した部分が置換され、伴わなければリクエストURIがそのまま渡ります。
- 7約 8 分TLS終端 — どこで暗号を解くのかTLSを終端した場所が、TLSのエンドポイントです。RFC 8446 が保証するのはその区間までで、内側をどう守るかはRFCの外側の設計判断です。
- 8約 9 分証明書は誰が更新するのか — ACMEと期限証明書の有効期間の上限を決めているのはRFCではなく、CA/Browser Forum という業界団体の Baseline Requirements です。そしてその上限は2026年3月に大幅に短縮されました。
- 9約 9 分キャッシュはどこに効くのか — 鍵と鮮度「速い層に置いて、古くなったら捨てる」——この素朴な一言には、実は**3つの別々の概念**が混ざっています。時間で古くなる**失効**、不安全なメソッドが引き金の**無効化**、容量で押し出される**追い出し**です。
- 10約 9 分送りすぎを止める — レート制限の原理レート制限は「**持続レート**」と「**短期のバースト許容**」の2つの数で表せます。この形はトークンバケットの `rT+b` とも、TCPの輻輳ウィンドウとも同じです。
- 11約 9 分WAFは何を見ているのか — 加算・合算・比較の3段階WAFのルールは一致してもその場で遮断せず、スコアに加算するだけです。判定は全ルールの実行後にまとめて行われます。
- 12約 9 分WAFの誤検知 — なぜ正しい通信が止まるのかCRSは相手のアプリを知らないまま汎用のパターンで検出するため、正常な通信が攻撃に見えることが構造的に避けられません。これを誤検知(false positive)と呼びます。
- 13約 9 分無停止で入れ替える — そして期末の切り分け設定の反映は「再起動」ではありません。**入れ替え**です。古いワーカーは処理中の接続を捌き切ってから終わるので、その間は新旧が同居します。