RealTime Web: WebSocket

a simple description of WebSocket via Node.js

Transcript

1. RealTime Web OMG! RealTime
2. Chapter 1 : WebSocket Revolution
3. RealTime 之路 • HTTP • HTTP （ with Cookies ， Session ）
4. HTTP Core of the web 在 B/S 的 web 架构模型中， 每次打开一个网页，浏览器都 至少发起一次 HTTP 请求去 从指定网络位置获取资源。
5. HTTP • 无状态协议： HTTP 协议对于事物处理没有 记忆能力。 • 无状态服务器： HTTP 服务器认为每一请求与 之前任何请求都无关。 • 通常 HTTP 请求是短连接
6. HTTP 由于这种服务器并不知道客户端是什么状态， 这就需要在每个请求上额外附加一些必要的标识信息， 即客户端的状态信息： + Cookies ：用客户端保持状态信息 + Session ：用服务器保持状态信息 Client——>Server
7. Client pull F5 ，泥妹的够了 *_* • Ajax （ client pull ） • JSONP （ cross domain ）
8. Issues 1. But ！ 要是我想在网页中一边浏览之前的新闻一边获取最新的消息？ 和小伙伴讨论刚刚看到的新鲜事？ 或者玩玩网页游戏？ 再或者跟机油视频聊天？ 若是炒股的想看看实时的股票行情？若是实时刷微博？…… 别想了，光靠一次简单的 HTTP 请求是绝对不够的！！ ！
9. Server push (Comet) • 轮询 • 长轮询 • 长连接
10. 蛋疼的历史… 在 HTML5 平台出现之前， 开发人员通常需要使用这些技术来实现服务器推送（ push ）： “ 轮询”、“长轮询”、“长连接” 也就是说， 要想实现服务器推，全靠 hacking 得来 !
11. 轮询工作： 在 Client 端 用计时器和 XMLHttpRequest 不断 的向 Server 端 发出请 求 。 长轮询—————— >>>
12. 所谓的长连接 也是在 HTML 页面里 添加指向请求地址的 隐藏域 iframe 标签 , 以达到保 持浏览器 & 服务器 的持续连接状态。
13. Issues 2. • 轮询会产生过多无效的请求 • 长轮询会消耗系统资源，不仅增大 Server 的开销，且很麻烦 • iframe 实现的长连接导致网页永远处于加载状态 • 蛋疼的同源策略
14. later… 这种状况一直持续到 HTML5 新标准出现。 在新的标准中，可以通过 EventSource 实现服务器推的 comet 技 术， web 开发者终于不用再费尽心思的 hack 了～
15. Issues 3. 但是无论怎样，这些所谓的 RealTime 都是单向连接，同一时刻只 能允许设备之间的单向通信。 或者说这些方法实现的通信属于“ half duplex” （半双工）
16. OMG! WebSocket! 直到这货诞生…… “ 将 TCP 的 Socket 与无状态的 HTTP 协议共同使用， 从而使通信双方建立起一个保持在活动状态的连接通道， 并且通信属于‘ full duplex （全双工）’”。 ————from Wikipedia
17. 设计哲学 • Minimum data • Frame • TCP • NameSpace • share port with HTTP Server
18. TCP or HTTP ? WebSocket 是基于 TCP 的独立的协议。 和 HTTP 的唯一关联就是 : HTTP 服务器需要把 WebSocket Client 发出的握手动作升级为 “ Upgrade” 请求并进行解析。 WebSocket 也属于长连接
19. Advance 不受同源策略限制 更快、更强、更专业，做到了真正的 RealTime 通信 传输数据量最小化
20. How does it works? Hand shake, first （ Via HTTP ）
21. Hand Shake 1 客户端请求头 : Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: ************==
22. Hand Shake 2 “Sec-WebSocket-Key” 字段 它是个经过 base64 编码的随机字符串，在握手过程中特重要： 当 Server 接收到来自浏览器的“ upgrade” 请求时，便会将请求 中的“ Sec-WebSocket-Key” 字段提取出来，追加一个固定 字符串“ 258EAFA5-E914-47DA-95CA-C5AB0DC85B11” ， 同时进行 SHA-1 加密，然后再次经过 base64 编码，生成一个新 的 KEY ， 作为响应头中的“ Sec-WebSocket-Accept” 字段的内容返回 给浏览器：
23. Hand Shake 3 服务器响应头 : HTTP/1.1 101 Switching Protocols Upgrade ： websocket Connnection: Upgrade Sec-WebSocket-Accept: ******
24. Frame WebSocket 传输的数据都是以 Frame （帧）的形式存在的， 就像 TCP/UDP 协议中的报文段 Segment WebSocket 协议是基于 Frame 而非 Stream 的。 每个 Frame 都定义了严格的数据结构，因此所有的信息就在这个 Frame 载体中。
25. Frame
26. Masking key Masking-key （掩码）如果存在，则一定是一个 32bit 的值。 如果消息是从客户端发送到服务器，那么 mask 一定是 1 。 如果是从服务器发送到客户端， mask 为 0 。 作用：当 mask 字段的值为 1 时， payload-data 字段的数据需要 经这个掩码进行解密。
27. Decode 在一个 WS 通信中，当消息到 WS 达服务器后，服务器程序就开始以 byte 为单位逐步读取这个帧。当读取到 payload-data 时，首先将数 据按 byte 依次与 Masking-key 中的 4 个 byte 按照如下算法做异或运 算： for (i = 0; i < len; i++) { j = i % 4; data[offset + i] ^= masking_key[j]; } // data ： Payload-data, len ： Payload 字节数 ; // masking_key ： 4byte 的 mask 掩码组成的数组 // offset ：跳过 Payload-data 之前的字节数
28. Chapter 2: Let's do it! We'll coding in Node.js~ that's a very cool thing~
29. Future 尽管 WebSocket 解决了 web 页面全双工通信的问题，但是一个真 正的 RealTime 互联网远不止于此。 Google 在 2010 年获得了 WebRTC 技术，这是一个允许浏览器之 间进行 P2P 通信的技术集合，利用 WebRTC 可以构建实时音频 视频等多媒体信息通信的应用程序。 不过这并不代表 WebSocket 就没有价值了。
30. Where & How In Trello In TeamChat BitCoin In BlockChain
31. V.S.
32. Principle 没有银弹
33. after 这个 Slide 已上传至 SpeakerDeck ： https://speakerdeck.com/abbshr/realtime-web-websocket-and-node demo 代码在这个 Repo 中： https://github.com/abbshr/websocket_talk 涉及到的解码和编码代码可在 Github Gist 上找到： https://gist.github.com/abbshr/7511731 https://gist.github.com/abbshr/7511762 详细学习 WebSocket ，移歩 http://abbshr.github.io/2013/11/05/new46.html 和 http://abbshr.github.io/2013/11/10/new47.html 了解 Node 底层实现（尚未完工，正在填坑），移歩 https://github.com/abbshr/abbshr.github.io/issues