作者一直認(rèn)為，從應(yīng)用程序到框架再到系統(tǒng)，使用每一個代碼是一回事理解。使用“今天，作者將研究服務(wù)器端套接字的功能。準(zhǔn)確地說，它是bind（基于linux3.10）。

一個最簡單的Server端例子

眾所周知，一個Server端Socket的建立，需要socket、bind、listen、accept四個步驟。?

代碼如下:

首先我們通過socket系統(tǒng)調(diào)用創(chuàng)建了一個socket，其中指定了SOCK_STREAM,而且最后一個參數(shù)為0，也就是建立了一個通常所有的TCP Socket。在這里，我們直接給出TCP Socket所對應(yīng)的ops也就是操作函數(shù)。?

如果你想知道上圖中的結(jié)構(gòu)是怎么來的，可以看下筆者以前的博客:

?

bind系統(tǒng)調(diào)用

bind將一個本地協(xié)議地址(protocol:ip:port)賦予一個套接字。例如32位的ipv4地址或128位的ipv6地址+16位的TCP活UDP端口號。

好了，我們直接進(jìn)入Linux源碼調(diào)用棧吧。

inet_bind

inet_bind這個函數(shù)主要做了兩個操作，一是檢測是否允許bind，而是獲取可用的端口號。這邊值得注意的是。如果我們設(shè)置需要bind的端口號為0，那么Kernel會幫我們隨機(jī)選擇一個可用的端口號來進(jìn)行bind！

讓我們看下inet_bind的流程?

值得注意的是，由于對于<1024的端口號需要CAP_NET_BIND_SERVICE,我們在監(jiān)聽80端口號(例如啟動nginx時(shí)候),需要使用root用戶或者賦予這個可執(zhí)行文件CAP_NET_BIND_SERVICE權(quán)限。

我們的bind允許綁定到0.0.0.0即INADDR_ANY這個地址上(一般都用這個)，它意味著內(nèi)核去選擇IP地址。對我們最直接的影響如下圖所示:?

然后，我們看下一個比較復(fù)雜的函數(shù)，即可用端口號的選擇過程inet_csk_get_port (sk->sk_prot->get_port)

inet_csk_get_port

第一段，如果bind port為0，隨機(jī)搜索可用端口號

直接上源碼，第一段代碼為端口號為0的搜索過程

由于，我們在使用bind的時(shí)候很少隨機(jī)端口號(在TCP服務(wù)器來說尤其如此),這段代碼筆者就注釋一下。一般只有一些特殊的遠(yuǎn)程過程調(diào)用(RPC)中會使用隨機(jī)Server端隨機(jī)端口號。

第二段，找到端口號或已經(jīng)指定

判斷端口號是否沖突

在上述源碼中，判斷端口號時(shí)否沖突的代碼為

上面代碼的邏輯如下圖所示:?

SO_REUSEADDR和SO_REUSEPORT

上面的代碼有點(diǎn)繞，筆者就講一下，對于我們?nèi)粘ｉ_發(fā)要關(guān)心什么。 我們在上面的bind里面經(jīng)常見到sk_reuse和sk_reuseport這兩個socket的Flag。這兩個Flag能夠決定是否能夠bind(綁定)成功。這兩個Flag的設(shè)置在C語言里面如下代碼所示:

在原生JAVA中

在Netty(Netty版本 >= 4.0.16且Linux內(nèi)核版本>=3.9以上)中,可以使用SO_REUSEPORT。

SO_REUSEADDR

在之前的源碼里面，我們看到判斷bind是否沖突的時(shí)候，有這么一個分支

如果sk2(即已bind的socket)是TCP_LISTEN狀態(tài)或者，sk2和新sk兩者都沒有設(shè)置_REUSEADDR的時(shí)候，可以判斷為沖突。

我們可以得出，如果原sock和新sock都設(shè)置了SO_REUSEADDR的時(shí)候，只要原sock不是Listen狀態(tài)，都可以綁定成功，甚至ESTABLISHED狀態(tài)也可以!?

這個在我們平常工作中，最常見的就是原sock處于TIME_WAIT狀態(tài)，這通常在我們關(guān)閉Server的時(shí)候出現(xiàn)，如果不設(shè)置SO_REUSEADDR,則會綁定失敗，進(jìn)而啟動不來服務(wù)。而設(shè)置了SO_REUSEADDR,由于不是TCP_LISTEN,所以可以成功。?

這個特性在緊急重啟以及線下調(diào)試的非常有用，建議開啟。

SO_REUSEPORT

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

我們看下一般的Reactor線程模型，?

明顯的其單線程listen/accept會存在瓶頸(如果采用多線程epoll accept，則會驚群，加WQ_FLAG_EXCLUSIVE可以解決一部分)，尤其是在采用短鏈接的情況下。 鑒于此,Linux增加了SO_REUSEPORT,而之前bind中判斷是否沖突的下面代碼也是為這個參數(shù)而添加的邏輯:

這段代碼讓我們在多次bind的時(shí)候，如果設(shè)置了SO_REUSEPORT的時(shí)候不會報(bào)錯，也就是讓我們有個多線程(進(jìn)程)bind/listen的能力。如下圖所示:?

而開啟了SO_REUSEPORT后，代碼棧如下:

直接在內(nèi)核層面做負(fù)載均衡，將accept的任務(wù)分散到不同的線程的不同socket上(Sharding)，毫無疑問可以多核能力，大幅提升連接成功后的socket分發(fā)能力。

Nginx已經(jīng)采用SO_REUSEPORT

Nginx在1.9.1版本的時(shí)候引入了SO_REUSEPORT，配置如下:

?

總結(jié)

Linux有一個非常復(fù)雜的內(nèi)核源代碼，希望能對讀者有所幫助。