探析如何使用SystemTap觀測TCP Backlog

什麼是TCP Backlog

本文所使用的Linux內核版本信息

5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

backlog的中文含義是 積壓 的意思,在Linux網絡中,意味著網絡數據包的積壓,在Linux表現為半連接隊列和全連接隊列存儲這些積壓的數據包。backlog參數的大小,則會影響半連接隊列和全連接隊列緩存數據包的多少。

其中,半連接隊列和全連接隊列的含義如圖所示(此處引用張師傅博客中的圖)

  • 半連接隊列(Incomplete connection queue),又稱 SYN 隊列
  • 全連接隊列(Completed connection queue),又稱 Accept 隊列

從服務端角度看待TCP三次握手的過程,有以下幾步:

  • 調用 listen 函數時,TCP 的狀態被從 CLOSE 狀態變為 LISTEN,此時內核就創建瞭半連接隊列和全連接隊列。backlog參數就是在listen的時候指定的。
int listen(int sockfd, int backlog);
  • 在TCP進行三次握手的時候,收到SYN報文會先將數據包放到半連接隊列,然後發出SYN+ACK
  • 接著當收到對端的SYN+ACK的時候,再將這個連接請求的數據包移動到全連接隊列,等待應用程序通過accept() 函數讀取。

我們可以通過listen函數傳入backlog參數值,且backlog參數值會影響到半連接隊列和全連接隊列的大小,但是我們該怎麼觀測到最終操作系統使用的backlog的大小呢?又怎麼觀測到半連接隊列、全連接隊列中的緩存的包數量呢?backlog參數和半連接隊列、全連接隊列的大小之間又有什麼關系呢?

實驗環境搭建

先在本地電腦上啟動瞭兩個虛擬機,Linux虛擬機1(命名為L1,ip: 10.211.55.6)和Linux虛擬機2(命名為L2,ip: 10.211.55.8),以 L1 作為服務器,L2作為客戶端。

觀測Linux最終采用的backlog大小

為確定backlog值通過listen函數設置進去之後,操作系統最終采用的數值,可以通過systemtap工具來確定。安裝好systemtap工具之後,編寫探測腳本如下:

probe kernel.function("tcp_v4_conn_request") {  
    tcphdr = __get_skb_tcphdr($skb);  
    dport = __tcp_skb_dport(tcphdr);  
    if (dport == 9090)  
    {  
        printf("reach here\n");  
        printf("socket struct: %s \n", $sk$);  
        syn_qlen = @cast($sk, "struct inet_connection_sock")->icsk_accept_queue->qlen;  
        max_backlog=$sk->sk_max_ack_backlog;  
        printf("qlen: %d, max_backlog: %d  \n", syn_len, max_backlog);  
    }  
}

這個腳本做的事情,就是對linux中 tcp_v4_conn_request 這個內核函數做瞭探針,隻要調用到這個內核函數,且端口號為9090,就會執行一系列的打印操作。其中,會將socket對象打印出來,也會將socket對象中的 sk_max_ack_backlog 變量打印出來,這個變量正是linux最終采用的backlog值。

將這個腳本放到機器L1中的任一用戶目錄下,腳本命名為 tcp_backlog.stp,然後用命令執行:

sudo stap -v tcp_backlog.stp

如果運行成功,則會看到在終端上顯示正在運行的提示:

此時,為避免編程語言的幹擾,用C語言準備一段服務器的啟動代碼,backlog值可以通過修改常量來更改,這裡使用backlog值為20

