前文我們聊了下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去訪問試試看；
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/112734.html
標籤：Linux