999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

移動(dòng)應(yīng)用的消息推送與MQTT協(xié)議

2016-03-04 20:43:21朱艷
無線互聯(lián)科技 2015年8期

朱艷

摘要:隨著智能設(shè)備的快速普及和移動(dòng)應(yīng)用的迅猛發(fā)展,已進(jìn)入移動(dòng)互聯(lián)網(wǎng)時(shí)代。消息推送是移動(dòng)應(yīng)用的一個(gè)顯著特征,是移動(dòng)互聯(lián)網(wǎng)時(shí)代的基礎(chǔ)設(shè)施。蘋果和谷歌都提供消息推送服務(wù),但并不能滿足企業(yè)級(jí)移動(dòng)應(yīng)用的推送要求。MQTT協(xié)議是由IBM提出的面向物聯(lián)網(wǎng)的通訊協(xié)議,其簡(jiǎn)潔,高效,可靠等特征非常適合用于構(gòu)建消息推送服務(wù)。文章討論了使用MQTT協(xié)議構(gòu)建消息推送服務(wù)的必要性和適用性,并指出了在具體實(shí)現(xiàn)上應(yīng)注意的一些關(guān)鍵問題,同時(shí)給出了相關(guān)建議。

關(guān)鍵詞:移動(dòng)應(yīng)用;消息推送;MQTT

1消息推送是移動(dòng)應(yīng)用的基礎(chǔ)功能

現(xiàn)今已經(jīng)從互聯(lián)網(wǎng)時(shí)代快速進(jìn)入到了移動(dòng)互聯(lián)網(wǎng)時(shí)代。根據(jù)相關(guān)資料,早在2014年,智能手機(jī)和平板電腦的銷售量就已經(jīng)超過了傳統(tǒng)Pc的銷售量,而且這一趨勢(shì)還在不斷加強(qiáng),以智能手機(jī)為主的移動(dòng)設(shè)備仍然在高速增長(zhǎng)。

信息化系統(tǒng)建設(shè)也相應(yīng)地轉(zhuǎn)向移動(dòng)設(shè)備,傳統(tǒng)的基于桌面瀏覽器的應(yīng)用系統(tǒng)日漸式微,移動(dòng)應(yīng)用(APP)已成為主流趨勢(shì)。以前的熱門網(wǎng)站不再受到人們的追捧,取而代之的是運(yùn)行在手機(jī)上的各種APP0一個(gè)顯著的例子是微信和QQ,同樣由騰訊公司開發(fā)的社交應(yīng)用,兩者分別代表了移動(dòng)互聯(lián)網(wǎng)和傳統(tǒng)互聯(lián)網(wǎng),微信的歷史只有短短的4-5年,但其活躍用戶數(shù)已經(jīng)遠(yuǎn)超歷史悠久的QQ。在企業(yè)內(nèi)部,政府部門、事業(yè)單位內(nèi)部,也紛紛調(diào)整其信息化建設(shè),向移動(dòng)應(yīng)用方向傾斜,移動(dòng)化已成為共識(shí)。

移動(dòng)應(yīng)用作為一種新的應(yīng)用類型,與傳統(tǒng)基于桌面的瀏覽器/服務(wù)器(Browser/Server)架構(gòu)相比較,在應(yīng)用場(chǎng)景,交互方式,開發(fā)技術(shù)等方面都有所不同。對(duì)于使用者而言,移動(dòng)應(yīng)用將其從電腦前解放了出來,使用者可以在任何時(shí)間,任意地點(diǎn)打開移動(dòng)應(yīng)用,瀏覽自己所需要的信息,或者進(jìn)行相應(yīng)的操作,只需設(shè)備聯(lián)網(wǎng)即可。這種便利性使得移動(dòng)應(yīng)用迅速受到使用者的歡迎。而且,由于移動(dòng)設(shè)備隨身攜帶,并一直保持網(wǎng)絡(luò)連接狀態(tài),移動(dòng)應(yīng)用能夠做到主動(dòng)的消息推送和提醒,而無需使用者不時(shí)打開應(yīng)用去查看,實(shí)現(xiàn)了信息主動(dòng)找人。

