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

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

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

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

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

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

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

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

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

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

之前的疑問算是解決了。

條件1：sk->sk_write_pending != 0

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

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

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

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

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

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

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

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

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

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

pingpong這個屬性實際上也是一個套接字選項，用來表明當前鏈接是否為交互數(shù)據(jù)流，如其值為1，則表明為交互數(shù)據(jù)流，會使用延遲確認機制。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論