ネットワーク（TCP/IP・DNS・TLS）

1. DNS名前解決：ブラウザ・OSキャッシュ → リゾルバ → ルート → TLD → 権威DNS。TTLとキャッシュの影響

2. TCP接続：3ウェイハンドシェイク（SYN → SYN/ACK → ACK）

3. TLSハンドシェイク：証明書の検証、鍵交換、TLS 1.3 は 1-RTT

4. HTTPリクエスト：CDN → ロードバランサ（L4 / L7） → Webサーバ → アプリ

5. アプリ処理：認証、キャッシュ参照、DB クエリ

6. レスポンスとレンダリング：HTML解析、追加リソース取得、Keep-Alive / HTTP/2 の多重化

各箱と矢印が「壊れる可能性のある場所」。面接では上から順に、それぞれの障害と調べ方まで話す。

各ステップで「ここが壊れたら何が起きるか、どう調べるか」まで話せると強い。

第6章「Web技術（HTTP・URI・REST）」：URIとHTTPの仕組みを図で詳しく

通信は、役割ごとに「層（レイヤー）」に分けて考えます。OSI参照モデルは7つの層に分けた教科書の型、TCP/IPは実際のインターネットで使われている4つの層の型です。下の層（ケーブルや IP の経路）が動いていなければ、上の層（HTTP など）の設定をいくら直しても通信はできません。

障害の切り分けを「どの層の問題か」で話せると説得力が増します。たとえば「ping は通るのに curl が失敗する」なら、第3層（IP）までは届いているので、第4層より上（ポート・TLS・アプリ）を疑う、というように順に絞り込めます。表では、実務で話題になりにくい第1層（物理）と第5層（セッション）は省いています。

下の「ブラウザで試す」の図では、第4層（トランスポート）の TCP が、SYN・SYN-ACK・ACK の3回のやりとりで接続を作り、データを送って ACK で確かめ、FIN と ACK で切断するまでを順に見られます。SYN_SENT・ESTABLISHED・CLOSE_WAIT・TIME_WAIT のような状態は ss の出力でも ESTAB・TIME-WAIT などの形で見られるので、どの段階の状態が溜まると障害になるかに注目してください。

ポートは0〜65535の番号で、TCPとUDPそれぞれにあります。サーバーのプログラムは決まったポートで待ち受け（listen）し、クライアントは自分の側に一時的な番号（エフェメラルポート）を割り当てて接続します。1本の接続は「送信元IP・送信元ポート・宛先IP・宛先ポート・プロトコル」の5つの組で区別されるので、同じサーバーの443番に何万人もが同時に接続できます。

「どのIPの、どのポートで、誰に向けて待ち受けているか」を ss -tlnp で確認する習慣をつける。

接続の確立に1往復かかるため、接続の再利用（Keep-Alive・接続プール）が効く。

10.0.1.0/24 は、先頭24ビット（10.0.1）が共通のネットワークで、残り8ビットで256個のアドレスを表します。数字が1減るごとにアドレス数は2倍になり、/16なら65,536個です。VPCやサブネットを設計するときは、将来の拡張と、他のVPCやオンプレミスとアドレスが重ならないことを最初に考えます。重なっていると、後からピアリングやVPN接続ができません。

EKSなどPodにVPCのIPを割り当てる構成では、アドレスがすぐ枯渇するので大きめに取る。

IPv4のアドレスは32ビット（約43億個）で、すでに新規の割り当てはほぼ枯渇しています。そのため、社内や家庭ではプライベートアドレス（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）を使い、インターネットに出るときにNATで1つの公開アドレスに変換しています。携帯回線などでは、事業者側でさらにNATをかけるCGNATもあり、多数の利用者が同じIPに見えます。

IPv6は128ビットで事実上無限にあり、端末ごとに世界で一意なアドレスを持てます。NATが不要になる一方、「NATの内側だから外から届かない」という暗黙の守りもなくなるので、ファイアウォールやセキュリティグループで明示的に守ります。

NATがなくなる分、守りは「明示的に閉じる」設計にする。

端末は最初、自分のIPアドレスを知りません。DHCPでは、端末がネットワーク全体に「アドレスをください」と呼びかけ（Discover）、DHCPサーバーが候補を提示し（Offer）、端末が申し込み（Request）、サーバーが確定（Ack）します。頭文字をとってDORAと呼びます。アドレスは期限つきのリースで貸し出され、期限が近づくと更新します。

