高速網(wǎng)絡(luò)環(huán)境中適合大數(shù)據(jù)傳輸?shù)母倪M(jìn)UDT協(xié)議

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

0 引 言

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

目前，研究者提出了很多改進(jìn)的傳輸協(xié)議用來(lái)提高大數(shù)據(jù)在廣域網(wǎng)上的傳輸性能。ESnet[2-3]科學(xué)網(wǎng)使用GridFTP協(xié)議即Globus Toolkit組件之一，實(shí)現(xiàn)兩臺(tái)主機(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ú)法充分利用網(wǎng)絡(luò)帶寬。在TCP協(xié)議中，速率控制和擁塞控制是以丟包作為控制的信號(hào)，因而，丟包將對(duì)TCP傳輸速度產(chǎn)生很大的影響[10]。在鏈路條件較好的情況下，這種自誘導(dǎo)式丟包數(shù)會(huì)超過(guò)其他原因的丟包，使得傳輸無(wú)法獲得平穩(wěn)的速度。而在廣域網(wǎng)的環(huán)境中，網(wǎng)絡(luò)環(huán)境復(fù)雜，丟包可能因?yàn)槎喾N情況，并非一定是帶寬的限制，因而這種方式將導(dǎo)致對(duì)網(wǎng)絡(luò)擁塞狀況估計(jì)的誤判，而基于TCP的高速網(wǎng)絡(luò)傳輸協(xié)議會(huì)繼承TCP協(xié)議的相關(guān)特性。GridFTP協(xié)議有三個(gè)重要的參數(shù)：并行、并發(fā)和管道[11]，并通過(guò)并行TCP數(shù)據(jù)流充滿網(wǎng)絡(luò)帶寬，但多個(gè)TCP流在一方面會(huì)加重網(wǎng)絡(luò)負(fù)擔(dān)，造成網(wǎng)絡(luò)資源的競(jìng)爭(zhēng)，引起不必要的重傳，使得帶寬資源浪費(fèi)。另一方面主機(jī)端在處理時(shí)需要使用更多的CPU資源和內(nèi)存資源來(lái)維護(hù)每個(gè)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ā)送包對(duì)的技術(shù)對(duì)帶寬進(jìn)行預(yù)測(cè)，將基于速率的擁塞控制和基于窗口的流控機(jī)制相結(jié)合，實(shí)現(xiàn)高速網(wǎng)絡(luò)的可靠傳輸。在UDT的架構(gòu)中，可以實(shí)現(xiàn)定制化的擁塞避免策略和流控機(jī)制來(lái)滿足不同網(wǎng)絡(luò)條件下的傳輸控制而不用修改操作系統(tǒng)內(nèi)核代碼。

在千兆網(wǎng)環(huán)境中，未優(yōu)化的UDT協(xié)議在吞吐率、公平性、TCP友好性以及穩(wěn)定性等方面具有良好的性能，但是與TCP協(xié)議相比會(huì)占有更高的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和存儲(chǔ)速度。

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

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

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

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

1 相關(guān)工作

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

文獻(xiàn)[15]指出在高速網(wǎng)絡(luò)的環(huán)境中，操作系統(tǒng)網(wǎng)絡(luò)協(xié)議棧處理數(shù)據(jù)包的速度已經(jīng)無(wú)法與網(wǎng)卡速度相適配，CPU是限制主機(jī)傳輸速度的主要瓶頸。Luigi Rizzo等[16]提出了一種高效的收發(fā)數(shù)據(jù)包的框架netmap，與傳統(tǒng)Linux網(wǎng)絡(luò)協(xié)議棧不同，它主要從三個(gè)方面減少數(shù)據(jù)包的處理代價(jià)：數(shù)據(jù)包動(dòng)態(tài)內(nèi)存分配、減少系統(tǒng)調(diào)用代價(jià)和內(nèi)存拷貝次數(shù)。通過(guò)這些優(yōu)化netmap提高了CPU的利用率，提升了數(shù)據(jù)包的收發(fā)處理速度。實(shí)驗(yàn)結(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可以繞過(guò)傳統(tǒng)的Linux協(xié)議棧，將數(shù)據(jù)包直接存放在用戶態(tài)空間，極大地減少了接收數(shù)據(jù)包時(shí)系統(tǒng)調(diào)用和內(nèi)存拷貝次數(shù)。DPDK的優(yōu)化效果很好，但是如果用戶選擇使用DPDK，就需要實(shí)現(xiàn)TCP和UDP協(xié)議來(lái)滿足應(yīng)用層協(xié)議的需求。

2 Advanced UDT

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

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

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

3) UDT協(xié)議占用過(guò)多的CPU資源問(wèn)題。

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

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

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

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

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

