成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

全面了解HTTP和HTTPS(開發(fā)人員必備)

開發(fā) 前端
Http和Https屬于計(jì)算機(jī)網(wǎng)絡(luò)范疇,但作為開發(fā)人員,不管是后臺(tái)開發(fā)或是前臺(tái)開發(fā),都很有必要掌握它們。這篇文章主要是按照自己的思路來(lái)講解對(duì)Http和Https的理解。

序言

Http和Https屬于計(jì)算機(jī)網(wǎng)絡(luò)范疇,但作為開發(fā)人員,不管是后臺(tái)開發(fā)或是前臺(tái)開發(fā),都很有必要掌握它們。

在學(xué)習(xí)Http和Https的過程中,主要是參考了阮一峰老師的博客《阮一峰:HTTP 協(xié)議入門》,講的很全面,并且通俗易懂,有興趣的同學(xué)可以去學(xué)習(xí)學(xué)習(xí)。

這篇文章主要是按照自己的思路來(lái)講解對(duì)Http和Https的理解。文章將會(huì)從以下幾個(gè)方面介紹。

目錄樹:

  • 一、網(wǎng)絡(luò)層結(jié)構(gòu)
  • 二、Http協(xié)議
  • 三、Tcp三次握手
  • 四、Https協(xié)議/SSL協(xié)議
  • 五、SSL證書
  • 六、RSA加密和DH加密
  • 七、Http和Https對(duì)比

從目錄結(jié)構(gòu)可以看出,每個(gè)標(biāo)題展開來(lái)說都是一個(gè)很大的主題。但本文旨在讓各位同學(xué)對(duì)Http和Https相關(guān)知識(shí)有一個(gè)全面的認(rèn)知,不會(huì)太過深入探討各個(gè)主題,有興趣的同學(xué)可以進(jìn)行針對(duì)性研究。

一、網(wǎng)絡(luò)層結(jié)構(gòu)

網(wǎng)絡(luò)結(jié)構(gòu)有兩種主流的分層方式:OSI七層模型和TCP/IP四層模型。

OSI七層模型和TCP/IP四層模型

OSI是指Open System Interconnect,意為開放式系統(tǒng)互聯(lián)。

TCP/IP是指?jìng)鬏斂刂茀f(xié)議/網(wǎng)間協(xié)議,是目前世界上應(yīng)用最廣的協(xié)議。 

 

兩種模型區(qū)別

1、OSI采用七層模型,TCP/IP是四層模型

2、TCP/IP網(wǎng)絡(luò)接口層沒有真正的定義,只是概念性的描述。OSI把它分為2層,每一層功能詳盡。

3、在協(xié)議開發(fā)之前,就有了OSI模型,所以O(shè)SI模型具有共通性,而TCP/IP是基于協(xié)議建立的模型,不適用于非TCP/IP的網(wǎng)絡(luò)。

4、實(shí)際應(yīng)用中,OSI模型是理論上的模型,沒有成熟的產(chǎn)品;而TCP/IP已經(jīng)成為國(guó)際標(biāo)準(zhǔn)。

二、HTTP協(xié)議

Http是基于TCP/IP協(xié)議的應(yīng)用程序協(xié)議,不包括數(shù)據(jù)包的傳輸,主要規(guī)定了客戶端和服務(wù)器的通信格式,默認(rèn)使用80端口。

Http協(xié)議的發(fā)展歷史

1、1991年發(fā)布Http/0.9版本,只有Get命令,且服務(wù)端直返HTML格式字符串,服務(wù)器響應(yīng)完畢就關(guān)閉TCP連接。

2、1996年發(fā)布Http/1.0版本,優(yōu)點(diǎn):可以發(fā)送任何格式內(nèi)容,包括文字、圖像、視頻、二進(jìn)制。也豐富了命令Get,Post,Head。請(qǐng)求和響應(yīng)的格式加入頭信息。缺點(diǎn):每個(gè)TCP連接只能發(fā)送一個(gè)請(qǐng)求,而新建TCP連接的成本很高,導(dǎo)致Http/1.0新能很差。

3、1997發(fā)布Http/1.1版本,完善了Http協(xié)議,直至20年后的今天仍是最流行的版本。

