libcurl C++检测HTTPS响应码从503变为200出现长时间延迟

Q1：代码是否存在导致异常的错误 #

代码确实存在多个会触发该异常的问题：

• 未设置任何超时参数：CURLOPT_CONNECTTIMEOUT、CURLOPT_TIMEOUT均未配置，一旦出现连接异常会进入无限等待
• 未校验请求执行结果：curl_easy_perform的返回值未做判断，出现请求错误时仍会读取可能无效的历史响应码，无法及时触发重试
• 无间隔死循环发请求：高频请求极容易触发服务器的速率限制规则，导致请求被临时延迟处理
• 长连接复用逻辑缺陷：长期复用同一个CURL句柄保持keep-alive连接，当服务器在状态切换阶段主动断开旧的空闲连接时，libcurl默认无法及时感知连接失效，会等待内核TCP超时（默认15-20秒）后才会重建连接发送请求，刚好匹配你遇到的18秒延迟特征
• 未限制重定向次数：开启CURLOPT_FOLLOWLOCATION后如果遇到无限重定向场景会直接卡住
• 不必要的全量响应接收：当前代码会完整接收整个响应体后才返回响应码，200状态的响应体通常远大于503状态，会额外增加不必要的延迟。

Q2：2021年7月左右libcurl是否有相关影响的更新 #

确实存在匹配时间点的相关更新。Ubuntu 20.04官方源的libcurl4-openssl-dev在2021年7月中下旬推送了安全补丁，对应版本从7.68.0-1ubuntu2.5升级到7.68.0-1ubuntu2.7，其中修复了CVE-2021-22925漏洞，该补丁调整了libcurl对服务器端连接关闭提示的处理逻辑，会导致旧的长连接失效后无法被及时感知，和你遇到的问题现象、出现时间完全吻合。

Q3：是否是本地服务器设置导致的问题 #

大概率不是你主动修改配置导致，但存在几个系统默认配置会放大该问题：

• 系统默认TCP keepalive检测间隔过长：默认tcp_keepalive_time为7200秒，不会主动检测空闲连接是否已被服务器断开
• 若你调整过net.ipv4.tcp_syn_retries参数，值过大会导致重连时SYN包重试总耗时变长，刚好达到18秒左右的延迟
• 503状态下服务器直接返回静态响应，不需要处理业务逻辑，且此时你的请求频率还未触达限流阈值，所以响应很快；到状态切换的时间点请求频率达到峰值，刚好触发限流规则，才会出现200状态下响应变慢的现象。

可以按优先级尝试以下优化：

1. 每次请求后添加100~500毫秒的等待间隔，避免触发服务器限流
2. 新增CURLOPT_NOBODY参数，仅请求响应头不接收响应体，大幅降低请求耗时
3. 配置CURLOPT_CONNECTTIMEOUT为1秒、CURLOPT_TIMEOUT为2秒，超时后立即重试
4. 新增CURLOPT_MAXREDIRS配置，限制最多重定向5次
5. 每次执行请求前调用curl_easy_reset(curl)清理上一次请求的状态，或者每次请求新建、销毁CURL句柄，避免长连接复用问题
6. 开启libcurl层面的TCP keepalive检测：配置CURLOPT_TCP_KEEPALIVE为1、CURLOPT_TCP_KEEPIDLE为5、CURLOPT_TCP_KEEPINTVL为1，及时检测失效连接
7. 每次调用curl_easy_perform后先判断返回值是否为CURLE_OK，仅请求正常完成时再读取响应码

内容的提问来源于stack exchange，提问作者p.luck