从http到websocket

已于 2024-07-21 23:42:37 修改
阅读量1.2k 收藏 24
点赞数 15
分类专栏： 计算机网络 文章标签： http websocket 网络协议
于 2024-03-01 17:50:14 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/roadtohacker/article/details/135724442
版权

阅读本文之前，你最好已经做过一些websocket的简单应用

从http到websocket

HTTP101

  • 在HTTP/1.0中，每个服务器请求需要一个单独的链接，这种方法至少可以说没有太好的伸缩性。在HTTP的下一个修订版本，也就是HTTP/1.1中增加了可重用连接。由于可重用连接的推出，浏览器可以初始化一个到web服务器的连接，以读取HTML页面，然后重用该连接读取图片、脚本等资源。HTTP/1.1通过减少客户端到服务器的连接数量，降低了请求的延迟
  • HTTP是无状态的，也就是说，它将每个请求当成唯一和独立的。无状态协议具有一些优势，例如，服务器不需要保存有关会话的信息，从而不需要存储数据。但是这也意味着在每次HTTP请求和响应中都会发送关于请求的冗余信息
  • 从根本上讲，HTTP还是半双工的协议，也就是说，在同一时刻，流量只能单向流动：客户端向服务器发送请求，然后服务器响应请求。之后出现了轮询、长轮询和HTTP流化(streaming)等技术

HTTP 轮询、长轮询和流化

  • 很多提供实时web应用程序的尝试多半是围绕轮询(polling)技术进行的，这是一种定时的同步调用，客户端向服务器发送请求查看是否有可用的新信息。请求以固定的时间间隔发出，不管是否有信息，客户端都会得到响应：如果有可用信息，服务器发送这些信息，否则服务器返回一个拒绝响应，客户端关闭连接，这种技术的问题在于我们无法事先预知信息交付的精确间隔，从而导致打开或者关闭很多不必要的连接
  • 长轮询(long polling)是另一种流行的通信方法，客户端向服务器请求信息，并且在设定的时间段内打开一个连接。服务器如果没有任何信息，会保持请求打开，直到有客户端可用的信息，或者直到指定的超时时间用完为止。这时，客户端重新向服务器请求信息。长轮询也称作Comet或者反向AJAX。Comet延长HTTP响应的完成，直到服务器有需要发送给客户端的内容，这种技术常常称作“挂起GET”或“搁置POST”。但是当信息量很大的时候，长轮询相对于传统轮询并没有明显的性能优势，因为客户端必须频繁的重连到服务器以读取新信息，造成网络的表现和快速轮询相同。长轮询的另一个问题是缺乏标准实现
  • 在流化技术中，客户端发送一个请求，服务器发送并维护一个持续更新和保持打开（可以是无限或者规定的时间段）的开放响应。每当服务器有需要交付给客户端的信息时，它就更新响应。似乎这是一种能够适应不可预测的信息交付的极佳方案，但是服务器从不发出完成HTTP响应的请求，从而使连接一直保持打开。在这种情况下，代理和防火墙可能缓存响应，导致信息交付的延迟增加。因此，许多流化的尝试对于存在防火墙和代理的网络时不友好的
  • 上述几种方法还有一些问题，例如冗余的HTTP首标数据和延迟、客户端必须等待请求返回才能发出后续的请求，这会显著增加延迟

其他技术

1. 服务器发送事件

  • 如果你的服务主要向其客户端广播或者推送消息，而不需要任何交互，可能使用服务器发送事件(Server-Sent Events SSE)提供的EventSource API是个好的选择。SSE是HTML5规范的一部分，加强了某些Comet技术，可以将SSE当作一种HTTP轮询、长轮询和流化的公用可互操作语法使用。利用SSE，你可以得到自动重连、事件ID等功能，但是这种方式只支持文本数据

2. SPDY

  • SPDY(音同"Speedy")是Google开发的一种网络协议，本质上扩充了HTTP协议，通过压缩HTTP首标和多路复用等手段改进HTTP请求性能，也就是说，它相当于对于HTTP进行的增量改进，改正了许多HTTP的非本质问题，增加了多路复用、工作管道(working pipling)和其他有用的改进。而websocket与HTTP之间的不同是架构性的，不是增量的，可以将SPDY扩充的HTTP连接升级为Websocket，从而在两个领域获得利益

3. web实时通信

  • 这是一种浏览器之间的点对点技术，不借助服务器传输数据，目前尚未完善

互联网简史

  • 一开始，互联网主机之间采用TCP/IP通信。在这种情况下，任意一台主机都可以建立新的连接，一旦TCP连接建立，两台主机都可以在任何时候发送数据
  • 你想在网络协议中实现的其他功能必须在传输协议基础上构建，这些更高的层次被称为应用层协议。例如，在web之前主线的用于聊天的IRC和用于远程终端访问的telnet就是两个重要的应用层协议，他们显然需要异步的双向通信，客户端必须在另一个用户发送聊天消息或者远程应用程序打印一行输出时接收到提示通知。由于这些协议一般在TCP之上运行，异步双向通信总是可用
  • TCP/IP还是http和websocket协议的基础，我们先简单介绍一下http协议

web和http

  • 1991年，万维网(World Wide Web)项目第一次公布。Web是使用统一资源定位符 (URL)链接的超文本文档系统。当时，URL是一个重大的发明。URL的U是universal(统一)的缩写，说明了当时的一个革命性想法 ，所有超文本文档的相互连接。Web上的HTML文档通过URL相互链接。更有意义的是，Web协议经过裁剪，用于读取资源。HTTP是一个用于文档传输的简单同步请求 — \text{---} — 响应式协议
  • 最早的web应用程序使用表单和全页刷新。每当用户提交信息，浏览器将提交一个表单并读取新页面。每当有需要显示的更新信息，用户或者浏览器必须刷新整个页面，使用HTTP读取整个资源
  • 利用JavaScript和XMLHttpRequest API，人们开发出了一组称为AJAX的技术，这项技术能够使应用程序在每次交互期间不会有不连贯的过渡。AJAX使应用程序只读取感兴趣去的资源数据，并在没有导航的情况下更新页面。AJAX使用的网络协议仍然是HTTP；尽管名为XMLHttpRequest，数据也只是有时使用XML格式，而不是始终使用该格式
  • 本质上，HTTP用其内置的文本支持、URL和HTTPS使Web成为可能，然而，在某种程度上，HTTP的流行也造成了互联网的退化。因为HTTP不需要可寻址的客户端，Web世界的寻址变成不对称的。浏览器能够通过URL寻找服务器资源，但是服务器端应用程序却无法主动的向客户端发送资源。客户端只能发起请求，而服务器只能响应未决的请求，在这个非对称的世界中，要求全双工通信的协议无法正常工作
  • 解决这一局限性的方法之一是由客户端发出HTTP请求，以防服务器有需要共享的更新。使用HTTP请求颠倒通知流程的这一过程用一个伞形术语Comet来表示。正如前面所说，Comet本质是一组利用轮询、长轮询和流化开发HTTP潜力的技术。这些技术实际上模拟了TCP的一些功能。因为同步的HTTP和这些异步应用程序之间不匹配，Comet复杂、不标准且低效

Websocket协议

1. 简介

  • Websocket是定义服务器和客户端如何通过Web通信的一种网络协议。在万维网以及其基础技术HTML、HTTP等推出之前，互联网和现在完全不同。一方面，它比现在小的多；另一方面，它实际上是一个对等网络。当时互联网主机之间通信的两个流行协议现在仍然盛行：互联网协议(Internet Protocol, IP)和传输控制协议(Transmission Control Protocol, TCP)
    ，前者负责在互联网的两台主机之间传送数据封包，后者可以看做跨越互联网，在两个端点之间可靠地双向传输字节流的一个管道。两者结合起来的TCP/IP在历史上是无数网络应用程序使用的和核心传输层协议，这种情况仍在持续
  • WebSocket为Web应用程序保留了我们所喜欢的HTTP特性(URL、HTTP安全性、更简单的基于数据模型的消息和内置的文本支持)，同时提供了其他网络架构和通信模式。和TCP一样，WebSocket是异步的，可以用作高级协议的传输层。WebSocket是消息协议、聊天、服务器通知、管道和多路复用协议、自定义协议、紧凑二进制协议和用于互联网服务器互操作的其他标准协议的很好基础
  • WebSocket为Web应用程序提供了TCP风格的网络能力。寻址仍然是单向的，服务器可以异步发送客户端数据，但是只在WebSocket连接打开时才能做到。在客户端和服务器之间WebSocket连接始终打开。WebSocket服务器也可以作为WebSocket客户端
特性TCPHTTPWebSocket
寻址IP地址和端口URLURL
并发传输全双工半双工全双工
内容字节流MIME信息文本和二进制数据
消息定界否是是
连接定向是否是
  • TCP只能传送字节流，所以消息边界只能由更高层的协议来表现。对于TCP来说，它唯一可以保证的是到达接收端的单个字节将会按顺序到达。和TCP不同，WebSocket传输一序列单独的消息，在WebSocket中，和HTTP一样，多字节的消息作为整体，按照顺序到达。因为WebSocket协议内置了消息边界，所以它能够发送和接收单独的消息并避免常见的碎片错误
  • IP处于互联网层，而TCP处于IP之上的传输层。WebSocket的层次在TCP/IP之上，因为你可以在WebSocket上构建应用级协议，所以它也被看作是传输层协议

