一、UDP協(xié)議

UDP在前面套接字編程介紹了特點(diǎn)是：

無(wú)連接、不可靠傳輸、面向數(shù)據(jù)報(bào)、全雙工。

UDP協(xié)議格式：

• 16位UDP?度，表?整個(gè)數(shù)據(jù)報(bào) (UDP?部+UDP數(shù)據(jù)) 的最??度，0 - 65535，也就64KB;
• 16位UDP校驗(yàn)和：如果校驗(yàn)和出錯(cuò)，就會(huì)直接丟棄;

校驗(yàn)和的作用：

• 防止傳輸過(guò)程出現(xiàn)比特翻轉(zhuǎn)（比特翻轉(zhuǎn)就是指：數(shù)據(jù)受到外界干擾，0變1,1變0）

發(fā)送之前，先計(jì)算一個(gè)校驗(yàn)和，把真?zhèn)€數(shù)據(jù)報(bào)的數(shù)據(jù)都代入
把數(shù)據(jù) 和 校驗(yàn)和 一起發(fā)送給對(duì)端
接收方收到之后重新計(jì)算一下校驗(yàn)和，和收到的校驗(yàn)和進(jìn)行對(duì)比(UDP發(fā)現(xiàn)校驗(yàn)和不一致，就會(huì)直接丟棄)
UDP的校驗(yàn)和使用了CRC方式來(lái)進(jìn)行校驗(yàn)（循環(huán)冗余校驗(yàn)）
把每個(gè)字節(jié)（除了校驗(yàn)和位置的部分之外），都當(dāng)做整數(shù)進(jìn)行累加.溢出也沒關(guān)系，繼續(xù)加
最終得到結(jié)果CRC校驗(yàn)和
傳輸?shù)綄?duì)端時(shí)，數(shù)據(jù)如果出現(xiàn)錯(cuò)誤了，對(duì)端再次計(jì)算的校驗(yàn)和，就會(huì)和第一個(gè)校驗(yàn)和不一樣了
校驗(yàn)和相同，原始數(shù)據(jù)可能相同（原始數(shù)據(jù)不同發(fā)生的概率非常?。?。
校驗(yàn)和不同，原始數(shù)據(jù)一定不同。

這樣的機(jī)制雖然也有錯(cuò)，因?yàn)橐粋€(gè)數(shù)據(jù)和對(duì)應(yīng)的數(shù)據(jù)不是唯一的，但是這種是小概率事件。

二、TCP協(xié)議

2.1 TCP結(jié)構(gòu)

TCP在前面套接字編程介紹了特點(diǎn)是：

有連接、可靠傳輸、面向字節(jié)流、全雙工。

TCP格式：

• 4位首部長(zhǎng)度：表?該TCP頭部有多少個(gè)32位bit (有多少個(gè)4字節(jié))；所以TCP頭部最??度是15 * 4 = 60 字節(jié)
• 選項(xiàng)：選項(xiàng)就是確定TCP長(zhǎng)度是可變的，固定長(zhǎng)度是20字節(jié)，選項(xiàng)最多增加40字節(jié)
• 保留位：UDP長(zhǎng)度不夠時(shí)，不能擴(kuò)展，而保留位就是TCP預(yù)留解決這種問(wèn)題的。
• 6個(gè)標(biāo)志位：
• • URG：緊急指針（相當(dāng)于“插隊(duì)”，跳過(guò)前面數(shù)據(jù)，從指定序號(hào)開始）是否有效
• • ACK：確認(rèn)號(hào)是否有效
• • PSH：催促標(biāo)志位，提?接收端應(yīng)?程序?刻從TCP緩沖區(qū)把數(shù)據(jù)讀?
• • PST：對(duì)?要求重新建?連接；我們把攜帶RST標(biāo)識(shí)的稱為復(fù)位報(bào)?段
• • SYN：請(qǐng)求建?連接；我們把攜帶SYN標(biāo)識(shí)的稱為同步報(bào)?段
• • FIN：通知對(duì)?,本端要關(guān)閉了，我們稱攜帶FIN標(biāo)識(shí)的為結(jié)束報(bào)?段
• 16位校驗(yàn)和：校驗(yàn)數(shù)據(jù)是否出現(xiàn)錯(cuò)誤
• 16位緊急指針：標(biāo)識(shí)哪部分?jǐn)?shù)據(jù)是緊急數(shù)據(jù)

