原文連結：http://blog.csdn.net/hbhhww/article/details/8237309

我們首先考慮的第1個選項是TCP_DEFER_ACCEPT（這是Linux系統上的叫法，其他一些作業系統上也有同樣的選項但使用不同的名字）。為了理解TCP_DEFER_ACCEPT選項的具體思想，我們有必要大致闡述一下典型的HTTP客戶/伺服器互動過程。請回想下TCP是如何與傳輸資料的目標建立連線的。在網路上，在分離的單元之間傳輸的資訊稱為IP包（或IP 資料報）。一個包總有一個攜帶服務資訊的包頭，包頭用於內部協議的處理，並且它也可以攜帶資料負載。服務資訊的典型例子就是一套所謂的標誌，它把包標記代表TCP/IP協議

　　現在伺服器建立了一個套接字同時等待連線。TCP/IP式的連線過程就是所謂“3次握手”。首先，客戶程式傳送一個設定SYN標誌而且不帶資料負載的TCP包（一個SYN包）。伺服器則以發出帶SYN/ACK標誌的資料包（一個SYN/ACK包）作為剛才收到包的確認響應。客戶隨後傳送一個ACK包確認收到了第2個包從而結束連線過程。在收到客戶發來的這個ACK包之後，伺服器會喚醒一個接收程序等待資料到達。當3次握手完成後，客戶程式即開始把“有用的”的資料傳送給伺服器。通常，一個HTTP請求的量是很小的而且完全可以裝到一個包裡。但是，在以上的情況下，至少有4個包將用來進行雙向傳輸，這樣就增加了可觀的延遲時間。此外，你還得注意到，在“有用的”資料被髮送之前，接收方已經開始在等待資訊了。

　　為了減輕這些問題所帶來的影響，Linux（以及其他的一些作業系統）在其TCP實現中包括了TCP_DEFER_ACCEPT選項。它們設定在偵聽套接字的伺服器方，該選項命令核心不等待最後的ACK包而且在第1個真正有資料的包到達才初始化偵聽程序。在傳送SYN/ACK包之後，伺服器就會等待客戶程式傳送含資料的IP包。現在，只需要在網路上傳送3個包了，而且還顯著降低了連線建立的延遲，對HTTP通訊而言尤其如此。這一選項在好些作業系統上都有相應的對等物。例如，在FreeBSD上，同樣的行為可以用以下程式碼實現：

　　/* 為明晰起見，此處略去無關程式碼 */

　　struct accept_filter_arg af = { "dataready", "" };

　　setsockopt(s, SOL_SOCKET, SO_ACCEPTFILTER, &af, sizeof(af));

　　這個特徵在FreeBSD上叫做“接受過濾器”，而且具有多種用法。不過，在幾乎所有的情況下其效果與TCP_DEFER_ACCEPT是一樣的：伺服器不等待最後的ACK包而僅僅等待攜帶資料負載的包。要了解該選項及其對高效能Web伺服器的重要意義的更多資訊請參考Apache文件上的有關內容。

　　就HTTP客戶/伺服器互動而言，有可能需要改變客戶程式的行為。客戶程式為什麼要傳送這種“無用的”ACK包呢？這是因為，TCP協議棧無法知道ACK包的狀態。如果採用FTP而非HTTP，那麼客戶程式直到接收了FTP伺服器提示的資料包之後才傳送資料。在這種情況下，延遲的ACK將導致客戶/伺服器互動出現延遲。為了確定ACK是否必要，客戶程式必須知道應用程式協議及其當前狀態。這樣，修改客戶行為就成為必要了。

　　對Linux客戶程式來說，我們還可以採用另一個選項，它也被叫做TCP_DEFER_ACCEPT。我們知道，套接字分成兩種型別，偵聽套接字和連線套接字，所以它們也各自具有相應的TCP選項集合。因此，經常同時採用的這兩類選項卻具有同樣的名字也是完全可能的。在連線套接字上設定該選項以後，客戶在收到一個

　　SYN/ACK包之後就不再發送ACK包，而是等待使用者程式的下一個傳送資料請求；因此，伺服器傳送的包也就相應減少了。

tcp三次握手過程：

第一次握手：建立連線時，客戶端傳送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認； 

第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也傳送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態； 

第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=k+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。