// main.c
#include <sys/socket.h>  
#include <stdio.h>  
#include <netinet/in.h>  
#include <unistd.h>  
#include <string.h>  
#include <stdlib.h>  
#include <sys/shm.h>  
#define MYPORT  9090  
#define BACKLOG 20  
#define BUFFER_SIZE 1024  
int main()  
{  
    ///定義sockfd  
    int server_sockfd = socket(AF_INET,SOCK_STREAM, 0);  
    ///定義sockaddr_in  
    struct sockaddr_in server_sockaddr;  
    server_sockaddr.sin_family = AF_INET;  
    server_sockaddr.sin_port = htons(MYPORT);  
    server_sockaddr.sin_addr.s_addr = htonl(INADDR_ANY);  
    ///bind,成功返回0,出錯返回-1  
    if(bind(server_sockfd,(struct sockaddr *)&server_sockaddr,sizeof(server_sockaddr))==-1)  
    {  
        perror("bind");  
        exit(1);  
    }  
    ///listen,成功返回0,出錯返回-1  
    if(listen(server_sockfd, BACKLOG) == -1)  
    {  
        perror("listen");  
        exit(1);  
    }  
    ///客戶端套接字  
    char buffer[BUFFER_SIZE];  
    char message[100] = "已成功接收!";  
    struct sockaddr_in client_addr;  
    socklen_t length = sizeof(client_addr);  
    ///成功返回非負描述字,出錯返回-1  
    int conn = accept(server_sockfd, (struct sockaddr*)&client_addr, &length);  
    if(conn<0)  
    {  
        perror("connect");  
        exit(1);  
    }  
    while(1)  
    {  
        memset(buffer,0,sizeof(buffer));  
        int size = read(conn, buffer, 1024);  
        if(strcmp(buffer,"exit\n")==0)  
            break;  
        strncat(buffer, message, 100);  
        fputs(buffer, stdout);  
        write(conn,buffer,strlen(buffer)+1);  
    }  
    close(conn);  
    close(server_sockfd);  
    return 0;  
}

在L1上通過命令編譯sk.c 並啟動:

gcc main.c -o sk.o && ./sk.o 

啟動後,在L2上通過nc命令連接L1的9090端口:

nc 10.211.55.6 9090

接著觀察 tcp_backlog.stp 探針腳本的輸出:

可見此時使用的backlog值為20,通過這個方法,我們可以觀測到linux最終采用的 backlog值的大小是多少瞭。

<>系統變量對backlog大小的影響

backlog雖然可以通過listen設置進去,但是按照張師傅的博客所說,最終的大小會受到操作系統的配置影響。可通過sysctl命令查看這兩個系統變量:

sysctl net.ipv4.tcp_max_syn_backlog
# net.ipv4.tcp_max_syn_backlog = 128
sysctl net.core.somaxconn
# net.core.somaxconn = 4096

按照上述觀測的方法,函數傳入的backlog值分別在 小於128,大於128但小於4096,大於4096這三個區間取一個值。設置backlog大小為 20、200、6000,分別觀測操作系統最終采用的backlog值如下:

listen backlog值為200時,操作系統采用的backlog值為200

listen backlog值為6000時,操作系統采用的backlog值為4096,和系統變量 net.core.somaxconn 保持一樣。

將上述測試數據總結如下:

listen backlog值 操作系統實際采用的backlog值
20 20
200 200
6000 4096

在張師傅的博客中提到, Linux內核版本在3.10.0的時候,會受到 net.ipv4.tcp_max_syn_backlognet.core.somaxconn 的影響,且受這兩個變量影響的邏輯還比較復雜。但是在 5.15.0版本中,已經做瞭簡化,代碼如下:

// net/socket.c
int __sys_listen(int fd, int backlog)
{
  struct socket *sock;
  int err, fput_needed;
  int somaxconn;
  sock = sockfd_lookup_light(fd, &err, &fput_needed);
  if (sock) {
    # sysctl_somaxconn對應系統變量net.core.somaxconn的值
    somaxconn = sock_net(sock->sk)->core.sysctl_somaxconn;
    if ((unsigned int)backlog > somaxconn)
      backlog = somaxconn;
    err = security_socket_listen(sock, backlog);
    if (!err)
      err = sock->ops->listen(sock, backlog);
    fput_light(sock->file, fput_needed);
  }
  return err;
}

再簡化一下核心邏輯,核心邏輯的偽代碼如下:

backlog = listen_backlog;
somaxconn = valuOf(`net.core.somaxconn`);
if(backlog > somaxconn) {
	backlog = somaxconn;
}

按張師傅的博客所說,在內核版本為3.10.0中, backlog 值會在這個時候依次傳遞給 __sys_listen() -> inet_listen()->inet_csk_listen_start()->reqsk_queue_alloc(),最終在 reqsk_queue_alloc函數中根據這兩個系統變量經歷一系列復雜的計算,最終得到操作系統使用的backlog值。但是這些操作,在5.x版本的內核都去掉瞭,reqsk_queue_alloc函數中不再對backlog做過任何處理:

// net/ipv4/inet_connection_sock.c
// 在這個函數中,雖然傳入瞭backlog,但是在後續的處理中完全沒有用上,由此證明backlog的賦值,在 __sys_listen 函數中已經完成
int inet_csk_listen_start(struct sock *sk, int backlog)
{
  struct inet_connection_sock *icsk = inet_csk(sk);
  struct inet_sock *inet = inet_sk(sk);
  int err = -EADDRINUSE;
  reqsk_queue_alloc(&icsk->icsk_accept_queue);
  sk->sk_ack_backlog = 0;
  inet_csk_delack_init(sk);
  /* There is race window here: we announce ourselves listening,
   * but this transition is still not validated by get_port().
   * It is OK, because this socket enters to hash table only
   * after validation is complete.
   */
  inet_sk_state_store(sk, TCP_LISTEN);
  if (!sk->sk_prot->get_port(sk, inet->inet_num)) {
    inet->inet_sport = htons(inet->inet_num);
    sk_dst_reset(sk);
    err = sk->sk_prot->hash(sk);
    if (likely(!err))
      return 0;
  }
  inet_sk_set_state(sk, TCP_CLOSE);
  return err;
}
// net/core/request_sock.c
void reqsk_queue_alloc(struct request_sock_queue *queue)
{
  spin_lock_init(&queue->rskq_lock);
  spin_lock_init(&queue->fastopenq.lock);
  queue->fastopenq.rskq_rst_head = NULL;
  queue->fastopenq.rskq_rst_tail = NULL;
  queue->fastopenq.qlen = 0;
  queue->rskq_accept_head = NULL;
}

觀測半連接隊列大小

在三次握手的過程中,服務端收到握手請求包之後,會先把它放到半連接隊列中,然後回復SYN+ACK。接著接收到客戶端返回的ACK報文時,再把這個數據包從半連接隊列移動到全連接隊列中。在正常情況下,SYN報文在半連接隊列逗留的時間會很快,觀測半連接隊列大小要做點處理。

按照張師傅博客提供的方法,可以在客戶端設置防火墻,把服務端返回的ACK包都扔掉,這樣在服務端就不會收到ACK報文瞭。

// 在L2機器上設置這條防火墻規則
sudo iptables --append INPUT --match tcp --protocol tcp --src 10.211.55.6 --sport 9090 --tcp-flags SYN SYN --jump DROP
// 查看防火墻規則是否設置成功
sudo iptables -L

接著用上述的服務端代碼啟動服務後,在L2上通過nc命令連接上:

nc 10.211.55.6 9090

接著可以通過以下命令觀察到,當前有多少個連接處於SYN_RECV狀態:

sudo netstat -lnpa | grep :9090  | awk '{print $6}' | sort | uniq -c | sort -rn

處於SYN_RECV狀態的連接,意味著接收到瞭客戶端的SYN報文但未接收到ACK報文。此時連接就處於SYN_RECV狀態。通過這個點可以觀測到半連接隊列此時的大小是多少。你也可以在L2上通過程序發起多次連接,看看SYN_RECV狀態的連接數是否有變化,此處就不再敘述瞭。

觀測全連接隊列大小

當請求收到ACK之後,就會從半連接隊列挪到全連接隊列,此時連接已經完全建立,連接狀態就會從LISTEN變成ESTABLISHED狀態,等待應用程序調用accept函數從全連接隊列中取走數據。所以,要觀察全連接隊列的大小,隻要觀察ESTABLISHED狀態的連接數即可。同樣可以采用netstat命令:

netstat -lnpa | grep :9090 | awk '{print $6}' | sort | uniq -c | sort -rn

也可以使用ss命令來進行觀測。使用命令如下:

ss -lnt | grep :9090
  • 處於 LISTEN 狀態的 socket,Recv-Q 表示 accept 隊列排隊的連接個數,Send-Q 表示全連接隊列(也就是 accept 隊列)的總大小
  • 對於非 LISTEN 狀態的 socket,Recv-Q 表示 receive queue 的字節大小,Send-Q 表示 send queue 的字節大小

總結

SystemTap是一個很有力的工具,用好這個工具,可以實實在在地觀測到Linux內部的狀態,讓自己對操作系統有個更深刻的認識。

以上就是使用SystemTap觀測TCP Backlog過程解析的詳細內容,更多關於SystemTap觀測TCP Backlog的資料請關註WalkonNet其它相關文章!

推薦閱讀: