php sec-websocket-accept,关于node.js:Sec-WebSocket-Accept值的Base64编码

不久前,我开始尝试使用node.js来处理后端。它工作得很好,但是现在当我返回时,协议已经更新,我不能让它正常工作了。

具体来说,问题是Sec-WebSocket-Accept头。我计算的时候好像做错了什么,虽然我真的不知道那可能是什么。据我所知,我正在按照维基百科上的指示上网。

以下是我的代码:

var magicString ="258EAFA5-E914-47DA-95CA-C5AB0DC85B11";

var secWsKey = req.headers['sec-websocket-key'];

var hash = require('crypto')

.createHash('SHA1')

.update(secWsKey + magicString)

.digest('hex');

var b64hash = new Buffer(hash).toString('base64');

var handshake ="HTTP/1.1 101 Web Socket Protocol Handshake

" +

"Upgrade: WebSocket

" +

"Connection: Upgrade

" +

"Sec-WebSocket-Accept:" + b64hash +"

" +

"

";

socket.write(handshake);

示例连接:

// The incoming headers

{ upgrade: 'websocket',

connection: 'Upgrade',

host: 'localhost:8888',

origin: 'http://localhost:8888',

'sec-websocket-key': '4aRdFZG5uYrEUw8dsNLW6g==',

'sec-websocket-version': '13' }

// The outgoing handshake

HTTP/1.1 101 Switching Protocols

Upgrade: WebSocket

Connection: Upgrade

Sec-WebSocket-Accept: YTYwZWRlMjQ4NWFhNzJiYmRjZTQ5ODI4NjUwMWNjNjE1YTM0MzZkNg==

// Result: Error during WebSocket handshake: Sec-WebSocket-Accept mismatch

更深入地研究这个问题,我尝试在wiki中复制计算散列,但失败了。

var hash = require('crypto')

.createHash('SHA1')

.update('x3JJHMbDL1EzLkh9GBhXDw==258EAFA5-E914-47DA-95CA-C5AB0DC85B11')

.digest('hex');

// Result  : 1d29ab734b0c9585240069a6e4e3e91b61da1969

// Expected: 1d29ab734b0c9585240069a6e4e3e91b61da1969

var buf = new Buffer(hash).toString('base64');

// Result  : MWQyOWFiNzM0YjBjOTU4NTI0MDA2OWE2ZTRlM2U5MWI2MWRhMTk2OQ==

// Expected: HSmrc0sMlYUkAGmm5OPpG2HaGWk=

如您所见,sha1散列是正确的,但base64编码不是。看看这个答案,我似乎做得对。我在PHP中尝试了相同的过程,得到了相同的结果,所以很明显我做错了。

我正在运行node.js v0.6.8。越来越近

我对PHP进行了进一步的实验,这对我来说更为熟悉,并且从shell中的printf的行为派生而来,我得出了以下工作片段:

$hash = sha1('x3JJHMbDL1EzLkh9GBhXDw==258EAFA5-E914-47DA-95CA-C5AB0DC85B11');

$hashdec = '';

for ($i = 0; $i < strlen($hash); $i += 2) {

$hashdec .= chr(hexdec(substr($hash, $i, 2)));

};

echo base64_encode($hashdec);

// Result  : HSmrc0sMlYUkAGmm5OPpG2HaGWk=

// Expected: HSmrc0sMlYUkAGmm5OPpG2HaGWk=

然后我尝试在javascript中复制它,但没有任何效果。

var magic ="258EAFA5-E914-47DA-95CA-C5AB0DC85B11";

var key ="4aRdFZG5uYrEUw8dsNLW6g==";

var magic_key = magic + key;

var hash = require('crypto').createHash('sha1').update(magic_key).digest('hex');

var buf = new Buffer(hash.length / 2);

for (var i = 0; i < hash.length; i += 2) {

var token = hash.substr(i, 2);

var int = parseInt(token.toString(16), 16);

var chr = String.fromCharCode(int);

buf.write(chr);

}

console.log(buf.toString('base64'));

// Result  : w53dAAEAAADBIIAFAQAAAGGAtwA=

// Expected: HSmrc0sMlYUkAGmm5OPpG2HaGWk=

这可能不是你想听到的,但我强烈建议把处理协议的工作留给其他人。它复杂多变。正在接受同行评审的开源解决方案将确保所有内容始终符合最新规范。node.js socket模块见本页

@Xeon06我很清楚。但因为我喜欢解剖东西以便更好地理解它们,所以我想做一个有效的POC。这不是我在生产环境中使用的东西。

啊,是的,我能理解。我自己做了自己的websocket服务器在乞讨只是为了学习,但后来转向了一个更稳定的解决方案。祝你的问题好运。