AWSのVPCでは、DHCPはAWSが自動で提供し、DHCPオプションセットでDNSサーバーやドメイン名を変えられます。オンプレミスのDNSを使いたいときなどに設定します。IPv6では、ルーターの情報から端末が自分でアドレスを作るSLAACもよく使われます。

DHCPのリース切れやアドレスの枯渇は、オフィスやオンプレの「急に繋がらない」の定番原因。

DNSは、example.com のような名前を IP アドレスに変える仕組みです。ほとんどの通信は最初に名前を引くので、DNS が止まったり古い答えが残ったりすると、サーバーが正常でも「サイトにつながらない」障害になります。

名前を引くときに働くのは、問い合わせを代わりに回ってくれるリゾルバ（キャッシュDNS）と、そのドメインの正しい答えを持つ権威DNSサーバーです。リゾルバは答えを TTL（キャッシュしてよい秒数）の間覚えておきます。下の手順は、どこにもキャッシュがないときの流れです。

1. ブラウザのキャッシュ、OSのキャッシュ（/etc/hosts も含む）を確認

2. フルサービスリゾルバ（ISPやVPCのDNS）に問い合わせ

3. リゾルバがルートサーバーに問い合わせ → .com のTLDサーバーを教わる

4. TLDサーバーに問い合わせ → example.com の権威DNSサーバーを教わる

5. 権威DNSサーバーが IP アドレスを返す

6. リゾルバが TTL の間キャッシュし、クライアントに返す

リゾルバのキャッシュがあるので、2回目以降はルートやTLDまで問い合わせない。

下の「ブラウザで試す」の図では、リゾルバがルート → TLD → 権威DNSの順に聞きに行き、ルートとTLDは答えではなく「次に聞く先」（NSレコード）を紹介するだけ、という流れを順に見られます。最後に権威DNSが返す答えに付いた TTL と、2回目の問い合わせではリゾルバがキャッシュから即答してルートやTLDに行かないところに注目してください。

TTLは、そのレコードをキャッシュしてよい秒数です。長いとDNSへの問い合わせが減って安定しますが、変更の反映が遅れます。切り替えの予定があるなら、事前にTTLを短くしておきます。また「存在しない」という応答もキャッシュされる（ネガティブキャッシュ）ので、レコードを作る前に問い合わせてしまうと、しばらく引けないことがあります。

SREとして押さえておきたい落とし穴もあります。Kubernetesでは、Podの設定（ndots:5 と検索ドメイン）により、外部の名前を引くたびに検索ドメインを付けた余計な問い合わせが何度も発生し、DNSの負荷や遅延の原因になることがあります。VPC内の名前解決はVPCのDNS（Route 53 Resolver）が担い、問い合わせ数に上限があるので、アプリ側でのキャッシュも検討します。DNSが止まると全サービスが止まって見えるので、DNSは最も重要な依存先の1つとして扱います。

ドメインの頂点をCDNやロードバランサに向けるときはALIASを使う。

TTLを短くするのは「切り替えの前」。当日では間に合わない。

ドメイン名は、右端のルート（.）から、TLD（.com、.jpなど）、その下の名前へと、木構造で枝分かれしています。example.co.jp なら、jpがTLD、coは企業向けの区分、exampleが取得した名前です。取得した名前より左（shop.example.co.jp、api.shop.example.co.jp など）は、持ち主が自由に作れるサブドメインです。

ドメインを使うには2つの手続きがあります。1つは登録で、登録者（自社）がレジストラ（お名前.com、Route 53など）を通じて申し込み、レジストラがレジストリ（.jpならJPRS、.comならVerisign）に登録します。もう1つは委任で、TLDのDNSサーバーに「example.co.jp のことは、このネームサーバーに聞いて」というNSレコードを登録してもらいます。これで世界中のリゾルバが自社の権威DNSにたどり着けるようになります。

サブドメインを別のチームやAWSアカウントに任せたいときは、親ゾーンにそのサブドメイン用のNSレコードを置いて委任します（例：dev.example.com を開発用アカウントのRoute 53に任せる）。

自分たちが自由にできるのは、取得した名前から左側。

登録（レジストラ）とDNSの運用（権威DNS）は別物。どちらが止まってもサービスは見えなくなる。

