将文本框发送到 WebSocket 回显服务器
Posted
技术标签:
【中文标题】将文本框发送到 WebSocket 回显服务器【英文标题】:Send Textframe to WebSocket echo-server 【发布时间】:2015-12-29 13:38:45 【问题描述】:我正在用 C++ 编写 WebSocket 实现。现在几乎完成了,我想针对这个WebSocket echo-server 进行测试。首先,我在 HTTP-Handshake 中连接到它和 Upgrade
到 WebSocket-Protocol。
然后我发送一个带有“这是一个测试”作为内容的文本框。这是我的程序发送的内容:
FRRR-OP- M-LENGTH MASK-KEY
10000001 10001110 00000100
MASK-KEY MASK-KEY MASK-KEY
01000101 11010000 01101011
--DATA-- --DATA-- --DATA--
01010000 00101101 10111001
--DATA-- --DATA-- --DATA--
00011000 00100100 00101100
--DATA-- --DATA-- --DATA--
10100011 01001011 01100101
--DATA-- --DATA-- --DATA--
01100101 10000100 00001110
--DATA-- --DATA--
01110111 00110001
我会快速解释这些字母:
F:表示这是消息中的最后一个片段(引用 RFC6455) RRR:RSV1、RSV2、RSV3。除非使用扩展名,否则始终为 0。 -OP-:操作码。操作码 1 = 短信 M:表示数据是否被屏蔽。 1 = 被屏蔽。 -LENGTH:数据的字节长度(不包括 MASK-KEY)。 MASK-KEY:用于加密数据的密钥。总是 4 字节长。来自RFC6455
数据:加密数据(“这是一个测试”)要将屏蔽数据转换为未屏蔽数据,反之亦然, 应用以下算法。相同的算法适用 无论翻译的方向如何,例如,相同 应用步骤来屏蔽数据以取消屏蔽数据。
转换后数据的八位字节 i ("transformed-octet-i") 是 XOR 原始数据的八位字节 i (“original-octet-i”),八位字节位于 掩码键的索引 i 模 4(“masking-key-octet-j”):
j = i MOD 4 transformed-octet-i = original-octet-i XOR masking-key-octet-j
发送此帧后,echo-server 需要很长时间才能响应(~45 秒),这是我得到的数据:
FRRR-OP- M-LENGTH --DATA--
10000001 00001110 01010100
--DATA-- --DATA-- --DATA--
01101000 01101001 01110011
--DATA-- --DATA-- --DATA--
00100000 01101001 01110011
--DATA-- --DATA-- --DATA--
00100000 01100001 00100000
--DATA-- --DATA-- --DATA--
01010100 01100101 01110011
--DATA-- --DATA-- --DATA--
01110100 10001001 00000000
将数据转换为字符串会产生这种结果。
This is a Test‰
所以这里出了点问题。当服务器响应时,它不能是错误的 OP-Code。不可能是错误的加密,因为服务器可以解密数据。长度也没有错怎么看。但是,奇怪的是服务器需要很长时间才能响应。它似乎正在等待更多数据。
【问题讨论】:
【参考方案1】:最后两个字节(10001001
、00000000
)是没有负载的ping frame。
【讨论】:
以上是关于将文本框发送到 WebSocket 回显服务器的主要内容,如果未能解决你的问题,请参考以下文章
将图像从 websocket 服务器 .NET 发送到客户端 (HTML5)