衛(wèi)星網(wǎng)絡(luò)中并發(fā)TCP的復(fù)用機制

王 維，郝曉強，段桂華，黃家瑋，王建新

衛(wèi)星網(wǎng)絡(luò)中并發(fā)TCP的復(fù)用機制

王 維1，郝曉強2，段桂華1，黃家瑋1，王建新1

(1.中南大學(xué)信息科學(xué)與工程學(xué)院，湖南長沙，410083；2.航天恒星科技有限公司，北京，100190)

研究衛(wèi)星網(wǎng)絡(luò)中并發(fā)TCP流的復(fù)用機制，在通過模型分析得到最優(yōu)復(fù)用比的基礎(chǔ)上，基于epoll事件驅(qū)動機制設(shè)計并實現(xiàn)衛(wèi)星網(wǎng)絡(luò)的并發(fā)TCP復(fù)用加速網(wǎng)關(guān)。研究結(jié)果表明：該加速網(wǎng)關(guān)可以對來自不同客戶端的多條TCP流按照一定的復(fù)用比進(jìn)行復(fù)用，這樣，每條客戶端流可以通過避免3次握手并充分利用復(fù)用流的窗口加速數(shù)據(jù)傳輸；所設(shè)計的加速網(wǎng)關(guān)均能將典型門戶網(wǎng)頁頁面的加載時間和首字節(jié)到達(dá)時間最高縮短50%，可滿足衛(wèi)星網(wǎng)絡(luò)的加速需求。

衛(wèi)星網(wǎng)絡(luò)；傳輸控制協(xié)議；加速網(wǎng)關(guān)

隨著互聯(lián)網(wǎng)的飛速發(fā)展和大規(guī)模普及，各種新型網(wǎng)絡(luò)應(yīng)用為用戶提供了方便和快速的網(wǎng)絡(luò)服務(wù)。其中，Web應(yīng)用是目前使用最廣泛的網(wǎng)絡(luò)應(yīng)用，用戶可以使用各種網(wǎng)絡(luò)終端通過瀏覽器等訪問遠(yuǎn)程的Web服務(wù)器以獲取網(wǎng)絡(luò)信息和資料。但在大延時和高丟包的衛(wèi)星網(wǎng)絡(luò)環(huán)境中，網(wǎng)絡(luò)傳輸速度變得十分緩慢。同時，在Web應(yīng)用等網(wǎng)絡(luò)服務(wù)中，絕大部分網(wǎng)絡(luò)流量是由小于20 kB的小數(shù)據(jù)流組成。在衛(wèi)星網(wǎng)絡(luò)傳輸中，這些小流的傳輸控制開銷相對于有效數(shù)據(jù)傳輸較大，這使得典型網(wǎng)站在衛(wèi)星網(wǎng)絡(luò)中的訪問時間會從傳統(tǒng)廣域網(wǎng)中的幾秒劇增到幾十秒。SmartBear公司的統(tǒng)計結(jié)果表明[1]，57%的Web應(yīng)用用戶在3 s內(nèi)還沒加載完就會放棄。因此，如何在衛(wèi)星網(wǎng)絡(luò)中提高傳輸效率、降低響應(yīng)時間、提高用戶的體驗就變得十分重要。當(dāng)前針對衛(wèi)星網(wǎng)絡(luò)的加速研究包含網(wǎng)絡(luò)的多個層面，其中有使用灰色系統(tǒng)優(yōu)化ALOHA協(xié)議中的退避算法[2]、網(wǎng)絡(luò)層優(yōu)化時固定緩沖條件下的最大吞吐率路由算法[3]、近地衛(wèi)星網(wǎng)絡(luò)中的流量預(yù)測路由算法[4]和基于效率最大化的路由算法[5]。傳輸層協(xié)議優(yōu)化包括：通過RTT(round-trip time，往返時延)動態(tài)指數(shù)增窗和動態(tài)的降窗算法來修改TCP中的擁塞控制策略[6]；通過隨機早期檢測和窗口大小調(diào)整進(jìn)行數(shù)據(jù)流量的TCP傳輸控制[7]；提升延遲敏感服務(wù)質(zhì)量的包調(diào)度策略[8]；針對近地衛(wèi)星網(wǎng)絡(luò)中衛(wèi)星頻繁切換的特點使用MPTCP平滑網(wǎng)絡(luò)切換延遲[9]。在應(yīng)用協(xié)議的研究中，HTTP PEP[10]是專門針對HTTP協(xié)議進(jìn)行加速，其主要使用HTTP對象緩存、HTTP預(yù)取等；FFDP[11]是針對衛(wèi)星網(wǎng)絡(luò)中文件傳輸而設(shè)計的協(xié)議，該協(xié)議通過定時請求未確認(rèn)數(shù)據(jù)包和重傳丟失數(shù)據(jù)包充分利用鏈路帶寬，從而可以快速傳輸文件；GOOGLE提出了SPDY協(xié)議[12]，該協(xié)議通過優(yōu)先加載、多路復(fù)用、壓縮、推送等技術(shù)加速HTTP的訪問，在衛(wèi)星網(wǎng)絡(luò)中可以縮短頁面加載時間[13?15]。其中，SPDY協(xié)議的多路復(fù)用是將當(dāng)前HTTP協(xié)議下多條TCP連接上的數(shù)據(jù)復(fù)用到1條TCP連接上發(fā)送以避免建立TCP連接的延遲。但該協(xié)議需要在瀏覽器和服務(wù)端同步部署，且在高誤碼率的衛(wèi)星網(wǎng)絡(luò)中該協(xié)議的傳輸性能由于TCP的擁塞控制而產(chǎn)生抖動?？傮w而言，目前基于傳輸層協(xié)議的優(yōu)化未充分考慮典型應(yīng)用的數(shù)據(jù)流量特性，導(dǎo)致傳輸控制開銷較高。而基于應(yīng)用協(xié)議主要針對某一種特定的應(yīng)用場景和應(yīng)用層協(xié)議，無法對其他或場景提供加速服務(wù)，普適性不強。為此，本文作者針對衛(wèi)星網(wǎng)絡(luò)的特點，基于TCP協(xié)議的工作流程，研究衛(wèi)星網(wǎng)絡(luò)中并發(fā)TCP流的復(fù)用機制。

