吳超，段桂華，黃俊杰，黃家瑋，馬宇超，呂清嬌

(1. 中南大學(xué) 信息科學(xué)與工程學(xué)院，湖南 長沙，410083；2. 中國人民解放軍75660 部隊(duì)，廣西 桂林，541002)

隨著網(wǎng)絡(luò)技術(shù)的發(fā)展和網(wǎng)絡(luò)應(yīng)用的普及，對網(wǎng)絡(luò)性能的需求也越來越高，主要表現(xiàn)在速度要求、存儲開銷和通信代價(jià)等方面。基于這種需求，各網(wǎng)絡(luò)公司和研究單位紛紛投入大量人力物力以尋求提高帶寬利用率以及用戶體驗(yàn)的解決方案[1]。其中，廣域網(wǎng)加速方案是研究熱點(diǎn)。這是因?yàn)槟壳胺植际狡髽I(yè)增多，企業(yè)分支與公司總部之間的網(wǎng)絡(luò)建設(shè)不斷完善，很多企業(yè)傾向于建設(shè)集中的數(shù)據(jù)中心，使得跨網(wǎng)段的使用廣域網(wǎng)作為傳輸網(wǎng)絡(luò)的異地海量數(shù)據(jù)存取逐漸普遍。為了解決廣域網(wǎng)中由于帶寬限制和高時(shí)延造成的數(shù)據(jù)中心訪問速度低的問題，近年來，涌現(xiàn)出一大批加速設(shè)備廠商如Cisco[2]，Riverbed[3]，Juniper[4]及深信服[5]和QuickBi[6]等。采用的加速策略主要有傳輸協(xié)議優(yōu)化、數(shù)據(jù)優(yōu)化和應(yīng)用協(xié)議優(yōu)化[7]，相應(yīng)的技術(shù)主要有擁塞控制、數(shù)據(jù)緩存、數(shù)據(jù)壓縮和數(shù)據(jù)預(yù)取等[8]。數(shù)據(jù)庫是信息系統(tǒng)的基礎(chǔ)，擔(dān)負(fù)著保存單位核心數(shù)據(jù)的重要使命，國內(nèi)外基于數(shù)據(jù)庫的企業(yè)辦公自動化系統(tǒng)遍布各行各業(yè)，其擁有極為廣泛的用戶群體。Microsoft Project 是目前國際上最為盛行與通用的項(xiàng)目管理軟件，適用于新產(chǎn)品研發(fā)、IT、房地產(chǎn)、工程、大型活動等多種項(xiàng)目類型[9]。Microsoft Project 用戶通過客戶端直接訪問服務(wù)器所連接的數(shù)據(jù)庫，利用MS-SQL TDS(tabular data stream)協(xié)議進(jìn)行數(shù)據(jù)庫讀取、存儲或更新項(xiàng)目。MS-SQL TDS 是微軟開發(fā)的一個(gè)應(yīng)用層協(xié)議，用于SQL Server 數(shù)據(jù)庫與客戶端之間的通信。作為一種建立在TCP/IP Net-Library 之上的數(shù)據(jù)傳輸協(xié)議，TDS描述了客戶端與服務(wù)器之間數(shù)據(jù)傳輸?shù)囊?guī)則、數(shù)據(jù)類型以及消息傳輸?shù)闹刃騕10]。雖然MS-SQL TDS能保證客戶端直接與數(shù)據(jù)庫進(jìn)行通信，但在廣域網(wǎng)環(huán)境下，由于會受到低帶寬和高延遲的局限，TDS 的傳輸性能急劇下降，進(jìn)而會對整個(gè)協(xié)作環(huán)境造成影響，成為項(xiàng)目運(yùn)行的瓶頸[11]。在目前已有的協(xié)議加速策略中，研究得比較多的是傳輸協(xié)議TCP[12-13]。在應(yīng)用層協(xié)議中，有針對通用Internet 文件系統(tǒng)CIFS[14]和郵件應(yīng)用程序接口MAPI[15]等協(xié)議的加速策略研究，但對于數(shù)據(jù)庫協(xié)議，暫時(shí)還沒有很好的加速方案。為此，本文作者研究針對TDS 協(xié)議的加速目標(biāo)，提出有效可行的解決方案，以提高數(shù)據(jù)中心的訪問速度，并為其他數(shù)據(jù)庫協(xié)議的加速方法研究提供參考。

