首頁  >  文章  >  Java  >  Java中關於tcp和udp以及ip協定的圖文介紹

Java中關於tcp和udp以及ip協定的圖文介紹

黄舟
黄舟原創
2017-07-21 16:12:412059瀏覽

這篇文章主要為大家詳細介紹了tcp、udp、ip協議分析的相關資料,具有一定的參考價值,有興趣的小伙伴們可以參考一下

互連網早期的時候,主機間的互連使用的是NCP協定。這種協定本身有很多缺陷,如:不能互連不同的主機,不能互連不同的作業系統,沒有糾錯功能。為了改善這個缺點,大牛弄出了TCP/IP協議。現在幾乎所有的作業系統都實作了TCP/IP協定棧。

TCP/IP協定堆疊主要分為四層:應用層、傳輸層、網路層、資料鏈結層,每層都有對應的協議,如下圖


#所謂的協定就是雙方進行資料傳輸的一種格式。整個網路中使用的協定有很多,所幸的是每一種協定都有RFC文件。這裡只對IP、TCP、UDP協定頭做一個分析。

首先來看看在網路中,一幀乙太網路封包的格式:


在Linux 作業系統中,當我們想發送數據的時候,我們只需要在上層準備好數據,然後提交給內核協議棧, 內核協議棧自動添加相應的協議頭。下面我們來看看,每一層新增的協定頭具體內容。

一. TCP協定

TCP協定是連結導向、保證高可靠性(資料無遺失、資料無失序、資料無錯誤、資料無重複到達)傳輸層協定。

1.TCP頭分析

先來分析TCP頭的格式以及每個欄位的意義:


(1)連接埠號碼[16bit]

我們知道,網路實作的是不同主機的進程間通訊。在一個作業系統中,有很多進程,當資料到來時要提交給哪個進程進行處理呢?這就需要用到端口號。在TCP頭中,有來源連接埠號碼(Source Port)和目標連接埠號碼(Destination Port)。來源連接埠號碼標識了發送主機的進程,目標連接埠號碼標識接受方主機的進程。

(2)序號[32bit]

序號分為發送序號(Sequence Number)和確認序號(Acknowledgment Number)。

傳送序號:用來識別從 TCP來源端傳送到 TCP目的端的資料位元組流,它表示在這個封包段中的第一個資料位元組的順序號。如果將位元組流看作在兩個應用程式間的單向流動,則 TCP用順序號對每個位元組進行計數。序號是 32bit的無符號數,序號到達 2  32- 1後又從 0開始。當建立新的連線時, SYN標誌變 1,順序號欄位包含此主機選擇的該連結的初始順序號 ISN( Initial Sequence Number)。

確認序號:包含發送確認的一端所期望收到的下一個順序號碼。因此,確認序號應為上次已成功收到資料位元組順序號加 1。只有 ACK標誌為 1時確認序號欄位才有效。 TCP為應用層提供全雙工服務,這意味著資料能在兩個方向上獨立地進行傳輸。因此,連接的每一端必須保持每個方向上的傳輸資料順序號。

(3)偏移[4bit]

這裡的偏移實際上指的是TCP首部的長度,它用來表示TCP首部中32 bit字的數目,透過它可以知道一個TCP包它的用戶資料是從哪裡開始的。這個字段佔4bit,如4bit的值是0101,則表示TCP首長度是5 * 4 = 20位元組。 所以TCP的首長度最大為15 * 4 = 60位元組。然而沒有可選字段,正常長度為20位元組。

(4)Reserved [6bit]

目前沒有使用,它的值都是0

(5)標誌[6bit ]

在TCP首部有6個標誌位元。他們中的多個可同時被置為1 。

URG         緊急指標(urgent pointer)有效

ACK          確認序號有效

##PSH  等待緩衝區裝滿

RST           一般表示斷開一個連線

例如:一個TCP的客戶端向一個沒有監聽的連接埠的伺服器端發起連線,wirshark抓包如下



可以看到host:192.168.63.134向host:192.168.63.132發起連線請求,但是host:192.168.63.132並沒有處於監聽對應埠的伺服器端,這:192.168.63.132並沒有處於監聽對應埠的伺服器端,這時

host : 192.168.63.132發一個RST置位的TCP包斷開連線。


SYN          同步序號用來發起一個連線

FIN            傳送端完成傳送任務(即斷開連線)