2.2 TCP十大核心機(jī)制

2.2.1 確認(rèn)應(yīng)答

保證可靠性：那就肯定需要，發(fā)送放知道接收方是否接收到請(qǐng)求，接收方返回一個(gè)“應(yīng)答報(bào)文（acknowledge ，ack）”

如果有這種情況：后發(fā)先至

網(wǎng)上做題是答案是對(duì)應(yīng)題目的，但是如果你先寫的第一題答案，后寫的第二題答案，由于傳輸問(wèn)題，導(dǎo)致第二題答案先到。那么如果沒有題號(hào)對(duì)應(yīng)的話，那么就可能填在第一題去了。所以TCP也引入的類似題號(hào)作用的東西：序列號(hào)

TCP將每個(gè)字節(jié)的數(shù)據(jù)都進(jìn)?了編號(hào)。即為序列號(hào)。

每?個(gè)ACK都帶有對(duì)應(yīng)的確認(rèn)序列號(hào)，意思是告訴發(fā)送者，該確認(rèn)序號(hào)前的數(shù)據(jù)都已經(jīng)收到；下?次你從哪?開始發(fā)。

2.2.2 超時(shí)重傳

超時(shí)重傳是為了應(yīng)對(duì)丟包問(wèn)題。

丟包：數(shù)據(jù)無(wú)法到達(dá)指定位置。

丟包兩個(gè)原因：假如主機(jī)A發(fā)送數(shù)據(jù)給主機(jī)B

1. 主機(jī)A發(fā)送的數(shù)據(jù)，由于各種原因，沒能到達(dá)主機(jī)B，造成丟包
2. 主句B返回的應(yīng)答數(shù)據(jù)，由于各種原因，沒能到達(dá)主機(jī)A，造成丟包

TCP就引入超時(shí)時(shí)間（TCP中判定超時(shí)的時(shí)間閾值，不是固定值，動(dòng)態(tài)變化），來(lái)應(yīng)對(duì)丟包情況，
當(dāng)超出超時(shí)時(shí)間，還沒有接收到應(yīng)答報(bào)文，那么就是出現(xiàn)丟包（無(wú)論哪種原因造成），那么都會(huì)重新發(fā)送這條數(shù)據(jù)。

超時(shí)時(shí)間的動(dòng)態(tài)變化機(jī)制：

TCP為了保證?論在任何環(huán)境下都能?較?性能的通信，因此會(huì)動(dòng)態(tài)計(jì)算這個(gè)最?超時(shí)時(shí)間。

• Linux中(BSD Unix和Windows也是如此),超時(shí)以500ms為?個(gè)單位進(jìn)?控制, 每次判定超時(shí)重發(fā)的
  超時(shí)時(shí)間都是500ms的整數(shù)倍.
• 如果重發(fā)?次之后, 仍然得不到應(yīng)答, 等待 2*500ms 后再進(jìn)?重傳.
• 如果仍然得不到應(yīng)答, 等待 4*500ms 進(jìn)?重傳. 依次類推, 以指數(shù)形式遞增.
• 累計(jì)到?定的重傳次數(shù), TCP認(rèn)為?絡(luò)或者對(duì)端主機(jī)出現(xiàn)異常, 強(qiáng)制關(guān)閉連接.

確認(rèn)應(yīng)答和超時(shí)重傳是確認(rèn)TCP可靠傳輸?shù)淖詈诵臋C(jī)制。

2.2.3 連接管理

TCP中連接是邏輯上的連接，都保留對(duì)端的信息，不是物理上的連接。

兩個(gè)主機(jī)間的連接管理，TCP通過(guò)三次握手機(jī)制建立連接，四次揮手?jǐn)嚅_連接。

2.2.3.1 三次握手建立連接

過(guò)程簡(jiǎn)述：主機(jī)A與主機(jī)B通信