2. 初始握手

  • 每个WebSocket连接都始于一个HTTP请求，该请求与其他请求很相似，但是包含一个特殊的首标 — \text{---} —Upgrade，这个首标表示客户端将把连接升级到不同的协议。在这种情况下，这种特殊的协议就是WebSocket
  • 从客户端发往服务器升级为WebSocket的HTTP请求称为WebSocket的初始握手，在成功升级之后，连接的语法切换为用于表示WebSocket消息的数据帧格式。除非服务器响应 101代码、Upgrade首标和Sec-WebSocket-Accept首标，否则WebSocket连接不能成功。Sec-WebSocket-Accept响应首标的值从Sec-WebSocket-Key请求首标继承而来，包含一个特殊的响应健值，必须与客户端的预期精确匹配

3. 计算响应健值

  • 为了成功地完成握手，WebSocket服务器必须响应一个计算出来的健值。这个响应说明服务器理解WebSocket协议。这个响应说明服务器理解WebSocket协议。没有精确的响应，就可能哄骗一些轻信的HTTP服务器意外的升级一个连接
  • 响应函数从客户端发送的Sec-WebSocket-Key首标中取得键值，并在Sec-WebSocket- Accept首标中返回根据客户端预期计算的键值
首标描述
Sec-WebSocket-Key只能在HTTP请求中出现一次，用于从客户端到服务器的WebSocket初始握手，避免跨协议攻击
Sec-WebSocket-Accept只能在HTTP请求中出现一次，用于从客户端到服务器的WebSocket初始握手，确认服务器理解WebSocket协议
Sec-WebSocket-Extensions可能在HTTP请求中出现多次，但是在HTTP响应中只能出现一次。用于从客户端到服务器的WebSocket初始握手，然后用于从服务器到客户端的响应。这个首标帮助客户端和服务器商定一组连接期间使用的协议级扩展
Sec-WebSocket-Protocol用于从客户端到服务器的WebSocket初始握手，然后用于从服务器到客户端的响应。这个首标通告客户端应用程序可使用的协议。服务器使用相同的首标，在这些协议中最多选择一个
Sec-WebSocket-Version用于从客户端到服务器的WebSocket初始握手，表示版本兼容性。RFC 6455的版本总是13。服务器如果不支持客户端请求的协议版本，则用这个首标响应。在那种情况下，服务器发送的首标中列出了它支持的版本。这只发生在RFC 6455之前的客户端中

4. 消息格式

  • 当WebSocket连接打开时，客户端和服务器可以在任何时候相互发送消息。这些消息在网络上用于标记消息之间边界并包括简洁的类型消息的二进制语法表示。更准确地说，这些二进制首标标记另一个单位 — \text{---} —帧(frame)之间的边界。帧是可以合并组成消息的部分数据。你可能在WebSocket的相关讨论中将“帧”和“消息”互换使用，这是因为很少有一个消息使用超过一个帧的(至少目前如此)。而且在协议帧的早期草案中，帧就是消息，消息在线路上的表示被称作“组帧”(framing)
  • WebSocket API没有向应用程序暴露帧级别的信息。尽管API按照消息工作，但是可以在协议级别上处理子消息数据单元。虽然消息一般只有一个帧，但是它可以由任意数量的帧组成。服务器可以使用不同数量的帧，在全体数据可用之前开始交付数据
  • 下面是一个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 ...                |
     +---------------------------------------------------------------+

参考https://datatracker.ietf.org/doc/html/rfc6455

下面详细介绍

  1. 操作码(opcode)
  • 每条Websocket消息都有一个指定消息载荷类型的操作码。操作码由帧头的第一个字节中最后4 bit组成，如下表所示