(6)視窗大小(window)[16]視窗大小(window

##(6)視窗大小(window)[16]視窗大小(window


##(6) 視窗大小(window)[16]視窗大小(window

##(6)視窗大小(window)[16]視窗大小(window

##(6)視窗大小(window)[16]視窗大小(window


##(6)視窗大小(window)[16bit]##(6)視窗大小(window)》[1616]視窗大小(window)[16]視窗大小。

##視窗的大小,表示來源方法最多能接受的位元組數。 。

(7)校驗和[16bit]

校驗和覆寫了整個的TCP封包段:TCP首部和TCP資料。這是一個強制性的字段,一定是由發端計算和存儲,並由收端進行驗證。

(8)緊急指標[16bit]

只有當URG標誌置為1時緊急指標才有效。緊急指標是正的偏移量,和序號欄位中的值相加表示緊急資料最後一個位元組的序號。 TCP的緊急方式是發送端向另一端發送緊急資料的一種方式。
(9)TCP選項


是可選的,在後面抓包的時候,我們在看看它



2.重點詳解

(1)三次握手建立連線

#a.請求端(通常稱為客戶)發送一個SYN段指明客戶打算連接的伺服器的端口,以及初始序號(ISN,在這個例子中為1415531521)。這個SYN段為報文段1。

b.伺服器傳回包含伺服器的初始序號的SYN封包段(封包2)作為應答。同時,將確認序號設定為客戶的ISN加1以確認客戶的SYN封包段落。一個SYN將佔用一個序號
c.客戶必須將確認序號設定為伺服器的ISN加1以對伺服器的SYN封包段進行確認(封包3)

這三個封包完成連接的建立。這個過程也稱為三次握手(three-way handshake)




#用wirshark抓包如下:


可以看到三次握手確定了雙方間包的序號、最大接受資料的大小(window)以及MSS(Maximum Segment Size)。 MSS = MTU - IP頭 - TCP頭,MTU表示最大傳輸單元,我們在IP頭分析的時候會講到,它一般為1500個位元組。 IP頭和TCP 頭部帶可選選項的時候都是20個位元組。這樣的話MSS=1500 - 20 -20 = 1460。

MSS限制了TCP包攜帶資料的大小,它的意思就是當應用層向傳輸層提交資料透過TCP協定傳輸時,如果應用層的資料>MSS就必須分段,分成多個段,逐一的發過去。

例如:應用層一次向傳輸層提交4096個位元組數據,這個時候透過wirshark抓包效果如下:




前三次是三次握手的過程,後面三次是傳送資料的過程,由於資料大小是4096個字節,所以用了三次進行傳遞(1448 + 1448 + 1200)。細心的人會問為什麼每次傳送的最大資料大小不是1460個位元組呢?因為這裡的TCP攜帶可選項,TCP頭長度 = 20 + 12(可選選項大小) = 32位元組。 這樣能傳輸的最大資料為:1500 - 20 - 32 = 1448個位元組。

(2)四次揮手斷開連接

a.現在的網路通訊都是基於socket實現的,當客戶端將自己的socket進行關閉時,核心協定堆疊會向伺服器自動傳送一個FIN置位的包,請求斷開連線。我們稱首先發起斷開請求的一方稱為主動斷開方。
b.伺服器端收到請客端的FIN斷開請求後,核心協定堆疊會立即發送一個ACK包作為應答,表示已經收到客戶端的請求

c.伺服器運行一段時間後,關閉了自己的socket。這時候核心協定棧會向客戶端發送一個FIN置位的包,請求斷開連線

d.客戶端收到服務端發來的FIN斷開請求後,會發送一個ACK做出應答,表示已經收到服務端的請求


用wirshar抓包分析如下:################################################### ##(3)TCP可靠性的保證#######

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

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



(4)滑動視窗技術

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



二、UDP協定

#UDP協定也是傳輸層協議,它是無連接,不保證可靠的傳輸層協定。它的協定頭比較簡單,如下:



這裡的連接埠號碼就不解釋了,和TCP的連接埠號碼是一樣的意義。

Length佔用2個位元組,標識UDP頭的長度。 Checksum : 校驗和,包含UDP頭和資料部分。

三、IP協定

I P是T C P / I P協定族中最核心的協定。所有的T C P、U D P、I C M P及I G M P資料都以I P資料封包格式傳輸。它的特點如下:
不可靠(u n r e l i a b l e)的意思是它不能保證 I P資料報能成功地到達目的地。 I P僅提供最好的傳輸服務。如果發生某種錯誤時,例如某個路由器暫時用完了緩衝區, I P有一個簡單的錯誤處理演算法:丟棄該資料報,然後發送 I C M P訊息報給信源端。任何要求的可靠性必須由上層來提供(如T C P) 。

無連線(c o n n e c t i o n l e s s)這個術語的意思是I P並沒有維護任何關於後續資料報的狀態資訊。每個資料報的處理是相互獨立的。這也說明, I P數據報可以不按發送順序接收。如果一信來源向相同的信宿發送兩個連續的資料封包(先是A,然後是B) ,每個資料封包都是獨立地進行路由選擇,可能選擇不同的路線,因此B可能在A到達之前先到達。

1.IP 頭格式


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

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

(3)區分服務 佔8位,用來獲得更好的服務。這個欄位在舊標準中叫做服務類型,但實際上一直沒有被使用過。 1998年IETF把這個欄位改名為區分服務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)來源IP位址 佔32位元。 

(12)目的IP位址 佔32位元。

2.分片解釋

分片指的是需要傳送的資料大於最大傳輸單元(MTU)的時候,就需要分成多個包,然後一個個發送給對方。我們在說TCP的時候,說到MSS很多人不能區分它們。透過下面的圖,我想就可以完全區分它們了。

個人覺的如果透過TCP協定傳輸數據,到IP層的時候,可定不需要分片了。只有在透過UDP協定傳送大數據的時候,才需要分片。
例如:用UDP協定傳送10240個位元組資料


可以看到,但資料提交到網路層的時候,由於資料超過了最大傳輸單元,就分片了。分成多個包透過IP協定發送個對方。每個封包最大的位元組為MTU - IP頭 = 1500 - 20 = 1480。

四、乙太網路頭


#三部分組成:來源MAC Address | 目的MAC Address | 所使用的協定.

所以在乙太網路中,封包的格式有一下幾種:


ARP協定是透過IP位址取得對應的MAC位址,稱為位址解析協定

RARP協定是透過MAC位址來獲得對應的IP位址,稱為逆向位址解析協定

以上是Java中關於tcp和udp以及ip協定的圖文介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn