http://blog.csdn.net/fenglibing/article/details/7100222
2、WEB客戶端與服務端信息交互的幾種方式
1）、Flash XMLSocket入門示例： http://en.wikipedia.org/wiki/XMLSocket
不足：
a）、客戶端必須安裝 Flash 播放器；
b）、因為 XMLSocket 沒有 HTTP 隧道功能，XMLSocket 類不能自動穿過防火牆；
c）、因為是使用套接口，需要設置一個通信端口，防火牆、代理服務器也可能對非 HTTP 通道端口進行限制；
2）、Java Applet 套接口
不足：
a）、需要安裝Java的插件；
b）、有些瀏覽器運行於如Apple iOS、Android等是不支持Applet的；
c）、軟件插件的安裝可能會受制於當前用戶的系統權限；
d）、受安全限制不能夠正常運行；
e）、如果運行的Applet需要安裝新的JRE，那么此時用戶在看到Applet展示的時候會有等待的過程，這個可能會因為網絡或者代理導致失敗，使用戶不能夠正常使用該功能；
f）、Applet標簽，必須要是支持跨瀏覽器的；
詳見：http://en.wikipedia.org/wiki/Java_applet#Disadvantages
3）、Comet
a）、基於 AJAX 的長輪詢（long-polling）方式
示例圖：
b）、基於 Iframe 及 htmlfile 的流（streaming）方式
示例圖：
使用“htmlfile“的 ActiveX 組件，解決IE的加載顯示問題；
瀏覽器兼容性比較好，Google Talk是基於這種方式實現的；
還是存在從客戶端往服務端發消息時，需要提交新的請求；
4）、HTML5中的WebSocket
1）~3）詳細參見： https://www.ibm.com/developerworks/cn/web/wa-lo-comet
3、WebSocket
1）、WebSocket介紹HTML5 Web Sockets規范定義了Web Sockets API，支持頁面使用Web Socket協議與遠程主機進行全雙工的通信。它引入了WebSocket接口並且定義了一個全雙工的通信通道，通過一個單一的套接字在Web上進行操作。HTML5 Web Sockets以最小的開銷高效地提供了Web連接。相較於經常需要使用推送實時數據到客戶端甚至通過維護兩個HTTP連接來模擬全雙工連接的舊的輪詢或長輪詢（Comet）來說，這就極大的減少了不必要的網絡流量與延遲。
要使用HTML5 Web Sockets從一個Web客戶端連接到一個遠程端點，你要創建一個新的WebSocket實例並為之提供一個URL來表示你想要連接到的遠程端點。該規范定義了ws://以及wss://模式來分別表示WebSocket和安全WebSocket連接。一個WebSocket連接是在客戶端與服務器之間HTTP協議的初始握手階段將其升級到Web Socket協議來建立的，其底層仍是TCP/IP連接。
WebSocket Hybi草案12的地址：http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-12，可以以此為入口訪問其它的草案。
2）、優點
a）、服務器與客戶端之間交換的標頭信息很小，大概只有2字節；
b）、客戶端與服務器都可以主動傳送數據給對方；
c）、不用頻率創建TCP請求及銷毀請求，減少網絡帶寬資源的占用，同時也節省服務器資源；
3）、WebSocket數據幀的介紹
a）、草案版本00到草案版本05之間，詳細可以查看草案文檔，解碼編碼可以看見Netty的WebSocketFrameDecoder和WebSocketFrameEncoder實現；
b）、草案版本06到現在最新的草案17，介紹參見文章：http://blog.csdn.net/fenglibing/article/details/6852497
4）、WebSocket不同版本的幾種握手方式
a）、無安全key、最老的WebSocket握手協議的實現（Flash）；
b）、帶兩個安全key請求頭的后端握手實現；
c）、帶一個安全key請求頭的后端握手實現；
參見：http://blog.csdn.net/fenglibing/article/details/7100070
5）、WebSocket可以穿越防火牆嗎？
WebSocket使用標准的80及443端口，這兩個都是防火牆友好協議，Web Sockets使用HTTP Upgrade機制升級到Web Socket協議。HTML5 Web Sockets有着兼容HTTP的握手機制，因此HTTP服務器可以與WebSocket服務器共享默認的HTTP與HTTPS端（80和443）。
6）、Web Sockets與代理服務器交互
代理服務器的問題：
a）、HTTP代理服務器可能會選擇關閉流或閑置的WebSocket連接，因為它們看起好像是嘗試連接一個沒有回應的HTTP服務器；
b）、代理服務器可能會緩沖未加密的HTTP響應，這將會對HTTP響應流帶來不可估計的延遲；
c）、未加密的WebSocket連接(ws://開頭的請求)服務器時，如果中間存在透明代理服務器，連接可能會失敗，或者發送消息會失敗；而加密的WebSocket連接在存在透明代理服務器的情況下成功的機率會比較大；
關於代理詳細參見：http://www.infoq.com/cn/articles/Web-Sockets-Proxy-Servers
7）、使用示例展示
WebSocket經由瀏覽器本身實現后，在Web端的實現就非常的簡單，只需要簡單初使化一個WebSocket組件，並且增加onopen、onmessage、onclose等事件的處理即可，以下是一個用於初使化WebSocket連接（WEB端JS實現）的源碼截圖展示：
這一個截圖展示的在不支持WebSocket的瀏覽器，使用Comet針對不同的瀏覽器進行的組件初使化處理操作：
下面這個圖展示的是使用WebSocket與不使用WebSocket發送消息的代碼及邏輯差異，其中畫紅線的部份為使用WebSocket發送消息的實現，只有一行代碼，而余下的代碼，則是針對不支持WebSocket瀏覽器發送消息的代碼
本文出自：馮立彬的博客
再分享一下我老師大神的人工智能教程吧。零基礎！通俗易懂！風趣幽默！還帶黃段子！希望你也加入到我們人工智能的隊伍中來！https://blog.csdn.net/jiangjunshow