操作码消息载荷类型描述
1文本消息的数据类型为文本
2二进制消息的数据类型为二进制
8关闭客户端或者服务器向对方发送关闭握手
9ping客户端或者服务器向对方发送ping
10pong客户端或者服务器向对方发送pong
  • 4 bit的操作码有16种可能取值，WebSocket协议只定义了5种操作码，剩余的操作码保留用于未来的扩展
  1. 长度
  • WebSocket协议使用可变位数来变码帧长度，这样，小的消息就能使用紧凑的编码，协议仍然可以携带中型甚至非常大的消息。对于小于126字节的消息，长度用帧头前两个字节之一来表示。对于126~216字节的消息，使用额外的两个字节表示长度。对于大于216字节的消息，长度为8字节。该长度编码保存于帧头第二个字节的最后7位。该字段种126和127两个值被当作特殊的信号，表示需要后面的字节才能完成长度编码
  1. 编码文本
  • WebSocket文本消息用8位UCS转换格式(UTF-8)编码。UTF-8是用于Unicode的变长编码，向后兼容7位的ASCII，也是WebSocket文本消息允许的唯一编码。坚持使用UTF-8编码避免了大量的“普通文本”格式以及协议中的不同编码对互操作性的妨害
  1. 屏蔽(或者叫掩码)
  • 从浏览器向服务器发送的WebSocket帧内容进行了“屏蔽”，以混淆其内容。屏蔽的目的不是阻止窃听，而是为了不常见的安全原因，以及改进和现有的HTTP代理的兼容性。
  • 帧头的第二个字节的第一位表示该帧是否进行了屏蔽，WebSocket协议要求客户端屏蔽发送的所有帧。如果有屏蔽，所用的掩码将占据帧头扩展长度部分后的4个字节
  • WebSocket服务器接收的每个载荷在处理之前首先被解除屏蔽。解除屏蔽之后，服务器得到原始消息内容：二进制消息可以直接交付；文本消息将进行UTF-8编码，并通过服务器API输出字符串
  1. 多帧消息
  • 帧格式中的fin位考虑了多帧消息或者部分可用消息的流化，这些消息可能不连续或者不完整。要发送一条不完整的消息，你可以发送一个fin位设置为0的帧。最后一个帧的fin位设置为1，表示消息以这一帧的载荷作为结束

5. WebSocket关闭握手

  • WebSocket连接总是以初始握手开始，因为这是初始化互联网和其他可靠网上对话的唯一手段，连接可以在任何时候关闭，所以不可能总是以关闭握手结束。有时候，底层的TCP套接字可能突然关闭。关闭握手优雅地关闭连接，使应用程序能够知道有意中断和意外终止连接之间的差异
  • 当WebSocket关闭时，终止连接的端点可以发送一个数字代码，以及一个表示选择关闭套接字原因的字符串。代码和原因编码为具有关闭操作码的一个帧的载荷。数字代码 用一个16位无符号整数表示，原因则是一个UTF-8编码的短字符串。RFC 6455定义了多种特殊的关闭代码。代码1000~1015规定用于WebSocket连接层。这戏的代码表示网络中或者协议中的某些故障，下表是关闭代码
代码描述何时使用
1000正常关闭当你的会话成功完成时发送这个代码
1001离开因应用程序离开且不希望后续的连接尝试而关闭连接时，发送这一代码。服务器可能关闭，或者客户端应用程序可能关闭
1002协议错误当因协议错误而关闭连接时发送这一代码
1003不可接受的数据类型当应用程序接收到一条无法处理的意外类型消息时发送这一代码
1004保留不要发送这一代码。根据RFC 6455，这个状态码保留，可能在未来定义
1005保留不要发送这一代码。WebSocket API用这个代码表示没有接收到任何代码
1006保留不要发送这一代码。WebSocket API用这个代码表示连接异常关闭
1007无效数据在接收一个格式与消息类型不匹配的消息之后发送这一代码。如果文本消息包含错误格式的UTF-8数据，连接应该用这个代码关闭
1008违反消息政策当应用程序由于其他代码所不包含的原因终止连接，或者不希望泄露消息无法处理的原因时，发送这一代码
1009消息过大当接收的消息过大，应用程序无法处理时发送这一代码(帧的载荷长度最多为64字节，即使你有一个大服务器，有些消息也仍然太大)
1010需要扩展当应用程序需要一个或职责多个服务器无法协商的特殊扩展时，从客户端(浏览器)发送这一代码
1011意外情况当应用程序由于不可预见的原因，无法继续处理连接时，发送这一代码
1015TLS失败(保留)不要发送这个代码。WebSocket API用这个代码表示TLS在WebSocket握手之前失败

实现

  • 我们分析一下golang的websocket包https://github.com/gorilla/websocket来看此协议是如何实现的，重点关注conn.go文件，我们先看一下Conn结构的定义
