IP 三次握手和四次揮手

網絡知識點 OSI 開放式互聯參考模型

七層協議

1物理層

• 解決：機器1向機器2發送比特流，機器2接收比特流。
• 定義：物理設備的標準，網線類型，設備接口類型，各種傳輸介質的傳輸速率
• 作用：傳輸比特流010101數據，將比特流轉化為電流強弱信號，到達後再轉化為0101機器碼-> 數模轉換和模數轉換。網卡定義在這一層

2數據鏈路層

• 解決：傳輸比特流的過程中解決數據傳輸不完整的可能
• 定義：如何格式化數據以進行傳輸以及對物理介質的訪問
• 作用：錯誤檢測和糾正，確保數據傳輸的可靠性，將比特數據組成了幀，交換機工作在這層，對幀解碼，根據幀中的數據發送到網絡接收方

3網絡層

• 解決：找到目標節點選擇最佳路徑，幀數據點對點通信經過多個節點
• 定義：將網絡地址翻譯成物理地址並決定將發送方路由到接收方，通過綜合考慮選擇優先權和最佳路徑，TCP/IP 路由器屬於網絡層，數據為數據包
• 作用：將數據包切割為一個一個段落進行發送。

4傳輸層

• 解決：數據丟失要不要重傳，每個段落要按順序達到麼，解決了主機間的數據傳輸，傳輸質量的問題
• 定義：傳輸協議，流量控制，速率，傳輸順序, TCP、UDP

5 會話層

• 解決：建立和管理應用程序間的通信，解決不同系統之間通信語法的問題，再表示成網絡能理解的方案格式化，方案也因為網絡的類型不同而不同，
• 定義： RPC 遠程過程調用協議在此層

7 應用層

發送方發送的數據接收方是不知道他的字節數組和內容格式的

• 解決：規定發送方接收方使用固定的消息頭，規定頭的組成，消息體的長度，用來正確解析發送的數據，應用從網絡中接收到的數據。
• 定義：TCP/IP 協議對應的 HTTP HTTPS 協議

模型參考

發送方解釋數據，分段，分組成幀解釋成比特流，通過電纜發送到目標方在向上解析傳遞。

TCP/IP 模型

OSI概念七層實現：TCP/IP 四層模型 TCP/IP 模型關注應用程序實現，OSI模型在協議開發之前設計的，具有通用性

TCP/IP 解釋

• TCP 和 IP 協議 單獨的 TCP IP 協議
• TCP/IP通信時用到的協議群-網ji協議群 TCP,UDP 都屬於 TCP/IP 協議

• OSI模型注重通信協議必要的功能是什麼
• TCP/IP模型更強調在計算機上實現協議應該開發哪種程序 一層層包裹在一層層解套出來

TCP 三次握手

傳輸控制協議TCP

• 面向連接、可靠、基於字節流的傳輸層通信協議
• 將應用層的數據流分割成報文段併發送給目標節點的TCP層
• 數據包有都有序號，對方接收到則發送ACK 確認，未收到則重傳
• 使用校驗和檢驗數據在傳輸過程中是否有誤

TCP 報文頭

• 傳輸中使用協議端口號，ip地址+協議+端口號產生唯一標識網絡進程， 也成為套接字 socket。 source port 原端口，destination port 目的端口
• Sequence Number 序號字段佔4字節 對每個字節標識，比如一段報文序號107攜帶100個字段，下一個報文段就是 107 + 100 = 207 開始
• Acknowledgment Number 期望收到對方下個字節的序號 例如B收到A 301序號200字節大小的報文段，B接收500字節，B發送給A501 ACK Number，告訴A期望下次接收501序號的報文段

TCP Flage

• URG: 緊急指針標誌 0忽略
• ACK：確認序號標誌1
• PSH：push 標誌 1就有push 將數據儘快交給應用程序而不是緩存區排隊
• RST：重置連接標誌
• SYN：同步序列號1，用戶建立連接過程
• FIN:finish標誌，用於釋放連接

三次握手

握手是為了建立連接，TCP 三次握手的流程

第一次握手

• B服務器創建傳輸控制塊TCP 時刻準備接收客戶端進程發送的請求，進入 listen 狀態
• A客戶端創建傳輸控制塊TCP向服務器發送連接請求報文 - sent 報文段，SYN同步序號1，seq報文段序號正整數值
• A客戶端進入 SYN-SENT 同步已發送狀態，發送的稱為 sent 報文段, 不能攜帶數據，但是要消耗掉一個 seq 序號，這便是第一次握手

第二次握手

