在tcp_v4_do_rcv中，有下面一段代碼，是關於TCP連接建立時候的代碼：
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 出現錯誤
nsk==sk 接受到SYN
nsk！=sk 接受到ACK
接受到ACK包時，tcp_v4_hnd_req函數會新建一個sock結構，並設置其初始狀態為SYN_RECV，並返回新建的sock結構。
接著調用tcp_child_process函數，改變新建的sock的狀態為ESTABLISHED.
（以下基於linux內核2.4.0）
SYN_RECV狀態，顧名思義，是收到SYN包後應該置的狀態。關於SYN_RECV狀態，受某些教科書的誤導，我以前一直理解為服務器收到SYN包後應該置此狀態。也沒細想到底是置那個socket的狀態，最近在看三次握手協議在linux內核中的實現時，才仔細思考這個問題應該是置連接套接字的狀態而非監聽套接字的狀態。
通常，SYN包只用於TCP三次握手協議中。常見的tcp三次握手協議過程（當然還有同時連接、
半連接等其它一些情況）如下：
1、client SYN包——> server
2、client <——SYN包/ACK包 server
3、client ACK包——> server
根據tcp狀態圖，對應下述4個狀態的變化
a、client發送完畢，狀態變成SYN_SEND；
b、server收到SYN報並發送ack確認包和SYN包，狀態變為SYN_RECV
c、client發送ack包完畢，狀態變成ESTABLISHED
d、server發送ack包完畢，狀態變成ESTABLISHED
在linux內核中，上述幾個狀態對應為TCP_SYN_SEND、TCP_SYN_RECV、TCP_ESTABLISHED.
RFC793中關於SYN_RECV狀態的描述如下：
SYN-RECEIVED - represents waiting for a confirming connection
request acknowledgment after having both received and sent a
connection request.
從上面可以看出，這個狀態是在本端接收到對端連接請求，並發送連接對端請求後，等待對端應答時所置的狀態。所以，本質上連接的過程是雙方請求應答的來回， 應該稱四次握手，只是常見的應用以c/s模式為主，而linux、包括絕大部分操作系統都把服務器端的應答和請求封裝在一個包裡面。
但在linux內核中，卻是在監聽套接字收到了客戶端的ACK包後，才創建連接套接字並初始化為TCP_SYN_RECV狀態，如下函數調用關系：
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）； /*創建連接sock結構*/
if（newsk ！= NULL） {
struct tcp_opt *newtp；
……
memcpy（newsk， sk， sizeof（*newsk））；
newsk->state = TCP_SYN_RECV； /*置初始狀態為SYN_RECV*/
//以下為一些初始化newsk結構的操作
……
}
這裡似乎都正常了，但還有一點，服務器收到ACK包後，狀態應該改為連接狀態，而此時連接套接字的狀態還是TCP_SYN_RECV
原因在於現在對ack包還沒處理完，^_^，如下：
int tcp_v4_do_rcv（struct sock *sk， struct sk_buff *skb）
{
……
if （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）） //此處調用tcp_rcv_state_process置套接字為連接建立狀態
goto reset；
return 0；
}
}
……
}
可見，在linux內核中，SYN_RECV狀態的保持時間是非常短暫的（也很難創建條件讓此狀態保持），這也是我們實際應用中通過netstat基本看不到這個狀態的原因
