-
我用一个长连接连着下游服务,平时好好的,可只要一段时间没有数据来往、再发请求就超时失败,两边的连接看着都还在、谁也没断开,排查半天才发现是中间的网络设备早把这个空闲连接悄悄掐了、而两端都被蒙在鼓里的深度复盘
我有个服务用一个长连接连着下游,想复用连接省去反复建连。请求频繁时一切正常,可问题出在空闲之后:只要连接一段时间没数据来往,下次再用它发请求就卡住然后超时;诡异的是连接两端看着都还活着——我这边状态正常、下游也没主动关闭。第一次失败后重建又能用,空闲又失败如此反复。我以为下游不稳定,查半天下游正常。直到抓包又了解链路才恍然:我和下游间隔着 NAT 网关/防火墙/负载均衡这类有状态中间设备,它们为每…- 2
- 0
-
我的服务传输大量数据,带宽明明很充足、网络也不差,可吞吐量就是上不去、尤其每次新建连接的前期慢得明显,排查半天才发现 TCP 有个慢启动机制、新连接的发送窗口是从很小一点点试探着爬上来的深度复盘
我有个服务要在节点间传输大量数据,观察到怪现象:带宽明明充足、延迟也不高,可实际吞吐就是上不去、达不到带宽理论值,尤其每次新建连接前期都慢得肉眼可见、过一会儿才提上速,而我的模式恰恰是频繁建新连接传一小批就关,于是每条连接几乎都在慢吞吞的前期就结束了。我以为是带宽不够、对端慢、缓冲小,排查都不对。直到抓包盯着一条新连接的发送速率曲线:刚建立时速率非常低、然后指数往上爬、爬好一阵才接近带宽上限。查 …- 0
- 0
-
我的服务调用下游一切正常,可一到高峰期就大量报连接失败、报错说没有可用端口了,我的机器明明负载不高、内存也充足,排查半天发现是几万个处于 TIME_WAIT 状态的连接把本地端口耗光了的深度复盘
我有个服务要频繁调用一个下游接口,写法很干净:每次调用都新建连接、发请求、拿响应、然后立刻关掉,用完即走。平时跑得好好的。可一到流量高峰就灾难了:服务大量报 Cannot assign requested address(没有可用端口),新的下游建连接连失败。我以为机器扛不住了,可一看监控傻眼:CPU 不高、内存充足、下游也好好的,机器很闲,凭什么连接就建不出来?直到我 netstat 统计连接状…- 0
- 0
-
我的服务从连接池取到的长连接其实早就"死"了、发请求全卡到超时,可连接池却以为它还活着,我对着连接假死和心跳保活排查了大半天的复盘
做了个调下游 RPC 的服务,用长连接+连接池复用,平时正常,可每当下游重启、或中间防火墙/LB 抖动后,就冒出一批诡异超时:从连接池取到的某些连接一发请求就卡到超时,连接池却一直认为它们可用、反复借出。盯着监控百思不得其解:连接不是好好在池里吗怎么用起来是死的?排查大半天才理解 TCP 长连接的隐蔽陷阱——连接假死:TCP 连接是虚拟约定,不发数据时网络无信号确认对端在;异常断开(对端宕机没发F…- 0
- 0
-
端口被 TIME_WAIT 占满:TCP 短连接避坑复盘
这次事故的报错信息第一眼看上去毫无道理:我们一个服务在流量高峰期偶发性地报一个奇怪的错误 Cannot assign requested address 无法分配请求的地址。我盯着这行错误懵了好一会儿:分配地址?我又没在创建什么地址,我只是在调用一个下游的 HTTP 接口而已啊,而且这个错误只在高峰期出现,服务器的 CPU 内存带宽也都不紧张,一个资源充裕的服务器却报无法分配地址,这到底是什么玄学…- 0
- 0
-
WebSocket 被 AWS ALB idle_timeout 静默 RST 断线率飙到 14% 的 5 天复盘:应用层心跳 + TCP keepalive 双保险 + 12 条长连接保活纪律
实时协作产品 WebSocket 用户低活跃 10 分钟就断,客户端只看到 1006 不知道是谁干的。5 天定位 ALB idle_timeout 静默 RST,应用层 ping/pong 30 秒心跳上线后断线率从 14% 压到 0.3%,顺手立下 12 条长连接保活纪律 + CloudFront/conntrack/移动 NAT 全链路 idle timer 登记。- 4
- 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
-
WebSocket 长连接完全指南:从一次"连接建好了消息却悄悄丢"看懂为什么心跳和重连才是根本
2023 年我做一个实时通知功能服务端有新消息要立刻推到用户正开着的浏览器页面上不让用户手动刷新我自然想到 WebSocket 在浏览器和服务端之间建一条长连接服务端有消息就顺着这条连接推过来第一版我做得很顺手前端 new 一个 WebSocket 服务端接受连接把它存进一个连接表有消息时遍历连接表挨个推送本地一测通知秒到我心里很笃定 WebSocket 嘛握手建好一条长连接两端就能一直互发消息直…- 0
- 0
-
TCP 连接优化完全指南:从一次"压测 QPS 上不去,CPU 内存全很闲,连接却建不动"看懂三次握手与 TIME_WAIT
2021 年我接手优化公司一个内部 API 网关一场大促前要给它压测看能扛多少 QPS 怎么把它的吞吐做上去这件事我压根没多想第一版我做得很顺手网关嘛收到请求转发给后端服务拿到响应再返回我用最直接的写法每来一个请求就新建一个连接到后端转发完拿到结果把连接关掉就完事了本地拿低并发一压真不错延迟很低转发又快又稳我心里很笃定TCP 连接不就是个透明的管道connect 一下就有了网络快不快只看带宽连接本…- 0
- 0
-
WebSocket 实时推送完全指南:从一次"用户开着页面挂一会儿就再也收不到消息"看懂长连接工程
2023 年我做一个站内实时消息推送用户开着网页不用刷新就能实时收到新通知新私信。我选了 WebSocket。第一版我做得很省事服务端用 WebSocket 库起一个 server 客户端 new WebSocket 连上去服务端有消息就 send 客户端 onmessage 收到就显示。本地一测完美消息几乎瞬间就到。我心里很踏实WebSocket 嘛不就是建一个长连接两边随便互发消息。可等它真正…- 0
- 0
-
WebSocket 完全指南:从一次"消息莫名丢失、连接悄悄断开"看懂实时通信
2023 年我给一个后台系统加实时通知,选了 WebSocket。Demo 阶段丝滑,上线后却陆续收到"通知有时收不到""页面挂一会儿通知就再也不来、刷新才恢复"的反馈,本地怎么都复现不出来。定位根因才发现:用户网络中间隔着 NAT、代理、负载均衡,这些设备会把"一段时间无数据往来"的连接静默掐断——关键在"静默"二字…- 0
- 0
长连接
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×