一直想把這個流程整理一下。
包結構：
| 包 |
對（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寫的)