1. 主要教學(xué)內(nèi)容

• 實(shí)驗(yàn)內(nèi)容：使用Wireshark捕獲數(shù)據(jù)包，根據(jù)捕獲的相關(guān)數(shù)據(jù)包分別對(duì)HTTP、DNS協(xié)議展開(kāi)分析。額外內(nèi)容：利用fiddler軟件對(duì)HTTPS協(xié)議進(jìn)行分析。
• 所需學(xué)時(shí)：1。
• 重難點(diǎn)：HTTP和DNS協(xié)議的報(bào)文結(jié)構(gòu)。
• 周次：第3周。
• 教材相關(guān)章節(jié)：2.4、2.7。

2. HTTP協(xié)議

HTTP(超文本傳輸協(xié)議)是一個(gè)基于請(qǐng)求與響應(yīng)模式的、無(wú)狀態(tài)(指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力)的應(yīng)用層協(xié)議，常基于 TCP 的連接方式。HTTP 1.1版本中給出一種持續(xù)連接的機(jī)制，絕大多數(shù)的 Web 應(yīng)用都構(gòu)建在 HTTP 協(xié)議之上。
在 HTTP 的請(qǐng)求和應(yīng)答標(biāo)準(zhǔn)中，客戶端是終端用戶，服務(wù)器端是網(wǎng)站。通過(guò)使用 Web瀏覽器或者其他的工具，客戶端發(fā)起一個(gè)到服務(wù)器上指定端口(默認(rèn)端口為 80)的 HTTP請(qǐng)求，這個(gè)客戶端稱為用戶代理(User Agent)。應(yīng)答的服務(wù)器上存儲(chǔ)著一些資源，比如HTML 文件和圖像，這個(gè)應(yīng)答服務(wù)器稱為源服務(wù)器(Origin Server)。在用戶代理和源服務(wù)器中間可能存在多個(gè)中間層，比如代理、網(wǎng)關(guān)或者隧道(Tunnels)。盡管 TCP/IP 協(xié)議是互聯(lián)網(wǎng)上最流行的應(yīng)用，但是 HTTP 協(xié)議并沒(méi)有規(guī)定必須使用它和它支持的層。事實(shí)上HTTP 可以在任何其他互聯(lián)網(wǎng)協(xié)議或其他網(wǎng)絡(luò)上實(shí)現(xiàn)。HTTP 只假定其下層協(xié)議提供可靠的傳輸，任何能夠提供這種保證的協(xié)議都可以被其使用。
通常情況下，由 HTTP 客戶端發(fā)起一個(gè)請(qǐng)求，建立一個(gè)到服務(wù)器指定端口的 TCP 連接。HTTP 服務(wù)器則在該端口監(jiān)聽(tīng)客戶端發(fā)送過(guò)來(lái)的請(qǐng)求。一旦收到請(qǐng)求，服務(wù)器向客戶端發(fā)回一個(gè)狀態(tài)行和響應(yīng)的消息,消息的消息體可能是請(qǐng)求的文件、錯(cuò)誤消息或者其他一些信息。

• HTTP有兩類報(bào)文，HTTP的請(qǐng)求報(bào)文和響應(yīng)報(bào)文結(jié)構(gòu)(SP:空格；crlf :回車換行)：

• HTTP 協(xié)議定義了8種方法表示對(duì)指定數(shù)據(jù)的操作：

• HTTP請(qǐng)求報(bào)文分為三部分：請(qǐng)求行、消息報(bào)頭、請(qǐng)求正文。

• 在接收和解釋請(qǐng)求消息后，服務(wù)器返回一個(gè)HTTP響應(yīng)消息(Request Mesage)。 HTTP 響應(yīng)消息也由三部分組成，分別是狀態(tài)行、消息報(bào)頭、響應(yīng)正文。

• 狀態(tài)碼由三位數(shù)宇組成，第 一位數(shù)字定義了響應(yīng)的類別，有以下5種可能取值。

1xx：指示信息，表示請(qǐng)求已接收，繼續(xù)處理。

2xx：成功，表示請(qǐng)求已被成功接收、理解、接受。

3xx：重定向，要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作。

4xx：客戶端錯(cuò)誤，請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)。

5xx：服務(wù)器端錯(cuò)誤,服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求。

