本文主要介绍curl异步接口的使用方式，以及获取高性能的一些思路和实践。同时假设读者已经熟悉并且使用过同步接口。

1.curl接口基本介绍

curl一共有三种接口：

• Easy Interface
• Multi Interface
• Share Interface

1.1 Easy Interface

Easy下是同步接口，curl_easy_*的形式，基本处理方式有几个步骤：

1. curl_easy_init获取easy handle
2. curl_easy_setopt设置header/cookie/post-filed/网页内容接收回调函数等
3. curl_easy_perform执行
4. curl_easy_cleanup清理
   注意在第3步是阻塞的

1.2 Multi Interface

Multi下是异步接口，curl_multi_*的形式，允许在单线程下同时操作多个easy handle，基本处理方式有几个步骤：

1. curl_multi_init获取multi handle
2. 调用Easy Interface设置若干easy handle，通过curl_multi_add_handle.加到1里的multi handle
3. 调用curl_multi_wait/curl_multi_perform等待所有easy handle处理完成
4. curl_multi_info_read依次读取所有数据
5. curl_multi/easy_cleanup清理
   注意curl_multi_perform不是阻塞的

1.3 Share Interface

Share是共享接口，curl_shared_*的形式，用于多个easy handle间共享一些数据，例如cookie dns等
注意需要用到锁的情况，比如share了CURL_LOCK_DATA_DNS，如果没有加锁，在curl_multi_perform时会core掉:

Since you can use this share from multiple threads, and libcurl has no internal thread synchronization, you must provide mutex callbacks if you’re using this multi-threaded. You set lock and unlock functions with curl_share_setopt too.

可以参考这两处例子：

1. http://www.mit.edu/afs.new/sipb/user/ssen/src/curl-7.11.1/tests/libtest/lib506.c
2. https://curl.haxx.se/mail/lib-2006-01/0218.html

2. 异步接口的例子

curl自带的例子还是介绍的curl_multi_fdset的方法。
实际上已经可以用curl_multi_wait代替了，据说是facebook的工程师提的升级：
Facebook contributes fix to libcurl’s multi interface to overcome problem with more than 1024 file descriptors.
使用方法可以参考这里

通过一个示例来看下multi的工作方式（注意出于简短的目的，有的函数没有判断返回值）

#include "curl/curl.h"
#include 

const char* url = "http://www.baidu.com";
const int count = 1000;

size_t write_data(void* buffer, size_t size, size_t count, void* stream) {
    (void)buffer;
    (void)stream;
    return size * count;
}

void curl_multi_demo() {
    CURLM* curlm = curl_multi_init();

    for (int i = 0; i < count i curl easy_handle='curl_easy_init();' curl_easy_setopteasy_handle curlopt_nosignal 1 curl_easy_setopteasy_handle curlopt_url url curl_easy_setopteasy_handle curlopt_writefunction write_data curl_multi_add_handlecurlm easy_handle int running_handlers='0;' do curl_multi_waitcurlm null 0 2000 null curl_multi_performcurlm running_handlers while running_handlers> 0);

    int msgs_left = 0;
    CURLMsg* msg = NULL;
    while ((msg = curl_multi_info_read(curlm, &msgs_left)) != NULL) {
        if (msg->msg == CURLMSG_DONE) {
            int http_status_code = 0;
            curl_easy_getinfo(msg->easy_handle, CURLINFO_RESPONSE_CODE, &http_status_code);
            char* effective_url = NULL;
            curl_easy_getinfo(msg->easy_handle, CURLINFO_EFFECTIVE_URL, &effective_url);
            fprintf(stdout, "url:%s status:%d %s\n",
                    effective_url,
                    http_status_code,
                    curl_easy_strerror(msg->data.result));

            curl_multi_remove_handle(curlm, msg->easy_handle);
            curl_easy_cleanup(msg->easy_handle);
        }
    }

    curl_multi_cleanup(curlm);
}

int main() {
    curl_multi_demo();
    return 0;
}

注意L35~36 L37~38不能互换，否则url为空，原因没有继续深追。

