从Linux源码分析bind系统调用

导读大家好，我是极客范的本期栏目编辑小友，现在为大家讲解从Linux源码分析bind系统调用问题。序我一直认为，了解从应用程序到框架再到操作系

大家好，我是极客范的本期栏目编辑小友，现在为大家讲解从Linux源码分析bind系统调用问题。

序

我一直认为，了解从应用程序到框架再到操作系统的每一个代码将是令人兴奋的。今天，我从Linux源代码的角度来看一下服务器端的Socket在绑定时绑定了什么(基于Linux 3.10内核)。

最简单的服务器端例子之一

众所周知，服务器端socket的建立需要四个步骤：Socket、bind、listen和accept。

代码如下：

void start _ server(){ 0

//服务器fd

int sockfd _ server

//接受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(INADR _ 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){ 0

fprintf(stdout，' bind错误！\ n ')；

出口(1)；

}

//听着

call_err=listen(sockfd_server，MAX _ BACK _ LOG)；

if(call _ err==-1){ 0

fprintf(stdout，' listen error！\ n ')；

出口(1)；

}

首先，我们通过调用socket系统创建一个socket，其中指定了SOCK_STREAM，最后一个参数为0，也就是建立了所有的TCP Socket。这里我们直接给出TCP Socket对应的ops，也就是操作函数。

如果你想知道上图的结构是怎么来的，可以看看我之前的博客：

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

绑定系统调用

Bind为套接字分配一个本地协议地址(protocol:ip:port)。例如32位ipv4地址或128位ipv6地址、16位TCP实时UDP端口号。

#包括

//返回，如果成功则为0，如果错误则为-1。

int bind(int sockfd，const struct sockaddr *myaddr，sock len _ t addr len)；

好了，我们直接进入Linux源码调用栈。

约束

//这里，系统调用的返回值将被glibc的INLINE_SYSCALL包覆盖。

//如果有错误，将返回值设置为-1，将系统调用返回值的绝对值设置为errno。

|-INLINE_SYSCALL(绑定.);

|-SYSCAL _ DEFINE 3(绑定.);

/*检查对应的描述符fd是否存在，如果不存在则返回-BADF。

|-sockfd_lookup_light

|-sock-ops-bind(inet _ stream _ ops)

|-inet_bind

|-AF_INET兼容性检查

|-sk-sk _ prot-get _ port(inet _ csk _ get _ port)

inet_bind

inet_bind函数主要做两个操作。一种是检查是否允许绑定，但要获取可用的端口号。这里值得注意。如果我们将需要绑定的端口号设置为0，那么内核会帮助我们随机选择一个可用的端口号进行绑定！

让系统随机选择可用端口号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 orsetcap 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一样的portif (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 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_foundtb_found:// 如果此port已被bindif (!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// 设置fastreuseportsuccess:......// 将当前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_conflictint 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) ){// 即有一方没有设置}

如果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 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; # ... }}

总结

Linux内核源码博大精深，一个看起来简单的bind系统调用竟然牵涉这么多，在里面可以挖掘出各种细节。在此分享出来，希望对读者有所帮助。编辑：hfy

前言

笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件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 // 返回，若成功则为0，若出错则为-1int 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兼容性检查|->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的流程

use root orsetcap 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的搜索过程

第二段，找到端口号或已经指定

判断端口号是否冲突

在上述源码中，判断端口号时否冲突的代码为

上面代码的逻辑如下图所示:

SO_REUSEADDR和SO_REUSEPORT

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) ){// 即有一方没有设置}

如果sk2(即已bind的socket)是TCP_LISTEN状态或者，sk2和新sk两者都没有设置_REUSEADDR的时候，可以判断为冲突。

我们可以得出，如果原sock和新sock都设置了SO_REUSEADDR的时候，只要原sock不是Listen状态，都可以绑定成功，甚至ESTABLISHED状态也可以!

这个特性在紧急重启以及线下调试的非常有用，建议开启。

SO_REUSEPORT

SO_REUSEPORT是Linux在3.9版本引入的新功能。

1.在海量高并发连接的创建时候，由于正常的模型是单线程listener分发，无法利用多核优势，这就会成为瓶颈。2.CPU缓存行丢失

我们看下一般的Reactor线程模型，

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后，代码栈如下:

直接在内核层面做负载均衡，将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; # ... }}

总结

Linux内核源码博大精深，一个看起来简单的bind系统调用竟然牵涉这么多，在里面可以挖掘出各种细节。在此分享出来，希望对读者有所帮助。编辑：hfy

.dfma { position: relative; width: 1000px; margin: 0 auto; } .dfma a::after { position: absolute; left: 0; bottom: 0; width: 30px; line-height: 1.4; text-align: center; background-color: rgba(0, 0, 0, .5); color: #fff; font-size: 12px; content:"广告"; } .dfma img { display: block; }

猜你喜欢

最新文章