轉(zhuǎn)載:
http://hi.baidu.com/tangzhenjiang/blog/item/e860003be8f807e814cecb28.htmlTCP_NODELAY 和 TCP_CORK，
這兩個(gè)選項(xiàng)都對(duì)網(wǎng)絡(luò)連接的行為具有重要的作用。許多UNIX系統(tǒng)都實(shí)現(xiàn)了TCP_NODELAY選項(xiàng)，但是，TCP_CORK則是Linux系統(tǒng)所獨(dú)有的而且相對(duì)較新；它首先在內(nèi)核版本2.4上得以實(shí)現(xiàn)。此外，其他UNIX系統(tǒng)版本也有功能類(lèi)似的選項(xiàng)，值得注意的是，在某種由BSD派生的系統(tǒng)上的TCP_NOPUSH選項(xiàng)其實(shí)就是TCP_CORK的一部分具體實(shí)現(xiàn)。
TCP_NODELAY和TCP_CORK基本上控制了包的“Nagle化”，Nagle化在這里的含義是采用Nagle算法把較小的包組裝為更大的幀。John Nagle是Nagle算法的發(fā)明人，后者就是用他的名字來(lái)命名的，他在1984年首次用這種方法來(lái)嘗試解決福特汽車(chē)公司的網(wǎng)絡(luò)擁塞問(wèn)題（欲了解詳情請(qǐng)參看IETF RFC 896）。他解決的問(wèn)題就是所謂的silly window syndrome ，中文稱(chēng)“愚蠢窗口癥候群”，具體含義是，因?yàn)槠毡榻K端應(yīng)用程序每產(chǎn)生一次擊鍵操作就會(huì)發(fā)送一個(gè)包，而典型情況下一個(gè)包會(huì)擁有一個(gè)字節(jié)的數(shù)據(jù)載荷以及40個(gè)字節(jié)長(zhǎng)的包頭，于是產(chǎn)生4000%的過(guò)載，很輕易地就能令網(wǎng)絡(luò)發(fā)生擁塞,。 Nagle化后來(lái)成了一種標(biāo)準(zhǔn)并且立即在因特網(wǎng)上得以實(shí)現(xiàn)。它現(xiàn)在已經(jīng)成為缺省配置了，但在我們看來(lái)，有些場(chǎng)合下把這一選項(xiàng)關(guān)掉也是合乎需要的。
現(xiàn)在讓我們假設(shè)某個(gè)應(yīng)用程序發(fā)出了一個(gè)請(qǐng)求，希望發(fā)送小塊數(shù)據(jù)。我們可以選擇立即發(fā)送數(shù)據(jù)或者等待產(chǎn)生更多的數(shù)據(jù)然后再一次發(fā)送兩種策略。如果我們馬上發(fā)送數(shù)據(jù)，那么交互性的以及客戶/服務(wù)器型的應(yīng)用程序?qū)O大地受益。例如，當(dāng)我們正在發(fā)送一個(gè)較短的請(qǐng)求并且等候較大的響應(yīng)時(shí)，相關(guān)過(guò)載與傳輸?shù)臄?shù)據(jù)總量相比就會(huì)比較低，而且，如果請(qǐng)求立即發(fā)出那么響應(yīng)時(shí)間也會(huì)快一些。以上操作可以通過(guò)設(shè)置套接字的TCP_NODELAY選項(xiàng)來(lái)完成，這樣就禁用了Nagle算法。
另外一種情況則需要我們等到數(shù)據(jù)量達(dá)到最大時(shí)才通過(guò)網(wǎng)絡(luò)一次發(fā)送全部數(shù)據(jù)，這種數(shù)據(jù)傳輸方式有益于大量數(shù)據(jù)的通信性能，典型的應(yīng)用就是文件服務(wù)器。應(yīng)用Nagle算法在這種情況下就會(huì)產(chǎn)生問(wèn)題。但是，如果你正在發(fā)送大量數(shù)據(jù)，你可以設(shè)置TCP_CORK選項(xiàng)禁用Nagle化，其方式正好同TCP_NODELAY相反（TCP_CORK 和 TCP_NODELAY 是互相排斥的）。下面就讓我們仔細(xì)分析下其工作原理。
假設(shè)應(yīng)用程序使用sendfile()函數(shù)來(lái)轉(zhuǎn)移大量數(shù)據(jù)。應(yīng)用協(xié)議通常要求發(fā)送某些信息來(lái)預(yù)先解釋數(shù)據(jù)，這些信息其實(shí)就是報(bào)頭內(nèi)容。典型情況下報(bào)頭很小，而且套接字上設(shè)置了TCP_NODELAY。有報(bào)頭的包將被立即傳輸，在某些情況下（取決于內(nèi)部的包計(jì)數(shù)器），因?yàn)檫@個(gè)包成功地被對(duì)方收到后需要請(qǐng)求對(duì)方確認(rèn)。這樣，大量數(shù)據(jù)的傳輸就會(huì)被推遲而且產(chǎn)生了不必要的網(wǎng)絡(luò)流量交換。
但是，如果我們?cè)谔捉幼稚显O(shè)置了TCP_CORK（可以比喻為在管道上插入“塞子”）選項(xiàng)，具有報(bào)頭的包就會(huì)填補(bǔ)大量的數(shù)據(jù)，所有的數(shù)據(jù)都根據(jù)大小自動(dòng)地通過(guò)包傳輸出去。當(dāng)數(shù)據(jù)傳輸完成時(shí)，最好取消TCP_CORK 選項(xiàng)設(shè)置給連接“拔去塞子”以便任一部分的幀都能發(fā)送出去。這同“塞住”網(wǎng)絡(luò)連接同等重要。
總而言之，如果你肯定能一起發(fā)送多個(gè)數(shù)據(jù)集合（例如HTTP響應(yīng)的頭和正文），那么我們建議你設(shè)置TCP_CORK選項(xiàng)，這樣在這些數(shù)據(jù)之間不存在延遲。能極大地有益于WWW、FTP以及文件服務(wù)器的性能，同時(shí)也簡(jiǎn)化了你的工作。示例代碼如下：
intfd, on = 1;
…
/* 此處是創(chuàng)建套接字等操作，出于篇幅的考慮省略*/
…
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)); /* 拔去塞子 */
不幸的是，許多常用的程序并沒(méi)有考慮到以上問(wèn)題。例如，Eric Allman編寫(xiě)的sendmail就沒(méi)有對(duì)其套接字設(shè)置任何選項(xiàng)。
Apache HTTPD是因特網(wǎng)上最流行的Web服務(wù)器，它的所有套接字就都設(shè)置了TCP_NODELAY選項(xiàng)，而且其性能也深受大多數(shù)用戶的滿意。這是為什么呢？答案就在于實(shí)現(xiàn)的差別之上。由BSD衍生的TCP/IP協(xié)議棧（值得注意的是FreeBSD）在這種狀況下的操作就不同。當(dāng)在TCP_NODELAY 模式下提交大量小數(shù)據(jù)塊傳輸時(shí)，大量信息將按照一次write()函數(shù)調(diào)用發(fā)送一塊數(shù)據(jù)的方式發(fā)送出去。然而，因?yàn)樨?fù)責(zé)請(qǐng)求交付確認(rèn)的記數(shù)器是面向字節(jié)而非面向包（在Linux上）的，所以引入延遲的概率就降低了很多。結(jié)果僅僅和全部數(shù)據(jù)的大小有關(guān)系。而 Linux 在第一包到達(dá)之后就要求確認(rèn)，F(xiàn)reeBSD則在進(jìn)行如此操作之前會(huì)等待好幾百個(gè)包。
在Linux系統(tǒng)上，TCP_NODELAY的效果同習(xí)慣于BSD TCP/IP協(xié)議棧的開(kāi)發(fā)者所期望的效果有很大不同，而且在Linux上的Apache性能表現(xiàn)也會(huì)更差些。其他在Linux上頻繁采用TCP_NODELAY的應(yīng)用程序也有同樣的問(wèn)題。