3、网络异常检测：心跳检测、超时机制、重试计数、错误码分类
好，咱们接着聊。上一章讲了网络异常有哪些类型，这一章我们重点说说——怎么把这些异常「抓出来」。
你想想看，OTA升级最怕什么？最怕设备连不上服务器，或者连到一半突然断了。更怕的是，设备自己还不知道断了，还在那傻等。所以，网络异常检测，说白了就是给设备装上一双「眼睛」和一只「闹钟」。
我个人习惯把这套检测机制拆成四个部分：心跳检测、超时机制、重试计数、错误码分类。咱们一个一个说。
3.1 心跳检测：确认对方还活着
心跳检测，名字很形象。就像人需要心跳一样，设备和服务器之间也需要一个「你还活着吗？」的信号。
我在项目中遇到过这样的情况：设备下载到90%了，网络其实已经断了，但TCP连接还没释放。设备以为还在下载，服务器以为设备还在线。结果呢？卡在那半小时不动。用户直接骂娘。
所以，心跳机制就是用来解决这个问题的。
核心思路：客户端定期向服务器发送一个很小的数据包（心跳包），服务器收到后回复确认。如果连续几次没收到回复，就判定连接已断开。
具体实现上，我建议这样设计：
- 心跳间隔：一般设为30秒到60秒。太频繁浪费流量，太慢反应迟钝。
- 心跳超时：发送后3秒内没收到回复，算一次失败。
- 最大失败次数：连续3次失败，判定连接断开。
嗯，这里要注意：心跳包一定要轻量。别发个几百K的数据过去，那就不是心跳了，是「心梗」。
我的小技巧：心跳包可以复用应用层的Ping/Pong消息。比如用JSON格式：{"type":"ping"}，服务器回复{"type":"pong"}。简单、清晰、好解析。
3.2 超时机制：别让设备傻等
超时机制，说白了就是给每个操作设定一个「最后期限」。到了时间没完成，就别等了，赶紧处理。
我曾经在一个项目中吃过亏：下载一个固件包，服务器响应慢，设备等了5分钟还没收到第一个字节。用户以为死机了，直接断电重启。结果呢？固件损坏，变砖了。
从那以后，我对超时机制特别敏感。
OTA升级中，需要设置超时的地方至少有这几个：
| 操作 | 建议超时时间 | 说明 |
|---|---|---|
| DNS解析 | 5秒 | 域名解析失败就直接报错 |
| TCP连接 | 10秒 | 连不上就换下一个IP |
| TLS握手 | 15秒 | 证书验证超时很常见 |
| HTTP请求 | 30秒 | 包括请求头和第一个字节 |
| 数据块下载 | 60秒 | 每个分块的下载超时 |
| 固件校验 | 根据大小定 | 1MB大概1-2秒 |
你可能会问：这些时间怎么定出来的？其实没有标准答案。我一般会先根据经验设一个值，然后在实际网络环境下测试，再调整。说白了，就是「试出来的」。
注意：超时时间不是越长越好。设得太长，用户体验差；设得太短，容易误判。我建议在弱网环境下（比如2G、3G）适当放宽，在WiFi环境下收紧。
3.3 重试计数：给失败留点余地
网络这东西，偶尔抽风很正常。一次失败不代表永远失败。所以，我们需要重试机制。
但重试不是无脑重试。你想想看，如果网络真的断了，你重试100次也没用，反而浪费电和流量。所以，重试计数就很重要了。
我一般这样设计重试策略：
- 最大重试次数：3次。超过3次就放弃，进入错误处理流程。
- 重试间隔：第一次失败后等1秒，第二次等2秒，第三次等4秒。指数退避，别一窝蜂地重试。
- 重试范围：只在「可重试」的错误上重试。比如超时、连接重置。如果是404、403这种，重试也没用。
举个例子，代码实现大概是这样：
int retry_count = 0;
int max_retry = 3;
int delay = 1;
while (retry_count < max_retry) {
result = download_chunk(chunk_id);
if (result == SUCCESS) {
break;
}
if (is_retryable(result)) {
retry_count++;
sleep(delay);
delay *= 2; // 指数退避
} else {
// 不可重试的错误，直接退出
break;
}
}嗯，这里要注意：重试计数要区分「当前连接的重试」和「整个升级的重试」。前者是同一个连接上重试，后者是重新建立连接再试。我建议把这两个分开计数。
我的经验：如果连续3次重试都失败，别急着放弃。可以尝试切换网络（比如从WiFi切到4G），或者切换服务器域名。有时候换个路就通了。
3.4 错误码分类：给异常贴个标签
最后说说错误码分类。这个看似简单，其实很关键。
你想想看，设备上报了一个错误码「-1」，你知道是什么意思吗？不知道。所以，错误码必须分类清晰，让开发和运维人员一眼就能看出问题出在哪。
我习惯把OTA相关的错误码分成这几类：
| 错误类别 | 错误码范围 | 典型错误 | 处理方式 |
|---|---|---|---|
| 网络层错误 | 1000-1999 | DNS解析失败、连接超时、TLS握手失败 | 重试或切换网络 |
| 协议层错误 | 2000-2999 | HTTP 4xx、5xx、响应格式错误 | 根据状态码决定是否重试 |
| 数据层错误 | 3000-3999 | 校验和错误、分块缺失、数据损坏 | 重新下载该分块 |
| 设备层错误 | 4000-4999 | 存储空间不足、电量过低、固件签名验证失败 | 停止升级，提示用户 |
| 业务层错误 | 5000-5999 | 版本号不匹配、设备未授权、升级策略拒绝 | 上报服务器，等待指令 |
我曾经在一个项目里，把所有错误都用一个「-1」表示。结果线上出了问题，根本不知道是网络断了还是固件坏了。排查了三天，最后发现是服务器证书过期了。从那以后，我再也不敢偷懒了。
我的建议：每个错误码都要有明确的含义、触发条件和处理建议。最好做成文档，团队共享。别让后来的人猜谜语。
好了，这一章的内容就这些。总结一下：心跳检测让你知道对方「还在不在」，超时机制让你知道「该不该等」，重试计数让你知道「要不要再试一次」，错误码分类让你知道「到底出了什么问题」。这四个东西配合起来，基本能覆盖大部分网络异常场景。
下一章，我们聊聊具体的重试策略和退避算法。到时候我会分享一些实际项目中的踩坑经验，敬请期待。