IP 位址
每台連上網路的裝置都有一個 IP 位址，這是它在網路上的唯一身分。封包要送到哪台機器，看的就是 IP。
IPv4 長這樣：
93.184.216.34四組數字，每組 0–255，用小數點隔開。整個 IPv4 空間大約 43 億個位址，早就不夠全球裝置分了。
IPv6 長這樣：
2606:2800:220:1:248:1893:25c8:1946十六進位加冒號，位址多到近乎用不完。目前兩者並存，多數服務同時支援。
問題是，沒有人記得住這串數字。所以才有 Domain 和 DNS，把好記的名字對應到 IP。
Domain 與 DNS
Domain（網域）就是給人看的名字，像 google.com、github.com。DNS（Domain Name System）負責把 domain 解析成 IP 位址。
Domain 的結構要從右往左看：
- TLD（頂級網域）：最右邊，像
.com、.org、.tw - 二級網域：你登記的名字，像
google、github - 子網域：最左邊，像
www、mail、api
拿 mail.google.com 來拆：.com 是 TLD，google 是二級網域，mail 是子網域。
DNS 解析流程
瀏覽器手上沒有 domain 對 IP 的對照表，得一層一層問出來：
順序是：瀏覽器 → Recursive Resolver（ISP 提供的，或像 Google 的 8.8.8.8）→ Root Nameserver → TLD Nameserver → Authoritative Nameserver → 拿到 IP。
看起來要問四層，實際上通常幾毫秒就結束，因為每一層都有快取。查到的結果會照 TTL 設定暫存，在有效期間內就不用重問。
也因為到處都是快取，改 DNS 設定之後不會馬上生效——要等全球各地的快取陸續過期。這段等待期叫 DNS propagation，通常幾小時到 48 小時不等。
TCP/IP
TCP/IP 是網路通訊的基礎協定組，把整個通訊過程切成四層：
各層各管各的事：
| 層級 | 負責內容 |
|---|---|
| 應用層 | HTTP、Email、DNS 等應用協定 |
| 傳輸層 | 資料分段、送達確認、流量控制 |
| 網路層 | 封包路由、IP 定址 |
| 網路存取層 | 實體訊號傳輸（電纜、Wi-Fi、光纖） |
TCP vs UDP
傳輸層有兩大協定，取捨很明確——要可靠還是要快：
| TCP | UDP | |
|---|---|---|
| 全名 | Transmission Control Protocol | User Datagram Protocol |
| 連線方式 | 三次握手建立連線 | 無連線 |
| 可靠性 | 確認送達，遺失重送 | 不保證送達 |
| 延遲 | 較高（確認開銷） | 極低 |
| 適用場景 | 網頁載入、檔案下載 | 線上遊戲、視訊通話 |
TCP 三次握手：Client → SYN → Server → SYN-ACK → Client → ACK。三步走完，雙方都確認對方準備好了，才開始傳資料。
HTTP 與 HTTPS
HTTP（HyperText Transfer Protocol） 定義瀏覽器和伺服器之間講話的格式：
- Request：方法（GET、POST 等）、路徑、Header
- Response：狀態碼（200 OK、404 Not Found 等）、Header、Body
拆開看實際文字格式——Request：
POST /api/login HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 42
{"email":"aira@example.com","pw":"****"}Response：
HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: sid=abc123; HttpOnly; Secure
Content-Length: 25
{"ok":true,"userId":42}注意一件事：HTTP 是明文傳輸，路上經過的每個節點都讀得到全部內容。
HTTPS 就是在 HTTP 底下墊一層 TLS（Transport Layer Security） 加密。建立連線時雙方先協商出金鑰，之後傳的東西全部用這把金鑰加密——就算被攔截，也只是一堆看不懂的密文。
現在幾乎所有網站都應該用 HTTPS。瀏覽器會對 HTTP 網站顯示「不安全」警告，搜尋引擎也偏好 HTTPS 網站。如果你在架站，讓 TLS 憑證這件事盡早處理好。
TLS 憑證可以從 Let’s Encrypt 免費取得，大部分的主機平台（Vercel、Netlify、Cloudflare）都會自動幫你設定好。
CDN
你的伺服器可能放在美國，但你的使用者可能在台灣、日本、德國。物理距離是客觀存在的，光速是有限的，資料要跑 2000 公里，延遲就是比較高。
CDN（Content Delivery Network） 的解法是在全球各地部署快取節點（Edge Node）。使用者連線時，不是直接打去原始伺服器，而是打去離他最近的 Edge Node。
CDN 的核心概念是快取：
- Cache Hit：Edge Node 已經有這份內容的副本，直接回傳，原始伺服器完全不需要介入
- Cache Miss：Edge Node 沒有快取（第一次請求、或快取過期），才回去跟原始伺服器要，取得後再快取起來
靜態資源（圖片、CSS、JS、字型）特別適合 CDN，因為這些檔案不常變動，快取命中率高。
實際上你每天都在用 CDN，只是沒意識到：
- jsDelivr、unpkg：npm 套件的免費 CDN
- Cloudflare：除了 CDN，還提供 DDoS 防護、DNS 管理
- AWS CloudFront：AWS 生態系的 CDN，跟 S3 整合緊密
CDN 不只是速度的問題。當流量突然暴增，CDN 的快取節點可以吸收大量請求，讓原始伺服器不至於被打爆。這也是很多人在網站上線前優先設定 CDN 的原因。
串起來看
把這些拼在一起，你輸入網址按下 Enter 之後發生的事，大概是這樣：
- DNS 查詢：瀏覽器問 Recursive Resolver，最終拿到 IP 位址
- TCP 連線：三次握手，與目標伺服器（或 CDN Edge Node）建立連線
- TLS 握手：如果是 HTTPS，協商加密金鑰
- HTTP 請求：瀏覽器發出 GET 請求，說明要哪個資源
- CDN 回應：如果是 Cache Hit，Edge Node 直接回傳；如果是 Cache Miss，Edge Node 先跟原始伺服器拿，再回傳
- 頁面渲染：瀏覽器拿到 HTML，再繼續請求 CSS、JS、圖片，重複以上步驟
整個流程在 0.幾秒內跑完，每個環節都有相應的技術在背後支撐。理解這個流程不只是知識層面的好奇，也能幫助你在遇到效能問題、網路錯誤的時候，更快判斷問題出在哪個環節。
Latest Updates
- 2026.06.11 Content updated