消息推送是移動(dòng)應(yīng)用的基礎(chǔ)功能,是移動(dòng)互聯(lián)網(wǎng)時(shí)代的重要基礎(chǔ)設(shè)施,是移動(dòng)應(yīng)用區(qū)別于傳統(tǒng)應(yīng)用的一個(gè)重要特征和優(yōu)勢(shì),可以說,沒有消息推送的移動(dòng)應(yīng)用就不能稱之為移動(dòng)應(yīng)用。

2現(xiàn)有推送服務(wù)及問題

根據(jù)移動(dòng)操作系統(tǒng)的不同,當(dāng)前移動(dòng)領(lǐng)域主要分為兩個(gè)體系:蘋果公司的iOS系統(tǒng)和由谷歌公司主導(dǎo)的Andriod系統(tǒng)。這兩大陣營(yíng)都意識(shí)到了移動(dòng)消息推送在移動(dòng)應(yīng)用建設(shè)上的基礎(chǔ)性地位,并提供了相應(yīng)的推送服務(wù),供開發(fā)者或企業(yè)用戶調(diào)用。但是,無論是蘋果還是谷歌的推送服務(wù),都存在服務(wù)質(zhì)量,安全性,處理容量等問題,特別是對(duì)于企業(yè)、政府等高端用戶而言,這些推送服務(wù)都無法滿足實(shí)際需要。

2.1蘋果推送通知服務(wù)(APNS,Apple Push NotificationService)

蘋果為全球范圍的lOS設(shè)備提供推送通知服務(wù)。當(dāng)服務(wù)的提供方(Provider)希望給某個(gè)設(shè)備上的應(yīng)用推送消息時(shí),需要調(diào)用蘋果APNS提供的推送服務(wù),將目標(biāo)設(shè)備(設(shè)備令牌)和消息內(nèi)容(有效載荷)傳遞給APNS服務(wù),APNS會(huì)負(fù)責(zé)找到相應(yīng)的目標(biāo)設(shè)備,并將消息傳遞給該設(shè)備;該設(shè)備收到消息后,會(huì)將消息傳給相應(yīng)的應(yīng)用APP,由APP處理消息,提醒用戶。其處理過程在蘋果的開發(fā)者網(wǎng)站有詳細(xì)描述如圖1所示。

從實(shí)際使用情況看,APNS服務(wù)比較穩(wěn)定,一般情況下消息也能被及時(shí)傳遞,基本能夠滿足一般性消費(fèi)類移動(dòng)應(yīng)用的需要。但是,對(duì)于具有更高消息推送要求的企業(yè)級(jí)市場(chǎng),APNS就顯得力不從心,具有以下問題。

(1)不保證消息到達(dá)。如果移動(dòng)設(shè)備暫時(shí)無法聯(lián)網(wǎng),服務(wù)的提供方也可以推送消息,蘋果會(huì)負(fù)責(zé)暫時(shí)保存該消息;當(dāng)設(shè)備再次可用時(shí),保存的消息會(huì)被推送。但是,蘋果只會(huì)為同一個(gè)設(shè)備保留最近的一條消息。如果在設(shè)備持續(xù)無法聯(lián)網(wǎng)的情況下,服務(wù)提供方再次推送消息,會(huì)導(dǎo)致上一條推送消息的丟失,而且不會(huì)告知。這對(duì)于普通消費(fèi)型應(yīng)用問題不大,但對(duì)于企業(yè)級(jí)應(yīng)用則不然,特別是對(duì)于某些重要性很高,而且推送消息很頻繁的移動(dòng)應(yīng)用而言,隨意丟棄消息是不可接受的。

(2)不保證消息傳遞時(shí)效。APNS服務(wù)宣稱會(huì)盡快傳遞消息,但不保證多長(zhǎng)時(shí)間內(nèi)可以傳遞到,不能要求限時(shí)到達(dá)。而且,它沒有消息優(yōu)先級(jí)的設(shè)置,所有的消息都按照同樣的優(yōu)先級(jí)傳遞,不能對(duì)消息區(qū)別對(duì)待。