1 TDS 協(xié)議分析

表格格式數(shù)據(jù)流協(xié)議(TDS 協(xié)議)是微軟公司的SQL Server 數(shù)據(jù)庫服務(wù)端與客戶端所遵循的通信協(xié)議，是一種請求與響應(yīng)模式的應(yīng)用層協(xié)議。由于TDS會話是建立在TCP 之上的[13]，這意味著當(dāng)TCP 連接建立并且服務(wù)器收到客戶端建立TDS 連接的請求數(shù)據(jù)包時(shí)，TDS 會話將會被建立，并一直持續(xù)到TCP連接終止。一旦TCP 長連接成功建立，TDS 消息將會在客戶端與服務(wù)器之間進(jìn)行傳輸。由于TDS 建立在TCP 之上，所以，TDS 的數(shù)據(jù)是可靠的、按序到達(dá)的。

1.1 TDS 協(xié)議頭分析

通過對捕獲到的數(shù)據(jù)包分析發(fā)現(xiàn)，TDS 存在公共包頭，它是不同類型的數(shù)據(jù)包所共有的包頭，也是識別TDS 數(shù)據(jù)包的唯一標(biāo)準(zhǔn)。TDS 公共包頭長8 字節(jié)，其具體結(jié)構(gòu)如圖1 所示。

圖1 中，type(1 Byte)標(biāo)識TDS 消息類型，常用消息類型的含義如表1 所示；status(1 Byte)定義為TDS消息的狀態(tài)；length(2 Byte)表示應(yīng)用層數(shù)據(jù)長度；channel(2 Byte)傳遞服務(wù)器與客戶端的進(jìn)程ID；packnum(1 Byte)表示數(shù)據(jù)包序號；windows(1 Byte)表示在確認(rèn)信息收到以前必須發(fā)送的框架數(shù)目。

表1 type 字段的值及其含義Table 1 Values and descriptions of type field

1.2 RPC 消息分析

TDS 協(xié)議頭之后封裝了數(shù)據(jù)段，也稱為消息。如表1 所示，消息有多種類型，不同的消息完成不同的功能。其中，與優(yōu)化相關(guān)的是RPC(remote procedure call)消息。

RPC 消息的type 字段值為0x03，客戶端通過發(fā)送一系列的RPC 請求到服務(wù)器上，并在服務(wù)器上執(zhí)行，服務(wù)器將執(zhí)行結(jié)果返回給客戶端。其中，RPC 請求信息包含了RPC 的具體信息，包括存儲過程的編號、選項(xiàng)標(biāo)志位以及每個(gè)存儲過程所需要的參數(shù)。每個(gè)RPC 請求必須包含1 個(gè)單獨(dú)的SQL 語句，而不能攜帶其他的SQL 語句，其完整結(jié)構(gòu)如圖2 所示。其中：procedure name length(2 Byte)表示存儲過程名稱的長度；stored procedure id(2 Byte)表示存儲過程對應(yīng)的ID。parameters 字段為存儲過程所攜帶的參數(shù)字段，具體參數(shù)的結(jié)構(gòu)如圖3 所示。

圖2 RPC Request Data 結(jié)構(gòu)Fig.2 Structure of RPC request data

圖3 RPC 參數(shù)結(jié)構(gòu)Fig.3 Structure of RPC Parameters

圖3 中：name length(1 byte)表示參數(shù)名字的長度；status flags(1 byte)表示狀態(tài)標(biāo)志位；type info(2 Byte)表示類型信息，它的值決定了value 字段的值。

1.3 文件傳輸交互分析

TDS 協(xié)議交互過程包括預(yù)登錄、登錄、文件傳輸以及斷開連接這4 步，這里重點(diǎn)介紹可優(yōu)化的文件傳輸交互流程。

