作為一個(gè)程序員需要了解網(wǎng)絡(luò)方面的基礎(chǔ)有哪些

這篇文章主要講解了“作為一個(gè)程序員需要了解網(wǎng)絡(luò)方面的基礎(chǔ)有哪些”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“作為一個(gè)程序員需要了解網(wǎng)絡(luò)方面的基礎(chǔ)有哪些”吧！

成都創(chuàng)新互聯(lián)公司客戶(hù)idc服務(wù)中心，提供四川綿陽(yáng)服務(wù)器托管、成都服務(wù)器、成都主機(jī)托管、成都雙線服務(wù)器等業(yè)務(wù)的一站式服務(wù)。通過(guò)各地的服務(wù)中心，我們向成都用戶(hù)提供優(yōu)質(zhì)廉價(jià)的產(chǎn)品以及開(kāi)放、透明、穩(wěn)定、高性?xún)r(jià)比的服務(wù)，資深網(wǎng)絡(luò)工程師在機(jī)房提供7*24小時(shí)標(biāo)準(zhǔn)級(jí)技術(shù)保障。

面試過(guò)程中經(jīng)常會(huì)被問(wèn)到計(jì)算機(jī)網(wǎng)絡(luò)相關(guān)的知識(shí)，就打算寫(xiě)一篇博客不斷總結(jié)一些計(jì)算機(jī)網(wǎng)絡(luò)的基礎(chǔ)點(diǎn)以及面試中常問(wèn)的考點(diǎn)。如果文檔中存在錯(cuò)誤歡迎指出，有任何補(bǔ)充留言私信均可以，我會(huì)不定期的添加上去。話不多說(shuō)，直接進(jìn)入主題：

1.OSI網(wǎng)絡(luò)體系結(jié)構(gòu)和TCP/IP協(xié)議結(jié)構(gòu)

OSI網(wǎng)絡(luò)體系結(jié)構(gòu)分為七層：

從下到上分為：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話層、表示層、應(yīng)用層

TCP/IP協(xié)議結(jié)構(gòu)分為四層：

從下到上分為：網(wǎng)絡(luò)接口層、網(wǎng)際層、傳輸層、應(yīng)用層

網(wǎng)絡(luò)接口層對(duì)應(yīng)于OSI的物理層和數(shù)據(jù)鏈路層，應(yīng)用層對(duì)應(yīng)于OSI的會(huì)話層、表示層、應(yīng)用層。

2.HTTP和HTTPS協(xié)議

Http協(xié)議運(yùn)行在TCP之上，明文傳輸，客戶(hù)端與服務(wù)器端都無(wú)法驗(yàn)證對(duì)方的身份；Https是身披SSL(Secure Socket Layer)外殼的Http，運(yùn)行于SSL上，SSL運(yùn)行于TCP之上，是添加了加密和認(rèn)證機(jī)制的HTTP。二者之間存在如下不同：

端口不同：Http與Http使用不同的連接方式，用的端口也不一樣，前者是80，后者是443；

資源消耗：和HTTP通信相比，Https通信會(huì)由于加減密處理消耗更多的CPU和內(nèi)存資源；

開(kāi)銷(xiāo)：Https通信需要證書(shū)，而證書(shū)一般需要向認(rèn)證機(jī)構(gòu)購(gòu)買(mǎi)；

Https的加密機(jī)制是一種共享密鑰加密和公開(kāi)密鑰加密并用的混合加密機(jī)制。

HTTP協(xié)議格式

http請(qǐng)求協(xié)議部分?jǐn)?shù)據(jù)

GET /user HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9

<html>...

第一部分：請(qǐng)求行：請(qǐng)求類(lèi)型，資源路徑以及http版本（上述第一行）

第二部分：請(qǐng)求頭：緊接在請(qǐng)求行之后，用于說(shuō)明服務(wù)器需要使用的附加信息（第二到第八行）

第三部分：空行（請(qǐng)求頭和主體之間必須有換行）

第四部分：主體數(shù)據(jù)，可以添加任意數(shù)據(jù)

http響應(yīng)協(xié)議

HTTP/1.1 200
Content-Type：text/html

OK

第一部分：狀態(tài)行，http版本，狀態(tài)碼，狀態(tài)信息（第一行）

第二部分：響應(yīng)報(bào)文頭部，說(shuō)明服務(wù)器需要用到的附加信息（第二行）

第三部分：空行（第三行）

