IP協議是我們學習網路協議最開始，也是最基礎的協議。那麼今天我們主要介紹一下有關於IP協議頭格式的基本狀態。那麼就讓我們具體看以下有關於IP協議頭格式和Sniiffer Portable的IP頭的相關內容吧。IP(Internet Protocol,因特網協議)是OSI第三層——網路層協議,本節僅以IPv4版本為例進行介紹｡IP協議也是一個無連線的協議,主要就是負責在主機間定址,併為資料包設定路由,在交換資料前它並不建立會話｡因為它不保證正確傳遞｡另一方面,資料在被收到時,IP不需要收到確認,所以它是不可靠的｡

IP協議頭格式

資料在經過IP網路層時,也會對資料進行封裝,也就有相應的IP協議包頭了｡在乙太網幀中,IPv4包頭緊跟著乙太網幀頭,同時乙太網幀頭中的協議型別值設定為十六進位制的0800｡

◆版本(Version)

指定IP協議的版本號｡因為目前仍主要使用IPv4版本,所以這裡的值通常是 0x4 (注意封包使用的數字通常都是十六進位的)｡佔4位｡

◆包頭長度(Internet Header Length,IHL)

指明IPv4協議包頭長度的位元組數包含多少個32位｡由於IPv4的包頭可能包含可變數量的可選項,所以這個欄位可以用來確定IPv4資料報中資料部分的偏移位置｡IPv4包頭的最小長度是20個位元組,因此IHL這個欄位的最小值用十進位制表示就是5｡佔4位｡由於它是一個4位元欄位,因此首部最長為60個位元組,但實際上目前最多仍為24個位元組｡

◆服務型別(Type of Service,TOS)

定義IP封包在傳送過程中要求的服務型別,共由8個bit組成其中每個bit的組合分別代表不同的意思｡4bit中只能置其中1bit｡如果所有4bit均為0,那麼就意味著是一般服務｡具體如下:

◆000..... (Routine): 過程欄位,佔3位｡設定了資料包的重要性,取值越大資料越重要,取值範圍為:0(正常)~ 7(網路控制)

◆...0....(Delay):延遲欄位 ,佔1位,取值:0(正常)､1(期特低的延遲) 

◆....0...(Throughput):流量欄位,佔1位｡取值:0(正常)､1(期特高的流量) 

◆.....0..(Reliability) :可靠性欄位,佔1位｡取值:0(正常)､1(期特高的可靠性)

◆…..0.(ECN-Capable Transport):顯式擁塞指示傳輸欄位,佔1位｡由源端設定,以顯示源端節點的傳輸協議是支援ECN(Explicit Cogestion Notifica tion,顯式擁塞指示)的｡取值:0(不支援ECN)､1(支援ECN)

◆.......0(Congestion Experienced):擁塞預警欄位,佔1位｡取值:0(正常,不擁塞)､1(擁塞)

◆包長度(Total Length,TL)

IP協議頭格式中指定IP包的總長,通常以byte做單位來表示該封包的總長度此數值包括標頭和資料的總和｡它以位元組為單位,佔16位｡利用首部長度欄位和總長度欄位,就可以知道IP資料報中資料內容的起始位置和長度｡

由於該欄位長16位元,所以IP資料報最長可達65535位元組｡儘管可以傳送一個長達65535位元組的IP資料報,但是大多數的鏈路層都會對它進行分段｡而且,主機也要求不能接收超過576位元組的資料報｡由於TCP把使用者資料分成若干段,因此一般來說這個限制不會影響TCP｡UDP的應用(如RIP､TFTP､BOOTP､DNS､SNMP等),都限制使用者資料報長度為512位元組,小於576位元組｡但是,事實上現在大多數的實現允許超過8192位元組的IP資料報｡

總長度欄位是IP首部中必要的內容,因為一些資料鏈路(如乙太網)需要填充一些資料以達到最小長度｡儘管乙太網的最小幀長為46個位元組(將在本章後面介紹),但是IP資料可能會更短｡如果沒有總長度欄位,那麼IP層就不知道46位元組中有多少是IP資料報的內容｡

◆標識(Identification)

每一個IP封包都有一個16位的唯一識別碼｡當程式產生的資料要通過網路傳送時都會被拆散成封包形式傳送,當封包要進行重組的時候這個ID就是依據了｡佔16位｡

標識欄位唯一地標識主機發送的每一份資料報｡通常每傳送一份訊息它的值就會加1｡RFC791認為標識欄位應該由讓IP傳送資料報的上層來選擇｡假設有兩個連續的IP資料報,其中一個是由TCP生成的,而另一個是由UDP生成的,那麼它們可能具有相同的標識欄位｡儘管這也可以照常工作(由重組演算法來處理),但是在大多數從伯克利派生出來的系統中,每傳送一個IP資料報,IP層都要把一個核心變數的值加1,不管交給IP的資料來自哪一層｡核心變數的初始值根據系統引導時的時間來設定｡

◆標記(Flags)

這是當封包在傳輸過程中進行最佳組合時使用的3個bit的識別記號｡佔3位｡

◆000(Reserved Fragment):保留分段｡當此值為0的時候表示目前未被使用｡

