web協(xié)議中DNS和WebSocket有什么用

這篇文章主要介紹web協(xié)議中DNS和WebSocket有什么用，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

一、DNS 

1、Linux dig命令

我們首先通過 Linux 下的dig命令來了解一下 DNS 是怎么做域名解析的。我們首先輸入命令：

dig www.baidu.com

看下標(biāo)注的紅框，從左到右依次代表：

• 域名的名稱 也就是服務(wù)器名稱

• 網(wǎng)絡(luò)類型，DNS 協(xié)議在設(shè)計(jì)的時(shí)候考慮到了其他網(wǎng)絡(luò)類型，但是目前位置這個(gè)值還是寫死的IN 你就理解成是互聯(lián)網(wǎng)就可以了。這個(gè)值一般不變

• 標(biāo)識(shí)域名對(duì)應(yīng)何種類型的地址，A 就代表ip的地址。

這里可能有人會(huì)問了，這個(gè)域名的后面為啥還有個(gè)“.”？我們輸入的明明是 www.baidu.com 不是 www.baidu.com. 啊 。 

這里要提一下：

末尾的. 代表的就是根域名，每個(gè)域名都有根域名，所以通常我們會(huì)省略它。

根域名的下一級(jí)叫頂級(jí)域名，比如我們熟知的.com與.net。

再下一級(jí)就是次級(jí)域名了，比如例子中的.baidu。這個(gè)次級(jí)域名只要你有錢是可以隨便注冊(cè)的。

最后這個(gè)www，這個(gè)代表三級(jí)域名。一般是用戶在自己的域里面為服務(wù)器分配的名稱。用戶可以隨便分他。 

所以可以看出來這里的域名是分級(jí)別的。能弄明白這點(diǎn)就能搞清楚為什么DNS的查詢過程是分級(jí)查詢了。

我們可以利用dig+trace命令來完整的還原一次分級(jí)查詢的過程：

你看通過命令的方式就能一目了然的理解DNS查詢的過程了。這遠(yuǎn)比你在網(wǎng)上搜一些什么DNS是遞歸查詢啊之類的要來的直觀。這里有眼尖的小伙伴可能會(huì)問，這個(gè)CNAME是用來干嘛的？大家只要理解CNAME主要用來做CDN加速的即可。詳細(xì)的可以去維基百科查詢，那里說的很清楚，本文受限于篇幅就不在這個(gè)知識(shí)點(diǎn)上展開了。

2、WireShark學(xué)習(xí)理解DNS報(bào)文

這里注意因?yàn)?Wireshark的捕獲過濾器無法設(shè)置DNS協(xié)議，又因?yàn)镈NS是基于 UDP協(xié)議的，所以這里捕獲過濾器我們就設(shè)置為 UDP就好。

然后就可以在一堆 UDP報(bào)文中找到我們想看的DNS報(bào)文了，我們?cè)跒g覽器中輸入www.airbnb.com:

這里要注意左邊有兩個(gè)箭頭,向右的箭頭代表“請(qǐng)求”，向左的箭頭就代表該“請(qǐng)求”的回復(fù)了。

這些DNS報(bào)文經(jīng)過 Wireshark的解析以后，格式已經(jīng)幫我們分析好了，所以看起來很清晰。也很簡(jiǎn)單。這里我們不再詳細(xì)分析DNS的二進(jìn)制報(bào)文格式，有興趣的可以自行查找相關(guān)資料。在我們上述展示的DNS報(bào)文抓包截圖的時(shí)候，細(xì)心的同學(xué)已經(jīng)發(fā)現(xiàn)了，我們DNS報(bào)文的查詢地址是172.22.3.102。一般而言，大部分公司內(nèi)部網(wǎng)絡(luò)都會(huì)提供一個(gè)統(tǒng)一的DNS服務(wù)器，這個(gè)地址就是內(nèi)部的DNS服務(wù)器地址了，有圖為證：

我們當(dāng)然也可以使用其他DNS查詢，比如使用著名的谷歌DNS

3、傳統(tǒng)DNS服務(wù)查詢的缺點(diǎn)

經(jīng)過上述的分析看起來DNS的查詢過程好像比較簡(jiǎn)單，但實(shí)際上DNS帶來的性能或者安全問題很多很多。我們首先來還原一下完整的DNS查詢過程（假設(shè)我們想訪問csdn的網(wǎng)站）：