在已登錄狀態(tài)下，TDS 客戶端等待來自上層應(yīng)用的通知。若上層應(yīng)用需要從服務(wù)器上傳或下載文件，則客戶端進(jìn)入發(fā)送客戶端請求狀態(tài)并發(fā)送第1 個(gè)請求。在該狀態(tài)下，客戶端將會在正確識別服務(wù)器的響應(yīng)后發(fā)送請求。若上層應(yīng)用想取消剛發(fā)出去的請求，則客戶端將會發(fā)送1 個(gè)注意消息請求，并進(jìn)入發(fā)送注意消息狀態(tài)。

在發(fā)送注意消息狀態(tài)下，若客戶端能夠識別服務(wù)器發(fā)來的Attention 確認(rèn)并且其結(jié)構(gòu)合法有效，則客戶端會丟棄該確認(rèn)包中的所有數(shù)據(jù)，并向上層應(yīng)用提交對該確認(rèn)包處理的完成，說明發(fā)送Attention 數(shù)據(jù)請求的原因，然后重新進(jìn)入已登錄狀態(tài)。文件傳輸?shù)耐暾换ミ^程如圖4 所示。

在客戶端進(jìn)入發(fā)送客戶端請求狀態(tài)后，若并未取消請求，則開始進(jìn)入文件傳輸RPC 交互階段，主要包括文件格式傳輸和文件內(nèi)容傳輸。此時(shí)協(xié)議交互以RPC 類型數(shù)據(jù)包為主，并且RPC 交互呈現(xiàn)了一定的規(guī)律，其典型交互過程如圖5 所示。

首先客戶端發(fā)送攜帶有存儲過程ID 號為5 的RPC 請求至服務(wù)器，以獲取下一個(gè)存儲過程ID 號為7的句柄和內(nèi)容游標(biāo)；然后，在收到并正確識別RPC 響應(yīng)后，客戶端發(fā)送攜帶有存儲過程ID 號為7 的RPC請求至服務(wù)器，以獲取內(nèi)容游標(biāo)所指向的內(nèi)容；最后，在收到并正確識別RPC 響應(yīng)后，客戶端發(fā)送攜帶有存儲過程ID 號為9 的RPC 請求至服務(wù)器，關(guān)閉該內(nèi)容游標(biāo)。若需要開始下一個(gè)任務(wù)，則客戶端在完成ID為7 的過程交互之后，會發(fā)送攜帶有存儲過程ID 號為14 和15 的RPC 請求，前者獲取下一條任務(wù)的信息，后者通告這條任務(wù)的信息傳輸已經(jīng)完成，可以進(jìn)入下一條信息的傳輸過程。

2 TDS 加速策略的設(shè)計(jì)

在對TDS 協(xié)議的數(shù)據(jù)包頭以及協(xié)議交互過程詳細(xì)分析的基礎(chǔ)上，提出基于數(shù)據(jù)預(yù)取的TDS 加速策略，并結(jié)合流量控制和內(nèi)存池技術(shù)提升加速效果。

2.1 基于數(shù)據(jù)預(yù)取的加速策略

為了減少TDS 協(xié)議頻繁的交互，采用數(shù)據(jù)預(yù)取技術(shù)的加速策略，以提升TDS 數(shù)據(jù)傳輸?shù)男阅?。采用?shù)據(jù)預(yù)取加速策略的文件傳輸交互協(xié)議，如圖6 所示。在T1時(shí)刻，客戶端發(fā)起請求，客戶端和服務(wù)器網(wǎng)關(guān)轉(zhuǎn)發(fā)請求。服務(wù)器在T2時(shí)刻接受到請求并將結(jié)果發(fā)送給客戶端。在T3時(shí)刻，結(jié)果到達(dá)服務(wù)器網(wǎng)關(guān)后，網(wǎng)關(guān)將結(jié)果轉(zhuǎn)發(fā)的同時(shí)開啟預(yù)取，服務(wù)器通過服務(wù)器網(wǎng)關(guān)將請求數(shù)據(jù)發(fā)送給客戶端網(wǎng)關(guān)，客戶端網(wǎng)關(guān)將所接受到的數(shù)據(jù)進(jìn)行緩存。因此，當(dāng)客戶端在T4時(shí)刻接收到T1時(shí)的處理結(jié)果并在T5時(shí)刻產(chǎn)生下一個(gè)請求時(shí)，其結(jié)果已經(jīng)到達(dá)客戶端，這極大地減少了客戶端與服務(wù)器的交互次數(shù)?？蛻舳说挠脩舨槐卦偃ダ速M(fèi)時(shí)間等待數(shù)據(jù)到來，性能得到大幅度提升。

