邢 璐 嚴(yán) 明 吳承榮(復(fù)旦大學(xué)計算機(jī)科學(xué)技術(shù)學(xué)院 上海 200433)

0 引 言

近些年，隨著互聯(lián)網(wǎng)、云計算、大數(shù)據(jù)集群等技術(shù)的發(fā)展，大數(shù)據(jù)時代到來，數(shù)據(jù)如今滲透到各行各業(yè)，數(shù)據(jù)規(guī)模已從TB級增長到PB級[1]。數(shù)據(jù)總量多，單個數(shù)據(jù)文件大，通過現(xiàn)有的網(wǎng)絡(luò)傳輸數(shù)據(jù)往往需要很長時間，這給不同地區(qū)機(jī)構(gòu)之間的數(shù)據(jù)交流帶來了困難。如果網(wǎng)絡(luò)發(fā)生變化或者網(wǎng)絡(luò)出現(xiàn)中斷，傳輸性能還將進(jìn)一步降低。傳輸數(shù)據(jù)規(guī)模大，傳輸效率要求高，傳統(tǒng)的互聯(lián)網(wǎng)協(xié)議和傳輸工具已經(jīng)無法滿足大數(shù)據(jù)時代對傳輸?shù)囊?，因此亟需研究和?gòu)建新的高速網(wǎng)絡(luò)傳輸協(xié)議。

目前，研究者提出了很多改進(jìn)的傳輸協(xié)議用來提高大數(shù)據(jù)在廣域網(wǎng)上的傳輸性能。ESnet[2-3]科學(xué)網(wǎng)使用GridFTP協(xié)議即Globus Toolkit組件之一，實(shí)現(xiàn)兩臺主機(jī)之間高速、可靠的數(shù)據(jù)傳輸。優(yōu)化的高速網(wǎng)絡(luò)傳輸協(xié)議一般分為兩類：一類是基于TCP的，如GridTCP[4]、FDT(Fast Data Transfer Tool)[5]、fast-TCP[6]和sftp[7]；另一類是基于UDP的，如UDT[8]、QUIC[9]、PAT等。

傳統(tǒng)的TCP協(xié)議可以提供可靠的、面向連接的傳輸功能，但是在復(fù)雜的廣域網(wǎng)環(huán)境中，由于TCP協(xié)議的固有瓶頸使得基于TCP的高速傳輸協(xié)議無法充分利用網(wǎng)絡(luò)帶寬。在TCP協(xié)議中，速率控制和擁塞控制是以丟包作為控制的信號，因而，丟包將對TCP傳輸速度產(chǎn)生很大的影響[10]。在鏈路條件較好的情況下，這種自誘導(dǎo)式丟包數(shù)會超過其他原因的丟包，使得傳輸無法獲得平穩(wěn)的速度。而在廣域網(wǎng)的環(huán)境中，網(wǎng)絡(luò)環(huán)境復(fù)雜，丟包可能因為多種情況，并非一定是帶寬的限制，因而這種方式將導(dǎo)致對網(wǎng)絡(luò)擁塞狀況估計的誤判，而基于TCP的高速網(wǎng)絡(luò)傳輸協(xié)議會繼承TCP協(xié)議的相關(guān)特性。GridFTP協(xié)議有三個重要的參數(shù)：并行、并發(fā)和管道[11]，并通過并行TCP數(shù)據(jù)流充滿網(wǎng)絡(luò)帶寬，但多個TCP流在一方面會加重網(wǎng)絡(luò)負(fù)擔(dān)，造成網(wǎng)絡(luò)資源的競爭，引起不必要的重傳，使得帶寬資源浪費(fèi)。另一方面主機(jī)端在處理時需要使用更多的CPU資源和內(nèi)存資源來維護(hù)每個TCP流的狀態(tài)，加重其系統(tǒng)負(fù)擔(dān)。

UDT協(xié)議是基于UDP協(xié)議的應(yīng)用層協(xié)議，應(yīng)用程序可以基于UDT協(xié)議實(shí)現(xiàn)可靠的文件傳輸功能[8]。UDT協(xié)議顯式通知發(fā)送方丟包序列，使用連續(xù)發(fā)送包對的技術(shù)對帶寬進(jìn)行預(yù)測，將基于速率的擁塞控制和基于窗口的流控機(jī)制相結(jié)合，實(shí)現(xiàn)高速網(wǎng)絡(luò)的可靠傳輸。在UDT的架構(gòu)中，可以實(shí)現(xiàn)定制化的擁塞避免策略和流控機(jī)制來滿足不同網(wǎng)絡(luò)條件下的傳輸控制而不用修改操作系統(tǒng)內(nèi)核代碼。

在千兆網(wǎng)環(huán)境中，未優(yōu)化的UDT協(xié)議在吞吐率、公平性、TCP友好性以及穩(wěn)定性等方面具有良好的性能，但是與TCP協(xié)議相比會占有更高的CPU資源。隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，出現(xiàn)了10 Gbps、40 Gbps甚至更高帶寬的網(wǎng)絡(luò)環(huán)境，然而在這些高速網(wǎng)絡(luò)環(huán)境中，有許多因素阻礙網(wǎng)絡(luò)傳輸速度的進(jìn)一步提升，如CPU和存儲速度。

