UNIX/Linux系统管理技术手册-读书笔记-第十九章
《UNIX/Linux系统管理技术手册-读书笔记-第十九章
Web托管
1. HTTP协议核心
1.1 URL结构
scheme://[username:password@]hostname[:port][/path][?query][#anchor]
| 组成部分 | 说明 | 示例 |
|---|---|---|
scheme |
协议类型 | http、https、ws、ftp |
hostname |
域名或IP地址 | www.example.com |
port |
TCP端口(默认http=80,https=443) | :8080 |
path |
资源路径 | /index.html |
query |
查询参数(key=value,&分隔) |
?term=linux&page=2 |
anchor |
页面内锚点 | #section3 |
安全警告:密码和敏感数据绝不应放在URL中(URL会被记入日志、浏览器历史等)。
1.2 HTTP请求与响应
请求首行:GET /index.html HTTP/1.1
常用HTTP动词:
| 动词 | 安全(Safe) | 用途 |
|---|---|---|
GET |
✅ | 检索资源(最常用) |
HEAD |
✅ | 仅获取元数据(无响应体) |
POST |
❌ | 提交数据(表单、上传) |
PUT |
❌ | 替换/创建资源 |
DELETE |
❌ | 删除资源 |
OPTIONS |
✅ | 查询服务器支持的请求方法 |
HTTP状态码类别:
| 类别 | 含义 | 常见代码 |
|---|---|---|
| 1xx | 信息类,继续处理 | 101 Switching Protocols |
| 2xx | 成功 | 200 OK、201 Created |
| 3xx | 重定向 | 301 Moved Permanently、302 Found |
| 4xx | 客户端错误 | 403 Forbidden、404 Not Found |
| 5xx | 服务器错误 | 503 Service Unavailable |
1.3 常用HTTP头部
| 头部 | 方向 | 用途 |
|---|---|---|
Host |
请求 | HTTP/1.1必须,指定目标域名(虚拟主机基础) |
Content-Type |
双向 | 数据格式(如application/json、text/html) |
Authorization |
请求 | HTTP基本认证凭证 |
Cookie / Set-Cookie |
请求/响应 | 会话状态管理 |
User-Agent |
请求 | 客户端软件标识 |
Server |
响应 | 服务器软件标识 |
Cache-Control |
双向 | 缓存策略(no-cache、max-age=7200) |
Content-Length |
双向 | 消息主体字节数 |
Upgrade |
双向 | 协议升级(如HTTP→HTTP/2) |
1.4 curl:命令行HTTP客户端
| 命令 | 功能 |
|---|---|
curl -v http://example.com |
详细输出(含请求/响应头部) |
curl -o /dev/null -s -v http://example.com |
静默模式,只看头部 |
curl -H "Host: www.example.com" 1.2.3.4 |
自定义Host头部(绕过DNS测试) |
curl -O http://example.com/file.tar.gz |
下载文件 |
curl -X POST -d "key=value" http://example.com/api |
发送POST请求 |
💡 Chrome开发者工具 → Network标签 → 右键请求 → Copy as cURL,可生成完整的curl命令用于调试。
1.5 HTTP/2 与连接优化
| 技术 | 说明 |
|---|---|
| Keep-Alive(HTTP/1.1) | 单TCP连接上发送多个请求,减少连接开销 |
| HTTP/2多路复用 | 单连接上交错传输多个请求/响应,避免队头阻塞 |
| TLS+HTTP/2 | 主流浏览器要求HTTP/2必须使用TLS加密 |
| 调试HTTP/2 | 二进制协议,telnet不再可用;可使用h2i或curl(支持HTTP/2) |
2. Web软件栈
2.1 核心组件对比
| 组件 | 功能 | 代表软件 |
|---|---|---|
| Web服务器 | 提供静态内容、TLS终止、代理动态请求 | Apache httpd、Nginx |
| 应用服务器 | 运行动态代码(Ruby/Python/Java等) | Unicorn、Tomcat、Gunicorn |
| 负载均衡器 | 在多个后端服务器间分发请求 | HAProxy、Nginx、AWS ELB |
| 缓存服务器 | 保存频繁访问内容,减轻源站负载 | Varnish、Squid、Nginx |
| WAF(Web应用防火墙) | 检测/拦截常见Web攻击 | ModSecurity |
| CDN(内容分发网络) | 全球边缘节点加速内容分发 | Akamai、CloudFlare、AWS CloudFront |
2.2 典型Web应用栈流程
客户端 → CDN/边缘缓存 → 负载均衡器 → 反向代理缓存 → Web服务器 → 应用服务器 → 数据库/缓存
2.3 内容分发网络(CDN)
| CDN | 特点 |
|---|---|
| Akamai | 最老牌、最大全球网络,企业首选 |
| CloudFlare | 价格透明,安全特性强,HTTP/2先行者 |
| AWS CloudFront | 与AWS服务(S3/EC2/ELB)深度集成 |
CDN工作原理:通过DNS将客户端路由到地理位置最近的边缘节点,边缘节点缓存内容,减轻源站压力,降低延迟。
3. Web服务器:Apache httpd
3.1 核心特性
| 特性 | 说明 |
|---|---|
| MPM(多处理模块) | prefork(进程)、worker(线程)、event(推荐) |
| 模块化架构 | 通过LoadModule动态加载功能(认证、重写、代理等) |
| 虚拟主机 | 基于域名(Host头部)或IP地址 |
| 权限分离 | 主进程root(绑定<1024端口),工作进程以低权限用户运行 |
3.2 配置文件结构
| 系统 | 主配置 | 虚拟主机目录 | 用户 |
|---|---|---|---|
| RHEL/CentOS | /etc/httpd/conf/httpd.conf |
/etc/httpd/conf.d/ |
apache |
| Debian/Ubuntu | /etc/apache2/apache2.conf |
/etc/apache2/sites-available/、sites-enabled/ |
www-data |
| FreeBSD | /usr/local/etc/apache24/httpd.conf |
/usr/local/etc/apache24/Includes/ |
www |
3.3 关键配置示例
基本虚拟主机(HTTP → HTTPS重定向) :
|
|
目录访问控制:
HTTP基本认证:
|
|
状态监控:
3.4 应用服务器模块
| 模块 | 语言 | 说明 |
|---|---|---|
mod_php |
PHP | 不推荐用于生产(仅prefork MPM) |
mod_wsgi |
Python | WSGI标准接口,运行Django等 |
mod_passenger |
Ruby/Python/Node.js | 商业支持的应用服务器 |
mod_proxy_fcgi |
通用 | FastCGI标准接口 |
mod_perl |
Perl | 内嵌Perl解释器 |
4. Web服务器:Nginx
4.1 核心特性
| 特性 | 说明 |
|---|---|
| 事件驱动架构 | 少量worker进程处理大量并发请求(高性能首选) |
| 配置风格 | C风格语法({}分块,;结束行) |
| root权限分离 | 主进程root,worker进程低权限用户 |
| worker数量建议 | = CPU核心数 |
4.2 配置文件结构
| 系统 | 配置目录 | 用户 |
|---|---|---|
| RHEL/CentOS | /etc/nginx/ |
nginx |
| Debian/Ubuntu | /etc/nginx/ |
www-data |
| FreeBSD | /usr/local/etc/nginx/ |
nobody |
4.3 关键配置示例
基础虚拟主机:
反向代理:
TLS配置:
4.4 Nginx信号管理
| 信号 | 功能 |
|---|---|
TERM / INT |
立即关闭 |
QUIT |
优雅关闭(处理完当前连接) |
HUP |
重新加载配置(不停机) |
USR1 |
重新打开日志文件(配合logrotate) |
USR2 |
优雅替换二进制文件(升级) |
5. 负载均衡器:HAProxy
5.1 核心特性
| 特性 | 说明 |
|---|---|
| 支持协议 | HTTP、TCP(包括MySQL/Redis等) |
| 健康检查 | 主动探测后端服务器状态,自动摘除故障节点 |
| 粘滞会话 | 通过cookie将同一客户端固定在相同后端服务器 |
| TLS终止 | 在负载均衡层终结HTTPS,减轻后端加密开销 |
| 统计界面 | 内置Web界面显示服务器状态和流量 |
5.2 关键配置示例
基础配置:
global
daemon
maxconn 5000
defaults
mode http
timeout connect 5000ms
timeout client 10000ms
timeout server 10000ms
frontend http-in
bind *:80
default_backend webservers
backend webservers
balance roundrobin
option httpchk GET /
server web1 10.0.0.10:8080 check inter 30000
server web2 10.0.0.11:8080 check inter 30000
粘滞会话(Cookie) :
backend webservers
balance roundrobin
cookie SERVERNAME insert httponly secure
server web1 10.0.0.10:8080 cookie web1 check
server web2 10.0.0.11:8080 cookie web2 check
TLS终止:
frontend https-in
bind *:443 ssl crt /etc/ssl/private/admin.com.pem
default_backend webservers
💡 HAProxy要求证书和私钥在同一PEM文件中:
cat admin.com.key admin.com.crt > admin.com.pem
统计界面:
listen stats :8000
mode http
stats enable
stats uri /
stats auth admin:password
stats admin if TRUE
6. 缓存与性能优化
6.1 缓存层级
| 层级 | 说明 | 控制方式 |
|---|---|---|
| 浏览器缓存 | 用户本地缓存 | Cache-Control、Expires头部 |
| 代理缓存 | 企业/ISP缓存(Squid) | 被动式(浏览器配置)或拦截式 |
| 反向代理缓存 | 源站前缓存(Varnish/Nginx) | 减轻源站负载 |
| CDN边缘节点 | 全球分布式缓存 | DNS路由到最近节点 |
6.2 缓存控制头部
| 头部 | 用途 |
|---|---|
Cache-Control: max-age=7200 |
缓存2小时 |
Cache-Control: no-cache, no-store |
不缓存(动态内容) |
Cache-Control: public |
允许任何缓存存储 |
ETag |
实体标签,用于验证缓存有效性 |
Expires: Sat, 15 Oct 2016 14:02:00 GMT |
绝对过期时间(旧方式) |
6.3 开源缓存软件
| 软件 | 特点 |
|---|---|
| Squid | 首批开源缓存,适合代理缓存 |
| Varnish | 多线程,VCL配置语言,可扩展 |
| Nginx缓存 | 与Nginx服务器集成,性能优秀 |
| Apache Traffic Server | Yahoo捐赠,支持HTTP/2,高流量场景 |
7. Web语言与部署
| 语言 | 框架/运行时 | 特点 |
|---|---|---|
| Ruby | Rails | 快速原型,性能平庸,Gems依赖管理复杂 |
| Python | Django/Flask | 可读性好,科学计算生态,WSGI标准 |
| Java | Spring/Tomcat | 性能好,企业级,工具链复杂 |
| Node.js | Express | 高并发,实时通信,JavaScript |
| PHP | WordPress/Drupal | 易上手,但代码质量堪忧,安全漏洞常见 |
| Go | 原生HTTP | 编译为独立二进制,部署简单,并发原语强 |
8. 云环境Web托管
| 方案 | 说明 | 适用场景 |
|---|---|---|
| 单EC2实例 | 传统虚拟机部署 | 小型站点,开发测试 |
| ELB + EC2集群 | AWS托管负载均衡+多实例 | 高可用生产环境 |
| PaaS(AppEngine/ElasticBeanstalk) | 只部署代码,平台管理基础设施 | 原型开发,简单应用 |
| 静态托管(S3/Google Firebase) | 仅静态HTML/CSS/JS | 文档站点,单页应用 |
| 无服务器(Lambda + API Gateway) | 按事件触发执行代码 | 轻量级API,突发流量 |
| ELB + 多AZ | 跨可用区部署 | 高可用+容灾 |
无服务器架构:
客户端 → API Gateway → Lambda函数 → 响应
静态资源 → S3托管
9. 本章核心命令速查表
| 命令 | 功能 |
|---|---|
curl -v http://example.com |
查看HTTP请求/响应详情 |
curl -H "Host: www.example.com" IP |
测试虚拟主机配置 |
curl -X POST -d "key=value" URL |
发送POST请求 |
apachectl start/stop/graceful |
Apache控制 |
apachectl -t |
Apache配置语法检查 |
httpd -t |
Apache配置语法检查(直接) |
nginx -t |
Nginx配置语法检查 |
nginx -s reload |
Nginx优雅重载配置 |
haproxy -f /etc/haproxy/haproxy.cfg -c |
HAProxy配置语法检查 |
htpasswd -c /path/.htpasswd user |
创建HTTP基本认证密码文件 |
systemctl status httpd/nginx/haproxy |
检查服务状态 |
DBA视角补充:
- 数据库是Web应用栈的底层:Web应用性能瓶颈常在数据库。监控工具(如Apache的
mod_status、Nginx的ngx_http_stub_status_module、HAProxy统计页面)可与数据库监控(如pg_stat_activity、MySQLSHOW PROCESSLIST)联动排查。- 连接池与负载均衡:应用服务器的数据库连接池大小需与负载均衡器的后端配置协调,避免连接耗尽。
- API Gateway与数据库:无服务器架构中,Lambda直接访问数据库的并发数受数据库连接数限制,需评估并发峰值,考虑使用RDS Proxy等连接池服务。
- 缓存策略:Redis/Memcached等缓存服务可部署在Web应用层和数据库之间,显著减少数据库查询负载。确保缓存失效策略合理(如Cache-Control与业务数据变更节奏匹配)。
- 健康检查端点:建议Web应用提供
/health端点,除检查Web服务本身外,还应验证数据库连接和缓存服务状态,供负载均衡器做全面健康检查。
文章作者 会写代码的小郎中
上次更新 2011-06-30
许可协议 CC BY-NC-ND 4.0