1. 主機(jī)A先發(fā)一個(gè)狀態(tài)碼為syn的報(bào)文給主機(jī)B（相當(dāng)于我給你打電話，你接通后，我先說(shuō)一個(gè)喂）
2. 主機(jī)B接收到主機(jī)A發(fā)的報(bào)文后，也要發(fā)一個(gè)狀態(tài)碼為ack的應(yīng)答報(bào)文，還要發(fā)送一個(gè)syn報(bào)文，這兩個(gè)報(bào)文可以一起發(fā)送。（這就相當(dāng)于打電話，你聽到了我說(shuō)喂，你回一個(gè)干嘛）
3. 主機(jī)A收到主機(jī)B的報(bào)文后，要發(fā)送一個(gè)狀態(tài)碼為ack的應(yīng)答報(bào)文。（就相當(dāng)于打電話，我知道你那邊聽筒和麥克風(fēng)正常，我就開始說(shuō)事了，你聽到我說(shuō)事，也就知道我設(shè)備沒問(wèn)題，但是在TCP中要應(yīng)答報(bào)文，讓主機(jī)B知道，然后才是發(fā)送數(shù)據(jù)）

syn和ack報(bào)文簡(jiǎn)述：

1. syn報(bào)文，就是通知對(duì)端我要和你建立連接了，這里面包含了發(fā)送端的信息，讓對(duì)端保存好
2. ack報(bào)文，就是通知對(duì)端你發(fā)的報(bào)文，我收到了，將信息記錄好了。

三次握手簡(jiǎn)圖：

三次握手機(jī)制好處：

1. 三次握手，相當(dāng)于“投石問(wèn)路”，初步探索一下網(wǎng)絡(luò)通信鏈路是不是暢通的
2. 驗(yàn)證通信雙方的發(fā)送和接收能力是不是正常的。
3. 三次握手過(guò)程中，是可以協(xié)商一些關(guān)鍵數(shù)據(jù)的，比如通信的初始序號(hào)

2.2.3.2 四次揮手?jǐn)嚅_連接

過(guò)程簡(jiǎn)述：主機(jī)A與主機(jī)B通信

1. 主機(jī)A先發(fā)一個(gè)狀態(tài)碼為FIN的報(bào)文給主機(jī)B（相當(dāng)于我給你打電話，我要掛電話了，我說(shuō)我要掛電話了，你還有事嗎）
2. 主機(jī)B接收到主機(jī)A發(fā)的報(bào)文后，也要發(fā)一個(gè)狀態(tài)碼為ack的應(yīng)答報(bào)文，（這就相當(dāng)于打電話，你聽到了我說(shuō)要掛電話了）
3. 還要發(fā)送一個(gè)FIN報(bào)文。（這就相當(dāng)于打電話，你聽到了我說(shuō)要掛電話了，你回一個(gè)ok）
4. 主機(jī)A收到主機(jī)B的報(bào)文后，要發(fā)送一個(gè)狀態(tài)碼為ack的應(yīng)答報(bào)文。（就相當(dāng)于打電話，我掛電話）

在四次揮手時(shí)：接收端發(fā)送的FIN和ACK報(bào)文如能合并。

接收端發(fā)送的FIN和ACK報(bào)文，只有在延時(shí)應(yīng)答機(jī)制下才能合并。而其他時(shí)候不能合并。因?yàn)锳CK的報(bào)文是操作系統(tǒng)內(nèi)核發(fā)的，而FIN報(bào)文是程序猿代碼調(diào)用到Socket的close方法才發(fā)送的。

四次握手簡(jiǎn)圖：

三次握手與四次揮手的丟包問(wèn)題：

三次握手無(wú)論哪個(gè)報(bào)文發(fā)生丟包，觸發(fā)超時(shí)重傳就可以解決。
四次揮手中在除了最后發(fā)送端（主機(jī)A）的ACK報(bào)文外，其它報(bào)文發(fā)生丟包問(wèn)題，觸發(fā)超時(shí)重傳就可以解決。
當(dāng)發(fā)送端（主機(jī)A）接收到了FIN，直接發(fā)送ACK，同時(shí)釋放這次資源，那么如果ACK丟包，主機(jī)B重傳FIN后，主機(jī)A都不認(rèn)識(shí)了。這是就引入一個(gè)TIME-WAIT狀態(tài)（在接收到了FIN后等一定時(shí)間），再釋放資源。

CLOSE-WAIT:

?般??，對(duì)于服務(wù)器上出現(xiàn)?量的 CLOSE_WAIT 狀態(tài), 原因就是服務(wù)器沒有正確的關(guān)閉 socket, 導(dǎo)致四次揮?沒有正確完成. 這是?個(gè) BUG. 只需要加上對(duì)應(yīng)的 close 即可解決問(wèn)題.

三次握手和四次揮手的詳圖（出自《圖解TCP/IP》）

2.2.4 滑動(dòng)窗口

滑動(dòng)窗口：

像在發(fā)送數(shù)據(jù)報(bào)的時(shí)候，我們發(fā)一條等待對(duì)方接收一條返回一條應(yīng)答報(bào)文，那么和發(fā)一堆再進(jìn)入等待狀態(tài)相比，明顯后者的效率更高。
滑動(dòng)窗口就是指第二種發(fā)數(shù)據(jù)方式。

滑動(dòng)窗口機(jī)制解析：

• 窗口大?。壕褪侵笩o(wú)需等待的數(shù)據(jù)報(bào)數(shù)量，也就是第一次可以發(fā)送的最大值。
• 進(jìn)出數(shù)據(jù)：滑動(dòng)窗口中的數(shù)據(jù)，接收到了哪個(gè)確認(rèn)序列號(hào)，就將滑動(dòng)窗口的頭移動(dòng)到對(duì)應(yīng)的確認(rèn)序列號(hào)的數(shù)據(jù)地方

  

• 操作系統(tǒng)內(nèi)核為了維護(hù)這個(gè)滑動(dòng)窗?, 需要開辟 發(fā)送緩沖區(qū) 來(lái)記錄當(dāng)前還有哪些數(shù)據(jù)沒有應(yīng)答; 只有確認(rèn)應(yīng)答過(guò)的數(shù)據(jù), 才能從緩沖區(qū)刪掉;
• 滑動(dòng)窗口的大小要適量，過(guò)大會(huì)影響TCP的可靠性，過(guò)小對(duì)效率提升沒啥作用。

滑動(dòng)窗口中的丟包問(wèn)題：

1. 數(shù)據(jù)報(bào)已經(jīng)抵達(dá), ACK丟了。
   這種情況，不用任何處理，因?yàn)楹竺娴竭_(dá)的ACK的確認(rèn)序號(hào)就包含了，前面的數(shù)據(jù)都接收到了的意思。

   

2. 數(shù)據(jù)報(bào)丟了
   快速重傳:在滑動(dòng)窗口下的變種機(jī)制。
   2.1. 當(dāng)某?段報(bào)?段丟失之后, 發(fā)送端會(huì)?直收到 1001 這樣的ACK, 就像是在提醒發(fā)送端 “我想要的是1001” ?樣;
   2.2. 如果發(fā)送端主機(jī)連續(xù)多次都收到了同樣?個(gè) “1001” 這樣的應(yīng)答, 就會(huì)將對(duì)應(yīng)的數(shù)據(jù) 1001 - 2000 重新發(fā)送;
   2.3. 這個(gè)時(shí)候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因?yàn)?001 - 7000)接收端其實(shí)之前就
   已經(jīng)收到了, 被放到了接收端操作系統(tǒng)內(nèi)核的接收緩沖區(qū)中;

   

2.2.5 流量控制

流量控制：

接收端處理數(shù)據(jù)的速度是有限的. 如果發(fā)送端發(fā)的太快, 導(dǎo)致接收端的緩沖區(qū)被打滿（就像小學(xué)數(shù)學(xué)小明給泳池一邊放水一邊蓄水一樣）, 這個(gè)時(shí)候如果發(fā)送端繼續(xù)發(fā)送, 就會(huì)造成丟包, 繼?引起丟包重傳等等?系列連鎖反應(yīng).
因此TCP?持根據(jù)接收端的處理能?, 來(lái)決定發(fā)送端的發(fā)送速度. 這個(gè)機(jī)制就叫做流量控制(Flow Control);

如何實(shí)現(xiàn)流量控制：

• 接收端將自己的接收緩沖區(qū)剩余的容量，通過(guò)TCP首部的“十六位窗口大小”字段，通過(guò)ACK發(fā)給發(fā)送端，發(fā)送端根據(jù)這個(gè)值來(lái)設(shè)置滑動(dòng)窗口大小，來(lái)實(shí)現(xiàn)流量控制。

特點(diǎn)：

