TCP/IP數據報格式分析

TCP/IP協議(全卷)

 http://download.csdn.net/detail/whuancai/6525747


IP 數據包格式

(1)版本 佔4位,指IP協議的版本。通信雙方使用的IP協議版本必須一致。目前廣泛使用的IP協議版本號爲4(即IPv4)。關於IPv6,目前還處於草案階段。

(2)首部長度 佔4位,可表示的最大十進制數值是15。請注意,這個字段所表示數的單位是32位字長(132位字長是4字節),因此,當IP的首部長度爲1111時(即十進制的15),首部長度就達到60字節。當IP分組的首部長度不是4字節的整數倍時,必須利用最後的填充字段加以填充。因此數據部分永遠在4字節的整數倍開始,這樣在實現IP協議時較爲方便。首部長度限制爲60字節的缺點是有時可能不夠用。但這樣做是希望用戶儘量減少開銷。最常用的首部長度就是20字節(即首部長度爲0101),這時不使用任何選項。

(3)區分服務 佔8位,用來獲得更好的服務。這個字段在舊標準中叫做服務類型,但實際上一直沒有被使用過。1998IETF把這個字段改名爲區分服務DS(Differentiated Services)。只有在使用區分服務時,這個字段才起作用。

(4)總長度 總長度指首部和數據之和的長度,單位爲字節。總長度字段爲16位,因此數據報的最大長度爲216-1=65535字節。

  在IP層下面的每一種數據鏈路層都有自己的幀格式,其中包括幀格式中的數據字段的最大長度,這稱爲最大傳送單元MTU(Maximum Transfer Unit)。當一個數據報封裝成鏈路層的幀時,此數據報的總長度(即首部加上數據部分)一定不能超過下面的數據鏈路層的MTU值。

(5)標識(identification) 佔16位。IP軟件在存儲器中維持一個計數器,每產生一個數據報,計數器就加1,並將此值賦給標識字段。但這個標識並不是序號,因爲IP是無連接服務,數據報不存在按序接收的問題。當數據報由於長度超過網絡的MTU而必須分片時,這個標識字段的值就被複制到所有的數據報的標識字段中。相同的標識字段的值使分片後的各數據報片最後能正確地重裝成爲原來的數據報。

(6)標誌(flag) 佔3位,但目前只有2位有意義。

 標誌字段中的最低位記爲MF(More Fragment)MF=1即表示後面還有分片的數據報。MF=0表示這已是若干數據報片中的最後一個。

 標誌字段中間的一位記爲DF(Don’t Fragment),意思是不能分片。只有當DF=0時才允許分片。

(7)片偏移 佔13位。片偏移指出:較長的分組在分片後,某片在原分組中的相對位置。也就是說,相對用戶數據字段的起點,該片從何處開始。片偏移以8個字節爲偏移單位。這就是說,每個分片的長度一定是8字節(64位)的整數倍。

(8)生存時間 佔8位,生存時間字段常用的的英文縮寫是TTL(Time To Live),表明是數據報在網絡中的壽命。由發出數據報的源點設置這個字段。其目的是防止無法交付的數據報無限制地在因特網中兜圈子,因而白白消耗網絡資源。最初的設計是以秒作爲TTL的單位。每經過一個路由器時,就把TTL減去數據報在路由器消耗掉的一段時間。若數據報在路由器消耗的時間小於1秒,就把TTL值減1。當TTL值爲0時,就丟棄這個數據報。

(9)協議 佔8位,協議字段指出此數據報攜帶的數據是使用何種協議,以便使目的主機的IP層知道應將數據部分上交給哪個處理過程。

(10)首部檢驗和 佔16位。這個字段只檢驗數據報的首部,但不包括數據部分。這是因爲數據報每經過一個路由器,路由器都要重新計算一下首部檢驗和(一些字段,如生存時間、標誌、片偏移等都可能發生變化)。不檢驗數據部分可減少計算的工作量。

(11)源地址 佔32位。

