Apache Traffic Server能確保每次都能獲取到完整的web頁面嗎？

tao_627

各位老大，我是一直在研究Apache Traffic Server（以下簡稱ATS）的，最近有業(yè)務(wù)需求，需要ATS快速獲取完整的http response body，但是令我沮喪的是，我一連用了兩種方法，都無法每次獲取到完整的http response body。希望高手指點。
業(yè)務(wù)需求：給定url，一次快速獲取完整的http response body
下面是我嘗試過的方法：
方法1：仿照simplecont狀態(tài)機，直接dns解析url，再連接OS，發(fā)送request，接收response；
方法2：仿照prefetch思路，連接并向127.0.0.1:8080本地代理端口發(fā)送http請求，接收response。

以上兩種方法，都無法確保每次獲取到完整的http response body，而且我發(fā)現(xiàn)，在方法2中，僅當獲取到完整的http response body時，cache中才有數(shù)據(jù)。
可是我覺得ATS的HttpSM貌似是一次就能獲取到response body的。

淘寶的前輩，有空幫我看看，多謝了。急死了

tao_627

是否數(shù)據(jù)過大或造成接收的response body不完整？因為我自己構(gòu)造的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壓縮的格式，因為我得到后，處理前，還要解壓縮；
按理說，壓縮后的數(shù)據(jù)只是原長度的三分之一，得到完整的響應(yīng)的概率會高些

tao_627

忘說了，我進行網(wǎng)絡(luò)IO每次得到的事件是VC_EVENT_EOS，并不是我希望的VC_EVENT_READ_COMPLETE，這是什么原因呀？

tao_627

說實在的，覺得這個問題很好笑的。作為一個Http proxy/cache，ATS應(yīng)該是可以處理數(shù)萬并發(fā)的，如果不能確保每次都獲得完整的web頁面，那還有有何意義？
我個人覺得ATS中的HttpSM狀態(tài)機是可以確保每次都很快獲取完整的web頁面，但是它的處理細節(jié)太過復(fù)雜，我只想一個簡單的狀態(tài)機就能完成這個功能，不知道這兩者的區(qū)別有多大？

其實用PHP中的file_get_contents()之類的函數(shù)，很快就可以完整獲取響應(yīng)，真的沒有必要繞這么遠的路？但是如果我非要用C++來實現(xiàn)http協(xié)議，有何簡單一些的方法呢？

aaaaaa

這兩天有點折騰,沒看到,周三有空看看你的問題,http是body是stream流,TS的核心設(shè)計是用狀態(tài)機+http_tunnel用流的方式實現(xiàn)數(shù)據(jù)各種filter過程.由于ts的異步方式,寫個handler啥的也是必需的啊

weilog

你不能正常取到完整數(shù)據(jù)（EVENT_EOS)，說明是連接（TCP）已經(jīng)斷掉了，這可能數(shù)據(jù)已經(jīng)傳輸完整也可能被截斷，總的說來我認為這種情況應(yīng)該極小概率發(fā)生才對。（私下的認為：會不會你們測試cnbeta的服務(wù)器認為你們是惡意訪問，把你們ip屏蔽了一段時間，^_^）。自己先搭個服務(wù)器，如果還有問題，把核心代碼貼出來我看看，如果不是太私密的話。

marsbible

你用ts實現(xiàn)這個沒必要��？他里面先讀取頭部，后續(xù)看情況從server讀取。你直接寫個簡單的http client不就得了嗎？用libcurl，分分鐘的事情.

tao_627

多謝幾位前輩的指點，我在ATS中已經(jīng)使用libcurl來作為http client實現(xiàn)抓取指定url的html頁面，而且是多線程多并發(fā)。目前已經(jīng)能夠滿足我的業(yè)務(wù)需求，而且libcurl比較好的地方時，會自動解壓數(shù)據(jù)，會自動dechunk數(shù)據(jù)，會自動處理302重定向，等等比較底層的http 交互細節(jié)，保證我獲得的數(shù)據(jù)就是一個完整的html頁面。

如果大家有興趣，歡迎交流討論多線程下的libcurl調(diào)用問題。

但是作為研究的目的，我還是想和各位討論一下，在ATS中模擬客戶端發(fā)送http request，并快速獲取http response的問題。
下面是對幾位前輩的回復(fù)：

to aaaaaa：
ATS處理http請求的思路的確是http tunnel的形式，就是一個producer產(chǎn)生數(shù)據(jù)，多個consumer接收數(shù)據(jù)，共同消費producer的數(shù)據(jù)緩存，這一點在SimpleHttp.cc中很清楚，我也是仿照它寫的狀態(tài)機，但是我沒有使用這種典型的tunnel方法，

   OS===========>ATS=======>UA
                                    |
                                     =========>Cache
我只用到了前半部分，就是一個consumer，一個producer，對數(shù)據(jù)緩存MIOBuffer，每次從中復(fù)制數(shù)據(jù)后，就consume（），同時vio->reenable()，這樣有時一次獲得完整的數(shù)據(jù)，有時一次不能獲得完整的數(shù)據(jù)。也許使用tunnel的方法，結(jié)果會好些，尚待驗證測試；

to weilog：
您說的數(shù)據(jù)可能完整也可能是截斷，這是對的，我目前只用到OS=====>ATS這段流程，在大并發(fā)異步的情況下，對不同的http connection，有時EVENT_EOS事件要等很長時間才能收到，我懷疑是否這種連接要加入保活（keep-alive）或超時（timeout）處理，對那些pending的連接是否需要再次觸發(fā)？貌似這樣的處理有些太復(fù)雜了，在一個狀態(tài)機里處理不了這么多細節(jié)。
另外，這個http request僅是一個例子，對很多網(wǎng)站都是這種情況，不限cnBeta。
代碼的問題，我稍后整理下，在貼出來，這幾天有些忙。

另外，在ATS\proxy中，我發(fā)現(xiàn)有個FetchSM.h/cc的，似乎就是干的這個事，它是基于TS API，有個接口TSFetchPage()似乎就是干這個事，可是這個接口，ATS中沒有地方用到，我只能借鑒其手法，歡迎有興趣的朋友交流。

guozi058

代碼能分享研究一下嗎？