Study notes for server push.
- 在 Client Request 後,與 Server 保持持久連結,以方便 Server 在連結期間主動傳遞資料。
- Long-Polling:延後 Server Response 的時間,利用這段延遲來減少 Request 數量。適用於資料更新不頻繁的場合。實作技術:AJAX / Script tag。
- HTTP Streaming:連結後使用串流模式傳遞資料,Client 可在連結期間不斷接收 Server 資料,直到 Server 傳遞結束。實作技術:iframe / AJAX / SSE。可能因 proxy 或防火牆的資料緩存機制,造成資料回應上的延遲。
- 伺服器端可實作非同步回應,來處理資源佔據的效能問題。
Reference
- 傳統的 Request / Response 機制為有限長度的傳輸,並在傳輸完成後才對整塊完整資料進行處理。Streaming 的概念是不限定長度,將資料分塊傳輸並即時處理,使得總傳輸量可超過接收方的記憶體容量限制。
- 分塊傳輸的概念適用於 Request 與 Response。Request streaming 對上傳檔案特別有用,但實務上支援此功能的 server 不多。
- HTTP/1.1:「Transfer-Encoding: chunked」;HTTP/2:不須額外設定(IE11 部分支援)
- 若資料非連續傳輸,須注意 timeout 問題(後端可能須用特定方式 output stream,前端如用 AJAX 則可設定 timeout=0)
- 實作面最大的問題在於 buffering;一次請求回應所流經的所有 Client / Server 都有各自的 buffering 機制與限制。若要 streaming 正確運作,一般不是把預設的 buffering 機制關閉,就是將 buffer size 設定成與 chunk size 相同。
- 瀏覽器在開始解析 Response 資料以前,有個資料接收的 buffer 限制。每個瀏覽器的 buffer 限制不同,通常為 1KB。
- 資料分塊愈多,切割與解析的成本就愈高。另外若接收方無法立刻處理資料,則資料緩衝的成本與複雜度也會提高。
Reference
- 此技術主要也是應用於大型資料傳輸上
- 如何運用 AJAX 在後端以串流回傳資料的同時,同步進行處理
- Oboe.js & Highland.js 可幫助處理 JSON 串流資料,兩者都適用於 Node Server 和 Client Browser
- NodeJS 對 streaming 的支援性相當好。
Reference
影音類多媒體串流,使得客戶端得以:
- 一邊下載一邊播放,
- 跳至指定位置下載並播放。
Reference
- 最新實作 HTTP Streaming 的 HTML5 API。類似訂閱機制:瀏覽器透過 SSE 來向 Server 訂閱一個資料來源;一旦有更新時,Server 即會主動通知瀏覽器。
- 與 WebSocket 相似,但為 Server > Client 單向。具備 WebSocket 所沒有的特性:自動重新連線、事件 ID、傳送任意事件。
- IE / Edge 不支援
- SSE 定義了一些特別的資料傳輸格式,所有要從伺服器透過 SSE 傳輸的資料都要符合它所定義的格式:「data: ... \n\n」。
- 安全性:在使用 SSE 接收訊息時,應該要檢查訊息中的 e.origin 是否跟應用程式正確的來源相符合。
Reference
- 主要用於 Server 主動推送該網頁所需的其他資源,比較像是 preload 的概念。
- 需 Server 支援實作。需在 Server 端預先定義好須主動推送哪些資源,這也代表所有資源須在同一台 Server 上。
- 若瀏覽器已存在該資源的緩存,反而浪費資源。因此一般只針對第一次訪問的使用者進行 Server Push。
Reference
- OSI Model
- HTTP 3-way handshake
Reference
- HTTP/1.1 可並行請求資源,但 TCP 三方交握成本仍高,請並行數量有上限。HTTP/1.1 keep-alive 能減少交握,但需串行。HTTP/2 Multiplexing 可解決上述問題。
- Request / Response 能在同一個 TCP 連線中:a) 多個打散並行傳輸、b) 兩者並行傳輸。
- 過去的網站載入優化處理在此架構下可能變得不再適用(例如:將資源壓成一包來降低 Request 數量。)
Reference
- 全雙工傳輸
- 網路頻寬與延遲都比 HTTP 協定小很多
- 各大瀏覽器支援良好(IE10+ 支援)
- Client 端實作相對簡單;Server 端亦須支援 WebSocket
Reference
- 無論是傳輸時間、資料大小,或每秒請求數,WebSocket 都有絕對的優勢,而這在傳輸頻繁、Server 同時連線 loading 重的情境下尤其明顯。
- 建立 WebSocket 連線需耗時 ~190ms,在多數情況下不會造成嚴重的 overhead。
- HTTP 的優勢:可快取、資料安全一致性高、錯誤處理情境支援性高,適合同步事件處理。
Reference
Reference
- Server / Proxy 可能會有預設的閒置自動關閉連線設定。
- Client 端需自行設定排程來實作 timeout 機制 / 斷線自動重連。
Reference
- WebSocket 使用 PING/PONG 訊息傳遞機制來保持連線:由 Server 傳送 PING 給 Client,Client 再回應 PONG。若 Client 無回應,則 Server 自動關閉連線。
- WebSocket API 目前不支援由 Client 發起 PING/PONG。雖然瀏覽器可能自行實作發起 PING/PONG,但大部分的 PING/PONG 是由 Server 發起的。
- PING/PONG 機制的實作方式視瀏覽器和 Server 而有所不同。可自訂方法來自行實作。
- PING/PONG 的間隔最好小於 30 秒,因為在各個環境中(Chrome / Firefox WebSocket Idle Timeout、TCP Timeout)許多超時的實作設定是 30 秒。20 秒是個不錯的選擇。
Reference
- 主要用於 Server - Server 之間的訂閱通知回呼機制
- 使用 HTTP 協定
- 無法跨防火牆或在瀏覽器中使用
Reference
- 各種實現 Server Push 的方式
- 各方式的優劣比較
- 需求分析
Link
- Server Push | Google Slide
- Medium