睿豐德科技 專注RFID識別技術和條碼識別技術與管理軟件的集成項目。質量追溯系統、MES系統、金蝶與條碼系統對接、用友與條碼系統對接

最近在做團購酒店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請求，就可以不使用該方法而且也可以避免以上提到的兩個副作用，解決的辦法如下：

 

[cpp] view plaincopy  

1. // disable Expection header   
2. curl_easy_setopt(curl, CURLOPT_HTTPHEADER, array('Expect:'));  

禁用該機制后，測試了一下qzone分享接口平均調用時延減小到了200ms，這才是正常的延時嘛，嘿嘿。
參考資料:
http://www.laruence.com/2011/01/20/1840.html

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

RFID管理系統集成商 RFID中間件 條碼系統中間層 物聯網軟件集成