ats缓存规则

一. 用户访问过程:
1. ats收到一个用户对web对象的请求;
2. 使用该地址, ats尝试着在其对象数据库(缓存)中用被请求对象的地址来定位该对象;
3. 如果对象在缓存中， ats会检查该对象是否过期，如果对象没有过期, ats以缓冲命中的方式用该对象来响应用户;
4. 如果缓存中的数据已经过期， ats连接源服务器并检查该对象是否仍然可用(重新生效).如果生效，ats直接发送缓存中的对象给用户;
5. 如果对象没有在缓存中(缓存未命中)或者源服务器显示缓存中的对象已经失效，ats会从源服务器重新获取该对象。该对象会同时发送给用户以及ats的本地缓存。由于本地已经有        了最新的缓存，后期对该对象的请求将会被更快的响应。

二. 对象有效期判断:
     ats支持可选的作者自定义的有效期。ats首先根据有效期判断，如果有效期不存在，会在对象被改变的频率和管理员选择的有效期方案之间挑选一个有效期。可以通过源服务器检查对象有效性的方式来重新生效对象。

HTTP对象保鲜
    1. 检查Expires or max-age头;
    2. 检查Last-Modified/Date头;
        如果没有上述字段，则freshness_limit = (date - last_modified) * 0.10;
    3. 如果没有expires 或者没有Last-Modified 和date头, 使用最大和最小的保鲜限制;
    4. 检查cache.config中设置的规则;

设置过期的加权因子
     假如对象没有包含失效信息，ats会利用Last-Modified和Date头来估计新鲜度. ats会将对象
存储为上次更改后经过时间的10%, 可以修改proxy.config.http.cache.heuristic_lm_factor; 来修改
加权因子；(traffic_ctl config reload)

设置绝对新鲜度限制
如果对象没有Expires 或者Last-Modified 和Date头， 可以设置绝对新鲜限制:
1.修改 proxy.config.http.cache.heuristic_min_lifetime 和
proxy.config.http.cache.heuristic_max_lifetime
2. 运行 traffic_ctl config reload

ats配置为使用特点标志缓存对象
1. 修改 配置proxy.config.http.cache.required_headers
2. traffic_ctl config reload

缓存控制标头( Cache-Control Headers)
尽管对象在缓存中可能有效, 客户端和服务端也经常施加自己的约束，从而阻止从缓存中检索对象。例如，客户端可能请求不从缓存中进行检索，或者允许检索，但是不能缓存超过10分钟;
1. no-cache ; client 发送;
2. max-age; servers发送;
3. min-fresh: client 发送；
4. min-fresh: client 发送;
5. max-stale: client 发送;
ats在http有效期标准之后使用Cache-Control标准。比如，一个对象可能被认为是有效的，
但是如果它的使用期限大于它的max-age, 它将不会用于响应请求。

重新验证HTTP 对象
当客户端请求在缓存中是失效的对象， ats重新验证该对象。通过对源站发送请求来验证是否已经改变:
1. 如果该对象还是新鲜的，ats重新设置该对象的有效期并且用该对象服务；
2. 如果这个对象已经有了新的拷贝，则缓存新拷贝，并用这个新拷贝服务客户；
3. 如果这个对象在源站已经不存在，则ats则不用这个对象提供服务;
4. 如果源服务器没有响应该有效性查询，则ats用这个过期的对象提供服务，同时提供
111 Revalidation Failed 告警;

为了配置ats重新生效规则， 可以在cache.config中设置具体的规则；
1. 修改 proxy.config.http.cache.when_to_revalidate
2. traffic_ctl config reload

推送内容到缓存
a> 修改配置允许push
1. ip_allow.config ， 允许适当的ip能够push;
2. CONFIG proxy.config.http.push_method_enabled INT 1
3. traffic_ctl config reload

缓存http 对象
a> 客户端指令
如果客户端请求带有如下指令则不缓存;
1. Authorization;
2. Cache-Control: no-store
3. Cache-Control: no-cache
4. Cookie (text objects)

可以设置为忽略Cache-Control选项:
1. CONFIG proxy.config.http.cache.ignore_client_no_cache INT 1
2. traffic_ctl config reload

b> Origin Server 指令(源站指令)
ats不缓存源站带有如下的响应头指令:
1. Cache-Control: no-store
2 . Cache-Control: private
3. WWW-Authenticate
4. Set-Cookie
5. Cache-Control: no-cache
6. Expires 值为0或者一个过期的日期;

可以配置过滤, recoreds.config中
CONFIG proxy.config.http.cache.ignore_server_no_cache INT 1 //no cache
CONFIG proxy.config.http.cache.ignore_authentication INT 1
traffic_ctl config reload

禁止http缓存:
默认情况下，ats缓存http的所有对象， 除非在cache.config中设置了never-cache.
可以配置禁止缓存:
CONFIG proxy.config.http.cache.http INT 0
traffic_ctl config reload

