NetAnalyzer筆記之二. 簡單的協議分析

時間 2019-11-17

標籤 netanalyzer 筆記簡單協議分析简体版

原文原文鏈接

[建立時間：2015-08-27 22:15:17]html

上篇咱們回顧完了NetAnalyzer一些無關緊要的歷史，在本篇，我決定先不對NetAnalyzer作介紹，而是先要了解一些關於構建NetAnalyzer的基礎知識，如系統中能夠分析的一些網絡協議，瞭解它們的分佈方式，字段含義等。在瞭解了協議的基礎上，之後學習配置Winpcap的開發環境，作一些簡單的數據採集程序就會更加方便。接下來則要介紹一下在開發NetAnalzyer過程當中涉及到的一些數據結構與編程思想。編程

NetAnalyzer中的協議緩存

在這裏我並不想講太多關於協議體系結構的問題，也無論什麼OSI七層模型，也不論TCP/IP的四層結構，也爲這些體系方面的知識不少，並且有在不少的書中都有介紹。而在此處講的是，在NetAnalyzer中所能解析的數據，並對各數據字段給出相應的解釋與說明，最終只是做爲參考資料，方便NetAnalyzer後續的開發升級。所以在此處全部數據報文分析數據將依照NetAnalyzer中現有的數據解析結果，與總體解析層次做爲參考進行協議說明。安全

在介紹具體協議以前先看看NetAnalyzer數據分析界面服務器

(a) 上面爲獲取的數據包列表網絡

(b) 左下角爲具體的協議分析內容，也是該軟件的核心區域數據結構

本軟件能夠從網卡採集數據，也能夠讀取緩存文件得到，由於有些數據包不容易採集，因此能夠到這裏下載（不會博客傳文件，因此給一個連接吧）tcp

http://pan.baidu.com/s/1ntxi5dB

1.幀（ Frame）

事實上，這並非一個網絡協議。這只是用來獲取的一個數據報文的基本信息，這是Winpcap定義的一種數據格式，當其轉爲字符串時顯示如圖所示。在每一個數據包被捕獲到的時候,在內存中的存儲數據如圖2.1所示

圖2.1 原始的數據報文

第一行包括冒號在內的第一個字段13309501:631439是一種時間戳標記方式。該時間戳記錄以「：」爲分隔符，分爲秒計時，與毫秒計時。

秒計時：32位，一個UNIX格式的精確到秒時間值，用來記錄數據包抓獲的時間，記錄方式是記錄從格林尼治時間的1970年1月1日 00:00:00 到抓包時通過的秒數；

毫秒計時：32位，記錄抓取數據包時的毫秒值。

在時間戳後面的字段，使用括號的包含起來的字段則是表示當前獲取數據報文的大小。以字節文單位。其記錄了所抓獲的數據包的真實長度，若是文件中保存不是完整的數據包，那麼這個值可能要比前面的數據包長度的值大，該字段中的數據數量是54字節。

第一行以後的數據爲網絡傳輸數據報文，爲了方便在書中展現，此處使用十六進制的方式展現出來，在這些數據中，其中記錄了各類協議的首部信息以及索要傳遞的數據內容。圖2.2則是對整個數據報文的信息摘要。

圖2.2 Frame中所要表達的數據信息

2 以太網協議(Ethernet)

在完成了數據報文基礎信息的講解，如今開始真正的協議分析。首先天然是鏈路層的以太網。由於目前大多數的網絡都採用以太網進行構建。

以太網最先由Xerox（施樂）公司建立，於1980年DEC、lntel和Xerox三家公司聯合開發成爲一個標準。以太網是應用最爲普遍的局域網，包括標準的以太網(10Mbit/s)、快速以太網(100Mbit/s)和10G(10Gbit/s)以太網，採用的是CSMA/CD訪問控制法，它們都符合IEEE802.3。　　IEEE 802.3標準　　IEEE802.3規定了包括物理層的連線、電信號和介質訪問層協議的內容。以太網是當前應用最廣泛的局域網技術。它很大程度上取代了其餘局域網標準，如令牌環、FDDI和ARCNET。歷經100M以太網在上世紀末的飛速發展後，目前千兆以太網甚至10G以太網正在國際組織和領導企業的推進下不斷拓展應用範圍。

