本文主要說(shuō)明的是TCP連接過(guò)程中，各個(gè)階段對(duì)套接字的操作，希望能對(duì)沒(méi)有網(wǎng)絡(luò)編程基礎(chǔ)的人理解套接字是什么、扮演的角色有所幫助。如發(fā)現(xiàn)錯(cuò)誤，敬請(qǐng)指出。

[[274866]]

一. 背景

1.完整的套接字格式{protocol,src_addr,src_port,dest_addr,dest_port}。

這常被稱為套接字的五元組。其中protocol指定了是TCP還是UDP連接，其余的分別指定了源地址、源端口、目標(biāo)地址、目標(biāo)端口。但是這些內(nèi)容是怎么來(lái)的呢?

2.TCP協(xié)議棧維護(hù)著兩個(gè)socket緩沖區(qū)：send buffer和recv buffer。

要通過(guò)TCP連接發(fā)送出去的數(shù)據(jù)都先拷貝到send buffer，可能是從用戶空間進(jìn)程的app buffer拷入的，也可能是從內(nèi)核的kernel buffer拷入的，拷入的過(guò)程是通過(guò)send()函數(shù)完成的，由于也可以使用write()函數(shù)寫入數(shù)據(jù)，所以也把這個(gè)過(guò)程稱為寫數(shù)據(jù)，相應(yīng)的send buffer也就有了別稱write buffer。不過(guò)send()函數(shù)比write()函數(shù)更有效率。

最終數(shù)據(jù)是通過(guò)網(wǎng)卡流出去的，所以send buffer中的數(shù)據(jù)需要拷貝到網(wǎng)卡中。由于一端是內(nèi)存，一端是網(wǎng)卡設(shè)備，可以直接使用DMA的方式進(jìn)行拷貝，無(wú)需CPU的參與。也就是說(shuō)，send buffer中的數(shù)據(jù)通過(guò)DMA的方式拷貝到網(wǎng)卡中并通過(guò)網(wǎng)絡(luò)傳輸給TCP連接的另一端：接收端。

當(dāng)通過(guò)TCP連接接收數(shù)據(jù)時(shí)，數(shù)據(jù)肯定是先通過(guò)網(wǎng)卡流入的，然后同樣通過(guò)DMA的方式拷貝到recv buffer中，再通過(guò)recv()函數(shù)將數(shù)據(jù)從recv buffer拷入到用戶空間進(jìn)程的app buffer中。

大致過(guò)程如下圖： 

3.兩種套接字：監(jiān)聽(tīng)套接字和已連接套接字。

監(jiān)聽(tīng)套接字是在服務(wù)進(jìn)程讀取配置文件時(shí)，從配置文件中解析出要監(jiān)聽(tīng)的地址、端口，然后通過(guò)socket()函數(shù)創(chuàng)建的，然后再通過(guò)bind()函數(shù)將這個(gè)監(jiān)聽(tīng)套接字綁定到對(duì)應(yīng)的地址和端口上。隨后，進(jìn)程/線程就可以通過(guò)listen()函數(shù)來(lái)監(jiān)聽(tīng)這個(gè)端口(嚴(yán)格地說(shuō)是監(jiān)控這個(gè)監(jiān)聽(tīng)套接字)。

已連接套接字是在監(jiān)聽(tīng)到TCP連接請(qǐng)求并三次握手后，通過(guò)accept()函數(shù)返回的套接字，后續(xù)進(jìn)程/線程就可以通過(guò)這個(gè)已連接套接字和客戶端進(jìn)行TCP通信。

為了區(qū)分socket()函數(shù)和accept()函數(shù)返回的兩個(gè)套接字描述符，有些人使用listenfd和connfd分別表示監(jiān)聽(tīng)套接字和已連接套接字，挺形象的，下文偶爾也這么使用。

下面就來(lái)說(shuō)明各種函數(shù)的作用，分析這些函數(shù)，也是在連接、斷開連接的過(guò)程。

二. 連接的具體過(guò)程分析

如下圖：

2.1 socket()函數(shù)

