TCP實戰抓包分析

學習資源 小林coding 2022.4.8

顯形網絡包

• tcpdump 僅支持命令行使用 常在linux種抓取和分析網絡包
• Wireshark 除了可以抓包 還提供了可視化分析網絡包的圖形界面

三次握手分析

• TCP第一次握手 SYN丟包 RTO翻倍增長

• TCP第二次握手 SYN ACK丟包

  • 客戶端發起SYN后 防火墻屏蔽數據包 超時 重傳SYN包
  • 客戶端收到客戶的SYN包后 回SYN ACK包 客戶端一直沒有回ACK 服務端超時重傳 SYN ACK
  • 客戶端超時重傳的SYN又到達服務器 服務端收到后 回SYN ACK
  • SYN ACK重傳定時器沒有充值 持續重傳 超過最大次數

  第二次揮手的SYN ACK丟包時 客戶端會超時重發SYN 服務端也會超時重傳SYN ACK

  客戶端SYN超時重傳的最大次數 是由tcp_syn_retries決定的

  服務端SYN ACK包重傳的最大次數 是由 tcp_synack_retries 決定

  默認5次

• TCP第三次握手 ACK丟包

  • 客戶端發送SYN包 服務端發送SYN ACK 服務端處于SYN_RECV狀態
  • 客戶端收到SYN ACK 給服務端發送ACK TCP連接處于ESTABLISHED狀態
  • 屏蔽ACK 服務端一直處于SYN_RECV狀態
  • 服務端超時重傳SYN ACK包 重傳4次 沒有繼續重傳 服務端TCP主動連接斷開
  • 服務端TCP斷開 但是發現客戶端仍然處于建立狀態 在客戶端的telnet發送123456會話
  • 客戶端發送的數據報文一直在重傳 RTO指數增長

  TCP建立連接后最大超時重傳次數是由tcp_retries2指定默認15次

  如果客戶端不發送數據 什么時候才會斷開處于ESTABLISHED狀態的連接

  TCP的保活機制

net.ipv4.tcp_keepalive_time=7200 net.ipv4.tcp_keepalive_intvl=75 net.ipv4.tcp_keepalive_probes=9

保活時間 2h 兩小時內如果沒有任何連接相關的活動 則會啟動保活i價值

每次檢查間隔75s 9次沒響應 就中斷連接

TCP快速建立連接

客戶端在向服務端發起HTTP GET請求的時候 一個完整的交互過程 需要2.5RTT

第三次握手可以攜帶數據 第三次握手攜帶數據 需要2RTT

Linux3.7 提供了 TCP Fast Open 功能 可以減少TCP連接建立的時延

• 在第一次建立連接的時候 服務端在第二次握手產生一個Cookie并通過SYN ACK包一起發送客戶端 客戶端緩存Cookie 第一次發起HTTP Get 請求的時候 需要2RTT的時延
• 下次請求的時候 客戶端在SYN包帶上Cookie發給客戶端 Cookie中維護了一些信息 服務端可以從Cookie 獲取TCP相關的信息 此時發起的HTTP GET請求只需要1個RTT的時延

TCP重復確認和快速重傳

當接收方收到亂序數據包時 會發送重復的ACK 以便告知發送方要重傳該數據包 當發送方收到3個重復ACK 就會觸發快速重傳 立即重發丟失包

啟用SACK -> 重傳丟失的數據包

TCP流量控制

通過滑動窗口機制 利用接收方的接受窗口來控制發送方要發送的數據量

接收窗口時由接收方指定的值 存儲在TCP頭部中 可以告訴發送方自己的TCP緩沖空間區大小

整個緩沖區給應用程序讀取數據的空間

• 如果應用程序讀取了緩存區的數據 那么緩沖空間區就會把讀取的數據移除
• 如果應用程序沒有讀取數據 則數據會一直滯留在緩沖區

現實中服務器會出現繁忙的情況 當應用程序讀取慢 緩存空間逐漸會被占滿 于是為了保證發送方發送端數據不會超過緩沖區大小

服務器則會調整窗口大小的值 接著通過ACK報文通知對方 告知窗口大小

零窗口通知與窗口檢測

假設接收方處理數據的速度跟不上接受數據的速度 緩存就會被占滿 從而導致接收窗口為0 當發送方接收到零窗口通知時 就會停止發送數據

發送方會定時發送窗口大小探測報文 以便及時知道接收方窗口大小的變化

窗口探測報文 超時時間翻倍遞增

發送窗口的分析

win 在向對付聲明自己的接受窗口

發送窗口 min（擁塞窗口 接受窗口）

發送窗口與MSS關系

發送窗口決定了一口氣發多少字節

MSS決定這些字節要分多少包才能發完

發送方在一個窗口發出n個包 是不是需要n個ACK確認報文

不一定 TCP由累計確認機制 當收到多個數據包時 只需要應答最后一個數據包的ACK報文就可以了

TCP延遲確認與Nagle算法

• 延遲確認
• Nagle算法

Nagle算法 如何避免大量TCP小數據報文的傳輸

Nagle算法做了一些策略來避免過多的小數據報文發送 可以提高傳輸效率

• 沒有已發送未確認報文時 立即發送數據
• 存在未確認報文 直到沒有已發送未確認報文或數據長度達到MSS大小時再發送數據
• 只要沒滿足上面條件中的一條 發送方一直在囤積數據 直到滿足發送條件

延遲確認

沒有攜帶數據的ACK網絡效率很低

40個字節的IP頭和TCP頭 但卻沒有攜帶數據報文

衍生出了TCP延遲確認

• 當有相應數據要發送時 ACK會隨著響應數據一起立刻發送
• 沒有相應數據發送時 ACK將會延遲一段時間 等待是否有相應數據可以一起發送
• 如果在延遲等待發送ACK期間 第二個數據報文到達 立即發送ACK

總結

以上是生活随笔為你收集整理的TCP实战抓包分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。