本文通過對UDT協(xié)議在10 Gbps帶寬的高速網(wǎng)絡(luò)環(huán)境中進(jìn)行大數(shù)據(jù)文件傳輸時的傳輸瓶頸和主機(jī)丟包的原因進(jìn)行分析，提出了基于UDT的改進(jìn)A-UDT(Advanced UDT)協(xié)議。本文的主要貢獻(xiàn)包括以下三個方面：

1) 分析高速網(wǎng)絡(luò)環(huán)境中UDT協(xié)議的傳輸瓶頸和丟包原因，提出了一系列的系統(tǒng)優(yōu)化措施。

2) 改進(jìn)UDT協(xié)議的重傳機(jī)制，減少超時重傳的次數(shù)，增強(qiáng)了UDT協(xié)議的可靠性。

3) 分析主機(jī)端使用UDT協(xié)議時CPU的分布規(guī)律，通過減少系統(tǒng)調(diào)用的次數(shù)優(yōu)化了CPU的利用率。

1 相關(guān)工作

TPG[12-13]是一種用來提升端到端傳輸性能的通用框架，并以UDT協(xié)議為例子，驗證了在高速網(wǎng)絡(luò)中TPG可以提升傳輸協(xié)議的性能。在TPG的相關(guān)文獻(xiàn)中，列舉了可能影響UDT傳輸?shù)囊蛩睾拖嚓P(guān)參數(shù)設(shè)置，并通過調(diào)整數(shù)據(jù)包大小、塊大小和緩存大小提升UDT協(xié)議的傳輸速度。在文獻(xiàn)的實(shí)驗部分，TPG指出實(shí)驗需要網(wǎng)卡支持jumbo frames模式來實(shí)現(xiàn)巨型幀達(dá)到修改數(shù)據(jù)包大小的目的，但是對廣域網(wǎng)的傳輸，這就要求鏈路上的節(jié)點(diǎn)都支持這種模式。此外，大的數(shù)據(jù)包也意味著出現(xiàn)丟包時，重傳的代價也將更大。文獻(xiàn)[14]測試了基于TCP和UDP的多種高速網(wǎng)絡(luò)傳輸工具在不同RTT和背景流量的情況下的傳輸性能，實(shí)驗結(jié)果顯示UDT在RTT較高的情況下仍然有較高的傳輸速度和穩(wěn)定的吞吐率。

文獻(xiàn)[15]指出在高速網(wǎng)絡(luò)的環(huán)境中，操作系統(tǒng)網(wǎng)絡(luò)協(xié)議棧處理數(shù)據(jù)包的速度已經(jīng)無法與網(wǎng)卡速度相適配，CPU是限制主機(jī)傳輸速度的主要瓶頸。Luigi Rizzo等[16]提出了一種高效的收發(fā)數(shù)據(jù)包的框架netmap，與傳統(tǒng)Linux網(wǎng)絡(luò)協(xié)議棧不同，它主要從三個方面減少數(shù)據(jù)包的處理代價：數(shù)據(jù)包動態(tài)內(nèi)存分配、減少系統(tǒng)調(diào)用代價和內(nèi)存拷貝次數(shù)。通過這些優(yōu)化netmap提高了CPU的利用率，提升了數(shù)據(jù)包的收發(fā)處理速度。實(shí)驗結(jié)果顯示netmap運(yùn)行在900 MHz的單CPU上，數(shù)據(jù)包收發(fā)次數(shù)可以達(dá)到14.88 Mpacket/s。但是，netmap并不提供可靠性的保證和網(wǎng)絡(luò)擁塞控制。DPDK[17](Data Plane Development Kit)協(xié)議也是一種高性能的快速包處理工具，DPDK可以繞過傳統(tǒng)的Linux協(xié)議棧，將數(shù)據(jù)包直接存放在用戶態(tài)空間，極大地減少了接收數(shù)據(jù)包時系統(tǒng)調(diào)用和內(nèi)存拷貝次數(shù)。DPDK的優(yōu)化效果很好，但是如果用戶選擇使用DPDK，就需要實(shí)現(xiàn)TCP和UDP協(xié)議來滿足應(yīng)用層協(xié)議的需求。

2 Advanced UDT

Advanced UDT(A-UDT)在繼承UDT良好框架的基礎(chǔ)上，實(shí)現(xiàn)了UDT協(xié)議在萬兆網(wǎng)上的可適應(yīng)性。本文主要從以下三個方面分析和解決UDT協(xié)議在高速網(wǎng)絡(luò)中的傳輸瓶頸：

1) 在萬兆網(wǎng)的環(huán)境中，UDT傳輸出現(xiàn)嚴(yán)重的丟包問題。

2) UDT協(xié)議持續(xù)丟包引起超時重傳的現(xiàn)象。

3) UDT協(xié)議占用過多的CPU資源問題。

2.1 系統(tǒng)調(diào)優(yōu)

緩沖區(qū)在高速網(wǎng)絡(luò)的傳輸過程中有很大的作用，越大的緩沖區(qū)對突發(fā)數(shù)據(jù)流的處理能力越強(qiáng)。數(shù)據(jù)包從網(wǎng)卡接收到拷貝至應(yīng)用層進(jìn)行處理流程如圖1所示。

圖1 數(shù)據(jù)包一次接收過程

