這篇文章給大家分享的是有關后臺開發(fā)框架UDPServer的工作原理的內容。小編覺得挺實用的，因此分享給大家學習。如下資料是關于UDPServer的介紹和工作原理的內容。

站在用戶的角度思考問題，與客戶深入溝通，找到海東網站設計與海東網站推廣的解決方案，憑借多年的經驗，讓設計與互聯網技術結合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網站建設、做網站、企業(yè)官網、英文網站、手機端網站、網站推廣、域名注冊、網絡空間、企業(yè)郵箱。業(yè)務覆蓋海東地區(qū)。

第一個接觸的叫udpserver。顧名思義，就是只支持udp的服務框架。因為我們部門是做音視頻產品的，音視頻數據對實時性要求很高，因此常用udp傳輸數據。Udp server是同步多進程模型，包含1個Interface進程和多個Worker進程。

Iterface進程負責接收來自外部的請求，做一些合法性校驗和格式轉換后，轉發(fā)給后端的Worker進程。Worker進程監(jiān)聽不同的端口收包，并處理業(yè)務邏輯。Worker進程的回包直接發(fā)給客戶端。

此處有幾個點值得關注：

首先，Worker進程監(jiān)聽的是不同端口。

監(jiān)聽相同的端口顯然是更常見的做法，而監(jiān)聽相同的端口也需要注意一點，即監(jiān)聽的端口socket必須是從父進程中繼承得到的，而非Worker自己創(chuàng)建的socket。因為對于前者內核才能保證調度的均勻性，而后者是沒有這種效果的，內核只會把請求包扔給同一個Worker。

這里之所以使用監(jiān)聽不同端口的方案，是為了保證調度的可控性，請求包發(fā)往哪個Worker是有預期的，可以做更個性化的調度策略，問題定位也方便得多。Udp server默認是使用輪詢的調度方式。

第二點是，Worker進程回包是直接返回給客戶端的。

另一種常見做法是通過Interface進程回包，缺點是Interface會成為瓶頸。而Worker直接回包的缺點是向外部暴露Worker，不過這個問題并不十分嚴重。相較之下，我們更希望獲得性能的提升。為了給客戶端回包，Interface會把客戶端的ip和端口封裝到請求包發(fā)給Worker。

框架雖簡單，但是性能非常優(yōu)異，作為echosvr性能可達30w+ QPS。但是這個框架不支持TCP，因此只能作為內部的服務框架使用。

看完上述內容，你們對UDPServer有進一步的了解嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注創(chuàng)新互聯行業(yè)資訊頻道，感謝各位的閱讀。