第一種思路，既然是傳輸檔案，那麼檔案的大小和校驗碼（MD5）應該是一開始就給接收端了吧那麼接收端其實是知道傳輸已經快結束了，就剩最後一小段資料了。這時候就改變下策略，激進點，就是在傳輸接近結束的時候，接收端對剩餘的資料包主動發起重傳。這樣的好處是避免了在 99%的時候長時間等待，而耽誤了後面其它任務，多浪費一點頻寬，但是比例很小。這種策略在P2P檔案分享的時候也有用到，有些BT客戶端會在下載任務接近完成的時候向所有種子節點發送請求，讓任務儘快完成。第二種思路就是 其它回答提到的編碼方案，比如噴泉碼，這種編碼的好處就是不需要重傳包，不停收資料就好，收夠了解碼用的資料，檔案自然就完整了。第三種，多路TCP，單路TCP的時候是受丟包和RTT影響的，在某些劣質鏈路上速度上不去，甚至連線都會斷掉。同時建立多個TCP連線，每個連線傳輸檔案的一個片段，這樣可以獲得更高的傳輸速度，以前的HTTP下載工具比如 網路螞蟻 flashget都是這樣的，迅雷現在也會這麼做。分片和調動的演算法要自己實現，但是比用UDP實現一套傳輸控制協議要簡單多了。

用fopen函式來建檔案，用fwrite來往檔案中寫資料，用fclose來關閉檔案……這跟是否用UDP沒有任何關係。 UDP傳送資料不保證正確性，所以接收方需要驗證收到的資料並且向傳送方確認，才能保證正確傳輸。