(3)消息大小有限制。如果移動(dòng)設(shè)備的操作系統(tǒng)不是最新的iOS 8,那么推送消息內(nèi)容不能超過256字節(jié),只能用來傳遞一些最簡(jiǎn)單的消息。企業(yè)級(jí)應(yīng)用中,這么小的數(shù)據(jù)量幾乎是無法使用的。如果將移動(dòng)設(shè)備升級(jí)到iOS 8,最大推送字節(jié)數(shù)會(huì)增加到2000字節(jié)。很多情況下,這一數(shù)值也無法滿足企業(yè)級(jí)移動(dòng)應(yīng)用的要求。

(4)發(fā)送頻率受控。蘋果官方對(duì)單位時(shí)間內(nèi)允許推送的消息數(shù)沒有限定,但在實(shí)際使用時(shí)發(fā)現(xiàn),如果與推送服務(wù)器建立的網(wǎng)絡(luò)連接數(shù)過多,或者推送消息的頻率過于密集,都會(huì)導(dǎo)致蘋果拒絕服務(wù),無法推送。

(5)不支持消息回執(zhí)。最終用戶有沒有收到消息?如果客戶端收到了,具體是什么時(shí)間點(diǎn)收到的?這種需求對(duì)于企業(yè)應(yīng)用很常見,但APNS并沒有提供類似的消息回執(zhí)機(jī)制。

(6)無法控制數(shù)據(jù)安全。雖然APNS提供了相應(yīng)的數(shù)據(jù)傳輸安全機(jī)制,確保在傳輸過程中的安全,但數(shù)據(jù)畢竟是經(jīng)過蘋果的服務(wù)器傳遞,而且,如果設(shè)備不在線,消息還會(huì)在蘋果的服務(wù)器上保存。這對(duì)于一些對(duì)數(shù)據(jù)敏感性有要求的組織或機(jī)構(gòu)而言是不允許的。某些要求嚴(yán)格的企業(yè),甚至?xí)笠苿?dòng)設(shè)備全部使用VPN專有網(wǎng)絡(luò),所有的互聯(lián)網(wǎng)服務(wù)都不允許訪問,這種情況TAPNS就更無法使用了。

2.2谷歌云推送(GcM,Google Cloud Messaging forAndroid)

與蘋果類似,谷歌也為Android設(shè)備提供了一個(gè)公共的消息推送服務(wù),其架構(gòu)如圖2所示。與APNS類似,第三方應(yīng)用需要推送消息時(shí),只需要連接到一個(gè)GCM服務(wù)器,調(diào)用消息推送服務(wù),就可以將消息傳遞到指定的移動(dòng)設(shè)備,并喚起相應(yīng)的移動(dòng)應(yīng)用。

谷歌云推送在功能上較APNS有不少增強(qiáng),支持包括消息回執(zhí)功能,send-to-sync消息機(jī)制等,其最大可推送的消息內(nèi)容也較蘋果的大,為4000字節(jié)。

但是,現(xiàn)實(shí)的情況是,由于網(wǎng)絡(luò)原因,谷歌的推送服務(wù)在國(guó)內(nèi)根本無法訪問,無法訪問谷歌的GCM服務(wù)器,谷歌的GCM服務(wù)器也無法與我們的移動(dòng)手機(jī)建立推送連接。而且,消息推送需要手機(jī)與服務(wù)器兩者的相互配合,手機(jī)端必須具備相應(yīng)的GCM接收服務(wù),才能接收到推送的消息,但由于Android手機(jī)廠商的分裂狀態(tài),幾乎每個(gè)手機(jī)廠商都會(huì)用自己的推送服務(wù)替代原有的GCM接收服務(wù),這就導(dǎo)致即使GcM月艮務(wù)器可以訪問,手機(jī)端也無法接收到消息。除非能全部限定所有的移動(dòng)設(shè)備為同一家供應(yīng)商,否則也無法使用手機(jī)廠商提供的推送服務(wù)。而現(xiàn)實(shí)中,幾乎不存在這種設(shè)備完全由同一個(gè)廠商供應(yīng)的可能性。

