共計 5592 個字符,預計需要花費 14 分鐘才能閱讀完成。
怎么從 Linux 源碼看 Socket TCP 的 Listen 及連接隊列,很多新手對此不是很清楚,為了幫助大家解決這個難題,下面丸趣 TV 小編將為大家詳細講解,有這方面需求的人可以來學習下,希望你能有所收獲。
從 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 校驗而導致。
看完上述內容是否對您有幫助呢?如果還想對相關知識有進一步的了解或閱讀更多相關文章,請關注丸趣 TV 行業資訊頻道,感謝您對丸趣 TV 的支持。