第四部分：響應(yīng)正文（第四行）

3.TCP協(xié)議和UDP協(xié)議

TCP是傳輸層協(xié)議，TCP提供了數(shù)據(jù)的可靠連接，通過(guò)面向連接、端到端和可靠的字節(jié)流服務(wù)。

UDP是傳輸層協(xié)議，UDP在數(shù)據(jù)傳輸前不會(huì)建立連接，不能保證數(shù)據(jù)連接的可靠性，傳輸速度快。

4.TCP協(xié)議的三次握手和四次揮手

作為一個(gè)程序員需要了解網(wǎng)絡(luò)方面的基礎(chǔ)有哪些四次揮手

第一次揮手：客戶(hù)端進(jìn)程發(fā)出連接釋放報(bào)文，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報(bào)文首部，F(xiàn)IN=1，其序列號(hào)為seq=u（等于前面已經(jīng)傳送過(guò)來(lái)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1），此時(shí)，客戶(hù)端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)。 TCP規(guī)定，F(xiàn)IN報(bào)文段即使不攜帶數(shù)據(jù)，也要消耗一個(gè)序號(hào)。

第二次揮手：服務(wù)器收到連接釋放報(bào)文，發(fā)出確認(rèn)報(bào)文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑?hào)seq=v，此時(shí)，服務(wù)端就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器通知高層的應(yīng)用進(jìn)程，客戶(hù)端向服務(wù)器的方向就釋放了，這時(shí)候處于半關(guān)閉狀態(tài)，即客戶(hù)端已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶(hù)端依然要接受。這個(gè)狀態(tài)還要持續(xù)一段時(shí)間，也就是整個(gè)CLOSE-WAIT狀態(tài)持續(xù)的時(shí)間。客戶(hù)端收到服務(wù)器的確認(rèn)請(qǐng)求后，此時(shí)，客戶(hù)端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器發(fā)送連接釋放報(bào)文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。

第三次揮手：服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶(hù)端發(fā)送連接釋放報(bào)文，F(xiàn)IN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時(shí)的序列號(hào)為seq=w，此時(shí)，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶(hù)端的確認(rèn)。

第四次揮手：客戶(hù)端收到服務(wù)器的連接釋放報(bào)文后，必須發(fā)出確認(rèn)，ACK=1，ack=w+1，而自己的序列號(hào)是seq=u+1，此時(shí)，客戶(hù)端就進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)。注意此時(shí)TCP連接還沒(méi)有釋放，必須經(jīng)過(guò)2??MSL（最長(zhǎng)報(bào)文段壽命）的時(shí)間后，當(dāng)客戶(hù)端撤銷(xiāo)相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)。服務(wù)器只要收到了客戶(hù)端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。同樣，撤銷(xiāo)TCB后，就結(jié)束了這次的TCP連接。可以看到，服務(wù)器結(jié)束TCP連接的時(shí)間要比客戶(hù)端早一些。

4.1 為什么連接的時(shí)候是三次握手，關(guān)閉的時(shí)候卻是4次揮手

因?yàn)楫?dāng)Server端收到Client端的SYN連接請(qǐng)求報(bào)文后，可以直接發(fā)送SYN+ACK報(bào)文。其中ACK報(bào)文是用來(lái)應(yīng)答的，SYN報(bào)文是用來(lái)同步的。但是關(guān)閉連接時(shí)，當(dāng)Server端收到FIN報(bào)文時(shí)，很可能并不會(huì)立即關(guān)閉SOCKET，所以只能先回復(fù)一個(gè)ACK報(bào)文，告訴Client端，"你發(fā)的FIN報(bào)文我收到了"。只有等到我Server端所有的報(bào)文都發(fā)送完了，我才能發(fā)送FIN報(bào)文，因此不能一起發(fā)送。故需要四步握手。

4.2為什么TIME_WAIT狀態(tài)需要經(jīng)過(guò)2MSL(最大報(bào)文段生存時(shí)間)才能返回到CLOSE狀態(tài)？

