前言

今天想通過抓包實(shí)驗(yàn)，鞏固一下所學(xué)習(xí)的網(wǎng)絡(luò)協(xié)議。同時(shí)，在知識(shí)點(diǎn)上會(huì)加上以前遇到的一些問題。這次實(shí)驗(yàn)并不是對(duì)所有的網(wǎng)絡(luò)協(xié)議都進(jìn)行分析，而是從下面這個(gè)問題出發(fā)(面試常被問)。從這一過程中復(fù)習(xí)學(xué)過的網(wǎng)絡(luò)協(xié)議。使用的工具是wireshark。

問題：在瀏覽器中輸入U(xiǎn)RL后，執(zhí)行的過程。會(huì)用到哪些協(xié)議？

例如：查詢www.163.com的IP地址過程如下：

(1) 域名解析(DNS)

? ? ? ? ? ① 在瀏覽器中輸入www.163.com域名，首先查看本機(jī)的緩存有無該域名記錄，如果沒有，則向本地DNS服務(wù)器請(qǐng)求；

? ? ? ? ? ② 本地DNS服務(wù)器收到請(qǐng)求后，查看是否有該域名的解析，若有，直接返回，完成解析；若沒有，則請(qǐng)求根域名服務(wù)器；

? ? ? ? ? ③ 根域名服務(wù)器收到請(qǐng)求后，根域名返回.com的服務(wù)器ip；

? ? ? ? ? ④ 本地域名服務(wù)器接到.com服務(wù)器地址后，向該域名服務(wù)器請(qǐng)求www.163.com，返回163.com域的服務(wù)器ip；

? ? ? ? ? ⑤ 本地域名服務(wù)器獲得163.com域的服務(wù)器ip后，發(fā)請(qǐng)求到該域名服務(wù)器，返回www.163.com域的服務(wù)器ip；

? ? ? ? ? ⑥ 本地域名服務(wù)器獲取該解析后，返回給主機(jī)，解析完成，同時(shí)自己也將IP地址緩存起來。

(2) 發(fā)起TCP的3次握手(TCP)

(3) 為了將消息從你的PC上傳到服務(wù)器上，需要用到IP協(xié)議、ARP協(xié)議。

(4) 建立TCP連接后發(fā)起HTTP請(qǐng)求。(HTTP)

(5) 服務(wù)器響應(yīng)HTTP請(qǐng)求

(6) 瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源（如js、css、圖片等）

(7) 斷開TCP連接

?

使用wireshark搜索某一目標(biāo)地址可以使用以下方法：

?

DNS協(xié)議

DNS報(bào)文格式如下：

DNS詢問報(bào)文如下：

Queries內(nèi)的格式：

(1) 查詢名：長度不固定，且不使用填充字節(jié)，一般該字段表示的就是需要查詢的域名（如果是反向查詢，則為IP，反向查詢即由IP地址反查域名）。

(2) 查詢類型：

類型	助記符	說明
1	A	由域名獲得IPv4地址
2	NS	查詢域名服務(wù)器
5	CNAME	查詢規(guī)范名稱
6	SOA	開始授權(quán)
11	WKS	熟知服務(wù)
12	PTR	把IP地址轉(zhuǎn)換成域名
13	HINFO	主機(jī)信息
15	MX	郵件交換
28	AAAA	由域名獲得IPv6地址
252	AXFR	傳送整個(gè)區(qū)的請(qǐng)求
255	ANY	對(duì)所有記錄的請(qǐng)求

(3) 查詢類：通常為1，表明是Internet數(shù)據(jù)(實(shí)驗(yàn)數(shù)據(jù)就為0x0001)。

資源記錄(RR)區(qū)域（包括回答區(qū)域，授權(quán)區(qū)域和附加區(qū)域）格式：

(1) 域名（2字節(jié)或不定長）：它的格式和Queries區(qū)域的查詢名字字段是一樣的。有一點(diǎn)不同就是，當(dāng)報(bào)文中域名重復(fù)出現(xiàn)的時(shí)候，該字段使用2個(gè)字節(jié)的偏移指針來表示。比如，在資源記錄中，域名通常是查詢問題部分的域名的重復(fù)，因此用2字節(jié)的指針來表示，具體格式是最前面的兩個(gè)高位是11，用于識(shí)別指針。其余的14位從DNS報(bào)文的開始處計(jì)數(shù)（從0開始），指出該報(bào)文中的相應(yīng)字節(jié)數(shù)。一個(gè)典型的例子，C00C(1100000000001100，12正好是頭部的長度，其正好指向Queries區(qū)域的查詢名字字段)。

(2) 查詢類型：表明資源紀(jì)錄的類型。

