GPRS-DT測(cè)試性能優(yōu)化

1、GPRS-D測(cè)T 試性能優(yōu)化華為技術(shù)有限公司Huawei Technologies Co., Ltd.版權(quán)所有 侵權(quán)必究All rights reserved日期修訂版本修改描述作者DateVersionDescriptionAuthor2008-1-20文檔建立莊培燦 /謝紅偉修訂記錄 Revision Record 1修訂記錄 Revision Record TOC o 1-5 h z HYPERLINK l bookmark6 o Current Document 修訂記錄 Revision Record 1 HYPERLINK l bookmark8 o Current Documen

2、t 背景 2 HYPERLINK l bookmark10 o Current Document 測(cè)試規(guī)范 2 HYPERLINK l bookmark12 o Current Document 測(cè)試軟件及終端 2 HYPERLINK l bookmark14 o Current Document DT 部分 2 HYPERLINK l bookmark16 o Current Document DT-WAP 2 HYPERLINK l bookmark18 o Current Document DT-FTP 3 HYPERLINK l bookmark20 o Current Documen

3、t 覆蓋率優(yōu)化 4 HYPERLINK l bookmark22 o Current Document 掉線優(yōu)化 4 HYPERLINK l bookmark24 o Current Document 下載速率優(yōu)化 7 HYPERLINK l bookmark30 o Current Document FTP服務(wù)器優(yōu)化 12 HYPERLINK l bookmark32 o Current Document 設(shè)置最優(yōu) MTU 值 12 HYPERLINK l bookmark34 o Current Document 關(guān)閉 Nagle算法 13 HYPERLINK l bookmark36 o

4、 Current Document 參數(shù)調(diào)整方法： 14背景GPRS 的DT測(cè)試是移動(dòng)用于衡量 GPRS 網(wǎng)絡(luò)質(zhì)量的一個(gè)重要手段， 移動(dòng)集團(tuán)公司對(duì)各個(gè) 重點(diǎn)城市網(wǎng)絡(luò)質(zhì)量檢查工作也包括 GPRS-DT 測(cè)試，此次在成都項(xiàng)目做了一些 GPRS 類的DT 優(yōu)化工作，其中積累一些經(jīng)驗(yàn)，在本文中做一個(gè)簡(jiǎn)單的總結(jié)。測(cè)試規(guī)范附件是集團(tuán)公司下發(fā)的 GPRS業(yè)務(wù)測(cè)試規(guī)范， 這個(gè)規(guī)范對(duì)于全國(guó)的 GPRS業(yè)務(wù)優(yōu)化非常具 有指導(dǎo)意義，這里不再重復(fù)引用規(guī)范的具體內(nèi)容，后面在涉及到關(guān)鍵細(xì)節(jié)再進(jìn)行闡述。測(cè)試軟件及終端一般GPRS-DT使用的測(cè)試工具是北京惠捷朗公司的 CDS3.0+SAGEM OT290 手機(jī)，該工 具不支

5、持 EDGE功能，并且迎檢只測(cè)試 GPRS性能。 SAGEM OT290 的多時(shí)隙能力為 3下行1 上行。測(cè)試軟件和測(cè)試終端的特性和最終的測(cè)試性能密切相關(guān)， 詳細(xì)內(nèi)容將在后面具體介紹。DT 部分DT測(cè)試分兩個(gè)大項(xiàng)， FTP下載和 WAP 類測(cè)試。DT-WAPWAP類測(cè)試使用“ CMWAP ”的 APN ，這類業(yè)務(wù)都必須經(jīng)過(guò)一個(gè)關(guān)鍵的網(wǎng)元WAP-GW（WAP網(wǎng)關(guān)）， WAPGW 作為協(xié)議轉(zhuǎn)換代理，其主要目的就是完成手機(jī)到網(wǎng)關(guān)之間的WAP協(xié)議到 HTTP協(xié)議轉(zhuǎn)換。手機(jī)和 WAP網(wǎng)關(guān)的協(xié)議模式有兩種： WAP1X 協(xié)議和 WAP2.0協(xié)議。 兩者的不同在于承載協(xié)議， WAP1X 承載于 UDP ，W

