请教一个udp服务器设计的问题

sqfasd

最近在研究并发udp服务器的设计，考虑了以下三种模型

A.多线程处理同一个socket，阻塞模式，recvfrom完了sendto
B.多线程，每个线程创建一个socket，开启SO_REUSEPORT选项，所有线程共享一个地址，也是阻塞模式
C.多线程＋epoll＋非阻塞，每当客户端第一次请求时，就新建一个socket并connect到该客户端的地址，并将新的socket句柄加入epoll中，后续的读写操作都将有那个新的socket处理

第三种模型是比较奇怪，一般都是客户端connect服务端，我先解释下
之所以要用第三种模型，是因为我在unp 8.1 (UDP的connect函数)一节中看到，如果没有调用connect，每次recvfrom和sendto都会有额外的消耗，即内核每发一次包都会进行连接套接口和断开套接口

下面是我的问题
1. 我预期第模型Ｃ性能最高，但实测模型Ｃ性能最低，只有Ａ的1/3左右
2. 我预期模型Ｂ应该比Ａ高，毕竟使用了多个socket，至少内核中也会建立多个缓冲区，而且SO_REUSEPORT是linux内核3.x版本新出的为了改善性能一个选项，但实测性能跟第一种比较接近，但稳定性远远不如第一种，经常发生丢包现象
3.模型Ａ是最稳定的，性能也几乎是最高的（这个还有待测试，我在家里的电脑上测的结果是比模型Ｂ略高，但在公司是比模型Ｂ略低）

下面是我的测试代码
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，但源和目标都一样，协议栈打包到IP层的时候就已经归一了，最后出口都在网卡，reuse后的多个sockfd内
       核还要做些额外开销
      

sqfasd

cokeboL 发表于 2015-04-26 12:35
以下拙见供参考：
    1.在一对一的场景中，阻塞效率高于非阻塞，非阻塞是为了保证一对多的场景中不让多等 ...

多谢，很有帮助。
你怎么看unp8.1那节，　在udp服务器中，有没有必要让服务器反过来connect客户端，以减少每次recvfrom和sendto时的额外开销

cokeboL

回复 4# sqfasd

    一对一的话，connect当然省些，但是性能瓶颈估计也不差这点吧，如果性能上需求这一点，那可能已经是满载的情况，满载的话，丢包就悲催了
    多对一的情况没尝试过，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都要进行绑定?这个和协议栈实现有关系吧.
udp的这个开销应该非常之小, 还担心不到这里来.

sqfasd

hanxin83 发表于 2015-04-27 13:51
A最好, 如果A适合你的场景你就不要想别的方案.
你不是嫌弃A的解决方式太简单吧, 简单的就是最好的.
这个我 ...

嗯，看来是我把问题复杂化了
不过多研究研究也没坏处

wangfeng2500

B模型我记得以前试过，会导致只有最后绑定socket的线程才能recvfrom