王 維，郝曉強(qiáng)，段桂華，黃家瑋，王建新

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

王 維1，郝曉強(qiáng)2，段桂華1，黃家瑋1，王建新1

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

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

1 設(shè)計(jì)思路

1.1問(wèn)題分析

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

圖1 對(duì)象長(zhǎng)度分布Fig.1 Distribution of object’s size

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

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

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

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

1.2 設(shè)計(jì)思想

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

圖3 TCP傳輸時(shí)序圖Fig.3 Sequence diagram of TCP transm ission

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

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

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

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

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

2.1 理論分析

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

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

圖5所示為n條TCP流的總擁塞窗口wn變化。其中：i和d分別為擁塞窗口的增窗因子和降窗因子，P為鏈路丟包率。若沒(méi)有發(fā)生丟包，則在1個(gè)往返延時(shí)t內(nèi)n條流共增長(zhǎng)窗口ni。當(dāng)發(fā)生誤碼導(dǎo)致丟包時(shí)，其中1條TCP流降低其擁塞窗口，另外n?1條流窗口不變，因此，總擁塞窗口變?yōu)?n?d)wn/n。丟包后，共花費(fèi)dwn/(n2i)個(gè)往返延時(shí)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)值時(shí)，隨著n增加，總吞吐率R也不斷增加。這說(shuō)明在不考慮TCP流控制開(kāi)銷(xiāo)時(shí)，TCP流的并發(fā)度越高，傳輸?shù)目偹俾室苍酱蟆５珜?shí)際上，衛(wèi)星網(wǎng)絡(luò)中過(guò)高的傳播延時(shí)下TCP的控制開(kāi)銷(xiāo)很高，嚴(yán)重地影響著傳輸效率。而且隨著并發(fā)度提高，復(fù)用比不斷降低，這意味著TCP連接控制開(kāi)銷(xiāo)在整個(gè)傳輸過(guò)程中占據(jù)越來(lái)越大的比例，整體上降低了加速效率。

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

每條TCP流的平均吞吐率r見(jiàn)圖6。從圖6可見(jiàn)：丟包率越低，吞吐率越高；不論是哪種丟包率，當(dāng)并發(fā)度n變化時(shí)，TCP流的吞吐率存在1個(gè)最高值。這說(shuō)明存在1個(gè)最優(yōu)的復(fù)用率，使得TCP流的傳輸效率最高。下面計(jì)算最優(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對(duì)n求導(dǎo)得

因?yàn)榕c2n在n的取值范圍內(nèi)誤差小于1，所以，可以將式(8)化簡(jiǎn)為

得到最優(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ū)動(dòng)。采用epoll的事件驅(qū)動(dòng)機(jī)制，負(fù)責(zé)處理所有的TCP連接的事件。

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

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

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

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

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

2.3 TCP流映射

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

2.4 會(huì)話(huà)層

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

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

2.5 連接池

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

3 實(shí)驗(yàn)分析

實(shí)驗(yàn)分為本地測(cè)試、廣域網(wǎng)測(cè)試和對(duì)比測(cè)試。本地測(cè)試和廣域網(wǎng)測(cè)試分別測(cè)試可控環(huán)境下和真實(shí)環(huán)境下的復(fù)用網(wǎng)關(guān)加速性能，對(duì)比測(cè)試用于比較本文的并發(fā)TCP復(fù)用機(jī)制和SPDY協(xié)議的傳輸性能。其中，采用前面的實(shí)驗(yàn)拓?fù)浣Y(jié)構(gòu)進(jìn)行測(cè)試。小站網(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?？蛻?hù)端端使用chrome瀏覽器訪(fǎng)問(wèn)測(cè)試網(wǎng)站10次，然后統(tǒng)計(jì)平均測(cè)試結(jié)果。

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

3.1 本地測(cè)試

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

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

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

3.2 廣域網(wǎng)測(cè)試

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

3.3 對(duì)比測(cè)試

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

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

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

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

4 結(jié)論

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

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

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

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