圖4 文件傳輸交互圖Fig.4 Interaction diagram of transfer

圖5 文件傳輸中RPC 交互圖Fig.5 RPC interaction diagram of file transfer

圖6 采用預(yù)取技術(shù)的文件傳輸交互圖Fig.6 Interaction diagram of prefetch

2.2 流量控制技術(shù)

雖然采用數(shù)據(jù)預(yù)取可以實(shí)現(xiàn)對TDS 協(xié)議的加速，而客戶端必須對預(yù)取的數(shù)據(jù)進(jìn)行緩存，但由于緩存有限，不可能無止境地對數(shù)據(jù)進(jìn)行緩存，必須對數(shù)據(jù)量進(jìn)行合理控制。

假設(shè)雙邊網(wǎng)關(guān)上的緩存為B(雙邊網(wǎng)關(guān)上緩存大小設(shè)置相同)，廣域網(wǎng)延時(shí)設(shè)置為K，實(shí)際吞吐量為M，客戶端或者服務(wù)器的一次性發(fā)送的數(shù)據(jù)塊字節(jié)為P，客戶端服務(wù)器一次性發(fā)送數(shù)據(jù)包個(gè)數(shù)為N，則有

在客戶端與服務(wù)器交互的過程中，客戶端發(fā)送請求后，必須等待服務(wù)器返回的響應(yīng)，在正確接收到響應(yīng)以后才能繼續(xù)發(fā)送請求。頻繁的交互會受到廣域網(wǎng)高延遲的嚴(yán)重影響導(dǎo)致性能降低，故采用加速代理后，可在代理客戶端上進(jìn)行數(shù)據(jù)預(yù)取，將數(shù)據(jù)提前取回。式(1)中N 則實(shí)際表示可預(yù)取的最大的數(shù)據(jù)包個(gè)數(shù)，吞吐量M 可以通過網(wǎng)關(guān)測量獲取，N 作為閾值在代理客戶端和服務(wù)器上設(shè)置計(jì)數(shù)器即可實(shí)現(xiàn)流量控制。

2.3 內(nèi)存池技術(shù)

內(nèi)存池技術(shù)是應(yīng)用程序通過調(diào)用系統(tǒng)內(nèi)存管理分配函數(shù)為程序申請一塊足夠大的內(nèi)存，此后應(yīng)用程序需要開辟內(nèi)存時(shí)，均從這塊大內(nèi)存中獲取，從而避免了頻繁地申請系統(tǒng)內(nèi)存，提升程序的性能。本系統(tǒng)中需要頻繁地申請內(nèi)存來構(gòu)建數(shù)據(jù)包，因此，使用內(nèi)存池技術(shù)提升效率，從而提升加速效果。

根據(jù)內(nèi)存池中對申請內(nèi)存變化進(jìn)行劃分，可分為固定內(nèi)存池和動態(tài)內(nèi)存池。固定內(nèi)存池分配的內(nèi)存均是固定的，而動態(tài)內(nèi)存池分配的內(nèi)存是動態(tài)變化的。在本系統(tǒng)中，因?yàn)樾枰l繁構(gòu)造數(shù)據(jù)包，故需要頻繁申請內(nèi)存，而數(shù)據(jù)包的大小并不一致，所以，綜合使用這2 種內(nèi)存池。系統(tǒng)通過對申請內(nèi)存的判斷來決定是固定內(nèi)存還是動態(tài)內(nèi)存來進(jìn)行分配，這樣只需在系統(tǒng)啟動時(shí)申請1 次內(nèi)存就能滿足程序的需要，使得加速效果達(dá)到最佳。其分配方式如圖7 所示。

圖7 內(nèi)存池結(jié)構(gòu)Fig.7 Structure of memory pool

