關於TCP_NODELAY 和 TCP_CORK選項

TCP_NODELAY 和 TCP_CORK
這兩個選項都對網絡連接的行為具有重要的作用。許多UNIX系統都實現了TCP_NODELAY選項，但是，TCP_CORK則是Linux系統所獨有的 而且相對較新；它首先在內核版本2.4上得以實現。此外，其他UNIX系統版本也有功能類似的選項，值得注意的是，在某種由BSD派生的系統上的 TCP_NOPUSH選項其實就是TCP_CORK的一部分具體實現。 
TCP_NODELAY和TCP_CORK基本上控制了包的“Nagle化”，Nagle化在這里的含義是采用Nagle算法把較小的包組裝為更大的幀。 John Nagle是Nagle算法的發明人，后者就是用他的名字來命名的，他在1984年首次用這種方法來嘗試解決福特汽車公司的網絡擁塞問題（欲了解詳情請參 看IETF RFC 896）。他解決的問題就是所謂的silly window syndrome ，中文稱“愚蠢窗口症候群”，具體含義是，因為普遍終端應用程序每產生一次擊鍵操作就會發送一個包，而典型情況下一個包會擁有一個字節的數據載荷以及40 個字節長的包頭，於是產生4000%的過載，很輕易地就能令網絡發生擁塞,。 Nagle化后來成了一種標准並且立即在因特網上得以實現。它現在已經成為缺省配置了，但在我們看來，有些場合下把這一選項關掉也是合乎需要的。 
現在讓我們假設某個應用程序發出了一個請求，希望發送小塊數據。我們可以選擇立即發送數據或者等待產生更多的數據然后再一次發送兩種策略。如果我們馬上發 送數據，那么交互性的以及客戶/服務器型的應用程序將極大地受益。例如，當我們正在發送一個較短的請求並且等候較大的響應時，相關過載與傳輸的數據總量相 比就會比較低，而且，如果請求立即發出那么響應時間也會快一些。以上操作可以通過設置套接字的TCP_NODELAY選項來完成，這樣就禁用了Nagle 算法。 
另外一種情況則需要我們等到數據量達到最大時才通過網絡一次發送全部數據，這種數據傳輸方式有益於大量數據的通信性能，典型的應用就是文件服務器。應用 Nagle算法在這種情況下就會產生問題。但是，如果你正在發送大量數據，你可以設置TCP_CORK選項禁用Nagle化，其方式正好同 TCP_NODELAY相反（TCP_CORK 和 TCP_NODELAY 是互相排斥的）。下面就讓我們仔細分析下其工作原理。 
假設應用程序使用sendfile()函數來轉移大量數據。應用協議通常要求發送某些信息來預先解釋數據，這些信息其實就是報頭內容。典型情況下報頭很 小，而且套接字上設置了TCP_NODELAY。有報頭的包將被立即傳輸，在某些情況下（取決於內部的包計數器），因為這個包成功地被對方收到后需要請求 對方確認。這樣，大量數據的傳輸就會被推遲而且產生了不必要的網絡流量交換。 
但是，如果我們在套接字上設置了TCP_CORK（可以比喻為在管道上插入“塞子”）選項，具有報頭的包就會填補大量的數據，所有的數據都根據大小自動地 通過包傳輸出去。當數據傳輸完成時，最好取消TCP_CORK 選項設置給連接“拔去塞子”以便任一部分的幀都能發送出去。這同“塞住”網絡連接同等重要。 
總而言之，如果你肯定能一起發送多個數據集合（例如HTTP響應的頭和正文），那么我們建議你設置TCP_CORK選項，這樣在這些數據之間不存在延遲。能極大地有益於WWW、FTP以及文件服務器的性能，同時也簡化了你的工作。示例代碼如下： 

intfd, on = 1; 
… 
/* 此處是創建套接字等操作，出於篇幅的考慮省略*/ 
… 
setsockopt (fd, SOL_TCP, TCP_CORK, &on, sizeof (on)); /* cork */ 
write (fd, …); 
fprintf (fd, …); 
sendfile (fd, …); 
write (fd, …); 
sendfile (fd, …); 
… 
on = 0; 
setsockopt (fd, SOL_TCP, TCP_CORK, &on, sizeof (on)); /* 拔去塞子 */ 


不幸的是，許多常用的程序並沒有考慮到以上問題。例如，Eric Allman編寫的sendmail就沒有對其套接字設置任何選項。 