數(shù)據(jù)包在網(wǎng)絡(luò)中傳輸，先到達(dá)接收方主機(jī)的網(wǎng)卡，ring buffer是網(wǎng)卡接收緩存區(qū)，在處理收發(fā)數(shù)據(jù)包時對突發(fā)情況有著重要的作用，而一般網(wǎng)卡的默認(rèn)的接收緩沖區(qū)較小，可以重新設(shè)置。當(dāng)網(wǎng)卡接收到數(shù)據(jù)包后，會通過觸發(fā)IO中斷的方式告知內(nèi)核有數(shù)據(jù)包到達(dá)，操作系統(tǒng)內(nèi)核將網(wǎng)卡數(shù)據(jù)包存儲到內(nèi)存中，一般系統(tǒng)內(nèi)核參數(shù)對于TCP協(xié)議的接收緩存會自適應(yīng)的設(shè)置，而對UDP協(xié)議則沒有。之后UDT接收端會調(diào)用系統(tǒng)內(nèi)核提供的UDP套接字接口函數(shù)獲取數(shù)據(jù)包。應(yīng)用程序會在用戶空間中開辟了一段內(nèi)存，用來順序存放接收到的UDT數(shù)據(jù)包。這段內(nèi)存作為環(huán)形隊列，重復(fù)利用，隊列空間滿時，UDT接收端并沒有重新調(diào)整的機(jī)制。

在萬兆網(wǎng)的環(huán)境中，使用UDT傳輸工具傳輸大文件時，會出現(xiàn)傳輸速度慢，帶寬利用率低，并且伴隨著嚴(yán)重丟包的現(xiàn)象。使用流量監(jiān)控服務(wù)器對接收端流量進(jìn)行分析，發(fā)現(xiàn)在網(wǎng)絡(luò)的鏈路上沒有發(fā)生丟包，發(fā)送方發(fā)送的數(shù)據(jù)包都到達(dá)了接收方，但在應(yīng)用層，UDT發(fā)送方仍然收到了大量的NAK控制包，使得文件的傳輸速度很低。

根據(jù)之前對數(shù)據(jù)包在接收方的接收流程的分析可以得出，數(shù)據(jù)從鏈路上獲取之后，會暫存在不同的緩存隊列中等待下一步的處理，數(shù)據(jù)包的處理需要獲取CPU資源。當(dāng)CPU不足以處理高速網(wǎng)絡(luò)的傳輸流量時，數(shù)據(jù)包會在緩沖區(qū)累積，當(dāng)超過緩沖區(qū)的容量時，數(shù)據(jù)包就會被丟棄，造成鏈路中沒有發(fā)現(xiàn)丟包，但UDT接收端在應(yīng)用層接收不到相應(yīng)數(shù)據(jù)包，一直發(fā)送NAK控制包進(jìn)行重傳操作的現(xiàn)象。

假設(shè)當(dāng)前傳輸?shù)奈募笮镈，網(wǎng)卡接收速度為Snet，CPU的處理速度為Scpu，不考慮丟包重傳，接收時間可以表示為D/Snet，當(dāng)Scpu

當(dāng)文件較小時(即D比較小時)，系統(tǒng)默認(rèn)的緩存大小可以滿足傳輸需求不會發(fā)生丟包；當(dāng)文件較大時，就會有持續(xù)的數(shù)據(jù)流量，導(dǎo)致所需緩存大小增大，系統(tǒng)的默認(rèn)配置已無法滿足需求導(dǎo)致數(shù)據(jù)包被丟棄。

在Linux系統(tǒng)中可以通過調(diào)整不同階段的參數(shù)緩解丟包現(xiàn)象。首先，可以使用ethtool命令修改網(wǎng)卡配置，增大環(huán)形緩沖區(qū)的大小。其次，Linux的內(nèi)核參數(shù)配置可以寫在sysctl.conf文件中以達(dá)到修改接收數(shù)據(jù)包最大內(nèi)存的目的，其中參數(shù)rmem_max表示最大接收數(shù)據(jù)包的內(nèi)存大小。最后，UDT接收程序則提供了兩個API函數(shù)接口：UDT_RCVBUF和UDP_RCVBUF來設(shè)置UDT的接收緩存和UDP的接收緩存。

2.2 增強(qiáng)傳輸可靠性

這個部分我們解決的主要問題是分析為什么主機(jī)出現(xiàn)丟包時會引發(fā)超時重傳，分析UDT可靠機(jī)制存在的問題，減少超時重傳的次數(shù)。

2.2.1UDT可靠機(jī)制

在最新的UDT4.0版本中，發(fā)送方和接收方各自維持一個丟失列表，接收方丟失數(shù)據(jù)包的集合用RLL={l1,l2,…,ln}表示，發(fā)送方丟失數(shù)據(jù)包的集合用SLL={l1,l2,…,lm}表示，li表示丟失數(shù)據(jù)包的序列號。

當(dāng)數(shù)據(jù)包到達(dá)接收方后，首先檢測是否發(fā)生丟包事件，在UDT協(xié)議中，接收方會記錄已接收到的最大數(shù)據(jù)包的編號smax。如果當(dāng)前接收到的數(shù)據(jù)包的序列號si>smax+1，則表明出現(xiàn)丟包，此時更新smax為si，并將未接收到的數(shù)據(jù)包的序列號區(qū)間加入到丟失列表中，即：

RLL=RLL∪{smax+1,smax+2,…,si-1}

之后，接收方會發(fā)送NAK控制包告知發(fā)送方需要重傳的數(shù)據(jù)，相同的序號區(qū)間會加入到發(fā)送方丟失列表SLL中，并通過擁塞控制算法降低發(fā)送速度。當(dāng)丟失列表不為空時，發(fā)送方優(yōu)先發(fā)送丟失列表中的數(shù)據(jù)包，當(dāng)數(shù)據(jù)包一旦重傳成功，就將其從丟失列表SLL中刪除；同時當(dāng)接收方接收到數(shù)據(jù)包后，也將其序列號從RLL中刪除。

