TCP请求公网传输随机丢包是否正常？日万次请求丢3次咨询

同英语圈发达国家境内、成熟基础设施环境下，日1万次请求出现3次完全无法抵达后端IIS的情况，不属于TCP公网传输的正常丢包范畴，网络团队甩锅给“公网丢包正常”的说法不成立。

• 首先要明确两个概念的本质区别：运维常说的“公网丢包正常”，指的是IP层单个数据包的丢失，不是整个TCP请求层面的完全消失。TCP协议本身内置了重传机制，同国成熟运营商网络的单IP包丢包率通常低于0.01%，这种级别的零星丢包会被客户端和中间链路的TCP栈自动重传补全，根本不会导致整个请求到不了服务端，业务侧完全感知不到。
• 你观测到的是请求完全没有抵达任意一台后端Web服务器，这和普通IP层丢包完全不是一回事：如果真的是公网传输过程中出问题，要么TCP重传成功、请求最终落到IIS日志里，要么客户端会收到连接超时、连接重置这类明确的错误反馈，不会出现万分之三量级的请求平白无故消失的情况。同国成熟公网链路下，纯传输问题导致整个TCP请求失败的概率通常在十万分级甚至更低，远低于你现在碰到的万分之三的故障率。

• 重试逻辑当然可以加，这本来就是分布式系统的基础容错手段，但加重试不代表要接下网络团队甩的锅，优先定位根因：
  • 第一步先拉负载均衡的七层访问日志，核对这部分丢失的请求有没有到过负载均衡：如果LB日志里完全查不到对应请求记录，故障点在LB前端入口或者LB到客户端的公网入口段；如果LB日志里有记录但没有转发到后端的日志，100%是负载均衡自身的问题，常见原因包括连接表耗尽静默丢包、TLS握手偶发兼容bug、健康检查误判丢弃连接、WAF/抗D设备偶发误拦截、限流规则误触发，这类问题的故障量级刚好就是万分之几的水平，和你现在遇到的现象完全匹配，直接拿日志找网络团队排查就行，不用接公网丢包的由头。
  • 客户端侧可以加简单的故障日志埋点，出现请求失败时同步记录TCP建连结果、TLS握手状态、路由跳点探测结果，攒3-5个故障样本就能基本锁定丢包位置。
  • 加重试逻辑的时候一定要先保证接口幂等，毕竟SOAP接口不少是带数据写入、状态变更类的操作，避免重试导致重复数据或者业务逻辑错乱；重试策略用指数退避，不要固定短间隔猛重试，避免放大故障时的服务压力。

内容的提问来源于stack exchange，提问作者user648336