常見的802.3應用爲: 　　

10M: 10base-T (銅線UTP模式)

100M: 100base-TX (銅線UTP模式)

　　100base-FX(光纖線)

　　1000M: 1000base-T(銅線UTP模式)

ethernet採用無源的介質，按廣播方式傳播信息。它規定了物理層和數據鏈路層協議，規定了物理層和數據鏈路層的接口以及數據鏈路層與更高層的接口。

（1）物理層

　　物理層規定了Ethernet的基本物理屬性，如數據編碼、時標、電頻等。

（2）數據鏈路層

數據鏈路層的主要功能是完成幀發送和幀接收，包括負責對用戶數據進行幀的組裝與分解，隨時監測物理層的信息監測標誌，瞭解信道的忙閒狀況，實現數據鏈路的收發管理。

以太網首部格式，如圖2.3所示，其首部共14個字節共112個bits，五個字段組成。

圖2.3Ethernet 首部格式

在Ethernet幀字段的說明

字段	長度(bit)	說明
目的硬件地址(Destination MAC Address)	48	下一跳主機的硬件地址
源主機硬件地址(Source MAC Address)	48	上一跳主機的硬件地址
網絡層協議類型	16	所分裝的上一層協議類型
數據字段	可變
FCS	16	幀校驗序列（CRC校驗）

表2-1 Eternet字段

(1) 硬件地址(MAC Address)

MAC(Medium/Media Access Control)地址，或稱爲 MAC位址、硬件地址，用來定義網絡設備的位置,由48比特長，16進制數字組成，0到23位是組織惟一標識符，是識別LAN（局域網）結點的標誌。在OSI模型中，第三層網絡層負責 IP地址，第二層數據鏈路層則負責 MAC位址。所以一個網卡會有一個全球惟一固定的MAC地址，但可對應多個IP地址。其中24到47位是廠家本身分配的，第40位是組播地址標誌位。

(2) 網絡層協議類型(Type)

用於識別上一層分裝數據的類型。如0x0080表示上一次即網絡層的協議爲IPv4，而0x0806則表示地址解析協議ARP。

(3) 數據(Data)

該字段表示當前傳輸的上層協議首部和分裝的數據。其數據長度限制在46-1500個字節之間。

(4) FCS

FCS是802.3幀和Ethernet幀的最後一個字段，用於保存幀的CRC校驗值,站4個字節。

NetAnalyzer中表示

在NetAnalyzer中所獲取的原始數據效果如圖2.4所示，在該段數據中，能夠看出此數據報文的目的硬件地址(Destination Mac Address)：94-0C-6D-32-40-82，源硬件地址(Source): 00-24-54-19-4B-2E，類型(Type)：0x0800 即上冊協議爲IPv4。

圖2.4 Eternet原始數據

在NetAnalyzer中分析結果如圖2.5所示。

圖2.5 Ehternet 在NetAnalyzer中的分析結果

3 地址解析協議(ARP)

ARP，即地址解析協議，實現經過IP地址得知其物理地址。在TCP/IP網絡環境下，每一個主機都分配了一個32位的IP地址，這種互聯網地址是在網際範圍標識主機的一種邏輯地址。爲了讓報文在物理網路上傳送，必須知道對方目的主機的物理地址。這樣就存在把IP地址變換成物理地址的地址轉換問題。以以太網環境爲例，爲了正確地向目的主機傳送報文，必須把目的主機的32位IP地址轉換成爲48位以太網的地址。這就須要在互連層有一組服務將IP地址轉換爲相應物理地址，這組協議就是ARP協議。另有電子防翻滾系統也稱爲ARP。

