通訊協定 on Wayne's blog | 偉恩的部落格 | 技術博客

關於 TCP 的三次握手與四次揮手，滿分的回答在此！

Sat, 28 Jan 2023 00:00:00 +0000

參考網站
 參考網站
 參考網站
 參考網站

前言

在面試中，計算機網絡的 TCP 三次握手和四次揮手是很常見的問題，但是在實際面試中，面試官會更願意聽到怎樣的回答呢？詳細程度是怎樣的？

越簡單常見的問題越不可小覷，萬丈高樓平地起，把簡單的問題深入化，才更能拉開與競爭者的距離。掌握了本文講的全部知識點，關於 TCP 三次握手和四次揮手基本就OK 了😊

TCP 與 UDP

講解 TCP 三次握手和四次握手之前，我們先了解一下 TCP 和 UDP 這兩個重量級的傳輸層協議。

💦 用戶數據報協議 UDP（User Datagram Protocol）：
- UDP 在傳送數據之前不需要先建立連接，遠程主機在收到 UDP 報文後，不需要給出任何確認。
- 雖然 UDP 不提供可靠交付，但在某些情況下 UDP 確是一種最有效的工作方式（一般用於即時通信、直播串流），比如：QQ 語音、QQ 視頻、直播等等。
💦 傳輸控制協議 TCP（Transmission Control Protocol）：
- TCP 提供面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束後要釋放連接。
- TCP 不提供廣播或多播服務。由於 TCP 要提供可靠的，面向連接的傳輸服務（TCP 的可靠，體現在 TCP 在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認、窗口、重傳、流量控制、擁塞控制機制，在數據傳完後，還會四次揮手斷開連接用來節約系統資源），這不僅使協議數據單元的首部增大很多，還要佔用許多處理機資源。
- TCP 一般用於文件傳輸、發送和接收郵件、遠程登錄等場景。

TCP 報文段首部格式

TCP 報文段的具體格式大家可以不必都記住，但是其中的幾個控制位與我們接下來要講的三次握手和四次揮手息息相關，大家一定要牢記。

首部固定部分各字段意義如下：

源端口和目的端口：各佔 2 個字節，分別寫入源端口和目的端口。IP 地址 + 端口號就可以確定一個進程地址。
序號/序列號（Sequense Number，SN）：在一個TCP 連接中傳送的字節流中的每一個字節都按順序編號。該字段表示本報文段所發送的數據的第一個字節的序號。初始序號稱為Init Sequense Number，ISN（序號/序列號這個字段很重要，大家留個印象，下文會詳細講解）
例如，一報文段的序號是 101，共有 100 字節的數據。這就表明：本報文段的數據的第一個字節的序號是 101，最後一個字節的序號是 200。顯然，下一個報文段的數據序號應當從 201 開始，即下一個報文段的序號字段值應為 201。
確認號 ack：期望收到對方下一個報文段的第一個數據字節的序號。若確認號為 N，則表明：到序號 N-1 為止的所有數據都已正確收到。
數據偏移（首部長度）：它指出 TCP 報文段的數據起始處距離 TCP 報文段的起始處有多遠。這個字段實際上是指出 TCP 報文段的首部長度。
保留：佔 6 位，應置為 0，保留為今後使用。

⭐ 大家看上圖，保留位的右邊還有 6 個控制位（重要），這是 TCP 用來說明該報文段性質的：

緊急位URG：當 URG = 1 時，表明此報文段中有緊急數據，是高優先級的數據，應盡快發送，不用在緩存中排隊。該控制位需配合緊急指針使用（緊急指針指出本報文段中緊急數據的字節數）
舉個例子：我們需要取消一個已經發送了很長程序的運行，因此用戶從鍵盤發出中斷命令。如果不使用緊急數據，那麼這個指令將存儲在接收 TCP 的緩存末尾，只有在所有的數據被處理完畢後這兩個字符才被交付接收方的應用進程，這樣做就無法實現立即中斷。
確認ACK：僅當 ACK = 1 時確認號字段才有效，當 ACK = 0 時確認號無效。TCP 規定，在連接建立後所有傳送的報文段都必須把 ACK 置為 1。
推送PSH：當兩個應用進程進行交互式的通信時，有時在一端的應用進程希望在鍵入一個命令後立即就能收到對方的響應。在這種情況下，TCP 就可以使用推送（push）操作。這時，發送方 TCP 把 PSH 置為 1，並立即創建一個報文段發送出去。接收方 TCP 收到 PSH = 1 的報文段，就盡快地交付接收應用進程。而不用等到整個緩存都填滿了後再向上交付。
復位RST：當 RST = 1 時，表明TCP 連接中出現了嚴重錯誤（如由於主機崩潰或其他原因），必須釋放連接，然後再重新建立傳輸連接。
同步SYN： SYN = 1 表示這是一個連接請求或連接接受報文。
當 SYN = 1 而 ACK = 0 時，表明這是一個連接請求報文段。對方若同意建立連接，則應在響應的報文段中使 SYN = 1 且 ACK = 1。
終止FIN：用來釋放一個連接。當 FIN = 1 時，表明此報文段的發送發的數據已發送完畢，並要求釋放運輸連接。

TCP 三次握手建立連接

三次握手過程詳解

三次握手的原文是 three-way handshake，整個名詞的可以翻譯為：需要三個步驟才能建立握手/連接的機制。當然，三次握手也可以叫 three-message handshake，通過三條消息來建立的握手/連接。

進行三次握手的主要作用就是為了確認雙方的接收能力和發送能力是否正常、指定自己的 初始化序列號 (Init Sequense Number，ISN ) 為後面的可靠性傳輸做準備。

三次握手過程如下圖：

回顧一下圖中字符的含義：

SYN：連接請求/接收報文段
seq：發送的第一個字節的序號
ACK：確認報文段
ack：確認號。希望收到的下一個數據的第一個字節的序號

剛開始客戶端處於 Closed 的狀態，而服務端處於 Listen 狀態：

CLOSED：沒有任何連接狀態
LISTEN：偵聽來自遠方 TCP 端口的連接請求

第一次握手：客戶端向服務端發送一個 SYN 報文（SYN = 1），並指明客戶端的初始化序列號 ISN(x)，即圖中的 seq = x，表示本報文段所發送的數據的第一個字節的序號。此時客戶端處於 SYN_Send 狀態。

SYN-SENT：在發送連接請求後等待匹配的連接請求

第二次握手：服務器收到客戶端的 SYN 報文之後，會發送 SYN 報文作為應答（SYN = 1），並且指定自己的初始化序列號 ISN(y)，即圖中的 seq = y。同時會把客戶端的 ISN + 1 作為確認號 ack 的值，表示已經收到了客戶端發來的的 SYN 報文，希望收到的下一個數據的第一個字節的序號是 x + 1，此時服務器處於 SYN_REVD 的狀態。

SYN-RECEIVED：在收到和發送一個連接請求後等待對連接請求的確認

第三次握手：客戶端收到服務器端響應的 SYN 報文之後，會發送一個 ACK 報文，也是一樣把服務器的 ISN + 1 作為ack 的值，表示已經收到了服務端發來的的 SYN 報文，希望收到的下一個數據的第一個字節的序號是 y + 1，並指明此時客戶端的序列號 seq = x + 1（初始為 seq = x，所以第二個報文段要 +1），此時客戶端處於 Establised 狀態。

服務器收到ACK 報文之後，也處於 Establised 狀態，至此，雙方建立起了 TCP 連接。

ESTABLISHED：代表一個打開的連接，數據可以傳送給用戶

為什麼要三次握手

三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是數據的發送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。

只有經過三次握手才能確認雙發的收發功能都正常，缺一不可：

第一次握手（客戶端發送SYN 報文給服務器，服務器接收該報文）：
客戶端什麼都不能確認；服務器確認了對方發送正常，自己接收正常。
第二次握手（服務器響應SYN 報文給客戶端，客戶端接收該報文）：
客戶端確認了：自己發送、接收正常，對方發送、接收正常；
服務器確認了：對方發送正常，自己接收正常。
第三次握手（客戶端發送ACK 報文給服務器）：
客戶端確認了：自己發送、接收正常，對方發送、接收正常；
服務器確認了：自己發送、接收正常，對方發送、接收正常。

ISN (Initial Sequence Number) 是固定的嗎？

三次握手的其中一個重要功能是客戶端和服務端交換 ISN(Initial Sequence Number)，以便讓對方知道接下來接收數據的時候如何按序列號組裝數據。

