從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!而筆者也正是寫這篇博客而詳細閱讀源碼的時候偶然間靈光一閃，找到了最近一個詭異問題的根因。這個詭異問題的分析過程將會在近期寫出來分享給大家。
本文轉載自微信公眾號「解Bug之路」，可以通過以下二維碼關注。轉載本文請聯系解Bug之路公眾號。
