socket 获取回传信息_Socket开发框架之数据传输协议

我在前面一篇随笔《Socket开发框架之框架设计及分析》中，介绍了整个Socket开发框架的总体思路，对各个层次的基类进行了一些总结和抽象，已达到重用、简化代码的目的。本篇继续分析其中重要的协议设计部分，对其中消息协议的设计，以及数据的拆包和封包进行了相关的介绍，使得我们在更高级别上更好利用Socket的特性。

1、协议设计思路

对Socket传输消息的封装和拆包，一般的Socket应用，多数采用基于顺序位置和字节长度的方式来确定相关的内容，这样的处理方式可以很好减少数据大小，但是这些处理对我们分析复杂的协议内容，简直是一场灾难。对跟踪解决过这样协议的开发人员来说会很好理解其中的难处，协议位置一旦变化或者需要特殊的处理，就是很容易出错的，而且大多数代码充斥着很多位置的数值变量，分析和理解都是非常不便的。随着网络技术的发展，有时候传输的数据稍大一点，损失一些带宽来传输数据，但是能成倍提高开发程序的效率，是我们值得追求的目标。例如，目前Web API在各种设备大行其道，相对Socket消息来说，它本身在数据大小上不占优势，但是开发的便利性和高效性，是众所周知的。

借鉴了Web API的特点来考虑Socket消息的传输，如果对于整体的内容，Socket应用也使用一种比较灵活的消息格式，如JSON格式来传输数据，那么我们可以很好的把消息封装和消息拆包解析两个部分，交给第三方的JSON解析器来进行，我们只需要关注具体的消息处理逻辑就可以了，而且对于协议的扩展，就如JSON一样，可以自由灵活，这样瞬间，整个世界都会很清静了。

对于Socket消息的安全性和完整性，加密处理方面我们可以采用 RSA公钥密码系统。平台通过发送平台RSA公钥消息向终端告知自己的RSA公钥，终端回复终端RSA公钥消息，这样平台和终端的消息，就可以通过自身的私钥加密，让对方根据接收到的公钥解密就可以了，虽然加密的数据长度会增加不少，但是对于安全性要求高的，采用这种方式也是很有必要的。

对于数据的完整性，传统意义的CRC校验码其实没有太多的用处了，因为我们的数据不会发生部分的丢失，而我们更应该关注的是数据是否被篡改过，这点我想到了微信公众号API接口的设计，它们带有一个安全签名的加密字符串，也就是对其中内容进行同样规则的加密处理，然后对比两个签名内容是否一致即可。不过对于非对称的加密传输，这种数据完整性的校验也可以不必要。

前面介绍了，我们可以参照Web API的方式，以JSON格式作为我们传输的内容，方便序列号和反序列化，这样我们可以大大降低Socket协议的分析难度和出错几率，降低Socket开发难度并提高开发应用的速度。那么我们应该如何设计这个格式呢？

首先我们需要为Socket消息，定义好开始标识和结束标识，中间部分就是整个通用消息的JSON内容。这样，一条完整的Socket消息内容，除了开始和结束标识位外，剩余部分是一个JSON格式的字符串数据。