基于uws.js的Node.js WebSocket服务偶发高延迟问题排查及解决咨询

• 两端埋点拆分延迟环节：服务端和客户端同时新增时间戳埋点，分别记录服务端业务层发起广播时间、uws层消息实际发送时间、客户端收到消息时间、客户端回发ACK时间、服务端收到ACK时间，可直接把延迟范围锁定在「服务端内部处理」「公网传输」「客户端处理」三个区间
• 抓包验证TCP传输异常：在服务端用tcpdump抓取高延迟用户IP的websocket流量，重点统计重传次数、RTO（重传超时）数值、乱序包数量。你提到的39秒后一次性收到多条积压消息，基本可以对应TCP重传指数退避的典型特征——丢包后TCP首次重传等待1s，后续每次重试等待时间翻倍，累计重试6次的总耗时就接近39s，和你遇到的现象完全匹配
• 检查uws配置合理性：确认uws的pub-sub队列长度、积压消息淘汰策略，排查是否存在单用户连接阻塞导致消息排队未发送的情况
• 排查AWS实例网络限制：去CloudWatch查看对应t2.micro实例的NetworkPacketsOut、NetworkPacketsDrop指标，确认是否存在突发带宽耗尽被限流、内核层面丢包的问题

传输层优化 #

• 调整TCP参数降低重传等待阈值：在AWS实例的/etc/sysctl.conf中修改参数，把net.ipv4.tcp_retries2从默认的15下调到5-6，避免最长900秒的重传等待，超时后直接断开连接触发客户端重连；同时给WebSocket连接开启TCP_NODELAY选项，禁用Nagle算法避免小数据包攒包延迟
• 新增应用层消息可靠性机制：给每条业务消息分配唯一ID，客户端收到后立即回应用层ACK，服务端3秒未收到ACK就主动重发对应消息，跳过TCP层的慢重传逻辑；同时新增每5秒一次的应用层心跳，15秒未收到客户端心跳回应就主动断开连接

架构层优化 #

• 对跨区域用户新增边缘接入：在用户集中的区域部署AWS边缘节点，用户就近接入后通过AWS内部专线回源到eu-west-2的主服务，大幅降低公网传输的丢包率
• 关键消息冗余发送：对阶段跳转这类核心消息，间隔1秒连续发送2次，即便单次丢包也能保障用户快速收到消息

客户端优化 #

• 新增自动重连+状态拉取逻辑：客户端检测到连接断开或长时间未收到消息后，自动发起重连，重连成功后主动向服务端拉取当前最新的竞赛状态，无需等待服务端推送积压消息

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