題目與適用情境
當使用者在瀏覽器網址列輸入 https://shop.example/products?id=42#reviews 並按下 Enter，到頁面可見為止發生了什麼？請涵蓋 URL 解析、名稱解析、連線與加密、HTTP、伺服器端處理、瀏覽器導覽和渲染，並說明哪些階段可能因快取或連線重用而略過。
為避免回答在不同前提之間游移，主路徑先採用一組明確假設：這是一次新的頂層文件導覽；輸入的是完整 URL，不是搜尋詞；沒有 Service Worker 回傳回應、沒有可直接使用的 HTTP 快取、沒有可重用連線；網域名稱需要解析；伺服器最終回傳狀態碼 200 的 HTML。後文再討論熱快取、重新導向和 HTTP/3 等分支。
這是一道跨層基礎題，適用於後端、客戶端、全端、基礎架構、SRE 與通用軟體工程職缺。核心任務不是背誦協定名稱，而是根據快取與協定前提推導真實路徑，並把網路、伺服器端和渲染階段對應到可觀測證據。
面試官考察重點
第一，候選人能否先聲明前提。背誦「DNS → TCP → TLS → HTTP → 渲染」會漏掉快取、Service Worker、連線重用與 HTTP/3。真實路徑取決於導覽類型、快取狀態、協定協商和回應內容；好的回答會先給出一條確定主線，再補充會改變主線的分支。
第二，能否準確劃分協定邊界。#reviews 是 URL 的片段，HTTP 請求目標不包含它；HTTPS 預設連接埠是 443；DNS 解析的是主機名稱，但不保證每次都從根伺服器開始；HTTP/1.1 與 HTTP/2 通常運作在 TCP 上，HTTP/3 運作在 QUIC 上，而 QUIC 使用 UDP 並整合 TLS 1.3。
第三，能否區分導覽提交、資源載入和像素出現。收到第一個位元組不等於頁面可見，導覽提交也不等於所有資源載入完成。瀏覽器還要選擇渲染程序、解析 HTML、發現子資源、建構 DOM 與 CSSOM，並完成樣式計算、版面配置、繪製和合成。
第四，能否把端到端模型用於除錯。若候選人只會講順序，就無法回答「慢在哪裡」。高品質回答會把 DNS、連線、TLS、第一個位元組、下載和主執行緒渲染分別對應到導覽計時、網路面板和效能軌跡中的證據。
回答前需要釐清的問題
- 輸入一定是 URL 嗎？ 網址列可能把一般文字交給搜尋引擎。本題已給出含 scheme 的完整 HTTPS URL，因此繼續按導覽處理。
- 是新文件導覽還是單頁應用程式內跳轉？
history.pushState()不會自動觸發同一套跨文件導覽。本題假設是新的頂層文件。 - 冷啟動還是熱路徑？ HTTP 快取、DNS 快取、Service Worker、預先連線或既有 HTTP/2/3 連線都可能省略階段。主回答先講冷路徑，再補充分支。
- 協定和網路環境是什麼？ HTTP/1.1、HTTP/2 與 HTTP/3 的連線建立方式不同；Proxy、VPN、企業閘道與 UDP 可用性也會改變路徑。
- 回應是什麼？ 200 HTML、重新導向、下載、憑證錯誤與網路錯誤會進入不同分支。本題主路徑以 200 HTML 為準。
- 「頁面可見」指什麼？ 首次繪製、最大內容繪製、
DOMContentLoaded與load不是同一個時刻。本題解釋到首次可見，並補充其後的資源載入。
30 秒回答框架
「我先按一次冷啟動的 HTTPS 頂層導覽回答。瀏覽器解析 URL，片段留在客戶端；再經快取或 DNS 取得位址，重用連線，或為 HTTP/1.1、HTTP/2 建立 TCP 與 TLS，為 HTTP/3 建立整合 TLS 1.3 的 QUIC。它傳送路徑和查詢，收到回應後檢查狀態、類型與安全政策，選擇渲染程序並提交導覽。渲染器解析 HTML、載入子資源，建構 DOM、CSSOM 與渲染樹，再完成版面配置、繪製和合成。排查慢頁面時，分別查看 DNS、連線/TLS、TTFB、下載和主執行緒。」
分步深入解析
第一步：網址列判定輸入並解析 URL
瀏覽器先判斷網址列內容是可導覽 URL 還是搜尋查詢。本題輸入包含 https://，因此按 URL 解析。解析結果可以寫成：
| 元件 | 值 | 作用 | |---|---|---| | scheme | https | 決定安全 HTTP 語意與可用傳輸 | | host | shop.example | 用於名稱解析、連線與伺服器身分驗證 | | port | 443（預設） | 未明確寫出時由 HTTPS scheme 決定 | | path | /products | 標示目標資源路徑 | | query | id=42 | 隨請求目標傳給伺服器 | | fragment | reviews | 留在客戶端供文件內定位，不進入 HTTP 請求目標 |
瀏覽器還會執行 URL 標準規定的解析與正規化，並檢查導覽政策。舊頁面的卸載處理、瀏覽器安全政策或無效 URL 都可能在網路請求前改變結果。面試時不要把「按下 Enter」直接等同於「立即送出封包」。
第二步：先判斷能否避免網路存取
真實瀏覽器會考慮既有文件狀態、Service Worker、HTTP 快取、預先載入與可重用連線。新鮮且適用的快取回應可能省去存取來源站；受控頁面的 Service Worker 可能從快取回傳、自行發起網路請求，或組合兩者。快取命中也不表示完全沒有瀏覽器工作，HTML 仍可能需要解析和渲染。
主路徑假設這些捷徑都不可用，所以繼續網路存取。這裡不應背誦一個絕對的「先查所有快取，再查 DNS」順序：不同快取分別服務 URL 回應、DNS 記錄和連線狀態，瀏覽器實作也可能平行或推測執行部分工作。
第三步：把主機名稱解析為可連線位址
瀏覽器或作業系統先使用仍有效的名稱解析結果；沒有命中時，向設定的遞迴解析器查詢。遞迴解析器也會使用快取，只有缺少答案時才依 DNS 委派關係繼續查詢，最後取得適用的位址記錄。答案可能指向 CDN 或邊緣節點，不是應用程式來源站。
因此，「瀏覽器每次依序查詢根、頂級網域和權威伺服器」並不準確。客戶端通常把遞迴工作交給解析器，快取與記錄 TTL 會影響是否需要繼續查詢。現代瀏覽器也可能使用加密 DNS；它改變 DNS 查詢的傳輸與隱私邊界，但不改變網域名稱需要映射到可到達服務位址這個目標。
第四步：重用或建立安全連線
取得候選位址後，瀏覽器會嘗試重用與目標相容的既有連線。無法重用時，路徑取決於最後採用的 HTTP 版本：
- HTTP/1.1 或 HTTP/2 通常先建立 TCP 連線，再進行 TLS 交握。TLS 驗證伺服器憑證與主機名稱、協商加密參數，並可透過 ALPN 協商 HTTP/2 或 HTTP/1.1。
- HTTP/3 使用 QUIC；QUIC 運作在 UDP 上，並把 TLS 1.3 交握整合到連線建立中，所以不能說所有 HTTPS 都先完成 TCP 三向交握。
- 若網路不支援可用的 QUIC/UDP 路徑，客戶端可以退回以 TCP 為基礎的 HTTP。具體嘗試順序和退回策略屬於瀏覽器實作細節，不宜編造固定時序。
IP 路由、區域網路鏈路、NAT、Proxy 或 VPN 都可能參與資料到達對端的過程。面試時間有限時，可以說明它們存在；除非面試官繼續追問，不必把每一跳展開成另一道網路題。
第五步：傳送 HTTP 請求並處理伺服器回應
連線可用後，瀏覽器建構請求。以 HTTP/1.1 文字形式表達核心語意時，可以寫成：
GET /products?id=42 HTTP/1.1
Host: shop.example
Accept: text/html請求目標包含路徑和查詢，不包含 #reviews。瀏覽器還會依 Cookie 的網域、路徑、SameSite 與安全屬性等規則，決定是否攜帶 Cookie，並傳送內容協商、快取驗證等標頭；不能籠統地說「所有 Cookie 都會送出」。HTTP/2 與 HTTP/3 的線上編碼不是這段 HTTP/1.1 文字，但方法、目標、標頭欄位和回應語意仍可對應。
請求可能先到 CDN、反向 Proxy 或負載平衡器，再進入應用程式、快取與資料庫；也可能由簡單伺服器直接回傳。不要把常見架構畫成必經事實。回應包含狀態、標頭欄位與內容。重新導向會讓瀏覽器依新位置開始後續導覽；304 Not Modified 會結合既有快取；主路徑則收到 200、HTML 內容類型和回應本文。
第六步：瀏覽器提交導覽
瀏覽器讀取回應時會處理狀態、內容類型、下載判定與安全政策，並為目標網站選擇合適的渲染程序。Chromium 將「提交導覽」與「載入文件」區分：提交表示瀏覽器把回應交給渲染器並切換目前文件的歸屬，後續回應讀取、解析、腳本與子資源仍可能繼續。
錯誤狀態不一定代表「沒有頁面」。伺服器回傳的 HTML 錯誤文件也可以成為新文件；憑證錯誤、連線失敗或瀏覽器攔截則可能顯示瀏覽器產生的錯誤頁。回答時說「只有 200 才會提交導覽」過於絕對。
第七步：解析、載入並把像素畫出來
渲染器增量解析 HTML、建構 DOM，並在遇到樣式表、腳本、字型、圖片等引用時安排子資源請求。子資源可以重用 DNS 結果和既有連線，也可能來自其他來源而需要新的名稱解析與連線；不能說每個資源必然重新完成整套交握。
CSS 解析形成 CSSOM；DOM 與 CSSOM 參與產生可見元素的渲染樹，接著完成樣式計算、版面配置和繪製，瀏覽器再合成圖層並顯示像素。傳統腳本若沒有合適的 defer、async 或模組語意，可能阻塞 HTML 解析；CSS 也會影響首次渲染。首次繪製可能發生在所有圖片或非同步腳本完成前，DOMContentLoaded 也早於某些子資源的 load 完成。
片段 #reviews 沒有傳給伺服器。文件可定位後，瀏覽器可以捲動到對應元素；若元素稍後才由腳本建立，最終表現仍取決於頁面程式碼。
第八步：用階段證據定位「慢」
先問使用者看到的是 DNS 失敗、連線失敗、白畫面、內容延遲還是互動卡頓，再把症狀映射到階段：
| 階段 | 重點證據 | 常見解釋邊界 | |---|---|---| | DNS | domainLookupStart 到 domainLookupEnd | 名稱解析慢，不代表應用程式伺服器慢 | | 連線 | connectStart 到 connectEnd，包含安全連線時間 | 新建連線、網路路徑或 TLS 可能占用時間 | | TTFB | requestStart 到 responseStart | 包含請求傳輸、邊緣/伺服器處理與回傳第一個位元組 | | 下載 | responseStart 到 responseEnd | 回應本文大小、頻寬與壅塞都會影響 | | 渲染 | 效能軌跡中的繪製、長任務和版面配置記錄 | 渲染可與串流下載重疊；主執行緒腳本、樣式與版面配置可能是瓶頸 |
可以在頁面中讀取一次導覽記錄做初步篩查：
const [nav] = performance.getEntriesByType("navigation");
console.table({
dns: nav.domainLookupEnd - nav.domainLookupStart,
connect: nav.connectEnd - nav.connectStart,
ttfb: nav.responseStart - nav.requestStart,
download: nav.responseEnd - nav.responseStart,
protocol: nav.nextHopProtocol,
});這些差值是觀察點，不是自動根因。連線重用會讓部分時間點相同；Service Worker、快取、重新導向和 Proxy 也會改變含義。應結合瀏覽器網路面板、伺服器端追蹤和效能軌跡驗證，不能看到 TTFB 高就直接歸咎資料庫。
高品質示範回答
「我先明確一條冷啟動主路徑：這是新的 HTTPS 頂層導覽，沒有 Service Worker 回應、HTTP 快取或可重用連線，最後回傳 200 HTML。
瀏覽器先把 https://shop.example/products?id=42#reviews 解析為 HTTPS scheme、主機、預設連接埠 443、路徑、查詢和片段。片段只在客戶端使用，所以實際請求目標是 /products?id=42。接著瀏覽器或系統使用 DNS 快取；沒有結果時向遞迴解析器查詢。解析器也會快取，因此不代表每次都存取根、頂級網域和權威伺服器。
取得位址後，瀏覽器先看能否重用連線。HTTP/1.1 或 HTTP/2 通常使用 TCP 與 TLS，並透過憑證驗證伺服器身分；HTTP/3 使用基於 UDP 的 QUIC，TLS 1.3 已整合在 QUIC 交握中，所以我不會把 TCP 寫成所有 HTTPS 的必經步驟。連線建立後傳送 GET 請求，路徑和查詢會傳出，片段不會。請求可能經過 CDN、負載平衡器和應用程式，也可能直接由伺服器處理，最後回傳狀態、回應標頭和 HTML。
瀏覽器檢查回應類型和安全政策，選擇渲染程序並提交導覽。渲染器接著增量解析 HTML、建立 DOM、發現並載入 CSS、JavaScript、字型和圖片；這些資源可以重用連線或快取。CSSOM 與 DOM 參與產生渲染樹，之後是版面配置、繪製和合成。頁面首次可見可能早於全部資源載入完成，最後再依 #reviews 做文件內定位。
如果頁面很慢，我會按階段取證：導覽計時看 DNS、連線、TTFB 和下載，網路面板看協定、快取與重新導向，效能軌跡看主執行緒腳本、樣式、版面配置和繪製。這樣可以判斷時間消耗在名稱解析、網路與伺服器，還是瀏覽器渲染，不只複述固定流水線。」
常見錯誤
- 把固定順序當成每次真實路徑 → 快取、Service Worker 和連線重用會略過網路階段 → 先聲明冷路徑，再說明哪些條件會縮短路徑。
- 說 HTTPS 一定先建立 TCP → HTTP/3 使用 QUIC/UDP 並整合 TLS 1.3 → 依最終 HTTP 協定分別說明 TCP 與 QUIC。
- 把
#reviews傳給伺服器 → HTTP 請求目標排除片段 → 只傳送/products?id=42，片段留給客戶端定位。 - 說瀏覽器每次查詢根 DNS → 客戶端、遞迴解析器與權威鏈路都可能有快取 → 描述遞迴解析與委派關係，不編造每次必走的查詢序列。
- 讓每個子資源重複 DNS、TCP 與 TLS → 同源連線與快取通常可以重用 → 只有新來源、失效狀態或連線不相容時才需要新增工作。
- 把 CDN、微服務、快取與資料庫都畫成必經層 → 伺服器端實作沒有固定拓撲 → 用「可能經過」表達，並依實際系統展開。
- 把收到 HTML 等同頁面完成 → 提交、解析、首次繪製、
DOMContentLoaded與load是不同里程碑 → 明確回答採用的完成標準。 - 只背協定名稱，不能定位效能 → 面試官看不到工程判斷 → 把 DNS、連線、TTFB、下載和渲染對應到可觀測證據。
追問與應對
追問一：如果頁面有新鮮 HTTP 快取或受 Service Worker 控制，流程怎麼變？
新鮮快取可以直接提供回應，省去存取來源站；需要驗證的快取可能傳送條件請求並收到 304。Service Worker 可以回傳自己的快取回應、轉送網路請求或混合兩者。無論回應來自哪裡，瀏覽器仍可能需要提交導覽、解析文件和渲染。回答應說明快取來源和驗證狀態，不能只說「有快取就什麼都不用做」。
追問二：HTTP/3 與 HTTP/2 的主路徑差在哪裡？
HTTP/2 通常在 TCP 上透過 TLS 運作；HTTP/3 把 HTTP 語意映射到 QUIC，QUIC 使用 UDP 並整合 TLS 1.3。兩者都支援在一條連線上並行處理多個串流，但 HTTP/3 的傳輸層封包遺失處理不要求其他獨立串流都等待 TCP 位元組流恢復。網路不支援可用 QUIC 時，客戶端可採用以 TCP 為基礎的 HTTP。
追問三：如果伺服器回傳 301 到另一個網域，哪些步驟會重複？
瀏覽器先處理重新導向狀態與 Location，解析新 URL，並套用重新導向和安全政策。若新主機沒有可用 DNS 結果或相容連線，就需要新的名稱解析和連線建立；若有可重用狀態則可以省略。接著傳送新請求，直到取得最終回應或觸發重新導向限制。依 HTTP 語意，若 Location 沒有片段，新引用會繼承原始片段；若 Location 自帶片段，則使用新片段。片段在兩種情況下都不會進入 HTTP 請求目標。
追問四：DNS 和 TTFB 都很快，但頁面長時間白畫面，先查什麼？
網路階段已經縮小嫌疑範圍。先看 HTML 是否真的到達、內容類型與安全政策是否阻擋資源，再在效能軌跡檢查長任務、同步腳本、樣式表、字型和大規模版面配置。對照首次繪製、關鍵資源瀑布和主執行緒時間線，找出第一個阻止像素出現的相依項，不要繼續最佳化 DNS。
追問五：為什麼 DOMContentLoaded 已觸發，圖片仍未全部出現？
DOMContentLoaded 關注文件解析與相關阻塞腳本完成，並不等待所有圖片等子資源。load 更接近文件與相依資源完成，但延遲載入、後續腳本請求和持續更新仍可能發生。效能目標應採用符合使用者體驗的里程碑，不能把單一事件當成「頁面一切結束」。