青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

CppExplore

一切像霧像雨又像風(fēng)

  C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
  29 隨筆 :: 0 文章 :: 280 評論 :: 0 Trackbacks

作者:CppExplore 網(wǎng)址:http://m.shnenglu.com/CppExplore/
本章主要列舉服務(wù)器程序的各種網(wǎng)絡(luò)模型,示例程序以及性能對比后面再寫。
一、分類依據(jù)。服務(wù)器的網(wǎng)絡(luò)模型分類主要依據(jù)以下幾點(diǎn)
(1)是否阻塞方式處理請求,是否多路復(fù)用,使用哪種多路復(fù)用函數(shù)
(2)是否多線程,多線程間如何組織
(3)是否多進(jìn)程,多進(jìn)程的切入點(diǎn)一般都是accept函數(shù)前
二、分類。首先根據(jù)是否多路復(fù)用分為三大類:
(1)阻塞式模型
(2)多路復(fù)用模型
(3)實(shí)時信號模型
三、詳細(xì)分類。
1、阻塞式模型根據(jù)是否多線程分四類:
(1)單線程處理。實(shí)現(xiàn)可以參見http://m.shnenglu.com/CppExplore/archive/2008/03/14/44509.html后面的示例代碼。
(2)一個請求一個線程。
主線程阻塞在accept處,新連接到來,實(shí)時生成線程處理新連接。受限于進(jìn)程的線程數(shù),以及實(shí)時創(chuàng)建線程的開銷,過多線程后上下文切換的開銷,該模型也就是有學(xué)習(xí)上價值。
(3)預(yù)派生一定數(shù)量線程,并且所有線程阻塞在accept處。
該模型與下面的(4)類似與線程的領(lǐng)導(dǎo)者/追隨者模型。
傳統(tǒng)的看法認(rèn)為多進(jìn)程(linux上線程仍然是進(jìn)程方式)同時阻塞在accept處,當(dāng)新連接到來時會有“驚群”現(xiàn)象發(fā)生,即所有都被激活,之后有一個獲取連接描述符返回,其它再次轉(zhuǎn)為睡眠。linux從2.2.9版本開始就不再存在這個問題,只會有一個被激活,其它平臺依舊可能有這個問題,甚至是不支持所有進(jìn)程直接在accept阻塞。
(4)預(yù)派生一定數(shù)量線程,并且所有線程阻塞在accept前的線程鎖處。
一次只有一個線程能阻塞在accept處。避免不支持所有線程直接阻塞在accept,并且避免驚群問題。特別是當(dāng)前l(fā)inux2.6的線程庫下,模型(3)沒有存在的價值了。另有文件鎖方式,不具有通用性,并且效率也不高,不再單獨(dú)列舉。
(5)主線程處理accept,預(yù)派生多個線程(線程池)處理連接。
類似與線程的半同步/半異步模型。
主線程的accept返回后,將clientfd放入預(yù)派生線程的線程消息隊(duì)列,線程池讀取線程消息隊(duì)列處理clientfd。主線程只處理accept,可以快速返回繼續(xù)調(diào)用accept,可以避免連接爆發(fā)情況的拒絕連接問題,另加大線程消息隊(duì)列的長度,可以有效減少線程消息隊(duì)列處的系統(tǒng)調(diào)用次數(shù)。
(6)預(yù)派生多線程阻塞在accept處,每個線程又有預(yù)派生線程專門處理連接。
3)和(4)/(5)的復(fù)合體。
經(jīng)測試,(5)中的accept線程處理能力非常強(qiáng),遠(yuǎn)遠(yuǎn)大于業(yè)務(wù)線程,并發(fā)10000的連接數(shù)也毫無影響,因此該模型沒有實(shí)際意義。
總結(jié):就前五模型而言,性能最好的是模型(5)。模型(3)/(4)可以一定程度上改善模型(1)的處理性能,處理爆發(fā)繁忙的連接,仍然不理想。。阻塞式模型因?yàn)樽x的阻塞性,容易受到攻擊,一個死連接(建立連接但是不發(fā)送數(shù)據(jù)的連接)就可以導(dǎo)致業(yè)務(wù)線程死掉。因此內(nèi)部服務(wù)器的交互可以采用這類模型,對外的服務(wù)不適合。優(yōu)先(5),然后是(4),然后是(1),其它不考慮。
2、多路復(fù)用模型根據(jù)多路復(fù)用點(diǎn)、是否多線程分類:
以下各個模型依據(jù)選用select/poll/epoll又都細(xì)分為3類。下面?zhèn)€別術(shù)語采用select中的,僅為說明。
(1)accept函數(shù)在多路復(fù)用函數(shù)之前,主線程在accept處阻塞,多個從線程在多路復(fù)用函數(shù)處阻塞。主線程和從線程通過管道通訊,主線程通過管道依次將連接的clientfd寫入對應(yīng)從線程管道,從線程把管道的讀端pipefd作為fd_set的第一個描述符,如pipefd可讀,則讀數(shù)據(jù),根據(jù)預(yù)定義格式分解出clientfd放入fd_set,如果clientfd可讀,則read之后處理業(yè)務(wù)。
此方法可以避免select的fd_set上限限制,具體機(jī)器上select可以支持多少個描述符,可以通過打印sizeof(fd_set)查看,我機(jī)器上是512字節(jié),則支持512×8=4096個。為了支持多余4096的連接數(shù),此模型下就可以創(chuàng)建多個從線程分別多路復(fù)用,主線程accept后平均放入(順序循環(huán))各個線程的管道中。創(chuàng)建5個從線程以其對應(yīng)管道,就可以支持2w的連接,足夠了。另一方面相對與單線程的select,單一連接可讀的時候,還可以減少循環(huán)掃描fd_set的次數(shù)。單線程下要掃描所有fd_set(如果再最后),該模型下,只需要掃描所在線程的fd_set就可。
(2)accept函數(shù)在多路復(fù)用函數(shù)之前,與(1)的差別在于,主線程不直接與從線程通過管道通訊,而是將獲取的fd放入另一緩存線程的線程消息隊(duì)列,緩存線程讀消息隊(duì)列,然后通過管道與從線程通訊。
目的在主線程中減少系統(tǒng)調(diào)用,加快accept的處理,避免連接爆發(fā)情況下的拒絕連接。
(3)多路復(fù)用函數(shù)在accept之前多路復(fù)用函數(shù)返回,如果可讀的是serverfd,則accept,其它則read,后處理業(yè)務(wù),這是多路復(fù)用通用的模型,也是經(jīng)典的reactor模型。
4)連接在單獨(dú)線程中處理。
以上(1)(2)(3)都可以在檢測到cliendfd可讀的時候,把描述符寫入另一線程(也可以是線程池)的線程消息隊(duì)列,另一線程(或線程池)負(fù)責(zé)read,后處理業(yè)務(wù)。

