[創建時間：2015-08-27 22:15:17]
上篇我們回顧完了NetAnalyzer一些可有可無的歷史，在本篇，我決定先不對NetAnalyzer做介紹，而是先要了解一些關於構建NetAnalyzer的基礎知識，如系統中可以分析的一些網絡協議，了解它們的分布方式，字段含義等。在了解了協議的基礎上，以后學習配置Winpcap的開發環境，做一些簡單的數據采集程序就會更加方便。接下來則要介紹一下在開發NetAnalzyer過程中涉及到的一些數據結構與編程思想。
NetAnalyzer中的協議
在這里我並不想講太多關於協議體系結構的問題，也不管什么OSI七層模型，也不論TCP/IP的四層結構，也為這些體系方面的知識很多，而且有在很多的書中都有介紹。而在此處講的是，在NetAnalyzer中所能解析的數據，並對各數據字段給出相應的解釋與說明，最終只是作為參考資料，方便NetAnalyzer后續的開發升級。因此在此處所有數據報文分析數據將依照NetAnalyzer中現有的數據解析結果，與整體解析層次作為參考進行協議說明。
在介紹具體協議之前先看看NetAnalyzer數據分析界面
(a) 上面為獲取的數據包列表
(b) 左下角為具體的協議分析內容，也是該軟件的核心區域
(c) 右下角為數據包的具體原始數據
本軟件可以從網卡采集數據，也可以讀取緩存文件獲得，因為有些數據包不容易采集，所以可以到這里下載（不會博客傳文件，所以給一個鏈接吧）
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)2不需要分片，片偏移量(00000)2；生存時間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
具體怎么用，看幫助去吧
好了今天就寫到這里，歡迎指正。
NetAnalzyer交流群：39753670 （PS 只提供交流平台，群主基本不說話^_^）
[轉載請保留作者信息 作者：馮天文 網址：http://www.cnblogs.com/twzy/p/4762077.html]