linux_https，udp，tcp協議（更新中）

https

加密類型

對稱加密

非對稱加密

加密方案

只用對程加密

只用非對程加密

雙方都是用非對程加密

非對稱+對稱加密

非對稱+對稱加密+證書

流程圖

校驗流程圖

udp

udp協議格式

特點

UDP緩沖區

tcp

tcp協議格式

32位序號及確認序號

4位首部

6位標志位

16位窗口大小

16位緊急指針

超時處理

連接管理機制

https

與普通的 “http” 相比，https 通過 SSL/TLS 加密技術對傳輸的數據進行加密處理，能有效防止數據在傳輸過程中被竊取、篡改或偽造，保障用戶在瀏覽網頁、進行在線支付、登錄賬號等操作時的信息安全。

加密類型

對稱加密

加密和解密所用密鑰是相同的。

特點：算法公開，加密速度快，加密效率高

非對稱加密

需要兩個密鑰進行加密和解密。

特點：運行速度非常慢，用公鑰加密要用私鑰解密。

加密本質是通過MD5哈希將文件轉化成定長字符串。

加密方案

只用對程加密

黑客攔截路由器截取內容，不安全

只用非對程加密

公鑰傳遞過程不安全

雙方都是用非對程加密

非對稱+對稱加密

從第三方黑客視角看，對稱與非對稱加密結合的“不安全點”，就是他們想突破的攻擊路徑，核心圍繞偷密鑰、破算法、鉆流程漏洞：
?
- 截獲公鑰篡改：黑客先把自己的公鑰，替換通信雙方交換的公鑰。后續甲方用假公鑰加密“對稱密鑰”發乙方，黑客用自己私鑰解密，拿到對稱密鑰，就能監聽、篡改后續對稱加密的通信內容（中間人攻擊經典套路）。
- 暴力破解弱公鑰：若通信方用的非對稱算法參數弱（比如 RSA 選的密鑰長度不夠），黑客暴力窮舉公鑰相關參數，破解后就能解密出傳遞的對稱密鑰。
?
對黑客來說，找最薄弱的環節突破：要么截胡密鑰傳遞，要么打爆弱算法，要么鉆流程漏洞。只要混合加密在密鑰、算法、實現上有一個環節沒做到位，就成了黑客的“突破口” 。

非對稱+對稱加密+證書

流程圖

?
1. 服務器找 CA 辦證
?
- 誰做：server（網站服務器）
- 干啥：生成自己的公鑰、私鑰，填好域名、自身信息，打包發 CA 申請“身份證明”（證書）
?
2. CA 審核身份
?
- 誰做：CA（證書機構，類似“網絡公安局” ）
- 干啥：查 server 填的信息是否真實（域名是不是你的？身份合法嗎？）
?
3. CA 發“數字身份證”（證書）
?
- 誰做：CA
- 干啥：用自己的私鑰，給 server 的信息“蓋章簽名”，做成證書發給 server（證明：這是真服務器，公鑰合法）
?
4. server 給客戶端“亮證”
?
- 誰做：server
- 干啥：客戶端（瀏覽器/APP ）訪問時，server 把 CA 發的“數字身份證”（證書）給客戶端看
?
5. 客戶端驗“證”
?
- 誰做：client（瀏覽器/APP ）
- 干啥：用內置的 CA 公鑰，檢查證書簽名、有效期、域名（確認：這證是 CA 發的，沒造假）
?
6. 商量加密鑰匙
?
- 誰做：client ? server
- 干啥：驗完證，雙方商量一個“對稱加密鑰匙”，后續通信就用這把鑰匙加密，保證安全
?
一句話總結流程邏輯：
服務器找 CA 辦“網絡身份證”→CA 審核后發帶簽名的證→服務器給客戶端亮證→客戶端找 CA 公鑰驗明證→驗真后商量加密鑰匙，安全通信
（核心就是靠 CA 當“權威擔保人”，讓客戶端相信服務器身份，再加密傳數據～）

校驗流程圖

