什么是WebSocket？

Scrapeless Agent Browser通过Chrome DevTools协议公开WebSocket连接，以支持远程浏览器控制。

WebSocket是一种用于在长时间连接上进行双向消息交换的协议。客户端通过握手打开连接，然后客户端和服务器可以独立发送消息。这种模型适合需要持续命令和事件的实时仪表板、协作界面和浏览器控制会话。它与反复发送单独的HTTP请求以询问是否有任何变化有所不同。

打开的连接是一个传输，而不是关于每条消息的含义的承诺。应用程序必须定义消息类型、身份验证、排序期望，以及如何处理关闭的连接。本指南解释了协议边界和保持在其上的设计决策。

打开握手

WebSocket连接以与HTTP相关的握手开始。客户端请求升级通信，服务器可以接受或拒绝该请求。 WebSocket协议规范 定义了握手和消息帧。在成功握手后，各方交换WebSocket帧，而不是每条消息的普通HTTP响应体。

熟悉的ws和wss URL方案标识不安全和经过TLS保护的WebSocket连接。对于携带凭证或应用程序数据的远程服务，当提供者记录该安全形式时，请使用安全形式。确切的路径和查询参数属于服务合同；一个通用的WebSocket客户端无法猜测特定端点接受哪些消息。

打开请求可以包含来自浏览器的Origin值，服务器应该评估该Origin是否适合其用例。WebSocket安全性与浏览器CORS并不相同。应用程序授权仍然需要得到执行。成功的协议握手仅建立了一个通道；它并不授予通过它发送的每条消息的许可。

消息、帧和连接状态

WebSocket传输可能是文本或二进制的消息。一条消息可以由一个或多个帧承载，协议控制帧支持关闭连接和保持连接健康等功能。 MDN WebSocket API指南 介绍了打开连接和接收消息的浏览器接口。

应用程序决定文本消息的含义。股票更新可能是包含符号和价格的JSON；浏览器控制协议可以携带命令标识符和事件名称。解析消息格式并将其应用于应用状态是与维护套接字分开的任务。在更新图表或触发动作之前，验证每条传入消息。

连接可以正常关闭或意外关闭。客户端需要知道其最后的命令是否被确认，是否错过了更新，以及稍后会话应该从什么状态开始。一些应用程序提供序列号或快照来回答这些问题。如果没有这样的应用程序级设计，一个开放的连接仍然可以传递世界的不完整视图。

WebSocket与HTTP轮询的区别

在轮询中，客户端发送重复请求以询问新信息。WebSocket保持通道开放，以便任何一方可以在需要时发送消息。这可以减少重复请求的开销，并提高对频繁变化的数据的响应能力。收益取决于流量模式和部署；每小时检查一次状态的页面未必需要持久连接。

HTTP仍然用于创建资源、获取静态文档以及具有明确请求和响应的操作。当交换是持续的并且双方需要交谈时，WebSocket很有用。系统可以同时使用两者：首先使用HTTP加载初始页面并建立上下文，然后使用套接字进行实时更新。选择一种传输并不需要删除另一种。

Server-Sent Events提供了另一种实时更新模型，其中服务器通过HTTP响应向客户端发送事件。对于单向源，这可能更简单。WebSocket提供双向消息。在选择用于新功能的传输之前，比较通信方向、浏览器支持、基础设施行为和状态恢复。

浏览器自动化中的WebSocket

远程浏览器控制需要将命令传递给浏览器，并将事件返回给控制器。 Scrapeless Agent Browser 提供了一个记录的安全WebSocket端点，以通过支持的浏览器工具进行连接。 Agent Browser快速入门 解释了如何建立会话。WebSocket传输是通道；浏览器控制协议定义了命令词汇。

该浏览器内部的页面可能会打开其自己的WebSocket与一个网站。这是与控制器连接到Agent Browser的不同连接。混淆两者会导致错误的结论：观察浏览器控制套接字并不意味着目标页面使用实时套接字，捕获目标页面帧并不会暴露控制器的内部命令。

相关的 WebSocket帧捕获指南 显示如何在授权工作流程中观察页面创建的套接字流量。帧可能包含公共市场数据、私人账户信息或其他应用程序消息。仅检查任务权限范围内的数据，并避免不必要地记录令牌或个人有效载荷。

长期通道的操作挑战

打开的连接在两端都会消耗资源。服务器必须管理空闲客户端，并限制为慢接收者缓冲未发送数据的量。客户端必须决定在更新停止时如何显示过时的状态。浏览器的 WebSocket 接口并不能自动解决每种使用模式的背压，因此高容量流需要明确的负载测试和消息处理设计。

中介可以影响连接生命周期。反向代理、网关和网络变化可能会关闭空闲或长时间运行的连接，即使应用程序本身是健康的。定义应用程序如何检测关闭并从权威快照或游标恢复正确视图。不要假设新打开的套接字能够恢复旧套接字所看到的事件序列。

安全控制属于应用程序协议。根据服务合同对连接或消息进行身份验证，授权每个敏感操作，验证消息大小和类型，并在访问结束时关闭会话。 WebSocket 服务器指南 涵盖握手检查。安全传输保护传输中的数据；它并不能使不受信任的消息处理变得安全。

何时选择 WebSocket

当实际用例需要及时的双向交换时选择 WebSocket：协作编辑、互动控制、实时遥测或远程浏览器会话都是例子。定义所需的更新频率、最大消息大小和断开连接后的行为。协议将支持该通道，但应用程序必须定义正确性。

对于偶尔的读取，请从正常的 HTTP 操作开始。如果应用程序仅需要从服务器到客户端的更新，请比较服务器发送事件。如果它需要在同一持续通道上的命令和事件，WebSocket 就变得更具吸引力。测量代表性工作负载，而不是因为演示感觉更实时而选择协议。

像 HTTP API 一样仔细记录消息。命名每个消息类型，标识所需字段，并指定错误和关闭行为。从连接到清理测试预期的顺序。具有明确定义协议的应用程序可以有效地使用 WebSocket；具有未定义状态转换的应用程序可能会失败，尽管套接字功能完美。

实时数据消费者还需要一个清晰的快照边界。如果它在早期事件发生后加入流，它可能需要一个初始的 HTTP 快照，随后是更新该快照的消息。定义客户端如何识别快照与流之间的间隙。如果没有这个规则，即使是完美有序的套接字仍然可能显示不完整的账户余额或库存数量，因为客户端从未学习过起始状态。

结论

WebSocket 在打开握手后提供了一个持久的双向通道。它非常适合持续的命令和事件，包括远程浏览器控制，但它并不定义应用程序的消息含义或恢复行为。明确设计这些规则并在真实连接条件下验证它们。