• B服務器接收到請求後如果同意則發送確認接收報文
• 接收報文包含 SYN1 ACK1 兩個字段，而為自己的緩存初始化一個序列號 seq 確認報文序號為 y，ack期待報文序號為 x + 1，因為第一次握手 seq為x
• 進入 SYN-RCVD 同步收到狀態，這時候報文要不能攜帶數據需要消耗一個 序號

第三次握手

• TCP 客戶端進程A 收到確認報文後還要給服務進程一個報文
• 確認報文 ACK=1，seq=x+1, ack=y+1
• 此時TCP 連接建立，客戶端進入ESTAB-LISHED 已建立連接的狀態，此時ACK報文段可以攜帶數據(不攜帶則不消耗序號),之前不可攜帶數據
• 服務端進入 SETAB-LISHED 狀態 雙方就可以通信了。

Wireshark 抓包理解 TCP 三次握手

win 參數為滑動窗口，進行流量控制

總結三次握手

在 TCP/IP 協議中, TCP 採用三次握手建立可靠的連接。

• 第一次握手 建立連接時客戶端發送 SYN 包 syn=1 到服務器並進入 SYN_SEND 狀態 等待服務器確認
• 第二次握手 服務器收到 SYN 包，必須給客戶端發送確認包 ACK ack=1，同時發送一個 SYN syn=k，也就是 SYN+ACK 包，此時服務器進入 SYN_RECV 狀態
• 第三次握手 客戶端收到服務器的 SYN+ACK 包後向服務器發送確認包 ACK ack=k+1，此包發送完畢後客戶端和服務端後進入 ESTABLISHED 狀態，三次握手完畢

為什麼要三次握手建立連接

• 初始化 sequence number 的初始值 通信雙方要通知雙方 seq num，用來以後通信的序號，保證應用層接收到的數據不會因為網絡傳輸問題導致亂序，TCP用序號拼接數據，而且還要發送確認報文 ack

SYN 超時隱患

首次握手出現

原因

• server 收到 client 的SYN 回覆 SYN-ACK的時候未收到 ACK 確認
• server 不斷重試直至超時，linux 默認63秒等待才斷開

目前，Linux下默認會進行5次重發SYN-ACK包，重試的間隔時間從1s開始，下次的重試間隔時間是前一次的雙倍，5次的重試時間間隔為1s, 2s, 4s, 8s, 16s, 總共31s, 稱為指數退避，第5次發出後還要等32s才知道第5次也超時了，所以，總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s, TCP才會把斷開這個連接。由於，SYN超時需要63秒，那麼就給攻擊者一個攻擊服務器的機會，攻擊者在短時間內發送大量的SYN包給Server(俗稱SYN flood攻擊)，用於耗盡Server的SYN隊列。

惡意攻擊 SYN Flood

發送SYN 而不回應，每次都等待63秒，讓正常連接不能處理

最基本的DoS攻擊就是利用合理的服務請求來佔用過多的服務資源，從而使合法用戶無法得到服務的響應。syn flood屬於Dos攻擊的一種。

如果惡意的向某個服務器端口發送大量的SYN包，則可以使服務器打開大量的半開連接，分配TCB（Transmission Control Block）, 從而消耗大量的服務器資源，同時也使得正常的連接請求無法被相應。當開放了一個TCP端口後，該端口就處於Listening狀態，不停地監視發到該端口的Syn報文，一 旦接收到Client發來的Syn報文，就需要為該請求分配一個TCB，通常一個TCB至少需要280個字節，在某些操作系統中TCB甚至需要1300個字節，並返回一個SYN ACK命令，立即轉為SYN-RECEIVED即半開連接狀態。系統會為此耗盡資源。

防護措施

• Syn Cache 服務端在收到SYN報文時，在一個專用HASH表中保存這種半連接信息，直到收到正確的回應ACK報文再分配TCB。這個開銷遠小於TCB的開銷。還需要保存序列號。
• Syn Cookie 1.使用對方的IP、端口、己方IP、端口的固定信息，生成 Sequence Number 2.SYN 隊列滿後，通過 tcp_syncookies 參數回發 SYN cookie 3.若為正常連接則 client 會回發 SYN cookie，直接建立連接分配 TCB 。 4.攻擊者不會回覆所以，正常的回覆了SYN cookie 就可以在隊列外直接建立

建立後 client 出現故障

• 保活機制 向對方發送保活探測報文，如果未收到響應則繼續發送 嘗試次數達到保活探測數仍未收到響應則中斷

連接隊列

在外部請求到達時，被服務程序最終感知到前，連接可能處於SYN_RCVD狀態或是ESTABLISHED狀態，但還未被應用程序接受。 對應地，服務器端也會維護兩種隊列，處於SYN_RCVD狀態的半連接隊列，而處於ESTABLISHED狀態但仍未被應用程序accept的為全連接隊列。如果這兩個隊列滿了之後，就會出現各種丟包的情形。

