关闭通知与截断防护
协议规范要求在正常结束会话前发送关闭通知警报，明确告知对端不再发送数据。如果对端没有收到通知就断开连接，应用可能把被截断的数据当成完整数据，这类问题在下载与流式响应中最隐蔽。防护手段是在应用层做长度校验、分块编码校验或内容校验，同时区分正常结束与异常截断。
基本信息
| 警报类型 | 关闭通知，编号为 0 |
|---|---|
| 作用 | 明确告知对端不再发送数据 |
| 风险 | 连接直接断开可能意味着数据被截断 |
| 防护 | 长度校验、分块编码、应用层内容校验 |
典型使用场景
- 下载类业务：确认文件是否完整
- 流式接口排错：响应中途结束但客户端未报错
- 自研协议栈：区分正常结束与异常截断
- 抓包分析：判断连接是正常关闭还是被重置
- 中间设备排查：代理或网关未转发通知
观察会话结束行为
观察会话结束行为
printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n' | openssl s_client -connect example.com:443 -servername example.com -quiet 2>&1 | tail -3
# 抓包时关注是否有警报记录
tshark -r tls.pcap -Y 'tls.alert_message' -T fields -e tls.alert_message.desc | head结束方式对照
| 结束方式 | 含义 | 风险 |
|---|---|---|
| 收到关闭通知 | 正常结束 | 低 |
| 直接断开 | 可能被截断 | 中，需应用层校验 |
| 连接被重置 | 异常中断 | 高，可能被中间设备干预 |
部分中间设备或旧代理不发关闭通知；自研协议栈应显式区分正常结束与异常截断，而不是把断开一律当成正常结束。
落地建议
- 下载与导出类接口都做长度或内容校验
- 在客户端记录异常结束的统计指标
- 对中间设备的行为建立基线并定期对比
- 自研协议明确结束帧与超时的处理分支
抓包看到连接被重置就判定为攻击是常见误判：也可能只是中间设备或服务端超时回收连接，需要结合上下文与其他指标判断。