Apache Traffic Server能確保每次都能獲取到完整的web頁面嗎？
各位老大，我是一直在研究Apache Traffic Server（以下簡稱ATS）的，最近有業務需求，需要ATS快速獲取完整的http response body，但是令我沮喪的是，我一連用了兩種方法，都無法每次獲取到完整的http response body。希望高手指點。
業務需求：給定url，一次快速獲取完整的http response body
下面是我嘗試過的方法：
方法1：仿照simplecont狀態機，直接dns解析url，再連接OS，發送request，接收response；
方法2：仿照prefetch思路，連接並向127.0.0.1:8080本地代理埠發送http請求，接收response。
以上兩種方法，都無法確保每次獲取到完整的http response body，而且我發現，在方法2中，僅當獲取到完整的http response body時，cache中才有數據。
可是我覺得ATS的HttpSM貌似是一次就能獲取到response body的。
淘寶的前輩，有空幫我看看，多謝了。急死了
《解決方案》
是否數據過大或造成接收的response body不完整？因為我自己構造的request如下：
+++++++++ Request Header created for ProxyFetchPageSM +++++++++
-- State Machine Id: 0
GET http://www.cnbeta.com/articles/192944.htm HTTP/1.1
Host: www.cnbeta.com
Proxy-Connection: close
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.83 Safari/535.11
Accept: */*
我的本意是不希望獲取gzip壓縮的格式，因為我得到后，處理前，還要解壓縮；
按理說，壓縮后的數據只是原長度的三分之一，得到完整的響應的概率會高些
《解決方案》
忘說了，我進行網路IO每次得到的事件是VC_EVENT_EOS，並不是我希望的VC_EVENT_READ_COMPLETE，這是什麼原因呀？
《解決方案》
說實在的，覺得這個問題很好笑的。作為一個Http proxy/cache，ATS應該是可以處理數萬併發的，如果不能確保每次都獲得完整的web頁面，那還有有何意義？
我個人覺得ATS中的HttpSM狀態機是可以確保每次都很快獲取完整的web頁面，但是它的處理細節太過複雜，我只想一個簡單的狀態機就能完成這個功能，不知道這兩者的區別有多大？
其實用PHP中的file_get_contents()之類的函數，很快就可以完整獲取響應，真的沒有必要繞這麼遠的路？但是如果我非要用C++來實現http協議，有何簡單一些的方法呢？
《解決方案》
這兩天有點折騰,沒看到,周三有空看看你的問題,http是body是stream流,TS的核心設計是用狀態機+http_tunnel用流的方式實現數據各種filter過程.由於ts的非同步方式,寫個handler啥的也是必需的啊
《解決方案》
你不能正常取到完整數據（EVENT_EOS)，說明是連接（TCP）已經斷掉了，這可能數據已經傳輸完整也可能被截斷，總的說來我認為這種情況應該極小概率發生才對。（私下的認為：會不會你們測試cnbeta的伺服器認為你們是惡意訪問，把你們ip屏蔽了一段時間，^_^）。自己先搭個伺服器，如果還有問題，把核心代碼貼出來我看看，如果不是太私密的話。
《解決方案》
你用ts實現這個沒必要啊？他裡面先讀取頭部，後續看情況從server讀取。你直接寫個簡單的http client不就得了嗎？用libcurl，分分鐘的事情.
《解決方案》
多謝幾位前輩的指點，我在ATS中已經使用libcurl來作為http client實現抓取指定url的html頁面，而且是多線程多併發。目前已經能夠滿足我的業務需求，而且libcurl比較好的地方時，會自動解壓數據，會自動dechunk數據，會自動處理302重定向，等等比較底層的http 交互細節，保證我獲得的數據就是一個完整的html頁面。
如果大家有興趣，歡迎交流討論多線程下的libcurl調用問題。
但是作為研究的目的，我還是想和各位討論一下，在ATS中模擬客戶端發送http request，並快速獲取http response的問題。
下面是對幾位前輩的回復：
to aaaaaa：
ATS處理http請求的思路的確是http tunnel的形式，就是一個producer產生數據，多個consumer接收數據，共同消費producer的數據緩存，這一點在SimpleHttp.cc中很清楚，我也是仿照它寫的狀態機，但是我沒有使用這種典型的tunnel方法，
OS===========>ATS=======>UA
|
=========>Cache
我只用到了前半部分，就是一個consumer，一個producer，對數據緩存MIOBuffer，每次從中複製數據后，就consume（），同時vio->reenable()，這樣有時一次獲得完整的數據，有時一次不能獲得完整的數據。也許使用tunnel的方法，結果會好些，尚待驗證測試；
to weilog：
您說的數據可能完整也可能是截斷，這是對的，我目前只用到OS=====>ATS這段流程，在大併發非同步的情況下，對不同的http connection，有時EVENT_EOS事件要等很長時間才能收到，我懷疑是否這種連接要加入保活（keep-alive）或超時（timeout）處理，對那些pending的連接是否需要再次觸發？貌似這樣的處理有些太複雜了，在一個狀態機里處理不了這麼多細節。
另外，這個http request僅是一個例子，對很多網站都是這種情況，不限cnBeta。
代碼的問題，我稍後整理下，在貼出來，這幾天有些忙。
另外，在ATS\proxy中，我發現有個FetchSM.h/cc的，似乎就是乾的這個事，它是基於TS API，有個介面TSFetchPage()似乎就是干這個事，可是這個介面，ATS中沒有地方用到，我只能借鑒其手法，歡迎有興趣的朋友交流。
《解決方案》
代碼能分享研究一下嗎？
