HTTP：Web主机托管

喜欢ヅ旅行 2022-09-01 13:57 87阅读 0赞

> 对内容资源的存储、协调以及管理的职责统称为**Web主机托管**。主机托管是Web服务器的主要功能之一。保存并提供内容，记录对内容的访问以及管理内容都离不开服务器。如果不想自行管理服务器所需的软硬件，就需要主机托管服务，即**托管者**。托管者出租服务和网站管理维护业务，并提供各种不同程序的安全级别、报告以及易用性。托管者通常把很多网站放在一些强大的Web服务器上联合运行，这样可以获得更高的成本效益、可靠性和性能。

# 主机托管服务 #

因为很少有人由能力或者时间来搭建服务器机房，注册域名或者购买网络带宽，所以很多企业提供了专业化管理的Web主机托管服务。服务级别由很多种，从物理上的设备管理到完整的Web主机托管，顾客只需要提供内容就行了

本节主要探讨Web服务器要提供什么服务。网站运行需要的很多东西都取决于托管Web服务器提供的功能。

## 简单例子：专用托管 ##

租用专用的Web服务器，该服务器是由其他企业购买和维护的。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]

## 虚拟主机托管 ##

很多Web托管者通过让一些顾客共享一台计算机来提供便宜的Web主机托管服务。这称为**共享主机托管或者虚拟主机托管**。每个网站看起来是托管在不同的服务器上的，但实际上是托管在同一个物理服务器上。从最终用户的角度来看，被虚拟托管的网站应当和托管在专用服务器上的网站没有什么区别

从成本效益、空间以及管理方面考虑，提供虚拟主机托管的公司希望能够在同一个服务器上托管数百上千和网站----但这不一定意味着上千个网站是同一台PC来提供服务。托管者可以创建成排同样的服务器，称为**服务器集群**，把负载分摊在群里的服务器上。因为群里每台服务器都一样，并且托管了很多虚拟网站，所以管理起来更方便。

很多网站刚开始商务运作时，它们可能会选择虚拟主机托管，以节省费用，直到它们网站的流量规模达到值得使用专用服务器的水平为止。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]

## 虚拟服务器请求缺乏主机信息 ##

不幸的是，HTTP/1.0规范中没有为共享的Web服务器提供任何方法来识别要访问的是哪一个托管的网站。

HTTP/1.0请求在报文中只发送了URL的路径部分。如果要访问http://www.joes-hardware.com/index.html，浏览器会连接到服务器www.joes-hardware.com，但HTTP/1.0请求中只提到了GET /index.html，没有提到主机名。如果服务器虚拟托管了多个站点，就没有足够的信息能指出要访问的是哪个虚拟网站。如下图：

*  如果客户端A试图访问http://www.joes-hardware.com/index.html，请求GET /index.html将被发送到共享的Web服务器
 *  如果客户端A试图访问http://www.marys-antiques.com/index.html，请求GET /index.html将被发送到共享的Web服务器  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]  
    就Web服务器而言，没有足够的信息可以供其判断究竟要访问的是哪个网站。尽管请求的是完全不同的文档，但这两个请求看起来是一样的，这是因为网站的主机信息已经从请求中剥离了。

## 设法让虚拟主机托管正常工作 ##

缺失主机信息是原始HTTP规范的疏忽，它错误的假设了每个Web服务器上只托管了一个网站。HTTP设计者没有为进行虚拟主机托管的共享服务器提供支持。正因为如此，URL中的主机名信息被当做冗余信息剥离了，只要求发送路径部分。

HTTP/1.1解决了这个问题，但是一定要用HTTP/1.0怎么办？有四种方法：

*  **通过URL路径进行虚拟主机托管**：在URL中增添了专门的路径部分，以便服务器判断是哪个网站
 *  **通过端口号进行主机托管**：为每个站点分配不同的端口号，这样请求就由Web服务器的单独实例来处理
 *  **通过IP地址进行主机托管**：为不同的虚拟站点分配专门的IP地址，把这些地址都绑定到一台单独的机器上。这样，Web服务器就可以通过IP地址来识别网站名了
 *  **通过Host首部进行主机托管**：HTTP/1.0的增强版和HTTP/1.1的正式版定义了Host请求首部来携带网站名称。Web服务器可以通过Host首部识别虚拟站点。

### 通过URL路径进行虚拟主机托管 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 3]

### 通过端口号进行虚拟主机托管 ###

![在这里插入图片描述][91ffba8b9d43432099b8a9ae9f38d607.png]

### 通过IP地址进行虚拟主机托管 ###

一个更常用的、更好的方法是通过IP地址进行虚拟化。每个虚拟网站都分配一个或者多个唯一的IP地址。**所有虚拟网站的IP地址都绑定到同一个共享的服务器上**。服务器可以查询HTTP连接的目的IP地址，并以此来判断客户端的目标网站。

比如说，托管者把IP地址209.172.34.3分配给www.joes-hardware.com，把IP地址209.173.34.4分配给www.marys-antiques.com，把这个两个IP地址都绑定到同一个物理服务器上。Web服务器就能使用目的IP地址来识别用户请求的是哪个虚拟站点了，如下图：

