本文以訪問一個(gè)實(shí)際的 HTTP 網(wǎng)站為例，講述在訪問一個(gè)網(wǎng)頁背后所經(jīng)歷哪些過程。通過介紹各層協(xié)議是如何共同協(xié)作，最終完成網(wǎng)頁數(shù)據(jù)傳輸，使得讀者能夠?qū)υ撨^程的理解更加清晰。本文以瀏覽器訪問 URL 為例，其實(shí)在眾多 APP 客戶端工作的過程中，也是會訪問各自服務(wù)器的 URL，從原理上來說和瀏覽器端的訪問基本一致，可自行對應(yīng)。

本文分析使用到的數(shù)據(jù)報(bào)文，我已經(jīng)放在這個(gè)地方，可自行下載，對應(yīng)著后續(xù)的講述更加容易的理解整個(gè)分析過程。

本文以央視網(wǎng)這樣一個(gè) HTTP 網(wǎng)站為例來進(jìn)行講述。如果訪問像這樣一個(gè)常見的域名，由于為百度已經(jīng)采用了全站加密的技術(shù)，這樣的話會出現(xiàn)一些重定向， 同時(shí) ssl 層還有一個(gè)建立連接的過程，對于網(wǎng)絡(luò)協(xié)議還不是那么熟悉的同學(xué)來說可能會顯得較為復(fù)雜。因此這里面使用一個(gè)沒有重定向，基于 HTTP1.1 協(xié)議傳輸?shù)木W(wǎng)站會使問題的分析變的更加容易理解，同時(shí)目前國內(nèi)的大多數(shù)網(wǎng)站還停留在 HTTP1.1 傳輸階段，分析 HTTP1.1 傳輸也能夠兼顧大多數(shù)的場景。雖然一些大的互聯(lián)網(wǎng)企業(yè)都是積極的擁抱新技術(shù)，采用了 HTTPS，但是也可以看到，政府網(wǎng)站，學(xué)校網(wǎng)站，公司網(wǎng)站依然基于 HTTP1.1 傳輸居多。

在分析 HTTP1.1 傳輸?shù)幕A(chǔ)上再去嘗試分析重定向以及 HTTPS，甚至已經(jīng)開始應(yīng)用的 HTTP2 等網(wǎng)站就變得很容易。需要說明的是本文只分析協(xié)議層次的訪問流程，也就是以對主頁 URL 的訪問為例。至于主頁上的腳本，圖片等資源的加載請求的 URL 跟主頁的請求在協(xié)議角度原理一致，不在贅述。

本文的分析主要分為三個(gè)層次：

1. 站在各個(gè)協(xié)議層次來看協(xié)議間是如何對等傳輸?shù)摹?/li>
2. 站在數(shù)據(jù)發(fā)送者角度自頂向下的分析，分析各層協(xié)議字段如何獲取。
3. 站在數(shù)據(jù)接受者的角度自底向上的分析，分析各層協(xié)議之間的聯(lián)系。

一、對等傳輸

TCP/IP 模型如圖 1：

圖 1

可以看到 TCP/IP 模型的協(xié)議棧包含四層，對等傳輸表達(dá)的就是如圖 1 虛線所示，應(yīng)用層之間互相通信，傳輸層之間互相交換數(shù)據(jù)，同理網(wǎng)絡(luò)層和物理層。這里面以 HTTP 這個(gè)常見的應(yīng)用層協(xié)議為例說明對等傳輸。

在瀏覽器中輸入 http://www.cctv.com 這樣一個(gè)網(wǎng)址，同時(shí)通過 Wireshark 工具抓取傳輸過程中的數(shù)據(jù)。使用 http.host contains "cctv" 過濾排除無用的數(shù)據(jù)包，可以看到有諸多的 http 請求和響應(yīng)。如前所述，只考慮主頁 URL 的請求，并選擇第一條進(jìn)行 follow，如圖 2：

圖 2