?一、簽名流程（左邊）
?
1.?算哈希：對原始數據，用“散列函數（比如 MD5、SHA ）”生成固定長度的哈希值（散列值，如 101100110101 ）。作用：把任意長數據壓縮成短串，當數據“指紋”。
2.?私鑰加密：用簽名者的私鑰，加密這個哈希值，生成簽名（如 11110101110 ）。作用：私鑰只有自己有，加密后證明“這是我簽的”。
3.?打包發送：把原始數據 + 簽名 + 認證信息（可選，證明身份的證書），一起打包成“數字簽名的數據”，發給別人。
?
二、驗證流程（右邊）
?
1.?拆包取數：收到“數字簽名的數據”，拆分出原始數據、簽名。
2.?重算哈希：對原始數據，用同樣的散列函數，重新算哈希值（得到 101100110101 ）。
3.?公鑰解密：用簽名者的公鑰，解簽名里的哈希值（得到 101100110101 ）。
4.?對比判斷：對比“重算的哈希值”和“解密得到的哈希值”：
- 一致 → 數據沒被篡改，且是用對應私鑰簽名的（身份合法）。
- 不一致 → 數據被改過，或簽名是假的。
?
一句話總結邏輯
?
簽名：數據→哈希（指紋）→私鑰加密指紋（簽名）→打包發出去
驗證：收到包→拆出數據和簽名→數據重算哈希→公鑰解簽名哈希→對比哈希，一致就合法
?
（核心是“私鑰簽名、公鑰驗真”，靠非對稱加密保證身份，哈希保證數據沒被改～）

udp

udp協議格式

數據長度=UDP長度-8

如果udp校驗和錯誤，其內容會被拋棄；

特點

1.無連接: 知道對端的IP和端口號就直接進行傳輸, 不需要建立連接;（不同于tcp，不需要connect）
2.不可靠: 沒有確認機制, 沒有重傳機制; 如果因為網絡故障該段無法發到對方, UDP協議層也不會給應用層返回任何錯誤信息;
3.面向數據報: 不能夠靈活的控制讀寫數據的次數和數量(應用層交給UDP多長的報文, UDP原樣發送, 既不會拆分, 也不會合并;用UDP傳輸100個字節的數據:如果發送端調用一次sendto, 發送100個字節, 那幺接收端也必須調用對應的一次recvfrom, 接收100個字節; 而不能循環調用10次recvfrom, 每次接收10個字節，如果超過最大接受上線，需要分批傳輸);

UDP緩沖區

UDP沒有發送緩沖區. 調用sendto會直接交給內核, 由內核將數據傳給網絡層協議進行后續的傳輸動作;
UDP具有接收緩沖區. 但是這個接收緩沖區不能保證收到的UDP報的順序和發送UDP報的順序一致; 如果緩沖區滿了, 再到達的UDP數據就會被丟棄;

udp既能收又能發的特性為全雙工。

tcp

tcp協議格式

分析

32位序號及確認序號

在TCP協議中，32位序號和確認序號是保證數據可靠傳輸的核心機制，以下是關鍵信息：
?
32位序號
?
- 作用：標識發送端所發送數據字節流的位置，確保數據按序傳輸、無重復。
- 定義：每個字節的數據都被分配一個唯一的32位序號（范圍0~232-1）。
- 初始序號（ISN）：連接建立時，雙方會隨機生成一個初始序號，避免因歷史數據殘留導致混淆。
- 示例：若初始序號為100，發送一個10字節的數據包，其序號為100，下一個數據包的序號則為110（100+10）。
?
32位確認序號
?
- 作用：告知發送端已成功接收的數據字節位置，用于確認數據并請求后續數據。
- 定義：確認序號的值 = 已接收的最后一個字節的序號 + 1，表示期望接收的下一個字節序號。
- 示例：若接收端收到序號為100的10字節數據（即100~109），則確認序號為110，說明“已收到109及之前的所有數據，下一步請發110開始的內容”。
?
兩者配合實現了TCP的可靠傳輸：序號確保數據有序，確認序號確保數據不丟失，是TCP面向連接、可靠通信的基礎。

TCP的序號和確認序號之所以不能用一個字段（或“表”）表示，核心原因是它們承擔的角色、作用對象和邏輯含義完全不同，屬于兩個獨立的通信維度，具體可從以下角度理解：
?
- 角色不同：序號是發送端標識自己發出的數據位置（“我發的是從X開始的數據”）；確認序號是接收端告知發送端“我已經收到了哪些數據，你接下來該發什么”。兩者分別對應“發送”和“接收確認”兩個方向的邏輯，無法合并。
- 作用對象不同：序號針對的是本地發送的字節流，由發送端主動生成，隨數據一起傳遞；確認序號針對的是對端發送的字節流，由接收端根據已接收的數據計算得出，用于回應對端。一個是“自己發的”，一個是“告訴對方我收到的”，對象完全分離。
- 邏輯獨立：在TCP雙向通信中，雙方同時既是發送端也是接收端。例如A向B發送數據時用序號，B向A回復時既用自己的序號（發B的數據），也用確認序號（告訴A“我收到你的數據到哪了”）。如果合并為一個字段，會導致雙方的發送和確認邏輯混亂，無法區分“自己發的位置”和“對端該發的位置”。
?
簡單說，序號是“我發了啥”，確認序號是“你該發啥”，兩者功能互補但邏輯獨立，必須分開表示才能實現TCP雙向、可靠的通信機制。

