Web Sockets

目標：

在一個單獨的持久鏈接上提供全雙工、雙向通訊。與其餘方案不一樣，Web Sockets不使用HTTP協議，而使用一種自定義的協議。這種協議專門爲快速傳輸小數據設計。雖然要求使用不一樣的Web服務器，但卻具備速度上的優點

過程：

• 建立Web Socket
• HTTP請求發送到瀏覽器，發起鏈接
• 服務器響應
• 使用的HTTP升級爲Web Socket協議

也就是說，使用標準的HTTP服務器沒法實現Web Sockets，只有支持這種協議的專門服務器才能正常工做

在使用Web Socket URL時，必須帶着這個模式（將來可能支持其餘模式）

• 未加密： ws://
• 加密： wss://

使用自定義協議而非HTTP協議：

• 好處

  可以在客戶端和服務器之間發送很是少許的數據，而沒必要擔憂HTTP那樣的字節開銷

  適用於移動應用（帶寬和網絡延遲）

• 缺點：

  制定協議的時間比制定JavaScript API的時間還要長

支持Web Sockets爲瀏覽器：

Firefox 6+ 、 Safari 5+ 、 Chrome和iOS 4+版Safari

Web Sockets API

1. 建立Web Socket，先實例一個WebSocket對象並傳入要鏈接的URL：

   var socket = new WebSocket("ws://www.example.com/server.php")

-Ps: 必須給WebSocket構造函數傳入絕對URL。同源策略對Web Sockets不適用，所以能夠經過它打開到任何站點的鏈接。至因而否與某個域中的頁面通訊，徹底取決於服務器。（經過握手信息就能夠知道請求來自何方）-

爲確保經過XHR訪問的URL安全，通行的作法就是驗證發送請求者是否有權限訪問相應的資源

• 要求以SSL鏈接來訪問能夠經過XHR請求的資源
• 要求每一次請求都要附帶通過相應算法計算獲得的驗證碼

注意： 如下措施對防範CSRF攻不起做用。

• 要求發送POST而不是GET請求 --- 很容易改變
• 檢查來源URL以肯定是否可信 --- 來源記錄很容易僞造
• 基於cookie信息進行驗證 --- 一樣很容易僞造

ps： XHR對象也提供了一些安全機制，雖然表面上看起來保證安全，但實際上卻至關不可靠。

如： xhr.open("get","example.php",true, "usename","password") // 不要這樣作！！！

即使能夠考慮這種安全機制，可是仍是儘可能不雅這樣作。把用戶名和密碼保存在JavaScript代碼總自己就很不安全的。任何人，只要他會使用JavaScript調試器，就能夠經過查看相應的變量發現純文本形式的用戶名和密碼

同源策略

: 是對XHR的一個主要約束，它爲通訊設置了「相同的域、相同的端口、相同的協議」這一限制。

試圖訪問上述限制以外的資源，都會引起安全錯誤，除非採用CORS(Cross-Origin Resource Sharing, 跨源資源共享)。IE經過XDomainRequest對象支持CORS，其餘瀏覽器也經過XHR對象原生支持CORS。圖像Ping和JSONP是另外兩種跨域通訊的技術，但不如CORS