這時(shí)候你發(fā)現(xiàn)訪問 www.cctv.com 應(yīng)用層使用了 HTTP 協(xié)議進(jìn)行傳輸，為什么呢？因?yàn)闉g覽器地址欄這時(shí)候地址變成了 http://www.cctv.com/，也就是瀏覽器在訪問 www.cctv.com 時(shí)候，會添加 http:// 這樣一個(gè)協(xié)議頭，默認(rèn)了其傳輸協(xié)議為 HTTP。但是訪問 gitchat 卻是 https://gitbook.cn/ 這個(gè)樣子的，前面也提到了會有 http://gitbook.cn/ 重定向到 https://gitbook.cn/ 的過程，為了問題的簡化，本文不過多的討論。如果你和服務(wù)器之間想通過 ftp 協(xié)議進(jìn)行傳輸，那么在瀏覽器訪地址欄輸入的時(shí)候就要帶上具體協(xié)議了，例如 ftp://image.cctv.com 這種形式，因?yàn)?image.cctv.com 會被默認(rèn)為 http://image.cctv.com，ftp 協(xié)議是沒有重定向的功能的。

從 HTTP 這個(gè)應(yīng)用層來說，通信過程是這樣的。

1. 客戶端發(fā)起一個(gè) HTTP GET 請求。
2. 服務(wù)器給出一個(gè) HTTP/1.1 220 OK 的響應(yīng)，同時(shí)傳輸具體的網(wǎng)頁數(shù)據(jù)。整體來看，HTTP 協(xié)議過程非常的簡單，就是請求和響應(yīng)的過程。不僅 HTTP 如此，大多數(shù)的通信協(xié)議都是請求和響應(yīng)的過程。

當(dāng)然 HTTP 協(xié)議復(fù)雜程度遠(yuǎn)不止上述請求和響應(yīng)那么簡單。例如 HTTP 所規(guī)定的方法就還包括 POST，PUT，DELETE，CONNECT，OPTIONS，HEAD，TRACE 這幾種，涵蓋了數(shù)據(jù)的增刪改查等方面。HTTP 的響應(yīng)也還包括 1xx,2xx,3xx,4xx,5xx 等多種響應(yīng)方式，分別表示不同的應(yīng)答，例如信息類應(yīng)答，成功的應(yīng)答，重定向，客戶端錯誤應(yīng)答，服務(wù)器錯誤應(yīng)答等等。

除了請求方法和響應(yīng)碼之外，還有豐富的 HTTP 頭域，例如在請求階段 Host 表示請求域名，Connection 表示長連接，User-Agent 表示客戶端名稱，Referer 表示請求來源，Aceept-Encoding 表示可接受傳輸?shù)膲嚎s編碼方式等常見的請求頭域。在響應(yīng)階段，可以看到 Expires 表示內(nèi)容過期時(shí)間，Server 表示服務(wù)器名稱，Content-Encoding 表示傳輸?shù)膲嚎s編碼方式等常見的響應(yīng)頭域。

總體上看，可以理解為 HTTP 層是基于請求和應(yīng)答（請求應(yīng)答最終是協(xié)商服務(wù)器絕對路徑，因此也可以認(rèn)為是基于服務(wù)器絕對地址）所建立的虛擬鏈接。頭域字段更多的是為了協(xié)商傳輸內(nèi)容服務(wù)的。有了這樣一個(gè)虛擬連接之后，自然而然的，數(shù)據(jù)就在 HTTP 層次對等的傳輸起來。如圖 3：

圖 3

可以看到，我們忽略了所有的下層，認(rèn)為 HTTP 層存在一條虛擬鏈接。同理可以認(rèn)為 TCP 層是基于端口所建立的鏈接，當(dāng)然關(guān)于 TCP 層的對等傳輸通常指的是 TCP 的三次握手，如圖 4：

圖 4

TCP 的三次握手具體過程是：

1. 客戶端發(fā)起 TCP 連接（SYN）
2. 服務(wù)器同意，并響應(yīng)（SYN，ACK）
3. 客戶端也準(zhǔn)備就緒，開始發(fā)數(shù)據(jù)（ACK）。

在一條流的結(jié)束時(shí)候，有四次揮手?jǐn)嚅_相應(yīng)的 TCP 連接，如圖 5：

圖 5

