Python 爬虫网络质量评估实战：成功率、P95 延迟与错误分布怎么测
爬虫任务出现“偶发超时”时，最有价值的不是换一组配置继续跑，而是把失败拆成可量化的指标。同一目标站点在不同时间段可能出现连接超时、读取超时、429、5xx 或 DNS 解析失败。只看一次请求是否返回 200，无法判断问题在客户端、网络链路、目标服务还是请求频率。
一、质量评估应该记录哪些指标
单个“平均耗时”不足以说明稳定性。一个实用的最小指标集包括：
- 成功率：成功响应次数占总请求次数的比例。
- P50 与 P95 延迟：P50 表示典型耗时，P95 用于观察较慢的一段请求。
- 状态码分布：403、404、429、5xx 的含义和连接异常不同，应分别统计。
- 异常类型：DNS、连接、读取、TLS、代理认证错误需要分开记录。
- 测试条件：目标 URL、开始时间、超时值、请求间隔、运行环境必须写入日志。
P95 不等于“最慢的一次”。使用最近邻定义时，排序后取排名为ceil(n × 0.95)的样本；样本数较小，P95 会很接近最大值。因此它适合做趋势比较，不适合在 5 次请求后得出长期结论。
二、为什么状态码与异常必须分开
| 结果 | 说明 | 排查方向 |
|---|---|---|
| 2xx / 3xx | HTTP 服务已返回响应 | 记录耗时与响应大小 |
| 4xx | 请求已到达 HTTP 服务，但不符合接口要求 | 权限、参数、频率、资源状态 |
| 5xx | 服务端或中间层处理失败 | 服务端日志、重试策略、维护窗口 |
| ConnectTimeout | TCP 连接未在限定时间内建立 | 地址、端口、路由、防火墙 |
| ReadTimeout | 连接已建立但未及时收到数据 | 服务端负载、响应体、读取超时 |
| SSLError | TLS 验证或握手失败 | 系统时间、证书链、主机名、CA 包 |
例如，429 不是连接故障，而是服务端或网关明确给出的限流响应。将它和超时混在“失败率”里会掩盖根因，也会导致不合适的重试行为。
三、可运行的测量脚本
下面脚本以一个公开测试 URL 为默认值。运行生产或业务测试时，请替换为拥有访问授权的接口，并把请求次数、间隔和超时与服务方要求保持一致。
import math import os import time from collections import Counter from statistics import median import requests URL = os.getenv("TARGET_URL", "https://httpbin.org/get") REPEAT = int(os.getenv("REPEAT", "20")) TIMEOUT = (3.05, 15) def p95(values: list[float]) -> float | None: if not values: return None return sorted(values)[math.ceil(len(values) * 0.95) - 1] latencies: list[float] = [] statuses: Counter[str] = Counter() exceptions: Counter[str] = Counter() with requests.Session() as session: for index in range(REPEAT): started = time.perf_counter() try: response = session.get(URL, timeout=TIMEOUT) except requests.RequestException as exc: exceptions[type(exc).__name__] += 1 else: statuses[str(response.status_code)] += 1 if 200 <= response.status_code < 400: latencies.append((time.perf_counter() - started) * 1000) if index + 1 < REPEAT: time.sleep(0.5) successes = sum( count for code, count in statuses.items() if 200 <= int(code) < 400 ) print("success_rate:", round(successes / REPEAT * 100, 1), "%") print("p50_ms:", round(median(latencies), 1) if latencies else None) print("p95_ms:", round(p95(latencies), 1) if latencies else None) print("status_codes:", dict(statuses)) print("exceptions:", dict(exceptions))安装并运行：
python -m pip install requests python quality_check.py四、脚本的统计边界
脚本把 2xx 和 3xx 视为成功响应，用于计算延迟分位数；4xx、5xx 会保留在状态码统计中，但不计入成功延迟。这不是唯一口径：如果你的业务允许 304，或要求接口必须返回 200，可以在代码中按业务契约调整。
此外，requests.Session()会复用适当的连接。它更接近日常客户端的连续请求行为，但不等于从零开始建立连接的冷启动耗时。需要测试冷启动时，应在每次请求中创建独立 Session，并明确在报告中标注测试方式。
五、如何解释 P50、P95 与失败率
P50 上升：典型请求整体变慢
如果 P50 从 100ms 升到 500ms，说明大部分请求都变慢。应检查最近的目标服务变更、DNS 解析结果、运行环境负载和网络路径变化。
P95 上升而 P50 稳定：尾部波动变大
这常见于偶发拥塞、连接复用失效、服务端排队或少量慢响应。此时应保留每次请求的时间戳，确认慢请求是否集中在特定时段。
失败率上升：先按错误类别分组
连接超时、读取超时、HTTP 429 和 HTTP 503 的后续动作不同。针对可重试的临时错误，可遵循接口文档配置有限次数的指数退避；对 4xx 权限类错误，重复请求通常没有帮助。
六、合规采集任务的运行建议
- 只访问已授权接口、公开可访问资源或拥有明确许可的测试环境。
- 遵守目标站点服务条款、robots.txt 与接口频率要求；robots.txt 不是访问授权本身。
- 设置明确超时和请求间隔，避免无界循环与无限重试。
- 日志中不要写入 Authorization、Cookie、个人数据或完整查询参数。
- 对业务接口使用脱敏的测试样本，并为网络异常设置告警阈值。
七、FAQ
为什么不直接用平均延迟？
平均值容易被少量极慢请求拉高或掩盖。P50 与 P95 同时记录，可以更直观看到典型体验和尾部波动。
429 是否应该重试？
应以接口文档和响应头为准。若服务端提供Retry-After，应优先遵守；没有明确规则时，不要立即高频重试。
脚本能判断网络质量的全部原因吗？
不能。它记录的是 HTTP 客户端视角的结果。需要进一步定位时，还应结合 DNS 查询、系统资源、服务端日志和链路监控。
总结
网络质量评估不是一次“测速”，而是用一致的测试条件记录成功率、延迟分位数、状态码和异常类型。只要这些数据可复现，后续无论是优化超时、调整连接池还是与服务方沟通，都有明确的技术依据。