アプリやメーラーは、まず自分の送信サーバー（Amazon SESなど）にSMTPでメールを渡します。送信サーバーは宛先アドレスのドメイン（例：gmail.com）のMXレコードをDNSで引き、そこに書かれた受信サーバーへSMTPで転送します。受信者はIMAP（またはPOP3）やWebメールでメールボックスから読みます。

メールはもともと送信者を偽れる仕組みなので、受信側はなりすましを見抜くために3つの確認をします。SPFは送信元サーバーのIPがドメインの許可リストにあるか、DKIMはメールに付いた電子署名をドメインの公開鍵で検証できるか、DMARCはSPFかDKIMが送信元ドメインと一致して合格したか、を確認し、失敗時の扱いを指示します。2024年からGmailやYahoo!は、大量に送る送信者にSPF・DKIM・DMARCの設定やワンクリックでの配信停止などを求めています。

「メールが届かない」は、DNSの設定（SPF・DKIM・DMARC）か、送信元の評価の低下を疑う。

送信と受信で使うプロトコル

送るのは SMTP、受け取るのは IMAP / POP3。「送信」と「受信」で別のプロトコル・別のサーバーを使う。

メール障害のときに見るところ

よく見る SMTP の応答コード

調べる順番は「送信側のキューとログ → バウンスの応答コード → DNS（MX・SPF・DKIM・DMARC）→ 受信側」。どこで止まっているかを切り分ける。

TLSは、HTTPS などの通信を暗号化し、接続先が本物かを証明書で確かめる仕組みです。データを送る前に、使う暗号方式を決めて共通の鍵を作る「ハンドシェイク」というやりとりをします。TLS 1.3 では、このやりとりが TLS 1.2 より1往復少なくなりました。

SRE にとっては、証明書の期限切れや中間証明書の不足のような「設定と監視で防げたはずの障害」が多い分野です。ハンドシェイクのどの段階で何を確かめているかを知っておくと、openssl s_client の出力やエラーメッセージから、失敗した段階を絞り込めます。

証明書の期限切れや中間証明書の不足は、この検証の段階で失敗する。

下の「ブラウザで試す」の図では、ClientHello と ServerHello で鍵交換の材料（key_share）を交わした時点で共通鍵が決まり、そこから先の証明書や Finished はもう暗号化されて送られる、という順番を見られます。クライアントが証明書の信頼の連鎖・ドメイン名・有効期限を確かめる段階と、Finished のあとで HTTP のデータが流れ始めるところに注目してください。

共通鍵暗号は暗号化と復号に同じ鍵を使い、高速です。ただし鍵を安全に相手へ渡す方法が問題になります。公開鍵暗号は、公開してよい鍵と秘密の鍵のペアを使い、鍵の受け渡しや署名ができますが、遅いです。TLSは両方の良いところを組み合わせ、最初に公開鍵暗号で相手を確かめて共通鍵を決め、以降は共通鍵で通信します。

証明書は、サーバーの公開鍵とドメイン名に、認証局（CA）が署名したものです。ブラウザやOSには信頼できるルートCAの証明書が最初から入っていて、サーバー証明書から中間CA、ルートCAへと署名をたどれれば信頼します。

「一部の端末だけ接続できない」は中間証明書の送り忘れが定番の原因。

第11章「セキュリティ」：暗号化と復号、公開鍵と秘密鍵を図で詳しく

フォワードプロキシは利用者側に置き、社内からインターネットへの通信をまとめて中継します。アクセス先の制限やログ取得、キャッシュに使います。相手のサーバーからは、すべての社員がプロキシのIPから来たように見えます。

リバースプロキシはサーバー側に置き、利用者からのリクエストを受け付けて後ろのサーバーに振り分けます。Nginx、ALB、CloudFront、API Gatewayなどがこの役割で、TLSの終端、負荷分散、キャッシュ、WAF、圧縮、認証などをアプリの手前でまとめて行えます。ロードバランサは、負荷分散に特化したリバースプロキシと考えると分かりやすいです。

リバースプロキシを挟むと、アプリから見た接続元はプロキシになります。本当の利用者のIPはX-Forwarded-For、元のプロトコル（httpかhttpsか）はX-Forwarded-Protoヘッダーで伝えます。ただし利用者が自分でX-Forwarded-Forを偽って送ることもできるので、信頼できるプロキシが付けた値だけを使うように設定します。

リバースプロキシは、アプリに入る前の「共通の玄関」。玄関の設定が原因の障害も多い。