需要說明的是,基于谷歌一貫的開放策略,GCM也是一個(gè)開放性的標(biāo)準(zhǔn),任何人或企業(yè)都可以直接使用谷歌提供的推送云服務(wù),也可以自行根據(jù)GCM服務(wù)端的標(biāo)準(zhǔn)規(guī)范實(shí)現(xiàn)私有的GCM推送服務(wù)。不過,GCM在消息通訊協(xié)議上只有HTTP和XMPP兩種選擇,這兩種協(xié)議無論從傳輸效率,可靠性角度,還是從安全的角度看,都不是最適合移動(dòng)應(yīng)用的協(xié)議。

綜上所述,消息推送作為一個(gè)新的技術(shù)話題,在協(xié)議規(guī)范和技術(shù)標(biāo)準(zhǔn)方面都還沒有形成業(yè)界標(biāo)準(zhǔn),蘋果和谷歌作為業(yè)界領(lǐng)先的兩大企業(yè),雖然提供了針對(duì)各自平臺(tái)的推送服務(wù),但都存在不同程度的問題,特別是對(duì)于企業(yè)級(jí)高端用戶而言。

構(gòu)建消息推送服務(wù)是一個(gè)系統(tǒng)工程,需要進(jìn)行完備的架構(gòu)設(shè)計(jì)。這其中,推送協(xié)議的選擇至關(guān)重要,不同的協(xié)議會(huì)直接影響推送的速度,服務(wù)質(zhì)量和用戶滿意度。

3MQTT協(xié)議

消息隊(duì)列遙測(cè)傳輸(MQTT,Message QueuingTelemetry Transport)協(xié)議是IBM公司提出的開放協(xié)議,最初的設(shè)想是應(yīng)用于大量計(jì)算能力有限的傳感器等微型設(shè)備,其工作的網(wǎng)絡(luò)帶寬低且不穩(wěn)定,但又需要保證網(wǎng)絡(luò)節(jié)點(diǎn)之間的可靠通訊。

該協(xié)議目前已經(jīng)被結(jié)構(gòu)化信息標(biāo)準(zhǔn)促進(jìn)組織(OASIS)接受,并將其建議為物聯(lián)網(wǎng)消息傳遞協(xié)議的首選標(biāo)準(zhǔn)。MQTT已經(jīng)成為物聯(lián)網(wǎng)領(lǐng)域的事實(shí)標(biāo)準(zhǔn),IBM公司已經(jīng)成功將其應(yīng)用于智能實(shí)驗(yàn)室、遠(yuǎn)程醫(yī)療中心等項(xiàng)目,并推出了MessageSight等MQTT中間件產(chǎn)品,其它企業(yè)和機(jī)構(gòu)也相繼跟進(jìn),發(fā)布支持MOTT協(xié)議的開源/商業(yè)產(chǎn)品,或采用MQTT協(xié)議構(gòu)建相關(guān)應(yīng)用。伴隨著物聯(lián)網(wǎng)的迅猛發(fā)展,MQTT協(xié)議未來的發(fā)展不可限量。

由于物聯(lián)網(wǎng)傳感器等設(shè)備的計(jì)算能力和電量都非常有限,因此MQTT的設(shè)計(jì)理念從一開始就是簡(jiǎn)單,輕量,節(jié)省電力,這正好滿足了移動(dòng)應(yīng)用的一個(gè)重要訴求。當(dāng)前電池儲(chǔ)能技術(shù)的發(fā)展遠(yuǎn)遠(yuǎn)不能滿足智能手機(jī)的發(fā)展需要,使用智能手機(jī)用戶最痛苦的事情就是手機(jī)耗電太快,手機(jī)的電量甚至不能支持完8小時(shí)的工作時(shí)間。但如果要保證消息及時(shí)到達(dá),手機(jī)就必須時(shí)刻保持與服務(wù)器的連接,并定期與其通訊,檢查是否有新消息。MQTT協(xié)議非常精簡(jiǎn),額外的數(shù)據(jù)傳輸量非常小,可以在最大限度節(jié)省電力,同時(shí)也節(jié)省網(wǎng)絡(luò)流量。這是選擇MQTT構(gòu)建消息推送服務(wù)的最大原因。

