一直想把这个流程整理一下。
包结构：
|
包 |
对（datacrc+protoID+dataSize）组成的byte[] 进行crc计算而得到 |
对（数据内容）进行crc计算而得到 |
协议号 |
数据内容的字节长度 |
数据内容 |
|
字段 |
headcrc |
datacrc |
protoID |
dataSize |
data |
|
类型 |
uint |
uint |
ushort |
ushort |
byte[] |
|
字节数 |
4 |
4 |
2 |
2 |
dataSize |
- crc校验
问：TCP协议中，底层做了校验，那通信时我们还有必要再进行有CRC或者其他校验吗？
答：tcp 是可靠的, 就是有重传, 校验, 有序等保证. 在字节流层次, 你不用验证了.
但是协议层可靠不代表应用层可靠, 应用层数据校验只能自己做CRC/MD5/SHA1
因为tcp是基于流的,一个报文可能分多个包发送，你自己要要验证报文的完整性
TCP 的校验只能保证物理电路上如果出错, 可以发现并通过重传来修正. 但是对人为的对包恶意的修改是无法校验的。如果是安全要求比较高的地方, 最好还是自己再校验下.
问：为什么选crc ?
答：CRC（Cyclic Redundancy Check，循环冗余校验）
其校验准确度较之普通的奇偶校验、校验和等方法更高，当然计算也略微复杂；
较之MD5、SHA1等算法，CRC安全性和准确度方面又略显不足，
但计算较之这两者明显简单，效率更高。
所以如果仅仅针对网络数据的一致性校验，即收发端数据的是否一致
（因为在Socket编程里，单次收到数据的长度和发送数据的长度即使在阻塞模式下，也不一定是相同的，这个依赖于网络环境，虽然TCP协议保证了数据的完整性和一致性，但像人为对数据进行了分片的这种情况，在收到数据时视情况还是有必要进行一下校验），
针对这种校验要求，CRC32是明显足够，也不会带来很大的计算负担。
2.加密，解密
介绍：
不可逆加密：md5 ，sha1，加密后就不能解密，只能用于存储密码和校验文件变动，不能用网络通讯
可逆对称加密：DES，3DES，AES
可逆非对称加密： RSA
选定：对称加密：DES 非对称加密：RSA
.net有封装好的，DESCryptoServiceProvider, RSACryptoServiceProvider
流程：
一般流程为：先用非对称加密去加密对称加密的密钥(对称加密的密钥比较短，可视为不怎么耗时) ，然后再用对称加密去加密数据。
也就是说：
客户端用RSA生成公钥和私钥，发送公钥给服务器，服务器用收的公钥对3DES的key进行加密后，发还给客户端，客户端用私钥进行解密得到3DES的key，之后就可以用此key来进行加密解密。
3.数据内容形式：json, protobuf-net, protobuf-java, pbc, pb-lua-gen, sproto
选定:Client：pbc Server: protobuf-java (我的服务器是java写的)