筆記: 三向交握 (Three Way Handshake) 及未來傳輸協議發展閱讀心得

現今主流的傳輸協議為 HTTP / TCP ，其中由於皆為明文傳輸，因此 HTTP 演進為 HTTPS ，

HTTPS 的差別就是利用加密方法來加密，並且利用信任鏈分散流量，例如 A 是可信賴的憑證發行

機構，那麼通過 A 頒發的 B、C、D ，以及 B 頒發的 E、F、G 皆可信任。

接下來說到 TCP 著名的三向交握傳輸方式，區分為客戶端和伺服器端，算是一種互相試探？

的過程。

首先客戶端向伺服器端發送第一次訊息，內容為簡單可辨識的資料 X 。

伺服器端收到 X 之後，發送第二次訊息，包含收到 X 、

傳送簡單可辨識的資料 Y 、嘗試請求資料 Z 。

最後客戶端發送第三次訊息，包含收到 Y、傳送 Z 。

這個過程經過簡化，實際上還有傳送一些其他資訊。在參考資料中提到 HTTP/3，與

HTTP/TCP 相比，差異最大的就是在 UDP 而非 TCP，那麼在加密以及如何省去傳輸內容增加

傳輸速度上就要關心一下。

以下解說引用自參考資料 HTTP/3 傳輸協議 - QUIC 原理簡介：「

初始交握 (Initial Handshake)

在連線的一開始，客戶端會傳送一個哈囉訊息 (CHLO, Client Hello) 到服務端，觸發服務端回傳一個代表交握未建立或是公鑰已經過期的拒絕訊息：REJ 封包，REJ 中包含四比資料：

在客戶端收到 REJ 後，依照 QUIC的定義，雙方就已經完成了交握，可以開始安全的傳輸資料。這是為什麼呢？讓我們看看從 REJ 中客戶端得到了哪些資訊：

服務端的驗證：透過憑證串鏈和數位簽章，客戶端可以驗證服務端的真實性和資料的可靠性。
初始密鑰 (Initial Key)：客戶端在收到 REJ 後，首先要為這次連線隨機產生一個自己的短期DH密鑰，將自己的短期密鑰和服務端的長期公鑰進行運算後，就可以得到一個初始密鑰。(這邊密鑰的交換使用的是 Diffie–Hellman key exchange，如果對這個方法不熟悉的讀者可以參考WIKI連結：Diffie–Hellman key exchange )

」

此篇先以 Diffie-Hellman Key 作一個斷點，還有其他作法為了速度、以及漏封包...等等的改進

機制，容後再議。

為什麼 Diffie-Hellman Key 可以產生安全的通道？以顏色來舉例：首先 A 與 B 選擇了一個起始

顏色，暫定為 C 與 A 決定其秘密顏色 AC ，B 決定其秘密顏色 BC ，然後分別將起始顏色與

秘密顏色混合 C+AC C+BC ，之後交換 C+AC 與 C+BC的結果，最後將得到的混合顏色加入

自己的秘密顏色得到最終結果， A 為 C+BC+AC、B 為 C+AC+BC，兩者相等，第三者無法

從已知資訊 C 及 C+AC 、 C+BC 推導出 AC 與 BC 的值，當然其中有些數字可以很小，有些

則要非常大，但此處只為了理解如何以簡短的流程產生出第三者無法得知的秘密。

參考資料：

筆記