UDP協議高階

1. udp協議有更加好的通訊速度 2. 在一問一答的情況之下，包的次序無關 =>dns 我的思考：在udp上實現乙個帶超時的請求回應機制，讓業務層負責超時重發，可能比tcp效果更好，前提：單個請求或回應的包不應該過大，最好不要超過乙個mtu，大概在網際網路上500多位元組，

在國內是最大不超過521個位元組，在跨網（電信和聯通）udp是比tcp快120倍

1. 在一定的情況之下，tcp的設計已經很複雜了，利用udp來進行封裝成可靠的協議，只能表現在部分方面的優勢。其實有乙個更加好的協議 sctp
2. 建立乙個可靠通訊協議，最主要解決的問題還是如果利用不可靠的資料傳輸，實現乙個協議來達到可靠傳輸（保證次序不丟包）的問題。
`struct rudp_package 
;     rudp_new 建立 rudp 物件時，有兩個引數可配置。send delay 表示資料累積多少個時間週期 tick 數才打包在一起傳送。expired time 表示已傳送的包至少保留多少個時間週期。
和 tcp 不同，我們既然使用 udp 通訊，就是希望高響應速度，所以即使資料抱遲遲沒有送達，它們也不必保留太長時間，而只需要通知業務層異常即可。
struct rudp * rudp_new(int send_delay, int expired_time); 
void rudp_delete(struct rudp *); // return the size of new package, 0 where no new package // -1 corrupt connection 
而業務層的資料收發只需要呼叫 rudp_send 和 rudp_recv 即可。其中，rudp_recv 保證資料報按次序輸出；rudp_send 也並不真正傳送這些資料報，
而是堆積在 rudp 物件內，等待下乙個時間片。
int rudp_recv(struct rudp *u, char buffer[max_package]); // send a new package out 
// should call every frame with the time tick, or a new package is coming. 
// return the package should be send out. 
void rudp_send(struct rudp *u, const char *buffer, int sz); 
這裡提供了乙個 rudp_update 的 api 要求業務層按時間週期呼叫，當然也可以在同一時間片內呼叫多次，用傳入的引數 tick 做區分。如果 tick 為 0 表示是在同一時間片內，不用急著處理資料，
當 tick 大於 0 時，才表示時間流逝，這時可以合併上個時間週期內的資料集中處理。 rudp_update 的每次呼叫均可以傳入乙個實際收到的 udp 包（可以是乙個完整的 udp 包，也可以是一部分），
這個包資料是乙個黑盒子，業務層不必了解細節。它的編碼依賴對端採用的相同的 rudp 模組。每次呼叫都有可能輸出一系列需要傳送出去的 udp 包。這些資料報是由過去的 rudp_send 呼叫壓入的數
據產生的，同時也包含了最近接收到的資料報中發現的，對端可能需要重傳的資料，以及在沒有通訊資料時插入的心跳包等。總的來說，rudp_update 內部做了所有的可靠化通訊需要的資料組織工作。
使用的人傳入從 udp socket 上收到的資料（不包括資料加密或其它資料組織工作），並從中獲取需要傳送到 udp socekt 的資料。
struct rudp_package * rudp_update(struct rudp *u, const void * buffer, int sz, int tick);`

無非是在udp的模式上我們拿了2樣東西回來。 1. 順序，同時是流控方式：基於狀態的**模式決定的資料順序。 tcp把資料確保資料序列的工作在網路傳輸時，層層包包，順序保證，用起來確實方便。但也消除了資料併發傳輸的可能。這很大程度上直接形成了tcp的流控模式，從程式設計的形式上tcp無需流控，你不拿走對方就丟不出來。**的順序化，和收發的順序在影響傳輸效能。但udp模式在這方面有本質的不同，資料傳送時沒有前後這一說，你拿到的資料也是如此。交換機，網絡卡根本不考慮序列的要求，從傳輸上這很牛叉，但這種模式與coding的順序式思維不相符，偶爾有無狀態的資料可以直接套用這個思維，但對於具備時間和序列要求的場景，這就顯得十分難用。因此大多情況下udp fake tcp必須要做資料序列重整。端對端的序列重建和步步緊等的區域性重整，在整體行為上確實可以減少延遲。 2. 鏈路特性，更是流控方式。一旦轉入udp,鏈路的管理就從路由器的問題變成你的問題了。還要不要等ack,對方是否還在，我能傳送多快這一系列的問題在你建立socket的第乙個瞬間就變坑了。貌似少了connect的動作，但實際需要考慮的問題變得更多了起來，但此時你具備的資訊也是路由器不具備的例如頻寬，端對端延遲，實際的丟包率，如果這些都用來作為

鏈路可靠性和流控的引數，你或許能'**'，傳送速率，ack的時間，重發的速度。

UDP協議高階

TCP協議 UDP協議

UDP協議與UDP通訊

UDP協議簡介

UDP協議高階

TCP協議 UDP協議

UDP協議與UDP通訊

UDP協議簡介

相關推薦