從瀏覽器輸入 URL 到網頁呈現全景：DNS 遞迴解析、TCP 三向交握、TLS 協商到 HTTP 請求全鏈路拆解

「當你在瀏覽器輸入 URL 並按下 Enter 到頁面渲染出來，這中間發生了什麼事？」

這是全球軟體工程師、SRE 與架構師面試中出現頻率最高、涵蓋領域最廣的「面試神題」。許多人只能背出零散的名詞（DNS、TCP、HTTP、DOM），卻無法將作業系統內核、網路協定棧與瀏覽器渲染引擎串聯成一條條理清晰的完整鏈路。

本文將帶你沿著資料封包的真實流轉軌跡，由淺入深、毫秒級拆解這場跨越微秒、公網與矽晶片的傳輸全景之旅。

1. 全鏈路旅程鳥瞰圖

URL 合法性與協議判斷：瀏覽器判斷輸入的是搜尋關鍵字還是標準 URL。
HSTS（HTTP Strict Transport Security）檢查：
- 瀏覽器檢查內建的 HSTS Preload 列表。若域名在列表中，瀏覽器會直接在內部將 http:// 強制重寫為 https://，從源頭避免明文跳轉遭受 SSL-Stripping 中間人攻擊。
階層式快取檢查：
- 檢查 Service Worker 快取 ➔ Memory Cache ➔ Disk Cache ➔ Push Cache。若命中強快取（Cache-Control: max-age=... 且未過期），直接從本機硬碟/記憶體讀取並結束網路傳輸！

若無快取，系統必須將人類可讀的域名（如 carlstack.dev）轉換為機器識別的 IP 位址：

遞迴查詢（Recursive Query）：客戶端與 Local DNS 之間的關係（「請直接給我最終結果」）。
迭代查詢（Iterative Query）：Local DNS 代表客戶端依序向「根（Root）➔ 頂級域（TLD）➔ 權威域（Authoritative）」發起詢問的過程。
現代優化：透過 DoH（DNS over HTTPS） 或 DoT（DNS over TLS） 對 DNS 查詢進行加密，防止 ISP 劫持與流量窺探。

獲取目標 IP 後，瀏覽器內核透過 socket() 系統調用向目標伺服器的 443 埠發起 TCP 連線：

為什麼必須是三次？ 兩次無法確認雙向的發送與接收能力，四次則冗餘浪費。三次是通訊雙方在不可靠網路上達成「初始序列號（ISN）同步」的理論最小次數。
MSS（Maximum Segment Size）協商：在 SYN 階段同步雙方最大報文段大小（通常為 1460 字節，對應 1500 字節的乙太網 MTU）。

在 TCP 管道之上，進行 1-RTT 的 TLS 1.3 握手（協商 AES-GCM 對稱密鑰與校驗 X.509 證書鏈）。

連線就緒後，客戶端發送二進位 HTTP 幀：

GET /posts/system-design HTTP/2
Host: carlstack.dev
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml

伺服器網關（如 Envoy / Nginx）接收請求，透過反向代理將其轉發至後端微服務處理，並返回 HTML 響應流（HTTP/2 200 OK，帶有 Content-Type: text/html; charset=utf-8）。

瀏覽器網路執行緒接收到字節流後，交由渲染引擎（如 Blink / WebKit）的主執行緒解析：

構建 DOM 與 CSSOM：邊下載邊流式解析 HTML 構建 DOM 樹；遇到 <link rel="stylesheet"> 時非同步下載並構建 CSSOM 樹。
生成渲染樹（Render Tree）：結合 DOM 與 CSSOM，過濾掉 display: none 的隱藏節點。
佈局計算（Layout / Reflow）：計算每個可見節點在螢幕上的精確幾何座標與尺寸。
圖層繪製與合成（Paint & Composite）：將元素繪製到不同圖層，交由 GPU 執行硬體加速合成，最終將像素呈現在螢幕上！

從輸入 URL 到網頁呈現，是計算機科學各層級協同運作的極致藝術：