-
我的服务要高频调用一个 HTTPS 接口每次请求都老老实实新建一个连接发完就关、功能没问题可延迟一直降不下来 CPU 还莫名其妙偏高,抓包一看才发现每一次请求前都在完整地做一遍 TLS 握手——多轮往返加上一堆非对称加密运算,这笔昂贵的建立成本被我每个请求都重新付了一遍的深度复盘
我有个服务需要高频调用一个第三方 HTTPS 接口,客户端代码写得很朴素:每次要调用就新建一个 HTTPS 连接发请求拿响应关掉连接。功能完全正常但性能不对劲:单次延迟明显比纯网络往返加服务端处理该有的时间长出一截而且这一截稳定存在优化业务逻辑怎么都压不下去;CPU 莫名偏高调用量一大就明显升高和它就是个调接口的定位不符;低频还好一到高频延迟和 CPU 成倍放大;抓包发现每一次请求之前都有一整套 …- 0
- 0
-
.NET 9 gRPC 风控网关 HTTP/2 MaxConcurrentStreams 默认 100 雪崩 5 天复盘:上游 12 业务方接入 P99 飙 14 秒 + DEADLINE_EXCEEDED 47% + 漏拦欺诈 380 笔——Kestrel.MaxStreamsPerConnection 1000 + EnableMultipleHttp2Connections + KeepAlivePing + Polly 8 Resilience + dotnet-counters 6 套修法 + 13 条 gRPC 工程纪律
2026 年 3 月,我们一个核心风控网关(.NET 9 + Kestrel + gRPC 1.69 + 12 个上游业务方调用 + 7 个下游风控引擎服务、日均 RPC 调用 28 亿次、P99 SLO 80ms)在一次"上游业务方接入数量从 8 个扩展到 12 个"的灰度后第- 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
-
HTTP/2 多路复用真的快吗:一次 CDN 升级反而变慢的两周复盘
CDN 从 HTTP/1.1 升级到 HTTP/2,所有人都以为页面会加快,结果首屏时间反而从 800ms 涨到 1.2s,移动端弱网用户感受尤其明显。复盘了两周才搞明白,HTTP/2 的多路复用在某些场景下确实更慢,原因是底层 TCP 的队头阻塞被放大了。这篇把升级失败的完整过程、HTTP/2 真实的优劣场景、几种修法的取舍、以及最后部分回退到 HTTP/1.1 的决策依据完整讲一遍。- 4
- 0
-
gRPC 微服务通信完全指南:从一次"ClusterIP LB 让 99% 流量打一个 pod 单机 CPU 95%"看懂为什么 HTTP/2 + protobuf 远远不够
2023 年底我们公司启动微服务全栈改造把单体 Spring Boot 拆成 18 个 gRPC 服务期望解耦和性能提升架构师拍板 gRPC 性能比 REST 快 10 倍 type-safe IDL 优雅我们也信了开搞第一个月顺利上线性能压测确实快 3 倍服务间调用 P99 从 200ms 降到 60ms 大家很高兴但第二个月开始事故连连平均每周 2-3 次 P1 故障凌晨被告警叫醒 4 次然后…- 2
- 0
-
HTTP/2 完全指南:从一次"网站首页加载慢得想关掉,优化了文件却还是慢"看懂多路复用与队头阻塞
2021 年我接手优化公司官网首页打开一次要五六秒慢得让人想关掉怎么让它快起来这件事我压根没多想第一版我做得很顺手网上讲前端优化的文章都说慢就是因为文件又多又大那我照着做把几十个小 JS 小 CSS 合并成几个大 bundle 把零碎图标拼成雪碧图再把所有资源压缩一遍挂上 CDN 改完一测真不错首屏好像是快了那么一点点可等我盯着浏览器的 Network 瀑布图反复看等真实用户的访问数据回来一串问题…- 0
- 0
HTTP/2
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×