1. 问题现象拨测任务丢失与WebSocket断连那天下午测试同事急匆匆跑过来说批量导入的URL拨测任务有大量结果丢失。我第一反应是查看Agent日志果然发现了规律性的Connection reset by peer错误。这种错误就像你正打着电话突然被挂断而且对方还直接拔了电话线——粗暴的RST复位。拨测系统的架构其实很简单Master节点通过WebSocket向Agent下发任务Agent执行curl或DNS拨测后返回结果。正常情况下这个双向通道应该像高速公路一样畅通无阻。但现实是每当批量任务达到一定数量级这条公路就会发生连环追尾——大量任务积压最终导致连接被重置。最诡异的是断连发生时Master服务器CPU使用率不足30%Nginx已经配置了3600秒的超时时间客户端网络连接状态良好这就像一栋大楼突然停电但检查发现发电机正常、电网完好、电闸也没跳——问题到底出在哪2. 排查思路从表象到本质的层层递进2.1 第一层排查服务端负载与配置先用经典三板斧检查Master服务端top -H -p pid # 查看线程级CPU使用 netstat -tulnp | grep websocket # 检查连接状态 tail -f /var/log/nginx/error.log # 监控Nginx错误结果令人困惑没有CPU或内存瓶颈Nginx报错显示send() failed (104: Connection reset by peer)netstat显示Send-Q堆积了108KB未发送数据这就像快递站明明有足够人手快递车也没满但包裹就是堆积在发货区。Send-Q的堆积暗示数据卡在了TCP发送缓冲区没能及时到达对端。2.2 第二层排查网络抓包分析是时候祭出tcpdump这把手术刀了tcpdump -i eth0 -nn tcp port 443 and host 172.28.72.119 -w ws.pcap用Wireshark分析抓包文件后发现几个关键现象Agent端频繁发送TCP ZeroWindow报文窗口大小为0Nginx多次重传相同数据包约8次后放弃最终由Nginx主动发送RST终止连接这相当于接收方Agent不断喊别发了我仓库堆不下了而发送方Nginx在多次尝试后直接拆毁了整个仓库。2.3 第三层排查客户端处理能力转到Agent机器执行netstat -tnlp | grep 443输出显示tcp6 362708 0 172.28.72.119:63132 172.28.72.117:443 ESTABLISHED 32278/java那个惊人的Recv-Q数字362708约350KB说明内核已经收到数据但应用层没及时取走。就像快递柜塞满了包裹但收件人迟迟不来取件。3. 根因分析消费端阻塞引发的连锁反应3.1 TCP层的雪崩效应整个过程就像多米诺骨牌Agent业务线程同步处理拨测任务如执行curl任务处理耗时过长导致WebSocket消息堆积内核Recv-Q缓冲区逐渐填满TCP滑动窗口逐渐减小直至归零ZeroWindowNginx触发最大重传次数默认8次服务端主动重置连接RST关键点在于WebSocket是应用层协议它的存活依赖于底层TCP连接的健康度。当消费速度跟不上生产速度就像小水管接大瀑布最终必然决堤。3.2 为什么不是FIN而是RST这里有个技术细节当Nginx主动关闭连接时为什么发RST而不是FIN通过分析内核源码net/ipv4/tcp.c发现void tcp_close(struct sock *sk, long timeout) { if (sk-sk_state TCP_CLOSE || !sock_flag(sk, SOCK_ZAPPED)) tcp_send_fin(sk); // 正常关闭流程 else tcp_send_active_reset(sk, GFP_ATOMIC); // 异常重置 }当Socket被标记为SOCK_ZAPPED强制关闭时内核会直接发送RST。这种暴力拆迁式的关闭往往发生在应用层明确要求立即释放资源时。4. 解决方案线程池优化与流量控制4.1 消费端线程池改造原始代码的问题在于同步阻塞处理// 反例同步处理导致IO线程阻塞 OnWebSocketMessage public void onMessage(Session session, String message) { doHeavyWork(message); // 耗时操作阻塞线程 }改造为异步线程池模式private ExecutorService taskPool Executors.newFixedThreadPool(8); OnWebSocketMessage public void onMessage(Session session, String message) { taskPool.submit(() - { doHeavyWork(message); }); }参数配置建议核心线程数 CPU核数 * 2队列容量根据任务特性调整建议100-1000拒绝策略推荐CallerRunsPolicy由调用线程处理4.2 双向心跳保活机制增加应用层心跳检测防止中间设备超时// 服务端心跳 scheduler.scheduleAtFixedRate(() - { session.getRemote().sendPing(ByteBuffer.wrap(ping.getBytes())); }, 0, 30, TimeUnit.SECONDS); // 客户端心跳 wsSession.addMessageHandler(new MessageHandler.Pong() { Override public void onPong(PongMessage message) { lastPongTime System.currentTimeMillis(); } });4.3 背压(Back Pressure)控制在Master端实现发送速率动态调整class RateLimiter { private int windowSize 10; private AtomicInteger pendingTasks new AtomicInteger(); public boolean tryAcquire() { return pendingTasks.get() windowSize; } public void release() { pendingTasks.decrementAndGet(); } }当检测到Agent的Recv-Q持续增长时动态减小windowSize像水龙头一样控制流量。5. 预防措施监控体系搭建5.1 TCP缓冲区监控脚本#!/bin/bash while true; do netstat -tn | awk /:443/{print $2,$3} | sort | uniq -c ss -temop | grep -A1 Recv-Q sleep 5 done关键指标告警阈值Recv-Q持续 32KBSend-Q持续 64KB重传率 5%5.2 WebSocket健康检查在Prometheus中配置以下指标metrics: websocket_connections: gauge websocket_receive_queue: gauge websocket_heartbeat_latency: histogramGrafana面板建议展示连接数变化趋势消息处理延迟P99心跳响应时间6. 经验总结与避坑指南这次故障给我上了重要一课WebSocket的稳定性不仅取决于协议本身更依赖于整个数据处理链路的协调。分享几个关键认知Recv-Q/Send-Q就像煤矿中的金丝雀——它们的异常增长往往是系统崩溃的前兆。建议将netstat -s的输出纳入监控体系。线程池配置需要黄金分割——太大导致资源竞争太小引发处理瓶颈。经过实测核心线程数CPU核数*2队列容量100是个不错的起点。RST比FIN更值得警惕——它往往意味着非优雅关闭。在Linux中可以通过ss -eip查看详细的TCP状态信息。应用层心跳不能替代传输层保活——TCP的SO_KEEPALIVE默认需要2小时才会探测死连接而Nginx等中间件的超时设置通常以分钟计。最后特别提醒WebSocket是长连接但长连接不等于永连接。设计系统时一定要考虑如何优雅地处理断连和恢复就像优秀的快递公司既要有高效的派送系统也要有完善的退货流程。