(5)業(yè)務(wù)線程獨(dú)立,下面的網(wǎng)絡(luò)層讀取結(jié)束后通知業(yè)務(wù)線程。
以上(1)(2)(3)(4)中都可以將業(yè)務(wù)線程(可以是線程池)獨(dú)立,事先告之(1)、(2)、(3)、(4)中read所在線程(上面1、2、4都可以是線程池),需要讀取的字符串結(jié)束標(biāo)志或者需要讀取的字符串個數(shù),讀取結(jié)束,則將clientfd/buffer指針放入業(yè)務(wù)線程的線程消息隊(duì)列,業(yè)務(wù)線程讀取消息隊(duì)列處理業(yè)務(wù)。這也就是經(jīng)典的proactor模擬。
總結(jié):模型(1)是拓展select處理能力不錯選擇;模型(2)是模型(1)在爆發(fā)連接下的調(diào)整版本;模型(3)是經(jīng)典的reactor,epoll在該模型下性能就已經(jīng)很好,而select/poll仍然存在爆發(fā)連接的拒絕連接情況;模型(4)(5)則是方便業(yè)務(wù)處理,對模型(3)進(jìn)行多線程調(diào)整的版本。帶有復(fù)雜業(yè)務(wù)處理的情況下推薦模型(5)。根據(jù)測試顯示,使用epoll的時候,模型(1)(2)相對(3)沒有明顯的性能優(yōu)勢,(1)由于主線程兩次的系統(tǒng)調(diào)用,反而性能下降。
3、實(shí)時信號模型:
使用fcntl的F_SETSIG操作,把描述符可讀的信號由不可靠的SIGIO(SYSTEM V)或者SIGPOLL(BSD)換成可靠信號。即可成為替代多路復(fù)用的方式。優(yōu)于select/poll,特別是在大量死連接存在的情況下,但不及epoll。
四、多進(jìn)程的參與的方式
(1)fork模型。fork后所有進(jìn)程直接在accept阻塞。以上主線程在accept阻塞的都可以在accept前fork為多進(jìn)程。同樣面臨驚群問題。
(2)fork模型。fork后所有進(jìn)程阻塞在accept前的線程鎖處。同線程中一樣避免不支持所有進(jìn)程直接阻塞在accept或者驚群問題,所有進(jìn)程阻塞在共享內(nèi)存上實(shí)現(xiàn)的線程互斥鎖。
(3)業(yè)務(wù)和網(wǎng)絡(luò)層分離為不同進(jìn)程模型。這個模型可能是受unix簡單哲學(xué)的影響,一個進(jìn)程完成一件事情,復(fù)雜的事情通過多個進(jìn)程結(jié)合管道完成。我見過進(jìn)程方式的商業(yè)協(xié)議棧實(shí)現(xiàn)。自己暫時還沒有寫該模型的示例程序測試對比性能。
(4)均衡負(fù)載模型。起多個進(jìn)程綁定到不同的服務(wù)端口,前端部署lvs等均衡負(fù)載系統(tǒng),暴露一個網(wǎng)絡(luò)地址,后端映射到不同的進(jìn)程,實(shí)現(xiàn)可擴(kuò)展的多進(jìn)程方案。
總結(jié):個人認(rèn)為(1)(2)沒什么意義。(3)暫不評價。(4)則是均衡負(fù)載方案,和以上所有方案不沖突。
以上模型的代碼示例以及性能對比后面給出。