根據(jù)之前對(duì)數(shù)據(jù)包在接收方的接收流程的分析可以得出，數(shù)據(jù)從鏈路上獲取之后，會(huì)暫存在不同的緩存隊(duì)列中等待下一步的處理，數(shù)據(jù)包的處理需要獲取CPU資源。當(dāng)CPU不足以處理高速網(wǎng)絡(luò)的傳輸流量時(shí)，數(shù)據(jù)包會(huì)在緩沖區(qū)累積，當(dāng)超過(guò)緩沖區(qū)的容量時(shí)，數(shù)據(jù)包就會(huì)被丟棄，造成鏈路中沒(méi)有發(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，不考慮丟包重傳，接收時(shí)間可以表示為D/Snet，當(dāng)Scpu

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

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

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

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

2.2.1UDT可靠機(jī)制

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

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

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

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

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

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

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

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

我們提出改進(jìn)的UDT可靠性控制算法，能夠及時(shí)發(fā)現(xiàn)鏈路中丟失的二次重傳數(shù)據(jù)包，并充分利用ACK控制包信息，避免超時(shí)重傳。在算法中，當(dāng)接收端在發(fā)送一系列ACK控制包{ACK1,ACK2,…,ACKn}后，首先檢測(cè)當(dāng)前發(fā)送的ACK控制包是否與之前發(fā)送的相同，如果相同，記錄序列號(hào)相同次數(shù)的變量RAsame加1，否則，清零。使用TAsame表示發(fā)送相同ACK序列號(hào)次數(shù)的閾值，如果RAsame超過(guò)TAsame，則將RAsame清零并重傳RLL列表中的數(shù)據(jù)包，即發(fā)送NAK控制包(優(yōu)先選擇序列號(hào)小的連續(xù)的數(shù)據(jù)包)。當(dāng)發(fā)送方接收到NAK數(shù)據(jù)包后，重發(fā)丟失重傳的數(shù)據(jù)包。執(zhí)行過(guò)程如算法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)境中，單個(gè)UDT流和單個(gè)TCP流相比使用更多CPU的資源[8]，而在10 Gbit/s帶寬的網(wǎng)絡(luò)環(huán)境中，UDT協(xié)議將占用更多的CPU資源。由于UDT處理一個(gè)數(shù)據(jù)包代價(jià)較高，當(dāng)CPU的處理速度低于網(wǎng)卡的接收速度，數(shù)據(jù)包會(huì)暫存在緩沖區(qū)。在10 Gbit/s高速網(wǎng)絡(luò)進(jìn)行大文件傳輸時(shí)會(huì)有持續(xù)的大數(shù)據(jù)流量涌入主機(jī)，如果緩沖區(qū)容量較小，就會(huì)發(fā)生主機(jī)丟包的現(xiàn)象。因此需要適當(dāng)?shù)脑龃缶彌_區(qū)的大小，這也是我們要做系統(tǒng)調(diào)優(yōu)的原因。然而如果我們過(guò)度增大緩沖區(qū)，就會(huì)增大端到端的網(wǎng)絡(luò)時(shí)延，導(dǎo)致bufferbolat[18]的現(xiàn)象出現(xiàn)。

由于UDT協(xié)議是單進(jìn)程的，因而如果我們能夠提升單個(gè)CPU處理數(shù)據(jù)包的效率，對(duì)使用高速網(wǎng)絡(luò)傳輸大數(shù)據(jù)的性能將會(huì)有很大的提升。處理數(shù)據(jù)包的開(kāi)銷主要包含以下三個(gè)方面[16]：系統(tǒng)調(diào)用代價(jià)、內(nèi)存拷貝和動(dòng)態(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)用層，我們可以通過(guò)減少處理數(shù)據(jù)包的代價(jià)進(jìn)一步降低CPU的占用率。

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

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

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

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

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

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

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

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

T=(N/ni)×ti

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

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

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

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

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

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

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

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

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

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

在主線程中，我們會(huì)將接收緩存中的數(shù)據(jù)順序?qū)懭氲轿募小Ｊ紫刃枰业綐?biāo)記位為0的位置，這表示連續(xù)存儲(chǔ)的開(kāi)始位置，再計(jì)算這塊連續(xù)存儲(chǔ)區(qū)域的大小，如果后續(xù)的數(shù)據(jù)包標(biāo)記為1，則將這個(gè)數(shù)據(jù)包的大小加入到總和中。如果后續(xù)的數(shù)據(jù)包是0，則將之前的數(shù)據(jù)寫(xiě)入到文件中，更新記錄的起始位置，并將統(tǒng)計(jì)連續(xù)數(shù)據(jù)包大小總和置為0。將數(shù)據(jù)包放入到接收緩存區(qū)的過(guò)程描述如算法2所示。

算法2 接收緩沖區(qū)接收過(guò)程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ù)包寫(xiě)入文件的過(guò)程如算法3所示。

算法3 數(shù)據(jù)包寫(xiě)入文件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í)驗(yàn)結(jié)果與性能評(píng)估

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

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

實(shí)驗(yàn)環(huán)境如圖5所示。交換機(jī)之間的鏈路帶寬是10 Gbit/s的帶寬，鏈路時(shí)延為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í)驗(yàn)環(huán)境拓?fù)鋱D

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

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

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

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

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

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

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

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

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

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

圖8 提高CPU利用率的傳輸對(duì)比圖

4 結(jié) 語(yǔ)

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

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

[1] 王元卓, 靳小龍, 程學(xué)旗. 網(wǎng)絡(luò)大數(shù)據(jù):現(xiàn)狀與展望[J]. 計(jì)算機(jī)學(xué)報(bào), 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.