• 常見(jiàn)狀態(tài)碼：

3. HTTP分析實(shí)驗(yàn)

【實(shí)驗(yàn)?zāi)康摹?/h3>

(1) 掌握 HTTP 協(xié)議獲取網(wǎng)頁(yè)的流程。
(2) 了解 HTTP 請(qǐng)求報(bào)文和響應(yīng)報(bào)文的格式,并進(jìn)行報(bào)文分析。
(3) 了解 HTTP 1.0 和 HTTP 1.1的區(qū)別。

【實(shí)驗(yàn)原理】

HTTP 協(xié)議定義了 Web 客戶端(瀏覽器)如何向 Web 站點(diǎn)請(qǐng)求 Web 頁(yè)面以及 Web 服務(wù)器如何將 Web 頁(yè)面?zhèn)魉徒o客戶機(jī)。具體而言，這是通過(guò)客戶端發(fā)送 HTTP 請(qǐng)求報(bào)文和HTTP 響應(yīng)報(bào)文實(shí)現(xiàn)的。當(dāng)用戶請(qǐng)求一個(gè)頁(yè)面時(shí)(在瀏覽器中輸人網(wǎng)址或者單擊網(wǎng)頁(yè)某一個(gè)鏈接)，瀏覽器會(huì)向 Web 服務(wù)器發(fā)出對(duì)該頁(yè)及其引用的相關(guān)對(duì)象的 HTTP 請(qǐng)求報(bào)文，服務(wù)器響應(yīng)這些請(qǐng)求報(bào)文,生成 HTTP 響應(yīng)報(bào)文，并將請(qǐng)求的對(duì)象附在 HTTP 響應(yīng)報(bào)文后發(fā)送給客戶端。

由于網(wǎng)頁(yè)文檔的傳輸需要可靠性的保證，所以 HTTP 協(xié)議使用傳輸層的 TCP 協(xié)議作為載體。TCP 協(xié)議是一個(gè)面向連接的協(xié)議，提供可靠的數(shù)據(jù)傳輸，HTTP 協(xié)議在默認(rèn)的情況下使用TCP的80端口。

HTTP 協(xié)議是無(wú)狀態(tài)的協(xié)議，即當(dāng)服務(wù)器收到某個(gè)客戶端發(fā)送的 HTTP 請(qǐng)求報(bào)文時(shí)， 并不清楚該客戶端是否曾經(jīng)發(fā)送過(guò)相同的 HTTP 請(qǐng)求報(bào)文，即 HTTP 協(xié)議本身不會(huì)維護(hù)客戶端和服務(wù)器端的狀態(tài)。

非持久連接方式與網(wǎng)頁(yè)上的每個(gè)對(duì)象都需要建立一個(gè)TCP 連接，效率不高，HTTP 1. 0 只能使用非持久連接方式。持久連接方式使用一個(gè)TCP 連接，其流水線作業(yè)方式比非流水線作業(yè)方式效率高。HTTP 1. 1既能使用非持久連接方式又能使用持久連接方式，默認(rèn)方式下使用持久連接的流水線作業(yè)方式。持久連接的缺點(diǎn)是對(duì)服務(wù)器的性能要求比較高。因?yàn)榉?wù)器對(duì)于每個(gè)TCP 的連接都需要花費(fèi)較長(zhǎng)的時(shí)間，而每個(gè)TCP 連接都需要占用服務(wù)器響應(yīng)的資源, 非持久連接由于連接釋放得快，資源的釋放也相對(duì)快，并且連接客戶的數(shù)量對(duì)于持久連接而言相對(duì)要少一些。

HTTP報(bào)文包括HTTP請(qǐng)求報(bào)文和HTTP響應(yīng)報(bào)文。這兩種報(bào)文在實(shí)際的傳輸中都是以 ASCII 碼方式編碼的。HTTP 報(bào)文格式反映了HTTP 協(xié)議的核心內(nèi)容，包括客戶端如何向服務(wù)器端請(qǐng)求對(duì)象，通信雙方需要協(xié)商哪些內(nèi)容等。

【實(shí)驗(yàn)內(nèi)容】

• 步驟 1：打開(kāi) Wireshark，選擇監(jiān)聽(tīng)網(wǎng)卡，設(shè)置過(guò)濾規(guī)則(只捕獲 HTTP 的報(bào)文)，開(kāi)始偵聽(tīng)。

