『壹』 如何將html文件緩存到伺服器內存 （iis）
你把後綴名改為aspx，然後加上緩存屬性不就可以了嗎？
如果不改後綴，IIS會直接自己處理html文件，根本到不了.net處理程序，更不用談緩存到內存中。
當然你也可以修改html文件的映射，然後自己寫httpHandler，不過這樣貌似太過多此一舉了。
『貳』 Okhttp解析（五）緩存的處理
大家好，之前我們講解了Okhttp網路數據請求相關的內容，這一節我們講講數據緩存的處理。本節按以下內容講解Okhttp緩存相關的內容。
緩存的使用場景很多，通過它可以將數據通過一定的規則存儲起來，再次請求數據的時候就可以快速從緩存中讀取了，緩存有以下優勢。
HTTP本身提供了一套緩存相關的機制。這套機制定義了相關的欄位和規則，用來客戶端和服務端進行緩存相關的協商，如響應的數據是否需要緩存，緩存有效期，緩存是否有效，伺服器端給出指示，而客戶端則根據服務端的指示做具體的緩存更新和讀取緩存工作。http緩存可以分為兩類：
強制緩存，在緩存數據未失效的情況下，可以直接使用緩存數據，有兩個欄位Expires和Cache-Control用於標明失效規則。
表示過期時間，由服務端返回。那麼下次請求數據時，判斷這個Expires過期時間是否已經過了，如果還沒有到過期時間，則使用緩存，如果過了過期時間，則重新請求伺服器的數據。Expires格式如下：
不過因為伺服器和客戶端的時間並不是同步的，用一個絕對時間作為過期的標記並不是很明智，所以HTTP1.1之後更多的是Cache-Control，它的控制更加靈活。
表示緩存的控制，有服務端返回。它有以下幾個取值：
默認情況下是private，也就是不能共享的。Cache-Control格式如下：
對比緩存，表示需要和服務端進行相關信息的對比，由伺服器決定是使用緩存還是最新內容，如果伺服器判定使用緩存，返回響應嗎304，判定使用最新內容，則返回響應碼200和最新數據。對比緩存的判定欄位有兩組：
ETag表示資源的一種標識信息，用於標識某個資源，由服務端返回，優先順序更高。格式如下：
然後客戶端再次請求時，加入欄位If-None-Match，格式如下：
服務端收到請求的該欄位時（之前的Etag值），和資源的唯一標識進行對比，如果相同，說明沒有改動，則返回狀態碼304，如果不同，說明資源被改過了，則返回狀態碼200和整個內容數據。
Last-Modified表示資源的最近修改時間，由服務端返回，優先順序更低。格式如下：
Last-Modified
由伺服器返回，表示響應的數據最近修改的時間。
If-Modified-Since
由客戶端請求，表示詢問伺服器這個時間是不是上次修改的時間。如果服務端該資源的修改時間小於等於If-Modified-Since指定的時間，說明資源沒有改動，返回響應狀態碼304，可以使用緩存。如果服務端該資源的修改時間大於If-Modified-Since指定的時間，說明資源又有改動了，則返回響應狀態碼200和最新數據給客戶端，客戶端使用響應返回的最新數據。
Last-Modified欄位的值（服務端返回的資源上次修改時間），常常被用於客戶端下次請求時的If-Modified-Since欄位中。
HTTP的緩存規則是優先考慮強制緩存，然後考慮對比緩存。
Okhttp緩存相關的類有如下：
要開啟使用Okhttp的緩存其實很簡單，只需要給OkHttpClient對象設置一個Cache對象即可，創建一個Cache時指定緩存保存的目錄和緩存最大的大小即可。
那麼下面我們來看看Okhttp緩存執行的大概流程
Okhttp的緩存流程分為讀取緩存和存儲緩存兩個過程，我們分別分析。
讀取使用緩存的流程從HttpEngine的sendRequest發送請求開始。
接下來我們分析
從Cache的get方法開始。它按以下步驟進行。
如果存在緩存的話，在指定的緩存目錄中，會有兩個文件「****.0」和「****.1」，分別存儲某個請求緩存的響應頭和響應體信息。（「****」是url的md5加密值）對應的ENTRY_METADATA響應頭和ENTRY_BODY響應體。緩存的讀取其實是由DiskLruCache來讀取的，DiskLruCache是支持Lru（最近最少訪問）規則的用於磁碟存儲的類，對應LruCache內存存儲。它在存儲的內容超過指定值之後，就會根據最近最少訪問的規則，把最近最少訪問的數據移除，以達到總大小不超過限制的目的。
接下來我們分析CacheStrategy緩存策略是怎麼判定的。
直接看CacheStrategy的get方法。緩存策略是由請求和緩存響應共同決定的。
接來下我們看看CacheControl類里有些什麼。
可以發現，它就是用於描述響應的緩存控制信息。
然後我們再看看Okhttp存儲緩存是怎麼進行的。
存儲緩存的流程從HttpEngine的readResponse發送請求開始的。
可以看到這里先通過maybeCache寫入了響應頭信息，再通過cacheWritingResponse寫入了響應體信息。我們再進去看Cache的put方法實現。
我們繼續看Cache的writeTo方法，可以看到是寫入一些響應頭信息。
到這里Okhttp緩存的讀取和存儲流程我們就清楚了。可以說，緩存的使用策略基本都是按照HTTP的緩存定義來實現的，所以對HTTP緩存相關欄位的理解是很重要的。然後關於DiskLruCache是如何管理緩存文件的，這個其實也很好理解，首先的原則就是按照LRU這種最近最少使用刪除的原則，當總的大小超過限定大小後，刪除最近最少使用的緩存文件，它的LRU演算法是使用LinkedHashMap進行維護的，這樣來保證，保留的緩存文件都是更常使用的。具體實現大家可以分析DiskLruCache和LinkedHashMap的實現原理。
『叄』 http緩存過程
註：http 緩存只能緩存 get 方式請求的資源
緩存是指 代理伺服器 或 客戶端本地磁碟 內保存的資源副本。利用緩存可減少對源伺服器的訪問，因此也就節省了通信流量和通信時間。
緩存伺服器是代理伺服器的一種，並歸類在緩存代理類型中。換句話說， 當代理轉發從伺服器返回的響應時，代理伺服器將會保存一份資源的副本 。
緩存伺服器的優勢在於利用緩存可避免多次從源伺服器轉發資源。因 此客戶端可就近從緩存伺服器上獲取資源，而源伺服器也不必多次處 理相同的請求了。
瀏覽器緩存分 強制緩存 和 協商緩存 ，分別使用的欄位前者是Expires和Cach-control，後者是 Etag 和 Last-modified。
Expires (http/1.0)：設的是資源的過期時間（絕對時間），瀏覽器判斷這次請求的時候是不是超過這個日期，沒超的話就直接讀取緩存中的資源，不向伺服器發請求。
Pragma ：欄位值為「no-cache」的時候，會通知客戶端不要對該資源讀緩存，即每次都得向伺服器發一次請求才行。但是這種禁用緩存的形式作用不是那麼太大：1. 僅有IE才能識別這段meta標簽含義，其它主流瀏覽器僅能識別「Cache-Control: no-store」的meta標簽。2. 在IE中識別到該meta標簽含義，並不一定會在請求欄位加上Pragma，但的確會讓當前頁面每次都發新請求，但是僅限頁面，頁面上的資源則不受影響。
如果Pragma和Expires一起出現的話，Pragma的優先順序是高的。
Cach-Control (http/1.1)：緩存控制 示例：
Cache-Control 有三種屬性：緩沖能力、過期時間和二次驗證。
緩沖能力:
過期時間:
二次驗證:
Expires使用的是服務端時間，可能出現客戶端和服務端時間不同步，導致本地緩存無用或無法過期。
Max-Age使用的是客戶端本地時間的計算，不會出現這個問題，推薦Max-Age。
如果同時啟用了Cache-Control和Pragma ，Expires，Cache-Control優先順序高。
Last-Modified / If- Modified-Since (http/1.0)：判斷資源最後修改時間，只要這個日期改變了就不使用緩存。瀏覽器的頭部是If- Modified-Since，服務端的是Last-Modified，如果兩個匹配，代表伺服器資源未改變，服務端不會返回資源實體，只返回頭部，通知瀏覽器使用緩存。
缺點：可能有些文件會周期性地改變日期，但是內容其實沒變，但是該欄位只判斷最後修改時間，
E-tag / If-None-Match (http/1.1)：Etag 是伺服器針對請求的資源文件生成的唯一標識，只要文件內容沒變化，則Etag值不變，克服了 Last-Modified / If- Modified-Since 的缺點。瀏覽器的頭部是If-None-Match，服務端的是E-tag，如果兩個匹配，代表內容未改變，通知瀏覽器使用緩存。
Etag 缺點：不適用於分布式系統 ，因為每個伺服器上的 Etag 值不同。
如果同時帶有E-tag和Last-Modified，服務端優先檢查E-tag。
『肆』 緩存伺服器的緩存伺服器原理
Web緩存伺服器的應用模式主要是正向代理和反向代理。正向代理(Proxy)模式是代理網路用戶訪問internet，客戶端將本來要直接發送到internet上源伺服器的連接請求發送給代理伺服器處理。正向代理的目的是加速用戶在使用瀏覽器訪問Internet時的請求響應時間，並提高廣域網線路的利用率。正向代理瀏覽器無需和該站點建立聯系，只訪問到Web緩存即可。通過正向代理，大大提高了後續用戶的訪問速度，使他們無需再穿越Internet，只要從本地Web緩存就可以獲取所需要的信息，避免了帶寬問題，同時可以大量減少重復請求在網路上的傳輸，從而降低網路流量，節省資費。
反向代理(Reverse Proxy)模式是針對Web伺服器加速功能的，在該模式中，緩存伺服器放置在web應用伺服器的前面，當用戶訪問web應用伺服器的時候，首先經過緩存伺服器，並將用戶的請求和應用伺服器應答的內容寫入緩存伺服器中，從而為後續用戶的訪問提供更快的響應。其工作原理如下圖所示。
『伍』 web伺服器怎麼使用redis分步式緩存
Redis復制流程概述
Redis的復制功能是完全建立在之前我們討論過的基於內存快照的持久化策略基礎上的，也就是說無論你的持久化策略選擇的是什麼，只要用到了Redis的復制功能，就一定會有內存快照發生，那麼首先要注意你的系統內存容量規劃，原因可以參考我上一篇文章中提到的Redis磁碟IO問題。
Redis復制流程在Slave和Master端各自是一套狀態機流轉，涉及的狀態信息是：
Slave 端：
REDIS_REPL_NONEREDIS_REPL_CONNECTREDIS_REPL_CONNECTED
Master端：
REDIS_REPL_WAIT_BGSAVE_STARTREDIS_REPL_WAIT_BGSAVE_ENDREDIS_REPL_SEND_BULKREDIS_REPL_ONLINE
整個狀態機流程過程如下：
Slave端在配置文件中添加了slave of指令，於是Slave啟動時讀取配置文件，初始狀態為REDIS_REPL_CONNECT。
Slave端在定時任務serverCron(Redis內部的定時器觸發事件)中連接Master，發送sync命令，然後阻塞等待master發送回其內存快照文件(最新版的Redis已經不需要讓Slave阻塞)。
Master端收到sync命令簡單判斷是否有正在進行的內存快照子進程，沒有則立即開始內存快照，有則等待其結束，當快照完成後會將該文件發送給Slave端。
Slave端接收Master發來的內存快照文件，保存到本地，待接收完成後，清空內存表，重新讀取Master發來的內存快照文件，重建整個內存表數據結構，並最終狀態置位為 REDIS_REPL_CONNECTED狀態，Slave狀態機流轉完成。
Master端在發送快照文件過程中，接收的任何會改變數據集的命令都會暫時先保存在Slave網路連接的發送緩存隊列里（list數據結構），待快照完成後，依次發給Slave,之後收到的命令相同處理，並將狀態置位為 REDIS_REPL_ONLINE。
整個復制過程完成，流程如下圖所示：
Redis復制機制的缺陷
從上面的流程可以看出，Slave從庫在連接Master主庫時，Master會進行內存快照，然後把整個快照文件發給Slave，也就是沒有象Mysql那樣有復制位置的概念，即無增量復制，這會給整個集群搭建帶來非常多的問題。
比如一台線上正在運行的Master主庫配置了一台從庫進行簡單讀寫分離，這時Slave由於網路或者其它原因與Master斷開了連接，那麼當Slave進行重新連接時，需要重新獲取整個Master的內存快照，Slave所有數據跟著全部清除，然後重新建立整個內存表，一方面Slave恢復的時間會非常慢，另一方面也會給主庫帶來壓力。
所以基於上述原因，如果你的Redis集群需要主從復制，那麼最好事先配置好所有的從庫，避免中途再去增加從庫。
Cache還是Storage
在我們分析過了Redis的復制與持久化功能後，我們不難得出一個結論，實際上Redis目前發布的版本還都是一個單機版的思路，主要的問題集中在，持久化方式不夠成熟，復制機制存在比較大的缺陷，這時我們又開始重新思考Redis的定位：Cache還是Storage？
如果作為Cache的話，似乎除了有些非常特殊的業務場景，必須要使用Redis的某種數據結構之外，我們使用Memcached可能更合適，畢竟Memcached無論客戶端包和伺服器本身更久經考驗。
如果是作為存儲Storage的話，我們面臨的最大的問題是無論是持久化還是復制都沒有辦法解決Redis單點問題，即一台Redis掛掉了，沒有太好的辦法能夠快速的恢復，通常幾十G的持久化數據，Redis重啟載入需要幾個小時的時間，而復制又有缺陷，如何解決呢？
Redis可擴展集群搭建1. 主動復制避開Redis復制缺陷。
既然Redis的復制功能有缺陷，那麼我們不妨放棄Redis本身提供的復制功能，我們可以採用主動復制的方式來搭建我們的集群環境。
所謂主動復制是指由業務端或者通過代理中間件對Redis存儲的數據進行雙寫或多寫，通過數據的多份存儲來達到與復制相同的目的，主動復制不僅限於用在Redis集群上，目前很多公司採用主動復制的技術來解決MySQL主從之間復制的延遲問題，比如Twitter還專門開發了用於復制和分區的中間件gizzard(https://github.com/twitter/gizzard) 。
主動復制雖然解決了被動復制的延遲問題，但也帶來了新的問題，就是數據的一致性問題，數據寫2次或多次，如何保證多份數據的一致性呢？如果你的應用對數據一致性要求不高，允許最終一致性的話，那麼通常簡單的解決方案是可以通過時間戳或者vector clock等方式，讓客戶端同時取到多份數據並進行校驗，如果你的應用對數據一致性要求非常高，那麼就需要引入一些復雜的一致性演算法比如Paxos來保證數據的一致性，但是寫入性能也會相應下降很多。
通過主動復制，數據多份存儲我們也就不再擔心Redis單點故障的問題了，如果一組Redis集群掛掉，我們可以讓業務快速切換到另一組Redis上，降低業務風險。
2. 通過presharding進行Redis在線擴容。
通過主動復制我們解決了Redis單點故障問題，那麼還有一個重要的問題需要解決：容量規劃與在線擴容問題。
我們前面分析過Redis的適用場景是全部數據存儲在內存中，而內存容量有限，那麼首先需要根據業務數據量進行初步的容量規劃，比如你的業務數據需要100G存儲空間，假設伺服器內存是48G，那麼根據上一篇我們討論的Redis磁碟IO的問題，我們大約需要3~4台伺服器來存儲。這個實際是對現有業務情況所做的一個容量規劃，假如業務增長很快，很快就會發現當前的容量已經不夠了，Redis裡面存儲的數據很快就會超過物理內存大小，那麼如何進行Redis的在線擴容呢？
Redis的作者提出了一種叫做presharding的方案來解決動態擴容和數據分區的問題，實際就是在同一台機器上部署多個Redis實例的方式，當容量不夠時將多個實例拆分到不同的機器上，這樣實際就達到了擴容的效果。
拆分過程如下：
在新機器上啟動好對應埠的Redis實例。
配置新埠為待遷移埠的從庫。
待復制完成，與主庫完成同步後，切換所有客戶端配置到新的從庫的埠。
配置從庫為新的主庫。
移除老的埠實例。
重復上述過程遷移好所有的埠到指定伺服器上。
以上拆分流程是Redis作者提出的一個平滑遷移的過程，不過該拆分方法還是很依賴Redis本身的復制功能的，如果主庫快照數據文件過大，這個復制的過程也會很久，同時會給主庫帶來壓力。所以做這個拆分的過程最好選擇為業務訪問低峰時段進行。
Redis復制的改進思路
我們線上的系統使用了我們自己改進版的Redis,主要解決了Redis沒有增量復制的缺陷，能夠完成類似Mysql Binlog那樣可以通過從庫請求日誌位置進行增量復制。
我們的持久化方案是首先寫Redis的AOF文件，並對這個AOF文件按文件大小進行自動分割滾動，同時關閉Redis的Rewrite命令，然後會在業務低峰時間進行內存快照存儲，並把當前的AOF文件位置一起寫入到快照文件中，這樣我們可以使快照文件與AOF文件的位置保持一致性，這樣我們得到了系統某一時刻的內存快照，並且同時也能知道這一時刻對應的AOF文件的位置，那麼當從庫發送同步命令時，我們首先會把快照文件發送給從庫，然後從庫會取出該快照文件中存儲的AOF文件位置，並將該位置發給主庫，主庫會隨後發送該位置之後的所有命令，以後的復制就都是這個位置之後的增量信息了。
Redis與MySQL的結合
目前大部分互聯網公司使用MySQL作為數據的主要持久化存儲，那麼如何讓Redis與MySQL很好的結合在一起呢？我們主要使用了一種基於MySQL作為主庫，Redis作為高速數據查詢從庫的異構讀寫分離的方案。
為此我們專門開發了自己的MySQL復制工具，可以方便的實時同步MySQL中的數據到Redis上。
（MySQL-Redis 異構讀寫分離）
總結：
Redis的復制功能沒有增量復制，每次重連都會把主庫整個內存快照發給從庫，所以需要避免向在線服務的壓力較大的主庫上增加從庫。
Redis的復制由於會使用快照持久化方式，所以如果你的Redis持久化方式選擇的是日誌追加方式(aof),那麼系統有可能在同一時刻既做aof日誌文件的同步刷寫磁碟，又做快照寫磁碟操作，這個時候Redis的響應能力會受到影響。所以如果選用aof持久化，則加從庫需要更加謹慎。
可以使用主動復制和presharding方法進行Redis集群搭建與在線擴容。
『陸』 怎麼架設緩存伺服器
問題一：如何架設緩存DNS伺服器 Windows Server配置緩存DNS：
安裝DNS後，不設置任何zone。只通過forwarder、root hint對名稱進行解析。參考：
technet.microsoft/...217396
有問題的話你可以直接到微軟的論壇提問：social.technet.microsoft/Forums/en-us/home
問題二：伺服器緩存怎麼設置啊 雙核cpu 用ok緩存，是單核心cpu用liunx的緩存
問題三：怎麼搭建一個tair緩存伺服器 能啊，不過不知你要怎麼做。
一般來說，對企業級用戶才需要這些功能。主要就是避開上網高峰期，利用夜間來把網頁等內容緩存下來，到了白天再用，再打開時可以看到網頁是前一天或當天凌晨的。不過，不要緊，一點「刷新」就好了，因為大部分內容都下來了，改動也就很少，瀏覽網頁的速度也就很快了。
方法我知道有兩種，都是基於系統伺服器的：1 WINDOWS系統下可以裝一個ISA2000之類的軟體，它可以提供防火牆、NAT、緩存三大功能。這個軟體一時半會說不清楚，你可以自己下一個下來慢慢來，並不是很難碰蘆。2 LINUX系統下也可以實現，在安裝了一個叫squid的服務後，這個功能就可以再通過配置來實現，不過配置全是用命令，有點困難了。
最後，建議用ISA來做，或者找些專用的小軟體之類的。順便問一下，你該不是在開網吧，自學吧。
問題四：如何將一個頁面緩存一天，伺服器該如何設置 16G??20台? ?安裝2008SP2? ?系統自己緩存就可以了 查看原帖>>
問題五：linux網吧緩存伺服器如何架設 現成的緩存伺服器MQCache，下載安裝，省時又省力
問題六：Win2003系統緩存怎麼設置(伺服器) 20分 的電腦--屬性---高級----性能「設置」---高級---虛擬內存「設置」，可修改腔做頁面大小等。。。
問題七：16G伺服器，怎麼設置緩存啊！ - 16G??20台? ?安裝2008SP2? ?系統自己緩存就可以了 查看原帖>>
問題八：如何在IIS里設置伺服器端緩存時間？ 設置IIS緩存的方法
1.測試，可以緩存整個Share工程（經測試IIS中的緩存測試對ASPX頁面不起作用，估計與頁面壓縮的設置原理一樣）；
2.需要設置緩存的工程： Share，Portal（根據IIS日誌分析報告中的「Most Requested Directories」得出）；
3.設置的方法：
第一步：
打開 IIS 配置管理工具（Internet 信息服務(IIS)管理器）。
選中一個目錄（或者網站，如果您想為所有站點配置，請選擇點中「網站」那個圖標），點「屬性」按鈕，會彈出一個配置窗口
第二步：
選擇「HTTP 頭」 TAB 標簽，然後您會看到：「自定義 HTTP 頭」一欄。
第三步：
點旁邊的「添加(D)...」按鈕，來添加上那條命令。
在彈出的窗口中：「自定義 HTTP 頭名(C)」中輸入：「Cache-Control」，在「自定義 HTTP 頭值(U)」中輸入：「Must-revalidate」。
Cache-Control頭的參數設置：
Public 響應會被緩存，並且在多用戶間共享。
Private 響應只能夠作為私有的緩存，不能再用戶間共享。
No-cache 響應不會被緩存
No-store 響應不會被緩存，並且不會被寫入到客戶端的磁碟里，這也是基於安全考慮的某些敏感的響應才會使用這個。
Max-age=#seconds 響應將會某個指定的秒數內緩存，一旦時間過了，就不會被緩存。
Must-revalidate 響應會被重用來滿足接下來的請求，但是它必須到伺服器端去驗證它是不是仍然是最新的。
注意：
如果你要想在iis中配置緩存，請參閱微軟的知識技術文章：
・ How to Modify the Cache-Control HTTP Header When You Use IIS.
不知道這樣可以 不可以啊。
問題九：做前端靜態資源緩存伺服器有哪些成熟易搭建的方案 我現在是把阿里雲的笑圓帶 CDN 直接解析到 OSS 。
每天的 PV ， 1 萬到 5 萬。
然而才用了一個多月就跑了 300+G 流量。 0.36/GB 。淚。
阿里雲的 CDN 實在是太貴了，用峰值帶寬的話，根本就不能控製成本啊！萬一有個用戶 100M 水管，那一天豈不是要付 100 塊錢？
所以還不如選一個好一點的 BGP 線路機器反代到 OSS 。
自己用 squid 搭建嗎？
如果主站是 HTTPS 的， squid 能配置 SSL 嗎？還是說要 nginx 配置 SSL 以後再去反代 squid ，然後 squid 反代 oss ？
有沒有配置腳本？
還是裝個 AMH/WDCP 之類面板，然後可以傻瓜化配置？
對主機磁碟 IO 、內存有什麼要求？
問題十：安裝秒開緩存伺服器後怎麼檢測數據是否走緩存了？ 兩個：
一是設置瀏覽器，以IE為例，打開工具-Internet選項-Internet臨時文件里的設置，改為每次訪問時檢查
二是設置伺服器端,以IIS為例，設置內容過期為立即過期，那這樣每次都會從伺服器下載新的數據，代價是伺服器的帶寬佔用大幅度上升
『柒』 緩存伺服器Cache-only是怎麼工作的
4．CDN 的工作原理
在描述CDN的實現原理，讓我們先看傳統的未加緩存服務的訪問過程，以便了解CDN緩存訪問方式與未加緩存訪問方式的差別： http://www.video.com.cn/club/attachment.php?aid=939&k=&t=1218114144&noupdate=yes
由上圖可見，用戶訪問未使用CDN緩存網站的過程為:
1)、用戶向瀏覽器提供要訪問的域名；
2)、瀏覽器調用域名解析函數庫對域名進行解析，以得到此域名對應的IP地址；
3)、瀏覽器使用所得到的IP地址，域名的服務主機發出數據訪問請求；
4)、瀏覽器根據域名主機返回的數據顯示網頁的內容。
通過以上四個步驟，瀏覽器完成從用戶處接收用戶要訪問的域名到從域名服務主機處獲取數據的整個過程。CDN網路是在用戶和伺服器之間增加Cache層，如何將用戶的請求引導到Cache上獲得源伺服器的數據，主要是通過接管DNS實現，下面讓我們看看訪問使用CDN緩存後的網站的過程： http://www.video.com.cn/club/attachment.php?aid=940&k=&t=1218114144&noupdate=yes
通過上圖，我們可以了解到，使用了CDN緩存後的網站的訪問過程變為：
1)、用戶向瀏覽器提供要訪問的域名；
2)、瀏覽器調用域名解析庫對域名進行解析，由於CDN對域名解析過程進行了調整，所以解析函數庫一般得到的是該域名對應的CNAME記錄，為了得到實際IP地址，瀏覽器需要再次對獲得的CNAME域名進行解析以得到實際的IP地址；在此過程中，使用的全局負載均衡DNS解析，如根據地理位置信息解析對應的IP地址，使得用戶能就近訪問。
3)、此次解析得到CDN緩存伺服器的IP地址，瀏覽器在得到實際的IP地址以後，向緩存伺服器發出訪問請求；
4)、緩存伺服器根據瀏覽器提供的要訪問的域名，通過Cache內部專用DNS解析得到此域名的實際IP地址，再由緩存伺服器向此實際IP地址提交訪問請求；
5)、緩存伺服器從實際IP地址得得到內容以後，一方面在本地進行保存，以備以後使用，二方面把獲取的數據返回給客戶端，完成數據服務過程；
6)、客戶端得到由緩存伺服器返回的數據以後顯示出來並完成整個瀏覽的數據請求過程。
通過以上的分析我們可以得到，為了實現既要對普通用戶透明(即加入緩存以後用戶客戶端無需進行任何設置，直接使用被加速網站原有的域名即可訪問)，又要在為指定的網站提供加速服務的同時降低對ICP的影響，只要修改整個訪問過程中的域名解析部分，以實現透明的加速服務，下面是CDN網路實現的具體操作過程。
1)、作為ICP，只需要把域名解釋權交給CDN運營商，其他方面不需要進行任何的修改；操作時，ICP修改自己域名的解析記錄，一般用cname方式指向CDN網路Cache伺服器的地址。
2)、作為CDN運營商，首先需要為ICP的域名提供公開的解析，為了實現sortlist，一般是把ICP的域名解釋結果指向一個CNAME記錄；
3)、當需要進行sorlist時，CDN運營商可以利用DNS對CNAME指向的域名解析過程進行特殊處理，使DNS伺服器在接收到客戶端請求時可以根據客戶端的IP地址，返回相同域名的不同IP地址；
4)、由於從cname獲得的IP地址，並且帶有hostname信息，請求到達Cache之後，Cache必須知道源伺服器的IP地址，所以在CDN運營商內部維護一個內部DNS伺服器，用於解釋用戶所訪問的域名的真實IP地址；
5)、在維護內部DNS伺服器時，還需要維護一台授權伺服器，控制哪些域名可以進行緩存，而哪些又不進行緩存，以免發生開放代理的情況。
『捌』 瀏覽器緩存和伺服器緩存
一、瀏覽器緩存
瀏覽器緩存即http緩存；瀏覽器緩存根據是否需要向伺服器重新發起HTTP請求將緩存過程分為兩個部分，分別是 強制緩存 和 協商緩存 。
瀏覽器第一次請求資源的時候伺服器會告訴客戶端是否應該緩存資源，根據響應報文中HTTP頭的緩存標識，決定是否緩存結果，是則將請求結果和緩存標識存入瀏覽器緩存中。如下圖：
1.強制緩存 ：瀏覽器會對緩存進行查找，並根據一定的規則確定是否使用緩存。
強制緩存的緩存規則？
HTTP/1.0 Expires 這個欄位是絕對時間，比如2018年6月30日12:30，然後在這個時間點之前的請求都會使用瀏覽器緩存，除非清除了緩存。
這個欄位的缺點就是只會同步客戶端的時間，這就有可能修改客戶端時間導致緩存失效。
HTTP/1.1 cache-Control 這個是1.1的時候替換Expires的，它會有幾種取值：
public ：所有內容都將被緩存（客戶端和代理伺服器都可緩存）
private ：所有內容只有客戶端可以緩存， Cache-Control的默認取值
no-cache ：客戶端緩存內容，但是是否使用緩存則需要經過協商緩存來驗證決定
no-store ：所有內容都不會被緩存，即不使用強制緩存，也不使用協商緩存
max-age=xxx (xxx is numeric) ：緩存內容將在xxx秒後失效
比如max-age=500，則在500秒內再次請求會直接只用緩存。
優先性：cache-Control > Expires
如果同時存在，cache-Control會覆蓋Expires。
這個欄位的缺點就是：
如果資源更新的速度是秒以下單位，那麼該緩存是不能被使用的，因為它的時間單位最低是秒。
如果文件是通過伺服器動態生成的，那麼該方法的更新時間永遠是生成的時間，盡管文件可能沒有變化，所以起不到緩存的作用。
上圖中瀏覽器緩存中存在該資源的緩存結果，並且沒有失效，就會直接使用緩存的內容。
上圖中瀏覽器緩存中沒有該資源的緩存結果和標識，就會直接向伺服器發起HTTP請求。
2.協商緩存： 瀏覽器的強制緩存失效後(時間過期)，瀏覽器攜帶緩存標識請求伺服器，由伺服器決定是否使用緩存。
伺服器決定的規則？
控制協商緩存的欄位有 Last-Modified / If-Modified-Since 和 Etag / If-None-Match。
①Last-Modified 是伺服器返回給瀏覽器的本資源的最後修改時間。
當下次再次請求的時候，瀏覽器會在請求頭中帶 If-Modified-Since ,即上次請求下來的 Last-Modified 的值，
然後伺服器會用這個值和該資源最後修改的時間比較，如果最後修改時間大於這個值，則會重新請求該資源，返回狀態碼200。
如果這個值和最後修改時間相等，則會返回304，告訴瀏覽器繼續使用緩存。
② Etag 是伺服器返回的一個hash值。
當下次再次請求的時候，瀏覽器會在請求頭中帶 If-None-Match ,即上次請求下來的 Etag 值，
然後伺服器會用這個值和該資源在伺服器的 Etag 值比較，如果一致則會返回304，繼續使用緩存；如果不一致，則會重新請求，返回200。
二、伺服器緩存
上面是一個簡單的流程圖：
用戶1訪問A頁面，伺服器解析A頁面返回給用戶1，同時在伺服器內存上做一定映射，把A頁面緩存在硬碟上面
用戶2訪問A頁面，伺服器直接根據內存上的映射找到對應的頁面緩存，直接返回給用戶2，這樣就減少了伺服器對同一頁面的重復解析
伺服器緩存和瀏覽器緩存的區別：
伺服器緩存是把頁面緩存到伺服器上的硬碟里，而瀏覽器緩存是把頁面緩存到用戶自己的電腦里
Nginx伺服器
Nginx是一個高性能的HTTP和反向代理伺服器。具有非常多的優越性：
在連接高並發的情況下，Nginx是Apache伺服器不錯的替代品，Nginx在美國是做虛擬主機生意的老闆們經常選擇的軟體平台之一。
Nginx提供了expires、etag、if-modified-since指令來實現瀏覽器緩存控制。
nginx -s reload#重新載入配置文件
nginx -s reopen#重新打開log文件
nginx -s stop#快速關閉nginx服務
nginx -s quit #優雅的關閉nginx服務，等待工作進程處理完所有的請求
Nginx設置靜態文件的緩存過期時間
location ~.*\.(js|css|html|png|jpg)$ {
expires 3d;
}
expires 3d;//表示緩存3天
expires 3h;//表示緩存3小時
expires max;//表示緩存10年
expires -1;//表示永遠過期。
如果設置為-1在js、css等靜態文件在沒有修改的情況下返回的是http 304，如果修改返回http 200
對於靜態資源會自動添加ETag，可以通過添加etag off指令禁止生成ETag。如果是靜態文件，那麼Last-Modified值為文件的最後修改時間。
在開發調試web的時候，經常會碰到因瀏覽器緩存(cache)而經常要去清空緩存或者強制刷新來測試的煩惱，提供下apache不緩存配置和nginx不緩存配置的設置。在常用的緩存設置裡面有兩種方式，都是使用add_header來設置：分別為Cache-Control和Pragma。
location ~ .*\.(css|js|swf|php|htm|html )$ {
add_header Cache-Control no-store;
add_header Pragma no-cache;
}
nginx gzip壓縮
使用 gzip 壓縮可以降低網站帶寬消耗，同時提升訪問速度。
主要在nginx服務端將頁面進行壓縮，然後在瀏覽器端進行解壓和解析，
目前大多數流行的瀏覽器都遲滯gzip格式的壓縮，所以不用擔心。
默認情況下，Nginx的gzip壓縮是關閉的，同時，Nginx默認只對text/html進行壓縮
gzip on;
ersio #開啟gzip壓縮輸出
gzip_http_vn 1.0 ;#默認1.1
#其中的gzip_http_version的設置，它的默認值是1.1，就是說對HTTP/1.1協議的請求才會進行gzip壓縮
#如果我們使用了proxy_pass進行反向代理，那麼nginx和後端的upstream server之間是用HTTP/1.0協議通信的。
gzip_vary on ;
#和http頭有關系，加個vary頭，給代理伺服器用的，有的瀏覽器支持壓縮，有的不支持，
#所以避免浪費不支持的也壓縮，所以根據客戶端的HTTP頭來判斷，是否需要壓縮
gzip_comp_level 6;
#設置gzip壓縮等級，等級越底壓縮速度越快文件壓縮比越小，反之速度越慢文件壓縮比越大 1-9
gzip_proxied any;
#Ngnix作為反向代理的時候啟用
#expample:gzip_proxied no-cache;
# off – 關閉所有的代理結果數據壓縮
# expired – 啟用壓縮，如果header中包含」Expires」頭信息
# no-cache – 啟用壓縮，如果header中包含」Cache-Control:no-cache」頭信息
# no-store – 啟用壓縮，如果header中包含」Cache-Control:no-store」頭信息
# private – 啟用壓縮，如果header中包含」Cache-Control:private」頭信息
# no_last_modified – 啟用壓縮，如果header中包含」Last_Modified」頭信息
# no_etag – 啟用壓縮，如果header中包含「ETag」頭信息
# auth – 啟用壓縮，如果header中包含「Authorization」頭信息
# any – 無條件壓縮所有結果數據
gzip_types text/html ;#壓縮的文件類型
#設置需要壓縮的MIME類型,非設置值不進行壓縮
#param:text/html|application/x-javascript|text/css|application/xml
gzip_buffers 16 8k; #設置gzip申請內存的大小,其作用是按塊大小的倍數申請內存空間設置gzip申請內存的大小,其作用是按塊大小的倍數申請內存空間
#設置gzip申請內存的大小,其作用是按塊大小的倍數申請內存空間
# param1:int 增加的倍數
# param2:int(k) 後面單位是k
# example: gzip_buffers 4 8k;
# Disable gzip for certain browsers.
gzip_disable 「MSIE [1-6].(?!.*SV1)」; #ie6不支持gzip，需要禁用掉ie6