1. 瀏覽器輸入一個(gè)域名地址，如果操作系統(tǒng)的DNS緩存中有這個(gè)域名的Ip地址 那么直接返回，沒有的話 就去第二步。

2. 操作系統(tǒng)會(huì)向 本系統(tǒng)設(shè)置的tcp/ip 參數(shù)中的DNS服務(wù)器地址 發(fā)出DNS查詢報(bào)文。注意這個(gè)服務(wù)器我們通常叫他 本地DNS服務(wù)器。也就是上述我們截圖中的172.22.3.102

3. 如果本地DNS服務(wù)器的緩存中有這個(gè)域名對(duì)應(yīng)的ip地址，那就直接返回，如果沒有，繼續(xù)下一步。

4. 首先看DNS服務(wù)器的架構(gòu)圖：

5. 也就是說當(dāng)我們的本地DNS服務(wù)器緩存中沒有該域名的ip地址的時(shí)候，本地DNS服務(wù)器就會(huì)直接向 根DNS（全世界只有13臺(tái)）服務(wù)器去查詢，然后根DNS服務(wù)器就會(huì)分析這個(gè)域名，告訴我們的本地DNS服務(wù)器 你應(yīng)該去.net 這個(gè)DNS服務(wù)器去查詢。然后.net這個(gè)DNS服務(wù)器又告訴本地DNS服務(wù)器 你應(yīng)該去csdn.net 這個(gè)DNS服務(wù)器 去查詢DNS地址。然后最終csdn的 DNS服務(wù)器就將正確的ip地址返回給我們的本地DNS，本地DNS再將這個(gè)值返回給我們的瀏覽器（這個(gè)過程其實(shí)你用前面的dig+trace命令可以更直觀的體會(huì)到）。

通過上述的一次完整的DNS交互過程，我們可以至少得出三個(gè)結(jié)論：

1. DNS服務(wù)器是可以做負(fù)載均衡的。當(dāng)然前提條件是你這個(gè)域名得自己建一個(gè)DNS服務(wù)器。一般大廠都會(huì)自建。

2. DNS的查詢是一個(gè)遞歸的過程，弱網(wǎng)的情況，這個(gè)時(shí)間會(huì)變的很漫長(zhǎng)。且DNS使用的是 UDP傳輸協(xié)議，弱網(wǎng)有直接查詢失敗的可能。

3. DNS的查詢過程不可控，比如說本地DNS服務(wù)器完全可以返回一個(gè)錯(cuò)誤的ip地址。比如你訪問了一個(gè)京東的鏈接，然后返回給你的ip地址是拼多多的。

這還只是表面上看出來的傳統(tǒng)DNS查詢的缺點(diǎn)，實(shí)際上現(xiàn)在我們每天大部分的流量都來自于移動(dòng)網(wǎng)絡(luò)。移動(dòng)網(wǎng)絡(luò)中，傳統(tǒng)DNS服務(wù)暴露出來的問題更多：

1. 前文我們說過本地DNS服務(wù)器會(huì)緩存域名的ip，但這個(gè)緩存時(shí)效我們控制不了，全靠運(yùn)營(yíng)商的操守。有可能發(fā)生我們ip地址已經(jīng)變化，但是本地DNS服務(wù)器返回的還是老ip的情況。

2. 有些運(yùn)營(yíng)商為了節(jié)省運(yùn)營(yíng)商和運(yùn)營(yíng)商之間的流量計(jì)算成本，會(huì)偷偷的將一些靜態(tài)頁(yè)面緩存。當(dāng)用戶訪問這些頁(yè)面的時(shí)候 往往訪問的是這些靜態(tài)頁(yè)面的緩存服務(wù)器的地址。此時(shí)不管我們的頁(yè)面更新了多少內(nèi)容，對(duì)于用戶來說都是老的頁(yè)面。

3. 運(yùn)營(yíng)商在某些場(chǎng)景，例如人口集中的地鐵站，演唱會(huì)，足球場(chǎng)附近等等，一旦發(fā)現(xiàn)自己的用戶太多，本地DNS服務(wù)器壓力巨大的時(shí)候，就會(huì)手動(dòng)設(shè)置將本地DNS服務(wù)器向根域名服務(wù)器

