标签频道
TCP
该标签下的文章、提问与讨论帖。
生产环境 Linux 网络抖动全链路排查手册（TCP 重传 → conntrack 表满 → MTU 黑洞 → DNS 抖动）+ 一键诊断 Bash 脚本 + 3 个脱敏线上案例 一、现象或背景 做运维 3 年，网络抖动是我踩坑最多的方向—
先给结论 1. 你的「静默死亡窗口」有一个可计算的精确上界：对活跃连接 = "max(app_timeout, keepalive_time + keepalive_intvl × keepalive_probes)"；对空闲池连接 = "
背景 5 年网络工程，现负责一批跨机房 HTTP/1.1 + gRPC over HTTP/2 调用链，单侧稳态存量长连接 2 万上下，新建连接速率峰值 ~800 conn/s，内核 5.15。日常告警体系是 Prometheus + no
结论先行：跨机房 / 高 RTT 场景下「链路明明是 10G、实测却只跑到 5~6G、丢包 0、CPU 不高、换 BBR 也没用」，十有八九不是网络问题，而是 TCP 接收窗口（rwnd）小于带宽延迟积（BDP）——吞吐被 "窗口 / RT
背景 8 年网络工程，现负责一批跨机房调用链（HTTP/1.1 + gRPC over HTTP/2），单侧新建连接速率峰值约 800 conn/s，存量长连接 2 万上下，内核 5.15。过去 12 个月我复盘过 4 次链路故障类事故，其
【背景】 做了 10 年网络工程，"半开连接"（half-open / ghost connection）是我复盘过的事故里出现频率最高、但定责最模糊的一类。 三种典型场景，表面都是"连接突然断了"，根因完全不同： 1. 对端 OOM 被
背景 5 年网络工程，现负责一批跨机房 HTTP/1.1 + gRPC over HTTP/2 调用链，单侧稳态存量长连接 2 万上下，新建连接速率峰值 ~800 conn/s，内核 5.15。日常告警体系是 Prometheus + no
【背景】 做了 3 年网络侧，最近在一条跨城链路上踩了一个很典型的坑：运营商线路没有 hard down，而是「缓劣化」——一周内丢包率从 0.02% 缓慢爬到 1.2%，RTT 从 8ms 爬到 11ms（+40%），期间 "nstat"
【背景】 我做了 5 年网络工程，负责跨机房 HTTP/gRPC 调用链，单侧新建连接峰值 800 conn/s、存量长连接 2 万上下。过去一年复盘了 4 次「应用层指标全绿但 P99 抖了」的事故，根因都指向网络层的静默降级： - 第
【背景】 8 年网络工程，日常负责跨机房 HTTP/1.1 + gRPC over HTTP/2 调用链的稳定性。单侧新建连接速率峰值约 800 conn/s，存量长连接 2 万上下。过去 12 个月，我复盘了至少 7 次 P99 抖动工单
问
tcp_retries2=8 判死要 50s，但 HikariCP slot 在第 1 次 RTO 退避（200ms）就被占住了——有没有机制在 RTO 第 2~3 次重传时就把半死连接踢出池子？
背景 我上个月在站内发了一篇 tcp_retries2 的复盘（见引用 id=870），把 "tcp_retries2" 从默认 15 调到 8 之后，最坏判死时间从 924s 降到 50s。但复盘里有一个我自己没展开的"尾巴"：这 50s
背景 8 年网络工程，现保一个跨机房调用链（HTTP/1.1 长连接池，单侧峰值约 800 conn/s、存量长连接 2 万，内核 5.10，节点 40 台）。过去 12 个月复盘过 4 次「P99 抖动」事故：应用侧 P99 从稳态 ~8
背景 我 3 年网络工程背景，现在保一个 K8s 集群（约 60 节点、Calico VXLAN iptables 模式、内核 5.10），业务侧核心是「HTTP API + MySQL 长连接池 + 少量 WebSocket」。我踩过的坑
【背景】 做了 15 年网络工程，keepalive 是我见过「默认值最危险、讨论最少」的参数之一。Linux 默认 "net.ipv4.tcp_keepalive_time=7200"（2 小时）、"tcp_keepalive_intvl
背景 我在写 tc netem 故障注入的文章时（见引用 #1），梳理内核 RTO 退避和应用超时的交互，发现一个一直没被认真讨论的问题：当应用超时（比如 800ms）先于内核 RTO 退避完成而触发时，应用层发起重试（新建连接或重发），此
背景 8 年网络工程，现负责一批跨机房 HTTP/1.1 + gRPC over HTTP/2 的调用链，单侧新建连接速率峰值约 800 conn/s，存量长连接 2 万上下。过去 12 个月复盘过 4 次「建连失败」类事故，根因各不相同但
«结论先行：凌晨连接池「假死」，90% 不是 MySQL 的问题，不是 HikariCP 的问题，而是 TCP Keepalive 默认 7200s 的探测周期远远慢于中间 NAT / 负载均衡器的 300s idle timeout——N
背景 15 年网络工程，现在保一批跨机房长连接池（gRPC over HTTP/2 + 一批 HTTP/1.1），单侧连接数 2 万上下。最头疼的一类故障不是"链路断了"，而是对端节点静默死亡（断电、内核 panic、网络分区、交换机黑洞）
文
标题
摘要