88、深入解析 Web 托管：从基础到实践

最新推荐文章于 2025-12-08 16:09:41 发布

青柠汽水308

最新推荐文章于 2025-12-08 16:09:41 发布

阅读量31

点赞数

CC 4.0 BY-SA版权

分类专栏： UNIX/Linux系统管理精要文章标签： Web托管 Apache HTTP服务器

本文链接：https://blog.youkuaiyun.com/solidity8miner/article/details/155906205

UNIX/Linux系统管理精要专栏收录该内容

99 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

深入解析 Web 托管：从基础到实践

1. Web 托管基础

在当今的网络环境中，UNIX 和 Linux 系统是提供 Web 内容和应用程序的主流平台。这是因为它们从设计之初就是抢占式多任务系统，能够高效、安全且可靠地处理大量的 Web 请求。

基于 Web 的应用程序在一定程度上简化了系统管理员的工作。像 AJAX（异步 JavaScript 和 XML）和动态 HTML 这样的“Web 2.0”特性，为用户带来了与本地安装应用程序相同的功能和响应速度，同时也减轻了系统管理员在部署方面的困扰，因为客户端只需要一个 Web 浏览器即可。

在服务器端，LAMP（Linux、Apache、MySQL 和 PHP/Perl/Python）堆栈是一种常见且功能强大的配置。对于数据库驱动的应用程序，基于 Ruby 语言构建的 Ruby on Rails 是一个流行的开源 Web 应用程序框架。这两种堆栈都是不错的选择，并且易于维护。

1.1 网站托管的基本原理

网站托管与提供其他网络服务本质上并无太大差异。一个守护进程会监听 TCP 端口 80（HTTP 标准端口）上的连接，接收文档请求，并将其传输到请求用户的浏览器。许多文档是与数据库和应用程序框架结合动态生成的，但这并不影响底层的 HTTP 协议。

1.2 网络资源定位

互联网上的信息由互联网协会（ISOC）定义的架构进行组织。ISOC 定义了三种主要的资源标识方式：统一资源标识符（URI）、统一资源定位符（URL）和统一资源名称（URN）。URL 和 URN 实际上是 URI 的特殊类型，它们的关系如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(URI):::process -->|is-kind-of| B(URL):::process
    A(URI):::process -->|is-kind-of| C(URN):::process

它们的区别在于：
- URL 通过描述资源的主要访问机制来告诉用户如何定位资源，例如 http://admin.com 。
- URN 用于标识资源，而不暗示其位置或访问方式，例如 urn:isbn:0-13-020601-6 。

如果资源只能通过互联网访问，则称为 URL；如果资源可以通过互联网或其他方式访问，则使用 URI。

1.3 统一资源定位符

大多数情况下，我们处理的是 URL，它通过五个基本组件描述如何访问对象：
- 协议或应用程序
- 主机名
- TCP/IP 端口（可选）
- 目录（可选）
- 文件名（可选）

1.4 HTTP 工作原理

HTTP 是一种无状态的客户端/服务器协议。客户端向服务器请求特定 URL 的“内容”，服务器要么返回一段数据，要么返回某种错误消息。客户端可以继续请求另一个对象。

由于 HTTP 非常简单，我们可以通过运行 telnet 将自己变成一个简单的 Web 浏览器。只需使用 telnet 连接到所选 Web 服务器的 80 端口，连接成功后即可发出 HTTP 命令。

最常见的命令是 GET，用于请求文档的内容。通常， GET / 用于请求所连接服务器的根文档（通常是主页）。HTTP 是区分大小写的，所以请确保以大写字母输入命令。

示例代码如下：

$ telnet localhost 80
Trying 127.0.0.1…
Connected to localhost.atrust.com.
Escape character is '^]'.
GET / 
<contents of your default file appear here> 
Connection closed by foreign host.

一个更“完整”的 HTTP 请求会包括 HTTP 协议版本、请求的主机（从基于名称的虚拟主机检索文件时需要）和其他信息。响应将包括信息头和响应数据。例如：

$ telnet localhost 80
Trying 127.0.0.1…
Connected to localhost.atrust.com.
Escape character is '^]'.
GET / HTTP/1.1 
Host: www.atrust.com 
HTTP/1.1 200 OK
Date: Sat, 01 Aug 2009 17:43:10 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Sat, 01 Aug 2009 16:20:22 GMT
Content-Length: 7044
Content-Type: text/html
<contents of your default file appear here> 
Connection closed by foreign host.