MOTT協(xié)議的消息頭固定為2個(gè)字節(jié),當(dāng)前只使用了第一個(gè)字節(jié),第二個(gè)字節(jié)保留。第一個(gè)字節(jié)共8個(gè)bit位,前4位為控制類型,可取值為16種,按照功能可以分為連接類,訂閱類,保持活動(dòng)類幾種,后4位攜帶每種控制類型的特有信息如表1所示。

作為對(duì)比,讓我們來看看最常見的HTTP協(xié)議的消息頭,如圖3所示為訪問百度主頁(yè)(www.baidu.com)時(shí),HTTP請(qǐng)求所提交的消息頭信息,其數(shù)據(jù)量超過300字節(jié),是MQTT協(xié)議(2個(gè)字節(jié))的150倍。而且,這只是一個(gè)比較小的HTTP消息頭,如果用戶多次訪問同一網(wǎng)站,會(huì)有不斷增長(zhǎng)的Cookie信息,消息頭的內(nèi)容會(huì)更多。

為了實(shí)現(xiàn)及時(shí)推送,手機(jī)需要周期性給服務(wù)器發(fā)送請(qǐng)求(心跳),以保持與消息推送服務(wù)器的連接不中斷。假設(shè)手機(jī)每30秒發(fā)送一次心跳,每天就需要發(fā)送2880次,如果采用MQTT協(xié)議,只需5k的通訊流量,而如果采用HTTP方式,則需要的流量為864k,其高下一目了然。而手機(jī)需要消耗的電力與需要傳輸?shù)臄?shù)據(jù)量直接相關(guān)。

除了短小精悍,節(jié)約帶寬,節(jié)省電量消耗,MQTT協(xié)議還具有其它的特性,非常適合用于構(gòu)建移動(dòng)應(yīng)用的消息推送服務(wù)。

(1)保證服務(wù)質(zhì)量。MQTT提供三種消息傳輸?shù)姆?wù)質(zhì)量保障水平,用戶可以根據(jù)實(shí)際需要進(jìn)行選擇:

QoS0:至多傳遞一次。消息有可能會(huì)丟失。這種服務(wù)質(zhì)量下,消息傳遞的速度最快,但不能保證消息的可靠到達(dá)。通常適用于網(wǎng)絡(luò)環(huán)境差,而且不在意單次數(shù)據(jù)丟失的情況,例如GPS數(shù)據(jù)的采集。

QoS1:至少傳遞一次。可以確保消息被可靠傳遞到目標(biāo),但可能會(huì)有消息被重復(fù)傳遞。這種服務(wù)質(zhì)量權(quán)衡了傳輸效率和消息可靠性,最常被采用。

QoS2:確定只傳遞一次。消息不會(huì)被丟失,也不會(huì)被重復(fù)傳遞。這種服務(wù)質(zhì)量被用來保證最高的消息傳遞服務(wù)質(zhì)量。

(2)連接中斷通知。與物聯(lián)網(wǎng)類似,手機(jī)的網(wǎng)絡(luò)質(zhì)量遠(yuǎn)不能與連接網(wǎng)線的臺(tái)式機(jī)相比,當(dāng)我們發(fā)生位移時(shí),或者進(jìn)入電梯,地下室等區(qū)域時(shí),手機(jī)經(jīng)常會(huì)發(fā)生基站切換,網(wǎng)絡(luò)信號(hào)消失,連接中斷等情況。MQTT協(xié)議可以很好地適應(yīng)這種不穩(wěn)定的網(wǎng)絡(luò)環(huán)境,并且保證數(shù)據(jù)的可靠傳輸。而且,當(dāng)發(fā)生網(wǎng)絡(luò)異常中斷時(shí),MQTT還支持遺囑機(jī)制,將網(wǎng)絡(luò)中斷事件通知給指定的目標(biāo)對(duì)象。