(3) 查詢類：對(duì)于Internet信息，總是IN。

(4) 生存時(shí)間（TTL）：以秒為單位，表示的是資源記錄的生命周期，一般用于當(dāng)?shù)刂方馕龀绦蛉〕鲑Y源記錄后決定保存及使用緩存數(shù)據(jù)的時(shí)間，它同時(shí)也可以表明該資源記錄的穩(wěn)定程度，極為穩(wěn)定的信息會(huì)被分配一個(gè)很大的值（比如86400，這是一天的秒數(shù)）。

(5) 資源數(shù)據(jù)：該字段是一個(gè)可變長字段，表示按照查詢段的要求返回的相關(guān)資源記錄的數(shù)據(jù)。可以是Address（表明查詢報(bào)文想要的回應(yīng)是一個(gè)IP地址）或者CNAME（表明查詢報(bào)文想要的回應(yīng)是一個(gè)規(guī)范主機(jī)名）等。

實(shí)驗(yàn)中的查詢問題區(qū)域：

?

DNS應(yīng)答報(bào)文：

可以看到Answer RRs和Authority RRs都置為1了。

Answers和Authoritative nameservers詳細(xì)信息如下：

?

Ps：DNS占用53號(hào)端口，同時(shí)使用TCP和UDP協(xié)議。DNS在區(qū)域傳輸?shù)臅r(shí)候使用TCP協(xié)議，其他時(shí)候使用UDP協(xié)議。

DNS區(qū)域傳輸?shù)臅r(shí)候使用TCP協(xié)議：

原因：輔域名服務(wù)器會(huì)定時(shí)（一般3小時(shí)）向主域名服務(wù)器進(jìn)行查詢以便了解數(shù)據(jù)是否有變動(dòng)。如有變動(dòng)，會(huì)執(zhí)行一次區(qū)域傳送，進(jìn)行數(shù)據(jù)同步。區(qū)域傳送使用TCP而不是UDP，因?yàn)閿?shù)據(jù)同步傳送的數(shù)據(jù)量比一個(gè)請(qǐng)求應(yīng)答的數(shù)據(jù)量要多得多。

域名解析時(shí)使用UDP協(xié)議：

原因：客戶端向DNS服務(wù)器查詢域名，一般返回的內(nèi)容都不超過512字節(jié)，用UDP傳輸即可。不用經(jīng)過三次握手，這樣DNS服務(wù)器負(fù)載更低，響應(yīng)更快。理論上說，客戶端也可以指定向DNS服務(wù)器查詢時(shí)用TCP，但事實(shí)上，很多DNS服務(wù)器進(jìn)行配置的時(shí)候，僅支持UDP查詢包。

?

HTTP協(xié)議

Connection：Keep-Alive表示采用長連接

請(qǐng)求行由方法字段、URL字段和HTTP協(xié)議版本字段。其中，方法字段嚴(yán)格區(qū)分大小寫，當(dāng)前HTTP協(xié)議中的方法都是大寫，方法字段如下介紹如下：

① GET：請(qǐng)求獲取 Request-URI (URI：通用資源標(biāo)識(shí)符，URL是其子集，URI注重的是標(biāo)識(shí)，而URL強(qiáng)調(diào)的是位置，可以將URL看成原始的URI)，所標(biāo)識(shí)的資源。

② POST：在 Request-URI 所標(biāo)識(shí)的資源后附加新的數(shù)據(jù)；支持HTML表單提交，表單中有用戶添入的數(shù)據(jù)，這些數(shù)據(jù)會(huì)發(fā)送到服務(wù)器端，由服務(wù)器存儲(chǔ)至某位置（例如發(fā)送處理程序）。

③ HEAD：請(qǐng)求Request-URI所標(biāo)識(shí)的資源響應(yīng)消息報(bào)頭，HEAD方法可以在響應(yīng)時(shí)不返回消息體。

④ PUT：與GET相反，請(qǐng)求服務(wù)器存儲(chǔ)一個(gè)資源，并用Request-URI做為其標(biāo)識(shí)；例如發(fā)布系統(tǒng)。

⑤ DELETE：請(qǐng)求刪除URL指向的資源。

⑥ OPTIONS：請(qǐng)求查詢服務(wù)器的性能，或者查詢與資源相關(guān)的選項(xiàng)。

⑦ TRACE：跟蹤請(qǐng)求要經(jīng)過的防火墻、代理或網(wǎng)關(guān)等，主要用于測試或診斷。

⑧ CONNECT：保留將來使用。

?