在以太網協議中規定，同一局域網中的一臺主機要和另外一臺主機進行直接通訊，必需要知道目標主機的MAC地址。而在TCP/IP協議棧中，網絡層和傳輸層只關心目標主機的IP地址。這就致使在以太網中使用IP協議時，數據鏈路層的以太網協議接到上層IP協議提供的數據中，只包含目的主機的IP地址。 Bits

因而須要一種方法，根據目的主機的IP地址，得到其MAC地址。這就是ARP協議要作的事情。所謂地址解析（address resolution）就是主機在發送幀前將目標IP地址轉換成目標MAC地址的過程。

ARP首部格式，如圖2.6所

圖2.6 ARP協議首部

(1) 硬件類型(Hardware Type)

對不一樣的鏈路層協議，使用不一樣的硬件接口類型，所以該字段用於指明當前使用的硬件接口類型，以太網的值爲1。

(2) 協議類型(Protocol Type)

針對對於不一樣的網絡層協議，該字段指明瞭發送方提供的高層協議類型，例如IP爲0x0800。

(3) 硬件長度(Hardware Size)

指明當前鏈路層協議類型的地址長度。

(4) 協議長度(Protocol Size)

與硬件長度同樣，該字段指明當前網絡層協議使用的地址長度。

(5) 操做(Operation)

該字段字段用來表示這個報文的做用類型,ARP，若是是發出請求爲1，響應則爲2。

(6) 源主機硬件地址，目的主機硬件地址

肯定源主機與目的主機在鏈路層通訊使用的地址。

(7) 源主機協議地址，目的主機協議地址

表示源主機與目的主機的網絡層使用的通訊地址。

NetAnalyzer中的表示

圖2.7 ARP原始數據

在NetAnalyzer中所獲得的原始數據如圖2.7所示，硬件類型 0x0001，爲以太網；協議類型 0x0800所以網絡層協議爲IPv4；硬件長度0x06，以太網MAC地址站6個字節；協議長度 0x04,IPv4的地址站4個字節；操做：0x0001該數據報文是一個請求報文；以後即是一些地址信息。

NetAnalyzer中分析ARP協議的結果如圖2.8

圖2.8 ARP在NetAnalyzer中的分析結果

4 網際協議第四版(IPv4)

IPv4，是互聯網協議（Internet Protocol，IP）的第四版，也是第一個被普遍使用，構成現今互聯網技術的基石的協議。1981年 Jon Postel 在RFC791中定義了IP，Ipv4能夠運行在各類各樣的底層網絡上，好比端對端的串行數據鏈路(PPP協議和SLIP協議) ，衛星鏈路等等。局域網中最經常使用的是以太網。

IPv4首部通常是20字節長。在以太網幀中，IPv4包首部緊跟着以太網幀首部，同時以太網幀首部中的協議類型值設置爲0800。 IPv4提供不一樣，大部分是不多用的選項，使得IPv4包首部最長可擴展到60字節(老是4個字節4個字節的擴展) 。

IPv4首部格式如圖2.9所示

圖2.9 IPv4首部格式

(1) 版本(Version)

指出當前使用的 IP 版本，該協議版本文4。

(2) 首部長度(Head length)

IPv4的首部使用了選項字段，所以須要使用首部長度說明IP首部的偏移量。

(3) 區分服務

根據不一樣的使用狀況，對數據傳輸方式進行傳輸質量區分，其指出上層協議對處理當前數據報所指望的服務質量，並對數據報按照重要性級別進行分配。這些8位字段用於分配優先級、延遲、吞吐量以及可靠性。

(4) 報文長度(Total Length)

指定整個 IP 數據包的字節長度，包括數據和協議頭。其最大值爲65,535字節。典型的主機能夠接收576字節的數據報。

(5) 標識(Identification)

包含一個整數，用於識別當前數據報。該字段由發送端分配幫助接收端集中數據報分片。

(6) 標誌(Flags)

由3位字段構成，其中低兩位（最不重要）控制分片。中間位（DF）指出數據包是否可進行分片。低位(MF)指出在一系列分片數據包中數據包是不是最後的分片。第三位即最高位不使用。

(7) 片偏移量(Fragment Offset)

13位字段，指出與源數據報的起始端相關的分片數據位置，支持目標IP適當重建源數據報。

(8) 生存時間(Time to live)

是一種計數器，在丟棄數據報的每一個點值依次減1直至減小爲0。這樣確保數據包無止境的環路過程。

(9) 協議(Protocol)

IP數據包分裝的上一層協議的類型,若是爲6，則上層協議爲Tcp

(10) 首部校驗和(Header Checksum)

幫助確保 IP 協議頭的完整性。因爲某些協議頭字段的改變，如生存期（Time to Live），這就須要對每一個點從新計算和檢驗。Internet 協議頭須要進行處理。

(11) 源IP地址(Source Address)，目的IP地址(Destination Address)

用於指定源主機的IP地址與目的主機的IP地址。

(12) 選項(Options)

IP 支持各類選項，該選項字段用來支持排錯，測量以及安全等措施，此字段的長度可變，從1個字節到40個字節不等，取決於所選擇的項目。

(13) 填充字段

該字段目的是解決由於選項字段不字節不肯定而形成的IP首部不能對齊的問題，使用0填充確實的數據，使其成4字節對齊。

NetAnalyzer中獲取的IPv4的原始數據如圖2.10，

圖2.10 IPv4原始數據

IPv4首部20個字節，沒有選項字段，IP版本首部長度只用一個字節表示0x45，表示第四個版本，20個字節的首部；區分服務 0x00大多數IPv4報文並不設置該字段；報文長度 0x0028所以報文長度爲40個字節；標識0x04B4；標誌(010)₂不須要分片，片偏移量(00000)₂；生存時間0x40即64跳；協議0x06，表示上層協議爲TCP，首部校驗和0x0000這是一個無效的數據包；最後是兩個方向的IP地址。

在NetAnalyzer中分析IPv4的結果如圖2.11

圖 2.11 IPv4在NetAnalyzer中分析的結果

5 網際協議第六版(IPv6)

IPv6是Internet Protocol Version 6的縮寫，其中Internet Protocol譯爲「互聯網協議」。IPv6是IETF（互聯網工程任務組，Internet Engineering Task Force）設計的用於替代現行版本IP協議（IPv4）的下一代IP協議。目前IP協議的版本號是4（簡稱爲IPv4），它的下一個版本就是IPv6。

IPv6的特色：

(1) IPV6地址長度爲128比特，地址空間增大了2的9中國IPV6主幹節點示意圖

(2) [1]6次方倍；　　

(3) 靈活的IP報文頭部格式。使用一系列固定格式的擴展頭部取代了IPV4中可變長度的選項字段。IPV6中選項部分的出現方式也有所變化，使路由器能夠簡單路過選項而不作任何處理，加快了報文處理速度；　　

(4) IPV6簡化了報文頭部格式，字段只有8個，加快報文轉發，提升了吞吐量；　　

(5) 提升安全性。身份認證和隱私權是IPV6的關鍵特性；　　

(6) 支持更多的服務類型；　　

(7) 容許協議繼續演變，增長新的功能，使之適應將來技術的發展；

IPv6包由IPv6包頭（40字節固定長度）、擴展包頭和上層協議數據單元三部分組成。IPv6包擴展包頭中的分段包頭中指明瞭IPv6包的分段狀況。其中不可分段部分包括：IPv6包頭、Hop-by-Hop選項包頭、目的地選項包頭（適用於中轉路由器）和路由包頭；可分段部分包括：認證包頭、ESP協議包頭、目的地選項包頭（適用於最終目的地）和上層協議數據單元。可是須要注意的是，在IPv6中，只有源節點才能對負載進行分段，而且IPv6超大包不能使用該項服務。

IPv6的固定首部格式

圖2.12 IPv6固定首部

IPv6包頭長度固定爲40字節，去掉了IPv4中一切可選項，只包括8個必要的字段，所以儘管IPv6地址長度爲IPv4的四倍，IPv6包頭長度僅爲IPv4包頭長度的兩倍。

(1) 版本(Version)

4位，IP協議版本號，值= 6。

(2) 通訊量等級(Traffic Class)

8位，指示IPv6數據流通訊類別或優先級。功能相似於IPv4的服務類型（TOS）字段。

(3) 遊標記(Flow Label)

20位，IPv6新增字段，標記須要IPv6路由器特殊處理的數據流。該字段用於某些對鏈接的服務質量有特殊要求的通訊，諸如音頻或視頻等實時數據傳輸。在IPv6中，同一信源和信宿之間能夠有多種不一樣的數據流，彼此之間以非「0」流標記區分。若是不要求路由器作特殊處理，則該字段值置爲「0」。

(4) 有效載荷(Payload Length)

16位負載長度。負載長度包括擴展頭和上層PDU，16位最多可表示65535字節負載長度。超過這一字節數的負載，該字段值置爲「0」，使用擴展頭逐個跳段（Hop-by-Hop）選項中的巨量負載（Jumbo Payload）選項。

(5) 下個首部(Next Header)

8位，識別緊跟IPv6頭後的包頭類型，如擴展頭（有的話）或某個傳輸層協議頭（諸如TCP，UDP或着ICMPv6）。

(6) 跳數限制(Hop Limit)

8位，相似於IPv4的TTL（生命期）字段，用包在路由器之間的轉發次數來限定包的生命期。包每通過一次轉發，該字段減1，減到0時就把這個包丟棄。

(7) 源地址(Source Address)

128位，發送方主機地址。

(8) 目的地址(Destination Address)

128位，在大多數狀況下，目的地址即信宿地址。但若是存在路由擴展頭的話，目的地址多是發送方路由表中下一個路由器接口。

擴展包頭

IPv6包頭設計中對原IPv4包頭所作的一項重要改進就是將全部可選字段移出IPv6包頭，置於擴展頭中。因爲除Hop-by-Hop選項擴展頭外，其餘擴展頭不受中轉路由器檢查或處理，這樣就能提升路由器處理包含選項的IPv6分組的性能。

NetAnalyzer中獲取的IPv6原始數據如圖2.13

圖2.13 IPv6原始數據

NetAnalyzer中分析獲取的IPv6的信息如圖2.14

圖 2.14 IPv6在Netanalyzer中的分析結果

6 網際控制報文協議(ICMP)

ICMP是（Internet Control Message Protocol）Internet控制報文協議。它是TCP/IP協議族的一個子協議，用於在IP主機、路由器之間傳遞控制消息。控制消息是指網絡通不通、主機是否可達、路由是否可用等網絡自己的消息。這些控制消息雖然並不傳輸用戶數據，可是對於用戶數據的傳遞起着重要的做用。

ICMP協議是一種面向無鏈接的協議，用於傳輸出錯報告控制信息。它是一個很是重要的協議，它對於網絡安全具備極其重要的意義。

它是TCP/IP協議族的一個子協議,屬於網絡層協議,主要用於在主機與路由器之間傳遞控制信息,包括報告錯誤、交換受限控制和狀態信息等。當遇到IP數據沒法訪問目標、IP路由器沒法按當前的傳輸速率轉發數據包等狀況時，會自動發送ICMP消息。

