• <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>

            CppExplore

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

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

            作者:CppExplore 網(wǎng)址:http://m.shnenglu.com/CppExplore/
            本章主要列舉服務(wù)器程序的各種網(wǎng)絡(luò)模型,示例程序以及性能對(duì)比后面再寫(xiě)。
            一、分類(lèi)依據(jù)。服務(wù)器的網(wǎng)絡(luò)模型分類(lèi)主要依據(jù)以下幾點(diǎn)
            (1)是否阻塞方式處理請(qǐng)求,是否多路復(fù)用,使用哪種多路復(fù)用函數(shù)
            (2)是否多線程,多線程間如何組織
            (3)是否多進(jìn)程,多進(jìn)程的切入點(diǎn)一般都是accept函數(shù)前
            二、分類(lèi)。首先根據(jù)是否多路復(fù)用分為三大類(lèi):
            (1)阻塞式模型
            (2)多路復(fù)用模型
            (3)實(shí)時(shí)信號(hào)模型
            三、詳細(xì)分類(lèi)。
            1、阻塞式模型根據(jù)是否多線程分四類(lèi):
            (1)單線程處理。實(shí)現(xiàn)可以參見(jiàn)http://m.shnenglu.com/CppExplore/archive/2008/03/14/44509.html后面的示例代碼。
            (2)一個(gè)請(qǐng)求一個(gè)線程。
            主線程阻塞在accept處,新連接到來(lái),實(shí)時(shí)生成線程處理新連接。受限于進(jìn)程的線程數(shù),以及實(shí)時(shí)創(chuàng)建線程的開(kāi)銷(xiāo),過(guò)多線程后上下文切換的開(kāi)銷(xiāo),該模型也就是有學(xué)習(xí)上價(jià)值。
            (3)預(yù)派生一定數(shù)量線程,并且所有線程阻塞在accept處。
            該模型與下面的(4)類(lèi)似與線程的領(lǐng)導(dǎo)者/追隨者模型。
            傳統(tǒng)的看法認(rèn)為多進(jìn)程(linux上線程仍然是進(jìn)程方式)同時(shí)阻塞在accept處,當(dāng)新連接到來(lái)時(shí)會(huì)有“驚群”現(xiàn)象發(fā)生,即所有都被激活,之后有一個(gè)獲取連接描述符返回,其它再次轉(zhuǎn)為睡眠。linux從2.2.9版本開(kāi)始就不再存在這個(gè)問(wèn)題,只會(huì)有一個(gè)被激活,其它平臺(tái)依舊可能有這個(gè)問(wèn)題,甚至是不支持所有進(jìn)程直接在accept阻塞。
            (4)預(yù)派生一定數(shù)量線程,并且所有線程阻塞在accept前的線程鎖處。
            一次只有一個(gè)線程能阻塞在accept處。避免不支持所有線程直接阻塞在accept,并且避免驚群?jiǎn)栴}。特別是當(dāng)前l(fā)inux2.6的線程庫(kù)下,模型(3)沒(méi)有存在的價(jià)值了。另有文件鎖方式,不具有通用性,并且效率也不高,不再單獨(dú)列舉。
            (5)主線程處理accept,預(yù)派生多個(gè)線程(線程池)處理連接。
            類(lèi)似與線程的半同步/半異步模型。
            主線程的accept返回后,將clientfd放入預(yù)派生線程的線程消息隊(duì)列,線程池讀取線程消息隊(duì)列處理clientfd。主線程只處理accept,可以快速返回繼續(xù)調(diào)用accept,可以避免連接爆發(fā)情況的拒絕連接問(wèn)題,另加大線程消息隊(duì)列的長(zhǎng)度,可以有效減少線程消息隊(duì)列處的系統(tǒng)調(diào)用次數(shù)。
            (6)預(yù)派生多線程阻塞在accept處,每個(gè)線程又有預(yù)派生線程專(zhuān)門(mén)處理連接。
            3)和(4)/(5)的復(fù)合體。
            經(jīng)測(cè)試,(5)中的accept線程處理能力非常強(qiáng),遠(yuǎn)遠(yuǎn)大于業(yè)務(wù)線程,并發(fā)10000的連接數(shù)也毫無(wú)影響,因此該模型沒(méi)有實(shí)際意義。
            總結(jié):就前五模型而言,性能最好的是模型(5)。模型(3)/(4)可以一定程度上改善模型(1)的處理性能,處理爆發(fā)繁忙的連接,仍然不理想。。阻塞式模型因?yàn)樽x的阻塞性,容易受到攻擊,一個(gè)死連接(建立連接但是不發(fā)送數(shù)據(jù)的連接)就可以導(dǎo)致業(yè)務(wù)線程死掉。因此內(nèi)部服務(wù)器的交互可以采用這類(lèi)模型,對(duì)外的服務(wù)不適合。優(yōu)先(5),然后是(4),然后是(1),其它不考慮。
            2、多路復(fù)用模型根據(jù)多路復(fù)用點(diǎn)、是否多線程分類(lèi):
            以下各個(gè)模型依據(jù)選用select/poll/epoll又都細(xì)分為3類(lèi)。下面?zhèn)€別術(shù)語(yǔ)采用select中的,僅為說(shuō)明。
            (1)accept函數(shù)在多路復(fù)用函數(shù)之前,主線程在accept處阻塞,多個(gè)從線程在多路復(fù)用函數(shù)處阻塞。主線程和從線程通過(guò)管道通訊,主線程通過(guò)管道依次將連接的clientfd寫(xiě)入對(duì)應(yīng)從線程管道,從線程把管道的讀端pipefd作為fd_set的第一個(gè)描述符,如pipefd可讀,則讀數(shù)據(jù),根據(jù)預(yù)定義格式分解出clientfd放入fd_set,如果clientfd可讀,則read之后處理業(yè)務(wù)。
            此方法可以避免select的fd_set上限限制,具體機(jī)器上select可以支持多少個(gè)描述符,可以通過(guò)打印sizeof(fd_set)查看,我機(jī)器上是512字節(jié),則支持512×8=4096個(gè)。為了支持多余4096的連接數(shù),此模型下就可以創(chuàng)建多個(gè)從線程分別多路復(fù)用,主線程accept后平均放入(順序循環(huán))各個(gè)線程的管道中。創(chuàng)建5個(gè)從線程以其對(duì)應(yīng)管道,就可以支持2w的連接,足夠了。另一方面相對(duì)與單線程的select,單一連接可讀的時(shí)候,還可以減少循環(huán)掃描fd_set的次數(shù)。單線程下要掃描所有fd_set(如果再最后),該模型下,只需要掃描所在線程的fd_set就可。
            (2)accept函數(shù)在多路復(fù)用函數(shù)之前,與(1)的差別在于,主線程不直接與從線程通過(guò)管道通訊,而是將獲取的fd放入另一緩存線程的線程消息隊(duì)列,緩存線程讀消息隊(duì)列,然后通過(guò)管道與從線程通訊。
            目的在主線程中減少系統(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)都可以在檢測(cè)到cliendfd可讀的時(shí)候,把描述符寫(xiě)入另一線程(也可以是線程池)的線程消息隊(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)志或者需要讀取的字符串個(gè)數(shù),讀取結(jié)束,則將clientfd/buffer指針?lè)湃霕I(yè)務(wù)線程的線程消息隊(duì)列,業(yè)務(wù)線程讀取消息隊(duì)列處理業(yè)務(wù)。這也就是經(jīng)典的proactor模擬。
            總結(jié):模型(1)是拓展select處理能力不錯(cuò)選擇;模型(2)是模型(1)在爆發(fā)連接下的調(diào)整版本;模型(3)是經(jīng)典的reactor,epoll在該模型下性能就已經(jīng)很好,而select/poll仍然存在爆發(fā)連接的拒絕連接情況;模型(4)(5)則是方便業(yè)務(wù)處理,對(duì)模型(3)進(jìn)行多線程調(diào)整的版本。帶有復(fù)雜業(yè)務(wù)處理的情況下推薦模型(5)。根據(jù)測(cè)試顯示,使用epoll的時(shí)候,模型(1)(2)相對(duì)(3)沒(méi)有明顯的性能優(yōu)勢(shì),(1)由于主線程兩次的系統(tǒng)調(diào)用,反而性能下降。
            3、實(shí)時(shí)信號(hào)模型:
            使用fcntl的F_SETSIG操作,把描述符可讀的信號(hào)由不可靠的SIGIO(SYSTEM V)或者SIGPOLL(BSD)換成可靠信號(hào)。即可成為替代多路復(fù)用的方式。優(yōu)于select/poll,特別是在大量死連接存在的情況下,但不及epoll。
            四、多進(jìn)程的參與的方式
            (1)fork模型。fork后所有進(jìn)程直接在accept阻塞。以上主線程在accept阻塞的都可以在accept前fork為多進(jìn)程。同樣面臨驚群?jiǎn)栴}。
            (2)fork模型。fork后所有進(jìn)程阻塞在accept前的線程鎖處。同線程中一樣避免不支持所有進(jìn)程直接阻塞在accept或者驚群?jiǎn)栴},所有進(jìn)程阻塞在共享內(nèi)存上實(shí)現(xiàn)的線程互斥鎖。
            (3)業(yè)務(wù)和網(wǎng)絡(luò)層分離為不同進(jìn)程模型。這個(gè)模型可能是受unix簡(jiǎn)單哲學(xué)的影響,一個(gè)進(jìn)程完成一件事情,復(fù)雜的事情通過(guò)多個(gè)進(jìn)程結(jié)合管道完成。我見(jiàn)過(guò)進(jìn)程方式的商業(yè)協(xié)議棧實(shí)現(xiàn)。自己暫時(shí)還沒(méi)有寫(xiě)該模型的示例程序測(cè)試對(duì)比性能。
            (4)均衡負(fù)載模型。起多個(gè)進(jìn)程綁定到不同的服務(wù)端口,前端部署lvs等均衡負(fù)載系統(tǒng),暴露一個(gè)網(wǎng)絡(luò)地址,后端映射到不同的進(jìn)程,實(shí)現(xiàn)可擴(kuò)展的多進(jìn)程方案。
            總結(jié):個(gè)人認(rèn)為(1)(2)沒(méi)什么意義。(3)暫不評(píng)價(jià)。(4)則是均衡負(fù)載方案,和以上所有方案不沖突。
            以上模型的代碼示例以及性能對(duì)比后面給出。

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

            評(píng)論

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

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

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

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

            BTW:看來(lái)兄臺(tái)也是server程序員,有時(shí)間多多交流:)
              回復(fù)  更多評(píng)論
              

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

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

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

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計(jì)之 網(wǎng)絡(luò)模型(二)[未登錄](méi) 2008-03-24 19:32 CppExplore
            @ecopgm
            1、上面的模型并不是都將accept獨(dú)立處理啊?各種情況都有的。“下級(jí)線程池處理邏輯”這個(gè)就多說(shuō)了,這個(gè)和accept/讀寫(xiě)是否在同一線程不沖突,不同線程的時(shí)候也可以把邏輯獨(dú)立出來(lái)。各種模型性能上的數(shù)據(jù)對(duì)比后面的文章會(huì)給出具體的數(shù)據(jù)。概括說(shuō)下,不單獨(dú)處理accept,除epoll方式外,爆發(fā)連接都會(huì)出現(xiàn)拒絕連接情況,比如ab(apache帶的工具)并發(fā)1w的時(shí)候。當(dāng)然并非所有的服務(wù)器能是要處理這種爆發(fā)的斷連接。在不拒絕連接的情況下,比如并發(fā)1000,性能還是差不多的。
            2、連接被拒絕是在三路握手階段,accept接受的所有連接,連接就不會(huì)被丟掉了啊,生產(chǎn)者的確是非常快,消費(fèi)者很慢,但不影響client把數(shù)據(jù)發(fā)送到這邊的接受緩沖區(qū)。服務(wù)器沒(méi)有發(fā)送reset的必要,client也不會(huì)發(fā)fin分節(jié),連接自然不會(huì)被丟掉。
            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ù)  更多評(píng)論
              

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

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

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

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

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

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計(jì)之 網(wǎng)絡(luò)模型(二)[未登錄](méi) 2008-05-01 07:53 CppExplore
            @true
            :)
            這個(gè)就是文中2(1)的模型,主線程accept,將新的clientfd通過(guò)管道傳遞給epoll線程,管道的讀端也在epoll的監(jiān)控之下。不使用管道的話,sockpair也可以,不過(guò)它也是基于管道實(shí)現(xiàn)。
            管道的連接是不可回避的,因?yàn)閑poll線程在epoll_wait處等待,要實(shí)時(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ù)需要后接線程,測(cè)試的數(shù)據(jù)一直沒(méi)時(shí)間發(fā)出來(lái),過(guò)幾天發(fā)下。  回復(fù)  更多評(píng)論
              

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

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

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

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


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


            色婷婷久久久SWAG精品| 久久亚洲国产最新网站| 久久久久久午夜精品| 久久久久青草线蕉综合超碰| 久久99精品久久久久久动态图 | 国产精品美女久久久久AV福利| 久久精品三级视频| 婷婷五月深深久久精品| 久久亚洲国产欧洲精品一 | 综合久久久久久中文字幕亚洲国产国产综合一区首| 久久久国产视频| 天堂久久天堂AV色综合| 国产综合成人久久大片91| 精品久久久久久国产潘金莲| 久久无码国产| 九九热久久免费视频| 免费精品久久天干天干| 久久久久国产一区二区三区| 性欧美丰满熟妇XXXX性久久久 | 精品人妻久久久久久888| 欧美日韩成人精品久久久免费看| 99久久99久久精品国产片果冻| 久久一区二区三区免费| 久久发布国产伦子伦精品| 久久人人爽人人爽人人片AV高清 | 久久婷婷五月综合97色直播| 久久久久一区二区三区| 久久精品国产亚洲AV影院| 久久久WWW免费人成精品| 久久99精品国产99久久| 国产日产久久高清欧美一区| 国内精品九九久久精品| 亚洲人成无码www久久久| 精品99久久aaa一级毛片| 国产69精品久久久久99尤物| 久久精品亚洲中文字幕无码麻豆| 久久无码AV中文出轨人妻| 人妻系列无码专区久久五月天| 欧美精品一本久久男人的天堂| 久久精品www人人爽人人| 久久精品国产亚洲77777|