posted on 2008-03-21 17:16 cppexplore 閱讀(11580) 評論(16)  編輯 收藏 引用

評論

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-21 19:17 sgsoft
現(xiàn)在的高性能服務(wù)器多采用異步IO,在Windows上,使用IOCP,在AIX上,使用AIO 系統(tǒng)對象,在Solaris,HP-UX上,都有不同實(shí)現(xiàn)。但大多使用了OS的異步事件隊(duì)列來防止連接阻塞。

是否缺異步通信服務(wù)器模型呢?Win和*inx不一樣的實(shí)現(xiàn)。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-21 22:05 cppexplore
@sgsoft
win上實(shí)現(xiàn)了socket上真正的AIO,*inx上基本上都沒有針對socket實(shí)現(xiàn)真正的AIO。本文主要針對linux平臺,其他平臺不很熟悉,并且沒機(jī)會接觸,也無法寫代碼進(jìn)行測試,因此AIO的模型就沒涉及。
另詳細(xì)分類2里的模型(5)模擬了AIO的實(shí)現(xiàn),也就是proactor的模擬。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-03-22 12:27 創(chuàng)
我一直采用的sever處理模型是,父進(jìn)程創(chuàng)建出監(jiān)聽socket,然后fork出子進(jìn)程,子進(jìn)程中在accept出阻塞,處理IO時采用多路復(fù)用模型(select之類的),個人感覺效率還是不錯的.

BTW:看來兄臺也是server程序員,有時間多多交流:)
  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-24 12:16 cppexplore
@創(chuàng)
你的模型是不是和細(xì)分類2中(1)的模型類似啊,直接使用線程不更好嘛。如果是用epoll的話,直接單線程在epoll處wait就好。