6、AP2.0承載于 TCP。集團(tuán)公司 2007年的網(wǎng) 絡(luò)質(zhì)量巡檢基于 WAP1X 協(xié)議進(jìn)行測(cè)試。圖1 WAP 網(wǎng)關(guān)協(xié)議DT-WAP 測(cè)試包括 WAP 登錄和圖鈴下載，其中圖鈴下載的速率在開(kāi)通CS3/4編碼的情況下，一般都能輕松達(dá)到。但 WAP 登錄和圖鈴下載成功率對(duì)于小區(qū)的無(wú)線質(zhì)量比較敏感，需 要保證各個(gè)小區(qū)的業(yè)務(wù)正常。 對(duì)于無(wú)線承載而言， WAP 和FTP優(yōu)化基本一致， 相關(guān)的優(yōu)化手 段請(qǐng)參考下面的 FTP優(yōu)化介紹。需要注意的是， WAP 類測(cè)試需要臨時(shí)關(guān)閉公司的一些信息安全軟件，例如SPES、ACC和Sygate防火墻等。下表是集團(tuán)定義的 WAP-DT 測(cè)試的健康指標(biāo)：表1 WAP 類DT測(cè)

7、試健康指標(biāo)WAP測(cè)試WAP網(wǎng)站登 陸成功率WAP首頁(yè)顯 示時(shí)間WAP網(wǎng)頁(yè)刷 新成功率WAP網(wǎng)頁(yè)刷 新時(shí)長(zhǎng)WAP圖鈴下 載成功率WAP圖鈴下 載平均速 率99.50%8.5099.50%599.50%1.6DT-FTP下表是 DT-FTP 下載測(cè)試的考核指標(biāo)在優(yōu)化前后的對(duì)比情況， 主要有三個(gè)指標(biāo)需要優(yōu)化。 包括覆蓋率、掉線次數(shù)和平均使用層吞吐率。表 2 優(yōu)化前后 DT-FTP 下載效果對(duì)比DT 測(cè)試測(cè)試 時(shí)長(zhǎng) （分 鐘）測(cè)試 里程 （公 里）速度 （ km/ h）FTP 測(cè)試無(wú)覆 蓋里 程覆蓋率嘗試 下載 次數(shù)掉線 次數(shù)掉線率平均使 用層吞 吐率 （KB/s）集團(tuán)優(yōu)秀指標(biāo)0100%002.806

8、年 12 月實(shí)測(cè)265.9133.430.120100%269003.35第一輪測(cè)試 1018349.6128.122.010100%93110.1182.01第二輪測(cè)試 1022438.0199.627.340100%218240.111.93第三次測(cè)試結(jié)果469.399.7%281145.00%2.28第四次測(cè)試結(jié)果222.489.524.10100%13642.90%2.21第五次測(cè)試結(jié)果291.999.5%168137.70%2.21優(yōu)化后最終測(cè)試結(jié)果444.2191.625.880100%37700.00%3.02覆蓋率優(yōu)化覆蓋率的要求

9、比較寬松，下面是判斷無(wú)GPRS覆蓋的判決條件。相對(duì)而言，覆蓋率的控制較為容易，只需要保證小區(qū)的 GPRS屬性正常。滿足以下條件之一判別為 GPRS無(wú)覆蓋里程：a. 服務(wù)小區(qū)電平低于 -94dbm 且最強(qiáng)的鄰小區(qū)電平低于 -90dbm，并持續(xù) 5 秒鐘以上的路段b. 手機(jī)的 TBF 處于關(guān)閉狀態(tài)且超過(guò) 90 秒鐘以上沒(méi)有接收到 System Info13 的路段掉線優(yōu)化FTP掉線的要求也相對(duì)比較寬松，判決條件如下。滿足以下條件之一判別為掉線：a. 網(wǎng)絡(luò)原因造成連接斷開(kāi)，以下行信令 PDP deactivate request 或 RAU reject 作為判斷依據(jù)。b. 測(cè)試過(guò)程中超過(guò) 3 分鐘

