自定义网络协议总结

为什么要自定义网络协议？

目前网络通信常用的应用层协议已经有了HTTPS和HTTP，为什么还要自定义协议呢？

个人认为主要有两个好处：

1. 更加安全。
   目前网络上最常见的攻击手段就是抓HTTP/HTTPS包，如果自定义网络协议，抓包工作无法使用，能避开大部分来自于脚本小子的攻击。
   当然对于直接在TCP/IP层的攻击还是需要由网络协议本身的安全来保证。
2. 更加轻便。
   HTTP/HTTPS在业务上绝对已经是可以满足大部分情况了，但是也因为这一点，导致其协议没法根据业务来精简。
   举个简单的例子，你可能只是想发送“0x12”这一个字符，但是由于http本身结构的设定，你必须将“请求方法”、“HTTP版本”，“状态码”以及“header信息”等一起发送出去。这样整个消息加起来可能有几十个字节，但实际用于你业务有用的只有“0x12”这一个字节而已。

自定义网络协议注意点

笔者自己接触的是TCP连接，此处也以此举例了。

1. 解决tcp粘包分包问题。
2. 数字签名，保证对称密钥信息只有Server和Client两个人有。
3. 消息认证，避免消息被篡改。
4. 协议callback的实现，也就是request和response的配对问题。
5. 防范重放攻击。

tcp粘包分包问题

对于粘包分包问题有两种解决方式：
方法一是通过在每段消息头尾添加唯一的“标志字段”，使用“标志字段”来得到一段段完整的包内容。
方法二是在每段消息头部添加length字段，length设置固定的字节，每次先读取length的内容，然后根据length去读取包剩余的部分。

对tcp粘包分包不是很了解的可以看下笔者的另一篇文章：socket粘包和分包的处理

数字签名和消息认证

这两个是必须要做的，具体的实现一般都是根据自己需要来，由于之前笔者已经有文章描述过其内容了，此处就不多增篇幅了。
有兴趣的读者可以看下笔者这篇文章：HTTP和HTTPS

协议callback的实现

每个包都是单独的，由本地发送出的request和从远端接收到的response如何能配对呢？
其实也就是很普通的做法，在包中加一个frame字段，每个包的frame字段唯一，这样本地接收到response之后就可以用来配对相应的request来实现callback。

防范重放攻击

这个做法还是基于frame来的，既然已经有了frame可以保证每个包的唯一性，那么本地只需要让frame递增，并且存储frame当前的值就可以了。
如果接收到的包的frame小于本地存储的frame的值，那么就可以认为是重放攻击，把这个包丢掉。