H3C-OAA之WAN優(yōu)化技術(shù)白皮書(shū)

H3COAA之WAN優(yōu)化技術(shù)白皮書(shū)

目錄目錄 41.概述 5背景 5廣域網(wǎng)優(yōu)化簡(jiǎn)介 52.廣域網(wǎng)優(yōu)化原理介紹 6數(shù)據(jù)壓縮原理介紹 6緩存原理 7根本原理 7數(shù)據(jù)塊緩存原理 72.3TCP加速原理介紹 8窗口大小通告與滑動(dòng)窗口 9慢啟動(dòng) 9擁塞防止 9窗口調(diào)節(jié)技術(shù) 11選擇性確認(rèn) 11SplitTCP 112.4QoS原理介紹 12模型 12QoS技術(shù)介紹 133.解決方案主要模塊介紹 14多業(yè)務(wù)路由器MSR 143.2WAAM模塊 14數(shù)據(jù)壓縮 15應(yīng)用加速 19TCP加速 21基于應(yīng)用的QoS技術(shù) 21ACFP協(xié)議 224.參考案例 25

目錄TOC\h\z\t"圖注"\c圖1數(shù)據(jù)壓縮原理 7圖2同類數(shù)據(jù)壓縮原理 8圖3基于塊的數(shù)據(jù)緩存 9圖4字節(jié)級(jí)數(shù)據(jù)緩存 9圖5擁塞防止與慢啟動(dòng) 11圖6SplitTCP 13圖7IPComp和RTM壓縮模式 16圖8VDA算法 17圖9SC算法 18圖10APC算法 18圖11壓縮過(guò)程1 19圖12壓縮過(guò)程2 19圖13HTTP/FTP應(yīng)用加速 20圖14DNS應(yīng)用加速 21圖15Citrix應(yīng)用加速 21圖16語(yǔ)音應(yīng)用加速 22圖17OAA體系結(jié)構(gòu)示意圖 24圖18主機(jī)模式示意圖 25圖19透?jìng)髂Ｊ绞疽鈭D 25圖20鏡像模式示意圖 26圖21重定向模式示意圖 26OAAWAN優(yōu)化解決方案技術(shù)白皮書(shū)概述背景廣域網(wǎng)的帶寬比局域網(wǎng)帶寬差很多，并且廣域網(wǎng)帶寬的增加會(huì)帶來(lái)本錢大幅度上升。與此同時(shí)還會(huì)帶來(lái)一定影響的網(wǎng)絡(luò)延遲。廣域網(wǎng)應(yīng)用大幅度增加，除了語(yǔ)音、視頻外，傳輸文件、圖片以及海量數(shù)據(jù)的分析以及處理，這些都是困擾用戶正常使用的重要因素。另外信息的集中化管理，對(duì)各分部和總部之間的高質(zhì)量信息轉(zhuǎn)送也提出了越來(lái)越高的要求，這就需要增加各地的分支機(jī)構(gòu)。與此同時(shí)企業(yè)分支網(wǎng)絡(luò)逐漸出現(xiàn)了數(shù)據(jù)集中趨勢(shì)，一般情況下企業(yè)會(huì)將大局部共享數(shù)據(jù)庫(kù)放到總部的數(shù)據(jù)中心，給每一個(gè)分支機(jī)構(gòu)訪問(wèn)，但隨著分支機(jī)構(gòu)的迅速增加且多數(shù)員工外出辦公時(shí)的訪問(wèn)量也在上升，這種一對(duì)多的數(shù)據(jù)效勞給企業(yè)總部的效勞器和帶寬帶來(lái)了巨大的壓力，影響了數(shù)據(jù)交換的速度。企業(yè)雖然也可以向運(yùn)營(yíng)商購(gòu)置更高的帶寬，不過(guò)本錢費(fèi)用較高并且效果不明顯。廣域網(wǎng)性能低下對(duì)于用戶的影響主要包括以下幾個(gè)方面：大多數(shù)企業(yè)管理、應(yīng)用軟件均采用C/S結(jié)構(gòu)進(jìn)行編寫(xiě)，雖逐步在進(jìn)行B/S的更改，但是大局部企業(yè)的應(yīng)用仍然基于C/S結(jié)構(gòu)，對(duì)于C/S到B/S結(jié)構(gòu)的更改仍然是一個(gè)重要的課題增加帶寬并不能解決訪問(wèn)及應(yīng)用慢速的問(wèn)題，問(wèn)題存在與TCP自身，TCP自身慢啟動(dòng)問(wèn)題仍然是阻礙企業(yè)業(yè)務(wù)正常開(kāi)展的主要問(wèn)題廣域網(wǎng)行業(yè)縱向網(wǎng)的分支機(jī)構(gòu)眾多，全部采用高帶寬連接投資非常巨大，合作伙伴之間帶寬一般采取的是臨時(shí)建立的連接，帶寬極低，又要傳輸大量的數(shù)據(jù)，造成傳輸速度難以忍受根本語(yǔ)音視頻業(yè)務(wù)沒(méi)有最正確的QoS策略來(lái)進(jìn)行保證，造成質(zhì)量不佳，最終導(dǎo)致應(yīng)用開(kāi)展不起來(lái)；大量非法應(yīng)用堵塞了現(xiàn)有正常應(yīng)用開(kāi)展，占據(jù)的帶寬造成了正常帶寬的縮減。廣域網(wǎng)優(yōu)化簡(jiǎn)介廣域網(wǎng)〔WAN〕帶寬昂貴，絕大多數(shù)用戶也因此只能擁有有限的廣域網(wǎng)帶寬。如何以最小的投入提高網(wǎng)絡(luò)性能？如何為遠(yuǎn)程用戶提高訪問(wèn)速度和效勞效率？怎樣確保隨時(shí)召開(kāi)異地視頻會(huì)議而不被打斷？一種方式是“擴(kuò)出口買帶寬〞，其實(shí)有更合理的方法解決。數(shù)據(jù)壓縮、動(dòng)態(tài)緩存、IP流量管理以及QoS等都可以一定程度上解決廣域網(wǎng)傳輸加速的問(wèn)題。但壓縮僅僅解決了帶寬資源的問(wèn)題，對(duì)于延遲非常大的鏈路，僅靠壓縮是無(wú)法完全解決問(wèn)題的。為解決系統(tǒng)性能和應(yīng)用系統(tǒng)數(shù)據(jù)傳輸受WAN通信限制的問(wèn)題，相關(guān)技術(shù)開(kāi)始浮出水面，并逐漸形成一個(gè)細(xì)分的市場(chǎng)—這就是WAN優(yōu)化技術(shù)市場(chǎng)。其中包括：應(yīng)用加速、數(shù)據(jù)壓縮、動(dòng)態(tài)緩存、IP流量管理、QoS保障、帶寬管理、延時(shí)縮減、序列緩存、路徑優(yōu)化和應(yīng)用管理可視化等。要解決的核心問(wèn)題是應(yīng)用和廣域網(wǎng)之間的矛盾，因?yàn)閭鹘y(tǒng)的網(wǎng)絡(luò)資源限制了多種應(yīng)用的性能。隨著網(wǎng)絡(luò)優(yōu)化技術(shù)的開(kāi)展，諸如控制網(wǎng)絡(luò)應(yīng)用〔控制QQ、MSN、IM〕、限制P2P〔限制BT、eMule、PPLive、eDonkey〕軟件占用帶寬、通過(guò)QoS合理分配帶寬、Web緩存、數(shù)據(jù)壓縮、動(dòng)態(tài)緩存等網(wǎng)絡(luò)加速方法和解決方案已經(jīng)能夠滿足多數(shù)用戶的需要了。為什么廣域網(wǎng)優(yōu)化會(huì)受到如此青睞呢？原因是它確實(shí)能解決廣域網(wǎng)目前存在的幾大關(guān)鍵弊病。首先，帶寬問(wèn)題。廣域網(wǎng)的帶寬比局域網(wǎng)帶寬差得太多，如一條T1線路的帶寬只相當(dāng)于千兆網(wǎng)的千分之一，許多幀中繼線路的帶寬只有256Kbps，并且廣域網(wǎng)帶寬的增加會(huì)帶來(lái)本錢大幅度上升。其次，延遲問(wèn)題。打過(guò)跨國(guó)IP的人或許都有這樣的體驗(yàn)，當(dāng)你說(shuō)完話后，對(duì)方的回音總是過(guò)一小段時(shí)間才能聽(tīng)到，這就是延遲的最好例子，在進(jìn)行視頻通話時(shí)就更明顯了。目前廣域網(wǎng)應(yīng)用劇增，除了語(yǔ)音、視頻外，傳輸圖形或圖像文件、海量數(shù)據(jù)的處理，都是困擾用戶的實(shí)際應(yīng)用。再有，協(xié)議問(wèn)題。一些目前采用的協(xié)議并不是為廣域網(wǎng)而設(shè)計(jì)的〔如TCP協(xié)議〕，協(xié)議效率低下，性能不夠理想。廣域網(wǎng)優(yōu)化原理介紹廣域網(wǎng)優(yōu)化的技術(shù)有很多，但核心的技術(shù)主要包括：數(shù)據(jù)壓縮、動(dòng)態(tài)緩存、TCP加速、應(yīng)用加速、QoS等幾個(gè)方面。數(shù)據(jù)壓縮原理介紹迄今為止大多數(shù)網(wǎng)絡(luò)壓縮系統(tǒng)都是基于數(shù)據(jù)包。基于數(shù)據(jù)包的壓縮系統(tǒng)緩沖數(shù)據(jù)包都通過(guò)解壓器引導(dǎo)至遠(yuǎn)程網(wǎng)絡(luò)。此后，用戶可一次壓縮一個(gè)數(shù)據(jù)包，或一次壓縮多個(gè)數(shù)據(jù)包，然后再發(fā)送至在其中反向進(jìn)行該流程的解壓器。數(shù)據(jù)壓縮原理基于數(shù)據(jù)包壓縮應(yīng)用的主要問(wèn)題是壓縮時(shí)它將多種數(shù)據(jù)類型混合在一起。所有壓縮例程在處理同類數(shù)據(jù)時(shí)將獲得更大的壓縮比。在處理異質(zhì)數(shù)據(jù)時(shí)〔例如，多種協(xié)議的大量數(shù)據(jù)包〕，壓縮比率會(huì)大大降低。基于數(shù)據(jù)包的壓縮系統(tǒng)會(huì)存在其它問(wèn)題。壓縮數(shù)據(jù)包時(shí)，這些系統(tǒng)必須在網(wǎng)絡(luò)中編寫(xiě)小數(shù)據(jù)包，并進(jìn)行其它工作以集合并封裝多個(gè)數(shù)據(jù)包。僅有其中一項(xiàng)操作不可能到達(dá)最正確效果。在網(wǎng)絡(luò)中編寫(xiě)小數(shù)據(jù)包會(huì)增加TCP/IP標(biāo)頭的開(kāi)銷。另外，集合并封裝數(shù)據(jù)包會(huì)為該數(shù)據(jù)流增加封裝標(biāo)頭。先進(jìn)的壓縮算法支持在處理所有應(yīng)用類型時(shí)能夠在完全同類的數(shù)據(jù)之間進(jìn)行壓縮。隨之而來(lái)的結(jié)果是，與同類基于數(shù)據(jù)包的系統(tǒng)相比，壓縮比更高。同類數(shù)據(jù)壓縮原理緩存原理根本原理所有壓縮例程共同存在的局限性是存儲(chǔ)空間有限。許多例程，例如gzip，只能存儲(chǔ)64Kb的數(shù)據(jù)。其它技術(shù)，例如基于磁盤(pán)的壓縮系統(tǒng)，可以存儲(chǔ)1TB的數(shù)據(jù)。為了理解字典大小的作用，需要對(duì)高速緩存管理內(nèi)容有一個(gè)根本的了解。請(qǐng)求web站點(diǎn)類似，并非所有網(wǎng)絡(luò)中傳輸?shù)淖止?jié)會(huì)在同一個(gè)頻率下重復(fù)。有時(shí)系統(tǒng)會(huì)通過(guò)高頻率傳輸一些字節(jié)，因?yàn)檫@些字節(jié)是常用文件或通用網(wǎng)絡(luò)協(xié)議中的一局部。其它字節(jié)只會(huì)出現(xiàn)一次并且不會(huì)重復(fù)出現(xiàn)。壓縮和堆積定律(Zipf’sLawandHeaps’Law)中描述了頻繁重復(fù)字節(jié)序列和非頻繁重復(fù)字節(jié)序列之間的關(guān)系。所有基于當(dāng)前字典的壓縮系統(tǒng)會(huì)通過(guò)存儲(chǔ)頻繁訪問(wèn)的數(shù)據(jù)并刪除非頻繁訪問(wèn)的數(shù)據(jù)以進(jìn)行不均等的分配。通過(guò)這種優(yōu)化方式，存儲(chǔ)少于10%的所有字節(jié)方式會(huì)使命中率超過(guò)50%。這種字節(jié)方式的不均等分布效果充分證明了公共壓縮程序的效率。Gzip僅存儲(chǔ)64kb的歷史記錄，但平均能夠壓縮近64%的內(nèi)容。Bzip2能夠存儲(chǔ)100kb至900kb的歷史記錄，平均壓縮了66%的內(nèi)容。盡管數(shù)據(jù)存儲(chǔ)空間缺乏，但Gzip和Bzip2仍能出色運(yùn)行的原因在于頻繁出現(xiàn)的字節(jié)序列能夠表示網(wǎng)絡(luò)中的大多數(shù)字節(jié)。數(shù)據(jù)塊緩存原理基于塊的系統(tǒng)可存儲(chǔ)以前在廣域網(wǎng)中傳輸數(shù)據(jù)流局部。再次遇到這些塊時(shí)，其參考數(shù)據(jù)會(huì)傳送到遠(yuǎn)程設(shè)備中，該遠(yuǎn)程設(shè)備繼而會(huì)重組原始數(shù)據(jù)。基于塊的系統(tǒng)主要缺點(diǎn)是反復(fù)出現(xiàn)的數(shù)據(jù)和塊的長(zhǎng)度永遠(yuǎn)不會(huì)完全相同。因此，匹配僅是局部匹配，還會(huì)留下一些重復(fù)數(shù)據(jù)不被壓縮。以下圖詳細(xì)描述了使用256字節(jié)塊大小壓縮512字節(jié)數(shù)據(jù)時(shí)的情況?；趬K的數(shù)據(jù)緩存為了提高緩存效率，字節(jié)級(jí)粒度的緩存技術(shù)出現(xiàn)了。匹配并發(fā)送帶有字節(jié)級(jí)粒度(bytelevelgranularity)的數(shù)據(jù)。以下圖說(shuō)明了處理數(shù)據(jù)的過(guò)程。字節(jié)級(jí)數(shù)據(jù)緩存與基于塊的系統(tǒng)相比，字節(jié)粒度級(jí)別無(wú)論對(duì)于文檔還是對(duì)于應(yīng)用層協(xié)議標(biāo)頭，均能提高其壓縮級(jí)別。TCP加速原理介紹TCP協(xié)議原理較為復(fù)雜，影響TCP性能的因素很多，但有一個(gè)關(guān)鍵的因素是TCP會(huì)降低帶寬的利用率，這對(duì)于帶寬極其有限的廣域網(wǎng)來(lái)說(shuō)是非常致命的。影響TCP帶寬利用率的主要因素包括以下幾個(gè)方面：窗口大小通告與滑動(dòng)窗口擁塞防止慢啟動(dòng)窗口調(diào)節(jié)技術(shù)除了提高帶寬利用率之外，減少確認(rèn)重傳次數(shù)，縮短TCP連接的握手過(guò)程時(shí)間等也是TCP加速的重要技術(shù)點(diǎn)。選擇性確認(rèn)3次握手過(guò)程的優(yōu)化下面簡(jiǎn)單介紹這幾個(gè)方面的原理。窗口大小通告與滑動(dòng)窗口通信雙方接收模塊需要依據(jù)各自的緩沖區(qū)大小，相互通告還能接受對(duì)方數(shù)據(jù)的尺寸。雙方發(fā)送模塊那么必須根據(jù)對(duì)方通告的接收窗口大小，進(jìn)行數(shù)據(jù)發(fā)送。這種機(jī)制稱之謂滑動(dòng)窗口，它是TDP接收方的流量控制方法。它允許發(fā)送方在停止并等待確認(rèn)前可以連續(xù)發(fā)送多個(gè)分組〔依據(jù)滑動(dòng)窗口的大小〕，由于發(fā)送方不必每發(fā)一個(gè)分組就停下來(lái)等待確認(rèn)，因此可以加速數(shù)據(jù)的傳輸?；瑒?dòng)窗口在排序數(shù)據(jù)流上不時(shí)的向右移動(dòng)，窗口兩個(gè)邊沿的相對(duì)運(yùn)動(dòng)增加或減少了窗口的大小，關(guān)于窗口邊沿的運(yùn)動(dòng)有三個(gè)術(shù)語(yǔ)：窗口合攏〔當(dāng)左邊沿向右邊沿靠近〕、窗口張開(kāi)〔當(dāng)右邊沿向右移動(dòng)〕、窗口收縮〔當(dāng)右邊沿向左移動(dòng)〕。當(dāng)遇到快的發(fā)送方與慢的接收方的情況時(shí)，接收方的窗口會(huì)很快被發(fā)送方的數(shù)據(jù)填滿，此時(shí)接收方將通告窗口大小為0,發(fā)送方那么停止發(fā)送數(shù)據(jù)。直到接收方用戶程序取走數(shù)據(jù)后更新窗口大小，發(fā)送方可以繼續(xù)發(fā)送數(shù)據(jù)；另外，因?yàn)锳CK報(bào)文段有可能喪失，發(fā)送方可能沒(méi)有成功接收到更新的窗口大小，因此發(fā)送方將啟動(dòng)一個(gè)堅(jiān)持定時(shí)器，當(dāng)堅(jiān)持定時(shí)器超時(shí)，發(fā)送方將發(fā)送一個(gè)字節(jié)的數(shù)據(jù)到接收方，嘗試檢查窗口大小的更新。慢啟動(dòng)如果發(fā)送方一開(kāi)始便向網(wǎng)絡(luò)發(fā)送多個(gè)報(bào)文段，直至到達(dá)接收方通告窗口大小為止。當(dāng)發(fā)送方與接收方在同一局域網(wǎng)時(shí)，這種方式是可以的。但如果在發(fā)送方與接收方之間存在多個(gè)路由器和速率較慢的鏈路時(shí)，就可能出現(xiàn)問(wèn)題。一些中間路由器必須緩存分組，并有可能耗盡存儲(chǔ)器的空間，將來(lái)得降低TCP連接的吞吐量。于是需要一種叫“慢啟動(dòng)〞的擁塞控制算法。慢啟動(dòng)為發(fā)送方增加一個(gè)擁塞窗口，記為cwnd，當(dāng)與另一個(gè)網(wǎng)絡(luò)的主機(jī)建立連接時(shí)，擁塞窗口被初始化為1個(gè)報(bào)文段。每收到一個(gè)ACK，擁塞窗口就增加一個(gè)報(bào)文段〔cwnd以字節(jié)為單位，但慢啟動(dòng)以報(bào)文段大小為單位進(jìn)行增加〕。發(fā)送方取擁塞窗口與通告窗口中的最小值作為發(fā)送上限。擁塞窗口是發(fā)送方使用的流量控制，而通告窗口是接收方使用的流量控制。發(fā)送方開(kāi)始時(shí)發(fā)送一個(gè)報(bào)文段，然后等待ACK。當(dāng)收到該ACK時(shí)，擁塞窗口從1增加到2,即可以發(fā)送兩個(gè)報(bào)文段。當(dāng)收到這兩個(gè)報(bào)文段的ACK時(shí)，擁塞窗口就增加為4。這是一種指數(shù)增加的關(guān)系。擁塞防止慢啟動(dòng)算法增加擁塞窗口大小到某些點(diǎn)上可能到達(dá)了互聯(lián)網(wǎng)的容量，于是中間路由器開(kāi)始丟棄分組。這就通知發(fā)送方它的擁塞窗口開(kāi)得太大。擁塞防止算法是一種處理喪失分組的方法。該算法假定由于分組受到損壞引起的喪失是非常少的〔遠(yuǎn)小于1％〕，因此分組喪失就意味著在源主機(jī)和目標(biāo)主機(jī)之間的某處網(wǎng)絡(luò)上發(fā)生了擁塞。有兩種分組喪失的指示：發(fā)生超時(shí)和接收到重復(fù)確實(shí)認(rèn)。擁塞防止算法與慢啟動(dòng)算法是兩個(gè)獨(dú)立的算法，但實(shí)際中這兩個(gè)算法通常在一起實(shí)現(xiàn)。擁塞防止與慢啟動(dòng)擁塞防止算法和慢啟動(dòng)算法需要對(duì)每個(gè)連接維持兩個(gè)變量：一個(gè)擁塞窗口cwnd和一個(gè)慢啟動(dòng)門限ssthresh。算法的工作過(guò)程如下：1)對(duì)一個(gè)給定的連接，初始化cwnd為1個(gè)報(bào)文段，ssthresh為65535個(gè)字節(jié)。2)TCP輸出例程的輸出不能超過(guò)cwnd和接收方通告窗口的大小。擁塞防止是發(fā)送方使用的流量控制，而通告窗口那么是接收方進(jìn)行的流量控制。前者是發(fā)送方感受到的網(wǎng)絡(luò)擁塞的估計(jì)，而后者那么與接收方在該連接上的可用緩存大小有關(guān)。3)當(dāng)擁塞發(fā)生時(shí)〔超時(shí)或收到重復(fù)確認(rèn)〕，ssthresh被設(shè)置為當(dāng)前窗口大小的一半〔cwnd和接收方通告窗口大小的最小值，但最少為2個(gè)報(bào)文段〕。此外，如果是超時(shí)引起了擁塞，那么cwnd被設(shè)置為1個(gè)報(bào)文段〔這就是慢啟動(dòng)〕。4)當(dāng)新的數(shù)據(jù)被對(duì)方確認(rèn)時(shí)，就增加cwnd，但增加的方法依賴于我們是否正在進(jìn)行慢啟動(dòng)或擁塞防止。如果cwnd小于或等于ssthresh，那么正在進(jìn)行慢啟動(dòng)，否那么正在進(jìn)行擁塞防止。慢啟動(dòng)一直持續(xù)到我們回到當(dāng)擁塞發(fā)生時(shí)所處位置的半時(shí)候才停止〔因?yàn)槲覀冇涗浟嗽诓襟E2中給我們制造麻煩的窗口大小的一半〕，然后轉(zhuǎn)為執(zhí)行擁塞防止。慢啟動(dòng)算法初始設(shè)置cwnd為1個(gè)報(bào)文段，此后每收到一個(gè)確認(rèn)就加1。這會(huì)使窗口按指數(shù)方式增長(zhǎng)：發(fā)送1個(gè)報(bào)文段，然后是2個(gè)，接著是4個(gè)……。擁塞防止算法要求每次收到一個(gè)確認(rèn)時(shí)將cwnd增加1/cwnd。與慢啟動(dòng)的指數(shù)增加比起來(lái)，這是一種加性增長(zhǎng)。我們希望在一個(gè)往返時(shí)間內(nèi)最多為cwnd增加1個(gè)報(bào)文段〔不管在這個(gè)RTT中收到了多少個(gè)ACK〕，然而慢啟動(dòng)將根據(jù)這個(gè)往返時(shí)間中所收到確實(shí)認(rèn)的個(gè)數(shù)增加cwnd。處于擁塞防止?fàn)顟B(tài)時(shí)，擁塞窗口的計(jì)算公式如下〔引公式參照BSD的實(shí)現(xiàn)，segsize/8的值是一個(gè)匹配補(bǔ)充量，不在算法描述當(dāng)中〕：cwnd<-cwnd+segsize*segsize/cwnd+segsize/8。窗口調(diào)節(jié)技術(shù)傳輸窗口大小，即在收到回應(yīng)之前一次發(fā)送的數(shù)據(jù)量，會(huì)直接影響到TCP的性能。相反，性能又與回程時(shí)間成正比，因?yàn)閰f(xié)議需要〔通過(guò)ACK包說(shuō)明數(shù)據(jù)已被成功接收的信號(hào)〕確保數(shù)據(jù)投送到位。在最糟糕的情況下，一個(gè)端點(diǎn)會(huì)等待另一端點(diǎn)回應(yīng)數(shù)據(jù)的傳輸情況，從而使網(wǎng)絡(luò)閑置的時(shí)間變長(zhǎng)。當(dāng)傳輸窗口變得很小時(shí)，這種現(xiàn)象便會(huì)發(fā)生，但此現(xiàn)象并不能準(zhǔn)確反映線路速度和延遲情況。使情況變得更加復(fù)雜的是，TCP會(huì)根據(jù)響應(yīng)速度調(diào)整自己的窗口大小。連接的距離越長(zhǎng)，窗口就越小。如果響應(yīng)的速度非常緩慢，TCP協(xié)議就可能永遠(yuǎn)也不選擇最大的窗口尺寸，這意味著許多廣域網(wǎng)連接的完整容量永遠(yuǎn)也不會(huì)被完全利用。因此，TCP協(xié)議可能導(dǎo)致廣域網(wǎng)性能的惡化，甚至在帶寬仍然非常充足時(shí)，性能的惡化也在所難免。同樣，重傳也會(huì)嚴(yán)重影響TCP的性能，要知道1%的包喪失可能導(dǎo)致最多80%的性能損失。TCP應(yīng)當(dāng)基于系統(tǒng)可用帶寬時(shí)延積〔BDP，BandwidthDelayProduct〕設(shè)定適宜的接收方窗口大小。接收方通知窗口應(yīng)當(dāng)至少同BDP一樣大，否那么接收方的TCP層將對(duì)最大可用帶寬造成限制。該技術(shù)可以自行選擇TCP窗口的大小，從而實(shí)現(xiàn)最高的傳輸速率并在廣域網(wǎng)連接發(fā)生包喪失時(shí)將重傳數(shù)據(jù)包的數(shù)量減至最小。通知窗口應(yīng)當(dāng)盡可能地設(shè)大一些，使得所有的可用帶寬都有可能使用；但如果通知窗口比BDP大太多，也可能因?yàn)榫彺嬉绯龊碗S后的TCP重傳導(dǎo)致性能惡化。因而，通知窗口應(yīng)當(dāng)比BDP稍大，一方面充分使用容量，另一方面也不會(huì)損害到網(wǎng)絡(luò)處理?yè)砣蛠G報(bào)恢復(fù)的能力。TCPFastStart也是一種算法，它可以加速TCP發(fā)送窗口的增長(zhǎng)速度，從而實(shí)現(xiàn)了可用帶寬的快速利用。選擇性確認(rèn)TCP連接期間，接收方將最后一個(gè)成功接收?qǐng)?bào)文段的序號(hào)包含進(jìn)ACK中，此即累積性確認(rèn)。一般而言，選擇性ACK〔SACK，SelectiveAcknowledgement〕那么是可選項(xiàng)，它允許接收方向發(fā)送方通知所有數(shù)據(jù)段的傳輸狀態(tài)。這樣，發(fā)送方就可以有選擇地重傳，而不是僅僅重傳第一個(gè)喪失分組并等待下一個(gè)ACK〔一個(gè)RTT〕來(lái)接收新的喪失信息。在具有較大BDP通道時(shí)，SACK更能發(fā)揮作用，有研究結(jié)果說(shuō)明它適合于具有中等喪失率〔低于窗口大小的50%〕的長(zhǎng)延遲網(wǎng)絡(luò)環(huán)境。這使得SACK比擬適合于無(wú)線鏈路。但其缺乏在于它會(huì)稍微加大報(bào)頭的尺寸〔最多增添8byte〕，且其使用需要客戶機(jī)、效勞器兩端的支持。SplitTCPTCP連接跨越廣域網(wǎng)時(shí)，廣域網(wǎng)上跳數(shù)多，路由變化頻繁，會(huì)對(duì)TCP連接的性能造成不良影響。為了提高TCP連接的吞吐率，提出SplitTCP〔即TCP代理〕的解決思路。具體地說(shuō)就是在TCP端到端連接中設(shè)置代理，將一條完整的長(zhǎng)路經(jīng)切割成多條段路徑，針對(duì)每一條短路徑分別建立TCP連接。這樣可以提高TCP連接的吞吐量，同時(shí)也可以改善TCP建立的3次握手過(guò)程的性能。連接建立分要經(jīng)過(guò)三次握手過(guò)程：客戶端發(fā)送一個(gè)SYN段到指明客戶打算連接的效勞器的端口，報(bào)文段中要設(shè)置客戶端初始序號(hào)。效勞器發(fā)回包含效勞器的初始序號(hào)的SYN報(bào)文段作為應(yīng)答。同時(shí)，將確認(rèn)序號(hào)設(shè)置為客戶的初始序號(hào)加1,并設(shè)置ACK位標(biāo)志報(bào)文段為確認(rèn)報(bào)文段?？蛻舳吮仨殞⒋_認(rèn)序號(hào)設(shè)置為效勞器初始序號(hào)加1,對(duì)效勞器的SYN報(bào)文段進(jìn)行確認(rèn)。全局維護(hù)一個(gè)初始序號(hào)種子，這個(gè)初始序號(hào)為隨時(shí)產(chǎn)生的32位整數(shù)。連接建立的超時(shí)和重傳初始值為3秒，超時(shí)采用指數(shù)退避算法，3秒超時(shí)后超時(shí)值為6秒，然后是12秒，24秒……。連接建立最長(zhǎng)時(shí)間限制為75秒。SplitTCPQoS原理介紹模型Best-Effort模型Best-Effort是一個(gè)單一的效勞模型，也是最簡(jiǎn)單的效勞模型。應(yīng)用程序可以在任何時(shí)候發(fā)出任意數(shù)量的報(bào)文，而且不需要事先獲得批準(zhǔn)，也不需要通知網(wǎng)絡(luò)。對(duì)Best-Effort效勞網(wǎng)絡(luò)，盡最大的可能性來(lái)發(fā)送報(bào)文，但對(duì)時(shí)延可靠性等性能不提供任何保證。InterServ模型該模型使用資源預(yù)留〔RSVP〕協(xié)議，RSVP運(yùn)行在從源端到目的端的每個(gè)路由器上，負(fù)責(zé)請(qǐng)求/預(yù)留資源。InterServ模型能夠在IP網(wǎng)上提供端到端的QOS保證。但是，InterServ模型對(duì)路由器的要求很高，當(dāng)網(wǎng)絡(luò)中的數(shù)據(jù)流數(shù)量很大時(shí)，路由器的存儲(chǔ)和處理能力會(huì)遇到很大的壓力。DiffServ模型區(qū)分效勞〔DiffServ〕是IETF工作組為了克服InterServ的可擴(kuò)展性差在1998年提出的另一個(gè)效勞模型，目的是制定一個(gè)可擴(kuò)展性相對(duì)較強(qiáng)的方法來(lái)保證IP的效勞質(zhì)量。在DiffServ模型中，業(yè)務(wù)流被劃分成不同的差分效勞類。一個(gè)業(yè)務(wù)流的差分效勞類由其IP包頭中的差分效勞標(biāo)記字段〔DifferentServiceCodePoint，簡(jiǎn)稱DSCP〕來(lái)表示。在實(shí)施DiffServ的網(wǎng)絡(luò)中，每一個(gè)路由器都會(huì)根據(jù)數(shù)據(jù)包的DSCP字段執(zhí)行相應(yīng)的PHB(PerHopBehavior)行為，主要包括以下三類PHB：ExpeditedForwarding(EF)：主要用于低延遲、抖動(dòng)和丟包率的業(yè)務(wù)，這類業(yè)務(wù)一般運(yùn)行一個(gè)相對(duì)穩(wěn)定的速率，需要在路由器中進(jìn)行快速轉(zhuǎn)發(fā)；AssuredForwarding(AF)：這類業(yè)務(wù)在沒(méi)有超過(guò)最大允許帶寬時(shí)能夠確保轉(zhuǎn)發(fā)，一旦超出最大允許帶寬，那么允許根據(jù)不同的丟棄級(jí)別丟棄報(bào)文。AF確保轉(zhuǎn)發(fā)類將轉(zhuǎn)發(fā)行為分為4類，每一個(gè)確保轉(zhuǎn)發(fā)類都被分配了不同的帶寬資源，并對(duì)應(yīng)3個(gè)不同的丟棄優(yōu)先級(jí)。IETF建議使用4個(gè)不同的隊(duì)列分別傳輸AF1x、AF2x、AF3x、AF4x業(yè)務(wù)，并且每個(gè)隊(duì)列提供3種不同的丟棄優(yōu)先級(jí)，因此可以構(gòu)成12個(gè)有保證轉(zhuǎn)發(fā)的PHB。BestEffort(BE)：盡力轉(zhuǎn)發(fā)，主要用于對(duì)時(shí)延、抖動(dòng)和丟包不敏感的業(yè)務(wù)。目前，基于DiffServ模型的QoS效勞是業(yè)界主流。下面將簡(jiǎn)單介紹一些基于DiffServ模型的QoS技術(shù)。QoS技術(shù)介紹流量分類和標(biāo)記報(bào)文分類是將報(bào)文劃分為多個(gè)優(yōu)先級(jí)或多個(gè)效勞類，如使用IP報(bào)文頭的ToS〔Typeofservice，效勞類型〕字段的前三位〔即IP優(yōu)先級(jí)〕來(lái)標(biāo)記報(bào)文，可以將報(bào)文最多分成8類；假設(shè)使用DSCP〔DifferentiatedServicesCodepoint，區(qū)分效勞編碼點(diǎn)，ToS域的前6位〕，那么最多可分成64類。在報(bào)文分類后，就可以將其它的QoS特性應(yīng)用到不同的分類，實(shí)現(xiàn)基于類的擁塞管理、流量整形等。擁塞管理?yè)砣芾硎侵妇W(wǎng)絡(luò)在發(fā)生擁塞時(shí)，如何進(jìn)行管理和控制。處理的方法是使用隊(duì)列技術(shù)。將所有要從一個(gè)接口發(fā)出的報(bào)文進(jìn)入多個(gè)隊(duì)列，按照各個(gè)隊(duì)列的優(yōu)先級(jí)進(jìn)行處理。不同的隊(duì)列算法用來(lái)解決不同的問(wèn)題，并產(chǎn)生不同的效果。常用的隊(duì)列有FIFO、PQ，CQ，RTP優(yōu)先隊(duì)列，WFQ，CBWFQ等。擁塞管理的處理包括隊(duì)列的創(chuàng)立、報(bào)文的分類、將報(bào)文送入不同的隊(duì)列、隊(duì)列調(diào)度等。在一個(gè)接口沒(méi)有發(fā)生擁塞的時(shí)候，報(bào)文在到達(dá)接口后立即就被發(fā)送出去，在報(bào)文到達(dá)的速度超過(guò)接口發(fā)送報(bào)文的速度時(shí)，接口就發(fā)生了擁塞。擁塞管理就會(huì)將這些報(bào)文進(jìn)行分類，送入不同的隊(duì)列；而隊(duì)列調(diào)度對(duì)不同優(yōu)先級(jí)的報(bào)文進(jìn)行分別處理，優(yōu)先級(jí)高的報(bào)文會(huì)得到優(yōu)先處理。擁塞防止由于內(nèi)存資源的有限，按照傳統(tǒng)的處理方法，當(dāng)隊(duì)列的長(zhǎng)度到達(dá)規(guī)定的最大長(zhǎng)度時(shí)，所有到來(lái)的報(bào)文都被丟棄。對(duì)于TCP報(bào)文，如果大量的報(bào)文被丟棄，將造成TCP超時(shí)，從而引發(fā)TCP的慢啟動(dòng)和擁塞防止機(jī)制，使TCP減少報(bào)文的發(fā)送。當(dāng)隊(duì)列同時(shí)丟棄多個(gè)TCP連接的報(bào)文時(shí)，將造成多個(gè)TCP連接同時(shí)進(jìn)入慢啟動(dòng)和擁塞防止，稱之為：TCP全局同步。這樣多個(gè)TCP連接發(fā)向隊(duì)列的報(bào)文將同時(shí)減少，使得發(fā)向隊(duì)列的報(bào)文的量不及線路發(fā)送的速度，減少了線路帶寬的利用。并且，發(fā)向隊(duì)列的報(bào)文的流量總是忽大忽小，使線路的上的流量總在極少和飽滿之間波動(dòng)。為了防止這種情況的發(fā)生，隊(duì)列可以采用加權(quán)隨機(jī)早期檢測(cè)WRED〔WeightedRandomEarlyDetection〕的報(bào)文丟棄策略〔WRED與RED的區(qū)別在于前者引入IP優(yōu)先權(quán)，DSCP值，和MPLSEXP來(lái)區(qū)別丟棄策略〕。采用WRED時(shí)，用戶可以設(shè)定隊(duì)列的閾值〔threshold〕。當(dāng)隊(duì)列的長(zhǎng)度小于低閾值時(shí)，不丟棄報(bào)文；當(dāng)隊(duì)列的長(zhǎng)度在低閾值和高閾值之間時(shí)，WRED開(kāi)始隨機(jī)丟棄報(bào)文〔隊(duì)列的長(zhǎng)度越長(zhǎng)，丟棄的概率越高〕；當(dāng)隊(duì)列的長(zhǎng)度大于高閾值時(shí)，丟棄所有的報(bào)文。由于WRED隨機(jī)地丟棄報(bào)文，將防止使多個(gè)TCP連接同時(shí)降低發(fā)送速度，從而防止了TCP的全局同步現(xiàn)象。當(dāng)某個(gè)TCP連接的報(bào)文被丟棄，開(kāi)始減速發(fā)送的時(shí)候，其他的TCP連接仍然有較高的發(fā)送速度。這樣，無(wú)論什么時(shí)候，總有TCP連接在進(jìn)行較快的發(fā)送，提高了線路帶寬的利用率。流量監(jiān)管與流量整形 流量監(jiān)管〔trafficpolicing〕的典型作用是限制進(jìn)入某一網(wǎng)絡(luò)的某一連接的流量與突發(fā)。在報(bào)文滿足一定的條件時(shí)，如某個(gè)連接的報(bào)文流量過(guò)大，流量監(jiān)管就可以對(duì)該報(bào)文采取不同的處理動(dòng)作，例如丟棄報(bào)文，或重新設(shè)置報(bào)文的優(yōu)先級(jí)等。通常的用法是使用CAR來(lái)限制某類報(bào)文的流量，例如限制HTTP報(bào)文不能占用超過(guò)50%的網(wǎng)絡(luò)帶寬。 流量整形〔trafficshaping〕的典型作用是限制流出某一網(wǎng)絡(luò)的某一連接的流量與突發(fā)，使這類報(bào)文以比擬均勻的速度向外發(fā)送。流量整形通常使用緩沖區(qū)和令牌桶來(lái)完成，當(dāng)報(bào)文的發(fā)送速度過(guò)快時(shí)，首先在緩沖區(qū)進(jìn)行緩存，在令牌桶的控制下，再均勻地發(fā)送這些被緩沖的報(bào)文。鏈路分片與交叉〔LinkFragment&Interleave，LFI〕對(duì)于低速鏈路，即使為語(yǔ)音等實(shí)時(shí)業(yè)務(wù)報(bào)文配置了高優(yōu)先級(jí)隊(duì)列〔如RTP優(yōu)先隊(duì)列或LLQ〕，也不能夠保證其時(shí)延與抖動(dòng)，原因在于接口在發(fā)送其他數(shù)據(jù)報(bào)文的瞬間，語(yǔ)音業(yè)務(wù)報(bào)文只能等待，而對(duì)于低速接口發(fā)送較大的數(shù)據(jù)報(bào)文要花費(fèi)相當(dāng)?shù)臅r(shí)間。采用LFI以后，數(shù)據(jù)報(bào)文〔非RTP實(shí)時(shí)隊(duì)列和LLQ中的報(bào)文〕在發(fā)送前被分片、逐一發(fā)送，而此時(shí)如果有語(yǔ)音報(bào)文到達(dá)那么被優(yōu)先發(fā)送，從而保證了語(yǔ)音等實(shí)時(shí)業(yè)務(wù)的時(shí)延與抖動(dòng)。LFI主要用于低速鏈路。RTP報(bào)文頭壓縮〔RTPHeaderCompression，cRTP〕cRTP主要在低速鏈路上使用，可將40字節(jié)的IP/UDP/RTP頭壓縮到2~4個(gè)字節(jié)〔不使用校驗(yàn)和可到2字節(jié)〕，提高鏈路的利用率。cRTP主要得益于同一會(huì)話的語(yǔ)音分組頭和語(yǔ)音分組頭之間的差異往往是不變的，因此只需傳遞增量。RTP協(xié)議用于在IP網(wǎng)絡(luò)上承載語(yǔ)音、視頻等實(shí)時(shí)多媒體業(yè)務(wù)。解決方案主要模塊介紹H3C的OAAWAN優(yōu)化解決方案，主要由MSR(MultipleServiceRouter)多業(yè)務(wù)路由器與WAAM(WanApplication)模塊組成，兩者之間通過(guò)ACFP(Applicationcontrolforwardprotocol應(yīng)用控制轉(zhuǎn)發(fā)協(xié)議)進(jìn)行互動(dòng)連接。多業(yè)務(wù)路由器MSRMSR〔MultipleServicesRouter〕多業(yè)務(wù)開(kāi)放路由器是H3C公司專門面向行業(yè)分支機(jī)構(gòu)和大中型企業(yè)而推出的新一代網(wǎng)絡(luò)產(chǎn)品。MSR先進(jìn)的軟件結(jié)構(gòu)與硬件平臺(tái)，能夠在最小的投資范圍內(nèi)為企業(yè)邊緣網(wǎng)絡(luò)提供一體化解決方案，更能充分滿足未來(lái)業(yè)務(wù)擴(kuò)展的多元化應(yīng)用需求，符合企業(yè)IT建設(shè)的現(xiàn)狀與趨勢(shì)。企業(yè)信息架構(gòu)正在由C/S模式向B/S模式轉(zhuǎn)變，MSR具備高數(shù)據(jù)轉(zhuǎn)發(fā)能力與高加密能力，很好的解決了轉(zhuǎn)變過(guò)程中凸現(xiàn)的網(wǎng)絡(luò)帶寬壓力與平安隱患，保障企業(yè)關(guān)鍵業(yè)務(wù)流可以高速、機(jī)密的通過(guò)廣域網(wǎng)傳輸。WAAM模塊WAAM模塊的主要功能包括以下4個(gè)局部：數(shù)據(jù)壓縮應(yīng)用加速TCP加速L7QoS數(shù)據(jù)壓縮壓縮模式WAAM有兩個(gè)壓縮模式：IPComp,RTM。報(bào)文的具體壓縮封裝模式參加以下圖。IPComp和RTM壓縮模式IPComp類似一種隧道封裝方式，在兩個(gè)WAAM模塊之間建立一條靜態(tài)隧道，對(duì)于隧道內(nèi)的數(shù)據(jù)提供完全的封裝，對(duì)原始報(bào)文頭和數(shù)據(jù)都進(jìn)行壓縮處理，對(duì)外不可見(jiàn)，平安性較高。但由于對(duì)外屏蔽了原始報(bào)文頭，使得網(wǎng)絡(luò)中一些基于報(bào)文頭特殊字段的處理無(wú)法實(shí)施，例如：QoS，流量分析等等。需要注意的是：如果有明確的需要，可以通過(guò)配置保存原始報(bào)文頭中的局部字段，如：源地址、TTL或ToS域。RTM保存原始報(bào)文頭，僅壓縮原始數(shù)據(jù)區(qū)，平安性較差，但由于保存了原始報(bào)文頭，可以保證QoS、流量分析等功能的實(shí)施。壓縮算法WAAM的壓縮算法主要有3個(gè)，分別針對(duì)不同區(qū)域的數(shù)據(jù)進(jìn)行壓縮。VDA(VerticalDataAnalysis),將數(shù)據(jù)流分割成不同的報(bào)頭和數(shù)據(jù)段，并標(biāo)記可以緩存的局部。SC(SelectiveCaching),緩存重復(fù)傳輸?shù)淖止?jié)段。APC(AdaptivePacketCompression),對(duì)于不能緩存、不能分割報(bào)頭的數(shù)據(jù)進(jìn)行壓縮。VDA算法VDA算法VDA可以自動(dòng)識(shí)別報(bào)文中的各個(gè)協(xié)議字段，例如：:HDLCIPHeaderTCPHeaderHTTP/1.1HeaderXMLData通過(guò)預(yù)定義的規(guī)那么，VDA能夠分析更加細(xì)致的報(bào)頭信息，例如：sequencenumbersChecksumsprotocolidentifiersSC算法SC算法SC算法的本質(zhì)就是數(shù)據(jù)塊緩存，為了提高緩存效率，SC算法支持字節(jié)級(jí)粒度的緩存方式。從緩存的角度來(lái)看，VDA算法實(shí)際上是為SC算法效勞的。APC算法APC算法APC算法屬于典型的壓縮算法，具體原理與2.1小節(jié)中描述的原理很相似。不同的數(shù)據(jù)類型應(yīng)用不同的壓縮算法，例如：以下的數(shù)據(jù)就用不同的方式壓縮處理。這樣壓縮效果更好。HTMLSQLJavaScript壓縮處理過(guò)程在整個(gè)壓縮過(guò)程中，VDA、SC、APC并不是獨(dú)立存在的，而是相互配合、相互作用的一個(gè)整體，下面是一個(gè)完成的壓縮過(guò)程中，各算法之間的關(guān)系。壓縮過(guò)程1VDA、SC、APC算法的應(yīng)用有嚴(yán)格的順序關(guān)系，VDA算法實(shí)際上可以看作是SC算法的一個(gè)準(zhǔn)備步驟，而APC那么是VDA/SC算法的有效補(bǔ)充。壓縮過(guò)程2應(yīng)用加速當(dāng)前廣域網(wǎng)存在的主要問(wèn)題是時(shí)延過(guò)大，導(dǎo)致各種應(yīng)用性能嚴(yán)重降低。針對(duì)廣域網(wǎng)時(shí)延過(guò)大的問(wèn)題，WAAM采用應(yīng)用加速和TCP加速。應(yīng)用加速主要包括：HTTP/FTP/DNS等Citrix的各種應(yīng)用語(yǔ)音流的加速處理HTTP/FTP/DNS加速HTTP/FTP/DNS應(yīng)用加速的原理是本地代理機(jī)制。即在本地應(yīng)用加速設(shè)備上建立代理，通過(guò)代理與效勞器連接連接，對(duì)常用的請(qǐng)求進(jìn)行緩存。在收到請(qǐng)求時(shí)與緩存數(shù)據(jù)比照，如果匹配那么可以直接從本地代理獲取應(yīng)答，有效的減少了穿越廣域網(wǎng)的請(qǐng)求、應(yīng)答過(guò)程。因此，可以取得很好的加速效果。HTTP/FTP應(yīng)用加速啟用HTTP/FTP加速時(shí)，局部重復(fù)的請(qǐng)求與應(yīng)答不需要穿越廣域網(wǎng)，減小時(shí)延廣域網(wǎng)優(yōu)化設(shè)備終結(jié)會(huì)話緩存數(shù)據(jù)，并對(duì)重復(fù)的請(qǐng)求本地作出應(yīng)答減少重復(fù)數(shù)據(jù)反復(fù)穿越廣域網(wǎng)啟用DNS加速時(shí)，廣域網(wǎng)優(yōu)化設(shè)備本地應(yīng)答DNS請(qǐng)求，可以將原本需要200ms的應(yīng)答縮短到5ms。DNS應(yīng)用加速Citrix應(yīng)用加速Citrix應(yīng)用加速的核心是“小包組大包〞，減少報(bào)文頭對(duì)帶寬的消耗Citrix數(shù)據(jù)流小包居多，平均報(bào)文大小是80-100字節(jié)，壓縮后40-50字節(jié)，這些小包的報(bào)文頭對(duì)帶寬的消耗很可觀將報(bào)文頭相同的多個(gè)小包組成一個(gè)大包，可以有效的減少報(bào)文頭部對(duì)于帶寬的消耗Citrix應(yīng)用加速語(yǔ)音應(yīng)用加速語(yǔ)音加速的核心是鏈路分片與交叉〔LinkFragment&Interleave，LFI〕語(yǔ)音等實(shí)時(shí)業(yè)務(wù)報(bào)文配置了高優(yōu)先級(jí)隊(duì)列〔如RTP優(yōu)先隊(duì)列或LLQ〕低速接口發(fā)送較大的數(shù)據(jù)報(bào)文要花費(fèi)相當(dāng)?shù)臅r(shí)間，影響語(yǔ)音時(shí)延采用LFI以后，數(shù)據(jù)報(bào)文〔非RTP實(shí)時(shí)隊(duì)列和LLQ中的報(bào)文〕在發(fā)送前被分片、逐一發(fā)送，而此時(shí)如果有語(yǔ)音報(bào)文到達(dá)那么被優(yōu)先發(fā)送，從而保證了語(yǔ)音等實(shí)時(shí)業(yè)務(wù)的時(shí)延與抖動(dòng)語(yǔ)音應(yīng)用加速TCP加速WAAM在實(shí)現(xiàn)TCP加速技術(shù)方面，主要依據(jù)SCPS(SpaceCommunicationsProtocolStandards)的標(biāo)準(zhǔn)。重點(diǎn)突出以下幾個(gè)方面的技術(shù)內(nèi)容：SplitTCP突破TCP端到端連接的理念：取消了廣域網(wǎng)上TCP連接建立的3次握手過(guò)程。加快TCP連接建立過(guò)程。在兩端的局域網(wǎng)內(nèi)建立兩個(gè)高速的TCP連接在兩端的TCP加速設(shè)備之間建立一條優(yōu)化的TCP連接內(nèi)網(wǎng)隔離,快速啟動(dòng)。本地加速設(shè)備回應(yīng)SYN報(bào)文，同時(shí)保證廣域網(wǎng)連接啟動(dòng)優(yōu)化TCP，增加帶寬的使用率取消廣域網(wǎng)上TCP連接得慢啟動(dòng)過(guò)程，廣域網(wǎng)兩側(cè)的加速設(shè)備統(tǒng)一配置帶寬參數(shù)，通過(guò)帶寬參數(shù)計(jì)算擁塞窗口的尺寸取消窗口大小調(diào)整過(guò)程。窗口尺寸根據(jù)帶寬計(jì)算，相對(duì)固定，不再頻繁變化。窗口大小調(diào)整，擴(kuò)大TCP窗口尺寸：基準(zhǔn)值16K，最大值64K。便于ACK快速到達(dá)，減少不必要的重傳。選擇性ACK—SNACK，僅對(duì)丟棄的包進(jìn)行重傳。不對(duì)稱鏈路，例如：減少?gòu)V域網(wǎng)上ACK傳輸?shù)臄?shù)量取消擁塞防止機(jī)制優(yōu)化容錯(cuò)算法基于應(yīng)用的QoS技術(shù)基于應(yīng)用的QoS的本質(zhì)還是QoS，不同的是前者增加了一項(xiàng)功能：識(shí)別應(yīng)用。在識(shí)別應(yīng)用的根底上，對(duì)不同的應(yīng)用進(jìn)行標(biāo)識(shí)，然后基于不同的標(biāo)志對(duì)不同的應(yīng)用作不同的QoS處理，就是基于應(yīng)用的QoS技術(shù)的意義。應(yīng)用識(shí)別WAAM識(shí)別應(yīng)用的范圍包括以下幾個(gè)方面：預(yù)定義的應(yīng)用識(shí)別支持60種預(yù)定義的應(yīng)用識(shí)別，保存全部統(tǒng)計(jì)信息支持266種預(yù)定義的應(yīng)用識(shí)別，保存簡(jiǎn)要信息支持50種自定義的應(yīng)用識(shí)別，定義內(nèi)容包括：IP地址和端口號(hào)TOS/COS入方向或是出方向7層應(yīng)用識(shí)別，包括：HTTP地址，URL，MIME等等Citrix發(fā)布的應(yīng)用，客戶端名稱等等另外，WAAM還能監(jiān)控所有應(yīng)用的歷史統(tǒng)計(jì)數(shù)據(jù)。QoS處理WAAM對(duì)不同的應(yīng)用做不同的QoS處理，主要包括以下幾個(gè)方面：識(shí)別應(yīng)用后，指定應(yīng)用的優(yōu)先級(jí)根據(jù)應(yīng)用的優(yōu)先級(jí)，改變報(bào)