C/S通信模型和相关技术要点

差点儿全部的项目中，都会涉及到client和服务端。而client与server之间的通信又是一个非经常见但又有须要问题的技术问题。

首先，连接方式有长连接和短连接。先看看概念。

长连接短连接仅仅是一个概念性的问题,仅仅要知道其概念，不是一个特殊的东西：

长连接：系统通讯连接建立后就一直保持。

短连接：仅仅有系统须要相互发消息连接才建立（client发起），请求消息得到响应后连接关闭；

通讯实体间使用长连接，一般还须要定义心跳消息，定期发送来检測系统间链路是否异常，每隔一定时间发送一次心跳，假设一定次数没有收到心跳消息，这觉得此连接出现故障，须要断开连接又一次建立。

详细心跳消息的格式，以及发送间隔，以及多少次没有收到心跳就觉得链路异常，以及数据部是否算作心跳消息（有的系统假设接收到数据包则会清除心跳计时器也就相当于系统中的数据包也算作心跳消息）；这个须要两端进行协商。比方GSM经常使用的短消息中心和其它网络实体互连的SMPP协议，要求建立的就是长连接。

非常显然，长连接要复杂些。对于服务端，要对连接上来的client进行管理，还要检查心跳包。非常多业务server都用的长连接，而接口server一般用短连接。

其次，数据的同步和异步请求。

在client请求到server后，client能够等待结果返回后，再处理其它的事情，也能够把请求放到队列，继续做其它的事情，有结果返回后，在做处理。这里就是同步和异步的问题。

一般来说，同步等待也是有个超时时间的，不能一直等待下去。而异步处理的话，都会有个消息队列和请求队列。当server的消息返回后，放到消息队列中，另外有一个线程来处理这个消息队列中的消息，以及和请求队列的数据做对应的处理。

另外，就是堵塞和非堵塞。

堵塞的结果就是这个线程将会等到这个结果返回，非堵塞就是仅仅发送请求，不等待结果。

在非常多时候，都会用异步和非堵塞，这样能够提高处理性能和资源的高效使用。

最后，就是报文。数据报文是自定义的。一般有2种：数据结构和xml数据。

这2种各有利弊。对于数据结构，程序内部处理比較easy，看在多版本号兼容方面没那么好，比方结构添加了字段，低版本号处理的时候，可能就有问题了。xml数据的兼容性比較好，你能够仅仅关心自己想要的字段，而不用管那些不关心的字段，所以对版本号的兼容也比較好。所以如今非常多都採用xml数据。而对xml数据，如今用的比較多的就是json，而且C++、java、android等都支持。另外就是在传输的过程中加密。当然了，对于跨平台，还要考虑字节序的问题。

最后，在总结一下：

1 连接方式：长连接和短连接。

2 数据的同步和异步请求。

3 堵塞和非堵塞。

4 报文：协议，加密，字节序。

转载请注明原创链接：/article/1627957.html