淺談從Linux源碼分析bind系統(tǒng)調(diào)用

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

一個(gè)最簡(jiǎn)單的Server端例子

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

代碼如下:

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

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

?

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

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

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

inet_bind

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

讓我們看下inet_bind的流程?

值得注意的是，由于對(duì)于<1024的端口號(hào)需要CAP_NET_BIND_SERVICE,我們?cè)诒O(jiān)聽80端口號(hào)(例如啟動(dòng)nginx時(shí)候),需要使用root用戶或者賦予這個(gè)可執(zhí)行文件CAP_NET_BIND_SERVICE權(quán)限。

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

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

inet_csk_get_port

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

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

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

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

判斷端口號(hào)是否沖突

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

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

SO_REUSEADDR和SO_REUSEPORT

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

在原生JAVA中

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

SO_REUSEADDR

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

如果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)也可以!?

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

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

SO_REUSEPORT

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

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

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

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

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

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

Nginx已經(jīng)采用SO_REUSEPORT

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

?

總結(jié)

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