我在TCP端口91托pipe我的网站。
有没有办法在同一个端口91绑定他们的SSL证书？
我在TCP端口91托pipe我的网站。有没有办法在同一个端口91绑定他们的SSL证书？
我将这个问题解释为“我在http://www.mysite.example:91/上运行我的站点，并且我也想通过https://www.mysite.example:91/在HTTPS上运行它” （在这种情况下，它不是同一个IP地址和同一个端口上的多个SSL域的重复，如同临时标记的那样）。
这可以使用由例如Grizzly（Java web服务器）支持的端口统一来完成。 （你的问题没有说你想使用哪个服务器。）
端口统一可以适用于客户端首先要与之交谈的任何协议（例如HTTP，SSL / TLS，而不是IMAP，…）。
从本质上讲，服务器在分派请求之前，试着通过查看请求的开始来检测使用哪个协议。 如果它收到GET / ...它可以认为它是一个HTTP请求。 如果它收到一个ClientHello ，它可以认为它是一个SSL / TLS请求（如果需要的话，可能会被redirect到适当的顶层协议，在这种情况下是HTTP over TLS ）。
支持这个function是非常不寻常的，但它的工作原理。 但是，如果URL不是默认值，则必须在URL中明确指定端口（80将始终是http://的缺省值，而443将始终是https://的缺省值）。
我不知道这个function是在Apache Httpd中实现的，但这在原则上不是问题。 其他答案提到，两个服务（或两个进程）不能在同一个端口上侦听。 这是真的，但没有什么能阻止相同的服务器/进程能够处理多个站点（Apache Httpd在同一进程监听多个端口（例如80和443，并且VirtualHost在后面调度）时能够很好地执行）。
回到“ 可能的重复问题 ”，另一个解决scheme可能是使用RFC 2817 ，正如在这个答案中提到的。 不幸的是，虽然这个答案提到了这个RFC，但它显示的日志表明，在SSL / TLSstream量之前， curl并不是纯HTTPstream量，这将表明它使用了服务器名称指示（SNI）而不是RFC 2817.另外，没有意识到任何RFC 2817的实现，而curl在那个答案时已经支持SNI。
与支持端口统一相比，支持RFC 2817要复杂得多，因为它需要客户端和服务器端的支持，包括在协议中间进行升级的能力。 （这不是世界末日，SMTP，LDAP等都可以这样做，但是这些协议已经得到了广泛的支持。）
相比之下，端口统一只需要改变服务器端的初始调度机制。 只要在URL中明确指定端口，任何浏览器都将在客户端支持它。
它不起作用。 每个端口只能绑定一个服务。
两个服务不能使用TCP在同一个系统上的相同端口上侦听。 您可以使用NAT并将来自不同位置的stream量路由到同一端口上的不同内部地址，但外部IP无法在同一端口上同时使用这两个服务。
当用户代理或客户端发起HTTPS请求时，它使用默认端口443 。 HTTP的默认端口是80 。
如果您的服务器正在侦听另一个端口（91），那么您需要将端口443转发到此端口，因此当有人键入https://www.example.com/时 ，它将指向侦听端口91的服务器。
您不能让http://www.example.com/和https://www.example.com/在同一个端口上运行，因为只有一个进程可以在端口上侦听。 如果服务器有多个IP地址，您可以让他们在同一台服务器上侦听。
如果您的服务器只有https站点，那么转发443到91，并将您的服务器切换到HTTPS将工作。