為什麼會談到「即時更新」這項技術呢？

因為最普遍常見的通訊協定（protocal）是 HTTP，但他有個小小的缺點，就是只能被動的等待客戶端發起請求，才會給予回應（如下圖）

主要是因為聊天室的核心價值就在於即時更新，會這麼說的理由就是因為 HTTP 協定都是由客戶端先發送 Request 給伺服器端，伺服器端再 Response 到客戶端，也就是說客戶端沒有發送請求，自然就不會得到回應。

倘若我們的使用者小明，在使用聊天室網站時，要不斷的重新整理頁面（也就是不斷發送請求），這樣才能知道有沒有新訊息。但這樣很不合理，萬一小明在打一堆文字的時候，對方等得不耐煩，又開啟了新話題，直到重新整理頁面，小明只好刪掉剛剛輸入的一大篇文章。或者小明一直在等小美上線，卻只能守在電腦前一直重新整理頁面，殊不知小美已經進入夢鄉了。

為了要解決這個問題，衍生了幾種方法：

Polling（輪詢）

由瀏覽器定時自動向伺服器發出請求，例如每秒發送一次。缺點是整個頁面可能只為了某區塊的一則新訊息，或是根本沒有新訊息，而不斷的請求資料，這樣的方式實在很消耗的頻寬和伺服器資源。簡單來說就是瀏覽器替小明不斷執行重新整理。

Long Polling (長輪詢)

伺服器收到瀏覽器送出的請求後，伺服器會等一段時間，若在這段時間裡有新的訊息，伺服器就會把最新的訊息回應給瀏覽器，萬一等待的時間到了還是沒有新訊息的話，就會送一個回應給瀏覽器，告訴瀏覽器沒有任何更新。
這樣的方式可以減少傳統輪詢浪費資源的狀況，卻也沒有達到即時更新的要求，甚至長時間的等待，累積大量資源的狀況下，造成連續的輪詢問題！
就像小明打電話給小美，聊天聊到半夜，小美不小心睡著了，而小明非得等到小美跟他說一聲晚安，才肯掛掉電話去睡覺。等到不到小美，卻等到媽媽起床上個廁所，發現小明的房間還亮著，斥罵小明不要再講電話趕緊睡覺，小明才甘願掛掉電話。

參考資料：
維基百科
WebSocket 通訊協定簡介：比較 Polling、Long-Polling 與 Streaming 的運作原理
Websocket解析及實現

學無止盡，每天都要進步一點點！