吞吐量

在代理场景中，吞吐量（throughput）衡量代理服务器在给定时间段内成功处理并传输的数据总量。它量化了代理能够承载的数据量，反映其高效转发客户端请求与源服务器响应的能力。

理解代理吞吐量

吞吐量是任何代理服务的关键性能指标，直接影响用户体验和数据传输的运营效率。就数据量而言，它通常以每秒比特（bps）、每秒千比特（Kbps）、每秒兆比特（Mbps）或每秒吉比特（Gbps）来衡量。对于面向连接的指标，也可以用每秒请求数（RPS）或每秒连接数（CPS）表示，这些指标体现了代理处理并发操作的能力。

代理的吞吐能力决定了它能同时服务多少客户端，以及在客户端与源服务器之间搬运数据的速度。对于视频流、大文件下载或高并发 API 请求等需要快速传输数据的应用，高吞吐量必不可少。吞吐量低则表现为加载缓慢、响应延迟以及服务质量整体下降。

影响代理吞吐量的因素

多个相互关联的因素决定了代理服务器的有效吞吐量：

网络基础设施

底层网络带宽是首要决定因素。这包括代理服务器自身的互联网连接速度（上行和下行）、到源服务器的网络链路，以及到客户端的网络路径。配备 1 Gbps 网络接口的代理服务器，无论处理能力多强，吞吐量都不可能超过 1 Gbps。网络路径上任何一点的拥塞都会降低有效吞吐量。

代理服务器硬件

代理服务器的物理资源直接影响其处理能力：
* CPU： 处理能力对 SSL/TLS 加解密、请求解析、请求头处理、内容过滤以及管理大量并发连接等任务至关重要。在 SSL/TLS 流量很大或内容处理复杂时，CPU 瓶颈会格外明显。
* 内存： 需要足够的内存来缓存高频访问的内容、维护连接状态并支撑 worker 进程。内存不足会导致过量磁盘 I/O（换页）或缓存命中率下降，两者都会拖慢性能。
* 磁盘 I/O： 对于带缓存的代理，磁盘读写速度至关重要。在这方面 SSD 明显优于 HDD，尤其在高并发访问模式下。持久化日志同样消耗磁盘 I/O。
* 网卡（NIC）： 网卡的容量和质量决定了服务器可承载的最大数据速率。可以使用多块网卡实现冗余或聚合带宽。

代理软件配置

代理软件的配置方式深刻影响其吞吐量：
* 并发设置： 最大 worker 进程/线程数、最大打开文件描述符数、最大并发连接数等参数直接限制代理处理并行请求的能力。
* 缓存策略： 有效的缓存能降低源服务器和网络的负载，通过直接从代理提供内容来提升感知吞吐量。缓存大小、淘汰策略和生存时间（TTL）设置都很关键。
* SSL/TLS 卸载： SSL/TLS 握手与加解密非常耗费 CPU。把这部分卸载到专用硬件（SSL 加速卡）或独立服务器，可以释放代理主 CPU 去处理其他任务。
* 日志级别： 冗长的日志会消耗 CPU、磁盘 I/O 和内存，可能降低吞吐量。
* 过滤与规则集： 复杂或庞大的过滤规则（例如 WAF 规则、内容检测）会增加每个请求的处理量，抬高延迟并降低总体吞吐量。
* 协议支持： 高效处理 HTTP/2 或 HTTP/3 等现代协议，可通过减少开销并启用多路复用来提升吞吐量。

上游与下游性能

源服务器（上游）以及客户端设备/网络（下游）的性能同样影响代理的有效吞吐量。再快的代理也无法弥补缓慢的源服务器或带宽受限的客户端。

流量特征

流量本身的性质也有影响：
* 请求大小： 大量小请求（例如请求众多小资源）会因连接建立/拆除和请求头处理而更多地占用 CPU；而少量大请求则更多地占用网络带宽。
* 连接持久性： 使用 HTTP keep-alive 或持久连接（HTTP/2 多路复用）可减少为每个请求建立新 TCP 连接的开销，提高效率。
* 协议开销： 不同协议的开销各不相同。例如 HTTP/1.1 常常需要多条连接，而 HTTP/2 用一条连接承载多个流。

测量代理吞吐量

准确测量代理吞吐量需要监控多种系统级和应用级指标。

系统级监控

top、htop、vmstat 和 iostat 等工具能反映 CPU、内存和磁盘 I/O 的使用情况。iftop、nload 或 vnstat 等网络监控工具可跟踪网络接口的带宽占用。

# 监控 CPU、内存和平均负载
top -bn1 | head -n 5

# 监控指定网卡的带宽占用（例如 eth0）
iftop -i eth0

# 监控磁盘 I/O 活动
iostat -xdm 1 5

应用级指标