sync queue (半連接隊列)

• sync queue 的作用 三次握手中，第一次握手服務端收到客戶端的 SYN 包後，把相關信息放到半連接隊列中，同時進行第二次握手回覆客戶端 SYN + ACK
• 當 sync queue 滿時 該隊列保存服務器已收到客戶端的 SYN 包，並向客戶發出確認，正在等待客戶的確認包。這些所標識的連接在服務器處於 SYN_RECV 狀態，當服務器收到客戶的確認包時，刪除該 SYN 包的信息，服務器進入 ESTABLISHED 狀態。

accept queue (全連接隊列)

• accept queue 作用 第三次握手時服務器收到客戶端的 ack，如果這時全連接隊列沒滿，那麼從半連接隊列拿出相關信息放入到全連接隊列中，否則按 tcp_abort_on_overflow 指示的執行。
• 當 accept queue 滿時 如果全連接隊列滿了並且 tcp_abort_on_overflow 是 0 直接丟棄該ACK，服務器會進行過一段時間再次進行第二次握手發送 SYN + ACK 給客戶端，如果客戶端超時等待比較短，就很容易異常。 tcp_abort_on_overflow 1 表示發送 RST(重置連接) 通知客戶端

參考1 參考2

TCP 四次揮手

為了終止連接， 要發送四個包

1揮手

• server client 都處於 ESTAB-LISHED 狀態
• client 主動關閉
• 客戶端發送連接釋放報文並且停止發送數據
• 釋放報文 FIN=1，seq=u u是最後一個字節的序號+1， 不攜帶數據也要消耗序號
• 客戶端進入 FIN-WAIT-1

2揮手

• server 接收到釋放報文 發出確認報文
• 確認報文 ACK=1,seq=v,ack=u+1
• 進入CLOSE-WAIT狀態（重要）半關閉狀態，客戶端不發送數據，但server 發送的數據 client 還是可以接收

3揮手

• client 接收到 server 的確認報文進入 FIN-WAIT-2 狀態, 等待 server 發送釋放連接報文（等待第三次揮手）
• 此時 client 還要接收 server 發送的最後數據
• server 發送完最後數據後，發送連接釋放報文，FIN=1,ACK=1,seq=w,ack=u+1
• server 進入 LAST-ACK 最後確認狀態

4揮手

• client 收到釋放報文後必須發送確認報文，ACK=1,seq=u+1,ack=w+1
• client 進入 TIME-WAIT 狀態，這時候 client TCP 連接還沒釋放，必須等待 2MSL(最長報文段壽命liux30s) 才釋放
• server 收到 client 的確認報文後立即關閉，server 比client 稍早點關閉

四次揮手總結

• 第一次揮手 客戶端發送一個 FIN 序號 seq=u，用來關閉 客戶端到服務器的數據傳送，客戶端進入 FIN_WAIT_1 狀態
• 第二次揮手 服務器收到 FIN 後，發送一個 ACK 給客戶端，確認序號為收到的序號 ack=u+1 FIN 也佔一個序號 seq=v，服務器進入 CLOSE_WAITE狀態, 這時服務器要把剩下的數據發送完畢
• 第三次揮手 服務器剩餘數據發送完畢，發送一個 FIN seq=w ack=u+1，用來關閉服務器到客戶端的數據傳送，服務器進入 LAST_ACK 狀態
• 第四次揮手 客戶端收到 FIN 後，客戶端進入 TIME_WAIT 狀態，接著發送一個 ACK 給服務器，確認序號為收到序號 ack=w+1和 seq=u+1，服務器進入 CLOSED 狀態，客戶端等待 2MSL 時間進入 CLOSED 結束。

client TIME_WAIT 狀態

等待 2MSL 時間

• 保證讓被動關閉方有足夠的時間收到ACK包(確認報文)
• 如果被動關閉方沒有收到則重新發送 FIN 包，一來一回剛好 2MSL
• 避免新舊連接混淆， 有的路由器緩存的連接跟新連接混淆

為什麼要四次揮手才斷開連接

雙工是允許雙向發送，發送方和接收方都需要 FIN 報文和 ACK 報文 各自需要2次揮手，但是一方是被動的，才看上去是4次揮手

服務端出現大量 CLOSE_WAIT

客戶端一直請求，但是返回時異常的 當對方發送 FIN 報文後，應用沒有返回 ACK 對方關閉 socket 連接，我方忙於讀寫，沒有及時關閉 檢查代碼，釋放資源代碼 檢查配置，處理請求的線程配置