MS-TDS 協(xié)議加速策略的研究與實(shí)現(xiàn)

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

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

隨著網(wǎng)絡(luò)技術(shù)的發(fā)展和網(wǎng)絡(luò)應(yīng)用的普及，對(duì)網(wǎng)絡(luò)性能的需求也越來(lái)越高，主要表現(xiàn)在速度要求、存儲(chǔ)開(kāi)銷(xiāo)和通信代價(jià)等方面?；谶@種需求，各網(wǎng)絡(luò)公司和研究單位紛紛投入大量人力物力以尋求提高帶寬利用率以及用戶(hù)體驗(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ù)中心訪問(wèn)速度低的問(wèn)題，近年來(lái)，涌現(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ù)庫(kù)是信息系統(tǒng)的基礎(chǔ)，擔(dān)負(fù)著保存單位核心數(shù)據(jù)的重要使命，國(guó)內(nèi)外基于數(shù)據(jù)庫(kù)的企業(yè)辦公自動(dòng)化系統(tǒng)遍布各行各業(yè)，其擁有極為廣泛的用戶(hù)群體。Microsoft Project 是目前國(guó)際上最為盛行與通用的項(xiàng)目管理軟件，適用于新產(chǎn)品研發(fā)、IT、房地產(chǎn)、工程、大型活動(dòng)等多種項(xiàng)目類(lèi)型[9]。Microsoft Project 用戶(hù)通過(guò)客戶(hù)端直接訪問(wèn)服務(wù)器所連接的數(shù)據(jù)庫(kù)，利用MS-SQL TDS(tabular data stream)協(xié)議進(jìn)行數(shù)據(jù)庫(kù)讀取、存儲(chǔ)或更新項(xiàng)目。MS-SQL TDS 是微軟開(kāi)發(fā)的一個(gè)應(yīng)用層協(xié)議，用于SQL Server 數(shù)據(jù)庫(kù)與客戶(hù)端之間的通信。作為一種建立在TCP/IP Net-Library 之上的數(shù)據(jù)傳輸協(xié)議，TDS描述了客戶(hù)端與服務(wù)器之間數(shù)據(jù)傳輸?shù)囊?guī)則、數(shù)據(jù)類(lèi)型以及消息傳輸?shù)闹刃騕10]。雖然MS-SQL TDS能保證客戶(hù)端直接與數(shù)據(jù)庫(kù)進(jìn)行通信，但在廣域網(wǎng)環(huán)境下，由于會(huì)受到低帶寬和高延遲的局限，TDS 的傳輸性能急劇下降，進(jìn)而會(huì)對(duì)整個(gè)協(xié)作環(huán)境造成影響，成為項(xiàng)目運(yùn)行的瓶頸[11]。在目前已有的協(xié)議加速策略中，研究得比較多的是傳輸協(xié)議TCP[12-13]。在應(yīng)用層協(xié)議中，有針對(duì)通用Internet 文件系統(tǒng)CIFS[14]和郵件應(yīng)用程序接口MAPI[15]等協(xié)議的加速策略研究，但對(duì)于數(shù)據(jù)庫(kù)協(xié)議，暫時(shí)還沒(méi)有很好的加速方案。為此，本文作者研究針對(duì)TDS 協(xié)議的加速目標(biāo)，提出有效可行的解決方案，以提高數(shù)據(jù)中心的訪問(wèn)速度，并為其他數(shù)據(jù)庫(kù)協(xié)議的加速方法研究提供參考。

1 TDS 協(xié)議分析

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

1.1 TDS 協(xié)議頭分析

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

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

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

1.2 RPC 消息分析

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

RPC 消息的type 字段值為0x03，客戶(hù)端通過(guò)發(fā)送一系列的RPC 請(qǐng)求到服務(wù)器上，并在服務(wù)器上執(zhí)行，服務(wù)器將執(zhí)行結(jié)果返回給客戶(hù)端。其中，RPC 請(qǐng)求信息包含了RPC 的具體信息，包括存儲(chǔ)過(guò)程的編號(hào)、選項(xiàng)標(biāo)志位以及每個(gè)存儲(chǔ)過(guò)程所需要的參數(shù)。每個(gè)RPC 請(qǐng)求必須包含1 個(gè)單獨(dú)的SQL 語(yǔ)句，而不能攜帶其他的SQL 語(yǔ)句，其完整結(jié)構(gòu)如圖2 所示。其中：procedure name length(2 Byte)表示存儲(chǔ)過(guò)程名稱(chēng)的長(zhǎng)度；stored procedure id(2 Byte)表示存儲(chǔ)過(guò)程對(duì)應(yīng)的ID。parameters 字段為存儲(chǔ)過(guò)程所攜帶的參數(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ù)名字的長(zhǎng)度；status flags(1 byte)表示狀態(tài)標(biāo)志位；type info(2 Byte)表示類(lèi)型信息，它的值決定了value 字段的值。

1.3 文件傳輸交互分析

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

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

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

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

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

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

