• <tr id="yyy80"></tr>
  • <sup id="yyy80"></sup>
  • <tfoot id="yyy80"><noscript id="yyy80"></noscript></tfoot>
  • 99热精品在线国产_美女午夜性视频免费_国产精品国产高清国产av_av欧美777_自拍偷自拍亚洲精品老妇_亚洲熟女精品中文字幕_www日本黄色视频网_国产精品野战在线观看 ?

    面向數(shù)據(jù)中心網(wǎng)絡(luò)的高速數(shù)據(jù)傳輸技術(shù)

    2016-11-29 03:42:25秦宣龍李大剛陳遠(yuǎn)磊
    軟件 2016年9期
    關(guān)鍵詞:以太網(wǎng)數(shù)據(jù)中心傳輸

    秦宣龍,李大剛,都 政,陳遠(yuǎn)磊

    (1. 北京大學(xué)深圳研究生院 信息工程學(xué)院,廣東深圳 518055;2. 國家超級計(jì)算深圳中心(深圳云計(jì)算中心)高性能計(jì)算部,廣東深圳 518055)

    面向數(shù)據(jù)中心網(wǎng)絡(luò)的高速數(shù)據(jù)傳輸技術(shù)

    秦宣龍1,李大剛1,都政2,陳遠(yuǎn)磊2

    (1. 北京大學(xué)深圳研究生院 信息工程學(xué)院,廣東深圳518055;2. 國家超級計(jì)算深圳中心(深圳云計(jì)算中心)高性能計(jì)算部,廣東深圳518055)

    數(shù)據(jù)中心是云計(jì)算和大數(shù)據(jù)應(yīng)用的基礎(chǔ)設(shè)施,目前數(shù)據(jù)中心網(wǎng)絡(luò)基本都是采用TCP/IP協(xié)議并基于以太網(wǎng)技術(shù)搭建。隨著以太網(wǎng)的提速,TCP/IP協(xié)議及其實(shí)現(xiàn)方式已經(jīng)無法適應(yīng)高速數(shù)據(jù)傳輸?shù)男枨?,成為網(wǎng)絡(luò)性能進(jìn)一步增長的瓶頸。在分析了現(xiàn)有數(shù)據(jù)中心網(wǎng)絡(luò)的特點(diǎn)以及網(wǎng)絡(luò)實(shí)現(xiàn)的開銷和性能之后,文章對多種網(wǎng)絡(luò)性能優(yōu)化技術(shù)進(jìn)行了比對和總結(jié),并且分析了下一步的研究方向。

    TCP;數(shù)據(jù)中心網(wǎng)絡(luò);以太網(wǎng);RDMA

    本文著錄格式:秦宣龍,李大剛,都政,等. 面向數(shù)據(jù)中心網(wǎng)絡(luò)的高速數(shù)據(jù)傳輸技術(shù)[J]. 軟件,2016,37(9):01-07

    0 引言

    隨著云計(jì)算和大數(shù)據(jù)應(yīng)用的不斷發(fā)展,互聯(lián)網(wǎng)中的計(jì)算和存儲服務(wù)越來越依賴于數(shù)據(jù)中心。近年來國內(nèi)許多學(xué)者針對數(shù)據(jù)中心在不同場景之下的應(yīng)用也展開了廣泛研究[30-33]。數(shù)據(jù)中心大多基于成熟且廉價(jià)的服務(wù)器和以太網(wǎng)設(shè)備搭建,采用廣泛使用的TCP/IP協(xié)議來完成數(shù)據(jù)的傳輸。隨著以太網(wǎng)技術(shù)的快速發(fā)展以及數(shù)據(jù)中心應(yīng)用對網(wǎng)絡(luò)性能需求不斷上升,通常我們通過帶寬、延遲和CPU占有率來作為性能指標(biāo),而TCP越來越成為數(shù)據(jù)傳輸?shù)男阅芷款i。TCP主要帶來兩個(gè)方面的問題,首先是數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中遇到的挑戰(zhàn)。TCP的傳輸控制機(jī)制依賴于端到端反饋,并采用重傳機(jī)制來實(shí)現(xiàn)可靠傳輸,對數(shù)據(jù)中心常見的短流來講調(diào)整過于緩慢;再加上慢啟動(dòng)和丟包時(shí)的速率減半帶來的流量劇烈變化,其過于繁雜的算法機(jī)制并不適用于數(shù)據(jù)中心高帶寬低延遲的情況,對于網(wǎng)絡(luò)性能而言這都是需要提升和解決的問題。另一個(gè)方面整個(gè)TCP/IP協(xié)議棧在主機(jī)端都是通過Socket軟件實(shí)現(xiàn),整個(gè)數(shù)據(jù)傳輸過程需要CPU的參與,在高包速率情況下會大量占用CPU時(shí)間,甚至使得CPU變成數(shù)據(jù)傳輸?shù)钠款i。另外在Socket的架構(gòu)下數(shù)據(jù)會在系統(tǒng)內(nèi)存、處理器緩存和網(wǎng)卡緩存之間來回進(jìn)行拷貝,給服務(wù)器的CPU和內(nèi)存帶來嚴(yán)重的負(fù)擔(dān)。這些因素都會造成數(shù)據(jù)中心網(wǎng)絡(luò)性能受損,為此研究者們嘗試了不同思路來解決這個(gè)問題。首先提出了對TCP協(xié)議的優(yōu)化,Jeonghoon[19]提出了TCP速率調(diào)整的算法,Hammann[20][27]提出了ECN標(biāo)記算法,Tang[21]提出了DMA零拷貝技術(shù)等等,這些對TCP和主機(jī)端的改進(jìn)在一定程度上都改善了傳輸性能。

    為了更進(jìn)一步提升數(shù)據(jù)中心網(wǎng)絡(luò)性能,本文綜述了目前常見的網(wǎng)絡(luò)性能優(yōu)化方式,第二章節(jié)論述了在保持?jǐn)?shù)據(jù)中心網(wǎng)絡(luò)整體架構(gòu)不變的情況下采用硬件實(shí)現(xiàn)來提速網(wǎng)絡(luò)處理能力的典型技術(shù)。在第三章節(jié)論述了從網(wǎng)絡(luò)協(xié)議優(yōu)化的角度來針對性地改進(jìn)數(shù)據(jù)中心網(wǎng)絡(luò)傳輸性能的主要方法。第四章節(jié)更進(jìn)一步論述了將RDMA技術(shù)引入以太網(wǎng)架構(gòu)的主要方案及其特點(diǎn)。最后進(jìn)行了總結(jié)。

    1 TCP硬件加速方案

    隨著以太網(wǎng)的速度提升,帶來更高的帶寬,但是TCP/IP協(xié)議是無法滿足高帶寬下數(shù)據(jù)中心網(wǎng)絡(luò)的高帶寬、低延遲,低CPU占有率等需求的,這些標(biāo)準(zhǔn)也是對網(wǎng)絡(luò)性能的衡量方式,而且TCP協(xié)議在主機(jī)端的處理占用了大量CPU,當(dāng)包處理量很高的時(shí)候?qū)W(wǎng)絡(luò)性能影響極大,在這一部分如果做到進(jìn)一步優(yōu)化,那對網(wǎng)絡(luò)性能是一個(gè)極大的好處,考慮到硬件的處理速度快,使用硬件來處理部分TCP協(xié)議會對性能有一個(gè)極大的提升。

    1.1TCP引擎卸載技術(shù)(TCP offload engine, TOE)

    TOE是基于傳統(tǒng)以太網(wǎng)結(jié)構(gòu)下的一種TCP加速技術(shù),由于數(shù)據(jù)在主機(jī)內(nèi)的來回拷貝,中斷處理給CPU帶來過高的負(fù)載,TOE技術(shù)的中心思想是利用硬件來分擔(dān)CPU對TCP/IP協(xié)議的處理所造成負(fù)擔(dān),其做法就是將部分TCP協(xié)議遷移至網(wǎng)卡中減少主機(jī)上CPU對協(xié)議棧的校驗(yàn)和檢查等處理的需求,減少系統(tǒng)總線之間的數(shù)據(jù)復(fù)制,在處理程序的時(shí)候和傳統(tǒng)的網(wǎng)卡每發(fā)送一個(gè)數(shù)據(jù)包就中斷一次不同,它通過運(yùn)行一個(gè)完整的數(shù)據(jù)處理進(jìn)程后才觸發(fā)一次中端,以此來減少主機(jī)CPU的中斷次數(shù),通過上述的方式TOE大大提升了TCP/IP的效率。

    K. Kant[7]對比了使用TOE和不使用TOE情況下網(wǎng)絡(luò)的吞吐率,在傳輸速度越快的網(wǎng)絡(luò)下吞吐率提升就越明顯。

    W. Feng[8]在MTU為1500和9000的情況下對比了延遲,在兩種情況下TOE對延遲都只提高了2微秒左右,但是對CPU的占有率下降非常大。尤其是在多服務(wù)器和多流的情況下帶寬從無TOE的3000 Mbps上升到7000Mbps.

    Jeffrey[9]從基本性能和部署兩個(gè)問題上描述了TOE并不是很適合現(xiàn)有的網(wǎng)絡(luò)。作者指出TOE作為一種TCP改進(jìn)方式無疑是成功的,但是在實(shí)際上性能和各方面因素卻導(dǎo)致了他日漸衰退的趨勢。

    首先從基本性能上來說,由于TOE是硬件上的實(shí)現(xiàn),其更新?lián)Q代的速度可能比不上CPU性能的增加速度,通過硬件做TCP引擎卸載代價(jià)過大,Sarker[10]指出現(xiàn)在的NIC系統(tǒng)產(chǎn)品速度可能還不夠快,TOE會影響到真實(shí)環(huán)境下的性能甚至增加延遲,同時(shí)由于網(wǎng)卡和主機(jī)接口的復(fù)雜性,不兼容性,短時(shí)間的TCP連接都會導(dǎo)致浪費(fèi)額外的性能。從部署上來說,基于RAM的可用性TOE可能會有些許限制,使其擴(kuò)展性受損,同時(shí)由于硬件出現(xiàn)問題導(dǎo)致的錯(cuò)誤以及質(zhì)量問題都很難保證。

    1.2Intel加速技術(shù)(intel acceleration technology, IOAT/IOAT2)

    從TOE的思想出發(fā),使用硬件來減少CPU的占有率是一個(gè)可行的方法,從多個(gè)角度去降低整個(gè)系統(tǒng)花費(fèi)對網(wǎng)絡(luò)性能提升必然更加有優(yōu)勢,IOAT就是為此提出的。

    IOAT(intel acceleration technology)也是Intel為了應(yīng)對網(wǎng)絡(luò)I/O瓶頸,IOAT是第一代intel I/O加速技術(shù),是一種平臺化策略,因特爾I/O加速技術(shù)表達(dá)了“以應(yīng)用為中心的服務(wù)器觀點(diǎn)”,即I/OAT是將整個(gè)平臺的整體優(yōu)化作為解決I/O開銷的方案。

    Intel I/OAT分析了現(xiàn)有操作系統(tǒng)帶來的問題,提出了從三個(gè)方面進(jìn)行優(yōu)化:

    · 降低系統(tǒng)開銷(System overhead)

    · 實(shí)現(xiàn)流線型內(nèi)存訪問(Memory access)

    · 優(yōu)化TCP/IP協(xié)議計(jì)算(TCP/IP processing)

    IOAT采用增強(qiáng)型的DMA技術(shù),在主機(jī)端加入了TOE的方式,使得在數(shù)據(jù)復(fù)制時(shí)的時(shí)間更少以提升CPU的利用率,同時(shí)也對TCP協(xié)議進(jìn)行了改進(jìn),優(yōu)化數(shù)據(jù)包的分離,使得數(shù)據(jù)得到更快的處理。IOAT的優(yōu)化是整個(gè)系統(tǒng)可能在某一方面優(yōu)化的力度不夠,但是多個(gè)方位同步實(shí)現(xiàn),確實(shí)提供了更加高效的網(wǎng)絡(luò)數(shù)據(jù)傳輸。I/OAT作為一項(xiàng)開源技術(shù)對硬件的支持需求很高,還需要操作系統(tǒng)和特殊的驅(qū)動(dòng)這些都是亟待考慮的問題。

    IOAT2在IOAT的基礎(chǔ)上增加了多端口,虛擬化,網(wǎng)絡(luò)存儲,應(yīng)用快速響應(yīng),增加了附加協(xié)議,附加平臺級加速,增加了高級緩存訪問(DCA),MSI-X終端快速響應(yīng)等機(jī)制進(jìn)一步優(yōu)化整個(gè)平臺的性能。

    Intel公司[11]給出了在不使用優(yōu)化的狀態(tài)下CPU的利用率,文中可以看出I/O大小在8KB左右就出現(xiàn)了I/O瓶頸,系統(tǒng)開銷、內(nèi)存訪問和TCP處理對CPU利用率從60%下降到30%,在使用IOAT技術(shù)后,對比了IOAT和普通以太網(wǎng)下CPU的利用率,明顯可以看出CPU的占有率下降,而吞吐率上升。Intel公司[12]從性能上對IOAT技術(shù)與TOE技術(shù)進(jìn)行了論證與分析,在吞吐率和延遲上的性能IOAT都遠(yuǎn)勝于TOE,這兩種基于硬件優(yōu)化網(wǎng)絡(luò)性能的方式針對有特殊需求的網(wǎng)絡(luò)使很有意義的,但是對于目前傳統(tǒng)的以太網(wǎng)而言想要大規(guī)模部署代價(jià)過于高昂,研究者期望尋找一種在以太網(wǎng)架構(gòu)下獲得高質(zhì)量網(wǎng)絡(luò)的方式。

    2 面向數(shù)據(jù)中心的TCP協(xié)議優(yōu)化

    硬件帶來的網(wǎng)絡(luò)性能優(yōu)化是毋庸置疑的,但是部署起來過于麻煩,研究者們更希望在已有的軟件基礎(chǔ)上進(jìn)行優(yōu)化來獲得性能提升,為此首先要了解數(shù)據(jù)中心的流量結(jié)構(gòu)特征。

    數(shù)據(jù)中心內(nèi)部常用的網(wǎng)絡(luò)拓?fù)淙鐖D1所示,應(yīng)用數(shù)據(jù)在節(jié)點(diǎn)處來進(jìn)行頻繁交互,而數(shù)據(jù)中心的龐大流量會給節(jié)點(diǎn)帶來巨大的負(fù)載,從而引起丟包,吞吐量降低的問題,進(jìn)而可能會造成連接中斷,延遲上升,同時(shí)數(shù)據(jù)中心大量采用Partition/ Aggregate的工作模式,高層將自己的deadline分為若干片向下傳遞,由下層完成,而無法完成時(shí)則會放棄任務(wù),這帶來的時(shí)延代價(jià)和響應(yīng)問題是用戶無法接受的。

    尤其是在數(shù)據(jù)中心網(wǎng)絡(luò)中的短流的比例占90%,TCP Incast現(xiàn)象在高帶寬、低延遲,短流多的情況下更易發(fā)生,造成性能浪費(fèi)嚴(yán)重。

    但是傳統(tǒng)的TCP/IP協(xié)議是無法保證數(shù)據(jù)中心的性能的,由于TCP的“貪婪性”,TCP在發(fā)送流量是以盡最大可能交付,所以很有可能在傳輸過程中引發(fā)擁塞,TCP產(chǎn)生擁塞丟包后會進(jìn)行重發(fā),M.Allman[1]指出TCP在重傳初期會經(jīng)歷慢開始的階段,所以數(shù)據(jù)在傳輸時(shí)發(fā)生擁塞導(dǎo)致重傳,會使性能大幅下降,表現(xiàn)在交換機(jī)的隊(duì)列長度產(chǎn)生震蕩。同時(shí)因?yàn)槟壳暗慕粨Q機(jī)出于商業(yè)考慮大部分是淺緩存交換機(jī),而且其緩存是在端口間共享,因此某一個(gè)端口的短流很容易因?yàn)槿鄙倬彺媸艿狡渌丝诘拇罅鞯挠绊?,這都會大大增加數(shù)據(jù)傳輸在網(wǎng)絡(luò)的延遲。

    圖1 數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)圖

    而且針對TCP的突發(fā)流量其效果也并不好,所以對TCP協(xié)議的改進(jìn)就顯得很重要,本章詳細(xì)描述了DCTCP、D2TCP、L2DCT并進(jìn)行了總結(jié)。

    2.1DCTCP

    DCTCP使用了一個(gè)非常簡單的活動(dòng)管理隊(duì)列的機(jī)制,僅僅使用了標(biāo)記門限K這一個(gè)參數(shù),當(dāng)隊(duì)列的長度超過門限K就用CE標(biāo)記這個(gè)數(shù)據(jù)包,否則就不打標(biāo)記,這樣發(fā)送端就可以根據(jù)標(biāo)記的數(shù)據(jù)包的比例調(diào)整窗口的大小,當(dāng)標(biāo)記的值越多則下一次發(fā)送窗口就降低更多。

    M. Alizadeh[4]在文中得出的實(shí)驗(yàn)結(jié)果可以看出,在1Gbps的帶寬下TCP和DCTCP的吞吐量都在0.95Gps左右,鏈路利用率都接近100%,但是DCTCP的隊(duì)列長度基本保持在20個(gè)包左右,而TCP的隊(duì)列長度比DCTCP的十倍還要大,在帶寬為10Gbps下TCP算法的隊(duì)列長度抖動(dòng)的情況非常嚴(yán)重遠(yuǎn)遠(yuǎn)超于DCTCP,綜上DCTCP能實(shí)低延遲和和一定突發(fā)流量的容忍能力,在吞吐量上比TCP維持更高且穩(wěn)定的吞吐量。

    DCTCP依賴于ECN標(biāo)記進(jìn)行多位反饋,需要依賴于支持這個(gè)功能的商業(yè)交換機(jī),在早期搭建的數(shù)據(jù)中心中采用的交換機(jī)有可能缺乏對ECN功能的支持,從而影響到DCTCP的部署。

    2.2D2TCP

    D2TCP在設(shè)計(jì)時(shí)就明確了兩個(gè)目標(biāo),不需要調(diào)整交換機(jī)硬件和支持傳統(tǒng)的TCP協(xié)議,D2TCP算法通過ECN的標(biāo)記數(shù)量和數(shù)據(jù)流的截止時(shí)間提供的信息通過伽馬函數(shù)來調(diào)節(jié)擁塞窗口的大小。D2TCP可以根據(jù)截至?xí)r間的不同讓數(shù)據(jù)流獲得不同優(yōu)先級,截止時(shí)間比較遠(yuǎn)的流放棄帶寬讓截止時(shí)間快到的流保證流可以在截止時(shí)間內(nèi)完成傳輸,這對有時(shí)延要求的流來說效果是顯著的。

    B. Vamanan[5]得出的實(shí)驗(yàn)結(jié)果可以看出,DCTCP中的流在傳輸過程被授予相同帶寬,而D2TCP中的其他流帶寬全部下降這樣使得第一個(gè)流的完成時(shí)間縮短,整個(gè)傳輸過程大約減少了400ms的時(shí)延,對突發(fā)數(shù)據(jù)流的容忍能力和帶寬都有一定程度提升,比DCTCP錯(cuò)過截止時(shí)間的比率降低了75%。

    2.3L2DCT

    L2DCT也是通過ECN顯示擁塞反饋來進(jìn)行發(fā)送窗口的調(diào)控同時(shí)兼容現(xiàn)有TCP協(xié)議。L2DCT通過數(shù)據(jù)流的大小定義優(yōu)先級,通過數(shù)據(jù)流的擁塞程度和權(quán)重來調(diào)整發(fā)送窗口,權(quán)重取決于以及發(fā)送的數(shù)目,這些權(quán)重隱式定義了流的優(yōu)先級,當(dāng)流的數(shù)據(jù)量變大時(shí)算法就會將他的優(yōu)先級調(diào)低。由于短流的數(shù)量龐大,L2DCT更加關(guān)注短流的完成時(shí)間,當(dāng)長流和短流并存的時(shí)候,長流會放棄自己部分帶寬給短流,通過這種方式來減少數(shù)據(jù)流的完成時(shí)間。

    A. Munir[29]中得出的實(shí)驗(yàn)結(jié)果來看,L2DCT相比于DCTCP數(shù)據(jù)流傳輸平均完成時(shí)間提高了50%,相比于TCP協(xié)議提高了95%,錯(cuò)過截至?xí)r間的百分率約為TCP的30%,在突發(fā)流量的情況和高負(fù)載下長流的性能下長流的吞吐量會下降。

    L2DCT和D2TCP都是為了盡量少的deadline miss,所以犧牲了一部分長流的性能,對于時(shí)延敏感的應(yīng)用有效,而不同的應(yīng)用可能采取別的權(quán)重分配方式,也有人可以將長流分割為短流作為進(jìn)一步研究方向。

    3 基于RDMA的新型協(xié)議

    3.1RDMA的技術(shù)來源

    為了更高效的提高網(wǎng)絡(luò)性能,研究者們認(rèn)為TCP的網(wǎng)絡(luò)僵化、協(xié)議創(chuàng)新困難、配置復(fù)雜、流量管理繁瑣、安全問題凸顯,服務(wù)盡力而為無法保證服務(wù)質(zhì)量。根據(jù)擺脫TCP協(xié)議、從新的網(wǎng)絡(luò)架構(gòu)下獲得高質(zhì)量網(wǎng)絡(luò)服務(wù)的想法,研究者提出了不基于TCP/IP和以太網(wǎng)的專有網(wǎng)絡(luò)技術(shù)。現(xiàn)在的主流的高速互聯(lián)網(wǎng)絡(luò)互聯(lián)技術(shù)有Fiber Channel和Infiniband,一般專用與存儲集群。

    Infiniband又稱為無限帶寬技術(shù),是一種異于傳統(tǒng)網(wǎng)絡(luò)架構(gòu)的新體系,Buyya[15]在文中對Infiniband的體系結(jié)構(gòu)做了詳細(xì)的介紹,IB基于鏈路層的流控機(jī)制和先進(jìn)的擁塞控制機(jī)制可以防止擁塞,完全的CPU卸載功能,基于硬件的傳輸協(xié)議,內(nèi)核旁路技術(shù)都保證了可靠傳輸,在IB體系架構(gòu)里,網(wǎng)絡(luò)總線DMA技術(shù)以RDMA的形式體現(xiàn),服務(wù)器之間通過RDMA來實(shí)現(xiàn)數(shù)據(jù)高效的傳輸,TCA(通道適配器)結(jié)合RDMA技術(shù)也在主機(jī)端優(yōu)化了網(wǎng)絡(luò)性能,可以使得CPU直接移動(dòng)其他服務(wù)器上的數(shù)據(jù),這可以帶來更高的效率和靈活性。

    Fibre Channel是一種靈活的、擴(kuò)展性強(qiáng)的高速數(shù)據(jù)傳輸接口,光纖通道具有很高的傳輸帶寬,無論是在銅線或者是光纖上數(shù)據(jù)率大約是現(xiàn)在的通信接口的250倍,它的目的就是使用最低的延遲最快的速度進(jìn)行傳輸,但是和IB一樣安裝復(fù)雜需要特殊的IB交換機(jī),可擴(kuò)展的成本較高,傳輸和普適性方面顯得很笨拙,于是研究者們將FC技術(shù)和RDMA協(xié)議結(jié)合起來,將FC搬遷至以太網(wǎng)實(shí)現(xiàn)。

    3.2RDMA技術(shù)特征

    針對RDMA給IB和FC帶來的網(wǎng)絡(luò)性能提升,但是卻需要特殊的硬件支持,為了使網(wǎng)絡(luò)更加具有普適性,在結(jié)合的RDMA技術(shù)所帶來的優(yōu)越的特性進(jìn)行了調(diào)研。

    RDMA(Remote Direct Memory Access, RDMA)遠(yuǎn)程數(shù)據(jù)存儲存取起源于DMA,DMA可以使設(shè)備不經(jīng)過CPU直接和系統(tǒng)內(nèi)存交換數(shù)據(jù),為了使這種性能能在整個(gè)網(wǎng)絡(luò)中使用,又將可靠傳輸協(xié)議固化到網(wǎng)卡(稱為RNIC),通過這兩種途徑數(shù)據(jù)在傳輸時(shí)不經(jīng)過內(nèi)核和部分TCP協(xié)議直接從源主機(jī)的存儲區(qū)發(fā)送到目的主機(jī)的存儲區(qū),避免了主機(jī)內(nèi)部之間的重復(fù)拷貝,這也形成了RDMA的兩大主要特點(diǎn),零拷貝技術(shù)(Zero-copy)和內(nèi)核旁路技術(shù)(Bypass)。零拷貝技術(shù),使數(shù)據(jù)在接收發(fā)送時(shí)直接進(jìn)入緩存而不需要網(wǎng)絡(luò)層之間的拷貝。內(nèi)核旁路技術(shù),從用戶空間直接訪問和控制設(shè)備內(nèi)存,避免了數(shù)據(jù)從設(shè)備拷貝到內(nèi)核,又再一次從內(nèi)核拷貝至用戶空間。RDMA的數(shù)據(jù)拷貝計(jì)傳輸實(shí)現(xiàn)流程如圖2所示

    有CPU的參與,就減少了CPU的占有率。同時(shí)在RDMA中數(shù)據(jù)處理事離散的消息而不是以一個(gè)流的方式,消除了應(yīng)用程序區(qū)分不同流的信息的需要,這些特點(diǎn)都使得RDMA成為一種數(shù)據(jù)移動(dòng)處理的高效方式,在低延遲,高帶寬,低CPU占有率的場景下RDMA的應(yīng)用非常常見,比如HPC, Cloud Computing, Storage and Backup system等等由于解放了CPU網(wǎng)絡(luò)性能得到巨幅提升。

    圖2 RDMA通訊協(xié)議棧

    沒這些新型的計(jì)算機(jī)網(wǎng)絡(luò)模型在網(wǎng)絡(luò)性能上確實(shí)也得到了顯著的增加,但是由于新型體系結(jié)構(gòu)網(wǎng)絡(luò)模型的更改,RDMA協(xié)議在傳統(tǒng)的TCP/IP體系下是不支持的,原有在TCP上的服務(wù)因?yàn)镾ocket適合協(xié)議端口綁定的原因,就無法繼續(xù)在新的體系架構(gòu)下,如果想要新的網(wǎng)絡(luò)模型支持這種應(yīng)用,勢必需要提供新的Socket,這樣代價(jià)也隨之而來。但是由于傳統(tǒng)TCP體系結(jié)構(gòu)的落后,導(dǎo)致現(xiàn)在網(wǎng)絡(luò)的性能很差,應(yīng)用數(shù)據(jù)在網(wǎng)絡(luò)體系上傳輸?shù)乃俣葲]有達(dá)到理想中的需求,這也逐漸成為網(wǎng)絡(luò)性能的瓶頸。新引入的RDMA技術(shù)雖然能夠達(dá)到數(shù)據(jù)傳輸?shù)男枨?,但是由于Socket的不同,所以可能需要針對這項(xiàng)技術(shù)提供專門的RDMA應(yīng)用,考慮到應(yīng)用大規(guī)模部署在以太網(wǎng)中,所以直接革新式的制作新的應(yīng)用顯然代價(jià)過于高昂。

    從上述的論述中可以得出我們在考慮網(wǎng)絡(luò)性能的同時(shí)也要考慮到現(xiàn)實(shí)的應(yīng)用場景,隨著以太網(wǎng)速度提升至40Gbps以上,相比于IB和FC的速度也毫不遜色,所以如果將RDMA協(xié)議布置到傳統(tǒng)以太網(wǎng)中,那么無論是網(wǎng)絡(luò)的性能還是從實(shí)用上來說都會得到質(zhì)的飛躍。

    3.3iWARP(internet Wide Area RDMA Protocol)技術(shù)

    傳統(tǒng)以太網(wǎng)的從應(yīng)用處理到操作系統(tǒng)的開銷,網(wǎng)絡(luò)處理,I/O處理,線路延遲等一系列流程導(dǎo)致延遲快速積累,但是隨著以太網(wǎng)的提速延遲大大下降,直逼毫秒級延遲,完全可以滿足現(xiàn)有的網(wǎng)絡(luò)架構(gòu),如果將RDMA技術(shù)布置在以太網(wǎng)上必然能帶來性能的大幅提升。

    iWARP是一個(gè)計(jì)算機(jī)網(wǎng)絡(luò)中的協(xié)議,能夠通過以太網(wǎng)實(shí)現(xiàn)遠(yuǎn)程數(shù)據(jù)直接訪問。iWARP在設(shè)計(jì)上就是為了適用于現(xiàn)有的TCP傳輸,利用傳統(tǒng)TCP協(xié)議達(dá)到可靠傳輸,由于RDMA提供了應(yīng)用程序到應(yīng)用程序之間直接通信的能力,跳過了操作系統(tǒng),實(shí)現(xiàn)遠(yuǎn)程內(nèi)存應(yīng)用程序的訪問,使得IWARP低延遲變得可能,同時(shí)由于IWARP使用普通交換機(jī)就可以完成RDMA,所以對比Ether fabric這種私有技術(shù)和IB特殊的體系結(jié)構(gòu),顯然更加具有普適性,但是帶來的代價(jià)就是,IWARP協(xié)議族使用了一個(gè)復(fù)雜的混合層。

    在2007年,IETF發(fā)布了五個(gè)RFC標(biāo)準(zhǔn)定義iWARP,如圖4所示,在RFC標(biāo)準(zhǔn)中[22-26]中詳細(xì)解釋了iWARP的協(xié)議分工,在DDP(Data Placement Protocol)層上定義了遠(yuǎn)程數(shù)據(jù)直接存取協(xié)議,這個(gè)協(xié)議告訴RDMA如何讀寫數(shù)據(jù),MPA層上的DDP定義了如何將數(shù)據(jù)不通過間接緩存區(qū)直接放入上層協(xié)議的接收緩存區(qū)等。從圖3可以清楚的看出有無iWARP協(xié)議對整個(gè)數(shù)據(jù)處理的影響。數(shù)據(jù)直接在硬件部分通過iWARP協(xié)議尋址定位到用戶空間,避免了內(nèi)存拷貝。

    圖3 iWARP和傳統(tǒng)架構(gòu)下數(shù)據(jù)處理方式

    圖4 iWARP網(wǎng)絡(luò)協(xié)議棧

    iWARP協(xié)議主要組件包括了DDP(direct data placement,實(shí)現(xiàn)數(shù)據(jù)傳輸零拷貝),RDMA(RDMA讀和RDMA寫),MPA(Maker PDU Aligned framing,數(shù)據(jù)單元組幀以確保和TCP的消息邊界),這種架構(gòu)使得RDMA在現(xiàn)有的網(wǎng)絡(luò)中傳輸變的可能,由于iWARP是通過TCP/IP的RDMA,也享受了TCP/IP提供了可靠的通信路徑,支持多地子網(wǎng)尋址功能,以及TCP/IP帶來的可擴(kuò)展性。iWARP由硬件執(zhí)行TCP/IP的處理,從應(yīng)用里完全提取出網(wǎng)絡(luò)協(xié)議占的處理,同時(shí)由于傳統(tǒng)網(wǎng)絡(luò)對TCP的支持我們在傳統(tǒng)網(wǎng)絡(luò)中部署的應(yīng)用可以直接使用,這種方式大大減少了我們在硬件,資源等方面的消耗。

    Rashti[17]在10Gbps以太網(wǎng)下對比了iWARP和Infiniband的性能,實(shí)驗(yàn)顯示消息字節(jié)在1byte到1Kbyte的情況下iWARP在時(shí)延和帶寬的性能都是比Infiniband高的。這也說明在高速的網(wǎng)絡(luò)下即使不適用新的體系結(jié)構(gòu)我們?nèi)耘f可以通過RDMA技術(shù)來實(shí)現(xiàn)性能的提升。而將RDMA應(yīng)用到以太網(wǎng)上無論從網(wǎng)絡(luò)性能的角度還是經(jīng)濟(jì)適用上都是一個(gè)不錯(cuò)的選擇。

    3.4RoCE(RDMA over Converged Ethernet)技術(shù)

    隨著IEEE提出的數(shù)據(jù)中心橋接技術(shù)(Data Center Bridging, DCB),使得數(shù)據(jù)鏈路層性能急劇提升。

    由于DCB提供了擁塞控制,在iWARP的TCP,SCTP和RDDP中提供的擁塞控制功能就變得冗余起來,在DCB中,TCP慢啟動(dòng)行為能夠被減弱或者移除,因此在DCB中布置一個(gè)最合適的協(xié)議來減少iWARP的復(fù)雜性和布置問題,RoCE就是在這種情況下提出來的。

    IEEE數(shù)據(jù)中心橋接技術(shù)主要包括基于優(yōu)先級的流量控制(Priority-based Flow Control, PFC),量化擁塞通知(Quantized Congestion Notification, QCN)在DCB技術(shù)支撐下實(shí)現(xiàn)了無損以太網(wǎng),以及對RDMA的支持。

    RoCE基于融合以太網(wǎng)的RDMA是一種可以極低延遲在無損以太網(wǎng)絡(luò)上提供高效數(shù)據(jù)傳輸?shù)臋C(jī)制,由于RoCE以及RoCEv2的提出使RDMA更加高效的運(yùn)行在以太網(wǎng)上,RoCEV2是對IB協(xié)議棧的一種改進(jìn)和增強(qiáng),保留了IB的傳輸層,使用IP和UDP封裝代替了IB的網(wǎng)絡(luò)層,同時(shí)使用以太網(wǎng)代替了IB的鏈路層,在UDP報(bào)頭中加入了ECMP,為了有效的運(yùn)轉(zhuǎn)RoCE同時(shí)提供了無損的第二層。圖5為RoCE的網(wǎng)絡(luò)協(xié)議棧,相比于iWARP復(fù)雜的網(wǎng)絡(luò)層,RoCE的模型顯得更加簡單。

    圖5 RoCE網(wǎng)絡(luò)協(xié)議棧

    相比于iWARP,一個(gè)包僅僅觀察他的UDP目的地端口的值和IANA分配的端口值是否匹配,就可以知道他是否為ROCE包,這種方式在很大程度簡化了流量分析和管理。

    iWARP使用傳統(tǒng)TCP協(xié)議棧共享端口,所以會限制了它的高消費(fèi)和布置的難度。ROCE包頭封裝了IP和UDP,意味著RoCE可以在L2和L3層運(yùn)行,可以在L3層路由可以使RDMA帶來構(gòu)造多子網(wǎng)的功能,同時(shí)由于Soft-RoCE的布置,RoCE可以通過軟件布置而不需要本地硬件,這使得ROCE可以在數(shù)據(jù)中心獲得更加靈活的性能。

    在文獻(xiàn)[18]中Mellanox對RoCE和iWARP進(jìn)行了性能的比較,在消息字節(jié)大小為100B的情況下,平均延遲相差20微秒,99%的情況下RoCE的延遲比iWARP低40微秒,同時(shí)RoCE具有更低的CPU占用率。

    4 總結(jié)

    本文從TCP協(xié)議和主機(jī)端的數(shù)據(jù)傳輸方式分析了傳統(tǒng)的網(wǎng)絡(luò)結(jié)構(gòu)的弊端,總結(jié)了幾種高效的網(wǎng)絡(luò)性能提升的方式.

    第一類方法考慮到硬件的處理效率,直接將部分協(xié)議搬遷至硬件實(shí)現(xiàn)提高網(wǎng)絡(luò)性能,這種方式比較直接,但是需要特殊的硬件支持,不適用于大規(guī)模布置,而且硬件更新?lián)Q代的速度非???,接口常常難以兼容,接口設(shè)置復(fù)雜。第二類方法考慮在以太網(wǎng)下對協(xié)議優(yōu)化,在不改變整個(gè)架構(gòu)的基礎(chǔ)上做出的性能提升,可擴(kuò)展性強(qiáng),而且由于以太網(wǎng)的普遍使用,適用性很強(qiáng),但是這樣做仍舊出于傳統(tǒng)的TCP體系下,TCP本身就是一個(gè)笨拙的體系結(jié)構(gòu),在TCP的改進(jìn)雖然有效,但是隨著以太網(wǎng)的提速也慢慢顯出不適。第三種方法是將RDMA的想法應(yīng)用在以太網(wǎng)上,RDMA的思想源于IB,但是由于應(yīng)用不兼容,體系不同,將RDMA部署在以太網(wǎng)上是一種趨勢,而且從數(shù)據(jù)分析來看,RDMA確實(shí)提高了網(wǎng)絡(luò)帶寬,降低了延遲,減少了CPU的占有率,對于網(wǎng)絡(luò)性能的提升是很可觀的,基于以太網(wǎng)的結(jié)構(gòu)又可以讓它輕易擴(kuò)展,是當(dāng)下提升網(wǎng)絡(luò)性能的一種較優(yōu)的方式。

    [1] M.Allman, V.Paxson,E Blanton.TCP congestion control. RFC 5681.

    [2] Y.Zhu, H.Eran, D.Firestone, C.Guo. Congestion Control for Large-Scale RDMA Deployments. In SIGCOMM Computer Communication Review, New York, USA, 2015:Volume 45 Issue 4

    [3] S.Floyd.TCP and Explicit Congestion Notification. In ACM SIGCOMM Computer Communication Review, New York, USA, 1994: Volume 24 Issue 5.

    [4] M.Alizadeh, A Greenberg, DA Maltz, J Padhye. Data Center Tcp. In ACM SIGCOMM Computer Communication Review, New York, USA, 2010: Volume 40 Issue 4.

    [5] B. Vamanan, J.Hasan, TN Vijaykumar. Deadline-aware Datacenter Tcp. In ACM SIGCOMM Computer Communication Review, New York, USA, 2012: Volume 42 Issue 4.

    [6] S.Joy, A Nayak. Improving Flow Completion Time for Short Flows In Datacenter Networks. In IFIP/IEEE International Symposium on Integrated Network Management (IM), Ottawa. ON.

    [7] K. Kant. TCP Offload Performance for Front-end Servers. In Global Telecommunications Conference, USA, 2003: volume 6

    [8] W. Feng, P. Balaji, L.N Bhuyan, D.K. Panda. Performance characterization of a 10-Gigabit Ethernet TOE. In Symposium on High Performance Interconnects, 2005.

    [9] J.C Mogul, P. Alto. TCP offload is a dumb idea whose time has come, 9th Workshop on Hot Topics in Operating Systems, senix Assoc, 2003.

    [10] P. Sarker, K. Voruganti. Storage over IP: Does hardware support help? In Proc. 2nd USENIX Conf. on File and Storage Technologies, San Francisco, CA, 2003.

    [11] Intel. White Paper. Accelerating High-Speed Networking with Intel?I/O Acceleration Technology. http://www.intel.com/content/www/xr/en/io/i-o-accelerationtechnology-paper.html

    [12] Intel. Competitive Guide. Competitive Comparison Intel?I/O Acceleration Technology vs. TCP Offload Engine. http://www.intel.com/content/www/us/en/wireless-network/a ccel-technology.html

    [13] J. Shu, B. Li, Weimin Zheng. Design and Implementation of an SAN System Based on the Fiber Channel Protocol. In IEEE Transaction on Computers, 2005: volume 54.

    [14] K. Malavalli, High-speed Fiber Channel Switching Fabric services, In Proceedings of the SPIE,USA,1992:Volume 1577

    [15] R. Buyya, T.Cortes, H. Jin, An Introduction to the InfiniBand Architecture(http://www.infinibandta.org), In IEEE Press, 2001.

    [16] A. Vishnu, A.R Mamidala, W Jin, D.K Panda, Performance modeling of subnet management on fat tree InfiniBand networks using OpenSM, 19th IEEE International Parallel and Distributed Processing Symposium, 2005.

    [17] M.J. Rashti, A. Afsahi, 10-Gigabit iWARP Ethernet: Comparative Performance Analysis with InfiniBand and Myrinet-10G, In 2007 IEEE International Parallel and Distributed Processing Symposium, Long Beach, CA, 2007.

    [18] Mellanox. White Paper. RoCE vs. iWARP Competitive Analysis Brief. http://www.techrepublic.com/resource-library/whitepapers/ro ce-vs-iwarp-competitive-analysis-brief/.

    [19] J. MO, R. La, V. Anantharam, J. Walrand, Analysis and comparison of TCP Reno and Vegas,In IEEE INFOCOM, 1999.

    [20] T. Hamann, J. Walrand, A new fair window algorithm for ECN capable TCP (new-ECN), In INFOCOM, Tel Aviv, 2000.

    [21] D. Tang, Y. Bao, W.Hu, M. Chen, DMA cache: Using onchip storage to architecturally separate I/O data from CPU data for improving I/O performance, In 16th International Symposium on High-Performance Computer Architecture, Bangalore, 2010.

    [22] R. Recio, B. Metzler P. Culley, J. Hilland, D. Garcia. A Remote Direct Memory Access Protocol Specification. RFC 5040, 2007.

    [23] H. Shah J. Pinkerton R. Recio P. Culley, Direct Data Placement over Reliable Transports, RFC 5041,2007.

    [24] J. Pinkerton E. Deleganes, Direct Data Placement Protocol (DDP)/Remote Direct Memory Access Protocol (RDMAP) Security, RFC 5042,2007.

    [25] C. Bestler, R. Stewart, Stream Control Transmission Protocol (SCTP)/Direct Data Placement (DDP) Adaptation, RFC 5043, 2007.

    [26] P. Culley, U. Elzur, R. Recio, S. Bailey, J. Carrier, Marker PDU Aligned Framing for TCP Specification, RFC 5044, 2007.

    [27] K. Ramakrishnan, S. Floyd, and D. Black. The addition of explicit congestion notification (ECN). RFC 3168.

    [28] Riesbeck, C.K. & Martin, C.E, Direct Memory Access Parsing. In J. Kolodner & C. Riesbeck (Eds) Experience, Memory and Reasoning, 1986.

    [29] A. Munir, I. A Qzai, Z.A Uzmi, A. Mushtaq, S. N Ismail, M. S Iqbal, B. Khan, Minimizing flow completion times in data centers, In INFOCOM, Turin, 2013

    [30] 王曉艷. 基于云計(jì)算的數(shù)據(jù)中心建設(shè)探討[J]. 軟件, 2014, 35(2): 129-130

    [31] 錢育蓉, 于炯, 英昌甜, 等. 云計(jì)算環(huán)境下新疆遙感應(yīng)用數(shù)據(jù)中心的挑戰(zhàn)與機(jī)遇[J]. 軟件, 2015, 36(4): 58-61

    [32] 信懷義, 安衛(wèi)杰. 金融數(shù)據(jù)中心數(shù)據(jù)備份必要性及其機(jī)制研究[J]. 軟件, 2015, 36(12): 72-75

    [33] 張宇翔. 面向質(zhì)量評估的高校教學(xué)數(shù)據(jù)中心數(shù)據(jù)模塊的設(shè)計(jì)與實(shí)踐[J]. 軟件, 2016, 37(4): 51-53

    High Speed Data Transport Technology for Datacenter Network

    QIN Xuan-long1, LI Da-gang1, DU Zheng2, CHEN Yuan-lei2
    (1. School of Electronic and Computer Engineering, Peking University Shenzhen Graduate School, Shenzhen 518055, China; 2. Department of High Performance Computing, National Supercomputing Center in Shenzhen, Shenzhen 518055, China)

    Data center is the common infrastructure for cloud computing as well as big data application. At present almost all data center network use TCP/IP protocol running on Ethernet technology. With the increase in speed of Ethernet, the TCP/IP protocol and its way of implementation has been unable to meet the requirements of high speed data transmission and is even becoming the bottleneck of the network performance. After analyzing the characteristics of the existing data center network and the real-life performance of the network implementation, this paper will compare and summarize a variety of network performance optimization technologies, and then analyze the future research directions.

    TCP; Datacenter Network; Ethernet; RDMA

    TP393.03

    A

    10.3969/j.issn.1003-6970.2016.09.001

    國家重點(diǎn)研發(fā)計(jì)劃“資源準(zhǔn)入和分級標(biāo)準(zhǔn)體系建設(shè)”(2016YFB0201401);深圳市公共技術(shù)服務(wù)平臺項(xiàng)目“深圳市工業(yè)設(shè)計(jì)云服務(wù)平臺”(GGJS20150429172906635);深圳市技術(shù)攻關(guān)項(xiàng)目“重20150075:面向智能城市管理的大數(shù)據(jù)智能分析關(guān)鍵技術(shù)研究”(JSGG2015051214574248)

    秦宣龍(1993-),男,研究生,主要研究方向:數(shù)據(jù)中心網(wǎng)絡(luò);都政(1981-),男,高級工程師,主要研究方向:高性能計(jì)算、云計(jì)算與大數(shù)據(jù)分析;陳遠(yuǎn)磊(1988-),男,工程師,主要研究方向:大數(shù)據(jù)分析處理技術(shù)。

    通訊聯(lián)系人: 李大剛(1975-),男,助理教授,主要研究方向:高性能網(wǎng)絡(luò)及分布式存儲技術(shù)。

    猜你喜歡
    以太網(wǎng)數(shù)據(jù)中心傳輸
    酒泉云計(jì)算大數(shù)據(jù)中心
    混合型隨機(jī)微分方程的傳輸不等式
    牽引8K超高清傳輸時(shí)代 FIBBR Pure38K
    基于1500以太網(wǎng)養(yǎng)豬場的智能飼喂控制系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)
    電子制作(2018年18期)2018-11-14 01:48:00
    民航綠色云數(shù)據(jù)中心PUE控制
    電子測試(2018年11期)2018-06-26 05:56:24
    支持長距離4K HDR傳輸 AudioQuest Pearl、 Forest、 Cinnamon HDMI線
    談實(shí)時(shí)以太網(wǎng)EtherCAT技術(shù)在變電站自動(dòng)化中的應(yīng)用
    電子制作(2017年24期)2017-02-02 07:14:44
    一種90W高功率以太網(wǎng)供電系統(tǒng)的設(shè)計(jì)
    淺談EPON與工業(yè)以太網(wǎng)在貴遵高速公路中的應(yīng)用
    最近视频中文字幕2019在线8| 国产 亚洲一区二区三区 | 亚洲精品亚洲一区二区| 久久久久久九九精品二区国产| 国产乱人视频| 午夜日本视频在线| 国产一区二区三区av在线| 国产精品久久久久久精品电影| 美女xxoo啪啪120秒动态图| 亚洲国产色片| 国产伦精品一区二区三区四那| 精品不卡国产一区二区三区| www.色视频.com| 国产高清有码在线观看视频| 成人二区视频| 欧美变态另类bdsm刘玥| 只有这里有精品99| 日韩强制内射视频| 国产69精品久久久久777片| 赤兔流量卡办理| 一区二区三区高清视频在线| 激情五月婷婷亚洲| 一级毛片我不卡| 97精品久久久久久久久久精品| 最近2019中文字幕mv第一页| 久久精品夜色国产| 国产v大片淫在线免费观看| 老师上课跳d突然被开到最大视频| 国产淫语在线视频| av在线亚洲专区| 国产激情偷乱视频一区二区| 美女被艹到高潮喷水动态| 国产成人一区二区在线| 国产精品1区2区在线观看.| 精品一区二区三区人妻视频| 汤姆久久久久久久影院中文字幕 | 日本wwww免费看| 99热网站在线观看| 精品久久久久久久久av| 青青草视频在线视频观看| 亚洲高清免费不卡视频| 最近的中文字幕免费完整| 亚洲精品成人av观看孕妇| 欧美极品一区二区三区四区| 在线观看人妻少妇| 国产在线男女| 日韩,欧美,国产一区二区三区| 欧美日韩综合久久久久久| 午夜福利网站1000一区二区三区| ponron亚洲| 日韩中字成人| 精品一区二区免费观看| 国产精品三级大全| 乱人视频在线观看| 97热精品久久久久久| 午夜福利视频1000在线观看| 亚洲精品成人av观看孕妇| 中文字幕免费在线视频6| 国产成人精品一,二区| 久久亚洲国产成人精品v| av福利片在线观看| 天天躁夜夜躁狠狠久久av| av免费观看日本| 日韩欧美三级三区| 最近视频中文字幕2019在线8| 91久久精品国产一区二区三区| 亚洲aⅴ乱码一区二区在线播放| 一区二区三区乱码不卡18| 免费观看的影片在线观看| 99热全是精品| 精品久久久久久久久久久久久| 久久久精品免费免费高清| 国产成人freesex在线| 午夜福利在线观看免费完整高清在| freevideosex欧美| 国产精品av视频在线免费观看| 有码 亚洲区| 国精品久久久久久国模美| 国产淫片久久久久久久久| 成人二区视频| 大又大粗又爽又黄少妇毛片口| 国产一区二区三区综合在线观看 | 亚洲av.av天堂| 国产精品三级大全| 欧美成人一区二区免费高清观看| 嫩草影院新地址| 国产高清有码在线观看视频| 三级国产精品片| 久久亚洲国产成人精品v| av播播在线观看一区| 国产精品女同一区二区软件| 成人二区视频| 色综合色国产| 国产精品人妻久久久影院| 一本一本综合久久| 中文资源天堂在线| 亚洲欧美精品专区久久| 大片免费播放器 马上看| 国产乱人偷精品视频| 欧美日韩一区二区视频在线观看视频在线 | 中文资源天堂在线| 国内揄拍国产精品人妻在线| 大香蕉97超碰在线| 99久久精品一区二区三区| 男女啪啪激烈高潮av片| 国产黄色小视频在线观看| 成人亚洲精品av一区二区| .国产精品久久| 99热网站在线观看| 精品人妻熟女av久视频| 成人高潮视频无遮挡免费网站| 男人舔女人下体高潮全视频| 国产精品熟女久久久久浪| 国产激情偷乱视频一区二区| 欧美bdsm另类| 在线 av 中文字幕| 国产成人一区二区在线| 亚洲国产精品专区欧美| 精品人妻熟女av久视频| 国产精品一区二区三区四区免费观看| 亚州av有码| 能在线免费观看的黄片| 欧美人与善性xxx| 少妇被粗大猛烈的视频| 国产精品熟女久久久久浪| 日韩欧美一区视频在线观看 | 日本三级黄在线观看| 亚洲国产高清在线一区二区三| 一级毛片 在线播放| 亚洲欧美日韩卡通动漫| 久久韩国三级中文字幕| 插阴视频在线观看视频| 亚洲人与动物交配视频| 男女那种视频在线观看| 久久鲁丝午夜福利片| 精品人妻偷拍中文字幕| 国产成人免费观看mmmm| 亚洲精品久久午夜乱码| 韩国av在线不卡| 观看免费一级毛片| www.av在线官网国产| 亚洲真实伦在线观看| 亚洲一级一片aⅴ在线观看| 国产av国产精品国产| 少妇人妻精品综合一区二区| 丝袜喷水一区| h日本视频在线播放| 街头女战士在线观看网站| 亚洲av成人av| 国产精品久久视频播放| 一级av片app| 少妇的逼水好多| 精品熟女少妇av免费看| 在线观看一区二区三区| 美女xxoo啪啪120秒动态图| 精品人妻熟女av久视频| 国产精品麻豆人妻色哟哟久久 | 丝袜美腿在线中文| 久热久热在线精品观看| 尾随美女入室| 国产午夜福利久久久久久| 午夜福利在线在线| av免费在线看不卡| 女人十人毛片免费观看3o分钟| 99热6这里只有精品| 啦啦啦韩国在线观看视频| 亚洲欧美一区二区三区黑人 | 国产在视频线精品| 中文字幕人妻熟人妻熟丝袜美| 成人高潮视频无遮挡免费网站| 国产不卡一卡二| 色哟哟·www| av在线播放精品| 中文字幕免费在线视频6| 白带黄色成豆腐渣| 成人国产麻豆网| 一区二区三区免费毛片| 亚洲不卡免费看| 大香蕉久久网| 国内揄拍国产精品人妻在线| 天美传媒精品一区二区| 免费黄色在线免费观看| a级一级毛片免费在线观看| 夫妻性生交免费视频一级片| 国产三级在线视频| 久久久久九九精品影院| 国产日韩欧美在线精品| 国产午夜精品久久久久久一区二区三区| 国产成人a∨麻豆精品| 日韩电影二区| 99热网站在线观看| 女人被狂操c到高潮| 国产熟女欧美一区二区| 国产亚洲最大av| 高清毛片免费看| 精品人妻偷拍中文字幕| 亚洲精品国产av成人精品| 少妇的逼水好多| 又大又黄又爽视频免费| 精品一区二区三区视频在线| 伦理电影大哥的女人| 又粗又硬又长又爽又黄的视频| 亚洲一区高清亚洲精品| 肉色欧美久久久久久久蜜桃 | 国产中年淑女户外野战色| 精品酒店卫生间| 九色成人免费人妻av| 99久国产av精品| 亚洲欧美精品自产自拍| 性插视频无遮挡在线免费观看| 免费人成在线观看视频色| 看非洲黑人一级黄片| 在现免费观看毛片| 白带黄色成豆腐渣| av一本久久久久| 色尼玛亚洲综合影院| 纵有疾风起免费观看全集完整版 | 久久草成人影院| 国产精品一区二区三区四区免费观看| 深夜a级毛片| 亚洲四区av| 国产一区二区三区综合在线观看 | 国产 亚洲一区二区三区 | 免费在线观看成人毛片| 国产高清不卡午夜福利| 国产高清有码在线观看视频| 中文资源天堂在线| 男女边吃奶边做爰视频| 亚洲在线观看片| eeuss影院久久| 国产片特级美女逼逼视频| 国产成人精品福利久久| 国产精品女同一区二区软件| 午夜视频国产福利| 亚洲18禁久久av| 国产精品久久久久久久久免| 麻豆久久精品国产亚洲av| 久久99热这里只频精品6学生| 精品国内亚洲2022精品成人| 亚洲一级一片aⅴ在线观看| 国产单亲对白刺激| 亚洲av国产av综合av卡| 国产精品嫩草影院av在线观看| 国产毛片a区久久久久| 久久久精品94久久精品| 欧美97在线视频| 免费播放大片免费观看视频在线观看| 女人被狂操c到高潮| 中文天堂在线官网| 亚洲四区av| 99久久九九国产精品国产免费| 夫妻午夜视频| 久久久久久久亚洲中文字幕| 菩萨蛮人人尽说江南好唐韦庄| 美女高潮的动态| 午夜福利网站1000一区二区三区| 美女cb高潮喷水在线观看| 久久鲁丝午夜福利片| 一级毛片电影观看| 日韩电影二区| 五月玫瑰六月丁香| 丝袜喷水一区| 欧美bdsm另类| 欧美 日韩 精品 国产| 国产精品综合久久久久久久免费| 国产亚洲av嫩草精品影院| 少妇熟女aⅴ在线视频| 精品一区在线观看国产| 亚洲丝袜综合中文字幕| av又黄又爽大尺度在线免费看| 午夜福利成人在线免费观看| 日日啪夜夜撸| 最近的中文字幕免费完整| 国产老妇女一区| 嫩草影院新地址| 小蜜桃在线观看免费完整版高清| 国产成人福利小说| 国产探花在线观看一区二区| xxx大片免费视频| 99热这里只有精品一区| 97人妻精品一区二区三区麻豆| 欧美xxxx性猛交bbbb| 国产有黄有色有爽视频| 嫩草影院入口| 国产黄片美女视频| 少妇猛男粗大的猛烈进出视频 | 亚洲国产精品sss在线观看| 国产成人aa在线观看| 日本免费在线观看一区| 亚洲综合精品二区| 插逼视频在线观看| 亚洲高清免费不卡视频| 亚洲成色77777| 亚洲av一区综合| 99久久精品一区二区三区| 亚洲av免费在线观看| 99久久人妻综合| 日本午夜av视频| 非洲黑人性xxxx精品又粗又长| 大话2 男鬼变身卡| 嫩草影院入口| 又黄又爽又刺激的免费视频.| 最近手机中文字幕大全| 午夜激情欧美在线| 成人一区二区视频在线观看| 亚洲精品自拍成人| 99久国产av精品国产电影| 国产高清不卡午夜福利| 欧美成人一区二区免费高清观看| 国产男女超爽视频在线观看| 一个人免费在线观看电影| 成人午夜精彩视频在线观看| 男女边吃奶边做爰视频| 国产欧美日韩精品一区二区| 一级片'在线观看视频| 国产亚洲av片在线观看秒播厂 | 18禁在线无遮挡免费观看视频| 欧美+日韩+精品| 久久久久久国产a免费观看| 国产成人精品一,二区| 国产成人免费观看mmmm| 乱码一卡2卡4卡精品| 亚洲美女视频黄频| 高清毛片免费看| 欧美日韩精品成人综合77777| 国产精品一二三区在线看| 亚洲精品视频女| 国产片特级美女逼逼视频| 欧美三级亚洲精品| 男人和女人高潮做爰伦理| av天堂中文字幕网| 大片免费播放器 马上看| 欧美激情久久久久久爽电影| av在线播放精品| 亚洲,欧美,日韩| 日韩强制内射视频| 亚洲无线观看免费| 综合色丁香网| 岛国毛片在线播放| 男女视频在线观看网站免费| 国产男女超爽视频在线观看| 亚洲国产最新在线播放| av.在线天堂| 一区二区三区免费毛片| 国产熟女欧美一区二区| 国内精品宾馆在线| 国产黄片视频在线免费观看| 国产探花极品一区二区| 最近中文字幕高清免费大全6| 国产伦一二天堂av在线观看| 欧美性感艳星| 99久久精品一区二区三区| 免费不卡的大黄色大毛片视频在线观看 | 永久免费av网站大全| 最后的刺客免费高清国语| 色网站视频免费| 色播亚洲综合网| 麻豆成人av视频| 听说在线观看完整版免费高清| 免费观看精品视频网站| 欧美另类一区| 免费av观看视频| 中国国产av一级| 人人妻人人看人人澡| 国产一区二区亚洲精品在线观看| 精品久久久久久久人妻蜜臀av| 亚洲av福利一区| 中文字幕久久专区| 精品久久久久久久久av| 人人妻人人看人人澡| 国产视频首页在线观看| 日日摸夜夜添夜夜添av毛片| 在线观看美女被高潮喷水网站| 尾随美女入室| 亚洲av一区综合| 一个人看视频在线观看www免费| 偷拍熟女少妇极品色| 麻豆成人av视频| 综合色丁香网| 看十八女毛片水多多多| 欧美成人一区二区免费高清观看| 免费观看在线日韩| 国产淫片久久久久久久久| 边亲边吃奶的免费视频| 国产中年淑女户外野战色| 国产av在哪里看| 欧美丝袜亚洲另类| 亚洲精品亚洲一区二区| 成人鲁丝片一二三区免费| 日韩欧美精品v在线| 国产一级毛片在线| 男女下面进入的视频免费午夜| 欧美高清性xxxxhd video| 婷婷六月久久综合丁香| 日本一本二区三区精品| 亚洲欧洲日产国产| av在线亚洲专区| 日本爱情动作片www.在线观看| 日韩国内少妇激情av| 亚洲精品久久午夜乱码| 波野结衣二区三区在线| 国产精品熟女久久久久浪| 国产女主播在线喷水免费视频网站 | 看免费成人av毛片| 久久午夜福利片| 欧美区成人在线视频| 免费观看的影片在线观看| 永久免费av网站大全| 亚洲人与动物交配视频| 亚洲欧美日韩无卡精品| 精品99又大又爽又粗少妇毛片| 久久99热这里只有精品18| 伊人久久国产一区二区| 国产成人精品婷婷| 小蜜桃在线观看免费完整版高清| 观看美女的网站| 国内精品一区二区在线观看| 六月丁香七月| 身体一侧抽搐| 国产精品国产三级国产专区5o| 亚洲欧美日韩无卡精品| 99久久人妻综合| 爱豆传媒免费全集在线观看| 99久久精品一区二区三区| 乱人视频在线观看| 欧美不卡视频在线免费观看| 高清欧美精品videossex| 国内精品美女久久久久久| 亚洲人与动物交配视频| 97人妻精品一区二区三区麻豆| 蜜桃久久精品国产亚洲av| 99久久精品热视频| 国产探花在线观看一区二区| 欧美性猛交╳xxx乱大交人| 日韩,欧美,国产一区二区三区| 国产精品久久久久久av不卡| 免费观看av网站的网址| 午夜激情福利司机影院| 日韩中字成人| 乱码一卡2卡4卡精品| 国产av不卡久久| 亚洲精华国产精华液的使用体验| 日本爱情动作片www.在线观看| 国产精品一区二区在线观看99 | 少妇高潮的动态图| 亚洲va在线va天堂va国产| 人妻夜夜爽99麻豆av| 久久精品国产亚洲网站| 精品国产三级普通话版| 国产一区有黄有色的免费视频 | 丝袜喷水一区| 淫秽高清视频在线观看| 国产成人精品福利久久| 亚洲最大成人手机在线| av在线观看视频网站免费| 亚洲av电影不卡..在线观看| 国产精品国产三级国产av玫瑰| 亚洲精品国产成人久久av| 免费av观看视频| av在线播放精品| 精品不卡国产一区二区三区| 99久国产av精品国产电影| 亚洲第一区二区三区不卡| 嫩草影院入口| 女人久久www免费人成看片| 69人妻影院| av在线亚洲专区| 视频中文字幕在线观看| 人体艺术视频欧美日本| 中文乱码字字幕精品一区二区三区 | 春色校园在线视频观看| 91午夜精品亚洲一区二区三区| 又爽又黄无遮挡网站| 九九久久精品国产亚洲av麻豆| 亚洲在线观看片| 乱人视频在线观看| 夫妻性生交免费视频一级片| 水蜜桃什么品种好| 亚洲精品成人久久久久久| 尤物成人国产欧美一区二区三区| 久久精品综合一区二区三区| 亚洲欧美日韩东京热| 成人无遮挡网站| 22中文网久久字幕| 99久国产av精品| 一本—道久久a久久精品蜜桃钙片 精品乱码久久久久久99久播 | 男人爽女人下面视频在线观看| av天堂中文字幕网| 亚洲精品国产成人久久av| 又爽又黄a免费视频| 亚洲美女视频黄频| 99热这里只有精品一区| 久久久久精品久久久久真实原创| 国产一级毛片在线| 亚洲精品日韩av片在线观看| 建设人人有责人人尽责人人享有的 | 免费不卡的大黄色大毛片视频在线观看 | 成人亚洲欧美一区二区av| 欧美成人a在线观看| 免费大片黄手机在线观看| 免费观看性生交大片5| 国产精品99久久久久久久久| 国产精品精品国产色婷婷| 在线播放无遮挡| av在线天堂中文字幕| 亚洲国产日韩欧美精品在线观看| av一本久久久久| 18+在线观看网站| 一级二级三级毛片免费看| 免费大片黄手机在线观看| 久久韩国三级中文字幕| 大陆偷拍与自拍| 狂野欧美白嫩少妇大欣赏| 少妇丰满av| 直男gayav资源| 99久久精品热视频| 精品一区二区三区视频在线| 国产淫片久久久久久久久| 国产有黄有色有爽视频| 亚洲综合精品二区| 欧美三级亚洲精品| 大香蕉97超碰在线| 日韩一本色道免费dvd| 久久99热6这里只有精品| 国产精品福利在线免费观看| 建设人人有责人人尽责人人享有的 | 特级一级黄色大片| 国产亚洲午夜精品一区二区久久 | 又爽又黄a免费视频| 亚洲精品日韩av片在线观看| 蜜桃亚洲精品一区二区三区| 美女大奶头视频| 久久久久性生活片| 我的老师免费观看完整版| 久久国内精品自在自线图片| 夜夜看夜夜爽夜夜摸| 久久久色成人| 国产免费一级a男人的天堂| 人妻少妇偷人精品九色| 亚洲精品自拍成人| 亚洲人与动物交配视频| 免费高清在线观看视频在线观看| 国产亚洲一区二区精品| eeuss影院久久| 欧美成人午夜免费资源| 九色成人免费人妻av| 国产精品99久久久久久久久| 久久6这里有精品| 亚洲成色77777| 欧美精品一区二区大全| 久久6这里有精品| 欧美区成人在线视频| 国产精品久久久久久精品电影小说 | 热99在线观看视频| 免费黄网站久久成人精品| 亚洲国产av新网站| 精品久久久噜噜| 国产视频首页在线观看| 一个人看视频在线观看www免费| 日日摸夜夜添夜夜爱| 国产老妇女一区| 亚洲va在线va天堂va国产| 大话2 男鬼变身卡| 狂野欧美白嫩少妇大欣赏| 黄片无遮挡物在线观看| 久久久久久久国产电影| 亚洲av成人精品一二三区| 老师上课跳d突然被开到最大视频| 亚洲国产欧美在线一区| 久久这里有精品视频免费| 少妇裸体淫交视频免费看高清| 精品熟女少妇av免费看| 中文字幕制服av| 男女国产视频网站| 高清午夜精品一区二区三区| 国产精品一二三区在线看| 久久久久久伊人网av| 超碰av人人做人人爽久久| 国产精品久久久久久久久免| 成人亚洲精品一区在线观看 | 九九久久精品国产亚洲av麻豆| 在线免费十八禁| 国产精品.久久久| 国产黄a三级三级三级人| 国产色爽女视频免费观看| av网站免费在线观看视频 | 国产69精品久久久久777片| 亚洲欧美一区二区三区黑人 | 天天一区二区日本电影三级| 亚洲精品国产成人久久av| 精品久久久噜噜| 一本—道久久a久久精品蜜桃钙片 精品乱码久久久久久99久播 | 日韩大片免费观看网站| 欧美极品一区二区三区四区| 免费高清在线观看视频在线观看| 国产人妻一区二区三区在| 亚洲欧美精品自产自拍| 最近手机中文字幕大全| 成人亚洲精品一区在线观看 | 亚洲精品第二区| 插逼视频在线观看| 丝袜美腿在线中文| 人妻制服诱惑在线中文字幕| 午夜亚洲福利在线播放| 日日摸夜夜添夜夜添av毛片| 国产一区二区亚洲精品在线观看| 国产淫语在线视频| 日韩av免费高清视频| 一级毛片aaaaaa免费看小| 亚洲av成人av| 国产淫语在线视频| 亚洲国产欧美人成| 国产淫语在线视频| 色哟哟·www| 国产欧美日韩精品一区二区|