4. 查詢 然后遞歸查詢 DNS的過程 修改成：直接向另外一個(gè)運(yùn)營(yíng)商（假設(shè)這個(gè)運(yùn)營(yíng)商名字為B）的DNS服務(wù)器地址進(jìn)行查詢，B的DNS服務(wù)器就會(huì)返回一個(gè)B的地址，此時(shí)運(yùn)營(yíng)商A的用戶訪問的ip地址就是運(yùn)營(yíng)商B的ip了，這種跨運(yùn)營(yíng)商訪問的場(chǎng)景速度會(huì)非常慢。

5. 某些寬帶提供方的NAT服務(wù)非常不穩(wěn)定，大家都知道我們?cè)诩疑暇W(wǎng)的時(shí)候 本機(jī)地址其實(shí)就是一個(gè)內(nèi)網(wǎng)地址，我們之所以能訪問外部的網(wǎng)絡(luò)是因?yàn)檫@些寬帶提供方提供了一層網(wǎng)關(guān)來負(fù)責(zé)NAT,這個(gè)NAT會(huì)將我們的內(nèi)網(wǎng)地址轉(zhuǎn)換成一個(gè)外網(wǎng)的地址，NAT之后的ip，某些權(quán)威DNS服務(wù)器就無法判斷這個(gè)ip到底屬于哪個(gè)運(yùn)營(yíng)商。也會(huì)帶來跨運(yùn)營(yíng)商訪問的問題。

6. 除了自己的DNS服務(wù)器，其他公共DNS服務(wù)器的緩存時(shí)效都不可控，這對(duì)雙機(jī)房部署，異地多活，多域名等策略都會(huì)有影響。

7. 弱網(wǎng)環(huán)境下，因?yàn)镈NS使用的傳輸協(xié)議是不可靠的 UDP，又因?yàn)镈NS查詢的過程是一個(gè)遞歸的過程，所以DNS查詢?cè)谌蹙W(wǎng)環(huán)境下是有概率失敗的。

4、HTTPDNS

基于上述缺點(diǎn)，越來越多的大廠使用了HTTPDNS的這種技術(shù)（據(jù)騰訊的公開資料顯示，15年騰訊每天的localDNS失敗次數(shù)就達(dá)到了80w次，接入HTTPDNS以后，用戶平均訪問延遲下降超過10%，訪問失敗率下降了超過五分之一，用戶訪問體驗(yàn)的效果提升非常顯著）：

這種技術(shù)的原理其實(shí)挺簡(jiǎn)單的，無非就是讓我們的手機(jī)App 發(fā)起一個(gè)HTTP請(qǐng)求(這個(gè)請(qǐng)求地址多數(shù)使用ip直連，如果使用域名那么依然針對(duì)此請(qǐng)求依然有傳統(tǒng)DNS的問題)，這個(gè)請(qǐng)求可以攜帶用戶所在的運(yùn)營(yíng)商，地理位置，精確到省市，然后服務(wù)器根據(jù)這些信息 返回一個(gè)最佳的ip地址給App，然后App將這個(gè)域名-ip的映射關(guān)系設(shè)置到我們的okhttp中。這樣手機(jī)中的大部分請(qǐng)求就會(huì)直接使用我們HTTP服務(wù)器返回的ip地址而不是運(yùn)營(yíng)商的地址了。

注意這里我說的是大部分請(qǐng)求而不是全部請(qǐng)求的原因是，對(duì)于Android系統(tǒng)來說，webview的DNS查詢過程代碼全部在c層，且版本和版本之間有一定差異，這部分的hook過程極為艱難，截止到這篇文章編寫的時(shí)候，筆者依舊沒有查詢到公開的能夠hook webview DNS的源碼，而iOS這點(diǎn)做的顯然就比Android好一些，對(duì)于iOS來說webview的HTTP就是一個(gè)正常的HTTP request 與原生的代碼并沒有任何區(qū)別。對(duì)于Android客戶端來說，接入HTTPDNS也不是一件特別容易的事。即使現(xiàn)在擁有了okhttp。

方案一：