優(yōu)點(diǎn):a. 引入持久連接,TCP默認(rèn)不關(guān)閉,可被多個(gè)請(qǐng)求復(fù)用,對(duì)于一個(gè)域名,多數(shù)瀏覽器允許同時(shí)建立6個(gè)持久連接。b. 引入管道機(jī)制,即在同一個(gè)TCP連接中,可以同時(shí)發(fā)送多個(gè)請(qǐng)求,不過服務(wù)器還是按順序響應(yīng)。c. 在頭部加入Content-Length字段,一個(gè)TCP可以同時(shí)傳送多個(gè)響應(yīng),所以就需要該字段來(lái)區(qū)分哪些內(nèi)容屬于哪個(gè)響應(yīng)。d. 分塊傳輸編碼,對(duì)于耗時(shí)的動(dòng)態(tài)操作,用流模式取代緩存模式,即產(chǎn)生一塊數(shù)據(jù),就發(fā)送一塊數(shù)據(jù)。e. 增加了許多命令,頭信息增加Host來(lái)指定服務(wù)器域名,可以訪問一臺(tái)服務(wù)器上的不同網(wǎng)站。

缺點(diǎn):TCP連接中的響應(yīng)有順序,服務(wù)器處理完一個(gè)回應(yīng)才能處理下一個(gè)回應(yīng),如果某個(gè)回應(yīng)特別慢,后面的請(qǐng)求就會(huì)排隊(duì)等著(對(duì)頭堵塞)。

4、2015年發(fā)布Http/2版本,它有幾個(gè)特性:二進(jìn)制協(xié)議、多工、數(shù)據(jù)流、頭信息壓縮、服務(wù)器推送。

Http請(qǐng)求和響應(yīng)格式

Request格式:

 

  1. GET /barite/account/stock/groups HTTP/1.1 
  2. QUARTZ-SESSION: MC4xMDQ0NjA3NTI0Mzc0MjAyNg.VPXuA8rxTghcZlRCfiAwZlAIdCA 
  3. DEVICE-TYPE: ANDROID 
  4. API-VERSION: 15 
  5. Host: shitouji.bluestonehk.com 
  6. Connection: Keep-Alive 
  7. Accept-Encoding: gzip 
  8. User-Agent: okhttp/3.10.0 

