Web Caching效率的改善主要著重在：
1提高accumulative cache hit ratio(成功快取的比率):
使用者可在較短時間內取得資料，而不用連到原始網路去接取資料，使得:
a.減少使用者等待的latency(延遲時間)
b.減少cache miss的發生，因為一但發生cache miss則必定會增加latency
c.減少網路負載，減少資料在重覆地網路上自原始網路傳送出來
2具可擴充性
3load balancing(負載均衡)
4有效率的快取分享
5Network Congestion(網路擁擠)以及Bandwidth Consumption(網路頻寬使用)的改善
6分層簡單的設定管理。
7提升快取效能配備:ex記憶體,網路卡
……………
現有的Web Caching Protocol(掌控快取伺服器群之間分享運作的協定)
HTCP(Hyper Text Caching Protocol)
目前還屬於Internet-Draft的研擬階段，包含如何發現快取伺服器、object，以及如何管理、監看其運作
HTTP(HyperText Transfer Protocol)v1.1
提供了以下相關Header支援Web Caching的運作：Cache-Control、Age、Pragma: no-cache、Expires
支援Persistent Connection(持續性連線)：對同一個使用者而言，在一短時間內於網站上瀏覽，不斷地自網站上接取資料，HTTP主要架構在TCP (Transmission Control Protocol)的基礎上，不斷的建立連線、接收資料、關閉連線，對於網路的使用與網站伺服器而言，都會導致較差的使用效益，於是提出持續性連線的方法，在不重新連線的情況下，可接取多次資料接收
ICP(Internet Caching Protocol,網路快取傳輸協定)
Hierarchical(階層式) Caching 1995
缺點:太多的ICP Query / Response資料在快取伺服器群之間傳送，明顯地增加了使用者等待時間。而且會造成過多的連線要求集中在單一的快取伺服器上，在階層式快取架構上往往會產生過度集中的問題，使得該快取伺服器成為整個架構中的瓶頸。並且，當上層的某個快取伺服器發生錯誤，無法提供服務時，也會使的整個階層式架構無法繼續運作
icpv2(Internet Cache Protocol v2,網際網路快取通訊協定第二版)
由Squid代理/快取伺服器所使用,port:3130
CARP (Cache Array Routing Protocol)
Distributed (分散式) Caching
Microsoft 提出，利用URL-hashing的方式將WWW client的連線要求分散到所有參與CARP運作的快取伺服器群中。由於CARP使用URL-hashing的方式，來分配連線要求，特定URL的object會被指定到特定伺服器，而不會考量到WWW client characteristic，雖然可以造就全域性的快取架構，但效率不佳，且不適合在區域較廣的Web Caching分享環境中使用。
CARP 使用以雜訊為基礎的路由方式來在陣列中提供「要求解析路徑 (request resolution path)」。要求解析路徑是以陣列成員身份及 URL 的雜訊為基礎，這表示瀏覽器或下游代理伺服器 (Proxy Server) 可瞭解所要求的資訊是儲存於陣列的何處
WCCP(Web Cache Control Protocol)
HTTP packet routing
配合Cisco發展的Cache Engine，將Cache Engine依附在路由器上，具有Transparent Web Caching的特性，Cache Engine儼然就是快取伺服器，當cache hit發生時，便將object傳回給連線要求端，否則當cache miss發生時，便將連線要求往下個路由器轉送，直到object所在的原始網站為止。user不需任何設定
缺點是，整個網路上都必須安裝Cache Engine，因為其它一般的路由器接收到此連線要求之封包，仍舊會繼續將封包傳遞下去，但此連線要求之封包目的地是object原始網站，而不是某個快取伺服器，在這種情況下，雖有傳統的快取伺服器存在網路上，也是徒然無功，無法使用。
……………………….
相關議題
Forced HTTP packet routing(強制性的HTTP封包routing)：
會引致網路效率低落。HTTP封包routing又稱URL routing，類似IP-routing但卻是使用URL來取代IP位址，同樣地加入default routing。 HTTP封包routing的缺點在於需要更換新的路由器與routing演算法，並且不能考量到快取伺服器Application-Level負載。
Adaptive Cache：
設計建構一個Global(全域性的)網路快取架構。由於HTTP封包是在透過routing路徑選擇，經過路由器或LAN交換器到達網路快取伺服器。當網路快取伺服器發生cache miss時，最後不論是自快取伺服器或原始網站所取得的object勢必都會經過router兩次，所以針對以上的缺點加以改善。CGMP (Cache Group Management Protocol)使用multicast 來自動發現鄰近的快取伺服器，並且能夠動態調整彼此之間的關係與架構。
Cache Digest：
將伺服器cache內所有objects的URL Table利用hash function簡化為digest
理念:快取伺服器彼此間交換Cache Digest，可以在每隔一定時間進行交換，或是視情況來進行交換
例如：當False miss, False hit發生頻率過高時。其中False miss指的是，雖然Cache Digest利用Hashing Table的機制，將URL對映到某個數字，例如：n，若某個URL的object有存在該快取伺服器中，就會記錄object相關資訊在Hashing Table的第n筆欄位中。其它快取伺服器只要將此Hashing Table取回，即可不需要送出ICP Query也不需要等待ICP Response就可馬上知道該快取伺服器中是否擁有此URL的object，大幅減少ICP Query / Response
web頁面保留方法
啟發式演算法heuristic
1猜測保存每個網頁時間長度,根據last-modified表頭推算保存時間
2若網頁在某時前被修改,則保存其快取網頁到某時
rfc2616處理
1代理程式送給伺服器if-modified-since要求表頭,指定想要的網頁及被快取之網頁last-modified(最近修改時間)
2未修改則回not modified訊息,使用快取內的網頁,若修改則傳回新的內容
主動式快取
代理程式從伺服器取得網頁後,便將指向超連結的網頁載入快取
雖可減少後續要求處理時間,但可能有處理不完的網頁
伺服器複製
mirroring(鏡像複製)：伺服端將內容複製到多個且散佈各處的位置
鏡像網站：完全靜態,可將完整或部份內容放到每個地點
流量突然大增的網站根據需要把自己複製到多個地點,等到緩和後在關閉網站：需於託管網站公司協議
CDN(content delivery networks,內容遞送網路)
將內容很有效率地提供給終端使用者,並收取費用
1內容擁有者將網站內容交由CDN進行前處理程式把URL換掉
2修改過網頁存在內容擁有者網站,影像音訊等資料改在CDN伺服器上抓取
3將CDN伺服器放入ISP的LAN上
CDN伺服器(CDN假HTTP伺服器)
不提供任何內容
主要查出那個CDN內容伺服器可提供使用者最好的服務
並將使用者導往CDN伺服器（通常是代理程式）
若代理程式無此檔則從真實伺服器取出,並放入快取以備後續使用