计算机网络———

计算机网络————（三）

news2025/2/26 12:39:25

前文二
前文一

Websocket协议

是一种存在TCP协议之上的协议
当客户端需要了解服务器是否更新就需要不断给客户端发送请求询问是否更新，这行会造成服务端压力很大
而Websocket相当于服务器一旦更新了就会给客户端发送消息表明自己更新了，类似客户端订阅了服务器，一旦服务器更新就会给客户端返回更新消息

在这里插入图片描述

在浏览器自带WS代表的就是WebSocket协议或者是过滤器中输入is:running
表格列：
Data:消息负载。如果消息为纯文本，则此处显示。二进制操作码，此列将显示操作码的名称和代码。
Length:消息负载的长度（字节为单位）
Time:收到或发送消息的时间
消息颜色：
浅绿色:发至服务器的文本消息
白色:接收到文本消息
浅黄色:操作码
浅红色:错误

成本

1.元数据放在应用层了，HTTP放在的是头部
2.传输是基于帧，HTTP是基于流传输
3.同源策略
4.同一台主机会根据URI、子协议支持同主机同端口上的多个服务

URI格式
we-URI/wws-URI =“ws/wws :” "//“host[”:“port]path[”?"query]

在这里插入图片描述

发送四类消息
红色的消息————必选的消息
请求：
必须是GET请求且为HTTP/1.1，头部必须是HOST头部，以及
携带WebSocket-Version的版本13，并且携带连接升级的消息Connection:keep-alive,Upgrade,
并且携带升级为什么类型Upgrade:Websocket

绿色的为随机数

蓝色的为传递跨域信息

黑色的为自协议等
响应：
必须返回的响应码为101，Connection为Upgrade,以及Upgrade为websocket

绿色：服务器必须根据客户端传来的随机数生成新的编码

蓝色为响应的跨域头部信息

如何证明握手被服务器接收

请求中绿色的随机数作64位编码
然后响应中的Sec-WebSocket-Accept 使用做拼接（BASE64(SHA1(Sec-WebSocket-KeyGUID))）作为验证

消息与数据帧

Message消息
1条消息由1个或多个帧组成，这些数据帧属于同一类型
代理服务器可能合并、拆分消息的数据帧

Frame数据帧
持续帧
文本帧、二进制帧

帧的格式：
在这里插入图片描述

0——31 表示几个二位数——4个字节，红色的为必然存在的帧的头部

FIN（Finish）是一个标志位，用于TCP连接的正常关闭过程。当一个设备想要终止与另一个设备之间的TCP连接时，它会发送一个带有FIN标志位设置为1的TCP段（或称为帧）。这表示该端不再有数据要发送了，但仍然可以接收对方发来的数据

RSV1-3:默认为0，仅当使用extension扩展时，由扩展决定其值

opcode:定义了帧的类型三种——1）持续帧————0表示跟前一个帧一样。
2）非控制帧————a.1——文本帧（UTF8） b.2——二进制帧 c.3-7为非控制帧
3）控制帧————a.8——关闭帧（关闭连接） b.9——心跳帧ping c.A——心跳帧pong d.B-F——控制帧保留

非控制帧的消息分片必须保证有序
在这里插入图片描述

插入FIN=1 OP=A 表示插入了一个控制帧，并且通知对方要结束传输了，但是还有挥手协议所以还会有FIN=1的传递

内容和长度

消息内容长度组成
1.应用消息长度
2.扩展数据长度————压缩等

当内容长度为<=125字节————使用Payload len 的格式，
126-2^16-1 Payload len 值为126使用Extended payload length 16位表示长度，
2^16至264-1 Payload len值为127 使用Extended payload length 共8字节64位
在这里插入图片描述

发送消息的前提

确保WebSocket会话处于POEN状态
以帧来承载消息，一条消息可拆分位多个数据帧
客户端发送的帧必须基于掩码编码
一旦发送或者接收到关闭帧，连接必须处于CLOSING状态
一旦发送了关闭帧，且接收到关闭帧，连接处于CLOSED状态
TCP连接关闭后，WebSocket连接才完全关闭

客户端向服务端发送消息要做掩码处理和原因
由一种针对代理服务器的缓存污染攻击
在这里插入图片描述

实现不当的代理服务器————只能识别HTTP请求，而不能识别WebSocket的服务器
首先恶意页面通过JS发送握手，然后代理服务器正常代理进恶意服务器————成功建立了WebSocket握手
问题就在第三步，恶意页面伪造GET 请求，而实际使用FROM增的请求，因为代理服务器无法识别WebSocket协议并且认为是HTTP请求就正常
转发给服务器。然后恶意服务器再返回响应给代理服务器，此时代理服务器就将这个恶意服务器的内容放入缓存————实际应该存放正常服务器的内容。
这样正常浏览器访问页面的话就会返回恶意服务器里面的内容。

解决办法：frame-masking-key 掩码
客户器端消息：MASK为1（控制帧），传递32位无法预测的、随机的Masking-key
服务器端消息MASK为0
强制浏览器生成32位 Frame-masking-key,不能让那个js代码猜出，否则任然可以反向构造
对传输包体按照Frame-masking-key执行可对称解密的XOR异或操作，使代理服务器不识别