狀態(tài)碼	狀態(tài)描述	簡要說明
200	OK	客戶端請(qǐng)求成功
201	Created?	請(qǐng)求已經(jīng)被實(shí)現(xiàn)，而且有一個(gè)新的資源已經(jīng)依據(jù)請(qǐng)求的需要而創(chuàng)建，且其URI已經(jīng)隨Location頭信息返回。
301	Moved Permanently	被請(qǐng)求的資源已永久移動(dòng)到新位置，并且將來任何對(duì)此資源的引用都應(yīng)該使用本響應(yīng)返回的若干個(gè)URI之一
302	Found	在響應(yīng)報(bào)文中使用首部“Location: URL”指定臨時(shí)資源位置
304	Not Modified	條件式請(qǐng)求中使用
403	Forbidden	請(qǐng)求被服務(wù)器拒絕
404	Not Found	服務(wù)器無法找到請(qǐng)求的URL
405	Method Not Allowed	不允許使用此方法請(qǐng)求相應(yīng)的URL
500	Internal Server Error	服務(wù)器內(nèi)部錯(cuò)誤
502	Bad Gateway	代理服務(wù)器從上游收到了一條偽響應(yīng)
503	Service Unavailable	服務(wù)器此時(shí)無法提供服務(wù)，但將來可能可用
505	HTTP Version Not Supported	服務(wù)器不支持，或者拒絕支持在請(qǐng)求中使用的HTTP版本。這暗示著服務(wù)器不能或不愿使用與客戶端相同的版本。響應(yīng)中應(yīng)當(dāng)包含一個(gè)描述了為何版本不被支持以及服務(wù)器支持哪些協(xié)議的實(shí)體。

?

HTTP長連接和短連接

HTTP協(xié)議與TCP/IP協(xié)議的關(guān)系

HTTP的長連接和短連接本質(zhì)上是TCP長連接和短連接。HTTP屬于應(yīng)用層協(xié)議，在傳輸層使用TCP協(xié)議，在網(wǎng)絡(luò)層使用IP協(xié)議。IP協(xié)議主要解決網(wǎng)絡(luò)路由和尋址問題，TCP協(xié)議主要解決如何在IP層之上可靠的傳遞數(shù)據(jù)包，使在網(wǎng)絡(luò)上的另一端收到發(fā)端發(fā)出的所有包，并且順序與發(fā)出順序一致。TCP有可靠，面向連接的特點(diǎn)。

如何理解HTTP協(xié)議是無狀態(tài)的

HTTP協(xié)議是無狀態(tài)的，指的是協(xié)議對(duì)于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。也就是說，打開一個(gè)服務(wù)器上的網(wǎng)頁和你之前打開這個(gè)服務(wù)器上的網(wǎng)頁之間沒有任何聯(lián)系。HTTP是一個(gè)無狀態(tài)的面向連接的協(xié)議，無狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議（無連接）。

什么是長連接、短連接？

在HTTP/1.0中，默認(rèn)使用的是短連接。也就是說，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，但任務(wù)結(jié)束就中斷連接。如果客戶端瀏覽器訪問的某個(gè)HTML或其他類型的Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當(dāng)瀏覽器每遇到這樣一個(gè)Web資源，就會(huì)建立一個(gè)HTTP會(huì)話。

但從HTTP/1.1起，默認(rèn)使用長連接，用以保持連接特性。使用長連接的HTTP協(xié)議，會(huì)在響應(yīng)頭有加入這行代碼：Connection:keep-alive

在使用長連接的情況下，當(dāng)一個(gè)網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉，如果客戶端再次訪問這個(gè)服務(wù)器上的網(wǎng)頁，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會(huì)永久保持連接，它有一個(gè)保持時(shí)間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長連接要客戶端和服務(wù)端都支持長連接。

?

HTTP協(xié)議的長連接和短連接，實(shí)質(zhì)上是TCP協(xié)議的長連接和短連接。

TCP短連接

短連接的情況：client向server發(fā)起連接請(qǐng)求，server接到請(qǐng)求，然后雙方建立連接。client向server發(fā)送消息，server回應(yīng)client，然后一次讀寫就完成了，這時(shí)候雙方任何一個(gè)都可以發(fā)起close操作，不過一般都是client先發(fā)起close操作。為什么呢，一般的server不會(huì)回復(fù)完client后立即關(guān)閉連接的，當(dāng)然不排除有特殊的情況。從上面的描述看，短連接一般只會(huì)在client/server間傳遞一次讀寫操作

短連接的優(yōu)點(diǎn)是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段。

?

TCP長連接

長連接的情況：client向server發(fā)起連接，server接受client連接，雙方建立連接。client與server完成一次讀寫之后，它們之間的連接并不會(huì)主動(dòng)關(guān)閉，后續(xù)的讀寫操作會(huì)繼續(xù)使用這個(gè)連接。

