在我們做web項目的過程中，經常需要做的一個模塊是消息模塊。典型的場景：一個商城系統的后台管理，我想實現如果前台有客戶下單，后台就會接到消息，以便盡快發貨處理。
要實現上述的功能，我們有幾種備選的方案。
方案1.使用ajax短輪詢，比如每隔1分鍾去請求一次服務器，讓服務器去數據庫去查詢，看看有無新的未處理的訂單，然后返回給客戶端。
方案2.長輪詢，長輪詢的原理與上述類似，只不過采取了阻塞響應（response）的方法，也就是說只要服務器沒有響應，這個請求就不斷開，一直等到服務器有響應為止。
ajax短輪詢好比客戶端每隔一段時間打一個電話給服務器，服務器不管有沒有數據都要響應給客戶端，響應完以后就掛掉電話，然后周而復始；
長輪詢則是客戶端打一個電話，開始一直等，直到服務器有響應，如果服務器一直不響應，這個請求就一直掛在那邊。
很顯然，這兩種方案都有各自弊端。
方案1：每隔一定時間去輪詢服務器，這個時間的設置很關鍵，太長了，即時性得不到保證，太短了，有可能會造成服務器性能的浪費（主要是cpu）,假設在一個小時之內都沒有一個訂單，但是客戶端還是不間斷的每分鍾發一次請求，這些請求就是浪費。
方案2：方案2的出現本來是為了解決方案1這種盲目不確定地發送請求造成浪費的弊端，但是它自己同樣也有弊端，首先，它采取阻塞的方式來強迫連接長時間保持，而對於服務器而言，在同一個時間里面能處理的連接數（我們稱之為程序的並發數）是有限的，而長輪詢方式很容易造成服務端達到並發的限制，因為它不像短輪詢一樣會很快釋放掉連接。
它們的共同的缺點是，每一次請求和響應，處理處理真正有用的數據，服務器和客戶端還要交換一堆請求頭，響應頭等東西，信息交換的效率不高。事實上可以說，長輪詢是一種偽長連接，它還是需要遵循http連接的規則：客戶端請求--服務器響應--釋放連接，順便交換了一些相同的無用的信息。（造成帶寬浪費）
websocket的原理網上有很多人也介紹了，簡單來說，它就是html5中的一種協議，我的理解是，他是對html的長連接的一種升級。你也可以將它理解成一種長連接。只不過這種長連接相對於方案2的長輪詢有以下優越之處。
1.首先，websocket連接只需要建立一次，在第一次連接的時候，客戶端和服務器會交換必要的信息，如下所示。
可以看到，websocket連接成功后返回的狀態碼是101.在請求頭處，傳遞過來的connection類型是keep_alive，upgrade。也就是說是keep_alive的升級版。首先keep_alive是屬於http1.1協議的范疇。大概的意思就是，在http1.0時代，我建立一個連接就是對應一次request--response的過程。而在1.1時代，新增加了keep-alive，我們可以保持這個連接的生命周期（可以通過nginx等服務器設置keepalive-timeout這個參數來實現），這樣做的好處是可以自定義一個連接的存活時間，使得一個連接可以處理多個請求，而不是單單一次請求。設置了keepalive-timeout以后，當一個請求結束以后，我們在等keepalive-timeout這么長的時間，如果沒有新的請求，就關閉這個連接。
說到http1.1，我們來看一個http的連接的請求頭和響應頭。
看到了吧，不一樣的地方就在於那個upgrade。所以我們可以這么說，websocket也是一個長連接。但是因為它是升級版，所以它有個好處，就是它只需要建立一次連接，傳遞一次必要的請求頭和響應頭信息，之后再傳遞數據的時候就不需要在交換這些信息了。節省了帶寬。
2.websocket是雙向的，這也是他跟另外兩種方法最大的不同，不管是ajax還是長輪詢，他們都是通過客戶端發送請求，服務器響應的形式完成信息的交換，這種模式下服務器處於一種被動的角色。而websocket不存在這個問題，websocket的鏈接一旦建立，服務器和客戶端都可以互推信息。
有了這兩個優點，在做一些需要即時通信的功能時候，我們首選就是用websocket。