[[346270]]

從Linux源碼看Socket(TCP)的listen及連接隊(duì)列前言筆者一直覺得如果能知道從應(yīng)用到框架再到操作系統(tǒng)的每一處代碼，是一件Exciting的事情。今天筆者就來從Linux源碼的角度看下Server端的Socket在進(jìn)行l(wèi)isten的時(shí)候到底做了哪些事情(基于Linux 3.10內(nèi)核)，當(dāng)然由于listen的backlog參數(shù)和半連接hash表以及全連接隊(duì)列都相關(guān)，在這一篇博客里也一塊講了。

Server端Socket需要Listen

眾所周知，一個(gè)Server端Socket的建立，需要socket、bind、listen、accept四個(gè)步驟。今天筆者就聚焦于Listen這個(gè)步驟。

代碼如下:

void start_server(){ 
    // server fd 
    int sockfd_server; 
    // accept fd  
    int sockfd; 
    int call_err; 
    struct sockaddr_in sock_addr; 
  ...... 
    call_err=bind(sockfd_server,(struct sockaddr*)(&sock_addr),sizeof(sock_addr)); 
    if(call_err == -1){ 
        fprintf(stdout,"bind error!\n"); 
        exit(1); 
    } 
    // 這邊就是我們今天的聚焦點(diǎn)listen 
    call_err=listen(sockfd_server,MAX_BACK_LOG); 
    if(call_err == -1){ 
        fprintf(stdout,"listen error!\n"); 
        exit(1); 
    } 
} 

首先我們通過socket系統(tǒng)調(diào)用創(chuàng)建了一個(gè)socket，其中指定了SOCK_STREAM,而且最后一個(gè)參數(shù)為0，也就是建立了一個(gè)通常所有的TCP Socket。在這里，我們直接給出TCP Socket所對(duì)應(yīng)的ops也就是操作函數(shù)。

如果你想知道上圖中的結(jié)構(gòu)是怎么來的，可以看下筆者以前的博客:

https://my.oschina.net/alchemystar/blog/1791017

Listen系統(tǒng)調(diào)用好了，現(xiàn)在我們直接進(jìn)入Listen系統(tǒng)調(diào)用吧。

#include <sys/socket.h> 
// 成功返回0,錯(cuò)誤返回-1,同時(shí)錯(cuò)誤碼設(shè)置在errno 
int listen(int sockfd, int backlog); 

注意，這邊的listen調(diào)用是被glibc的INLINE_SYSCALL裝過一層，其將返回值修正為只有0和-1這兩個(gè)選擇，同時(shí)將錯(cuò)誤碼的絕對(duì)值設(shè)置在errno內(nèi)。這里面的backlog是個(gè)非常重要的參數(shù)，如果設(shè)置不好，是個(gè)很隱蔽的坑。

對(duì)于java開發(fā)者而言，基本用的現(xiàn)成的框架，而java本身默認(rèn)的backlog設(shè)置大小只有50。這就會(huì)引起一些微妙的現(xiàn)象，這個(gè)在本文中會(huì)進(jìn)行講解。

接下來，我們就進(jìn)入Linux內(nèi)核源碼棧吧