首先說一下TCP/IP詳解上講到的TCP保活功能，保活功能主要為服務(wù)器應(yīng)用提供，服務(wù)器應(yīng)用希望知道客戶主機(jī)是否崩潰，從而可以代表客戶使用資源。如果客戶已經(jīng)消失，使得服務(wù)器上保留一個(gè)半開放的連接，而服務(wù)器又在等待來自客戶端的數(shù)據(jù)，則服務(wù)器將應(yīng)遠(yuǎn)等待客戶端的數(shù)據(jù)，保活功能就是試圖在服務(wù)器端檢測到這種半開放的連接。

如果一個(gè)給定的連接在兩小時(shí)內(nèi)沒有任何的動(dòng)作，則服務(wù)器就向客戶發(fā)一個(gè)探測報(bào)文段，客戶主機(jī)必須處于以下4個(gè)狀態(tài)之一：

(1)客戶主機(jī)依然正常運(yùn)行，并從服務(wù)器可達(dá)。客戶的TCP響應(yīng)正常，而服務(wù)器也知道對(duì)方是正常的，服務(wù)器在兩小時(shí)后將保活定時(shí)器復(fù)位。

(2)客戶主機(jī)已經(jīng)崩潰，并且關(guān)閉或者正在重新啟動(dòng)。在任何一種情況下，客戶的TCP都沒有響應(yīng)。服務(wù)端將不能收到對(duì)探測的響應(yīng)，并在75秒后超時(shí)。服務(wù)器總共發(fā)送10個(gè)這樣的探測，每個(gè)間隔75秒。如果服務(wù)器沒有收到一個(gè)響應(yīng)，它就認(rèn)為客戶主機(jī)已經(jīng)關(guān)閉并終止連接。

(3)客戶主機(jī)崩潰并已經(jīng)重新啟動(dòng)。服務(wù)器將收到一個(gè)對(duì)其保活探測的響應(yīng)，這個(gè)響應(yīng)是一個(gè)復(fù)位，使得服務(wù)器終止這個(gè)連接。

(4)客戶機(jī)正常運(yùn)行，但是服務(wù)器不可達(dá)，這種情況與2類似，TCP能發(fā)現(xiàn)的就是沒有收到探查的響應(yīng)。

短連接的操作步驟是：

建立連接——數(shù)據(jù)傳輸——關(guān)閉連接…建立連接——數(shù)據(jù)傳輸——關(guān)閉連接
長連接的操作步驟是：

建立連接——數(shù)據(jù)傳輸…(保持連接)…數(shù)據(jù)傳輸——關(guān)閉連接

?

長連接和短連接的優(yōu)點(diǎn)和缺點(diǎn)

由上可以看出，長連接可以省去較多的TCP建立和關(guān)閉的操作，減少浪費(fèi)，節(jié)約時(shí)間。對(duì)于頻繁請(qǐng)求資源的客戶來說，較適用長連接。不過這里存在一個(gè)問題，存活功能的探測周期太長，還有就是它只是探測TCP連接的存活，屬于比較斯文的做法，遇到惡意的連接時(shí)，保活功能就不夠使了。在長連接的應(yīng)用場景下，client端一般不會(huì)主動(dòng)關(guān)閉它們之間的連接，client與server之間的連接如果一直不關(guān)閉的話，會(huì)存在一個(gè)問題，隨著客戶端連接越來越多，server早晚有扛不住的時(shí)候，這時(shí)候server端需要采取一些策略，如關(guān)閉一些長時(shí)間沒有讀寫事件發(fā)生的連接，這樣可以避免一些惡意連接導(dǎo)致server端服務(wù)受損；如果條件再允許就可以以客戶端機(jī)器為顆粒度，限制每個(gè)客戶端的最大長連接數(shù)，這樣可以完全避免某個(gè)蛋疼的客戶端連累后端服務(wù)。

短連接對(duì)于服務(wù)器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請(qǐng)求頻繁，將在TCP的建立和關(guān)閉操作上浪費(fèi)時(shí)間和帶寬。長連接和短連接的產(chǎn)生在于client和server采取的關(guān)閉策略，具體的應(yīng)用場景采用具體的策略，沒有十全十美的選擇，只有合適的選擇。

?

什么時(shí)候用長連接、短連接？