對萬兆網(wǎng)中使用UDT協(xié)議進(jìn)行傳輸?shù)那闆r分析，在未進(jìn)行系統(tǒng)優(yōu)化前，進(jìn)行大文件傳輸速度慢的原因是存在大量持續(xù)的丟包，并且一旦出現(xiàn)丟包，會有傳輸速度降低為0 bit/s并觸發(fā)超時重傳定時器的現(xiàn)象。由于網(wǎng)卡速度很快，在超時重傳操作之前，發(fā)送方已將發(fā)送窗口中的所有數(shù)據(jù)發(fā)送完畢，不再發(fā)送數(shù)據(jù)包，此時發(fā)送瞬時速度降為0 bit/s并持續(xù)到超時重傳定時器啟動。超時重傳的主要原因是發(fā)送窗口中的數(shù)據(jù)一直沒有收到確認(rèn)，對于丟失列表中的數(shù)據(jù)包，發(fā)送方只在丟包檢測的時候發(fā)送一次NAK控制包。當(dāng)鏈路狀況不好或者主機(jī)處理能力不夠的情況下，重傳的數(shù)據(jù)包發(fā)生丟包，而此時UDT協(xié)議沒有二次重傳的機(jī)制，從而導(dǎo)致超時重傳的現(xiàn)象。

2.2.2 改進(jìn)重傳機(jī)制

UDT協(xié)議存在兩種ACK控制包，一種是常規(guī)ACK控制包，常規(guī)ACK控制包是通過定時器觸發(fā)的，一般是0.01 s的間隔發(fā)送一次。這種ACK中包含較多的控制信息:確認(rèn)序列號、往返時延、UDT可用緩沖區(qū)大小、預(yù)估接收速度和鏈路容量等信息。另一種是輕量級ACK控制包，只包含確認(rèn)序列號，當(dāng)接收端接收到一定數(shù)量的數(shù)據(jù)包會發(fā)送一個輕量級ACK控制包用于確認(rèn)。

超時重傳使得大數(shù)據(jù)傳輸?shù)乃俣茸兟⒔禐? bit/s。根據(jù)傳輸過程分析發(fā)現(xiàn)，在發(fā)送方將發(fā)送窗口中的所有數(shù)據(jù)包發(fā)送完畢并等待接收方確認(rèn)期間，發(fā)送方會多次收到具有相同序列號的輕量級ACK控制包，這也是丟包的信號。但是UDT接收端只會在第一次判斷丟包時發(fā)送NAK控制包，發(fā)送端接收到的NAK控制包后會重傳數(shù)據(jù)。重傳的數(shù)據(jù)如果發(fā)生丟失，UDT接收端是沒有相應(yīng)機(jī)制發(fā)現(xiàn)的，因為UDT協(xié)議忽略了多次收到相同序列號的ACK控制包這個丟包信號。

我們提出改進(jìn)的UDT可靠性控制算法，能夠及時發(fā)現(xiàn)鏈路中丟失的二次重傳數(shù)據(jù)包，并充分利用ACK控制包信息，避免超時重傳。在算法中，當(dāng)接收端在發(fā)送一系列ACK控制包{ACK1,ACK2,…,ACKn}后，首先檢測當(dāng)前發(fā)送的ACK控制包是否與之前發(fā)送的相同，如果相同，記錄序列號相同次數(shù)的變量RAsame加1，否則，清零。使用TAsame表示發(fā)送相同ACK序列號次數(shù)的閾值，如果RAsame超過TAsame，則將RAsame清零并重傳RLL列表中的數(shù)據(jù)包，即發(fā)送NAK控制包(優(yōu)先選擇序列號小的連續(xù)的數(shù)據(jù)包)。當(dāng)發(fā)送方接收到NAK數(shù)據(jù)包后，重發(fā)丟失重傳的數(shù)據(jù)包。執(zhí)行過程如算法1所示。

算法1 改進(jìn)的UDT可靠性控制算法Input：aseriesofACKsequencenumbers{ACKi}whichthesenderhasreceived． thethresholdTAsame thetimesRAsameforeachACKiwhensenderreceivestheACKdo ifACKi=ACKi-1then RAsame++； else RAsame=0；foreachreceivedACKdo ifSLLisNULLthen ifRAsame>TAsamethen insertthepacketsequencenumberACKiintoSLL； RAsame=0；foreachpacketintheSLLdo retransmitthelostpacket；

2.3 提高CPU利用率

高速網(wǎng)絡(luò)傳輸?shù)钠款i在于CPU資源不足，在千兆網(wǎng)的環(huán)境中，單個UDT流和單個TCP流相比使用更多CPU的資源[8]，而在10 Gbit/s帶寬的網(wǎng)絡(luò)環(huán)境中，UDT協(xié)議將占用更多的CPU資源。由于UDT處理一個數(shù)據(jù)包代價較高，當(dāng)CPU的處理速度低于網(wǎng)卡的接收速度，數(shù)據(jù)包會暫存在緩沖區(qū)。在10 Gbit/s高速網(wǎng)絡(luò)進(jìn)行大文件傳輸時會有持續(xù)的大數(shù)據(jù)流量涌入主機(jī)，如果緩沖區(qū)容量較小，就會發(fā)生主機(jī)丟包的現(xiàn)象。因此需要適當(dāng)?shù)脑龃缶彌_區(qū)的大小，這也是我們要做系統(tǒng)調(diào)優(yōu)的原因。然而如果我們過度增大緩沖區(qū)，就會增大端到端的網(wǎng)絡(luò)時延，導(dǎo)致bufferbolat[18]的現(xiàn)象出現(xiàn)。