在这个例子中，我们告诉服务器我们将使用 HTTP 1.1 协议，并指定了请求信息的虚拟主机。服务器返回了状态码（ HTTP/1.1 200 OK ）、当前日期和时间、运行的服务器软件名称和版本、请求文件的最后修改日期、请求文件的长度以及请求文件的内容类型。头信息和内容之间用一个空行分隔。

1.5 动态内容生成

除了提供静态文档外，HTTP 服务器还可以为用户提供动态生成的内容。例如，如果要为访问网站的用户提供当前的时间和温度，可以让 HTTP 服务器执行一个脚本以获取这些信息。这种技巧通常通过通用网关接口（CGI）实现。

CGI 不是一种编程语言，而是 HTTP 服务器与其他程序交换信息的规范。CGI 脚本通常用 Perl、Python 或 PHP 编写，但实际上，任何能够执行实时 I/O 的编程语言都是可以接受的。

1.6 嵌入式解释器

CGI 模型提供了完全的灵活性，因为 Web 开发人员可以自由使用任何解释器或脚本语言。然而，在处理大量动态内容的繁忙 Web 服务器上，为每个脚本调用启动一个单独的进程可能会导致性能问题。

许多 Web 服务器除了支持外部 CGI 脚本外，还定义了一种插件架构，允许将 Perl 和 PHP 等脚本解释器嵌入到 Web 服务器本身。这种捆绑方式显著提高了性能，因为 Web 服务器不再需要为每个脚本请求派生一个单独的进程。这种架构对脚本开发人员来说基本上是透明的。

1.7 FastCGI

在某些情况下，可以使用 FastCGI（fastcgi.com）来提高脚本的性能。这个模块通过启动脚本一次，然后让它们持续运行以处理多个请求，从而分摊了解释器启动和脚本解析的成本。在某些情况下，它可能比在 Apache 内部运行解释器更快。

然而，脚本必须进行修改以适应与 Web 服务器的这种新交互方式。基本协议易于实现，但 FastCGI 脚本在内存管理方面不能马虎。如果处理不当，脚本的内存占用会随着时间的推移而增加。另一个潜在的风险是请求之间的数据持久化，程序员必须确保请求之间不会相互影响。Web 开发人员需要权衡 FastCGI 带来的性能提升是否值得付出额外的努力和风险。

一些管理员更喜欢 FastCGI 而不是嵌入式解释器，因为当单个脚本出现问题时，可以在不影响系统其他部分的情况下重新启动。而使用嵌入式解释器时，如果某个解释器出现问题，可能需要重启整个 Web 服务器。

1.8 脚本安全

CGI 脚本和服务器插件主要是 Web 开发人员和程序员的关注点，但在安全方面与系统管理员的工作产生了交集。由于 CGI 脚本和插件可以访问文件、网络连接和其他数据传输方式，它们的执行可能会影响运行 HTTP 服务器的机器的安全性。最终，CGI 脚本或插件使世界上任何人都能够在你的服务器上运行程序（脚本）。

因此，CGI 脚本和插件处理的文件必须与其他可通过网络访问的程序一样安全。开放 Web 应用程序安全项目（OWASP，owasp.org）发布了各种关于 Web 安全的优秀资料。

1.9 应用程序服务器

复杂的企业应用程序可能需要比基本 HTTP 服务器更多的功能。例如，现代 Web 2.0 页面通常包含与动态数据馈送（如股票行情）相关的子组件。虽然可以通过 AJAX 和 JavaScript 对象表示法（JSON）等技术在 Apache 中实现这些功能，但一些开发人员更喜欢使用功能更丰富的语言，如 Java。

将 Java 应用程序与企业的其他数据源集成的常见方法是使用“servlet”。Servlet 是在应用程序服务器平台上运行的 Java 程序。应用程序服务器可以独立工作，也可以与 Apache 协同工作。

如果需要支持这些应用程序服务器之一，建议寻求特定产品的文档和培训。

1.10 负载均衡

很难预测服务器在单位时间内能够处理多少点击量（对对象的请求，包括图像）或页面浏览量（对 HTML 页面的请求）。服务器的容量取决于系统的硬件架构（包括子系统）、运行的操作系统、系统调优的程度和重点，以及最重要的是所服务网站的结构（是否仅包含静态 HTML 页面，还是需要进行数据库调用和数值计算）。