socket()函數(shù)的作用就是生成一個(gè)用于通信的套接字文件描述符sockfd(socket() creates an endpoint for communication and returns a descriptor)。這個(gè)套接字描述符可以作為稍后bind()函數(shù)的綁定對(duì)象。

2.2 bind()函數(shù)

服務(wù)程序通過(guò)分析配置文件，從中解析出想要監(jiān)聽(tīng)的地址和端口，再加上可以通過(guò)socket()函數(shù)生成的套接字sockfd，就可以使用bind()函數(shù)將這個(gè)套接字綁定到要監(jiān)聽(tīng)的地址和端口組合"addr:port"上。綁定了端口的套接字可以作為listen()函數(shù)的監(jiān)聽(tīng)對(duì)象。

綁定了地址和端口的套接字就有了源地址和源端口(對(duì)服務(wù)器自身來(lái)說(shuō)是源)，再加上通過(guò)配置文件中指定的協(xié)議類型，五元組中就有了其中3個(gè)元組。即：

{protocal,src_addr,src_port}

但是，常見(jiàn)到有些服務(wù)程序可以配置監(jiān)聽(tīng)多個(gè)地址、端口實(shí)現(xiàn)多實(shí)例。這實(shí)際上就是通過(guò)多次socket()+bind()系統(tǒng)調(diào)用生成并綁定多個(gè)套接字實(shí)現(xiàn)的。

2.3 listen()函數(shù)和connect()函數(shù)

顧名思義，listen()函數(shù)就是監(jiān)聽(tīng)已經(jīng)通過(guò)bind()綁定了addr+port的套接字的。監(jiān)聽(tīng)之后，套接字就從CLOSE狀態(tài)轉(zhuǎn)變?yōu)長(zhǎng)ISTEN狀態(tài)，于是這個(gè)套接字就可以對(duì)外提供TCP連接的窗口了。

而connect()函數(shù)則用于向某個(gè)已監(jiān)聽(tīng)的套接字發(fā)起連接請(qǐng)求，也就是發(fā)起TCP的三次握手過(guò)程。從這里可以看出，連接請(qǐng)求方(如客戶端)才會(huì)使用connect()函數(shù)，當(dāng)然，在發(fā)起connect()之前，連接發(fā)起方也需要生成一個(gè)sockfd，且使用的很可能是綁定了隨機(jī)端口的套接字。既然connect()函數(shù)是向某個(gè)套接字發(fā)起連接的，自然在使用connect()函數(shù)時(shí)需要帶上連接的目的地，即目標(biāo)地址和目標(biāo)端口，這正是服務(wù)端的監(jiān)聽(tīng)套接字上綁定的地址和端口。同時(shí)，它還要帶上自己的地址和端口，對(duì)于服務(wù)端來(lái)說(shuō)，這就是連接請(qǐng)求的源地址和源端口。于是，TCP連接的兩端的套接字都已經(jīng)成了五元組的完整格式。

2.3.1 深入分析listen()

再來(lái)細(xì)說(shuō)listen()函數(shù)。如果監(jiān)聽(tīng)了多個(gè)地址+端口，即需要監(jiān)聽(tīng)多個(gè)套接字，那么此刻負(fù)責(zé)監(jiān)聽(tīng)的進(jìn)程/線程會(huì)采用select()、poll()的方式去輪詢這些套接字(當(dāng)然，也可以使用epoll()模式)，其實(shí)只監(jiān)控一個(gè)套接字時(shí)，也是使用這些模式去輪詢的，只不過(guò)select()或poll()所感興趣的套接字描述符只有一個(gè)而已。