伺服器在三次握手後會喚起一個程序等待資料到達，當伺服器設定了TCP_DEFER_ACCEPT後，核心不等待最後一個ACK包，而且在第一個真正有資料的包到達後才初始化偵聽過程，可以減少一些上下文切換，三次握手後，如果沒有資料到來，伺服器socket處於SYN_RECV狀態，這個時候就依賴於net.ipv4.tcp_synack_retries引數控制了，當達到重傳後，過指定的時間關閉socket

看測試程式

伺服器環境：Linux version 2.6 + gcc，ip：192.168.30.202

客戶端環境：win32 + vs2010，ip：192.168.30.12

沒有設定TCP_DEFER_ACCEPT，三次握手的抓包：

[[email protected] ~]# tcpdump tcp port 10000

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

16:30:59.486716 IP 192.168.30.12.4326 > 192.168.30.202.ndmp: S 1992149464:1992149464(0) win 65535 <mss 1460,nop,nop,sackOK>

16:30:59.490951 IP 192.168.30.202.ndmp > 192.168.30.12.4326: S 524361898:524361898(0) ack 1992149465 win 5840 <mss 1460,nop,nop,sackOK>

16:30:59.491059 IP 192.168.30.12.4326 > 192.168.30.202.ndmp: . ack 1 win 65535

設定TCP_DEFER_ACCEPT，通過命令“sysctl -w net.ipv4.tcp_synack_retries=1”設定重傳後，抓包如下：

[[email protected] ~]# tcpdump tcp port 10000

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

16:35:12.764157 IP 192.168.30.12.4548 > 192.168.30.202.ndmp: S 1431219651:1431219651(0) win 65535 <mss 1460,nop,nop,sackOK>

16:35:12.767924 IP 192.168.30.202.ndmp > 192.168.30.12.4548: S 795485424:795485424(0) ack 1431219652 win 5840 <mss 1460,nop,nop,sackOK>

16:35:12.768044 IP 192.168.30.12.4548 > 192.168.30.202.ndmp: . ack 1 win 65535

16:35:15.726875 IP 192.168.30.202.ndmp > 192.168.30.12.4548: S 795485424:795485424(0) ack 1431219652 win 5840 <mss 1460,nop,nop,sackOK>

16:35:15.726980 IP 192.168.30.12.4548 > 192.168.30.202.ndmp: . ack 1 win 65535

設定TCP_DEFER_ACCEPT，通過命令“sysctl -w net.ipv4.tcp_synack_retries=3”設定重傳後，抓包如下：

[[email protected] ~]# tcpdump tcp port 10000

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

16:36:57.993105 IP 192.168.30.12.4648 > 192.168.30.202.ndmp: S 242062800:242062800(0) win 65535 <mss 1460,nop,nop,sackOK>

16:36:57.996526 IP 192.168.30.202.ndmp > 192.168.30.12.4648: S 917726329:917726329(0) ack 242062801 win 5840 <mss 1460,nop,nop,sackOK>

16:36:57.996567 IP 192.168.30.12.4648 > 192.168.30.202.ndmp: . ack 1 win 65535

16:37:02.140832 IP 192.168.30.202.ndmp > 192.168.30.12.4648: S 917726329:917726329(0) ack 242062801 win 5840 <mss 1460,nop,nop,sackOK>

16:37:02.141226 IP 192.168.30.12.4648 > 192.168.30.202.ndmp: . ack 1 win 65535

16:37:08.065966 IP 192.168.30.202.ndmp > 192.168.30.12.4648: S 917726329:917726329(0) ack 242062801 win 5840 <mss 1460,nop,nop,sackOK>

16:37:08.066190 IP 192.168.30.12.4648 > 192.168.30.202.ndmp: . ack 1 win 65535

16:37:19.915745 IP 192.168.30.202.ndmp > 192.168.30.12.4648: S 917726329:917726329(0) ack 242062801 win 5840 <mss 1460,nop,nop,sackOK>

16:37:19.915993 IP 192.168.30.12.4648 > 192.168.30.202.ndmp: . ack 1 win 65535

上面抓包結果可以看出結果，不過還有個問題沒弄明白，當達到重傳次數後，過指定的時間關閉socket，這個時間沒有準確的計算出來

int val = 10;

if (setsockopt(sock_descriptor, IPPROTO_TCP, TCP_DEFER_ACCEPT, &val, sizeof(val))== -1)

{

perror("setsockopt");

exit(1);

}

val以秒為單位，val設定的時間越久，測試出這個等待關閉的時間就越久，具體沒弄清楚是多少，或者是由其他什麼控制的，杯具啊！！