雖然按道理，四個(gè)報(bào)文都發(fā)送完畢，我們可以直接進(jìn)入CLOSE狀態(tài)了，但是我們必須假象網(wǎng)絡(luò)是不可靠的，有可能最后一個(gè)ACK丟失。所以TIME_WAIT狀態(tài)就是用來(lái)重發(fā)可能丟失的ACK報(bào)文。在Client發(fā)送出最后的ACK回復(fù)，但該ACK可能丟失。Server如果沒(méi)有收到ACK，將不斷重復(fù)發(fā)送FIN片段。所以Client不能立即關(guān)閉，它必須確認(rèn)Server接收到了該ACK。Client會(huì)在發(fā)送出ACK之后進(jìn)入到TIME_WAIT狀態(tài)。Client會(huì)設(shè)置一個(gè)計(jì)時(shí)器，等待2MSL的時(shí)間。如果在該時(shí)間內(nèi)再次收到FIN，那么Client會(huì)重發(fā)ACK并再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個(gè)片段在網(wǎng)絡(luò)中最大的存活時(shí)間，2MSL就是一個(gè)發(fā)送和一個(gè)回復(fù)所需的最大時(shí)間。如果直到2MSL，Client都沒(méi)有再次收到FIN，那么Client推斷ACK已經(jīng)被成功接收，則結(jié)束TCP連接。

4.3為什么要用三次握手而不是兩次或四次

3次握手完成兩個(gè)重要的功能，既要雙方做好發(fā)送數(shù)據(jù)的準(zhǔn)備工作(雙方都知道彼此已準(zhǔn)備好)，也要允許雙方就初始序列號(hào)進(jìn)行協(xié)商，這個(gè)序列號(hào)在握手過(guò)程中被發(fā)送和確認(rèn)。

現(xiàn)在把三次握手改成僅需要兩次握手，當(dāng)?shù)诙挝帐趾螅捶?wù)器發(fā)送給客戶(hù)端）的請(qǐng)求客戶(hù)端沒(méi)收到時(shí)，服務(wù)器會(huì)認(rèn)為已經(jīng)建立了連接，開(kāi)始發(fā)送數(shù)據(jù)，但是客戶(hù)端沒(méi)收到連接請(qǐng)求，會(huì)認(rèn)為連接未建立，繼續(xù)發(fā)送連接信息。這時(shí)就導(dǎo)致了死鎖。

至于為什么不改成四次，當(dāng)三次連接后，服務(wù)器和客戶(hù)機(jī)都能確定之前的通信情況，但是無(wú)法確認(rèn)之后的情況，可靠的通信協(xié)議是根本不存在的，因此再增加一次也是徒勞。

4.4 如果已經(jīng)建立了連接，但是客戶(hù)端突然出現(xiàn)故障了怎么辦？

TCP還設(shè)有一個(gè)?；钣?jì)時(shí)器，顯然，客戶(hù)端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費(fèi)資源。服務(wù)器每收到一次客戶(hù)端的請(qǐng)求后都會(huì)重新復(fù)位這個(gè)計(jì)時(shí)器，時(shí)間通常是設(shè)置為2小時(shí)，若兩小時(shí)還沒(méi)有收到客戶(hù)端的任何數(shù)據(jù)，服務(wù)器就會(huì)發(fā)送一個(gè)探測(cè)報(bào)文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個(gè)探測(cè)報(bào)文仍然沒(méi)反應(yīng)，服務(wù)器就認(rèn)為客戶(hù)端出了故障，接著就關(guān)閉連接。

5.常見(jiàn)的網(wǎng)絡(luò)協(xié)議有哪些？

網(wǎng)絡(luò)層

IP協(xié)議：網(wǎng)際協(xié)議

ICMP協(xié)議：Internet控制報(bào)文協(xié)議

ARP協(xié)議:地址解析協(xié)議

RARP協(xié)議：逆地址解析協(xié)議

傳輸層

UDP協(xié)議：用戶(hù)數(shù)據(jù)報(bào)協(xié)議

TCP協(xié)議：傳輸控制協(xié)議

應(yīng)用層

FTP：文件傳送協(xié)議

Telenet：遠(yuǎn)程登錄協(xié)議

DNS：域名解析協(xié)議

POP3：郵局協(xié)議

HTTP協(xié)議：超文本傳輸協(xié)議

SMTP：簡(jiǎn)單郵件傳送協(xié)議

SNMP：簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議

TFTP：簡(jiǎn)單文件傳送協(xié)議

6.常見(jiàn)的網(wǎng)絡(luò)攻擊方式？以及預(yù)防措施

6.1 DDoS

DDoS攻擊

DDoS全稱(chēng)Distributed Denial of Service，中文意思為“分布式拒絕服務(wù)”，就是利用大量合法的分布式服務(wù)器對(duì)目標(biāo)發(fā)送請(qǐng)求，從而導(dǎo)致正常合法用戶(hù)無(wú)法獲得服務(wù)。

