在线观看www成人影院-在线观看www日本免费网站-在线观看www视频-在线观看操-欧美18在线-欧美1级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

什么是QUIC和HTTP/3呢?

LiveVideoStack ? 來源:LiveVideoStack ? 作者:LiveVideoStack ? 2020-11-02 10:04 ? 次閱讀

隨著IETF很快完成QUIC標(biāo)準(zhǔn)定稿,越來越多的企業(yè)和開發(fā)者投入到QUIC開發(fā)實(shí)現(xiàn)與部署中。阿里巴巴實(shí)現(xiàn)了XQUIC;B站、快手在2019年就公開了QUIC的應(yīng)用實(shí)踐;Akamai等CDN服務(wù)商則很早就開始擁抱QUIC,并提供相應(yīng)的支持。本文來自Facebook的工程博客,詳細(xì)介紹了Facebook是如何將其3/4的流量切換到QUIC上的。

Facebook正在使用QUIC取代互聯(lián)網(wǎng)幾十年來一直沿用的默認(rèn)協(xié)議,這是我們最新的網(wǎng)絡(luò)協(xié)議優(yōu)化策略,同時(shí)也是最激進(jìn)的一步,目的還是為了進(jìn)一步提高我們的服務(wù)的用戶體驗(yàn)。

今天,QUIC和HTTP/3在我們的互聯(lián)網(wǎng)通信中使用率超過75%(我們將QUIC和HTTP/3統(tǒng)稱為QUIC)。QUIC已經(jīng)顯著地改善多個(gè)指標(biāo),包括請求錯(cuò)誤、尾延遲(Tail Latency)、響應(yīng)頭大小以及各種其他影響我們應(yīng)用程序用戶體驗(yàn)相關(guān)的參數(shù)。 互聯(lián)網(wǎng)工程任務(wù)組(IETF)目前正在為QUIC和HTTP/3開發(fā)標(biāo)準(zhǔn)。

什么是QUIC和HTTP/3呢?

從廣義上講,QUIC替代了傳輸控制協(xié)議(TCP),后者是互聯(lián)網(wǎng)通信的主要協(xié)議之一。QUIC最初由谷歌公司內(nèi)部研發(fā),稱為GoogleQUIC,或gQUIC,于2015年提交給IETF。從那之后,更廣大的IETF社區(qū)對其進(jìn)行了重新設(shè)計(jì)與改進(jìn),形成了一個(gè)新的協(xié)議,也就是我們現(xiàn)在所說的QUIC。

HTTP/3是HTTP的新一代迭代,它是基于網(wǎng)絡(luò)的應(yīng)用程序和服務(wù)器之間通信的標(biāo)準(zhǔn)協(xié)議。綜合Facebook、谷歌和IETF社區(qū)數(shù)十年來在互聯(lián)網(wǎng)上運(yùn)行協(xié)議獲得的最佳實(shí)踐經(jīng)驗(yàn)和教訓(xùn),QUIC和HTTP/3共同代表了最新且最強(qiáng)大的以互聯(lián)網(wǎng)為中心的協(xié)議。

QUIC和HTTP/3整體優(yōu)于TCP和HTTP/2,后者則跑贏了TCP和HTTP/1.1。TCP和HTTP/2首先引入了流多路復(fù)用的概念,在同一進(jìn)程中,允許單個(gè)網(wǎng)絡(luò)連接服務(wù)多個(gè)數(shù)據(jù)流。QUIC和HTTP / 3在此基礎(chǔ)上更進(jìn)一步,通過避免TCP可怕的隊(duì)頭阻塞 (隊(duì)頭阻塞時(shí),丟失的數(shù)據(jù)包發(fā)生阻塞同時(shí)導(dǎo)致連接上的所有流變慢),從而使得流真正獨(dú)立。 QUIC采用了最先進(jìn)的丟失恢復(fù)技術(shù),在惡劣的網(wǎng)絡(luò)條件下,這能使得它在大多數(shù)情況下性能跑贏TCP協(xié)議實(shí)現(xiàn)。TCP也容易僵化,因?yàn)榉阑饓Φ染W(wǎng)絡(luò)中間件對數(shù)據(jù)包的格式做了假設(shè),TCP協(xié)議很難進(jìn)行升級,QUIC通過完全加密功能避免了這個(gè)問題,使得協(xié)議的可擴(kuò)展性走向最佳,同時(shí)保證將來可以進(jìn)行改進(jìn)。QUIC還可以通過QLOG(一種專門為QUIC設(shè)計(jì)的基于JSON的跟蹤格式)來檢測、觀察和可視化展示傳輸行為。