@Xeon06,总的来说,我不反对你不应该重新发明轮子。然而,协议并没有经常改变。它现在是IETF RFC标准。在标准化之前的一年中,Hybi的有线协议框架几乎没有变化。这些变化包括错误代码和标准措辞等。浏览器支持正在逐渐增加,所以感觉事情正在发生变化,但协议没有。

@卡纳卡啊,我明白了。感谢您的精确性。

有时阅读手册确实有帮助。

hash.digest([encoding])

Calculates the digest of all of the passed data to be hashed. The encoding can be 'hex', 'binary' or 'base64'.

(强调我的)

因此,通过将代码更改为:

var magicString ="258EAFA5-E914-47DA-95CA-C5AB0DC85B11";

var secWsKey = req.headers['sec-websocket-key'];

var hash = require('crypto')

.createHash('SHA1')

.update(secWsKey + magicString)

.digest('base64'); //

var handshake ="HTTP/1.1 101 Web Socket Protocol Handshake

" +

"Upgrade: WebSocket

" +

"Connection: Upgrade

" +

"Sec-WebSocket-Accept:" + hash +"

" +

"

";

socket.write(handshake);

是时候觉得自己很傻了。(再次)

使用http://pajhome.org.uk/crypt/md5/sha1.html和代码

b64pad ="=";

var b64hash = b64_sha1(secWsKey + magicString);

console.log(b64hash);

谢谢,但这已经解决了。(没有外部代码)看我自己的答案。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
WebSocket虽然很常见,但是我很少用到,源自某次群里的讨(吹)论(比),于是就实现了一下,一直没有整理代码,今天顺便写点分析,更多的也就是试着说一下自己是如何学习一个新接触的东西的。 一、简介 网上的介绍相当多,我就简单地理解优势,相对于HTTP,服务端可以不需要客户Duan去主动请求就可以[推送]数据。所以在聊天室、客服、推送等场景中的应用特别多。但是归根到底,它和HTTP都是TCP。 最权威的资料当然是RFC 6455 [The WebSocket Protocol],里面有各种标准定义,本源码以及分析也都是基于这个RFC:https://tools.ietf.org/html/rfc6455 这也是我的学习习惯,尽量看原版的权威资料 ,翻译或者博客经常有很多谬误,容易被误导,反而耽误时间。 二、抓包 ws:的抓包相当简单,任意一个可以抓取tcp数据的工具都可以,wss:则由于是SSL,都是密文,还是用网卡抓包工具的话分析起来就很麻烦。所以我是利用Chrome浏览器的开发者工具抓包。当然只是Opcode为Text的情况才可以利用这个来分析Frame信息,但是握手数据却是可以很简单看到的,二进制数据我没有做过,那大概就需要分析客户Duan代码(javascript)了。 三、握手 RFC6455 4.1 Client Requirements :https://tools.ietf.org/html/rfc6455#section-4.1 请求: 下面就是一个普通的握手请求,标注星号的不是必须。 GET / HTTP/1.1 Accept-Language: zh-CN Host: 121.40.165.18:8088//不是默认端口则跟上端口 Sec-WebSocket-Version: 13 Upgrade: websocket Sec-WebSocket-Key: 2mzaxLsKR++Hp0c5q2ufwg==//随机16byte的base64编码 Connection: Upgrade *User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36 *Origin:http://121.40.165.18 *Sec-WebSocket-Protocol: *Sec-WebSocket-Extensions: *Cookie: *Authorization: 响应: 下面就是一个普通的握手响应。 HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: Gk9vEODnOs/Kmjxy9leCLqw+9f8= 并不是每个ws的握手的响应的状态码都是101,如果不是101,则根据RFC rfc2616https://tools.ietf.org/html/rfc2616 来进行处理。如果状态码是401,则可能需要执行身份验证。 Sec-WebSocket-Accept 应当为Sec-WebSocket-Key + “258EAFA5-E914-47DA-95CA-C5AB0DC85B1” 的SHA1base64 四丶数据包 Base Framing Protocol:https://tools.ietf.org/html/rfc6455#section-5.2 数据包构造和解析应该是WebSocket学习中最重要的部分了,其实也就是看一看RFC就出来了。 下面我配合着RFC挨个解释下,也方便英文不太好的朋友: 1 byte(字节) = 8 bit(位)这种基础知识就不说了 Fin :1 bit 标识着这个 Frame 是不是一个消息中的最后一条 有的消息可能被拆成了若干个Frame RSV1, RSV2, RSV3 : 每个都是 1 bit 就是 Reserved(保留)的意思,在一些扩展协yi以外一般赋0。 Opcode :4 bits 操作码,标识着 Payload Data 的类型: OPCODE_CO

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值