談完上一篇《Linux高性能網絡編程十談|網絡篇》，我們繼續探索高性能網絡編程，但是我覺得在談系統API之前可以先講一些Linux底層的收發包過程，如下這是一個簡單的socket編程代碼：

int main() {
    ... 

    fd = socket(AF_INET, SOCKET_STREAM, 0);
    bind(fd, ...);
    listen(fd, ...);

    // 如何建立連接
    ...
    afd = accept(fd, ...);

    // 如何接收數據
    ...
    read(afd, ...);

    // 如何發送數據
    ...
    send(afd, ...);

    // 如何關閉連接
    ...
    close(fd);
    ...
}

第一部分：如何建立連接

從上一篇文章我們介紹了網絡協議，我們知道TCP/IP協議族劃分了應用層、TCP傳輸層、IP網絡層、鏈路層(以太層驅動)。

如上圖看應用層，通常在網絡編程中我們需要調用accept的API建立TCP連接，那TCP如何做的呢?

從上圖的流程可以看到：

(1)client端發起TCP握手，發送syn包;

(2)內核收到包以后先將當前連接的信息插入到網絡的SYN隊列;

(3)插入成功后會返回握手確認(SYN+ACK);

(4)client端如果繼續完成TCP握手，回復ACK確認;

(5)內核會將TCP握手完成的包，先將對應的連接信息從SYN隊列取出;

(6)將連接信息丟入到ACCEPT隊列;

(7)應用層sever通過系統調用accept就能拿到這個連接，整個網絡套接字連接完成;

那基于這個圖，我想問問讀者這里會有什么問題么?

細心的讀者應該可以看出：

1、這里有兩個隊列，必然會有滿的情況，那如果遇到這種情況內核是怎么處理的呢?

(1)如果SYN隊列滿了，內核就會丟棄連接;

(2)如果ACCEPT隊列滿了，那內核不會繼續將SYN隊列的連接丟到ACCEPT隊列，如果SYN隊列足夠大，client端后續收發包就會超時;

(3)如果SYN隊列滿了，就會和(1)一樣丟棄連接;

2、如何控制SYN隊列和ACCEPT隊列的大小?

(1)內核2.2版本之前通過listen的backlog可以設置SYN隊列(半連接狀態SYN_REVD)和ACCEPT隊列(完全連接狀態ESTABLISHED)的上限;

(2)內核2.2版本以后backlog只是表示ACCEPT隊列上限，SYN隊列的上限可以通過/proc/sys/net/ipv4/tcp_max_syn_backlog設置;

3、server端通過accept一直等，豈不是會卡住收包的線程?

在linux網絡編程中我們都會追求高性能，accept如果卡住接收線程，性能會上不去，所以socket編程中就會有阻塞和非阻塞模式。

(1)阻塞模式下的accept就會卡住，當前線程什么事情都干不了;

(2)非阻塞模式下，可以通過輪詢accept去處理其他的事情，如果返回EAGAIN，就是ACCEPT隊列為空，如果返回連接信息，就是可以處理當前連接;

第二部分：接收數據

(1)當網卡接收到報文并判斷為TCP協議后，將會調用到內核的tcp_v4_rcv方法，如果數據按順序收到S1數據包，則直接插入receive隊列中;

(2)當收到了S3數據包，在第1步結束后，應該收到S2序號，但是報文是亂序進來的，則將S3插入out_of_order隊列(這個隊列存儲亂序報文);

(3)接下來收到S2數據包，如第1步直接進入receive隊列，由于此時out_of_order隊列不像第1步是空的，所以引發了接來的第4步;

(4)每次向receive隊列插入報文時都會檢查out_of_order隊列，如果遇到期待的序號S3，則從out_of_order隊列摘除，寫入到receive隊列;

(5)現在應用程序開始調用recv方法;

(6)經過層層封裝調用，接收TCP消息最終會走到tcp_recvmsg方法;

(7)現在需要拷貝數據從內核態到用戶態，如果receive隊列為空，會先檢查SO_RCVLOWAT這個閥值(0表示收到指定的數據返回，1表示只要讀取到數據就返回，系統默認是1)，如果已經拷貝的字節數到現在還小于它，那么可能導致進程會休眠，等待拷貝更多的數據;

(8)將數據從內核態拷貝到用戶態，recv返回拷貝數據的大小;

(9)為了選擇降低網絡包延時或者提升吞吐量，系統提供了tcp_low_latency參數，如果為0值，用戶暫時沒有讀數據則數據包進入prequeue隊列，提升吞吐量，否則不使用prequeue隊列，進入tcp_v4_do_rcv，降低延時;

第三部分：發送數據

(1)假設調用send方法來發送大于一個MSS(比如2K)的數據;

(2)內核調用tcp_sendmsg，實現復制數據，寫入隊列和組裝tcp協議頭;

(3)在調用tcp_sendmsg先需要在內核獲取skb，將用戶態數據拷貝到內核態，內核真正執行報文的發送，與send方法的調用并不是同步的，即send方法返回成功，也不一定把IP報文都發送到網絡中了。因此，需要把用戶需要發送的用戶態內存中的數據，拷貝到內核態內存中，不依賴于用戶態內存，也使得進程可以快速釋放發送數據占用的用戶態內存。但這個拷貝操作并不是簡單的復制，而是把待發送數據，按照MSS來劃分成多個盡量達到MSS大小的分片報文段，復制到內核中的sk_buff結構來存放;

(4)將數據拷貝到發送隊列中tcp_write_queue;

(5)調用tcp_push發送數據到IP層，這里主要滑動窗口，慢啟動，擁塞窗口的控制和判斷是否使用Nagle算法合并小報文(上一篇已經有介紹);

(6)組裝IP報文頭，通過經過iptables或者tcpdump等netfilter模塊過濾，將數據交給鄰居子系統(主要功能是查找需要發送的MAC地址，發送arp請求，封裝MAC頭等);

(7)調用網卡驅動程序將數據發送出去;

第四部分：關閉連接

關閉連接就是TCP揮手過程，我們都知道TCP連接是一種可靠的連接，那如何才能完整可靠的完成關閉連接呢?linux系統提供了兩個函數：

close對應tcp_close方法，通過減少socket的引用次數實現關閉，僅當引用計數為0時才會觸發tcp_close;

shutdown對應tcp_shutdown方法，不關心socket被引用次數，直接關閉對應的連接;

(1)shutdown可攜帶一個參數，取值有3個，分別意味著：只關閉讀、只關閉寫、同時關閉讀寫;

(2)若shutdown的是半打開的連接，則發出RST來關閉連接;

(3)若shutdown的是正常連接，那么關閉讀其實與對端是沒有關系的;

(4)若參數中有標志位為關閉寫，那么下面做的事與close是一致的，發出FIN包，告訴對方本機不會再發消息了;

第五部分：思考題

基于本文留幾個思考題，下一篇文章解答。

(1)發送方法返回成功后，數據一定發送到了TCP的對端么?

(調用了IP層的方法返回后，也未必就保證此時數據一定發送成功)

(2)1個socket套接字可能被多個進程在使用，出現并發訪問時，內核是怎么處理這種狀況的?

(3)若socket為默認的阻塞套接字，調用recv方法傳入的len參數，如果網絡包的數據小于len，recv會返回么?

(4)當socket被多進程或者多線程共享時，關閉連接時有何區別?