由于UDT協(xié)議是單進(jìn)程的，因而如果我們能夠提升單個CPU處理數(shù)據(jù)包的效率，對使用高速網(wǎng)絡(luò)傳輸大數(shù)據(jù)的性能將會有很大的提升。處理數(shù)據(jù)包的開銷主要包含以下三個方面[16]：系統(tǒng)調(diào)用代價、內(nèi)存拷貝和動態(tài)內(nèi)存分配。由于UDT協(xié)議是應(yīng)用層協(xié)議，下層使用的是操作系統(tǒng)的TCP/IP協(xié)議棧，netmap和DPDK作為高性能的數(shù)據(jù)包快速處理架構(gòu)，可以替代原用操作系統(tǒng)的協(xié)議棧達(dá)到優(yōu)化的目的。而在應(yīng)用層，我們可以通過減少處理數(shù)據(jù)包的代價進(jìn)一步降低CPU的占用率。

在進(jìn)行傳輸實(shí)驗的過程中，我們觀察CPU的使用情況可以看到其中一個CPU的利用率高達(dá)99%，并通過工具獲取執(zhí)行一次文件傳輸所消耗的時間、花費(fèi)在用戶模式的CPU時間以及內(nèi)核模式的CPU時間。通過實(shí)驗我們發(fā)現(xiàn)，完成一次大文件傳輸?shù)挠脩鬋PU時間和內(nèi)核CPU時間比約為1∶8。這表明在內(nèi)核中執(zhí)行系統(tǒng)調(diào)用所花費(fèi)的時間占很大比例，因此我們可以降低系統(tǒng)調(diào)用時間來減少UDT對數(shù)據(jù)包處理的代價。

通過跟蹤UDT接收端進(jìn)行文件傳輸所產(chǎn)生的系統(tǒng)調(diào)用情況，發(fā)現(xiàn)UDT接收方在運(yùn)行時有兩個線程：一個work線程負(fù)責(zé)從操作系統(tǒng)內(nèi)核提供的API接收數(shù)據(jù)，主要的系統(tǒng)調(diào)用是從UDP套接字中讀取數(shù)據(jù)；另一個是主線程，負(fù)責(zé)將接收到UDT數(shù)據(jù)包進(jìn)行分析并將其數(shù)據(jù)部分寫入到文件中，主要的系統(tǒng)調(diào)用函數(shù)是系統(tǒng)內(nèi)核提供的寫文件操作函數(shù)。

UDT接收端有兩個比較重要的數(shù)據(jù)結(jié)構(gòu)，接收環(huán)形隊列和接收緩沖區(qū)。worker線程將從內(nèi)核接收到的數(shù)據(jù)包放入接收隊列中，這時的數(shù)據(jù)包是包含UDT的頭部信息和數(shù)據(jù)的。通過分析UDT數(shù)據(jù)包的頭部信息，確定當(dāng)前數(shù)據(jù)所在文件的位置，并將數(shù)據(jù)保存在接收緩沖區(qū)中，數(shù)據(jù)緩沖區(qū)的數(shù)據(jù)是按序存放的，保證了的UDT傳輸?shù)目煽啃?。?shù)據(jù)從接收隊列到接收緩沖區(qū)的轉(zhuǎn)移在UDT協(xié)議中是指針的賦值操作，沒有進(jìn)行額外的內(nèi)存拷貝。接收隊列是一個環(huán)形隊列，保證了存儲的內(nèi)存空間可以循環(huán)利用，隊列空間是事先分配，只有當(dāng)空間不夠時，接收隊列的長度才會動態(tài)增加，因此，UDT協(xié)議的動態(tài)內(nèi)存分配的代價比較小。數(shù)據(jù)包接收的具體過程如圖2所示。

圖2 woker線程接收數(shù)據(jù)包的過程

以Linux環(huán)境為例，我們使用strace命令分析UDT接收文件時系統(tǒng)調(diào)用的具體過程。表1是我們傳輸150 MB大小的文件，UDT的兩個線程運(yùn)行時系統(tǒng)調(diào)用的分析結(jié)果。雖然使用系統(tǒng)調(diào)用分析工具會影響傳輸?shù)乃俣龋俏覀冎豢紤]各個操作所占比例，所以不會對分析結(jié)果造成很大的影響。

表1 150 MB文件傳輸系統(tǒng)調(diào)用統(tǒng)計表

如表1所示，UDT接收端每次處理的數(shù)據(jù)包大小是1 472字節(jié)，寫入文件大小是1 456字節(jié)(去除頭部信息)。兩個線程最主要的系統(tǒng)調(diào)用函數(shù)是writev和recvmsg，所占比例分別為99.61%和98.17%，這說明在UDT接收端接收數(shù)據(jù)包和寫文件的操作占用了大部分的系統(tǒng)資源。

假設(shè)ni表示每次系統(tǒng)調(diào)用寫入數(shù)據(jù)塊的大小，ti表示對應(yīng)每次系統(tǒng)調(diào)用的執(zhí)行時間，則將N字節(jié)數(shù)據(jù)寫入文件的總時間T可以表示為：

