socket和Websocket

本文主要針對如下問題給出解答

1.Socket 和 WebSocket 有哪些區別和聯繫？

2.WebSocket 和 HTML5 是什麼關係？

3.必須在瀏覽器中才能使用 WebSocket 嗎？

建議在看以前，先閱讀此文 http://blog.csdn.net/lisaem/article/details/48489703。重點了解OSI七層模型的會話層。

概述

WebSocket 是爲了知足基於 Web 的日益增加的實時通訊需求而產生的。在傳統的 Web 中，要實現實時通訊，通用的方式是採用 HTTP 協議不斷髮送請求。但這種方式即浪費帶寬（HTTP HEAD 是比較大的），又消耗服務器 CPU 佔用（沒有信息也要接受請求）。

HTTP、WebSocket 等協議都是處於 OSI 模型的最高層： 應用層 。而 IP 協議工做在網絡層（第3層），TCP 協議工做在傳輸層（第4層）。

對於 WebSocket 來講，它必須依賴 HTTP 協議進行一次握手 ，握手成功後，數據就直接從 TCP 通道傳輸，與 HTTP 無關了。

Socket是應用層與TCP/IP協議族通訊的中間軟件抽象層，它是一組接口。在設計模式中，Socket其實就是一個門面模式，它把複雜的TCP/IP協議族隱藏在Socket接口後面，對用戶來講，一組簡單的接口就是所有，讓Socket去組織數據，以符合指定的協議。而 WebSocket 則不一樣，它是一個完整的 應用層協議，包含一套標準的 API 。

 

WebSocket API 是 HTML5 標準的一部分， 但這並不表明 WebSocket 必定要用在 HTML 中，或者只能在基於瀏覽器的應用程序中使用。

實際上，許多語言、框架和服務器都提供了 WebSocket 支持，例如：

• 基於 C 的 libwebsocket.org
• 基於 Node.js 的 Socket.io
• 基於 Python 的 ws4py
• 基於 C++ 的 WebSocket++
• Apache 對 WebSocket 的支持： Apache Module mod_proxy_wstunnel
• Nginx 對 WebSockets 的支持： NGINX as a WebSockets Proxy 、 NGINX Announces Support for WebSocket Protocol 、WebSocket proxying
• lighttpd 對 WebSocket 的支持：mod_websocket

補充:

TCP/IP 
TCP/IP是個協議組，可分爲三個層次：網絡層、傳輸層和應用層。 
在網絡層有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。 
在傳輸層中有TCP協議與UDP協議。 
在應用層有:TCP包括FTP、HTTP、TELNET、SMTP等協議 
                 UDP包括DNS、TFTP等協議 
短鏈接 
鏈接->傳輸數據->關閉鏈接 
HTTP是無狀態的，瀏覽器和服務器每進行一次HTTP操做，就創建一次鏈接，但任務結束就中斷鏈接。 
也能夠這樣說：短鏈接是指SOCKET鏈接後發送後接收完數據後立刻斷開鏈接。 
  
長鏈接 
鏈接->傳輸數據->保持鏈接 -> 傳輸數據-> 。。。 ->關閉鏈接。 
長鏈接指創建SOCKET鏈接後無論是否使用都保持鏈接，但安全性較差。 
  
http的長鏈接 
HTTP也能夠創建長鏈接的，使用Connection:keep-alive，HTTP 1.1默認進行持久鏈接。HTTP1.1和HTTP1.0相比較而言，最大的區別就是增長了持久鏈接支持(貌似最新的 http1.0 能夠顯示的指定 keep-alive),但仍是無狀態的，或者說是不能夠信任的。 
  
何時用長鏈接，短鏈接？ 
 長鏈接多用於操做頻繁，點對點的通信，並且鏈接數不能太多狀況，。每一個TCP鏈接都須要三步握手，這須要時間，若是每一個操做都是先鏈接，再操做的話那麼處理速度會下降不少，因此每一個操做完後都不斷開，次處理時直接發送數據包就OK了，不用創建TCP鏈接。例如：數據庫的鏈接用長鏈接， 若是用短鏈接頻繁的通訊會形成socket錯誤，並且頻繁的socket 建立也是對資源的浪費。 
  
而像WEB網站的http服務通常都用短連接，由於長鏈接對於服務端來講會耗費必定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的鏈接用短鏈接會更省一些資源，若是用長鏈接，並且同時有成千上萬的用戶，若是每一個用戶都佔用一個鏈接的話，那可想而知吧。因此併發量大，但每一個用戶無需頻繁操做狀況下需用短連好。 
  
總之，長鏈接和短鏈接的選擇要視狀況而定。