同樣的 IP 層是基于 IP 地址所建立的鏈接，MAC 是基于 MAC 地址多建立的鏈接。當(dāng)然顯而易見的是，這些鏈接并不唯一。但是協(xié)議棧中各層析協(xié)議組合起來構(gòu)成的鏈接在某個(gè)時(shí)刻就是唯一的一條鏈接，因此可以看到在復(fù)雜的網(wǎng)絡(luò)中數(shù)據(jù)為什么非常有秩序的從一個(gè)終端流向另一個(gè)終端，正是這一條條唯一的鏈接所決定，不會跑偏。同時(shí)也可以看到協(xié)議中非常重要的一個(gè)要素就是地址，無論是 MAC 地址，IP 地址，端口，URL 都是一種地址，而地址就是通信的目的地?；诘刂返逆溄泳蜆?gòu)成了協(xié)議層次的對等傳輸。

二、自頂向下

這個(gè)時(shí)候你可能會有疑問，在 TCP 對等傳輸中，端口從何而來，同樣的 IP 和 MAC 地址從何而來。因?yàn)槲覀儼l(fā)現(xiàn) HTTP 下層的 TCP 端口，IP 的地址這個(gè)時(shí)候都是已知的，如圖 2 中所示。端口的獲取過程很簡單，系統(tǒng)自帶 TCP 協(xié)議棧隨機(jī)選擇了一個(gè)客戶端的端口，當(dāng)然通常情況下客戶端的端口都在默認(rèn)在 30000 以上。同時(shí)由于傳輸協(xié)議是 HTTP 協(xié)議，因此端口為 80。因?yàn)?1-1024 這樣一個(gè)保留端口是由 IANA 規(guī)定分配給指定的協(xié)議的，80 號端口就分配給了 HTTP 協(xié)議，后面的 53 號端口分配給了 DNS 是同樣的道理，這是一個(gè)通用的標(biāo)準(zhǔn)，大多數(shù)的使用共有協(xié)議的服務(wù)都會遵守。如果想了解關(guān)于更多的常見端口信息，可以參見我寫的文章，這里。客戶端的 IP 就是本機(jī) IP，服務(wù)器的 IP 地址的獲取過程通過 DNS 來完成。

DNS 是域名解析協(xié)議，就是將域名轉(zhuǎn)換為對應(yīng)的 IP 地址，因?yàn)橹挥型ㄟ^ IP 地址才能找到對應(yīng)的主機(jī)所在。那么為什么不直接在瀏覽器里面輸入 IP 地址的，這當(dāng)然是可以的，但是由于 IP 地址沒有域名方便于記憶，通常輸入的都是域名，因此中間多了這一道過程，計(jì)算機(jī)設(shè)計(jì)的目的還是要方便于人。

使用 dns.qry.name == "www.cctv.com" 過濾得到 http://www.cctv.com/ 對應(yīng)的 DNS 請求，如圖 6：

圖 6

可以看到 DNS 使用的是 UDP 協(xié)議，源端口是本機(jī)分配的端口，由系統(tǒng)的 UDP 協(xié)議棧進(jìn)行分配，而目的端口是 53，前面也提到了。因此協(xié)議棧在發(fā)送 DNS 協(xié)議的時(shí)候，將目的端口賦值為 53，長度則是由 DNS 長度來決定。

同樣的 IP 層的目的地址從何而來？其實(shí)該地址是本機(jī)所配置的 dns 地址，如圖 7：

圖 7

由于本機(jī)使用的是 DHCP 服務(wù)且使用的是電信的寬帶，因此自動獲取的最近的一個(gè)電信的 DNS，因此這里的目的地址就是電信的 DNS。當(dāng)然如果你手動配置了 DNS，這時(shí)候的目的 IP 就是你所配置的目標(biāo) DNS，例如 114.114.114.114，以及 8.8.8.8 這些較為知名的 DNS 服務(wù)器，可以親自手動設(shè)置下，抓包驗(yàn)證。

有了 IP 層的地址，那么以太網(wǎng)層的信息如何獲取呢？首先上層是 Ipv4 協(xié)議，因此 type 字段就是確定的值，源地址就是本機(jī)的 MAC 地址，按照通常的思路，你可能理所當(dāng)然的認(rèn)為目的 MAC 應(yīng)該是目的 IP 所對應(yīng)的 MAC 地址，但是事實(shí)上并非如此。由于目的 IP 和源 IP 并不是處在同一個(gè)網(wǎng)段之中，通過 IP 地址和子網(wǎng)掩碼與的結(jié)果并不相同得知。同時(shí) MAC 層的通信規(guī)定的是局域網(wǎng)范圍內(nèi)的通信過程，對于不在同一個(gè)局域網(wǎng)內(nèi)的主機(jī)來說，首先應(yīng)該把數(shù)據(jù)包交給網(wǎng)關(guān)設(shè)備，由網(wǎng)關(guān)設(shè)備進(jìn)行轉(zhuǎn)發(fā)。