在對(duì)TDS 協(xié)議的數(shù)據(jù)包頭以及協(xié)議交互過(guò)程詳細(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í)刻，客戶(hù)端發(fā)起請(qǐng)求，客戶(hù)端和服務(wù)器網(wǎng)關(guān)轉(zhuǎn)發(fā)請(qǐng)求。服務(wù)器在T2時(shí)刻接受到請(qǐng)求并將結(jié)果發(fā)送給客戶(hù)端。在T3時(shí)刻，結(jié)果到達(dá)服務(wù)器網(wǎng)關(guān)后，網(wǎng)關(guān)將結(jié)果轉(zhuǎn)發(fā)的同時(shí)開(kāi)啟預(yù)取，服務(wù)器通過(guò)服務(wù)器網(wǎng)關(guān)將請(qǐng)求數(shù)據(jù)發(fā)送給客戶(hù)端網(wǎng)關(guān)，客戶(hù)端網(wǎng)關(guān)將所接受到的數(shù)據(jù)進(jìn)行緩存。因此，當(dāng)客戶(hù)端在T4時(shí)刻接收到T1時(shí)的處理結(jié)果并在T5時(shí)刻產(chǎn)生下一個(gè)請(qǐng)求時(shí)，其結(jié)果已經(jīng)到達(dá)客戶(hù)端，這極大地減少了客戶(hù)端與服務(wù)器的交互次數(shù)?？蛻?hù)端的用戶(hù)不必再去浪費(fèi)時(shí)間等待數(shù)據(jù)到來(lái)，性能得到大幅度提升。

圖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)對(duì)TDS 協(xié)議的加速，而客戶(hù)端必須對(duì)預(yù)取的數(shù)據(jù)進(jìn)行緩存，但由于緩存有限，不可能無(wú)止境地對(duì)數(shù)據(jù)進(jìn)行緩存，必須對(duì)數(shù)據(jù)量進(jìn)行合理控制。

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

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

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

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

根據(jù)內(nèi)存池中對(duì)申請(qǐng)內(nèi)存變化進(jìn)行劃分，可分為固定內(nèi)存池和動(dòng)態(tài)內(nèi)存池。固定內(nèi)存池分配的內(nèi)存均是固定的，而動(dòng)態(tài)內(nèi)存池分配的內(nèi)存是動(dòng)態(tài)變化的。在本系統(tǒng)中，因?yàn)樾枰l繁構(gòu)造數(shù)據(jù)包，故需要頻繁申請(qǐng)內(nèi)存，而數(shù)據(jù)包的大小并不一致，所以，綜合使用這2 種內(nèi)存池。系統(tǒng)通過(guò)對(duì)申請(qǐng)內(nèi)存的判斷來(lái)決定是固定內(nèi)存還是動(dòng)態(tài)內(nèi)存來(lái)進(jìn)行分配，這樣只需在系統(tǒng)啟動(dòng)時(shí)申請(qǐng)1 次內(nèi)存就能滿(mǎn)足程序的需要，使得加速效果達(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，并對(duì)系統(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 的代理客戶(hù)端部署在企業(yè)局域網(wǎng)出口的網(wǎng)關(guān)(圖8 中Gateway(C))上，公司內(nèi)所有主機(jī)必須通過(guò)此網(wǎng)關(guān)才能夠連接Internet；而AcTDS 代理服務(wù)器則部署在企業(yè)數(shù)據(jù)中心的出口網(wǎng)關(guān)(圖8 中Gateway(S))上，這樣無(wú)論任何1 個(gè)分公司的局域網(wǎng)內(nèi)的任何1 臺(tái)主機(jī)通過(guò)Project 客戶(hù)端在跨廣域網(wǎng)訪問(wèn)企業(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 包括代理客戶(hù)端與代理服務(wù)器?？蛻?hù)端與服務(wù)器的功能模塊主要有數(shù)據(jù)包識(shí)別模塊、數(shù)據(jù)包解析模塊、數(shù)據(jù)預(yù)取模塊、數(shù)據(jù)包重組模塊、數(shù)據(jù)包緩存模塊共5 個(gè)模塊。

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.1 客戶(hù)端加速

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

3.3.2 服務(wù)端加速

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

4 系統(tǒng)測(cè)試

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

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

圖10 測(cè)試環(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)境。在測(cè)試過(guò)程中，對(duì)帶寬、丟包率等參數(shù)進(jìn)行梯度設(shè)置，直至網(wǎng)速限制在10 Mb/s 左右，時(shí)延在500 ms 左右。測(cè)試過(guò)程中，服務(wù)器端數(shù)據(jù)大小為2 MB，測(cè)試結(jié)果如表2所示。

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

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

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

5 結(jié)論

1) 在對(duì)MS-TDS 協(xié)議深入分析的基礎(chǔ)上，提出了一種有效的TDS 協(xié)議加速策略，并在Linux 網(wǎng)關(guān)平臺(tái)下實(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ù)庫(kù)的協(xié)議加速方法研究中。雖然這些數(shù)據(jù)庫(kù)在數(shù)據(jù)通信過(guò)程中所采用的協(xié)議各不相同，但其通信過(guò)程基本上是一致的，因此，可以采用類(lèi)似的加速方法提升其他數(shù)據(jù)庫(kù)協(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] 王圣, 蘇金樹(shù).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.