通訊(Netty、Mina2)【通訊粘包的處理】、【數據協議】、【網絡系統的安全性】

Netty、Mina2是很是優秀的javaNIO+ThreadPool線程池通訊框架 http://www.cnblogs.com/51cto/archive/2010/09/06/1819361.html 提到通訊就得面臨兩個問題，一是通訊協議的選擇，二是數據協議的定義。通訊協議耳熟能詳的就有好幾種，TCP，UDP，HTTP，FTP等等。數據協議是一種數據交換的格式，像jason,xml,amf3,google protocol均可以用做數據協議，你也能夠本身根據通訊的效率，安全等因素來定義本身的數據協議。

　　通訊系統的開發是一項很複雜的工做，不要覺得往發服務端發一個Hello World！就認爲徹底掌握了通訊系統的開發。歸納來講要開發一個健壯的通訊系統，必須從這幾個方面來着手。

　　一，通訊粘包的處理

　　這裏包的概念是邏輯上的數據包，也就是咱們發送的一個完整業務消息包，粘包狀況有兩種，一種是粘在一塊兒的包都是完整的數據包，另外一種狀況是粘在一塊兒的包有不完整的包。不是全部的粘包現象都須要處理，若傳輸的數據爲不帶結構的連續流數據（如文件傳輸），則沒必要把粘連的包分開（簡稱分包）。但在實際工程應用中，傳輸的數據通常爲帶結構的數據，這時就須要作分包處理。

　　爲了不粘包現象，可採起如下幾種措施。一是對於發送方引發的粘包現象，用戶可經過編程設置來避免，TCP提供了強制數據當即傳送的操做指令push，TCP軟件收到該操做指令後，就當即將本段數據發送出去，而沒必要等待發送緩衝區滿；二是對於接收方引發的粘包，則可經過優化程序設計、精簡接收進程工做量、提升接收進程優先級等措施，使其及時接收數據，從而儘可能避免出現粘包現象；三是由接收方控制，將一包數據按結構字段，人爲控制分屢次接收，而後合併，經過這種手段來避免粘包。

　　以上提到的三種措施，都有其不足之處。總的來講下降了通訊系統的吞吐量。咱們能夠本身設計一個分包算法來處理粘包的問題，該算法的實現是這樣的:

1. 當有數據到達時，將數據壓入程序緩衝區。
2. 循環處理緩衝區，若是緩衝區長度大於包頭長度，則取出長度信息n，不然跳出循環，若是緩衝區的長度大於n，則從緩衝區取出一個完整包進行處理，不然跳出循環。

若是你是Java的愛好均可以參考一下Mina和netty2的實現，像Mina和Netty2都提供了粘包處理類可供使用，像Mina的CumulativeProtocolDecoder類,Netty2的LengthFieldBasedFrameDecoder。

　　二，數據協議選擇

　　如今已經有不少數據協議可供咱們選擇，像jason,xml,amf3,google protocol等等，這些協議相應的語言都有API來對自身數據作協議處理，咱們選擇協標準無非就是效率和大小，這裏每一個人能夠根據實際的應用環境選擇適合的數據協議。

　　三，網絡系統的安全性

　　網絡安全是一個永遠的話題，對通訊數據加密通常常RSA對byte流加密，FLOOD驗證，IP黑名單驗證都是必須考慮到的。

　　以上是作網絡開發必須瞭解的一些基礎知識，在這裏咱們使用一個具體的實例來加深一下理解，Java與Flex使用AMF3數據協議通訊。作過網絡開發的通常都會知道套接字（SOCKET），不少語言都會通SOCKET來提供對網絡操做的API，Java的提供的NIO SOCKET是一個高效的異步通訊API，固然能夠在這個基礎上來開發咱們的網絡應用，但這種Native API須要咱們花不少精力來處理網絡通訊的細節，消弱了咱們對業務的關心。爲咱們開發帶來不少不便性，幸虧Java有不少現成的NIO SOCKET框架可供使用，像Mina，Netty2，xSocket等等，這些框架處理了不少底層的通訊問題，提供了一些易用的API以供使用。在這個實例中咱們使用Netty2來作通訊框架。

轉自 http://www.cnblogs.com/51cto/archive/2010/09/06/1819361.html