Azure同区域P1v2层App Service托管API间1-5%请求通信缓慢问题问询

可能的诱发原因 #

• SNAT端口耗尽：App Service出站请求默认依赖SNAT端口进行地址转换，P1v2层级单实例默认SNAT端口配额有限，如果源API的HTTP客户端没有复用连接，会快速消耗端口，新请求会排队等待端口释放，表现为端到端耗时高但目标侧无感知。
• HTTP短连接开销：如果源API没有开启HTTP长连接（Keep-Alive），每次跨API调用都需要重新完成TCP三次握手、TLS握手，偶发的网络抖动会放大建链耗时，这部分开销不会计入目标API的执行耗时。
• 源端连接池/线程池耗尽：如果HTTP客户端的连接池最大连接数配置过小，并发请求超过上限时会在源端排队等待可用连接，排队耗时全部累加在端到端总耗时中。
• DNS解析偶发延迟：如果调用目标API使用自定义域名，偶发的DNS递归查询超时、缓存失效都会导致解析耗时突增，这部分损耗也不会体现在目标侧的监控中。
• App Service出站限流：P1v2层级的App Service Plan有固定的出站带宽配额，即便是整体负载较低的时段，瞬时的出站流量突增也会触发限流，导致请求报文排队。
• Azure内部网络偶发抖动：同区域内计算节点间的虚拟网络链路偶发拥塞、数据包重传，也会导致端到端耗时升高。

进一步排查路径 #

• 核验SNAT端口使用情况：在源App Service的「诊断和解决问题」面板搜索「SNAT端口耗尽」，查看问题时段是否存在端口用尽、连接排队的告警记录。
• 检查HTTP客户端配置：确认源API代码中是否使用单例HttpClient、是否开启Keep-Alive、连接池最大连接数配置是否和实际并发请求量匹配。
• 拆解请求各阶段耗时：在源API侧新增埋点，分别记录DNS解析耗时、TCP建链耗时、TLS握手耗时、请求传输耗时、等待响应耗时，对比慢请求的各阶段耗时分布，直接定位损耗环节。
• 排查App Service网络指标：查看源App Service监控面板的出站带宽、TCP连接数、TCP重传率指标，确认问题时段是否存在指标突增的情况。
• 手动复现验证：登录源App Service的Kudu控制台，使用curl工具批量调用目标API，通过-w参数打印各阶段耗时，确认是否能复现偶发延迟的场景。

内容的提问来源于stack exchange，提问作者Saša