ATS緩存規則你都知道了嗎？

ATS汽車凱迪拉克大家知道的多，那麼編程中的ATS緩存規則你都知道嘛？

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選項:

圖2

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.

最後你覺得我們的文章對你有幫助，歡迎關注我，可以私信我：久伴，領取學習資料，在評論下方可以關注我的學習群，你可以隨時在上面向我們提問，把你在學習C++過程中所遇到的問題發給我們。我們每天都會按時回復大家的每一個問題，希望久伴可以伴隨你從入門到專家

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！