4年前PHP Curl毫秒超时问题现在怎么样了？

江湖惯例，先上结论：

PHP 7和libcurl 7.60.0对curl毫秒超时理论都是支持的，但如果DNS使用同步解析模式（部分Linux发行版缺省为依赖alram信号的同步模式），则无法支持毫秒

通过设置


           CURLOPT_NOSIGNAL

（Guzzle毫秒的缺省处理），会设置DNS解析不超时，一旦DNS异常将导致服务阻塞，简单粗暴风险高

建议方案：配置curl时启用异步DNS解析特性，两种异步DNS解析特性均可


           ./configure --enable-ares

：开启c-ares


          ./configure --enable-threaded-resolver

：开启threaded-resolver

二者对比说明： libcurls-name-resolving

CentOS 7中缺省编译的Curl已配置异步DNS解析，也就说CentOS7下PHP 7 完美支持毫秒超时

鸟哥在14年抛出的问题

问题起源： Laruence：21 Jan 14 Curl的毫秒超时的一个”Bug”

问题描述：

libcurl 新版本支持毫秒级超时，升级PHP后，设置毫秒超时直接返回超时错误（ Timeout reached 28 ）

解决方案：


          curl_setopt($ch, CURLOPT_NOSIGNAL, 1);

禁用信号，直接跳过DNS解析超时校验

缺点：DNS解析不受控制，如果DNS服务异常，且无超时，导致整个应用大面积阻塞


          libcurl

编译时启用


          c-ares

进行DNS解析，如此配置


          ./configure --enable-ares[=PATH]

缺点：依赖libcurl编译时配置

PHP文档中关于 `TIMEOUT_MS` 说明

看下PHP文档里的说明： http://php.net/manual/zh/function.curl-setopt.php

CURLOPT_CONNECTTIMEOUT_MS

尝试连接等待的时间，以毫秒为单位。设置为0，则无限等待。如果 libcurl 编译时使用系统标准的名称解析器（ standard system name resolver），那部分的连接仍旧使用以秒计的超时解决方案，最小超时时间还是一秒钟。

在 cURL 7.16.2 中被加入。从 PHP 5.2.3 开始可用。

The number of milliseconds to wait while trying to connect. Use 0 to wait indefinitely. If libcurl is built to use the standard system name resolver, that portion of the connect will still use full-second resolution for timeouts with a minimum timeout allowed of one second.

Added in cURL 7.16.2. Available since PHP 5.2.3.

2018年的今天这个问题如何


          curl-7.60.0

中同样保持此段代码，原因在于使用Linux默认的


          SIGALARM

进行DNS解析时，alarm()最小时间为1秒

因此缺省情况下，直接使用毫秒仍然会有问题


          curl-7.60.0.tar.gz

中相关部分代码如下：

int Curl_resolv_timeout(struct connectdata *conn,
                        const char *hostname,
                        int port,
                        struct Curl_dns_entry **entry,
                        time_t timeoutms)
#ifdef USE_ALARM_TIMEOUT
  if(data->set.no_signal)  // 设置no_signal，则timeout为0，忽略超时
    /* Ignore the timeout when signals are disabled */
    timeout = 0;
    timeout = (timeoutms > LONG_MAX) ? LONG_MAX : (long)timeoutms;
  if(!timeout)  // timeout=0，则无超时解析
    /* USE_ALARM_TIMEOUT defined, but no timeout actually requested */
    return Curl_resolv(conn, hostname, port, entry);
  if(timeout < 1000) { // 如果timeout < 1000，则直接返回CURLRESOLV_TIMEDOUT超时，增加了日志输出
    /* The alarm() function only provides integer second resolution, so if
       we want to wait less than one second we must bail out already now. */
    failf(data,
        "remaining timeout of %ld too small to resolve via SIGALRM method",
        timeout);
    return CURLRESOLV_TIMEDOUT;
Guzzle Http中是否有规避策略
guzzlehttp/guzzle 6.2中
如果设置timeout时间小于1，则guzzle会设置CURLOPT_NOSIGNAL=true
代码如下：
$timeoutRequiresNoSignal = false;
if (isset($options['timeout'])) {
    $timeoutRequiresNoSignal |= $options['timeout'] < 1;  // 超时时间小于1，则设置NoSignal=1
    $conf[CURLOPT_TIMEOUT_MS] = $options['timeout'] * 1000;
// CURL default value is CURL_IPRESOLVE_WHATEVER
if (isset($options['force_ip_resolve'])) {
    if ('v4' === $options['force_ip_resolve']) {
        $conf[CURLOPT_IPRESOLVE] = CURL_IPRESOLVE_V4;
    } else if ('v6' === $options['force_ip_resolve']) {
        $conf[CURLOPT_IPRESOLVE] = CURL_IPRESOLVE_V6;
if (isset($options['connect_timeout'])) {
    $timeoutRequiresNoSignal |= $options['connect_timeout'] < 1; // 超时时间小于1，则设置NoSignal=1
    $conf[CURLOPT_CONNECTTIMEOUT_MS] = $options['connect_timeout'] * 1000;
if ($timeoutRequiresNoSignal && strtoupper(substr(PHP_OS, 0, 3)) !== 'WIN') {
    $conf[CURLOPT_NOSIGNAL] = true;
在某个老版本guzzle中发现并未兼容的老代码：
if (isset($options['timeout'])) {
    $conf[CURLOPT_TIMEOUT_MS] = $options['timeout'] * 1000;
if (isset($options['connect_timeout'])) {
    $conf[CURLOPT_CONNECTTIMEOUT_MS] = $options['connect_timeout'] * 1000;
CentOS 7中curl
CentOS 7中缺省携带的curl编译已配置threaded-resolver，也就是说CentOS 7 + PHP 7组合使用毫秒超时很安全。
补充一点curl支持异步DNS的方式有两种：c-ares和threaded-resolver（centos 7中缺省启用threaded-resolver）
附带两个查看本机curl编译配置的命令：
curl --version：AsynchDNS表示支持异步DNS特性
curl-config --configure：查看编译时配置
附录不同CentOS下curl缺省编译配置：
CentOS 6.5
>curl --version
curl 7.37.0 (x86_64-unknown-linux-gnu) libcurl/7.37.0 OpenSSL/1.0.1e zlib/1.2.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp 
Features: Largefile NTLM NTLM_WB SSL libz
> curl-config --configure
'--with-ssl' '--with-ipv6' '--enable-ldap' '--enable-ldaps'
CentOS 7
> cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core) 
> curl --version
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.19.1 Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz
> curl-config --configure
'--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-static' '--enable-hidden-symbols' '--enable-ipv6' '--enable-ldaps' '--enable-manual' '--enable-threaded-resolver' '--with-ca-bundle=/etc/pki/tls/certs/ca-bundle.crt' '--with-gssapi' '--with-libidn' '--with-libssh2' '--without-ssl' '--with-nss' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro '
curl timeout less than 1000ms always fails?
Laruence：21 Jan 14 Curl的毫秒超时的一个”Bug”

4年前PHP Curl毫秒超时问题现在怎么样了？

鸟哥在14年抛出的问题

PHP文档中关于 TIMEOUT_MS 说明

2018年的今天这个问题如何

Guzzle Http中是否有规避策略

CentOS 7中curl

PHP文档中关于 `TIMEOUT_MS` 说明