• 步驟 2：打開(kāi)瀏覽器，輸人網(wǎng)址(例如 www.baidu.com)，捕獲數(shù)據(jù)

• 步驟 3：分析捕獲的數(shù)據(jù)包，回答以下問(wèn)題。

(1) 在捕獲的報(bào)文中，共有幾種 HTTP 報(bào)文？客戶機(jī)與服務(wù)器之間共建立了幾個(gè)連接？服務(wù)器和客戶機(jī)分別使用了哪幾個(gè)端口？

(2) 在捕獲的 HTTP 報(bào)文中，選擇一個(gè) HTTP 請(qǐng)求報(bào)文和對(duì)應(yīng)的 HTTP 應(yīng)答報(bào)文，按圖 2-8 所示分析它們的字段，并將分析結(jié)果填人表 2-4 和表 2-5 中。

(3) 綜合分析捕獲的報(bào)文，理解HTTP協(xié)議的工作過(guò)程，將結(jié)果填人表2-6中。

(4) 在第1個(gè)和第3個(gè)HTTP會(huì)話中，Web服務(wù)器對(duì) Web客戶端GET請(qǐng)求的響應(yīng)是什么?

【實(shí)驗(yàn)思考】

(1) 實(shí)驗(yàn)中哪臺(tái)計(jì)算機(jī)啟動(dòng)了 HTTP 會(huì)話？是如何啟動(dòng)的？

(2) 哪臺(tái)計(jì)算機(jī)首先發(fā)出了結(jié)束 HTTP 會(huì)話的信號(hào)? 是如何發(fā)出的？

(3) GET 方法取回由 Request-URI標(biāo)識(shí)的信息，POST 方法可以用于提交表單。請(qǐng)尋找一個(gè)有表單提交特征的網(wǎng)頁(yè)，訪問(wèn)該網(wǎng)頁(yè)，捕獲數(shù)據(jù)包并分析請(qǐng)求方法中的 GET 和POST 方法。

4. HTTP分析實(shí)驗(yàn)可能遇到的問(wèn)題

4.1 捕捉不到http報(bào)文

可能原因：不是無(wú)法抓取 http包，是抓到了沒(méi)有解密，顯示還是TLS。

解決方法：

Windows系統(tǒng)參考：為什么我的 Wireshark 抓不到/抓不全 HTTP 數(shù)據(jù)包 ？

MAC系統(tǒng)參考：Mac電腦安裝配置Wireshark 抓包工具，解決Https無(wú)法抓包問(wèn)題

4.2 百度是使用HTTPS協(xié)議進(jìn)行傳輸

我們以為捕獲不到http報(bào)文，實(shí)際上是因?yàn)榫W(wǎng)站加密了，通過(guò)上述方法得到http報(bào)文中可能有許多看不懂的地方，而且發(fā)現(xiàn)使用的端口號(hào)是443而不是80，這是因?yàn)榇蟛糠志W(wǎng)站都是使用HTTPS協(xié)議進(jìn)行傳輸，以提高數(shù)據(jù)傳輸?shù)陌踩浴?/p>

但是我們無(wú)法通過(guò)Wireshark進(jìn)行捕捉數(shù)據(jù)包，因此，我們可以嘗試一些使用HTTP的網(wǎng)站。

盡管如此，仍然有一些HTTP開(kāi)頭的網(wǎng)站存在。這些網(wǎng)站可能是因?yàn)檫\(yùn)營(yíng)成本較低、沒(méi)有很多個(gè)人信息輸入需求，或者本身不涉及敏感信息等原因。比如旅游網(wǎng)站“馬蜂窩”（http://www.mafengwo.cn/）。

4.3 Wireshark獲得數(shù)據(jù)太多如何篩選

• 我們可以通過(guò)網(wǎng)站的前端頁(yè)面獲得網(wǎng)站的IP地址：

通過(guò)Wireshark中的過(guò)濾器，篩選出該IP的數(shù)據(jù)：

此時(shí)就能清晰的看到http請(qǐng)求報(bào)文，以及http響應(yīng)報(bào)文。

進(jìn)行對(duì)應(yīng)分析即可：

4.4 http報(bào)文字段含義不清楚

General（通用部分）：