Response格式:

 

  1. HTTP/1.1 200 OK 
  2. Server: nginx/1.6.3 
  3. Date: Mon, 15 Oct 2018 03:30:28 GMT 
  4. Content-Type: application/json;charset=UTF-8 
  5. Pragma: no-cache 
  6. Cache-Control: no-cache 
  7. Expires: Thu, 01 Jan 1970 00:00:00 GMT 
  8. Content-Encoding: gzip 
  9. Transfer-Encoding: chunked 
  10. Proxy-Connection: Keep-alive 
  11.  
  12. {"errno":0,"dialogInfo":null,"body":{"list":[{"flag":2,"group_id":1557,"group_name":"港股","count":1},{"flag":3,"group_id":1558,"group_name":"美股","count":7},{"flag":1,"group_id":1556,"group_name":"全部","count":8}]},"message":"success"

說明一下請(qǐng)求頭和響應(yīng)頭的部分字段:

  • Host:指定服務(wù)器域名,可用來(lái)區(qū)分訪問一個(gè)服務(wù)器上的不同服務(wù)
  • Connection:keep-alive表示要求服務(wù)器不要關(guān)閉TCP連接,close表示明確要求關(guān)閉連接,默認(rèn)值是keep-alive
  • Accept-Encoding:說明自己可以接收的壓縮方式
  • User-Agent:用戶代理,是服務(wù)器能識(shí)別客戶端的操作系統(tǒng)(Android、IOS、WEB)及相關(guān)的信息。作用是幫助服務(wù)器區(qū)分客戶端,并且針對(duì)不同客戶端讓用戶看到不同數(shù)據(jù),做不同操作。
  • Content-Type:服務(wù)器告訴客戶端數(shù)據(jù)的格式,常見的值有text/plain,image/jpeg,image/png,video/mp4,application/json,application/zip。這些數(shù)據(jù)類型總稱為MIME TYPE。
  • Content-Encoding:服務(wù)器數(shù)據(jù)壓縮方式
  • Transfer-Encoding:chunked表示采用分塊傳輸編碼,有該字段則無(wú)需使用Content-Length字段。
  • Content-Length:聲明數(shù)據(jù)的長(zhǎng)度,請(qǐng)求和回應(yīng)頭部都可以使用該字段。

三、Tcp三次握手

Http和Https協(xié)議請(qǐng)求時(shí)都會(huì)通過Tcp三次握手建立Tcp連接。

那么,三次握手是指什么呢?

 

 

那么,為什么一定要三次握手呢,一次可以嗎?兩次可以嗎?

帶著這些問題,我們來(lái)分析一下為什么必須是三次握手。

1、第一次握手,A向B發(fā)送信息后,B收到信息。B可確認(rèn)A的發(fā)信能力和B的收信能力

2、第二次握手,B向A發(fā)消息,A收到消息。A可確認(rèn)A的發(fā)信能力和收信能力,A也可確認(rèn)B的收信能力和發(fā)信能力

3、第三次握手,A向B發(fā)送消息,B接收到消息。B可確認(rèn)A的收信能力和B的發(fā)信能力

通過三次握手,A和B都能確認(rèn)自己和對(duì)方的收發(fā)信能力,相當(dāng)于建立了互相的信任,就可以開始通信了。

下面,我們介紹一下三次握手具體發(fā)送的內(nèi)容,用一張圖描述如下:

 

 

首先,介紹一下幾個(gè)概念:

  • ACK:響應(yīng)標(biāo)識(shí),1表示響應(yīng),連接建立成功之后,所有報(bào)文段ACK的值都為1
  • SYN:連接標(biāo)識(shí),1表示建立連接,連接請(qǐng)求和連接接受報(bào)文段SYN=1,其他情況都是0
  • FIN:關(guān)閉連接標(biāo)識(shí),1標(biāo)識(shí)關(guān)閉連接,關(guān)閉請(qǐng)求和關(guān)閉接受報(bào)文段FIN=1,其他情況都是0,跟SYN類似
  • seq number:序號(hào),一個(gè)隨機(jī)數(shù)X,請(qǐng)求報(bào)文段中會(huì)有該字段,響應(yīng)報(bào)文段沒有
  • ack number:應(yīng)答號(hào),值為請(qǐng)求seq+1,即X+1,除了連接請(qǐng)求和連接接受響應(yīng)報(bào)文段沒有該字段,其他的報(bào)文段都有該字段

知道了上面幾個(gè)概念后,看一下三次握手的具體流程:

1、第一次握手:建立連接請(qǐng)求??蛻舳税l(fā)送連接請(qǐng)求報(bào)文段,將SYN置為1,seq為隨機(jī)數(shù)x。然后,客戶端進(jìn)入SYN_SEND狀態(tài),等待服務(wù)器確認(rèn)。

2、第二次握手:確認(rèn)連接請(qǐng)求。服務(wù)器收到客戶端的SYN報(bào)文段,需要對(duì)該請(qǐng)求進(jìn)行確認(rèn),設(shè)置ack=x+1(即客戶端seq+1)。同時(shí)自己也要發(fā)送SYN請(qǐng)求信息,即SYN置為1,seq=y。服務(wù)器將SYN和ACK信息放在一個(gè)報(bào)文段中,一并發(fā)送給客戶端,服務(wù)器進(jìn)入SYN_RECV狀態(tài)。

3、第三次握手:客戶端收到SYN+ACK報(bào)文段,將ack設(shè)置為y+1,向服務(wù)器發(fā)送ACK報(bào)文段,這個(gè)報(bào)文段發(fā)送完畢,客戶端和服務(wù)券進(jìn)入ESTABLISHED狀態(tài),完成Tcp三次握手。

從圖中可以看出,建立連接經(jīng)歷了三次握手,當(dāng)數(shù)據(jù)傳輸完畢,需要斷開連接,而斷開連接經(jīng)歷了四次揮手:

1、第一次揮手:主機(jī)1(可以是客戶端或服務(wù)器),設(shè)置seq和ack向主機(jī)2發(fā)送一個(gè)FIN報(bào)文段,此時(shí)主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài),表示沒有數(shù)據(jù)要發(fā)送給主機(jī)2了

2、第二次揮手:主機(jī)2收到主機(jī)1的FIN報(bào)文段,向主機(jī)1回應(yīng)一個(gè)ACK報(bào)文段,表示同意關(guān)閉請(qǐng)求,主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)。