ICMP提供一致易懂的出錯報告信息。發送的出錯報文返回到發送原數據的設備，由於只有發送設備纔是出錯報文的邏輯接受者。發送設備隨後可根據ICMP報文肯定發生錯誤的類型，並肯定如何才能更好地重發失敗的數據包。可是ICMP惟一的功能是報告問題而不是糾正錯誤，糾正錯誤的任務由發送方完成。

咱們在網絡中常常會使用到ICMP協議，好比咱們常用的用於檢查網絡通不通的Ping命令（Linux和Windows中均有），這個「Ping」的過程實際上就是ICMP協議工做的過程。還有其餘的網絡命令如跟蹤路由的Tracert命令也是基於ICMP協議的。

ICMP首部格式

圖2.15 ICMP報文格式

(1) 類型(Type)

用於定義ICMP報文的類型。

(2) 代碼(Code)

用於定義標識發送這個特定報文類型的緣由。

(3) 校驗和(Check sum)

用於數據傳輸的差錯控制，提供ICMP整個報文的校驗和，其計算方法與IP首部的校驗和計算方法相似。

(4) 首部其餘部分

由報文類型來肯定相應的內容，大部分差錯報告未使用該字段。

(5) 數據(Data)

T提供了ICMP差錯和狀態報告信息，內容因報文類型而異。

7 傳輸控制協議(TCP)

TCP：Transmission Control Protocol 傳輸控制協議TCP是一種面向鏈接（鏈接導向）的、可靠的、基於字節流的運輸層（Transport layer）通訊協議，由IETF的RFC 793說明（specified）。在簡化的計算機網絡OSI模型中，它完成第四層傳輸層所指定的功能，UDP是同一層內另外一個重要的傳輸協議。

在因特網協議族（Internet protocol suite）中，TCP層是位於IP層之上，應用層之下的運輸層。不一樣主機的應用層之間常常須要可靠的、像管道同樣的鏈接，可是IP層不提供這樣的流機制，而是提供不可靠的包交換。

應用層向TCP層發送用於網間傳輸的、用8位字節表示的數據流，而後TCP把數據流分割成適當長度的報文段（一般受該計算機鏈接的網絡的數據鏈路層的最大傳送單元(MTU)的限制）。以後TCP把結果包傳給IP層，由它來經過網絡將包傳送給接收端實體的TCP層。TCP爲了保證不發生丟包，就給每一個字節一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。而後接收端實體對已成功收到的字節發回一個相應的確認(ACK)；若是發送端實體在合理的往返時延(RTT)內未收到確認，那麼對應的數據（假設丟失了）將會被重傳。TCP用一個校驗和函數來檢驗數據是否有錯誤；在發送和接收時都要計算和校驗。

首先，TCP創建鏈接以後，通訊雙方都同時能夠進行數據的傳輸，其次，他是全雙工的；在保證可靠性上，採用超時重傳和捎帶確認機制。

在流量控制上，採用滑動窗口協議，協議中規定，對於窗口內未經確認的分組須要重傳。

在擁塞控制上，採用廣受好評的TCP擁塞控制算法（也稱AIMD算法），該算法主要包括三個主要部分：1，加性增、乘性減；2，慢啓動；3，對超時事件作出反應。

TCP協議首部格式：

圖2.16 Tcp協議首部格式

(1) 源端口(Source Port)

源主機進程的端口。

(2) 目的端口(Destination Port)

標識目的主機的進程端口號

(3) 序列號(Sequence Number)

在一個鏈接中用於肯定該數據報文的偏移量。

(4) 確認序列號(Acknowledgement Number)

對對方主機發來的信息進行確認，從告訴對方已經成功獲取的數據。

(5) 數據偏移量(Data Offset)

在一些書中也叫首部長度，由於TCP協議有擴展字段，因此須要使用該字段標註，無擴展字段時，爲20。

(6) 保留字段

(7) 標誌(Flags)

用於傳遞該報文的狀態信息。

(8) 窗口大小(Window Size)

