在 Glassfish 2 上为 HTTP 和 HTTPS 使用单个端口

Question

我有一个部署在 Glassfish 上的应用程序，并侦听端口 8181 的 HTTPS 流量（当前）。问题是在部署时，客户很少为服务器创建有效的证书。这意味着 HTTPS 无法通过证书检查。

我们希望通过 HTTP 获取我们的应用程序中的某些类型的内容，因为它是静态的，而且获取未加密这一事实不是问题。

我们遇到的问题是只有 8181 端口可供用户使用（防火墙等无法更改）。

因此，我们需要让 Glassfish 能够侦听端口 8181 上的传入连接并识别正在尝试的协议（@987654321@ 或 @987654322@）。

我已经看到了 Tomcat 的解决方案： https://serverfault.com/questions/47876/handling-http-and-https-requests-using-a-single-port-with-nginx#comment-37501

关于如何使用 Glassfish 执行此操作的任何想法？我们可以在那里实现一个钩子并适当地移交给任一处理程序（HTTP 或 HTTPS）吗？

Answer 1

我查看了那里的所有answers，它们的说法几乎相同： 由于 HTTP 和 HTTPS 之间的差异，这是不可能的。甚至浏览器也使用不同的默认端口来处理 HTTP/HTTPS。

为什么会这样：HTTP 基本上是文本协议，浏览器只是通过 TCP-IP 发送 HTTP（文本）标头。 HTTPS 不仅仅是基于 HTTP 的 SSL。首先浏览器执行“握手”，然后它从服务器接收证书，并且从服务器到浏览器的所有信息（反之亦然）都使用握手期间协商的对称密钥进行编码。

由于在非对称加密中使用了 2 个密钥（公钥和私钥），因此没有人（知道私钥的人除外）无法嗅探或更改信息。

实验：尝试执行以下操作： 将 https 更改为 http 并在末尾明确添加“443”（类似于 http://google.com:443） 您收到“连接已重置”或存储二进制文件（例如证书）的建议。

注意：通常服务器会拒绝此类请求。

因此，即使您使用相同的连接器来处理 HTTP 和 HHTPS 连接，您也应该使用不同的连接处理程序（我们在实现基于 Netty 的高负载服务器时遇到过这种情况）。

在同一个端口上使用 HTTP 和 HTTPS 的唯一可能性是使用“魔术识别器”，它会检查纯文本是否已到达或二进制握手。如果我们将该识别器放在容器端（Glassfish 协议处理程序），它将产生相当大的性能开销（检查每个请求是否为 SSL！）。如果我们把它放在代理服务器端（例如 nginx 或其他非阻塞服务器，例如 Netty），性能不会受到太大影响，但无论如何这并不能保证 100% 的成功。

注意：代理服务器只是识别，然后将请求转发到 2 个不同的端口！

作为结论：总的来说，这是可能的，但在我看来，所需的工作不值得结果。

编辑：正如@Bruno 回答的那样，有现成的魔术识别器，但 Glassfish 不正式支持。

Answer 2

您尝试执行的操作称为“端口统一”，should be supported by Glassfish 称为implemented in Grizzly。