Linux中ss命令Recv-Q和Send-Q詳解

參考：http://phpmianshi.com/?id=95

 

ss用來顯示處於活動狀態的套接字信息。ss命令可以用來獲取socket統計信息，它可以顯示和netstat類似的內容。但ss的優勢在於它能夠顯示更多更詳細的有關TCP和連接狀態的信息，而且比netstat更快速更高效。

當服務器的socket連接數量變得非常大時，無論是使用netstat命令還是直接cat /proc/net/tcp，執行速度都會很慢。可能你不會有切身的感受，但請相信我，當服務器維持的連接達到上萬個的時候，使用netstat等於浪費 生命，而用ss纔是節省時間。

ss快的祕訣在於，它利用到了TCP協議棧中tcp_diag。tcp_diag是一個用於分析統計的模塊，可以獲得Linux 內核中第一手的信息，這就確保了ss的快捷高效。當然，如果你的系統中沒有tcp_diag，ss也可以正常運行，只是效率會變得稍慢。

 

-h：顯示幫助信息；

-V：顯示指令版本信息；

-n：不解析服務名稱，以數字方式顯示；

-a：顯示所有的套接字；

-l：顯示處於監聽狀態的套接字；

-o：顯示計時器信息；

-m：顯示套接字的內存使用情況；

-p：顯示使用套接字的進程信息；

-i：顯示內部的TCP信息；

-4：只顯示ipv4的套接字；

-6：只顯示ipv6的套接字；

-t：只顯示tcp套接字；

-u：只顯示udp套接字；

-d：只顯示DCCP套接字；

-w：僅顯示RAW套接字；

-x：僅顯示UNIX域套接字。

 

顯示TCP連接

ss -t -a

顯示 Sockets 摘要

ss -s

查看進程使用的socket

ss -pl

找出打開套接字/端口應用程序

ss -pl | grep 3306

​

Recv-Q和Send-Q詳解

 

 

1. 當 client 通過 connect 向 server 發出 SYN 包時，client 會維護一個 socket 等待隊列，而 server 會維護一個 SYN 隊列

2. 此時進入半鏈接的狀態，如果 socket 等待隊列滿了，server 則會丟棄，而 client 也會由此返回 connection time out；只要是 client 沒有收到 SYN+ACK，3s 之後，client 會再次發送，如果依然沒有收到，9s 之後會繼續發送

3. 半連接 syn 隊列的長度爲 max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)  決定

4. 當 server 收到 client 的 SYN 包後，會返回 SYN, ACK 的包加以確認，client 的 TCP 協議棧會喚醒 socket 等待隊列，發出 connect 調用

5. client 返回 ACK 的包後，server 會進入一個新的叫 accept 的隊列，該隊列的長度爲 min(backlog, somaxconn)，默認情況下，somaxconn 的值爲 128，表示最多有 129 的 ESTAB 的連接等待 accept()，而 backlog 的值則由 int listen(int sockfd, int backlog) 中的第二個參數指定，listen 裏面的 backlog 的含義請看這裏。

6. 當 accept 隊列滿了之後，即使 client 繼續向 server 發送 ACK 的包，也會不被相應，此時，server 通過 /proc/sys/net/ipv4/tcp_abort_on_overflow 來決定如何返回，0 表示直接丟丟棄該 ACK，1 表示發送 RST 通知 client；相應的，client 則會分別返回 read timeout 或者 connection reset by peer。上面說的只是些理論，如果服務器不及時的調用 accept()，當 queue 滿了之後，服務器並不會按照理論所述，不再對 SYN 進行應答，返回 ETIMEDOUT。根據這篇文檔的描述，實際情況並非如此，服務器會隨機的忽略收到的 SYN，建立起來的連接數可以無限的增加，只不過客戶端會遇到延時以及超時的情況。

 

可以看到，整個 TCP stack 有如下的兩個 queue:
1. 一個是 half open(syn queue) queue(max(tcp_max_syn_backlog, 64))，用來保存 SYN_SENT 以及 SYN_RECV 的信息。
2. 另外一個是 accept queue(min(somaxconn, backlog))，保存 ESTAB 的狀態，但是調用 accept()。