• Request URL：請(qǐng)求的URL地址，即請(qǐng)求的目標(biāo)資源。
• Request Method：請(qǐng)求方法，表示客戶端對(duì)資源的請(qǐng)求操作。常見(jiàn)的方法有GET、POST、PUT、DELETE等。
• Status Code：狀態(tài)碼，表示服務(wù)器對(duì)請(qǐng)求的處理結(jié)果。常見(jiàn)的狀態(tài)碼有200 OK（成功）、404 Not Found（未找到資源）、500 Internal Server Error（服務(wù)器內(nèi)部錯(cuò)誤）等。
• Remote Address：這個(gè)字段不是HTTP標(biāo)準(zhǔn)中的一部分，而是指示客戶端的IP地址和端口號(hào)，表示請(qǐng)求的源IP地址。在HTTP請(qǐng)求中，這個(gè)字段顯示客戶端的IP地址和端口號(hào)，通常是代理服務(wù)器或負(fù)載均衡器的地址，而不是最終用戶的真實(shí)IP地址。
• Referrer Policy：Referrer是HTTP請(qǐng)求頭部的一個(gè)字段，用于指示請(qǐng)求的來(lái)源URL，即訪問(wèn)當(dāng)前頁(yè)面的前一個(gè)頁(yè)面的URL。Referrer Policy則是為了控制Referrer頭部的發(fā)送情況而定義的策略。Referrer Policy可以設(shè)置為no-referrer（不發(fā)送Referrer頭部）、no-referrer-when-downgrade（只在從HTTPS網(wǎng)頁(yè)導(dǎo)航到HTTP網(wǎng)頁(yè)時(shí)不發(fā)送Referrer頭部）、origin（僅發(fā)送源信息，但不包含路徑等具體內(nèi)容）、strict-origin（僅在協(xié)議安全的情況下發(fā)送完整的源信息）等。

Request Headers（請(qǐng)求頭部）：

• User-Agent：用戶代理，標(biāo)識(shí)發(fā)起請(qǐng)求的客戶端應(yīng)用程序或設(shè)備類型，例如瀏覽器名稱和版本。
• Accept：客戶端可接受的響應(yīng)內(nèi)容類型，通常是MIME類型（例如text/html、application/json等）。
• Accept-Language：客戶端可接受的語(yǔ)言類型，用于指定客戶端希望接收的語(yǔ)言版本。
• Cookie：包含客戶端發(fā)送給服務(wù)器的HTTP cookie信息，通常用于會(huì)話管理。
• Referer：表示請(qǐng)求的來(lái)源URL，即訪問(wèn)當(dāng)前頁(yè)面的前一個(gè)頁(yè)面的URL，跨域時(shí)基于安全不會(huì)給全
• Authorization：用于在請(qǐng)求中傳遞認(rèn)證信息，例如JWT或者原始的用于HTTP基本認(rèn)證的用戶名和密碼。
• Cache-Control：緩存控制指令，用于指定緩存策略，例如no-cache（不使用緩存）或max-age（緩存的最大有效時(shí)間）等。
• Host：表示請(qǐng)求的目標(biāo)主機(jī)的域名或IP地址。在HTTP/1.1中，Host頭部是必需的，用于指定請(qǐng)求的目標(biāo)服務(wù)器和端口號(hào)。例如：www.example.com:8080
• Origin：Origin頭部用于指示請(qǐng)求的來(lái)源，即發(fā)起請(qǐng)求的網(wǎng)頁(yè)所在的源，包含協(xié)議、域名和端口號(hào)。它通常用于跨域請(qǐng)求中，由瀏覽器自動(dòng)添加。例如：http://www.origin.com
• Connection：Connection頭部用于控制是否在請(qǐng)求完成后保持與服務(wù)器的連接。它是一個(gè)非標(biāo)準(zhǔn)的HTTP頭部，在HTTP/1.1中引入了持久連接（Persistent Connection）后，取代了早期版本的Proxy-Connection和Keep-Alive頭部。Connection頭部的取值通常有幾種：
• close：請(qǐng)求完成后關(guān)閉與服務(wù)器的連接。即，每次請(qǐng)求都會(huì)新建一個(gè)連接。
• keep-alive：請(qǐng)求完成后保持與服務(wù)器的連接，以便在同一連接上進(jìn)行多個(gè)請(qǐng)求。這是持久連接的一種方式，減少了連接的建立和關(guān)閉的開(kāi)銷，提高了請(qǐng)求的效率。
• Upgrade：允許客戶端和服務(wù)器協(xié)商更高級(jí)的協(xié)議。例如，WebSocket可以通過(guò)此頭部實(shí)現(xiàn)從HTTP協(xié)議升級(jí)到WebSocket協(xié)議。
• 在現(xiàn)代的HTTP/1.1中，持久連接是默認(rèn)啟用的，即默認(rèn)使用keep-alive，除非顯示指定close，因此通常情況下可以不必手動(dòng)添加Connection頭部。