*  客户端A获取http://www.joes-hardware.com/index.html
 *  客户端A查询www.joes-hardware.com的IP地址，得到209.172.34.3
 *  客户端A打开到共享服务器的TCP连接，目的地址是209.172.34.3
 *  客户端A发送请求，内容为GET /index.html HTTP/1.0
 *  在Web服务器提供响应之前，它注意到实际的目的IP地址(209.172.34.3)，判断出这时joe的网站的虚拟IP地址，就根据子目录/joe来完成请求，返回文件/joe/index.html

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 4]  
对大的托管者来说，虚拟IP的主机托管能够工作，但也会带来一些麻烦。

*  在计算机系统上能绑定的虚拟IP地址往往是有限制的。
 *  IP地址是稀缺资源。由很多虚拟站点的托管者不一定能为被托管的网站获取足够多的IP地址

虽然有着上面的缺点，但是还是用的比较广泛

### 通过Host首部进行虚拟主机托管 ###

为了避免过度的地址消耗和虚拟IP地址的限制，我们希望在虚拟站点间共享同一个IP地址，而且仍能区分站点。但正如我们看到的那样，因为大多数浏览器只是把URL的路径发给服务器，关键的虚拟主机名信息被丢弃了。

为了解决这个问题，浏览器和服务器的实现者扩展了HTTP，把原始的主机名提供给服务器。不过，浏览器不能只发送完整的URL，因为这会使得很多只能接收路径的服务器无法工作。替代方法是，把主机名(和端口号)放在所有请求的Host扩展首部中传送。

下图中，客户端A和客户端B都发送了携带有要访问的原始主机名的Host首部。当服务器收到对`/index.html`的请求时，可以通过Host首部来判断是要使用哪个资源。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 5]

## HTTP/1.1的Host首部 ##

Host首部描述了所请求的资源所在的因特网主机和端口号，语法如下：  
![在这里插入图片描述][f0ccadbd50b547039ab7ab8dda90c49b.png]  
看个例子：

![在这里插入图片描述][662b9cb9e32841e4b6aadfa15735cb8e.png]

# 使网站更可靠 #

下面情况中，网站通常是无法运作的：

*  服务器宕机的时候
 *  交通拥塞：突然由很多人访问网站。突然的拥塞可以使Web服务器挂载，降低其响应速度，甚至使得它彻底死机
 *  网站中断或者掉线

## 镜像的服务器集群 ##

服务器集群是一排配置相同的Web服务器，相互可以替换。每个服务器上的内容可以通过镜像复制，这样当某个服务器出问题的时候，其他的可以顶上。

镜像的服务器通常组成层次化的关系。某个服务器可能充当“内容权威”-----它含有原始内容，这个服务器称为**主原始服务器**(master origin server)。从主原始服务器接收内容的镜像服务器称为**复制原始服务器**(replica origin server)。一种简单的部署服务器集群的方法是用网络交换机把请求分发给服务器。托管在服务器上的每个网站的IP地址就设置为交换机的IP地址。

如下图镜像服务器集群中，主原始服务器负责把内容发送给复制原始服务器。对集群外部来说，内容所在的IP地址就是交换机的IP地址。交换机负责把请求发送到服务器上去。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 6]  
镜像Web服务器可以在不同的地点包含同样的内容的副本。如下图展示了4个镜像服务器，其中主服务器在芝加哥，复制服务器在纽约、迈阿密和小石城。主服务器为芝加哥地区的客户端服务，并肩负把内容传播给复制服务器的任务。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 7]  
如上场景中，有以下两种方法把客户端的请求导向特定的服务器：

*  **HTTP重定向**：该内容的URL会解析到主服务器的IP地址，然后它会发送重定向到复制服务器
 *  **DNS重定向**：该内容的URL会解析4个IP地址，DNS服务器可以选择发送给客户端的IP地址

## 内容分发网络 ##

简单地说，内容分发网络(CDN)就是对特定内容进行分发的专门网络。这个网络中的节点可以是Web服务器、反向代理或者缓存。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20220829/d88ead32ad2942edb7d40a55725b537e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]: /images/20220829/11c35c87ab694e52853bb941e23d7be7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]: /images/20220829/7847c4741af94c7fb76e9dea12ffc52e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 3]: /images/20220829/6b340bff53374f0d9e2d80b9c4be75e7.png
[91ffba8b9d43432099b8a9ae9f38d607.png]: /images/20220829/713d9591be1f46298ccf5024b5fb5453.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 4]: /images/20220829/1ead124c8da94a49bb7965cdea66cb74.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 5]: /images/20220829/a476b77d8f0e4fcea0dd7ea507abf8ac.png
[f0ccadbd50b547039ab7ab8dda90c49b.png]: /images/20220829/4c78fe01d75f4de89c14593ed25f66b5.png
[662b9cb9e32841e4b6aadfa15735cb8e.png]: /images/20220829/705d7e9705eb4b18b00d0c5da3b06fea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 6]: /images/20220829/c5c1f03c691f4819870a8da4955e646f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 7]: /images/20220829/a6a76d236e4b498eadb201197ffa27d7.png