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