我们有许多 Jetty http(s) 服务器，都在不同的防火墙后面。http 服务器位于客户站点（不受我们控制）。在这些站点的防火墙中打开端口不是一种选择。目前，这些服务器仅提供 JSON 文档以响应 REST 请求。
我们有需要基于 URL 参数或标头值与给定 http 服务器交互的 Web 客户端。
这似乎是一个简单的代理服务器情况 - 除了防火墙。
我目前正在尝试的方法是这样的：
有一个集中的代理服务器（也是基于 Jetty 的）来监听来自远程 http 服务器的入站注册请求。注册请求将采用 Websocket 连接的形式，只要远程 HTTP 服务器可用，该连接就会保持活动状态。注册时，代理服务器将捕获 websocket 连接并将其映射到资源标识符。
Web 客户端将连接代理服务器，并在 URL 或标头中包含资源标识符。
代理服务器将确定要使用的适当 Websocket，然后将请求传递给 HTTP 服务器。所以请求和响应将通过 Websocket 传输。收到响应后，将返回给 Web 客户端。
所以这在理论上都很好 - 我想弄清楚的是：
a）有没有更好的方法来实现这一目标？
b) 设置 Jetty 以在管道的 HTTP 服务器端进行代理的最佳方法是什么？
我想我可以使用 Jetty 的 HttpClient，但我真正想做的只是从 websocket 中提取 HTTP 字节并将它们直接通过管道传输到 Jetty 连接器。解析所有内容似乎没有意义。我想我可以在 localhost 上打开一个常规套接字连接，从 websocket 中获取字节，然后这样做——但是像这样通过操作系统路由似乎很愚蠢（我已经在HTTP Server 的 Jetty 环境中运行） .
看起来这确实是可能已经解决的问题......也许通过使用适用于 WebSockets 而不是 TCP/IP 套接字的自定义码头连接？
更新：正如我一直在玩这个，似乎另一个棘手的问题是如何处理请求/响应行为（理想情况下支持通过 websocket 通道进行复用）。我发现的一个潜在资源是 websockets 的 WAMP 子协议： http ://wamp.ws/