1 設(shè)計思路

1.1問題分析

目前，Web應(yīng)用是使用最廣泛的互聯(lián)網(wǎng)服務(wù)且Web應(yīng)用的數(shù)據(jù)流通常是由小對象組成。對使用GoogleChrome瀏覽器訪問“新浪”、“網(wǎng)易”、“搜狐”等目前中國Top 5的門戶網(wǎng)站主頁的對象長度分布進(jìn)行統(tǒng)計，對象的長度分布如圖1所示。從圖1(a)可以看出：超過70%的對象小于20 kB。從圖1(b)可看出：小于5 kB的對象占66%，只有34%的對象大于5 kB。HTTPArchive提供了全球范圍內(nèi)Top 1000的網(wǎng)站對象長度分布統(tǒng)計[16]。其結(jié)果顯示，55%的Web頁面中包含的對象數(shù)超過76個，所有對象中有91%是靜態(tài)對象，而這些靜態(tài)對象平均小于23 kB。

圖1 對象長度分布Fig.1 Distribution of object’s size

各大瀏覽器廠商和Web應(yīng)用提供方使用多種方式來加速Web應(yīng)用的訪問。主流的瀏覽器規(guī)定每個域名同時可以建立6條TCP連接，通過增大并行度以降低請求與響應(yīng)的停等式傳輸帶來的影響。而Web應(yīng)用提供方為了進(jìn)一步加快訪問速度，將不同的對象部署在不同的域名下進(jìn)一步增大并行度。這些加速機制在低延遲的網(wǎng)絡(luò)可以加快Web訪問速度，但也導(dǎo)致Web應(yīng)用傳輸?shù)木W(wǎng)頁對象進(jìn)一步分散到不同的TCP流中，形成了大量的短數(shù)據(jù)流。

圖2所示為測試的對地同步衛(wèi)星網(wǎng)絡(luò)拓?fù)?。同步衛(wèi)星需要對地面保持位置不變，因此，保持在離地比較高的運行軌道。其傳播延遲被大大拉長，往返延時RTT達(dá)到500ms以上，而且誤碼率高于10?5。當(dāng)用戶訪問首先通過高速、低延遲的地面網(wǎng)絡(luò)連接到衛(wèi)星小站時，小站通過大延遲、高丟包的衛(wèi)星鏈路連接到衛(wèi)星中心站，最后衛(wèi)星中心站通過高速、低延遲的地面網(wǎng)絡(luò)連接到互聯(lián)網(wǎng)。一般多個小站會共用同一個中心站，各小站被分配的帶寬設(shè)定為100MB/s。

圖2 衛(wèi)星網(wǎng)絡(luò)拓?fù)銯ig.2 Topology of satellite network

用戶通過衛(wèi)星網(wǎng)絡(luò)訪問Web對象時，大多數(shù)小對象會經(jīng)歷3次握手的延遲、從請求到響應(yīng)的延遲和服務(wù)端等待客戶端確認(rèn)的延遲。因此，多數(shù)對象需要至少2個RTT才能完成傳輸，稍大的對象則需要更多RTT，而這種延遲在RTT大于500ms時將非常明顯。