10、 FTP沒(méi)有任何數(shù)據(jù)傳輸，且嘗試 ping 后數(shù)據(jù)鏈路仍不可使用。此時(shí)應(yīng)斷開(kāi)撥 號(hào)連接并重新?lián)芴?hào)來(lái)恢復(fù)測(cè)試。有兩種場(chǎng)景會(huì)導(dǎo)致 CDS軟件判斷 FTP下載掉線。1、 長(zhǎng)時(shí)間無(wú)下載FTP下載使用 TCP 協(xié)議，在 TCP數(shù)據(jù)傳輸中，為了確保數(shù)據(jù)傳輸?shù)臏?zhǔn)確性，采用 了確認(rèn)機(jī)制：當(dāng)發(fā)送端發(fā)送一個(gè)報(bào)文（IP包）時(shí)，啟動(dòng)重傳定時(shí)器，如果定時(shí)器超時(shí)前收到接收端發(fā)送的該報(bào)文的 ACK 消息，那么復(fù)位重傳定時(shí)器，否則重傳沒(méi)有收到 ACK 的報(bào)文，具體機(jī)制如下圖所示：圖2 TCP 報(bào)文確認(rèn)機(jī)制由于 CDS軟件采用單線程模式，在 DT測(cè)試中， FTP服務(wù)器發(fā)送的報(bào)文會(huì)由于 PCU 間的小區(qū)重選丟失，導(dǎo)致服務(wù)器一直等

11、不到接收端（測(cè)試終端）的 ACK 消息，一直等 待定時(shí)器超時(shí)， 而在無(wú)線環(huán)境下的 FTP業(yè)務(wù)，發(fā)送端計(jì)算的重發(fā)定時(shí)器值較長(zhǎng) （ 10s）， 并且呈幾何指數(shù)增長(zhǎng)，重傳的時(shí)間太久；同時(shí)，接收端因?yàn)橐恢睕](méi)有接受到服務(wù)器的 數(shù)據(jù)塊，處于一直等待狀態(tài)中，不會(huì)重復(fù)發(fā)送ACK 消息，向服務(wù)器請(qǐng)求報(bào)文，這就導(dǎo)致數(shù)據(jù)傳輸一直處于中斷中。圖3 長(zhǎng)時(shí)間無(wú)數(shù)傳導(dǎo)致 FTP 下載失敗圖4 CDS 軟件無(wú)數(shù)傳時(shí) ping機(jī)制優(yōu)化措施： 優(yōu)化 FTP服務(wù)器參數(shù)配置，盡量規(guī)避這種問(wèn)題，但無(wú)法根治這種問(wèn)題。具體 見(jiàn)FTP服務(wù)器優(yōu)化部分。個(gè)別路線上的小區(qū)有可能出現(xiàn)擁塞或者故障（CS業(yè)務(wù)正常，可以正常選入）的情況，這個(gè)時(shí)候手機(jī)選入

12、這類小區(qū)就會(huì)出現(xiàn)接入不了的情況，通常表現(xiàn)為長(zhǎng)時(shí)間嘗試ping而ping 不通，持續(xù)一段時(shí)間后超時(shí)掉線。優(yōu)化措施： 保證路線上的小區(qū)各種業(yè)務(wù)正常，對(duì)于擁塞的小區(qū)增加 PDCH 信道或者調(diào)高 信道的復(fù)用深度。2、 RAU reject當(dāng)出現(xiàn) RAU reject 時(shí)，即判斷為掉線。當(dāng)網(wǎng)絡(luò)中存在兩個(gè)SGSN時(shí)，如果 DNS服務(wù)器的數(shù)據(jù)不準(zhǔn)確，很容易出現(xiàn)這樣的現(xiàn)象。圖5 RAU 失敗導(dǎo)致 FTP下載失敗下圖是跨 SGSN路由區(qū)更新時(shí)的信令流程，當(dāng) DNS的RAI 表信息不準(zhǔn)確時(shí)，在流程 3那 返回錯(cuò)誤的 SGSN IP ，導(dǎo)致 RAU reject 。圖6 跨SGSN RAU 信令流程優(yōu)化措施： 將D