通過okhttp的攔截器，在發(fā)出請(qǐng)求之前將我們的url中的域名直接替換成ip，再手動(dòng)往header中添加host頭部信息。缺點(diǎn)：如果url是https的，ip直連會(huì)出現(xiàn)證書校驗(yàn)的問題。另外因?yàn)檎?qǐng)求的時(shí)候 我們直接用的ip 但是 服務(wù)端返回的set cookie頭部信息卻帶上的域名，這里也要額外處理。優(yōu)點(diǎn)：因?yàn)槭菙r截器的實(shí)現(xiàn)機(jī)制，所以很容易做開關(guān)進(jìn)行降級(jí)處理。

方案二：

通過okhttp的DNS直接接管。

public class HttpDNS implements DNS {
    private static final DNS SYSTEM = DNS.SYSTEM;
  
    @Override
    public List<InetAddress> lookup(String hostname) throws UnknownHostException {
        //假設(shè)這個(gè)DNShelper可以返回我們httpDNS查詢的結(jié)果
        String ip = DNSHelper.getIpByHost(hostname);
        if (ip != null && !ip.equals("")) {
            List<InetAddress> inetAddresses = Arrays.asList(InetAddress.getAllByName(ip));
            return inetAddresses;
        }
        return SYSTEM.lookup(hostname);
    }
}
 //然后讓okhttp使用我們的DNS實(shí)現(xiàn)就好
 OkHttpClient client = new OkHttpClient.Builder()
                .DNS(new HttpDNS())
                .build();

這種方案就不存在攔截器哪種缺點(diǎn)，因?yàn)楸举|(zhì)上這種方案和系統(tǒng)的DNS查詢方案并無二致，無非系統(tǒng)的是 UDP去localDNS找，我們的是用HTTP去 HTTP服務(wù)器上找。這種方案可以解決方案一的所有缺點(diǎn)，但是有一個(gè)問題就是一旦這個(gè)HTTPDNS返回的結(jié)果有問題，那么很難降級(jí)。且okhttp的DNS查詢也是有一層緩存的，一旦我們的HTTP DNS服務(wù)器返回的地址有誤，那么在一定時(shí)間范圍內(nèi)后續(xù)針對(duì)這個(gè)域名的訪問都會(huì)有問題。

前面我們說過Android自身webview的機(jī)制導(dǎo)致HTTPDNS很難在webview中起到作用，但是仍舊有一些方法可以盡量規(guī)避掉webview中l(wèi)oacalDNS速度慢的缺點(diǎn)。例如我們可以在html中設(shè)置預(yù)加載靜態(tài)資源的DNS請(qǐng)求，而不用等到真正請(qǐng)求這些資源的時(shí)候才會(huì)查找DNS。

<!--域名預(yù)解析-->
<meta http-equiv="x-DNS-prefetch-control" content="on" >
<link rel="DNS-prefetch" href="//vivo.com.cn" >

考慮到實(shí)際上webview和App自身代碼使用的DNS緩存都是操作系統(tǒng)中的同一塊存儲(chǔ)區(qū)域，我們也可以統(tǒng)計(jì)出我們常用web頁(yè)面中頻繁請(qǐng)求的url的域名，在App一啟動(dòng)的時(shí)機(jī)，就提前訪問這些域名，這樣等到熱點(diǎn)web頁(yè)面在加載的時(shí)候，如果操作系統(tǒng)DNS緩存已經(jīng)有了對(duì)應(yīng)的ip，則可以省略一次DNS的查詢。

5、DNS真的是基于UDP協(xié)議的嗎？

其實(shí)DNS協(xié)議真的不是完全基于UDP協(xié)議的，DNS的協(xié)議里面其實(shí)有主DNS服務(wù)器和輔DNS服務(wù)器的概念，輔DNS服務(wù)器在啟動(dòng)的時(shí)候會(huì)主動(dòng)去主DNS服務(wù)器上拉取最新的該區(qū)域DNS信息。這個(gè)拉取的過程采用的就是TCP協(xié)議，而不是UDP協(xié)議。也就是協(xié)議文檔中說的zone transfer。

這里有人可能會(huì)想到，為什么不用UDP協(xié)議來完成這個(gè)過程，因?yàn)閁DP協(xié)議最大只能傳送512個(gè)byte的數(shù)據(jù)，而輔DNS要拉取該區(qū)域的DNS信息很容易就超過這個(gè)最大報(bào)文數(shù)量的限制，所以這里采用的就是TCP協(xié)議來完成拉取數(shù)據(jù)的操作。