不管使用select()還是poll()模式(至于epoll的不同監(jiān)控方式就無(wú)需多言了)，在進(jìn)程/線程(監(jiān)聽(tīng)者)監(jiān)聽(tīng)的過(guò)程中，它阻塞在select()或poll()上。直到有數(shù)據(jù)(SYN信息)寫入到它所監(jiān)聽(tīng)的sockfd中(即recv buffer)，監(jiān)聽(tīng)者被喚醒并將SYN數(shù)據(jù)拷貝到用戶空間中自己管理的app buffer中進(jìn)行一番處理，并發(fā)送SYN+ACK，這個(gè)數(shù)據(jù)同樣需要從app buffer中拷入send buffer(使用send()函數(shù))中，再拷入網(wǎng)卡傳送出去。這時(shí)會(huì)在連接未完成隊(duì)列中為這個(gè)連接創(chuàng)建一個(gè)新項(xiàng)目，并設(shè)置為SYN_RECV狀態(tài)。然后再次使用select()/poll()方式監(jiān)控著套接字listenfd，直到再次有數(shù)據(jù)寫入這個(gè)listenfd中監(jiān)聽(tīng)者才被喚醒，如果這次寫入的數(shù)據(jù)是ACK信息，則將數(shù)據(jù)拷入到app buffer中進(jìn)行一番處理后，把連接未完成隊(duì)列中對(duì)應(yīng)的項(xiàng)目移入連接已完成隊(duì)列，并設(shè)置為ESTABLISHED狀態(tài)，如果這次接收的不是ACK，則肯定是SYN，也就是新的連接請(qǐng)求，于是和上面的處理過(guò)程一樣，放入連接未完成隊(duì)列。這就是監(jiān)聽(tīng)者處理整個(gè)TCP連接的循環(huán)過(guò)程。

也就是說(shuō)，listen()函數(shù)還維護(hù)了兩個(gè)隊(duì)列：連接未完成隊(duì)列和連接已完成隊(duì)列。當(dāng)監(jiān)聽(tīng)者接收到某個(gè)客戶端發(fā)來(lái)的SYN并回復(fù)了SYN+ACK之后，就會(huì)在未完成連接隊(duì)列的尾部創(chuàng)建一個(gè)關(guān)于這個(gè)客戶端的條目，并設(shè)置它的狀態(tài)為SYN_RECV。顯然，這個(gè)條目中必須包含客戶端的地址和端口相關(guān)信息(可能是hash過(guò)的，我不太確定)。當(dāng)服務(wù)端再次收到這個(gè)客戶端發(fā)送的ACK信息之后，監(jiān)聽(tīng)者線程通過(guò)分析數(shù)據(jù)就知道這個(gè)消息是回復(fù)給未完成連接隊(duì)列中的哪一項(xiàng)的，于是將這一項(xiàng)移入到已完成連接隊(duì)列，并設(shè)置它的狀態(tài)為ESTABLISHED。

當(dāng)未完成連接隊(duì)列滿了，監(jiān)聽(tīng)者被阻塞不再接收新的連接請(qǐng)求，并通過(guò)select()/poll()等待兩個(gè)隊(duì)列觸發(fā)可寫事件。當(dāng)已完成連接隊(duì)列滿了，則監(jiān)聽(tīng)者也不會(huì)接收新的連接請(qǐng)求，同時(shí)，正準(zhǔn)備移入到已完成連接隊(duì)列的動(dòng)作被阻塞。在Linux 2.2以前，listen()函數(shù)有一個(gè)backlog的參數(shù)，用于設(shè)置這兩個(gè)隊(duì)列的最大總長(zhǎng)度，從Linux 2.2開始，這個(gè)參數(shù)只表示已完成隊(duì)列的最大長(zhǎng)度，而/proc/sys/net/ipv4/tcp_max_syn_backlog則用于設(shè)置未完成隊(duì)列的最大長(zhǎng)度。/proc/sys/net/core/somaxconn則是硬限制已完成隊(duì)列的最大長(zhǎng)度，默認(rèn)為128，如果backlog大于somaxconn，則backlog會(huì)被截?cái)酁榈扔谠撝怠?/p>