Response Headers（響應(yīng)頭部）：

• Content-Type：響應(yīng)的內(nèi)容類型，表示服務(wù)器返回的數(shù)據(jù)的MIME類型，例如text/html、application/json等。
• Content-Length：響應(yīng)的內(nèi)容長(zhǎng)度，表示服務(wù)器返回?cái)?shù)據(jù)的字節(jié)數(shù)。
• Set-Cookie：設(shè)置HTTP cookie，服務(wù)器通過(guò)該頭部向客戶端發(fā)送新的cookie信息，用于會(huì)話管理。
• Expires：指定響應(yīng)內(nèi)容的過(guò)期時(shí)間，即緩存失效時(shí)間點(diǎn)。
• Cache-Control：緩存控制指令，用于指定緩存策略，例如no-cache（不緩存）或max-age（緩存的最大有效時(shí)間）等。
• Server：指示服務(wù)器軟件的名稱和版本。

4.5 http協(xié)議工作過(guò)程怎么填寫(xiě)

可以參考：

5. DNS協(xié)議

DNS(Domain Name System，域名系統(tǒng))用于命名組織到域?qū)哟谓Y(jié)構(gòu)中的計(jì)算機(jī)和網(wǎng)絡(luò)服務(wù)。
DNS 協(xié)議分成包頭和數(shù)據(jù)兩部分。如圖所示，該報(bào)文由12B的首部和4個(gè)長(zhǎng)度可變的字段組成：

各字段含義：

• 標(biāo)識(shí)字段：由客戶程序設(shè)置并有服務(wù)器返回結(jié)果，16 位，在對(duì)應(yīng)的query和response報(bào)文中有著相同的ID，可以在捕獲到的包中配對(duì)請(qǐng)求和應(yīng)答報(bào)文，提取相關(guān)信息，同時(shí)也可以根據(jù)它們的時(shí)間戳大致估計(jì)DNS的響應(yīng)時(shí)間。
• 標(biāo)志字段：16 位，結(jié)構(gòu)如圖所示：

標(biāo)志字段各字段解釋如下：

QR(查詢/響應(yīng))：占 1B，定義報(bào)文類型。若為0則表示是查詢報(bào)文，否則就是響應(yīng)報(bào)文。

OpCode：占4B，定義查詢或響應(yīng)的類型。若為0則表示是標(biāo)準(zhǔn)的，若為 1則表示是反向的，若為2則表示是服務(wù)器狀態(tài)請(qǐng)求。

AA(授權(quán)回答)：占1B，當(dāng)它置位時(shí)(即值為 1)，表示名字服務(wù)器是權(quán)限服務(wù)器，它只用在響應(yīng)報(bào)文中。

TC(截?cái)嗟?：占 1B，當(dāng)它置位時(shí)，表示響應(yīng)已超過(guò)512B并已截?cái)唷?/p>

RD(要求遞歸)：占 1B，當(dāng)它置位時(shí)，表示客戶希望得到遞歸回答。它在查詢報(bào)文中置位,在響應(yīng)報(bào)文中重復(fù)置位。

RA(遞歸可用)：占 1B，當(dāng)它在響應(yīng)報(bào)文中置位時(shí)，表示可得到遞歸響應(yīng)，它只能在響應(yīng)報(bào)文中置位。

保留：占 1B,置為 0。

未知1與未知2均為新增字段，各占 1B。

RCode：占4B，表示在響應(yīng)中的差錯(cuò)狀態(tài)，只有權(quán)限服務(wù)器才能做出這個(gè)判斷。

• 問(wèn)題數(shù)字段：

