HTTP性能优化下|HTTP协议篇
# HTTP性能优化下
30 秒速记
- HTTP 性能问题可以从服务器、客户端和传输链路观察，但客户端通常不可完全控制，落地优化主要集中在服务器侧。
- 服务器侧还要拆分后端服务与前端资源：前者影响处理能力，后者包括
HTML、CSS、图片等交付内容。 - 硬件扩容可直接增加容量，例如更强的
CPU、网卡、带宽或更多服务器，但需要投入成本。 - 外部服务可处理自身难以覆盖的链路问题；资料重点举例
CDN，用于改善内容在中间链路上的交付。 - 站内软件优化可归纳为“开源、节流、缓存”，需要结合瓶颈位置选择，而不是把所有手段同时堆上。
HTTP 性能优化要先定位瓶颈在服务器、客户端还是传输链路，实际可控的工作通常集中在服务器侧。 服务端还要分开看后台处理和前端资源，因为排队、计算耗时与资源体积、请求数量对应的是不同问题。硬件扩容能直接增加容量，CDN 能改善静态内容的中间链路，但它们不会自动修复慢查询或过大的资源。我一般把站内优化归为开源、节流和缓存，再根据 TTFB、带宽、CPU 与缓存命中情况选择手段并复测。
在整个 HTTP 系统里有三个可优化的环节，分别是服务器、客户端和传输链路（“第一公里”和“中间一公里”）。但因为我们是无法完全控制客户端的，所以实际上的优化工作通常是在服务器端。这里又可以细分为后端和前端，后端是指网站的后台服务，而前端就是 HTML、CSS、图片等展现在客户端的代码和数据。
知道了大致的方向，HTTP 性能优化具体应该怎么做呢？
总的来说，任何计算机系统的优化都可以分成这么几类：硬件软件、内部外部、花钱不花钱。
投资购买现成的硬件最简单的优化方式，比如换上更强的 CPU、更快的网卡、更大的带宽、更多的服务器，效果也会“立竿见影”，直接提升网站的服务能力，也就实现了 HTTP 优化
另外，花钱购买外部的软件或者服务也是一种行之有效的优化方式，最“物有所值”的应该算是 CDN 了。CDN 专注于网络内容交付，帮助网站解决“中间一公里”的问题，还有很多其他非常专业的优化功能。把网站交给 CDN 运营，就好像是“让网站坐上了喷气飞机”，能够直达用户，几乎不需要费什么力气就能够达成很好的优化效果。
不过这些“花钱”的手段实在是太没有“技术含量”了，属于“懒人”（无贬义）的做法，所以我就不再细说，接下来重点就讲讲在网站内部、“不花钱”的软件优化。
我把这方面的 HTTP 性能优化概括为三个关键词：开源、节流、缓存。
原理拆解： 优化应从时间分解和资源利用率入手：域名解析、建连与握手属于链路成本，等待首字节同时受网络和服务端处理影响，内容下载则受体积与带宽约束。后端重点观察排队、数据库和计算耗时；前端资源重点处理压缩、缓存与请求数量。扩容提高容量，却不会自动修复慢查询或超大资源；CDN 能缩短静态内容的传输距离，但动态接口仍可能受源站处理限制。“开源”增加并发处理能力，“节流”减少无效工作，“缓存”避免重复计算与传输。
最小验证： 输入同一资源地址，连续请求两次，验证 DNS、连接、首字节和总耗时，而不是只看一个总时长。命令可在安装了 curl 的终端执行。
url='https://example.com/'
for run in 1 2; do
curl --silent --output /dev/null \
--write-out "run=${run} code=%{http_code} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s size=%{size_download}B\n" \
"$url"
done
关键字段中，time_starttransfer 是从开始到收到首字节的累计时间，time_total 是完整请求时间；第二次更快可能来自 DNS、连接或缓存复用，不能直接归因于服务端代码。请求失败时先检查 code，TLS 或网络错误也可能使状态码显示为 000。
边界与排查： 单次测量容易被网络抖动误导，应在相同地域、协议和负载下采样分位数，并区分缓存命中与回源。工程上同时对照服务端吞吐量、CPU、队列、错误率以及客户端 TTFB、资源体积；若 CPU 已饱和可扩容或削减计算，若带宽饱和应压缩或使用 CDN，若命中缓存后仍慢，则继续检查链路和连接复用。任何优化都应以瓶颈迁移后的新指标复测。
面试官追问
追问 1商品详情页首屏从 1.5s 升到 3s，后端监控里的接口处理耗时没有变化，平台主管却要求立刻扩容一倍，你会先补哪些证据？
不能仅凭接口处理耗时不变就扩容，应拆分 DNS、建连、TLS、TTFB 和内容下载时间，并对照资源体积、源站吞吐、CPU、队列与错误率。若慢点在图片下载或跨地域链路，增加业务服务器不会直接改善首屏，还会造成无效投入。
追问 2你用 curl 连续两次请求同一个首页，第二次总耗时下降了很多，开发同学据此认定刚上线的后端优化生效，你会怎样验证？
这个结论证据不足，应记录两次请求的 time_namelookup、time_connect、time_appconnect、time_starttransfer 和 time_total。第二次变快可能来自 DNS、连接或缓存复用；还需在相同地域、协议和负载下采样分位数，并区分缓存命中与回源。
追问 3跨地域用户加载 HTML 很快，但一组静态图片下载很慢，源站 CPU 与出口带宽均未饱和，预算允许购买外部服务，你会优先选扩容还是 CDN？
应优先评估 CDN，现象更接近静态内容在“中间一公里”的交付成本，而不是源站计算能力不足。上线后要分别观察边缘命中率、回源量和各地域下载耗时；动态接口仍可能受源站处理限制，不能期待 CDN 自动解决全部延迟。
追问 4活动当天客户端 TTFB 和总耗时同时升高，服务器 CPU 已饱和且请求队列持续增长，但静态资源体积没有变化，你会怎样划定处理顺序？
应先把瓶颈定位到服务端容量或计算路径，短期可扩容并削减不必要计算，同时检查排队、数据库和后台处理耗时。扩容能提高并发能力，却不会自动修复慢查询；处理后必须复测 TTFB、吞吐和队列，确认瓶颈没有迁移到带宽或链路。
追问 5年度预算被冻结，团队只能改站内软件，但产品要求所有页面都立即提速，你会如何拆解方案并约束承诺？
应按“开源、节流、缓存”组织改造：挖掘服务器并发能力、减少请求与传输数据、避免重复计算和传输。优先级必须由分段耗时和资源利用率决定，不能承诺所有页面同幅度提升；实时接口、私有数据和首次连接等场景仍有明确边界。
# 开源
30 秒速记
- 服务端优化的核心是提高现有资源的处理能力：用高性能的
Nginx或OpenResty承接连接与静态资源，把动态请求代理给业务服务器。 - 通过动静分离避免让
Tomcat、Django、Rails等业务层承担图片、样式表等低价值工作。 - 必须启用
HTTP长连接；它不减少首次TCP或TLS握手，却能让后续请求复用连接，摊薄建连延迟。 - 还可从连接池、负载均衡锁、
CPU绑定等参数继续调优，但要结合并发量和机器资源验证，不能只追求更大的配置值。 TCP Fast Open可在握手阶段携带数据以降低初次连接延迟；原文所列支持基线为Windows 10、iOS 9和Linux 4.1，实际启用仍取决于操作系统及服务器配置。
“开源”就是挖掘服务器现有能力，用 Nginx 或 OpenResty 承接连接和静态资源，再把动态请求代理给业务服务器。 这样做能实现动静分离，避免 Tomcat、Django 等业务层把资源耗在图片、样式表上。HTTP 长连接也要开启，虽然首次握手仍有成本，但后续请求可以复用连接。连接池、负载均衡锁、CPU 绑定和 TCP Fast Open 都能继续调优，不过要结合并发量、机器资源和系统支持情况验证。
这个“开源”可不是 Open Source，而是指抓“源头”，开发网站服务器自身的潜力，在现有条件不变的情况下尽量挖掘出更多的服务能力。
首先，我们应该选用高性能的 Web 服务器，最佳选择当然就是 Nginx/OpenResty 了，尽量不要选择基于 Java、Python、Ruby 的其他服务器，它们用来做后面的业务逻辑服务器更好。利用 Nginx 强大的反向代理能力实现“动静分离”，动态页面交给 Tomcat、Django、Rails，图片、样式表等静态资源交给 Nginx。
Nginx 或者 OpenResty 自身也有很多配置参数可以用来进一步调优，举几个例子，比如说禁用负载均衡锁、增大连接池，绑定 CPU 等等，相关的资料有很多。
特别要说的是，对于 HTTP 协议一定要启用长连接TCP 和 SSL 建立新连接的成本是非常高的，有可能会占到客户端总延迟的一半以上。长连接虽然不能优化连接握手，但可以把成本“均摊”到多次请求里，这样只有第一次请求会有延迟，之后的请求就不会有连接延迟，总体的延迟也就降低了。
另外，在现代操作系统上都已经支持 TCP 的新特性“TCP Fast Open”（Win10、iOS9、Linux 4.1），它的效果类似 TLS 的“False Start”，可以在初次握手的时候就传输数据，也就是 0-RTT，所以我们应该尽可能在操作系统和 Nginx 里开启这个特性，减少外网和内网里的握手延迟。
下面给出一个简短的 Nginx 配置示例，启用了长连接等优化参数，实现了动静分离：
server {
listen 80 deferred reuseport backlog=4096 fastopen=1024;
keepalive_timeout 60;
keepalive_requests 10000;
location ~* \.(png)$ {
root /var/images/png/;
}
location ~* \.(php)$ {
proxy_pass http://php_back_end;
}
}