3 AcTDS 的設(shè)計(jì)與實(shí)現(xiàn)

基于提出的TDS 加速策略，設(shè)計(jì)和實(shí)現(xiàn)1 個(gè)TDS加速系統(tǒng)AcTDS，并對系統(tǒng)的網(wǎng)絡(luò)拓?fù)?、總體結(jié)構(gòu)的設(shè)計(jì)以及功能實(shí)現(xiàn)進(jìn)行闡述。

3.1 系統(tǒng)部署圖

系統(tǒng)詳細(xì)的網(wǎng)絡(luò)結(jié)構(gòu)如圖8 所示。其中，加速系統(tǒng)AcTDS 的代理客戶端部署在企業(yè)局域網(wǎng)出口的網(wǎng)關(guān)(圖8 中Gateway(C))上，公司內(nèi)所有主機(jī)必須通過此網(wǎng)關(guān)才能夠連接Internet；而AcTDS 代理服務(wù)器則部署在企業(yè)數(shù)據(jù)中心的出口網(wǎng)關(guān)(圖8 中Gateway(S))上，這樣無論任何1 個(gè)分公司的局域網(wǎng)內(nèi)的任何1 臺主機(jī)通過Project 客戶端在跨廣域網(wǎng)訪問企業(yè)總部中的數(shù)據(jù)中心時(shí)，都能夠得到加速。

圖8 系統(tǒng)網(wǎng)絡(luò)拓?fù)銯ig.8 Network topology of system

3.2 系統(tǒng)功能結(jié)構(gòu)

AcTDS 包括代理客戶端與代理服務(wù)器?？蛻舳伺c服務(wù)器的功能模塊主要有數(shù)據(jù)包識別模塊、數(shù)據(jù)包解析模塊、數(shù)據(jù)預(yù)取模塊、數(shù)據(jù)包重組模塊、數(shù)據(jù)包緩存模塊共5 個(gè)模塊。

3.2.1 數(shù)據(jù)包識別模塊

數(shù)據(jù)包識別模塊的功能是在所有經(jīng)過網(wǎng)關(guān)的數(shù)據(jù)包中準(zhǔn)確識別出TDS 數(shù)據(jù)包，并遞交給數(shù)據(jù)包解析模塊進(jìn)行處理。而正確識別數(shù)據(jù)是協(xié)議加速的基礎(chǔ)。

本文采用端口識別與行為分析2 種方式來保障協(xié)議數(shù)據(jù)包識別的準(zhǔn)確性。SQL Server 在進(jìn)行通信時(shí)，所占用的端口是1433，因此，在網(wǎng)關(guān)的配置文件中對監(jiān)聽端口進(jìn)行配置，使加速網(wǎng)關(guān)只捕獲通過1433 端口的數(shù)據(jù)流，從而過濾掉其他數(shù)據(jù)包。其次，對數(shù)據(jù)包初步過濾之后，再通過傳輸數(shù)據(jù)包中的應(yīng)用層字段規(guī)律或者獨(dú)有的特征進(jìn)行再次分析確認(rèn)。

3.2.2 數(shù)據(jù)包解析與重組模塊

在加速過程中，通過數(shù)據(jù)包識別模塊識別出所有TDS 的數(shù)據(jù)包。然而，TDS 存在多種消息結(jié)構(gòu)，必須解析出每一個(gè)數(shù)據(jù)包所屬類型才能進(jìn)行下一步操作。在數(shù)據(jù)查詢加速中，代理客戶端發(fā)起數(shù)據(jù)預(yù)取，在獲取服務(wù)器返回的響應(yīng)后，通過對響應(yīng)進(jìn)行解析，從特定的響應(yīng)中獲取偽造下一個(gè)請求命令所需要句柄、游標(biāo)ID 等信息。

