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