前言

今天想通過抓包實驗，鞏固一下所學習的網絡協議。同時，在知識點上會加上以前遇到的一些問題。這次實驗并不是對所有的網絡協議都進行分析，而是從下面這個問題出發(面試常被問)。從這一過程中復習學過的網絡協議。使用的工具是wireshark。

問題：在瀏覽器中輸入URL后，執行的過程。會用到哪些協議？

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

(1) 域名解析(DNS)

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

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

? ? ? ? ? ③ 根域名服務器收到請求后，根域名返回.com的服務器ip；

? ? ? ? ? ④ 本地域名服務器接到.com服務器地址后，向該域名服務器請求www.163.com，返回163.com域的服務器ip；

? ? ? ? ? ⑤ 本地域名服務器獲得163.com域的服務器ip后，發請求到該域名服務器，返回www.163.com域的服務器ip；

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

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

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

(4) 建立TCP連接后發起HTTP請求。(HTTP)

(5) 服務器響應HTTP請求

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

(7) 斷開TCP連接

?

使用wireshark搜索某一目標地址可以使用以下方法：

?

DNS協議

DNS報文格式如下：

DNS詢問報文如下：

Queries內的格式：

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

(2) 查詢類型：

類型	助記符	說明
1	A	由域名獲得IPv4地址
2	NS	查詢域名服務器
5	CNAME	查詢規范名稱
6	SOA	開始授權
11	WKS	熟知服務
12	PTR	把IP地址轉換成域名
13	HINFO	主機信息
15	MX	郵件交換
28	AAAA	由域名獲得IPv6地址
252	AXFR	傳送整個區的請求
255	ANY	對所有記錄的請求

(3) 查詢類：通常為1，表明是Internet數據(實驗數據就為0x0001)。

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

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

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

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

(4) 生存時間（TTL）：以秒為單位，表示的是資源記錄的生命周期，一般用于當地址解析程序取出資源記錄后決定保存及使用緩存數據的時間，它同時也可以表明該資源記錄的穩定程度，極為穩定的信息會被分配一個很大的值（比如86400，這是一天的秒數）。

(5) 資源數據：該字段是一個可變長字段，表示按照查詢段的要求返回的相關資源記錄的數據。可以是Address（表明查詢報文想要的回應是一個IP地址）或者CNAME（表明查詢報文想要的回應是一個規范主機名）等。

實驗中的查詢問題區域：

?

DNS應答報文：

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

Answers和Authoritative nameservers詳細信息如下：

?

Ps：DNS占用53號端口，同時使用TCP和UDP協議。DNS在區域傳輸的時候使用TCP協議，其他時候使用UDP協議。

DNS區域傳輸的時候使用TCP協議：

原因：輔域名服務器會定時（一般3小時）向主域名服務器進行查詢以便了解數據是否有變動。如有變動，會執行一次區域傳送，進行數據同步。區域傳送使用TCP而不是UDP，因為數據同步傳送的數據量比一個請求應答的數據量要多得多。

域名解析時使用UDP協議：

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

?

HTTP協議

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

請求行由方法字段、URL字段和HTTP協議版本字段。其中，方法字段嚴格區分大小寫，當前HTTP協議中的方法都是大寫，方法字段如下介紹如下：

① GET：請求獲取 Request-URI (URI：通用資源標識符，URL是其子集，URI注重的是標識，而URL強調的是位置，可以將URL看成原始的URI)，所標識的資源。

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

③ HEAD：請求Request-URI所標識的資源響應消息報頭，HEAD方法可以在響應時不返回消息體。

④ PUT：與GET相反，請求服務器存儲一個資源，并用Request-URI做為其標識；例如發布系統。

⑤ DELETE：請求刪除URL指向的資源。

⑥ OPTIONS：請求查詢服務器的性能，或者查詢與資源相關的選項。

⑦ TRACE：跟蹤請求要經過的防火墻、代理或網關等，主要用于測試或診斷。

⑧ CONNECT：保留將來使用。

?

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

?

HTTP長連接和短連接

HTTP協議與TCP/IP協議的關系