只有通过在实际硬件上对实际网站进行直接基准测试和测量，才能回答“能处理多少点击量”这个问题。有时，在类似硬件上构建过类似网站的人可以提供一些有用的规划信息。但无论如何，都不应轻信系统供应商提供的数字。同时，带宽也是一个关键因素，一台提供静态 HTML 文件和图像的机器很容易就能使 OC3（155 Mb/s）链路饱和。

相比单服务器的点击量统计，更值得关注的参数是可扩展性。Web 服务器通常在以太网接口饱和之前就会受到 CPU 或 I/O 的限制。因此，确保你和你的 Web 设计团队计划将高流量网站的负载分散到多个服务器上是很重要的。

负载均衡可以提高性能和冗余性。常见的负载均衡方法有以下几种：
- 轮询 DNS ：这是最简单和最原始的负载均衡形式。在这种系统中，多个 IP 地址被分配给一个主机名。当请求网站的 IP 地址到达名称服务器时，客户端会收到其中一个 IP 地址作为响应。地址按照“轮询”顺序依次分配。

例如，查询 www.google.com 的 DNS 记录可能会得到如下结果：

$ dig www.google.com a
…
;; QUESTION SECTION:
;www.google.com.    IN    A
;; ANSWER SECTION:
www.google.com.    0    IN    CNAME    www.l.google.com.
www.l.google.com.    65    IN    A    74.125.95.104
www.l.google.com.    65    IN    A    74.125.95.105
www.l.google.com.    65    IN    A    74.125.95.106
www.l.google.com.    65    IN    A    74.125.95.147
www.l.google.com.    65    IN    A    74.125.95.99
www.l.google.com.    65    IN    A    74.125.95.103

在这个例子中， www.google.com 映射到规范名称 www.l.google.com 。Google 增加这一层间接性，以便将内容分发责任委托给下游提供商（如 Akamai），而无需将根域名的控制权交给 CDN。

DNS 客户端可以随机选择 www.l.google.com 返回的任何一个 A 记录。与普遍看法相反，A 记录的返回顺序没有意义，第一个记录并不是“主”记录。由于客户端随机选择地址，该网站的负载大致均匀地分布在这六台服务器上。

轮询 DNS 的问题在于，如果服务器出现故障，必须更新 DNS 数据以将流量重新路由。A 记录的长超时可能会使此操作变得棘手和不可靠，而短超时则会阻碍缓存，使网站的 DNS 查找变慢且更消耗资源。

负载均衡硬件 ：这是轮询 DNS 的一种简单替代方案，但需要一定的资金投入。商业第三方负载均衡硬件包括 F5 Networks 的 Big-IP 控制器、北电的 Alteon 网络交换产品和思科的内容服务交换机。这些产品根据各种可配置参数分配传入的工作，并可以考虑单个服务器的当前响应时间。
基于软件的负载均衡器 ：不需要专门的硬件，可以在 UNIX 服务器上运行。既有开源解决方案，也有商业解决方案。开源解决方案包括 Linux 虚拟服务器（linuxvirtualserver.org）和 Apache 2.2 中引入的代理负载均衡功能（mod_proxy_balancer）。商业解决方案的一个例子是 Zeus（zeus.com）销售的产品。

Google 实际上结合使用了自定义负载均衡 DNS 服务器（带有轮询记录）和负载均衡硬件。

需要注意的是，如今大多数网站都是动态生成的，这种架构会给数据库服务器带来很大的负载。如有必要，请咨询数据库管理员，以确定在多个数据库服务器之间分配负载的最佳方法。

2. HTTP 服务器安装

安装和维护 Web 服务器相对简单，Web 服务在复杂度和管理难度上远低于电子邮件和 DNS。

2.1 选择服务器

有多种 HTTP 服务器可供选择，但通常建议从 Apache 服务器开始。Apache 以其灵活性和性能在行业中闻名。截至 2010 年 1 月，互联网上 54% 的 Web 服务器运行 Apache（目前为超过 1.11 亿个网站提供内容），微软的服务器占比 24%。Apache 和微软之间的市场份额在过去五年中相对稳定。

可以在 news.netcraft.com/archives/web_server_survey.html 查看更详细的市场份额统计数据，在 serverwatch.com/stypes （在“Server Type”菜单中选择“web”）找到当前可用 HTTP 服务器的有用比较。选择服务器时，可以考虑以下因素：
- 健壮性
- 性能
- 更新和修复漏洞的及时性
- 源代码的可用性
- 商业或社区支持的程度
- 成本
- 访问控制和安全性
- 作为代理的能力
- 处理加密的能力

