松花皮蛋的黑板報
  • 分享在京東工作的技術感悟,還有JAVA技術和業內最佳實踐,大部分都是務實的、能看懂的、可復現的

掃一掃
關注公眾號

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

博客首頁文章列表 松花皮蛋me 2019-05-30 23:17

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

報文丟失的可能因素有很多種

  • 1、 網絡設備或線路故障
    案例:設備接口常常出現的CRC數據校驗錯誤
    特點:問題一直持續,所有經過該節點的數據都受影響,影響服務器數量大
  • 2、 數據路徑上的流量突發導致鏈路擁塞
    案例:專線打滿導致丟包嚴重
    特點:突發性極強,持續時間短。更多時候有周期性。所有經過該節點的數據都受影響,影響服務器數量大
  • 3、 客戶端服務器故障
    案例:某服務器網卡故障,或者性能下降
    特點:故障長時間持續,僅僅影響單臺設備
  • 4、 服務器端服務器故障
    案例:某服務器網卡故障
    特點:故障長時間持續,所有請求到該節點的數據都受影響,影響服務器數量大
  • 5、 服務器端性能下降
    案例:有運營活動的時候服務端請求量太大,導致性能下降
    特點:突發,如果服務端有巨量請求會有周期性,所有請求到這臺設備(集群)的數據都有可能受影響,影響服務器數量大
  • 6、 代理節點或者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演示

  • 1、 LISTEN 狀態:

這兩個值表示的是最大的listen backlog積壓數值,這里顯示為0,實際上會取內核參數net.core.somaxconn的值

  • 2、 其他狀態:
    • (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%,于是去找網絡組的同事檢查

補充一、Wiresherk常用操作

1、Statistics->Conversations會話統計功能,統計通信會話之間接收和發送的數據包和字節數,通過這個工具可以找出網絡中哪個會話(IP地址或端口號)最占用帶寬,進一步作出網絡策略

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

補充二、Wiresherk的info常見提示

  • 1、Packet size limited during capture

    說明被標記的那個包沒有抓全。一般是由抓包方式引起,有些操作系統中默認只抓每個幀的前96個字節
  • 2、TCP Previous segment not captured

    如果Wireshark發現后一個包的Seq大于Seq+Len,就知道中間缺失了一段,如果缺失的那段在整個網絡包中找不到(排除了亂序),就會提示
  • 3、TCP ACKed unseen segment

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

    當Wireshark發現后一個包的Seq號小于前一個包的Seq+Len時,就會認為亂序,發出提示
  • 5、TCP Dup ACK

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

    當發送方收到3個或以上的【TCP Dup ACK】,就意識到之前發的包可能丟了,于是快速重傳它
  • 7、TCP Retransmission

    如果一個包真的丟了,又沒有后續包可以在接收方觸發【Dup Ack】就不會快速重傳,這種情況下發送方只好等到超時了再重傳
  • 8、TCP zerowindow

    包種的“win”代表接收窗口的大小,當Wireshark在一個包中發現“win=0”時,就會發提示
  • 9、TCP window Full

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

補充三、Linux網絡性能排查常見套路

黑龙江6+1开奖结果查询