IP協議頭格式的詳細分析
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位。 #p#
◆生存時間(Time To Live,TTL)
生存時間字段設置了數據報可以經過的最多路由器數,表示數據包在網絡上生存多久。TTL的初始值由源主機設置(通常為32或64),一旦經過一個處理它的路由器,它的值就減去1。當該字段的值為0時,數據報就被丟棄,并發送ICMP消息通知源主機。這樣當封包在傳遞過程中由於某些原因而未能抵達目的地的時候就可以避免其一直充斥在網路上面。占8位。
◆協議(Protocol,PROT)
指該封包所使用的網絡協議類型,如ICMP、DNS等。占8位。各協議對應的值如表1所示。
表1 協議號
協議號 |
協議 |
協議號 |
協議 |
00 |
IP |
22 |
XNS-IDP |
01 |
ICMP |
27 |
RDP |
02 |
IGMP |
29 |
ISO-TP4 |
03 |
GGP |
36 |
XTP |
04 |
IP-ENCAP |
37 |
DDP |
05 |
ST |
39 |
IDPR-CMTP |
06 |
TCP |
73 |
RSPF |
08 |
EGP |
81 |
VMTP |
12 |
PUP |
89 |
OSPFIGP |
17 |
UDP |
94 |
IPIP |
20 |
HMP |
98 |
ENCAP |
◆頭校驗和(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協議包頭大小是一樣的。