UDP 并发服务器，大家帮忙看一看！该如何解决

UDP2000个客户端左右 并发

单个数据包最大512字节

Internet 10MB带宽

要求效率（尽可能快，尽可能少丢包），这种情况下用哪种通讯模型比较有优势！

想用IOCP，因为和select模型相比，这个稍微熟悉一点，也在项目中用过，不过是TCP的。

有两个问题，大家懂得的帮忙给指导一下：

是否可以理解为UDP模式下，一次recvfrom 只对应一次sendto。

2能否对服务端的套接字同时投递多个WsaRecvFrom,能否在多个线程中同时投递WsaSendTo和WsaRecvFrom。

------解决方案--------------------------------------------------------

-------------------------------------

等不到，包被截断了。

2能否对服务端的套接字同时投递多个WsaRecvFrom,能否在多个线程中同时投递WsaSendTo和WsaRecvFrom。

--------------------------

其实，我个人认为对udp而言，不用iocp也可以满足。 首先sendto都是立即完成的，无需异步操作。而recvfrom可以只需阻塞一个线程就够了，不需要重叠操作。

------解决方案--------------------------------------------------------

用UDX协议最可靠，效率高，开发简单，非开源。

UDT开源，对于你这种2000客户，够用，开源。

------解决方案--------------------------------------------------------

1sendto 10k,接受部分要么收到10k,要么全部丢失，不会出现部分收到的情况。

------解决方案--------------------------------------------------------

-------------------------------------

在局域网可以，公网，一般1K也收不到。

2能否对服务端的套接字同时投递多个WsaRecvFrom,能否在多个线程中同时投递WsaSendTo和WsaRecvFrom。

--------------------------完全可以

------解决方案--------------------------------------------------------

1如果UDP数据在传输过程中被分包，则你需要对数据包进行标识，已确保获取的包完整。一次recvfrom并不对应一次sendto，考虑UDP不可靠传输的因素。

2不可以，因为sendto和recvfrom都是对同一个资源Socket进行操作。如果在多个线程中对同一个资源进行操作，如果不加锁的情况下，会非常可怕的。而且，如果你加锁了，其实还不如单线程操作。

按照你的需求最好还是采用UDP，不过可以考虑组播。

2API调用完全没有问题。但是接到的数据可能和发送的数据次序不一样，这本身是UDP乱序特性决定了的。而且你发送方可能是多线程，从API层面来说，这些调用都是可以的，完全没有问题。但是给你接收方处理带来一系列问题。

昨天，接同事电话，说帮忙协查一个UDP抓不到包的问题，他描述的问题是A主机通过UDP协议向B主机的10001端口发送syslog报文，结果我们的采集程序flume收不到数据；但是C主机向B主机的10002端口也同样发送syslog报文，同一个flume采集程序却可以正常收到报文。

B主机双网卡分别为：42这个ip，网口是eth0；72这个ip，网口是eth1。

B对外网用的IP是一个134网段的IP。

A主机和C主机均使用134这个网段的IP向B主机发送报文。

示意图如下：

我第一个反应是不是防火墙的问题。登录到主机后，因为是centos7的版本，所以通过防火墙状态查看命令，查看防火墙已经关闭。

继续分析，接着考虑是不是防火墙的问题，所以在接收主机B主机上用tcpdump进行抓包，命令如下：

发现报文没问题，接着加上-vv选项，可以看到解析出来的信息，也正是我们要发送的报文，说明中间网络是没问题的。

nc可以说是网络测试的神器，可以方面的建立监听端口，做服务器；可以做客户端测试服务器。

具体测试步骤如下：

1 把B上的flume监听程序停止，然后在B主机上 运行一下命令：

结果：收不到任何消息！！！ 有点吃惊，都可以抓到包了，防火墙也是关闭的为什么收不到那。

不服气，继续用nc，在B主机随便启动一个10009端口：

在A服务器上 通过nc命令连接测试：

输入报文进行测试，仍然收不到报文。

2 看下系统日志，发现没有报错。

进入深深的思考中

说什么，咱们也不能认怂啊，打电话问了下大师，大师说重启下防火墙吧。

所以第二天一大早联系上同事，继续重启防火墙，发现故障依旧。

接着看下flume启动的监听端口情况：

监听的ip配置为0000 ，端口绑定的是10001 ，没问题。

虽然B主机有两块网卡，两个IP，但是我们监听了所有IP啊，谨慎一点，还是把IP配置成抓包抓到的42这个IP，结果故障依旧。