由于本機(jī)配置的網(wǎng)關(guān)為 192.168.0.1，圖 7 所示，因此可以斷定這里面配置的 MAC 為網(wǎng)關(guān)的 MAC 地址。因此在完成這個(gè)報(bào)文發(fā)送之前應(yīng)該還有一個(gè)過程，獲取網(wǎng)關(guān)的 MAC 地址，根據(jù)網(wǎng)關(guān)的 IP 地址獲取網(wǎng)關(guān)的 MAC 過程就是 ARP 的過程。

介紹一下 ARP 的主要原理，如下：

1. 先在 ARP 緩存中查看是否存在目的主機(jī)的的 IP 地址，windows 上可以通過在命令行輸入 arp -a 查看。如果有，就把這個(gè)硬件地址寫入相應(yīng)的 MAC 層中。
2. 如果沒有目的 IP 地址，將在 ARP 幀中的目的 MAC 部分寫全 F 形式表示廣播該數(shù)據(jù)，因此網(wǎng)段內(nèi)所有的主機(jī)或設(shè)備都能夠接收到該數(shù)據(jù)幀。除了目的主機(jī)外，所有接收到該 ARP 請求幀的主機(jī)和設(shè)備都會丟棄該 ARP 請求幀。
3. 目的主機(jī)收到請求后構(gòu)造并發(fā)送 ARP 應(yīng)答幀。
4. 源主機(jī)收到 ARP 響應(yīng)后，將目的主機(jī)的物理地址作為一條新記錄加入到 ARP 高速緩存表。

通過 ARP 過濾器進(jìn)行過濾，如圖 8

圖 8

由于本機(jī)的 ARP 緩存中有網(wǎng)關(guān)的記錄，因此不用發(fā)送相應(yīng)的廣播包，但是發(fā)現(xiàn) ARP 請求中填寫了目的的 MAC 地址和 IP 地址，并且目的也給予了響應(yīng)。這有可能是 ARP 具體實(shí)現(xiàn)過程中的刷新 ARP 緩存的一種優(yōu)化策略，因?yàn)閺V播包畢竟會造成網(wǎng)絡(luò)擁堵。

至此我們已經(jīng)分析到了四層模型中的鏈路層，最底層了。在獲取網(wǎng)關(guān)的 MAC 之后，會把該值填入 DNS 那條流中對應(yīng)的以太網(wǎng)層中，圖 6 中。網(wǎng)關(guān)在收到 DNS 報(bào)文之后，會使用路由選擇協(xié)議，根據(jù)目的 IP 地址，將該數(shù)據(jù)包轉(zhuǎn)發(fā)到下一跳網(wǎng)關(guān)路由器上，從而不斷的在一個(gè)個(gè)小的局域網(wǎng)內(nèi)部轉(zhuǎn)發(fā)，最終達(dá)到目標(biāo) IP 所在的局域網(wǎng)，然后送達(dá)目標(biāo) IP 服務(wù)器。這個(gè)過程和快遞的投送是類似的，快遞的投送有沒有借鑒該過程就不得而知了。

在 DNS 服務(wù)器收到相應(yīng)的請求之后，就將對應(yīng)的響應(yīng)報(bào)文返回給客戶端，如上圖 6，數(shù)據(jù)不斷通過路由選擇協(xié)議在一個(gè)個(gè)局域網(wǎng)之間流動。客戶在收到響應(yīng)報(bào)文后，將報(bào)文交由協(xié)議棧中不同的層進(jìn)行解封裝處理，最終獲取域名對對應(yīng)的 IP 地址。

當(dāng)然上述是基于 DNS 服務(wù)器中具有域名和 IP 的對應(yīng)關(guān)系，則會返回對應(yīng)的 IP 地址。如果域名服務(wù)器中沒有，會作何處理。因?yàn)?a target="_blank">域名服務(wù)器的行為，本地是無法觀測的，因此對于 DNS 原理作以下介紹。DNS 分為如下幾步：