• 16位數(shù)字最?表?65535，但是TCP窗?最?卻不是65535字節(jié)么。實(shí)際上，TCP?部40字節(jié)選項(xiàng)中還包含了?個(gè)窗?擴(kuò)?因?M，實(shí)際窗???是 窗?字段的值左移 M 位;
• 如果接收端緩沖區(qū)滿了，就會(huì)將窗?置為0；這時(shí)發(fā)送?不再發(fā)送數(shù)據(jù)，但是需要定期發(fā)送?個(gè)窗?探測(cè)數(shù)據(jù)段，使接收端把窗???告訴發(fā)送端。

流程解釋圖：

2.2.6 擁塞控制

擁塞控制：依據(jù)通信鏈路的轉(zhuǎn)發(fā)能力，進(jìn)行限制。

找擁塞控制的滑動(dòng)窗口的大?。?/p>

我們前面的流量控制的滑動(dòng)窗口的大小，直接是TCP首部字段帶的。但是我們通信鏈路沒這個(gè)功能，我們就將通信鏈路當(dāng)一個(gè)整體，先按照小的窗口發(fā)著，一直加大窗口，當(dāng)窗口過(guò)大，發(fā)生丟包就減小窗口到較小值，再次執(zhí)行前面操作，又增大窗口（面多加水，水多加面），讓窗口大小一直處于丟包臨界值動(dòng)態(tài)平衡。

圖解：

• 

• 慢啟動(dòng)：初始的小窗口大小

• ssthresh初始值：預(yù)設(shè)的窗口大小

• 過(guò)程解析：慢啟動(dòng) -> 指數(shù)增長(zhǎng) -> 線性增長(zhǎng) -> 丟包，窗口變回較小值

滑動(dòng)窗口的最終大小取決于擁塞控制和流量控制的較小值。

2.2.7 延時(shí)應(yīng)答

延時(shí)應(yīng)答：

默認(rèn)情況，接收方收到數(shù)據(jù)報(bào)第一時(shí)間返回ACK，但是可以通過(guò)延時(shí)應(yīng)答，延時(shí)返回ACK的方式提高效率。
返回窗口的大小跟流量控制，接收緩沖區(qū)剩余容量的大小有關(guān)，當(dāng)接收到數(shù)據(jù)報(bào)的時(shí)候，等一會(huì)，程序就會(huì)消耗緩沖區(qū)的數(shù)據(jù)報(bào)，這樣我們返回的ACK的窗口大?。ㄊＳ嗳萘浚┚涂梢员炔坏戎苯臃祷氐拇?，提高效率。

但是如果程序消耗的速度比不上發(fā)送方的發(fā)送速度，引入延時(shí)機(jī)制相反還會(huì)是窗口大小變小，降低效率。

延時(shí)應(yīng)答限制：

• 數(shù)量限制: 每隔N個(gè)包就應(yīng)答?次;
• 時(shí)間限制: 超過(guò)最?延遲時(shí)間就應(yīng)答?次;

圖解：

2.2.8 捎帶應(yīng)答

捎帶應(yīng)答：

引入了延時(shí)應(yīng)答，接收方得到數(shù)據(jù)后，不會(huì)立刻返回當(dāng)前數(shù)據(jù)報(bào)的ACK，那么下次返回?cái)?shù)據(jù)的時(shí)候，捎帶把上次的ACK帶回去。

圖解：

2.2.9 面向字節(jié)流

面向字節(jié)流：