1.2 設(shè)計思想

從HTTPArchive的統(tǒng)計結(jié)果可看出Web應(yīng)用的訪問場景中主要包含2種數(shù)據(jù)：平均長度小于20 kB的對象和平均長度大于250 kB的視頻流數(shù)據(jù)。由于視頻流數(shù)據(jù)比較大，瀏覽器通常采取緩沖策略以通過當(dāng)前的延遲提升視頻播放中的流暢度，所以，視頻流對延遲的敏感度低于其他小對象對延遲的敏感度。為了提高Web應(yīng)用中普遍存在的小對象的傳輸效率，研究衛(wèi)星網(wǎng)絡(luò)并發(fā)TCP流復(fù)用機制。其中，傳輸層有多種變種TCP可供選擇，包括TCPHybla和TCPCubic等。文獻(xiàn)[17]對TCPHybla和TCPCubic在衛(wèi)星網(wǎng)絡(luò)中的傳輸性能進(jìn)行了對比測試，測試結(jié)果顯示TCPCubic的性能更優(yōu)，因此，選用TCPCubic進(jìn)行傳輸層的擁塞控制。并發(fā)TCP流復(fù)用機制的設(shè)計思想是：將多條TCP流傳輸?shù)男ο髲?fù)用匯聚到1條TCP流中，從而降低衛(wèi)星網(wǎng)絡(luò)中相對過高的傳輸控制開銷，加速網(wǎng)絡(luò)數(shù)據(jù)傳輸。復(fù)用加速前后的工作原理和加速效果見圖3。假設(shè)單流的握手和揮手時間為2個RTT，而數(shù)據(jù)傳輸延時也是2個RTT。圖3(a)表明單流的傳輸效率僅為50%，而圖3(b)顯示了復(fù)用加速的效果。其中，復(fù)用比定義為復(fù)用到同一條流的客戶端單流數(shù)量。這里，設(shè)定復(fù)用比為4，即4條單流復(fù)用到1條流，復(fù)用后傳輸效率提升為80%。

圖3 TCP傳輸時序圖Fig.3 Sequence diagram of TCP transm ission

圖4 每條客戶端流的吞吐率與復(fù)用比的關(guān)系Fig.4 Relationship betweenmultip lexing ratio and throughputof each client flow

進(jìn)一步測試加大復(fù)用比的傳輸性能，并統(tǒng)計每條單流的吞吐率。當(dāng)RTT為500ms，誤碼率為10?5的模擬衛(wèi)星網(wǎng)絡(luò)中，多條客戶端流在不同復(fù)用比的條件下連續(xù)請求多個20 kB對象過程中每條客戶端流的平均吞吐率示意圖見圖4。從圖4可以看出：當(dāng)復(fù)用比從1增長到5的過程中，每條客戶端流的平均吞吐率不斷提高，此時，多個客戶端流可以充分利用并增大復(fù)用后TCP的窗口，從而使每條客戶端流獲得較高的平均吞吐率；但當(dāng)復(fù)用比從5到20時，每條客戶端流的平均吞吐率呈現(xiàn)下降趨勢，其原因在于衛(wèi)星網(wǎng)絡(luò)的誤碼率高；隨著復(fù)用比增加，每條復(fù)用后TCP連接上傳輸?shù)臄?shù)據(jù)量變大，而衛(wèi)星網(wǎng)絡(luò)的高誤碼率引起的丟包會導(dǎo)致TCP減小擁塞窗口以降低發(fā)送速率，這樣，不斷增大復(fù)用比會導(dǎo)致每條客戶端流分得的帶寬降低；當(dāng)復(fù)用比大于10時，每條單流在復(fù)用后的TCP連接上傳輸吞吐率甚至低于復(fù)用前的吞吐率。

從以上分析可以看出：衛(wèi)星網(wǎng)絡(luò)的大延時和高丟包特性共同決定了復(fù)用的效率，過高或過低的復(fù)用比都不能得到最好的加速效果。這就需要進(jìn)一步分析在特性網(wǎng)絡(luò)環(huán)境中如何得到最優(yōu)的復(fù)用比，以獲取最優(yōu)傳輸性能。

2 協(xié)議設(shè)計