以前去你blog上逛過,呵呵,多多交流!  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-24 15:24 ecopgm
在下是新手,想問幾個問題:
1. 上面的模型,都是將accept獨(dú)立處理,這樣可以接受爆發(fā)連接,然后讀寫和邏輯處理都是交給下級線程池。那這樣的模型跟主線程里accept并讀寫,然后下級線程池處理邏輯,在性能上區(qū)別有多大呢?
2. accept即使接受了所有爆發(fā)連接,但是生產(chǎn)者快,消費(fèi)者慢,加上隊(duì)列的流控,這樣還是沒什么用啊,連接還是會被丟掉
3. 消息隊(duì)列和管道,這兩種通信方式,在性能上有什么差異?管道更好嗎,比消息隊(duì)列更少的同步操作?  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-03-24 19:32 CppExplore
@ecopgm
1、上面的模型并不是都將accept獨(dú)立處理啊?各種情況都有的?!跋录壘€程池處理邏輯”這個就多說了,這個和accept/讀寫是否在同一線程不沖突,不同線程的時候也可以把邏輯獨(dú)立出來。各種模型性能上的數(shù)據(jù)對比后面的文章會給出具體的數(shù)據(jù)。概括說下,不單獨(dú)處理accept,除epoll方式外,爆發(fā)連接都會出現(xiàn)拒絕連接情況,比如ab(apache帶的工具)并發(fā)1w的時候。當(dāng)然并非所有的服務(wù)器能是要處理這種爆發(fā)的斷連接。在不拒絕連接的情況下,比如并發(fā)1000,性能還是差不多的。
2、連接被拒絕是在三路握手階段,accept接受的所有連接,連接就不會被丟掉了啊,生產(chǎn)者的確是非常快,消費(fèi)者很慢,但不影響client把數(shù)據(jù)發(fā)送到這邊的接受緩沖區(qū)。服務(wù)器沒有發(fā)送reset的必要,client也不會發(fā)fin分節(jié),連接自然不會被丟掉。
3、消息隊(duì)列自然比管道快,這里的消息隊(duì)列不是ipc的消息隊(duì)列,全部實(shí)現(xiàn)在用戶態(tài),可以看下上一篇《線程二》有消息隊(duì)列的實(shí)現(xiàn),比涉及系統(tǒng)調(diào)用的管道快,管道怎么也是屬于進(jìn)程間通訊的方式。但是消息隊(duì)列不能象管道一樣把文件描述符放到fd_set里,供select監(jiān)控。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-24 22:11 ecopgm
@CppExplore
我先前理解錯了,能不能接受爆發(fā)連接,是取決于accept的速度。我對并發(fā)的概念沒想清楚,呵呵,謝謝。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-03-24 22:34 CppExplore
@ecopgm
這么晚還沒睡覺啊。
這里說的爆發(fā)的連接,也可以說是單點(diǎn)并發(fā)。你想的并發(fā)是不是同時在線的連接???一般都是追求的同時在線連接數(shù)。爆發(fā)連接的場景畢竟也不多。尤其是對音頻視頻等多媒體的應(yīng)用服務(wù)器,限于網(wǎng)絡(luò)帶寬,也不可能有爆發(fā)的連接出現(xiàn),有的話直接拒絕連接就可以接受,呵呵。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-24 22:41 ecopgm
對的,我想成請求數(shù)了,覺得如果1萬個連接到了,每個發(fā)個消息過來,邏輯層處理不了這么多,而隊(duì)列又裝不下,那這個請求就丟失了,請求不是連接,呵呵  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二) 2008-03-25 10:11 游客
好文章,贊一個?。?nbsp; 回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-04-30 20:05 true
下面這個假想的模型在上面有體現(xiàn),但不太好歸類,描述如下:
1.主線程一直accept
2.有一個線程在監(jiān)聽epoll事件
3.accept后將連接加入2中的epoll監(jiān)聽(在epoll中add 這個fd時是線程安全的嗎?)
4.epoll檢測到某fd可讀時,交給業(yè)務(wù)邏輯線程t1處理(這時需要在epoll中del這個fd嗎),在t1中根據(jù)請求的類型給fd發(fā)送了一些數(shù)據(jù),然后再加入到epoll中?。即2中的epoll只監(jiān)聽可讀  回復(fù)  更多評論
  

