I01 · Edge 入口層 詳細 ROADMAP
計畫文件，不會被 Quartz 渲染。
回主 roadmap → infra/ROADMAP.md
章節目標
Request 進來的第一站。從使用者瀏覽器發 request，要先經過：
- DNS 解析 → 找到 IP
- CDN / Anycast → 就近取靜態資源
- Load Balancer（L4 / L7） → 分流到 server
- WAF / DDoS 防護 → 阻擋惡意流量
- Reverse Proxy（Nginx / Caddy / HAProxy） → 轉到應用層
- TLS 終止 → 加密解密的地點
本章不處理 application 層（Gateway 之後）——那些在 I02 Gateway 章。
🌱 基本介紹
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 01 | Edge 入口層是什麼 | 01-what-is-edge-layer | 🌱 | Request 到達你機器前會經過的所有基礎設施、各層的責任、雲 vs 地端的邊界差異 |
❓ 為什麼需要
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 02 | 為什麼 DNS 不是「查一次就好」 | 02-why-dns-not-one-shot | 🌱 | TTL / 快取 / resolver 選擇錯會 page 半夜；Anycast / GeoDNS 為什麼存在 |
| 03 | 為什麼必須有 CDN | 03-why-need-cdn | 🌱 | 單機 bandwidth 撞牆 / 全球延遲撞牆；邊緣快取解什麼 |
| 04 | 為什麼 L4 / L7 LB 不是選一個 | 04-why-both-l4-l7 | 🌱 | L4 快但看不到 payload；L7 看得到但有成本；大型系統為什麼兩層都有 |
| 05 | 為什麼應用層 rate limit 撐不住 DDoS | 05-why-app-rate-limit-fails-ddos | 🌱 | L3/L4 volumetric 攻擊在 application 看到時已經掛了；為什麼 DDoS 防禦必須在 edge |
🕰️ 演進
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 06 | Edge 演進驅動力 | 06-edge-evolution-drivers | 🌱 | Single origin bandwidth 撞牆 → CDN；手動 DNS failover 撞牆 → Anycast / GeoDNS；HTTP/1.1 head-of-line blocking 撞牆 → HTTP/2；TLS handshake RTT 撞牆 → TLS 1.3 / 0-RTT；TCP 握手 + HOL 撞牆 → QUIC / HTTP/3；volumetric DDoS 撞牆 → 全球 Anycast 清洗（CloudFlare / AWS Shield 商業模式）。各代演進的 pointer 到下面知識型各組（DNS → F01-A、TLS → F01-D、CDN → F01-B） |
🧠 知識型
F01-A DNS 與網域
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 07 | DNS 基礎運作 | ⛔️ infra/network-edge/01-network-dns | 🌿 | 跨系列 |
| 08 | DNS TTL 與快取策略 | 08-dns-ttl-strategy | 🌱 | 短 TTL vs 長 TTL 的 trade-off / failover 場景 / TTL 太短代價 |
| 09 | GeoDNS / Anycast / Latency routing | 09-geodns-anycast | 🌱 | Route 53 / CloudFlare Anycast；雲地混合時如何做 |
| 10 | DNS over HTTPS / TLS（DoH / DoT） | 10-doh-dot | 🌱 | 為什麼要 / 誰在用（Cloudflare 1.1.1.1 / Google 8.8.8.8）/ 對企業監控的影響 |
F01-B CDN 與邊緣
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 11 | CDN 架構原理 | ⛔️ infra/network-edge/29-dns-loadbalancing-cdn | 🌿 | 跨系列 |
| 12 | CDN 選型（CloudFlare / Fastly / CloudFront / Akamai） | 12-cdn-selection | 🌱 | 定價 / 功能 / 邊緣 PoP / Edge Workers 支援 |
| 13 | Cache 策略（Cache-Control / Surrogate-Control / Vary） | 13-cdn-cache-strategy | 🌱 | 哪些該 cache / 哪些不 cache / cache invalidation |
| 14 | Edge Functions 實作 | 14-edge-functions-impl | 🌱 | 本章聚焦「在 network edge 跑 code」的實作面：CloudFlare Workers / Fastly Compute / Vercel Edge 寫法、runtime 限制（50ms CPU / no Node.js API）、跟 origin server 資料互動；架構決策面（compute edge vs network edge）見 I08 S01 |
F01-C Load Balancer & Reverse Proxy
定位區分（本節第 15 題 overview 會完整展開）：Load Balancer 是「網路層分流」的概念；Reverse Proxy 是「協議層代理」的概念。Nginx / HAProxy / Envoy 同一個軟體可以當兩種角色——選軟體看協議支援度，選架構看責任切割。
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 15 | LB vs Reverse Proxy 邊界 | 15-lb-vs-reverse-proxy | 🌱 | 為什麼 Nginx 既是 RP 也是 L7 LB；責任區分；什麼時候要分開部署 |
| 16 | L4 vs L7 LB | 16-l4-vs-l7-lb | 🌱 | TCP/UDP balancing vs HTTP；何時選哪個；兩層混合架構 |
| 17 | 雲上 LB 選型 | 17-cloud-lb-selection | 🌱 | AWS ALB / NLB vs GCP LB vs Azure LB；跟 aws/04-load-balancing 連動 |
| 18 | 地端 LB / RP 選型 | 18-on-prem-lb-rp | 🌱 | HAProxy / Nginx / Caddy / Traefik / F5 BIG-IP；BGP + Anycast 自架 |
| 19 | Nginx 深入 | 19-nginx-deep | 🌱 | 配置模型、module、性能調校；2026 還在用的理由 |
| 20 | Caddy 自動化優勢 | 20-caddy-auto | 🌱 | 自動 HTTPS、配置簡單；小型場景首選 |
| 21 | 健康檢查策略 | 21-health-check-strategy | 🌱 | Passive vs Active；檢查頻率；跟 application readiness probe 的整合 |
F01-D TLS / HTTPS
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 22 | TLS 基礎 | ⛔️ infra/network-edge/02-reverse-proxy-tls | 🌿 | 跨系列 |
| 23 | TLS 終止位置決策 | 23-tls-termination-location | 🌱 | LB 終止 vs Gateway 終止 vs Pod 終止；效能 vs 可觀測性 trade-off |
| 24 | Edge TLS 憑證自動化（cert-manager / Let’s Encrypt） | 24-edge-cert-automation | 🌱 | 僅限 edge ingress TLS 憑證：ACME 流程、K8s cert-manager for ingress；內部 PKI / service-to-service mTLS / Vault PKI 見 infra/security-governance/ I06 F06-B |
F01-E WAF / DDoS 防護
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 25 | DDoS 防禦分層（吸收 backend B16 #39） | 25-ddos-defense-layers | 🌱 | L3/L4 volumetric vs L7 application；CloudFlare / AWS Shield / Akamai；app rate limit 配合；從 backend/security/ B16 吸收 |
| 26 | WAF 規則設計 | 26-waf-rules | 🌱 | OWASP CRS / Custom rule；false positive 管理；log 分析 |
| 27 | Bot 防護 | 27-bot-protection | 🌱 | CAPTCHA / JS challenge / Behavioral；API 層防爬 |
F01-F Modern Protocols at Edge
現代應用不只跑 HTTP/1.1 + REST。QUIC / gRPC / WebSocket / SSE 在 edge 層都有自己的挑戰——LB 要支援 HTTP/2、長連接要 sticky、streaming 要注意 timeout。
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 28 | HTTP/3 / QUIC 部署實務 | 28-http3-quic-deployment | 🌱 | QUIC 在 LB / CDN 的支援度（Cloudflare 先行、AWS CloudFront 2023+）；UDP:443 防火牆穿透；瀏覽器相容性；怎麼驗證實際走 HTTP/3 |
| 29 | gRPC 在 Edge 層的挑戰 | 29-grpc-at-edge | 🌱 | L4 LB 無法辨識 gRPC stream（需 L7 支援 HTTP/2）；gRPC-Web for browser；Envoy vs Nginx gRPC 支援差異；長連接 connection rebalance；keep-alive / timeout 設計 |
| 30 | WebSocket / SSE 在 Edge 層 | 30-websocket-sse-edge | 🌱 | HTTP Upgrade 握手；sticky session vs pub-sub fanout；連接風暴；idle timeout；CDN WebSocket 支援（Cloudflare / CloudFront）；跟 backend/micro-service/26-websocket-sse 視角區隔（本篇是 edge infra 面，那篇是 application 面） |
🔧 小實作注意事項
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 31 | 本機起 Nginx + LB + TLS stack | 31-local-edge-stack | 🌱 | Docker Compose 模擬完整 edge；測 cert rotation / health check |
| 32 | DNS failover 演練 | 32-dns-failover-drill | 🌱 | Route 53 healthcheck + failover policy；測 RTO |
| 33 | CloudFlare + Origin shield 設定 | 33-cloudflare-origin-shield | 🌱 | 減少 origin 負擔、多層 CDN 架構實作 |
| 34 | 驗證站點實際走 HTTP/3 | 34-verify-http3-traffic | 🌱 | Chrome DevTools / curl —http3；cloudflare headers；HTTP/3 fallback 測試 |
💣 Anti-pattern
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 35 | Edge 層 Anti-patterns | 35-edge-antipatterns | 🌱 | DNS TTL 訂 86400（緊急切換要等 1 天）/ 或 30 秒（resolver 被打爆）；只用 L4 LB 看不到業務錯誤；TLS 終止在 app 層卻不 offload；以為 CDN 會自動擋 DDoS；忽略 origin shield；cert 手動 renew（週末到期慘劇）；gRPC 用 L4 LB 導致 stream 無法分流；WebSocket 用普通 LB 但沒設 sticky 結果狂斷線 |
🧰 對應檢查工具
| # | 主題 | Slug | Stage | 大綱 |
|---|
| 36 | Edge 相關工具 | 36-edge-tooling | 🌱 | dig / nslookup / mtr（DNS）、openssl / testssl.sh（TLS）、wrk / hey（LB 壓測）、grpcurl / grpc_health_probe（gRPC）、CloudFlare Analytics / AWS WAF metrics |
📎 補充
| # | 主題 | Slug | Stage | 大綱 |
|---|
| S01 | 雲地混合 Edge 設計 | s01-hybrid-edge | 🌱 | 部分流量走地端 / 部分雲端；故障切換 / 成本考量 |
| S02 | Anycast 原理與實作 | s02-anycast-deep | 🌱 | BGP 宣告、AS / IX peering、自建 Anycast 門檻 |
章節進度統計
- 知識主題：36 + 2 補充 = 38 項
- 🌿 growing：3（既有 infra/ 檔案 + B16 pointer）
- 🌱 seed：35
本章內容範圍變更（2026-04）：
- 合併原 F01-C Load Balancer + F01-F Reverse Proxy → F01-C LB & Reverse Proxy
- 新增 F01-F Modern Protocols at Edge（HTTP/3、gRPC、WebSocket / SSE）
- 演進段原 3 個 pointer（DNS/TLS/CDN 演進）收進 #06 Edge 演進驅動力
- #24 Edge TLS 憑證明確限定範圍，內部 PKI 歸 I06
- 整章已重新編號（補 07-09 gap，全連續 01-36）
跨系列連結
- →
infra/01, 02, 29（原始 infra 篇吸收進來）
- →
backend/security/ B16 #39 DDoS（已 pointer 到本章 #25）
- →
backend/micro-service/26-websocket-sse（application 面，本章 #30 是 infra 面）
- →
infra/cloud/aws/02 VPC / 04 Load Balancing / 08 Secrets（雲端實作對照）
- →
ops-notes/（CloudFlare / Nginx 踩坑案例—未來擴充）
- → I02 Gateway（本章結束後 request 進 Gateway；gRPC routing 深入在 I02）
- → I06 Security-governance（內部 PKI / service mesh mTLS 歸這）