此外，在數(shù)據(jù)查詢加速和數(shù)據(jù)更新加速中都會存在大數(shù)據(jù)傳輸。在大數(shù)據(jù)傳輸過程中，對捕獲到的數(shù)據(jù)塊進(jìn)行分析，由于黏包(由1 個(gè)完整數(shù)據(jù)包和下1 個(gè)數(shù)據(jù)包中的部分內(nèi)容組成)和斷包(只含有1 個(gè)完整數(shù)據(jù)包的部分內(nèi)容)的現(xiàn)象存在，必須對接收到的數(shù)據(jù)進(jìn)行拆分和重組，重新整合成單個(gè)完整的數(shù)據(jù)包。通過解析模塊對數(shù)據(jù)進(jìn)行特征識別，獲取每個(gè)完整數(shù)據(jù)包的真實(shí)長度，根據(jù)長度進(jìn)行重新組包。

3.2.3 數(shù)據(jù)包預(yù)取模塊

數(shù)據(jù)包預(yù)取模塊根據(jù)解析模塊識別出的特征，偽造命令，從客戶端或者服務(wù)器提前取回?cái)?shù)據(jù)。在數(shù)據(jù)查詢加速中，預(yù)取模塊偽造客戶端的請求命令，發(fā)送偽造的TDS 請求數(shù)據(jù)包至數(shù)據(jù)庫服務(wù)器，提前獲取服務(wù)器的響應(yīng)數(shù)據(jù)，并將響應(yīng)數(shù)據(jù)包發(fā)送至客戶端網(wǎng)關(guān)；而在數(shù)據(jù)更新加速中，偽造服務(wù)器響應(yīng)，發(fā)送偽造的TDS 響應(yīng)數(shù)據(jù)包至客戶端，提前獲取客戶端的數(shù)據(jù)，并將數(shù)據(jù)發(fā)送至服務(wù)器網(wǎng)關(guān)。

3.2.4 數(shù)據(jù)包緩存模塊

由于數(shù)據(jù)包預(yù)取是一種預(yù)先處理的操作，而客戶端請求按順序發(fā)出的，因此，存在請求沒有發(fā)出而數(shù)據(jù)已到達(dá)的現(xiàn)象。針對這種現(xiàn)象，采用通過構(gòu)建動態(tài)緩存隊(duì)列，對預(yù)取數(shù)據(jù)進(jìn)行緩存的方法進(jìn)行處理，只有在網(wǎng)關(guān)獲得請求之后才會發(fā)出對應(yīng)數(shù)據(jù)包。

3.3 系統(tǒng)模塊實(shí)現(xiàn)

AcTDS 包括代理客戶端與代理服務(wù)器，分別從數(shù)據(jù)更新和數(shù)據(jù)查詢2 方面進(jìn)行加速。AcTDS 在交互過程中智能判斷交互過程是數(shù)據(jù)查詢還是數(shù)據(jù)更新。根據(jù)請求特征，代理客戶端和服務(wù)器會針對不同操作開啟相應(yīng)的模式?？蛻舳撕头?wù)器網(wǎng)關(guān)的流程圖如圖9所示。

圖9 客戶端和服務(wù)器網(wǎng)關(guān)流程圖Fig.9 Flow charts of client and server gateway

3.3.1 客戶端加速

代理客戶端在數(shù)據(jù)查詢加速下，將開啟請求緩存模式。監(jiān)聽后續(xù)到達(dá)網(wǎng)卡的數(shù)據(jù)包，見圖9(a)。若是客戶端發(fā)來請求，則攔截請求，通過特征判斷，將緩存隊(duì)列中的數(shù)據(jù)準(zhǔn)確地發(fā)送給客戶端；若是服務(wù)器網(wǎng)關(guān)發(fā)來數(shù)據(jù)，則先進(jìn)行數(shù)據(jù)包拆分重組，將完整單一的數(shù)據(jù)包緩存在隊(duì)列中，等到客戶端的請求到達(dá)之后，將數(shù)據(jù)發(fā)送給客戶端的同時(shí)攔截回復(fù)。而在數(shù)據(jù)更新加速下，將開啟響應(yīng)預(yù)取模式，代理客戶端將客戶端數(shù)據(jù)發(fā)給服務(wù)器端的同時(shí)，偽造回復(fù)發(fā)送給客戶端，以使客戶端將后續(xù)數(shù)據(jù)繼續(xù)發(fā)送給服務(wù)器而不必等待真實(shí)的服務(wù)器回復(fù)。