TCP復(fù)用的關(guān)鍵是將多條TCP上的數(shù)據(jù)通過1條TCP連接進(jìn)行傳輸，提高了傳輸效率。為此，設(shè)計一種并發(fā)TCP流的復(fù)用機制。該機制處于傳輸層之上，對每個TCP連接上的數(shù)據(jù)進(jìn)行封裝并分配會話，實現(xiàn)TCP復(fù)用。在復(fù)用過程中，復(fù)用比決定了傳輸?shù)募铀傩阅?。因此，首先通過建模分析得到最優(yōu)的復(fù)用比，然后研究復(fù)用網(wǎng)關(guān)的設(shè)計結(jié)構(gòu)，并描述實現(xiàn)細(xì)節(jié)和關(guān)鍵技術(shù)。

2.1 理論分析

最優(yōu)復(fù)用比的計算問題可以轉(zhuǎn)化成如何得到特定網(wǎng)絡(luò)環(huán)境下最佳的并發(fā)TCP流數(shù)量。使用并發(fā)TCP流擁塞控制模型分析得到最佳的并發(fā)TCP流數(shù)。系統(tǒng)模型中使用的變量見表1。

表1 系統(tǒng)模型變量說明Tab le 1 Description of variables in system model

圖5所示為n條TCP流的總擁塞窗口wn變化。其中：i和d分別為擁塞窗口的增窗因子和降窗因子，P為鏈路丟包率。若沒有發(fā)生丟包，則在1個往返延時t內(nèi)n條流共增長窗口ni。當(dāng)發(fā)生誤碼導(dǎo)致丟包時，其中1條TCP流降低其擁塞窗口，另外n?1條流窗口不變，因此，總擁塞窗口變?yōu)?n?d)wn/n。丟包后，共花費dwn/(n2i)個往返延時t將總窗口恢復(fù)到wn。

圖5 并發(fā)TCP流的總擁塞窗口Fig.5 Total congestion window of concurrent TCP flows

在各增窗周期內(nèi)，各流發(fā)包總量為1/P。由圖5可知

得到n條TCP流的總擁塞窗口wn為

根據(jù)wn可以得出n條TCP流的總吞吐率R為

代入式(1)和(2)得

在i和d為默認(rèn)值時，隨著n增加，總吞吐率R也不斷增加。這說明在不考慮TCP流控制開銷時，TCP流的并發(fā)度越高，傳輸?shù)目偹俾室苍酱?。但實際上，衛(wèi)星網(wǎng)絡(luò)中過高的傳播延時下TCP的控制開銷很高，嚴(yán)重地影響著傳輸效率。而且隨著并發(fā)度提高，復(fù)用比不斷降低，這意味著TCP連接控制開銷在整個傳輸過程中占據(jù)越來越大的比例，整體上降低了加速效率。

假設(shè)TCP連接握手和揮手時間為T0，s為n條TCP流的總傳輸量，由此可以計算出每條流的平均吞吐率r：

每條TCP流的平均吞吐率r見圖6。從圖6可見：丟包率越低，吞吐率越高；不論是哪種丟包率，當(dāng)并發(fā)度n變化時，TCP流的吞吐率存在1個最高值。這說明存在1個最優(yōu)的復(fù)用率，使得TCP流的傳輸效率最高。下面計算最優(yōu)的并發(fā)TCP流數(shù)nopt。

圖6 每條并發(fā)流的平均吞吐率Fig.6 Average throughputof each TCP flow

首先取增窗因子i和降窗因子d為默認(rèn)值，并令

得

為了得到最優(yōu)的并發(fā)TCP流數(shù)nopt，將r對n求導(dǎo)得

因為與2n在n的取值范圍內(nèi)誤差小于1，所以，可以將式(8)化簡為

得到最優(yōu)的的并發(fā)TCP流數(shù)nopt后，可得到復(fù)用比α為

2.2 加速網(wǎng)關(guān)架構(gòu)

TCP復(fù)用加速網(wǎng)關(guān)分為小站網(wǎng)關(guān)和中心站網(wǎng)關(guān)2部分。加速網(wǎng)關(guān)工作于傳輸層和應(yīng)用層之間，主要由3部分構(gòu)成。

1)事件驅(qū)動。采用epoll的事件驅(qū)動機制，負(fù)責(zé)處理所有的TCP連接的事件。

2)連接池。維護(hù)小站網(wǎng)關(guān)與中心站網(wǎng)關(guān)之間正在使用的TCP連接。

3)會話層。負(fù)責(zé)維護(hù)用戶與小站網(wǎng)關(guān)和中心站網(wǎng)關(guān)與廣域網(wǎng)之間的會話。