代理服务通常会暴露以下特定指标：
* 每秒进出字节数： 直接测量经过代理的数据传输速率。
* 每秒请求数（RPS）： 表示代理处理客户端请求的速率。
* 活动连接数： 代理当前正在管理的打开连接数量。
* 缓存命中率： 由缓存直接响应的请求占比，反映缓存效率。
* 错误率： 错误率偏高可能意味着代理过载或配置有误，会影响有效吞吐量。

许多代理服务器会提供状态页面或 API 接口来暴露这些指标。例如 NGINX 的 stub_status 模块或 HAProxy 的统计页面就能提供实时性能数据。

压力测试

要确定最大可持续吞吐量，压力测试工具不可或缺。Apache JMeter、k6、Locust 或 wrk 等工具可以模拟大量并发用户和请求，测量代理在高压下的表现。

# 使用 wrk 测试代理的示例
wrk -t12 -c400 -d30s --latency http://your-proxy-ip:port/test-path

该命令启动 12 个线程，保持 400 条打开连接，持续测试 30 秒，并输出延迟统计数据。

优化代理吞吐量

优化代理吞吐量需要结合硬件升级、软件调优和架构层面的考量。

硬件扩容

• CPU 升级： 使用主频更高、核心更多的 CPU，尤其是面向 SSL/TLS 密集型负载时。
• 内存扩展： 增加内存以支持更大的缓存和更多并发连接。
• 更快的存储： 为缓存和日志部署 SSD 或 NVMe 硬盘。
• 网络升级： 采用更高带宽的网卡（例如 10 Gbps、25 Gbps、40 Gbps），并确保网络基础设施能承载这些速率。

软件配置与调优

• 内核参数调优： 调整 TCP 缓冲区大小（net.ipv4.tcp_rmem、net.ipv4.tcp_wmem），提高文件描述符上限（fs.file-max、ulimit -n），并优化其他与网络相关的内核参数。
• 代理专项调优：
  • 增加 worker 进程/线程数，充分利用可用的 CPU 核心。
  • 优化缓存：确保缓存容量充足、max-age 请求头设置合理、淘汰策略高效。
  • 启用 HTTP/2 或 HTTP/3 以实现多路复用并降低开销。
  • 配置连接池，复用与源服务器之间的已有连接。
  • 在生产环境中尽量减少冗长日志。
  • 精简访问控制列表（ACL）和过滤规则，降低处理开销。
• SSL/TLS 优化：
  • 使用高效的加密套件。
  • 启用 SSL 会话缓存和 TLS session ticket，减少握手开销。
  • 考虑使用专用的 SSL/TLS 终结服务器或硬件卸载设备。

架构层面的考量

• 负载均衡： 通过负载均衡器（例如 DNS 轮询、L4/L7 负载均衡器）把入站流量分散到多个代理实例上，从而横向扩展吞吐量。
• 地理分布： 把代理部署在多个地理位置（边缘代理），更靠近客户端和/或源服务器，以降低延迟并提升感知吞吐量。
• 内容分发网络（CDN）： 与 CDN 集成以卸载静态内容分发，把代理资源留给动态或关键流量。

吞吐量、延迟与带宽的区别

三者虽有关联，但吞吐量、延迟和带宽是不同的概念：

高带宽连接提供了实现高吞吐量的潜力。然而，即便带宽很高，吞吐量仍可能受到服务器处理能力、网络拥塞或协议开销等因素的限制。延迟作为时间上的迟滞，影响单个请求被处理的速度；高延迟会推迟数据传输或确认的开始，从而间接降低有效吞吐量。性能优秀的代理追求的是在最小化延迟的同时最大化吞吐量。

HTTP 协议版本的影响

HTTP 协议的演进显著改变了代理处理吞吐量的方式：

HTTP/1.1

• 连接模型： 通常每个请求一条 TCP 连接，或通过 Keep-Alive 复用。
• 队头阻塞： 如果同一连接上较早的请求被卡住，后续请求必须等待。
• 对吞吐量的影响： 复杂页面可能需要大量打开的连接，增加开销并可能限制并发请求数。代理往往需要管理数量庞大的连接。

HTTP/2

• 连接模型： 用单条 TCP 连接承载多个并发流（多路复用）。
• 特性： 请求头压缩、服务器推送、流优先级。
• 对吞吐量的影响： 减少连接开销，缓解队头阻塞（在应用层），并高效利用网络资源。代理从更少的 TCP 握手和更好的资源利用中获益。不过由于 HTTP/2 通常运行在 TLS 之上，SSL/TLS 开销依然可观。

HTTP/3

• 连接模型： 基于 UDP 之上的 QUIC（Quick UDP Internet Connections）。
• 特性： 内置 TLS 1.3、无队头阻塞的流多路复用（在传输层）、更快的连接建立（0-RTT/1-RTT）、更好的丢包恢复。
• 对吞吐量的影响： 专为更低延迟和在不稳定网络上的更好表现而设计。基于 UDP 的特性可带来更高效的数据传输和更低的延迟，进而转化为更高的有效吞吐量，在移动或高丢包环境中尤为明显。代理需要支持 UDP 和 QUIC 才能获得最佳性能。