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

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

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

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

1 TDS 協(xié)議分析

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

1.1 TDS 協(xié)議頭分析

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

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

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

1.2 RPC 消息分析

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

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

1.3 文件傳輸交互分析

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

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

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

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

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

2 TDS 加速策略的設計

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

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

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

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

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

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

2.2 流量控制技術(shù)

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

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

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

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

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

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

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

3 AcTDS 的設計與實現(xiàn)

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

3.1 系統(tǒng)部署圖

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

圖8 系統(tǒng)網(wǎng)絡拓撲Fig.8 Network topology of system

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.1 客戶端加速

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

3.3.2 服務端加速

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

4 系統(tǒng)測試

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

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

圖10 測試環(huán)境網(wǎng)絡拓撲圖Fig.10 Network topology of simulation environment

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

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

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

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

5 結(jié)論

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

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

3)AcTDS 具有良好的可擴展性。本文的研究成果可應用到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)關設計與實現(xiàn)[J]. 中南大學學報(自然科學版),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]. 軟件學報, 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.