-
我用一个长连接连着下游服务,平时好好的,可只要一段时间没有数据来往、再发请求就超时失败,两边的连接看着都还在、谁也没断开,排查半天才发现是中间的网络设备早把这个空闲连接悄悄掐了、而两端都被蒙在鼓里的深度复盘
我有个服务用一个长连接连着下游,想复用连接省去反复建连。请求频繁时一切正常,可问题出在空闲之后:只要连接一段时间没数据来往,下次再用它发请求就卡住然后超时;诡异的是连接两端看着都还活着——我这边状态正常、下游也没主动关闭。第一次失败后重建又能用,空闲又失败如此反复。我以为下游不稳定,查半天下游正常。直到抓包又了解链路才恍然:我和下游间隔着 NAT 网关/防火墙/负载均衡这类有状态中间设备,它们为每…- 2
- 0
-
gRPC HTTP/2 长连接被 AWS NLB 350 秒 idle timeout 悄悄 RST 的 5 天复盘:每天 1842 次 connection reset 噪音清零 + 三端 keepalive 协调纪律落地
推荐服务 order-service 调 inventory-service 每天 1842 次 connection reset 全部集中在低 QPS 时段,5 天复盘根因是 AWS NLB 350 秒 idle timeout + gRPC 默认不发 keepalive + HTTP/2 多路复用三层叠加,最终落地 client/server/LB 三端协调的 keepalive 工程纪律 +…- 2
- 0
-
Nginx upstream keepalive 漏一行配置,QPS 直接砍 6 倍
新搭 Nginx 反代,QPS 2000 后端就 502。本文讲清楚 Nginx 默认到 upstream 是短连接、三件套配置缺一不可、非幂等重试的坑、WebSocket/SSE/gRPC 反代差异,附完整配置 + CI 自检脚本 + 6 条必读规则。- 0
- 0
keepalive
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×