Apache HTTP 服务器是免费的，可以从 Apache Group 网站（apache.org）获取完整的源代码。不太愿意自己编译的人可以安装预构建的二进制包。一些供应商可能避免使用“Apache”这个名称，但实际上提供的就是 Apache 服务器。

2.2 安装 Apache

如果决定下载 Apache 源代码并自行编译，首先执行发行版中包含的 configure 脚本。该脚本会自动检测系统类型并设置适当的 makefile。可以使用 --prefix 选项指定 Apache 服务器在目录树中的位置。例如：

$ ./configure --prefix=/etc/httpd/

如果不指定前缀，默认位置是 /usr/local/apache2 。

可以使用 configure --help 查看所有可能的参数，其中大部分是 --enable-module 和 --disable-module 选项，用于包含或排除 Web 服务器中的各种功能组件。

也可以通过指定 --enable-module=shared 选项将模块编译成动态共享对象文件（或使用 --enabled-mods-shared=all 使所有模块都为共享）。这样，以后可以决定包含或排除哪些模块，只有在 httpd 配置中指定的模块才会在运行时加载。这实际上是仅二进制 Apache 包的默认配置，所有模块都编译成共享对象，并在 Apache 启动时动态加载。

使用共享库的唯一缺点是启动时间会稍长，性能会有轻微下降（通常小于 5%）。对于大多数网站来说，能够动态添加新模块和关闭现有模块而无需重新编译的好处，超过了轻微的性能损失。

当 configure 脚本执行完毕后，运行 make 命令，然后运行 make install 命令来实际编译和安装相应的文件。

需要注意的是，在 AIX 上编译 Apache 并不那么简单，可以参考 people.apache.org/~trawick/apache-2-on-aix.html 中的提示和技巧。

2.3 配置 Apache

安装服务器后，需要根据自己的环境进行配置。配置文件位于安装目录的 conf 子目录中。需要检查并自定义 httpd.conf 文件，该文件分为三个部分：

第一部分处理全局设置，如服务器池、HTTP 服务器监听查询的 TCP 端口（通常是 80 端口，但也可以选择其他端口，并且可以在一台机器上的不同端口运行多个 HTTP 服务器）以及动态模块加载的设置。
第二部分配置“默认”服务器，即处理未被虚拟主机定义（VirtualHost）响应的请求的服务器。此部分的配置参数包括服务器将以哪个用户和组的身份运行（不能是 root 用户！）以及重要的 DocumentRoot 语句，该语句定义了提供文档的目录树的根。这部分还处理一些“特殊”URL 的问题，例如包含 ~user 语法以访问用户主目录的 URL。

在配置文件的第二部分还需要管理全局安全问题。可以使用指令控制对文件或目录的访问，这些权限设置可以防止通过 httpd 访问敏感文件。建议至少指定两个访问控制：一个覆盖整个文件系统，另一个应用于主文档文件夹。Apache 默认的设置已经足够，但建议删除 AllowSymLinks 选项，以防止 httpd 遵循文档树中的符号链接，避免意外创建指向 /etc 等敏感目录的符号链接。更多 Apache 安全提示可以参考 httpd.apache.org/docs-2.2/misc/security_tips.html 。

第三部分配置虚拟主机，后续会详细讨论这个话题。

完成配置更改后，可以运行 httpd -t 命令检查配置文件的语法。如果 Apache 报告“Syntax OK”，则表示配置文件语法正确，可以继续下一步操作；否则，需要检查 httpd.conf 文件中是否存在拼写错误。

2.4 运行 Apache

可以手动启动 httpd 服务器，也可以通过系统的启动脚本来启动。建议使用后者，因为这样可以确保服务器在机器重启时自动重启。手动启动服务器的命令如下：

$ apachectl start

2.5 分析日志文件

当网站投入使用后，可能需要收集有关网站使用情况的统计信息，例如每个页面的请求数、每天的平均请求数、失败请求的百分比以及传输的数据量。

确保使用“combined”日志格式（ CustomLog 指令的末尾应该是 combined 而不是 common ）。这种日志格式包含每个请求的引用页面（链接到该 URL 的页面）和用户代理（客户端的浏览器和操作系统）。

访问日志和错误日志位于 Apache 的 logs 目录中。这些文件是可读的，但由于包含大量信息，可能需要使用单独的工具来进行分析。

3. 虚拟主机配置

在 Apache 服务器中，虚拟主机允许在一台物理服务器上托管多个网站，每个网站都有自己独立的配置和内容。这大大提高了服务器资源的利用率，并且方便管理多个不同的域名或网站。

