标签：合法性   mamicode   请求   使用   htm   src   code   总结   结束   

WebSocket握手验证反爬虫

!

HTTP协议

请求头

服务器端创建 socket 服务后监听客户端，使用 while True 的方式读取客户端发送的消息

然后对服务器端发送的握手请求进验证，如果验证通过，则返回状态码为 101 的响应头，否则返回状态码为 403 的响应头

客户端按照 WebSocket 规范生成握手信息并向服务器端发送握手请求，然后读取服务器端推送的消息，最后验证握手信息

服务器端和客户端实际上可以不遵守这些约定

比如服务器可以在校验握手信息是增加对客户端 User-Agent 或 Referer （请求头）的验证，如果客户端发送的握手请求中并没有对应的信息，则拒绝连接

WebSocket 消息校验反爬虫

握手成功之后，双端就可以开始互推消息了

WebSocket 只需要完成 1 次握手，就可以保持长期连接，在后续的消息互发阶段是不需要用到 HTTP 协议的

其实消息互发阶段也是可以对客户端身份进行校验的，这是因为客户端所获取的消息是有服务器端主动推动的

如果服务器端不主动推送，那么客户端就无法获取信息

可以在服务器端新增一个逻辑：握手结束后客户端发送特定的消息，服务器端对该消息进行校验，校验通过则将服务器端的数据推送给客户端，否则不做处理

如果我们将客户端发送的新消息修改为数据仓库中没有的键，那么服务器端就不会给客户端推送消息

WebSocket Ping 反爬虫

通过刚才我们知道，WebSocket 是可以保持长期连接的，但是服务器端不可能保持所有客户端永久连接这太耗费资源了，

有没有一种方法可以检查客户端的状态呢？

WebSocket 协议规范中约定，服务器端可以向客户端发送 Ping 帧，当客户端收到 Ping 帧时应当回复 Pong 帧

如果客户端不回复或者回复的并不是 Pong 帧，那么服务器端就可以人为客户端异常，主动关闭该连接

? 通常，Ping 帧和 Pong 帧的 Plyload Data 中是没有内容的，所以只要目标服务器发送 Ping 帧时，客户端回复没有任何内容的 Pong 帧即可

总结

信息校验主要解决了客户端身份鉴别、数据来源判断和请求的合法性判断等问题，避免数据接收者使用被篡改过得数据，保证数据的有效性

无论是 HTTP 协议还是 WebSocket 协议，都需要对客户端身份进行鉴别，信息校验无疑是最合适的方法

WebSocket 反爬虫的产生跟协议规范有很大的关联，由于协议中的一些规范并不是强制实现的，所以开发者可以在服务器端与客户端握手和消息互传的过程叫做验证

WebSocket 反爬虫

标签：合法性   mamicode   请求   使用   htm   src   code   总结   结束   

原文地址：https://www.cnblogs.com/kai-/p/12242612.html