背景知識

HTTP 1.0

• 每一次 HTTP 連線都建立一次 TCP 連線
  • 視實作方法而存在差異
• 利用 HTTP Header 進行持久連線
  • Connection: Keep-Alive

HTTP 1.1

• 持久連線成為預設

XMLHttpRequest

• 原理
  • 客戶端部份 Request
  • 伺服端部份 Response
• 優勢
  • 資料量大幅減少
• 劣勢
  • 畫面需重新渲染

WebSocket 介紹

WebSocket

• RFC 6455、RFC 7936
• 單個 TCP 連線上的全雙工通訊協定
• 常與 HTTP 協定進行組合使用

// Client Request

Connection:Upgrade
Host:echo.websocket.org
Origin:http://websocket.org
Sec-WebSocket-Key:ov0xgaSDKDbFH7uZ1o+nSw==
Sec-WebSocket-Version:13
Upgrade:websocket 

Client Request

// Server Response

HTTP/1.1 101 Switching Protocols
Connection:Upgrade
Date:Sun, 29 Jan 2012 18:05:49 GMT
Sec-WebSocket-Accept:7vI97qQ5QRxq6lD6E5RRX36mOBc=
Server:jetty
Upgrade:websocket

Server Response

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
     |N|V|V|V|       |S|             |   (if payload len==126/127)   |
     | |1|2|3|       |K|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |Masking-key, if MASK set to 1  |
     +-------------------------------+-------------------------------+
     | Masking-key (continued)       |          Payload Data         |
     +-------------------------------- - - - - - - - - - - - - - - - +
     :                     Payload Data continued ...                :
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                     Payload Data continued ...                |
     +---------------------------------------------------------------+

 

WS Payload

WebSocket

• 優勢
  • Payload Header 小
  • 全雙工通訊
• 劣勢
  • 大量連線會耗費 CPU 資源

實驗環境設計

Server

• echo service on WebSocket
• 接收 Ping，回傳 Pong
• 接收與回傳都是 JSON 格式資料
  • 包含 Timestamp

// Request
{
    "data": "ping",
    "timestamp": 1478246460,
}

// Response
{
    "data": "pong",
    "timestamp": 1478246461,
}

Client

• 通常使用 100 個 VM Instance
• 每一個 client 最多有 1000 個平行的 socket 連接
  • 每一個 socket 都是獨立的
• 流程
  • Client 送出 ping
  • 等待伺服器回傳
  • 計算延遲
• Client 由 Client Master 控制

Client Master

• 作用
  • 控制 Clients
  • 收集資料
• 傳送資料給 DataDog
  • DataDog：即時監測記錄端

技術決策

Hosting

• 使用 Google Cloud
  • Preemptible Virtual Machine

Languages and Packages

• 使用 Golang
  • Gorilla package
    • Github 上最受歡迎的 Golang Websocket 套件
• 以下幾個套件曾經備選
  • Node.js 的 ws 與 Socket.io
  • C++ 的 WebSocket++
  • Erlang 的 Cowboy
  • 比較結果是 C++ 與 Golang 的效能最好

Measurement Task

• 量化 Client 的資料交換效能
  • 所耗資源（Costs）
  • 延遲時間（Latency）

Performance Costs

• Server-side WebSocket is CPU-heavy
  • 建立連線
  • 接收 Ping
  • 處理接收資料
  • 回傳 Pong

實驗驗證

Client-side Measurement Errors

• 1 / 2 / 3 client(s)
• 環境
  • 每個 Client 最多 1500 個連接數
  • 每秒每個 client 新建一個連接
  • 每秒每個活躍的連接傳送一個 message

• 1500、3000 及 4500 連線數特性相近
  • 延遲是由 Client-side 造成
• 延遲時間呈線性成長
  • 1500 連線數時，最高到 90ms
• 單一 Client side 的吞吐量能夠承受 1500 連線數

Client-side Measurement Errors

實驗驗證

Requirement of Separate Connections

• 比較
  • 訊息藉由同一個 connection 傳送
  • 訊息藉由不同的 connection 傳送
• 比較方法
  • 1台 Client 開啟 100 個 connection
  • 共 10 次的訊息尖峰，每次 8 萬個 messages
  • 分成三種變化
    • 8萬 connections（1 message/connection）
    • 4萬 connections（2 messages/connection）
    • 2萬 connections（4 messages/connection）

Requirement of Separate Connections

• 當 connection 數較少
  • 訊息的瞬間吞吐量較大
• 驗證使用單獨 connection 的必要性

實驗驗證

Validation of Multiple Connections per Client

• 內容
  • connection 總數最大為 5 萬
  • 每秒建立 100 個新的 connection
  • 每個活躍的 connection 每秒傳送一個 message
• 比較
  • 訊息經由 50 個 instance 傳送
    • 單一 instance 最多 1000 個 connections
  • 訊息經由 100 個 instance 傳送
    • 單一 instance 最多 500 個 connections

Validation of Multiple Connections per Client

• 80 秒左右達到 Server 最大吞吐量
  • 限制建立新的 connection
  • 訊息開始產生延遲
• 100 個 instance 的效率略大於 50 個 instance
  • 可能是 WebSocket 協定或實作產生的誤差
  • 忽略不計
• 故可得：
  • 在相同連線數的情況下 100 個 instance 的效能與 50 個 instance 的效能差不多