這個網頁裡面寫了：
其可靠性必須由上層應用實現。一般都會採用訊息重傳來實現其可靠性，採用訊息重傳的時候有兩種方式，一種是傳送者發起，另一種是接收者發起。
前一種接收者發的是ack。傳送者收到ack，就不重傳。但是可能ack內爆。
第二種接收者發的是nack。傳送者收到nack，就重傳。但是可能nack內爆。另外需要保留發出去的資料，但是一般可以用超時機制，把以前的資料丟棄。
另外，看到雲風的這篇文章。
如果用 udp 再實現乙個可靠傳輸協議，而表現的比 tcp 效果更好，那麼多半只是在部分情況下的優勢；或是霸道的占用了過量的資源，而 tcp 在設計時則是很友好的，以整個網路的通暢為更高準則的。
如果基於 udp 可以做的比 tcp 更好，那麼一定是放棄了點 tcp 需要做到的東西。
一條路是寄希望於業務邏輯上允許資訊丟失。
那麼，不允許資訊丟失，但允許包亂序會不會改善?
在網路狀況不好的時候，我們可以看到有時採用短連線反而能獲得比長連線更好的使用者體驗。
我的思考結論就是：在 udp 協議之上，實現乙個帶超時的請求回應機制，讓業務層負責超時重發，有可能取得比 tcp 通訊更好的效果。但其前提是：單個請求或回應的包不應該過大，最好不要超過乙個 mtu ，在網際網路上大約是 500 多位元組。mss加報頭就等於mtu。 msl是2msl = time_wait時間。
UDP實現可靠傳輸
如何讓udp實現可靠傳輸 自定義通訊協議，在應用層定義一些可靠的協議，比如檢測包的順序，重複包等問題，如果沒有收到對方的ack，重新發包 udp沒有delievery garuantee，也沒有順序保證，所以如果你要求你的資料傳送與接受既要高效，又要保證有序，收包確認等，你就需要在udp協議上構建自...
可靠UDP淺入
問題來了，既然想要使用可靠的udp，那就必須補充一些tcp的流控機制 超時機制 重排機制 重傳機制，那麼這和tcp有什麼區別，為何不直接使用tcp更省事呢？google採用quic後連線速率能有效提公升75 google搜尋採用quic後頁面載入效能提公升3 youtube採用quic後重新緩衝次數...
UDP協議及UDP實現可靠傳輸
udp基於傳輸層 16位 2位元組 16位 2位元組 16位 2位元組 16位 2位元組 udp源埠號 udp目的埠號 udp長度 udp檢驗和資料 udp的傳輸過程類似於寄信 什麼時面向資料報 應用層交給udp多長的報文,udp原樣傳送,既不會拆分,也不會合併 老實巴交的 用udp傳輸100個位元...