3、第三次揮手:主機(jī)2向主機(jī)1發(fā)送FIN報(bào)文段,請(qǐng)求關(guān)閉連接,主機(jī)2進(jìn)入LAST_ACK狀態(tài)。

4、第四次揮手:主機(jī)1收到主機(jī)2的FIN報(bào)文段,想主機(jī)2回應(yīng)ACK報(bào)文段,然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài);主機(jī)2收到主機(jī)1的ACK報(bào)文段后,關(guān)閉連接。此時(shí)主機(jī)1等待主機(jī)2一段時(shí)間后,沒有收到回復(fù),證明主機(jī)2已經(jīng)正常關(guān)閉,主機(jī)1頁(yè)關(guān)閉連接。

下面是Tcp報(bào)文段首部格式圖,對(duì)于理解Tcp協(xié)議很重要:

 

 

四、Https協(xié)議/SSL協(xié)議

Https協(xié)議是以安全為目標(biāo)的Http通道,簡(jiǎn)單來(lái)說就是Http的安全版。主要是在Http下加入SSL層(現(xiàn)在主流的是SLL/TLS),SSL是Https協(xié)議的安全基礎(chǔ)。Https默認(rèn)端口號(hào)為443。

前面介紹了Http協(xié)議,各位同學(xué)能說出Http存在的風(fēng)險(xiǎn)嗎?

1、竊聽風(fēng)險(xiǎn):Http采用明文傳輸數(shù)據(jù),第三方可以獲知通信內(nèi)容

2、篡改風(fēng)險(xiǎn):第三方可以修改通信內(nèi)容

3、冒充風(fēng)險(xiǎn):第三方可以冒充他人身份進(jìn)行通信

SSL/TLS協(xié)議就是為了解決這些風(fēng)險(xiǎn)而設(shè)計(jì),希望達(dá)到:

1、所有信息加密傳輸,三方竊聽通信內(nèi)容

2、具有校驗(yàn)機(jī)制,內(nèi)容一旦被篡改,通信雙發(fā)立刻會(huì)發(fā)現(xiàn)

3、配備身份證書,防止身份被冒充

下面主要介紹SSL/TLS協(xié)議。

SSL發(fā)展史(互聯(lián)網(wǎng)加密通信)

1、1994年NetSpace公司設(shè)計(jì)SSL協(xié)議(Secure Sockets Layout)1.0版本,但未發(fā)布。

2、1995年NetSpace發(fā)布SSL/2.0版本,很快發(fā)現(xiàn)有嚴(yán)重漏洞

3、1996年發(fā)布SSL/3.0版本,得到大規(guī)模應(yīng)用

4、1999年,發(fā)布了SSL升級(jí)版TLS/1.0版本,目前應(yīng)用最廣泛的版本

5、2006年和2008年,發(fā)布了TLS/1.1版本和TLS/1.2版本

SSL原理及運(yùn)行過程

SSL/TLS協(xié)議基本思路是采用公鑰加密法(最有名的是RSA加密算法)。大概流程是,客戶端向服務(wù)器索要公鑰,然后用公鑰加密信息,服務(wù)器收到密文,用自己的私鑰解密。

為了防止公鑰被篡改,把公鑰放在數(shù)字證書中,證書可信則公鑰可信。公鑰加密計(jì)算量很大,為了提高效率,服務(wù)端和客戶端都生成對(duì)話秘鑰,用它加密信息,而對(duì)話秘鑰是對(duì)稱加密,速度非??臁6€用來(lái)機(jī)密對(duì)話秘鑰。

下面用一張圖表示SSL加密傳輸過程:

 

 

詳細(xì)介紹一下圖中過程:

1、客戶端給出協(xié)議版本號(hào)、一個(gè)客戶端隨機(jī)數(shù)A(Client random)以及客戶端支持的加密方式

2、服務(wù)端確認(rèn)雙方使用的加密方式,并給出數(shù)字證書、一個(gè)服務(wù)器生成的隨機(jī)數(shù)B(Server random)

3、客戶端確認(rèn)數(shù)字證書有效,生成一個(gè)新的隨機(jī)數(shù)C(Pre-master-secret),使用證書中的公鑰對(duì)C加密,發(fā)送給服務(wù)端