Apache HTTPD是因特網上最流行的Web服務器，它的所有套接字就都設置了TCP_NODELAY選項，而且其性能也深受大多數用戶的滿意。這是為什么呢？答 案就在於實現的差別之上。由BSD衍生的TCP/IP協議棧（值得注意的是FreeBSD）在這種狀況下的操作就不同。當在TCP_NODELAY 模式下提交大量小數據塊傳輸時，大量信息將按照一次write()函數調用發送一塊數據的方式發送出去。然而，因為負責請求交付確認的記數器是面向字節而 非面向包（在Linux上）的，所以引入延遲的概率就降低了很多。結果僅僅和全部數據的大小有關系。而 Linux 在第一包到達之后就要求確認，FreeBSD則在進行如此操作之前會等待好幾百個包。 

在Linux系統上，TCP_NODELAY的效果同習慣於BSD TCP/IP協議棧的開發者所期望的效果有很大不同，而且在Linux上的Apache性能表現也會更差些。其他在Linux上頻繁采用TCP_NODELAY的應用程序也有同樣的問題。 


TCP_DEFER_ACCEPT 

我們首先考慮的第1個選項是TCP_DEFER_ACCEPT（這是Linux系統上的叫法，其他一些操作系統上也有同樣的選項但使用不同的名字）。為了 理解TCP_DEFER_ACCEPT選項的具體思想，我們有必要大致闡述一下典型的HTTP客戶/服務器交互過程。請回想下TCP是如何與傳輸數據的目 標建立連接的。在網絡上，在分離的單元之間傳輸的信息稱為IP包（或IP 數據報）。一個包總有一個攜帶服務信息的包頭，包頭用於內部協議的處理，並且它也可以攜帶數據負載。服務信息的典型例子就是一套所謂的標志，它把包標記代 表TCP/IP協議棧內的特殊含義，例如收到包的成功確認等等。通常，在經過“標記”的包里攜帶負載是完全可能的，但有時，內部邏輯迫使TCP/IP協議 棧發出只有包頭的IP包。這些包經常會引發討厭的網絡延遲而且還增加了系統的負載，結果導致網絡性能在整體上降低。 
現在服務器創建了一個套接字同時等待連接。TCP/IP式的連接過程就是所謂“3次握手”。首先，客戶程序發送一個設置SYN標志而且不帶數據負載的 TCP包（一個SYN包）。服務器則以發出帶SYN/ACK標志的數據包（一個SYN/ACK包）作為剛才收到包的確認響應。客戶隨后發送一個ACK包確 認收到了第2個包從而結束連接過程。在收到客戶發來的這個SYN/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_QUICKACK 

阻止因發送無用包而引發延遲的另一個方法是使用TCP_QUICKACK選項。這一選項與 TCP_DEFER_ACCEPT不同，它不但能用作管理連接建立過程而且在正常數據傳輸過程期間也可以使用。另外，它能在客戶/服務器連接的任何一方設 置。如果知道數據不久即將發送，那么推遲ACK包的發送就會派上用場，而且最好在那個攜帶數據的數據包上設置ACK 標志以便把網絡負載減到最小。當發送方肯定數據將被立即發送（多個包）時，TCP_QUICKACK選項可以設置為0。對處於“連接”狀態下的套接字該選 項的缺省值是1，首次使用以后內核將把該選項立即復位為1（這是個一次性的選項）。 
在某些情形下，發出ACK包則非常有用。ACK包將確認數據塊的接收，而且，當下一塊被處理時不至於引入延遲。這種數據傳輸模式對交互過程是相當典型的，因為此類情況下用戶的輸入時刻無法預測。在Linux系統上這就是缺省的套接字行為。 
在上述情況下，客戶程序在向服務器發送HTTP請求，而預先就知道請求包很短所以在連接建立之后就應該立即發送，這可謂HTTP的典型工作方式。既然沒有 必要發送一個純粹的ACK包，所以設置TCP_QUICKACK為0以提高性能是完全可能的。在服務器方，這兩種選項都只能在偵聽套接字上設置一次。所有 的套接字，也就是被接受呼叫間接創建的套接字則會繼承原有套接字的所有選項。 
通過TCP_CORK、TCP_DEFER_ACCEPT和TCP_QUICKACK選項的組合，參與每一HTTP交互的數據包數量將被降低到最小的可接 受水平（根據TCP協議的要求和安全方面的考慮）。結果不僅是獲得更快的數據傳輸和請求處理速度而且還使客戶/服務器雙向延遲實現了最小化。