我为什么要使用websocket
我正在通过WebSocket路由我的所有HTTPS请求，因为我的应用程序有聊天功能，我需要在应用程序运行时保持WebSocket打开，所以为什么不通过它路由所有请求呢？
我的问题
这说起来容易做起来难。我应该使用相同的访问令牌&刷新令牌以验证客户端身份验证。或者我应该在连接打开时验证它，然后在它打开的时候一直信任它。以下是我的问题：
- wss(Web套接字安全(是否足以阻止中间人攻击
- 我是否应该为每个WebSocket连接生成一个票证类型的机制，持续2-10分钟，然后断开连接并要求客户端重新连接
- 或者我应该为客户端的每个请求都提供一个访问令牌
- 如何确保当服务器发送数据时，它会发送到正确的客户端
- 我应该对所有有效载荷进行端到端加密以避免很多问题吗
或者我应该在连接打开时验证它，然后在它打开的时候信任它。
只要连接是通过受信任的通道(例如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(涵盖了它。安全性、二进制流(如文件服务(等通常是开箱即用的。所以这感觉有点像重新发明轮子。不管怎样，我祝你好运，希望你能回来告诉我们事情的进展。