listen 
 |->INLINE_SYSCALL(listen......) 
  |->SYSCALL_DEFINE2(listen, int, fd, int, backlog) 
   /* 檢測對(duì)應(yīng)的描述符fd是否存在，不存在，返回-BADF 
   |->sockfd_lookup_light 
   /* 限定傳過來的backlog最大值不超出 /proc/sys/net/core/somaxconn 
   |->if ((unsigned int)backlog > somaxconn) backlog = somaxconn 
   |->sock->ops->listen(sock, backlog) <=> inet_listen 

值得注意的是，Kernel對(duì)于我們傳進(jìn)來的backlog值做了一次調(diào)整，讓其無法>內(nèi)核參數(shù)設(shè)置中的somaxconn。

inet_listen

接下來就是核心調(diào)用程序inet_listen了。

int inet_listen(struct socket *sock, int backlog) 
{ 
 
 /* Really, if the socket is already in listen state 
  * we can only allow the backlog to be adjusted. 
  *if ((sysctl_tcp_fastopen & TFO_SERVER_ENABLE) != 0 && 
      inet_csk(sk)->icsk_accept_queue.fastopenq == NULL) { 
      // fastopen的邏輯 
   if ((sysctl_tcp_fastopen & TFO_SERVER_WO_SOCKOPT1) != 0) 
    err = fastopen_init_queue(sk, backlog); 
   else if ((sysctl_tcp_fastopen & 
      TFO_SERVER_WO_SOCKOPT2) != 0) 
    err = fastopen_init_queue(sk, 
        ((uint)sysctl_tcp_fastopen) >> 16); 
   else 
    err = 0; 
   if (err) 
    goto out; 
  } 
 if(old_state != TCP_LISTEN) { 
  
  err = inet_csk_listen_start(sk, backlog); 
 } 
 sk->sk_max_ack_backlog =backlog; 
 ...... 
} 

從這段代碼中，第一個(gè)有意思的地方就是,listen這個(gè)系統(tǒng)調(diào)用可以重復(fù)調(diào)用!第二次調(diào)用的時(shí)候僅僅只能修改其backlog隊(duì)列長度(雖然感覺沒啥必要)。

首先，我們看下除fastopen之外的邏輯(fastopen以后開單章詳細(xì)討論)。也就是最后的inet_csk_listen_start調(diào)用。

int inet_csk_listen_start(struct sock *sk, const int nr_table_entries) 
{ 
 ...... 
 // 這里的nr_table_entries即為調(diào)整過后的backlog 
 // 但是在此函數(shù)內(nèi)部會(huì)進(jìn)一步將nr_table_entries = min(backlog,sysctl_max_syn_backlog)這個(gè)邏輯 
 int rc = reqsk_queue_alloc(&icsk->icsk_accept_queue, nr_table_entries); 
 ...... 
 inet_csk_delack_init(sk); 
 // 設(shè)置socket為listen狀態(tài) 
 sk->sk_state = TCP_LISTEN; 
 // 檢查端口號(hào) 
 if (!sk->sk_prot->get_port(sk, inet->inet_num)){ 
  // 清除掉dst cache 
  sk_dst_reset(sk); 
  // 將當(dāng)前sock鏈入listening_hash 
  // 這樣，當(dāng)SYN到來的時(shí)候就能通過__inet_lookup_listen函數(shù)找到這個(gè)listen中的sock 
  sk->sk_prot->hash(sk); 
 } 
 sk->sk_state = TCP_CLOSE; 
 __reqsk_queue_destroy(&icsk->icsk_accept_queue); 
 // 端口已經(jīng)被占用，返回錯(cuò)誤碼-EADDRINUSE 
 return -EADDRINUSE; 
} 

這里最重要的一個(gè)調(diào)用sk->sk_prot->hash(sk),也就是inet_hash,其將當(dāng)前sock鏈入全局的listen hash表，這樣就可以在SYN包到來的時(shí)候?qū)ふ业綄?duì)應(yīng)的listen sock了。如下圖所示:

如圖中所示，如果開啟了SO_REUSEPORT的話，可以讓不同的Socket listen(監(jiān)聽)同一個(gè)端口，這樣就能在內(nèi)核進(jìn)行創(chuàng)建連接的負(fù)載均衡。在Nginx 1.9.1版本開啟了之后，其壓測性能達(dá)到3倍!

半連接隊(duì)列hash表和全連接隊(duì)列

在筆者一開始翻閱的資料里面,都提到。tcp的連接隊(duì)列有兩個(gè)，一個(gè)是sync_queue,另一個(gè)accept_queue。但筆者仔細(xì)閱讀了一下源碼，其實(shí)并非如此。事實(shí)上，sync_queue其實(shí)是個(gè)hash表(syn_table)。另一個(gè)隊(duì)列是icsk_accept_queue。

所以在本篇文章里面，將其稱為reqsk_queue(request_socket_queue的簡稱)。在這里，筆者先給出這兩個(gè)queue在三次握手時(shí)候的出現(xiàn)時(shí)機(jī)。如下圖所示:

當(dāng)然了，除了上面提到的qlen和sk_ack_backlog這兩個(gè)計(jì)數(shù)器之外，還有一個(gè)qlen_young,其作用如下:

qlen_young:  
記錄的是剛有SYN到達(dá)， 
沒有被SYN_ACK重傳定時(shí)器重傳過SYN_ACK 
同時(shí)也沒有完成過三次握手的sock數(shù)量 

如下圖所示:

至于SYN_ACK的重傳定時(shí)器在內(nèi)核中的代碼為下面所示:

static void tcp_synack_timer(struct sock *sk) 
{ 
 inet_csk_reqsk_queue_prune(sk, TCP_SYNQ_INTERVAL, 
       TCP_TIMEOUT_INIT, TCP_RTO_MAX); 
} 

這個(gè)定時(shí)器在半連接隊(duì)列不為空的情況下，以200ms(TCP_SYNQ_INTERVAL)為間隔運(yùn)行一次。限于篇幅，筆者就在這里不多討論了。

為什么要存在半連接隊(duì)列

因?yàn)楦鶕?jù)TCP協(xié)議的特點(diǎn)，會(huì)存在半連接這樣的網(wǎng)絡(luò)攻擊存在，即不停的發(fā)SYN包，而從不回應(yīng)SYN_ACK。如果發(fā)一個(gè)SYN包就讓Kernel建立一個(gè)消耗極大的sock，那么很容易就內(nèi)存耗盡。所以內(nèi)核在三次握手成功之前，只分配一個(gè)占用內(nèi)存極小的request_sock，以防止這種攻擊的現(xiàn)象，再配合syn_cookie機(jī)制，盡量抵御這種半連接攻擊的風(fēng)險(xiǎn)。

半連接hash表和全連接隊(duì)列的限制

由于全連接隊(duì)列里面保存的是占用內(nèi)存很大的普通sock，所以Kernel給其加了一個(gè)最大長度的限制。這個(gè)限制為:

下面三者中的最小值 
1.listen系統(tǒng)調(diào)用中傳進(jìn)去的backlog 
2./proc/sys/inet/ipv4/tcp_max_syn_backlog 
3./proc/sys/net/core/somaxconn  
即min(backlog,tcp_ma_syn_backlog,somaxcon) 

如果超過這個(gè)somaxconn會(huì)被內(nèi)核丟棄，如下圖所示:

這種情況的連接丟棄會(huì)發(fā)生比較詭異的現(xiàn)象。在不設(shè)置tcp_abort_on_overflow的時(shí)候,client端無法感知，就會(huì)導(dǎo)致即在第一筆調(diào)用的時(shí)候才會(huì)知道對(duì)端連接丟棄了。

那么，怎么讓client端在這種情況下感知呢，我們可以設(shè)置一下tcp_abort_on_overflow

echo '1' > tcp_abort_on_overflow 

設(shè)置后，如下圖所示:

當(dāng)然了，最直接的還是調(diào)大backlog!

listen(fd,2048) 
echo '2048' > /proc/sys/inet/ipv4/tcp_max_syn_backlog 
echo '2048' > /proc/sys/net/core/somaxconn 

backlog對(duì)半連接隊(duì)列的影響

這個(gè)backlog對(duì)半連接隊(duì)列也有影響，如下代碼所示:

/* TW buckets are converted to open requests without 
  * limitations, they conserve resources and peer is 
  * evidently real one. 
  */ 
 // 在開啟SYN cookie的情況下，如果半連接隊(duì)列長度超過backlog，則發(fā)送cookie 
 // 否則丟棄 
 if (inet_csk_reqsk_queue_is_full(sk) && !isn) { 
  want_cookie = tcp_syn_flood_action(sk, skb, "TCP"); 
  if (!want_cookie) 
   goto drop; 
 } 
 
 /* Accept backlog is full. If we have already queued enough 
  * of warm entries in syn queue, drop request. It is better than 
  * clogging syn queue with openreqs with exponentially increasing 
  * timeout. 
  */ 
 // 在全連接隊(duì)列滿的情況下，如果有young_ack，那么直接丟棄 
 if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) { 
  NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS); 
  goto drop; 
 } 

我們?cè)赿mesg里面經(jīng)?？吹降?/p>

Possible SYN flooding on port 8080  

就是由于半連接隊(duì)列滿以后，Kernel發(fā)送cookie校驗(yàn)而導(dǎo)致。

總結(jié)

TCP作為一個(gè)古老而又流行的協(xié)議，在演化了幾十年后，其設(shè)計(jì)變的相當(dāng)復(fù)雜。從而在出問題的時(shí)候變的難于分析，這時(shí)候就要reading the fucking source code!而筆者也正是寫這篇博客而詳細(xì)閱讀源碼的時(shí)候偶然間靈光一閃，找到了最近一個(gè)詭異問題的根因。這個(gè)詭異問題的分析過程將會(huì)在近期寫出來分享給大家。

本文轉(zhuǎn)載自微信公眾號(hào)「解Bug之路」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系解Bug之路公眾號(hào)。