當一端為建立連接而發送它的 SYN 時，它會為連接選擇一個初始序號。ISN 隨時間而變化，因此每個連接都將具有不同的 ISN。如果 ISN 是固定的，攻擊者很容易猜出後續的確認號，因此 ISN 是動態生成的。

三次握手過程中可以攜帶數據嗎？

第三次握手的時候，是可以攜帶數據的。但是，第一次、第二次握手絕對不可以攜帶數據。

假如第一次握手可以攜帶數據的話，如果有人要惡意攻擊服務器，那他每次都在第一次握手中的 SYN 報文中放入大量的數據，然後瘋狂重複發 SYN 報文的話（因為攻擊者根本就不用管服務器的接收、發送能力是否正常，它就是要攻擊你），這會讓服務器花費很多時間、內存空間來接收這些報文。

⭐ 簡單的記憶就是，請求連接/接收即 SYN = 1 的時候不能攜帶數據

而對於第三次的話，此時客戶端已經處於 ESTABLISHED 狀態。對於客戶端來說，他已經建立起連接了，並且也已經知道服務器的接收、發送能力是正常的了，所以當然能正常發送/攜帶數據了。

半連接隊列

服務器第一次收到客戶端的 SYN 之後，就會處於 SYN_RCVD 狀態，此時雙方還沒有完全建立其連接，服務器會把這種狀態下的請求連接放在一個隊列裡，我們把這種隊列稱之為半連接隊列。

當然還有一個全連接隊列，完成三次握手後建立起的連接就會放在全連接隊列中。如果隊列滿了就有可能會出現丟包現象。

SYN 洪氾攻擊

SYN 攻擊就是 Client 在短時間內偽造大量不存在的 IP 地址，並向 Server 不斷地發送 SYN 包，Server 則回覆確認包，並等待 Client 確認，由於源地址不存在，因此 Server 需要不斷重發直至超時，這些偽造的 SYN 包將長時間佔用半連接隊列，導致正常的 SYN 請求因為隊列滿而被丟棄，從而引起網絡擁塞甚至系統癱瘓。

如果第三次握手丟失了，客戶端服務端會如何處理？

服務器發送完 SYN-ACK 包，如果未收到客戶端響應的確認包，也即第三次握手丟失。那麼服務器就會進行首次重傳，若等待一段時間仍未收到客戶確認包，就進行第二次重傳。如果重傳次數超過系統規定的最大重傳次數，則係統將該連接信息從半連接隊列中刪除。

注意，每次重傳等待的時間不一定相同，一般會是指數增長，例如間隔時間為 1s、2s、4s、8s…

TCP 四次揮手釋放連接

四次揮手過程詳解

建立一個 TCP 連接需要三次握手，而終止一個 TCP 連接要經過四次揮手（也有將四次揮手叫做四次握手的）。這是由於 TCP 的半關閉（half-close）特性造成的，TCP 提供了連接的一端在結束它的發送後還能接收來自另一端數據的能力。

TCP 連接的釋放需要發送四個包（執行四個步驟），因此稱為四次揮手(Four-way handshake)，客戶端或服務端均可主動發起揮手動作。

回顧一下上圖中符號的意思：

FIN：連接終止位
seq：發送的第一個字節的序號
ACK：確認報文段
ack：確認號。希望收到的下一個數據的第一個字節的序號

剛開始雙方都處於 ESTABLISHED 狀態，假設是客戶端先發起關閉請求。四次揮手的過程如下：

第一次揮手：客戶端發送一個 FIN 報文（請求連接終止：FIN = 1），報文中會指定一個序列號 seq = u。並停止再發送數據，主動關閉 TCP 連接。此時客戶端處於 FIN_WAIT1 狀態，等待服務端的確認。

FIN-WAIT-1：等待遠程 TCP 的連接中斷請求，或先前的連接中斷請求的確認

第二次揮手：服務端收到 FIN 之後，會發送 ACK 報文，且把客戶端的序號值 +1 作為 ACK 報文的序列號值，表明已經收到客戶端的報文了，此時服務端處於 CLOSE_WAIT 狀態。

CLOSE-WAIT：等待從本地用戶發來的連接中斷請求

此時的 TCP 處於半關閉狀態，客戶端到服務端的連接釋放。客戶端收到服務端的確認後，進入 FIN_WAIT2（終止等待2）狀態，等待服務端發出的連接釋放報文段。

FIN-WAIT-2：從遠程TCP等待連接中斷請求

第三次揮手：如果服務端也想斷開連接了（沒有要向客戶端發出的數據），和客戶端的第一次揮手一樣，發送 FIN 報文，且指定一個序列號。此時服務端處於 LAST_ACK 的狀態，等待客戶端的確認。

LAST-ACK：等待原來發向遠程TCP的連接中斷請求的確認

第四次揮手：客戶端收到 FIN 之後，一樣發送一個 ACK 報文作為應答（ack = w+1），且把服務端的序列值 +1 作為自己 ACK 報文的序號值（seq=u+1），此時客戶端處於 TIME_WAIT（時間等待）狀態。

TIME-WAIT：等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認

🚨 注意！這個時候由服務端到客戶端的 TCP 連接並未釋放掉，需要經過時間等待計時器設置的時間 2MSL（一個報文的來回時間）後才會進入 CLOSED 狀態（這樣做的目的是確保服務端收到自己的 ACK 報文。如果服務端在規定時間內沒有收到客戶端發來的 ACK 報文的話，服務端會重新發送 FIN 報文給客戶端，客戶端再次收到 FIN 報文之後，就知道之前的 ACK 報文丟失了，然後再次發送 ACK 報文給服務端）。服務端收到 ACK 報文之後，就關閉連接了，處於 CLOSED 狀態。

為什麼要四次揮手

由於 TCP 的半關閉（half-close）特性，TCP 提供了連接的一端在結束它的發送後還能接收來自另一端數據的能力。

任何一方都可以在數據傳送結束後發出連接釋放的通知，待對方確認後進入半關閉狀態。當另一方也沒有數據再發送的時候，則發出連接釋放通知，對方確認後就完全關閉了 TCP 連接。

通俗的來說，兩次握手就可以釋放一端到另一端的 TCP 連接，完全釋放連接一共需要四次握手。

舉個例子： A 和 B 打電話，通話即將結束後，A 說"我沒啥要說的了"，B 回答"我知道了"，於是 A 向 B 的連接釋放了。但是 B 可能還會有要說的話，於是 B 可能又巴拉巴拉說了一通，最後 B 說"我說完了"，A 回答"知道了"，於是 B 向 A 的連接釋放了，這樣整個通話就結束了。

網站前端打 API 時把密碼加密，有意義嗎？

Tue, 17 Jan 2023 00:00:00 +0000

參考網站
 參考網站
 參考網站
 參考網站

最近有人在臉書前端交流社群發了一則貼文，內容是他看到了一個問題：請問登入api傳賬號、密碼json明碼會有問題嗎?，想知道大家對這個問題的看法。

而底下的回答大部份都是覺得「有用 HTTPS 就好了，沒必要額外再實作一層加密，沒有什麼太大的意義」.

老實說我以前也是這樣認為的，而且過去在社群中就有出現過類似的討論。我那時候想說都已經有 HTTPS 了，而 HTTPS 本身的目的就是為了保障傳輸的安全，為什麼要自己再做加密？

但這一兩年接觸資安以後，我的想法有了改變，我認為前端在傳輸前把密碼加密，是有其意義的，而接下來我會詳細說明我的理由。

定義問題

在進入正題之前，我想把問題定義得更明確一點，免得出現一堆張飛打岳飛，拿兩個完全不同的情境來比較的狀況。在原文底下，就有不少留言在討論的是不同的問題，把問題先定義清楚滿重要的。

首先，我們要比較的對象是：

在使用 HTTPS 的前提下，打登入 API 時不做任何事直接傳送密碼的明文
在使用 HTTPS 的前提下，打登入 API 時先把密碼加密，再傳送到 server

這邊需要注意的是「兩個狀況都是 HTTPS」，所以如果你想講的是「沒必要自己發明新技術」或是「自己發明新的加密方式不會比較安全」等等，在這個前提下全都不適用。

因為傳輸層還是靠 HTTPS 在傳輸，所以在這個階段並沒有自己發明新的方式，我只是在應用層自己把傳輸的資料額外加密一層而已。

再來，先不考慮成本這件事，純粹只從技術的角度去看可能有哪些優缺點(成本相關的最後再來討論)。

最後呢，我這邊的情境是「加密密碼」而非 hash，這是因為我覺得 hash 的狀況比較複雜，我自己想先用加密來舉例，而且這個加密是「非對稱式加密」。

