JavaSE——UDP協議網絡編程（一）。本站提示廣大學習愛好者：（JavaSE——UDP協議網絡編程（一））文章只能為提供參考，不一定能成為您想要的結果。以下是JavaSE——UDP協議網絡編程（一）正文
UDP協議是英文UserDatagramProtocol的縮寫，即用戶數據報協議，次要用來支持那些需求在計算機之間傳輸數據的網絡使用。包括網絡視頻會議零碎在內的眾多的客戶/服務器形式的網絡使用都需求運用UDP協議。
用戶數據報協議，是一個復雜的面向數據報的運輸層協議。UDP不提供牢靠性，它只是把使用順序傳給IP層的數據報發送出去，但是並不能保證它們能抵達目的地。由於UDP在傳輸數據報前不必在客戶和服務器之間樹立一個銜接，且沒有超時重發等機制，故而傳輸速度很快。
TCP和UDP是TCP/IP協議中的兩個傳輸層協議（第四層），它們運用IP（第三層 網絡層）路由功用把數據包發送到目的地，從而為使用順序及使用層協議（包括：HTTP、SMTP、SNMP、FTP和Telnet）提供網絡服務。TCP提供的是面向銜接的、牢靠的數據傳播輸，而UDP提供的是非面向銜接的、不牢靠的數據傳播輸。面向銜接的協議在任何數據傳輸前就樹立好了點到點的銜接。ATM和幀中繼是 面向銜接的協議，但它們任務在數據鏈路層，而不是在傳輸層。普通的音頻電話也是面向銜接的。
UDP協議的次要作用是將網絡數據流量緊縮成數據報方式。在信息接納端UDP將數據報轉換成實踐內容。一個典型的數據報就是一個二進制數據的傳輸單位。每一個數據報的前8個字節用來包括報頭信息，剩余字節則用來包括詳細的傳輸數據。
數據報也是分組交流的一種方式，就是把所傳送的數據分段打成“包”，再傳送出去。看上去就好象運貨裝“集裝箱”似的。但是，與傳統的“銜接型”分組交流不同，它屬於“無銜接型”，是把打成的每個“包”（分組）都作為一個“獨立的報文”傳送出去，所以叫做“數據報”。
每個傳入或傳出的數據包（packet）叫做一個 IP 數據報。數據包的單位從小到大有bit(位）,byte（字節），M（兆），G，T。從字面看，兩者根本上是同一樣東西，但運用起來，前者經常指數據流，後者經常是討論數據信息內容的方式。
UDP報文由報頭和數據區組成。用戶數據報其中包括了8字節固定長度的UDP數據報頭和可變長的數據區。其中，數據報頭中個字段定義如下：
源端口和目的端口，辨別用於標識數據報的源端進程和目的端進程所運用的端口。字段長度為16比特，最大支持64 k個端口號。源端進程不需求目的端前往數據報，源端口字段可設為0
數據報長度，16比特，紀錄以字節計算的整個數據報的長度。
數據報校驗和，16比特，用於數據報的校驗和維護，在UDP中，校驗的功用是可選的，若不運用校驗，該字段的值為0。
UDP報頭
UDP報頭由4個域組成，其中每個域各占用2個字節，詳細如下：
源端口號
目的端口號
數據報長度
校驗值
UDP協議運用端口號為不同的使用保存其各自的數據傳輸通道。UDP和TCP協議正是采用這一機制完成對同一時辰內多項使用同時發送和接納數據的支持。數據發送一方（可以是客戶端或服務器端）將UDP數據報經過源端口發送出去，而數據接納一方則經過目的端口接納數據。有的網絡使用只能運用事後為其預留或注冊的靜態端口；而另外一些網絡使用則可以運用未被注冊的靜態端口。由於UDP報頭運用兩個字節寄存端口號，所以端口號的無效范圍是從0到65535。普通來說，大於49151的端口號都代表靜態端口。
數據報的長度是指包括報頭和數據局部在內的總的字節數。由於報頭的長度是固定的，所以該域次要被用來計算可變長度的數據局部（又稱為數據負載）。數據報的最大長度依據操作環境的不同而各異。從實際上說，包括報頭在內的數據報的最大長度為65535字節。不過，一些實踐使用往往會限制數據報的大小，有時會降低到8192字節。
UDP協議運用報頭中的校驗值來保證數據的平安。校驗值首先在數據發送方經過特殊的算法計算得出，在傳遞到接納方之後，還需求再重新計算。假如某個數據報在傳輸進程中被第三方竄改或許由於線路樂音等緣由遭到損壞，發送和接納方的校驗計算值將不會相符，由此UDP協議可以檢測能否出錯。這與TCP協議是不同的，後者要求必需具有校驗值。
UDP vs.TCP
UDP和TCP協議的次要區別是兩者在如何完成信息的牢靠傳遞方面不同。TCP協議中包括了專門的傳遞保證機制，當數據接納方收到發送方傳來的信息時，會自意向發送方收回確認音訊；發送方只要在接納到該確認音訊之後才持續傳送其它信息，否則將不斷等候直到收到確認信息為止。
與TCP不同，UDP協議並不提供數據傳送的保證機制。假如在從發送方到接納方的傳遞進程中呈現數據報的喪失，協議自身並不能做出任何檢測或提示。因而，通常人們把UDP協議稱為不牢靠的傳輸協議。
絕對於TCP協議，UDP協議的另外一個不同之處在於如何接納突法性的多個數據報。不同於TCP，UDP並不能確保數據的發送和接納順序。例如，一個位於客戶端的使用順序向服務器收回了以下4個數據報
D1
D22
D333
D4444
但是UDP有能夠依照以下順序將所接納的數據提交到服務端的使用：
D333
D1
D4444
D22
現實上，UDP協議的這種亂序性根本上很少呈現，通常只會在網絡十分擁堵的狀況下才有能夠發作。
由於UDP具有TCP所望塵莫及的速度優勢。雖然TCP協議中植入了各種平安保證功用，但是在實踐執行的進程中會占用少量的零碎開支，無疑使速度遭到嚴重的影響。反觀UDP由於掃除了信息牢靠傳遞機制，將平安和排序等功用移交給下層使用來完成，極大降低了執行時間，使速度失掉了保證。
包括視頻電話會議零碎在內的許多使用都證明了UDP協議的存在價值。由於絕對於牢靠性來說，這些使用愈加注重實踐功能，所以為了取得更好的運用效果（例如，更高的畫面幀刷新速率）往往可以犧牲一定的牢靠性（例如，會面質量）。音頻和多媒體使用，UDP是最好的選擇。在數據傳輸時間很短，以致於此前的銜接進程成為整個流量主體的狀況下，UDP也是一個好的選擇，如：DNS交流。把SNMP樹立在UDP上的局部緣由是設計者以為當發作網絡阻塞時，UDP較低的開支使其有更好的時機去傳送管理數據。
