RFC793文檔里帶有SYN標(biāo)志的過程包是不可以攜帶數(shù)據(jù)的，也就是說三次握手的前兩次是不可以攜帶數(shù)據(jù)的（邏輯上看，連接還沒建立，攜帶數(shù)據(jù)好像也有點(diǎn)說不過去）。重點(diǎn)就是第三次握手可不可以攜帶數(shù)據(jù)。

先說結(jié)論：TCP協(xié)議建立連接的三次握手過程中的第三次握手允許攜帶數(shù)據(jù)。

對(duì)照著上邊的TCP狀態(tài)變化圖的連接建立部分，我們看下RFC793文檔的說法。RFC793文檔給出的說法如下（省略不重要的部分）：

重點(diǎn)是這句 “Data or controls which were queued for transmission may be included”，也就是說標(biāo)準(zhǔn)表示，第三次握手的ACK包是可以攜帶數(shù)據(jù)。

首先， 第三次握手的包是由連接發(fā)起方（以下簡(jiǎn)稱客戶端）發(fā)給端口監(jiān)聽方（以下簡(jiǎn)稱服務(wù)端）的，所以只需要找到內(nèi)核協(xié)議棧在一個(gè)連接處于SYN-RECV（圖中的SYN_RECEIVED）狀態(tài)時(shí)收到包之后的處理過程即可。經(jīng)過一番搜索后找到了，位于 net\ipv4目錄下tcp_input.c文件中的tcp_rcv_state_process函數(shù)處理這個(gè)過程。如圖：

這個(gè)函數(shù)實(shí)際上是個(gè)TCP狀態(tài)機(jī)，用于處理TCP連接處于各個(gè)狀態(tài)時(shí)收到數(shù)據(jù)包的處理工作。這里有幾個(gè)并列的switch語句，因?yàn)楹瘮?shù)很長(zhǎng)，所以比較容易看錯(cuò)層次關(guān)系。下圖是精簡(jiǎn)了無需關(guān)注的代碼之后SYN-RECV狀態(tài)的處理過程：

一定要注意這兩個(gè)switch語句是并列的。所以當(dāng)TCP_SYN_RECV狀態(tài)收到合法規(guī)范的二次握手包之后，就會(huì)立即把socket狀態(tài)設(shè)置為TCP_ESTABLISHED狀態(tài)，執(zhí)行到下面的TCP_ESTABLISHED狀態(tài)的case時(shí)，會(huì)繼續(xù)處理其包含的數(shù)據(jù)（如果有）。

上面表明了，當(dāng)客戶端發(fā)過來的第三次握手的ACK包含有數(shù)據(jù)時(shí)，服務(wù)端是可以正常處理的。那么客戶端那邊呢？那看看客戶端處于SYN-SEND狀態(tài)時(shí)，怎么發(fā)送第三次ACK包吧。如圖：

tcp_rcv_synsent_state_process函數(shù)的實(shí)現(xiàn)比較長(zhǎng)，這里直接貼出最后的關(guān)鍵點(diǎn)：

一目了然吧？if 條件不滿足直接回復(fù)單獨(dú)的ACK包，如果任意條件滿足的話則使用inet_csk_reset_xmit_timer函數(shù)設(shè)置定時(shí)器等待短暫的時(shí)間。這段時(shí)間如果有數(shù)據(jù)，隨著數(shù)據(jù)發(fā)送ACK，沒有數(shù)據(jù)回復(fù)ACK。

之前的疑問算是解決了。

條件1：sk->sk_write_pending != 0

這個(gè)值默認(rèn)是0的，那什么情況會(huì)導(dǎo)致不為0呢？答案是協(xié)議棧發(fā)送數(shù)據(jù)的函數(shù)遇到socket狀態(tài)不是ESTABLISHED的時(shí)候，會(huì)對(duì)這個(gè)變量做++操作，并等待一小會(huì)時(shí)間嘗試發(fā)送數(shù)據(jù)?？磮D：

net/core/stream.c里的sk_stream_wait_connect函數(shù)做了如下操作：