查詢名：要查找的名字，它由一個(gè)或者多個(gè)標(biāo)示符序列組成。每個(gè)標(biāo)示符以首字節(jié)數(shù)的計(jì)數(shù)值說(shuō)明該標(biāo)示符長(zhǎng)度，每個(gè)名字以 0 結(jié)束。計(jì)數(shù)字節(jié)數(shù)必須在 0~63 之間。該字段無(wú)須填充字節(jié)。

查詢類型：每個(gè)問(wèn)題有一個(gè)查詢類型,通常查詢類型為 A(由名字獲得 IP 地址)或者PTR(獲得 IP 地址對(duì)應(yīng)的域名)。

類域(class)：置為0x0001 即可。

• 資源記錄部分：是DNS協(xié)議的最后了個(gè)字段，回答字段、授權(quán)宇段和附加信息字段均采用資源記錄RR(Resource Record)的相同格式。

6. DNS協(xié)議分析實(shí)驗(yàn)

【實(shí)驗(yàn)?zāi)康摹?/h3>

(1) 學(xué)會(huì)在客戶端使用 nslookup 命令進(jìn)行域名解析

(2) 通過(guò)協(xié)議分析軟件掌握 DNS 協(xié)議的報(bào)文格式

【實(shí)驗(yàn)原理】

DNS(Domain Name System，域名系統(tǒng))是因特網(wǎng)的一項(xiàng)核心服務(wù)，它作為可以將域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫(kù)，能夠使用戶更方便地訪問(wèn)互聯(lián)網(wǎng)，而不用去記住能夠被機(jī)器直接讀取的IP地址。在因特網(wǎng)中向主機(jī)提供域名解析服務(wù)的機(jī)器即為 DNS 服務(wù)器。

DNS 基于 IP 協(xié)議中的 UDP 協(xié)議，端口號(hào)為 53。目前 DNS 分布式查詢方式一般采用遞歸或遞歸迭代相結(jié)合的方法。當(dāng)在瀏覽器的地址欄中輸人某一網(wǎng)址時(shí)，瀏覽器首先會(huì)向默認(rèn)的本地域名服務(wù)器發(fā)出 DNS 請(qǐng)求報(bào)文，DNS請(qǐng)求報(bào)文中包括請(qǐng)求的域名和請(qǐng)求的類別。若本地域名服務(wù)器能夠找到對(duì)應(yīng)的 IP 地址，便返回一個(gè) DNS 相應(yīng)報(bào)文，其中包括域名以及一個(gè)或多個(gè)對(duì)應(yīng)的IP 地址。若本地域名服務(wù)器不能找到,則會(huì)向上級(jí)根域名服務(wù)器發(fā)出域名解析請(qǐng)求，根域名服務(wù)器會(huì)返回一個(gè) IP 地址告訴本地域名服務(wù)器應(yīng)該到哪里請(qǐng)求所需域名的解析，本地域名服務(wù)器根據(jù)得到的 IP 向?qū)?yīng)的域名服務(wù)器發(fā)出請(qǐng)求，最終獲得域名和對(duì)應(yīng)的 IP。
DNS的正向解析用于通過(guò)域名解析 IP 地址，反向解析用于通過(guò) IP 地址獲得域名。DNS 采用一個(gè)稱為資源記錄的數(shù)據(jù)結(jié)構(gòu)描述某個(gè)域名和對(duì)應(yīng)IP。每個(gè)資源記錄是一個(gè)五元組，包括域名(Domain name)、生存時(shí)間(TTL)、類別類型和值。

• 生存時(shí)間用于指示該記錄的穩(wěn)定程度，極為穩(wěn)定的信息會(huì)被分配一個(gè)很大的值，而極不穩(wěn)定的信息則會(huì)被分配一個(gè)較小的值。
• 類別字段對(duì)于 Internet 而言總是IN，事實(shí)上用于其他非 Internet 的情況幾乎沒(méi)有。類型字段指出了記錄的類型，主要的類型包括 A，表示一臺(tái)主機(jī)的IP 地址；MX，郵件服務(wù)器；NS，名字服務(wù)器；Cname,別名等。

nslookup 是一個(gè)監(jiān)測(cè)網(wǎng)絡(luò)中DNS服務(wù)器是否能正確實(shí)現(xiàn)域名解析的命令行工具。適用于Linux/UNIX和Windows 平臺(tái)，用于簡(jiǎn)單檢測(cè)DNS服務(wù)器的工作是否正常，也是排除 DNS服務(wù)器故障的一項(xiàng)重要手段。nslookup 指令適用于正向域名解析和反向域名解析。本實(shí)驗(yàn)通過(guò)nslookup 檢測(cè)服務(wù)器的配置，并利用協(xié)議分析軟件Wireshark捕獲分析nslookup命令產(chǎn)生的DNS數(shù)據(jù)包。

nslookup查詢命令格式為 nslookup 域名，主要產(chǎn)生兩個(gè)操作，一是根據(jù)本地DNS服務(wù)器的IP地址獲得本地 DNS服務(wù)器的名字； 二是根據(jù)輸人查詢的域名查找該域名的 IP地址。

【實(shí)驗(yàn)內(nèi)容】

在一臺(tái)連接 Internet 的計(jì)算機(jī)上進(jìn)行下列實(shí)驗(yàn)。

• 步驟 1：?jiǎn)?dòng) Wireshark，選定偵聽(tīng)網(wǎng)卡，開(kāi)始抓包。
• 步驟 2：切換到命令提示窗口，在命令提示符下輸人 nslookup www.baidu.com，分析執(zhí)行結(jié)果。
• 步驟 3：分析 Wireshark 捕獲的數(shù)據(jù)，觀察 nslookup 的通信過(guò)程，正常情況下能夠捕獲到 4 幀，試具體分析捕獲的數(shù)據(jù)包中 DNS 的報(bào)文格式細(xì)節(jié)。
• 步驟 4：繼續(xù)使用協(xié)議分析儀進(jìn)行數(shù)據(jù)的捕獲，再次訪問(wèn) www.baidu.com，觀察此時(shí)是否還有 DNS 請(qǐng)求？
• 步驟 5：關(guān)閉瀏覽器后再重新打開(kāi)，訪問(wèn)一個(gè)尚未訪問(wèn)過(guò)的網(wǎng)站，例如 www.sohu.com，觀察此時(shí)是否有 DNS 請(qǐng)求？為什么？
• 步驟 6：在Windows 系統(tǒng)的命令提示符下運(yùn)行 ipconfig /displaydns，顯示本機(jī)緩沖區(qū)中的 DNS 解析內(nèi)容。
• 步驟 7：在 Windows 系統(tǒng)的命令提示符下運(yùn)行 ipconfig /flushdns，則可以清除本機(jī)的 DNS 緩存記錄。
• 步驟 8：關(guān)閉瀏覽器再打開(kāi)，訪問(wèn)剛才打開(kāi)過(guò)的網(wǎng)站，觀察是否有 DNS 請(qǐng)求？為什么？

【實(shí)驗(yàn)思考】

(1) DNS 協(xié)議中的資源記錄 RR(Record Resource)包含哪些內(nèi)容？

(2) DNS 除了返回需查找的域名還可能返回哪些內(nèi)容？

(3) 反復(fù)實(shí)驗(yàn)，判斷一個(gè)域名是否可以對(duì)應(yīng)多個(gè) IP 地址？域名與 IP 地址之間是否有對(duì)應(yīng)的關(guān)系?

(4) 若實(shí)驗(yàn)中無(wú)法進(jìn)行 DNS 解析，請(qǐng)寫(xiě)出導(dǎo)致問(wèn)題的原因及解決辦法

(5) DNS 協(xié)議何時(shí)用 UDP？何時(shí)用 TCP？

7. DNS協(xié)議分析實(shí)驗(yàn)可能遇到的問(wèn)題

7.1 不了解nslookup命令如何使用

可以參考：nslookup 入門命令詳解

7.2 如何在Wireshark中對(duì)應(yīng)DNS協(xié)議內(nèi)容

首先在過(guò)濾器中輸入dns，然后查看后面的info信息，看看哪些是自己發(fā)送的DNS請(qǐng)求，最后對(duì)應(yīng)信息進(jìn)行分析。

文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-640177.html

到了這里，關(guān)于計(jì)算機(jī)網(wǎng)絡(luò)實(shí)驗(yàn)4：HTTP、DNS協(xié)議分析的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！