首先明確一點：存在即合理
Browser已經支持http協議，爲什麼還要開發一種新的WebSocket協議呢？我們知道http協議是一種單向的網絡協議，在建立連接後，它只允許Browser/UA（UserAgent）向WebServer發出請求資源後，WebServer才能返回相應的數據。而WebServer不能主動的推送數據給Browser/UA，當初這麼設計http協議也是有原因的，假設WebServer能主動的推送數據給Browser/UA，那Browser/UA就太容易受到***，一些廣告商也會主動的把一些廣告信息在不經意間強行的傳輸給客戶端，這不能不說是一個災難。那麼單向的http協議給現在的網站或Web應用程序開發帶來了哪些問題呢？
讓我們來看一個案例，現在假設我們想開發一個基於Web的應用程序去獲取當前Web服務器的實時數據，例如股票的實時行情，火車票的剩餘票數等等，這就需要Browser/UA與WebServer端之間反覆的進行http通信，Browser不斷的發送Get請求，去獲取當前的實時數據。下面介紹幾種常見的方式：
1. Polling
這種方式就是通過Browser/UA定時的向Web服務器發送http的Get請求，服務器收到請求後，就把最新的數據發回給客戶端（Browser/UA），Browser/UA得到數據後，就將其顯示出來，然後再定期的重複這一過程。雖然這樣可以滿足需求，但是也仍然存在一些問題，例如在某段時間內Web服務器端沒有更新的數據，但是Browser/UA仍然需要定時的發送Get請求過來詢問，那麼Web服務器就把以前的老數據再傳送過來，Browser/UA把這些沒有變化的數據再顯示出來，這樣顯然既浪費了網絡帶寬，又浪費了CPU的利用率。如果說把Browser發送Get請求的週期調大一些，就可以緩解這一問題，但是如果在Web服務器端的數據更新很快時，這樣又不能保證Web應用程序獲取數據的實時性。
2. Long Polling
上面介紹了Polling遇到的問題，現在介紹一下LongPolling，它是對Polling的一種改進。
Browser/UA發送Get請求到Web服務器，這時Web服務器可以做兩件事情，第一，如果服務器端有新的數據需要傳送，就立即把數據發回給Browser/UA，Browser/UA收到數據後，立即再發送Get請求給Web Server；第二，如果服務器端沒有新的數據需要發送，這裏與Polling方法不同的是，服務器不是立即發送迴應給Browser/UA，而是把這個請求保持住，等待有新的數據到來時，再來響應這個請求；當然了，如果服務器的數據長期沒有更新，一段時間後，這個Get請求就會超時，Browser/UA收到超時消息後，再立即發送一個新的Get請求給服務器。然後依次循環這個過程。
這種方式雖然在某種程度上減小了網絡帶寬和CPU利用率等問題，但是仍然存在缺陷，例如假設服務器端的數據更新速率較快，服務器在傳送一個數據包給Browser後必須等待Browser的下一個Get請求到來，才能傳遞第二個更新的數據包給Browser，那麼這樣的話，Browser顯示實時數據最快的時間爲2×RTT（往返時間），另外在網絡擁塞的情況下，這個應該是不能讓用戶接受的。另外，由於http數據包的頭部數據量往往很大（通常有400多個字節），但是真正被服務器需要的數據卻很少（有時只有10個字節左右），這樣的數據包在網絡上週期性的傳輸，難免對網絡帶寬是一種浪費。
通過上面的分析可知，要是在Browser能有一種新的網絡協議，能支持客戶端和服務器端的雙向通信，而且協議的頭部又不那麼龐大就好了。WebSocket就是肩負這樣一個使命登上舞臺的。