常見(jiàn)的攻擊方式如TCP攻擊：

客戶(hù)端向服務(wù)端發(fā)送請(qǐng)求鏈接數(shù)據(jù)包

服務(wù)端向客戶(hù)端發(fā)送確認(rèn)數(shù)據(jù)包

客戶(hù)端不向服務(wù)端發(fā)送確認(rèn)數(shù)據(jù)包，服務(wù)器一直等待來(lái)自客戶(hù)端的確認(rèn)

DDoS預(yù)防

限制同時(shí)打開(kāi)SYN半鏈接的數(shù)目

縮短SYN半鏈接的Time out 時(shí)間

關(guān)閉不必要的服務(wù)

6.2 SQL注入

SQL注入

攻擊者不是將標(biāo)準(zhǔn)數(shù)據(jù)提交到文本框或其他數(shù)據(jù)輸入字段，而是輸入SQL語(yǔ)句來(lái)誘騙應(yīng)用程序顯示或操縱其數(shù)據(jù)。

SQL注入預(yù)防措施

不要使用動(dòng)態(tài)SQL

不要將敏感數(shù)據(jù)保留在純文本中。

限制數(shù)據(jù)庫(kù)權(quán)限和特權(quán)

避免直接向用戶(hù)顯示數(shù)據(jù)庫(kù)錯(cuò)誤

對(duì)訪問(wèn)數(shù)據(jù)庫(kù)的Web應(yīng)用程序使用Web應(yīng)用程序防火墻（WAF）

定期測(cè)試與數(shù)據(jù)庫(kù)交互的Web應(yīng)用程序

將數(shù)據(jù)庫(kù)更新為最新的可用修補(bǔ)程序

6.3 XSS攻擊

XSS 攻擊

XSS 攻擊，即跨站腳本攻擊（Cross Site Scripting），它是 web 程序中常見(jiàn)的漏洞。攻擊者破壞易受攻擊的網(wǎng)站或Web應(yīng)用程序并注入惡意代碼。當(dāng)頁(yè)面加載時(shí)，代碼在用戶(hù)的瀏覽器上執(zhí)行惡意腳本。

XSS預(yù)防

web 頁(yè)面用戶(hù)輸入的地方，對(duì)輸入的數(shù)據(jù)轉(zhuǎn)義、過(guò)濾處理。后臺(tái)輸出頁(yè)面的時(shí)候，也需要對(duì)輸出內(nèi)容進(jìn)行轉(zhuǎn)義、過(guò)濾處理（因?yàn)楣粽呖赡芡ㄟ^(guò)其他方式把惡意腳本寫(xiě)入數(shù)據(jù)庫(kù)）

前端對(duì) html 標(biāo)簽屬性、css 屬性賦值的地方進(jìn)行校驗(yàn)

6.4 CSRF攻擊

CSRF 攻擊

跨站請(qǐng)求偽造（英語(yǔ)：Cross-site request forgery），是一種挾制用戶(hù)在當(dāng)前已登錄的Web應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。

CSRF預(yù)防

檢查Referer字段

HTTP頭中有一個(gè)Referer字段，這個(gè)字段用以標(biāo)明請(qǐng)求來(lái)源于哪個(gè)地址。在處理敏感數(shù)據(jù)請(qǐng)求時(shí)，通常來(lái)說(shuō)，Referer字段應(yīng)和請(qǐng)求的地址位于同一域名下。以上文銀行操作為例，Referer字段地址通常應(yīng)該是轉(zhuǎn)賬按鈕所在的網(wǎng)頁(yè)地址，應(yīng)該也位于www.examplebank.com之下。而如果是CSRF攻擊傳來(lái)的請(qǐng)求，Referer字段會(huì)是包含惡意網(wǎng)址的地址，不會(huì)位于www.examplebank.com之下，這時(shí)候服務(wù)器就能識(shí)別出惡意的訪問(wèn)。

添加校驗(yàn)token

