libcurl的使用问题“Expect100-continue”

标签：blog   http   io   ar   os   使用   sp   strong   on   

最近在做团购酒店APP分享到qzone功能，使用libcurl访问qzone的分享cgi接口，酒店分享信息以POST方式传输，在测试的时候发现分享接口平均有2s的延迟，这延迟也太大了吧，于是乎问了空间的接口人，答曰：怎么可能，这个接口的平均调用时延是100-200ms，肯定是你的代码有问题。好吧，开始检查代码，使用strace -p跟踪系统调用，发现curl发送了两次请求，其中第一次请求的响应特别的慢，额，原来这个才是导致延迟的罪魁祸首，tcpdump之后发现curl发送的第一个请求包含一个Expect: 100-continue的头，这是为什么呢，于是开始百度，google，得到的解释如下：

当使用libcurl的POST方式时，如果POST数据的大小大于1024个字节，libcurl不会直接发送POST请求，而是会分为两步执行请求：
1、发送一个请求，该请求头部包含一个Expect： 100-continue的字段，用来询问server是否愿意接受数据
2、当接收到从server返回的100-continue的应答后，它才会真正的发起POST请求，将数据发送给server。

对于“100-continue"这个字段，RFC文档（http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3）是这么解释的：它可以让客户端在发送请求数据之前去判断服务器是否愿意接收该数据，如果服务器愿意接收，客户端才会真正发送数据，这么做的原因是如果客户端直接发送请求数据，但是服务器又将该请求拒绝的话，这种行为将带来很大的资源开销。所以为了避免这种情况，libcurl在发送大于1024字节的POST请求时采用了这种方法，但是相对的，它会引起请求延迟的加大，另外并不是所有的server都会正确处理并且应答”100-continue“，比如lighttpd，就会返回417”Expectation Failed“，造成请求逻辑出错。

如果确定服务器不会拒绝1024个字节以上的POST请求，就可以不使用该方法而且也可以避免以上提到的两个副作用，解决的办法如下：

禁用该机制后，测试了一下qzone分享接口平均调用时延减小到了200ms，这才是正常的延时嘛，嘿嘿。
参考资料:
http://www.laruence.com/2011/01/20/1840.html

from:http://blog.csdn.net/zxgfa/article/details/7604624

libcurl的使用问题“Expect100-continue”

标签：blog   http   io   ar   os   使用   sp   strong   on   

原文地址：http://www.cnblogs.com/lidabo/p/4159382.html