T=(N/ni)×ti

我們比較在不同數(shù)據(jù)塊大小下寫入相同數(shù)據(jù)到文件中所用的時間，如表2所示，寫入總字節(jié)數(shù)為1 456字節(jié)×64=93 184字節(jié)。

表2 寫操作執(zhí)行時間

從表2中我們可以看到，開始時，隨著ni成倍的增長，時間ti增長并不明顯，寫文件的總時間T下降明顯，但當(dāng)文件塊大于11 648字節(jié)的時候，寫文件總時間沒有很大的變化。

每次系統(tǒng)調(diào)用的時間ti由兩個部分組成：中斷響應(yīng)時間和中斷處理時間：ti=interupti+processi，中斷響應(yīng)時間interupti一般是相對固定，而中斷處理時間processi則是與所寫文件大小相關(guān)。

如圖3所示，當(dāng)我們將ni從1 456增長到11 648時，寫文件的總時間T明顯的下降。這是因為當(dāng)所寫字節(jié)數(shù)比較少時，中斷響應(yīng)時間所占比例較大，減少中斷次數(shù)就會有很明顯的效果。而當(dāng)繼續(xù)增大ni時，總時間T沒有很大的變化，這是因為此時中斷處理時間占很大比例，中斷響應(yīng)時間的影響可以忽略。

圖3 系統(tǒng)調(diào)用所寫字節(jié)數(shù)與時間關(guān)系

將順序到達(dá)的數(shù)據(jù)包一起寫入到文件中，可以增大每次寫文件的數(shù)據(jù)塊，減少寫文件的系統(tǒng)調(diào)用次數(shù)，降低中斷響應(yīng)時間所占比例，提升CPU的利用率。原始UDT接收端在應(yīng)用層處理數(shù)據(jù)包時，首先是從隊列中找到一個空閑的單元存放數(shù)據(jù)包。然后再按序放在接收緩沖區(qū)中，數(shù)據(jù)包在物理上存放的位置與到達(dá)順序和空閑單元的位置有關(guān)，并不一定是連續(xù)的，因此無法將多個數(shù)據(jù)包合并到一起寫入到文件中。

我們提出一個算法可以將連續(xù)到達(dá)固定數(shù)目的數(shù)據(jù)包連續(xù)存儲。首先設(shè)置FP為每次寫入到文件中的最大數(shù)據(jù)包的個數(shù)，并對于每一個環(huán)形隊列的元素，申請一塊連續(xù)的內(nèi)存區(qū)域，固定大小為FP×數(shù)據(jù)包大小。然后，當(dāng)接收方收到FP個序號連續(xù)的數(shù)據(jù)包，將其存儲到環(huán)形隊列的一個單元中，并通過一次寫文件系統(tǒng)調(diào)用將數(shù)據(jù)包寫入到文件中。當(dāng)數(shù)據(jù)包不是連續(xù)到達(dá)，即出現(xiàn)了丟包或者重傳時，先假設(shè)要接收到的數(shù)據(jù)包是順序到達(dá)，將它臨時順序存放在隊列中，然后找到合適的空閑隊列存放。數(shù)據(jù)包存放好之后，會將連續(xù)存儲的數(shù)據(jù)區(qū)域鏈接到數(shù)據(jù)緩沖區(qū)中，并記錄每個區(qū)域有效數(shù)據(jù)個數(shù)，最后將數(shù)據(jù)緩沖區(qū)中的數(shù)據(jù)寫入到文件中。圖4顯示，當(dāng)FP=4時，數(shù)據(jù)包的接收過程，一般而言，在鏈路條件好的情況下，數(shù)據(jù)大部分是按序到達(dá)接收端的。

圖4 FP為4時數(shù)據(jù)包的接收過程

在UDT協(xié)議中，接收端的worker負(fù)責(zé)將接收到的數(shù)據(jù)包先暫存在隊列中，然后再鏈接到接收緩存中。在A-UDT中，環(huán)形隊列的每個單元會有一個標(biāo)記位，這個標(biāo)記位用來指示到達(dá)的數(shù)據(jù)包是否是順序存儲的，1表示數(shù)據(jù)包序號連續(xù)，0表示不連續(xù)。在處理最新到達(dá)的數(shù)據(jù)包時，先將這個數(shù)據(jù)包存儲在之前接收的數(shù)據(jù)包后面，之后比較這個數(shù)據(jù)包的序列號和當(dāng)前已接收數(shù)據(jù)包的最新序列號。如果連續(xù)，不做操作，如果不連續(xù)，將這個數(shù)據(jù)包重新分配到一塊新的固定空間中，將標(biāo)記位置為0，并將之前連續(xù)的存儲空間鏈接到接收緩存區(qū)中。

在主線程中，我們會將接收緩存中的數(shù)據(jù)順序?qū)懭氲轿募?。首先需要找到?biāo)記位為0的位置，這表示連續(xù)存儲的開始位置，再計算這塊連續(xù)存儲區(qū)域的大小，如果后續(xù)的數(shù)據(jù)包標(biāo)記為1，則將這個數(shù)據(jù)包的大小加入到總和中。如果后續(xù)的數(shù)據(jù)包是0，則將之前的數(shù)據(jù)寫入到文件中，更新記錄的起始位置，并將統(tǒng)計連續(xù)數(shù)據(jù)包大小總和置為0。將數(shù)據(jù)包放入到接收緩存區(qū)的過程描述如算法2所示。

