hello websocket(cn)
TRANSCRIPT
<html5>
<figure>WebSocket</figure>
<a href='mailto:[email protected]'>leonguo</a>
<time>2010.10</time>
</html5>
• 当前 Web 应用面临的一些需求
• 现阶段采用的一些解决方案及不足
• 拯救 (html5 WebSocket)
• 立即尝试
• 一些不得不考虑的问题 (proxy/firewall etc.)
• Q&A
Agenda
• 越来越多的 web 应用需要实时的，或者尽可能低延时的
更新
• 不仅仅是广播，也需要双向互动
• Examples:
– Gmail/gtalk
– 在线股票信息
– SNS
– 在线游戏
• 如何构建一个实时的、全双工的 web 应用？
Today’s Requirements
Traditional C/S Architecture
full duplex && more powerful
HTTP Is Not Full Duplex
• 当初 http 协议是被设计用于文档传输的
• 一直以来，http 都在严格遵循 request-response
模型
• 至今，它已经成为构建复杂互动 web 应用的巨大拖累
• http 工作在半双工模式，任一时刻数据只能由一端流向另
一端
• header information 会在每次请求、回应中携带，尽管它
常常是不必要的。
• 简而言之，http 不是为实时的、全双工通信设计的
About HTTP
• 著名洁厕品牌
• Ajax(Asynchronous JavaScript and XML) 用于创建改善
的交互式 web 应用
– 局部更新内容而不需要刷新整个页面
– 相对较低的延迟
• Comet(Reverse Ajax) 实时
往往通过轮询或长轮询实现
– 缺乏一个统一的规范、标准
– 实现复杂
About Ajax and Comet
Half-Duplex Architecture
• 轮询用以实现 “近似实时”
• 用在 Ajax 应用以仿真实时通信
• 浏览器定期发送 Http 请求，并即刻获取响应
• 在消息比较“稀疏”时，很多资源(网络、计算、存储)被浪费
了
Polling
Polling Architecture
• 也称为异步轮询
• 客户端发起连接，服务端保持连接开放直至有数据输出或
连接过期
• 和 polling 一样，http headers 很有可能占据了大部分比重
的网络流量
• 消息较“密集”时，long polling 比 polling 没有任何改善甚
至可能会出现更糟的情况
Long Polling
Long Polling Architecture
Streaming
• 更有效率，但还是很多问题…
• 可能的“并发症”:
－ 代理与防火墙
－ 跨域问题与浏览器连接限制
－ 缺乏标准，浏览器实现兼容问题
Streaming Architecture
A Comet Demo
HTTP Request Headers
HTTP Response Headers
HTTP Header Traffic Analysis
• HTTP request and response header information
开销高达: 3253 + 290 = 3543 byte(club online example)
• 大量本非必须的头信息在轮询中消耗了巨大的网络吞吐：
– Use case One: 10,000 clients polling every second:
• Network throughput is (3543 x 10,000) = 35,430,000 bytes =
2,834,400,000 bits per second (~270 Mbps)
• 浪费的远不仅仅只是带宽，每一个连接的代价都是高昂的
Comet-3rd plugin
Complexity does not scale
低效 && 繁杂
Enter HTML5 WebSocket!
• 规范 (W3C API and IETF Protocol)
• 使页面和后端服务器直接通信成为现实
• 建立于 TCP/IP 之上的全双工通信模型
– 更低的消耗、延迟
– 可以方便的进行协议扩充
• 采用与 http 兼容的握手机制，所以可以共享标准的 HTTP
端口(80/443)，不需要安装新硬件、或者要求开放新的端
口
• 文本、二进制支持
HTML5 WebSocket
Possible WebSocket Architecture
• WebSocket
– ws://localhost:8000/echo
• WebSocketSecure
– wss://localhost:8000/encrypted-echo
HTML5 WebSocket Schemes
• WebSocket 会重用被升级的 Http 所建立的 TCP 连接
• 一旦升级完成，WebSocket 数据帧就可以在服务端和客户
端以全双工模式传输，在任一时刻流向任意方向
HTML5 WebSocket
HTML5 WebSocket Handshake
GET /text HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: localhost
Origin: http://localhost
WebSocket-Protocol: sample
…
Client
HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://localhost
WebSocket-Location: ws://localhost:8000/echo
WebSocket-Protocol: sample
…
Server
• Each frame of data:
– Starts with a 0x00 byte and End with a 0xFF byte
– Contains UTF-8 data in between
• 异步 socket 编程模型
• Example:
– \x00Hello, WebSocket\0xff
• 没有最大长度限制
– JavaScript 不支持超过 4GB 的数据
HTML5 WebSocket (Text)Frames
Using the WebSocket API
Checking For Browser Support
JavaScript
//Checking for browser support
if (window.WebSocket) {
//…
} else {
//…
}
Using the WebSocket API
JavaScript
// Create new WebSocket
var s = new WebSocket("ws:/localhost:8000/echo");
// Associate listeners
s.onopen = function(evt) {
alert("Connection open...");
};
s.onmessage = function(evt) {
alert("Received message: " + evt.data);
};
s.onclose = function(evt) {
alert("Connection closed...");
};
Using the WebSocket API
// Sending data
s.send("HTML5 WebSocket Rocks!");
//Close WebSocket
s.close();
JavaScript
Browser Support for WebSocket
http://www.findmebyip.com/litmus#target-selector
• Flash WebSocket implementation
– http://github.com/gimite/web-socket-js
– Requires opening port on the server’s firewall
• Kaazing WebSocket Gateway
– http://www.kaazing.com/download
– Makes WebSocket work in all browsers today (including I.E. 6)
Use it now
A toy demo - Server
A toy demo - Client
• 大幅减少了不必要的网络流量和延时
• 全双工，无需等待
• 没有因为从 HTTP 升级为 WS(S) 建立新 TCP 连接而引入
新的延时
• 每帧数据最少只有两个字节，相比 HTTP 有thousands:1
的减少
– Use case One: 10,000 clients receive 1 message by html5
WebSocket every second:
• Network throughput is (2 x 10,000) = 20,000 bytes = 160,000 bits per second
(~0.153 Mbps)
WebSocket Traffic Analysis
Polling vs. WebSocket
0.00
5,000,000,000.00
10,000,000,000.00
15,000,000,000.00
20,000,000,000.00
25,000,000,000.00
30,000,000,000.00
polling websocket
bits per second(online.club)
bps
Latency Reduction
No sliver bullet
• WebSocket 很简洁，另一方面，WebSocket 基本没有实
现可靠性的功能
– 没有连接自动重建
– 没有保证消息传递成功机制(Like Server-Sent Event)
– 不基于 HTTP 的，所以也无法利用 HTTP 内建的可靠性特性
– 需要我们来做(应用、子协议)，如发送“维持通信”消息，避免被关
闭等
• 多个页面连接共享
– WebSocket 包含一个难以共享的上游管道
– 并发同步问题
Cross Domain
• WebSocket 本身并没有跨域的限制
• 但浏览器限制客户端的编程语言(如 JavaScript)连接到跨
域服务器，所以 web 页面上以 JS 发起的 WebSocket 无
法穿越浏览器的安全界限
• WebSocket-Origin header 是 WebSocket 协议的必选字
段，包含在其升级请求中，可以在服务端以白名单方式做
出限制
• 一旦建立了 WebSocket 连接，即可以直接和后端服务
器、数据源、消息代理通信
• 在 web 上肆意的实现、括展你感兴趣的 c/s 协议:
– XMPP (Jabber)
– Pub/Sub (Stomp/AMQP)
– Gaming protocols
– Any TCP-based protocol
– …
• 企业开发
Beyond WebSocket
• WSS 是 WS 由 TLS(Transport Layer Security)支持完成的
– TLS 前身为 SSL(Secure Socket Layer), https 就是建立在 SSL 基
础之上
• WSS 连接建立于已经完成 TLS 握手(使用公共和私有密钥
证书)成功之后的 HTTP(S) 连接升级
Securing WebSocket Traffic
• 没有任何中介服务器时，只要C/S 双方了解网络套接字协
议 WebSocket 就可以顺利连接，但在真实环境中，存在
着大量的中间设备
• 虽然 WS(S) 协议本身并不知晓代理服务器和防火墙
• 但 WS(S) 可以与 HTTP 兼容握手，所以 HTTP 服务器可
以和 WebSocket 服务器共享它们的默认 HTTP 和 HTTPS
端口(80 和 443)
WebSocket and Web Intermediaries
• 代理服务器扮演了客户端和另一个服务器(如, internet 上
的一个 web server)之间的中介角色
• 通常被用作内容缓存、internet 连接、安全策略和企业内
容过滤
• 典型的模式是架设在私人网络和internet之间
• 代理服务器可以监控流量，自动断开已经打开很久看上去
闲置的连接
Proxy Servers
• 对于使用 long-lived connection (for example, Comet
HTTP streaming or HTML5 Web Sockets) 的web 应用来
说，HTTP 代理服务器有明显的问题
• 初衷是设计用来文档转移的
• 可能会选择关闭流或闲置的 WebSocket 连接，因为它们
看起来像是尝试连接一个没有回应的 HTTP 服务器
• 可能会缓存(非加密的)HTTP 响应，这将会对 HTTP 响应
流带来不可估量的延迟或异常
Http Proxy Server Problems
Types of Proxy Servers
WebSocket Proxy TraversalUnencrypted Connections
ws://
WebSocket Proxy TraversalEncrypted Connections
wss://
• TCP (Layer 4) 负载均衡路由器以与 HTML5 WebSocket
很好的工作，他们有同样的连接形式：一开始连接一次并
保持，而不是HTTP的文档转移请求--响应式的形式
• HTTP (Layer 7) 负载均衡路由器本是为 HTTP 信息流准备
的，因此很容易会被 WebSocket 升级信息所迷惑。所以
需要被配置为能明确感知 WebSocket 信息流
Load Balancing Routers
Firewalls
• 对于普通的 socket 连接，必须在防火墙上开放一个端口，
所以采用仿真的，但因为 WebSocket 共用了普通的
HTTP(S) 端口，所以不需要额外配置
• 因为防火墙通常是在对进入的流量控制和出去的流量路由
上加上规则(比如，通过代理服务器)因此通常来说没有对
于 WebSocket 信息流相关的防火墙顾虑
• 全双工通信
• 更低的消耗与延迟
• 简洁(标准、API)
• 使用仿真、使用安全连接(WSS)
Review
Q&A
THANKS