請教一個udp服務器設計的問題

sqfasd

最近在研究并發(fā)udp服務器的設計，考慮了以下三種模型

A.多線程處理同一個socket，阻塞模式，recvfrom完了sendto
B.多線程，每個線程創(chuàng)建一個socket，開啟SO_REUSEPORT選項，所有線程共享一個地址，也是阻塞模式
C.多線程＋epoll＋非阻塞，每當客戶端第一次請求時，就新建一個socket并connect到該客戶端的地址，并將新的socket句柄加入epoll中，后續(xù)的讀寫操作都將有那個新的socket處理

第三種模型是比較奇怪，一般都是客戶端connect服務端，我先解釋下
之所以要用第三種模型，是因為我在unp 8.1 (UDP的connect函數(shù))一節(jié)中看到，如果沒有調用connect，每次recvfrom和sendto都會有額外的消耗，即內核每發(fā)一次包都會進行連接套接口和斷開套接口

下面是我的問題
1. 我預期第模型Ｃ性能最高，但實測模型Ｃ性能最低，只有Ａ的1/3左右
2. 我預期模型Ｂ應該比Ａ高，畢竟使用了多個socket，至少內核中也會建立多個緩沖區(qū)，而且SO_REUSEPORT是linux內核3.x版本新出的為了改善性能一個選項，但實測性能跟第一種比較接近，但穩(wěn)定性遠遠不如第一種，經(jīng)常發(fā)生丟包現(xiàn)象
3.模型Ａ是最穩(wěn)定的，性能也幾乎是最高的（這個還有待測試，我在家里的電腦上測的結果是比模型Ｂ略高，但在公司是比模型Ｂ略低）

下面是我的測試代碼
https://github.com/sqfasd/ipractice/tree/master/net/socket

udp_server.cc　對應模型Ａ
udp_server_ex.cc　對應模型Ｃ
udp_server_ex2.cc 對應模型Ｂ

望大家不吝賜教

hellioncu

udp一般一個套接字就夠了，更多的應該關注丟包怎么處理

cokeboL

以下拙見供參考：
    1.在一對一的場景中，阻塞效率高于非阻塞，非阻塞是為了保證一對多的場景中不讓多等一。而且epoll要維護個內核事件表以及事件機制的額外開銷
    2.B方案中傳輸層雖然各自一個sockfd，但源和目標都一樣，協(xié)議棧打包到IP層的時候就已經(jīng)歸一了，最后出口都在網(wǎng)卡，reuse后的多個sockfd內
       核還要做些額外開銷
      

sqfasd

cokeboL 發(fā)表于 2015-04-26 12:35
以下拙見供參考：
    1.在一對一的場景中，阻塞效率高于非阻塞，非阻塞是為了保證一對多的場景中不讓多等 ...

多謝，很有幫助。
你怎么看unp8.1那節(jié)，　在udp服務器中，有沒有必要讓服務器反過來connect客戶端，以減少每次recvfrom和sendto時的額外開銷

cokeboL

回復 4# sqfasd

    一對一的話，connect當然省些，但是性能瓶頸估計也不差這點吧，如果性能上需求這一點，那可能已經(jīng)是滿載的情況，滿載的話，丟包就悲催了
    多對一的情況沒嘗試過，reuse之后不知道需不需要進行同步，如果需要同步，那多個sockfd不如只用一個算了

linux_c_py_php

其實我用asio，lf模型很舒服。

VIP_fuck

回復 6# linux_c_py_php


    你們asio用得多嗎？

hanxin83

A最好, 如果A適合你的場景你就不要想別的方案.
你不是嫌棄A的解決方式太簡單吧, 簡單的就是最好的.
這個我們內部一般稱之為"驚群模型", 其實不驚群啦....

B模型的樓上也說了, 一般不用多個socket, 用了只會降低效率.
C這個很奇葩, 什么sendto/recvfrom都要進行綁定?這個和協(xié)議棧實現(xiàn)有關系吧.
udp的這個開銷應該非常之小, 還擔心不到這里來.

sqfasd

hanxin83 發(fā)表于 2015-04-27 13:51
A最好, 如果A適合你的場景你就不要想別的方案.
你不是嫌棄A的解決方式太簡單吧, 簡單的就是最好的.
這個我 ...

嗯，看來是我把問題復雜化了
不過多研究研究也沒壞處

wangfeng2500

B模型我記得以前試過，會導致只有最后綁定socket的線程才能recvfrom