當(dāng)連接已完成隊(duì)列中的某個(gè)連接被accept()后，表示TCP連接已經(jīng)建立完成，這個(gè)連接將采用自己的socket buffer和客戶端進(jìn)行數(shù)據(jù)傳輸。這個(gè)socket buffer和監(jiān)聽(tīng)套接字的socket buffer都是用來(lái)存儲(chǔ)TCP收、發(fā)的數(shù)據(jù)，但它們的意義已經(jīng)不再一樣：監(jiān)聽(tīng)套接字的socket buffer只接受TCP連接請(qǐng)求過(guò)程中的syn和ack數(shù)據(jù);而已建立的TCP連接的socket buffer主要存儲(chǔ)的內(nèi)容是兩端傳輸?shù)?quot;正式"數(shù)據(jù)，例如服務(wù)端構(gòu)建的響應(yīng)數(shù)據(jù)，客戶端發(fā)起的Http請(qǐng)求數(shù)據(jù)。

netstat命令的Send-Q和Recv-Q列表示的就是socket buffer相關(guān)的內(nèi)容，以下是man netstat的解釋。

Recv-Q Established: The count of bytes not copied by the user program connected to this socket. Listening: Since Kernel 2.6.18 this column contains the current syn backlog.Send-Q Established: The count of bytes not acknowledged by the remote host. Listening: Since Kernel 2.6.18 this column contains the maximum size of the syn backlog.

對(duì)于監(jiān)聽(tīng)狀態(tài)的套接字，Recv-Q表示的是當(dāng)前syn backlog，即已完成隊(duì)列中當(dāng)前的連接個(gè)數(shù)，Send-Q表示的是syn backlog的最大值，即已完成連接隊(duì)列的最大連接限制個(gè)數(shù);

對(duì)于已經(jīng)建立的tcp連接，Recv-Q列表示的是recv buffer中還未被用戶進(jìn)程拷貝走的數(shù)據(jù)大小，Send-Q列表示的是遠(yuǎn)程主機(jī)還未返回ACK消息的數(shù)據(jù)大小。之所以區(qū)分已建立TCP連接的套接字和監(jiān)聽(tīng)狀態(tài)的套接字，就是因?yàn)檫@兩種狀態(tài)的套接字采用不同的socket buffer，其中監(jiān)聽(tīng)套接字更注重隊(duì)列的長(zhǎng)度，而已建立TCP連接的套接字更注重收、發(fā)的數(shù)據(jù)大小。

[root@xuexi ~]# netstat -tnlActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp6 0 0 :::80 :::* LISTEN tcp6 0 0 :::22 :::* LISTEN tcp6 0 0 ::1:25 :::* LISTEN[root@xuexi ~]# ss -tnlState Recv-Q Send-Q Local Address:Port Peer Address:PortLISTEN 0 128 *:22 *:* LISTEN 0 100 127.0.0.1:25 *:* LISTEN 0 128 :::80 :::* LISTEN 0 128 :::22 :::* LISTEN 0 100 ::1:25 :::*

注意，Listen狀態(tài)下的套接字，netstat的Send-Q和ss命令的Send-Q列的值不一樣，因?yàn)閚etstat根本就沒(méi)寫上已完成隊(duì)列的最大長(zhǎng)度。因此，判斷隊(duì)列中是否還有空閑位置接收新的tcp連接請(qǐng)求時(shí)，應(yīng)該盡可能地使用ss命令而不是netstat。

2.3.2 syn flood的影響

此外，如果監(jiān)聽(tīng)者發(fā)送SYN+ACK后，遲遲收不到客戶端返回的ACK消息，監(jiān)聽(tīng)者將被select()/poll()設(shè)置的超時(shí)時(shí)間喚醒，并對(duì)該客戶端重新發(fā)送SYN+ACK消息，防止這個(gè)消息遺失在茫茫網(wǎng)絡(luò)中。但是，這一重發(fā)就出問(wèn)題了，如果客戶端調(diào)用connect()時(shí)偽造源地址，那么監(jiān)聽(tīng)者回復(fù)的SYN+ACK消息是一定到不了對(duì)方的主機(jī)的，也就是說(shuō)，監(jiān)聽(tīng)者會(huì)遲遲收不到ACK消息，于是重新發(fā)送SYN+ACK。但無(wú)論是監(jiān)聽(tīng)者因?yàn)閟elect()/poll()設(shè)置的超時(shí)時(shí)間一次次地被喚醒，還是一次次地將數(shù)據(jù)拷入send buffer，這期間都是需要CPU參與的，而且send buffer中的SYN+ACK還要再拷入網(wǎng)卡(這次是DMA拷貝，不需要CPU)。如果，這個(gè)客戶端是個(gè)攻擊者，源源不斷地發(fā)送了數(shù)以千、萬(wàn)計(jì)的SYN，監(jiān)聽(tīng)者幾乎直接就崩潰了，網(wǎng)卡也會(huì)被阻塞的很嚴(yán)重。這就是所謂的syn flood攻擊。

