分类: Html/Css
2017-02-07 16:47:31
WebSocket 由来已久, 常用于 "服务器推" 场景。最近开始学习 WebSocket (从 tomcat examples 开始), 本文的主要目的是做学习笔记, 同时记录一份开发指南。
本文示例代码见:
我们先来看看 HTTP。
一次 HTTP 请求过程如下:
客户端 | 服务器 | |
---|---|---|
1. | 客户端建立到服务器的 TCP 连接 | |
2. | 客户端发送请求 | |
3. | 客户端等待响应 | |
4. | 服务器收到请求 | |
5. | 服务器发送响应 | |
6. | 客户端收到响应 | |
7. | 请求结束 |
TCP 连接是支持双向同时读写的全双工协议, 但是我们看传统的 HTTP 协议有几个问题:
也就是说, 传统的 HTTP 1.0/1.1 协议没有充分利用 TCP 连接的能力.
HTTP 协议这样的设计主要是简化了编程模型, 想一想传统的 CGI 脚本, 一个脚本只要能够接受输入, 产生输出, 就可以提供 web 服务。HTTP 协议缺少 ISO 7 层网络模型中的会话层, 动态 web 应用使用 cookie 来保存会话信息。HTTP/1.1 默认开启长连接来优化性能, 但 HTTP 连接和请求依然是无状态的。对传统提供静态内容服务, 或返回信息相对确定的 web 应用而言, 这样的设计并没有问题, 或者说虽然有一些不足, 但尚能忍受。无状态的设计也简化了 HTTP 测试, 日志回放也成为重要的 HTTP 服务测试手段之一。
直到 "服务器推" 场景的出现。服务器端信息随时可能变化, 我们希望将变化后最新的信息立即通知给客户端。传统的解决方案是客户端不断轮询服务器, 如每秒 1 次。这种轮询将产生许多额外的代价, 包括移动端流量收费, 并且编程模型也相对复杂。因此, 是时候开放 TCP 双向通信的能力了。我们可以重新写一个 TCP 服务器, 使用新的协议来通信。但也许是为了复用 HTTP 的 80 端口, 依附现有 HTTP 生态圈, 让 web 应用平滑升级, websocket 基于 HTTP 协议设计, 顾名思义就是基于 web HTTP 协议, 释放原生 TCP socket 的能力。所以 websocket 一开始还是按 HTTP 协议通信, 随后才转换成 websocket。
一个 websocket 连接的建立过程如下:
客户端 | 服务器 | |
---|---|---|
1. | 客户端建立到服务器的 TCP 连接 | |
2. | 客户端请求将当前 TCP 连接用作 websocket | |
3. | 服务器收到请求, 同意并确认将此 TCP 连接用作 websocket | |
4. | 客户端收到确认, HTTP 协议通信结束 | |
5. | 双方使用 websocket 协议自由双向通信 |
websocket 可基于 HTTP 建立, 即 ws 协议, 也可基于 HTTPS 建立, 即 wss 协议, 果然是复用了 HTTP 的基础设施。
HTTP 客户端发送完请求后才会监听响应, 收到一次响应后即结束。常见的 HTTP 客户端有:
浏览器 js 客户端, 如 angularjs 的 $http 服务.
$http.get("/http").then(function(resp) {
vm.msg = resp.data;
});
直接在浏览器输入 URL.
回顾 "服务器推" 场景, websocket 与 HTTP 协议最大的不同在于服务器不必等待请求, 也不再使用 "请求", "响应" 这样的术语, 而改称为消息, 双方都可以随时互发消息。HTTP 客户端不会一直监听消息, 所以显然不能作为 websocket 客户端 (且不说协议是否兼容)。要使用 websocket, 客户端和服务器都需要改造。常见的 websocket 客户端有:
浏览器 js 客户端。感谢浏览器厂商, 现在的主流浏览器都支持 websocket 。