由于CSRF的本質(zhì)在于攻擊者欺騙用戶(hù)去訪問(wèn)自己設(shè)置的地址，所以如果要求在訪問(wèn)敏感數(shù)據(jù)請(qǐng)求時(shí)，要求用戶(hù)瀏覽器提供不保存在cookie中，并且攻擊者無(wú)法偽造的數(shù)據(jù)作為校驗(yàn)，那么攻擊者就無(wú)法再運(yùn)行CSRF攻擊。這種數(shù)據(jù)通常是窗體中的一個(gè)數(shù)據(jù)項(xiàng)。服務(wù)器將其生成并附加在窗體中，其內(nèi)容是一個(gè)偽隨機(jī)數(shù)。當(dāng)客戶(hù)端通過(guò)窗體提交請(qǐng)求時(shí)，這個(gè)偽隨機(jī)數(shù)也一并提交上去以供校驗(yàn)。正常的訪問(wèn)時(shí)，客戶(hù)端瀏覽器能夠正確得到并傳回這個(gè)偽隨機(jī)數(shù)，而通過(guò)CSRF傳來(lái)的欺騙性攻擊中，攻擊者無(wú)從事先得知這個(gè)偽隨機(jī)數(shù)的值，服務(wù)端就會(huì)因?yàn)樾ｒ?yàn)token的值為空或者錯(cuò)誤，拒絕這個(gè)可疑請(qǐng)求。

7.TCP協(xié)議的粘包問(wèn)題

TCP 是面向連接的，面向流的可靠協(xié)議；發(fā)送端為了將多個(gè)發(fā)往接收端的包，更有效的發(fā)到對(duì)方，使用了優(yōu)化方法（Nagle算法），將多次間隔較小且數(shù)據(jù)量小的數(shù)據(jù)，合并成一個(gè)大的數(shù)據(jù)塊，然后進(jìn)行封包。這樣，接收端，就難于分辨出來(lái)了，就會(huì)出現(xiàn)所謂的粘包問(wèn)題。

產(chǎn)生粘包的原因：

(1)發(fā)送端需要等緩沖區(qū)滿(mǎn)才發(fā)送出去，造成粘包（發(fā)送數(shù)據(jù)時(shí)間間隔很短，數(shù)據(jù)了很小，會(huì)合到一起，產(chǎn)生粘包）

(2)接收方不及時(shí)接收緩沖區(qū)的包，造成多個(gè)包接收（客戶(hù)端發(fā)送了一段數(shù)據(jù)，服務(wù)端只收了一小部分，服務(wù)端下次再收的時(shí)候還是從緩沖區(qū)拿上次遺留的數(shù)據(jù)，產(chǎn)生粘包）

粘包的解決方案：

（1）定長(zhǎng)發(fā)送

在進(jìn)行數(shù)據(jù)發(fā)送的時(shí)候采用固定長(zhǎng)度的設(shè)計(jì)，無(wú)論多大的數(shù)據(jù)包都分成固定的長(zhǎng)度進(jìn)行發(fā)送，這種方式的弊端在于，最后一個(gè)包的長(zhǎng)度往往會(huì)被填充為空格，接收方可能無(wú)法辨別無(wú)效部分。

（2）設(shè)置尾部的標(biāo)記

在一個(gè)包結(jié)束的位置增加一個(gè)特殊的標(biāo)記，當(dāng)接收方讀取到這個(gè)標(biāo)記后就說(shuō)明數(shù)據(jù)包讀取完畢，這種方式的弊端在于取什么樣的數(shù)據(jù)作為標(biāo)志位是一件很難找到恰當(dāng)答案的事情。

（3）在頭部增加標(biāo)記標(biāo)明數(shù)據(jù)包長(zhǎng)度

在頭部標(biāo)記一個(gè)長(zhǎng)度，讀取時(shí)先讀取這個(gè)長(zhǎng)度再接受數(shù)據(jù)，這樣就不用擔(dān)心數(shù)據(jù)包丟失的問(wèn)題。

感謝各位的閱讀，以上就是“作為一個(gè)程序員需要了解網(wǎng)絡(luò)方面的基礎(chǔ)有哪些”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)作為一個(gè)程序員需要了解網(wǎng)絡(luò)方面的基礎(chǔ)有哪些這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

分享題目：作為一個(gè)程序員需要了解網(wǎng)絡(luò)方面的基礎(chǔ)有哪些
瀏覽路徑：http://jinyejixie.com/article16/ipjegg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)公司、小程序開(kāi)發(fā)、企業(yè)建站、App設(shè)計(jì)、面包屑導(dǎo)航、響應(yīng)式網(wǎng)站

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容

成人午夜视频全免费观看高清-秋霞福利视频一区二区三区-国产精品久久久久电影小说-亚洲不卡区三一区三区一区