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

    基于RDMA 的高性能單向數(shù)據(jù)采集技術(shù)研究

    2023-10-17 05:50:22梁嘉誠余江王洪波劉淵王曉鋒
    計算機(jī)工程 2023年10期
    關(guān)鍵詞:網(wǎng)卡單向數(shù)據(jù)包

    梁嘉誠,余江,王洪波,劉淵,王曉鋒

    (1.江南大學(xué) 人工智能與計算機(jī)學(xué)院,江蘇 無錫 214122;2.拓爾思天行網(wǎng)安信息技術(shù)有限責(zé)任公司,北京 100000)

    0 概述

    隨著大數(shù)據(jù)時代的興起,眾多企事業(yè)單位都建立了龐大的數(shù)據(jù)中心,有效地整合了各類數(shù)據(jù)資源,以供高效地采集數(shù)據(jù)[1],并通過搭建大數(shù)據(jù)分析平臺,對數(shù)據(jù)資源進(jìn)行實(shí)時分析和監(jiān)控等操作[2]。然而,傳統(tǒng)數(shù)據(jù)采集技術(shù)不能滿足數(shù)據(jù)中心海量數(shù)據(jù)、類型多樣化等需求,無法實(shí)現(xiàn)數(shù)據(jù)高效采集,并且內(nèi)網(wǎng)數(shù)據(jù)中心、外網(wǎng)大數(shù)據(jù)平臺等非對稱安全等級網(wǎng)域之間在直接進(jìn)行數(shù)據(jù)交互時,內(nèi)網(wǎng)存在網(wǎng)絡(luò)滲透、數(shù)據(jù)篡改等安全隱患。因此,如何保證數(shù)據(jù)采集的高效性、內(nèi)網(wǎng)數(shù)據(jù)的安全性,成為亟待解決的問題[3-4]。

    為解決當(dāng)前數(shù)據(jù)采集存在的性能問題,國內(nèi)外學(xué)者進(jìn)行了廣泛的研究。對數(shù)據(jù)中心海量、實(shí)時、異構(gòu)的數(shù)據(jù)采集傳輸場景,傳統(tǒng)的內(nèi)網(wǎng)數(shù)據(jù)采集技術(shù)已經(jīng)不滿足當(dāng)前需求,而消息中間件Kafka 具有高性能、低時延等特點(diǎn)[5-6],并且具備分布式集群部署能力,能夠有效提高數(shù)據(jù)采集傳輸?shù)男省?/p>

    針對內(nèi)網(wǎng)數(shù)據(jù)中心與外網(wǎng)大數(shù)據(jù)分析平臺直接交互時存在的數(shù)據(jù)安全問題,為提高網(wǎng)絡(luò)環(huán)境的安全性,研究人員提出了一系列跨網(wǎng)域數(shù)據(jù)交換的安全措施,其中主要方法是單向數(shù)據(jù)傳輸[7-8]。單向數(shù)據(jù)傳輸通過構(gòu)建不同安全等級的網(wǎng)域,避免內(nèi)外網(wǎng)直接交互,從而有效防止內(nèi)網(wǎng)攻擊、數(shù)據(jù)篡改等安全問題[9-10]。

    目前,單向傳輸技術(shù)一般都采用硬件光閘和軟件協(xié)議相結(jié)合的形式,從物理和邏輯兩個層面保證傳輸過程中內(nèi)網(wǎng)數(shù)據(jù)安全[11]。文獻(xiàn)[12]提出采用單向光網(wǎng)卡進(jìn)行數(shù)據(jù)單向傳輸,通過小反饋技術(shù)進(jìn)行數(shù)據(jù)的確認(rèn),兩個方向都不能建立在線連接,可以有效防止網(wǎng)絡(luò)攻擊。單向光網(wǎng)卡兩端采用私有協(xié)議進(jìn)行數(shù)據(jù)傳輸,保證傳輸過程中內(nèi)網(wǎng)數(shù)據(jù)的安全性。文獻(xiàn)[13]設(shè)計一個以二維碼為信息載體的移動端單向傳輸系統(tǒng),完成涉密信息從低密級網(wǎng)絡(luò)向高密級網(wǎng)絡(luò)的單向傳輸,不依賴單向的物理傳輸設(shè)備,信息傳輸工作只在軟件層面進(jìn)行,降低了對專業(yè)設(shè)備的要求,從而保證低密級網(wǎng)絡(luò)的安全性。文獻(xiàn)[14]針對不同安全等級網(wǎng)絡(luò)之間數(shù)據(jù)單向傳輸?shù)男枨?,提出一種單向代理傳輸協(xié)議,該協(xié)議運(yùn)行在計算機(jī)網(wǎng)絡(luò)體系中的網(wǎng)絡(luò)層,是一種非IP 協(xié)議,通過該協(xié)議實(shí)現(xiàn)了數(shù)據(jù)單向傳輸。

    上述研究對于提升數(shù)據(jù)采集的安全性具有一定的參考價值,然而這些單向傳輸系統(tǒng)存在一些性能瓶頸,基于UDP 協(xié)議或相關(guān)私有傳輸協(xié)議實(shí)現(xiàn)的單向傳輸系統(tǒng)存在傳輸時延過高、CPU 開銷過大等問題。因此,在對數(shù)據(jù)時延敏感的業(yè)務(wù)場景中,傳統(tǒng)的單向傳輸系統(tǒng)不能滿足真實(shí)需求。

    本文將遠(yuǎn)程直接內(nèi)存訪問(Remote Direct Memory Access,RDMA)技術(shù)應(yīng)用于單向數(shù)據(jù)采集場景,設(shè)計一種基于RDMA 的高性能單向數(shù)據(jù)采集(One-way Data Acquisition by RDMA,ODAR)架構(gòu)。RDMA 技術(shù)[15]通過網(wǎng)絡(luò)將數(shù)據(jù)直接寫入遠(yuǎn)端主機(jī)的內(nèi)存區(qū)域,繞過內(nèi)核處理,避免用戶態(tài)和內(nèi)核態(tài)之間的頻繁拷貝,降低系統(tǒng)的上下文切換的開銷,實(shí)現(xiàn)高帶寬和低時延的數(shù)據(jù)傳輸[16]。ODAR 架構(gòu)采用RDMA 技術(shù)的不可靠連接(Unreliable Connect,UC)模式,以及RDMA 技術(shù)所提供的Write 單邊原語進(jìn)行數(shù)據(jù)傳輸,從軟件層面保證數(shù)據(jù)傳遞的單向性與內(nèi)網(wǎng)的安全性。此外,ODAR 架構(gòu)為保證傳輸數(shù)據(jù)的完整性和正確性,設(shè)計基于可靠性的數(shù)據(jù)封裝策略,保證數(shù)據(jù)能夠正確傳輸?shù)浇邮斩藢?yīng)的節(jié)點(diǎn),并針對內(nèi)存分配存在時延過高的問題,結(jié)合RDMA 技術(shù)設(shè)計動態(tài)內(nèi)存優(yōu)化策略,通過對內(nèi)存的復(fù)用以及內(nèi)存分配和數(shù)據(jù)封裝,發(fā)送異步操作降低數(shù)據(jù)的時延。最后,提出基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度算法,解決數(shù)據(jù)傳輸時存在網(wǎng)卡帶寬實(shí)際利用率過低的問題,以提高網(wǎng)卡帶寬的實(shí)際傳輸量。

    1 基于RDMA 的高性能單向數(shù)據(jù)采集架構(gòu)

    針對當(dāng)前數(shù)據(jù)采集技術(shù)中存在的數(shù)據(jù)安全和傳輸性能問題,本文設(shè)計基于RDMA 的高性能單向數(shù)據(jù)采集架構(gòu),該架構(gòu)能保障數(shù)據(jù)傳輸時內(nèi)網(wǎng)的安全性,提高網(wǎng)絡(luò)傳輸性能。如圖1 所示,ODAR 架構(gòu)主要分為發(fā)送端和接收端,發(fā)送端包括初始化模塊、數(shù)據(jù)封裝模塊、數(shù)據(jù)傳輸調(diào)度模塊、數(shù)據(jù)發(fā)送模塊,接收端包括數(shù)據(jù)初始化模塊、數(shù)據(jù)處理模塊、數(shù)據(jù)接收模塊。

    圖1 ODAR 總體架構(gòu)Fig.1 ODAR overall architecture

    1.1 初始化模塊

    發(fā)送端初始化模塊主要負(fù)責(zé)消息隊列Kafka 和RDMA 網(wǎng)卡等信息初始化。如圖2 所示,首先構(gòu)建Kafka 集群,將Kafka 的生產(chǎn)者接口與數(shù)據(jù)中心服務(wù)器節(jié)點(diǎn)對接進(jìn)行數(shù)據(jù)采集,并將消費(fèi)者接口與發(fā)送主機(jī)對接,在該發(fā)送主機(jī)中監(jiān)聽多個Kafka 集群中的Broker[17],構(gòu)成多對一模式。然后根據(jù)需求將采集到的數(shù)據(jù)交由數(shù)據(jù)封裝模塊進(jìn)行處理。

    圖2 初始化過程Fig.2 Initialization process

    類似地,接收端的初始化模塊也需要對接收端一側(cè)的消息隊列Kafka 和RDMA 網(wǎng)卡進(jìn)行初始化操作,將接收主機(jī)作為生產(chǎn)者對接Kafka 集群,大數(shù)據(jù)分析平臺作為消費(fèi)者對接Kafka 集群。

    1.2 數(shù)據(jù)封裝模塊

    數(shù)據(jù)封裝模塊對應(yīng)基于可靠性的數(shù)據(jù)封裝和動態(tài)內(nèi)存優(yōu)化。首先進(jìn)行數(shù)據(jù)分類,根據(jù)數(shù)據(jù)類型將數(shù)據(jù)區(qū)分為普通數(shù)據(jù)和實(shí)時數(shù)據(jù),通過原始數(shù)據(jù)的長度以及封裝信息分配內(nèi)存,為數(shù)據(jù)包設(shè)置相對應(yīng)的優(yōu)先級,然后根據(jù)數(shù)據(jù)來源設(shè)置標(biāo)志信息,計算校驗碼,最后將這些信息封裝為一個完整的數(shù)據(jù)包,用于保證傳輸數(shù)據(jù)的安全性和準(zhǔn)確性。

    1.3 數(shù)據(jù)傳輸調(diào)度模塊

    數(shù)據(jù)傳輸調(diào)度模塊對應(yīng)基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度,主要負(fù)責(zé)數(shù)據(jù)的分類處理,并根據(jù)當(dāng)前的數(shù)據(jù)包長度進(jìn)行傳輸調(diào)度,提高網(wǎng)卡帶寬的實(shí)際利用率,在傳輸時將數(shù)據(jù)進(jìn)行序列化處理,提高數(shù)據(jù)的傳輸效率。

    1.4 數(shù)據(jù)發(fā)送模塊

    如圖3 所示,在第1.1 節(jié)初始化模塊中,用戶初始化RDMA 網(wǎng)卡靜態(tài)信息,將連接信息存入RDMA隊列對(Queue Pair,QP)的隊列對上下 文(QP Context,QPC)中,QP 由發(fā)送隊列(Send Queue,SQ)和接收隊列(Receive Queue,RQ)組成[18-19],ODAR 架構(gòu)使用RDMA 的不可靠連接(UC)[20]模式,保證傳輸過程的單向性。在第1.2 節(jié)和第1.3 節(jié)對數(shù)據(jù)進(jìn)行封裝和調(diào)度之后,可以創(chuàng)建工作任務(wù),按序存入SQ中,RDMA 網(wǎng)卡(RDMA NIC)根據(jù)SQ 中的工作任務(wù)信息獲取內(nèi)存中的數(shù)據(jù),使用RDMA 單邊原語Write[21]根據(jù)配置信息將數(shù)據(jù)直接寫入接收端指定的內(nèi)存區(qū)域,該數(shù)據(jù)傳輸過程繞過內(nèi)核處理,從而降低了CPU的開銷。

    圖3 數(shù)據(jù)發(fā)送流程Fig.3 Data sending procedure

    1.5 數(shù)據(jù)接收模塊

    通過配置信息,數(shù)據(jù)接收模塊與RDMA 發(fā)送方建立連接,當(dāng)RDMA 發(fā)送端使用RDMA 原語Write將數(shù)據(jù)寫入接收端內(nèi)存之后,響應(yīng)RQ 中的接收請求,產(chǎn)生工作完成(Work Completion,WC)信息告知上層[22-23],因此根據(jù)發(fā)送數(shù)據(jù)包攜帶的數(shù)據(jù)信息,接收端對指定接收內(nèi)存區(qū)域進(jìn)行輪詢,獲取寫入的數(shù)據(jù),然后將接收到的數(shù)據(jù)交由接收方的數(shù)據(jù)處理模塊進(jìn)行處理。

    1.6 數(shù)據(jù)處理模塊

    接收端的數(shù)據(jù)處理模塊對應(yīng)發(fā)送端的數(shù)據(jù)封裝模塊,申請了與發(fā)送端相同大小的內(nèi)存空間,首先將接收內(nèi)存中的數(shù)據(jù)包解封裝處理,對處理完成后的內(nèi)存空間進(jìn)行回收復(fù)用。其次將數(shù)據(jù)包排序,根據(jù)封裝信息將數(shù)據(jù)包還原為原始數(shù)據(jù),存入對應(yīng)的Kafka 集群中。

    2 基于可靠性的數(shù)據(jù)封裝

    ODAR 架構(gòu)從物理和邏輯兩個層面來保證數(shù)據(jù)傳輸?shù)膯蜗蛐?,?shù)據(jù)只能由內(nèi)網(wǎng)發(fā)送到外網(wǎng),沒有數(shù)據(jù)回路,從而保證了內(nèi)網(wǎng)的安全性。由于發(fā)送端監(jiān)聽了多個服務(wù)器節(jié)點(diǎn)進(jìn)行數(shù)據(jù)采集,如果直接傳輸原始數(shù)據(jù),接收端無法根據(jù)數(shù)據(jù)信息將接收到的數(shù)據(jù)準(zhǔn)確分發(fā)到對應(yīng)的節(jié)點(diǎn)。針對上述問題,本節(jié)設(shè)計了基于可靠性的數(shù)據(jù)封裝策略,保證了傳輸數(shù)據(jù)的準(zhǔn)確性,接收端能夠根據(jù)封裝的數(shù)據(jù)信息將數(shù)據(jù)分發(fā)到對應(yīng)的節(jié)點(diǎn)。封裝過程如圖4 所示。

    圖4 基于可靠性的數(shù)據(jù)封裝過程Fig.4 Reliability-based data encapsulation process

    封裝過程如下:

    1)解析原始數(shù)據(jù)信息進(jìn)行數(shù)據(jù)分類,采集到的數(shù)據(jù)可以劃分為實(shí)時數(shù)據(jù)和普通數(shù)據(jù)。實(shí)時數(shù)據(jù)對時延敏感,而普通數(shù)據(jù)允許一定的時延,因此需要將它們分類處理。數(shù)據(jù)包封裝時需要分配內(nèi)存空間,本文結(jié)合RDMA 技術(shù)設(shè)計動態(tài)內(nèi)存優(yōu)化策略。

    2)根據(jù)數(shù)據(jù)的來源對數(shù)據(jù)做標(biāo)識,保證接收端能夠根據(jù)封裝信息將數(shù)據(jù)準(zhǔn)確地分發(fā)到對應(yīng)的節(jié)點(diǎn)中。

    3)設(shè)定數(shù)據(jù)長度閾值,當(dāng)數(shù)據(jù)長度超過閾值時,將數(shù)據(jù)分片壓縮,如果數(shù)據(jù)過小未達(dá)到閾值,則無須分片,并根據(jù)數(shù)據(jù)的優(yōu)先級選用不同的加密算法,保證數(shù)據(jù)的安全性。計算數(shù)據(jù)的校驗碼,附加在數(shù)據(jù)包的尾部,在接收端能夠通過校驗碼來進(jìn)行判別該數(shù)據(jù)是否完整。對于分片的數(shù)據(jù)增加片段編碼,避免數(shù)據(jù)重新組裝時出現(xiàn)問題。

    增加數(shù)據(jù)的頭部和尾部信息以及數(shù)據(jù)包編號等內(nèi)容,組成一個完整的發(fā)送數(shù)據(jù)包,在數(shù)據(jù)發(fā)送前,對數(shù)據(jù)做序列化處理,提高傳輸效率。

    3 動態(tài)內(nèi)存優(yōu)化

    在ODAR 架構(gòu)中,由于RDMA 具有Kernel Bypass 特性[24],因此需要在數(shù)據(jù)發(fā)送前鎖定申請的發(fā)送內(nèi)存,防止Swap 機(jī)制導(dǎo)致虛擬內(nèi)存和物理內(nèi)存之間的映射產(chǎn)生變化。由于在發(fā)送主機(jī)中開啟了多個消費(fèi)者線程監(jiān)聽Kafka 集群中的多個節(jié)點(diǎn),在數(shù)據(jù)傳輸過程中,需要對采集到的原始數(shù)據(jù)進(jìn)行封裝,避免數(shù)據(jù)傳輸?shù)浇邮斩酥鬅o法存放到對應(yīng)節(jié)點(diǎn)。在高并發(fā)環(huán)境中,為了避免同時操作相同內(nèi)存區(qū)域?qū)е聰?shù)據(jù)出錯,因此多個線程之間需要保持互斥性,等待RDMA 發(fā)送內(nèi)存中數(shù)據(jù)發(fā)送完成,再由其他線程繼續(xù)寫入數(shù)據(jù),上述同步操作會導(dǎo)致數(shù)據(jù)產(chǎn)生過高的時延。針對該問題,提出動態(tài)內(nèi)存優(yōu)化策略,將RDMA 發(fā)送內(nèi)存構(gòu)建成一個環(huán)形緩沖區(qū),使內(nèi)存分配、數(shù)據(jù)封裝和數(shù)據(jù)發(fā)送可以異步執(zhí)行,從而降低數(shù)據(jù)時延。動態(tài)內(nèi)存優(yōu)化流程如圖5 所示。

    圖5 動態(tài)內(nèi)存優(yōu)化流程Fig.5 Dynamic memory optimization procedure

    動態(tài)內(nèi)存優(yōu)化流程如下:

    1)初次申請內(nèi)存:系統(tǒng)會對內(nèi)存進(jìn)行初始化操作,申請大塊的連續(xù)RDMA 發(fā)送內(nèi)存,用于內(nèi)存再分配。

    2)內(nèi)存申請:后續(xù)所申請的空間都是由該內(nèi)存再分配,并返回申請內(nèi)存區(qū)域的地址信息。

    3)回收內(nèi)存:根據(jù)該區(qū)域的狀態(tài)信息,啟動一個線程不斷回收可復(fù)用的內(nèi)存空間,用于后續(xù)再分配過程。

    4)數(shù)據(jù)封裝:按照封裝格式將數(shù)據(jù)寫入申請的內(nèi)存區(qū)域中。

    5)請求發(fā)送:將內(nèi)存中封裝好的數(shù)據(jù)發(fā)送到接收端。在數(shù)據(jù)封裝和數(shù)據(jù)發(fā)送過程中,其他線程可以繼續(xù)申請內(nèi)存,達(dá)到異步處理的效果。

    由于采集的數(shù)據(jù)包長度不可預(yù)估,為保證能夠充分利用內(nèi)存空間,根據(jù)原始數(shù)據(jù)信息和數(shù)據(jù)封裝信息在初始化的RDMA 發(fā)送內(nèi)存上動態(tài)申請對應(yīng)長度的空間,并保證申請過程中各個線程之間的互斥性。

    首先將RDMA 發(fā)送內(nèi)存的首尾地址、長度、使用狀態(tài)等信息作為一個鏈表節(jié)點(diǎn)存入記錄當(dāng)前內(nèi)存信息的鏈表List_Cur中。在申請內(nèi)存時,需要遍歷鏈表List_Cur,判斷當(dāng)前RDMA 內(nèi)存剩余容量是否足夠分配,如果內(nèi)存充足,那么記錄申請內(nèi)存區(qū)域的首地址Node_Head、尾地址Node_Tail、長度和使用狀態(tài)等信息,將申請的內(nèi)存區(qū)域的信息作為一個鏈表節(jié)點(diǎn),插入記錄使用內(nèi)存信息的鏈表List_Used 尾部,在申請的同時,需要更新鏈表List_Cur 中當(dāng)前RDMA 發(fā)送內(nèi)存的信息,將指向當(dāng)前RDMA 發(fā)送內(nèi)存頭部的指針RDMA_Cur 向后移動,直到指向RDMA 發(fā)送內(nèi)存的尾部指針RDMA_Tail。如果內(nèi)存余量不充足,出現(xiàn)圖6 所示中Situation 2 的情況,則可以利用RDMA 技術(shù)所具備的分散聚合特性,即RDMA 支持分散/聚合條目[25],讀取多個內(nèi)存區(qū)域中的數(shù)據(jù)作為一個流直接寫入到遠(yuǎn)端內(nèi)存中,即可以將數(shù)據(jù)拆分,存放在兩個不連續(xù)的內(nèi)存空間中,并在RDMA 發(fā)送任務(wù)中指定這兩片內(nèi)存的地址和長度信息,網(wǎng)卡根據(jù)指定的信息將數(shù)據(jù)發(fā)送。

    在數(shù)據(jù)發(fā)送完畢后,更新鏈表List_Used 中內(nèi)存節(jié)點(diǎn)的信息,將使用狀態(tài)設(shè)置為可回收狀態(tài),由回收線程進(jìn)行處理,從鏈表List_Used 頭部開始遍歷節(jié)點(diǎn),判斷鏈表List_Cur 的尾部節(jié)點(diǎn)的尾地址是否與回收的內(nèi)存節(jié)點(diǎn)的頭地址相等,如果相等則將回收的內(nèi)存節(jié)點(diǎn)信息合并到鏈表List_Cur 的尾部節(jié)點(diǎn)中。由于在對RDMA 發(fā)送內(nèi)存再分配時始終按照順序?qū)⒅羔槒念^部向尾部移動,如果不相等,表示當(dāng)前回收節(jié)點(diǎn)的首地址是RDMA 發(fā)送內(nèi)存的首地址,鏈表List_Cur 中尾節(jié)點(diǎn)的尾地址是RDMA 發(fā)送內(nèi)存的尾地址RDMA_Tail,因此將回收的節(jié)點(diǎn)作為一個新的節(jié)點(diǎn)插入到鏈表List_Cur 尾部。RDMA 發(fā)送內(nèi)存的再分配與回收始終按照地址順序操作,避免出現(xiàn)內(nèi)存碎片。

    4 基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度

    在數(shù)據(jù)采集時,由于數(shù)據(jù)包長度不可預(yù)估,針對頻繁發(fā)送小型數(shù)據(jù)包存在網(wǎng)卡帶寬利用率過低的問題,本文提出基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度算法,對實(shí)時數(shù)據(jù)和普通數(shù)據(jù)兩種類型數(shù)據(jù)采用不同處理方式。

    根據(jù)采集的數(shù)據(jù)類型區(qū)分優(yōu)先級,實(shí)時數(shù)據(jù)對于時延敏感,要求在傳輸過程中盡可能地降低時延,因此在傳輸過程中使用數(shù)據(jù)流式傳輸模式,指定數(shù)據(jù)存放內(nèi)存地址交由網(wǎng)卡直接發(fā)送。而普通數(shù)據(jù)可以適當(dāng)?shù)亟邮找恍?shù)據(jù)延遲,為保證網(wǎng)卡帶寬利用率,當(dāng)普通數(shù)據(jù)長度小于發(fā)送數(shù)據(jù)包長度閾值Data_Len時,采用數(shù)據(jù)發(fā)送策略,將多個小型數(shù)據(jù)包累積成一個大型數(shù)據(jù)包,可以有效提高網(wǎng)卡帶寬利用率,具體數(shù)據(jù)發(fā)送策略流程如圖7 所示。

    實(shí)時監(jiān)控數(shù)據(jù)的發(fā)送速率在數(shù)據(jù)發(fā)送速率超過閾值時,接收方因為處理不及時,存在數(shù)據(jù)丟包問題,因此當(dāng)數(shù)據(jù)發(fā)送速率過高時,需要對其限速。

    具體傳輸調(diào)度算法偽代碼如下:

    算法1基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度算法

    1.Timer()

    2.while there is new data to send

    3.if Throughput >=Max_Throughput

    4.Speed_limit()

    5.if Data->pkt_priority==Realtime_Data

    6.RDMA_Buffer←Data

    7.RDMA_Post_Send(RDMA_Buffer)

    8.continue

    9.if Data->pkt_len>Data_Len

    10.Send_Queue(Data)

    11.else

    12.SubTimer()

    13.while Sub_Wait_Time<=

    Max_Wait_time or Total_Len<=Max_DataSize do:

    14.Data_Merge(data)

    15.end while

    16.Send_Queue(Data)

    17.end if

    18.if Wait_Time==MAX_Cal_Time

    19.Recalculate_Throughput()

    20.end while

    算法1描述基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度過程。輸入待發(fā)送的數(shù)據(jù),在數(shù)據(jù)傳輸時,啟動一個定時器Timer(第1 行),用于實(shí)時計算吞吐量(第19 行),當(dāng)吞吐量高于閾值時,調(diào)用Speed_limit 函數(shù)進(jìn)行限速,避免傳輸速度過快、接收不及時產(chǎn)生丟包問題(第4 行)。

    在數(shù)據(jù)封裝過程中,根據(jù)采集數(shù)據(jù)的不同類型,規(guī)定了不同的優(yōu)先級pkt_priority,因此在數(shù)據(jù)傳輸時根據(jù)數(shù)據(jù)的優(yōu)先級來實(shí)施調(diào)度。判斷該數(shù)據(jù)包是否是實(shí)時數(shù)據(jù)Realtime_Data,如果是實(shí)時數(shù)據(jù),為盡可能降低時延,不考慮數(shù)據(jù)包長度都直接使用數(shù)據(jù)流傳輸模式,直接將數(shù)據(jù)寫入緩存,將數(shù)據(jù)存入發(fā)送隊列Send_Queue,保證了數(shù)據(jù)的時效性(第5~8 行)。

    當(dāng)傳輸普通數(shù)據(jù)時,為保證網(wǎng)卡帶寬的利用率,針對小型數(shù)據(jù)包采取數(shù)據(jù)發(fā)送策略,將數(shù)據(jù)包盡可能地歸并成一個大的數(shù)據(jù)包發(fā)送,提高實(shí)際發(fā)送的數(shù)據(jù)量。

    普通數(shù)據(jù)發(fā)送策略主要將多個小型數(shù)據(jù)包歸并為一個大型數(shù)據(jù)包,具體操作如下:

    普通數(shù)據(jù)首先判斷原始數(shù)據(jù)塊的長度是否大于發(fā)送數(shù)據(jù)包長度閾值Data_Len,如果大于Data_Len,判斷數(shù)據(jù)的標(biāo)志,即判斷數(shù)據(jù)來源,將數(shù)據(jù)存入相對應(yīng)的發(fā)送隊列(第9~10 行)。然后,當(dāng)原始數(shù)據(jù)塊長度小于Data_Len時,首先在第3 節(jié)內(nèi)存分配時需要申請一個發(fā)送數(shù)據(jù)包大小的空間,然后開始?xì)w并數(shù)據(jù),啟動一個子定時器SubTimer 用于定時,計算歸并數(shù)據(jù)包總長度Total_Len 以及歸并等待時間Sub_Wait_Time,將多個來自同一個節(jié)點(diǎn)的小型原始數(shù)據(jù)塊歸并為一個大的數(shù)據(jù)塊,不同節(jié)點(diǎn)的數(shù)據(jù)則分類歸并,在多個小型原始數(shù)據(jù)塊之間增加邊界符,并在數(shù)據(jù)包頭部信息中寫入對應(yīng)的長度和編號等信息,從而提高了網(wǎng)卡帶寬的有效利用率,當(dāng)接收端接收到數(shù)據(jù)之后,根據(jù)封裝信息和編號重新排序還原為原始數(shù)據(jù)塊。最后,如果數(shù)據(jù)包總長度Total_Len大于Data_Len,或者Sub_Wait_Time 大于最大等待時間Max_Wait_Time,則根據(jù)數(shù)據(jù)的標(biāo)志將數(shù)據(jù)存入對應(yīng)的發(fā)送隊列中(第12~16 行)。

    5 實(shí)驗結(jié)果與分析

    實(shí)驗主要對比基于UDP 和基于RDMA 技術(shù)實(shí)現(xiàn)的單向數(shù)據(jù)采集性能,并驗證基于可靠性的數(shù)據(jù)封裝的有效性、動態(tài)內(nèi)存優(yōu)化的性能以及基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度的有效性。

    本文的實(shí)驗環(huán)境為操作系統(tǒng)CentOS7,并且在發(fā)送端和接收端兩臺服務(wù)器上分別裝載支持RDMA 技術(shù)運(yùn)行的相關(guān)驅(qū)動MLNX_OFED(version 4.9-2.2.4.0)。RDMA 測試使用網(wǎng)卡InifinBand connectX-3,UDP 測試使用網(wǎng)卡NetXtreme BCM5720,兩張網(wǎng)卡均為萬兆網(wǎng)卡。

    5.1 ODAR 架構(gòu)性能驗證測試

    實(shí)驗測試在相同環(huán)境中基于RDMA 與基于UDP 實(shí)現(xiàn)的單向數(shù)據(jù)采集技術(shù)的吞吐量、時延、CPU開銷,驗證RDMA 技術(shù)應(yīng)用在單向環(huán)境中的性能。

    實(shí)驗性能測試的計算公式如式(1)所示:

    其中:區(qū)間[i,j]表示數(shù)據(jù)包長度的區(qū)間范圍;Mi表示在數(shù)據(jù)包長度為i使用RDMA 測試性能的數(shù)值;Ni表示數(shù)據(jù)包長度為i使用UDP 測試性能的數(shù)值;avg 代表在區(qū)間[i,j]內(nèi)使用RDMA 技術(shù)相對于使用UDP的性能平均提升數(shù)值。

    1)吞吐量測試

    實(shí)驗測試基于RDMA 技術(shù)與基于UDP 協(xié)議實(shí)現(xiàn)的單向數(shù)據(jù)采集的吞吐量,控制數(shù)據(jù)總量及數(shù)據(jù)包長度,保證數(shù)據(jù)流量充足,忽略數(shù)據(jù)處理過程的開銷。實(shí)驗結(jié)果如圖8 所示。

    圖8 吞吐量測試結(jié)果Fig.8 Test result of throughput

    實(shí)驗結(jié)果表明,在數(shù)據(jù)包長度區(qū)間[8 Byte,4 096 Byte]時,使用RDMA 和使用UDP 的吞吐量均處于增長階段,而使用RDMA 技術(shù)的吞吐量此時明顯優(yōu)于使用UDP,在數(shù)據(jù)包大于4 096 Byte后,當(dāng)前兩者吞吐量大小均接近閾值,并逐漸趨于穩(wěn)定。

    由于使用UDP 協(xié)議傳輸過程中需要操作系統(tǒng)封裝和解析數(shù)據(jù)、驗證數(shù)據(jù)完整性等工作,當(dāng)數(shù)據(jù)包長度較小時,對于相同待傳輸數(shù)據(jù)量操作系統(tǒng)需要處理更多的數(shù)據(jù)包,這個過程中操作系統(tǒng)會在內(nèi)核態(tài)和用戶態(tài)頻繁地切換,對CPU 資源的消耗急劇增加,因此CPU 的性能成為傳輸?shù)钠款i,所以UDP 在數(shù)據(jù)包長度較小的情況下吞吐量損失十分明顯,而RDMA 技術(shù)具有零拷貝和內(nèi)核旁路等特點(diǎn),在數(shù)據(jù)傳輸過程中,CPU 無須參與,通過DMA 引擎直接與用戶態(tài)進(jìn)行交互,數(shù)據(jù)包的封裝和解析工作交由RDMA 的硬件網(wǎng)卡來完成,從而避免過多地切換上下文,因此吞吐量、時延以及CPU 開銷這3 個方面相對于UDP 協(xié)議,RDMA 都具有明顯優(yōu)勢。

    根據(jù)式(1)計算結(jié)果表明,基于RDMA 實(shí)現(xiàn)的單向數(shù)據(jù)采集技術(shù)的吞吐量,相對于UDP 協(xié)議平均提高了57.01%。

    2)傳輸時延測試

    實(shí)驗測試基于RDMA 技術(shù)與基于UDP 協(xié)議實(shí)現(xiàn)的單向數(shù)據(jù)采集的時延,控制數(shù)據(jù)總量及數(shù)據(jù)包長度,保證數(shù)據(jù)流量充足,忽略數(shù)據(jù)處理過程的開銷。實(shí)驗結(jié)果如圖9 所示。從圖9 可以看出,在整個數(shù)據(jù)包長度區(qū)間內(nèi),使用RDMA 技術(shù)的時延明顯小于使用UDP 協(xié)議。主要原因同樣在于RDMA 技術(shù)是繞過內(nèi)核,直接由網(wǎng)卡來進(jìn)行封裝解析,無須像UDP 協(xié)議那樣需要層層封裝,頻繁地上下文切換會導(dǎo)致時延急劇增加。

    圖9 傳輸時延測試結(jié)果Fig.9 Test result of transmission delay

    根據(jù)式(1)計算結(jié)果表明,基于RDMA 技術(shù)實(shí)現(xiàn)的單向數(shù)據(jù)采集相對于基于UDP 協(xié)議實(shí)現(xiàn)的單向數(shù)據(jù)采集的傳輸時延平均降低了61.27%。

    3)CPU 開銷測試

    實(shí)驗測試基于RDMA 技術(shù)與基于UDP 協(xié)議實(shí)現(xiàn)的單向數(shù)據(jù)采集的CPU 開銷,控制數(shù)據(jù)總量及數(shù)據(jù)包長度,保證數(shù)據(jù)流量充足,忽略數(shù)據(jù)處理過程的開銷。CPU 開銷測試結(jié)果如圖10 所示。從圖10 可以看出,在整個數(shù)據(jù)包長度區(qū)間范圍內(nèi),使用RDMA技術(shù)的CPU 開銷明顯小于使用UDP 協(xié)議。主要原因與吞吐量測試相同,使用UDP 協(xié)議在數(shù)據(jù)傳輸時頻繁地上下文切換,導(dǎo)致CPU 消耗急劇增加,而RDMA 除了在程序初始化時注冊內(nèi)存等操作需要消耗CPU 資源,整個數(shù)據(jù)傳輸過程直接繞過內(nèi)核處理,無須CPU 的參與。根據(jù)式(1)計算結(jié)果表明,基于RDMA 技術(shù)實(shí)現(xiàn)的單向數(shù)據(jù)采集相對于基于UDP協(xié)議實(shí)現(xiàn)的CPU 開銷平均降低了68.01%。通過吞吐量、時延以及CPU 開銷3 個方面驗證了ODAR 架構(gòu)的優(yōu)勢性能。

    圖10 CPU 開銷測試結(jié)果Fig.10 Test result of CPU overhead

    5.2 基于可靠性的數(shù)據(jù)封裝測試

    實(shí)驗分別測試基于可靠性的數(shù)據(jù)封裝和使用原始數(shù)據(jù)傳輸兩種情況下接收端接收數(shù)據(jù)的正確率。實(shí)驗測試結(jié)果如表1所示,當(dāng)數(shù)據(jù)包長度為4 096 Byte左右時,吞吐量接近閾值,且此時的時延較低,因此設(shè)置發(fā)送的數(shù)據(jù)包長度為4 096 Byte,發(fā)送總量分別為10/20/30 GB,每個總量發(fā)送10 次求取其平均值。如果直接使用原始數(shù)據(jù)塊發(fā)送,則數(shù)據(jù)再發(fā)送到接收端,由于未標(biāo)識數(shù)據(jù)的來源以及應(yīng)該存放對應(yīng)位置的信息,導(dǎo)致數(shù)據(jù)不能正確被分發(fā),只能由分發(fā)線程隨機(jī)分發(fā),導(dǎo)致大規(guī)模數(shù)據(jù)出錯的現(xiàn)象,而基于可靠性的數(shù)據(jù)封裝之后,接收方根據(jù)數(shù)據(jù)標(biāo)識基本可以正確接收數(shù)據(jù),平均提高了93.3%,但由于發(fā)送速率過快,存在部分丟包現(xiàn)象。

    表1 基于可靠性的數(shù)據(jù)封裝測試Table 1 Reliability-based data encapsulation test

    5.3 動態(tài)內(nèi)存優(yōu)化測試

    實(shí)驗測試內(nèi)存分配和數(shù)據(jù)封裝、發(fā)送同步操作的情況,以及使用本文設(shè)計的動態(tài)內(nèi)存優(yōu)化情況下測試相同大小的數(shù)據(jù)從申請內(nèi)存開始到數(shù)據(jù)發(fā)送的平均時延,對比兩者在ODAR 架構(gòu)中的差異。實(shí)驗性能測試的計算公式見式(1),其中,區(qū)間[i,j]表示數(shù)據(jù)包長度的區(qū)間,Mi表示使用動態(tài)內(nèi)存優(yōu)化策略在數(shù)據(jù)包長度為i的測試的數(shù)值,Ni表示同步操作在數(shù)據(jù)包長度為i測試的數(shù)據(jù)值,avg 表示使用動態(tài)內(nèi)存優(yōu)化策略相對于同步操作在數(shù)據(jù)包長度區(qū)間[i,j]性能平均提升值。

    時延測試結(jié)果如圖11 所示,其中,RDMA-syn 曲線表示同步操作時的時延曲線,RDMA-asyn 表示使用本文設(shè)計的動態(tài)內(nèi)存優(yōu)化的時延曲線??刂茢?shù)據(jù)發(fā)送總量,保證數(shù)據(jù)量充足,根據(jù)測試數(shù)據(jù)顯示,在高并發(fā)環(huán)境中,整個數(shù)據(jù)包長度區(qū)間內(nèi)ODAR 架構(gòu)使用動態(tài)內(nèi)存優(yōu)化策略的時延明顯較低,動態(tài)內(nèi)存優(yōu)化策略使時延平均降低了80.15%。

    圖11 動態(tài)內(nèi)存優(yōu)化-時延測試結(jié)果Fig.11 Test result of dynamic memory optimization-delay

    實(shí)驗結(jié)果證明了動態(tài)內(nèi)存優(yōu)化策略的優(yōu)勢性能。在數(shù)據(jù)封裝和數(shù)據(jù)發(fā)送時,對接Kafka 集群的多個數(shù)據(jù)消費(fèi)線程無法運(yùn)行,必須等待數(shù)據(jù)封裝、發(fā)送完成之后才能繼續(xù)運(yùn)行,從而導(dǎo)致處理時間開銷增大,而使用動態(tài)內(nèi)存優(yōu)化操作時,將內(nèi)存分配和數(shù)據(jù)封裝,發(fā)送異步操作,使RDMA 發(fā)送內(nèi)存構(gòu)建為一個環(huán)形緩沖區(qū),在數(shù)據(jù)封裝與發(fā)送時,其他消費(fèi)者線程仍然可以申請內(nèi)存,因此時延隨之降低。

    5.4 基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度測試

    由于數(shù)據(jù)采集到的原始數(shù)據(jù)包存在長度不確定的情況,如果采集到海量小型原始數(shù)據(jù)塊,并將其封裝成一個數(shù)據(jù)包直接發(fā)送時,則封裝信息長度在數(shù)據(jù)包長度中占比過高會導(dǎo)致網(wǎng)卡帶寬的利用率嚴(yán)重下降,因此本文提出基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度算法。

    在實(shí)際傳輸時為保證實(shí)時數(shù)據(jù)的低時延,對于數(shù)據(jù)采用流式處理,而普通數(shù)據(jù)可以容忍一些數(shù)據(jù)時延。為提高當(dāng)前網(wǎng)卡帶寬的有效利用率,本文采用對應(yīng)的數(shù)據(jù)發(fā)送策略。測試結(jié)果如圖12 所示,其中,RDMA-Scheduling 表示基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度,RDMA-Raw 表示未做任何調(diào)度。實(shí)驗性能測試的計算公式見式(1),其中,區(qū)間[i,j]表示數(shù)據(jù)包長度的區(qū)間,Mi表示使用RDMA-Scheduling 在數(shù)據(jù)包長度為i測試的數(shù)值,Ni表示使用RDMA-Raw 在數(shù)據(jù)包長度為i測試的數(shù)據(jù)值,avg 表示使用基于優(yōu)先級的傳輸調(diào)度算法相對于未做任何處理的性能平均提升值。

    圖12 基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度測試結(jié)果Fig.12 Test result of priority-based data transmission scheduling

    在實(shí)驗測試時發(fā)送大批量的小型普通數(shù)據(jù)包,控制發(fā)送總量,保證數(shù)據(jù)流量充足。當(dāng)數(shù)據(jù)包長度在[8 Byte,4 096 Byte]時,吞吐量未達(dá)到閾值,在4 096 Byte 之后,當(dāng)前吞吐量趨于穩(wěn)定,接近閾值,并且此時時延較低,數(shù)據(jù)包是由原始數(shù)據(jù)和封裝信息組成。實(shí)驗結(jié)果表明,基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度能夠提高普通數(shù)據(jù)在數(shù)據(jù)包長度區(qū)間[8 Byte,4 096 Byte]范圍中的網(wǎng)卡帶寬利用率,網(wǎng)卡真實(shí)利用率也隨之增大,在不做任何處理的情況下,當(dāng)原始數(shù)據(jù)包長度逐漸增大時,網(wǎng)卡帶寬的實(shí)際利用率也在逐漸增大。主要是因為原始數(shù)據(jù)塊的封裝信息具有固定長度,當(dāng)傳輸?shù)脑紨?shù)據(jù)包長度過小時,封裝信息在發(fā)送數(shù)據(jù)包中所占比重較高,從而導(dǎo)致網(wǎng)卡的實(shí)際傳輸量低,而基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度處理對于長度較小的普通數(shù)據(jù)歸并為一個較大的數(shù)據(jù)包,設(shè)置邊界符,避免粘包,減少封裝信息在數(shù)據(jù)包長度的比重,從而可以提高網(wǎng)卡帶寬的實(shí)際利用率。根據(jù)式(1)計算,在[8 Byte,4 096 Byte]區(qū)間內(nèi)基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度之后,網(wǎng)卡帶寬利用率平均提高了33.03%。

    6 結(jié)束語

    針對單向數(shù)據(jù)采集場景,本文設(shè)計了結(jié)合消息中間件Kafka 和RDMA 技術(shù)的單向數(shù)據(jù)采集架構(gòu)ODAR,并提出基于可靠性的數(shù)據(jù)封裝解決傳輸時數(shù)據(jù)準(zhǔn)確性的問題。為克服內(nèi)存分配時存在的性能問題,設(shè)計動態(tài)內(nèi)存優(yōu)化策略,并給出基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度算法解決數(shù)據(jù)傳輸時網(wǎng)卡帶寬的利用率過低的問題。實(shí)驗結(jié)果表明,ODAR 架構(gòu)在單向場景中能夠提高單向傳輸時的吞吐量,降低時延和CPU 開銷,并驗證了基于可靠性的數(shù)據(jù)封裝和動態(tài)內(nèi)存優(yōu)化策略的有效性,且基于優(yōu)先級的數(shù)據(jù)傳輸調(diào)度能夠提高網(wǎng)卡實(shí)際傳輸量。但是,本文未對丟包問題做更加詳細(xì)的處理,因此在數(shù)據(jù)可靠性方面還需要進(jìn)一步研究。

    猜你喜歡
    網(wǎng)卡單向數(shù)據(jù)包
    在DDS 中間件上實(shí)現(xiàn)雙冗余網(wǎng)卡切換的方法
    碳纖維/PPS熱塑性單向預(yù)浸帶進(jìn)入市場
    用“單向?qū)m排除法”解四宮數(shù)獨(dú)
    單向截止閥密封失效分析
    Server 2016網(wǎng)卡組合模式
    SmartSniff
    挑戰(zhàn)Killer網(wǎng)卡Realtek網(wǎng)游專用Dragon網(wǎng)卡
    單向度
    新聞前哨(2015年2期)2015-03-11 19:29:30
    基于Libpcap的網(wǎng)絡(luò)數(shù)據(jù)包捕獲器的設(shè)計與實(shí)現(xiàn)
    視覺注意的數(shù)據(jù)包優(yōu)先級排序策略研究
    国产爱豆传媒在线观看| 中文字幕免费在线视频6| 中文字幕久久专区| 国语自产精品视频在线第100页| 在线观看av片永久免费下载| 天堂√8在线中文| 18禁在线无遮挡免费观看视频| 免费在线观看成人毛片| 国产精品电影一区二区三区| 国产女主播在线喷水免费视频网站 | 久久中文看片网| 亚洲欧美日韩卡通动漫| 男人狂女人下面高潮的视频| 亚洲在久久综合| 男的添女的下面高潮视频| 国产精品免费一区二区三区在线| 一本久久精品| 最近最新中文字幕大全电影3| 尾随美女入室| 国产极品天堂在线| 中国国产av一级| 国产人妻一区二区三区在| 丝袜喷水一区| 色哟哟哟哟哟哟| 久久久久久久久大av| 国产黄片视频在线免费观看| 老司机福利观看| 日韩成人伦理影院| 国产一区二区三区av在线 | 欧美激情久久久久久爽电影| 一区福利在线观看| 六月丁香七月| 天堂影院成人在线观看| 亚洲国产高清在线一区二区三| 亚洲欧洲国产日韩| 一边摸一边抽搐一进一小说| 丝袜喷水一区| 国内精品美女久久久久久| 久久精品国产清高在天天线| 禁无遮挡网站| 99热精品在线国产| 2022亚洲国产成人精品| 综合色丁香网| 欧美极品一区二区三区四区| 免费无遮挡裸体视频| 欧美日韩精品成人综合77777| 久久精品综合一区二区三区| 久久精品久久久久久久性| 亚洲国产日韩欧美精品在线观看| 亚洲真实伦在线观看| 国产精品国产高清国产av| 不卡一级毛片| 久久久久久国产a免费观看| 精品一区二区三区视频在线| 久久久欧美国产精品| 22中文网久久字幕| 久久精品综合一区二区三区| 美女高潮的动态| 国产午夜精品论理片| 人人妻人人澡欧美一区二区| 亚洲国产精品成人综合色| 久久精品久久久久久久性| 尾随美女入室| 热99在线观看视频| 国内精品宾馆在线| 国产综合懂色| 国产免费一级a男人的天堂| 亚洲国产欧洲综合997久久,| 久久久色成人| 美女被艹到高潮喷水动态| 91久久精品电影网| 舔av片在线| 桃色一区二区三区在线观看| 亚洲国产精品合色在线| 国产成人91sexporn| 好男人视频免费观看在线| 亚洲图色成人| 亚洲国产高清在线一区二区三| 国产成年人精品一区二区| 国内精品宾馆在线| 日韩在线高清观看一区二区三区| 亚洲真实伦在线观看| 久久综合国产亚洲精品| 老司机福利观看| 亚洲色图av天堂| 九九久久精品国产亚洲av麻豆| 18禁在线无遮挡免费观看视频| 又爽又黄a免费视频| 你懂的网址亚洲精品在线观看 | 男女视频在线观看网站免费| 亚洲精品影视一区二区三区av| 狂野欧美白嫩少妇大欣赏| 九九爱精品视频在线观看| 国产伦理片在线播放av一区 | 人人妻人人澡欧美一区二区| 色吧在线观看| 18禁在线播放成人免费| 日本av手机在线免费观看| 国模一区二区三区四区视频| 久久九九热精品免费| 精品人妻熟女av久视频| 国产日本99.免费观看| 久久精品国产亚洲av天美| 国产成人精品一,二区 | 亚洲美女视频黄频| 欧美激情在线99| 亚洲va在线va天堂va国产| 国产真实乱freesex| 青春草国产在线视频 | 久久久久久久久久久免费av| 小说图片视频综合网站| 欧美三级亚洲精品| 男女做爰动态图高潮gif福利片| 青青草视频在线视频观看| 精品久久久久久久末码| 日本欧美国产在线视频| 国产中年淑女户外野战色| 干丝袜人妻中文字幕| 久久精品夜色国产| 在线播放国产精品三级| 午夜视频国产福利| 国内精品美女久久久久久| 草草在线视频免费看| 欧美zozozo另类| 又爽又黄a免费视频| 两个人的视频大全免费| 国产黄片视频在线免费观看| 日韩大尺度精品在线看网址| 亚洲精品久久久久久婷婷小说 | 中文字幕熟女人妻在线| 老司机福利观看| 在线观看免费视频日本深夜| 久久久精品欧美日韩精品| 亚洲精品456在线播放app| 成年版毛片免费区| 国产精品三级大全| 一级黄片播放器| 国产又黄又爽又无遮挡在线| 美女被艹到高潮喷水动态| 亚洲精品影视一区二区三区av| 午夜福利在线观看吧| а√天堂www在线а√下载| 最近的中文字幕免费完整| 亚洲av成人精品一区久久| 99久久成人亚洲精品观看| 亚洲av一区综合| 给我免费播放毛片高清在线观看| 一本久久精品| 日韩欧美在线乱码| 搡女人真爽免费视频火全软件| 久久久久九九精品影院| 美女被艹到高潮喷水动态| 国产三级在线视频| 嫩草影院入口| 国产在线男女| 精品一区二区免费观看| 在线免费观看不下载黄p国产| 天天一区二区日本电影三级| 91麻豆精品激情在线观看国产| 97热精品久久久久久| 青春草视频在线免费观看| 日产精品乱码卡一卡2卡三| 亚洲aⅴ乱码一区二区在线播放| 中文字幕人妻熟人妻熟丝袜美| 悠悠久久av| 欧美性感艳星| 最近最新中文字幕大全电影3| 又粗又爽又猛毛片免费看| 日本免费a在线| 直男gayav资源| 1000部很黄的大片| 少妇猛男粗大的猛烈进出视频 | 少妇人妻一区二区三区视频| 亚洲四区av| 97超碰精品成人国产| 男人舔女人下体高潮全视频| 国产人妻一区二区三区在| 久久精品国产亚洲av涩爱 | av专区在线播放| 亚洲精品日韩av片在线观看| 午夜爱爱视频在线播放| 在线a可以看的网站| 亚洲18禁久久av| 日本撒尿小便嘘嘘汇集6| 黄色日韩在线| 中国国产av一级| 直男gayav资源| 精品人妻偷拍中文字幕| 噜噜噜噜噜久久久久久91| 校园春色视频在线观看| 22中文网久久字幕| 欧美zozozo另类| 亚洲欧美日韩高清在线视频| 午夜a级毛片| 国内精品宾馆在线| 网址你懂的国产日韩在线| 天堂√8在线中文| 久久草成人影院| 永久网站在线| 校园人妻丝袜中文字幕| 亚洲丝袜综合中文字幕| 久久久久久久久大av| 国产中年淑女户外野战色| 国语自产精品视频在线第100页| 亚洲精品粉嫩美女一区| 亚洲天堂国产精品一区在线| 亚洲精品成人久久久久久| 国模一区二区三区四区视频| 国产精品人妻久久久久久| 久久婷婷人人爽人人干人人爱| 国产精品一区www在线观看| 少妇熟女aⅴ在线视频| 97超视频在线观看视频| 人妻久久中文字幕网| 国产精品一区二区性色av| 最近中文字幕高清免费大全6| 成人美女网站在线观看视频| 久久亚洲精品不卡| 亚洲人与动物交配视频| 日本黄色视频三级网站网址| 国产免费一级a男人的天堂| 最近中文字幕高清免费大全6| 国内精品久久久久精免费| 日本色播在线视频| 简卡轻食公司| 夫妻性生交免费视频一级片| 日本av手机在线免费观看| 国产大屁股一区二区在线视频| 亚洲精品亚洲一区二区| 亚洲四区av| 国产成人freesex在线| 国产亚洲91精品色在线| 级片在线观看| 亚洲成人中文字幕在线播放| 人妻系列 视频| 国产精品乱码一区二三区的特点| 综合色av麻豆| 亚洲美女搞黄在线观看| 亚洲国产精品sss在线观看| 午夜免费激情av| 欧美+日韩+精品| av又黄又爽大尺度在线免费看 | 亚洲精品乱码久久久v下载方式| 在线观看av片永久免费下载| 国内精品宾馆在线| 亚洲色图av天堂| 精品久久久久久久久av| 亚洲人与动物交配视频| 1000部很黄的大片| 六月丁香七月| 黄色配什么色好看| 淫秽高清视频在线观看| 亚洲人成网站高清观看| 九九久久精品国产亚洲av麻豆| 欧美色欧美亚洲另类二区| 在线天堂最新版资源| 精品免费久久久久久久清纯| 欧美高清成人免费视频www| 国产精品一及| 色尼玛亚洲综合影院| 蜜臀久久99精品久久宅男| 给我免费播放毛片高清在线观看| 小说图片视频综合网站| 国产精品久久久久久av不卡| 免费人成在线观看视频色| 亚洲乱码一区二区免费版| 久久国内精品自在自线图片| 亚洲经典国产精华液单| 最近中文字幕高清免费大全6| 看片在线看免费视频| 国产成人91sexporn| 国产一级毛片在线| 2021天堂中文幕一二区在线观| 日本欧美国产在线视频| 三级经典国产精品| 国产高清有码在线观看视频| 国产亚洲精品av在线| 亚洲熟妇中文字幕五十中出| 亚洲美女搞黄在线观看| 成人毛片60女人毛片免费| 国产精品女同一区二区软件| 成人一区二区视频在线观看| 亚洲欧美精品专区久久| 又爽又黄无遮挡网站| 精品不卡国产一区二区三区| 男女视频在线观看网站免费| 国产精品国产高清国产av| 国产一区二区三区在线臀色熟女| 麻豆一二三区av精品| 亚州av有码| 久久精品国产亚洲av天美| 成人三级黄色视频| 国产精品一二三区在线看| 悠悠久久av| 一本久久精品| 熟女电影av网| 一本久久精品| 在线天堂最新版资源| 亚洲aⅴ乱码一区二区在线播放| 亚洲国产日韩欧美精品在线观看| 日韩强制内射视频| 赤兔流量卡办理| 日韩三级伦理在线观看| 乱码一卡2卡4卡精品| 欧美bdsm另类| 久久草成人影院| 亚洲精品久久久久久婷婷小说 | 美女高潮的动态| 日韩人妻高清精品专区| 国产亚洲精品久久久com| .国产精品久久| 亚洲七黄色美女视频| 欧美潮喷喷水| 亚洲内射少妇av| 老女人水多毛片| 在线观看一区二区三区| 女的被弄到高潮叫床怎么办| 日韩欧美精品v在线| 最近的中文字幕免费完整| 国产免费一级a男人的天堂| 高清毛片免费观看视频网站| 小说图片视频综合网站| 一级毛片我不卡| 亚洲色图av天堂| 国产高清有码在线观看视频| 成人高潮视频无遮挡免费网站| or卡值多少钱| 欧美日本视频| 欧美性感艳星| 中文资源天堂在线| 狂野欧美激情性xxxx在线观看| 欧美最黄视频在线播放免费| 人妻系列 视频| 日韩一本色道免费dvd| 一本一本综合久久| 日本黄色视频三级网站网址| 国内精品宾馆在线| 国产午夜福利久久久久久| 欧美成人一区二区免费高清观看| 一级黄色大片毛片| 亚洲av熟女| 亚洲无线观看免费| 欧美性感艳星| 国产伦理片在线播放av一区 | 老师上课跳d突然被开到最大视频| 婷婷色综合大香蕉| 校园春色视频在线观看| 婷婷六月久久综合丁香| 日本三级黄在线观看| 亚洲精品成人久久久久久| 日本黄色片子视频| 久久99蜜桃精品久久| 一进一出抽搐动态| 日韩一本色道免费dvd| 人妻少妇偷人精品九色| 日本成人三级电影网站| 色播亚洲综合网| 欧美激情久久久久久爽电影| 天天躁日日操中文字幕| 久久久久久久久久久免费av| 欧美成人一区二区免费高清观看| 国产精品久久久久久久电影| 美女cb高潮喷水在线观看| 人体艺术视频欧美日本| 国产亚洲av嫩草精品影院| 日本黄色视频三级网站网址| 好男人在线观看高清免费视频| 欧美日韩一区二区视频在线观看视频在线 | 一级黄片播放器| 亚洲精品乱码久久久久久按摩| 国产黄色视频一区二区在线观看 | 高清日韩中文字幕在线| 十八禁国产超污无遮挡网站| 免费电影在线观看免费观看| 日韩视频在线欧美| 麻豆国产97在线/欧美| 国产大屁股一区二区在线视频| 男女做爰动态图高潮gif福利片| 欧洲精品卡2卡3卡4卡5卡区| 色吧在线观看| 亚洲av成人精品一区久久| 久久中文看片网| 天堂影院成人在线观看| 亚洲精品自拍成人| 美女高潮的动态| 2021天堂中文幕一二区在线观| 99热全是精品| 亚洲自拍偷在线| 村上凉子中文字幕在线| 亚洲成a人片在线一区二区| 日本五十路高清| 日本撒尿小便嘘嘘汇集6| 国产精品福利在线免费观看| 国产精品蜜桃在线观看 | 麻豆成人午夜福利视频| 91午夜精品亚洲一区二区三区| 中文字幕精品亚洲无线码一区| 久久精品人妻少妇| 免费看av在线观看网站| 男人舔女人下体高潮全视频| 亚洲天堂国产精品一区在线| 久久精品影院6| 国产av麻豆久久久久久久| 亚洲无线在线观看| 精品少妇黑人巨大在线播放 | 亚洲av电影不卡..在线观看| 一区福利在线观看| 天堂影院成人在线观看| 五月玫瑰六月丁香| 国产在线男女| 哪里可以看免费的av片| 看黄色毛片网站| 长腿黑丝高跟| 日韩欧美在线乱码| 69人妻影院| 婷婷精品国产亚洲av| 18禁裸乳无遮挡免费网站照片| 夜夜看夜夜爽夜夜摸| 1024手机看黄色片| 久久精品人妻少妇| 啦啦啦啦在线视频资源| 日韩中字成人| 别揉我奶头 嗯啊视频| 哪个播放器可以免费观看大片| 干丝袜人妻中文字幕| 91av网一区二区| 中文字幕制服av| 九九久久精品国产亚洲av麻豆| 99久久成人亚洲精品观看| 亚洲av免费在线观看| 成人综合一区亚洲| 中文字幕熟女人妻在线| 内射极品少妇av片p| 亚洲aⅴ乱码一区二区在线播放| 在线观看66精品国产| 午夜福利视频1000在线观看| 久久热精品热| 嘟嘟电影网在线观看| 亚洲欧洲国产日韩| 久久久a久久爽久久v久久| 哪里可以看免费的av片| 国产成人一区二区在线| 嫩草影院入口| 悠悠久久av| 麻豆乱淫一区二区| 婷婷色综合大香蕉| 最近最新中文字幕大全电影3| 变态另类丝袜制服| 欧美激情国产日韩精品一区| videossex国产| 人妻夜夜爽99麻豆av| 国产中年淑女户外野战色| 亚洲国产精品sss在线观看| 国产久久久一区二区三区| 97超视频在线观看视频| 国产成人午夜福利电影在线观看| 久久6这里有精品| 中文亚洲av片在线观看爽| 老司机影院成人| 亚洲精品亚洲一区二区| 精品一区二区免费观看| 又黄又爽又刺激的免费视频.| 天堂√8在线中文| 国产亚洲精品av在线| 两个人视频免费观看高清| 女同久久另类99精品国产91| 久99久视频精品免费| 欧美日韩在线观看h| 亚洲不卡免费看| av又黄又爽大尺度在线免费看 | 免费看光身美女| 亚洲婷婷狠狠爱综合网| 国产免费一级a男人的天堂| 国产日本99.免费观看| 男女下面进入的视频免费午夜| 精品人妻一区二区三区麻豆| 国产av不卡久久| 欧美日韩国产亚洲二区| 亚洲精品久久国产高清桃花| 国产爱豆传媒在线观看| 晚上一个人看的免费电影| 久久精品国产清高在天天线| 亚洲人成网站在线观看播放| 乱人视频在线观看| 夫妻性生交免费视频一级片| 国产成人aa在线观看| 91aial.com中文字幕在线观看| 高清毛片免费看| 天堂√8在线中文| 欧美+日韩+精品| 日韩欧美精品免费久久| 亚洲精品亚洲一区二区| 99热这里只有精品一区| 国产精品一区二区三区四区久久| 亚洲国产日韩欧美精品在线观看| 午夜福利在线观看吧| 国产爱豆传媒在线观看| 欧美极品一区二区三区四区| 久久人人爽人人爽人人片va| 国产探花极品一区二区| 毛片女人毛片| 国产亚洲5aaaaa淫片| 国产精品永久免费网站| 成年女人永久免费观看视频| 欧美激情久久久久久爽电影| 精品一区二区三区视频在线| 免费观看a级毛片全部| 老师上课跳d突然被开到最大视频| 久久久精品94久久精品| 亚洲经典国产精华液单| 亚洲人与动物交配视频| 国产高清激情床上av| 美女被艹到高潮喷水动态| 狠狠狠狠99中文字幕| 亚洲欧美精品自产自拍| 麻豆av噜噜一区二区三区| 色综合亚洲欧美另类图片| 亚洲丝袜综合中文字幕| 欧美在线一区亚洲| 日韩欧美 国产精品| 性欧美人与动物交配| 亚洲综合色惰| 赤兔流量卡办理| 男女视频在线观看网站免费| 天天躁夜夜躁狠狠久久av| 午夜精品国产一区二区电影 | 午夜福利成人在线免费观看| 99在线人妻在线中文字幕| 赤兔流量卡办理| 性插视频无遮挡在线免费观看| 天天躁夜夜躁狠狠久久av| 亚洲久久久久久中文字幕| 色哟哟·www| 国产毛片a区久久久久| av女优亚洲男人天堂| 亚洲成人中文字幕在线播放| 日韩大尺度精品在线看网址| 一区二区三区四区激情视频 | 久久精品久久久久久久性| 免费电影在线观看免费观看| 国产伦一二天堂av在线观看| 久久九九热精品免费| 亚洲国产精品sss在线观看| 国产成人精品一,二区 | 国产午夜福利久久久久久| 成人鲁丝片一二三区免费| 亚洲一级一片aⅴ在线观看| 国产伦在线观看视频一区| 日韩高清综合在线| 自拍偷自拍亚洲精品老妇| 观看免费一级毛片| 亚洲无线在线观看| 亚洲成人av在线免费| 桃色一区二区三区在线观看| 亚州av有码| 日本熟妇午夜| 简卡轻食公司| 久久婷婷人人爽人人干人人爱| 久久久欧美国产精品| 日韩欧美精品免费久久| 国产午夜精品久久久久久一区二区三区| 级片在线观看| 在线观看美女被高潮喷水网站| 国产成人精品久久久久久| 蜜桃亚洲精品一区二区三区| 国产国拍精品亚洲av在线观看| 亚洲欧美日韩东京热| 成人性生交大片免费视频hd| avwww免费| 天堂av国产一区二区熟女人妻| 好男人视频免费观看在线| 日本五十路高清| 亚洲av成人精品一区久久| 狠狠狠狠99中文字幕| 22中文网久久字幕| 久久精品国产鲁丝片午夜精品| 黄色视频,在线免费观看| 国产在线男女| 亚洲五月天丁香| 亚洲精品日韩在线中文字幕 | or卡值多少钱| 亚洲电影在线观看av| 国产精品蜜桃在线观看 | av在线老鸭窝| 91在线精品国自产拍蜜月| 国产爱豆传媒在线观看| 国产乱人偷精品视频| 我要搜黄色片| 成人毛片a级毛片在线播放| 免费黄网站久久成人精品| 激情 狠狠 欧美| 欧美三级亚洲精品| 人妻久久中文字幕网| 亚洲精品国产成人久久av| 国产精品久久久久久久电影| 欧美成人免费av一区二区三区| 欧美激情在线99| 波多野结衣高清无吗| 丝袜喷水一区| 69av精品久久久久久| 男人舔奶头视频| 亚洲av成人精品一区久久| 69av精品久久久久久| 日产精品乱码卡一卡2卡三| 国产成人精品一,二区 | 一区二区三区高清视频在线| 久久精品国产鲁丝片午夜精品| 在线观看美女被高潮喷水网站| 一进一出抽搐gif免费好疼| 国产在视频线在精品| 日本av手机在线免费观看| 久久精品人妻少妇| 国产在线精品亚洲第一网站| 免费观看人在逋| ponron亚洲|