UDP是傳輸層協議,和TCP協議處於一個分層中,可是與TCP協議不一樣,UDP協議並不提供超時重傳,出錯重傳等功能,也就是說其是不可靠的協議。 緩存
因爲不少軟件須要用到UDP協議,因此UDP協議必須經過某個標誌用以區分不一樣的程序所須要的數據包。端口號的功能就在於此,例如某一個UDP程序A在系統中註冊了3000端口,那麼,之後從外面傳進來的目的端口號爲3000的UDP包都會交給該程序。端口號理論上能夠有2^16這麼多。由於它的長度是16個bit 服務器
這是一個可選的選項,並非全部的系統都對UDP數據包加以檢驗和數據(相對TCP協議的必須來講),可是RFC中標準要求,發送端應該計算檢驗和。 網絡
UDP檢驗和覆蓋UDP協議頭和數據,這和IP的檢驗和是不一樣的,IP協議的檢驗和只是覆蓋IP數據頭,並不覆蓋全部的數據。UDP和TCP都包含一個僞首部,這是爲了計算檢驗和而攝製的。僞首部甚至還包含IP地址這樣的IP協議裏面都有的信息,目的是讓UDP兩次檢查數據是否已經正確到達目的地。若是發送端沒有打開檢驗和選項,而接收端計算檢驗和有差錯,那麼UDP數據將會被悄悄的丟掉(不保證送達),而不產生任何差錯報文。 spa
UDP能夠很長很長,能夠有65535字節那麼長。可是通常網絡在傳送的時候,一次通常傳送不了那麼長的協議(涉及到MTU的問題),就只好對數據分片,固然,這些是對UDP等上級協議透明的,UDP不須要關心IP協議層對數據如何分片,下一個章節將會稍微討論一些分片的策略。 設計
IP在從上層接到數據之後,要根據IP地址來判斷從那個接口發送數據(經過選路),並進行MTU的查詢,若是數據大小超過MTU就進行數據分片。數據的分片是對上層和下層透明,而數據也只是到達目的地還會被從新組裝,不過不用擔憂,IP層提供了足夠的信息進行數據的再組裝。 接口
在IP頭裏面,16bit識別號惟一記錄了一個IP包的ID,具備同一個ID的IP片將會被從新組裝;而13位片偏移則記錄了某IP片相對整個包的位置;而這兩個表示中間的3bit標誌則標示着該分片後面是否還有新的分片。這三個標示就組成了IP分片的全部信息,接受方就能夠利用這些信息對IP數據進行從新組織(就算是後面的分片比前面的分片先到,這些信息也是足夠了)。 it
由於分片技術在網絡上被常常的使用,因此僞造IP分片包進行流氓攻擊的軟件和人也就層出不窮。 程序設計
能夠用Trancdroute程序來進行簡單的MTU偵測。請參看教材。 軟件
這是不常被人注意到的一個細節,這是針對一些系統地實現來講的。當ARP緩存仍是空的時候。UDP在被髮送以前必定要發送一個ARP請求來得到目的主機的MAC地址,若是這個UDP的數據包足夠大,大到IP層必定要對其進行分片的時候,想象中,該UDP數據包的第一個分片會發出一個ARP查詢請求,全部的分片都輝等到這個查詢完成之後再發送。事實上是這樣嗎? route
結果是,某些系統會讓每個分片都發送一個ARP查詢,全部的分片都在等待,可是接受到第一個迴應的時候,主機卻只發送了最後一個數據片而拋棄了其餘,這實在是讓人匪夷所思。這樣,由於分片的數據不能被及時組裝,接受主機將會在一段時間內將永遠沒法組裝的IP數據包拋棄,而且發送組裝超時的ICMP報文(其實不少系統不產生這個差錯),以保證接受主機本身的接收端緩存不被那些永遠得不到組裝的分片充滿。
當目標主機的處理速度趕不上數據接收的速度,由於接受主機的IP層緩存會被佔滿,因此主機就會發出一個「我受不了」的一個ICMP報文。
UDP協議的某些特性將會影響咱們的服務器程序設計,大體總結以下: