UDP沒有DelieveryGaruantee，也沒有順序保證，所以如果妳要求妳的數據發送與接受既要高效，又要保證有序，收包確認等，妳就需要在UDP協議上構建自己的協議。比如RTCP，RTP協議就是在UPD協議之上專門為H.323協議簇上的IP電話設計的壹種介於傳輸層和應用層之間的協議。
UDP構建可靠數據傳輸
簡單來講，要使用UDP來構建可靠的面向連接的數據傳輸，就要實現類似於TCP協議的超時重傳，有序接受，應答確認，滑動窗口流量控制等機制，等於說要在傳輸層的上壹層（或者直接在應用層）實現TCP協議的可靠數據傳輸機制，比如使用UDP數據包+序列號，UDP數據包+時間戳等方法，在服務器端進行應答確認機制，這樣就會保證不可靠的UDP協議進行可靠的數據傳輸，不過這好像也是壹個難題！
（壹）可靠性協議
（可靠性協議這部分協議參考論文《基於UDP的可靠文件傳輸協議設計與實現》）
首先來設計最為重要的可靠性。在UDP增加報頭前，我們先定義8個字節的協議頭，為2個字節的數據包標識，2個字節的發送序號，2個字節的文件指針定位和2個字節的數據包中數據大小信息。數據包標誌指明該數據包為文件數據包、確認包或者其它控制包，發送序號用來指明數據包的順序信息，指針定位字節數據用來指明該數據包中數據被填寫到文件的哪個位置，最後的大小信息也是用來向文件中讀寫數據時使用。
協議保證可靠性的大致流程是（先只考慮單對單情況下的單方向發送）：
首先發送端發送壹個文件信息報文，這個報文就是最簡單的UDP報文，但是裏面的信息很重要，記錄著文件的大小，被分隔成的報文數，文件序號。發完這個信息包，發送端阻塞，等待接收端的回復報文才能繼續。文件信息包被接收端接受以後使用確認機制確定是否接受這個文件，並把決定回饋給發送端。此時，發送端如果收到的是“確定接受”的結果，將會把這個文件的整組數據報全部發送過去，這裏我們並不像最傳統的可靠傳輸協議TCP協議壹樣，對於每個每個報文都要確認接受完才會對下壹個報文進行處理，太沒效率，遵守本協議的接受端在接受這組報文的時候將遵守錯序重排機制，來對收到的這組報文進行按序號排序，期間可能序號不聯系不過沒關系，接受過程只要保證序號從小到大即可。發送端發完所有報文延遲壹點時間再發送壹個結束報文，延遲時間是為了減少結束報文比數據報文還早被接受的情況，當然即使這種情況出現也不會破壞可靠性，只不過在在結束報文之後的數據報文會被當做丟失的包被要求重發，降低效率。接受端接受到結束報文後按照壹開始的文件信息包的信息和序列號做對比，把沒有的序列號的報文的信息傳回給發送端，要求重新發送這些報文。發送端接到信息以後重發丟失的數據包。直到接收端拿到的報文和信息匹配，接受端就可以發回壹個“接受完畢”的報文。這樣發送端接受端再進行下壹次文件傳輸。
在這個流程中有幾個重要的機制保證流程的可靠性：
確認機制
本系統接收方並非對任意數據包都進行確認，在下面的壹些情況下會使用到該確認機制：
1、接收方收到文件信息包時，要對是否接收進行確認。
2、接收方收到結束包時要進行確認，然後檢測該分組內數據包是否丟失。
3、接收方收到全部數據包時要進行確認，以便結束文件的傳輸過程。
重發機制
協議設計了兩種重發機制：壹種是自動重發機制，另壹種是請求重發機制。自動重發機制是消息發送時啟動壹個定時器，如果在規定的壹段時間內未收到接收方的確認消息，則斷定這段時間內發送的報文已經丟失並進行重發。請求重發機制則是在接收方收到發送方發來的傳輸結束消息後，在接收方對收到的所有報文序號進行檢測，如果發現某些序號的報文缺失，接收方主動請求重發缺失的序號對應的報文。具體實現設計如下所述：
1、自動重發機制
通信發送方和接收方都維持壹個自動重發定時器，在通信開始前會檢查自動重發定時器是否啟動，如果沒有啟動，就會啟動這個定時器。如果在壹個特定時間間隔內發送方沒有收到來自接收方的任何確認消息，或者接收方沒有到發送方的通道檢測報文。這時系統會將這個定時器歸零，並將這段時間內發送的消息重發壹遍，把記錄重發次數變量加1。如果過在規定的時間內依然沒有收到對方的任何確認信息，則重新將定時器歸0，執行重發操作並將重發次數加1，如此循環，在重發次數未達到指定數據之前，直到收到對方的壹個確認消息，然後停止自動重發定時器，將重發次數清0；否則證明傳輸路徑出現問題。
2、請求重發機制
接收方記錄著已收到數據包的序列以及未收到的數據包序列。當接收到分組結束包時，接收方就會啟動定時器，檢索該分組內未收到的數據包，如果數據包已全部接收到，則關閉定時器，進行下壹個分組的傳輸。否則查找丟失數據包的序號並依次發送請求重發數據包，在規定時間內接收發送方重發的數據包，然後定時器歸0，重新檢索未收到數據包，並按上述情況做出反應，如此循環往復，直到最終完成該分組的傳輸過程。
協議的錯序重排機制
協議頭結構中有2個字節的序號字段，當發送端接收到對端發送的確認接收報文後，開始讀取文件數據塊內容寫入協議數據區，為每壹個數據塊編制壹個序號，序號的最大值要求與接收端維護的壹個為了實現錯序重排機制的動態表長度壹致。序號排滿後，後面的報文會在下壹個分組中進行發送。這時發送端會根據當前分組下讀取的數據塊大小及起始位置填寫協議頭中的字段，最後將數據包發送出去。接收端起初會生成壹個動態數組用來存儲接收到的數據包序號，當接收端準備好接收文件後將數組的每壹位置為無效，每收到壹個數據包，就會讀取其序號字段值並將數組相應位置為有效，然後將數據區的內容寫入文件。這樣即使由於網絡狀況導致數據包不能按序到達，接收端也能根據數據包位置字段和大小字段將數據寫入文件。序號字段在收到結束包後用於檢索動態數組啟動請求重傳機制。
（二）多用戶並發訪問和文件下載協議
前面我們說UDP是面向無連接的，這樣壹來就可以打破壹對壹連接的狀態，使得壹臺服務器可以向多個客戶端傳輸相同信息。
所以我們如何利用它來實現多用戶並發訪問和文件下載呢？本協議中，首先發送方會開辟壹個空間，這個空間儲存著發送端有的各個文件的序號和可能出現的接收方希望得到某個序號文件的ip地址端口號等信息。在發送端開始運作之後，就會有壹個進程壹直在監聽是否有對某個文件的請求，如果有就把請求方的信息儲存在這個空間裏。假如請求某個文件的ip+端口只有壹個，那麽這個協議是沒有實質性作用。然而壹旦短時間內有大量的ip請求這個文件，那麽在某次我們上邊設計的可靠性協議的傳輸過程中，就可以好好利用這個時間差，下壹段具體說明。除此之外還有壹個很人性化的設計可以加入到這裏，就是可以在監聽到某次請求時向對方返回目前的服務器狀況，比如對應文件的等待ip有多少，這樣讓接受方決定狀況比較擁堵時候是否等壹下再請求。
具體來說，我們每次發送文件信息報文時，在多個接收方請求的情況下將是壹組壹組發送的，把目前在等待空間的所有（或者限制壹個上限個數10個）接收方都發送文件信息報文。收到的同意接受報文後把這些同意接受的信息記錄下來，將文件報文組和發送完畢的報文同時發送給這些接受方，再把各個接收方返回的缺失報文記錄下來，再重傳。
非常重要的壹點是，其實對於接受方來說在文件傳輸過程中並沒有什麽多余的動作，它要做的和只有他壹個接收方的情況沒有任何的不同，可能只是整個過程的流暢性會受影響。需要變動的主要是發送方，它在做好可靠性協議要求的幾點之外，還要做好壹系列的記錄操作，保證整個過程不會亂套。
（三）針對下載的文件大小不應有限制設計的協議
回答問題時候其實就把思路講完全了，對於壹份任意大小的文件，我們都是可以通過切分成固定大小的N個報文然後將他們組成壹組發送的。在每次組報文傳輸過程之前傳輸的文件信息報文也是這個過程之壹，它記錄了本次文件的大小，被分成的報文數量，每個報文的大小（通常確定的大小）。這種方法下，不管多大的文件都視作壹定數量的報文，只要發送方和接受方在信息報文中確定了信息，文件大小就沒有限制
所以，利用上邊設計的可靠性協議、多用戶並發訪問和文件下載協議和針對下載的文件大小不應有限制設計的協議，我們就能實現壹個可靠的文件傳輸協議，並滿足以下要求：1）下層使用不可靠的UDP服務（即使用數據報方式的套接字）；2）能夠支持多用戶並發訪問和文件下載；3）下載的文件大小不應有限制。