◆.0.(Don't Fragment):不分段｡當此值為0的時候表示封包可以被分段,如果為1則不能被分割｡ 

◆..0( More Fragment):更多分段｡當上一個值為0時,此值為0就示該封包是最後一個封包,如果為1則表示其後還有被分割的封包｡

◆分段偏移(Fragment Offset,FO)

IP協議頭格式規定當封包被分段之後,由於網路情況或其它因素影響其抵達順序不會和當初切割順序一至,所以當封包進行分段的時候會為各片段做好定位記錄,以便在重組的時候就能夠對號入座｡值為多少個位元組,如果封包並沒有被分段,則FO值為“0"｡ 佔13位｡ 

◆生存時間(Time To Live,TTL)

生存時間欄位設定了資料報可以經過的最多路由器數,表示資料包在網路上生存多久｡TTL的初始值由源主機設定(通常為32或64),一旦經過一個處理它的路由器,它的值就減去1｡當該欄位的值為0時,資料報就被丟棄,併發送ICMP訊息通知源主機｡這樣當封包在傳遞過程中由於某些原因而未能抵達目的地的時候就可以避免其一直充斥在網路上面｡佔8位｡

◆協議(Protocol,PROT)

指該封包所使用的網路協議型別,如ICMP､DNS等｡佔8位｡各協議對應的值如表1所示｡

表1 協議號

◆頭校驗和(Header checksum)

指IPv4資料報包頭的校驗和｡這個數值用來檢錯用的,用以確保封包被正確無誤的接收到｡當封包開始進行傳送後,接收端主機會利用這個檢驗值會來檢驗餘下的封包,如果一切無誤就會發出確認資訊表示接收正常｡與UDP和TCP協議包頭中的校驗和作用是一樣的｡佔16位｡

首部檢驗和欄位是根據IP首部計算的檢驗和碼,不對首部後面的資料進行計算｡ICMP､IGMP､UDP和TCP協議在它們各自的首部中均含有同時覆蓋首部和資料檢驗和碼｡

IP協議頭格式規定了：計算一份資料報的IP檢驗和,首先把檢驗和欄位置為0｡然後,對首部中每個16位進行二進位制反碼求和(整個首部看成是由一串16位的字組成),結果存在檢驗和欄位中｡當接收端收到一份IP資料報後,同樣對首部中每個16 位進行二進位制反碼的求和｡由於接收方在計算過程中包含了傳送方存在首部中的檢驗和,因此,如果首部在傳輸過程中沒有發生任何差錯,那麼接收方計算的結果應該為全1｡如果結果不是全1(即檢驗和錯誤),那麼IP就丟棄收到的資料報｡但是不生成差錯訊息,由上層去發現丟失的資料報並進行重傳｡

ICMP､IGMP､UDP和TCP都採用相同的檢驗和演算法,儘管TCP和UDP除了本身的首部和資料外,在IP首部中還包含不同的欄位｡由於路由器經常只修改TTL欄位(減1),因此當路由器轉發一份訊息時可以增加它的檢驗和,而不需要對IP整個首部進行重新計算｡

◆源地址(Source Address,SA)

傳送IP資料包的IP地址｡佔32位｡

◆目的地址(Destination Address)

接收IP資料包的IP地址｡也佔32位｡

◆選項(Options)+填充(Padding)

這兩個選項較少使用,只有某些特殊的封包需要特定的控制才會利用到｡共32位｡這些選項通常包括:

◆安全和處理限制:用於軍事領域

◆記錄路徑:讓每個路由器都記下它的IP地址

◆時間戳:讓每個路由器都記下它的IP地址和時間

◆寬鬆的源站選路:為資料報指定一系列必須經過的IP地址

◆嚴格的源站選路:與寬鬆的源站選路類似,但是要求只能經過指定的這些地址,不能經過其他的地址｡

以上這些選項很少被使用,而且並非所有的主機和路由器都支援這些選項｡選項欄位一直都是以32位作為界限,在必要的時候插入值為0的填充位元組｡這樣就保證IP首部始終是32位的整數倍(這是首部長度欄位所要求的)｡

從以上IP協議頭格式可以看出,IP協議包頭大小也有兩種:當沒有“選項"這個欄位時,為160位,20個位元組;當有“選項"欄位時為192位,24個位元組｡它與TCP協議包頭大小是一樣的｡

關於IP協議常見的問題：

1.為什麼IP不是可靠連線的協議

IP層沒有超時和重傳機制，沒有連線握手協議。

2.IP資料報經過路由器都做了哪些改動

IP沒經過一個路由器，TTL數就會減一，如果最後TTL為0了，但是依然沒有到達目的地，這個IP包將會被丟棄。

這樣做了目的是為了防止出現迴圈迴路。並且最後一跳的路由器會發送一個ICMP不可達的資料包給源IP。

3.關於分片的問題

IP資料包的長度為16，也就是說最大為65535個位元組。但是我們知道資料鏈路層規定MTU最大傳輸單元為1500個位元組。

當IP資料包的大小超過了1500，IP資料包必須要進行分片處理。這還只是初始傳送端的分片，在網路中如果某個路由器的MTU小於1500，那麼還需要在路由器

端做分片，這就給IP包的完整接收照成了很大的不確定性（我們知道資料包達到終點不一定是按照順序的），因為萬一某一個分片丟失，可能會造成真個IP重傳，當然前提是高層協議支援重傳。對於TCP協議，不存在分片的問題，因為TCP報頭的選項欄位有MSS欄位，規定一個TCP包最大可傳輸的位元組數，一般是1500-20-20=1460位元組。也就是說到達IP封包的時候最大可承載資料只有1460個位元組，這樣就可以避免分片的問題。但是對於UDP這一類的協議，分片操作還是交給IP完成，雖然這樣可以增載入荷的效率，但是穩定性會受到很大的影響。