varnish的狀态引擎分前端工作線程或者用戶端狀态引擎和後端工作線程或者服務端狀态引擎；用戶端狀态引擎，主要處理用戶端請求和響應相關的處理，比如是否可查緩存，是否命中，是否修剪緩存，是否識别使用者請求的方法有或者直接交給vcl_pass，又或者說怎樣響應用戶端等等，可以看到用戶端狀态引擎vcl_pass，是一個額外處理機制，不管是否可查緩存，是否命中，都可以交給它處理；對于服務端狀态引擎主要是處理和後端伺服器請求和響應相關操作，比如怎樣去後端伺服器取資源，對伺服器的響應封包是否可緩存，怎麼緩存，對後端伺服器的響應封包錯誤怎麼處理等；
前文我們聊了下varnish的VCL配置以及文法特點，怎樣去編譯加載varnish的vcl配置，以及指令行管理工具varnishadm怎麼去連接配接varnish管理接口進行管理varnish，回顧請參考https://www.cnblogs.com/qiuhom-1874/p/12626134.html；今天我們來說一下varnish的狀态引擎；首先我們來回顧下iptables封包的走向，在iptables裡封包的走向有三種，第一種是從别的主機發送過來的封包，首先它會到達網卡，然後進入prerouting鍊，然後經過路由決策後，如果是發往本機的，則就走input鍊，進而把封包送給本機上的應用程式；第二種是從prerouting鍊通過路由決策後，不是發往本機的封包而是發往其他主機，通過本機轉發的，它會從prerouting鍊到forward鍊，然後從postrouting鍊把封包發送給其他主機；第三種是從本機發往其他主機的封包，它的封包走向是從output鍊到postrouting鍊，然後從網卡發送出去；我們說iptables的原因是類比varnish的狀态引擎；varnish的狀态引擎就類似iptables裡的這5鍊；我們寫的vcl配置就相當于iptables裡的規則；他倆有個共同點就是在每個鍊上的規則隻對目前鍊上的表或者被自定義鍊引用才會生效，而varnish裡的狀态引擎也是同樣的邏輯，我們寫的vcl配置隻對目前狀态引擎生效，不同的狀态引擎處有着不同的意義，對其他狀态引擎互不幹擾；這樣描述相信大家對varnish的狀态引擎有了初步的概念，這也是我們在上一篇文中說到的，發送給用戶端的響應封包，為什麼要配置在vcl_deliver裡，而不是其他位置；接下來我們看看varnish的狀态引擎；
提示：以上這張圖上varnish4.0的狀态引擎圖，每個狀态引擎彼此的關系，以及varnish内部緩存處理邏輯；首先當varnish伺服器收到來自用戶端的請求封包，最先到達的狀态引擎是vcl_recv，我們可以在vcl_recv裡面對用戶端的請求封包做修改，或者其他操作，然後交給vcl_hash這個狀态引擎，這個狀态引擎主要是看是否可查緩存，如果可以查緩存，會判斷是否命中，命中就交給vcl_hit處理，vcl_hit處理後，就直接交給vcl_deliver處理，最後響應給用戶端，當然緩存命中後也可以将請求交給vcl_pass處理；如果vcl_hash處理後不能查緩存，就把封包發送給vcl_miss處理，意思是不能查緩存，或者緩存未能命中；當然我們也可以直接把封包交給vcl_pass處理；即便它可以被緩存命中，我們也是可以強行讓該請求不查緩存，直接交給vcl_pass處理或者vcl_miss直接交給vcl_backend_fatch處理；vcl_backend_fetch就是去後端真正的伺服器上取對應資源，然後它會對後端伺服器的響應封包頭部進行讀的操作，如果沒有什麼錯誤，就把響應封包發送給vcl_backend_response，vcl_backend_response在處理響應封包時，會判斷是否可緩存，如果可以緩存，就在本地緩存一份，然後通過vcl_deliver響應給用戶端，如果不可緩存，在本地就不緩存，直接将響應封包發送給vcl_deliver響應給用戶端；如果vcl_backend_fetch讀後端伺服器發來的響應封包是錯誤響應（或者vcl_backend_fatch未取到對應資源，或者後端主機當機等等），它就會把該處理邏輯交給vcl_backend_error處理；如果使用者的請求經過vcl_hash處理後，發現緩存内容變了或者說緩存過期了需要修剪緩存，它會把請求發往vcl_purge，vcl_purge主要處理緩存修剪相關的操作，然後把請求封包發送給vcl_synth處理，合成一響應發送給用戶端；如果通過vcl_hash處理後發現使用者請求的方法我們壓根就不認識，這個時候會将請求封包交給vcl_pipe處理；
從上面的圖來看，我們大概可以總結為兩點，varnish的狀态引擎分前端工作線程或者用戶端狀态引擎和後端工作線程或者服務端狀态引擎；用戶端狀态引擎，主要處理用戶端請求和響應相關的處理，比如是否可查緩存，是否命中，是否修剪緩存，是否識别使用者請求的方法有或者直接交給vcl_pass，又或者說怎樣響應用戶端等等，可以看到用戶端狀态引擎vcl_pass，是一個額外處理機制，不管是否可查緩存，是否命中，都可以交給它處理；對于服務端狀态引擎主要是處理和後端伺服器請求和響應相關操作，比如怎樣去後端伺服器取資源，對伺服器的響應封包是否可緩存，怎麼緩存，對後端伺服器的響應封包錯誤怎麼處理等；
varnish的前端狀态引擎有vcl_recv,vcl_pass, vcl_hit, vcl_miss, vcl_pipe, vcl_purge, vcl_synth, vcl_deliver;vcl_recv處理後可以通過return來指定下一跳處理的狀态引擎是那個，如果是return（hash）就表示交給vcl_hash處理；return（pass）就表示交給vcl_pass處理；return（pipe）就表示交給vcl_pipe處理；return(synth)就表示交給vcl_synth處理；return(purge)就表示交給vcl_purge處理；對于vcl_hash來說，return（hit）就表示緩存命中交給vcl_hit處理，return（miss）表示緩存未能命中交給vcl_miss處理，return（pass）或者return(hit_for_pass)就表示即便緩存命中也交給vcl_pass處理，return（purge）就表示交給vcl_purge處理；
varnish的後端狀态引擎有vcl_backend_fetch, vcl_backend_response, vcl_backend_error；vcl_backend_fetch處理去後端取資源的操作，vcl_backend_response處理後端伺服器響應回來的封包，vcl_backend_error處理後端伺服器錯誤；除此以外varinsh4.0還有兩個特殊的狀态引擎，分别是vcl_init和vcl_fini；vcl_init：在處理任何請求之前要執行的vcl代碼：主要用于初始化VMODs；vcl_fini：所有的請求都已經結束，在vcl配置被丢棄時調用；主要用于清理VMODs；
了解了上面的狀态引擎，我們在說一說varnish的變量，在前文我們大概說了下varnish的變量大概可以分5類，一類是用戶端請求封包相關的，req.*；一類是varnish伺服器請求後端伺服器封包，bereq.*；一類是後端伺服器響應varnish伺服器的beresp.*；一類是varnish伺服器響應用戶端的resp.*；還有一類是obj.*，這類變量主要是儲存緩存空間中的緩存對象的屬性；結合上面說的狀态引擎，不難裡接在不同的狀态引擎裡，對應變量是有限的，比如bereq.*這類變量就不能用于vcl_recv，因為vcl_recv是接收使用者請求相關的，而bereq.* 是varnish請求後端伺服器的變量，這兩者很明顯是不再一個級别的，是以通常不同類的變量對應能夠用于哪些狀态引擎中是有限制的；而對應變量的屬性也是有要求的，比如obj.hit這個變量是存儲緩存項命中次數的，通常可用在vcl_hit和vcl_deliver狀态引擎中，表示應用緩存命中次數，相對于這個變量來說，我們是不能修改的，是以obj.hits這個變量在vcl_hit和vcl_deliver狀态引擎中隻可讀，不可修改；而對于obj.ttl這個值就不一樣了；obj.ttl記錄緩存項可緩存的時間；很顯然obj.ttl這個變量隻能用于可緩存的狀态引擎上，比如vcl_hit，對于告訴用戶端可緩存的時間，很明顯它不能是一個不可修改的值；是以對于obj.ttl這個變量在vcl_hit狀态引擎中就具有可讀可寫權限（即我們可以修改該變量的值）；說這麼多無外乎就是表達一個意思，不同類型的變量受限狀态引擎，不同變量在不同的狀态引擎上不是都可讀可寫，有的變量隻可讀；如下圖
說明：以上這張表就是對于不同類型的變量對應varnish的狀态引擎是否可讀寫的，沒有讀寫就表示該類型變量不能用于對應狀态引擎中；比如resp.*隻能在error和deliver狀态引擎中使用；beresp.*這類變量隻能用于後端主機響應varnish伺服器的過程中使用，比如fetch這個狀态引擎就是處理後端伺服器響應varnish伺服器請求的；是以beresp.*這類變量隻能用于fetch;當然這裡的fetch是早期狀态引擎的名稱。在varnish4.0它不叫fetch，而叫vcl_backend_fatch；
了解了以上内容，我們接下來看幾個示例
示例：強制對某類資源的請求不檢查緩存
提示：以上配置表示對用戶端請求的url進行判斷，如果能夠被.jpg、.jpeg、.png、.gif、.js、.css、.html比對到，那麼就把使用者請求交給pass狀态引擎處理；pass狀态引擎處理就是不查緩存；是以對于用戶端請求.jpg的資源，其對應obj.hits的值會一直為0；因為我們明确指定了不查緩存；
測試：用浏覽器通路伺服器上的.jpg資源，看看響應封包中我們自定義的X-Cache 首部是否是 miss via 192.168.0.99；
提示：可以看到我們通路/day.jpg這個資源時，不管怎麼重新整理浏覽器，對應響應首部X-Cache的值都是 miss via 192.168.0.99，說明我們請求.jpg的資源的确沒有查緩存；
示例：把用戶端IP傳到後端伺服器
提示：以上vcl表示判斷用戶端請求首部X-Forwarded-For是否為空，如果不為空就把它的值在原有的值的基礎上和用戶端ip位址做字元串連接配接，并用逗号隔開；如果該首部為空或者沒有這個首部就把這個首部的值設定成用戶端ip位址；
更改後端web 服務的日志格式
提示：以上配置表示在日志格式中應用X-Forwarded-For這個首部的值；
測試：重新編譯加載vcl，然後用浏覽器通路，看看是否能夠把浏覽器所在主機的ip位址傳到後端httpd伺服器日志中做記錄？
提示：從上面的日志結果看，我們分别用不同的浏覽器去通路，在日志中可以看到不同浏覽器所在主機的IP位址，說明我們通過判斷使用者請求封包X-Forwarded-For首部是否為空，進而實作對于非空和空值對應設定該首部值，繼而實作把對應請求首部值記錄到後端伺服器日志中的目的；
示例：對于特定類型的資源，例如公開的圖檔等，取消其私有辨別，并強行設定其可以由varnish緩存的時長；
提示：首先我們要清楚在那個位置去對封包操作，取消私有辨別，是需要在後端伺服器響應varnish這個過程中把對應響應首部的值給撤銷了；是以我們需要在vcl_backend_response這個狀态引擎中來設定，取消set-cookie首部，這個首部主要是給對應用戶端設定一個cookie;以上配置表示判斷後端伺服器響應varnish伺服器的響應封包首部cache-control的值是否比對“s-maxage”，如果不比對說明該資源不允許被共有緩存系統所緩存，如果比對，則說明該資源允許被公有緩存系統所緩存；如果不比對再繼續判斷varnish向後端請求的首部url的值是否比對.jpg|jpeg|png|gif|css|js結尾的資源，如果比對則取消後端伺服器響應varnish伺服器的響應首部set-cookie的值，并設定後端伺服器響應varnish的資源緩存時長為1小時；簡單講就是判斷後端伺服器響應首部的cache-control的值是否比對到“s-maxage”，如果不能比對到在判斷向後端伺服器請求的首部url是否是比對指定結尾的資源，如果是，就取消後端伺服器響應首部set-cookie這個首部，同時把後端伺服器響應資源的緩存時長設定為1小時；
測試：為了驗證以上vcl配置正确性，我們把beresp.ttl的值通過cache-control這個首部傳遞到浏覽器響應首部，進而來判斷set-cookie首部是被撤銷了；
提示：在上面的配置中加入了set beresp.http.cache-control = beresp.ttl;表示把後端響應給varnish的響應首部beresp.ttl的值 通過beresp.http.cache-control首部儲存；這樣用戶端通路.jpg的資源就會在響應首部中把cache-control的值給顯示出來，如果該值是我們設定的3600s，就說明我們撤銷set-cookie這個首部的vcl語句是生效的；
提示：從上面的結果看，cache-control的值為3600是我們設定beresp.ttl的值；說明撤銷set-cookie的vcl配置生效了；同時這也告訴我們如果後端伺服器響應varnish的封包中沒有的首部，在varnish響應用戶端中就沒有；簡單說就是varnish會把後端伺服器響應給varnish中首部的值通過響應用戶端首部傳遞出來；比如我在後端響應封包中自定義一個aaa的封包首部，其值為bbb，那麼在用戶端的響應封包首部中就會有對應aaa首部和對應的值；如下
測試：
提示：做以上測試需要考慮varnish上的緩存，如果你始終通路同一個url可能會看到對應首部的值不會發生變化，需要重新開機varnish或者換個其他符合vcl定義的url去通路試試看；
作者：Linux-1874
出處：https://www.cnblogs.com/qiuhom-1874/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利.