我们来看看这个场景。
在传统的 LB 模型中，我们会让 LB（无论是否是反向代理）将请求/响应分发给应用程序级服务器。此模型适用于通用的请求/响应通信方式，但是当我们拥有持久连接时会发生什么情况呢？
让我们看一个 HTTP/2 示例。
这里我们没有简单的 Req/Rep 范例，我只需发送请求并对该请求进行负载平衡并获得响应即可。整个架构都是无状态的（忘记粘性会话，因为它具有与本例无关的含义）。我们有一个持久连接，例如 HTTP/2。
我无法将 HTTP/2 连接到 LB，否则 LB 将很快饱和，并且所有尚未与该 LB 建立套接字连接的客户端请求都将失败。如果他们依靠 DNS 指向该 LB，当我们用完套接字空间时，就会出现很多问题。
我们需要一些东西来将初始 SYN 请求重定向到另一台服务器，该服务器可能是另一个 LB 或应用程序层本身（忘记安全/外部攻击）。
客户端发送请求 s1.com --> （命中 DNS 并返回 ip .123）
然后，客户端向 .123 发送 HTTP/2 连接请求（这是一个 LB），但它不会连接并传递到应用程序层，而是向 ip .124 发送一个响应“重定向..类似于 HTTP 中的 302”。IP .124 可能是另一种 LB，也可能是应用程序层本身，实际套接字绑定到该层以进行 HTTP/2 通信。
.123 及其指向的节点的管理可以通过当前存在的各种工具来管理，但就这个“HTTP/2 重定向以平衡套接字负载问题”而言，我还没有找到解决方案。
有没有更好的方法来处理这个问题（再次强调不是针对内部服务而是针对外部请求）或者是否存在可以解决这个问题的代理/服务/系统？
DSR 略有不同，因为它在不同的层面上解决问题，当您有大量返回流量时，它确实很有用，但如果流量是双向的，它就无法解决问题（在许多云提供商上也不起作用）。DSR 对于媒体流和繁重的服务器响应流量非常有意义。
感谢您就此主题提供的任何见解或帮助！
如何