按方法过滤能看出什么
HTTP 方法在报文里是明文首个字段，按方法过滤与统计能很快看出接口的行为构成：以读取为主还是以写入为主、有无大量重试、是否出现批量删除这类需要重点保护的操作。方法分布发生突变往往对应真实变化，比如客户端版本升级、重试策略上线或被爬虫扫到。需要注意方法语义在链路中并不总是被完整保留，代理与网关都可能改写方法。
基本信息
| 适用平台 | Wireshark / tshark 解析的 HTTP/1.x 明文流量 |
|---|---|
| 过滤字段 | http.request.method |
| 统计方式 | tshark -T fields 导出后按频率聚合 |
| 方法语义 | GET 读取、POST 提交、PUT 替换、PATCH 局部更新、DELETE 删除、HEAD 只要头部、OPTIONS 探测能力 |
典型使用场景
- 接口调用量异常排查，先按方法看构成再钻取具体 URI
- 确认是否有应用在对写操作做自动重试
- 识别爬虫或扫描行为，通常表现为大量 GET 与 OPTIONS
- 改造前后对比方法分布，验证客户端升级是否生效
- 为审计留存写操作清单，重点关注删除与更新类调用
- 统计接口读写比，为缓存策略提供依据
统计与过滤
统计与过滤
tshark -r http.pcap -Y 'http.request' -T fields -e http.request.method \
| sort | uniq -c | sort -rn # 按方法统计频次
# 只看写操作:
# http.request.method == "POST" || http.request.method == "DELETE"
# 只看失败响应的方法分布:
# http.request.method && http.response.code >= 400方法逐项读法
| 方法 | 语义 | 抓包要点 |
|---|---|---|
| GET | 读取资源 | 可能被中间设备缓存，注意命中缓存的情况 |
| POST | 提交数据 | 重试会重复提交，需与业务幂等策略对照 |
| PUT | 整体替换资源 | 被改写为 POST 时可判定中间设备改写了方法 |
| PATCH | 局部更新 | 同上，链路改写会掩盖原始方法 |
| DELETE | 删除资源 | 审计关注项，出现频次异常应优先核查 |
| HEAD | 只要响应头 | 无实体，按响应长度判断会误判为空响应 |
| OPTIONS | 探测可用方法 | 跨域预检与扫描工具都会产生，需区分来源 |
HEAD 请求只有响应头没有实体，按响应长度字段判断容易误认为空响应，统计时要单独归类。
方法分布要按时间段切开看：按整天汇聚会把突发摊平，掩盖短时间内的异常行为。