配合滑動窗口而設計的字段。

(9) 校驗和(Check Sum)

對所傳數據進行校驗，以肯定數據是否完整。

(10) 緊急指針(Urgent Pointer)

配合狀態爲標誌URG使用，提醒主機儘快提交數據。

(11) 選項(Options)

用來完成如商議從新設定窗口大小等相似的任務。

NetAnalyzer中獲取的TCP報文數據如圖2.17，

圖2.17 NetAnalyzer中獲取的TCP原始數據

從圖中能夠看到該報文TCP字段有28個字節，因此TCP首部帶有擴展字段。

NetAnalyzer中分析Tcp報文的結果如圖2.18所示

圖 2.18 TCP報文在NetAnalyzer中的分析結果

8 用戶報文協議(UDP)

UDP 是User Datagram Protocol的簡稱，中文名是用戶數據包協議，是 OSI 參考模型中一種無鏈接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務。它是IETF RFC 768是UDP的正式規範。

UDP協議的全稱是用戶數據包協議，在網絡中它與TCP協議同樣用於處理

數據包，是一種無鏈接的協議。在OSI模型中，在第四層——傳輸層，處於IP協議的上一層。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送以後，是沒法得知其是否安全完整到達的。UDP用來支持那些須要在計算機之間傳輸數據的網絡應用。包括網絡視頻會議系統在內的衆多的客戶/服務器模式的網絡應用都須要使用UDP協議。UDP協議從問世至今已經被使用了不少年，雖然其最初的光彩已經被一些相似協議所掩蓋，可是即便是在今天，UDP仍然不失爲一項很是實用和可行的網絡傳輸層協議。

與所熟知的TCP（傳輸控制協議）協議同樣，UDP協議直接位於IP（網際協議）協議的頂層。根據OSI（開放系統互連）參考模型，UDP和TCP都屬於傳輸層協議。

UDP協議的主要做用是將網絡數據流量壓縮成數據包的形式。一個典型的數據包就是一個二進制數據的傳輸單位。每個數據包的前8個字節用來包含報頭信息，剩餘字節則用來包含具體的傳輸數據。

UDP首部格式

圖2.19 UDP報文首部格式

(1) 源端口號(Source Port)

發送數據的主機端口號。

(2) 目的端口號(Destination Port)

接受數據的主機的端口號。

(3) 數據長度(Length)

整個報文的數據長度。

(4) 校驗和(Checksum)

提取僞首部與UPD首部信息的校驗和。

NetAnalyzer中獲取的UDP原始數據如圖2.20所示

圖2.20 UDP報文原始數據

NetAnalyzer中獲取的UDP報文首部如圖2.21所示

圖2.21 NetAnalyzer中得到的UDP首部信息

在這裏只是對一些經常使用的網絡協議作一些簡單說明，事實上網絡協議不少並且有些數據包也不會嚴格的按照OSI七層模型或TCP/IP的模型來執行，只有深刻了理解他們，咱們才能夠進行後面的開發工做。我上面的文件都是本身蒐集或作實驗採集到的，文件格式爲libpcap方式的pcap格式文件，你能夠用著名Wirshark 打開，也能夠用非著名的NetAnalyzer^_^，在這些文件中並沒用加入SMTP和POP3兩個著名的協議，老實說，我是故意的，由於經過抓包能夠輕鬆的破解個人郵箱密碼，因此我沒放，大家能夠試着去抓一下

SMTP 端口 53

POP3 端口 110

過濾表達式爲: tcp port 53 or tcp port 110

具體怎麼用，看幫助去吧

好了今天就寫到這裏，歡迎指正。

NetAnalyzer下載地址

NetAnalzyer交流羣：39753670 （PS 只提供交流平臺，羣主基本不說話^_^）

[轉載請保留做者信息做者：馮天文網址：http://www.cnblogs.com/twzy/p/4762077.html]