4位首部

0000~1111（0-15）單位4字節；及范圍位0-60字節。

TCP首部包含可選字段（如選項和填充），長度不固定（基礎首部20字節，加可選字段后最長60字節）。接收端需要通過這個字段確定首部的結束位置，從而區分首部和數據部分（“哪里是首部，哪里開始是數據”）。

6位標志位

在客戶端與服務端數據傳輸過程中，不同的報頭會在不同的傳輸層級進行解除，而這些標識符是為了更好的區分不同報頭

- URG（Urgent）：緊急指針有效標志位。當URG = 1時，表示報文中包含緊急數據，接收端應盡快將數據推送到應用層，同時緊急指針字段生效，用于指示緊急數據的位置。

緊急指針字段：指向緊急處理數據的偏移量，大小1字節。

應用場景：當服務端與客戶端通信過程中，服務端因為過載而對客戶端的數據無法做出響應，客戶端并不知道，仍然連續的發送數據，此時如果客戶端想要知道服務端出現的問題，可以發送urg為1的字段進行訪問，因為服務端有單獨的進程，對緊急信息進行處理，因此客戶端可以得知服務器的問題

- ACK（Acknowledgment）：確認標志位。若ACK = 1，表明確認序號有效，用于確認收到的報文，通常除了第一個連接請求報文外，其他報文大多會將該位置為1。

- PSH（Push）：推送標志位。當PSH = 1時，通知接收端不要將報文緩存，而是立即將數據交付給應用層處理。（接收緩沖區不足時）

- RST（Reset）：重置標志位。若RST = 1，意味著要求對方重新建立連接，常用于斷開異常連接或拒絕無效連接請求。

- SYN（Synchronization）：同步標志位。在TCP三次握手過程中，客戶端發送的第一個連接請求報文會將SYN置為1，用于初始化連接并同步序號。

- FIN（Finished）：結束標志位。當FIN = 1時，表明發送端已發送完數據，請求關閉連接，常用于TCP四次揮手過程中通知對方本端即將關閉連接。

16位窗口大小

TCP報頭中的16位窗口大小字段用于指定接收方的緩沖區大小，告知發送方自己還有多少緩沖空間可以用來接收數據，主要用于流量控制和提高傳輸效率。

16位緊急指針

緊急指針就像快遞包裹上的“加急標簽”，但它不光貼標簽，還告訴你“加急內容到哪結束”。
?
- 當URG標志位（相當于“加急”開關）打開時，緊急指針才有用。

- 它的值是個數字，比如5。

- 結合當前包裹的“起始序號”（比如100），100 + 5 = 105，意思就是：從100開始，到104為止的這5個字節是緊急數據，接收方得先處理這部分，剩下的再慢慢處理。
?
簡單說：URG=1時，緊急指針+序號=緊急數據結束的下一個位置，幫接收方快速找到“要先處理的內容”。

超時處理

情景1：數據發送失敗，丟包

情景2：應答超時

客戶端沒有收到應答，可能會重復的發送數據，如果是網絡超時，那么后面服務器會收到多條重復消息，因此服務器就要處理這些重復的數據，其這個時候我們就可以使用上述的序列號進行去重

最理想的情況下, 找到一個最小的時間, 保證 "確認應答一定能在這個時間內返回".
1.但是這個時間的長短, 隨著網絡環境的不同, 是有差異的.
2.如果超時時間設的太長, 會影響整體的重傳效率;
3.如果超時時間設的太短, 有可能會頻繁發送重復的包;
4.TCP為了保證無論在任何環境下都能比較高性能的通信, 因此會動態計算這個最大超時時間.
Linux中(BSD Unix和Windows也是如此), 超時以500ms為一個單位進行控制, 每次判定超時重發的超時
##時間都是500ms的整數倍.
##如果重發一次之后, 仍然得不到應答, 等待 2*500ms 后再進行重傳.
##如果仍然得不到應答, 等待 4*500ms 進行重傳. 依次類推, 以指數形式遞增.
##累計到一定的重傳次數, TCP認為網絡或者對端主機出現異常, 強制關閉連接.