1. 客戶端查看本地緩存表，如果本地緩存表中存在域名和 IP 的對應(yīng)關(guān)系，則可以獲取相應(yīng)的 IP 地址，在 windows 上的查看命令是 ipconfig /displaydns。當(dāng)然有的瀏覽器也會緩存 IP 和域名的映射表，以加快連接的建立過程。但是各個(gè)瀏覽器的實(shí)現(xiàn)并不一致，這里不再討論。
2. 如果不存在，向 DNS 服務(wù)器發(fā)送 DNS 請求報(bào)文，來獲取相應(yīng)的 IP 地址。你可能會問 DNS 服務(wù)器在哪里？上面已經(jīng)介紹過了，可以查看本機(jī) DNS 服務(wù)器的配置情況。
3. 同樣的道理 DNS 服務(wù)器也可能沒有相應(yīng)的域名和 IP 的映射表，這個(gè)時(shí)候由 DNS 服務(wù)器（而不是客戶端）會像根域名服務(wù)器發(fā)起請求 (全球 13 臺，主要控制在美國手中) 詢問，如果沒有，根域名給出的是頂級域名服務(wù)器的 IP，例如通知你去詢問 com 域服務(wù)器，com 域服務(wù)器上存在了所有 com 相關(guān)定義域名的一些記錄。當(dāng)然如果訪問的是 mail.cctv.com 這樣一個(gè)域名，com 域名服務(wù)器有可能會通知繼續(xù)去詢問 cctv 這樣一個(gè)域名服務(wù)器等等，這是一個(gè)不斷迭代的過程，由 DNS 服務(wù)器來完成。最終 DNS 服務(wù)器給出相應(yīng)的 IP 地址，或者是報(bào)錯。

至此獲取訪問 www.cctv.com 主頁的那條流中 IP 地址，圖 2 所示，主要是通過 DNS。在分析的過程中順便分析了 DNS 流中 MAC 地址的獲取方法以及數(shù)據(jù)如何在網(wǎng)絡(luò)中不斷的流動。有了前面 DNS 傳輸?shù)睦?，同樣的關(guān)于該 HTTP 流中自頂向下的封裝和 DNS 是一樣的。

三、自底向上

客戶端發(fā)送報(bào)文的時(shí)候，數(shù)據(jù)在協(xié)議棧中的流動是打上每層協(xié)議的協(xié)議頭?？蛻粼谑盏巾憫?yīng)報(bào)文后，是如何獲取最終的網(wǎng)頁數(shù)據(jù)的呢？報(bào)文自底向上交，由協(xié)議棧中不同的層進(jìn)行解封裝處理，MAC 層處理前 14 個(gè)字節(jié)，IP 層，TCP 層以及 HTTP 層根據(jù)該層頭部長度處理對應(yīng)的字節(jié)數(shù)。這是一個(gè)自底向上解碼的過程。在去掉所有協(xié)議頭之后，剩下的數(shù)據(jù)部分就是網(wǎng)頁數(shù)據(jù)。當(dāng)然整個(gè)的網(wǎng)頁數(shù)據(jù)是在將每一個(gè)包的網(wǎng)頁數(shù)據(jù)按照順序進(jìn)行組合后形成的，如圖 9：

圖 9

可以看到該網(wǎng)頁由 42 個(gè)報(bào)文組成，報(bào)之間的順序在 TCP 層已經(jīng)通過 Sequence Number 定義了，Sequence Number 表示的就是數(shù)據(jù)相對于開始的偏移，因此不用擔(dān)心亂序問題。既然數(shù)據(jù)在收到之后，是通過剝離協(xié)議頭，按照 TCP 的 Sequence Number 交給客戶端（也就是瀏覽器）時(shí)候，那么自然是可以根據(jù)報(bào)文數(shù)據(jù)來還原原始網(wǎng)頁數(shù)據(jù)的，原理已經(jīng)介紹過了。當(dāng)然相應(yīng)的還原方法有多種，我在上一篇 chat 中基于 Wireshark 插件介紹了一種簡單實(shí)用的方法，感興趣的可以參考之，見這里。