也就是我們可以想像已經有一把 public key 存在於 client 端(當然，每個人都可以拿得到)，在送出 request 以前，會先使用 JavaScript 把密碼用 public key 加密以後再送出，而 server 使用 private key 解密，拿到密碼以後 hash 過再存入資料庫中。

綜合以上，這篇想處理的問題是：「已經使用了 HTTPS，在打登入 API 以前先把密碼加密過或是不做任何處理，這兩者的差別在哪？」

而我們可以把回答分成兩個部分：

假設 HTTPS 被破解了，是不安全的，差在哪？
假設 HTTPS 是安全的，差在哪？

假設 HTTPS 不安全，差在哪？

首先，可以先想一下怎樣的狀況會造成 HTTPS 不安全，攻擊者掌握了系統的哪些部分？

底下簡單分為四種狀況討論：

攻擊者掌控整台電腦，信任惡意憑證
攻擊者成功執行了中間人攻擊
攻擊者可以在網路層監聽 request 並使用漏洞取得明文
攻擊者直接針對 HTTPS server 進行攻擊

攻擊者掌控整台電腦，信任惡意憑證

若是這種類型的狀況，那當然是有沒有加密都沒差，因為攻擊者都有其他更好的手段去取得你的密碼。

攻擊者成功執行了中間人攻擊

那如果是「攻擊者成功執行了中間人攻擊（Man-In-The-Middle）」呢？你的電腦沒事，只是封包在傳輸的過程中被中間人攻擊。

在這樣的前提底下，沒加密的情形就能直接被獲取密碼，而有加密的情形攻擊者只能獲取到加密過的密文而非明文。但需要注意的是既然是叫中間人攻擊，那攻擊者除了監聽你的 request 以外，也能傳送偽造的 response 給你，把前端用來加密密碼的部分換掉。

因此無論密碼是否加密，攻擊者都可以拿到明文，只是如果有加密的話，攻擊者取得密碼的成本較高（需要先找到在哪邊加密的，然後把那段改掉）。

攻擊者可以在網路層監聽 request 並使用漏洞取得明文

這個狀況跟上一個的不同之處在於這個只能讀，不能寫。若是有辦法解密 request 的封包，就能夠看到明文。

所以如果有把密碼先加密，攻擊者就無法取得密碼的明文。

這邊需要注意的是儘管無法取得明文，攻擊者依然可以透過重送請求來登入你的帳號（先假設沒有其他機制），所以你帳號還是被盜了，只是攻擊者不知道你的密碼明文。

這有差嗎？有！

假設他知道了你的密碼明文，就可以拿你的這組帳號密碼去各個服務都試試看，若是你其他網站也用同一組帳號密碼，就會跟著淪陷（俗稱的撞庫攻擊）。

因此在這個狀況底下，加密密碼的安全性顯然是更高的。

此時你可能會想問的問題是：「那在什麼狀況下攻擊者能夠取得 HTTPS 的明文？真的有可能嗎？」

這邊有一份美國衛生及公共服務部 HHS 所做的簡報：SSL/TLS Vulnerabilities，裡面有記錄一些 SSL/TLS 曾經有過的漏洞，所以取得 HTTPS 的明文確實是有可能的。

不過光是知道「有可能」是不夠的，應該問的是「機率高嗎？」，在討論風險的時候，通常也會根據風險的高低以及嚴重程度來決定該怎麼處理這個風險。

答案是「機率很低」，簡報裡的漏洞最近的已經是 2017 年的事情了，而且是使用一些舊的、有問題的加密演算法，除此之外還需要符合不少其他條件，才能執行攻擊，所以我認為機率確實是很低的。

以 2016 年發表的 DROWN(Decrypting RSA with Obsolete and Weakened eNcryption) 來說，Server 要支援 SSLv2，而攻擊者要能抓到加密過的 TLS connection，符合這些條件以後，進行一大堆運算後就可以解開 900 個 connection 中的 1 個，而運算成本在當時是 440 美金，約 13k 台幣。

總之呢，針對這個狀況，我們可以說：

假設攻擊者可以取得 HTTPS 的明文，那確實自己在應用層加密會更安全，但要符合這個假設的成本很高，發生機率很低

攻擊者直接針對 HTTPS server 進行攻擊

這個分類我指的是在 2014 年發生過的 Heartbleed 漏洞，攻擊者可以藉由 OpenSSL 的漏洞讀取到 server 的記憶體。

這個狀況跟上一個滿像的，如果有在 client 端先加密過密碼，那攻擊者在 server 上讀到的就是加密過後的，不知道密碼明文是什麼。

所以結論跟上個一樣，就是加密密碼會更安全。

中場總結

剛剛我們討論了幾種「HTTPS 變得不安全」的狀況，從以往發生過的案例可以得知「HTTPS 變得不安全」是有可能的。若是攻擊者能夠讀到 HTTPS 傳輸的明文，那在應用層將密碼加密，就能防止攻擊者取得密碼的明文，因此會比沒有加密來得更安全。

如果要講得更詳細，可以從兩個維度去切入，一個是嚴重性（severity），另一個是可能性（possibility）。

以嚴重性來說，不管有沒有加密密碼，只要攻擊者有辦法拿到 request 的內容，你的帳號就已經淪陷了，而有沒有加密唯一的差別只有攻擊者是否能取得明文密碼，有的話就可以執行撞庫攻擊，拿密碼去試更多其他的網站。

而可能性就是「HTTPS 的明文被拿到」這件事的可能性，從過往的經歷以及研究來看，雖然是有可能的，但在 2023 年的今天，機率是很低的。

因此我們現階段的結論應該是：

攻擊者若是可以繞過 HTTPS 拿到明文的 request，那在應用層將密碼加密，確實會比較安全，但要注意的是要達成這個前提非常困難，發生的機率極低。

假設 HTTPS 是安全的

接下來我們討論第二種狀況，那就是假設 HTTPS 是安全的，沒有任何人可以從中間看到明文的內容，這應該也是留言區中大多數人假設的前提。

在這種狀況下，會有哪些風險呢？

有一個現實生活中會發生，而且也確實發生過的風險，那就是 logging。

身為前端工程師，在前端加裝一些 error tracking 的服務是很合理的事情，若是我們直接實作一個「只要伺服器回傳 5xx，就把 request 記錄起來」的機制，如果好巧不巧哪天登入的 API 出現這個狀況，你就可以在 log 裡面看到使用者的明文密碼。

而且不只前端，後端也可能有類似的機制，碰到一些問題就把 request 整個寫到 log 檔去，方便以後查看以及 debug，一不小心密碼就可能被寫進去。

在這種狀況下，在 client 端先把密碼加密顯然是有好處的，那就是在這些錯誤處理的 log 中，被記錄下來的密碼會是密文，除非你有密鑰，否則你是不會知道使用者的密碼的。

我在網路上找到一篇跟我論點一樣的文章：The case for client-side hashing: logging passwords by mistake，裡面有附上很多參考連結，都是以前各大公司不小心把密碼的明文記錄下來的案例。

然後有個小地方稍微講一下，上面這篇做的是「在 client 端 hash」，跟我這篇一開始設定的「在 client 端做非對稱式加密」有點不同，hash 會更安全一點，確保在 server 真的沒人知道你的密碼明文是什麼。

總之呢，在 client 端先把密碼加密或是 hash，可以避免在日誌中不小心出現使用者的密碼明文，這個顯然是個額外的優點。

加密還是 hash？

文章開頭我有提到 hash 的狀況有些複雜，所以我先把情境設定在「對密碼做非對稱式加密」再傳輸，因為對上面我舉的那些例子而言，這兩種情境的差異不大。

舉例來說，HTTPS 被拿到明文內容，無論你對密碼做了非對稱式加密還是雜湊，在攻擊者無法取得伺服器端密鑰的前提之下，都是拿不到明文密碼的。

那為什麼 hash 的狀況有些複雜呢？

假設我們在前端先把密碼 hash 過後再傳到後端，那後端是要直接存進去資料庫嗎？如果直接存進去資料庫，哪天資料庫的內容曝光，攻擊者就拿到這些 hash 過的密碼了。

通常在有加鹽以及雜湊演算法夠強的前提之下，被拿到 hash 的密碼還是能保證一定的安全性，可是在這種情況下，反而變得很不安全。

因為前端傳給後端的內容已經是 hash 過的了，所以攻擊者可以直接拿 hash 過的密碼進行登入，根本不用知道明文是什麼。雖然保護了明文，但失去了原本雜湊的安全性。

