为什么我使用 websockets？
我正在通过 WebSocket 路由我的所有 HTTPS 请求，因为我的应用程序具有聊天功能，并且我需要在应用程序运行时保持 WebSocket 处于打开状态，所以为什么不直接通过它路由所有请求。
我的问题。
事实证明，说起来容易做起来。我是否应该使用相同的访问令牌和刷新令牌来验证客户端身份验证。或者我应该在连接打开时验证它，然后只要它打开就信任它。所以这是我的问题：
或者我应该在连接打开时验证它，然后只要它打开就信任它。
只要连接是通过受信任的通道（例如 ssl/tls）就可以了。
- wss（Web 套接字安全）是否足以阻止中间人攻击？
是的。Wss 只是 ws over ssl/tls。
- 我是否应该为每个 WebSocket 连接生成一种票证机制，持续 2 到 10 分钟，然后断开连接并要求客户端重新连接？
我不确定你为什么要那样做。相反，对于类似聊天的应用程序，您希望尽可能长时间地保持连接打开。尽管我建议在客户端实现 ping 调用并在服务器端实现超时。使用这种方法，您可以每隔 30 秒就要求客户端采取行动。
- 或者我应该对来自客户端的每个请求都有一个访问令牌。
不必要。使用 ssl/tls，您可以对整个连接进行一次身份验证，并且只需记住经过身份验证的服务器端。令牌与经典 HTTP 一起使用，因为它更容易水平扩展此类应用程序，例如连接到哪个服务器并不重要，您甚至可以在调用之间切换服务器并且不会影响身份验证。但是对于类似聊天的应用程序（或任何需要双向通信的应用程序），连接必须从一开始就保持不变，因此令牌会引入不必要的开销。
- 如何确保当服务器发送数据时它会发送到正确的客户端。
我不确定你的意思。无论如何，这几乎就是 tcp + ssl/tls 所保证的。对于任何其他基于安全 tcp 的协议也是如此。还是您的意思是在应用程序级别？好吧，一旦通过身份验证，您就必须将用户与相应的连接匹配。服务器必须对此进行跟踪。
- 我应该端到端加密所有有效负载以避免很多问题吗？
什么问题？E2E 加密的目的非常不同：它保证您，也就是服务器，无法读取消息。它保证了高度的隐私，因此即使服务器也无法读取消息，只能读取对等方。所以这是一个商业决策，而不是技术或安全决策。您想完全控制对话吗？那么显然你不能使用 E2E。另一方面，如果您想为用户提供最高级别的隐私，那么这是一个很好的（如果不是强制性的）方法。请注意，全功能 E2E 本质上比非 E2E 更难实现。
我需要在应用程序运行时保持 WebSocket 处于打开状态，所以为什么不直接通过它路由所有请求。
这是一个有趣的方法。我自己正在考虑这样做（并且很可能会尝试一下）。优点是整个通信都通过一个更容易调试的协议。另一个优点是，通过适当的协议，您可以获得更高的性能。缺点是经典的 HTTP 很好理解，有很多工具和子协议（例如 REST）覆盖它。安全性、二进制流（例如文件服务）等通常是开箱即用的。所以感觉有点像重新发明轮子。不管怎样，我祝你好运，希望你能回到我们身边，告诉我们进展如何。