# re: 【原創(chuàng)】系統(tǒng)設(shè)計之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-05-01 07:53 CppExplore
@true
:)
這個就是文中2(1)的模型,主線程accept,將新的clientfd通過管道傳遞給epoll線程,管道的讀端也在epoll的監(jiān)控之下。不使用管道的話,sockpair也可以,不過它也是基于管道實(shí)現(xiàn)。
管道的連接是不可回避的,因?yàn)閑poll線程在epoll_wait處等待,要實(shí)時的告訴epoll監(jiān)控某fd,一定要epoll_wait返回,執(zhí)行加入操作,再繼續(xù)epoll_wait。
后面的業(yè)務(wù)線程處理也就是2(4)和2(5)模型。
2(3)是單線程的模型,就epoll而言,單線程的性能最好,也就是epoll+單線程=高性能。業(yè)務(wù)線程當(dāng)然是根據(jù)需要后接線程,測試的數(shù)據(jù)一直沒時間發(fā)出來,過幾天發(fā)下。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】技術(shù)系列之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-06-19 12:12 Jeff
想問一下,不可以用UDP來接收請求數(shù)據(jù)嗎,為什么非要用TCP,UDP不可靠?  回復(fù)  更多評論
  

# re: 【原創(chuàng)】技術(shù)系列之 網(wǎng)絡(luò)模型(二)[未登錄] 2008-06-19 13:26 CppExplore
@Jeff
udp也可以啊,模型簡單,在一個端口上復(fù)用就可以了,沒什么可寫的。  回復(fù)  更多評論
  

# re: 【原創(chuàng)】技術(shù)系列之 網(wǎng)絡(luò)模型(二) 2009-04-19 20:49 蛙蛙
你怎么2W連接就滿足了呀,下面這個人弄了單機(jī)50W連接。
http://blog.sina.com.cn/s/blog_466c66400100cfrj.html  回復(fù)  更多評論
  

# re: 【原創(chuàng)】技術(shù)系列之 網(wǎng)絡(luò)模型(二) 2015-03-27 17:13 ckw
文中2(1)的模型 使用select時也無法突破最大fd=1024的限制啊!  回復(fù)  更多評論
  


