這幾天在公司做項目要用到WinPcap，但在實現的過程中，需要分析捕獲的數據包，恰好用到了大學時學習的計算機網絡課程。現初步總結了幾個網絡協議及其格式：
一、MAC協議
在局域網中，硬件地址又稱爲物理地址或MAC地址(因爲這種地址用在MAC幀中)。
大家知道，在所有計算機系統的設計中，標識系統(identification system)都是一個核心問題。在標識系統中，地址就是爲識別某個系統的一個非常重要的標識符。在討論地址問題時，很多人常常引用著名文獻［SHOC78]給出的如下定義：
“名字指出我們所要尋找的那個資源，地址指出那個資源在何處，路由告訴我們如何到達該處。”
這個非形式的定義固然很簡單，但有時不夠準確。嚴格地講，名字應當與系統的所在地無關。這就像我們每一個人的名字一樣，不隨我們所處的地點而改變。但是802標準爲局域網規定了一種48bit的全球地址(一般都簡稱爲“地址”)，是指局域網上的每一臺計算機所插入的網卡上的地址。因此：
(1) 假定連接在局域網的一臺計算機的網卡壞了而我們更換了一個新的網卡，那麼這臺計算機的局域網的“地址”也就改變了，即使這臺計算機的地形位置一點也沒有變化。所接入的局城網也沒有任何改變。
(2) 假定我們將位於南京的某局城網上的一臺計算機轉移到北京。並連接在北京的某局域網上。雖然這臺計算機的地理位置改變了，但只要這臺計算機中的網卡不變，那麼這臺計算機在北京的局域網中的“地址”仍然和它在南京的局域網中的“地址”一樣。
因此可見，802標準所說的“地址”嚴格地講應當是每一個站的“名字”或標識符。但鑑於在家都早已習慣了將這種48bit的“名字”稱爲“地址”，所以本書也採用這種習慣用法。
儘管這種說法並不太嚴格，請讀者一定要弄清這個概念。
MAC地址也叫物理地址、硬件地址或鏈路地址，由網絡設備製造商生產時寫在硬件內部。IP地址與MAC地址在計算機裏都是以二進制表示的，IP地址是32位的，而MAC地址則是48位的。MAC地址的長度爲48位（6個字節），通常表示爲12個16進制數，每2個16進制數之間用冒號隔開，如：08:00:20:0A:8C:6D就是一個MAC地址，其中前6位16進制數08:00:20代表網絡硬件製造商的編號，它由IEEE（電氣與電子工程師協會）分配，而後3位16進制數0A:8C:6D代表該製造商所製造的某個網絡產品（如網卡）的系列號。只要你不去更改自己的MAC地址，那麼你的MAC地址在世界是惟一的。
以太網的MAC幀格式有兩種標準，一種是DIX Ethernet V2標準，另一種是IEEE的802.3標準，圖1 畫出了這兩種不同的MAC幀格式。
圖1 兩種不同的MAC幀格式
二、IP協議
IP協議（Internet Protocol）是網絡層協議，用在因特網上，TCP，UDP，ICMP，IGMP數據都是按照IP數據格式發送得。IP協議提供的是不可靠無連接得服務。IP數據包由一個頭部和一個正文部分構成。正文主要是傳輸的數據,IP頭部由20字節的固定長度和一個可選任意長度部分構成，以大段點機次序傳送，從左到右,IP協議數據包格式如圖2。
圖2 IP協議數據包格式
- 版本
- IP報文首部的第一個字段是4位版本字段。對IPv4來說，這個字段的值是4。
- 首部長度（IHL）
- 第二個字段是4位首部長度，說明首部有多少32位字長。由於IPv4首部可能包含數目不定的選項，這個字段也用來確定數據的偏移量。這個字段的最小值是5（RFC 791），最大值是15。
- DiffServ（DSCP）
- 最初被定義爲服務類型字段，但被RFC 2474重定義爲DiffServ。新的需要實時數據流的技術會應用這個字段，一個例子是VoIP。
- 總長
- 這個16位字段定義了報文總長，包含首部和數據，單位爲字節。這個字段的最小值是20（20字節首部+0字節數據），最大值是65,535。所有主機都必須支持最小576字節的報文，但大多數現代主機支持更大的報文。有時候子網會限制報文的大小，這時報文就必須被分片。
- 標識符
- 這個字段主要被用來唯一地標識一個報文的所有分片。一些實驗性的工作建議將此字段用於其它目的，例如增加報文跟蹤信息以協助探測僞造的源地址。
- 標誌
- 這個3位字段用於控制和識別分片，它們是：
- 位0：保留，必須爲0；
- 位1：禁止分片（DF）；
- 位2：更多分片（MF）。
- 如果DF標誌被設置但路由要求必須分片報文，此報文會被丟棄。這個標誌可被用於發往沒有能力組裝分片的主機。
- 當一個報文被分片，除了最後一片外的所有分片都設置MF標誌。不被分片的報文不設置MF標誌：它是它自己的最後一片。
- 分片偏移
- 這個13位字段指明瞭每個分片相對於原始報文開頭的偏移量，以8字節作單位。
- 生命期（TTL）
- 這個8位字段避免報文在互聯網中永遠存在（例如陷入路由環路）。存活時間以秒爲單位，但小於一秒的時間均向上取整到一秒。在現實中，這實際上成了一個跳數計數器：報文經過的每個路由器都將此字段減一，當此字段等於0時，報文不再向下一跳傳送並被丟棄。常規地，一份ICMP報文被髮回報文發送端說明其發送的報文已被丟棄。這也是traceroute的核心原理。
- 協議
- 這個字段定義了該報文數據區使用的協議。IANA維護着一份協議列表（最初由RFC 790定義）。
- 首部檢驗和
- 這個16位檢驗和字段用於對首部查錯。在每一跳，計算出的首部檢驗和必須與此字段進行比對，如果不一致，此報文被丟棄。值得注意的是，數據區的錯誤留待上層協議處理——用戶數據報協議和傳輸控制協議都有檢驗和字段。
- 因爲生存時間字段在每一跳都會發生變化，意味着檢驗和必須被重新計算，RFC 1071這樣定義計算檢驗和的方法：
- The checksum field is the 16-bit one's complement of the one's complement sum of all 16-bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.
- 源地址
- 一個IPv4地址由四個字節共32位構成，此字段的值是將每個字節轉爲二進制並拼在一起所得到的32位值。
- 例如，10.9.8.7是00001010000010010000100000000111。
- 這個地址是報文的發送端。但請注意，因爲NAT的存在，這個地址並不總是報文的真實發送端，因此發往此地址的報文會被送往NAT設備，並由它被翻譯爲真實的地址。
- 目的地址
- 與源地址格式相同，但指出報文的接收端。
- 選項
- 附加的首部字段可能跟在目的地址之後，但這並不被經常使用。請注意首部長度字段必須包括足夠的32位字來放下所有的選項（包括任何必須的填充以使首部長度能夠被32位整除）。當選項列表的結尾不是首部的結尾時，EOL（選項列表結束，0x00）選項被插入列表末尾。下表列出了可能的選項：
| 字段 | 長度（位） | 描述 |
|---|---|---|
| 備份 | 1 | 當此選項需要被備份到所有分片中時，設爲1。 |
| 類 | 2 | 常規的選項類別，0爲“控制”，2爲“查錯和措施”，1和3保留。 |
| 數字 | 5 | 指明一個選項。 |
| 長度 | 8 | 指明整個選項的長度，對於簡單的選項此字段可能不存在。 |
| 數據 | 可變 | 選項相關數據，對於簡單的選項此字段可能不存在。 |
- 注：如果首部長度大於5，那麼選項字段必然存在並必須被考慮。
- 注：備份、類和數字經常被一併稱呼爲“類型”。
- 寬鬆的源站選路（LSRR）和嚴格的源站選路（SSRR）選項不被推薦使用，因其可能帶來安全問題。許多路由器會拒絕帶有這些選項的報文。
數據
數據字段不是首部的一部分，因此並不被包含在檢驗和中。數據的格式在協議首部字段中被指明，並可以是任意的傳輸層協議。
一些常見協議的協議字段值被列在下面：
| 協議字段值 | 協議名 | 縮寫 |
|---|---|---|
| 1 | 互聯網控制消息協議 | ICMP |
| 2 | 互聯網組管理協議 | IGMP |
| 6 | 傳輸控制協議 | TCP |
| 17 | 用戶數據報協議 | UDP |
| 41 | IPv6封裝 | - |
| 89 | 開放式最短路徑優先 | OSPF |
| 132 | 流控制傳輸協議 | SCTP |
三、TCP協議
TCP協議（TRANSMISSION CONTROL PROTOCOL）是傳輸層協議，爲應用層提供服務，和UDP不同的是，TCP協議提供的可靠的面向連接的服務,跟IP頭部差不多，基本的長度也是20字節。TCP數據包是包含在一個IP數據報文中的,TCP數據包如圖3所示。
圖3 TCP數據包格式
四、UDP協議
在TCP/IP模型中，UDP爲網絡層以上和應用層以下提供了一個簡單的接口。UDP只提供數據的不可靠傳遞，它一旦把應用程序發給網絡層的數據發送出去，就不保留數據備份（所以UDP有時候也被認爲是不可靠的數據報協議）。UDP在IP數據報的頭部僅僅加入了複用和數據校驗（字段）。
UDP首部字段由4個部分組成，如圖4所示，其中兩個是可選的。各16bit的來源端口和目的端口用來標記發送和接受的應用進程。因爲UDP不需要應答，所以來源端口是可選的，如果來源端口不用，那麼置爲零。在目的端口後面是長度固定的以字節爲單位的長度域，用來指定UDP數據報包括數據部分的長度,長度最小值爲8byte。首部剩下地16bit是用來對首部和數據部分一起做校驗和（Checksum）的，這部分是可選的，但在實際應用中一般都使用這一功能。
圖4 UDP協議格式
由於缺乏可靠性且屬於非連接導向協定，UDP應用一般必須允許一定量的丟包、出錯和複製。有些應用，比如TFTP，如果需要則必須在應用層增加根本的可靠機制。但是絕大多數UDP應用都不需要可靠機制，甚至可能因爲引入可靠機制而降低性能。流媒體、實時多媒體遊戲和IP電話 (VoIP)就是典型的UDP應用。如果某個應用需要很高的可靠性，那麼可以用傳輸控制協議(TCP協議)來代替UDP。
端口號表示發送進程和接收進程。UDP長度字段指的是UDP首部和UDP數據的字節長度。該字段的最小值爲8字節（發送一份0字節的UDP數據報是OK）。這個UDP長度是有冗餘的。IP數據報長度指的是數據報全長，因此UDP數據報長度是全長減去IP首部的長度。
UDP檢驗和覆蓋UDP首部和UDP數據。回想IP首部的檢驗和，它只覆蓋IP的首部，並不覆蓋IP數據報中的任何數據。UDP的檢驗和是可選的，它是一個端到端的檢驗和。它由發送端計算，然後由接收端驗證。其目的是爲了發現UDP首部和數據在發送端到接收端之間發生的任何改動。
儘管U D P檢驗和的基本計算方法與I P首部檢驗和計算方法相類似（16 bit字的二進制反碼和） ，但是它們之間存在不同的地方。首先， U D P數據報的長度可以爲奇數字節，但是檢驗和算法是把若干個 16 bit字相加。解決方法是必要時在最後增加填充字節0，這只是爲了檢驗和的計算（也就是說，可能增加的填充字節不被傳送） 。其次，U D P數據報和T C P段都包含一個1 2字節長的僞首部，它是爲了計算檢驗和而設置的。僞首部包含 I P首部一些字段。其目的是讓 U D P兩次檢查數據是否已經正確到達目的地（例如，I P沒有接受地址不是本主機的數據報，以及 I P沒有把應傳給另一高層的數據報傳給U D P）。
圖5 帶僞首部的UDP格式
UDP和TCP首部都包含一個12字節的僞首部(如圖6)，包含了IP首部和自身的一些字段，主要是爲了計算檢驗和而設置的。僞首部是不佔實際空間的。僞首部包含IP首部的一些字段，目的是讓UDP兩次檢查數據是否已經到達目的地，以及IP層是否正確地傳輸了數據。
如果發送端沒有計算檢驗和而接收端檢測到檢驗和有差錯，那麼 U D P數據報就要被悄悄地丟棄。不產生任何差錯報文（當I P層檢測到I P首部檢驗和有差錯時也這樣做） 。
僞首部的源IP地址字段和目的IP地址字段記錄了發送UDP報文時使用的源IP地址和目的IP地址。 協議字段指明瞭所使用的協議類型代碼（UDP是17），而UDP長度字段是UDP數據報的長度（僞首部的長度不計算在內）。
UDP計算校驗和的方法和計算IP數據報首部校驗和的方法相似。 但不同的是：IP數據報的校驗和只檢驗IP數據報的首部，但UDP的校驗和是將首部和數據部分一起都檢驗。 在發送端，首先是將全零放入檢驗和字段。再將僞首部以及UDP用戶數據報看成是由許多16bit的字串接起來。 若UDP用戶數據報的數據部分不是偶數個字節，則要填入一個全零字節(但此字段不發送)。 然後按二進制反碼計算出這些16bit字的和(兩個數進行二進制反碼求和的運算的規則是：從低位到高位逐列進行計算。
0和0相加是0，0和1相加是1，1和1相加是0但要產生一個進位1，加到下一列。若最高位相加後產生進位，則最後得到的結果要加1)。 將此和的二進制反碼寫入校驗和字段後，發送此UDP用戶數據報。 在接收端，將收到的UDP用戶數據報連同僞首部(以及可能的填充全零字節)一起，按二進制反碼求這些16bit字的和。 當無差錯時其結果應全爲1。否則就表明有差錯出現， 接收端就應將此UDP用戶數據報丟棄(也可以上交給應用層，但附上出現了差錯的警告)。
以後再補充吧，呵呵，各位笑納。