13、NS服務(wù)器上的 RAI 和SGSN對(duì)應(yīng)關(guān)系進(jìn)行梳理。下載速率優(yōu)化下圖是 DT-FTP 下載速率優(yōu)化的主要控制點(diǎn)，這些關(guān)鍵控制點(diǎn)之間并不是孤立的，為了 方便敘述，將這些控制點(diǎn)進(jìn)行了分類，下面將對(duì)每個(gè)控制點(diǎn)進(jìn)行闡述。圖7 FTP 下載速率優(yōu)化關(guān)鍵控制點(diǎn)App/RLC 速率比App/RLC 速率比即使用層速率和 RLC 層速率的比值。 這個(gè)指標(biāo)反映了 Um口的質(zhì)量。 Um口的質(zhì)量主要受接收電平、 C/I 、上下行鏈路平衡的影響， Um口質(zhì)量對(duì) FTP 速率的 影響主要包括兩個(gè)方面：一個(gè)是編碼方式，另一個(gè)是空口重傳率。編碼方式越高， Um 口單信道的吞吐率就越高， Um口質(zhì)量越好，系統(tǒng)就會(huì)使用更高的編

14、碼方式，F(xiàn)TP 的吞吐率就越高； 重傳率越高， 說(shuō)明實(shí)際的有效吞吐率越低， 空口的帶寬都用在了無(wú)效的重 傳上， Um 口質(zhì)量越好，其重傳率就越低，有效的吞吐率就越高。需要注意的是， 如果測(cè)試用的便攜機(jī)系統(tǒng)沒(méi)有關(guān)閉 windows 自動(dòng)更新等自動(dòng)連接網(wǎng) 絡(luò)的系統(tǒng)進(jìn)程時(shí)， App/RLC 速率比也會(huì)比較低。這從 CDS 的網(wǎng)絡(luò)協(xié)議查看器可以比較 方便的檢查出來(lái)。優(yōu)化措施：頻率優(yōu)化PDCH 信道配置在載干比較好的載頻上，一般是 BCCH 載頻PDCH 所在載頻不參加跳頻 處理上下行不平衡小區(qū) 關(guān)閉測(cè)試使用便攜機(jī)的無(wú)關(guān)系統(tǒng)進(jìn)程， 包括不限于 windows 自動(dòng)更新、 病毒庫(kù)更新圖8 CDS 數(shù)據(jù)協(xié)議

15、察看器界面占用 PDCH信道數(shù)CDS配置測(cè)試 GPRS 的是OT290 手機(jī)，多時(shí)隙能力等級(jí)為 4，即支持 3下行 1上行。 從測(cè)試數(shù)據(jù)回放看， 在某些小區(qū)，手機(jī)一直沒(méi)有指配三個(gè)信道，導(dǎo)致速率一直不高。通 過(guò)分析配置可以發(fā)現(xiàn)， 這些小區(qū)的信道配置都是較少， 或者語(yǔ)音業(yè)務(wù)量較大， 搶占了動(dòng) 態(tài)PDCH 。優(yōu)化措施：增加 PDCH 信道數(shù)目，信道需要連續(xù)分配針對(duì) OT290 手機(jī)的多時(shí)隙能力，將信道進(jìn)行分組配置，盡量3 個(gè)一組，不同PDCH 組之間間隔一個(gè) TCH 或者 SDCCH對(duì)于話統(tǒng)中存在 BSC 回收動(dòng)態(tài) PDCH 信道次數(shù)較多的小區(qū)， 可以考慮在測(cè)試前 臨時(shí)配置靜態(tài) PDCH 信道CS4

16、使用比例CS4編碼方式在測(cè)試中使用的比例是影響速率的關(guān)鍵因素。CS4編碼方式在測(cè)試中的主要受兩個(gè)方面影響。一個(gè)是 C/I ，即重傳率，二是基站的空閑時(shí)隙配置和 RPPU板的 PCIC資源。優(yōu)化措施：關(guān)閉部分小區(qū)的 EDGE 功能，減少 PDCH 信道對(duì)空閑時(shí)隙和 PCIC 資源的消耗 配置足夠的空閑時(shí)隙(有副柜組的要分柜組分別配置)，均衡各個(gè) RPPU 單板 的PCIC 負(fù)荷每條信道預(yù)綁定兩條 PCIC ( g_ulPreConnectPcicNum )，使下行接入盡快使用 CS4 的編碼方式，命令： pcu cfg add allrppu g_ulPreConnectPcicNum 4 2