以經(jīng)驗(yàn)為導(dǎo)向的協(xié)議開發(fā)

Facebook開發(fā)了自己的QUIC實(shí)現(xiàn),我們稱之為mvfst,以便在我們自己的系統(tǒng)上快速測試和部署QUIC。我們有編寫和部署自己的協(xié)議實(shí)現(xiàn)的經(jīng)驗(yàn),首先部署我們的HTTP客戶機(jī)/服務(wù)器庫Proxygen,緊接著是Zero協(xié)議,最后是Fizz(我們的TLS1.3實(shí)現(xiàn))。

Facebook應(yīng)用程序運(yùn)用Fizz和Proxygen通過Proxygen Mobile與服務(wù)器進(jìn)行通信。我們還為TLS開發(fā)了一個(gè)名為delegated credentials的擴(kuò)展程序,提供兩方面安全解決方案,一方面可用于保護(hù)TLS上的證書和DNS,另一方面也可用于加密和驗(yàn)證TLS上的web流量。

從頭開始開發(fā)和部署新的傳輸協(xié)議

我們希望新協(xié)議能夠與現(xiàn)有的軟件無縫集成,并且?guī)椭鶩acebook的開發(fā)人員更高效地工作。作為一個(gè)試驗(yàn)場,我們決定將QUIC部署在Facebook的相當(dāng)一部分網(wǎng)絡(luò)流量上,尤其包括指向Facebook的公共代理流量在內(nèi)的內(nèi)部網(wǎng)絡(luò)流量。假如QUIC不能很好地處理內(nèi)部流量,我們便可以確定它在更廣闊的互聯(lián)網(wǎng)上效果也不會太好。

除開能暴露錯(cuò)誤及其他有問題的行為之外,通過這種策略,我們可以設(shè)計(jì)一種方法,使我們的網(wǎng)絡(luò)負(fù)載均衡器對QUIC深度了解,并使得負(fù)載均衡器的零停機(jī)釋放得到保證。 有了這個(gè)堅(jiān)實(shí)的基礎(chǔ),我們開始向互聯(lián)網(wǎng)上的用戶部署QUIC?;趍vfst的設(shè)計(jì),我們能夠?qū)UIC支持平穩(wěn)地集成到Proxygen Mobile中。

Facebook應(yīng)用程序

部署到Facebook應(yīng)用程序是我們在互聯(lián)網(wǎng)上使用QUIC的第一個(gè)目標(biāo)。Facebook擁有成熟的基礎(chǔ)架構(gòu),可以讓我們在向數(shù)十億人發(fā)布應(yīng)用程序之前,以有限的方式安全地推出應(yīng)用程序的更新。