解決syn flood的方法有多種，例如，縮小listen()維護(hù)的兩個(gè)隊(duì)列的最大長(zhǎng)度，減少重發(fā)syn+ack的次數(shù)，增大重發(fā)的時(shí)間間隔，減少收到ack的等待超時(shí)時(shí)間，使用syncookie等，但直接修改tcp選項(xiàng)的任何一種方法都不能很好兼顧性能和效率。所以在連接到達(dá)監(jiān)聽(tīng)者線程之前對(duì)數(shù)據(jù)包進(jìn)行過(guò)濾是極其重要的手段。

2.4 accept()函數(shù)

accpet()函數(shù)的作用是讀取已完成連接隊(duì)列中的第一項(xiàng)(讀完就從隊(duì)列中移除)，并對(duì)此項(xiàng)生成一個(gè)用于后續(xù)連接的套接字描述符，假設(shè)使用connfd來(lái)表示。有了新的連接套接字，工作進(jìn)程/線程(稱其為工作者)就可以通過(guò)這個(gè)連接套接字和客戶端進(jìn)行數(shù)據(jù)傳輸，而前文所說(shuō)的監(jiān)聽(tīng)套接字(sockfd)則仍然被監(jiān)聽(tīng)者監(jiān)聽(tīng)。

例如，prefork模式的httpd，每個(gè)子進(jìn)程既是監(jiān)聽(tīng)者，又是工作者，每個(gè)客戶端發(fā)起連接請(qǐng)求時(shí)，子進(jìn)程在監(jiān)聽(tīng)時(shí)將它接收進(jìn)來(lái)，并釋放對(duì)監(jiān)聽(tīng)套接字的監(jiān)聽(tīng)，使得其他子進(jìn)程可以去監(jiān)聽(tīng)這個(gè)套接字。多個(gè)來(lái)回后，終于是通過(guò)accpet()函數(shù)生成了新的連接套接字，于是這個(gè)子進(jìn)程就可以通過(guò)這個(gè)套接字專心地和客戶端建立交互，當(dāng)然，中途可能會(huì)因?yàn)楦鞣Nio等待而多次被阻塞或睡眠。這種效率真的很低，僅僅考慮從子進(jìn)程收到SYN消息開始到最后生成新的連接套接字這幾個(gè)階段，這個(gè)子進(jìn)程一次又一次地被阻塞。當(dāng)然，可以將監(jiān)聽(tīng)套接字設(shè)置為非阻塞IO模式，只是即使是非阻塞模式，它也要不斷地去檢查狀態(tài)。

再考慮worker/event處理模式，每個(gè)子進(jìn)程中都使用了一個(gè)專門的監(jiān)聽(tīng)線程和N個(gè)工作線程。監(jiān)聽(tīng)線程專門負(fù)責(zé)監(jiān)聽(tīng)并建立新的連接套接字描述符，放入apache的套接字隊(duì)列中。這樣監(jiān)聽(tīng)者和工作者就分開了，在監(jiān)聽(tīng)的過(guò)程中，工作者可以仍然可以自由地工作。如果只從監(jiān)聽(tīng)這一個(gè)角度來(lái)說(shuō)，worker/event模式比prefork模式性能高的不是一點(diǎn)半點(diǎn)。