二、WebSocket

1、有 HTTP 輪詢?yōu)槭裁催€需要 WebSocket 技術(shù)？

很多人不明白為什么一定要用 WebSocket，明明我輪詢HTTP請(qǐng)求一樣可以完成需求。這句話本身并不錯(cuò)，可以用 WebSocket 的地方確實(shí)全部都可以用輪詢HTTP請(qǐng)求來替代。但是其背后的效率卻天差地別。

我們可以把 WebSocket 看成是 HTTP 協(xié)議為了支持長(zhǎng)連接所打的一個(gè)大補(bǔ)丁，它和 HTTP 有一些共性，是為了解決 HTTP 本身無法解決的某些問題而做出的一個(gè)改良設(shè)計(jì)。在以前 HTTP 協(xié)議中所謂的 keep-alive 長(zhǎng)連接是指在一次 TCP 連接中完成多個(gè) HTTP 請(qǐng)求，但是對(duì)每個(gè)請(qǐng)求仍然要單獨(dú)發(fā) header；所謂的輪詢是指從客戶端不斷主動(dòng)的向服務(wù)器發(fā) HTTP 請(qǐng)求查詢是否有新數(shù)據(jù)。這種模式有三個(gè)缺點(diǎn)：

• 除了真正的數(shù)據(jù)部分外，服務(wù)器和客戶端還要大量交換 HTTP header，信息交換效率很低。

• 因?yàn)镠TTP是無狀態(tài)的，每次請(qǐng)求服務(wù)端都要通過客戶端傳遞來的參數(shù)來查詢這個(gè)請(qǐng)求到底是誰的，例如每次都要查詢一下這個(gè)userId下面有多少存款，買過幾部手機(jī)等等，對(duì)服務(wù)器的寶貴的計(jì)算資源是一種浪費(fèi)。

• 輪詢的時(shí)間間隔不好設(shè)置，設(shè)置高了，用戶的界面響應(yīng)不及時(shí)，設(shè)置的太低，又怕流量消耗大，服務(wù)器扛不住。

當(dāng)然輪詢也有優(yōu)點(diǎn)就是實(shí)現(xiàn)成本極低，幾乎不需要客戶端和服務(wù)端有額外的開發(fā)成本。WebSocket在首次使用的時(shí)候還是需要做一些基礎(chǔ)設(shè)施改造的（例如nginx相應(yīng)的配置）。WebSocket的實(shí)現(xiàn)成本：雖然說現(xiàn)代服務(wù)器編程中默認(rèn)都提供了WebSocket的實(shí)現(xiàn)，但是我們知道考慮到擴(kuò)展性等因素，我們通常都不會(huì)直接和源服務(wù)器打交道，而是和代理服務(wù)器打交道。對(duì)WebSocket來說同樣如此，所以這里對(duì)于首次實(shí)現(xiàn)WebSocket的團(tuán)隊(duì)是有一定技術(shù)成本。

上圖是一個(gè)簡(jiǎn)單的服務(wù)器架構(gòu)圖，客戶端發(fā)出去的請(qǐng)求經(jīng)過一臺(tái)專門做負(fù)載均衡的代理服務(wù)器以后將這些請(qǐng)求逐一轉(zhuǎn)發(fā)到對(duì)應(yīng)的源服務(wù)器上。而對(duì)于WebSocket來說 情況則變的稍微有點(diǎn)復(fù)雜：

相比純 HTTP 來說，WebSocket通常會(huì)增加一層專門的消息分發(fā)系統(tǒng)提高消息的處理效率。通常是Kafka或者是RabbitMQ。

2、Wireshark解析WebSocket報(bào)文

首先 來看一下WebSocket的幀格式。我們首先設(shè)置一下 Wireshark的捕獲器：

可以看出來這里我們操作步驟一共是 connect，然后發(fā)消息，服務(wù)器返回我們發(fā)送的消息，最后我們主動(dòng)斷開連接。

WebSocket是一個(gè)基于幀的協(xié)議，所以這里我們著重分析一下WebSocket的幀格式，每個(gè)幀頭部的 第4-第7個(gè) bit位，這4個(gè)bit 代表的就是Opcode，比較重要的就是幾個(gè)值：

