Traffic Server 穿透问题

aaaaaa

3.2社区版本？ 社区版本里有个问题，不能存储body size=0的任何结果（其实这是RFC的要求），我们在TS-621上有相关的patch，或者参考我们公开的3.2代码：
https://gitorious.org/trafficserver/taobao/ branch 3.2

另一个是你的negative cache没有启用，如果你的这次穿透的请求里404 403啥的比较多的话，可以考虑启用这个：
   #############################
   # negative response caching #
   #############################
CONFIG proxy.config.http.negative_caching_enabled INT 0
CONFIG proxy.config.http.negative_caching_lifetime INT 1800

再有就是多副本情况，建议你用http_ui看看cache中存储的这些内容，是不是多副本不够多造成的问题。可以考虑提高：
   # The maximum number of alternates that are allowed for any given URL.
   # It is not possible to strictly enforce this if the variable
   #   'proxy.config.cache.vary_on_user_agent' is set to 1.
   # The default value for 'proxy.config.cache.vary_on_user_agent' is 0.
   # (0 disables the maximum number of alts check)
CONFIG proxy.config.cache.limits.http.max_alts INT 5

还有，如果你没有准确的expire时间的话，存储也可能成问题，建议看看调整：
   # required headers: three options:
   #   0 - No required headers to make document cachable
   #   1 - "Last-Modified:", "Expires:", or "Cache-Control: max-age" required
   #   2 - explicit lifetime required, "Expires:" or "Cache-Control: max-age"
CONFIG proxy.config.http.cache.required_headers INT 2


暂时想到这几个方向，从你贴出来的response看不懂为啥。用http_ui看看这些cache的内容，或许有些发现

aaaaaa

20个副本都不够的情况也可能是存在的。TS在作副本match的时候，存在一个不是最match的可能，结果会一直往cache系统里写入。我建议你用http_ui把相关的副本dump出来，这个会是一个非常好的可以用来改进TS的match代码的例子，一定要搞出来这个：
http://people.apache.org/~zym/trafficserver/FAQ.html 有关于http_ui的说明

aaaaaa

TS的多副本match是让我吐血的一点之一。这个地方需要动些手脚。

proxy.config.http.normalize_ae_gzip有效果也还可以啊。再看看后面其他穿透的还有问题吗

aaaaaa

取决于返回头的控制，是否有cache的控制以及是否有cookie，如果返回没有cookie而采用如url格式识别，你的方法就不对啦，建议对这个请求进一步分析，如用firebug来显示出请求和response头，好好看看