簡介
cap包爲通過抓包軟件保存下來的數據包文件，不同的抓包軟件保存下來的cap包格式也有很大差異，從最開始的4個字節便可以看出，如下列出不同抓包軟件的cap包文件前4字節的差異
#define CAP_SNIFFER_WINDOWS_200X "\x58\x43\x50\x00" //sniffer抓包的cap文件 #define PCAP_WIRESHARK_TCPDUMP "\xd4\xc3\xb2\xa1 //wireshark抓包的pcap文件
以下以sniffer抓包的cap文件爲示例，但也會介紹下其他cap文件的基本格式。
如下是sniffer cap文件頭4個字節：
如下爲其他cap文件頭4個字節：
cap文件格式
cap文件開始有128字節的文件頭部分，接下來是抓獲到的數據包部分，包括40字節的數據頭和數據內容部分，具體的數據內容的長度需要根據數據頭部分確定。cap文件大概結構如下：
在此說明下，除了sniffer抓的文件，其他cap文件的格式區別如下，cap文件開始是24字節的文件頭部分，接下來同樣是數據包部分，包括16字節的數據頭和數據內容部分，具體的數據內容的長度同樣需要數據頭部分確定。
以上結構中數據內容部分包括從數據鏈路控制層頭開始，然後IP報頭，傳輸層報頭，最後到傳輸層以及後續的應用層數據。
數據頭格式
sniffer的128字節或其他類型cap文件的前16字節的文件頭部分在此只是取出前4個字節作爲區分cap文件類型，其他數據沒有用到。所以現在直接開始介紹數據頭部分。sniffer的數據頭部分爲40字節，具體的結構類型如下：
其他類型cap文件的數據頭部分格式如下，長度爲16字節：
struct tcpdump_record_head {
unsigned int time_seconds; //精確到秒的時間戳
unsigned int time_microsecondes; //精確到毫秒的時間戳
unsigned int len; //數包長度：標識所抓獲的數據包保存在cap文件中的實際長度，以字節爲單位。
unsigned int len_copy; //數據包實際長度：所抓獲的數據包真實的長度，如果文件中保存不是完整的數據包，那麼這個值可能要比前面的數據包長度的值大
};
數據內容解析
根據以上讀取出頭部信息中的數據長度，截取相應長度的數據內容進行解析，以下根據協議層數只解析每層協議頭部的個別字段，通過此方式對數據內容進行逐層解析。
1、首先解析數據鏈路層協議
對數據內容跳轉12個字節，過濾MAC信息，獲取2字節的協議類型字段，此字段標誌着數據鏈路層的下一層是什麼協議，對獲取出的2字節數據需要進行網絡字節序到主機字節序的轉換，然後與如下數據進行比較確定下層協議類型：
0x86DD /*ipv6*/ 0x0800 /* ipv4 */ 0x8847 /* MPLS unicast */ 0x8848 /* MPLS multicast */ 0x0806 /* arp */ 0x8035 /* rarp */ 0x8863 /* PPPoE protocol */
2、網絡層
通過以上方式獲取下層協議的類型後，下邊我們以ipv4作爲示例，假設數據內容的網絡層是IPV4，ipv4網絡層的數據內容第1個字節就包含了ip協議的版本號和ip層的頭長度，具體內容如下：
上圖中的45,4表示爲IPV4，5*4（ip頭部長度計算方式需要乘以4）表示ip頭部長度，因爲這次只獲取出1字節內容，所以沒必要對數據進行字節序轉換。
下邊是IP的數據包格式：
各字段的含義如下：
3、傳輸層
通過以上方式知道了網絡層頭部長度，可以直接跳過網絡層頭部部分，下邊開始解析傳輸層。傳輸層分爲TCP和UDP，下邊以TCP作爲示例，如下是TCP報文格式：
根據以上TCP報文格式可知如果想獲取TCP頭部長度，需要跳過12個字節，獲取4位首部長度，爲了方便獲取，我們會直接獲取兩個字節（16位）數據，並對獲取的數據進行字節序轉換，然後獲取4位首部長度。如下爲實現的代碼示例：
short tcpHeaderLenAndFlag = 0; int tcpHeaderLen = ((ntohs(tcpHeaderLenAndFlag)&0xF000)>>12) * 4; //TCP頭部的長度同樣需要乘以4
4、應用層
通過上訴方式可以獲取TCP的首部長度，直接跳過TCP層來到應用層，因爲沒有對TCP層進行詳細解析，目前無法獲取應用層協議的具體協議信息。
通過以上方式解析完數據頭和數據內容後，按照cap文件的格式，下邊又會是數據頭和數據內容，直到把cap文件全部解析完。
總結
本次簡單介紹了cap文件的格式，以及協議的基本解析，因爲會涉及到非常多的協議，在此不對數據包的具體內容進行解析。