Java中關於udp協定簡單介紹

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

1.UDP簡要介紹

UDP是傳輸層協議，和TCP協議處於一個分層中，但是與TCP協議不同，UDP協議並不提供超時重傳，出錯重傳等功能，也就是說其是不可靠的協議。

2.UDP協定頭

#UDP埠號

由於許多軟體需要用到UDP協議，所以UDP協定必須透過某個標誌用來區分不同的程式所需的資料包。連接埠號碼的功能就在於此，例如某一個UDP程式A在系統中註冊了3000端口，那麼，以後從外面傳進來的目的端口號為3000的UDP包都會交給該程序。埠號理論上可以有2^16這麼多。因為它的長度是16個bit

UDP檢定和

這是一個可選的選項，並不是所有的系統都對UDP資料包加以檢驗和資料(相對TCP協定的必須來說)，但是RFC中標準要求，發送端應該計算檢驗和。

UDP檢驗並覆蓋UDP協定頭和數據，這和IP的檢驗和是不同的，IP協定的檢驗和只是覆蓋IP資料頭，不會覆蓋所有的資料。 UDP和TCP都包含一個偽首部，這是為了計算檢驗和而攝製的。偽首部甚至還包含IP位址這樣的IP協定裡面都有的訊息，目的是讓UDP兩次檢查資料是否已經正確到達目的地。如果發送端沒有開啟檢驗和選項，而接收端計算檢驗和有差錯，那麼UDP資料將會被悄悄的丟掉（不保證送達），而不會產生任何錯誤訊息。

UDP長度

UDP可以很長很長，可以有65535位元組那麼長。但是一般網路在傳送的時候，一次一般傳送不了那麼長的協議（涉及到MTU的問題），就只好對數據分片，當然，這些是對UDP等上級協議透明的，UDP不需要關心IP協議層對資料如何分片，下一個章節將會稍微討論一些分片的策略。

IP分片

#IP從上層接到資料以後，要根據IP位址來判斷從那個介面發送資料（透過選路），並進行MTU的查詢，如果資料大小超過MTU就進行資料分片。資料的分片是對上層和下層透明，而資料也只是到達目的地還會被重新組裝，不過不用擔心，IP層提供了足夠的資訊進行資料的再組裝。

在IP頭裡面，16bit識別號唯一記錄了一個IP包的ID,具有同一個ID的IP片將會被重新組裝；而13位片偏移則記錄了某IP片相對整個包的位置；而這兩個表示中間的3bit標誌則標示著該分片後面是否還有新的分片。這三個標示就組成了IP分片的所有信息，接受方就可以利用這些信息對IP資料進行重新組織（就算是後面的分片比前面的分片先到，這些信息也是足夠了）。
因為分片技術在網路上被經常的使用，所以偽造IP分片包進行流氓攻擊的軟體和人也就層出不窮。

可以用Trancdroute程式來進行簡單的MTU偵測。請參看教材。

UDP和ARP之間的互動式用

這是不常被人注意到的一個細節，這是針對一些系統地實現來說的。當ARP快取還是空的時候。 UDP在被發送之前一定要發送一個ARP請求來獲得目的主機的MAC位址，如果這個UDP的封包夠大，大到IP層一定要對其進行分片的時候，想像中，該UDP封包的第一個分片會發出一個ARP查詢請求，所有的分片都輝等到這個查詢完成以後再發送。事實上是這樣嗎？
結果是，某些系統會讓每一個分片都發送一個ARP查詢，所有的分片都在等待，但是接受到第一個回應的時候，主機卻只發送了最後一個資料片而拋棄了其他，這實在是讓人匪夷所思。這樣，因為分片的資料不能及時組裝，接受主機將會在一段時間內將永遠無法組裝的IP資料包拋棄，並且發送組裝超時的ICMP報文（其實很多系統不產生這個差錯），以保證接受主機自己的接收端快取不被那些永遠不會得到組裝的分片充滿。

ICMP來源站抑制錯誤

#當目標主機的處理速度趕不上資料接收的速度，因為接受主機的IP層快取會被佔滿，所以主機就會發出一個「我受不了」的一個ICMP封包。

UDP伺服器設計

#UDP協定的某些特性將會影響我們的伺服器程式設計，大致總結如下：

1.關於客戶IP和位址：伺服器必須有根據客戶IP位址和連接埠號碼判斷封包是否合法的能力（這似乎要求每個伺服器都要具備）
2.關於目的位址：伺服器必須要有過濾廣播位址的能力。
3.關於資料輸入：通常伺服器系統的每一個連接埠號碼都會和一塊輸入緩衝區對應，進來的輸入根據先來後到的原則等待伺服器的處理，所以難免會出現緩衝區溢出的問題，這種情況下，UDP封包可能會被丟棄，而應用伺服器程式本身並不知道這個問題。
4.伺服器應該要限製本地IP位址，就是說它應該可以把自己綁定到某一個網路介面的某一個連接埠上。

以上是Java中關於udp協定簡單介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！