圖7所示為TCP復(fù)用的主要流程。首先，小站網(wǎng)關(guān)啟動以后會阻塞在監(jiān)聽連接處等待客戶端發(fā)起TCP連接?？蛻舳税l(fā)起TCP連接后，此時需要判斷連接池中是否有到中心站的TCP連接。若有且該復(fù)用流的當(dāng)前復(fù)用數(shù)小于計算得到的最優(yōu)復(fù)用比，則會將該客戶端的數(shù)據(jù)在此連接上傳輸；否則，創(chuàng)建1條新的連接到中心站，在這條連接上傳輸該客戶端數(shù)據(jù)。每次客戶端連接的數(shù)據(jù)傳輸完成后，網(wǎng)關(guān)查看是否有其他客戶端連接在使用，若沒有，則關(guān)閉此鏈接。

圖7 TCP復(fù)用流程Fig.7 Processof TCPmultiplexing

TCP復(fù)用加速網(wǎng)關(guān)基于Linux2.6內(nèi)核，用libuv庫和C語言實現(xiàn)。其中l(wèi)ibuv庫是1個異步IO庫，可以簡化大并發(fā)網(wǎng)絡(luò)程序的開發(fā)，使用的關(guān)鍵技術(shù)包括TCP流映射、會話同步、連接池維護(hù)。

2.3 TCP流映射

系統(tǒng)中所有的TCP建流請求都是由客戶端發(fā)起。當(dāng)小站網(wǎng)關(guān)接收到1個建流請求時，會為該流創(chuàng)建1個會話ID，分配或創(chuàng)建小站網(wǎng)關(guān)和中心站網(wǎng)關(guān)之間的1條TCP連接，并將這種對應(yīng)關(guān)系存儲在小站網(wǎng)關(guān)的映射表中。這樣，當(dāng)客戶端TCP連接上有數(shù)據(jù)時，可以根據(jù)文件描述符對應(yīng)的結(jié)構(gòu)體獲得會話ID和復(fù)用的TCP流的信息。當(dāng)復(fù)用流上有數(shù)據(jù)到達(dá)時，可以根據(jù)會話ID獲取到客戶端TCP連接的信息，完成客戶端映射。此后，小站網(wǎng)關(guān)發(fā)送數(shù)據(jù)到中心站網(wǎng)關(guān)后，中心站網(wǎng)關(guān)會根據(jù)小站網(wǎng)關(guān)發(fā)送的會話ID也建立1個中心站的映射關(guān)系并存儲在中心站的映射表中，當(dāng)復(fù)用流上有數(shù)據(jù)時，可以根據(jù)會話ID獲取到對應(yīng)服務(wù)器端連接信息。當(dāng)服務(wù)器端連接上有數(shù)據(jù)時，可以根據(jù)文件描述符對應(yīng)的結(jié)構(gòu)體得到會話ID和復(fù)用的TCP流的信息。

2.4 會話層

會話層使用了自定義的協(xié)議，該協(xié)議的數(shù)據(jù)包格式如圖8所示。圖8(a)中數(shù)據(jù)包分為頭部和數(shù)據(jù)區(qū)，其中頭部包含4字節(jié)會話ID、1字節(jié)控制命令和2字節(jié)數(shù)據(jù)長度，數(shù)據(jù)區(qū)在一般情況下只包含有效負(fù)載。客戶端向小站網(wǎng)關(guān)發(fā)起請求后，小站為該TCP連接創(chuàng)建會話，會根據(jù)客戶端發(fā)送給它的目標(biāo)地址和端口等信息初始化會話。會話的數(shù)據(jù)格式如圖8(b)所示。中心站接收到該數(shù)據(jù)包以后會解析出目標(biāo)域名和端口，并與該地址建立TCP連接，然后將數(shù)據(jù)發(fā)送給該地址。

圖8 數(shù)據(jù)包格式Fig.8 Packet formats

中心站接收到遠(yuǎn)端服務(wù)器返回的響應(yīng)后，構(gòu)造普通的包后發(fā)送到小站。小站網(wǎng)關(guān)接收到數(shù)據(jù)包后根據(jù)會話ID找出對應(yīng)的客戶端連接，然后將數(shù)據(jù)發(fā)送給客戶端。

當(dāng)連接異常關(guān)閉后，網(wǎng)關(guān)要實施會話同步?？蛻舳说倪B接和服務(wù)器的連接都有可能因為某種原因關(guān)閉。當(dāng)連接關(guān)閉時，需要將小站和中心站網(wǎng)關(guān)的會話都刪除。若客戶端連接首先異常關(guān)閉，則小站網(wǎng)關(guān)會發(fā)送1個不包含數(shù)據(jù)區(qū)的會話包到中心站網(wǎng)關(guān)，表示關(guān)閉該ID的會話，同時將自身的相關(guān)資源釋放。中心站網(wǎng)關(guān)收到該包后，釋放會話對應(yīng)的資源。若服務(wù)器的連接異常關(guān)閉，則中心站網(wǎng)關(guān)通告小站網(wǎng)關(guān)釋放對應(yīng)會話的資源，同時將自身的相關(guān)資源釋放。

2.5 連接池

小站網(wǎng)關(guān)和中心站網(wǎng)關(guān)之間保持正在被客戶端連接使用的TCP連接，這些連接由小站網(wǎng)關(guān)主動發(fā)起并維護(hù)，多條連接之間的負(fù)載均衡也是由小站網(wǎng)關(guān)完成。當(dāng)客戶端發(fā)起1條TCP連接時，小站網(wǎng)關(guān)使用最少客戶端使用的負(fù)載均衡算法將該TCP連接與連接池中的某條TCP連接關(guān)聯(lián)。此后，該客戶端連接上的所有數(shù)據(jù)都由選定的TCP連接處理。這樣，只要有客戶端正在使用該連接，該連接就不會被主動斷開。當(dāng)新的客戶端連接到來時就有機會使用這條連接，但若最后1個使用該連接的客戶端連接關(guān)閉后，連接也隨之關(guān)閉。

3 實驗分析

實驗分為本地測試、廣域網(wǎng)測試和對比測試。本地測試和廣域網(wǎng)測試分別測試可控環(huán)境下和真實環(huán)境下的復(fù)用網(wǎng)關(guān)加速性能，對比測試用于比較本文的并發(fā)TCP復(fù)用機制和SPDY協(xié)議的傳輸性能。其中，采用前面的實驗拓?fù)浣Y(jié)構(gòu)進(jìn)行測試。小站網(wǎng)關(guān)和中心站網(wǎng)關(guān)均部署在普通PC上，配置如下：CPU為Intel(R)CoreTM i3-3220 CPU@3.30 GHz，內(nèi)存為4 GB，網(wǎng)卡為千兆網(wǎng)卡。衛(wèi)星網(wǎng)絡(luò)模擬器使用WANem 3.0，衛(wèi)星網(wǎng)絡(luò)模擬器設(shè)置帶寬為100MB/s。客戶端端使用chrome瀏覽器訪問測試網(wǎng)站10次，然后統(tǒng)計平均測試結(jié)果。

實驗中，測試網(wǎng)頁加載時間和首字節(jié)到達(dá)時間。其中，網(wǎng)頁加載時間是頁面所有對象元素都到達(dá)客戶端的最終時間，是決定網(wǎng)站用戶體驗的關(guān)鍵指標(biāo)。而首字節(jié)達(dá)到時間為響應(yīng)頁面的第1個字節(jié)到達(dá)客戶端的最快時間，包括DNS，socket連接和請求響應(yīng)時間，是反映服務(wù)端響應(yīng)速度的重要指標(biāo)。

3.1 本地測試

本地測試是在局域網(wǎng)中搭建網(wǎng)站，然后客戶端通過WANem訪問這些網(wǎng)站?？蛻舳瞬捎胏hrome瀏覽器測試各個網(wǎng)站，然后從chrome瀏覽器訪問各個網(wǎng)站所產(chǎn)生的日志文件中統(tǒng)計網(wǎng)頁的加載時間。通過實驗得出每個網(wǎng)站在不同丟包和往返延時條件下，使用加速網(wǎng)關(guān)和不使用加速網(wǎng)關(guān)的網(wǎng)頁加載時間對比如圖9所示。其中，圖9(a)中，往返延時t為500ms；圖9(b)中，丟包率為1%。

圖9 局域網(wǎng)中網(wǎng)頁加載時間測試結(jié)果Fig.9 Test results ofweb page load time in LAN

從圖9(a)可見：使用加速網(wǎng)關(guān)最低可以縮短37%的頁面加載時間，最高可以縮短55%的頁面加載時間；增大丟包率后，較大的丟包率對使用網(wǎng)關(guān)和不使用網(wǎng)關(guān)的網(wǎng)頁訪問都產(chǎn)生了負(fù)面影響，導(dǎo)致頁面加載時間波動變大，其中使用加速網(wǎng)關(guān)最低可以縮短36%的頁面加載時間，最高可以縮短56%的頁面加載時間。從圖9(b)可見：增大往返延時t后依然保持較高的加速比，最低縮短25%的頁面加載時間，最高縮短49%的頁面加載時間。

3.2 廣域網(wǎng)測試

