談談Linux中的TCP重傳抓包分析

文章來源：www.liangsonghua.me
做者介紹：京東資深工程師-梁鬆華，長期關注穩定性保障、敏捷開發、JAVA高級、微服務架構

收到研發反饋，TCP重傳嚴重。主機報文重傳是TCP最基本的錯誤恢復功能，它的目的是防止報文丟失

報文丟失的可能因素有不少種

一、 網絡設備或線路故障
案例：設備接口經常出現的CRC數據校驗錯誤
特色：問題一直持續，全部通過該節點的數據都受影響，影響服務器數量大
二、 數據路徑上的流量突發致使鏈路擁塞
案例：專線打滿致使丟包嚴重
特色：突發性極強，持續時間短。更多時候有周期性。全部通過該節點的數據都受影響，影響服務器數量大
三、 客戶端服務器故障
案例：某服務器網卡故障，或者性能降低
特色：故障長時間持續，僅僅影響單臺設備
四、 服務器端服務器故障
案例：某服務器網卡故障
特色：故障長時間持續，全部請求到該節點的數據都受影響，影響服務器數量大
五、 服務器端性能降低
案例：有運營活動的時候服務端請求量太大，致使性能降低
特色：突發，若是服務端有巨量請求會有周期性，全部請求到這臺設備(集羣)的數據都有可能受影響，影響服務器數量大
六、 代理節點或者VIP性能降低
案例：某一負載均衡集羣故障或性能降低
特色：突發，有周期性。全部請求到該節點的數據都受影響，影響服務器數量大
先抓包生成pcap文件，tcpdump -i nsdb475e5d-86 -vvv -w tcp_retry.pcap，保留證據要緊，同時留意值班羣和網絡應急響應羣是否有相同的反饋，若是有其餘人反饋，及時確認受影響範圍，服務器是否有一些共性，好比集中在某個數據中心上、某個POD下、某臺物理機上

使用如下命令實時能夠觀察系統中每秒tcp重傳報文數量，線上監控工具推薦使用阿里出品的tsar-Taobao System Activity Reporter

nstat -z -t 1 | grep -e TcpExtTCPSynRetrans -e TcpRetransSegs -e TcpOutSegs -e TcpInSegs

使用netstat -s查看總體狀況，按各個協議進行統計結果以下

ss -anti |grep -B 1 retrans查看重傳統計狀況，具體到IP+端口，這裏方便顯示使用ss -tanl演示

一、 LISTEN 狀態：
這兩個值表示的是最大的listen backlog積壓數值，這裏顯示爲0，實際上會取內核參數net.core.somaxconn的值

二、 其餘狀態：
(1)、 recv-Q:表示網絡接收隊列，表示收到的數據已經在本地接收緩衝，可是還有多少沒有被進程取走，若是短暫不爲0，多是處於半鏈接狀態，若是接收隊列Recv-Q一直處於阻塞狀態，多是遭受了拒絕服務 denial-of-service 攻擊
(2)、send-Q:表示網路發送隊列，對方沒有收到的數據或者說沒有Ack的,仍是在本地緩衝區.若是發送隊列Send-Q不能很快的清零，多是有應用向外發送數據包過快，或者是對方接收數據包不夠快
非LISTEN狀態下則一般應該爲0，若是不爲0多是有問題的，packets在兩個隊列裏都不該該有堆積狀態，可接受短暫的非0狀況

ulimit -a檢查服務打開的文件句柄上限,10多萬正常是足夠的

經過ifconfig查看網卡是否存在持續drop、error現象

容器狀態正常，開始使用wiresherk分析抓包文件

查看IO graph，確保鏈路不忙，不忙的鏈路IO會有不少高低起落，峯值以及空閒間隙

進入Analyze–>Expert Info 查看不一樣標籤下不一樣級別的提示信息，好比重傳的統計、鏈接的創建和重置統計

過濾重傳，發現集中在22000和22001這兩個內網服務框架JSF的通訊端口上

猜想是上游某個接口的服務異常或者通訊異常，點擊某個note查看詳情，或者回到控制面板，輸入tcp.analysis.retransmission過濾再點擊查看詳情

大部分是DATA數據傳輸時發生了重傳，PSH ACK報文表示開始向服務端發送數據

能夠看到有不少上游接口和不一樣的依賴類型(好比JMQ)都有重傳，說明不是某個接口的問題，應該是網絡問題。使用mtr(集成了traceroute、ping、nslookup的功能)來檢查下路徑上的互聯地址延遲和丟包狀況，發現中間某一跳丟包率爲16.7%，因而去找網絡組的同事檢查

補充1、Wiresherk經常使用操做
一、Statistics->Conversations會話統計功能，統計通訊會話之間接收和發送的數據包和字節數，經過這個工具能夠找出網絡中哪一個會話（IP地址或端口號）最佔用帶寬，進一步做出網絡策略

二、Statistics–>Flow graph會話通訊過程圖形可視化，還能夠看到是否有TCP的延遲包括延遲確認(Delayed ACK),服務端是否開啓Nagle算法

補充2、Wiresherk的info常見提示
一、Packet size limited during capture

說明被標記的那個包沒有抓全。通常是由抓包方式引發，有些操做系統中默認只抓每一個幀的前96個字節
二、TCP Previous segment not captured

若是Wireshark發現後一個包的Seq大於Seq+Len，就知道中間缺失了一段，若是缺失的那段在整個網絡包中找不到（排除了亂序），就會提示
三、TCP ACKed unseen segment

當Wireshark發現被Ack的那個包沒被抓到，就會提示
四、TCP Out-of-Order

當Wireshark發現後一個包的Seq號小於前一個包的Seq+Len時，就會認爲亂序，發出提示
五、TCP Dup ACK

當亂序或丟包發生時，接收方會收到一些Seq號比指望值大的包。沒收到一個這種包就會Ack一次指望的Seq值，提現發送方
六、TCP Fast Retransmission

當發送方收到3個或以上的【TCP Dup ACK】，就意識到以前發的包可能丟了，因而快速重傳它
七、TCP Retransmission

若是一個包真的丟了，又沒有後續包能夠在接收方觸發【Dup Ack】就不會快速重傳，這種狀況下發送方只好等到超時了再重傳
八、TCP zerowindow

包種的「win」表明接收窗口的大小，當Wireshark在一個包中發現「win=0」時，就會發提示
九、TCP window Full

此提示表示這個包的發送方已經把對方所聲明的接收窗口耗盡了
十、Time-to-live exceeded（Fragment reassembly time exceeded）

文章來源：www.liangsonghua.me做者介紹：京東資深工程師-梁鬆華，長期關注穩定性保障、敏捷開發、JAVA高級、微服務架構