17、無(wú)線環(huán)境好的小區(qū)下行編碼方式缺省設(shè)置為 CS4 無(wú)線環(huán)境優(yōu)化避免下載斷續(xù)比較容易造成丟包的環(huán)FTP下載通路上的各個(gè)接口和網(wǎng)元都可能會(huì)導(dǎo)致下載斷續(xù)。節(jié)在跨 RPPU板小區(qū)重選、跨 PCU小區(qū)重選和 FTP服務(wù)器和 GGSN 之間的 Gi接口。 跨RPPU板小區(qū)重選時(shí)，在 PCU版本為 R08C01B014SPH002 時(shí)，板間轉(zhuǎn)發(fā)會(huì)存在丟 包現(xiàn)象，需要升級(jí)為 R08C01B014SPH007 ?？鏟CU小區(qū)重選是指小區(qū)重選前后的 PCU不一致， 這種情況下， 在原 PCU緩存的數(shù) 據(jù)將被丟棄，新的 PCU 重新到 SGSN獲取數(shù)據(jù)，這種丟包是不可避免的，只能盡量減少 跨PCU小區(qū)重選的發(fā)生次數(shù)。

18、GGSN 和FTP之間傳輸如果不穩(wěn)定，可能會(huì)導(dǎo)致 IP層丟包。判斷方法可以在 GGSN 上ping FTP服務(wù)器， ping 1000次，包大小為 500字節(jié)。如果返回的統(tǒng)計(jì)有明顯丟包時(shí)， 則需要對(duì)這之間的數(shù)通設(shè)備進(jìn)行處理。圖9 FTP 下載測(cè)試涉及網(wǎng)元及接口優(yōu)化措施：優(yōu)化 FTP 服務(wù)器設(shè)置避免核心網(wǎng)網(wǎng)元接口之間丟包確認(rèn) PCU版本不存在 RPPU 板轉(zhuǎn)發(fā)丟包問(wèn)題盡量減少跨 PCU 的小區(qū)重選次數(shù)下行 TBF Open 比例下行TBF Open比例是指測(cè)試過(guò)程中，手機(jī)處于下行TBF建立時(shí)間占所有測(cè)試時(shí)間的比例。 FTP下載速率是按照總下載數(shù)據(jù)量 /總下載時(shí)間來(lái)計(jì)算的。 如果一次下載過(guò)程中 發(fā)

19、生小區(qū)重選等行為，將會(huì)導(dǎo)致總下載時(shí)間變長(zhǎng)，最終影響下載速率統(tǒng)計(jì)。影響下行 TBF Open比例的主要有小區(qū)重選、 位置區(qū)路由區(qū)更新 （LAU RAU ）。 數(shù)據(jù)業(yè)務(wù)測(cè)試中，小區(qū)重選必然會(huì)導(dǎo)致數(shù)據(jù)傳輸中斷。因?yàn)闇y(cè)試手機(jī)不支持 NACC 等EGPRS的優(yōu)化功能， 每次小區(qū)重選固定需要 4s以上的時(shí)間來(lái)對(duì)新小區(qū)的系統(tǒng)消息進(jìn)行 解碼，才能進(jìn)行接入請(qǐng)求，如果碰到路由區(qū)，位置區(qū)更新，會(huì)浪費(fèi)更多的時(shí)間。所以減 少小區(qū)重選的次數(shù)是提高 DT 速率關(guān)鍵手段之一。LAU+RAU 更新的時(shí)間開(kāi)銷一般為 10s左右，因此避免在路測(cè)過(guò)程中發(fā)生頻繁的跨位置區(qū)重選是一個(gè)優(yōu)化手段。優(yōu)化措施：減少小區(qū)重選次數(shù)（合理控制小區(qū)重選

20、，通過(guò)合理設(shè)置相關(guān)重選參數(shù)及 BA1 表合理配置來(lái)實(shí)現(xiàn)） 減少跨 LAC 小區(qū)重選次數(shù)傳輸質(zhì)量各環(huán)節(jié)比較容易出問(wèn)題的在于 G-Abis 口。G_Abis 口包括了 Pb 接口、BSC 內(nèi)部通道、 Abis 接口以及 BTS 的內(nèi)部通道，這些通道中任何一段出現(xiàn)問(wèn)題都會(huì)導(dǎo)致G_Abis 口鏈路出現(xiàn)問(wèn)題最終導(dǎo)致 FTP速率受到影響甚至業(yè)務(wù)不能正常進(jìn)行。造成G_Abis 口鏈路出現(xiàn)問(wèn)題的主要原因有： 1）工程質(zhì)量（連線錯(cuò)誤或傳輸接頭松動(dòng)）， 2）傳輸質(zhì)量問(wèn)題（例 如某些小區(qū)的 Abis 口傳輸為衛(wèi)星鏈路或者微波鏈路） 3）基站存在自環(huán)或者故障的 Abis 口2M傳輸。需要根據(jù)具體現(xiàn)象逐步排查定位問(wèn)題。