因此如果要做 client side hashing，server side 收到後也要再做一次。如此一來，就算資料庫被偷走，攻擊者也沒辦法利用資料庫中的 hash 直接登入。

有些人可能跟我一樣好奇：「做兩次 hash 不會更不安全嗎？」，我們可以看一下 Google 在 Modern password security for system designers 裡面怎麼說：

Have the client computer hash the password using a cryptographically secure algorithm and a unique salt provided by the server. When the password is received by the server, hash it again with a different salt that is unknown to the client. Be sure to store both salts securely. If you are using a modern and secure hashing algorithm, repeated hashing does not reduce entropy.

看起來是還好，問題不大。

總之呢，看起來最安全的但也更複雜的解法就是 client side 先 hash 一次，然後丟到 server 的時候再 hash 一次存進資料庫，如此一來就可以保證：

HTTPS 因為各種原因失效時，攻擊者無法取得明文密碼
在 Server 端，沒有任何人知道使用者的明文密碼
明文密碼不會因為人為失誤被記錄到 log 中

那如果真的比較好用，為什麼沒人在用？

現實生活中，到底有誰在前端做 hash 或是加密？

當我一開始碰到這個問題，講出「怎麼沒人在用」的時候，其實只是「我自己沒碰過有人這樣用」，但實際上我並不知道那些知名網站的登入是怎麼做的。

因此呢，我就直接去看了幾個知名網站的登入機制，我們一起來看一下結果，為了方便觀看，我把跟帳號密碼無關的內容都拿掉了。

我在測試的時候，基本上都是用 test 或是 test@test.com 搭配簡單的密碼如 1234 在測試，然後觀察 request 的內容。

先來看一下 FAANG 吧！

Facebook

API 網址：https://zh-tw.facebook.com/login

請求內容：

1
2


email=test@test.com
encpass=#PWD_BROWSER:5:1673256089:AbJQAJUvZZNvh2dZbeDqdu9dp7HWwyHOl3+0sCGjiHMMjvYdxJokpdHE/O+E5LIbnakRmDWQfV40ZaB31MaNXFYo1b+RI+LHh6MAdDPa4PJ+BesDp4u8B4F4diVQ+q7idbEhT5wTNaU=

