你輸入 google.com 接下來 0.1 秒發生了什麼？ | Joseph Chen

「『從瀏覽器輸入 URL 到頁面顯示，中間發生了什麼？』——這是軟體工程師面試最常見的問題之一。」

很多人能說「DNS 解析、TCP 連線、發 HTTP Request」，但面試官要的是細節： DNS 是怎麼查的？TCP 為什麼要三次握手？CDN 是在哪個環節介入的？這篇把每一步完整拆解，讓你下次不只是說個大概。

整體流程鳥瞰

輸入 URL 到頁面出現，一共走過 6 個大步驟。這篇專注在前三步（DNS、TCP、IP）， HTTP 在 EP.01 已經說過，HTTPS/TLS 在 EP.03 繼續。

DNS 解析

本篇重點

把 google.com 這個「名字」翻譯成 142.250.185.14 這個「地址」

建立 TCP 連接（三次握手）

本篇重點

確認你和伺服器之間的連線是通的，雙方都準備好收發資料

TLS 握手（HTTPS 才有）

EP.03

協商加密方式、驗證憑證，建立加密通道，詳見 EP.03

發出 HTTP Request

EP.01

GET / POST 請求，帶上 Headers（Cookie、Accept 等），詳見 EP.01

伺服器處理並回應

後端範疇

路由匹配、DB 查詢、業務邏輯、組成 HTML/JSON 回傳

瀏覽器解析 HTML + 渲染

前端渲染

建構 DOM Tree、載入 CSS/JS、計算 Layout、繪製畫面

DNS——網路的「電話本」

生活化比喻：你知道一間餐廳叫「麥當勞」，但你不知道它的地址。你查了 Google Maps，得到地址「台北市信義路 X 號」。DNS 就是網路的 Google Maps——把名字（域名 google.com）轉換成地址（IP 142.250.185.14）。沒有 DNS，你就必須記住每個網站的 IP，沒有人做得到。

DNS 解析的完整過程

查詢 DNS 不是問一個伺服器那麼簡單，而是一層一層往上問，直到有人知道答案。越高層的 DNS 伺服器知道的越少，但最終一定能找到。

DNS 解析路徑（無快取情況）

你的瀏覽器
  ↓ 1. 先查瀏覽器自己的 DNS 快取（幾分鐘前去過就有）
  ↓    沒有 → 問 OS
  ↓ 2. 查 OS 的快取（包括 /etc/hosts 設定）
  ↓    沒有 → 問 Router
  ↓ 3. 問你家 Router 的 DNS（通常是 ISP 給的 192.168.x.x）
  ↓    沒有 → 問 ISP 的遞迴 DNS 伺服器
  ↓ 4. ISP 遞迴 DNS（Recursive Resolver）
  ↓    這台伺服器負責幫你問到底
  ↓    它先問 Root DNS Server（13 組，全球都有備份）
  ↓
Root DNS：「我不知道 google.com 在哪，但 .com 的伺服器我知道，去問它」
  ↓
TLD DNS (.com)：「我不知道 google.com，但 google.com 的授權 DNS 我知道，去問它」
  ↓
Authoritative DNS（Google 的 DNS）：
  「google.com = 142.250.185.14，TTL 300 秒」
  ↓
← 層層回傳，最終告訴你的瀏覽器：
   google.com → 142.250.185.14

為什麼要分這麼多層？

全球有幾億個域名。如果只有一台 DNS 伺服器，每次查詢都打去同一台，早就被流量打掛了。分層設計讓查詢分散，快取讓大部分查詢在 ISP 層就結束，不需要每次都問到 Root。

TTL（Time to Live）

每條 DNS 記錄都有 TTL，單位是秒。TTL 300 = 快取 5 分鐘後過期。過期後下次查詢才會重新問。遷移網站時記得先把 TTL 調低（例如 60 秒），這樣換 IP 後才能快速生效。

常見 DNS Record 類型

DNS Record 速查表

