日韩性视频-久久久蜜桃-www中文字幕-在线中文字幕av-亚洲欧美一区二区三区四区-撸久久-香蕉视频一区-久久无码精品丰满人妻-国产高潮av-激情福利社-日韩av网址大全-国产精品久久999-日本五十路在线-性欧美在线-久久99精品波多结衣一区-男女午夜免费视频-黑人极品ⅴideos精品欧美棵-人人妻人人澡人人爽精品欧美一区-日韩一区在线看-欧美a级在线免费观看

歡迎訪問 生活随笔!

生活随笔

當前位置: 首頁 > 编程资源 > 编程问答 >内容正文

编程问答

计算机网络——数据包抓取与分析

發布時間:2023/12/10 编程问答 27 豆豆
生活随笔 收集整理的這篇文章主要介紹了 计算机网络——数据包抓取与分析 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

數據包抓取與分析

目錄

一、實驗目的

二、實驗內容

三、實驗環境

四、實驗步驟與過程


一、實驗目的

學習安裝、使用協議分析軟件,掌握基本的數據報捕獲、過濾和協議的分析技巧,能對抓取數據包進行分析。

二、實驗內容

協議分析軟件的安裝和使用、學會抓取數據包的方法并對對抓取數據包進行分析。

三、實驗環境

  • 使用Windows操作系統;Internet連接
  • 抓包軟件Wireshark。
  • 四、實驗步驟與過程

  • WireShark的使用
  • 選擇接口過濾器
  • 安裝Wireshark后,打開Wireshark,可以看到如圖 1所示的界面,提示我們選擇對應接口的過濾器,在此我選擇“以太網”進行抓包

    圖 1 選擇接口過濾器

  • Wireshark的界面
  • 打開Wireshark后,可以看到如圖 2的界面。Wireshark的界面主要分為如下幾個部分:

  • 顯示過濾器:主要用于過濾封包
  • 封包列表:顯示所有捕獲到的封包,有源地址和目標地址,端口號。不同的顏色代表了不同封包的類型與狀態
  • 封包詳細信息:顯示封包中的內容以及各個字段
  • 十六進制數據:展示十六進制的封包原始數據
  • 地址欄:顯示封包的統計信息與雜項
  • 圖 2 Wireshark主界面圖

    ??????

  • Wireshark過濾器
  • 在上一節中,我們介紹了Wireshark的界面,以及各個功能,接下來著重介紹Wireshark中過濾器的功能。過濾器可以在大量的數據中快速準確的找到我們需要的信息。

    圖 3 捕獲過濾器

    過濾器主要分兩種, 圖 2主界面上的顯示過濾器和圖 3上的捕獲過濾器。顯示過濾器用來在已捕獲的記錄中顯示所需要的記錄。捕獲過濾器主要用來過濾即將捕獲的封包,以免捕獲過多的記錄。

    圖 4 顯示過濾器

    ?????? 如圖 4,顯示過濾器通過過濾表達式實現過濾。具體可以通過如下幾個規則進行過濾:

  • 協議過濾:如tcp,則只顯示tcp協議
  • IP過濾:如ip.src==192.168.1.102顯示源地址為192.168.1.102的封包,ip.dst== 192.168.1.102則顯示目標地址為192.168.1.102的封包。
  • 端口過濾:如tcp.port ==80,只顯示端口為80的tcp協議的封包,又如tcp.srcport == 80,? 只顯示TCP協議的源端口為80的封包
  • Http過濾:如http.request.method=="GET",?? 只顯示HTTP GET方法的封包。
  • 此外,還可以通過邏輯運算符or,and等組合過濾表達式,達到更復雜的過濾效果。

  • 封包詳細信息
  • 封包詳細信息是抓包過程中最重要的,它包括如下五個字段:

  • Frame:???物理層的數據幀概況
  • Ethernet?II:?數據鏈路層以太網幀頭部信息
  • Internet Protocol Version 4:?互聯網層IP包頭部信息
  • Transmission Control Protocol:??傳輸層T的數據段頭部信息,此處是TCP
  • Hypertext Transfer Protocol:??應用層的信息,此處是HTTP協議
  • 圖 5 封包詳細信息

    ?????? 如圖 5所示,可以看到某一個封包的詳細信息。會顯示這個封包的長度,數據鏈路層信息等。

    圖 6 封包詳細信息與十六進制對應

    ?????? 如圖 6,對于封包里的每一條數據,可以通過點擊對應數據的方式,從下方十六進制原始文件中顯示對應的字節段。接下來,我們將對每個類型的封包分別進行介紹。

  • DNS分析
  • www.szu.edu.cn
  • 域名系統(英文:Domain Name System,縮寫:DNS)是互聯網的一項服務。它作為將域名和IP地址相互映射的一個分布式數據庫,能夠使人更方便地訪問互聯網。DNS使用UDP端口53。在http://www.szu.edu.cn/board/中,www.szu.edu.cn域名需要進行DNS解析得到對應的ip地址才能進行網絡資源訪問。

    首先通過DNS抓包查看域名解析的情況。打開Wireshark對網卡進行數據包的捕捉。接著對域名www.szu.edu.cn進行ping操作,由上一次實驗知道,ping操作首先需要對域名進行解析,然后在通過ip地址進行訪問、得到答復。通過ping得到域名解析后的ip如圖 7所示。

    圖 7 通過ping得到解析后的ip地址

    接下來打開Wireshark,在篩選框中輸入DNS以篩選出DNS解析的數據包,如圖 8所示。從結果來看,正好存在兩個DNS解析的數據包,分別對應著解析請求的發送和答復。

    圖 8 篩選DNS結果

    首先查看發送DNS解析的數據包,如圖 9所示。首先,從互聯網層看,DNS解析使用了ipv4協議,向223.5.5.5(阿里云公共DNS)發送了DNS解析請求。從傳輸層可以看到,使用的是UDP協議(User Datagram System),端口使用的是53端口。接著是DNS協議的詳細信息:第一個是Transaction ID標識字段,長度為2字節,用于辨別DNS應答報文是哪個請求報文的響應。第二個是Flags字段,長度為2字節,通過分析不同位的信息可以得到詳細的數據:

  • Response: 查詢/響應,1為響應,0為查詢。
  • Opcode: 查詢或響應類型,這里0表示標準,1表示反向,2表示服務器狀態請求。
  • Truncated: 截斷,1表示超過512字節并已被截斷,0表示沒有發生截斷。
  • TC: 截斷,1表示超過512字節并已被截斷,0表示沒有發生截斷。
  • zero: 全0保留字段。
  • Recursion:是否希望得到遞歸回答。
  • 經過上述信息分析,可以得知,該數據包是一個標準DNS請求,沒有被截斷,希望得到遞歸的回答。

    接下來是請求部分,字段Queries為查詢或者響應的正文部分,分為Name 、Type、Class。 Name是需要請求的域名,不定長度以0結束;Type是查詢類型,這里是主機A記錄;最后的Class中,IN表示Internet數據。

    圖 9 發送DNS請求數據包

    接下來分析答復部分的DNS數據包,如圖 10所示。可以看到,Transaction ID仍然是發送時的標記,用于表示這是回復當時請求的標記;Response處由0變成了1表示這是答復的DNS;新增的Recursion available為1表示服務器端可以使用遞歸查詢;Reply Code全0數據表示并沒有出現錯誤。相比于請求,答復多了一項Answers,由于ping操作只請求了一個域名, Answers中僅存在一項表名該域名只有一種解析。查看Answers中解析的域名可以看到,域名的名稱Name為www.szu.edu.cn,Type為A表示這是一個Ipv4地址,Class為In表示這是一個互聯網數據,Time to Live(生存時間TTL)表示該資源記錄的生命周期,從取出記錄到抹掉記錄緩存的時間,此處為9分26秒。Data length(資源數據長度)以字節為單位,這里的4表示IP地址的長度為4字節,也就是解析后的ip的長度。Addr(資源數據): 返回的IP地址210.39.4.1,就是我們想要的結果,該ip與ping命令行中的信息一致。

    圖 10 DNS答復

  • www.youku.com
  • 打開Wireshark對網卡進行數據包的捕捉,接著使用ping指令對域名www.youku.com進行連通性測試(相關操作省略)。

    打開Wireshark,在篩選框中輸入DNS篩選出DNS請求的數據包,得到如圖 11所示兩個數據包,分別代表DNS請求與答復。

    圖 11 篩選出的DNS相關數據包

    首先打開請求的數據包,如圖 12所示。從結果看出,協議采用UDP,端口為53;請求向223.5.5.5(阿里云公共DNS)發出;該數據包的Transaction ID為0x6cea。又從Flags字段中可以得出是一個請求的數據包,請求的是標準的查詢,沒有被截斷,請求遞歸查詢。接著從Queries字段中得出請求的只有一個域名的解析,類型為ipv4,為網絡數據類。

    圖 12 DNS解析請求數據包

    接著來分析得到的答復,如圖 13所示。可以看到,Transaction ID仍然是發送時的標記,用于表示這是回復當時請求的標記;Response處由0變成了1表示這是答復的DNS;新增的Recursion available為1表示服務器端可以使用遞歸查詢;Reply Code全0數據表示并沒有出現錯誤。

    查看Answers中解析的域名可以看到,首先是返回一個類型為CNME的項目。CAME為規范名字,即將www.youku.com規范為ipv6-aserver-heyi.m.taobao.com。然后,再次對ipv6-aserver-heyi.m.taobao.com進行解析,得到第二個同樣為CNME的項目。該項目再次規范名字,將ipv6-aserver-heyi.m.taobao.com規范為ipv6-aserver-heyi.m.taobao.com.gds.alibabadns.com。此時再次進行域名解析,得到第三個項目。這時,返回的終于是為A的Ipv4地址,Class為In表示這是一個互聯網數據,Time to Live(生存時間TTL)表示該資源記錄的生命周期,從取出記錄到抹掉記錄緩存的時間,此處為21秒。Data length(資源數據長度)以字節為單位,這里的4表示IP地址的長度為4字節,也就是解析后的ip的長度。Addr(資源數據): 返回的IP地址106.11.35.97。

    圖 13 DNS解析答復數據包

  • www.sina.com.cn
  • 打開Wireshark對網卡進行數據包的捕捉,接著使用ping指令對域名www.sina.com.cn進行連通性測試,如圖 14所示。

    圖 14 ping操作

    打開Wireshark,在篩選框中輸入DNS篩選出DNS請求的數據包,得到如圖 15所示兩個數據包,分別代表DNS請求與答復。

    圖 15 篩選DNS數據包

    首先打開請求的數據包,如圖 16所示。從結果看出,協議采用UDP,端口為53;請求向223.5.5.5(阿里云公共DNS)發出;該數據包的Transaction ID為0x96c7。又從Flags字段中可以得出是一個請求的數據包,請求的是標準的查詢,沒有被截斷,請求遞歸查詢。接著從Queries字段中得出請求的只有一個域名的解析,類型為ipv4,為網絡數據類。

    圖 16 DNS解析請求數據包

    接著來分析得到的答復,如圖 17所示。可以看到,Transaction ID仍然是發送時的標記,用于表示這是回復當時請求的標記;Response處由0變成了1表示這是答復的DNS;新增的Recursion available為1表示服務器端可以使用遞歸查詢;Reply Code全0數據表示并沒有出現錯誤。

    圖 17 DNS解析答復數據包 1

    查看Answers中(圖 18)解析的域名可以看到,首先是返回一個類型為CNME的項目。CAME為規范名字,即將www.sina.com.cn規范為spool.grid.sinaedge.com。然后,再次對spool.grid.sinaedge.com進行解析,得到第二個同樣為CNME的項目。該項目再次規范名字,將spool.grid.sinaedge.com規范為ww1.sinaimg.cn.w.alikunlun.com。此時再次進行域名解析,得到剩下的13個項目。這時,返回的全部是類型為A的Ipv4地址,Class為In表示這是一個互聯網數據。可以發現,ping指令最后只對第一個ipv4地址進行了操作。DNS將一個域名解析成了多個ip,如此一來一旦有其中一個ip宕機了,也能迅速訪問其他ip來連接,增加了服務的可靠性。

    圖 18 Answers解析的域名

  • HTTP
  • 超文本傳輸協議(Hypertext Transfer Protocol,HTTP)是一個簡單的請求-響應協議,它通常運行在TCP之上,端口號一般為80。它指定了客戶端可能發送給服務器什么樣的消息以及得到什么樣的響應。

    由于www.szu.edu.cn、www.youku.com、www.sina.com.cn等許多網站都已經采用更安全的https協議,所以測試http協議的網站使用深大內部的學生公寓管理中心http://gyzx.szu.edu.cn/。

    首先打開Wireshark對網卡進行數據包捕捉,然后在瀏覽器中打開http://gyzx.szu.edu.cn/。接著返回Wireshark中,在篩選框中輸入http對數據包進行篩選,得到兩個數據包,分別代表了http的請求及答復,如圖 19所示。

    圖 19 http請求和答復

    首先來觀察http請求的數據包,如圖 20所示。

    圖 20 http請求

    從傳輸層可以看到,http采用的是tcp協議,端口為80。在應用層,可以看到http協議的報文形式。首先,該數據包采用的是GET的方法,協議為HTTP 1.1。HTTP1.0 定義了三種請求方法: GET, POST 和 HEAD方法。HTTP1.1 新增了五種請求方法:OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

    表格 1 http請求方式

    GET

    請求指定的頁面信息,并返回實體主體。

    HEAD

    類似于 GET 請求,只不過返回的響應中沒有具體的內容,用于獲取報頭

    POST

    向指定資源提交數據進行處理請求(例如提交表單或者上傳文件)。數據被包含在請求體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改。

    PUT

    從客戶端向服務器傳送的數據取代指定的文檔的內容。

    DELETE

    請求服務器刪除指定的頁面。

    CONNECT

    HTTP/1.1 協議中預留給能夠將連接改為管道方式的代理服務器。

    OPTIONS

    允許客戶端查看服務器的性能。

    TRACE

    回顯服務器收到的請求,主要用于測試或診斷。

    PATCH

    是對 PUT 方法的補充,用來對已知資源進行局部更新 。

    從Connection中可以看到,該請求是keep-alive的,即永久連接。這樣子有利于在你訪問的網頁中有很多圖片等其他資源的時候,可以使用同一個TCP連接接收,而不是針對每一個文件都建立一次TCP/IP的連接。User-Agent則表示了訪問的客戶端的詳細信息。Accept-Encoding: gzip, deflate說明該瀏覽器支持的編碼格式,這里是壓縮編碼的方式,猜想應該是服務器將瀏覽器請求的文件都是以壓縮文件發送過來的。Accept-Language: zh-CN,zh;q=0.9,en;q=0.8指明了該瀏覽器支持的語言類型,支持zh-CN,zh,en。然后優先發送zh-CN和zh的語言,因為他們的權重是0.9。

    接下來分析http協議的答復,如圖 21所示。

    圖 21 http答復

    直接分析應用層的http協議,可以看到,答復同樣采用的是http1.1,Status為200說明客戶端請求成功。常見的幾個狀態碼如下所示。

  • 200:客戶端請求成功,是最常見的狀態。
  • 302:重定向。
  • 404:請求資源不存在,是最常見的狀態。
  • 400:客戶端請求有語法錯誤,不能被服務器所理解。
  • 401:請求未經授權。
  • 403:服務器收到請求,但是拒絕提供服務。
  • 500:服務器內部錯誤,是最常見的狀態。
  • 503:服務器當前不能處理客戶端的請求。
  • Content-Length表示內容長度。Content-Type表示后面的文檔屬于什么MIME類型,默認為text/plain,但通常需要顯式地指定為text/html。Date為當前的GMT時間。最后的line-based text data即為返回的網頁內容,瀏覽器經過解析html語言,進而將網頁呈現給用戶。

  • TCP
  • 傳輸控制協議(TCP,Transmission Control Protocol)是為了在不可靠的互聯網絡上提供可靠的端到端字節流而專門設計的一個傳輸協議。應用層向TCP層發送用于網間傳輸的、用8位字節表示的數據流,然后TCP把數據流分割成適當長度的報文段。之后TCP把結果包傳給IP層,由它來透過網絡將包傳送給接收端實體的TCP層。TCP為了保證不發生丟包,就給每個包一個序號,同時序號也保證了傳送到接收端實體的包的按序接收。然后接收端實體對已成功收到的包發回一個相應的確認信息(ACK);如果發送端實體在合理的往返時延(RTT)內未收到確認,那么對應的數據包就被假設為已丟失并進行重傳。TCP用一個校驗和函數來檢驗數據是否有錯誤,在發送和接收時都要計算校驗和。

    接下來通過打開網站www.szu.edu.cn來觀察TCP連接的情況。首先打開Wireshark對網卡進行數據包捕捉,然后在瀏覽器中打開www.suz.edu.cn。由圖 7可得,域名解析后的ip地址為210.39.4.1,于是在Wireshark的篩選框中輸入“ip.addr == 210.39.4.1”來篩選數據包。得到結果如圖 22所示。

    圖 22 TCP數據包

  • TCP建立
  • 圖 22中前3個數據包為TCP三次握手協議建立連接。當主動方發出SYN連接請求后,等待對方回答SYN+ACK,并最終對對方的 SYN 執行 ACK 確認。這種建立連接的方法可以防止產生錯誤的連接,TCP使用的流量控制協議是可變大小的滑動窗口協議。

    TCP三次握手的過程如下:

  • 客戶端發送SYN(SEQ=x)報文給服務器端,進入SYN_SEND狀態。
  • 服務器端收到SYN報文,回應一個SYN (SEQ=y)ACK(ACK=x+1)報文,進入SYN_RECV狀態。
  • 客戶端收到服務器端的SYN報文,回應一個ACK(ACK=y+1)報文,進入Established狀態。
  • 三次握手完成,TCP客戶端和服務器端成功地建立連接,可以開始傳輸數據了。

    首先來分析第一次握手,數據包如圖 23所示。可以看出,由于使用的是HTTPS協議打開的網頁,所以TCP端口為443。Src為客戶端,Dst為訪問的域名接續后的ip,所以這是客戶端發送給服務端的數據。可以看到客戶端將Flags標志位SYN置為1,隨機產生一個值Sequence Number = 0作為序號,并將該數據包發送給服務器,客戶機進入SYN_SENT狀態,等待服務器確認。實際上Wireshark 工具幫我們做了優化,它默認顯示的是序列號 seq 是相對值,而不是真實值,真實值在Sequence Number(raw)中,值為1136243156。

    圖 23 TCP第一次握手

    然后是第二次握手,如圖 24所示。可以看到,該數據包的Src是服務端,Dst是客戶端,說明這是服務器發送給客戶端的數據。這時觀察到,SYN仍然為1。然后,服務端將確認序號(Acknowledgement Number)設置為客戶的序號seq加1,即0+1=1, ACK變為了1(真實值為1136243157 = 1136243156 + 1),說明服務端收到了TCP請求。此時,seq由服務器隨機生成相對值0(實際值1721425601)。

    圖 24 TCP第二次握手

    接下來是TCP第三次握手,如圖 25所示。可以看到,該數據包的Src為客戶端,Dst為服務端,這是客戶端發送的數據包。在第三次握手中,客戶端收到第二次握手中服務器發來的包后檢查確認序號Seq是否正確,即第一次發送的序號Seq加1(X+1= 0+1=1)。以及標志位ACK是否為1。若正確,客戶端會再向服務器端發送一個數據包,SYN=0,ACK=1,確認序號Ack=Y+1=0+1=1,并且把服務器發來ACK的序號Seq加1發送給對方,發送序號Seq為X+1= 0+1=1。客戶端收到后確認序號值與ACK=1,至此,一次TCP連接就此建立,可以傳送數據了。

    圖 25 TCP第三次握手

  • 數據傳輸
  • 數據傳輸階段,服務端與客戶端之間仍然通過Seq與Ack的值進行數據可靠性的保證。具體操作如圖 26所示。

    圖 26 TCP數據傳輸過程

    由于數據傳輸的數據包非常多,為了更直觀的觀察,可以打開Wireshark中的統計-流量圖,如圖 27所示。圖中可以看到,服務端與客戶端一直在通信,并沒有終止。同時,因為發送或者接受的數據包并不固定數量,所以Seq和Ack值的變化不一。

    圖 27 TCP傳輸數據

  • 四次揮手
  • 建立一個連接需要三次握手,而終止一個連接要經過四次握手,這是由TCP的半關閉(half-close)造成的具體流程如下。

    (1)客戶端A發送一個FIN,用來關閉客戶A到服務器B的數據傳送。

    (2)服務器B收到這個FIN,它發回一個ACK,確認序號為收到的序號加1。和SYN一樣,一個FIN將占用一個序號。

    (3)服務器B關閉與客戶端A的連接,發送一個FIN給客戶端A。

    (4)客戶端A發回ACK報文確認,并將確認序號設置為收到序號加1。

    具體捕獲的數據包如圖 28紅框內所示。首先,第一行說明客戶端向服務端發送FIN請求;然后,第二行中,服務端向客戶端發送一條ACK回復,表名服務端已經收到結束請求;然后,第三行中,服務端向客戶端發送FIN,表名服務器已經關閉通信;第四行中,客戶端收到服務端的關閉信息,所以自己也關閉通信,同時,將自己已經收到關閉通信的信息用ACK發送給服務端。至此,整個TCP連接已經完全關閉

    圖 28 TCP四次揮手

  • UDP
  • UDP 是User Datagram Protocol的簡稱, 中文名是用戶數據報協議,是OSI參考模型中一種無連接的傳輸層協議,提供面向事務的簡單不可靠信息傳送服務。UDP協議與TCP協議一樣用于處理數據包,在OSI模型中,兩者都位于傳輸層,處于IP協議的上一層。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點,也就是說,當報文發送之后,是無法得知其是否安全完整到達的。

    ?接下來使用登錄QQ這一過程來抓取UDP數據包進行分析。首先打開Wireshark對網卡進行數據包捕捉,然后登錄QQ,在Wireshark篩選框中輸入OICQ進行篩選。OICQ協議是QQ在與服務器通信時使用的協議,通常是建立在UDP協議之上。篩選后,得到許多OICQ協議的數據包,如圖 29所示。

    圖 29 OICQ數據包

    接下來,隨便打開一個數據包,如圖 30所示。可以看到,這是由服務端發送至客戶端的數據包,傳輸層使用的是UDP協議。與TCP協議相比,UDP協議的報文非常簡單,這是因為UDP報文不對可達進行保證,適合高數據流的應用。然后應用層協議為OICQ協議,這一部分協議完全由QQ去定義,內含QQ通信時所需要的信息。

    圖 30 OICQ數據包詳細信息

    總結

    以上是生活随笔為你收集整理的计算机网络——数据包抓取与分析的全部內容,希望文章能夠幫你解決所遇到的問題。

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