IOS 拾遗

WebSocket 协议初探

2019-11-13  本文已影响0人  madaoCN

前言

公司项目使用WebSocket作为主要的请求方式，知其然也要知其所以然，会用也需要知道它的基本原理，所以写此文章分享下自己的浅见，文章主要包括以下内容：

聊天Demo代码：https://github.com/madaoCN/WebsocketDemo 包含tornado写的 Server 和 Client 脚本 和 简单ws使用实例的iOS代码

WebSocket是什么

WebSocket是一种在单个TCP连接上进行全双工通信的协议，WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。WebSocket协议在2011年由IETF标准化为RFC 6455

1. 优势

WebSocket和Socket联系

Socket其实并不是一个协议，而是为了方便使用TCP或UDP而抽象出来的一层，是位于应用层和传输控制层之间的一组接口, 而WebSocket和Http一样是属于应用层协议。

TCP/IP 四层模型

当两台主机通信时，必须通过Socket连接，Socket则利用TCP/IP协议建立TCP连接。

建立连接

Websocket 握手过程复用了HTTP协议的信道，然后对服务进行升级，后续就使用Websocket协议进行通信，所以只需要一次 HTTP 握手，服务端就能一直与客户端保持通信，直到关闭连接。

一、升级请求

GET / HTTP/1.1
Host: 192.168.1.250:6767
Sec-WebSocket-Version: 13
Upgrade: websocket
Sec-WebSocket-Key: cNtBvwgrxXtqDppb/0mcMw==
Connection: Upgrade
Origin: http://192.168.1.250:6767

与HTTP报文不太一样的主要是
Connection: Upgrade : 标识要升级协议
Upgrade: websocket : 升级到 Websocket 协议
Sec-WebSocket-Version: 13 : 标明WebSocket协议的版本号
Sec-WebSocket-Key: cNtBvwgrxXtqDppb/0mcMw== 随机生成的 ，与服务端响应
Sec-WebSocket-Accept字段对应，提供基本的防护，防止恶意或者无意的连接，

二、服务端响应报文

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Sec-Websocket-Accept: hutW70GFRNI1vI45roqiU0Lu33A=
Server: TornadoServer/5.0.2
Connection: Upgrade

Sec-Websocket-Accept : 是根据客户端 Sec-WebSocket-Key 计算而来的

计算方法为：

简单的python代码验证

#coding=utf8
import hashlib
import base64

if __name__ == "__main__":
    sec_key = "cNtBvwgrxXtqDppb/0mcMw=="
    static_key = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
    contact_key = sec_key + static_key

    sha1_rt = hashlib.sha1(contact_key).digest()
    print sec_key
    print base64.encodestring(sha1_rt)
计算结果

三、抓包验证

使用WireShark对WebSocket连接过程抓包


WireShark

很直观的可以看到 HTTP三次握手 -> 升级协议 -> 使用WebSocket通信的过程

升级请求 服务端响应

Websocket升级协议报文也与上文一致，大家可以自行运行Demo代码，然后使用WireShark进行抓包验证请求过程和报文

数据帧格式

如果我们数据帧格式都不清楚的话，更遑论说了解WebSocket协议了

数据帧概览

数据帧（frame）是WebSocket通信的基本单位，一个消息由一个或者多个帧组成，内容包括标志位，操作码，掩码，数据长度等

  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 ...                |
 +---------------------------------------------------------------+

引用自 RFC 6455 - Base Framing Protocol 这个一章节

数据帧格式
*  %x0  :  表明了这个一个持续帧（continuation frame），当操作码为0时，说明使用了数据分片，该帧为数据分片中的一帧

*  %x1  ：表明了这是一个文本帧（text frame）

*  %x2  ：表明了这是一个二进制帧（binary frame）

*  %x3-7  ：保留操作码，用于后续定义的非控制帧further non-control frames）

*  %x8  ：表明了这是一个关闭操作码

*  %x9  ：表明了这是一个ping操作码

*  %xA  ：表明了这是一个pong操作码

*  %xB-F ：保留操作码， 用于后续定义的控制帧（ further control frames）