算法2 接收緩沖區(qū)接收過程input：aseriesofpackets{Pi}theserverreceived，andtheirse?quencenumbersSanddatapartD． aseriesofunitsofthequeue{Ui}andtheircontinuousflagCF thefixedvalueofcontinuouspacketsFP thepriorpacket ssequencenumberstoredinthequeueLRSinitializethecontinuousflagofeveryunitinthequeueforeachunitin{Ui}do Ui．CF=0；foreachpacketPireceivedbyserverdogetNextAvailUnitUiforPi；Ui．CF=1；ifPi．S=LRS+1then UiintosetofContinuousUnits{CUi}；ifthesizeof{CUi}==FPthen foreachCUiinthe{CUi}do calculatetheoffsetintheRcvBuffer； addthepointertoRcvBuffer； clear{CUi}；else reallocatetheUnitUiforPi； Ui．CF=1； Ui．CF=0； releasetheUi； foreachCUiinthe{CUi}do calculatetheoffsetintheRcvBuffer； addthepointertoRcvBuffer； clear{CUi}andaddUiinto{CUj}；LRS=Pi．S

將接收緩沖區(qū)的數(shù)據(jù)包寫入文件的過程如算法3所示。

算法3 數(shù)據(jù)包寫入文件input：aseriesofRcvBufferpointerspointingtolocationofpacketunits{RPi}→{Ui}foreachunitin{RPi}do do addRPi？Uito{CUi}； i++； calculatethesumofpacketslengthPL； whileRPi？Ui．CF=1； foreach{{CUi}，{CUi+1}，…，{CUj}}do findthestartlocationofthispartSP； writeSPtoSP+PLtothefile； clearthe{CUi}； updateSP； setPL==0；

3 實(shí)驗結(jié)果與性能評估

在這個部分，我們將驗證A-UDT協(xié)議的有效性，評估A-UDT協(xié)議在高速網(wǎng)絡(luò)傳輸中的傳輸性能。

3.1 物理實(shí)驗環(huán)境

實(shí)驗環(huán)境如圖5所示。交換機(jī)之間的鏈路帶寬是10 Gbit/s的帶寬，鏈路時延為0.3 ms，接收方和發(fā)送方的服務(wù)器配置是相同的。網(wǎng)卡是BRCM 10 Gbit/s適配器，CPU是Intel Xeon E5-2620系列2.40 GHz，監(jiān)控服務(wù)器所連交換機(jī)的端口，做了端口鏡像，可以旁路式監(jiān)控接收方和發(fā)送方流進(jìn)和流出的數(shù)據(jù)包。服務(wù)器安裝的系統(tǒng)是CentOS7，內(nèi)核版本是Linux version 3.10.0。

圖5 實(shí)驗環(huán)境拓?fù)鋱D

3.2 系統(tǒng)調(diào)優(yōu)

通過適當(dāng)?shù)卦黾酉到y(tǒng)緩存大小可以提高UDT傳輸?shù)男阅?。在主機(jī)端，數(shù)據(jù)包最先到達(dá)網(wǎng)卡，因而，首先增大網(wǎng)卡環(huán)形緩沖區(qū)大小。然后，增大內(nèi)核的數(shù)據(jù)包接收緩沖區(qū)，通過測試設(shè)置一系列rmem_max的值發(fā)現(xiàn)，在當(dāng)前環(huán)境下，當(dāng)緩沖區(qū)大小設(shè)置不小于224Byte時，UDT在傳輸過程中的丟包現(xiàn)象就可以得到有效緩解。最后，在初始化套接字接口時，需要設(shè)置UDT接收緩存的大小和UDP接收緩存的大小，并且兩個值需要設(shè)置為相同，實(shí)驗表明將其設(shè)為108Byte可以滿足其需求。

netsniff-ng是一個高性能的網(wǎng)絡(luò)包分析工具，支持?jǐn)?shù)據(jù)包的捕獲、過濾和分析，可以用來測試網(wǎng)絡(luò)的性能和吞吐率。ifpps是netsniff的一個組件，提供Linux內(nèi)核的網(wǎng)絡(luò)和系統(tǒng)統(tǒng)計工具。借助上述工具，對使用UDT工具傳輸5 GB大小文件的過程進(jìn)行分析，其結(jié)果如圖6所示。從圖6中可以看出，經(jīng)過系統(tǒng)調(diào)優(yōu)，UDT可以獲得更高的吞吐率，并且平均傳輸速度從2 500 Mbit/s提升至5 000 Mbit/s。

圖6 傳輸5 GB文件系統(tǒng)調(diào)優(yōu)前后對比

3.3 增強(qiáng)傳輸?shù)目煽啃?/h3>

這個實(shí)驗比較了UDT接收端原生的可靠性算法和改進(jìn)可靠性算法的性能。我們傳輸了20 GB大小的文件，并且ifpps工具記錄不同時刻的傳輸速率，結(jié)果如圖7所示。圖中結(jié)果表明了改進(jìn)后的可靠性算法，丟包對重傳的性能影響更小，傳輸曲線更加平穩(wěn)。

圖7 增強(qiáng)傳輸可靠性傳輸曲線對比

3.4 優(yōu)化CPU的利用率