(12)目的地址 佔32位。

 

 

 

  • 源端口號( 16 位):它(連同源主機 IP 地址)標識源主機的一個應用進程。
  • 目的端口號( 16 位):它(連同目的主機 IP 地址)標識目的主機的一個應用進程。這兩個值加上 IP 報頭中的源主機 IP 地址和目的主機 IP地址唯一確定一個 TCP 連接。
  • 順序號( 32 位):用來標識從 TCP 源端向 TCP 目的端發送的數據字節流,它表示在這個報文段中的第一個數據字節的順序號。如果將字節流看作在兩個應用程序間的單向流動,則 TCP 用順序號對每個字節進行計數。序號是 32bit 的無符號數,序號到達 2 32 - 1 後又從 0 開始。當建立一個新的連接時, SYN 標誌變 1 ,順序號字段包含由這個主機選擇的該連接的初始順序號 ISN ( Initial Sequence Number )。
  • 確認號( 32 位):包含發送確認的一端所期望收到的下一個順序號。因此,確認序號應當是上次已成功收到數據字節順序號加 1 。只有 ACK 標誌爲 1 時確認序號字段纔有效。 TCP 爲應用層提供全雙工服務,這意味數據能在兩個方向上獨立地進行傳輸。因此,連接的每一端必須保持每個方向上的傳輸數據順序號。
  • TCP 報頭長度( 4 位):給出報頭中 32bit 字的數目,它實際上指明數據從哪裏開始。需要這個值是因爲任選字段的長度是可變的。這個字段佔 4bit ,因此 TCP 最多有 60 字節的首部。然而,沒有任選字段,正常的長度是 20 字節。
  • 保留位( 6 位):保留給將來使用,目前必須置爲 0 。
  • 控制位( control flags , 6 位):在 TCP 報頭中有 6 個標誌比特,它們中的多個可同時被設置爲 1 。依次爲:
  • URG :爲 1 表示緊急指針有效,爲 0 則忽略緊急指針值。
  • ACK :爲 1 表示確認號有效,爲 0 表示報文中不包含確認信息,忽略確認號字段。
  • PSH :爲 1 表示是帶有 PUSH 標誌的數據,指示接收方應該儘快將這個報文段交給應用層而不用等待緩衝區裝滿。
  • RST :用於復位由於主機崩潰或其他原因而出現錯誤的連接。它還可以用於拒絕非法的報文段和拒絕連接請求。一般情況下,如果收到一個 RST爲 1 的報文,那麼一定發生了某些問題。
  • SYN :同步序號,爲 1 表示連接請求,用於建立連接和使順序號同步( synchronize )。
  • FIN :用於釋放連接,爲 1 表示發送方已經沒有數據發送了,即關閉本方數據流。
  • 窗口大小( 16 位):數據字節數,表示從確認號開始,本報文的源方可以接收的字節數,即源方接收窗口大小。窗口大小是一個 16bit 字段,因而窗口大小最大爲 65535
  • .. 字節。
  • 校驗和( 16 位):此校驗和是對整個的 TCP 報文段,包括 TCP 頭部和 TCP 數據,以 16 位字進行計算所得。這是一個強制性的字段,一定是由發送端計算和存儲,並由接收端進行驗證。
  • 緊急指針( 16 位):只有當 URG 標誌置 1 時緊急指針纔有效。緊急指針是一個正的偏移量,和順序號字段中的值相加表示緊急數據最後一個字節的序號。 TCP 的緊急方式是發送端向另一端發送緊急數據的一種方式。
  • 選項:最常見的可選字段是最長報文大小,又稱爲 MSS(Maximum Segment Size) 。每個連接方通常都在通信的第一個報文段(爲建立連接而設置SYN 標誌的那個段)中指明這個選項,它指明本端所能接收的最大長度的報文段。選項長度不一定是 32 位字的整數倍,所以要加填充位,使得報頭長度成爲整字數。
  • 數據: TCP 報文段中的數據部分是可選的。在一個連接建立和一個連接終止時,雙方交換的報文段僅有 TCP 首部。如果一方沒有數據要發送,也使用沒有任何數據的首部來確認收到的數據。在處理超時的許多情況中,也會發送不帶任何數據的報文段。

  • 請求端(通常稱爲客戶)發送一個 SYN 報文段( SYN 爲 1 )指明客戶打算連接的服務器的端口,以及初始順序號( ISN )。
  • 服務器發回包含服務器的初始順序號( ISN )的 SYN 報文段( SYN 爲 1 )作爲應答。同時,將確認號設置爲客戶的 ISN 加 1 以對客戶的SYN 報文段進行確認( ACK 也爲 1 )。
  • 客戶必須將確認號設置爲服務器的 ISN 加 1 以對服務器的 SYN 報文段進行確認( ACK 爲 1 ),該報文通知目的主機雙方已完成連接建立。

 

三次握手協議可以完成兩個重要功能:它確保連接雙方做好傳輸準備,並使雙方統一了初始順序號。初始順序號是在握手期間傳輸順序號並獲得確認:當一端爲建立連接而發送它的 SYN 時,它爲連接選擇一個初始順序號;每個報文段都包括了順序號字段和確認號字段,這使得兩臺機器僅僅使用三個握手報文就能協商好各自的數據流的順序號。一般來說, ISN 隨時間而變化,因此每個連接都將具有不同的 ISN 。

 

TCP 採用一種名爲“帶重傳功能的肯定確認( positive acknowledge with retransmission )”的技術作爲提供可靠數據傳輸服務的基礎。這項技術要求接收方收到數據之後向源站回送確認信息 ACK 。發送方對發出的每個分組都保存一份記錄,在發送下一個分組之前等待確認信息。發送方還在送出分組的同時啓動一個定時器,並在定時器的定時期滿而確認信息還沒有到達的情況下,重發剛纔發出的分組。圖 3-5 表示帶重傳功能的肯定確認協議傳輸數據的情況,圖 3-6 表示分組丟失引起超時和重傳。爲了避免由於網絡延遲引起遲到的確認和重複的確認,協議規定在確認信息中稍帶一個分組的序號,使接收方能正確將分組與確認關聯起來。

從圖 3-5 可以看出,雖然網絡具有同時進行雙向通信的能力,但由於在接到前一個分組的確認信息之前必須推遲下一個分組的發送,簡單的肯定確認協議浪費了大量寶貴的網絡帶寬。爲此, TCP 使用滑動窗口的機制來提高網絡吞吐量,同時解決端到端的流量控制。

   滑動窗口技術是簡單的帶重傳的肯定確認機制的一個更復雜的變形,它允許發送方在等待一個確認信息之前可以發送多個分組。如圖 3-7 所示,發送方要發送一個分組序列,滑動窗口協議在分組序列中放置一個固定長度的窗口,然後將窗口內的所有分組都發送出去;當發送方收到對窗口內第一個分組的確認信息時,它可以向後滑動併發送下一個分組;隨着確認的不斷到達,窗口也在不斷的向後滑動。

 

Tcp數據包格式

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章