type Conn struct {
	conn        net.Conn // 底层网络连接
	isServer    bool // 如果这个连接作为服务器端的连接则为true，如果是客户端则为false
	subprotocol string // 代表WebSocket连接中协商的子协议

	// Write fields （写操作相关字段）
	mu            chan struct{} // used as mutex to protect write to conn（用作互斥锁保护对连接的写操作）
	writeBuf      []byte        // frame is constructed in this buffer.(字节切片，用于构造要写入的帧)
	writePool     BufferPool // 提供和管理写缓冲区的池
	writeBufSize  int // 写缓冲区的大小
	writeDeadline time.Time // 写操作的截止时间
	writer        io.WriteCloser // the current writer returned to the application(当前返回给应用程序的写入器)
	isWriting     bool           // for best-effort concurrent write detection(用于尽最大努力检测并发写操作)

	writeErrMu sync.Mutex // 用于保护写操作错误的互斥锁
	writeErr   error // 保存写操作中发生的错误

	enableWriteCompression bool // 指示是否启用写操作压缩
	compressionLevel       int // 写操作压缩的级别
	newCompressionWriter   func(io.WriteCloser, int) io.WriteCloser // 用于创建新的压缩写入器

	// Read fields(读操作相关字段)
	reader  io.ReadCloser // the current reader returned to the application (当前 返回给应用程序的读取器)
	readErr error // 保存读操作中发生的错误
	br      *bufio.Reader // 带缓冲的读取器
	// bytes remaining in current frame. 
	// set setReadRemaining to safely update this value and prevent overflow
	readRemaining int64 // 当前帧剩余的字节数
	readFinal     bool  // true the current message has more frames.(指示当前消息是否有更多帧)
	readLength    int64 // Message size. // 消息大小
	readLimit     int64 // Maximum message size. // 消息的最大大小
	readMaskPos   int // 掩码在消息中的位置
	readMaskKey   [4]byte // 用于WebSocket消息掩码
	handlePong    func(string) error // 处理Pong帧的回调函数
	handlePing    func(string) error // 处理Ping帧的回调函数
	handleClose   func(int, string) error // 处理关闭帧的回调函数
	readErrCount  int // 记录读取错误的次数
	messageReader *messageReader // the current low-level reader(当前的底层消息读取器)

	readDecompress         bool // whether last read frame had RSV1 set(指示最后读取的帧是否设置了RSV1(用于压缩))
	newDecompressionReader func(io.Reader) io.ReadCloser // 用于创建新的解压缩读取器
}
  • 之后我们来看一个关键的函数ReadMessage
// ReadMessage is a helper method for getting a reader using NextReader and
// reading from that reader to a buffer.
func (c *Conn) ReadMessage() (messageType int, p []byte, err error) {
	var r io.Reader
	messageType, r, err = c.NextReader()
	if err != nil {
		return messageType, nil, err
	}
	p, err = io.ReadAll(r)
	return messageType, p, err
}
  • ReadMessage函数是我们经常会用到的函数，它用来接收WebSocket消息，一般接收到来自浏览器端的每条消息，我们会从p数组中获取，可以看到这个函数的核心功能是NextReader()方法实现的，下面是这个方法
// NextReader returns the next data message received from the peer. The
// returned messageType is either TextMessage or BinaryMessage.
//
// There can be at most one open reader on a connection. NextReader discards
// the previous message if the application has not already consumed it.
//
// Applications must break out of the application's read loop when this method
// returns a non-nil error value. Errors returned from this method are
// permanent. Once this method returns a non-nil error, all subsequent calls to
// this method return the same error.
func (c *Conn) NextReader() (messageType int, r io.Reader, err error) {
	// Close previous reader, only relevant for decompression.
	if c.reader != nil {
		_ = c.reader.Close()
		c.reader = nil
	}

	c.messageReader = nil
	c.readLength = 0

	for c.readErr == nil {
		frameType, err := c.advanceFrame()
		if err != nil {
			c.readErr = err
			break
		}

		if frameType == TextMessage || frameType == BinaryMessage {
			c.messageReader = &messageReader{c}
			c.reader = c.messageReader
			if c.readDecompress {
				c.reader = c.newDecompressionReader(c.reader)
			}
			return frameType, c.reader, nil
		}
	}

	// Applications that do handle the error returned from this method spin in
	// tight loop on connection failure. To help application developers detect
	// this error, panic on repeated reads to the failed connection.
	c.readErrCount++
	if c.readErrCount >= 1000 {
		panic("repeated read on failed websocket connection")
	}

	return noFrame, nil, c.readErr
}
  • 核心是advanceFrame函数，这个函数内部实现了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 ...                |
     +---------------------------------------------------------------+
  • 前两行展示了帧格式的布局和结构，0到3表示列的索引，好像没什么实际含义，只是标记0的位置，第二行有32个数字，表示32个比特位，一共4个字节
  • FIN表示这是消息的最后一个帧
  • RSV1,RSV2,RSV3用于扩展协议
  • OpCode指示数据帧的类型，例如文本、二进制、连接关闭等
  • Mask指示是否有掩码
  • Payload length表示负载数据的长度，也就是实际传输的数据长度
  • Extended payload length表示扩展的负载长度，如果Payload len小于等于125个字节，则使用一个字节来表示长度；如果长度在126个字节到65535个字节之间，则使用两个字节来表示长度；如果长度超过65535个字节，则使用8个字节来表示长度。因此，负载数据的长度最大可以达到 2 64 − 1 2^{64}-1 264−1，所以一般不会有超过一个帧的数据
  • Masking-Key是发送方随机生成的4字节掩码，它会对负载数据进行加密，接收方使用这个掩码对负载数据进行加密，以获取原始数据内容。它能够防止一些网络攻击，如中间人攻击，每次随机生成的Masking-Key使得中间人无法进行持续解密
  • 接下来的部分就都是传输的数据了