上述其實(shí)反映的是各層協(xié)議之間是存在一定聯(lián)系，就是應(yīng)用層數(shù)據(jù)順序是由 TCP 傳輸層來決定的。當(dāng)然 MAC 層有表示 IP 層協(xié)議的字段，以及 IP 層也有表示傳輸層協(xié)議字段也是各層聯(lián)系的一個(gè)體現(xiàn)。

我們接下來以一個(gè)更為明顯的例子加以說明。還記得在學(xué)習(xí) TCP/IP 協(xié)議的時(shí)候，TCP 有 6 個(gè)標(biāo)志位，像 ACK，F(xiàn)IN，SYN 都是喜聞樂見的標(biāo)志位。但是 PUSH 這個(gè)標(biāo)志位表示的是什么含義呢？在什么時(shí)候用呢？PUSH 標(biāo)志位所表達(dá)的是發(fā)送方通知接收方應(yīng)該盡快的將這個(gè)報(bào)文段交給應(yīng)用層。傳輸層及以下的數(shù)據(jù)往往是由系統(tǒng)所帶的協(xié)議棧進(jìn)行處理的，客戶端在收到一個(gè)個(gè)報(bào)文之后，經(jīng)由協(xié)議棧解封裝之后會立馬把數(shù)據(jù)交給應(yīng)用層去處理嗎？如果說在收到報(bào)文之后立馬就交給上層，這時(shí)候應(yīng)用層由于數(shù)據(jù)不全，可能也不會進(jìn)行處理。而且每來一個(gè)報(bào)文就交一次，效率很低。因此傳輸層一般會是隔幾個(gè)報(bào)文，統(tǒng)一上交數(shù)據(jù)。什么時(shí)候上交數(shù)據(jù)呢，就是在發(fā)送方將 PUSH 標(biāo)志位置 1 的時(shí)候。那么什么時(shí)候標(biāo)志位會置 1 呢，通常是發(fā)送端覺得傳輸?shù)臄?shù)據(jù)應(yīng)用層可以進(jìn)行處理了的時(shí)候，如圖 10 所示：

圖 10

由于通常網(wǎng)絡(luò)較好的時(shí)候，數(shù)據(jù)會以滿包狀態(tài)進(jìn)行傳輸，當(dāng)然這里面是 1494 個(gè)字節(jié)，當(dāng)一段數(shù)據(jù)傳輸完畢就會出現(xiàn)包長度下降，這時(shí)候 PUSH 就置 1，提示傳輸層盡快刷新數(shù)據(jù)交由應(yīng)用層處理。其實(shí)一個(gè)更為明顯的例子是 ssl 握手階段，在服務(wù)器將證書傳輸完畢之后，是需要應(yīng)用層趕緊處理，進(jìn)行證書鏈的驗(yàn)證，因此會設(shè)置 PUSH 字段來告知傳輸層盡快上交數(shù)據(jù)，如圖 11：

圖 11

可以找一個(gè) ssl 報(bào)文觀察，證書傳輸完畢時(shí)候，是否 PUSH 字段設(shè)置了。相信通過上述的分析，你不僅對于 PUSH 字段的實(shí)際應(yīng)用有所理解，也對各層協(xié)議之間的聯(lián)系印象深刻。

總結(jié)上述過程，對等傳輸就是 HTTP、TCP、IP、MAC 層分別建立鏈接。自頂向下就是分別打上各層的協(xié)議頭，各層的地址等信息如何獲取，又涉及到其他協(xié)議類似的過程。自底向上就是不斷解封裝過程，包括 MAC 層解封裝，IP 層解封裝，TCP 層解封裝，HTTP 層解封裝。當(dāng)然各層協(xié)議之間不是獨(dú)立的，存在一定的耦合，比如 PUSH 的作用等等?；谏鲜龅囊粋€(gè)分析，相信對于協(xié)議的分層機(jī)制，以及數(shù)據(jù)傳輸背后協(xié)議的工作流程就能夠徹底的明白了。

新聞名稱：訪問一個(gè)網(wǎng)頁背后所經(jīng)歷了哪些過程
路徑分享：http://redsoil1982.com.cn/news/98083.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設(shè)、App開發(fā)、定制網(wǎng)站、網(wǎng)站改版、網(wǎng)站內(nèi)鏈、做網(wǎng)站

廣告

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