• 2：代表這是二進(jìn)制幀，

• 1：代表這是一個(gè)文本幀，

• 8：代表關(guān)閉幀。

3、WebSocket連接的建立過程

這里有人就要問了，既然WebSocket是能保證長(zhǎng)連接（tcp）的，那么這條長(zhǎng)連接是由誰發(fā)起的？看下圖：

此外我們還需要注意Sec-WebSocket-Accept，和Sec-WebSocket-Key 這2個(gè)頭部信息。

客戶端生成一個(gè)隨機(jī)數(shù)以后用base64加密以后放到Sec-WebSocket-Key頭部信息中，然后服務(wù)器接受到這個(gè)信息，用這個(gè)值與rfc中規(guī)定的一個(gè)魔法字符串：“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”拼起來，然后再使用sha-1加密 再經(jīng)過base64 以后計(jì)算出來的值 放到Sec-WebSocket-Accept頭部中返回給客戶端。

這么做的原因是帶來一些基礎(chǔ)的保障，前面我們說過WebSocket連接的建立是依托HTTP消息的，為了防止這個(gè)WebSocket連接的建立是調(diào)用者無心誤觸發(fā)或者其他異常情況，所以這里有一次額外的數(shù)據(jù)校驗(yàn)的過程。

4、WebSocket連接的斷開過程

看完連接，我們?cè)倏匆幌聰嚅_連接，與WebSocket的連接不同，WebSocket的斷開連接是有明確步驟的，需要先斷開WebSocket的連接，然后才是tcp的斷開連接。

圖中可以看出來這個(gè)心跳包大概是30s發(fā)送一次，而且并沒有使用rfc中約定好的0x9或者0xA的所謂ping pong的心跳幀，而是就用了最簡(jiǎn)單的文本幀來表示。

上圖所示，左邊的就是WebSocket 服務(wù)端發(fā)起的心跳包，opcode的值還是text文本幀的意思，只不過文本的內(nèi)容很特殊。右邊就是WebSocket客戶端回復(fù)的心跳包。

5、WebSocket的代理緩存污染

這里要注意的是 Wireshark抓包的時(shí)候，最右邊有一個(gè)masked的標(biāo)識(shí)，這通常代表這一個(gè)WebSocket的幀是由客戶端發(fā)送給服務(wù)端的，這是一個(gè)掩碼的標(biāo)識(shí)。在WebSocket協(xié)議中只要是客戶端發(fā)起的消息，都必須經(jīng)過這個(gè)隨機(jī)的masking-key的掩碼計(jì)算之后才能傳輸。這是為了解決代理緩存污染的問題。

注意這里問題的核心是實(shí)現(xiàn)不當(dāng)?shù)拇矸?wù)器，所謂實(shí)現(xiàn)不當(dāng)?shù)拇矸?wù)器就是指沒有完整實(shí)現(xiàn)好WebSocket協(xié)議的代理服務(wù)器。而不是真正意義上惡意的代理服務(wù)器，惡意的代理服務(wù)器，用mask幀的技術(shù)是無法避免的。

所謂mask掩碼技術(shù)就是指瀏覽器在發(fā)送WebSocket幀的時(shí)候必須生成一個(gè)隨機(jī)的mask-key，在幀的二進(jìn)制中將傳輸?shù)膬?nèi)容與這個(gè)mask-key做異或操作。得出來的值才可以在網(wǎng)絡(luò)中傳輸。

當(dāng)我們的服務(wù)器接收到這個(gè)WebSocket幀以后就可以用這個(gè)mask-key來反異或，從而就可以得出真正的內(nèi)容了，這是最低成本實(shí)現(xiàn)檢測(cè)WebSocket幀是否遭到篡改的方案。例如：我們用WebSocket 傳輸一個(gè) 文本幀，內(nèi)容為字符串vivo,vivo的ascii碼的16進(jìn)制為：76 69 76 6f。而這個(gè)消息，這次瀏覽器生成的mask-key 為 23 68 c0 a3。

我們將這2個(gè)值進(jìn)行異或操作：

可以得到值為55 01 b6 cc。然后看一下抓包的幀內(nèi)容里面是不是這個(gè)值：

以上是“web協(xié)議中DNS和WebSocket有什么用”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！