3.1 基于 IP 地址的虚拟主机

基于 IP 地址的虚拟主机是通过为每个网站分配不同的 IP 地址来实现的。每个 IP 地址对应一个独立的网站，服务器根据客户端请求的 IP 地址来确定要返回哪个网站的内容。

配置步骤如下：
1. 确保服务器有多个可用的 IP 地址 ：可以通过网络配置为服务器添加多个 IP 地址。
2. 编辑 httpd.conf 文件 ：在文件中添加以下配置示例：

<VirtualHost 192.168.1.100:80>
    ServerName example1.com
    DocumentRoot /var/www/example1
</VirtualHost>

<VirtualHost 192.168.1.101:80>
    ServerName example2.com
    DocumentRoot /var/www/example2
</VirtualHost>

其中， 192.168.1.100 和 192.168.1.101 是分配给不同网站的 IP 地址， example1.com 和 example2.com 是对应的域名， /var/www/example1 和 /var/www/example2 是网站内容的根目录。

重启 Apache 服务器 ：使配置生效。

$ apachectl restart

3.2 基于名称的虚拟主机

基于名称的虚拟主机是通过客户端请求中的 Host 头信息来区分不同的网站，多个网站可以共享同一个 IP 地址。这是一种更常用的虚拟主机配置方式，因为它不需要为每个网站分配独立的 IP 地址。

配置步骤如下：
1. 编辑 httpd.conf 文件 ：添加以下配置示例：

NameVirtualHost *:80

<VirtualHost *:80>
    ServerName example1.com
    DocumentRoot /var/www/example1
</VirtualHost>

<VirtualHost *:80>
    ServerName example2.com
    DocumentRoot /var/www/example2
</VirtualHost>

其中， NameVirtualHost *:80 表示监听所有 IP 地址的 80 端口， * 代表所有 IP 地址。每个 <VirtualHost> 块中指定了不同的域名和对应的文档根目录。

重启 Apache 服务器 ：

$ apachectl restart

4. 安全配置与优化

为了确保 Web 服务器的安全性和性能，需要进行一些安全配置和优化操作。

4.1 安全配置

限制访问 ：通过修改 httpd.conf 文件中的 <Directory> 和 <File> 指令来限制对敏感文件和目录的访问。例如，禁止对 .htaccess 文件的访问：

<Files ".htaccess">
    Require all denied
</Files>

启用 SSL/TLS ：为了保护用户数据的安全，建议启用 SSL/TLS 加密。可以通过以下步骤来配置：
1. 生成 SSL 证书 ：可以使用 OpenSSL 工具生成自签名证书或从证书颁发机构（CA）购买证书。
2. 安装证书 ：将生成的证书文件和私钥文件放置在服务器上的安全位置。
3. 编辑 httpd.conf 文件 ：添加以下配置示例：

Listen 443
<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/example
    SSLEngine on
    SSLCertificateFile /path/to/certificate.crt
    SSLCertificateKeyFile /path/to/private.key
</VirtualHost>

4. **重启 Apache 服务器**：使配置生效。

$ apachectl restart

4.2 性能优化

调整服务器参数 ：可以通过修改 httpd.conf 文件中的一些参数来优化服务器性能。例如，调整 MaxClients 参数来限制同时连接的客户端数量：

MaxClients 200

启用缓存 ：可以使用 Apache 的 mod_expires 模块为静态资源设置缓存过期时间，减少客户端对服务器的请求。在 httpd.conf 文件中添加以下配置：

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
</IfModule>

使用压缩 ：启用 Apache 的 mod_deflate 模块对传输的数据进行压缩，减少数据传输量，提高页面加载速度。在 httpd.conf 文件中添加以下配置：

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
</IfModule>

5. 监控与维护

为了确保 Web 服务器的稳定运行，需要进行定期的监控和维护工作。

5.1 监控指标

CPU 使用率 ：通过系统监控工具（如 top 、 htop 等）监控服务器的 CPU 使用率，确保服务器不会因为过高的 CPU 负载而出现性能问题。
内存使用率 ：监控服务器的内存使用情况，避免出现内存不足的情况。可以使用 free 命令查看内存使用情况。
网络流量 ：监控服务器的网络流量，确保服务器的带宽不会被过度占用。可以使用 iftop 、 nethogs 等工具进行网络流量监控。
请求响应时间 ：通过日志分析或性能监控工具（如 New Relic 、 Datadog 等）监控网站的请求响应时间，及时发现性能瓶颈。