4、服務(wù)端使用自己的私鑰解密出C

5、客戶端和服務(wù)器根據(jù)約定的加密方法,使用三個(gè)隨機(jī)數(shù)ABC,生成對(duì)話秘鑰,之后的通信都用這個(gè)對(duì)話秘鑰進(jìn)行加密。

SSL證書

上面提到了,Https協(xié)議中需要使用到SSL證書。

SSL證書是一個(gè)二進(jìn)制文件,里面包含經(jīng)過認(rèn)證的網(wǎng)站公鑰和一些元數(shù)據(jù),需要從經(jīng)銷商購(gòu)買。

證書有很多類型,按認(rèn)證級(jí)別分類:

  • 域名認(rèn)證(DV=Domain Validation):最低級(jí)別的認(rèn)證,可以確認(rèn)申請(qǐng)人擁有這個(gè)域名
  • 公司認(rèn)證(OV=Organization Validation):確認(rèn)域名所有人是哪家公司,證書里面包含公司的信息
  • 擴(kuò)展認(rèn)證(EV=Extended Validation):最高級(jí)別認(rèn)證,瀏覽器地址欄會(huì)顯示公司名稱。

EV證書瀏覽器地址欄樣式:

 

 

OV證書瀏覽器地址欄樣式:

 

 

DV證書瀏覽器樣式:

 

 

按覆蓋范圍分類:

  • 單域名證書:只能用于單域名,foo.com證書不能用不www.foo.com
  • 通配符證書:可用于某個(gè)域名及所有一級(jí)子域名,比如*.foo.com的證書可用于foo.com,也可用于www.foo.com
  • 多域名證書:可用于多個(gè)域名,比如foo.com和bar.com

認(rèn)證級(jí)別越高,覆蓋范圍越廣的證書,價(jià)格越貴。也有免費(fèi)的證書,為了推廣Https,電子前哨基金會(huì)成立了Let's Encrypt提供免費(fèi)證書。

https://letsencrypt.org/

證書的經(jīng)銷商也很多,知名度比較高的有亞洲誠(chéng)信(Trust Asia)。

五、RSA加密和DH加密

加密算法分類

加密算法分為對(duì)稱加密、非對(duì)稱加密和Hash加密算法。

  • 對(duì)稱加密:甲方和乙方使用同一種加密規(guī)則對(duì)信息加解密
  • 非對(duì)稱加密:乙方生成兩把秘鑰(公鑰和私鑰)。公鑰是公開的,任何人都可以獲取,私鑰是保密的,只存在于乙方手中。甲方獲取公鑰,然后用公鑰加密信息,乙方得到密文后,用私鑰解密。
  • Hash加密:Hash算法是一種單向密碼體制,即只有加密過程,沒有解密過程

對(duì)稱加密算法加解密效率高,速度快,適合大數(shù)據(jù)量加解密。常見的堆成加密算法有DES、AES、RC5、Blowfish、IDEA

非對(duì)稱加密算法復(fù)雜,加解密速度慢,但安全性高,一般與對(duì)稱加密結(jié)合使用(對(duì)稱加密通信內(nèi)容,非對(duì)稱加密對(duì)稱秘鑰)。

常見的非對(duì)稱加密算法有RSA、DH、DSA、ECC

Hash算法特性是:輸入值一樣,經(jīng)過哈希函數(shù)得到相同的散列值,但并非散列值相同則輸入值也相同。常見的Hash加密算法有MD5、SHA-1、SHA-X系列

下面著重介紹一下RSA算法和DH算法。

RSA加密算法

Https協(xié)議就是使用RSA加密算法,可以說RSA加密算法是宇宙中最重要的加密算法。

RSA算法用到一些數(shù)論知識(shí),包括互質(zhì)關(guān)系,歐拉函數(shù),歐拉定理。此處不具體介紹加密的過程,如果有興趣,可以參照RSA算法加密過程。

http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html

RSA算法的安全保障基于大數(shù)分解問題,目前破解過的最大秘鑰是700+位,也就代表1024位秘鑰和2048位秘鑰可以認(rèn)為絕對(duì)安全。

大數(shù)分解主要難點(diǎn)在于計(jì)算能力,如果未來(lái)計(jì)算能力有了質(zhì)的提升,那么這些秘鑰也是有可能被破解的。

