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

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

2. HTTP協(xié)議

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

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

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

• HTTP請求報文分為三部分：請求行、消息報頭、請求正文。

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

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

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

2xx：成功，表示請求已被成功接收、理解、接受。

3xx：重定向，要完成請求必須進行更進一步的操作。

4xx：客戶端錯誤，請求有語法錯誤或請求無法實現(xiàn)。

5xx：服務器端錯誤,服務器未能實現(xiàn)合法的請求。

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

3. HTTP分析實驗

【實驗目的】

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

【實驗原理】

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

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

HTTP 協(xié)議是無狀態(tài)的協(xié)議，即當服務器收到某個客戶端發(fā)送的 HTTP 請求報文時， 并不清楚該客戶端是否曾經(jīng)發(fā)送過相同的 HTTP 請求報文，即 HTTP 協(xié)議本身不會維護客戶端和服務器端的狀態(tài)。

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

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

【實驗內(nèi)容】

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

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

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

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

(2) 在捕獲的 HTTP 報文中，選擇一個 HTTP 請求報文和對應的 HTTP 應答報文，按圖 2-8 所示分析它們的字段，并將分析結(jié)果填人表 2-4 和表 2-5 中。

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

(4) 在第1個和第3個HTTP會話中，Web服務器對 Web客戶端GET請求的響應是什么?

【實驗思考】

(1) 實驗中哪臺計算機啟動了 HTTP 會話？是如何啟動的？

(2) 哪臺計算機首先發(fā)出了結(jié)束 HTTP 會話的信號? 是如何發(fā)出的？

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

4. HTTP分析實驗可能遇到的問題

4.1 捕捉不到http報文

可能原因：不是無法抓取 http包，是抓到了沒有解密，顯示還是TLS。

解決方法：

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

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

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

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

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

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

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

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

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

此時就能清晰的看到http請求報文，以及http響應報文。

進行對應分析即可：

4.4 http報文字段含義不清楚

General（通用部分）：

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

Request Headers（請求頭部）：

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

Response Headers（響應頭部）：

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

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

可以參考：

5. DNS協(xié)議

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

各字段含義：

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

標志字段各字段解釋如下：

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

OpCode：占4B，定義查詢或響應的類型。若為0則表示是標準的，若為 1則表示是反向的，若為2則表示是服務器狀態(tài)請求。

AA(授權(quán)回答)：占1B，當它置位時(即值為 1)，表示名字服務器是權(quán)限服務器，它只用在響應報文中。

TC(截斷的)：占 1B，當它置位時，表示響應已超過512B并已截斷。

RD(要求遞歸)：占 1B，當它置位時，表示客戶希望得到遞歸回答。它在查詢報文中置位,在響應報文中重復置位。

RA(遞歸可用)：占 1B，當它在響應報文中置位時，表示可得到遞歸響應，它只能在響應報文中置位。

保留：占 1B,置為 0。

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

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

• 問題數(shù)字段：

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

查詢類型：每個問題有一個查詢類型,通常查詢類型為 A(由名字獲得 IP 地址)或者PTR(獲得 IP 地址對應的域名)。

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

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

6. DNS協(xié)議分析實驗

【實驗目的】

(1) 學會在客戶端使用 nslookup 命令進行域名解析

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

【實驗原理】

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

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

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

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

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

【實驗內(nèi)容】

在一臺連接 Internet 的計算機上進行下列實驗。

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

【實驗思考】

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

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

(3) 反復實驗，判斷一個域名是否可以對應多個 IP 地址？域名與 IP 地址之間是否有對應的關(guān)系?

(4) 若實驗中無法進行 DNS 解析，請寫出導致問題的原因及解決辦法

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

7. DNS協(xié)議分析實驗可能遇到的問題

7.1 不了解nslookup命令如何使用

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

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

首先在過濾器中輸入dns，然后查看后面的info信息，看看哪些是自己發(fā)送的DNS請求，最后對應信息進行分析。