# A Record：域名 → IPv4（最常見）
A     www.example.com  →  93.184.216.34

# AAAA Record：域名 → IPv6
AAAA  www.example.com  →  2606:2800:220:1:248:1893:25c8:1946

# CNAME：別名，指向另一個域名（而不是 IP）
# 常見用途：shop.example.com 指向 CDN 或 Shopify
CNAME shop.example.com  →  example.myshopify.com

# MX：郵件伺服器（寄信去哪台）
MX    example.com       →  mail.example.com  (優先級 10)

# TXT：文字記錄，常用於驗證（Google 驗證、SPF 防偽造信件）
TXT   example.com       →  "v=spf1 include:_spf.google.com ~all"

# TTL：快取多久（秒）
TTL   300               →  5 分鐘後過期，重新查詢

CNAME vs A Record 怎麼選？

如果你的服務 IP 會變動（例如 Vercel、Cloudflare 托管），用 CNAME 指向他們給你的 hostname。這樣他們改 IP 你不需要動任何設定。如果你的伺服器 IP 固定（例如自架 VPS），用 A Record 直接指 IP 比較乾淨。注意：根域名（example.com，不帶 www）通常不能設 CNAME，要用 A Record 或特殊的 ALIAS 記錄。

IP 地址——你在哪裡

比喻：IP 地址就像快遞地址。 IPv4 是舊式地址（四段數字，如 192.168.1.1），總共只有 42 億個，早就快用完了。IPv6 是新式地址，長度更長、數量幾乎無限。 Port 就像「幾樓幾號」——同一台電腦可以同時運行網頁伺服器、資料庫、SSH 等多個服務，用 Port 區分哪個服務要接哪個連線。

IPv4 vs IPv6

格式192.168.1.1

位元數32 bits

總數量~42 億

IPv6

格式2001:db8::1

位元數128 bits

總數量3.4 × 10³⁸

常見 Port 速查

80→HTTP（網頁）

443→HTTPS（加密網頁）

22→SSH（遠端登入）

3306→MySQL

5432→PostgreSQL

27017→MongoDB

3000→Next.js / React 開發伺服器

8080→後端 API 常見開發 port

你平常連 http://localhost:3000，就是在連你自己電腦（localhost = 127.0.0.1）的 3000 port。瀏覽器連 https://google.com 不帶 port，是因為 HTTPS 預設就是 443，瀏覽器自動補上。

TCP 三次握手——打電話確認連線

比喻：打電話確認連線。你打電話（SYN），對方說「有聽到嗎？」（SYN-ACK），你說「有聽到，開始說吧」（ACK）—— 然後才開始真正的對話。這三個步驟確保雙方都能收發，才開始傳真正的資料。

TCP 三次握手流程

Client（你的瀏覽器）              Server（Google 的伺服器）

Client → Server : SYN
  「我想跟你連線，序號從 1000 開始」
                                    ↓
                   Server → Client : SYN-ACK
                     「收到了！我的序號從 2000 開始
                      確認你的序號是 1001」
                                    ↓
Client → Server : ACK
  「收到！確認你的序號是 2001」

[連線建立，雙方都確認能收發，可以開始傳 HTTP 資料了]

為什麼需要三次，不是兩次？

這是個好問題，很多面試官會追問。用情境解釋：

兩次握手的問題

1. Client 發 SYN（舊的，因為網路延遲才到）
2. Server 收到，回 SYN-ACK，以為連線建立
3. 但 Client 早就放棄這個連線了（太舊了）
4. Server 白白開著一個半連接等 Client，浪費資源

三次握手的保障

1. Client 確認 Server 收到了 SYN（靠 SYN-ACK）
2. Server 確認 Client 收到了 SYN-ACK（靠 ACK）
3. 雙方都確認對方能收發，才建立連線
4. Server 不會為舊的 SYN 白開連線

TCP vs UDP——什麼時候不需要握手？