缓存动态内容
如果一个URL以.asp结尾，或者包含(?)号，(;)或者cgi. ,则该URL默认为动态的.
CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 0 (0禁止, 1允许)
traffic_ctl config reload

缓存Cookied 对象
CONFIG proxy.config.http.cache.cache_responses_to_cookies
traffic_ctrl config reload

强制缓存
可以强制缓存，而不用考虑Cache-Control响应头
在cache.config 中添加缓存规则:
eg: url_regex=^https?://(www.)?apache.org/dev/ ttl-in-cache=6h
traffic_ctl config reload

缓存http多版本(Alternates)
修改records.config
proxy.config.http.cache.enable_default_vary_headers
proxy.config.http.cache.vary_default_text
proxy.config.http.cache.vary_default_images
proxy.config.http.cache.vary_default_other

traffic_ctl config reload
假如以cokkies设置为不同版本的标识，则设置:
proxy.config.http.cache.cache_responses_to_cookies

设置每个对象缓存不同版本的份数
CONFIG proxy.config.cache.limits.http.max_alts INT 5

使用事务缓冲控制 I/O
在默认情况下， I/O操作和ats, 网络，缓存一样能够全速的运行。但是在大的对象的情况下，如果客户端连接很慢.在这种情况下，大的对象将被缓存在ram中等待被发送给客户端；或者在客户端连接速度很快但是连接源站的速度很慢的情况下，客户端post上传大文件时也会导致内存很大。

通过控制事务使用的缓冲区空间量可以改善此问题，根据使用的字节数设置缓冲大小的高水位和低水位。如果使用的缓冲区空间超过了高水位，则会限制连接以防止其他外部数据到达。内部操作继续全速进行，直到使用的缓冲空间低于低水位线则重新启用外部数据I/O.

虽然这主要是为了限制ats的内存使用量，但它也可以通过设置缓冲区限制，然后再外部或通过转换限制客户端连接来充当原始速率限制器。这将导致与原始服务器的连接大致限制为客户端的连接
速度。

ats 以32k大小进行网络I/O , 所以缓存控制的粒度大概在相同的精度.

缓冲区大小计算包括事务中的所有元素，包括与转换插件关联的任何缓冲区。

可以使用配置变量或插件中的TSHttpTxnConfigIntSet()全局启用事务缓冲控制。

1. 启用buffering : proxy.config.http.flow_control.enabled
TS_CONFIG_HTTP_FLOW_CONTROL_ENABLED

2. 设置高水位: proxy.config.http.flow_control.high_water
TS_CONFIG_HTTP_FLOW_CONTROL_HIGH_WATER_MARK

3. 设置低水位: proxy.config.http.flow_control.low_water
TS_CONFIG_HTTP_FLOW_CONTROL_LOW_WATER_MARK

如果使用TSHttpTxnConfigIntSet(), 必须在不晚于TS_HTTP_READ_RESPONSE_HDR_HOOK
前调用。

减少回源数量
ats减少回源的措施:
1. 写时读 (Read While Writer)
当ats从源站获取内容时，并在收到响应后， 一旦收到对象的
background_fill_completed_threshold%, 就可以允许任意数量的客户端开始提供部分填充的
缓存对象。
尽管一些http 代理允许客户端在代理从源服务器接受数据时立即开始读取响应，但是
ATS在开始读取和处理完整的HTTP响应头之后才可以允许客户端读取. 这是ATS的副作用，
这会阻止了解响应是否可缓存。
由于来自源服务器的不可缓存的响应通常是由于该内容对于不同的客户端请求是唯一
的，因此ats在确定它将能够缓存该对象之前将不启用read-while-writer功能。

如果read-while-writer生效，需要修改records.config:
CONFIG proxy.config.cache.enable_read_while_writer INT 1
CONFIG proxy.config.http.background_fill_active_timeout INT 0
CONFIG proxy.config.http.background_fill_completed_threshold FLOAT 0.000000
CONFIG proxy.config.cache.max_doc_size INT 0

CONFIG proxy.config.cache.read_while_writer.max_retries INT 10
CONFIG proxy.config.cache.read_while_writer_retry.delay INT 50

2. Open Read Retry Timeout (打开读取重试超时)
当ats从源站读取请求时，后续的请求会等待 proxy.config.http.cache.open_read_retry_time
milliseconds, 然后才开始检查是否有缓存。如果仍在提取对象，则后续请求重试
proxy.config.http.cache.max_open_read_retries 次. 故后续请求会等待
(max_open_read_retries X open_read_retry_time) milliseconds, 然后才开始建立自己的原始
连接请求。

默认配置:
CONFIG proxy.config.http.cache.max_open_read_retries INT -1
CONFIG proxy.config.http.cache.open_read_retry_time INT 10

3. 打开读取失败操作(Open Write Fail Action)
proxy.config.http.cache.open_write_fail_action.