從Linux源碼看Socket(TCP)的listen及鏈接隊列

從Linux源碼看Socket(TCP)的listen及鏈接隊列

前言

筆者一直以爲若是能知道從應用到框架再到操做系統的每一處代碼，是一件Exciting的事情。 今天筆者就來從Linux源碼的角度看下Server端的Socket在進行listen的時候到底作了哪些事情(基於Linux 3.10內核)，固然因爲listen的backlog參數和半鏈接hash表以及全鏈接隊列都相關，在這一篇博客裏也一塊講了。

Server端Socket須要Listen

衆所周知，一個Server端Socket的創建，須要socket、bind、listen、accept四個步驟。
今天筆者就聚焦於Listen這個步驟。

代碼以下:

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);
    }
    // 這邊就是咱們今天的聚焦點listen
    call_err=listen(sockfd_server,MAX_BACK_LOG);
    if(call_err == -1){
        fprintf(stdout,"listen error!\n");
        exit(1);
    }
}

首先咱們經過socket系統調用建立了一個socket，其中指定了SOCK_STREAM,並且最後一個參數爲0，也就是創建了一個一般全部的TCP Socket。在這裏，咱們直接給出TCP Socket所對應的ops也就是操做函數。

若是你想知道上圖中的結構是怎麼來的，能夠看下筆者之前的博客:

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

Listen系統調用

好了，如今咱們直接進入Listen系統調用吧。

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

注意，這邊的listen調用是被glibc的INLINE_SYSCALL裝過一層，其將返回值修正爲只有0和-1這兩個選擇，同時將錯誤碼的絕對值設置在errno內。
這裏面的backlog是個很是重要的參數，若是設置很差，是個很隱蔽的坑。
對於java開發者而言，基本用的現成的框架，而java自己默認的backlog設置大小隻有50。這就會引發一些微妙的現象，這個在本文中會進行講解。

接下來，咱們就進入Linux內核源碼棧吧

listen
	|->INLINE_SYSCALL(listen......)
		|->SYSCALL_DEFINE2(listen, int, fd, int, backlog)
			/* 檢測對應的描述符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對於咱們傳進來的backlog值作了一次調整，讓其沒法>內核參數設置中的somaxconn。

inet_listen

接下來就是核心調用程序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;
	......
}

從這段代碼中，第一個有意思的地方就是,listen這個系統調用能夠重複調用！第二次調用的時候僅僅只能修改其backlog隊列長度(雖然感受沒啥必要)。

首先，咱們看下除fastopen以外的邏輯(fastopen之後開單章詳細討論)。也就是最後的inet_csk_listen_start調用。

int inet_csk_listen_start(struct sock *sk, const int nr_table_entries)
{
	......
	// 這裏的nr_table_entries即爲調整事後的backlog
	// 可是在此函數內部會進一步將nr_table_entries = min(backlog,sysctl_max_syn_backlog)這個邏輯
	int rc = reqsk_queue_alloc(&icsk->icsk_accept_queue, nr_table_entries);
	......
	inet_csk_delack_init(sk);
	// 設置socket爲listen狀態
	sk->sk_state = TCP_LISTEN;
	// 檢查端口號
	if (!sk->sk_prot->get_port(sk, inet->inet_num)){
		// 清除掉dst cache
		sk_dst_reset(sk);
		// 將當前sock鏈入listening_hash
		// 這樣，當SYN到來的時候就能經過__inet_lookup_listen函數找到這個listen中的sock
		sk->sk_prot->hash(sk);
	}
	sk->sk_state = TCP_CLOSE;
	__reqsk_queue_destroy(&icsk->icsk_accept_queue);
	// 端口已經被佔用，返回錯誤碼-EADDRINUSE
	return -EADDRINUSE;
}

這裏最重要的一個調用sk->sk_prot->hash(sk),也就是inet_hash,其將當前sock鏈入全局的listen hash表，這樣就能夠在SYN包到來的時候尋找到對應的listen sock了。以下圖所示:

如圖中所示，若是開啓了SO_REUSEPORT的話，可讓不一樣的Socket listen(監聽)同一個端口，這樣就能在內核進行建立鏈接的負載均衡。在Nginx 1.9.1版本開啓了以後，其壓測性能達到3倍!

半鏈接隊列hash表和全鏈接隊列

在筆者一開始翻閱的資料裏面,都提到。tcp的鏈接隊列有兩個，一個是sync_queue,另外一個accept_queue。但筆者仔細閱讀了一下源碼，其實並不是如此。事實上，sync_queue實際上是個hash表(syn_table)。另外一個隊列是icsk_accept_queue。

因此在本篇文章裏面，將其稱爲reqsk_queue(request_socket_queue的簡稱)。
在這裏，筆者先給出這兩個queue在三次握手時候的出現時機。以下圖所示:

固然了，除了上面提到的qlen和sk_ack_backlog這兩個計數器以外，還有一個qlen_young,其做用以下:

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

以下圖所示:

至於SYN_ACK的重傳定時器在內核中的代碼爲下面所示:

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

這個定時器在半鏈接隊列不爲空的狀況下，以200ms(TCP_SYNQ_INTERVAL)爲間隔運行一次。限於篇幅，筆者就在這裏很少討論了。

爲何要存在半鏈接隊列

由於根據TCP協議的特色，會存在半鏈接這樣的網絡攻擊存在，即不停的發SYN包，而從不迴應SYN_ACK。若是發一個SYN包就讓Kernel創建一個消耗極大的sock，那麼很容易就內存耗盡。因此內核在三次握手成功以前，只分配一個佔用內存極小的request_sock，以防止這種攻擊的現象，再配合syn_cookie機制，儘可能抵禦這種半鏈接攻擊的風險。

半鏈接hash表和全鏈接隊列的限制

因爲全鏈接隊列裏面保存的是佔用內存很大的普通sock，因此Kernel給其加了一個最大長度的限制。這個限制爲:

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

若是超過這個somaxconn會被內核丟棄，以下圖所示:

這種狀況的鏈接丟棄會發生比較詭異的現象。在不設置tcp_abort_on_overflow的時候,client端沒法感知，就會致使即在第一筆調用的時候纔會知道對端鏈接丟棄了。

那麼，怎麼讓client端在這種狀況下感知呢，咱們能夠設置一下tcp_abort_on_overflow

echo '1' > tcp_abort_on_overflow

設置後，以下圖所示:

固然了，最直接的仍是調大backlog!

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

backlog對半鏈接隊列的影響

這個backlog對半鏈接隊列也有影響，以下代碼所示:

/* TW buckets are converted to open requests without
	 * limitations, they conserve resources and peer is
	 * evidently real one.
	 */
	// 在開啓SYN cookie的狀況下，若是半鏈接隊列長度超過backlog，則發送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.
	 */
	// 在全鏈接隊列滿的狀況下，若是有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;
	}

咱們在dmesg裏面常常看到的

Possible SYN flooding on port 8080

就是因爲半鏈接隊列滿之後，Kernel發送cookie校驗而致使。

總結

TCP做爲一個古老而又流行的協議，在演化了幾十年後，其設計變的至關複雜。從而在出問題的時候變的難於分析，這時候就要reading the fucking source code!而筆者也正是寫這篇博客而詳細閱讀源碼的時候偶然間靈光一閃，找到了最近一個詭異問題的根因。這個詭異問題的分析過程將會在近期寫出來分享給你們。
歡迎你們關注我公衆號，裏面有各類乾貨，還有大禮包相送哦!