TCP 可靠但較慢（三次握手的額外往返）。UDP 直接送不管有沒有收到，很快但不可靠。視訊通話、線上遊戲、DNS 查詢用 UDP—— 偶爾掉幾個封包比等重傳更可接受。一般網頁（HTTP/HTTPS）用 TCP—— 確保資料完整很重要。HTTP/3（QUIC 協議）則是在 UDP 上自己實現可靠傳輸，兼顧速度和可靠性。

CDN——讓台灣連美國網站也快

比喻：McDonald's 在全球各地都有分店，你不用飛去美國總部買漢堡。 CDN（Content Delivery Network）就是網路的麥當勞—— 把內容分發到全球各地的伺服器，你連最近的那台就好。台灣的用戶連台灣的 CDN 節點，不需要跨太平洋連美國，延遲從 200ms 降到 20ms。

CDN 怎麼知道要回應哪台伺服器？

這裡 DNS 又出現了。CDN 的神奇之處在於：相同的域名，對不同地區的用戶，DNS 會回傳不同的 IP。

CDN 工作原理——從 DNS 到就近節點

你（台灣用戶）請求 cdn.example.com/image.jpg

Step 1. DNS 解析
  你的 DNS 請求打到 CDN 的 Authoritative DNS
  CDN DNS 根據你的 IP 判斷地理位置：「這個 IP 在台灣」
  回傳距你最近的 CDN 節點 IP：例如 Cloudflare 台北節點

Step 2. 連線到就近節點
  你連到台北的 CDN 伺服器（延遲 < 30ms）
  而不是美國的原始伺服器（延遲 ~200ms）

Step 3. 快取命中或回源
  [快取命中] CDN 已有這個檔案的副本 → 直接回應，超快
  [快取未命中] CDN 去原始伺服器拿 → 存起來 → 回應給你

同一個請求：
  無 CDN：台灣 → 美國伺服器（200ms）
  有 CDN：台灣 → 台北 CDN 節點（20ms）

靜態資源加速

圖片、CSS、JS、字型這類不常變的東西最適合 CDN。一旦快取就可以服務全球用戶。

DDoS 防護

大量惡意流量打進來，CDN 節點分散吸收，原始伺服器看不到攻擊。Cloudflare 就是這樣保護網站的。

Edge Computing

現代 CDN（Cloudflare Workers、Vercel Edge）甚至可以在節點上執行程式碼，讓計算也在用戶附近完成。

完整流程總覽——把這些全串起來

你輸入 google.com，按下 Enter

瀏覽器先查自己的 DNS 快取，有就跳過後面幾步

DNS 解析：名字 → IP

瀏覽器 → OS → Router → ISP Resolver → Root DNS → .com TLD → Google Authoritative DNS → 142.250.185.14

CDN 介入（如有）

DNS 根據你的地理位置，回傳最近的 CDN 節點 IP，不一定是 Google 美國總部

TCP 三次握手

SYN → SYN-ACK → ACK，確保雙方都能收發，建立可靠連線

TLS 握手（HTTPS）

協商加密演算法、驗證伺服器憑證、交換金鑰，建立加密通道（詳見 EP.03）

HTTP Request

GET / HTTP/2 帶上 Headers，伺服器回傳 HTML

瀏覽器渲染

解析 HTML → DOM，下載 CSS/JS，計算 Layout，繪製畫面，頁面出現

面試回答建議

面試時不用把每一步說得一樣詳細。重點是：先給出完整的步驟清單（讓面試官知道你有全局觀），再針對你最熟的部分（DNS、TCP、HTTP）深入說明。如果對方追問某一步，再展開說。

能說出「DNS 分層查詢」、「TCP 三次握手的必要性」、「CDN 透過 DNS anycast 實現就近存取」的候選人，已經比大部分人說得更完整了。

網路DNSIPTCP三次握手CDNPort面試必考網路系列EP.02

EP.01 HTTP 深挖

EP.03 HTTPS 與 TLS

你輸入 google.com接下來 0.1 秒發生了什麼？