sk->sk_write_pending遞增，并且等待socket連接到達(dá)ESTABLISHED狀態(tài)后發(fā)出數(shù)據(jù)。這就解釋清楚了。

Linux socket的默認(rèn)工作方式是阻塞的，也就是說，客戶端的connect調(diào)用在默認(rèn)情況下會(huì)阻塞，等待三次握手過程結(jié)束之后或者遇到錯(cuò)誤才會(huì)返回。那么nc這種完全用阻塞套接字實(shí)現(xiàn)的且沒有對(duì)默認(rèn)socket參數(shù)進(jìn)行修改的命令行小程序會(huì)乖乖等待connect返回成功或者失敗才會(huì)發(fā)送數(shù)據(jù)的，這就是我們抓不到第三次握手的包帶有數(shù)據(jù)的原因。

那么設(shè)置非阻塞套接字，connect后立即send數(shù)據(jù)，連接過程不是瞬間連接成功的話，也許有機(jī)會(huì)看到第三次握手包帶數(shù)據(jù)。不過開源的網(wǎng)絡(luò)庫即便是非阻塞socket，也是監(jiān)聽該套接字的可寫事件，再次確認(rèn)連接成功才會(huì)寫數(shù)據(jù)。為了節(jié)省這點(diǎn)幾乎可以忽略不計(jì)的性能，真的不如安全可靠的代碼更有價(jià)值。

條件2：icsk->icsk_accept_queue.rskq_defer_accept != 0

這個(gè)條件好奇怪，defer_accept是個(gè)socket選項(xiàng)，用于推遲accept，實(shí)際上是當(dāng)接收到第一個(gè)數(shù)據(jù)之后，才會(huì)創(chuàng)建連接。tcp_defer_accept這個(gè)選項(xiàng)一般是在服務(wù)端用的，會(huì)影響socket的SYN和ACCEPT隊(duì)列。默認(rèn)不設(shè)置的話，三次握手完成，socket就進(jìn)入accept隊(duì)列，應(yīng)用層就感知到并ACCEPT相關(guān)的連接。當(dāng)tcp_defer_accept設(shè)置后，三次握手完成了，socket也不進(jìn)入ACCEPT隊(duì)列，而是直接留在SYN隊(duì)列（有長(zhǎng)度限制，超過內(nèi)核就拒絕新連接），直到數(shù)據(jù)真的發(fā)過來再放到ACCEPT隊(duì)列。設(shè)置了這個(gè)參數(shù)的服務(wù)端可以accept之后直接read，必然有數(shù)據(jù)，也節(jié)省一次系統(tǒng)調(diào)用。

SYN隊(duì)列保存SYN_RECV狀態(tài)的socket，長(zhǎng)度由net.ipv4.tcp_max_syn_backlog參數(shù)控制，accept隊(duì)列在listen調(diào)用時(shí)，backlog參數(shù)設(shè)置，內(nèi)核硬限制由 net.core.somaxconn 限制，即實(shí)際的值由min(backlog,somaxconn) 來決定。

有意思的是如果客戶端先bind到一個(gè)端口和IP，然后setsockopt(TCP_DEFER_ACCEPT），然后connect服務(wù)器，這個(gè)時(shí)候就會(huì)出現(xiàn)rskq_defer_accept=1的情況，這時(shí)候內(nèi)核會(huì)設(shè)置定時(shí)器等待數(shù)據(jù)一起在回復(fù)ACK包。我個(gè)人從未這么做過，難道只是為了減少一次ACK的空包發(fā)送來提高性能？哪位同學(xué)知道煩請(qǐng)告知，謝謝。

條件3：icsk->icsk_ack.pingpong != 0

pingpong這個(gè)屬性實(shí)際上也是一個(gè)套接字選項(xiàng)，用來表明當(dāng)前鏈接是否為交互數(shù)據(jù)流，如其值為1，則表明為交互數(shù)據(jù)流，會(huì)使用延遲確認(rèn)機(jī)制。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。