利用TCP/IP選項優(yōu)化數據傳輸
加入技術(shù)交流群
TCP_DEFER_ACCEPT
我們首先考慮的第1個(gè)選項是TCP_DEFER_ACCEPT（這是Linux系統上的叫法，其他一些操作系統上也有同樣的選項但使用不同的名字）。為了理解TCP_DEFER_ACCEPT選項的具體思想，我們有必要大致闡述一下典型的HTTP客戶(hù)/服務(wù)器交互過(guò)程。請回想下TCP是如何與傳輸數據的目標建立連接的。在網(wǎng)絡(luò )上，在分離的單元之間傳輸的信息稱(chēng)為IP包（或IP 數據報）。一個(gè)包總有一個(gè)攜帶服務(wù)信息的包頭，包頭用于內部協(xié)議的處理，并且它也可以攜帶數據負載。服務(wù)信息的典型例子就是一套所謂的標志，它把包標記代表TCP/IP協(xié)議棧內的特殊含義，例如收到包的成功確認等等。通常，在經(jīng)過(guò)“標記”的包里攜帶負載是完全可能的，但有時(shí)，內部邏輯迫使TCP/IP協(xié)議棧發(fā)出只有包頭的IP包。這些包經(jīng)常會(huì )引發(fā)討厭的網(wǎng)絡(luò )延遲而且還增加了系統的負載，結果導致網(wǎng)絡(luò )性能在整體上降低。
現在服務(wù)器創(chuàng )建了一個(gè)套接字同時(shí)等待連接。TCP/IP式的連接過(guò)程就是所謂“3次握手”。首先，客戶(hù)程序發(fā)送一個(gè)設置SYN標志而且不帶數據負載的TCP包（一個(gè)SYN包）。服務(wù)器則以發(fā)出帶SYN/ACK標志的數據包（一個(gè)SYN/ACK包）作為剛才收到包的確認響應?？蛻?hù)隨后發(fā)送一個(gè)ACK包確認收到了第2個(gè)包從而結束連接過(guò)程。在收到客戶(hù)發(fā)來(lái)的這個(gè)ACK包之后，服務(wù)器會(huì )喚醒一個(gè)接收進(jìn)程等待數據到達。當3次握手完成后，客戶(hù)程序即開(kāi)始把“有用的”的數據發(fā)送給服務(wù)器。通常，一個(gè)HTTP請求的量是很小的而且完全可以裝到一個(gè)包里。但是，在以上的情況下，至少有4個(gè)包將用來(lái)進(jìn)行雙向傳輸，這樣就增加了可觀(guān)的延遲時(shí)間。此外，你還得注意到，在“有用的”數據被發(fā)送之前，接收方已經(jīng)開(kāi)始在等待信息了。
為了減輕這些問(wèn)題所帶來(lái)的影響，Linux（以及其他的一些操作系統）在其TCP實(shí)現中包括了TCP_DEFER_ACCEPT選項。它們設置在偵聽(tīng)套接字的服務(wù)器方，該選項命令內核不等待最后的ACK包而且在第1個(gè)真正有數據的包到達才初始化偵聽(tīng)進(jìn)程。在發(fā)送SYN/ACK包之后，服務(wù)器就會(huì )等待客戶(hù)程序發(fā)送含數據的IP包?，F在，只需要在網(wǎng)絡(luò )上傳送3個(gè)包了，而且還顯著(zhù)降低了連接建立的延遲，對HTTP通信而言尤其如此。這一選項在好些操作系統上都有相應的對等物。例如，在FreeBSD上，同樣的行為可以用以下代碼實(shí)現：
/* 為明晰起見(jiàn)，此處略去無(wú)關(guān)代碼 */
struct accept_filter_arg af = { dataready, };
setsockopt(s, SOL_SOCKET, SO_ACCEPTFILTER, af, sizeof(af));
這個(gè)特征在FreeBSD上叫做“接受過(guò)濾器”，而且具有多種用法。不過(guò)，在幾乎所有的情況下其效果與TCP_DEFER_ACCEPT是一樣的：服務(wù)器不等待最后的ACK包而僅僅等待攜帶數據負載的包。要了解該選項及其對高性能Web服務(wù)器的重要意義的更多信息請參考Apache文檔上的有關(guān)內容。
就HTTP客戶(hù)/服務(wù)器交互而言，有可能需要改變客戶(hù)程序的行為?？蛻?hù)程序為什么要發(fā)送這種“無(wú)用的”ACK包呢？這是因為，TCP協(xié)議棧無(wú)法知道ACK包的狀態(tài)。如果采用FTP而非HTTP，那么客戶(hù)程序直到接收了FTP服務(wù)器提示的數據包之后才發(fā)送數據。在這種情況下，延遲的ACK將導致客戶(hù)/服務(wù)器交互出現延遲。為了確定ACK是否必要，客戶(hù)程序必須知道應用程序協(xié)議及其當前狀態(tài)。這樣，修改客戶(hù)行為就成為必要了。
對Linux客戶(hù)程序來(lái)說(shuō)，我們還可以采用另一個(gè)選項，它也被叫做TCP_DEFER_ACCEPT。我們知道，套接字分成兩種類(lèi)型，偵聽(tīng)套接字和連接套接字，所以它們也各自具有相應的TCP選項集合。因此，經(jīng)常同時(shí)采用的這兩類(lèi)選項卻具有同樣的名字也是完全可能的。在連接套接字上設置該選項以后，客戶(hù)在收到一個(gè)
SYN/ACK包之后就不再發(fā)送ACK包，而是等待用戶(hù)程序的下一個(gè)發(fā)送數據請求；因此，服務(wù)器發(fā)送的包也就相應減少了。
TCP_QUICKACK
阻止因發(fā)送無(wú)用包而引發(fā)延遲的另一個(gè)方法是使用TCP_QUICKACK選項。這一選項與 CP_DEFER_ACCEPT不同，它不但能用作管理連接建立過(guò)程而且在正常數據傳輸過(guò)程期間也可以使用。另外，它能在客戶(hù)/服務(wù)器連接的任何一方設置。如果知道數據不久即將發(fā)送，那么推遲ACK包的發(fā)送就會(huì )派上用場(chǎng)，而且最好在那個(gè)攜帶數據的數據包上設置ACK 標志以便把網(wǎng)絡(luò )負載減到最小。當發(fā)送方肯定數據將被立即發(fā)送（多個(gè)包）時(shí)，TCP_QUICKACK選項可以設置為0。對處于“連接”狀態(tài)下的套接字該選項的缺省值是1，首次使用以后內核將把該選項立即復位為1（這是個(gè)一次性的選項）。
在某些情形下，發(fā)出ACK包則非常有用。ACK包將確認數據塊的接收，而且，當下一塊被處理時(shí)不至于引入延遲。這種數據傳輸模式對交互過(guò)程是相當典型的，因為此類(lèi)情況下用戶(hù)的輸入時(shí)刻無(wú)法預測。在Linux系統上這就是缺省的套接字行為。在上述情況下，客戶(hù)程序在向服務(wù)器發(fā)送HTTP請求，而預先就知
道請求包很短所以在連接建立之后就應該立即發(fā)送，這可謂HTTP的典型工作方式。既然沒(méi)有必要發(fā)送一個(gè)純粹的ACK包，所以設置TCP_QUICKACK為0以提高性能是完全可能的。在服務(wù)器方，這兩種選項都只能在偵聽(tīng)套接字上設置一次。所有的套接字，也就是被接受呼叫間接創(chuàng )建的套接字則會(huì )繼承原有套接字的所有選項。
通過(guò)TCP_CORK、TCP_DEFER_ACCEPT和TCP_QUICKACK選項的組合，參與每一HTTP交互的數據包數量將被降低到最小的可接受水平（根據TCP協(xié)議的要求和安全方面的考慮）。結果不僅是獲得更快的數據傳輸和請求處理速度而且還使客戶(hù)/服務(wù)器雙向延遲實(shí)現了最小化。
小結
網(wǎng)絡(luò )程序的性能優(yōu)化顯然是一項復雜的任務(wù)。優(yōu)化技術(shù)包括：盡可能使用零拷貝、用TCP_CORK及其等價(jià)選項組裝適當的數據包、把傳輸數據包的數量最小化以及延遲優(yōu)化等。為了提升網(wǎng)絡(luò )、系統的性能和可伸縮性，有必要在程序代碼中聯(lián)合一致地采用以上各種可用方法。當然，清楚了解TCP/IP協(xié)議棧和操作系統的內部工作原理也是必要的
發(fā)布者：博子
評論