服务器通信技术方案

服务器通信技术方案 前言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贓熱俣阃歲匱阊邺镓騷鯛汉鼉。 修订记录 序号 版本号 1.00.000 修订内容 第一个版本 修订人 颜冬 修订日期 2013.09.07 前言 RCU-U设备采集数据如：车辆诊断，通过GSM基站定位，内置GPS，GPRS系统提供远程数据，对车辆各个系统的运行状况（如ENG、ABS、ETC等）实时监测状态数据等。坛摶乡囂忏蒌鍥铃氈淚跻馱釣。 这些数据的网络通讯平台，则由服务器提供的通讯技术来实现，因此如何实现这种多设备数据同时接收的技术方案很重要。本文将详细介绍相关技术及提出方案。蜡變黲癟報伥铉锚鈰赘籜葦繯。 1 / 8

服务器通讯需要解决的问题 单台RCU设备通讯情况 主要通讯数据:

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

设备端，诊断数据及其它采集数据上传到服务器（估计频率 每秒发一次）; 服务器端，发送指令，实现对设备端的远程配置; RCU设备工程师估计的数据:

1每个RCU设备每秒钟产生一条数据，每条数据大概100个字节左右(0.1K左右)； 2可以假设每台车每天平均开动1小时或2小时(实际产生数据时间)； RCU数量（个） 1秒 1 1万 100万 1000万 0.1kb 1000kb 0.97M 100,000kb 97M 1000,000kb 970M 1小时 360kb 3515M 3.43G 343G 3430G 3.35TB 2小时 720kb 7030M 6.86G 686G 6860G 6.70TB 从上数据显示如果达到：

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再长连接通讯，这种架构有很多的优势。驅踬髏彦浃绥譎饴憂锦諑琼针。 2 / 8

[图一：标准集群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)。輒峄陽檉簖疖網儂號泶蛴镧釃。 3 / 8

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服务数，轮询端口的事件，充分利用多核，器，影响系统功能模块整合。 高效率地服务于多并发。 适合于大量连接数（上万路）， 多路复用IO接口，只遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合。通讯情况下，只对活跃的连接遍历，提高了效率。当前主流4 / 8

ET和LT模式下，其中LT模式比较复杂，较难处理数据收发。 linux下epoll