http://blog.csdn.net/wslz2001/article/details/12117127
默認情況下libcurl完成一個任務以后，出於重用連接的考慮不會馬上關閉
如果沒有新的TCP請求來重用這個連接，那么只能等到CLOSE_WAIT超時，這個時間默認在7200秒甚至更高，太多的CLOSE_WAIT連接會導致性能問題
解決方法：
curl_easy_setopt(curl, CURLOPT_FORBID_REUSE, 1);
最好再修改一下TCP參數調低CLOSE_WAIT和TIME_WAIT的超時時間
2. libcurl 有個很好的特性，它甚至可以控制域名解析的超時。但是在默認情況下，它是使用alarm + siglongjmp 實現的。用alarm在多線程下做超時，本身就幾乎不可能。如果只是使用alarm，並不會導致程序崩潰，但是，再加上siglongjmp，就要命了 （程序崩潰的很可怕，core中幾乎看不出有用信息），因為其需要一個sigjmp_buf型的全局變量，多線程修改它。（通常情況下，可以每個線程一個 sigjmp_buf 型的變量，這種情況下，多線程中使用 siglongjmp 是沒有問題的，但是libcurl只有一個全局變量，所有的線程都會用）。
具 體是類似 curl_easy_setopt(curl, CURLOPT_TIMEOUT, 30L) 的超時設置，導致alarm的使用（估計發生在域名解析階段），如前所述，這在多線程中是不行的。解決方式是禁用掉alarm這種超時， curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1L)。
這樣，多線程中使用超時就安全了。但是域名解析就沒了超時機制，碰到很慢的域名解析，也很麻煩。文檔的建議是 Consider building libcurl with c-ares support to enable asynchronous DNS lookups, which enables nice timeouts for name resolves without signals. c-ares 是異步的 DNS 解決方案。
http://blog.csdn.net/wslz2001/article/details/12117127