所謂的 HTTP/HTTPS 差異到底在哪？

大部分人針對這個問題的回答應該都是，多一個加密、比較安全類的，但實際究竟差在哪呢，就從今天的文章來一探究竟吧！

舉例

假設現在是登入送出帳密 / 呼叫 API
而情境是表單 POST 到 /login，或前端呼叫 /api/orders

用 HTTP 會像:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=amy&password=123456

帳密是明文串在網路上，任何中間人都能竊取或竄改，然而伺服器回的 Set-Cookie: session=... 都有機會被旁路讀取與盜用。

但如果是用 HTTPS，整個 POST 內容與 Cookie 都在 TLS 通道中加密傳遞。並搭配 Set-Cookie: Secure; HttpOnly; SameSite=... 可降低竊取與 CSRF 風險，因為中間人看不到帳密或 API 請求、回應內容，也無法無痕跡地插入或修改資料。

簡單一點我們用差異一覽表來說明

運作原理

1. HTTP 是什麼？

文謅謅的說法是**"應用層的文字協定"**：定義動詞（GET、POST…）、狀態碼（200、404…）、標題、主體等。
重點是明文傳輸，因為沒有內建加密或身分驗證，所以安全性風險高，語義也相對簡單。

2. HTTPS 是什麼？

HTTP over TLS：把同樣的 HTTP 語義包在 TLS 加密通道裡。
對應端口 443，實務上幾乎與 HTTP/2 、 HTTP/3 一起使用，而這兩個也相對複雜。

3. TLS 1.3（現今主流）

ClientHello 會告訴伺服器支援的密碼套件、TLS 版本、擬用的 ALPN（要用 HTTP/2 還是 HTTP/1.1）、以及 SNI 目標網域。
而 ServerHello + Certificate 中伺服器選定密碼套件，送出憑證鏈（X.509），並進行金鑰 ECDHE 的交換。

主要的作法是驗證與產生金鑰，讓瀏覽器檢驗憑證，從簽發 CA、到期、撤銷/OCSP Stapling、SAN 主機名比對等，然後使雙方用 ECDHE 產生**"對稱金鑰"**。

再來是加密通道就緒後的 HTTP 請求和回應都在此對稱金鑰下用 AEAD 進行加密與驗證。
其中有個步驟是快取與續用，當會話重復用 0-RTT 會有重放風險，只能用在冪等請求。
但要注意的重點是，公開金鑰只用於建立安全的對稱金鑰，真正大量資料傳輸會使用對稱加密，來提升效率，而且是提升非常多。

4. 憑證與信任鏈

站台內會有一張由受信任的 CA 簽發的憑證，憑證中包含網域 SAN、到期日、公鑰等。瀏覽器會內建憑證清單 → 驗證中間憑證 → 站台憑證，最後形成信任鏈。倘若憑證過期或網域不符，又或者是自簽或被撤銷，瀏覽器會出現紅色警告。

5. 為何 HTTPS 有時反而更快？

HTTP/2 的多工、Header 壓縮（HPACK/QPACK）與連線重用，常把握住 TLS 1.3 的低往返延遲優勢。使 CDN 在邊緣節點終止 TLS，縮短傳輸距離，所以才常常出現實務表現常優於 HTTP/1.1 的情況。

6. 實作工程與架構

全站強制 HTTPS：HTTP → 301 轉址到 HTTPS，並啟用 HSTS（含 Preload）。
只留 TLS 1.2/1.3，關閉舊協定與弱加密套件，並優先 AEAD。
正確的憑證管理：自動簽發、續期、OCSP Stapling、密鑰輪替。
安全 Cookie：Secure、HttpOnly、SameSite=Lax/Strict，避免會話外洩與 CSRF。
避免混合內容：所有子資源一律走 HTTPS，CDN、圖檔、腳本都要升級。
觀測與調優：啟用 HTTP/2/3、ALPN，使用 CDN 邊緣節點。