CPU被認(rèn)為是高速網(wǎng)絡(luò)傳輸?shù)钠款i，UDT協(xié)議是應(yīng)用層的協(xié)議，我們采用減少寫文件的系統(tǒng)調(diào)用次數(shù)來優(yōu)化應(yīng)用層處理時的CPU利用率。如2.3節(jié)所述，增大每次寫文件的塊大小，每次系統(tǒng)調(diào)用代價所占比例就會減小。通過之前的測試，可以看到增大每次寫固定大小數(shù)據(jù)包的個數(shù)，可以提高傳輸?shù)男阅?。但是如果一直增大，時間并不會有很大改變。另一方面，將很多數(shù)據(jù)包暫存在緩存隊列中，會造成寫延遲，也會造成UDT協(xié)議回復(fù)ACK不及時。通過測試，我們發(fā)現(xiàn)當(dāng)數(shù)目為8時，優(yōu)化效果最佳，且不會浪費(fèi)額外的緩存空間。

圖8顯示了UDT在優(yōu)化前和優(yōu)化后傳輸大文件時的穩(wěn)定速度，表明A-UDT可以實(shí)現(xiàn)更高的網(wǎng)絡(luò)的吞吐率。

圖8 提高CPU利用率的傳輸對比圖

4 結(jié) 語

本文分析了UDT協(xié)議在高速網(wǎng)絡(luò)中丟包的原因和傳輸瓶頸并提出了相應(yīng)的解決方案。通過系統(tǒng)調(diào)優(yōu)，可以看到丟包現(xiàn)象得到緩解傳輸速度顯著提升。另一方面，由于UDT協(xié)議的可靠性無法保證及時的二次重傳，丟包嚴(yán)重時會導(dǎo)致超時重傳，改進(jìn)的可靠性控制算法平滑了傳輸曲線，提升了傳輸速度。

高速網(wǎng)絡(luò)傳輸?shù)钠款i在于CPU，而UDT協(xié)議比TCP使用更多CPU資源。A-UDT協(xié)議通過減少寫文件的系統(tǒng)調(diào)用代價提高了CPU使用效率，使得在相同條件下，A-UDT協(xié)議實(shí)現(xiàn)了更高帶寬。

[1] 王元卓, 靳小龍, 程學(xué)旗. 網(wǎng)絡(luò)大數(shù)據(jù):現(xiàn)狀與展望[J]. 計算機(jī)學(xué)報, 2013, 36(6):1125- 1138.

[2] Dart E. The Science DMZ: a network design pattern for data-intensive science[C]// High Performance Computing, Networking, Storage and Analysis. IEEE, 2013:85.

[3] Calyam P, Berryman A, Saule E, et al. Wide-area overlay networking to manage science DMZ accelerated flows[C]// International Conference on Computing, Networking and Communications. IEEE, 2014:269- 275.

[4] Allcock W, Bresnahan J, Kettimuthu R, et al. The Globus Striped GridFTP Framework and Server[C]// Supercomputing, 2005. Proceedings of the ACM/IEEE SC 2005 Conference. IEEE, 2005:54.

[5] Fast Data Transfer: an Application for Efficient Data Transfers[OL]. http://monalisa.cern.ch/FDT/.

[6] Jin C, Wei D X, Low S H. FAST TCP: motivation, architecture, algorithms, performance[C]// Joint Conference of the IEEE Computer and Communications Societies. IEEE, 2004,4:2490- 2501.

[7] Galbraith J. SSH File Transfer Protocol (SFTP)[OL]. 2006.http://www. ietf. org/internet-drafts-ietf-secsh-fliexfer-12.txt.

[8] Gu Y, Grossman R L. UDT: UDP-based data transfer for high-speed wide area networks[M]. Elsevier North-Holland, Inc. 2007.

[9] Roskind J. QUIC(Quick UDP Internet Connections): Multiplexed Stream Transport Over UDP[R]. Technical report, Google,2013.

[10] Floyd S, Henderson T. The NewReno Modification to TCP’s Fast Recovery Algorithm[J]. Expires, 1999, 345(2):414- 418.

[11] Yildirim E, Kim J, Kosar T. How GridFTP Pipelining, Parallelism and Concurrency Work: A Guide for Optimizing Large Dataset Transfers[C]// SC Companion: High Performance Computing, Networking Storage and Analysis. IEEE Computer Society, 2012:506- 515.

[12] Yun D, Wu C Q, Rao N S V, et al. Profiling transport performance for big data transfer over dedicated channels[C]// International Conference on Computing, Networking and Communications. IEEE, 2015:858- 862.

[13] Yun D, Wu C Q. An Integrated Transport Solution to Big Data Movement in High-Performance Networks[C]// IEEE, International Conference on Network Protocols. IEEE, 2015:460- 462.

[14] Yu S Y, Brownlee N, Mahanti A. Comparative performance analysis of high-speed transfer protocols for big data[C]// Local Computer Networks. IEEE, 2013:292- 295.

[15] Gallenmuller S, Emmerich P, Wohlfart F, et al. Comparison of frameworks for high-performance packet IO[C]// Eleventh Acm/ieee Symposium on Architectures for Networking & Communications Systems. IEEE, 2015:29- 38.

[16] Rizzo L. Netmap: a novel framework for fast packet I/O[C]// Usenix Conference on Technical Conference. USENIX Association, 2012:9- 9.

[17] Intel Corporation. Impressive Packet Processing Performance Enables Greater Workload Consolidation[R]. Intel Solution Brief, 2013.

[18] Gettys J, Nichols K. Bufferbloat: Dark Buffers in the Internet[J]. IEEE Internet Computing, 2011, 15(3):96.