當(dāng)監(jiān)聽(tīng)者發(fā)起accept()系統(tǒng)調(diào)用的時(shí)候，如果已完成連接隊(duì)列中沒(méi)有任何數(shù)據(jù)，那么監(jiān)聽(tīng)者會(huì)被阻塞。當(dāng)然，可將套接字設(shè)置為非阻塞模式，這時(shí)accept()在得不到數(shù)據(jù)時(shí)會(huì)返回EWOULDBLOCK或EAGAIN的錯(cuò)誤?？梢允褂胹elect()或poll()或epoll來(lái)等待已完成連接隊(duì)列的可讀事件。還可以將套接字設(shè)置為信號(hào)驅(qū)動(dòng)IO模式，讓已完成連接隊(duì)列中新加入的數(shù)據(jù)通知監(jiān)聽(tīng)者將數(shù)據(jù)復(fù)制到app buffer中并使用accept()進(jìn)行處理。

常聽(tīng)到同步連接和異步連接的概念，它們到底是怎么區(qū)分的?同步連接的意思是，從監(jiān)聽(tīng)者監(jiān)聽(tīng)到某個(gè)客戶端發(fā)送的SYN數(shù)據(jù)開始，它必須一直等待直到建立連接套接字、并和客戶端數(shù)據(jù)交互結(jié)束，在和這個(gè)客戶端的連接關(guān)閉之前，中間不會(huì)接收任何其他客戶端的連接請(qǐng)求。細(xì)致一點(diǎn)解釋，那就是同步連接時(shí)需要保證socket buffer和app buffer數(shù)據(jù)保持一致。通常以同步連接的方式處理時(shí)，監(jiān)聽(tīng)者和工作者是同一個(gè)進(jìn)程，例如httpd的prefork模型。而異步連接則可以在建立連接和數(shù)據(jù)交互的任何一個(gè)階段接收、處理其他連接請(qǐng)求。通常，監(jiān)聽(tīng)者和工作者不是同一個(gè)進(jìn)程時(shí)使用異步連接的方式，例如httpd的event模型，盡管worker模型中監(jiān)聽(tīng)者和工作者分開了，但是仍采用同步連接，監(jiān)聽(tīng)者將連接請(qǐng)求接入并創(chuàng)建了連接套接字后，立即交給工作線程，工作線程處理的過(guò)程中一直只服務(wù)于該客戶端直到連接斷開，而event模式的異步也僅僅是在工作線程處理特殊的連接(如處于長(zhǎng)連接狀態(tài)的連接)時(shí)，可以將它交給監(jiān)聽(tīng)線程保管而已，對(duì)于正常的連接，它仍等價(jià)于同步連接的方式，因此httpd的event所謂異步，其實(shí)是偽異步。通俗而不嚴(yán)謹(jǐn)?shù)卣f(shuō)，同步連接是一個(gè)進(jìn)程/線程處理一個(gè)連接，異步連接是一個(gè)進(jìn)程/線程處理多個(gè)連接。

2.5 send()和recv()函數(shù)

send()函數(shù)是將數(shù)據(jù)從app buffer復(fù)制到send buffer中(當(dāng)然，也可能直接從內(nèi)核的kernel buffer中復(fù)制)，recv()函數(shù)則是將recv buffer中的數(shù)據(jù)復(fù)制到app buffer中。當(dāng)然，使用write()和read()函數(shù)替代它們并沒(méi)有什么不可以，只是send()/recv()的針對(duì)性更強(qiáng)而已。

這兩個(gè)函數(shù)都涉及到了socket buffer，但是在調(diào)用send()或recv()時(shí)，復(fù)制的源buffer中是否有數(shù)據(jù)、復(fù)制的目標(biāo)buffer中是否已滿而導(dǎo)致不可寫是需要考慮的問(wèn)題。不管哪一方，只要不滿足條件，調(diào)用send()/recv()時(shí)進(jìn)程/線程會(huì)被阻塞(假設(shè)套接字設(shè)置為阻塞式IO模型)。當(dāng)然，可以將套接字設(shè)置為非阻塞IO模型，這時(shí)在buffer不滿足條件時(shí)調(diào)用send()/recv()函數(shù)，調(diào)用函數(shù)的進(jìn)程/線程將返回錯(cuò)誤狀態(tài)信息EWOULDBLOCK或EAGAIN。buffer中是否有數(shù)據(jù)、是否已滿而導(dǎo)致不可寫，其實(shí)可以使用select()/poll()/epoll去監(jiān)控對(duì)應(yīng)的文件描述符(對(duì)應(yīng)socket buffer則監(jiān)控該socket描述符)，當(dāng)滿足條件時(shí)，再去調(diào)用send()/recv()就可以正常操作了。還可以將套接字設(shè)置為信號(hào)驅(qū)動(dòng)IO或異步IO模型，這樣數(shù)據(jù)準(zhǔn)備好、復(fù)制好之前就不用再做無(wú)用功去調(diào)用send()/recv()了。

