等待TCP/IP消息处理的60秒时长是否足够？

• 故障期间两端同步抓包：批量超时爆发时，在客户端、服务端同时用tcpdump抓取目标端口的TCP报文，对比报文时序即可定位诱因：
  • 若两端均能观测到TCP重传报文，且最终有应答报文只是到达时间晚于60秒，属于网络拥堵/抖动导致的延迟，请求最终可成功
  • 若一端发出的报文另一端完全未收到，且无RST重置报文，属于链路断流、防火墙丢包、对端进程崩溃等严重故障，合理时长内无法得到响应
• 配置TCP保活检测：给已建立的socket开启TCP keepalive，超时前如果保活检测失败，可直接判定为链路已失效，无需继续等待

60秒的超时设置不存在通用的“合理”标准，完全匹配业务特性即可：

• 如果你的接口平均响应在1秒内，p99响应不超过10秒，60秒属于非常充裕的设置，无需拉长
• 如果请求本身是大文件传输、长耗时计算类业务，正常响应就需要几十秒，60秒偏短，建议设置为p999响应时长的1.5~2倍
• 不建议盲目拉长超时：批量超时大多由流量突增、下游故障触发，过长超时会导致连接堆积，加重服务端负载甚至引发雪崩

• Amazon Linux默认TCP重传参数和主流Linux发行版一致：内核参数net.ipv4.tcp_retries2默认值为15，对应未确认报文的总重传时长约为15~30分钟，远长于你设置的60秒应用超时
• 确实会出现应用层超时关闭socket后，内核TCP栈仍在继续重试传输的情况
• 可通过两种方式避免该问题：一是调低net.ipv4.tcp_retries2内核参数，缩短内核重传总时长；二是给socket设置SO_LINGER选项，关闭socket时直接丢弃内核缓冲区中未发送的报文，终止无效重试

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