在廣域網(wǎng)測試中，客戶端通過WANem訪問廣域網(wǎng)中訪問量top5的門戶網(wǎng)站。通過多次實驗得出在不同丟包率和往返延時條件下，不同門戶網(wǎng)站主頁的頁面加載時間和首字節(jié)到達(dá)時間，統(tǒng)計結(jié)果如圖10所示。從圖10(a)可見：當(dāng)往返延時t為500ms，丟包分別為1%和10%時，使用網(wǎng)關(guān)比不使用網(wǎng)關(guān)訪問5個門戶網(wǎng)站首頁的頁面加載時間明顯縮短。從圖10(b)可見：隨著丟包率增大，首字節(jié)達(dá)到時間更短。這主要是因為不使用網(wǎng)關(guān)的訪問中域名的解析也需要通過衛(wèi)星網(wǎng)絡(luò)，因此，嚴(yán)重加大了門戶網(wǎng)站時的首字節(jié)到達(dá)時間；而采用加速網(wǎng)關(guān)后，能有效地降低DNS解析和流傳輸?shù)臅r間。保持1%丟包不變，增大往返延時t的測試結(jié)果如圖10(c)和圖10(d)所示，可見頁面加載時間總體保持加速，而首字節(jié)到達(dá)時間加速效果更明顯。

3.3 對比測試

由于SPDY是針對當(dāng)前HTTP協(xié)議進(jìn)行優(yōu)化，且使用了TCP復(fù)用技術(shù)，因此，對比測試中選用的SPDY協(xié)議作為比較對象。在對比測試中，客戶端分別通過并發(fā)TCP復(fù)用機制和SPDY協(xié)議訪問局域網(wǎng)中部署的頁面，其中不同頁面中包含不同數(shù)量的長度為20 kB的對象。通過多次實驗得出通過并發(fā)TCP復(fù)用機制和SPDY協(xié)議訪問不同頁面時的頁面加載時間，統(tǒng)計結(jié)果如圖11所示。

圖11中Cubic是不使用任何加速技術(shù)的頁面訪問狀態(tài)。從圖11可以看出：在頁面中包含不同數(shù)量對象的條件下，使用并發(fā)TCP復(fù)用可以縮短頁面的加載時間，且比使用SPDY的加速效率更高。這主要是因為SPDY采用的是將所有對象復(fù)用到1條流的策略，其傳輸性能受TCP擁塞控制的影響，而且SPDY自身復(fù)雜的控制流程導(dǎo)致在頁面對象數(shù)小于15時的頁面加載時間大于采用Cubic訪問時的頁面加載時間。并發(fā)TCP復(fù)用通過合理的復(fù)用比降低了TCP擁塞控制的影響，因此，可以獲得更好的加速性能。

圖10 廣域網(wǎng)中不同門戶網(wǎng)站網(wǎng)頁加載和首字節(jié)到達(dá)時間測試結(jié)果Fig.10 Test results forw eb page load time and firstbyte arrival time of differentportals inWAN

圖11 網(wǎng)頁加載時間對比測試結(jié)果Fig.11 Comparison test results ofweb page load time

4 結(jié)論

1)以傳輸Web應(yīng)用對象為例分析了衛(wèi)星網(wǎng)絡(luò)中基于TCP協(xié)議的傳輸效率低的問題，根據(jù)典型門戶網(wǎng)站的數(shù)據(jù)對象的長度分布和Web應(yīng)用數(shù)據(jù)傳輸?shù)牧髁刻匦裕７治龅玫奖ＷC傳輸效率最高的最優(yōu)復(fù)用比的基礎(chǔ)上設(shè)計了并發(fā)TCP流的復(fù)用機制，并實現(xiàn)了并發(fā)TCP流的復(fù)用加速網(wǎng)關(guān)。網(wǎng)關(guān)均能將典型門戶網(wǎng)頁頁面的加載時間和首字節(jié)到達(dá)時間最高縮短50%。

2)下一步將進(jìn)一步研究衛(wèi)星網(wǎng)絡(luò)中更為高效的傳輸方法，以及基于之上的壓縮、預(yù)取等其他加速方法，并將測試大規(guī)模真實系統(tǒng)。

[1]M ashable.Slow website cost retailers billion[EB/OL]. [2013?04?22].http://mashable.com/2012/11/22/slow-website/.

[2]QI Xiaohang,ZHANG Qi,TIAN Qinghua,et al.Design of adaptive backoff algorithm for satellite network using grey system[J].The Journal of China Universities of Posts and Telecommunications,2015,22(1):24?56.

[3]LIN Bing,LIHongyan,LONG Yan.A buffer-limited maximum throughput routing algorithm for satellite network[C]//22nd International Conference on Telecommunications(ICT2015). Sydney,Australia,2015:378?383.