我們從一個(gè)實(shí)驗(yàn)入手,在Facebook應(yīng)用程序的動態(tài)GraphQL請求中啟用了QUIC。在這些請求的響應(yīng)中,沒有圖像和視頻之類的靜態(tài)內(nèi)容。 我們的測試表明,運(yùn)用QUIC使得多個(gè)指標(biāo)有所提升。Facebook用戶的請求錯(cuò)誤率下降了6%,尾延遲下降了20%,響應(yīng)頭大小相較于HTTP/2縮小了5%。同時(shí)這也對其他指標(biāo)產(chǎn)生了級聯(lián)效應(yīng),可以說QUIC極大地提高了用戶的體驗(yàn)。 然而,QUIC的應(yīng)用相較TCP也有倒退之處。最令人費(fèi)解的是,盡管僅在動態(tài)請求時(shí)啟用QUIC,然而我們發(fā)現(xiàn)使用TCP下載的靜態(tài)內(nèi)容的錯(cuò)誤率卻增加了。其根本原因是我們在將流量轉(zhuǎn)換到QUIC時(shí)遇到的一個(gè)常見問題:應(yīng)用程序的邏輯是,根據(jù)不同類型內(nèi)容的請求的速度和可靠性,切換請求的類型和數(shù)量以處理相應(yīng)的類型內(nèi)容。于是乎,改進(jìn)一種請求類型可能會對其他類型產(chǎn)生糟糕的副作用。 再如,QUIC帶來的另一些麻煩,適應(yīng)應(yīng)用程序從服務(wù)器請求新靜態(tài)內(nèi)容的積極性的啟發(fā)式算法將隨著QUIC的使用而發(fā)生改變,當(dāng)應(yīng)用程序發(fā)出一個(gè)請求時(shí),比方說,當(dāng)加載News Feed的文本內(nèi)容時(shí),需要觀察這個(gè)請求耗時(shí)多久,然后再決定發(fā)出多少圖像/視頻請求。 我們發(fā)現(xiàn)啟發(fā)式算法策略可能對TCP比較有效,它是用任意閾值進(jìn)行調(diào)整的。但是當(dāng)我們切換到QUIC時(shí),這些閾值變得不準(zhǔn)確,應(yīng)用程序可能一次發(fā)送請求過多,最終導(dǎo)致News Feed的加載時(shí)間進(jìn)一步加長。

擴(kuò)大使用范圍

下一步是為Facebook應(yīng)用中的靜態(tài)內(nèi)容部署QUIC(如:圖片和視頻)。然而,在此之前,我們必須解決兩個(gè)重點(diǎn)問題:mvfst的CPU效率以及我們的主要擁塞控制實(shí)現(xiàn)的有效性與BBR。

到目前為止,mvfst的設(shè)計(jì)初衷是幫助開發(fā)人員靈活開發(fā)并跟上不斷變化的QUIC草案。與靜態(tài)請求相比,動態(tài)請求的響應(yīng)相對較小,它不需要占用大量的CPU,也不需要擁塞控制器來控制其進(jìn)度。 為了解決這些問題,我們開發(fā)了性能測試工具,用以幫助我們評估CPU的使用情況并有效地運(yùn)用擁塞控制器來管理網(wǎng)絡(luò)資源。 我們在負(fù)載均衡器中綜合使用了QUIC的負(fù)載測試和這些性能測試工具,取得了一些成果。一個(gè)重要的方向——例如——優(yōu)化我們調(diào)整UDP數(shù)據(jù)包的效率,以保證數(shù)據(jù)傳輸更加平滑。為了提高CPU的使用率,我們采用了不少技術(shù),諸如使用通用分段延后處理(GSO)來一次高效地發(fā)送多個(gè)UDP包。我們還對處理未確認(rèn)的QUIC數(shù)據(jù)使用的數(shù)據(jù)結(jié)構(gòu)和算法進(jìn)行了優(yōu)化。

QUIC針對所有內(nèi)容

在為Facebook應(yīng)用程序中的所有內(nèi)容啟用QUIC之前,我們先與包括我們的視頻工程師在內(nèi)的幾個(gè)利益相關(guān)者展開合作。他們對重要的產(chǎn)品指標(biāo)有著深刻的理解,能夠在我們啟用QUIC時(shí)幫助我們分析Facebook應(yīng)用程序中的實(shí)驗(yàn)性結(jié)果。

