-
我的服务要高频调用一个 HTTPS 接口每次请求都老老实实新建一个连接发完就关、功能没问题可延迟一直降不下来 CPU 还莫名其妙偏高,抓包一看才发现每一次请求前都在完整地做一遍 TLS 握手——多轮往返加上一堆非对称加密运算,这笔昂贵的建立成本被我每个请求都重新付了一遍的深度复盘
我有个服务需要高频调用一个第三方 HTTPS 接口,客户端代码写得很朴素:每次要调用就新建一个 HTTPS 连接发请求拿响应关掉连接。功能完全正常但性能不对劲:单次延迟明显比纯网络往返加服务端处理该有的时间长出一截而且这一截稳定存在优化业务逻辑怎么都压不下去;CPU 莫名偏高调用量一大就明显升高和它就是个调接口的定位不符;低频还好一到高频延迟和 CPU 成倍放大;抓包发现每一次请求之前都有一整套 …- 0
- 0
-
我的服务平时稳如老狗,可每次大促整点开闸流量一瞬间涌进来就有一批用户连接直接超时连不上、而服务端应用日志干干净净没有任何报错 CPU 内存也都没满,我盯着监控百思不得其解,最后才挖出来是 TCP 三次握手完成后那个全连接 accept 队列被挤满了、新完成握手的连接被内核静默丢弃了的深度复盘
我有个接口平时 QPS 不高服务稳得很,可每次运营搞活动整点开闸的那一瞬间,大量用户几乎同一秒涌进来,就有一批人连不上——页面打不开、一直转圈最后超时、刷新几次又好了。我上去看监控越看越糊涂:连不上的请求在我的应用日志里根本没有任何记录、就像从没到达过应用,CPU 内存也就五六成远没满,下游 DB 全绿,客户端报的是 connect timeout 连接阶段就超时了、有的显示 SYN 重传几次放弃…- 4
- 0
-
我把一个大文件从国内服务器传到海外节点、两边带宽都是千兆、可实际传输速度死活只有几 MB 每秒慢得令人发指,我换了更快的机器查了磁盘网卡都没问题,最后才搞懂瓶颈根本不在带宽而在这条高延迟链路上 TCP 窗口太小根本填不满这根又粗又长的管道的深度复盘
我要把一个几十 GB 大文件从国内机房传到海外节点,两端网卡和出口带宽都是千兆,满以为几分钟传完,结果速度稳稳卡在几 MB/s、几十 GB 要好几小时。我换更高配机器没用、测磁盘读写飞快、本地内网能跑满千兆,可这条跨国链路单连接就是只能几 MB/s。直到注意到这条链路 RTT 高达两三百毫秒(绕半个地球)才明白:TCP 是发一批数据等对方确认再发下一批,任意时刻已发出但还没收到确认的数据量受窗口大…- 0
- 0
-
我的服务跑着跑着就再也接受不了新连接、报 too many open files,我一查发现成百上千条连接全卡在 CLOSE_WAIT 状态死活不消失,一开始以为是对端没规矩不关连接,最后才搞明白 CLOSE_WAIT 恰恰是对端已经关了、正等着我这边关而我的代码根本就忘了调 close 的深度复盘
我的服务对外提供接口、也作为客户端调下游,运行一段时间后开始变诡异:先偶尔报错,后来直接无法接受任何新连接、日志满屏 too many open files——文件描述符耗尽了,重启能暂时恢复但过一阵又复发,典型的资源泄漏。我用 netstat grep CLOSE_WAIT 一统计倒吸凉气:成百上千条连接处于 CLOSE_WAIT 状态且只增不减。我第一反应是对端怎么用完连接不关,可去查对端它那…- 0
- 0
-
我用一个长连接连着下游服务,平时好好的,可只要一段时间没有数据来往、再发请求就超时失败,两边的连接看着都还在、谁也没断开,排查半天才发现是中间的网络设备早把这个空闲连接悄悄掐了、而两端都被蒙在鼓里的深度复盘
我有个服务用一个长连接连着下游,想复用连接省去反复建连。请求频繁时一切正常,可问题出在空闲之后:只要连接一段时间没数据来往,下次再用它发请求就卡住然后超时;诡异的是连接两端看着都还活着——我这边状态正常、下游也没主动关闭。第一次失败后重建又能用,空闲又失败如此反复。我以为下游不稳定,查半天下游正常。直到抓包又了解链路才恍然:我和下游间隔着 NAT 网关/防火墙/负载均衡这类有状态中间设备,它们为每…- 2
- 0
-
我的服务传输大量数据,带宽明明很充足、网络也不差,可吞吐量就是上不去、尤其每次新建连接的前期慢得明显,排查半天才发现 TCP 有个慢启动机制、新连接的发送窗口是从很小一点点试探着爬上来的深度复盘
我有个服务要在节点间传输大量数据,观察到怪现象:带宽明明充足、延迟也不高,可实际吞吐就是上不去、达不到带宽理论值,尤其每次新建连接前期都慢得肉眼可见、过一会儿才提上速,而我的模式恰恰是频繁建新连接传一小批就关,于是每条连接几乎都在慢吞吞的前期就结束了。我以为是带宽不够、对端慢、缓冲小,排查都不对。直到抓包盯着一条新连接的发送速率曲线:刚建立时速率非常低、然后指数往上爬、爬好一阵才接近带宽上限。查 …- 0
- 0
-
我的服务调用下游一切正常,可一到高峰期就大量报连接失败、报错说没有可用端口了,我的机器明明负载不高、内存也充足,排查半天发现是几万个处于 TIME_WAIT 状态的连接把本地端口耗光了的深度复盘
我有个服务要频繁调用一个下游接口,写法很干净:每次调用都新建连接、发请求、拿响应、然后立刻关掉,用完即走。平时跑得好好的。可一到流量高峰就灾难了:服务大量报 Cannot assign requested address(没有可用端口),新的下游建连接连失败。我以为机器扛不住了,可一看监控傻眼:CPU 不高、内存充足、下游也好好的,机器很闲,凭什么连接就建不出来?直到我 netstat 统计连接状…- 0
- 0
-
我的接口传小数据一切正常,可一旦传稍大的数据,在某些客户端那里就偶发卡死、超时,换个网络又好了,抓包发现大包发出去对方根本没收到、也没人告诉我为什么:一次 MTU 路径黑洞的深度复盘
我有个接口平时好好的,直到某些用户反馈:小数据没问题,可一旦传稍大的数据就偶发卡死、超时,更诡异的是同样的请求换一个网络环境(比如从 VPN 切到普通网络)就好了。抓包越看越懵:大请求的数据包发出去了可对端根本没收到,而且没有任何错误返回,就那么静静卡着到超时。查了很久才搞懂根因冷门:网络每条链路都有 MTU(一个包最大尺寸,以太网 1500),一个连接经过多跳,整条路径能传的最大包取决于路径上最…- 2
- 0
-
我的服务用连接池复用长连接调下游,平时好好的,却总在低峰期之后偶发 connection reset,排查发现是连接被对端的空闲超时悄悄关了、我的连接池却还留着这条已死的连接照样拿来用的深度复盘
我的服务用连接池复用到下游的长连接(避免每次新建,这是对的)。平时高峰期一切正常,可总在低峰期之后(凌晨流量小或一段时间没请求后)出怪事:之后的第一批请求偶发失败、报 Connection reset by peer 或 Broken pipe,而重试一下又成功了。复盘才搞懂:连接池为复用会把用完的长连接留着、放回池里下次直接用;可一条连接空闲太久,对端(下游服务、或中间的 LB/NAT/防火墙)…- 4
- 0
-
我的服务通过域名调用下游,下游因为故障切换换了 IP,我的服务却还死死连着那个已经下线的旧 IP 一直报连接失败,重启之后才恢复,原来是 DNS 解析结果被缓存了很久不刷新的深度复盘
我的服务通过域名 api.downstream.com 调下游。某天下游故障切换、运维把域名指向了新的健康节点(DNS 里的 IP 变了)。按理说我用的是域名、IP 变了该自动跟上,可现实是我的服务一直在连那个已下线的旧 IP、疯狂报 Connection refused,别的服务都正常,直到我重启才恢复。复盘才搞懂:用域名访问要先经过 DNS 解析把域名翻译成 IP,而这个解析结果会被缓存(系统…- 0
- 0
-
我给下游调用加了失败自动重试本想让系统更可靠,结果某次下游只是变慢,重试却把流量放大了好几倍直接把它压垮:一次重试风暴拖垮整个链路的深度复盘
我有个服务要调下游接口,之前偶尔因下游抖动失败,我想加个重试吧、失败自动重试3次、成功率能高不少。平时确实好用。可那天下游因 GC 卡顿只是变慢了(响应 50ms 涨到 2 秒、没挂),我却眼睁睁看着它在几十秒内被打成彻底挂掉、整条链路雪崩。复盘才倒吸凉气:下游一变慢,大量请求超时失败,每个失败的请求立刻重试3次,本来1倍的流量瞬间变成3~4倍,把本来还撑得住的下游直接压垮;压垮后失败更多、重试更…- 0
- 0
-
下游服务只是抖了一下,我们配的失败就重试三次反而把它彻底打死了,而且越打越死、再也起不来:一次重试风暴压垮下游、正反馈雪崩的深度复盘
我们调用下游服务,我很负责任地配了失败就重试最多三次,觉得能扛住下游临时抖动、更健壮。可线上某次下游只是因为一次 GC 短暂抖动了一下,结果它不但没缓过来反而被彻底打死、越打越死、迟迟起不来。复盘才看明白:那个失败就重试三次在下游抖动时变成了一场重试风暴——下游抖动→部分请求失败→上游对每个失败重试 3 次→请求量瞬间放大几倍→本就脆弱的下游被打成大面积失败→失败更多→重试更多→流量更大,形成越重…- 0
- 0
-
我那个请求-响应的小包通信,延迟总是莫名其妙地多出 40 毫秒,抓包才发现是 Nagle 算法和延迟确认这两个好心的优化打起来了:一次 TCP 小包延迟的深度复盘
我有个请求-响应式的小包通信,逻辑上应该很快,可监控显示延迟经常莫名多出约 40 毫秒,而服务端处理只要零点几毫秒。代码翻烂了也没找到哪里慢,最后 tcpdump 抓包看时间戳才明白:这 40ms 不在我的代码里,而消耗在 TCP 协议栈里两个各自合理的优化的相互作用上——发送端的 Nagle 算法(有未 ACK 数据时攒着不发新小包、等 ACK)和接收端的延迟确认(收到数据先不回 ACK、等回程…- 2
- 0
-
调用下游服务的接口慢得离谱、机器上还堆了几万个 TIME_WAIT,我抓包才发现每发一个请求都在重新三次握手加 TLS 握手:一次 HTTP 连接没复用、每次新建连接把建连开销付了无数遍的深度复盘
我写了个服务频繁调用下游 HTTP 接口,压测时 QPS 怎么也上不去、延迟还高,机器上 netstat 里密密麻麻几万个 TIME_WAIT。一开始以为下游慢,抓包才发现:我每发一个 HTTP 请求都在新建一个全新 TCP 连接——请求前三次握手+TLS 握手,请求后立刻关闭,大部分时间耗在建连和关连上、真正传输反而很少;而主动关闭的连接大量堆在 TIME_WAIT 耗端口。根因是每次请求 ne…- 2
- 0
-
我基于 TCP 写了个通信协议,客户端连发两条消息,服务端一次读出来却粘成了一坨,有时一条消息又被拆成两次才收全,我对着 TCP 是字节流没有消息边界这个粘包拆包的坑排查大半天的复盘
一个让我对 TCP 到底传的是什么彻底搞明白的网络坑,它让我意识到我一直以为的我 send 一条消息对方就 recv 到一条消息这个朴素直觉在 TCP 根本不成立,发和收之间根本没有消息这个概念。自己基于 TCP socket 写通信协议,客户端 conn.Write(hello) 再 Write(world),服务端一次 Read 却读到了 helloworld 两条粘在一起(粘包),有时一条消…- 0
- 0
-
下游一个接口只是变慢了一点,我的整个服务却跟着全部瘫痪、所有请求都卡死,我对着调用下游时没设超时导致请求堆积线程耗尽的级联雪崩这个坑排查大半天的复盘
一个让我对分布式系统脆弱性彻底敬畏的网络坑,可怕在真正出问题的只是一个下游依赖(还只是变慢没完全挂),却像多米诺骨牌层层传染放大,最终把我自己本来好好的服务也拖垮——级联雪崩。服务 A 调下游 B 的 HTTP 接口,我图省事没设任何超时(HttpClient.newHttpClient 默认无超时无限等待)。B 正常时没问题,但那天 B 负载高响应从几十毫秒变成几秒几十秒(慢但没挂),灾难发生:…- 2
- 0
-
我的服务跑着跑着就再也连不上下游了,报 too many open files,netstat 一看几千个 CLOSE_WAIT 堆在那,我对着忘记关闭 HTTP 响应体导致连接泄漏这个坑排查大半天的复盘
一个让我对关闭资源彻底敬畏的网络坑,可怕在它是缓慢累积定时爆发的雷:服务刚启动一切正常,运行几小时甚至几天后突然像被掐住喉咙,再也无法建立任何新连接、整个服务瘫痪。需求很常见:服务频繁调下游 HTTP 接口拿数据,我用 Go 写了个调用函数 resp,err := http.Get(url),用完却忘了 resp.Body.Close()。测试和刚上线跑得好好的,运行一段后告警:dial tcp …- 0
- 0
-
下游只是抖了一下,我那个"失败就立即重试三次"的客户端却把它彻底打垮了、还陷入越重试越崩的恶性循环,我对着这场重试风暴排查了大半天的复盘
我给调下游的客户端加了"失败就立即重试 3 次",自觉更健壮了。结果某次下游只是短暂抖动变慢几秒(本该自己很快恢复),却演变成下游被彻底打垮、长时间不可用,而且监控显示抖动那刻请求量不降反升暴涨好几倍。深挖才懂是"重试风暴":下游整体抖动时所有请求几乎同时失败、又几乎同时立即重试,流量瞬间放大 3~4 倍涌向本已脆弱的下游,它更慢→更多超时→更多重试→流量更…- 2
- 0
-
我的服务用域名连下游,对方机器扩缩容换了 IP 之后,我的服务却死活还在连那台早已下线的旧机器、疯狂报连接失败,我排查了大半天才发现是 DNS 被永久缓存了的复盘
我的服务用域名连下游,下游扩缩容换了 IP、更新了 DNS 记录,我的服务却死活还连那台早已下线的旧 IP、疯狂报 connection refused/超时;可 dig 查那个域名明明早就是新 IP 了,而且重启我的服务就好、下次换 IP 又犯。深挖才懂是 DNS 缓存:我的 JVM 把启动时解析到的旧 IP 永久缓存了——networkaddress.cache.ttl 在装了 Securit…- 2
- 0
-
我的服务调外部接口一到高峰就报"cannot assign requested address"、机器上堆了几万个 TIME_WAIT 连接,我盯着 netstat 排查了大半天才发现连接根本没复用
我的服务频繁调外部 HTTP 接口,一到高峰就大面积报错 cannot assign requested address、延迟还变高。netstat 一看惊呆:机器上堆了几万个 TIME_WAIT。深挖才懂:我每次请求都新建一个 TCP 连接、用完就关、从不复用——后果一是每次都白付三次握手(HTTPS 还有 TLS 握手)的延迟;后果二更致命,主动关闭的连接进入 TIME_WAIT 要停留约 2…- 4
- 0
-
我图省事每次请求都新建一个 HTTP 客户端,平时跑得好好的,流量一上来就连接耗尽、TIME_WAIT 堆成山、还报 too many open files,我查了好几天才懂连接要复用的深度复盘
我的服务频繁调外部 HTTP 接口,图省事每次请求都 new 一个 HTTP 客户端、用完就扔。低流量没事,可一到高峰:请求变慢、TIME_WAIT 堆成山把端口占光、还报 too many open files、甚至连不上外部接口。深究才懂:我把"连接"当成了廉价消耗品频繁创建销毁,可它是昂贵(每次要 TCP 三次握手+HTTPS 的 TLS 握手)又有限(端口约 6 万、f…- 0
- 0
-
我调用外部接口图省事没设超时,平时一直好好的,直到对方一抽风卡住不返回,我这边的线程被一个个拖死、整个服务跟着雪崩的深度复盘
我的服务要调一个外部接口,图省事没设任何超时,平时对方几十毫秒就返回、一切风平浪静。可有天对方故障抽风、挂在那不返回,我这边因为没超时,每个调它的请求线程都无限期阻塞、永不释放,请求不断涌入、线程池被彻底耗尽——连那些根本不调外部接口的正常请求也抢不到线程,整个服务跟着雪崩!一个外部依赖的故障,拖垮了我整个服务。深究才懂:没设超时=把"我等多久"的决定权交给对方,而阻塞会耗尽线…- 0
- 0
-
下游换了 IP 发布完成后我们死活连不上、下游明明健康重启自己就好:网络第一步 DNS 缓存导致连旧 IP 刻舟求剑的避坑复盘
这是一次下游明明好好的我却死活连不上的诡异故障。起因是我们依赖的一个下游服务做了一次发布,它换了新机器 IP 变了但对外的域名没变,本来嘛用域名访问的好处就是 IP 可以随便换域名不变。下游发布顺利完成自测一切正常,可就在它发布完成的那一刻我们的服务却开始大面积报错:调用那个下游持续地连接超时或者连接被拒绝。我赶紧检查下游服务确确实实是健康的能正常访问的,我们自己的网络代码也都没动,可我们就是连不…- 2
- 0
-
重试把下游打死了:重试风暴避坑复盘
这是一次好心办坏事的典型事故,也是我对重试这个看似无害的机制彻底改观的一次。起因很小:我们依赖的一个下游服务某天出现了短暂抖动,有那么几秒钟变慢了少量请求超时了,这本来是件小事下游抖一下缓一缓通常几秒就自己恢复了。可那天它不仅没恢复反而被彻底打挂了一垮就是好久,连带把我们整个服务也拖垮了。事后复盘真凶让我大跌眼镜——把下游打死的不是别人,正是我们自己为了提高成功率而精心设计的失败自动重试机制。这就…- 2
- 0
网络
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×