❶ 計算機網路——TCP/UDP協議
計算機網路七層模型中，傳輸層有兩個重要的協議：
（1）用戶數據報協議UDP (User Datagram Protocol)
（2）傳輸控制協議TCP (Transmission Control Protocol)
UDP 在傳送數據之前不需要先建立連接。遠地主機的運輸層在收到UDP 報文後，不需要給出任何確認。雖然UDP 不提供可靠交付，但在某些情況下UDP 卻是一種最有效的工作方式。
TCP 則提供面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束後要釋放連接。TCP 不提供廣播或多播服務。由於TCP 要提供可靠的、面向連接的運輸服務，因此不可避免地增加了許多的開銷，如確認、流量控制、計時器以及連接管理等。
UDP 的主要特點是：
首部手段很簡單，只有8 個位元組，由四個欄位組成，每個欄位的長度都是兩個位元組。
前面已經講過，每條TCP 連接有兩個端點，TCP 連接的端點叫做套接字（socket）或插口。套接字格式如下：
套接寧socket= (IP 地址：埠號』）
每一條TCP 連接唯一地被通信兩端的兩個端點（即兩個套接宇）所確定。即：
TCP 連接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}
3次握手鏈接
4次握手釋放鏈接
斷開連接請求可以由客戶端發出，也可以由伺服器端發出，在這里我們稱A端向B端請求斷開連接。
各個狀態節點解釋如下：
下面為了討論問題的萬便，我們僅考慮A發送數據而B 接收數據並發送確認。因此A 叫做發送方，而B 叫做接收方。
「停止等待」就是每發送完一個分組就停止發送，等待對方的確認。在收到確認後再發送下一個分組。
使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網路上實現可靠的通信。像上述的這種可靠傳輸協議常稱為自動重傳請求ARQ (Automatic Repeat reQuest）。意思是重傳的請求是自動進行的。接收方不需要請求發送方重傳某個出錯的分組。
滑動窗口協議比較復雜，是TCP 協議的精髓所在。這里先給出連續ARQ 協議最基本的概念，但不涉提到許多細節問題。詳細的滑動窗口協議將在後面討論。
下圖表示發送方維持的發送窗口，它的意義是：位於發送窗口內的5 個分組都可連續發送出去，而不需要等待對方的確認。這樣，信道利用率就提高了。
連續ARQ 協議規定，發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。
接收方一般都是採用 累積確認 的方式。這就是說，接收方不必對收到的分組逐個發送確認，而是可以在收到幾個分組後，對按序到達的最後一個分組發送確認，這樣就表示：到這個分組為止的所有分組都己正確收到了。
累積確認 的優點是容易實現，即使確認丟失也不必重傳。但缺點是不能向發送方反映出接收方己經正確收到的所有分組的信息。
例如，如果發送方發送了前5 個分組，而中間的第3 個分組丟失了。這時接收方只能對前兩個分組發出確認。發送方無法知道後面三個分組的下落，而只好把後面的三個分組都再重傳一次。這就叫做Go-back-N （回退N ），表示需要再退回來重傳己發送過的N 個分組。可見當通信線路質量不好時，連續ARQ 協議會帶來負面的影響。
TCP 的滑動窗口是以位元組為單位的。現假定A 收到了B 發來的確認報文段，其中窗口是20 （位元組），而確認號是31 （這表明B 期望收到的下一個序號是31 ，而序號30 為止的數據己經收到了）。根據這兩個數據， A 就構造出自己的發送窗口，其位置如圖所示。
發送窗口表示：在沒有收到B 的確認的情況下， A可以連續把窗口內的數據都發送出去。凡是己經發送過的數據，在未收到確認之前都必須暫時保留，以便在超時重傳時使用。
發送窗口後沿的後面部分表示己發送且己收到了確認。這些數據顯然不需要再保留了。而發送窗口前沿的前面部分表示不允許發送的，因為接收方都沒有為這部分數據保留臨時存放的緩存空間。
現在假定A 發送了序號為31 ～ 41 的數據。這時發送窗口位置並未改變，但發送窗口內靠後面有11個位元組（灰色小方框表示）表示己發送但未收到確認。而發送窗口內靠前面的9 個位元組（ 42 ～ 50 ）是允許發送但尚未發送的。】
再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 號為止的數據是已經發送過確認，並且己經交付給主機了。因此在B 可以不再保留這些數據。接收窗口內的序號（31～50）足允許接收的。B 收到了序號為32 和33 的數據，這些數據沒有按序到達，因為序號為31 的數據沒有收到（也許丟失了，也許滯留在網路中的某處）。 請注意， B 只能對按序收到的數據中的最高序號給出確認，因此B 發送的確認報文段中的確認號仍然是31 （即期望收到的序號）。
現在假定B 收到了序號為31 的數據，並把序號為31～33的數據交付給主機，然後B刪除這些數據。接著把接收窗口向前移動3個序號，同時給A 發送確認，其中窗口值仍為20，但確認號是34，這表明B 已經收到了到序號33 為止的數據。我們注意到，B還收到了序號為37, 38 和40 的數據，但這些都沒有按序到達，只能先存在接收窗口。A收到B的確認後，就可以把發送窗口向前滑動3個序號，指針P2 不動。可以看出，現在A 的可用窗口增大了，可發送的序號范圍是42～53。整個過程如下圖：
A 在繼續發送完序號42-53的數據後，指針P2向前移動和P3重合。發送窗口內的序號都已用完，但還沒有再收到確認。由於A 的發送窗口己滿，可用窗口己減小到0，因此必須停止發送。
上面已經講到， TCP 的發送方在規定的時間內沒有收到確認就要重傳已發送的報文段。這種重傳的概念是很簡單的，但重傳時間的選擇卻是TCP 最復雜的問題之一。
TCP採用了一種自適應演算法 ，它記錄一個報文段發出的時間，以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間RTT，TCP 保留了RTT的一個加權平均往返時間RTTs （這又稱為平滑的往返時間， S 表示Smoothed 。因為進行的是加權平均，因此得出的結果更加平滑）。每當第一次測量到RTT樣本時， RTTs值就取為所測量到的RTT樣本值。但以後每測量到一個新的RTT樣本，就按下式重新計算一次RTTs:
新的RTTs = (1 － α）×（舊的RTTs) ＋ α ×（新的RTT樣本）
α 越大表示新的RTTs受新的RTT樣本的影響越大。推薦的α 值為0.125，用這種方法得出的加權平均往返時間RTTs 就比測量出的RTT值更加平滑。
顯然，超時計時器設置的超時重傳時間RTO (RetransmissionTime-Out）應略大於上面得出的加權平均往返時間RTTs。RFC 2988 建議使用下式計算RTO:
RTO = RTTs + 4 × RTTd
RTTd是RTT 的偏差的加權平均值，它與RTTs和新的RTT樣本之差有關。計算公式如下：
新的RTTd= (1- β）×（舊的RTTd) + β × |RTTs－新的RTT樣本|
發現問題： 如圖所示，發送出一個報文段。設定的重傳時間到了，還沒有收到確認。於是重
傳報文段。經過了一段時間後，收到了確認報文段。現在的問題是：如何判定此確認報文段是對先發送的報文段的確認，還是對後來重傳的報文段的確認？
若收到的確認是對重傳報文段的確認，但卻被源主機當成是對原來的報文段的確認，則這樣計算出的RTTs 和超時重傳時間RTO 就會偏大。若後面再發送的報文段又是經過重傳後才收到確認報文段，則按此方法得出的超時重傳時間RTO 就越來越長。
若收到的確認是對原來的報文段的確認，但被當成是對重傳報文段的確認，則由此計算出的RTTs 和RTO 都會偏小。這就必然導致報文段過多地重傳。這樣就有可能使RTO 越來越短。
Kam 提出了一個演算法：在計算加權平均RTTs 時，只要報文段重傳了就不採用其往返時間樣本。這樣得出的加權平均RTTs 和RTO 就較准確。
新問題： 設想出現這樣的情況：報文段的時延突然增大了很多。因此在原來得出的重傳時間內，不會收到確認報文段。於是就重傳報文段。但根據Kam 演算法，不考慮重傳的報文段的往返時間樣本。這樣，超時重傳時間就無法更新。
解決方案： 對Kam 演算法進行修正，方法是z報文段每重傳一次，就把超時重傳時間RTO 增大一些。典型的做法是取新的重傳時間為2 倍的舊的重傳時間。當不再發生報文段的重傳時，才根據上面給出的公式計算超時重傳時間。
流量控制（flow control）就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
利用滑動窗口機制可以很方便地在TCP 連接上實現對發送方的流量控制。
接收方的主機B 進行了三次流量控制。第一次把窗口減小到rwnd =300，第二次又減到rwnd = 100 ，最後減到rwnd = 0 ，即不允許發送方再發送數據了。這種使發送方暫停發送的狀態將持續到主機B 重新發出一個新的窗口值為止。我們還應注意到，B 向A 發送的三個報文段都設置了ACK=1，只有在ACK=1 時確認號欄位才有意義。
發生死鎖： 現在我們考慮一種情況。上圖中， B 向A 發送了零窗口的報文段後不久， B 的接收緩存又有了一些存儲空間。於是B 向A 發送了rwnd = 400 的報文段。然而這個報文段在傳送過程中丟失了。A 一直等待收到B 發送的非零窗口的通知，而B 也一直等待A 發送的數據。如果沒有其他措施，這種互相等待的死鎖局面將一直延續下去。
解決方案： TCP 為每一個連接設有一個 持續計時器（persistence timer） 。只要TCP 連接的一方收到對方的零窗口通知，就啟動持續計時器。若持續計時器設置的時間到期，就發送一個 零窗口探測報文段 （僅攜帶1 宇節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。
1 TCP連接時是三次握手，那麼兩次握手可行嗎？
在《計算機網路》中是這樣解釋的：已失效的連接請求報文段」的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用「三次握手」，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送ACK包。這樣就會白白浪費資源。而經過三次握手，客戶端和伺服器都有應有答，這樣可以確保TCP正確連接。
2 為什麼TCP連接是三次，揮手確是四次？
在TCP連接中，伺服器端的SYN和ACK向客戶端發送是一次性發送的，而在斷開連接的過程中，B端向A端發送的ACK和FIN是是分兩次發送的。因為在B端接收到A端的FIN後，B端可能還有數據要傳輸，所以先發送ACK，等B端處理完自己的事情後就可以發送FIN斷開連接了。
3 為什麼在第四次揮手後會有2個MSL的延時？
MSL是Maximum Segment Lifetime，最大報文段生存時間，2個MSL是報文段發送和接收的最長時間。假定網路不可靠，那麼第四次發送的ACK可能丟失，即B端無法收到這個ACK，如果B端收不到這個確認ACK，B端會定時向A端重復發送FIN，直到B端收到A的確認ACK。所以這個2MSL就是用來處理這個可能丟失的ACK的。
1 文件傳送協議
文件傳送協議FTP (File Transfer Protocol) [RFC 959］是網際網路上使用得最廣泛的文件傳送協議，底層採用TCP協議。
盯P 使用客戶伺服器方式。一個FTP 伺服器進程可同時為多個客戶進程提供服務。FTP的伺服器進程由兩大部分組成：一個主進程，負責接受新的請求：另外有若干個從屬進程，負責處理單個請求。
在進行文件傳輸時，客戶和伺服器之間要建立兩個並行的TCP 連接：「控制連接」（21埠）和「數據連接」（22埠）。控制連接在整個會話期間一直保持打開， FTP 客戶所發出的傳送請求，通過控制連接發送給伺服器端的控制進程，但控制連接並不用來傳送文件。實際用於傳輸文件的是「數據連接」。伺服器端的控制進程在接收到FTP 客戶發送來的文件傳輸請求後就創建「數據傳送進程」和「數據連接」，用來連接客戶端和伺服器端的數據傳送進程。
2 簡單文件傳送協議TFTP
TCP/IP 協議族中還有一個簡單文件傳送協議TFfP (Trivial File Transfer Protocol），它是一個很小且易於實現的文件傳送協議，埠號69。
TFfP 也使用客戶伺服器方式，但它使用UDP 數據報，因此TFfP 需要有自己的差錯改正措施。TFfP 只支持文件傳輸而不支持交耳。
3 TELNET
TELNET 是一個簡單的遠程終端協議，底層採用TCP協議。TELNET 也使用客戶伺服器方式。在本地系統運行TELNET 客戶進程，而在遠地主機則運行TELNET 伺服器進程，佔用埠23。
4 郵件傳輸協議
一個電子郵件系統應具如圖所示的三個主要組成構件，這就是用戶代理、郵件伺服器，以及郵件發送協議（如SMTP ）和郵件讀取協議（如POP3)， POP3 是郵局協議（Post Office Protocol）的版本3 。
SMTP 和POP3 （或IMAP ）都是在TCP 連接的上面傳送郵件，使用TCP 的目的是為了使郵件的傳送成為可靠的。
❷ 計算機網路-運輸層-用戶數據報協議UDP
用戶數據報協議UDP只在IP的數據報服務之上增加的功能：復用和分用的功能以及差錯檢測的功能。
UDP的主要特點是：
(1) UDP是無連接的 ，即發送數據之前不需要建立連接（當然，發送數據結束時也沒有連接可釋放)，因此了開銷和發送數據之前的時延。
(2) UDP使用盡最大努力交付 ，即不保證可靠交付，因此主機不需要維持復雜的連接狀態表（這裡面有許多參數)。
(3) UDP是面向報文的 。發送方的UDP對應用程序交下來的報文，在添加首部後就向下交付IP層。UDP對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界。這就是說，應用層交給UDP多長的報文，UDP就照樣發送，即一次發送一個報文，如圖5-4所示。在接收方的UDP,對IP層交上來的UDP用戶數據報，在去除首部後就原封不動地交付上層的應用進程。也就是說，UDP一次交付一個完整的報文。因此，應用程序必須選擇合適大小的報文，若報文太長，UDP把它交給IP層後，IP層在傳送時可能要進行分片，這會降低IP層的效率。反之，若報文太短，UDP把它交給IP層後，會使IP數據報的首部的相對長度太大，這也降低了IP層的效率。
(4)UDP沒有擁塞控制，因此網路出現的擁塞不會使源主機的發送速率降低。這對某些實時應用是很重要的。很多的實時應用（如P電話、實時祝頻會議等）要求源主機以恆定的速率發遞數據，並且允許在網鉻發生擁塞時丟失一些數據，但卻不允許數據有太大的時延。UDP正好適合這種要求。
(5)UDP支持一對一、一對多、多對一和多對多的交互通信.
(6)UDP的首部開銷小，只有8個位元組，比TCP的20個位元組的首部要短。
(7)網路環境差的情況下，丟包嚴重。
雖然某些實時應用需要使用沒有擁塞控制的UDP,但當很多的源主機同時都向網路發送高速率的實時視領流時，網鉻就有可能發生擁塞。結果大家都無法正常接收。因此，不使用擁塞控制功能的UDP有可能會引起網路產生嚴重的擁塞問題。
還有一些使用UDP的實時應用，需要對UDP的不可靠的傳輸進行適當的改進，以減少數據的丟失。在這種情況下，應用進程本身可以在不影響應用的實時性的前提下，增加一些提高可靠性的措施，如採用前向糾錯或重傳己丟失的報文。
用戶數據報UDP有兩個欄位：數據欄位和首部欄位。首部欄位很簡單，只有8個位元組(圖5-5)，由四個欄位組成，每個欄位的長度都是兩個位元組。各欄位意義如下：
(1)源埠 源埠號。在需要對方回信時選用。不需要時可用全0。
(2)目的埠 目的埠號。這在終點交付報文時必須使用。
(3)長度 UDP用戶數據報的長度，其最小值是8（僅有首部）。
(4)檢驗和 檢測UDP用戶數據報在傳輸中是否有錯。有錯就丟棄。
偽首部的第3欄位是全零；第4欄位是P首部中的協議欄位的值，對於 UDP協議欄位值為17 ；第5欄位是UDP用戶數據報的長度。當運輸層從IP層收到UDP數據報時，就根據首部中的目的埠，把UDP數據報通過相應的埠，上交最後的終點一應用進程。
如果接收方UDP發現收到的報文中的目的埠號不正確（即不存在對應於該埠號的應用進程)，就丟棄該報文，並由 網際控制報文協議ICMP發送「埠不可達」差錯報文 給發送方。「ICMP的應用」中的traceroute時，就是讓發送的UDP用戶數據報故意使用一個非法的UDP埠，結果ICMP就返回「埠不可達」差錯報文，因而達到了測試的目的。
請注意，雖然在UDP之間的通信要用到其埠號，但由於UDP的通信是無連接的，因此不需要使用套接字(TCP之間的通信必須要在兩個套接字之間建立連接)。
UDP用戶數據報首部中檢驗和的計算方法有些特殊。在計算檢驗和時，要在UDP用戶數據報之前增加12個位元組的偽首部。所謂「偽首部」是因為這種偽首部並不是UDP用戶數據報真正的首部。只是在計算檢驗和時，臨時添加在UDP用戶數據報前面，得到一個臨時的UDP用戶數據報。檢驗和就是按照這個臨時的UDP用戶數據報來計算的。偽首部既不向下傳送也不向上遞交，而僅僅是為了計算檢驗和。
UDP計算檢驗和的方法 和計算IP數據報首部檢驗和的方法相似。但不同的是：IP數據報的檢驗和只檢驗IP數據報的首部，但UDP的檢驗和是把首部和數據部分一起都檢驗。 在發送方 ，首先是先把全零放入檢驗和欄位。再把偽首部以及UDP用戶數據報看成是由許多16位的字串接起來的。若UDP用戶數據報的數據部分不是偶數個位元組，則要填入一個全零位元組（但此位元組不發送）。然後按二進制反碼計算出這些16位字的和。將此和的二進制反碼寫入檢驗和欄位後，就發送這樣的UDP用戶數據報。 在接收方 ，把收到的UDP用戶數據報連同偽首部（以及可能的填充全零位元組）一起，轉為8位數二進制，然後按二進制反碼求這些16位字的和。當無差錯時其結果應為全1。否則就表明有差錯出現，接收方就應丟棄這個UDP用戶數據報（也可以上交給應用層，但附上出現了差錯的警告)。 檢驗和 ，既檢查了UDP用戶數據報的源埠號和目的埠號以及UDP用戶數據報的數據部分，又檢查了IP數據報的源P地址和目的地址。
這里假定用戶數據報的長度是15位元組，因此要添加一個全0的位元組。這種簡單的差錯檢驗方法的檢錯能力並不強，但它的好處是簡單，處理起來較快。
❸ UDP協議是什麼
UDP協議是英文UserDatagramProtocol的縮寫，即用戶數據報協議，主要用來支持那些需要在計算機之間傳輸數據的網路應用。包括網路視頻會議系統在內的眾多的客戶/伺服器模式的網路應用都需要使用UDP協議。UDP協議從問世至今已經被使用了很多年，雖然其最初的光彩已經被一些類似協議所掩蓋，但是即使是在今天，UDP仍然不失為一項非常實用和可行的網路傳輸層協議。
與我們所熟知的TCP（傳輸控制協議）協議一樣，UDP協議直接位於IP（網際協議）協議的頂層。根據OSI（開放系統互連）參考模型，UDP和TCP都屬於傳輸層協議。
UDP協議的主要作用是將網路數據流量壓縮成數據報的形式。一個典型的數據報就是一個二進制數據的傳輸單位。每一個數據報的前8個位元組用來包含報頭信息，剩餘位元組則用來包含具體的傳輸數據。
0UDP報頭
UDP報頭由4個域組成，其中每個域各佔用2個位元組，具體如下：
源埠號
目標埠號
數據報長度
校驗值
UDP協議使用埠號為不同的應用保留其各自的數據傳輸通道。UDP和TCP協議正是採用這一機制實現對同一時刻內多項應用同時發送和接收數據的支持。數據發送一方（可以是客戶端或伺服器端）將UDP數據報通過源埠發送出去，而數據接收一方則通過目標埠接收數據。有的網路應用只能使用預先為其預留或注冊的靜態埠；而另外一些網路應用則可以使用未被注冊的動態埠。因為UDP報頭使用兩個位元組存放埠號，所以埠號的有效范圍是從0到65535。一般來說，大於49151的埠號都代表動態埠。
數據報的長度是指包括報頭和數據部分在內的總的位元組數。因為報頭的長度是固定的，所以該域主要被用來計算可變長度的數據部分（又稱為數據負載）。數據報的最大長度根據操作環境的不同而各異。從理論上說，包含報頭在內的數據報的最大長度為65535位元組。不過，一些實際應用往往會限制數據報的大小，有時會降低到8192位元組。
UDP協議使用報頭中的校驗值來保證數據的安全。校驗值首先在數據發送方通過特殊的演算法計算得出，在傳遞到接收方之後，還需要再重新計算。如果某個數據報在傳輸過程中被第三方篡改或者由於線路噪音等原因受到損壞，發送和接收方的校驗計算值將不會相符，由此UDP協議可以檢測是否出錯。這與TCP協議是不同的，後者要求必須具有校驗值。
UDPvs.TCP
UDP和TCP協議的主要區別是兩者在如何實現信息的可靠傳遞方面不同。TCP協議中包含了專門的傳遞保證機制，當數據接收方收到發送方傳來的信息時，會自動向發送方發出確認消息；發送方只有在接收到該確認消息之後才繼續傳送其它信息，否則將一直等待直到收到確認信息為止。
與TCP不同，UDP協議並不提供數據傳送的保證機制。如果在從發送方到接收方的傳遞過程中出現數據報的丟失，協議本身並不能做出任何檢測或提示。因此，通常人們把UDP協議稱為不可靠的傳輸協議。
相對於TCP協議，UDP協議的另外一個不同之處在於如何接收突法性的多個數據報。不同於TCP，UDP並不能確保數據的發送和接收順序。例如，一個位於客戶端的應用程序向伺服器發出了以下4個數據報
D1
D22
D333
D4444
但是UDP有可能按照以下順序將所接收的數據提交到服務端的應用：
D333
D1
D4444
D22
事實上，UDP協議的這種亂序性基本上很少出現，通常只會在網路非常擁擠的情況下才有可能發生。
UDP協議的應用
也許有的讀者會問，既然UDP是一種不可靠的網路協議，那麼還有什麼使用價值或必要呢？其實不然，在有些情況下UDP協議可能會變得非常有用。因為UDP具有TCP所望塵莫及的速度優勢。雖然TCP協議中植入了各種安全保障功能，但是在實際執行的過程中會佔用大量的系統開銷，無疑使速度受到嚴重的影響。反觀UDP由於排除了信息可靠傳遞機制，將安全和排序等功能移交給上層應用來完成，極大降低了執行時間，使速度得到了保證。
關於UDP協議的最早規范是RFC768，1980年發布。盡管時間已經很長，但是UDP協議仍然繼續在主流應用中發揮著作用。包括視頻電話會議系統在內的許多應用都證明了UDP協議的存在價值。因為相對於可靠性來說，這些應用更加註重實際性能，所以為了獲得更好的使用效果（例如，更高的畫面幀刷新速率）往往可以犧牲一定的可靠性（例如，會面質量）。這就是UDP和TCP兩種協議的權衡之處。根據不同的環境和特點，兩種傳輸協議都將在今後的網路世界中發揮更加重要的作用.
❹ UDP是什麼，UDP協議及優缺點
UDP，全稱 User Datagram Protocol，中文名稱為用戶數據報協議，主要用來支持那些需要在計算機之間傳輸數據的網路連接。
UDP 協議從問世至今已經被使用了很多年，雖然目前 UDP 協議的應用不如 TCP 協議廣泛，但 UDP 依然是一種非常實用和可行的網路傳輸層協議。尤其是在一些實時性很強的應用場景中，比如網路游戲、視頻會議等，UDP 協議的快速能力更具有獨特的魅力。
UDP 是一種面向非連接的協議，面向非連接指的是在正式通信前不必與對方先建立連接，不管對方狀態就直接發送數據。至於對方是否可以接收到這些數據，UDP 協議無法控制，所以說 UDP 是一種不可靠的協議。
UDP 協議適用於一次只傳送少量數據、對可靠性要求不高的應用環境。
與前面介紹的 TCP 協議一樣，UDP 協議直接位於 IP 協議之上。實際上，IP 協議屬於 OSI 參考模型的網路層協議，而 UDP 協議和 TCP 協議都屬於傳輸層協議。
因為 UDP 是面向非連接的協議，沒有建立連接的過程，因此它的通信效率很高，但也正因為如此，它的可靠性不如 TCP 協議。
UDP 協議的主要作用是完成網路數據流和數據報之間的轉換在信息的發送端，UDP 協議將網路數據流封裝成數據報，然後將數據報發送出去；在信息的接收端，UDP 協議將數據報轉換成實際數據內容。
可以認為 UDP 協議的 socket 類似於碼頭，數據報則類似於集裝箱。碼頭的作用就是負責友送、接收集裝箱，而 socket 的作用則是發送、接收數據報。因此，對於基於 UDP 協議的通信雙方而言，沒有所謂的客戶端和伺服器端的概念。
UDP 協議和 TCP 協議簡單對比如下：
TCP 協議：可靠，傳輸大小無限制，但是需要連接建立時間，差錯控制開銷大。
UDP 協議：不可靠，差錯控制開銷較小，傳輸大小限制在 64 KB以下，不需要建立連接。
?相比較 TCP，UDP 是一種不可靠的網路協議，它在通信實例的兩端各建立一個 socket，但這兩個 socket 之間並沒有虛擬鏈路，它們只是發送、接收數據報的對象。