1. 主要教學內容

• 實驗內容：使用Wireshark捕獲數據包，根據捕獲的相關數據包分別對HTTP、DNS協議展開分析。額外內容：利用fiddler軟件對HTTPS協議進行分析。
• 所需學時：1。
• 重難點：HTTP和DNS協議的報文結構。
• 周次：第3周。
• 教材相關章節：2.4、2.7。

2. HTTP協議

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

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

• HTTP 協議定義了8種方法表示對指定數據的操作：

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

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

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

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

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

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

4xx：客戶端錯誤，請求有語法錯誤或請求無法實現。

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

• 常見狀態碼：

3. HTTP分析實驗

【實驗目的】

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

【實驗原理】

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

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

HTTP 協議是無狀態的協議，即當服務器收到某個客戶端發送的 HTTP 請求報文時， 并不清楚該客戶端是否曾經發送過相同的 HTTP 請求報文，即 HTTP 協議本身不會維護客戶端和服務器端的狀態。

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

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

【實驗內容】

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

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

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

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

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

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

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

【實驗思考】

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

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

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

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

4.1 捕捉不到http報文

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

解決方法：

Windows系統參考：為什么我的 Wireshark 抓不到/抓不全 HTTP 數據包 ？

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

4.2 百度是使用HTTPS協議進行傳輸

我們以為捕獲不到http報文，實際上是因為網站加密了，通過上述方法得到http報文中可能有許多看不懂的地方，而且發現使用的端口號是443而不是80，這是因為大部分網站都是使用HTTPS協議進行傳輸，以提高數據傳輸的安全性。

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

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

4.3 Wireshark獲得數據太多如何篩選

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

通過Wireshark中的過濾器，篩選出該IP的數據：

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

進行對應分析即可：

4.4 http報文字段含義不清楚

General（通用部分）：

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

Request Headers（請求頭部）：

• User-Agent：用戶代理，標識發起請求的客戶端應用程序或設備類型，例如瀏覽器名稱和版本。
• Accept：客戶端可接受的響應內容類型，通常是MIME類型（例如text/html、application/json等）。
• Accept-Language：客戶端可接受的語言類型，用于指定客戶端希望接收的語言版本。
• Cookie：包含客戶端發送給服務器的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頭部用于指示請求的來源，即發起請求的網頁所在的源，包含協議、域名和端口號。它通常用于跨域請求中，由瀏覽器自動添加。例如：http://www.origin.com
• Connection：Connection頭部用于控制是否在請求完成后保持與服務器的連接。它是一個非標準的HTTP頭部，在HTTP/1.1中引入了持久連接（Persistent Connection）后，取代了早期版本的Proxy-Connection和Keep-Alive頭部。Connection頭部的取值通常有幾種：
• close：請求完成后關閉與服務器的連接。即，每次請求都會新建一個連接。
• keep-alive：請求完成后保持與服務器的連接，以便在同一連接上進行多個請求。這是持久連接的一種方式，減少了連接的建立和關閉的開銷，提高了請求的效率。
• Upgrade：允許客戶端和服務器協商更高級的協議。例如，WebSocket可以通過此頭部實現從HTTP協議升級到WebSocket協議。
• 在現代的HTTP/1.1中，持久連接是默認啟用的，即默認使用keep-alive，除非顯示指定close，因此通常情況下可以不必手動添加Connection頭部。

Response Headers（響應頭部）：

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

4.5 http協議工作過程怎么填寫

可以參考：

5. DNS協議

DNS(Domain Name System，域名系統)用于命名組織到域層次結構中的計算機和網絡服務。
DNS 協議分成包頭和數據兩部分。如圖所示，該報文由12B的首部和4個長度可變的字段組成：

各字段含義：

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

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

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

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

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

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

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

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

保留：占 1B,置為 0。

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

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

• 問題數字段：

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

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

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

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

6. DNS協議分析實驗

【實驗目的】

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

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

【實驗原理】

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

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

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

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

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

【實驗內容】

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

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

【實驗思考】

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

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

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

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

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

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

7.1 不了解nslookup命令如何使用

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

7.2 如何在Wireshark中對應DNS協議內容

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