服务器通信技术方案

服务器通信技术方案

前言1

1.服务器通讯需要解决的问题2

1.1单台RCU设备通讯情况2

1.2上万个RCU甚至达到将近百万终端与服务器同时通讯2

1.2.1 单台服务器2

1.2.2 集群服务器2

2.目前服务器通讯主流技术方案3

2.1 网上常用主流方案简介与比较3

2.1.1 传统的socket通讯模型3

2.1.2 Windows下IOCP模型3

2.1.3 linux下epoll模型4

2.1.4 其它的网络通讯第三方开源库简介及比较5

2.2服务器集群方案6

3.根据项目情况选择最合适方案8

3.1 推荐选择linux系统下的epoll及开源库Boost::asio8

3.2 可能问题8

RCU-U设备采集数据如：车辆诊断，通过GSM基站定位，内置GPS，GPRS系统提供远程数据，对车辆各个系统的运行状况（如ENG、ABS、ETC等）实时监测状态数据等。

这些数据的网络通讯平台，则由服务器提供的通讯技术来实现，因此如何实现这种多设备数据同时接收的技术方案很重要。本文将详细介绍相关技术及提出方案。

服务器通讯需要解决的问题

单台RCU设备通讯情况

主要通讯数据:

设备端，刚连接时登陆验证（设备端信息验证）;

设备端，诊断数据及其它采集数据上传到服务器（估计频率每秒发一次）;

服务器端，发送指令，实现对设备端的远程配置;

RCU设备工程师估计的数据:

1每个RCU设备每秒钟产生一条数据，每条数据大概100个字节左右(0.1K左右)；

2可以假设每台车每天平均开动1小时或2小时(实际产生数据时间)；

100万级别的RCU用户量，需要服务器有近百兆的网络带宽吞吐量。

1000万级别的RCU用户量，需要服务器有近千兆的网络带宽吞吐量。

上万个RCU甚至达到将近百万终端与服务器同时通讯

1.2.1单台服务器

如果按照经典的server/client通讯模型，当有一个设备通过（TCP/UDP）连接服务器时，服务端单独开一个线程为这个设备数据服务，显然，当路数越多，我们的设备又是长连接方式，很快服务器将在设备近千路时服务器资源将达到上限，并且存在大量线程切换与管理问题。这时如果我们能合理利用单台服务器资源（如：windows 下iocp 模式，linux下的epoll网络通信模式等），在更优的管理模式下，将能接更多设备的服务（网上资料预估几千路的长连接甚至硬件较好配置下达到万路以上）。上面我们能在单台服务器在较好硬件配置和软件优化的模型管理下，能解决几千路上万路设备的长连接。

1.2.2集群服务器

但是，如果几十万台甚至接近百万级别的设备数量同时访问服务端时，这个时候需要涉及到一种合理的集群服务器架构模式。理论上，为了达到1:10000的连接，可以采用Server-Client 的连接方式，而为了达到1:10000*100的连接，我们怎么办呢？一般会采用Client-> ConnServer -> LogicServer。相当于有一批服务器来合理布局解决设备的大并发通讯问题。ConnServer在接受完Client 的连接后，将Logic Server 暴露给Client,并立刻断开连接，称之为短连接。以后的数据交互就和Conn Server没有关系了，让Logic Server 直接跟client再长连接通讯，这种架构有很多的优势。

[图一：标准集群Server架构方案]

目前服务器通讯主流技术方案

2.1网上常用主流方案简介与比较

2.1.1 传统的socket通讯模型

socket有两种：流式Socket（SOCK_STREAM）和数据报式Socket（SOCK_DGRAM）。流式是一种面向连接的Socket，针对于面向连接的TCP服务应用；数据报式Socket是一种无连接的Socket，对应于无连接的UDP服务应用。

一般小型的c/s通讯系统利用socket API 和结合一个线程对应一个客户的开发模式。如果路数增多，容易耗尽服务端资源。该通讯模型利用硬件资源效率不高。

2.1.2Windows下IOCP模型

IOCP 完成端口模型又是怎样实现的呢？首先我们创建一个完成端口CreateIOCompletionPort。绑定端口之后，建立一个监听线程，用来监听客户端的连接，当有连接进来时，将该连接的套接字加入到IOCP对队列中，同时再创建几个工作线程（CPU数*2+2），工作线程调用getQueuedCompletionStatus 方法在关联到这个完成端口上的所有套接字上等待I/O 的完成，再判断完成了什么类型的I/O，然后接着发出WSASend 和WSARecv，这样在该连接发生请求时，IOCP模型就会在工作线程通知，这样我们就可以在工作线程中，完成对客户端的请求做出一系列响应。

完成端口提供了一个高效复杂的内核对象，使得非I／O处理和I／O处理能重叠并行地操作。该对象通过指定工作线程的数量，对重叠的I／O操作进行处理。当一个事件发生，此完成端口就被操作系统加入一个队列中，然后应用程序可以对核心层进行查询以得到此完成端口。IOCP的核心思想简单说就是：将所有用户的请求都投递到一个消息队列中，利用事先创建好的若干个工作线程逐一从消息队列中取出消息并加以处理。这样不仅减少了线程资源，也大大提高了线程的利用率。要注意的是，所谓完成端口，实际上是Windows采用的一种I／O构造机制，并非通常所说的端口(如Port：80)。

2.1.3linux下epoll模型

epoll是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。因为它会复用文件描述符集合来传递结果而不用迫使开发者每次等待事件之前都必须重新准备要被侦听的文件描述符集合，另一点原因就是获取事件的时候，它无须遍历整个被侦听的描述符集，只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。epoll除了提供select/poll那种IO事件的电平触发（Level Triggered）外，还提供了边沿触发（Edge Triggered），这就使得用户空间程序有可能缓存IO状态，减少epoll_wait/epoll_pwait的调用，提高应用程序效率。

传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是“活跃”的，但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对“活跃”的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有“活跃”的socket才会主动的去调用callback函数，其他idle状态socket则不会。

通讯模型主要优点主要缺点

传统socket 适合于连接量较小的通讯情况，通过

socet API 建立C/S 通讯。服务连接路数小，IO没有复用，一般是一个线程对应终端的服务模式。通讯情况下，每个socket句柄，包含不活跃的连接也会需要遍历。

Windows下IOCP 适合于大量连接数（上万路），IO复

用，消息队列，可指定相应工作线程

数，轮询端口的事件，充分利用多核，

高效率地服务于多并发。只跑在windows服务器下，如果数据库平台为linux服务器，影响系统功能模块整合。

linux下epoll 适合于大量连接数（上万路），

多路复用IO接口，只遍历那些被内核

IO事件异步唤醒而加入Ready队列的

描述符集合。通讯情况下，只对活跃

的连接遍历，提高了效率。当前主流ET和LT模式下，其中LT模式比较复杂，较难处理数据收发。