DH加密算法

DH也是一種非對(duì)稱加密算法,DH加密算法過程。

https://zh.wikipedia.org/wiki/%E8%BF%AA%E8%8F%B2-%E8%B5%AB%E7%88%BE%E6%9B%BC%E5%AF%86%E9%91%B0%E4%BA%A4%E6%8F%9B

DH算法的安全保障是基于離散對(duì)數(shù)問題。

六、Http協(xié)議和Https協(xié)議的對(duì)比

Http和Https的區(qū)別如下:

1、https協(xié)議需要到CA申請(qǐng)證書,大多數(shù)情況下需要一定費(fèi)用

2、Http是超文本傳輸協(xié)議,信息采用明文傳輸,Https則是具有安全性SSL加密傳輸協(xié)議

3、Http和Https端口號(hào)不一樣,Http是80端口,Https是443端口

4、Http連接是無(wú)狀態(tài)的,而Https采用Http+SSL構(gòu)建可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議,更安全。

5、Http協(xié)議建立連接的過程比Https協(xié)議快。因?yàn)镠ttps除了Tcp三次握手,還要經(jīng)過SSL握手。連接建立之后數(shù)據(jù)傳輸速度,二者無(wú)明顯區(qū)別。

總結(jié)

經(jīng)過了3天的學(xué)習(xí)和總結(jié),總算完成了這篇文章,本文可以幫助讀者大體上把握Http和Https的知識(shí)框架。 
責(zé)任編輯:龐桂玉 來(lái)源: Web開發(fā)
相關(guān)推薦

2009-04-03 10:00:56

2023-02-06 18:27:00

開發(fā)人員語(yǔ)言

2012-06-28 09:56:36

設(shè)計(jì)交互設(shè)計(jì)

2020-10-14 09:45:29

Web開發(fā)瀏覽器

2022-07-15 15:22:51

區(qū)塊鏈開發(fā)語(yǔ)言

2018-11-21 12:21:33

Ruby框架Web應(yīng)用

2024-06-13 10:08:51

2020-08-30 14:30:33

macOS工具開發(fā)Mac

2020-04-07 17:13:15

開發(fā)工具技術(shù)

2015-02-10 09:24:04

Web開發(fā)JavaScript工具

2012-05-30 15:15:42

ibmdw

2023-03-15 07:12:53

企業(yè)開發(fā)人員提供商

2012-06-28 10:48:31

設(shè)計(jì)交互設(shè)計(jì)

2020-04-20 17:46:41

GitHub開發(fā)庫(kù)

2009-11-23 20:07:51

ibmdw開發(fā)

2021-02-19 09:33:01

kubernetesJAVA服務(wù)

2009-12-11 14:50:14

Visual Basi

2012-05-17 10:03:25

.NET

2019-07-02 14:27:31

編程語(yǔ)言開發(fā)

2015-04-14 09:38:35

軟件開發(fā)人員便利工具
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)

主站蜘蛛池模板: 中文字幕不卡在线观看 | 九九看片 | 精品视频久久久久久 | 欧美日韩电影免费观看 | 欧美一区二区三区 | 一区二区三区视频在线 | 成人黄色av网址 | 四虎影视一区二区 | 中文在线一区二区 | 伊人超碰| 九九热精| 美女视频黄的 | 黄视频欧美 | a级毛片免费高清视频 | 在线欧美一区 | 免费看黄色片 | 中文字幕第一页在线 | 成人欧美一区二区三区视频xxx | 亚洲一区二区三区在线免费 | 97av在线| 国产精品美女www爽爽爽视频 | 自拍偷拍亚洲一区 | 激情毛片 | 国产美女在线免费观看 | 黄网站在线播放 | 激情一区二区三区 | 国产999精品久久久久久 | 国产xxx在线观看 | 成人国产一区二区三区精品麻豆 | 91精品国产91久久综合桃花 | 九九热免费观看 | 久久国产精品一区二区三区 | 精品久久久久一区二区国产 | 精品久久久久久亚洲综合网站 | 奇米超碰 | 精品一区二区三区免费视频 | av色在线| 黄色av一区| 久久久精品一区二区 | 99热最新网址 | 97精品国产97久久久久久免费 |