3.3.2 服務(wù)端加速

代理服務(wù)器端在數(shù)據(jù)查詢狀態(tài)下將開啟預(yù)取請求模式，如圖9(b)所示。在收到代理客戶端發(fā)送的第1條數(shù)據(jù)查詢請求之后就開始持續(xù)偽造請求，并將從服務(wù)器獲取的數(shù)據(jù)發(fā)送給代理客戶端，直到最后1 條預(yù)取命令。而在數(shù)據(jù)更新狀態(tài)下，代理服務(wù)器開啟回復(fù)攔截模式，攔截服務(wù)器在收到數(shù)據(jù)包后確認(rèn)信息。

4 系統(tǒng)測試

為了對AcTDS 系統(tǒng)的性能進(jìn)行分析，在客戶端和服務(wù)器分別安裝Microsoft Project Server 2003 及SQL Server 2005，以測試AcTDS 在各種網(wǎng)絡(luò)環(huán)境下文件傳輸?shù)男阅堋?/p>

為保證網(wǎng)絡(luò)測試環(huán)境的可控性與可再現(xiàn)性，選擇在實(shí)驗(yàn)室搭建的網(wǎng)絡(luò)實(shí)驗(yàn)測試床與實(shí)際測試相結(jié)合的方式進(jìn)行。測試床實(shí)驗(yàn)的網(wǎng)絡(luò)拓?fù)鋱D如圖10 所示。客戶端與服務(wù)器部署在不同的子網(wǎng)之間，中間通過專用的廣域網(wǎng)模擬器WANem 連接。廣域網(wǎng)模擬器對網(wǎng)絡(luò)參數(shù)如帶寬、網(wǎng)絡(luò)速度、丟包率等進(jìn)行設(shè)置來模擬真實(shí)的廣域網(wǎng)環(huán)境。

圖10 測試環(huán)境網(wǎng)絡(luò)拓?fù)鋱DFig.10 Network topology of simulation environment

在實(shí)驗(yàn)中，將初始帶寬設(shè)置為4 Mb/s，RTT 設(shè)置為30 ms，以模擬現(xiàn)實(shí)中的廣域網(wǎng)網(wǎng)絡(luò)環(huán)境。在測試過程中，對帶寬、丟包率等參數(shù)進(jìn)行梯度設(shè)置，直至網(wǎng)速限制在10 Mb/s 左右，時(shí)延在500 ms 左右。測試過程中，服務(wù)器端數(shù)據(jù)大小為2 MB，測試結(jié)果如表2所示。

從表2 可以看出：延時(shí)對數(shù)據(jù)傳輸?shù)臅r(shí)間影響很大，數(shù)據(jù)傳輸時(shí)間會隨延時(shí)的增大而顯著增大，這說明廣域網(wǎng)的高延時(shí)會使得遠(yuǎn)程訪問數(shù)據(jù)庫的效率非常低。雖然加速后的傳輸時(shí)間也會有隨時(shí)延的增加有一定提高，但加速比也會隨時(shí)延增加而增大，可達(dá)到7.08。其原因在于TDS 加速插件通過削減協(xié)議交互次數(shù)有效削弱了高延時(shí)對協(xié)議交互的影響。

表2 模擬廣域網(wǎng)環(huán)境實(shí)驗(yàn)床測試結(jié)果Table 2 Simulation results based on WANem

此外，帶寬的增長對于數(shù)據(jù)傳輸?shù)臅r(shí)間并沒有太大影響，因?yàn)閭鬏斔俾蕸]有達(dá)到帶寬上限。以時(shí)延為30 ms、帶寬為4 Mb/s 的測試結(jié)果為例，加速后傳輸速率為2.57 Mb/s，未達(dá)到帶寬上限，繼續(xù)增加帶寬無法提升加速性能。因此，按照目前4 Mb/s 帶寬的常用網(wǎng)絡(luò)帶寬，主要影響還是在于延時(shí)。加速系統(tǒng)減少了交互次數(shù)，從而使得傳輸性能得到大大地提升，提高了帶寬的利用率。