(3)信息廣播機(jī)制。MQTT采用發(fā)布/訂閱機(jī)制來傳遞信息,多個(gè)手機(jī)終端可以訂閱同一個(gè)主題;服務(wù)端只需要針對(duì)主題發(fā)布信息,所有訂閱者都可以收到,而無需對(duì)逐個(gè)手機(jī)發(fā)送,簡(jiǎn)單高效。例如,股票價(jià)格信息,不同的人可以訂閱關(guān)注同一個(gè)股票的價(jià)格信息,當(dāng)該股票的價(jià)格發(fā)生變化時(shí),服務(wù)端只需發(fā)布一次最新價(jià)格,所有的訂閱者都會(huì)收到同樣消息。

4其它問題

在采用MQTT協(xié)議構(gòu)建移動(dòng)應(yīng)用的消息推送服務(wù)時(shí),也應(yīng)當(dāng)了解MQTT的不足,并妥善處理如下問題。

4.1避免客戶端越權(quán)訂閱

MQTT采用發(fā)布/訂閱模式處理消息傳遞,消息是針對(duì)主題傳遞,而不是目標(biāo)客戶端。客戶端只要進(jìn)行訂閱,就可以收到消息。理論上,如果某個(gè)客戶端訂閱了根主題,就可以收到所有人的消息,這是不可接受的。

可以啟用MQTT的用戶認(rèn)證機(jī)制,只有經(jīng)過認(rèn)證的用戶才可以訂閱主題,但這只能防止非認(rèn)證用戶的惡意訂閱,對(duì)于認(rèn)證通過的用戶則不起作用。

徹底的解決方法需要在服務(wù)端進(jìn)行控制,不允許用戶訂閱其沒有權(quán)限的主題。另外,一些MQTT產(chǎn)品對(duì)此也有處理,例如,IBM的MessageSight產(chǎn)品就支持點(diǎn)對(duì)點(diǎn)和發(fā)布/訂閱兩種方式,而使用點(diǎn)對(duì)點(diǎn)方式時(shí),任意訂閱都不起作用。

4.2處理iOS后臺(tái)服務(wù)運(yùn)行

ios系統(tǒng)對(duì)于后臺(tái)服務(wù)的長(zhǎng)時(shí)間運(yùn)行有很多限制,MQTT要求與服務(wù)端—直保持連接,在iOS系統(tǒng)下不容易做到。當(dāng)移動(dòng)APP在前臺(tái)運(yùn)行時(shí),MQTT可以建立并保持與推送服務(wù)器的連接,但是,一旦移動(dòng)APP被推入后臺(tái),所有的活動(dòng),包括連接都會(huì)被中斷。

iOS允許某些應(yīng)用在后臺(tái)保持運(yùn)行,但需要經(jīng)過蘋果的-審核,而且服務(wù)端還需要定期給移動(dòng)設(shè)備發(fā)送數(shù)據(jù)以保持網(wǎng)絡(luò)連接,相對(duì)而言較為繁瑣。

另4中解決方式是將MQTT推送與APNS相結(jié)合,當(dāng)MQTT連接被中斷時(shí),推送改為使用APNS通道。當(dāng)有新消息需要推送時(shí),推送服務(wù)器發(fā)送一個(gè)APNS的提示消息(沒有具體消息內(nèi)容),然后由APNS消息激活移動(dòng)應(yīng)用,喚起MQTT月艮務(wù),再通過MQTT渠道具體的推送消息內(nèi)容。這種方式只將APNS作為一個(gè)旁路提醒通道,不傳遞消息內(nèi)容,保證了數(shù)據(jù)的安全性。