// Read methods

func (c *Conn) advanceFrame() (int, error) {
	// 1. Skip remainder of previous frame.

	if c.readRemaining > 0 {
		if _, err := io.CopyN(io.Discard, c.br, c.readRemaining); err != nil {
			return noFrame, err
		}
	}

	// 2. Read and parse first two bytes of frame header.
	// To aid debugging, collect and report all errors in the first two bytes
	// of the header.

	var errors []string

	p, err := c.read(2)
	if err != nil {
		return noFrame, err
	}

	frameType := int(p[0] & 0xf)
	final := p[0]&finalBit != 0
	rsv1 := p[0]&rsv1Bit != 0
	rsv2 := p[0]&rsv2Bit != 0
	rsv3 := p[0]&rsv3Bit != 0
	mask := p[1]&maskBit != 0
	if err := c.setReadRemaining(int64(p[1] & 0x7f)); err != nil {
		return noFrame, err
	}

	c.readDecompress = false
	
	if rsv1 {
		if c.newDecompressionReader != nil {
			c.readDecompress = true
		} else {
			errors = append(errors, "RSV1 set")
		}
	}

	if rsv2 {
		errors = append(errors, "RSV2 set")
	}

	if rsv3 {
		errors = append(errors, "RSV3 set")
	}

	switch frameType {
	case CloseMessage, PingMessage, PongMessage:
		if c.readRemaining > maxControlFramePayloadSize {
			errors = append(errors, "len > 125 for control")
		}
		if !final {
			errors = append(errors, "FIN not set on control")
		}
	case TextMessage, BinaryMessage:
		if !c.readFinal {
			errors = append(errors, "data before FIN")
		}
		c.readFinal = final
	case continuationFrame:
		if c.readFinal {
			errors = append(errors, "continuation after FIN")
		}
		c.readFinal = final
	default:
		errors = append(errors, "bad opcode "+strconv.Itoa(frameType))
	}

	if mask != c.isServer {
		errors = append(errors, "bad MASK")
	}

	if len(errors) > 0 {
		return noFrame, c.handleProtocolError(strings.Join(errors, ", "))
	}

	// 3. Read and parse frame length as per
	// https://tools.ietf.org/html/rfc6455#section-5.2
	//
	// The length of the "Payload data", in bytes: if 0-125, that is the payload
	// length.
	// - If 126, the following 2 bytes interpreted as a 16-bit unsigned
	// integer are the payload length.
	// - If 127, the following 8 bytes interpreted as
	// a 64-bit unsigned integer (the most significant bit MUST be 0) are the
	// payload length. Multibyte length quantities are expressed in network byte
	// order.

	switch c.readRemaining {
	case 126:
		p, err := c.read(2)
		if err != nil {
			return noFrame, err
		}

		if err := c.setReadRemaining(int64(binary.BigEndian.Uint16(p))); err != nil {
			return noFrame, err
		}
	case 127:
		p, err := c.read(8)
		if err != nil {
			return noFrame, err
		}

		if err := c.setReadRemaining(int64(binary.BigEndian.Uint64(p))); err != nil {
			return noFrame, err
		}
	}

	// 4. Handle frame masking.

	if mask {
		c.readMaskPos = 0
		p, err := c.read(len(c.readMaskKey))
		if err != nil {
			return noFrame, err
		}
		copy(c.readMaskKey[:], p)
	}

	// 5. For text and binary messages, enforce read limit and return.

	if frameType == continuationFrame || frameType == TextMessage || frameType == BinaryMessage {

		c.readLength += c.readRemaining
		// Don't allow readLength to overflow in the presence of a large readRemaining
		// counter.
		if c.readLength < 0 {
			return noFrame, ErrReadLimit
		}

		if c.readLimit > 0 && c.readLength > c.readLimit {
			if err := c.WriteControl(CloseMessage, FormatCloseMessage(CloseMessageTooBig, ""), time.Now().Add(writeWait)); err != nil {
				return noFrame, err
			}
			return noFrame, ErrReadLimit
		}

		return frameType, nil
	}

	// 6. Read control frame payload.

	var payload []byte
	if c.readRemaining > 0 {
		payload, err = c.read(int(c.readRemaining))
		if err := c.setReadRemaining(0); err != nil {
			return noFrame, err
		}
		if err != nil {
			return noFrame, err
		}
		if c.isServer {
			maskBytes(c.readMaskKey, 0, payload)
		}
	}

	// 7. Process control frame payload.

	switch frameType {
	case PongMessage:
		if err := c.handlePong(string(payload)); err != nil {
			return noFrame, err
		}
	case PingMessage:
		if err := c.handlePing(string(payload)); err != nil {
			return noFrame, err
		}
	case CloseMessage:
		closeCode := CloseNoStatusReceived
		closeText := ""
		if len(payload) >= 2 {
			closeCode = int(binary.BigEndian.Uint16(payload))
			if !isValidReceivedCloseCode(closeCode) {
				return noFrame, c.handleProtocolError("bad close code " + strconv.Itoa(closeCode))
			}
			closeText = string(payload[2:])
			if !utf8.ValidString(closeText) {
				return noFrame, c.handleProtocolError("invalid utf8 payload in close frame")
			}
		}
		if err := c.handleClose(closeCode, closeText); err != nil {
			return noFrame, err
		}
		return noFrame, &CloseError{Code: closeCode, Text: closeText}
	}

	return frameType, nil
}
  • 第一步丢弃之前的帧的数据的原因是我们希望尽可能的从一个干净的状态开始，这些帧既然现在还存在就说明上一次接收的数据已经决定丢弃这些帧，那么这些帧是要被这次的数据忽略的，在这个函数中用到了io.Discard结构体，这个结构体很简单，写入它的所有数据都会被丢弃，通过io.CopyN将当前读取器缓冲区中上一个帧的残留数据全部清除
  • 后面的代码都是对协议的实现，理解上面的帧格式表之后，不难理解代码内容
