優(yōu)先級(jí)劃分
　　因?yàn)閿?shù)據(jù)包必須排隊(duì)通過(guò)WAN傳輸，因此，給實(shí)時(shí)流量劃分優(yōu)先級(jí)，以便盡量減小時(shí)延非常重要。如果數(shù)據(jù)量大，幾百毫秒的時(shí)延根本算不了什么; 如果是互動(dòng)性很強(qiáng)的流量—特別是語(yǔ)音或?qū)崟r(shí)視頻，時(shí)延過(guò)大就意味著服務(wù)是無(wú)法接受的。再有，要想提供始終如一的服務(wù)級(jí)別，還必須避免時(shí)延變化（即抖動(dòng)）。
　　所以有必要在面向WAN的路由器接口上實(shí)施嚴(yán)格的優(yōu)先級(jí)隊(duì)列機(jī)制，無(wú)論路由器是在中心站點(diǎn)還是在分支機(jī)構(gòu)或者遠(yuǎn)地辦公室。這種機(jī)制往往名為低時(shí)延隊(duì)列（LLQ），能夠?yàn)槟惴峙浔绕渌�所有�?duì)列優(yōu)先享受服務(wù)的權(quán)利：只要該隊(duì)列里面有數(shù)據(jù)包，就會(huì)被優(yōu)先傳輸。
　　正由于這個(gè)原因，說(shuō)到從總流量中劃分多少流量以便進(jìn)入優(yōu)先級(jí)隊(duì)列，就有一些設(shè)計(jì)準(zhǔn)則。優(yōu)先流量最高不得超過(guò)總流量的30%，也就是說(shuō)，高優(yōu)先級(jí)流量占鏈路總流量的比率不應(yīng)當(dāng)超過(guò)三分之一。因?yàn)槿绻�超過(guò)了該比率，等待接受程序調(diào)度的其他流量就可能輪不到由應(yīng)用軟件來(lái)處理。還有，也不應(yīng)該把過(guò)多的數(shù)據(jù)包塞在嚴(yán)格的優(yōu)先級(jí)隊(duì)列中排隊(duì)等候，否則同樣會(huì)遇到末端站所無(wú)法忍受的延遲。
鏈路分段
　　即使有了這種優(yōu)先級(jí)劃分，如果WAN鏈路速率低，你仍可能發(fā)現(xiàn)高優(yōu)先級(jí)數(shù)據(jù)包會(huì)遇到無(wú)法接受的延遲。譬如說(shuō)，假設(shè)調(diào)度程序檢查嚴(yán)格優(yōu)先級(jí)隊(duì)列后，發(fā)現(xiàn)什么也沒(méi)有，它就會(huì)移到下一個(gè)數(shù)據(jù)隊(duì)列，開(kāi)始把數(shù)據(jù)包撤出隊(duì)列，通過(guò)路由器接口傳輸出去。如果開(kāi)始傳輸該數(shù)據(jù)包1ms后，高優(yōu)先級(jí)數(shù)據(jù)包進(jìn)入嚴(yán)格優(yōu)先級(jí)隊(duì)列，而它必須等到正在接受處理的數(shù)據(jù)包傳輸完畢—路由器不會(huì)傳到一半就停下來(lái)，而這帶來(lái)的影響可能會(huì)超乎你當(dāng)初的設(shè)想。
　　譬如說(shuō)，1500字節(jié)的文件數(shù)據(jù)包在64Kbps的租用線路上傳輸，通過(guò)物理介質(zhì)串行傳輸出去大概需要190ms。也就是說(shuō)，嚴(yán)格優(yōu)先級(jí)隊(duì)伍中的數(shù)據(jù)包可能要等這么久才能發(fā)送出去，更不用說(shuō)數(shù)據(jù)包處理、抖動(dòng)緩沖器等因素帶來(lái)的其他各種延遲。如果是語(yǔ)音數(shù)據(jù)包，語(yǔ)音抖動(dòng)會(huì)非常明顯（ITU-T的設(shè)計(jì)準(zhǔn)則建議端到端時(shí)延不能超過(guò)150ms）。
　　所以，你要實(shí)施鏈路分段和交叉（LFI），這項(xiàng)技術(shù)可以確保大容量數(shù)據(jù)包由路由器細(xì)分成多個(gè)片段，每個(gè)片段只需少量特定的時(shí)間來(lái)傳輸，通常是10ms。在另一端，接收路由器將重新組裝片段。這樣一來(lái)，數(shù)據(jù)包片段就可以同優(yōu)先級(jí)較高的數(shù)據(jù)包交叉在一起，以便后者無(wú)須在隊(duì)列中排隊(duì)等候。
　　如果WAN鏈路的速率在1Mbps及以上，用不著考慮配置LFI，因?yàn)闊o(wú)論怎樣，即使容量再大的數(shù)據(jù)包也可以在10ms之內(nèi)傳輸完畢。不過(guò)對(duì)于無(wú)力為辦公室提供高帶寬鏈路的企業(yè)而言，就應(yīng)當(dāng)在WAN路由器上配置LFI。
鏈路優(yōu)化
　　正因?yàn)閃AN帶寬很寶貴，你可能想進(jìn)行某種程度的優(yōu)化。這往往跟IP語(yǔ)音有關(guān)，因?yàn)樗�主要是一些有效載荷較小的數(shù)據(jù)包，不過(guò)也有可能包括視頻。在少數(shù)情況下，優(yōu)化還適用于容量較小的數(shù)據(jù)包。
　　你把語(yǔ)音數(shù)據(jù)包封裝成IP格式后，其實(shí)也就添加了針對(duì)UDP、IP和RTP（實(shí)時(shí)協(xié)議）的三個(gè)報(bào)頭。通常，一個(gè)語(yǔ)音數(shù)據(jù)包會(huì)包括20個(gè)字節(jié)的語(yǔ)音載荷流量和40個(gè)字節(jié)的這三個(gè)報(bào)頭，這樣就不利于充分發(fā)揮網(wǎng)絡(luò)的利用效率。
　　所幸，40個(gè)字節(jié)的報(bào)頭信息可以利用壓縮RTP（cRTP）“壓縮”成2～4個(gè)字節(jié)。因?yàn)閷?duì)每個(gè)信息流而言，這些報(bào)頭里面的變化其實(shí)非常小。這顯然提高了數(shù)據(jù)傳輸效率，并且可以把G.729a呼叫（8K語(yǔ)音）所需的帶寬從24Kbps減小到12K～14Kbps左右。即便是容量較大（譬如256字節(jié)）的非語(yǔ)音數(shù)據(jù)包，也可以把帶寬節(jié)省10%以上。
　　最后，還需要注意兩點(diǎn)：cRTP占用相當(dāng)數(shù)量的CPU資源，所以盡管它適用于少許流量，但如果速率較高的WAN上有多路呼叫，cRTP并非上佳選擇，因?yàn)槁酚善骱芸赡芴幚聿涣�。另外，cRTP通過(guò)逐跳法（hop-by-hop）加以實(shí)現(xiàn)，所以可能不適合所有WAN環(huán)境。
　　總結(jié)起來(lái)，要充分利用WAN帶寬，就少不了為互動(dòng)流量支持嚴(yán)格優(yōu)先級(jí)確定方案的路由器。至于速率不到1Mbps的WAN連接，為了提高鏈路效率，你還必須配置LFI，可能還要配置cRTP。

計(jì)算機(jī)世界網(wǎng)(www.ccw.com.cn)