從 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! 而筆者也正是寫這篇博客而詳細閱讀源碼的時候偶然間靈光一閃,找到了最近一個詭異問題的根因。這個詭異問題的分析過程將會在近期寫出來分享給大家。
歡迎大家關注我公衆號,裏面有各種乾貨,還有大禮包相送哦!
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/yP8FsGbRvl_oWBH1vX8EOA