Clarence Liu
关注
  • 15
    点赞
  • 踩
  • 24
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
websocket获取httpsession
方方园园的博客
05-27 3503
websocket有两个session 一个是自身的 一个是httpsession，由于WebSocket与Http协议的不同，故在使用常用的HttpSession方面就存在了一些问题。通过google翻阅到了在onOpen方法下使用HttpSession的方法 import javax.servlet.http.HttpSession; import javax.websocket.Hand...
nginx 反向代理 http转https wss转ws 服务端不变
Tomshidi的博客
05-16 7135
nginx 反向代理 http转https wss转ws 服务端不变 本篇博客主要解决nginx http转https的配置问题，以及wss转ws的配置,本配置的好处就是后台原http代码不需要做任何修改 主要配置介绍 http配置介绍 http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' ...
【计算机网络】—— HTTP升级为WebSokect
chenxiyuehh的博客
08-12 4639
WebSocket和HTTP 一、WebSocket是HTML5中的协议，支持持久连接；而Http协议不支持持久连接。 首先HTMl5指的是一系列新的API,或者说新规范，新技术。WebSocket是HTML5中新协议、新API. Http协议本身只有1.0和1.1，也就是所谓的Keep-alive，把多个Http请求合并为一个。 二、WebSocket是什么样的协议，具体有什么优点。 首先，...
这个表明将http协议转成websocket协议
weixin_30800987的博客
01-01 563
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>websocket</title> <script> var socket; if (window...
前端（二十一）——WebSocket：实现实时双向数据传输的Web通信协议
杜永康的博客
10-24 8942
在当今互联网时代，实时通信已成为很多应用的需求。为了满足这种需求，WebSocket协议被设计出来。WebSocket是一种基于TCP议的全双工通信协议，通过WebSocket，Web应用程序可以与服务器建立持久的连接，实现实时双向数据输，提供极低的延迟和高效的数据传输。
WebSocket——“舔狗”Http的升级之路
毅航的博客
06-18 1102
一：基础了解——HTTP 超文本传输协议（Hypertext Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII形式给出；而消息内容则具有一个类似MIME的格式。这个简单模型是早期Web成功的有功之臣，因为它使开发和部署非常地直截了当。 对于WebSocket我们首先需要明白其本质还是一种协议和我们之前使用的http类似的网络协议，...
HTTP——浅谈WebSocket
ZKH129的博客
06-14 486
浅谈WebSocket
EasyRTC编译中Golang 将 http 请求升级为 websocket实现过程分享
EasyNVR官方技术博客
07-13 418
在 EasyRTC视频通话项目的编译中，部分操作采用 websocket 连接减少发送请求，增加实时性。一般情况下，会添加新端口的方式，在端口上做 websocket 服务。但是为了减少端口的使用，还有一种可以直接将 http 请求升级为 websokcet 协议。代码如下： p2pServer := p2p.NewP2PServer(p2p.HandleNewWebSocket) // 升级 websocket wsPath := "/ws" engine.GET(wsPath, p2pServer.
从Http的连接到WebSocket
热门推荐
冯立彬的博客
12-28 5万+
1、HTTP协议对长连接的支持以及各浏览器的支持情况 http://blog.csdn.net/fenglibing/article/details/7100222 2、WEB客户端与服务端信息交互的几种方式 1）、Flash XMLSocket 入门示例：http://en.wikipedia.org/wiki/XMLSocket 不足： a）、客户端必须安装 Flash 播
HTTP：协议升级机制（WebSocket）
OceanStar的博客
08-05 1万+
HTTP协议提供了一种特殊的机制，这一机制允许将一个已建立的连接升级成新的、不相容的协议。 通常来说这一机制总是由客户端发起的（不过也有例外，比如说可以由服务端发起升级到传输层安全协议(TLS)），服务端可以选择是否要升级到新协议。借助这一技术，连接可以以常用的协议启动(比如HTTP/1.1)，随后再升级到HTTP2甚至是WebSockets. 注意：HTTP/2 明确禁止使用此机制，这个机制只属于HTTP/1.1 升级HTTP/1.1的链接 协议升级请求总是由客户端发起的；暂时没有服务端请求协议更改的
Springboot Controller 获取httpSession对应的websocket Session
qq_22239651的博客
12-03 3129
上一篇文章中写了使用httpSessionId存储Websocket Session，下面在SpringBoot中在Contrller类获取前端请求的HttpSession，从而获得对应的websocket Session。 Controller类 import org.springframework.beans.factory.annotation.Autowired; import org.springframework.http.HttpStatus; import org.springfram
WebSocket之获取HttpSession
Erica_1230的专栏
04-28 2933
由于WebSocket与Http协议的不同，故在使用常用的HttpSession方面就存在了一些问题。通过google翻阅到了在onOpen方法下使用HttpSession的方法。 新建一个GetHttpSessionConfigurator类并继承Configurator类 package per.zww.web; import javax.servlet.http.HttpSession
基于tomcat 7.0.68 的websocket 实现，及通过 HttpSessionId 实现websocket session 共享
TT_DUL的博客
06-07 1万+
tomcat 7.0.68 websocket session 共享
haproxy对http协议升级websocket的负载配置
sltin的博客
11-24 2042
haproxy对websocket的负载 用习惯了HaProxy，最近用到关于WebSocket的负载上也涉及到这块，做个记录。 这里以简单的 kube-apiserver 3master 转发http为例子，实际直接4层转发即可 单纯使用ha的tcp或者http负载，会出现链接断开的情况，此处需重点关注Connection: Upgrade头，会让client端知道server端会改变协议，变成如Upgrade: websocketheader中所述的协议。若服务端提供，则会返回： HTTP/1.1 10
nginx配置https转http&wss转ws
Alain999的博客
03-29 1848
1.修改ngix中conf下的ngix.conf，详细配置如下： #user nobody; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { in...
轻松实现Nginx的HTTP与WebSocket转发：你的网站需要这个
最新发布
大猩猩的专栏
03-18 2352
在 Nginx 中配置 HTTP 和 WebSocket 的转发，那么 Nginx 的配置文件，通常这个文件位于 /etc/nginx/nginx.conf 或 /etc/nginx/sites-available/ 目录下的某个文件。总而言之，配置转发不生效的问题，假如配置全部正确，就是不转发的情况下，请查看您的api配置，以及正则的匹配优先级。该网站基本都是傻瓜式的点击配置，当我们配置完成后，进行下载，那么，我们会得到一个非常详尽的nginx配置文件。我们了解下nginx内正则的规则和序号。
flask总结之session，websocket，上下文管理
人言落日是天涯，望极天涯不见家。
03-04 381
1.关于session 　　flask是带有session的，它加密后存储在用户浏览器的cookie中，可以通过app.seesion_interface源码查看 from flask import Flask,session app = Flask(__name__) app.secret_key = 'aptx4869' # 必须要指定这个参数 @app.route('/login...
【学习心得】websocket协议简介并与http协议对比
qq_39780701的博客
03-07 1052
让我们通过一个生活化的比喻来解释轮询和websocket。假设你正在与一位不怎么主动说话的老大爷（服务器）聊天，你想要知道他是否有新的故事或者信息分享给你。
nodejs中，实现HTTP协议和WS协议复用同一端口
卖糖葫芦大叔的博客
09-12 4666
00、前言 ​ 最近在写一个网页，需要用到后端的websocket服务，由于不需要太复杂的功能，后端选择使用nodejs的nodejs-websocket模块。在开发过程中发现还需要http服务，但nodejs-websocket无法实现http服务，于是便开始寻求可以解决两个协议共用同一端口的方法。 01、有关问题 ​ 一般来说，每个服务启动时都需占用一个端口。例如上面所提到的nodejs-websocket，如下代码所示(代码来源：nodejs-websocket)： const ws = requ
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Clarence Liu

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值