WebSocket作為在HTTP下一個很重要的雙向通信延伸的protocol，HTTP 1.0/1.1的設計是half-duplex，也就是同一個時間只會有單向傳輸(request->response)，雖然HTTP 1.1有支援http pipelining，但本質上他還是單向傳輸的的架構(第二個request不用等到第一個response收到就可以發出，但是response order還是根據request)，並且這項功能在大部分的client/server實作不完整 WebSocket出現於2009年左右(並於Chrome 4開始實作支援)，在此之前要在Web上透過HTTP protocol進行雙向通信，需要用一些技巧模擬出來 因為HTTP 通信是half-duplex，從web browser client的角度，browser可以知道什麼時候要send資料，隨時可以由browser發起http request，而recv則是由server傳來的資料，但是在http request-response的架構下，因為不知道server什麼時候有資料，最簡單的做法就是要定期去polling，這個在早期的聊天室系統都是這樣處理，每隔幾秒鐘就發一次http request更新最新的內容，但是這樣做有個缺點 – 不即時 即時性的問題在後來發展出hidden iframe以及long polling兩種做法，以兩種做法解決問題主要是因為browser的限制(browser只支援單純的http request-response)，雖然在HTTP協定中其實有定義可以做雙向通信的，像是HTTP/1.1 CONNECT(主要用在tunnel proxy情境)，或是HTTP/1.1 Upgrade header，但是tunnel或是upgrade完的通信方式要由app決定。 hidden iframe的做法算是巧妙地利用browser load javascript的行為，他透過inline iframe建立起一個隱藏的iframe，在iframe裡面load一個特別的網頁，那個網頁會一直傳<script>，將要server通知的內容即時透過<script>結合javascript，在裡面嵌code和data，因為browser收到script會立即執行，並且按順序執行，透過巧妙地安排script內容，將訊息傳出來給parent page，因為網頁還沒load完，連線就會一直持續 long polling則是透過http XMLHttpRequest方式，連上server後，在沒有新的event data情況下，server就掛起連線，等有資料再response，當client收完資料後連線結束，再馬上發起新的long polling request，這個好處是可以即時的收到event data，缺點是XMLHttpRequest browser有一些限制(例如cross origin等問題)，以及每次HTTP … Continue reading WebSocket protocol整理