【網(wǎng)絡(luò)協(xié)議】【http】【https】TLS1.3

TLS1.3它的簽名算法和密鑰交換算法，默認(rèn)情況下是被固定了下來的，他的加密套件里面呢，只包含了對稱加密算法和摘要算法
客戶端和服務(wù)器第一次連接 仍然需要1RTT ，不能0-RTT

第一次連接

1.客戶端 Hello
客戶端向服務(wù)器發(fā)送 ClientHello 消息
1.TLS 版本（TLS 1.3）。
2.密碼套件（TLS 1.3 只協(xié)商對稱加密算法和摘要算法）。
3.隨機(jī)數(shù)（Client Random）。
3.Key_Share：客戶端生成 ECDHE橢圓曲線支持的橢圓曲線列表和對應(yīng)的公鑰對

2. 服務(wù)器 Hello
服務(wù)器收到 ClientHello 后，返回 ServerHello
1.TLS 版本（TLS 1.3）。
2.選擇的密碼套件（僅對稱加密算法和摘要算法）。
3.服務(wù)器隨機(jī)數(shù)（Server Random）。
4.服務(wù)器選定的橢圓曲線。服務(wù)器 ECDHE 公鑰。(此時(shí)根據(jù)這些數(shù)據(jù)計(jì)算出會話密鑰了，參考上一篇文章）
5.服務(wù)器證書（用于身份認(rèn)證）。
6.Certificate Verify（服務(wù)器使用私鑰簽名消息，證明身份）。
7.Finished 消息（包含握手?jǐn)?shù)據(jù)的摘要，使用會話密鑰加密）。

客戶端和服務(wù)器分別使用 ECDHE 密鑰交換算法：
服務(wù)器根據(jù)客戶端的公鑰，計(jì)算出 共享密鑰 K。
客戶端根據(jù)服務(wù)器的公鑰，計(jì)算出 相同的共享密鑰 K。
共享密鑰 K + 客戶端隨機(jī)數(shù) + 服務(wù)器隨機(jī)數(shù) → 最終的會話密鑰。
由于 ECDHE 算法的特性，雙方計(jì)算出的會話密鑰是相同的。

客戶端驗(yàn)證服務(wù)器身份
1.客戶端使用服務(wù)器證書的進(jìn)行身份驗(yàn)證，確保服務(wù)器的證書可信。
2.確保 Certificate Verify 消息的簽名有效（證明服務(wù)器控制了私鑰）。
3.驗(yàn)證 Finished 消息 的完整性。

3.如果驗(yàn)證通過，客戶端：
發(fā)送 Finished 消息（使用會話密鑰加密，確保完整性）。
服務(wù)器驗(yàn)證該 Finished 消息，如果正確，則握手完成。

4 . 數(shù)據(jù)加密通信(可以直接發(fā)送無需等待回復(fù))
握手完成后，雙方開始 安全數(shù)據(jù)傳輸，所有應(yīng)用數(shù)據(jù)都使用 會話密鑰加密。

如果客戶端之前已與服務(wù)器建立 TLS 1.3 連接，服務(wù)器會發(fā)送 Session Ticket（會話票據(jù)）給客戶端，用于 下次握手時(shí)減少延遲。這就是 0-RTT（Zero Round Trip Time）。

0-RTT 工作流程

服務(wù)器在首次握手完成后，向客戶端發(fā)送：

Session Ticket（會話票據(jù)）：保存握手信息（包括PSK預(yù)共享密鑰）。

客戶端下次訪問時(shí)，可直接發(fā)送：
ClientHello + 0-RTT 數(shù)據(jù)，攜帶 Early data（客戶端請求數(shù)據(jù)），（使用psk加密）立即發(fā)送加密數(shù)據(jù)。
服務(wù)器如果接受 0-RTT 數(shù)據(jù)，就能立即開始數(shù)據(jù)傳輸，同時(shí)繼續(xù)完成 ECDHE 密鑰協(xié)商，確保后續(xù)通信的安全性。
服務(wù)器可選擇拒絕 0-RTT 數(shù)據(jù)，要求客戶端進(jìn)行完整握手。
后續(xù)會話密鑰仍然需要協(xié)商（確保每次通信密鑰不一樣，更安全）

后續(xù)會大概說一下QUIC 基于TLS1.3 和UDP的傳輸層協(xié)議

部分轉(zhuǎn)自：https://zhuanlan.zhihu.com/p/686461033
部分轉(zhuǎn)自：https://www.cnblogs.com/ToTigerMountain/articles/18220849
部分轉(zhuǎn)自：https://xiaolincoding.com/network/2_http/http_interview.html