實(shí)驗(yàn)表明,QUIC對Facebook應(yīng)用中的視頻相關(guān)的指標(biāo)有著革命性的影響。根據(jù)平臺的不同,體現(xiàn)出緩沖事件間隔耗時(shí)指標(biāo)的平均重新緩沖時(shí)間(MTBR)總體上提高了22%。視頻請求的總體錯(cuò)誤量減少了8%。視頻卡頓率降低了20%。 包括元指標(biāo)在內(nèi)的其他幾個(gè)指標(biāo),考慮到各種因素,特別是異常情況,也得到了顯著改善。QUIC改善了視頻觀看體驗(yàn),對網(wǎng)絡(luò)條件相對較差的地區(qū),尤其是新興市場,產(chǎn)生了巨大的影響。 然而,能達(dá)到這樣的成就,一路上也是困難重重。一如我們在動態(tài)內(nèi)容方面的經(jīng)歷,我們在應(yīng)用程序中發(fā)現(xiàn)了針對TCP行為進(jìn)行調(diào)整的啟發(fā)式方法。例如,iOSAndroid上的應(yīng)用程序有不同的機(jī)制來估計(jì)可用的下載帶寬。當(dāng)使用QUIC時(shí),這些估計(jì)器有時(shí)會高估可用帶寬,導(dǎo)致應(yīng)用程序播放的視頻質(zhì)量高于網(wǎng)絡(luò)所能支持的質(zhì)量,從而引起視頻卡頓。 我們還需要調(diào)整流控制參數(shù)并繼續(xù)迭代它。流控制限制了接收者期望從發(fā)送者那里緩存到的數(shù)據(jù)量。Facebook應(yīng)用程序?qū)TTP/2有一個(gè)靜態(tài)定義的流控制限制,該限制是針對TCP進(jìn)行的隱藏式優(yōu)化,不過在QUIC中表現(xiàn)不太好。為了找到新的最優(yōu)流量控制值,我們需要進(jìn)行一些實(shí)驗(yàn)性迭代。

QUIC和TCP視頻加載時(shí)間之間的個(gè)體差異

Instagram及其他

即使是在Facebook這樣豐富復(fù)雜的應(yīng)用程序上,QUIC也被證明能夠有效改善人們在互聯(lián)網(wǎng)上的體驗(yàn)。在未來,我們計(jì)劃繼續(xù)利用更多QUIC的已有功能,比如連接遷移和真正的0-RTT連接創(chuàng)建,并致力于改善擁塞控制和損失恢復(fù)。

我們也在Instagram中部署了QUIC,使用了與Facebook部署相同的策略——先在Instagram的一小部分流量上進(jìn)行測試,然后進(jìn)一步大規(guī)模使用。 如今,QUIC已經(jīng)部署到了Instagram的iOS和安卓版本上。Instagram的兩個(gè)版本的相關(guān)指標(biāo)的優(yōu)化成果都達(dá)到甚至超越了我們先前在Facebook應(yīng)用程序上取得的收獲。 Facebook和Instagram的網(wǎng)頁版上也啟用了QUIC,隨著更多的web瀏覽器開始支持QUIC——如最近谷歌對Chrome和蘋果對Safari beta所做的改進(jìn)——越來越多的用戶將從中受益。 除了Instagram之外,我們相信我們有能力將QUIC的優(yōu)勢帶到Facebook應(yīng)用家族中的所有應(yīng)用的每一次體驗(yàn)中去,QUIC最終將不僅代表Facebook的大部分互聯(lián)網(wǎng)流量,而是代表Facebook的所有互聯(lián)網(wǎng)流量。 IETF有望在2021年某個(gè)時(shí)間點(diǎn)完成對QUIC協(xié)議的征求意見文檔(RFC)的定稿。到那時(shí)候,會有更多的網(wǎng)站、應(yīng)用程序和網(wǎng)絡(luò)庫提供通用的QUIC。在不久的將來,像QUIC這樣的新協(xié)議將是解鎖互聯(lián)網(wǎng)應(yīng)用創(chuàng)新的關(guān)鍵。對我們來說,QUIC則是一個(gè)起點(diǎn),我們將繼續(xù)提升人們在Facebook上的用戶體驗(yàn)。 在Facebook內(nèi)外,有太多的人共同努力促成了QUIC的成功部署。我們要感謝在過去幾年中參與IETF QUIC工作組的所有成員,感謝他們對QUIC不懈地探討與設(shè)計(jì)。IETF QUIC工作組由許多不同背景的成員組成,他們在相對較短的時(shí)間內(nèi)制定出了一項(xiàng)真正稱得上卓越的網(wǎng)絡(luò)協(xié)議。

責(zé)任編輯:lq

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • HTTP
    +關(guān)注

    關(guān)注

    0

    文章

    522

    瀏覽量

    32502
  • 應(yīng)用程序
    +關(guān)注

    關(guān)注

    38

    文章

    3322

    瀏覽量

    58776
  • Quic
    +關(guān)注

    關(guān)注

    0

    文章

    25

    瀏覽量

    7404

