主机头如何在托管多个服务器的物理主机上提供帮助？

Question

我有1台单机，IP 1.2.3.4。这台机器有2个Web服务器和一个ftp服务器：

• Web Server 1侦听端口82;它的域名：ws1.example.com
• Web Server 2侦听端口83;它的域名：ws2.example.com
• FTP服务器侦听端口21;它的域名：ftp.example.com

这就是DNS映射的样子：

ws1.example.com CNAME example.com
ws2.example.com CNAME example.com
ftp.example.com CNAME example.com
example.com A 1.2.3.4

案例1：我在浏览器URL ws1.example.com:82发出请求，DNS将我重定向到example.com但使用Host标头：ws1.example.com。

案例2：我在浏览器URL ws2.example.com:83处发出请求，并且DNS将我重定向到example.com但使用主机标头：ws2.example.com。

在这两种情况下：

• 请求最终到达同一台物理机器
• 当请求到达时： 在情况1中，请求到达该机器，并且正在侦听端口82即Web服务器1的应用程序处理该请求。 在情况2中，请求到达该机器，并且正在侦听端口83即Web服务器2的应用程序处理该请求。

据我所知，主机头用于通知接收主机识别哪个服务器（来自该IP托管的多个服务器）是该请求的意图，并相应地将请求定向到适当的应用程序。

我的问题是：

• 在此示例中，Host头的目的是什么，因为具有相同IP的相同物理机具有多个应用程序在其相应端口侦听。一旦请求到达此机器，相应的端口将无论如何都会被接收，其他应用程序将忽略该请求，因为端口与请求不匹配。那么，当apprpriate端口无论如何正在做他们的工作时，主机头在这里服务的目的是什么，对吧？
• 我能推断一下吗？ CNAMES 单个IP后面的多个Web服务器 随后使用Host标头解析对相应Web服务器的特定用户请求 只有当你使用像反向代理这样的东西时才有意义，例如1个机器与客户机接口，并将用户请求重定向到所有在同一端口上监听的不同机器上的相应Web服务器，例如80，每个在反向代理后面的网络中，在这种情况下，你有ws1.example.com和ws2.exmple.com都被重定向到反向代理example.com，这个反向代理现在转发到适当的主机基于主机头？

Answer 1

No DNS redirections

首先是一个重要的术语修复：

DNS中没有“重定向”。在您的情况下，DNS仅用于将名称映射到IP。有时，由于CNAME，名称会映射到另一个名称，然后映射到IP。是否存在类似的中间步骤并不重要，最后名称映射到IP（或者DNS解析失败）

这也意味着如果URL具有特定端口，那么不会更改，将通过URL中提到的端口查询最终IP。

重定向是HTTP级别的功能：在查询网络服务器以获取https://www.mygreatsite.example/foo时，它将使用HTTP返回代码301,302,303,307或308进行回复，并为您（HTTP客户端，即浏览器）提供要转到的新URL。

HTTP virtual hosting

在过去的好时光，IP地址是充足的。如果您在同一个物理盒上托管www.site1.example和www.site2.example，则可以为每个物理盒附加一个不同的IP地址。因此，在某种特定情况下，在某种程度上，HTTP host标头是无用的，仅仅连接到192.0.2.37或192.0.2.42的事实已经让你知道你想要的网站。事实上在HTTP/0.9没有host标题，因为根本没有标题。

但随后，随着大规模虚拟主机的发挥，以及IPv4地址变得稀缺，你不能再为每个站点附加一个IP地址，因为它也是一种浪费。因此，您通过DNS直接或间接（CNAME记录），两个网站都解析为相同的IP。

因此，当HTTP客户端连接到服务器时，默认情况下服务器无法知道您想要哪个网站。这就是为什么客户端填写的HTTP host标头让服务器知道您想要访问哪个网站，而不管其IP地址，这是通过DNS之前解决的。

默认情况下，HTTP使用端口80，因此在URL中通常不可见。当然如果你强迫你的客户在一边使用http://www.site1.example:4569而在另一边使用http://www.anothersite2.com:9873，那么你就是对了host标头并不是真的需要。除了该计划因许多原因而失败：

1. 端口号也不是无限空间，其中许多通常用于其他东西;因此，即使您在某一时刻扩展此方案，也无法将新网站附加到同一IP
2. 但比以前的技术要点更重要的是，对于人类而言，这将是一场噩梦，许多人会使用忘记端口号，然后没有进入相应的网站。

因此，通常不会这样做，如果您想通过HTTP公开某些给定服务，但在非默认端口中，您通常会在其前面安装反向代理。或者你从http://www.coolpublicname.example/到http://www.complicatedinternalname.example:9713进行HTTP重定向，但是客户端看到了这个赤裸裸的事实。

HTTPS virtual hosting

顺便提一下，HTTPS增加了一定程度的复杂性，因为HTTPS网络服务器需要将其证书发送到客户端，但由于每个网站都有不同的证书，因此需要知道客户想要使用哪个网站，这可以通过host HTTP标头，但随后在TLS握手完成后出现，因此在服务器发送证书的早期阶段，这还不可用。

因此，在HTTPS最早的时候，我们再次被迫做基于IP的虚拟主机，而不是基于名称的虚拟主机，因为在纯HTTP中可以使用host标头。

找到的解决方案是TLS扩展，服务器名称指示（SNI），客户端早期发送到服务器并提供网站名称，以便服务器可以发送相应的证书，因此我们重新开始营业基于名称的情况，理论上你可以有一个无限数量的名称解析为同一个IP，由一个给定的网络服务器提供服务。