2.6 close()、shutdown()函數(shù)

通用的close()函數(shù)可以關(guān)閉一個(gè)文件描述符，當(dāng)然也包括面向連接的網(wǎng)絡(luò)套接字描述符。當(dāng)調(diào)用close()時(shí)，將會(huì)嘗試發(fā)送send buffer中的所有數(shù)據(jù)。但是close()函數(shù)只是將這個(gè)套接字引用計(jì)數(shù)減1，就像rm一樣，刪除一個(gè)文件時(shí)只是移除一個(gè)硬鏈接數(shù)，只有這個(gè)套接字的所有引用計(jì)數(shù)都被刪除，套接字描述符才會(huì)真的被關(guān)閉，才會(huì)開始后續(xù)的四次揮手中。對(duì)于父子進(jìn)程共享套接字的并發(fā)服務(wù)程序，調(diào)用close()關(guān)閉子進(jìn)程的套接字并不會(huì)真的關(guān)閉套接字，因?yàn)楦高M(jìn)程的套接字還處于打開狀態(tài)，如果父進(jìn)程一直不調(diào)用close()函數(shù)，那么這個(gè)套接字將一直處于打開狀態(tài)，見(jiàn)一直進(jìn)入不了四次揮手過(guò)程。

而shutdown()函數(shù)專門用于關(guān)閉網(wǎng)絡(luò)套接字的連接，和close()對(duì)引用計(jì)數(shù)減一不同的是，它直接掐斷套接字的所有連接，從而引發(fā)四次揮手的過(guò)程?？梢灾付?種關(guān)閉方式：

1.關(guān)閉寫。此時(shí)將無(wú)法向send buffer中再寫數(shù)據(jù)，send buffer中已有的數(shù)據(jù)會(huì)一直發(fā)送直到完畢。

2.關(guān)閉讀。此時(shí)將無(wú)法從recv buffer中再讀數(shù)據(jù)，recv buffer中已有的數(shù)據(jù)只能被丟棄。

3.關(guān)閉讀和寫。此時(shí)無(wú)法讀、無(wú)法寫，send buffer中已有的數(shù)據(jù)會(huì)發(fā)送直到完畢，但recv buffer中已有的數(shù)據(jù)將被丟棄。

無(wú)論是shutdown()還是close()，每次調(diào)用它們，在真正進(jìn)入四次揮手的過(guò)程中，它們都會(huì)發(fā)送一個(gè)FIN。

三. 地址/端口重用技術(shù)

正常情況下，一個(gè)addr+port只能被一個(gè)套接字綁定，換句話說(shuō)，addr+port不能被重用，不同套接字只能綁定到不同的addr+port上。舉個(gè)例子，如果想要開啟兩個(gè)sshd實(shí)例，先后啟動(dòng)的sshd實(shí)例配置文件中，必須不能配置同樣的addr+port。同理，配置web虛擬主機(jī)時(shí)，除非是基于域名，否則兩個(gè)虛擬主機(jī)必須不能配置同一個(gè)addr+port，而基于域名的虛擬主機(jī)能綁定同一個(gè)addr+port的原因是http的請(qǐng)求報(bào)文中包含主機(jī)名信息，實(shí)際上在這類連接請(qǐng)求到達(dá)的時(shí)候，仍是通過(guò)同一個(gè)套接字進(jìn)行監(jiān)聽(tīng)的，只不過(guò)監(jiān)聽(tīng)到之后，httpd的工作進(jìn)程/線程可以將這個(gè)連接分配到對(duì)應(yīng)的主機(jī)上。