原文標(biāo)題:Facebook如何將QUIC應(yīng)用于數(shù)十億流量傳輸

文章出處:【微信號:livevideostack,微信公眾號:LiveVideoStack】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦
    熱點(diǎn)推薦

    HTTP網(wǎng)絡(luò)通訊過程

    的 OSI 模型。 OSI ?是一種理論下的模型,而? TCP/IP ?已被廣泛使用,成為網(wǎng)絡(luò)互聯(lián)事實(shí)上的標(biāo)準(zhǔn)。 2. HTTP 網(wǎng)絡(luò)通訊過程 示例:簡單的網(wǎng)絡(luò)拓?fù)淠P?詳解:當(dāng)鍵入網(wǎng)址到網(wǎng)頁顯示的通訊
    的頭像 發(fā)表于 01-20 09:07 ?430次閱讀
    <b class='flag-5'>HTTP</b>網(wǎng)絡(luò)通訊過程

    HTTP 協(xié)議對于SEO優(yōu)化的影響

    搜索引擎優(yōu)化(SEO)是提高網(wǎng)站在搜索引擎中的可見性和排名的過程。HTTP協(xié)議作為互聯(lián)網(wǎng)通信的基礎(chǔ),對SEO有著深遠(yuǎn)的影響。 1. HTTP狀態(tài)碼 HTTP狀態(tài)碼是服務(wù)器響應(yīng)客戶端請求的結(jié)果。這些
    的頭像 發(fā)表于 12-30 09:29 ?541次閱讀

    如何調(diào)試 HTTP 請求和響應(yīng)

    調(diào)試HTTP請求和響應(yīng)是Web開發(fā)和網(wǎng)絡(luò)編程中的一個(gè)重要技能。以下是一些步驟和工具,可以幫助你調(diào)試HTTP請求和響應(yīng): 1. 使用瀏覽器開發(fā)者工具 大多數(shù)現(xiàn)代瀏覽器都內(nèi)置了開發(fā)者工具,這些工具可以
    的頭像 發(fā)表于 12-30 09:28 ?1144次閱讀

    如何使用 cURL 測試 HTTP 協(xié)議

    cURL是一個(gè)強(qiáng)大的命令行工具,用于傳輸數(shù)據(jù),支持多種協(xié)議,包括HTTP、HTTPS、FTP等。使用cURL測試HTTP協(xié)議可以幫助你理解HTTP請求和響應(yīng)的工作原理,以及調(diào)試和驗(yàn)證你的HTT
    的頭像 發(fā)表于 12-30 09:26 ?1017次閱讀

    HTTP 1.1 和 HTTP 2.0 的區(qū)別

    HTTP(超文本傳輸協(xié)議)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的協(xié)議之一,用于在客戶端和服務(wù)器之間傳輸數(shù)據(jù)。隨著技術(shù)的發(fā)展,HTTP協(xié)議也在不斷地更新和優(yōu)化。HTTP/1.1是1999年發(fā)布的,而HTTP
    的頭像 發(fā)表于 12-30 09:25 ?963次閱讀

    如何實(shí)現(xiàn) HTTP 協(xié)議的安全性

    HTTP(超文本傳輸協(xié)議)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的協(xié)議之一,用于從服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議。然而,HTTP協(xié)議本身并沒有加密機(jī)制,因此傳輸?shù)臄?shù)據(jù)容易被竊聽、篡改和偽造。為了實(shí)現(xiàn)HTTP
    的頭像 發(fā)表于 12-30 09:22 ?803次閱讀

    HTTP 協(xié)議的工作原理

    HTTP協(xié)議的工作原理 1. HTTP協(xié)議概述 HTTP是一個(gè)應(yīng)用層協(xié)議,它定義了客戶端與服務(wù)器之間請求和響應(yīng)的格式。HTTP協(xié)議基于TCP/IP模型,通常使用80端口進(jìn)行通信。
    的頭像 發(fā)表于 12-30 09:21 ?910次閱讀

    HTTP 和 HTTPS 的區(qū)別

    在互聯(lián)網(wǎng)時(shí)代,數(shù)據(jù)傳輸安全變得越來越重要。HTTP 和 HTTPS 是兩種廣泛使用的網(wǎng)絡(luò)協(xié)議,它們在數(shù)據(jù)傳輸方面扮演著關(guān)鍵角色。盡管它們的名字相似,但它們在安全性和用途上有著顯著的區(qū)別。 HTTP
    的頭像 發(fā)表于 12-30 09:19 ?931次閱讀

    HTTP 協(xié)議的基本概念

    HTTP(HyperText Transfer Protocol,超文本傳輸協(xié)議)是一種用于分布式、協(xié)作式、超媒體信息系統(tǒng)的網(wǎng)絡(luò)協(xié)議。HTTP 是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的協(xié)議之一,它定義了客戶端(比如
    的頭像 發(fā)表于 12-29 15:12 ?1148次閱讀

    socket與HTTP協(xié)議的比較

    在計(jì)算機(jī)網(wǎng)絡(luò)中,Socket和HTTP協(xié)議都是非常重要的概念。它們在數(shù)據(jù)傳輸和通信中扮演著關(guān)鍵角色,但它們的應(yīng)用場景和工作原理有所不同。 1. 定義與基本概念 1.1 Socket Socket
    的頭像 發(fā)表于 11-01 16:14 ?809次閱讀

    合宙Air780EP模塊AT開發(fā)-HTTP應(yīng)用指南

    /article/937)2、初始化HTTP服務(wù)3、設(shè)置HTTP會話參數(shù)4、如果要支持SSL,配置SSL參數(shù)5、如果使用POST命令,輸入POST數(shù)據(jù)6、發(fā)起HTTP
    的頭像 發(fā)表于 08-01 17:15 ?1267次閱讀
    合宙Air780EP模塊AT開發(fā)-<b class='flag-5'>HTTP</b>應(yīng)用指南

    講解HTTP代理類別,使用設(shè)置,測試HTTP代理方法

    HTTP
    jf_62215197
    發(fā)布于 :2024年07月19日 07:03:46

    ESP32-C3播放http音頻文件消耗RAM空間怎么解決?

    主芯片:ESP32-C3-WROOM-02模組 問題描述: 在ESP-ADF下的play_http_mp3例程項(xiàng)目基礎(chǔ)上修改:從mqtt服務(wù)接收要播放的音頻地址,傳入
    發(fā)表于 06-28 07:21

    為什么使用MQTT而不是HTTP?

    為什么使用MQTT而不是HTTP? 在探討為何在某些場景下選擇MQTT(Message Queuing Telemetry Transport)而非HTTP(Hypertext Transfer
    的頭像 發(fā)表于 06-19 14:26 ?738次閱讀
    為什么使用MQTT而不是<b class='flag-5'>HTTP</b>?
    主站蜘蛛池模板: 天天插夜夜 | 狠狠去 | 伊人久久精品成人网 | 男人天堂资源网 | 天天干天天草天天 | 福利影院在线 | 女人牲交一级毛片 | 日韩免费网站 | 天天做天天爱天天爽天天综合 | 五月婷婷深爱五月 | 久久婷婷色综合老司机 | 免费看黄的视频软件 | 手机看片免费福利 | 亚洲我射 | 香蕉视频色版在线观看 | 亚洲国产精品婷婷久久 | 岛国午夜 | 亚洲午夜日韩高清一区 | 狠狠色狠狠色综合久久一 | 亚洲国产女人aaa毛片在线 | 四虎永久精品免费观看 | 性色爽爱性色爽爱网站 | 性xxxfreexxxx性欧美 | 四虎影院最新网站 | 黄色生活毛片 | 亚洲伦理一区二区三区 | 五月综合激情视频在线观看 | 男女视频免费观看 | 毛片韩国| 欧美黄色大片免费 | 色天使亚洲 | 人人爽人人澡 | 91视频看看| 欧美一级黄视频 | 国产午夜视频在线观看第四页 | 日韩一级欧美一级在线观看 | 色综合久久综合 | 业余性自由色xxxx视频 | 四虎最新网址入口 | 国产福利2021最新在线观看 | 欧美淫 |