從Linux原始碼看Socket(TCP)的bind
前言
筆者一直覺得如果能知道從應用到框架再到作業系統的每一處程式碼，是一件Exciting的事情。 今天筆者就來從Linux原始碼的角度看下Server端的Socket在進行bind的時候到底做了哪些事情(基於Linux 3.10核心)。
一個最簡單的Server端例子
眾所周知，一個Server端Socket的建立，需要socket、bind、listen、accept四個步驟。
程式碼如下:
void start_server(){
// server fd
int sockfd_server;
// accept fd
int sockfd;
int call_err;
struct sockaddr_in sock_addr;
sockfd_server = socket(AF_INET,SOCK_STREAM,0);
memset(&sock_addr,0,sizeof(sock_addr));
sock_addr.sin_family = AF_INET;
sock_addr.sin_addr.s_addr = htonl(INADDR_ANY);
sock_addr.sin_port = htons(SERVER_PORT);
// 這邊就是我們今天的聚焦點bind
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
bind系統呼叫
bind將一個本地協議地址(protocol:ip:port)賦予一個套接字。例如32位的ipv4地址或128位的ipv6地址+16位的TCP活UDP埠號。
#include <sys/socket.h>
// 返回，若成功則為0，若出錯則為-1
int bind(int sockfd, const struct sockaddr *myaddr, socklen_t addrlen);
好了，我們直接進入Linux原始碼呼叫棧吧。
bind
// 這邊由系統呼叫的返回值會被glibc的INLINE_SYSCALL包一層
// 若有錯誤，則設定返回值為-1,同時將系統呼叫的返回值的絕對值設定給errno
|->INLINE_SYSCALL (bind......);
|->SYSCALL_DEFINE3(bind......);
/* 檢測對應的描述符fd是否存在，不存在，返回-BADF
|->sockfd_lookup_light
|->sock->ops->bind(inet_stream_ops)
|->inet_bind
|->AF_INET相容性檢查
|-><1024埠許可權檢查
/* bind埠號校驗or選擇(在bind為0的時候)
|->sk->sk_prot->get_port(inet_csk_get_port)
inet_bind
inet_bind這個函式主要做了兩個操作，一是檢測是否允許bind，而是獲取可用的埠號。這邊值得注意的是。如果我們設定需要bind的埠號為0，那麼Kernel會幫我們隨機選擇一個可用的埠號來進行bind！
// 讓系統隨機選擇可用埠號
sock_addr.sin_port = 0;
call_err=bind(sockfd_server,(struct sockaddr*)(&sock_addr),sizeof(sock_addr));
讓我們看下inet_bind的流程
值得注意的是，由於對於<1024的埠號需要CAP_NET_BIND_SERVICE,我們在監聽80埠號(例如啟動nginx時候),需要使用root使用者或者賦予這個可執行檔案CAP_NET_BIND_SERVICE許可權。
use root
or
setcap cap_net_bind_service=+eip ./nginx
我們的bind允許繫結到0.0.0.0即INADDR_ANY這個地址上(一般都用這個)，它意味著核心去選擇IP地址。對我們最直接的影響如下圖所示:
然後，我們看下一個比較複雜的函式，即可用埠號的選擇過程inet_csk_get_port
(sk->sk_prot->get_port)
inet_csk_get_port
第一段，如果bind port為0，隨機搜尋可用埠號
直接上原始碼，第一段程式碼為埠號為0的搜尋過程
// 這邊如果snum指定為0，則隨機選擇埠
int inet_csk_get_port(struct sock *sk, unsigned short snum)
{
......
// 這邊net_random()採用prandom_u32,是偽(pseudo)隨機數
smallest_rover = rover = net_random() % remaining + low;
smallest_size = -1;
// snum=0,隨機選擇埠的分支
if(!sum){
// 獲取核心設定的埠號範圍,對應核心引數/proc/sys/net/ipv4/ip_local_port_range
inet_get_local_port_range(&low,&high);
......
do{
if(inet_is_reserved_local_port(rover)
goto next_nonlock; // 不選擇保留埠號
......
inet_bind_bucket_for_each(tb, &head->chain)
// 在同一個網路名稱空間下存在和當前希望選擇的port rover一樣的port
if (net_eq(ib_net(tb), net) && tb->port == rover) {
// 已經存在的sock和當前新sock都開啟了SO_REUSEADDR,且當前sock狀態不為listen
// 或者
// 已經存在的sock和當前新sock都開啟了SO_REUSEPORT,而且兩者都是同一個使用者
if (((tb->fastreuse > 0 &&
sk->sk_reuse &&
sk->sk_state != TCP_LISTEN) ||
(tb->fastreuseport > 0 &&
sk->sk_reuseport &&
uid_eq(tb->fastuid, uid))) &&
(tb->num_owners < smallest_size || smallest_size == -1)) {
// 這邊是選擇一個最小的num_owners的port，即同時bind或者listen最小個數的port
// 因為一個埠號(port)在開啟了so_reuseaddr/so_reuseport之後，是可以多個程式同時使用的
smallest_size = tb->num_owners;
smallest_rover = rover;
if (atomic_read(&hashinfo->bsockets) > (high - low) + 1 &&
!inet_csk(sk)->icsk_af_ops->bind_conflict(sk, tb, false)) {
// 進入這個分支，表明可用埠號已經不夠了，同時繫結當前埠號和之前已經使用此port的不衝突，則我們選擇這個埠號(最小的)
snum = smallest_rover;
goto tb_found;
}
}
// 若埠號不衝突，則選擇這個埠
if (!inet_csk(sk)->icsk_af_ops->bind_conflict(sk, tb, false)) {
snum = rover;
goto tb_found;
}
goto next;
}
break;
// 直至遍歷完所有的可用port
} while (--remaining > 0);
}
.......
}
由於，我們在使用bind的時候很少隨機埠號(在TCP伺服器來說尤其如此),這段程式碼筆者就註釋一下。一般只有一些特殊的遠端過程呼叫(RPC)中會使用隨機Server端隨機埠號。
第二段，找到埠號或已經指定
have_snum:
inet_bind_bucket_for_each(tb, &head->chain)
if (net_eq(ib_net(tb), net) && tb->port == snum)
goto tb_found;
}
tb = NULL;
goto tb_not_found
tb_found:
// 如果此port已被bind
if (!hlist_empty(&tb->owners)) {
// 如果設定為強制重用，則直接成功
if (sk->sk_reuse == SK_FORCE_REUSE)
goto success;
}
if (((tb->fastreuse > 0 &&
sk->sk_reuse && sk->sk_state != TCP_LISTEN) ||
(tb->fastreuseport > 0 &&
sk->sk_reuseport && uid_eq(tb->fastuid, uid))) &&
smallest_size == -1) {
// 這個分支表明之前bind的port和當前sock都設定了reuse同時當前sock狀態不為listen
// 或者同時設定了reuseport而且是同一個uid(注意，設定了reuseport後，可以同時listen同一個port了)
goto success;
} else {
ret = 1;
// 檢查埠是否衝突
if (inet_csk(sk)->icsk_af_ops->bind_conflict(sk, tb, true)) {
if (((sk->sk_reuse && sk->sk_state != TCP_LISTEN) ||
(tb->fastreuseport > 0 &&
sk->sk_reuseport && uid_eq(tb->fastuid, uid))) &&
smallest_size != -1 && --attempts >= 0) {
// 若衝突，但是設定了reuse非listen狀態或者設定了reuseport且出在同一個使用者下
// 則可以進行重試
spin_unlock(&head->lock);
goto again;
}
goto fail_unlock;
}
// 不衝突，走下面的邏輯
}
tb_not_found:
if (!tb && (tb = inet_bind_bucket_create(hashinfo->bind_bucket_cachep,
net, head, snum)) == NULL)
goto fail_unlock;
// 設定fastreuse
// 設定fastreuseport
success:
......
// 將當前sock鏈入tb->owner，同時tb->num_owners++
inet_bind_hash(sk, tb, snum);
ret = 0;
// 返回bind(繫結)成功
return ret;
判斷埠號是否衝突
在上述原始碼中，判斷埠號時否衝突的程式碼為
inet_csk(sk)->icsk_af_ops->bind_conflict 也即 inet_csk_bind_conflict
int inet_csk_bind_conflict(const struct sock *sk,
const struct inet_bind_bucket *tb, bool relax){
......
sk_for_each_bound(sk2, &tb->owners) {
// 這邊判斷表明，必須同一個介面(dev_if)才進入下內部分支，也就是說不在同一個介面埠的不衝突
if (sk != sk2 &&
!inet_v6_ipv6only(sk2) &&
(!sk->sk_bound_dev_if ||
!sk2->sk_bound_dev_if ||
sk->sk_bound_dev_if == sk2->sk_bound_dev_if))
{
if ((!reuse || !sk2->sk_reuse ||
sk2->sk_state == TCP_LISTEN) &&
(!reuseport || !sk2->sk_reuseport ||
(sk2->sk_state != TCP_TIME_WAIT &&
!uid_eq(uid, sock_i_uid(sk2))))) {
// 在有一方沒設定reuse且sock2狀態為listen 同時
// 有一方沒設定reuseport且sock2狀態不為time_wait同時兩者的uid不一樣的時候
const __be32 sk2_rcv_saddr = sk_rcv_saddr(sk2);
if (!sk2_rcv_saddr || !sk_rcv_saddr(sk) ||
// ip地址一樣，才算衝突
sk2_rcv_saddr == sk_rcv_saddr(sk))
break;
}
// 非放鬆模式，ip地址一樣，才算衝突
......
return sk2 != NULL;
}
......
}
上面程式碼的邏輯如下圖所示:
SO_REUSEADDR和SO_REUSEPORT
上面的程式碼有點繞，筆者就講一下，對於我們日常開發要關心什麼。
我們在上面的bind裡面經常見到sk_reuse和sk_reuseport這兩個socket的Flag。這兩個Flag能夠決定是否能夠bind(繫結)成功。這兩個Flag的設定在C語言裡面如下程式碼所示:
setsockopt(sockfd_server, SOL_SOCKET, SO_REUSEADDR, &(int){ 1 }, sizeof(int));
setsockopt(sockfd_server, SOL_SOCKET, SO_REUSEPORT, &(int){ 1 }, sizeof(int));
在原生JAVA中
// java8中，原生的socket並不支援so_reuseport
ServerSocket server = new ServerSocket(port);
server.setReuseAddress(true);
在Netty(Netty版本 >= 4.0.16且Linux核心版本>=3.9以上)中,可以使用SO_REUSEPORT。
SO_REUSEADDR
在之前的原始碼裡面，我們看到判斷bind是否衝突的時候，有這麼一個分支
(!reuse || !sk2->sk_reuse ||
sk2->sk_state == TCP_LISTEN) /* 暫忽略reuseport */){
// 即有一方沒有設定
}
如果sk2(即已bind的socket)是TCP_LISTEN狀態或者，sk2和新sk兩者都沒有設定_REUSEADDR的時候，可以判斷為衝突。
我們可以得出，如果原sock和新sock都設定了SO_REUSEADDR的時候，只要原sock不是Listen狀態，都可以繫結成功，甚至ESTABLISHED狀態也可以!
這個在我們平常工作中，最常見的就是原sock處於TIME_WAIT狀態，這通常在我們關閉Server的時候出現，如果不設定SO_REUSEADDR,則會繫結失敗，進而啟動不來服務。而設定了SO_REUSEADDR,由於不是TCP_LISTEN,所以可以成功。
這個特性在緊急重啟以及線下除錯的非常有用，建議開啟。
SO_REUSEPORT
SO_REUSEPORT是Linux在3.9版本引入的新功能。
1.在海量高併發連線的建立時候，由於正常的模型是單執行緒listener分發，無法利用多核優勢，這就會成為瓶頸。
2.CPU快取行丟失
我們看下一般的Reactor執行緒模型，
明顯的其單執行緒listen/accept會存在瓶頸(如果採用多執行緒epoll accept，則會驚群，加WQ_FLAG_EXCLUSIVE可以解決一部分)，尤其是在採用短連結的情況下。
鑑於此,Linux增加了SO_REUSEPORT,而之前bind中判斷是否衝突的下面程式碼也是為這個引數而新增的邏輯:
if(!reuseport || !sk2->sk_reuseport ||
(sk2->sk_state != TCP_TIME_WAIT &&
!uid_eq(uid, sock_i_uid(sk2))
這段程式碼讓我們在多次bind的時候，如果設定了SO_REUSEPORT的時候不會報錯，也就是讓我們有個多執行緒(程式)bind/listen的能力。如下圖所示:
而開啟了SO_REUSEPORT後，程式碼棧如下:
tcp_v4_rcv
|->__inet_lookup_skb
|->__inet_lookup
|->__inet_lookup_listener
/* 用打分和偽隨機數等挑選出一個listen的sock */
struct sock *__inet_lookup_listener(......)
{
......
if (score > hiscore) {
result = sk;
hiscore = score;
reuseport = sk->sk_reuseport;
if (reuseport) {
phash = inet_ehashfn(net, daddr, hnum,
saddr, sport);
matches = 1;
}
} else if (score == hiscore && reuseport) {
matches++;
if (((u64)phash * matches) >> 32 == 0)
result = sk;
phash = next_pseudo_random32(phash);
}
......
}
直接在核心層面做負載均衡，將accept的任務分散到不同的執行緒的不同socket上(Sharding)，毫無疑問可以多核能力，大幅提升連線成功後的socket分發能力。
Nginx已經採用SO_REUSEPORT
Nginx在1.9.1版本的時候引入了SO_REUSEPORT，配置如下:
http {
server {
listen 80 reuseport;
server_name localhost;
# ...
}
}
stream {
server {
listen 12345 reuseport;
# ...
}
}
在壓測場景下，效能提升了3倍！詳情見下面連結。
https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/
總結
Linux核心原始碼博大精深，一個看起來簡單的bind系統呼叫竟然牽涉這麼多，在裡面可以挖掘出各種細節。在此分享出來，希望對讀者有所幫助。
歡迎大家關注我公眾號，裡面有各種乾貨，還有大禮包相送哦!