創(chuàng)建?個(gè)TCP的socket, 同時(shí)在內(nèi)核中創(chuàng)建?個(gè) 發(fā)送緩沖區(qū) 和?個(gè) 接收緩沖區(qū);
• 調(diào)?write時(shí), 數(shù)據(jù)會(huì)先寫?發(fā)送緩沖區(qū)中;
• 如果發(fā)送的字節(jié)數(shù)太?, 會(huì)被拆分成多個(gè)TCP的數(shù)據(jù)包發(fā)出;
• 如果發(fā)送的字節(jié)數(shù)太短, 就會(huì)先在緩沖區(qū)?等待, 等到緩沖區(qū)?度差不多了, 或者其他合適的時(shí)機(jī)發(fā)
送出去;
• 接收數(shù)據(jù)的時(shí)候, 數(shù)據(jù)也是從?卡驅(qū)動(dòng)程序到達(dá)內(nèi)核的接收緩沖區(qū);
• 然后應(yīng)?程序可以調(diào)?read從接收緩沖區(qū)拿數(shù)據(jù);
• 另???, TCP的?個(gè)連接, 既有發(fā)送緩沖區(qū), 也有接收緩沖區(qū), 那么對(duì)于這?個(gè)連接, 既可以讀數(shù)據(jù), 也可以寫數(shù)據(jù). 這個(gè)概念叫做 全雙?
由于緩沖區(qū)的存在, TCP程序的讀和寫不需要??匹配, 例如:
• 寫100個(gè)字節(jié)數(shù)據(jù)時(shí), 可以調(diào)??次write寫100個(gè)字節(jié), 也可以調(diào)?100次write, 每次寫?個(gè)字節(jié);
• 讀100個(gè)字節(jié)數(shù)據(jù)時(shí), 也完全不需要考慮寫的時(shí)候是怎么寫的, 既可以?次read 100個(gè)字節(jié), 也可以?
次read?個(gè)字節(jié), 重復(fù)100次;

粘包問(wèn)題：

• 粘的是“應(yīng)用層數(shù)據(jù)包”
• 在TCP的協(xié)議頭中, 沒有如同UDP?樣的 “報(bào)??度” 這樣的字段, 但是有?個(gè)序號(hào)這樣的字段.
• 站在傳輸層的?度, TCP是?個(gè)?個(gè)報(bào)?過(guò)來(lái)的. 按照序號(hào)排好序放在緩沖區(qū)中.
• 站在應(yīng)?層的?度, 看到的只是?串連續(xù)的字節(jié)數(shù)據(jù).
• 那么應(yīng)?程序看到了這么?連串的字節(jié)數(shù)據(jù), 就不知道從哪個(gè)部分開始到哪個(gè)部分, 是?個(gè)完整的應(yīng)?層數(shù)據(jù)包.

解決方法：

• 在TCP角度無(wú)解，在應(yīng)用層解決。
• 法1：約定包與包之間的分隔符（包的結(jié)束標(biāo)志）；
• 法2：約定包的長(zhǎng)度（例如固定開始幾個(gè)字節(jié)表示接下來(lái)的數(shù)據(jù)包的長(zhǎng)度）

2.2.10 異常情況處理

• 進(jìn)程終?：進(jìn)程終?會(huì)釋放?件描述符，仍然可以四次揮手發(fā)送FIN。和正常關(guān)閉沒有什么區(qū)別。
• 機(jī)器重啟/正常關(guān)機(jī)：本質(zhì)上還是先殺死所有進(jìn)程，和進(jìn)程終?的情況相同。
• 接收端掉電：觸發(fā)超時(shí)重傳，觸發(fā)“重置連接”，發(fā)送方方主動(dòng)發(fā)送一個(gè)復(fù)位報(bào)文RST，還沒回應(yīng)就斷開連接。
• 發(fā)送方掉電：發(fā)送方一直不發(fā)，接收方等到一定時(shí)間，像發(fā)送方傳輸一個(gè)特殊報(bào)文“心跳包”，不攜帶數(shù)據(jù)，為了觸發(fā)ACK，還是沒有就斷開連接。
• ?線斷開：就是相當(dāng)于接收方和發(fā)送方同時(shí)掉電了。兩邊都進(jìn)行操作。

三、TCP、UDP對(duì)比

TCP，UDP對(duì)?：

• TCP是可靠連接，但是TCP不?定就優(yōu)于UDP。TCP和UDP之間的優(yōu)點(diǎn)和缺點(diǎn)，不能簡(jiǎn)單、絕對(duì)的進(jìn)??較
• TCP?于可靠傳輸?shù)那闆r，應(yīng)?于?件傳輸，重要狀態(tài)更新等場(chǎng)景；
• UDP?于對(duì)?速傳輸和實(shí)時(shí)性要求較?的通信領(lǐng)域，例如，早期的QQ，視頻傳輸?shù)?。另外UDP可以?于?播；

總結(jié)

到此這篇關(guān)于JavaSE網(wǎng)絡(luò)原理之UDP和TCP原理詳解的文章就介紹到這了,更多相關(guān)JavaSE UDP和TCP原理內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論