全球資訊網與 HTTP：一次網頁載入的完整旅程
從 URL、請求-回應、狀態碼到 Cookie、HTTPS，再深入 HTTP/2 多工與 TLS 握手的演進
當你按下 Enter，瀏覽器到底做了什麼？
想像你在咖啡廳打開瀏覽器，在網址列輸入 https://uedu.tw，按下 Enter。不到一秒，一個完整的網頁就出現在眼前：文字、圖片、按鈕、排版，一應俱全。這個過程看似理所當然，但背後其實牽涉到一連串精密的對話：你的瀏覽器找到了遠在某處的伺服器，向它「提問」，伺服器再把答案「寄回」給你。
這套讓全世界數十億台裝置能彼此交談、交換網頁的規則，就是全球資訊網(World Wide Web)與它的核心協定HTTP。理解它，等於理解了現代網路生活的底層運作邏輯。
全球資訊網不等於網際網路
首先要釐清一個常見迷思：全球資訊網(Web)與網際網路(Internet)並不是同義詞。
網際網路是底層的硬體與通訊基礎建設——一張由海底電纜、路由器、Wi-Fi 基地台組成的全球網路，負責把封包(packet)從一台機器送到另一台機器。它就像道路系統。
而全球資訊網是「跑在」網際網路之上的一項服務：它定義了如何用超連結(hyperlink)把文件彼此串連，如何用網址定位資源，如何用統一的協定傳遞網頁。Web 是道路上的一種交通工具，電子郵件、線上遊戲、串流影音則是其他工具，它們共用同一張網際網路。
Web 由三大支柱構成：
- URL：資源的「地址」，告訴瀏覽器要去哪裡找東西。
- HTTP：傳輸的「規則」，定義瀏覽器與伺服器如何對話。
- HTML：內容的「格式」，描述網頁的結構與內容。
URL：每個資源的全球唯一地址
URL(Uniform Resource Locator，統一資源定位符)是我們最熟悉的部分。以下面這個網址為例，拆解它的組成：
https://uedu.tw:443/finance/stock?symbol=2330#chart
└─┬─┘ └──┬──┘ └┬┘ └──────┬─────┘ └────┬────┘ └─┬─┘
協定 主機名稱 連接埠 路徑 查詢字串 片段
- 協定(scheme)：
https，告訴瀏覽器用哪種協定溝通。 - 主機名稱(host)：
uedu.tw，要連到哪一台伺服器。瀏覽器會先透過 DNS(Domain Name System) 把這個名稱解析成 IP 位址。 - 連接埠(port)：
443，伺服器上的哪個服務窗口（HTTP 預設 80、HTTPS 預設 443，通常省略）。 - 路徑(path)：
/finance/stock，伺服器上的哪個資源。 - 查詢字串(query string)：
?symbol=2330，附帶的參數。 - 片段(fragment)：
#chart，頁面內的定位點（這部分不會送給伺服器）。
HTTP：一問一答的請求-回應模型
HTTP(HyperText Transfer Protocol，超文本傳輸協定)的核心是一個極為簡單的模型：請求-回應(request-response)。客戶端(client，通常是瀏覽器)送出一個請求，伺服器(server)回傳一個回應。沒有請求，伺服器不會主動說話。
HTTP 還有一個重要特性：無狀態(stateless)。每一個請求對伺服器而言都是全新的、獨立的，伺服器預設不會記得你上一個請求是什麼。這個設計讓伺服器可以輕鬆擴展（任何一台伺服器都能處理任何請求），但也帶來「如何記住使用者已登入」的挑戰——後面講 Cookie 時會回到這點。
動手看一個例子：一次完整的 HTTP 對話
讓我們看看一個真實的 HTTP 請求長什麼樣子。當瀏覽器要取得 /finance/stock 頁面時，它送出的請求是純文字：
GET /finance/stock?symbol=2330 HTTP/1.1
Host: uedu.tw
User-Agent: Mozilla/5.0
Accept: text/html
Cookie: session_id=a3f8b2c1
第一行是請求行：方法(GET)、路徑、HTTP 版本。接著是一行行的標頭(header)，攜帶額外資訊（你是誰、接受什麼格式、帶了哪些 Cookie）。
伺服器處理後回傳：
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1024
Set-Cookie: session_id=a3f8b2c1; HttpOnly; Secure
<!DOCTYPE html>
<html>
<body><h1>台積電 2330</h1></body>
</html>
第一行是狀態行：版本、狀態碼(200)、原因短語(OK)。接著是回應標頭，一個空行之後，就是回應主體(body)——也就是真正的 HTML 內容。
HTTP 方法：你想做什麼？
HTTP 用方法(method)表達請求的意圖。最常用的兩個：
| 方法 | 用途 | 參數位置 | 特性 |
|---|---|---|---|
GET |
取得資源（讀） | URL 查詢字串 | 安全、可快取、可被書籤記錄 |
POST |
提交資料（寫） | 請求主體 | 通常改變伺服器狀態 |
一個關鍵差異：GET 的參數暴露在 URL 中，會留在瀏覽器歷史紀錄與伺服器日誌裡，因此絕不該用 GET 傳送密碼。POST 把資料放在請求主體，較適合提交表單、上傳檔案。
其他常見方法還有 PUT（更新）、DELETE（刪除）、PATCH（部分更新），它們構成了 RESTful API 設計的基礎。一個重要概念是冪等性(idempotency)：同一個請求執行多次與執行一次結果相同。GET、PUT、DELETE 是冪等的，POST 則不是（連按兩次「送出訂單」可能下兩筆單）。
狀態碼：伺服器的三位數回答
狀態碼(status code)是伺服器對請求結果的簡短回答，分為五大類：
| 類別 | 範圍 | 意義 | 常見例子 |
|---|---|---|---|
| 1xx | 100–199 | 資訊 | 100 Continue |
| 2xx | 200–299 | 成功 | 200 OK、201 Created |
| 3xx | 300–399 | 重新導向 | 301 永久搬移、302 暫時 |
| 4xx | 400–499 | 客戶端錯誤 | 404 找不到、403 禁止、401 未授權 |
| 5xx | 500–599 | 伺服器錯誤 | 500 內部錯誤、503 服務不可用 |
記住一個原則：4xx 是「你（客戶端）的問題」，5xx 是「我（伺服器）的問題」。看到 404 表示你要的資源不存在，看到 500 則表示伺服器自己出錯了。
Cookie 與 Session：讓無狀態的 HTTP「記得你」
前面提到 HTTP 是無狀態的，那為什麼你登入一次後，瀏覽整個網站都不用重新登入？答案是 Cookie 與 session(會話)。
機制是這樣的：
- 你登入成功後，伺服器產生一個獨一無二的 session id，並透過
Set-Cookie標頭把它送回瀏覽器。 - 瀏覽器把這個 Cookie 存起來，之後對同一網站的每個請求都自動附上
Cookie: session_id=...。 - 伺服器收到請求時，用 session id 查出「這是已登入的某某某」，於是知道你是誰。
換句話說，真正的使用者資料（你的帳號、權限）存在伺服器端的 session 裡，瀏覽器只保管一張「號碼牌」(session id)。這個設計也說明了為什麼 session id 的安全至關重要——拿到它就等於冒充你。因此安全的 Cookie 應設定：
HttpOnly：禁止 JavaScript 讀取，防範跨站腳本攻擊(XSS)竊取。Secure：只在 HTTPS 連線傳送，避免被竊聽。SameSite：限制跨站請求攜帶 Cookie，防範跨站請求偽造(CSRF)。
HTTPS：把明信片裝進保險箱
純 HTTP 有個致命問題：所有資料都以明文傳輸。你的密碼、Cookie、瀏覽內容，在傳輸途中的任何一個節點（咖啡廳的 Wi-Fi、ISP、惡意的中間人）都能被看光光。這就像寄明信片，沿途每個郵差都能讀。
HTTPS 是「HTTP over TLS」——在 HTTP 之下加了一層 TLS(Transport Layer Security，傳輸層安全)加密。它提供三重保障：
- 機密性(confidentiality)：資料加密，竊聽者只看到亂碼。
- 完整性(integrity)：資料若被竄改會被偵測。
- 身分驗證(authentication)：透過數位憑證(certificate)確認你連到的真的是
uedu.tw，而不是假冒網站。
憑證由受信任的憑證授權中心(CA, Certificate Authority)簽發，瀏覽器內建了信任的 CA 清單，因此能驗證憑證真偽。這就是網址列那把鎖頭的意義。
前端與後端：一個網頁的兩個世界
最後補上一組重要概念。現代網站的開發通常分為兩端：
- 前端(front-end)：在你的瀏覽器中執行，由 HTML（結構）、CSS（樣式）、JavaScript（互動）構成，負責呈現畫面與使用者互動。
- 後端(back-end)：在伺服器上執行，處理商業邏輯、存取資料庫、驗證權限。例如 Uedu 平台使用 Python 的 Flask 框架。
兩端透過 HTTP 溝通：前端送出請求（常是取得 JSON 資料的 API 呼叫），後端回傳資料，前端再用 JavaScript 把資料渲染成畫面。這種分工讓網頁能像桌面應用一樣流暢，也是「前端工程師」「後端工程師」分工的由來。
重點回顧
- Web ≠ Internet：網際網路是底層硬體道路，全球資訊網是跑在上面的服務，由 URL、HTTP、HTML 三大支柱構成。
- HTTP 是無狀態的請求-回應協定：客戶端提問、伺服器回答，每個請求彼此獨立。
- 狀態碼分五類：2xx 成功、3xx 重導、4xx 是客戶端的錯、5xx 是伺服器的錯。
- Cookie + session 補足無狀態的記憶：伺服器存資料、瀏覽器保管 session id 號碼牌；務必加上
HttpOnly、Secure、SameSite防護。 - HTTPS 用 TLS 提供機密性、完整性與身分驗證，是現代網站的安全基線。
深入探討（研究所視角）
從 HTTP/1.1 到 HTTP/2：對抗隊頭阻塞
HTTP/1.1（1997 年標準化）長期是 Web 的主力，但它有個結構性瓶頸：在單一 TCP 連線上，請求必須依序處理。雖然 1.1 引入了持久連線(keep-alive)讓多個請求複用同一條連線，避免反覆建立 TCP 的開銷，但回應仍須照順序回傳。如果第一個請求很慢（例如一張大圖），後面的請求即使早已準備好也得排隊等待，這稱為隊頭阻塞(Head-of-Line Blocking, HOL blocking)。
當時瀏覽器的權宜之計是對同一網域開 6 條平行 TCP 連線，並把資源拆散到多個網域（domain sharding），但這治標不治本，且每條連線都要付出 TCP 與 TLS 握手的成本。
HTTP/2（2015，RFC 7540，源自 Google 的 SPDY）的核心革新是多工(multiplexing)。它把通訊抽象為串流(stream)：在單一 TCP 連線上，多個請求與回應被切成帶有串流識別碼的二進位訊框(frame)，交錯傳輸、互不阻塞。其他關鍵特性包括：
- 二進位分幀(binary framing)：訊息以二進位訊框傳輸，比 1.1 的純文字更易解析、更省頻寬。
- 標頭壓縮(HPACK)：HTTP 標頭高度重複（如每次都送的
User-Agent、Cookie），HPACK 用靜態與動態字典壓縮，大幅減少冗餘。 - 伺服器推送(server push)：伺服器可主動推送預期會用到的資源（後來因實效不彰逐漸棄用）。
值得注意的是，HTTP/2 解決了應用層的隊頭阻塞，卻無法解決傳輸層(TCP)的隊頭阻塞——一旦底層 TCP 封包遺失，整條連線上所有串流都得等重傳。這個殘留問題正是 HTTP/3 改用 QUIC（建立在 UDP 之上、把多工與遺失復原下放到傳輸層）的動機。
TLS 握手：在不安全的通道上建立信任
HTTPS 的安全來自 TLS，而 TLS 的關鍵是連線開始時的握手(handshake)。問題的核心是：雙方如何在一條可能被竊聽的通道上，協商出一把只有彼此知道的對稱加密金鑰？答案是非對稱加密與金鑰交換的巧妙結合。
以 TLS 1.2 的典型握手為例，簡化流程如下：
- Client Hello：客戶端送出支援的 TLS 版本、加密套件(cipher suite)清單，以及一個隨機數。
- Server Hello + Certificate：伺服器選定加密套件，回傳自己的數位憑證（內含公鑰，由 CA 簽署）與一個隨機數。客戶端驗證憑證的簽章鏈，確認伺服器身分。
- 金鑰交換：雙方透過 Diffie-Hellman 等演算法協商出預主金鑰(pre-master secret)。採用 ECDHE（橢圓曲線臨時 DH）時，每次連線用臨時金鑰，即使伺服器私鑰日後外洩，過去的通訊也無法被解密——這個性質稱為前向保密(forward secrecy)。
- 產生對稱金鑰：雙方各自從預主金鑰與兩個隨機數推導出相同的會話金鑰(session key)。
- Finished：交換加密驗證訊息，之後所有應用資料改用快速的對稱加密傳輸。
這裡的設計哲學值得玩味：非對稱加密慢但能在不安全通道建立信任，對稱加密快但需要預先共享金鑰。TLS 因此用非對稱加密「安全地交換對稱金鑰」，再用對稱金鑰「高速地加密大量資料」，兼得安全與效率。
TLS 1.2 完整握手需要兩個來回(2-RTT)，在高延遲網路上明顯拖慢首次連線。TLS 1.3（2018，RFC 8446）將握手精簡為 1-RTT，並支援對重訪網站的 0-RTT 恢復；它同時移除了 RC4、靜態 RSA 金鑰交換等不安全的舊機制，強制要求前向保密。當 HTTP/2 或 HTTP/3 搭配 TLS 1.3，整個「建立安全連線 + 開始多工傳輸」的延遲被壓到最低，這正是當代 Web 效能與安全並進的縮影。
從這個角度回望本文開頭那「不到一秒」的網頁載入：它其實是 DNS 解析、TCP/QUIC 連線、TLS 握手、HTTP 多工請求、前端渲染這一整套機制協同運作的成果。理解每一層，才能在效能調校、資安防禦與系統設計上做出有依據的判斷。