我有一个部署在 Glassfish 上的应用程序，并侦听端口 8181 的 HTTPS 流量（当前）。问题是在部署时，客户很少为服务器创建有效证书。这意味着 HTTPS 无法通过证书检查。
我们的应用程序中有某种类型的内容我们希望通过 HTTP 获取，因为它是静态的，而且获取未加密的事实不是问题。
我们遇到的问题是只有端口 8181 可供用户使用（防火墙等无法更改）。
因此，我们需要一种方法让 Glassfish 监听端口 8181 上的传入连接并识别正在尝试的协议（https://myserver:8181或http://myserver:8181）。
我已经看到了 Tomcat 的解决方案： https ://serverfault.com/questions/47876/handling-http-and-https-requests-using-a-single-port-with-nginx#comment-37501
关于如何用 Glassfish 做到这一点的任何想法？我们可以在那里实现一个钩子并适当地移交给任一处理程序（HTTP 或 HTTPS）吗？
您正在尝试做的事情称为“端口统一”，并且应该得到 Glassfish的支持，正如在 Grizzly 中实现的那样。
我已经查看了那里的所有答案，它们的说法几乎相同：由于 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 并未正式支持它。