在tcp_v4_do_rcv中，有下面一段代碼，是關(guān)于TCP連接建立時(shí)候的代碼：



　　if (sk->sk_state == TCP_LISTEN) {
　　struct sock *nsk = tcp_v4_hnd_req(sk, skb);
　　if (!nsk)
　　goto discard;

　　if (nsk != sk) {
　　if (tcp_child_process(sk, nsk, skb))
　　goto reset;
　　return 0;
　　}
　　}



　　tcp_v4_hnd_req的返回值，不同情況下不同。

　　NULL 出現(xiàn)錯(cuò)誤

　　nsk==sk 接受到SYN

　　nsk!=sk 接受到ACK


　　接受到ACK包時(shí)，tcp_v4_hnd_req函數(shù)會(huì)新建一個(gè)sock結(jié)構(gòu)，并設(shè)置其初始狀態(tài)為SYN_RECV，并返回新建的sock結(jié)構(gòu)。

　　接著調(diào)用tcp_child_process函數(shù)，改變新建的sock的狀態(tài)為ESTABLISHED。


　　(以下基于linux內(nèi)核2.4.0)
　
　　SYN_RECV狀態(tài)，顧名思義，是收到SYN包后應(yīng)該置的狀態(tài)。關(guān)于SYN_RECV狀態(tài),受某些教科書的誤導(dǎo),我以前一直理解為服務(wù)器收到SYN包后應(yīng)該置此狀態(tài)。也沒細(xì)想到底是置那個(gè)socket的狀態(tài)，近在看三次握手協(xié)議在linux內(nèi)核中的實(shí)現(xiàn)時(shí),才仔細(xì)思考這個(gè)問題應(yīng)該是置連接套接字的狀態(tài)而非監(jiān)聽套接字的狀態(tài)。

　　通常,SYN包只用于TCP三次握手協(xié)議中。常見的tcp三次握手協(xié)議過程(當(dāng)然還有同時(shí)連接、

　　半連接等其它一些情況)如下：

　　1、client SYN包---> server

　　2、client <---SYN包/ACK包 server

　　3、client ACK包---> server

　　根據(jù)tcp狀態(tài)圖,對(duì)應(yīng)下述4個(gè)狀態(tài)的變化

　　a、client發(fā)送完畢，狀態(tài)變成SYN_SEND;

　　b、server收到SYN報(bào)并發(fā)送ack確認(rèn)包和SYN包，狀態(tài)變?yōu)镾YN_RECV

　　c、client發(fā)送ack包完畢，狀態(tài)變成ESTABLISHED

　　d、server發(fā)送ack包完畢，狀態(tài)變成ESTABLISHED


　　在linux內(nèi)核中,上述幾個(gè)狀態(tài)對(duì)應(yīng)為TCP_SYN_SEND、TCP_SYN_RECV、TCP_ESTABLISHED.

　　RFC793中關(guān)于SYN_RECV狀態(tài)的描述如下：

　　SYN-RECEIVED - represents waiting for a confirming connection

　　request acknowledgment after having both received and sent a

　　connection request.

　　從上面可以看出,這個(gè)狀態(tài)是在本端接收到對(duì)端連接請(qǐng)求,并發(fā)送連接對(duì)端請(qǐng)求后,等待對(duì)端應(yīng)答時(shí)所置的狀態(tài)。所以,本質(zhì)上連接的過程是雙方請(qǐng)求應(yīng)答的來回, 應(yīng)該稱四次握手,只是常見的應(yīng)用以c/s模式為主,而linux、包括絕大部分操作系統(tǒng)都把服務(wù)器端的應(yīng)答和請(qǐng)求封裝在一個(gè)包里面。

　　但在linux內(nèi)核中,卻是在監(jiān)聽套接字收到了客戶端的ACK包后,才創(chuàng)建連接套接字并初始化為TCP_SYN_RECV狀態(tài),如下函數(shù)調(diào)用關(guān)系：

　　tcp_v4_rcv-->tcp_v4_do_rcv-->tcp_v4_hnd_req-->tcp_check_req-->

　　tcp_v4_syn_recv_sock-->tcp_create_openreq_child...

　　struct sock *tcp_create_openreq_child(struct sock *sk, struct open_request *req, struct sk_buff *skb)

　　{

　　struct sock *newsk = sk_alloc(PF_INET, GFP_ATOMIC, 0); /*創(chuàng)建連接sock結(jié)構(gòu)*/


　　if(newsk != NULL) {

　　struct tcp_opt *newtp;

　　...

　　memcpy(newsk, sk, sizeof(*newsk));
　　
　　newsk->state = TCP_SYN_RECV; /*置初始狀態(tài)為SYN_RECV*/


　　//以下為一些初始化newsk結(jié)構(gòu)的操作

　　...

　　}

　　這里似乎都正常了，但還有一點(diǎn),服務(wù)器收到ACK包后，狀態(tài)應(yīng)該改為連接狀態(tài),而此時(shí)連接套接字的狀態(tài)還是　TCP_SYN_RECV

　　原因在于現(xiàn)在對(duì)ack包還沒處理完,^_^,如下：

　　int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)

　　{

　　...

　　if (sk->state == TCP_LISTEN) { //此處是監(jiān)聽套接字的狀態(tài)

　　struct sock *nsk = tcp_v4_hnd_req(sk, skb); //獲得了上面講的連接套接字

　　if (!nsk)

　　goto discard;


　　if (nsk != sk) { //顯然監(jiān)聽與連接套接字不等

　　if (tcp_child_process(sk, nsk, skb)) //此處調(diào)用tcp_rcv_state_process置套接字為連接建立狀態(tài)

　　goto reset;

　　return 0;

　　}

　　}

　　...
　
　　}


　　可見,在linux內(nèi)核中,SYN_RECV狀態(tài)的保持時(shí)間是非常短暫的(也很難創(chuàng)建條件讓此狀態(tài)保持),這也是我們實(shí)際應(yīng)用中通過netstat基本看不到這個(gè)狀態(tài)的原因。