PHP's curl function simulates post data submission. The first processing method is very slow.

If you use the curl_setopt function to process a remote WebService or capture a page, sometimes it is very strange that the first access speed is exceptionally slow, basically, it takes 5-10 s to let people crash.

But how can we find out what the problem is?ArticleWrite the method to solve this problem.

Start with solving the problem:

1. curl_setopt ($ ch, curlopt_http_version, curl_http_version_1_0); // The mandatory protocol is 1.0.

2. curl_setopt ($ ch, curlopt_httpheader, array (''ct: ''); // the header must send 'Expect CT :'

3. curl_setopt ($ ch, curlopt_ipresolve, curl_ipresolve_v4); // force domain name resolution using IPv4 protocol

I can't do either of the three.

Wrong CT: 100-continue problem: reproduced in: http://www.laruence.com/2011/01/20/1840.html

When using curl for post, when the data to be post is larger than 1024 bytes, curl does not directly initiate a POST request, but is divided into two steps,
1. Send a request that contains a response CT: 100-continue and ask the server if it is willing to accept data.
2. After receiving the 100-continue response returned by the server, the data is post to the server.

This is the behavior of libcurl.
Specific RFC Description: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3
So there is a problem. Not all servers will correctly respond to 100-continue. For example, Lighttpd will return 417 "expectation failed", which will cause a logic error ,,

Solution: curl_setopt ($ ch, curlopt_httpheader, array (''ct: ''); // the header must be 'ct :'

IPv4 problem: Reproduced in http://www.lovelucy.info/curl-exec-wget-slow-due-to-ipv6.html

At present, many servers enable IPv6 without routing and cannot work, which leads to unexpected problems.