5 結(jié)論

1) 在對MS-TDS 協(xié)議深入分析的基礎(chǔ)上，提出了一種有效的TDS 協(xié)議加速策略，并在Linux 網(wǎng)關(guān)平臺下實(shí)現(xiàn)了一個(gè)功能完備、性能良好、可擴(kuò)展的TDS 加速系統(tǒng)AcTDS。

2)AcTDS 在各種網(wǎng)絡(luò)環(huán)境下都能夠?qū)DS 進(jìn)行有效加速。

3)AcTDS 具有良好的可擴(kuò)展性。本文的研究成果可應(yīng)用到Oracle，MySQL 和DB2 等數(shù)據(jù)庫的協(xié)議加速方法研究中。雖然這些數(shù)據(jù)庫在數(shù)據(jù)通信過程中所采用的協(xié)議各不相同，但其通信過程基本上是一致的，因此，可以采用類似的加速方法提升其他數(shù)據(jù)庫協(xié)議的性能。

[1] Liu K, Lee J Y B. Mobile accelerator: A new approach to improve TCP performance in mobile data networks[C]//WCMC2011.Istanbul,Turkey,2011:2174-2180.

[2] Cisco Systems Inc. Application networking services, wide area application services(WAAS)[EB/OL]. [2013-05-20]. http://www.cisco.com/en/us/products/application-networking-services/index.html.

[3] WANSolutionWorks.Com. Riverbed optimization system(RiOS)[EB/OL]. [2013-05-20]. http://www.wansolutionworks.com/RiOS.asp

[4] Juniper networks.Technical documentation[EB/OL].[2013-05-20].https://www.juniper.net/techpubsl/.

[5] Shenzhen Sinfors Technology Co Ltd.WAN optimization[EB/OL].[2013-05-20].http://www.sangfor.com.

[6] QuickBi. WAN acceleration and WAN optimization[EB/OL].[2013-05-20].http://www.quickbi.com.cn/.

[7] Oguchi N, Abe S. Dynamic communication protocol for quick response in interactive communication[C]// IEEE/IPSJ 12th International Symposium on Applications and the Internet(SAINT).Izmir,Turkey,2012:226-231.

[8] 王建新, 王捷, 徐濤, 等. 廣域網(wǎng)加速網(wǎng)關(guān)設(shè)計(jì)與實(shí)現(xiàn)[J]. 中南大學(xué)學(xué)報(bào)(自然科學(xué)版),2012,43(10):3879-3885.WANG Jianxin, WANG Jie, XU Tao, et al. Design and implementation of WAN acceleration gateway[J]. Journal of Central South University (Science and Technology), 2012,43(10):3379-3885.

[9] Baidu Encyclopedia. Microsoft project[EB/OL]. [2013-04-20].http://baike.baidu.com/view/1155692.htm.

[10] WANG Jianxin, LI Jing, RONG liang. ARROW-WTCP: A fast transport protocol based on explicit congestion notification over wired/wireless networks[J]. Journal of Central South University of Technology,2011,18(3):800-808.

[11] Guo L, Wu H. Design and implementation of TDS protocol analyzer[C]// IEEE International Conference on Computer Science and Information Technology (ICCSIT 2009). Beijing,China,2009:633-636.

[12] 王圣, 蘇金樹.TCP 加速技術(shù)研究綜述[J]. 軟件學(xué)報(bào), 2004,15(11):1689-1699.WANG Sheng, SU Jinshu. A survey of technology for TCP acceleration[J].Journal of Software,2004,15(11):1689-1699.

[13] Huh E N, Choo H. Performance enhancement of TCP in high-speed networks[J]. Information Sciences, 2008, 178(2):352-362.

[14] Zhuang Z, Chang T Y, Sivakumar R, et al. A3: Applicationaware acceleration for wireless data networks[C]// Proceedings of the 12th annual international conference on Mobile computing and networking (MobiCom'06). California, USA, 2006:194-205.

[15] Ubik S, Friedl A, Hotmar S. Quantification of traffic burstiness with MAPI middleware[C]// CESNET Conference 2008.Prague,Czech Republic,2008:13-22.