既然上面說(shuō)的是正常情況下，當(dāng)然就有非正常情況，也就是地址重用和端口重用技術(shù)，組合起來(lái)就是套接字重用。在現(xiàn)在的Linux內(nèi)核中，已經(jīng)有支持地址重用的socket選項(xiàng)SO_REUSEADDR和支持端口重用的socket選項(xiàng)SO_REUSEPORT。設(shè)置了端口重用選項(xiàng)后，再去綁定套接字，就不會(huì)再有錯(cuò)誤了。而且，一個(gè)實(shí)例綁定了兩個(gè)addr+port之后(可以綁定多個(gè)，此處以兩個(gè)為例)，就可以同一時(shí)刻使用兩個(gè)監(jiān)聽(tīng)進(jìn)程/線程分別去監(jiān)聽(tīng)它們，客戶端發(fā)來(lái)的連接也就可以通過(guò)round-robin的均衡算法輪流地被接待。

對(duì)于監(jiān)聽(tīng)進(jìn)程/線程來(lái)說(shuō)，每次重用的套接字被稱為監(jiān)聽(tīng)桶(listener bucket)，即每個(gè)監(jiān)聽(tīng)套接字都是一個(gè)監(jiān)聽(tīng)桶。

以httpd的worker或event模型為例，假設(shè)目前有3個(gè)子進(jìn)程，每個(gè)子進(jìn)程中都有一個(gè)監(jiān)聽(tīng)線程和N個(gè)工作線程。

那么，在沒(méi)有地址重用的情況下，各個(gè)監(jiān)聽(tīng)線程是爭(zhēng)搶式監(jiān)聽(tīng)的。在某一時(shí)刻，這個(gè)監(jiān)聽(tīng)套接字上只能有一個(gè)監(jiān)聽(tīng)線程在監(jiān)聽(tīng)(通過(guò)獲取互斥鎖mutex方式獲取監(jiān)聽(tīng)資格)，當(dāng)這個(gè)監(jiān)聽(tīng)線程接收到請(qǐng)求后，讓出監(jiān)聽(tīng)的資格，于是其他監(jiān)聽(tīng)線程去搶這個(gè)監(jiān)聽(tīng)資格，并只有一個(gè)線程可以搶的到。如下圖：

當(dāng)使用了地址重用和端口重用技術(shù)，就可以為同一個(gè)addr+port綁定多個(gè)套接字。例如下圖中是多使用一個(gè)監(jiān)聽(tīng)桶時(shí)，有兩個(gè)套接字，于是有兩個(gè)監(jiān)聽(tīng)線程可以同時(shí)進(jìn)行監(jiān)聽(tīng)，當(dāng)某個(gè)監(jiān)聽(tīng)線程接收到請(qǐng)求后，讓出資格，讓其他監(jiān)聽(tīng)線程去爭(zhēng)搶資格。

如果再多綁定一個(gè)套接字，那么這三個(gè)監(jiān)聽(tīng)線程都不用讓出監(jiān)聽(tīng)資格，可以無(wú)限監(jiān)聽(tīng)。如下圖。

似乎感覺(jué)上去，性能很好，不僅減輕了監(jiān)聽(tīng)資格(互斥鎖)的爭(zhēng)搶，避免"饑餓問(wèn)題"，還能更高效地監(jiān)聽(tīng)，并因?yàn)榭梢载?fù)載均衡，從而可以減輕監(jiān)聽(tīng)線程的壓力。但實(shí)際上，每個(gè)監(jiān)聽(tīng)線程的監(jiān)聽(tīng)過(guò)程都是需要消耗CPU的，如果只有一核CPU，即使重用了也體現(xiàn)不出重用的優(yōu)勢(shì)，反而因?yàn)榍袚Q監(jiān)聽(tīng)線程而降低性能。因此，要使用端口重用，必須考慮是否已將各監(jiān)聽(tīng)進(jìn)程/線程隔離在各自的cpu中，也就是說(shuō)是否重用、重用幾次都需考慮cpu的核數(shù)以及是否將進(jìn)程與cpu相互綁定。