在之前的源码里面，我们看到判断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_REUSEPORTNginx在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系统调用竟然牵涉这么多，在里面可以挖掘出各种细节。在此分享出来，希望对读者有所帮助。
欢迎大家关注我公众号，里面有各种干货，还有大礼包相送哦!