沒想到 Facebook 就是有實作前端加密的網站！後面那段 Base64 並不是直接把密碼 Base64，而是把加密過的密碼做 Base64，解出來是這樣：\x01²P\x00\x95/e\x93o\x87gYmàêvï]§±ÖÃ!Î\x97\x7F´°!£\x88s\f\x8Eö\x1DÄ\x9A$¥ÑÄüï\x84ä²\x1B\x9D©\x11\x985\x90}^4e wÔÆ\x8D\\V(Õ¿\x91#âÇ\x87£\x00t3Úàò~\x05ë\x03§\x8B¼\x07\x81xv%Pú®âu±!O\x9C\x135¥

Amazon

API 網址：https://www.amazon.com/ap/signin

請求內容：

1

email=test@test.com&password=1234

Apple

API 網址：https://idmsa.apple.com/appleauth/auth/signin

請求內容：

1

{"accountName":"test@test.com","password":"1234"}

Netflix

API 網址：https://www.netflix.com/tw/login

請求內容：

1

userLoginId=test@test.com&password=1234

Google

API 網址：https://accounts.google.com/v3/signin/_/AccountsSignInUi/data/batchexecute.

請求內容：

1

f.req=[[["14hajb","[1,1,null,[1,null,null,null,[\"1234\",null,true]]]]

看來 FAANG 裡面，只有 Facebook 是有實作的。

接著我突然好奇起其他常用服務的登入有沒有做，底下貼結果。

GitHub

API 網址：https://github.com/session

請求內容：

1

login=test@test.com&password=1234

Microsoft

API 網址：https://login.live.com/ppsecure/post.srf

請求內容：

1

login=test@test.com&passwd=1234

IBM cloud

API 網址：https://cloud.ibm.com/login/doLogin

請求內容：

1

{"username":"test@test.com","password":"1234"}

看來有實作的是少數，那資安廠商呢？資安廠商自己有做嗎？

資安廠商

Kaspersky

API 網址：https://eu.uis.kaspersky.com/v3/logon/proceed

請求內容：

1

{"login":"test@test.com","password":"12345678"}

趨勢

API 網址：https://sso1.trendmicro.com/api/usersigninauth

請求內容：

1

{"email":"test@test.com","password":"12345678"}

Tenable

API 網址：https://cloud.tenable.com/session

請求內容：

1

{"username":"test","password":"1234"}

Proton

這個應該不算資安廠商，但突然很好奇強調隱私的 Proton 是怎麼做的，一看發現好像很複雜。
在登入的時候會先把 username 送過去，拿到一些看起來是 key 的東西。

API 網址：https://account.proton.me/api/auth/info

請求內容：

1

{"Username":"test@test.com"}

1
2
3
4
5
6
7
8


{
 "Code":1000,
 "Modulus":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nu9K5yr97L9VV2ijOSI62tJcewUiRhQa8qJa24baNpGyw0lf3JLiF4fxUHqTErwF9UdoxE0z4Kb147naphylBFddyKsjhzHNcxk2rBw9haiPxD69BrVYm0n+LVlPqmjXFF7btr1H7oqHGX4b4Dy9omL/KaZz/Dco2NEhw0UBhEZbTAs6Ch01ur9XLbSOI7yb6MRsqCehfy82gDTdbPtXvqQsQjg5XoC2Ib2qTYFaU/24mq/gOaMbVuAGX0hBYzr5NpN9ol2XCdHOLg28Xe90+kisg39VV04axy7Ndvh489dC1CxjcWSSpXd6cPJyOn/HH9aPeTZeucBllRGbPgwR6/w==\n-----BEGIN PGP SIGNATURE-----\nVersion: ProtonMail\nComment: https://protonmail.com\n\nwl4EARYIABAFAlwB1j0JEDUFhcTpUY8mAAD1GwEAoC91QCSfXPEuWM13NZvy\nvL9NQIABuSrVOvgJwMhUTnUBAPb4zbIdTYFOQNrPLvonJt2mmRNy4lGcW7uN\n5yHzJ18J\n=Oykn\n-----END PGP SIGNATURE-----\n",
 "ServerEphemeral":"DY6eRYM1bqYZZ5jzZFdWv88tKYP2PnS0y4A+f7/eqMXj8wB2VefV2kfIDrZ5AorWfDzBq4wMtNG2k5dzbT2qWppzpvltrSl2Nm4i8eWIRVxXWHl/46dGuPXFHUcXBNMP3XEQvft0YEbHOPO9Es0RZRaObV5XPFyx6kzOJxXc1tIt4PfbhODMfsAoy/yxt6eLN3HUiORCBOvzsH2sfG99Gx1YSAe3GL6g/K+bdg59eglueXRESoB0/VFRsvQevi9nVXx/JZNTG0U4BBUOlMjpYYMgEP6eQgZZ/09ZPYD3a2tW65mSnNt6lSDfwiKj02UuDqymTvj7mYm44T0SuAocwg==",
 "Version":4,
 "Salt":"dI7OcD+K4rGPBA==",
 "SRPSession":"3fa6224285409b6af07c811971e05341"
}

接著輸入密碼登入時，會送出如下的 request，看起來也很複雜：

1
2
3
4
5
6
7
8
9


{
 "ClientProof":"I9Nfd0Nd3OzODf2nt9zLxFHWogEwfRje8zjoeZnblyLfyzz23uXTjJ4qgRFomjIEEtZrlM1jTQa4wRIMGIIV7E6pMqq8c6wcc2tegP4Xt76S0EbnVtE1F9i0Wj46aCPUM0Mha3Zmgi9LKerrGlaftr2FBedjPFT9rPrbLqRQcFNMD33tn69gD/p28q4RAr3/7d/tz7TYhytD5oxCAUwrkqiZOi0kg//2mUJ9YNT2nWcgqUERoaU51NbNMcaPnMteEe1PlIJdiQbvNa5K07u8rk7itpBrGW2FP26bREp0UMTzNYM5HcDDkmp4dp9GoBjFJL9n0THUdt/oRRJ/Enj5WQ==",
 "ClientEphemeral":"D013N7FXYHylqMeWa6ctJIv3J4uF1hqodyYfw6O+Sj7MZOIB+wksfgk/nkXCmRxQhuSYwqwMJIpyFD3MEolOZAHMU2n6HQlxe9A4KbrE4gk3UiGwfgcZDmFejTmMMxfWhf4zO2Z1fBbohreqwwN0mz3AqqsfE5dsDh3LEfkiJB449YGZfHeUHyIzS1jTmnx/8l6uVSKwJDCJelVFYKMXrxVt0ltcGRoYD92MUj82kR0am+BN4+djHyYYXuwuIYArnTW4kDP3T2yCIAMVgZnFaUCc2gfynt40mQP4q87jmMELOl8TDIDo5iKyH4gJc/470qIuIyj4ffVLiZ7t8S+kcw==",
 "SRPSession":"3fa6224285409b6af07c811971e05341",
 "Username":"test@test.com",
 "Payload":{
 "qcA_CRYU6gSyHWdn":"c6UZSKPo4Sfm/3+DvQN72TTxyj+/TplKT9edDiUI5wMfGUsoJs9FGerOtkoW8T49r7KOvqHkzS2+M2v8ra7J9l5kSf5jgC9ZvgZ8Ja5Xgg02nxgAABydOirGLoL4htFsYVtwLrNg8NeSEanLwYLCVaSqkjANRJks0eaKpUOd8xRhCFtUH/GCbyg27oZfzDsqKXemKprOUsOh42NTqzEmruAkxs2x8mUsLy/vXptVAdaiJLrsSRqD0YBGjvOp4W2/0g6V2zfedJpJEzVwtSi1vXTC5bwxmEJlYdV9AiQECogAAJFxLQi7JjtmgFe4tNcv97JD0B8giZ6XS35swjz0vz0mOjVBUwmiDa8n54Y5kBaAoZe5pijdp2S4SOcRAknDIcD1nf0v7oSMOE9WtH/sa+XI1D2s5lFKo/iInf7r5R9src2hHFoy0b2XT0oCfLPwFX87yjaKbf7bbkjByx/3dOgzEliAkS6nHK+fmeDDVM4EoZqVSKZHLg3QTcg4DKaICyDsotALr2UqI/ARzkX4yhAXz5xHFaxl6hWAKLJPJcgk6il6oX0s0PCBNSY0Fi3vbQvXD4WalUx+LBNto6CUqeAIzVuAh8sCubzufoSORypE5WqfnuJzAlZ9sMEjaQycuRi497aV3jmjgx53UwO0OiZGxDTEMFBcov4P0g1blZ4vxmULhZU0RfdP31udLr6GTCAB90CM6Vk9w9CsYM+hmo3+JpEAtIVgLVVqcPikTbV+yaOJ1RknxBf3g06kTl0LQ+zBV6pG2rFVi8G4XT9L4FsIgxTNsl/ryzs8vJU7K+HvyE1Lp2pAXrfcju7TAIqK/FOXvp1c8Ay9O6d4fmd/PZalnRDv5mQ6Gmd6JSNzNh6i6AibBuF13w3OBaulY3FGNU/cH/AXLBIqjSzf/OySwkKkC9HBurSs3D0zqcH9BwUpmPEL8jbc8yPE+hPAim+tDo1BXCQNClxgGLaI6FXkuCiQ4AHiKsq0xs5b3WAFzcvBv1rc003RWxRegH/2teIooKU9w1kDPQRaK8/rIYe8u+BlBeZq4OwCXxx56JHfmTxtJwBi95KqsWzLGtY3ILcb+/XkzSRmE2TWbkW1IXzRsl8F6NSJj7JnHA3UrQf4hxuwbaYxpKJrcHuHc8e1wxqXrUSKooCOUxwSBgxvLLT37eaByNTxpfWomxIsH671wuydnmMedWyNIqyaMtxBORuiWUiG4jbMC2BjrVptXJ7VWigf3Vy5OQlMOyTx8tLWi1qZODYyywMBAvHYQlFfSqmIrm4y4dmK/srJE/+daEnNS+kWF48Jm/rQORO5AUwqWL+Lefg9pchcL1BnHOANcviO8pAkxLo8TiK7VLKI5/xUsZQoQSlhRt27zMF+sIv+exY375HApiY+a1VQ6OqE4Nvba7O8ETLoLFg4a8Aj+W8erXFHW5F0vVIRphAve9orM4QYnAmOigFAiLb0Pxx124wUjFR9s5oP98hAtNL/t+uGAXrb0oxiCfyHb9wa2Qb0x6o9FpuBIc5ZXId+cEXEvOdqhnUQ7ZuOi/fX81hlqgUaiD/A6P+zjAcREXdktd+hrhSXwCIKSBkp/mNymnalQKJkLaNVT+W2sOWqXxTSTIytCQx36xABcj1BXRApntob6Qvche8QJLTjzr9bDpn+Mo59N9PSU51DPIj5Avre6ChTHEQvjz9s1IM2XroBX/KFBnPj33aYQZyov4uxrVXxic+fiY+fLMF8x1ut/eNWeQU6fn+rU5PEGQ9bbAsjVBZYA5H93ROhO5lnSxoEk5PHkgQ9WpxueckPjJIUGAs+O8QMRFicccfKjhNIc32rXTqbVqLyoz62riDn8Y18MUBoeI8ORyqZOKEEBFsi5dwqoq8t82NFdx5LFjsLdk4RmMXZ2uygNLk8gH2Yyfu3iOQS2bKtNCW42Xmo66Xu5kt8NwAneYQK0mTn6HUv94K10J4hY+Q="
 }
}

補充：經討論串有人提醒後發現這是一個叫做 SRP（Secure Remote Password）的協議，Proton 有提供一個 ProtonMail Security Features and Infrastructure，裡面有記錄他們的安全措施，就有講到這個機制。

看起來滿複雜要花不少時間研究，先放著，有興趣的可以參考：SRP — 更健全的登入及資料傳輸保護協議

雖然更安全，但成本應該又更高了。

交易所與銀行

看完上面案例發現有做的是少數，因此我好奇更注重安全的加密貨幣交易所與傳統銀行有沒有做。

Binance

API 網址：https://accounts.binance.com/bapi/accounts/v2/public/authcenter/login

請求內容：

1
2
3
4
5


{
 "email":"test@test.com",
 "password":"fe2e6b4138fcd7f27a32bc9af557d69a",
 "safePassword":"d404559f602eab6fd602ac7680dacbfaadd13630335e951f097af3900e9de176b6db28512f2e000b9d04fba5133e8b1c6e8df59db3a8ab9d60be4b97cc9e81db"
}

Coinbase

API 網址：https://login.coinbase.com/api/v1/authenticate-credentials

請求內容：

1

{"email":"test@test.com", "password":"1234"}

kraken

API 網址：https://www.kraken.com/api/internal/account/settings/tfa

請求內容：

1

{"username":"test", "password":"1234"}

玉山銀行

API 網址：https://ebank.esunbank.com.tw/fco/fco08001/FCO08001_Home.faces

請求內容：

1
2
3


loginform:custid=A0000...
loginform:name=mxagZmaqygDx0XX6784Svw==__NgZQcFfAx+lQmPza2eNpOA==
loginform:pxsswd=8,lIRnuUxw/yStOt9QIYG2U3Gn2XkG03x4Ey/UU6JGtsbUxfRXoAv9CjE3EWerDN3tfx3dD/B3ChLAPMSG2BA3jMXUCZC06y8UbQ5isKc9fCWZSSZAWWcOmJ7LdXw1ZhjV55hpw1upvAr9WEmZ0XF6x7if+dBxJ4KZ00d83qA9eA+3VaSk+JLhN8/CFBfTKTfJEs3PDNsm12XzRUBb4YE1aPQosVX10mdvh3zY5lmkrKuq8gnuImEf3oLOk4EF3eVpr6jJiFzMKlHybvGdtKYS25+pgTS68wn3v023barbSmgivcv5atm0XsyXWDY2dKEtdQz+7A6R+AB0bExbQlRjqQ==

國泰世華

API 網址：https://www.cathaybk.com.tw/MyBank/Quicklinks/Home/NormalSignin

請求內容：

1
2
3


CustID=A000...
UserId=DC0C6E52BE2A2354C53401207F220F1B
Password=8cf5e1977f149ed0362629007a7f91d0efc7b12cb1895ba701c528a12b38d12f8148ca03ee671fe25d2a3a807be980f7728566e359a675734ce046899b147658388bb60f9b900e2ccc9adac280b54b5f2e28cb7eee1b634d0e1ed1c0c0c598c350f61eb003405559331a7f047add7289466bf42cfd5b9e774a1fa116af4fd7050adb8f174d42a8e2098a014a788bd2ffae3bf4ff7a8d8d7e2e8068402fda395da41be6e5d32f2d32cbee2afc26e82c58b60357b5cb186a3b9cf69df2deb9da8c9fde45337935180cb4e177109413d7a758d38bfc8334a4509d8d8fb6a37080f0e0086b4a5ef68f7809ca2ef97183b7f66d996873bb7dbfcee61d2da424b8b968

中國信託

API 網址：https://www.ctbcbank.com/IB/api/adapters/IB_Adapter/resource/preLogin

請求內容：

1
2
3
4
5
6
7


{
 "rqData": {
 "custId": "A00....",
 "pin": "878dbee38bbb4d77a30ee128f55f7bfe2169e45380d62a75453d3ca175e8ce8b|43d0499147b62adeec4eef3c77d33171b4569d0bdf7bbbe2b8b9bde3d30a26aba69aadfb28dfbaa9a997a0ccf668aaab0b6da582275175272172569a58a60bbfc5ac3a8c6862ce31f86247d7c1adf307e363c0f251fb88c4d39afa6ed0ca0a49e053f4f90000fa77b4e78beaead72ebdf52a13ecb4f20ae9a532947fad8156d5ec69d6763243364e71659079e469d1e01d0c384b0c71f4e9e524890227d82a51a340ef0b48638e05e347d75cb93d4a825a2bce6a90ef47f512351ee2d0d1ea17fb8afd521e427578603ea775191711f81d8dcb18e46b72daf3a49a60e50d12d3887e3bafab3758730f7fb0276373ebe1da01a03162ec8e73a202091a51b7f88d",
 "userId": "bfcdb9b2d6896a3bfb4a6542e8fb2689486d000b11bdc0c7bc336a6534aec74c|1b1a758bb26702bc0ac7cd660da2a72866f2cfdcf3668f2d39a5f8b006854f52a08f418b0a460b36374f95b7a310d73ea9994788698041f524ecd1f153448ab5d51f901a9a08ac2a9ee04c5c273ecb9d4ec1b6a62e9696c6126271e2f8c334fe17ce8b8538139363b90be75c1130cb251ec240bd26c920b52f5be9fc59094ce7d935d826242d69dc1ff7047a5abbf11d3c7de639a14bb10230912903cd948c05b3b3cb0cdb100f979640e291774e623a7109bde7b55bb8a6a373c0ca12820b072132ea61c845e60e26d09c7ee0fe23f7de286cbccb067a86fd1985c5b455f9ae46ce24dc8f52bcb05c205d6a462345162ae82c35e045bf3fd43a297c3edcfe17"
 }
}

美國銀行

API 網址：https://m.globalcard.bankofamerica.com/pkmslogin.form

請求內容：

1
2


username=fcc63767-1a43-4cc6-8c3e-1346350b5274
password=12345678

新加坡星展銀行

API 網址：https://internet-banking.dbs.com.sg/IB/Welcome

請求內容：

1
2


USER_LOGON_NAME=test123
ENCRYPTED_PIN_BLOCK=A8C48B7572A1A53C5A66E9B43365027C7FBF14BF461F480A46781E49648A8F70271A29C374F86FCD55A76ED17B2284B47C799B74475F29749D68631FF7E322177A21EEE8C41D8950638A2828C34A2653D7C9F69F5DA568E42D64CE89FCE8F024217B235835E6F8BC3C536F56361EDF459AFCE9A512BDBACAB2D25423209996C2E84A18EA8446685DAF9FAD4B1D6D8DF0F378EC27D9A81AD4D1A2B91BA3CFD838140A9BD48AD8D38D33B0093110BD1CA2C76F3DE4CBD969A9B0260DB890E9B1A99DC1193BFE9A1EDB3E56F71CB1CD8630558B242B040F733A4A40B2E17DE6DA03A58DEC8BB12DA87BB25971E2DBE5AF7AE6112266A3F9027B449BDF46D8DC0A1A

結論

在隨機想到的 20 個網站中，有 7 個有在前端做加密或是 hash（我懶得看是哪個了，總之有做事就對了），名單是：

Facebook
Proton
Binance
玉山銀行
國泰世華
中國信託
新加坡星展銀行

雖然說 35% 看起來很高，但那是因為銀行佔了大多數，一般網站則是很少實作這個機制。

寫到這邊，可以來下結論了。

第一個結論是：

「在 client 端傳送密碼前先把密碼加密或是 hash，確實能夠增加安全性」

理由是做了以後，能夠達成以下事項：

HTTPS 因為各種原因失效時，攻擊者無法取得明文密碼
在 Server 端，沒有任何人知道使用者的明文密碼
明文密碼不會因為人為失誤被記錄到 log 中

以上都是沒有在 client 加密或是 hash 時做不到的。

第二個結論是：

「確實有些大公司有做這個機制，但是非大多數，不過在銀行業似乎是主流」

這個結論上面有貼完整的資料了，一般的網站很少做這個機制，但還是有人做。

第三個結論是：

「雖然從技術上來看能夠增加安全性，但實際上是否實作，仍然要考慮其他因素」

這因素就是我前面提過的「可能性」還有開頭我講先不談的「成本」。

若是真的比較安全，為什麼一般網站不會實作這個機制？

或許是因為覺得 HTTPS 被攻破的可能性太低，低到可以忽略不計（我相信這是大多數留言的人覺得不需要做的理由，我也同意這點），也或許是成本太高，會增加程式碼複雜度；若是採用加密的方案，也會消耗更多運算的資源在加解密上面，這也是成本。

這就是我覺得應該講清楚的地方。

在前端先做 hash 或是加密，它確實是有優點的，不是多此一舉，也不是沒有意義，更不是讓系統變得更危險。

但這不代表每個系統都該實作這個機制，因為它帶來的效益或許沒有成本高，這個端看各個公司的考量。對大部分的公司來說，與其為了 HTTPS 失效這個極低的可能性去投入成本，不如把時間花在加強其他登入環節的安全性（例如說 2FA 啦，或是不同裝置登錄警告等等），帶來的效益會更高。

有些服務還會選擇把整包 request 都加密，而非只有密碼，這個又更安全但是成本又更高，而且 debug 很不方便。雖然說既然加密做在 client 端，攻擊者一定有辦法逆向這個機制，看出是怎麼做的，但這不代表這些機制沒幫助。

舉例來說，假設我有個搶票 App 不想讓別人知道 API 怎麼呼叫，於是就實作了一個超複雜的加解密機制，儘管高手還是可以做逆向工程，寫出一個搶票機器人，但這個機制增加了他的時間成本以及對技術的要求。

以技術上來說，就算理論上一定會被破解，這些機制還是有意義的，它的意義在於增加破解難度，加殼、混淆都是一樣的，不會因為「在 client 端的東西一定會被看穿」而不去做這些機制。

重點在於你想保護的商業邏輯的價值，有沒有高到你需要付出這些成本去做額外的安全機制。

最後，如果你需要一個條列式的簡單結論，會是：

無論如何，一定要先用 HTTPS
在前端先把密碼做加密或是 hash 後再傳送，能夠增加安全性，但同時也帶來不少成本
如果你是銀行或需要同等安全性，再來考慮要不要做這個，否則極大多數的狀況下，你不需要這個機制就夠安全了，資源投入在其他地方的效益會更大

若是對這個結論有不同意見，或是有在文章中發現哪些邏輯錯誤或技術錯誤，歡迎留言指正與討論，感恩。

補充一下，這篇大多數從技術面來看，除此之外還可以從法遵面或是資安的實務經驗來看，但這些面向我就零經驗了。許願一下有相關經驗的人出來指點迷津，或許會有不同觀點。

面試常見的瀏覽器問題(三) - HTTP/1、HTTP/1.1 和 HTTP/2 的區別

Mon, 19 Dec 2022 00:10:00 +0000

參考網站
 參考網站

從 1989 年起，HTTP 經歷了數代的演化，從 1 到 1.1 再到 2 以及目前的 3，這些不同版本有些什麼不同呢？不管是前端或後端的面試，都是經常會考的。這篇我們會先針對 1 到 1.1 再到 2 之間的異同處做摘要。

出現時間

超文本傳輸協定 HTTP (HyperText Transfer Protocol) 是在網際網路中用來通信數據的基礎。HTTP 一開始的發展是從 1989 年所發起制定，其中經過幾個時期的演進，HTTP/1.1 是隨著在 1999 年 6 月公布的 RFC 2616 所發表。HTTP/2 (最初命名為 HTTP 2.0) 則是在 2015 年 5 月以 RFC 7540 正式發表，並取代 HTTP/1.1 成為 HTTP 的實作標準。截至 2021 年 10 月，全球有 46.5%的網站支援了 HTTP/2 (wiki)。

HTTP/1 和 HTTP/1.1 差異

往下讀之前，要先理解之所以會有 HTTP/1.1 是因為 HTTP/1 有一些不那麼理想的地方。因此建議不要死背差異，而是從「 HTTP/1.1 解決了什麼問題」出發來理解。

持久連接 (keep-alive)

HTTP/1 在發送每個請求之前都需要建立一個新的連接，而每次連接都是有成本的，這種每次重連的方式會造成很多頻寬的浪費，以及時間的延遲。而 HTTP/1.1 默認使用持久連接，讓 HTTP/1.1 可以使用同一個 TCP 連接來重複多個 HTTP 請求，這麼一來就可以避免每次重新建立連接造成的頻寬浪費、時間延遲。

狀態碼 100 (Continue)

在某些情況下，伺服器端會拒絕客戶端發送的請求，因為發請求時可能會夾帶正文 (request body)，所以每次請求被拒絕都會造成頻寬上的額外浪費。在 HTTP/1 沒有機制避免這種類型的浪費，而 HTTP/1.1 的 100 (Continue) 狀態碼則可以協助我們避免這種浪費。具體來說，HTTP/1.1 讓使用者端先送出一個只含有標頭、不帶內文的請求到伺服器，伺服器確認沒有問題之後，會回應狀態碼 100 (Continue)；收到 100 (Continue) 後，客戶端才會正式發一個帶有正文的請求；如果沒有收到，則代表伺服器端不接受該請求，這讓客戶端知道伺服器端不接受，這能讓客戶端可以避免發帶有正文的請求，進而減少傳輸上的頻寬浪費。(詳細請見 RFC 的這個段落)。

快取緩存

HTTP/1 主要使用標頭中的 If-Modified-Since、Expires 來做為緩存的判斷標準，這兩者都是以時間作為依據；HTTP/1.1 則引入更多的緩存策略，例如：Etag、If-Unmodified-Since、If-Match、If-None-Match，透過這些可以更優化緩存的實現 (這些標頭的使用在面試也很常考，詳見這篇文章)。

Host 字段

HTTP/1.1 增加了 Host 字段，用來指定伺服器的域名。在 HTTP/1 中，會認為每台伺服器都綁定唯一的 IP 地址，因此請求當中的 URL 並沒有傳遞主機名(hostname)。但隨著之後虛擬主機技術的演進，現在在一台伺服器上可以存在多個虛擬主機，並且他們會共享同一個 IP 地址。所以有了 host 字段之後，就可以將請求發往同一台伺服器上的不同網站。

HTTP/2 和 HTTP/1.1 比較

多路復用(Request multiplexing) 來解決頭部阻塞 (head-of-line blocking)

HTTP/1.1 使用了 pipelining 的機制，這可以讓客戶端在同一個 TCP 連接內並行發出多個 HTTP 請求，客戶端也不需要等待上一次請求結果返回，就可以發出下一次請求，但伺服器端必須依照接收到的客戶端請求的先後順序一次返回，以保證客戶端能夠區分出每次請求的回應內容，但這項機制在實作上較難實現，因此各家瀏覽器，都將此功能預設為關閉。(可以參考此篇 stackoverflow)。此外 pipeline 也造成頭部阻塞(head-of-line blocking ( HOL ))問題，如果有任一個請求要操作很久或傳輸包流失，那就會阻塞整個 pipeline 的工作。

HTTP/2 引進了多路復用的機制，讓同一個 TCP 連接中，同時發送和接受多個請求，並且不用等到前一個請求收到回應，透過這個機制，解決了過往在 HTTP 層級的的頭部阻塞問題 (備註：但 TCP 層級仍有頭部阻塞問題，這會在 HTTP/3 被解決)。

優先請求順序

HTTP/2 版本中，每個請求或回應的所有數據包，稱之為一個數據流，並且，每個數據流擁有一個唯一編號 ID (stream ID)。每個數據包在發送的時候就會戴上對應的數據流編號 ID，客戶端還能指定數據流的優先級，優先級越高服務器也會越快做出回應。

在 HTTP/2 之前因為安全性問題，多數不會對標頭的訊息進行壓縮，主要是過去的採用的演算法可能遭受 CRIME 攻擊。在 HTTP/2 中，使用 HPACK 算法來避免攻擊，進而能壓縮標頭。因為壓縮標頭，讓傳輸時能大幅減少傳輸的訊息量，進而減少頻寬負擔，也增快傳輸速度。具體上 HPACK 使用一份索引表來定義常用的 http header，並把 http header 存放在表裡，請求的時候只需要發送在表裡的索引位置即可，不須用傳完整的標頭。

伺服器主動推送(Server push)

HTTP/2 允許伺服器端主動向客戶端推送數據，這能協助減少客戶端的請求次數。舉例來說，瀏覽器在過去要請求 index.html 與 style.css 來渲染完整的畫面；透過 Server Push，可以在瀏覽器請求 index.html 時，也由伺服器主動發送 style.css ，這樣只需要一輪 HTTP 的請求，就可以拿到所需的所有資源。

初學者都該了解的 HTTP 通訊協定基礎

Sun, 24 Jul 2022 00:00:00 +0000

參考網站 - 初學者都該學會的 HTTP 通訊協定基礎
 參考網站 - Http/2 是什麼?

目前 HTTP 通訊協定的版本

HTTP/0.9
- 於 1991 年發表(已廢止)
HTTP/1.0
- 於 1996 年 5 月發表(RFC 1945)
HTTP/1.1
- 於 1997 年 1 月發表(RFC 2068)
- 於 1999 年 6 月發布 HTTP/1.1 更新版(RFC 2616)
- 於 2014 年 6 月再次更新 HTTP/1.1 並將規格文件拆成六份
HTTP/2(Wikipedia)
- 於 2015 年 5 月發布(RFC 7540)(瀏覽器相容性)
- 僅針對 HTTP/1.1 的 Message Syntax 部分作出強化

HTTP/0.9 (已廢止)

概要

於 1990 年由 Tim Berners-Lee 提出最初的 HTTP 建議(WWW)
實作重點
- 用戶端要求是以 ASCII 字元為主(單行命令即可發出請求 GET/)
- 用戶端要求會以一個 換行字元 (CRLF) 來結束
- 伺服器回應是以 ASCII 字元為主，回應內容是 HTML 文件
- 每次執行完 Request / Response 就會自動關閉連線
主要特色
- Client / Server 架構、Request / Response 協定
- 跑在 TCP/IP 上的 ASCII 協定 (要求/回應)
- 被設計用來傳輸 HTML 文件
- 每完成一次 ASCII 協定就會自動關閉連線

使用 bash 測試

1
2
3
4
5
6
7
8


# 建立連線到 google
$ telnet google.com 80
> Connected to google.com.
> Escape character is '^]'.

# 發送 GET 請求
$ GET /about
> ...

HTTP/1.0

概要

在 1991 到 1995 年之間，所謂 瀏覽器 騰空出世！
於 1996 年 5 月發表 HTTP/1.0 版 (RFC 1945)
與 HTTP/0.9 不同的部分
- 用戶端要求是以 ASCII 字元為主，但可發送多行命令(含要求標頭)
  - 先送出要求方法，再送出要求標頭，最後以一個額外的換行字元結束
- 伺服器回應是以 ASCII 字元為主，回應內容會區分為
  - 狀態列
  - 回應標頭
  - 回應內文主體(不僅僅是 HTML 文件，可以是更多內容類型)
- 每完成一次 Request / Response 交握就會自動關閉 TCP/IP 連線

使用 bash 測試

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 建立連線到 google
$ telnet google.com 80
> Trying 172.217.24.14...
> Connected to google.com.
> Escape character is '^]'.

# 發送 GET 請求
$ GET /about HTTP/1.0
Host: www.google.com # 因一個 domain 可以 hosting 多個網站，因此通常都會於 request header 再標記 Host

> HTTP/1.0 301 Moved Permanently
> ...

# 取得後，會自動中斷 TCP 連線
# 若需再發送請求，需重新建立 TCP 連線
$ telnet google.com 80
...

HTTP/1.1

概要

於 1997 年 1 月發表 HTTP/1.1 版 (RFC 1945)
於 1999 年 6 月發布 HTTP/1.1 更新版 (RFC 2616)
與 HTTP/1.0 不同的部分
- 傳輸協議的效能改進(新增不少 HTTP 標頭定義)
  - 持續連線狀態(persistent connection)
  - 切塊編碼傳輸(chunked encoding transfer)
  - 位元範圍請求(byte range request)
  - 額外快取機制(cache control)
  - 請求管線作業(request pipelining)(需搭配持續連線狀態特性才能用)

使用 bash 測試

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 建立連線到 google
$ telnet google.com 80
> Trying 172.217.24.14...
> Connected to google.com.
> Escape character is '^]'.

# 發送 GET 請求
$ GET /about HTTP/1.1
Host: www.google.com # 因一個 domain 可以 hosting 多個網站，因此通常都會於 request header 再標記 Host

> HTTP/1.0 301 Moved Permanently
> ...

# 取得後，不會自動中斷 TCP 連線，可再發送請求
$ GET /abc HTTP/1.1
Host: www.google.com # 因一個 domain 可以 hosting 多個網站，因此通常都會於 request header 再標記 Host

> HTTP/1.1 404 Page Not Found
> ...

目前 HTTP/1.1 的六大規格

RFC 7230 HTTP/1.1：Message Syntax and Routing
RFC 7231 HTTP/1.1：Semantics and Content(最重要)
RFC 7232 HTTP/1.1：Conditional Requests
RFC 7233 HTTP/1.1：Range Requests
RFC 7234 HTTP/1.1：Caching
RFC 7235 HTTP/1.1：Authentication

關於 HTTP 通訊協定的基本常識

無狀態特性(stateless)：相同的 request，都會得到相同的 response，不會因為狀態不同而改變
分散式架構(distributed)：相同的 request，不同載體發送，都會得到相同的 response
協作的架構(collaborative)：不一定只有 client / server，也可以是 client / proxy / reverse proxy / server
超文本(hypertext = not just “text) but with “links”)：除了內容，還包含連結

初學者應了解 HTTP 的基本運作方式

如何發出 HTTP 要求(HTTP Request)
- 要求方法(Request Methods)
  - GET、POST、PUT、DELETE、PATCH、…
- 要求標頭(Request Headers)
  - Connection、COntent-Type、…
- 斷行符號(CRLF)
- 要求內容主體(Request Body)
如何回應 HTTP 訊息(HTTP Response)
- 回應狀態碼(Response Status Codes)
  - HTTP/1.1 200 OK
- 回應標頭(Response Headers)
- 斷行符號(CRLF)
- 回應內容主題(Response Body)

HTTP/2

HTTP/2 各個瀏覽器的支援度

點我查看瀏覽器支援度

Edge / Firefox / Chrome / Opera 皆在 2015 年起就支援 HTTP/2，基本上不需要太擔心主流瀏覽器的支援性問題。

PS：如何在 Node.js 中使用 HTTP/2

HTTP/2 改善了什麼？

http/2標準發布於2015年5月，其主要目的是透過一些措施改善瀏覽器瀏覽網頁 加載的速度(page load) 。目前大多數的瀏覽器已支援 http/2 (chrome, firefox, safari等)標準，又 http/2與 http/1.1有著高度的相容信，舉凡request method(post, get..etc), http status code, url, header 等等，因此對於web developer來說，只需要確保你的網站有支援https(因為瀏覽器只支援https 在http/2上)。那麼http/1.1與http/2到底相差多快呢，點我體驗!

HTTP/2 是如何改善？

只需要單一網路連線 (Single TCP connection)

只需要單一網路連線，就可以連接網站伺服器，下載所有需要的資源。大大節省 HTTP/1.1 需要一直建立多個網路連線時的啟動時間浪費。

Request and response multiplexing (多路複用)

在 http/1.1 中，client 端時常會同時發起多個 request 至 server 拿取檔案(像是js, css, image等)，以此方式達到快速載入頁面。如下圖在 http/1.1 中會同時與 server 建立3個 TCP connection，但是瀏覽器通常會限制 TCP connection 同時建立的數目。因此在 http/2 協定中，允許 client 端與同一 server 建立單一 TCP connection 並以非同步方式傳輸要的檔案。

優先權設計 (Prioritization)

伺服器可以決定例如 CSS 或 JavaScript 檔案，哪些要優先傳送。

Header compression (標頭壓縮)

每一個 http 的傳輸中都會攜帶一組 header，在 http/1.1 中，header 會是以明文(plain text)傳輸大小通常會是500-800 bytes，若有攜帶 cookie 也有可能會更大。因此在 http/2 中，會將 request 以及 response 的 header 使用 HPACK 演算法壓縮 header 的內容，此方法壓縮後可以減少 85%-88% 的大小。

Server push (伺服器推送)

在 http/1.1 中，通常 client 端 request 甚麼 server 就會回傳甚麼，例如: 當 client request html 那麼 server 將只會回傳 html。但在 http/2 中，允許 server 主動推送有相關的資料給 client，例如: 當 client 只 request html，但是 server 知道 client request 此 html 後續也會 request css, js 等，因此 server 就會在 client 沒有 request 的情況下主動推送 css, js 檔給 client。那 server 怎麼知道這些檔案是有相關性的呢? web developer 將需要 server push 的檔案加上特定的描述即可。(描述)

不過，這個功能比較有爭議，一來他需要 Web 開發者額外描述有哪些檔案需要隨著 HTML 一起推送給瀏覽器，不是 Web 伺服器升級 HTTP/2 就自動會有。二來它不管瀏覽器是不是已經有快取這個資源，都會推送而造成頻寬浪費。因此實務上筆者認為可以改用瀏覽器的 Prefetch 功能，讓客戶端的瀏覽器自己處理即可。

Binary framing layer (二進制影格層)

在 http/2 中，header 與 body 所挾帶的 property 與 http/1.1 相同(ex. verbs, methods)，然而兩者在傳輸上會有不同。在 http/2 中，會將 header 以及 body 編碼成二進制在 server 與 client 端中傳輸，在 http/1.1 中，則是以明文的方式傳輸。將訊息編碼成二進制進行傳輸，此特性是 http/2 的其他特性的根本基礎。

冷知識：在 HTTP/1.1 定義了四種解析訊息的方式，在 HTTP/2 只需要一種。

總結

根據 w3Techs 網站，目前使用http/2的網站有45.7%，未來確實會變成主流，身為軟體工程師，還是多少理解來的好。此篇文章僅記錄筆者蒐集資料彙整結果，若有任何錯誤資訊還請直接點出，萬分感謝。

通訊協定 on Wayne's blog | 偉恩的部落格 | 技術博客

關於 TCP 的三次握手與四次揮手，滿分的回答在此！

前言

TCP 與 UDP

TCP 報文段首部格式

TCP 三次握手建立連接

三次握手過程詳解

為什麼要三次握手

ISN (Initial Sequence Number) 是固定的嗎？

三次握手過程中可以攜帶數據嗎？

半連接隊列

SYN 洪氾攻擊

如果第三次握手丟失了，客戶端服務端會如何處理？

TCP 四次揮手釋放連接

四次揮手過程詳解

為什麼要四次揮手

網站前端打 API 時把密碼加密，有意義嗎？

定義問題

假設 HTTPS 不安全，差在哪？

攻擊者掌控整台電腦，信任惡意憑證

攻擊者成功執行了中間人攻擊

攻擊者可以在網路層監聽 request 並使用漏洞取得明文

攻擊者直接針對 HTTPS server 進行攻擊

中場總結

假設 HTTPS 是安全的

加密還是 hash？

現實生活中，到底有誰在前端做 hash 或是加密？

Facebook

Amazon

Apple

Netflix

Google

GitHub

Microsoft

IBM cloud

Kaspersky

趨勢

Tenable

Proton

交易所與銀行

Binance

Coinbase

kraken

玉山銀行

國泰世華

中國信託

美國銀行

新加坡星展銀行

結論

面試常見的瀏覽器問題(三) - HTTP/1、HTTP/1.1 和 HTTP/2 的區別

出現時間

HTTP/1 和 HTTP/1.1 差異

持久連接 (keep-alive)

狀態碼 100 (Continue)

快取緩存

Host 字段

更多請求方法

HTTP/2 和 HTTP/1.1 比較

多路復用(Request multiplexing) 來解決頭部阻塞 (head-of-line blocking)

優先請求順序

標頭(Header)訊息壓縮

伺服器主動推送(Server push)

初學者都該了解的 HTTP 通訊協定基礎

目前 HTTP 通訊協定的版本

HTTP/0.9 (已廢止)

概要

使用 bash 測試

HTTP/1.0

概要

使用 bash 測試

HTTP/1.1

概要

使用 bash 測試

目前 HTTP/1.1 的六大規格

關於 HTTP 通訊協定的基本常識

初學者應了解 HTTP 的基本運作方式

HTTP/2

HTTP/2 各個瀏覽器的支援度

HTTP/2 改善了什麼？

HTTP/2 是如何改善？