我编写了一个多进程的实时Websocket服务器，该服务器使用会话ID根据正在侦听的端口号使用会话ID向相关工人加载平衡流量。会话ID包含主机名，源端口号，工作端口号和工人用来唯一标识客户端的实际哈希ID。典型的会话ID看起来像这样：
localhost_9100_8000_0_aot_eiwv0w4hqz_naaav
我想知道将工作端口号（在这种情况下为9100）作为会话ID的一部分。
我有点担心拒绝服务（DOS）威胁 - 从理论上讲，这可能会使恶意用户能够生成针对特定端口号的大量http请求（例如，使用包含的伪造session，该端口号） - 但这是一个严重的威胁吗？（假设您有体面的防火墙）？像Google这样的大公司如何从安全角度处理粘性会话？
我还应该考虑其他威胁吗？
我这样设计的服务器的原因是要考虑初始的HTTP握手以及客户端不支持WebSocket的何时（在这种情况下，使用http long -polling-使用 - 因此，随后从客户端需要的HTTP请求要转到后端的同一工人）。
，因此您的问题中有几个子问题。我会尝试将它们分开并相应地回答：
在特定工人身上的dos-stake是严重的威胁吗？
这取决于。如果您有100个用户，则可能没有。但是您可以肯定的是，那里的人会查看您的应用程序，并会尝试找出弱点并利用这些弱点。
现在，如果您只能攻击整个服务器，那么对单个工人的DOS攻击是一种严重的可能性吗？我实际上会说是的，因为这是一个更精确的攻击=>当您一一做工人时，您需要更少的资源来杀死工人。但是，如果仅允许从端口80上的外部连接HTTP并阻止其他所有问题，则将解决此问题。
像Google这样的大公司如何处理粘性会话？
简单的答案 - 谁说，他们做到了？当您拥有分布式系统时，还有多种其他方法可以解决会话问题：
- 不要基于服务器存储任何会话，只需在cooky中使用一个键，您可以再次识别用户，与自动登录类似。
- 将会话状态存储在数据库或对象存储中（这会添加很多开销）
- 将会话信息存储在代理中（或经纪人，http端点，...），并将其与请求一起发送给下一个工人
我还应该考虑其他威胁吗？
总是有不可预见的威胁，这就是原因，为什么您永远不应该发布更多信息。在这种情况下，大多数大公司甚至都不发布其Web服务器的正确名称和版本（例如，Google是gws）
话虽如此，我明白您的意思是您为什么要保持实现，但也许您可以将其稍微修改以将其存储在负载平衡器中，该字典具有HostName，源端口号，Worker Port编号和作为会话ID，有两个哈希的集合。比负载平衡器通过查看词典所知道的是需要发送的工人。该信息应与时间戳一起保存，当该信息在上次检索到该信息时，每分钟都可以删除未使用的数据。