21、對(duì)于第三種原因， 可以通過(guò)關(guān)閉小區(qū)的 EDGE 和 CS3/4 功能， 使小區(qū)的 PDCH 只使 用一條Abis的16k時(shí)隙，再觀察小區(qū)的 G-Abis 口誤幀率情況，如果有所緩解和消失，則 比較大的可能是由于故障 2M 引入的誤碼。優(yōu)化措施：排查基站的 2M 是否存在自環(huán)、故障現(xiàn)象。上述的關(guān)鍵控制點(diǎn)中， 部分可以映射為關(guān)鍵控制指標(biāo)， 各關(guān)鍵控制指標(biāo)在優(yōu)化前后的對(duì) 比情況如下表所示。表 3 各關(guān)鍵控制指標(biāo)在優(yōu)化前后的對(duì)比情況測(cè)試文 件結(jié)果空口質(zhì)量下載狀 態(tài)Um口 資源Pb資源（ 編碼使用比例)修正系數(shù)FTP下 載速 率App/RLC速率比TBFOPEN比 例下行平 均時(shí)隙 數(shù)量CS1比 例CS

22、2比 例CS3比 例CS4比 例修正 系數(shù) （復(fù) 用、重 選恢 復(fù)開(kāi) 銷）整網(wǎng)摸 底2.1375%82%2.659.00%26.00%8.00%57.00%59%二環(huán)11082.5874%83%2.6421.00%12.00%6.00%62.00%72%草金2.6889%83%2.70721.00%19.00%7.00%53.00%64%1108草金1113am2.2172%61%2.6527.00%18.00%8.00%47.00%94%草金1113pm1.6761%73%2.58520.00%11.00%9.00%60.00%66%一環(huán)11243.5993%89%2.9375.60%18.

23、50%6.10%69.70%63%二環(huán)11243.4696%84%2.9158.80%7.20%7.30%76.70%61%注：1、 經(jīng)驗(yàn)公式： FTP下載速率下行平均時(shí)隙數(shù)量 *（CS1比例*CS1 速率+CS2比例*CS2速率+CS3比例 *CS3速率+CS4比例*CS4速率）/8*TBF OPEN 比例*修正系數(shù)（復(fù)用、重選恢復(fù)開(kāi)銷）*App/RLC速率 比2、上述指標(biāo)中，除修正系數(shù)外，其余從 CDS測(cè)試軟件可以直接統(tǒng)計(jì)生成3、修正系數(shù)是經(jīng)驗(yàn)值，和復(fù)用、重選后速率恢復(fù)相關(guān)FTP 服務(wù)器優(yōu)化對(duì)于 DT下載，屬于端到端的業(yè)務(wù)，因此，作為數(shù)據(jù)發(fā)送端的FTP服務(wù)器的優(yōu)化也是提升性能的一個(gè)重要因素

24、。 這在成都測(cè)試中， 使用WINDOWS Server 2000 作為操作系統(tǒng)， Serv-u 作為 FTP服務(wù)器軟件，針對(duì)這個(gè) FTP服務(wù)器做了一些優(yōu)化措施，這里重點(diǎn)介紹兩個(gè)比較關(guān)鍵 的參數(shù)：設(shè)置最優(yōu) MTU 值MTU（ MaximumT ransmission Unit ）是指最大傳輸單元決定了下發(fā)數(shù)據(jù)包的大?。?。如 果MTU 值過(guò)小，那么會(huì)在網(wǎng)絡(luò)中進(jìn)行頻繁的封包和解包，會(huì)造成網(wǎng)絡(luò)側(cè)的延時(shí)；同樣，如 果值太大，會(huì)在網(wǎng)絡(luò)中進(jìn)行拆分重組，同樣會(huì)造成網(wǎng)絡(luò)側(cè)的延時(shí)。該參數(shù)的最優(yōu)設(shè)置需要綜合考慮 GGSN 的最大 TCP報(bào)文長(zhǎng)度和 GGSN 和 SGSN數(shù)據(jù)封裝 特性。 1500是 GGSN 和網(wǎng)關(guān)