[4]NA Zhenyu,GAO Zihe,CUIYang,etal.Agent-based distributed routing algorithm with traffic prediction for LEO satellite network[J].International Journal of Future Generation Communication&Networking,2013,6(3):67?84.

[5]LU Yong,ZANG Jun,ZHANG Tao.UMR:A utility-maxim izing routing algorithm for delay-sensitive service in LEO satellite networks[J].Chinese Journal of Aeronautics,2015,28(2): 499?507.

[6]SHIN M,PARK M,OH D,et al.RTT fair congestion control algorithm for satellite interactive networks[C]//Computing, Communications and App licationsConference(ComCom Ap2012). Hong Kong,China,2012:339?344.

[7]TORRESR,BORDER J,STEVENSP,etal.Method and system for controlling TCP traffic w ith random early detection and w indow size adjustments:USPatent 8,705,357[P].2014?04?22.

[8]LU Yong,ZHANG Jun,ZHANG Tao.UPQ:An effective packet scheduling algorithm for delay-sensitive service in NGEO satellite network[C]//9th International Conference on Communications and Networking in China(CHINACOM 2014). M aom ing,China,2014:517?522.

[9]DU Pengyuan,LIXiao,LU You,et al.Multipath TCP over LEO satellite networks[C]//11th International W ireless Communications and Mobile Computing Conference(IWCMC 2015).Dubrovnik,Croatia,2015:1?6.

[10]DAVERN P,NASHID N,SREENAN C J,et al.Httpep:a http performance enhancing proxy for satellite systems[J]. International Journal of Next-Generation Computing,2011,2(3): 242?256.

[11]LIU Chang,WU Chunqing,YU Wanrong,et al.FFDP:a full-load file delivery protocol in satellite network communication[C]//W ireless Algorithms,Systems,and Applications.Berlin:Springer International Publishing,2015: 377?385.

[12]GOOGLECOM.SPDY:an experimental protocol for a faster web[R].[2016?03?30].http://dev.chromium.org./spdy/spdywhitepaper.

[13]ROSETIC,SALAM AA,LUGLIO M,etal.SPDY over satellite: performance optim ization through an end-to-end technology[C]// 38th International Conference on Telecommunications and Signal Processing(TSP2015).Prague,Czech Republic,2015: 1?6.

[14]CARDACIA,CAVIGLIONE L,GOTTA A,et al.Performance evaluation of SPDY over high latency satellite channels[M]// Personal Satellite Services.Berlin:Springer International Publishing,2013:123?134.

[15]SALAM A A,LUGLIO M,ROSETIC,etal.SPDY multiplexing approach on long-latency links[C]//IEEE W ireless Communicationsand Networking Conference(WCNC).Istanbul, Turkey,2014:3450?3455.

[16]Http Archive.Interesting stats[EB/OL].[2015?10?01]. http://httparchive.org/interesting.php.

[17]TRIVEDI S,JAISWAL S,KUMAR R,et al.Comparative performance evaluation of TCP Hybla and TCP Cubic for satellite communication under low error conditions[C]//IEEE 4th International Conference on Internet M ultimedia Services A rchitecture and Application(IMSAA 2010).Bangalore,India, 2010:1?5.

(編輯 陳燦華)

M ultip lexing scheme for concurrent TCPs in satellite networks

WANGWei1,HAO Xiaoqiang2,DUANGuihua1,HUANG Jiawei1,WANG Jianxin1

(1.School of Information Science and Engineering,Central South University,Changsha 410083,China; 2.Space Star Technology Co.Ltd.,Beijing 100190,China)

A multiplexing mechanism for the concurrent TCP in satellite networks was designed,the optimal multiplexing ratio w asmodeled,and an acceleration gateway based on event-driven epollmechanism was imp lemented. The results show that acceletation gatew ay can multiplex multiple TCP flow s of different clients on a TCP flow w ith a ratio,so that every client’s flow can accelerate the data transfer by avoid three-way handshake overhead and take full advantage of the w indow of multiplexed flow.The accelerate gateway reduces by 50%of the page load time and the arrival time of the firstbyte for the typical portalw eb sites,w hichmeets the acceleration requirementof satellite netw ork. Key words:satellite netw orks;TCP;acceleration gateway

TP393

A

1672?7207(2017)03?0712?09

10.11817/j.issn.1672-7207.2017.03.020

2016?04?10；

2016?06?22

國家自然科學(xué)基金資助項目(61572530，61462007)(Projects(61572530,61462007)supported by the Natural National Science Foundation of China)

段桂華，博士，教授，從事計算機網(wǎng)絡(luò)、網(wǎng)絡(luò)安全研究；E-mail:duangh@csu.edu.cn