表明是否要对载荷数据（Payload data）进行掩码操作，如果被置为1，那么 Masking-key 会定义一个 32位，4个字节的值，用于对载荷数据（Payload data）的反掩码操作，具体掩码的算法在后续内容中进行说明

值得注意的是，只有在客户端向服务端发送数据时，Mask才为1，而服务端向客户端发送数据时不需要进行掩码操作

客户端向服务端发送的数据都进行了掩码操作，客户端必须为发送的每一个frame选择新的掩码 (随机生成)，要求是这个掩码无法被提供数据的终端应用（即客户端）预测
备注：掩码长度不计入载荷数据（Payload data）的长度

另外，Payload length采用了网络字节序，也就是大端（big endian数据的高字节保存在内存的低地址中），大小端具体详情请看百度百科大小端模式

/**
original-octet-i为原始数据的第i字节
masking-key-octet-j为masking-key的第j个字节
transformed-octet-i为掩码计算后的第i个字节
*/
Octet i of the transformed data ("transformed-octet-i") is the XOR of
octet i of the original data ("original-octet-i") with octet at index
i modulo 4 of the masking key ("masking-key-octet-j"):

 j                   = i MOD 4
 transformed-octet-i = original-octet-i XOR masking-key-octet-j

摘抄自 RFC : Client-to-Server Masking

也就是将原始数据和masking-key做异或操作(异或的位数 j = i mode 4)，获得的就是转换后的结果

发送数据

WebSocket根据opcode操作码来区分操作类型，%x0 %x1 %x2 代表了数据交互帧

特别的操作码%x0 代表使用了数据分片，消息可能被切分成多个数据帧，笔者发现 tornado 和 SocketRocket 并没有实现数据分片，这里就暂不深入讨论，详情请参考 RFC: Fragmentation

存活心跳ping 和 pong

一旦建立与服务器的连接，客户端和服务端都可以发起一个ping请求，当接收到一个ping请求，那么接收端必须要尽快回复pong请求，通过这种方式，来确认对方是否存活，确保客户端、服务端之间的TCP通道保持连接没有断开

ping, pong操作码分别为 %x9 %xA

断开连接

客户端和服务端都可以通过发送带有特殊控制序列%x8的数据帧来发起断开连接，一旦某一端收到该帧，需要也响应一个断开帧，之后主动断开的那端便可以关闭连接了，之前提到过Websocket 握手过程复用了HTTP协议的信道，那么很自然的，断开连接期间也经历了四次挥手的过程

Sec-WebSocket-Key/Accept的作用

Sec-WebSocket-Key/Sec-WebSocket-Accept 的算法都是公开的，而且也不复杂，仅仅是提供一些基础防护，防止一些意外链接，和恶意链接

WebSocket协议：5分钟从入门到精通
中已经写得很详细，这边就不做详细探究

数据掩码的作用

随着websocket协议被开发出来，一项针对代理服务器的攻击（污染那些广泛部署的缓存代理服务器）实验也开始进行。
一般形式的攻击是跟被攻击者控制的服务器建立连接，并构造一个类似WebSocket握手一样的UPGRADE请求，随后通过UPGRADE建立的连接发送看起来就像GET请求的frame去获取一个已知资源（在攻击场景中可能是一个点击跟踪脚本或广告服务网络中的资源）
之后远程服务器会返回某些东西，就像对于这个伪造GET请求的响应，并且这个响应会被很多广泛部署的网络中间设备缓存，从而达到了污染缓存服务器的目的。对于这个攻击的产生的效应，可能一个用户被诱导访问受攻击者操控的服务器，攻击者就有可能污染这个用户以及其他共享相同缓存服务用户的缓存服务器，并跨域执行恶意脚本，破坏web安全模型

总结一下，掩码的作用很重要两点就是 防止攻击者获知网络链路中传输的原始数据 和 避免缓存

参考：

RFC6455
WebSocket协议：5分钟从入门到精通
WebSocket协议中Masking Key有什么用？

上一篇 下一篇

猜你喜欢

热点阅读