傳統代理: 用戶隱藏在代理服務器之後。代理服務器工作在應用層，它只轉發它支持的協議的數據。
反向代理(Reverse Proxy): 這種機制是Web服務器隱藏在代理服務器之後，實現這種機制的服務器稱作反向代理服務器(Reverse Proxy Server)。此時，Web服務器成爲後端服務器，反向代理服務器稱爲前端服務器。
引入反向代理服務器的目的之一就是基於緩存的加速。我們可以將內容緩存在反向代理服務器上，所有緩存機制的實現仍然採用HTTP/1.1協議。
反向代理服務器不使用緩存:
可將Nginx做爲Apache的反向代理服務器，反向代理服務器不使用緩存時，吞吐率會下降，因爲原本直達Web的請求，現在繞路轉達，處理時間必然會增加。
可將Web服務器和應用服務器分離，前者處理一些靜態內容，並作爲反向代理，後者處理動態內容。
反向代理服務器(RPS)使用緩存:
Varnish作爲RPS，能夠提供較好的緩存功能。如果緩存內容發揮作用，在Http響應頭中服務器顯示的是後端服務器，但Via標記會指示數據的來源。
RPS可通過修改流經它的Http頭信息來決定哪些內容可以緩存，哪些內容不可以緩存。瀏覽器和Web服務器通過Http將自己的需求告訴RPS，RPS進行協調緩存。
Varnish通過配置文件來修改緩存規則，使用VCL語言。它也提供強制清除緩存的功能。Varnish提供一個監控程序Varnishstat用來監控緩存命中率。
緩存命中率和後端吞吐率的理想技術模型:
實際吞吐率: 指反向代理服務器處理用戶請求時的實際吞吐率。
後端吞吐率: 指後端Web服務器處理來自反向代理服務器的請求時的吞吐率。
活躍內容數: 在平均緩存有效週期內，反向代理服務器想後端服務器請求內容的次數。
緩存丟失率=(活躍內容數/(實際吞吐率×平均緩存有效期))×100%
緩存命中率= 1-緩存丟失率
後端吞吐率= 活躍內容數/平均緩存有效期
緩存命中率= (1-(後端吞吐率/實際吞吐率))×100%
後端吞吐率 = (1 – 緩存命中率)×實際吞吐率
結論:
1. 活躍內容數和平均緩存有效期一定的情況下，緩存命中率與實際吞吐率成正比。
2. 實際吞吐率和平均緩存有效期一定的情況下，緩存命中率與活躍內容數成反比。
3. 活躍內容數和實際吞吐率一定的情況下，緩存命中率與平均緩存有效期成正比。
4. 活躍內容數一定的情況下，後端吞吐率與平均緩存有效期成反比。
5. 平均緩存有效期一定的情況下，後端吞吐率與活躍內容數成正比。
6. 緩存命中率的變化不一定會影響後端吞吐率。
7. 後端吞吐率的變化不一定會影響緩存命中率。
由此可見，緩存命中率越高，後端服務器工作量越少是錯誤的認識。
ESI(Edge Side Includes)
ESI類似於SSI，可以在頁面中嵌入子頁面，不同於SSI的是SSI在Web服務器端組裝內容，ESI在Http代理服務器上組裝內容，包括反向代理。
Varnish支持ESI，這樣Varnish就支持網頁局部緩存，實現局部更新動態內容。AJAX也有類似的功能(它對局部內容支持異步請求)。
穿過代理:
反向代理服務器作爲用戶和後端Web服務器的中介，它只將用戶的Http請求轉發給後端服務器，但用戶的某些信息有時並不在Http請求中，如用戶的IP地址和發送請求的TCP端口，這對於後端的Web服務器是不可見的，這就有必要想辦法讓這些信息“穿過”反向代理服務器。
辦法: 讓反向代理請求後端服務器時攜帶附加的Http頭信息(通過配置反向代理服務器來實現)。同樣，如果後端服務器想要告知瀏覽器一些額外的信息，也可以在Http響應頭中攜帶自定義的信息“穿過”反向代理。
Nginx和Lighttpd優勢主要體現在網絡IO模型上。
Nginx利用epoll模型可以在較大併發用戶數的情況下依然提供較高的吞吐率。
Ajax的問題，局部內容應該和父頁面所在的主機保持相同的頂級域名。
影響緩存命中率的因素: 緩存過期時間，緩存空間不夠大被換出，緩存的粒度，架構設計。
影響Web服務器處理能力的因素？(服務器併發處理能力這一章)