25、等數(shù)通產(chǎn)品支持的最大包大小，但由于Ftp Server 下發(fā)的數(shù)據(jù)包送到 GGSN時(shí)，GGS將N會(huì)對(duì)其進(jìn)行 GTP的封裝然后轉(zhuǎn)發(fā)給 SGSN，GTP封裝將在 IP包上加上 40bytes 的包頭，因此 FTP服務(wù)器下發(fā)包的最優(yōu)長(zhǎng)度為 1460（有效 TCP載荷1420Byte ），在經(jīng)過(guò) GGSN 進(jìn)行 GTP封裝后，剛好為 1500，這樣可以直接通過(guò)各個(gè)數(shù)通產(chǎn)品而不需要進(jìn)行拆包。Data1500bytesGGSN1460bytesFTP圖10 GGSN 和SGSN 的GTP封裝機(jī)制關(guān)閉 Nagle 算法目前建立在 TCP協(xié)議上的網(wǎng)絡(luò)協(xié)議特別多，有 telnet ，ssh ，有ftp ，有ht

26、tp 等等。這些 協(xié)議又可以根據(jù)數(shù)據(jù)吞吐量來(lái)大致分成兩大類：(1) 交互數(shù)據(jù)類型，例如 telet ，ssh ，這種類型的協(xié)議在大多數(shù)情況下只是做小流量的數(shù)據(jù)交換， 比如說(shuō)按一下鍵盤， 回顯一些文字等 等。 (2) 數(shù) 據(jù)成塊類型，例如 ftp ，這種類型的協(xié)議要求 TCP能盡量的運(yùn)載數(shù)據(jù)，把數(shù)據(jù)的 吞吐量做到最大，并盡可能的提高效率。針對(duì)這兩種情況，TCP 給出了兩種不 同的策略來(lái)進(jìn)行數(shù)據(jù)傳輸。對(duì)于交互性要求比較高的使用， TCP 給出兩個(gè)策略來(lái)提高發(fā)送效率和減低網(wǎng)絡(luò)負(fù)擔(dān)： (1)捎帶 ACK 。(2)Nagle 算法(一次盡量多的發(fā)數(shù)據(jù))。通常，在網(wǎng)絡(luò)速度很快的情況 下，比如進(jìn)行 teln

27、et 通信，當(dāng)按下字母鍵并要求回顯的時(shí)候，客戶端和服務(wù)器將經(jīng)歷 發(fā)送 按鍵數(shù)據(jù) -服務(wù)器發(fā)送按鍵數(shù)據(jù)的 ack - 服務(wù)器端發(fā)送回顯數(shù)據(jù) - 客戶端發(fā)送回顯數(shù)據(jù) 的ACK 的過(guò)程，而其中的數(shù)據(jù)流量將是 40bit + 41bit+41bit+40bit = 162bit，如果在廣域網(wǎng)里面，這種小分組的 TCP 流量將會(huì)造成很大的網(wǎng)絡(luò)負(fù)擔(dān)。上過(guò)bbs 的人應(yīng)該都會(huì)有感受，就是在網(wǎng)絡(luò)慢的時(shí)候發(fā)貼，有時(shí)鍵入一串字符串以后， 經(jīng)過(guò)一段時(shí)間，客戶端 “發(fā)瘋 ”一樣突然回顯出很多內(nèi)容，就好像數(shù)據(jù)一下子傳過(guò)來(lái)了一樣， 這就是 Nagle 算法的作用。很顯然， 對(duì)于 FTP類型的使用， 應(yīng)該禁用 Nagle 算法。尤其在 DT測(cè)試的場(chǎng)景下， 跨PCU 的小區(qū)重選會(huì)導(dǎo)致數(shù)據(jù)丟失，在這種情況下，如果FTP 服務(wù)器下發(fā)數(shù)據(jù)不及時(shí)，會(huì)導(dǎo)致長(zhǎng)時(shí)間無(wú)下載，空口的利用率低下，影響下載速率。Serv-U 安裝后默認(rèn)采用 Nag