瀏覽器緩存在 Nginx 的 HTTP 核心模塊中其實只有兩個簡單的配置，這一塊也是 HTTP 的基礎知識。之前我們就一直在強調(diào)，學習 Nginx 需要的就是各種網(wǎng)絡相關的基礎知識，其中更重要的就是 HTTP 和 TCP 相關的內(nèi)容。另外一個 try_files 配置指令也是 Nginx 中非常常用的一個指令，用于找不到指定的路徑文件時，可以去按順序查找備用的一些文件路徑，非常實用。
在 HTTP 協(xié)議中，有許多和瀏覽器緩存有關的選項，而在 Nginx 的核心配置中，也有兩個與之相關的配置。
if_modified_since 是由瀏覽器發(fā)送的，讓服務端來判斷返回 200 還是 304 ，在 Nginx 中，它用于指定響應的修改時間與 if_modified_since 請求頭的比較方法。
if_modified_since off | exact | before;
默認值是 exact ，每個選項分別代表：
etag 是由服務器端生成的，客戶端通過發(fā)送 If-Match 或者 If-None-Match 這個條件判斷請求來驗證資源是否修改。Nginx 中，這個配置可以開啟或關閉為靜態(tài)文件自動計算 “ETag” 響應頭。
etag on | off;
它的默認值是 on 。
正常情況下，我們第一次打開某個靜態(tài)頁面，是沒有 if_modified_since 的，服務端會返回 ETag 和 Last-Modified 以及 200 狀態(tài)碼。
然后第二次請求的時候，瀏覽器就會帶上 if_modified_since ，服務端會返回 304 表示使用本地緩存就可以了。
這是在默認情況下。現(xiàn)在我們修改 Nginx 的配置，先將 if_modified_since 設置為 off ，然后強刷頁面之后再進行普通刷新 ，會發(fā)現(xiàn)不管是強刷還是普通刷新，響應頭和請求雖然沒有什么變化，但服務端都只會返回 200 了。也就是說，服務端不會去比較瀏覽器發(fā)送過來的 if_modified_since 值來判斷是否返回 304 。
接下來測試 etag ，這個就麻煩一點，首先，我們要將 if_modified_since 設置為 before ，意思就是訪問的靜態(tài)資源文件的修改時間小于當前瀏覽器提供的 If-Modified-Since 時，才返回 200 。這樣的話，如果我們手動修改文件的時間，將時間修改到當前時間之后很長的一段時間，那么就可以讓瀏覽器在非強刷的狀態(tài)下一直返回 304 。
touch -m -d "2023-09-08 12:23:04" /usr/local/nginx/html/aaa.html
默認 etag 為 on 的情況下，你再次修改文件的時間，依然會正常返回一次 200 。這就是 etag 的作用，它是根據(jù)文件一些屬性進行綜合 Hash 從而返回一個值，客戶端保存上回的 etag 值后傳送到服務端進行比對。而如果現(xiàn)在你將 etag 設置為 off 的話，那么再次請求就不會有 Etag 響應頭返回了，這時修改文件的時間，甚至是修改文件的內(nèi)容（注意修改內(nèi)容后還要手動修改一下文件的修改時間，否則 if_modified_since 就會生效返回 200 了），后面的請求也將一直會是 304 （非強刷）。
ps.瀏覽器強刷其實就是瀏覽器不帶任何和 HTTP 緩存有關的請求頭進行一次請求訪問。
Etag 最主要解決的其實是 if_modified_since 的一些缺點，比如說有些時候可能我們只是周期性地修改一下文件，但文件內(nèi)容不發(fā)生變化（只是文件修改時間變動），這時其實可以不用重新 200 響應的。另外還有 if_modified_since 只支持到秒級，而 Etag 的 Hash 變化是跟隨文件變動的，因此它的粒度更細一些。還有一種情況就是某些服務器不能精確的得到文件的最后修改時間，這也會導致 if_modified_since 產(chǎn)生問題，更典型的就是客戶端時間和服務器時間不同步，比如有的人的電腦可能時間一直就是錯的。
這一塊的內(nèi)容是 HTTP 的基礎知識，而且寫文字也不太好描述怎么測試，大家可以關注下后期的視頻哈，在視頻中咱們再好好演示。
按指定順序檢查文件是否存在，并且使用第一個找到的文件來處理請求，那么處理過程就是在當前上下文環(huán)境中進行的。
try_files file ... uri;
try_files file ... =code;
其實就是我們不確定用戶訪問的路徑或者文件存不存在，這時可以按照 try_files 指定的順序來展示指定的 URI ，通常它都會和 $uri 變量一起搭配使用，$uri 變量就是當前訪問的 location 地址。說白了，就是給請求的鏈接準備好備胎，能夠為用戶帶來更優(yōu)良的用戶體驗。
文件路徑是根據(jù) root 指令和 alias 指令，將 file 參數(shù)拼接而成。 可以在名字尾部添加斜線以檢查目錄是否存在，比如“$uri/”。 如果找不到任何文件，將按最后一個參數(shù)指定的uri進行內(nèi)部跳轉。 比如：
location /tf1/ {
try_files $uri /50x.php;
}
現(xiàn)在試試訪問 /tf1 ，會發(fā)現(xiàn)顯示的是 50x.php 的內(nèi)容，如果 /tf1 下面有頁面的話，那么直接訪問就可以查看到指定的頁面。這種感覺是不是有點像 error_page ，其實上面的內(nèi)容就相當于是下面這樣的代碼。
location /tf1/ {
error_page 404 /50x.php;
}
$uri 變量表示的是規(guī)范以后的 URI ，也就是拼接請求之后完整的 URI 路徑。不過這個變量的值可能會隨著請求的處理過程而改變，比如，當進行內(nèi)部跳轉時，或者使用默認頁文件時。
這下就看出來了吧，try_files 按順序，如果第一個 $uri 找到文件了，就直接使用這個文件，如果沒找到，就找第二個，依次類推，我們也可以一直向后多寫幾個 uri ，直到有一個能夠找到對應的文件。
location /tf2/ {
try_files $uri /tf2/1.html /tf2/2.html;
}
在 tf2 目錄下，建立了兩個文件，然后訪問 /tf2 ，會顯示 1.html 的內(nèi)容，訪問 /tf2/2.html ，正常顯示 2.html 的內(nèi)容，按順序來說 $uri 是第一位的，后面的順序哪個先找到就按哪個來。因此，除了指定訪問 /tf2/2.html 之外，其它鏈接都會打開 1.html （如果有 404 的 error_page 設置，則直接走 404 的）。那么如果是跳轉 uri 呢？比如我們跳轉到 php 的 URI 上。
location /tf3/ {
try_files $uri /50x.php /404.php;
}
隨便訪問 /tf3 或者目錄中的任意不存在的路徑，我這里會彈出下載，查看請求 Content-Type 會變成 application/octet-stream ，下載的文件是 php 的源碼。注意，這里是個坑點，不要在靜態(tài)配置中進行這樣的 try_files 。換成帶 PHP 相關配置的再試試。
location /tf4/ {
try_files $uri /tf4/1.php /1.php =404;
fastcgi_pass unix:/var/sock/php-fpm/www.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
現(xiàn)在訪問 /tf4 會顯示到最外面那個我們之前測試的時候打印所有 $_SERVER 內(nèi)容的 1.php 頁面。如果我們創(chuàng)建 tf4 目錄，并且添加一個 1.php ，并打印 echo "this is tf4/1.php."; 那么，再次刷新，頁面就會展示 this is tf4/1.php. 。這樣才能正常的顯示 php 。不過我們直接用靜態(tài)配置去 try_files 動態(tài)文件也有別的方法，就是使用命名 location 。
location /tf5/ {
try_files $uri @tf5php;
}
location @tf5php {
root html;
fastcgi_pass unix:/var/sock/php-fpm/www.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root/tf5php/index.php;
include fastcgi_params;
}
訪問 /tf5 或者 /tf5/xxx.html ，都會打開 tf5php 目錄下的 index.php 文件。注意，這里演示的是從 靜態(tài) 文件到 php 文件，如果是 /tf5/xxx.php 則會被之前我們配置過的 ~ \.php 的配置拿走，不會走到這邊來。
我們再來看看響應碼的問題。
location /tf6/ {
try_files $uri $uri/ /xxx.html =401;
}
這一段表示的是如果前面 uri... 部分都沒有匹配到，那么就會返回 401 的狀態(tài)碼。大家可以自己試一下訪問 /tf6 下的任意文件，最后返回的都是 401 狀態(tài)。
好了，我們再來看一下 Laravel 文檔中給的一個 Nginx 配置，其中有一段內(nèi)容是大部分 PHP 應用在部署的時候也都會要求寫上的。
location / {
try_files $uri $uri/ /index.php?$query_string;
}
在全局的 location 中，訪問 uri 頁面或者 uri/ 目錄，找不到文件的話，會轉給 /index.php，并且把請求行的 GET 參數(shù)轉給 /index.php 文件。通常現(xiàn)代化的框架都是單一入口，index.php 總是可以接收請求的，如果確實還是找不到，也將由 PHP 應用來進行對應的 404 或者 500 處理。
另外，try_files 還可以做一件非常常見的事，就是顯示默認圖片。
location /images/ {
try_files $uri /images/default.gif;
}
正常的圖片路徑找不到圖片了，就使用默認的圖片來代替，這也是很多網(wǎng)站的基本需求。
今天的內(nèi)容不難吧，加起來就是三個配置項，不過我們做了很多的測試。緩存對于現(xiàn)代化的 Web 開發(fā)來說非常重要，而 HTTP 緩存則是最前端的面向客戶一級的緩存。對于靜態(tài)資源來說，有著非常重要的作用，可以大大減少服務器的壓力。而 try_files 的靈活則為我們帶來了更多的特色功能，類似于默認圖片這類的配置都能夠非常簡單方便。
不過估計大家平?？赡軐@幾個指令用得也并不多，畢竟緩存那兩個都有默認值，我們保持默認就好了。而 try_files 通常最多的就是用在上文所說的全局路徑的處理上，是使用 Laravel 時必備的一個配置。但是，通過今天的學習，相信咱們將來在需要的時候，也能馬上想起來這些配置指令的用法，能夠更加靈活自如的運用它們。學習，就是這樣一步一步的不斷積累，一次一次的不停實踐。
參考文檔：
http://nginx.org/en/docs/http/ngx_http_core_module.html