继续在B主机上抓包，发现A主机过来的IP是10网段，C主机过来的IP是134网段，那说明源IP网段不一样，会不会因为网段问题造成的这个问题。

鬼使神差地，用 route -n 看了下路由信息，发现：

10网段的目标IP，用的是eth1 这个网口，但是这个eth1的网口配置的ip是72 ip和A向B发送的目标IP不同，A向B发送的目标Ip为34这个ip。

下面把UDP包的流转过程梳理下：

从B主机（IP:10xxx）向A主机的134xxx 发送UDP报文，UDP报文经过中间的NAT转换后目标IP变成了xxx42 通过网口eth0进入到B主机。

B主机访问10xxx 时候，按照现有的route配置，是通过eth1 网口出去的，如果要是有回包的话，那么接收包的网口eth0和回包的网口eth1 不是同一个网卡！

总觉得不太对，我手工删除老的10xxx 路由，并且添加了下新的路由，新路由走eth0，命令如下：

接着再次测试nc收包情况，却可以收到了，flume也同样可以收到了，至此问题解决。

但是有点想不通，按道理udp报文是不会受到目录路由影响的，有大神知道的，请告知。

互联网工程任务组（IETF）官员透露，HTTP-over-QUIC实验协议将重命名为HTTP/3，并有望成为HTTP协议的第三个正式版本。

UDP协议被广泛用到对网络数据传输的实时性很高，对数据准确性不是非常高的场合，并且如今网络物理介质的高速提升（光纤）降低了数据丢包的机率，并且当网络状况很好的情况下，UDP的缺点又可以很好的大程度上的被改善。因此UDP协议发展前途无量。

所以，作为新一代HTTP协议的底层，要不要重温下？

UDP是什么？

UDP是User Datagram Protocol的缩写，是一种用户数据报协议，又称为用户数据报文协议。区别于TCP是面向连接的协议，UDP是一个简单的面向数据报的传输层协议，UDP的发起和接受是不需要经过连接的，仅仅只需要发送在对应端口上进行监听接受即可，不需要两个客户端一定是连接的

UDP传输不可靠的原因有五点：

TCP协议和UDP协议的区别是什么？

常见问题：QQ用的是TCP还是UDP？

QQ采用的通信协议以UDP为主，辅以TCP协议。QQ并不是完全基于UDP实现，比如在使用QQ进行文件传输等活动的时候，就会使用TCP作为可靠传输的保证。

由于QQ的服务器设计容量是海量级的应用，一台服务器要同时容纳十几万的并发连接，因此服务器端只有采用UDP协议与客户端进行通讯才能保证这种超大规模的服务。

QQ客户端之间的消息传送也采用了UDP模式，因为国内的网络环境非常复杂，而且很多用户采用的方式是通过代理服务器共享一条线路上网的方式，在这些复杂的情况下，客户端之间能彼此建立起来TCP连接的概率较小，严重影响传送信息的效率。而UDP包能够穿透大部分的代理服务器，因此QQ选择了UDP作为客户之间的主要通信协议。

采用UDP协议，通过服务器中转方式。大家都知道，UDP协议是不可靠协议，它只管发送，不管对方是否收到的，但它的传输很高效。但是，作为聊天软件，怎么可以采用这样的不可靠方式来传输消息呢？于是，腾讯采用了上层协议来保证可靠传输：如果客户端使用UDP协议发出消息后，服务器收到该包，需要使用UDP协议发回一个应答包。如此来保证消息可以无遗漏传输。之所以会发生在客户端明明看到“消息发送失败”但对方又收到了这个消息的情况，就是因为客户端发出的消息服务器已经收到并转发成功，但客户端由于网络原因没有收到服务器的应答包引起的。

之所以当时应用UDP，最本质上UDP的优势还是带宽的利用。这一切要回归到99~03年的网络状况，当时网络的特点就是接入带宽很窄而且抖动特别厉害。所谓抖动可能是多方面的，例如延时突发性地暴增、也有可能是由于路由层面的变化突然导致路由黑洞，还各种等等等等的问题。TCP因为拥塞控制、保证有序等原因，在这种网络状态上对带宽的利用是非常低的。而且因为网络抖动的原因，应用层心跳超时，应用层主动断掉socket之后TCP需要三次握手才能重新建立链接，一旦出现频繁的小抖动就会使得带宽利用更低。而等待四次挥手的时间，也会占用服务器上宝贵的资源。

总结来说，当网络差到一定程度了，TCP的优势反而会成为劣势。