長連接多用于操作頻繁，點(diǎn)對(duì)點(diǎn)的通訊，而且連接數(shù)不能太多情況。每個(gè)TCP連接都需要三步握手，這需要時(shí)間，如果每個(gè)操作都是先連接，再操作的話那么處理速度會(huì)降低很多，所以每個(gè)操作完后都不斷開，次處理時(shí)直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接，如果用短連接頻繁的通信會(huì)造成socket錯(cuò)誤，而且頻繁的socket創(chuàng)建也是對(duì)資源的浪費(fèi)。

像Web網(wǎng)站的http服務(wù)一般都用短鏈接，因?yàn)殚L連接對(duì)于服務(wù)端來說會(huì)耗費(fèi)一定的資源(具體還是要看實(shí)際情況以及用戶需求)。若Web網(wǎng)站的操作比較頻繁，而且有成千上萬甚至上億的客戶端，短連接會(huì)更節(jié)省資源。如果用長連接，同時(shí)有成千上萬的用戶，如果每個(gè)用戶都占用一個(gè)連接的話，資源花費(fèi)可想而知。所以在并發(fā)量大，而且每個(gè)用戶無需頻繁操作的情況下使用短連接會(huì)更好。

?

TCP協(xié)議

TCP報(bào)文格式：

TCP三次握手：

TCP四次揮手：

TCP報(bào)文詳細(xì)分析(第三次握手)：

TCP報(bào)文：[29 05 01 bb f4 0a 2c 77 1f a9 79 d2 50 10 01 00 b9 84 00 00] 為了更易理解：[29 05 01 bb][f4 0a 2c 77][1f a9 79 d2][50 10 01 00][b9 84 00 00] 源端口：2905(HEX) = 10501(DEC) 目的端口：01bb(HEX) = 443(DEC) 序號(hào)：1 確認(rèn)號(hào)：1 十六進(jìn)制[50 10]轉(zhuǎn)化成二進(jìn)制[0101 0000 0001 0000] 數(shù)據(jù)偏移(占4位)：單位是4個(gè)字節(jié)，此字段值為5，所以TCP首部的長度是20字節(jié)。 保留(占6位)：保留為今后使用，目前置為0。 緊急位URG:0 確認(rèn)位ACK:1 推送位PSH:0 復(fù)位位RST:0 同步位SYN:0 終止位FIN:0 窗口：0100(HEX) = 256(DEC) 檢驗(yàn)和：0xb984 緊急指針：0

需要注意的是：四次揮手的序號(hào)和確認(rèn)號(hào)。

在TCP要斷開連接時(shí)，由客戶端發(fā)送結(jié)束報(bào)文。[FIN,ACK]報(bào)文(第三次揮手)的序號(hào)等于最后一次[ACK]報(bào)文的確認(rèn)號(hào)加1，而它的確認(rèn)號(hào)等于最后一次[ACK]報(bào)文的序號(hào)。

?

UDP協(xié)議

UDP報(bào)文格式：

UDP報(bào)文：[09 06 c3 3b][00 57 05 01] 源端口：0906(HEX) = 2310(DEC) 目的端口：c33b(HEX) = 49979(DEC) 長度：57(HEX) = 87(DEC) 校驗(yàn)和：0x0501

?

IP協(xié)議

IP報(bào)文格式：

IP報(bào)文：[45 00 00 28][1c de 40 00][40 06 00 00][0a 66 09 5a][27 60 84 45] 版本：4 首部長度(單位是4字節(jié))：20 區(qū)分服務(wù)：0x00 總長度(單位是字節(jié))：40 標(biāo)識(shí)：0x1cde 十六進(jìn)制[40 00]轉(zhuǎn)化成二進(jìn)制[0100 0000 0000 0000] 標(biāo)志(占3位，即010)：Reserved bit: Not setDo not fragmaent:setMore fragments:Not set 片偏移(占13位)：0 生存時(shí)間：64 協(xié)議：TCP 首部檢驗(yàn)和：0x0000 源地址：10.102.9.90 目的地址：39.96.132.69

?

ARP協(xié)議

ARP協(xié)議格式：

硬件類型：Ethernet(1) 協(xié)議類型：IPv4(0x0800) 硬件地址長度：6 協(xié)議地址長度：4 OP:request(1) 發(fā)送者M(jìn)AC地址：Hewlettp_14:c9:c1 (34:64:a9:14:c9:c1) 發(fā)送者IP地址：10.102.7.206 目標(biāo)MAC地址：00:00:00_00:00:00 (00:00:00:00:00:00) 目標(biāo)IP地址：10.102.127.254

?

參考：

http://www.cnblogs.com/0201zcr/p/4694945.html

https://jocent.me/2017/06/18/dns-protocol-principle.html#_label0_0

總結(jié)

以上是生活随笔為你收集整理的使用wireshark抓包并进行网络协议分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。