Apache Traffic Server能确保每次都能获取到完整的web页面吗？

tao_627

各位老大，我是一直在研究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的。

淘宝的前辈，有空帮我看看，多谢了。急死了

tao_627

是否数据过大或造成接收的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压缩的格式，因为我得到后，处理前，还要解压缩；
按理说，压缩后的数据只是原长度的三分之一，得到完整的响应的概率会高些

tao_627

忘说了，我进行网络IO每次得到的事件是VC_EVENT_EOS，并不是我希望的VC_EVENT_READ_COMPLETE，这是什么原因呀？

tao_627

说实在的，觉得这个问题很好笑的。作为一个Http proxy/cache，ATS应该是可以处理数万并发的，如果不能确保每次都获得完整的web页面，那还有有何意义？
我个人觉得ATS中的HttpSM状态机是可以确保每次都很快获取完整的web页面，但是它的处理细节太过复杂，我只想一个简单的状态机就能完成这个功能，不知道这两者的区别有多大？

其实用PHP中的file_get_contents()之类的函数，很快就可以完整获取响应，真的没有必要绕这么远的路？但是如果我非要用C++来实现http协议，有何简单一些的方法呢？

aaaaaa

这两天有点折腾,没看到,周三有空看看你的问题,http是body是stream流,TS的核心设计是用状态机+http_tunnel用流的方式实现数据各种filter过程.由于ts的异步方式,写个handler啥的也是必需的啊

weilog

你不能正常取到完整数据（EVENT_EOS)，说明是连接（TCP）已经断掉了，这可能数据已经传输完整也可能被截断，总的说来我认为这种情况应该极小概率发生才对。（私下的认为：会不会你们测试cnbeta的服务器认为你们是恶意访问，把你们ip屏蔽了一段时间，^_^）。自己先搭个服务器，如果还有问题，把核心代码贴出来我看看，如果不是太私密的话。

marsbible

你用ts实现这个没必要啊？他里面先读取头部，后续看情况从server读取。你直接写个简单的http client不就得了吗？用libcurl，分分钟的事情.

tao_627

多谢几位前辈的指点，我在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中没有地方用到，我只能借鉴其手法，欢迎有兴趣的朋友交流。

guozi058

代码能分享研究一下吗？