只有注冊用戶登錄后才能發(fā)表評論。
網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲手机在线| 免费看黄裸体一级大秀欧美| 欧美久色视频| 久久裸体艺术| 亚洲韩日在线| 性欧美1819性猛交| 亚洲国产精品123| 国产精品美女www爽爽爽| 欧美另类99xxxxx| 欧美伦理影院| 欧美黑人在线播放| 久久手机精品视频| 中文在线资源观看网站视频免费不卡| 亚洲欧美日韩国产综合| 亚洲欧美在线网| 久久精品一二三区| 久久精品国产综合| 先锋影音国产一区| 亚洲国产精品免费| 日韩亚洲一区在线播放| 在线一区欧美| 亚洲国产成人高清精品| 欧美日韩二区三区| 国产精品区一区二区三区| 国产一区再线| 日韩视频在线一区二区| 亚洲美女在线视频| 在线视频亚洲欧美| 欧美1区2区| 亚洲美女网站| 久久激情一区| 欧美精品在欧美一区二区少妇| 欧美成人在线网站| 国产亚洲成精品久久| 一区二区三区精品国产| 欧美亚洲自偷自偷| 久久在线91| 99这里只有久久精品视频| 欧美日本一区二区三区| 精品成人国产在线观看男人呻吟| 韩国福利一区| 99re8这里有精品热视频免费| 欧美亚洲一区在线| 亚洲男人的天堂在线观看| 欧美日韩一区二区在线观看| 亚洲人成网站777色婷婷| 午夜在线视频观看日韩17c| 正在播放亚洲一区| 欧美精品福利视频| 在线观看不卡av| 亚洲视频在线观看一区| 午夜一区在线| 99国产精品99久久久久久| 久久资源在线| 国内精品美女在线观看| 亚洲精品久久嫩草网站秘色| 在线观看中文字幕不卡| 欧美主播一区二区三区美女 久久精品人| 欧美精品激情在线| 亚洲视频中文字幕| 亚洲大胆在线| 免费成人av资源网| 亚洲欧美日韩精品久久奇米色影视 | 欧美一区免费视频| 亚洲欧美激情视频| 韩国av一区二区三区| 亚洲国产日韩欧美综合久久| 欧美日韩综合| 久久网站热最新地址| 欧美在线视频观看免费网站| 在线综合亚洲欧美在线视频| 亚洲一区二区在线看| 国产一区视频网站| 午夜在线一区二区| 欧美亚洲免费电影| 欧美黄色免费| 亚洲欧美日韩精品久久久久| 午夜精彩视频在线观看不卡| 一区二区高清视频在线观看| 亚洲专区国产精品| 这里只有视频精品| 国产精品亚洲欧美| 亚洲欧美中文日韩v在线观看| 伊人夜夜躁av伊人久久| 亚洲一区二区三区视频| 欧美伊久线香蕉线新在线| 欧美日韩无遮挡| 午夜亚洲福利| 欧美绝品在线观看成人午夜影视| 在线观看91精品国产麻豆| 久久久久久日产精品| 欧美中文在线字幕| 国产精品毛片| 久久成人免费日本黄色| 久久精品国产2020观看福利| 欧美视频一区在线观看| 美腿丝袜亚洲色图| 亚洲精品日韩在线| 欧美日韩高清在线| 欧美激情视频网站| 欧美一区二区三区免费视频| 亚洲高清久久网| 日韩一级精品视频在线观看| 国产一区二区视频在线观看 | 亚洲特级片在线| 欧美成人国产va精品日本一级| 一区二区三区日韩欧美| 精品69视频一区二区三区| 国产精品伦一区| 欧美—级高清免费播放| 欧美电影在线观看| 久久狠狠亚洲综合| 欧美一区二区高清在线观看| 夜夜嗨网站十八久久| 亚洲国产高清在线| 亚洲一二三区在线| 亚洲国产婷婷| 欧美日韩中字| 欧美大片在线观看| 亚洲人成高清| 欧美日韩mp4| 亚洲精品偷拍| 夜夜精品视频一区二区| 久久久噜噜噜久久| 欧美人成在线| 一区二区三区**美女毛片| 欧美国产一区视频在线观看| 免费观看成人网| 小黄鸭精品aⅴ导航网站入口| 国产色婷婷国产综合在线理论片a| 欧美激情一区二区久久久| 欧美激情综合五月色丁香小说| 免费黄网站欧美| 久久久免费精品视频| 久久精品国产精品亚洲综合| 久久久久久亚洲精品杨幂换脸| 久久免费视频一区| 国产精品一区二区久久| 国产精品视频午夜| 亚洲第一在线视频| 久久国产欧美日韩精品| 亚洲电影下载| 亚洲一区不卡| 久久精品2019中文字幕| 国产精品大片| 一区二区电影免费观看| 午夜日韩电影| 亚洲精品在线视频| 久久在线视频在线| 国产欧美日韩三区| 91久久精品国产91久久性色| 亚洲精品一区二区在线观看| 久久精品人人| 亚洲一区一卡| 久久精品主播| 欧美精品国产| aⅴ色国产欧美| 亚洲高清三级视频| 欧美夜福利tv在线| 国产精品午夜电影| 午夜精品成人在线| 亚洲一区影院| 欧美成人黄色小视频| 亚洲激情在线播放| 欧美激情片在线观看| 久久不见久久见免费视频1| 国产精自产拍久久久久久蜜| 亚洲理伦在线| 久久婷婷综合激情| 亚洲精品一区在线| 欧美一区二区三区在线视频| 国产精品高潮呻吟久久av无限| 亚洲特黄一级片| 小黄鸭精品密入口导航| 亚洲国产精品久久| 99天天综合性| 国内揄拍国内精品少妇国语| 欧美成年人网站| 久久精品一区| 亚洲福利国产精品| 亚洲一区二区三区在线视频| 樱花yy私人影院亚洲| 亚洲国产精品嫩草影院| 欧美精品在线观看播放| 久久国产日韩| 国产精品久久久久久久久免费樱桃| 日韩午夜黄色| 日韩图片一区| 日韩午夜剧场| 欧美不卡视频| 亚洲欧美日韩综合一区| 久久久亚洲欧洲日产国码αv| 久久精品国产2020观看福利| 国内精品久久久久影院 日本资源| 欧美激情国产日韩精品一区18| 国产精品素人视频| 亚洲精品欧美日韩专区| 国产日韩综合一区二区性色av| 亚洲日本无吗高清不卡| 91久久精品久久国产性色也91|