可以看到异步处理的方式是通过curl_multi_add_handle接口不断的把待抓的easy handle放到multi handle里。然后通过curl_multi_wait/curl_multi_perform等待所有easy handle处理完毕。
因为是同时在等待所有easy handle处理完毕，耗时比easy方式里逐个同步等待大大减少。其中产生hold作用的是在这段代码里：

//等待所有easy handle处理完毕
do {
    ...
} while (running_handlers > 0);

3.应用

而在实际应用中，我们的使用场景往往是这样的：

某个负责抓取数据的模块，service监听端口接收url，抓取数据后发往下游。

因为不希望所有的线程都处于上面multi示例中的等待（什么都不做）。于是就有了这种想法：接收到一条url后构造对应的easy handle，通过curl_multi_add_handle接口放入curlm后返回。同时两个线程不断的wait/perform和read，如果有完成的url，那么就调用对应的回调函数即可。
相当于将curlm当做一个队列，两个线程分别充当了生产者和消费者。

模型类似于：

CURLM* curlm = curl_multi_init()

//Thread-Consumer
	while true:
		//读取已经完成的url
		curl_multi_info_read
		//通知该url已完成，并且从curlm里删除
		curl_multi_remove_handle
		
//Thread-Producer
	while true:
		//等待可读socket
		curl_multi_wait
		//查看运行中的easy handle数目
		curl_multi_perform
		
//Thread-Other
	//根据url构造CURL easy handle
	CURL* curl = make_curl_easy_handle(url)
	//添加到curlm
	curl_multi_add_handle

做了一下测试很快就放弃了，程序在libcurl内部函数里core掉。
实际上curl是线程安全的，但同时也格外强调了这点：

The first basic rule is that you must never share a libcurl handle (be it easy or multi or whatever) between multiple threads. Only use one handle in one thread at a time.

具体可以参考这里，说明上面的模型是不可行的。

看到这里有一个基于libcurl的单线程I:O多路复用HTTP框架，dispatch部分和chrome源码里的thread模型很像，CURLM*对象在Dispatch::IO线程里统一操作，同时全局唯一，在一个LazyInstance的ConnectionRunner里维护。不过没有找到dispatch_after的实现，所以不太确定。

在StackOverflow上看到了复用curl的想法：curl handler放在一个池子中，需要时从中获取，使用后归还，同样不可行。

因此，标准的写法就是之前的示例的代码，正如这里提到的：

The multi interface is designed for this purpose: you add multiple handles and then process all of them with one call, all in the same thread.

4.优化

接下来就是优化的问题，在不使用curl_multi_socket_*的接口的情况下，是否有办法提升性能呢？
参考了curl的Persistence一节，主要是持久化部分信息来加速（缓存）。
其中提到

Each easy handle will attempt to keep the last few connections alive for a while in case they are to be used again.

这里说到每个easy handle会缓存之前的若干连接来避免重连、缓存DNS等以提高性能。因此一些思路就是easy handle重用、dns全局缓存等。

5.测试&结论

按照上面的思路分别测试抓取1000次baidu首页

1. 串行使用curl easy接口
2. 10个线程并行使用curl easy接口
3. 使用curl multi接口
4. 使用curl multi接口,并且reuse connection。（方法是第一遍curl easy handle抓取后不cleanup，计算第二次全部抓取完成的时间）
5. 使用dns cache（使用curl_share_*接口，第一次抓取用于dnscache填充，计算第二次全部抓取完成的时间。效果上打开VERBOSE可以看到hostname found in DNS Cache）

其中处理时间测试结论如下：

methodavgmaxmineasy16.45721.61714.262easy parallel2.3319.4961.723multi0.7348.8950.259multi reuse0.001130.0015570.000898multi reuse cache0.001090.001400.000828

4 5的区别不大，同时不确定重用connection的情况下，dnscache是否还能起到正向作用

对应的测试代码都放到了gist上：1 2 3 4 5

6.补充

关于curl性能的讨论帖子很多，比如这里，其中也讲到了获取网页的一个基本流程：

1. Request from your DNS server, the IP corresponding to the name of the site you requested
2. Use the server’s reply to open a socket to that IP, port 80
3. Send a small HTTP message describing what you want
4. Receive the html code

这里有一些关于performance的建议，用到了curl_multi_socket_*接口，我没有用到。