4.3可擴(kuò)展的MQTT服務(wù)端

消息推送需要移動(dòng)設(shè)備與推送服務(wù)器保持長(zhǎng)連接,這與傳統(tǒng)應(yīng)用不同。傳統(tǒng)的B/s應(yīng)用是短連接模式,客戶端向服務(wù)端發(fā)起請(qǐng)求,服務(wù)端處理完成后返回結(jié)果給客戶端,然后釋放連接。如果不考慮業(yè)務(wù)邏輯處理對(duì)服務(wù)器資源的使用,單個(gè)服務(wù)器可以輕松支持幾十萬,甚至上百萬的用戶訪問。但是,如果拿一臺(tái)普通的服務(wù)器當(dāng)做消息推送服務(wù)器,單臺(tái)服務(wù)器的連接能力大約在2萬到10萬之間,如果要保證穩(wěn)定的服務(wù)能力,客戶端的連接數(shù)通常不允許超過5萬。IBM的MessageSight可以支持100萬的客戶端連接。但不論其數(shù)值多少,單臺(tái)服務(wù)器的處理能力總有極限。

如果要推送的設(shè)備數(shù)量超過了單臺(tái)的處理能力,就需要考慮服務(wù)端集群。MQTT在服務(wù)端的集群擴(kuò)展方面沒有規(guī)定,需要自行設(shè)計(jì)實(shí)現(xiàn)水平擴(kuò)展架構(gòu)。

主站蜘蛛池模板: 国产成人久久777777| 亚洲综合婷婷激情| 久久99精品久久久久纯品| 亚洲综合一区国产精品| 成年人国产网站| 久草国产在线观看| 久久永久精品免费视频| 国产婬乱a一级毛片多女| 久久综合九色综合97婷婷| 日韩精品成人在线| 婷婷午夜影院| 高清国产在线| 日韩高清欧美| 4虎影视国产在线观看精品| 欧美亚洲欧美| a天堂视频| 看看一级毛片| 女人爽到高潮免费视频大全| 区国产精品搜索视频| 丰满少妇αⅴ无码区| 在线无码九区| 国产在线欧美| 日韩精品毛片人妻AV不卡| 2020极品精品国产| 亚洲AⅤ永久无码精品毛片| 亚洲日本中文字幕天堂网| 色综合中文| 国产日韩av在线播放| 婷婷亚洲最大| 亚洲无码37.| 欧美α片免费观看| 97se亚洲综合在线天天| 六月婷婷精品视频在线观看 | 国产精品亚洲精品爽爽| 国产成人综合在线观看| 婷婷六月在线| 国产一区二区精品福利| 日本在线视频免费| 国产精品主播| 国产精欧美一区二区三区| 噜噜噜久久| aⅴ免费在线观看| 久久综合色88| 九九热在线视频| 免费毛片a| 久久久国产精品免费视频| 中文精品久久久久国产网址 | 久久亚洲综合伊人| 日本三级黄在线观看| 亚洲啪啪网| 亚洲精品国产首次亮相| 中文字幕 91| 欧美日本激情| 国产成人亚洲精品色欲AV| 五月婷婷综合在线视频| 看看一级毛片| 四虎亚洲精品| 天天做天天爱天天爽综合区| 国产丝袜91| 2021天堂在线亚洲精品专区| 日本一区二区三区精品AⅤ| 美女一级毛片无遮挡内谢| 久久天天躁狠狠躁夜夜躁| 91年精品国产福利线观看久久 | 香蕉网久久| 久久精品视频亚洲| 26uuu国产精品视频| 麻豆精品视频在线原创| 国产在线小视频| 亚洲av无码专区久久蜜芽| 日本久久网站| 无码高清专区| 五月天婷婷网亚洲综合在线| 尤物特级无码毛片免费| 超薄丝袜足j国产在线视频| 久久公开视频| 亚洲无线观看| 久久永久免费人妻精品| 狠狠色噜噜狠狠狠狠色综合久| 一级片一区| 先锋资源久久| 亚洲综合天堂网|