HTTP的長連接和短連接本質上是TCP長連接和短連接。HTTP屬于應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的傳遞數據包，使在網絡上的另一端收到發端發出的所有包，并且順序與發出順序一致。TCP有可靠，面向連接的特點。

如何理解HTTP協議是無狀態的

HTTP協議是無狀態的，指的是協議對于事務處理沒有記憶能力，服務器不知道客戶端是什么狀態。也就是說，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯系。HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協議（無連接）。

什么是長連接、短連接？

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

但從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭有加入這行代碼：Connection:keep-alive

在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接要客戶端和服務端都支持長連接。

?

HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。

TCP短連接

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

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

?

TCP長連接

長連接的情況：client向server發起連接，server接受client連接，雙方建立連接。client與server完成一次讀寫之后，它們之間的連接并不會主動關閉，后續的讀寫操作會繼續使用這個連接。

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

如果一個給定的連接在兩小時內沒有任何的動作，則服務器就向客戶發一個探測報文段，客戶主機必須處于以下4個狀態之一：

(1)客戶主機依然正常運行，并從服務器可達。客戶的TCP響應正常，而服務器也知道對方是正常的，服務器在兩小時后將保活定時器復位。

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

(3)客戶主機崩潰并已經重新啟動。服務器將收到一個對其保活探測的響應，這個響應是一個復位，使得服務器終止這個連接。

(4)客戶機正常運行，但是服務器不可達，這種情況與2類似，TCP能發現的就是沒有收到探查的響應。

短連接的操作步驟是：

建立連接——數據傳輸——關閉連接…建立連接——數據傳輸——關閉連接
長連接的操作步驟是：

建立連接——數據傳輸…(保持連接)…數據傳輸——關閉連接

?

長連接和短連接的優點和缺點

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

短連接對于服務器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費時間和帶寬。長連接和短連接的產生在于client和server采取的關閉策略，具體的應用場景采用具體的策略，沒有十全十美的選擇，只有合適的選擇。

?

什么時候用長連接、短連接？

長連接多用于操作頻繁，點對點的通訊，而且連接數不能太多情況。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那么處理速度會降低很多，所以每個操作完后都不斷開，次處理時直接發送數據包就OK了，不用建立TCP連接。例如：數據庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket創建也是對資源的浪費。

像Web網站的http服務一般都用短鏈接，因為長連接對于服務端來說會耗費一定的資源(具體還是要看實際情況以及用戶需求)。若Web網站的操作比較頻繁，而且有成千上萬甚至上億的客戶端，短連接會更節省資源。如果用長連接，同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，資源花費可想而知。所以在并發量大，而且每個用戶無需頻繁操作的情況下使用短連接會更好。

?

TCP協議

TCP報文格式：

TCP三次握手：

TCP四次揮手：

TCP報文詳細分析(第三次握手)：

TCP報文：[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) 序號：1 確認號：1 十六進制[50 10]轉化成二進制[0101 0000 0001 0000] 數據偏移(占4位)：單位是4個字節，此字段值為5，所以TCP首部的長度是20字節。 保留(占6位)：保留為今后使用，目前置為0。 緊急位URG:0 確認位ACK:1 推送位PSH:0 復位位RST:0 同步位SYN:0 終止位FIN:0 窗口：0100(HEX) = 256(DEC) 檢驗和：0xb984 緊急指針：0

需要注意的是：四次揮手的序號和確認號。

在TCP要斷開連接時，由客戶端發送結束報文。[FIN,ACK]報文(第三次揮手)的序號等于最后一次[ACK]報文的確認號加1，而它的確認號等于最后一次[ACK]報文的序號。

?

UDP協議

UDP報文格式：

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

?

IP協議

IP報文格式：

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

?

ARP協議

ARP協議格式：

硬件類型：Ethernet(1) 協議類型：IPv4(0x0800) 硬件地址長度：6 協議地址長度：4 OP:request(1) 發送者MAC地址：Hewlettp_14:c9:c1 (34:64:a9:14:c9:c1) 發送者IP地址：10.102.7.206 目標MAC地址：00:00:00_00:00:00 (00:00:00:00:00:00) 目標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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。