典型场景：
1）客户端使用HTTPS在POST请求中将其凭据发送到服务器 .
2）服务器验证凭证是否正确并验证用户 . 因此，它将JWT（JSON Web令牌）返回给客户端 .
3）客户端打开 non secured WebSocket连接（ws：//） . 所以客户端和服务器现在有一个轻松交换数据的渠道（确切原因在这里无关紧要） .
4）用户通过WebSocket和JWT向服务器发送任何类型的请求，因此服务器可以验证这些请求是否合法 .
5）服务器使用WebSocket通道返回用户在成功验证每个请求的JWT后询问的数据 .
由于我们使用了HTTPS，因此我们假设JWT在发布时并未被盗（HTTPS可能会失败但我们认为它对我们来说是理智的） .
我们使用非安全WebSocket的事实意味着有人可以嗅探WebSocket Channels 的流量并在心跳中窃取JWT . 因此，我们使用WebSocket Secure（wss：//）代替并应用相同的先前场景 .
现在我们正在使用WebSocket Secure，当我们使用WSS通道时，我们是否需要在我们向服务器发出的每个请求中继续发送JWT？或者WebSocket安全通道是否足够安全，以便服务器和客户端100％确定（只要TLS未被击败）该通道是合法的？
换句话说：一旦安全地 Build 了WSS渠道，我们能相信它吗？ （直到连接明显关闭）
我真的不明白如何 Build WSS连接以及它一旦 Build 就如何工作 . 我的理解是：关键部分是握手，一旦完成握手，您就可以安全地依赖WSS通道（因为它可以防止使用TLS的MITM攻击，而WS不会这样做） .
关于这一切，我在最后几天阅读了很多内容，但有些概念仍不清楚 . 任何帮助将不胜感激！
1 回答
Websockets使用持久性TCP / IP连接 .
使用
wss类似于使用HTTPS，这意味着一旦SSL / TLS握手完成，所有Websocket数据在TLS包中都是"wrapped"（通常是编码的） .假设TLS / SSL连接是安全的，Websocket连接将保持安全，并且可能（并且可能应该）仅进行一次身份验证 .
因此，没有理由继续一次又一次地发送JWT . 这是使用连接的持久状态以便将用户“分配”给连接的更好解决方案 .
Side-Note ：虽然不安全，但即使使用Websocket连接"in the clear"（
ws://）也最好发送一次JWT，因为嗅出JWT的机会较少 .