淺談從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)粘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ì)讀者有所幫助。