一、缓存技术
缓存技术是一种在本地存储经常访问的信息的一种技术。Web缓存在用户本地的存储设备上存储Web网页及其内容，这要比Web查询快。通过减少WAN链路和Web服务器上的传输量，缓存为ISP、企业网络及终端用户提供了以下一些好处。
1、减少WAN带宽的占用，降低成本。ISP把缓存引擎（Cache Engine）置于网络关
键点上，以提高响应时间，降低骨干网上的带宽占用需求。ISP也把缓引擎置于W AN 访问的关键点上，使其能从本地磁盘上为Web查询提供服务，而不能远距离或通过Web服务器读取信息。
在企业网中，由于Web缓存技术可以用低成本、低带宽的W AN链路服务同一个位置的用户群，从而大大降低了对带宽的占用时间。企业可以利用现有的WAN链路带宽增加用户数，并为用户提供更多的服务。
2、提高终端用户的效率。本地Web缓存的响应时间比WAN下载相同内容的时间快
三倍，终端用户可明显感到响应时间的加快，并可实现完整的传输。
3、安全访问控制及监测。缓存引擎为网络管理员提供了一个简单、安全的方法，通
过URL过滤机制，可加强基于站点地址的访问控制策略。
4、可操作日志记录。网络管理员能了解哪些URL被点击、每秒缓存服务多少个查询、
从缓存提取的URL的百分比是多少以及其它操作相关的统计数据。
Web缓存按以下步骤工作：1、用户访问Web网页；2、当网页传输给用户时，缓存系统存储网页并把与其相关的图文存储到本地存储设备上；3、另一个用户（或初始用户）访问此网页；4、Web缓存从本地存储器中取出网页，而不用在Internet上发送查询信息，这样就加快了下载速度，减少了W AN链路的带宽需求；5、不同的系统对保证缓存信息与源信息同步更新的方法各不相同。
IP缓存加快网络访问速度
I P超高速缓存（I P C a c h i n g）已经成为优化使用
带宽和提高网络性能的一种良好的解决方案。对最终用
户的近端所需文件频繁存储，可以降低相应的W A N或
I n t e r n e t连接的带宽需要，这样反过来又省去了或延
缓了昂贵的升级之需。因为所有通信都是以L A N的速度
传输，这同样提高了最终用户的性能。
这种缓存技术减少了W A N的数据链接流量，减轻了W e b服务器的负担，它给I S P、企业网与最终用户都带
来了显而易见的好处。
1．减小W A N的带宽从而降低了网络开销；
2．提高最终用户的效率。采用了I P缓存技术的网络，从缓存服务器中下载的回应速度要比从W A N上下载
同样的内容快3倍。
现实的提速方案早在万维网流行以前人们就知
道I P缓存的这个好处。典型的例子是I n t e r n e t上诸如F T P、G o p h e r和n e w s g r o u p s之类的归档文件的存放，
文件在世界各地以镜像方式就近存放。但对于H T T P，
由于用户请求的随机性数据量大和时间相关性强，镜像存储并不可行。
I P缓存服务器对H T T P就相当于对上述归档协议的镜像存储。这两种缓存服务器工作原理基本相同。I P
缓存服务器截获浏览器向W e b服务器发出的数据请求，当这部分数据从W e b服务器下传给浏览器时，将它们存在硬盘上。这样，以后I P缓存服务器再截获到类似请求时，就可以直接把相应的缓存数据发给请求者。
I S P由于面对来自用户和I C P方要求提高服务质量的压力，成为了I P缓存服务器的主要使用者。对于用户来说，更快的连接如D S L s（D i g i t a l S u b s c r i b e r
L i n e s）、I S D N和C a b l e M o d e m s将取代链路中的薄弱
环节———电话M o d e m（目前一般它的最大传输速率为56k b i t／s）。那些升级了他们因特网接入的用户，将感到浏览器性能有明显的提高，同时更大的数据流量也将注入I n t e r n e t主干线。在市场的推动下，I S P寻求
性能价格比更高的方法来充分利用现有网络带宽，I P
缓存则是现在和将来的主要解决方案。
代理服务器是前身
典型的早期缓存服务器是代理缓存服务器。它们为一组用户提供数据代理服务，接受用户的请求并转发到目的地。作为所有用户访问I n t e r n e t唯一的接入点，代理服务器要进行内容过滤、用户认证、活动日志及数据缓存，和防火墙一起，它是一种安全的接入I n t e r n e t 的方案。
最早的代理缓存是基于软件的H a r v e s t C a c h e，它是1994年到1996年美国几家研究部门资助的一个联合研究项目的成果。从那时起，市场上陆续出现了一些代理缓存服务器。其中最引人注目的有M i c r o s o f t
N e t s c a p e C o m m u n i c a t i o n s和N o v e l l等几家，它们的
代理缓存服务器都与其各自的公司产品紧密结合。除了有缓存功能，它们还有许多代理功能，如用户认证、内容过滤、病毒检查、安全、活动日志等。
“软”变“硬”是主流
1997年一个题为“为什么有缓存的”的报告中，
研究机构F o r r e s t e r预言缓存将从软件转向硬件。
D a t a q u e s t1998年7月也同样预言硬件缓存将是缓存
市场的主流。因此1998年许多供应商纷纷公布了硬件缓存的应用。他们声称硬件缓存比纯软件好，因为操作系统和缓存硬件是紧密集成的，并针对缓存进行了优化。他们还声称其产品易于安装和配置，是一个更安全的平台。概括地讲，基于软件的缓存，如代理缓存，是针对代理特性来设计的，而硬件缓存装置能支持繁重的缓存任务，并且也能用于代理。
值得注意的是最近推出的，相对低廉的缓存装置。这些基于非专有硬件和软件的设备，是预先配置好的，着重于低价和易用。它们对于小公司和那些希望只在工作组内实行缓存，又因以前的解决方案价格过高或操作过繁而犹豫不决的大公司特别有吸引力。
现有的协议
I C P（I n t e r n e t C a c h i n g P r o t o c o l），来源于
H a r v e s t P r o j e c t的早期缓存研究，规定了多个I P缓
存如何交换有关W e b内容的新信息，如何从对等的缓存上检索数据（如从源W e b服务器上检索相应数据）。通过I C P，缓存服务器的管理员可以将机器配置成能检索其他支持I C P的缓存。如一个本地的缓存可以轮询上一级的缓存，看看它们是否得到所需文件的更新拷贝，或者是否核实了该文件在源地的保存时间。即使上一级的缓存没有文件的新版本，它也可能在更近的时间里核实了该文件在源地没有被更新或者以一个新的版本存储。依赖于本地缓存的更新算法，可用该信息从源地得到文件的一个新版本，或是利用本地的版本。
轮询上一级的缓存数据因来回要耗时，延迟也会相应地增加，但因请求无需传到源地去，仍可节省大量的时间。另外，从就近的基于I C P链接的缓存获得数据，一般会减少I n t e r n e t主干网的阻塞，为I n t e r n e t的其他用户节省了带宽。目前市场上的缓存几乎都支持
I C P。
和I C P一样，C R P（C a c h i n g A r r a y R o u t i n g
P r o t o c o l）是缓存对等协议，它主要着重于本地缓存服务器间的载荷平衡。它是由M i c r o s o f t起草的，已经作为I n t e r n e t提议提交给了3W C（W o r l d W i d e W e b
C o n s o r t i u m）。除了M i c r o s o f t，其他不少的厂商如
P a c k e t s t o r m T e c h n o l o g i e s和S u n也支持C A R P。
不足之处
代理缓存方案有两个主要缺点。第一，缺乏透明性。
目前，为了将对W e b的访问要求指向一个本地缓存服务
器而非原来的某个远程服务器，有的必须将W e b浏览器
的客户端的所有请求配置成指向缓存服务器。尽管这对
于经验丰富的用户来说也许并不难，只需重新配置客户
端浏览器，但这也是大多数网络管理员所尽量避免的，
因为这样做，对于任何大规模的安装管理、技术支持和
统一规划用户来说，实在是太麻烦了，而且开销也过大。
第二，可扩展性不足。现在的系统局限在缓存器的大小、
增长和性能上，目前的W e b缓存服务器包括防火墙代理
服务器，网络管理员们现在正面对着他们曾遇到的，与
早期防火墙相同的扩展性局限。结果是当今的缓存服务
器系统不提供成千上万同时产生的，链接增长的路径，
网页的存储以及容错等等，缓存服务器被设计者们限定
成一个孤立的、集中的缓存装置。
为了克服缺点，可以安装基于策略的路由器或第四层的交换机将数据流重定向到一组缓存服务器，实现透
明的缓存。这些缓存服务器截获发向H T T P80端口的请
求并重定向到缓存服务器，由它来接管H T T P请求并将
所需数据回传给浏览器。一个真正透明的缓存方案还应
该支持缓存服务器负载平衡以及故障恢复的功能。典型
的第四层交换机有A l t e o n N e t w o r k s的A C E d i r e c t o r
和F o u n d r y N e t w o r k s的S e r v e r I r o n。
联想iCache的基本工作方式及应用环境浅析2000年
03月-04月
第二十四期
作者:李晓洪;创建时间:2000-05-19
联想iCache产品可放置于网络的多个点上，每台设备可服务于一组用户、工作组或地理区域。
联想iCache产品有Internet加速（正向代理）, Web服务器加速（反向代理）,高速缓存分层, 高速缓存集群四种工作方式。这里我们主要介绍一下前两种工作方式：正向代理与反向代理。Internet加速（正向代理）
正向代理用来加速用户（如浏览器）请求响应的时间。从网络配置观点看，这不是最简单的方法。但是，它确实要求所有用户将其浏览器配置为将联想iCache设备作为代理服务器使用，而代理已经被定义为可以在Cisco路由器或L-4交换机（透明代理）之后透明地发挥作用。基本
上讲，正向代理的操作原理如下（见图3）：
(图3).
浏览器从其正向代理服务器设备iCache请求初始web服务器的web页面。
转发代理服务从DNS获得数字IP。
从Web server上获得初始服务器的对象。
iCache将收到的对象的副本转发到浏览器。
转发代理服务无需访问DNS或初始Web服务器即可处理。
相同页面对象的后续请求。
1.系统中的用户发出浏览器请求，要求访问某Web站点。为方便起见，我们称此站点为https://www.doczj.com/doc/8d17390433.html,。如果转发代理激活，Web请求将从本地的高速缓存设备或Web站点的初始服务器履行。
2.为方便起见，我们假设对https://www.doczj.com/doc/8d17390433.html,的请求以前尚未由系统中的其它任何人实施过，因而请求页面无法从本地高速缓存中获取。在这种情况下，请求将沿着Internet到达Web站点的初始服务器（https://www.doczj.com/doc/8d17390433.html,），在此点上将请求的数据返回到选择此站点的用户。转发代理被激活后，这个已经访问过的Web站点（https://www.doczj.com/doc/8d17390433.html,）的所有静态元素都将本地存储于联想iCache 设备上。
3.现在，如果该用户再次请求访问同一站点，或者网络系统上的另一位用户希望访问该站点，此时浏览器无需再连接到Web站点的初始服务器，只要调用本地高速缓存的数据即可。
4.转发代理能大大提高每个后续用户的速度，使他们无需再穿越Internet（可能会遇到带宽和性能问题），只要从本地高速缓存中获取内容即可。
转发代理高速缓存还能起网络防火墙保护的作用。与Internet的直接连接会将网络暴露给外面，因而容易遭到入侵。转发代理服务器是Internet和网络之间的缓冲器，能作为两种系统之间的联系点。这意味着代理服务器需要对Internet"开放"，因而能通过将网络在防火墙之外隔离开来而保护网络。
如前所述，必须为每个浏览器设置代理高速缓存，这样相当耗费网络管理员的时间。而且，代理高速缓存比较脆弱：作为网络的Internet"网关"，代理高速缓存是潜在的最大故障点。如果代理高速缓存出现故障或瘫痪，整个网络上的Internet服务就会中断。
Web服务器加速（反向代理）
反向代理是Web服务器加速器。这时它作为代理高速缓存，不针对浏览器用户小组，而针对一台或多台特定初始Web服务器。Web服务器加速或反向代理的关键在于95%从Web站点请求的对象是静态对象，如HTML页面和图形等。其余请求针对非高速缓存对象，如CGI收集器程序的输出等。
为实施此高速缓存技术，只要将联想iCache 设备放置在一台或多台Web服务器前端即可。此"代理高速缓存"设备能假装作Web服务器，浏览器可以与它连接，无需再直接与Web服务器相连。因此，大量Web服务工作量被卸载到高速缓存上。联想iCache 设备将经常请求的Web 对象存储在RAM中，使之能快速响应。非高速缓存请求被传送到Web服务器，多数情况下与浏览器被直接；连接一样快或更快（见图4）。
图4.
Web上的浏览器请求一个初始web服务器的主页。
与往常一样，这样会向DNS产生一个要求该web服务器IP地址的请求。
DNS不会返回初始web服务器的数字IP地址，返回iCache的IP地址。
浏览器利用iCache设备的IP地址请求Web页。
iCache从初始web服务器获得web页面对象。
iCache向浏览器返回对象的复制品。
联想iCache的两种应用环境介绍:
iCache在企业中的应用---正向代理缓存(Proxy Cache)
iCache在ICP中的应用---反向代理缓存(Reverse Proxy)
联想iCache在企业中的应用
联想iCache在企业中的部署属正向代理缓存(Proxy Cache)方式：（见图5）
它是将联想iCache部署在企业的局域网中客户机前端，将用户访问过的页面在内存和硬盘中进行缓存，当下一个用户访问同样的页面时，可以直接从本地iCache中调用该Web访问信息,从而大大加快对Internet的访问速度,提高了响应性能；由于减少了对Internet的访问量，节约了宝贵的广域链路带宽（可以降低网络流量25--75%，平均50%），也就可以为企业节省上网费用50%。
另外，由于联想iCache了解用户的兴趣与需求,利用它可以限制和控制用户所访问的内容，提高安全性可管理性。
联想iCache在ICP中的应用：见图6
联想iCache在ICP中的部署属反向代理缓存(Reverse Proxy)形式:
是指为特定的WWW服务器设置iCache，又称Web加速器（Web ccelerator）,它是用来减少WWW服务器要响应的服务请求。这种iCache服务的最大特点就是所缓存的是同一WWW服务器的内容。
以Yahoo为例，当用户发起连接请求时，根据负荷情况，在多个为Y ahoo 的WWW提供加速iCache中选择负荷较低的服务器为用户提供服务，减轻了https://www.doczj.com/doc/8d17390433.html,服务器的负荷，实现负载平衡。值得注意的是https://www.doczj.com/doc/8d17390433.html,仍然是一台服务器，只是到它的连接请求根据负荷被送到其他的Cache服务器。
作为反向加速的iCache,其命中率在90%左右，也就是说，90%的信息可以不用到原Web服务器上获得，直接在Cache中得到。iCache Web加速器可以部署在电信端，成为电信对外提供的一种增值服务，其优势是，突破用户64K DDN专线的带宽限制，相当于租用的电信主干带宽，从而大大提高Web响应速度，大大增加了Web服务器的承受并发连接的能力，相当于对原Web 服务器升级或采用Web阵列等方式提高Web 服务器性能。利用iCache 的Web加速器可以实现Web服务器的镜像，这种实现方式比传统Web镜像方式的优势在于其维护、管理非常方便。
如何有效实现Web缓存
（作者：马昕2001年03月05日 13:25）
Web缓存近来成为各种媒体上频频出现的热门词语，其概念非常简单，就是“一次取来，多次使用”。具体来说，是当网络上的用户要求Web服务时，缓存服务器代表用户向源Web服务器发出请求。反过来，源服务器将响应这一请求的Web对象连同头信息一起发送给缓存服务器，头信息中包含有关于缓存的重要信息，比如这一对象是否能够缓存，可缓存多长时间等。如果该对象可被缓存，Web缓存就将它保留在局域网的本地服务器中，以便下次本地用户要访问同一Web对象时，可直接到本局域网的缓存服务器中取得，从而减少了广域网的流量，加快了用户访问Internet的速度。不过当有新请求到来时，Web缓存检查缓存对象的存在时间，同时利用收到的头信息来判断缓存内容是否过期，或判断缓存内容自上次请求后是否更改。
很清楚，Web缓存是一个实用的、有效率的概念，但在应用此技术之前，需要考虑如下问题：这个技术将会怎样影响网络配置？怎样处理由此带来的单点故障？
代理自动配置方式
目前有两种广泛使用的实现Web缓存的方法：带缓存功能的代理和透明缓存。第一种方法和通常所用的代理服务是完全一样的，只是Web 内容存在代理服务器本地的硬盘或RAM中。很多代理服务器同时还缓存FTP、Gopher以及NNTP（Network News Transfer Protocol）的内容。所有基于代理方式的技术都有一个共同的缺陷，就是所有的客户机都需要单独配置，来指明代理服务器的地址，从而将请求发给特定的代理服务器。这一缺陷在过去是难以忍受的，但是现在随着代理自动配置URL （Proxy Automated Configuration，PAC）技术的引入，这一代理服务固有的缺点正逐渐被克服。
当使用PAC URL时，所有浏览器在启动的时候都访问由PAC URL指定的一个文件，此文件中含有HTTP的代理配置信息。这一方法可以使关于代理的任何变化很快地在整个网络中传播，而不用单独配置每一个客户机。当网络中有问题存在时，可以很容易地通过代理配置信息的改变绕开故障点，保证用户对网络的实时访问。虽然这一方法非常奏效，但是仍然需要花时间来指示每一客户机经由PAC URL寻找配置信息。同过去相比，这一工作已经非常简单明了。同时，Web代理自动发现协议（Web Proxy Autodiscovery Protocol，WPAD）的引入，更加简化了在PAC－URL网络中对于代理服务的配置。
缓存透明方式
透明的缓存要比基于代理的缓存更方便，但也有一个不足之处。在采用透明缓存的网络中，缓存装置截取所有通向外部的网络流量，包括HTTP。因为所有的HTTP流量都经过Web缓存，所以用户不需要在客户端
进行单独配置来指示Web流量如何流向代理服务器。
有三种标准的放置缓存设备的方法：或作为以太网桥，或作为网络的缺省网关，或通过使用像Cisco系统授权的Web 缓存控制协议 (Web
Caching Control Protocol，WCCP)来透明地截取路由器或交换机流量，
根据你的网络结构可选择一种最佳方式。
透明缓存的优点在于不需要在客户端做单独配置来指明代理服务器的地址，这对大型ISP和企业环境非常合适。但缺点也很明显， Web客
户无法避免Web 缓存的单点故障，甚至无法检测到故障的发生，并且除
HTTP外的其他网络流量也会受影响。
容错机制的引入
如果采用透明缓存，当缓存服务器失败了，所有的网络流量就无法送出。因此，为了检测错误并且在错误出现的时候重定向网络流量，必
须引入容错机制。
一些厂商采用不同的容错机制，最常用的是 Novell的Internet 缓存系统（Internet Caching System，ICS）和InfoLiria的DynaCache。
ICS实质是采用集群技术，系统配备多个ICS，这些ICS互相交换信息，
当其中一个ICS失败时，另外的ICS可以接管它的工作，对用户来说就
像错误没有发生一样。
另一个容错机制是利用独立的硬件，分别设立原设备和错误恢复设备，在其中运行私有协议。在原设备发生故障之后，协议可以将网络流
量重定向到错误恢复设备，从而达到容错目的。InfoLibria的DynaCache
就是采用的这种方式。
尽管ICS和DynaCache有诸多优点，它们仍不能提供出一个完整的对用户透明的容错结构。ICS群中的一个失败将会使传输中断一段时间，
并且InfoLibria的解决方案也是不能完全避免服务中断的困扰。
放到第四层上去解决
另一个可能的解决方案是使用一个4层交换机来完成Web缓存负载均衡的应用。WebSystems等许多公司都具有这种交换机，它们能监测缓
存应用的状态且能绕开失败点指示出网络流量的新通路。除有极强的容
错性能外，它们在使用缓存高峰时还提供负载均衡的能力来提高其性能。
利用Ｗｅｂ交换技术优化因特网结构
中国数据网
1 引言
随着越来越多的用户加入到Ｉｎｔｅｒｎｅｔ这个全球网络中来，人们在网上的活动也正在变化，从信息收集发展到购物、娱乐以及进行各种商业交易。面对不断增加的负载和新的应用需求，网上业务的提供者需通过架构新的体系结构以适应其业务的增长，Ｗｅｂ交换机应
运而生，为数据中心设备包括互联网服务器、防火墙、高速缓存服务器、网关等提供管理、路由和负荷分担。
除了提供可由传统第二、三层交换机提供的连接和打包路由服务外，Ｗｅｂ交换机还可提供传统局域网交换机和路由器所不能提供的服务器负载均衡、存取控制、ＱｏＳ保证及带宽管理等功能，可在应用层为运营商提高性能，增强安全性、可用性和扩充能力。Ｗｅｂ交换机又称第四层交换机，目前Ｗｅｂ交换技术已由纯粹的传输层（第四层）发展到具有基于内容（第七层）交换的智能，这种技术在新一代Ｉｎｔｅｒｎｅｔ中将会具有更广泛的应用。２Ｉｎｔｅｒｎｅｔ发展的新要求
２．１Ｗｅｂ服务器集群
以单台服务器处理Ｗｅｂ服务的结构已渐成历史，现在通常是以多台服务器联合支持一个网站，并以一个单一的虚拟ＩＰ地址（ＶＩＰ）代表整个服务器集群，由集群中的多台服务器来分摊处理访问流量。这种结构使得某台服务器发生故障时，不影响Ｗｅｂ服务的继续工作，同时通过增加更多的服务器可以平滑地提升Ｗｅｂ服务的性能，具有较高的扩展性，这样在服务器之间起引导传输作用的负载均衡器就成为必需。负载均衡器截取进入ＶＩＰ的客户端请求，并将请求分配给相对性能最佳的服务器。
Ｗｅｂ服务器的虚拟化也带来了内容管理方面的挑战。如果同一个网站的服务器都能为任意请求提供服务，那么这些服务器就必须存取整个网站的内容，这在Ｉｎｔｅｒｎｅｔ发展的今天几乎是行不通的。而且，服务器功能的专业化（如专门内容存储和专门从事计算）也使内容的分离势在必行，如动态内容最好存放于经过优化后适于运行Ｓｃｒｉｐｔｓ和Ｊａｖａａｐｐｌｅｔｓ的高性能服务器，而图片、样板文件、视频剪辑文件等静态内容可以存放于具有较大存储容量的低档服务器，以降低成本。
２．２Ｗｅｂ用户的虚拟化
在有代理服务器、防火墙、ＶＩＰ的服务器集群中，ＩＰ地址的简单的一一对应关系不复存在，这就使ＩＰ用户不能再以其ＩＰ地址作为网络上的唯一识别标识。事实上，由一个用户向同一个地址发出的连续性请求可能代表不同的源ＩＰ地址。这会令持续性（ｐｅｒｓｉｓｔｅｎｓｅ）难以实现。持续性是指把来自每个独立用户的多个请求传递给同一台服务器进行处理，这对于网上购物等应用至关重要。在线应用如购物卡或搜索引擎等应用常常需要持续的处理，这意味着一个客户在一个会话期间要不断地与同一个真实服务器对话，而且可能是由多个ＴＣＰ连接完成。如购物卡，如果一个客户和服务器连接不是持续的，可能导致购物破裂，甚至授权给其他用户。持续性连接有助于提高服务器效率，实现网上购物、多页表格的状态性事物处理。
２．３多媒体应用
现代因特网上多媒体业务发展非常迅速，ＲＴＳＰ（实时流协议）和ＶｏＩＰ（ＩＰ话音）协议在客户端和服务器之间利用不同的通道传送控制信息和数据流，用于数据传送通道的端口号是动态产生的，并通过预先建立的控制通道在客户端和服务器之间通信。为正确将这些应用程序送到适合的服务器，流量管理设备必须解析控制通道传输的内容，以为数据通道析取出动态端口，使相关的控制和数据通道可作为单一的逻辑会话进行处理。
２．４带宽管理
Ｉｎｔｅｒｎｅｔ是各种用户的共享资源，对于网络运营商来说，不同层次地保证不同用户的需求是十分重要的。对于电子商务应用而言，能否确保其Ｉｎｔｅｒｎｅｔ带宽至关重要，如果一个商业网站和影视站点共享Ｗｅｂ托管资源，它就要避免共享的路由器链路被大量视频下载所阻塞，或者是需实时传送的业务（如ＩＰＰｈｏｎｅ）通道被大量静态数据传送所挤占。这种需求引发了服务质量（ＱｏＳ）技术。作为多台服务器连接Ｉｎｔｅｒｎｅｔ的接入口，需要在内容源头上实施ＱｏＳ控制，严格的ＱｏＳ控制需要能够测量、记录、控制各Ｗｅｂ站点的带宽使用、目前登录用户、服务内容等能力，即具有带宽管理能力。
３Ｗｅｂ交换对网络性能的改善
为解决Ｉｎｔｅｒｎｅｔ发展所带来的新问题，基于第四层交换技术的Ｗｅｂ交换机应运而生。Ｗｅｂ交换机完成连接建立，按应用或内容标识解析流量，运用服务器选择算法，监视服务器的健康状态和性能，测量和控制服务器的带宽使用，完成流量过滤和网络拓扑更新等。
３．１提高服务器利用率
在会话过程中，服务器会将最近使用过的资料存储于内存中，在本机内存中存取资料要比在后台数据库或硬盘存取资料快得多，具有内容智能交换功能的Ｗｅｂ交换机可发送具有相同网络跟踪器的成功请求到同一台服务器，利用服务器高速缓存提高服务器的效率和性能。在使用高速缓存服务器的地方，Ｗｅｂ交换机对进入的客户端请求具备智能过滤能力，可避免将不相关的请求传递给高速缓存服务器。如动态内容请求、具备内嵌网络跟踪器的请求等可直接转发到所请求的服务器，以减少缓存服务器上不必要的负载。
３．２灵活分配服务内容
Ｗｅｂ交换机通过检验网络请求的ＵＲＬ，可确定受请求内容的类型，并将该请求转发到存放该请求ＵＲＬ的服务器，这样，网站内容可在不改变应用程序的前提下被分离，使得每台服务器只需拥有部分的而不是全部的网站内容，这使得经营者可以使用专用于特定内容类别或处理功能的服务器。
３．３支持持续性连接
"购物车"、付款交易、搜寻显示及多页表格等应用程序需要持续性的连接。目前将多个连接匹配到同一个用户的可靠方式是匹配内嵌于非加密的ＨＴＴＰ连接的"网络跟踪器"（Ｃｏｏｋｉｅ），或内嵌于安全ＨＴＴＰ－Ｓ会话的"ＳＳＬ会话识别器"（ＳＳＬＩＤ），具有这一解析内容能力的Ｗｅｂ交换机能将来自统一用户的连续性请求准确地与同一台服务器联系起来，实现会话的完整性。
３．４优先级别服务及带宽管理
Ｗｅｂ交换机可通过识别"网络跟踪器"为不同的用户类别提供不同优先级的服务，同样，也可通过对ＵＲＬ的识别，为在传送不同的内容类别时分配适当的带宽。如果对内容不敏感，传输分类及服务质量只可根据ＩＰ地址或应用端口等在初级层次进行。
３．５虚拟主机的支持
虚拟主机通过同一个ＩＰ地址代表多个域名，当Ｗｅｂ交换机收到客户端对共用ＩＰ地址的请求时，可从ＨＴＴＰ包头的"主机包头"部分析出请求的域名，然后将其与ＩＰ地址配合，以取得唯一的主机识别资料，并将请求转发到适当的服务器。
４Ｗｅｂ交换机体系结构
目前有三种不同的Ｗｅｂ交换机设计方案：集中式ＣＰＵ模式、分布式处理系统和二级混合模式。
４．１集中式模式
集中式模式是将控制和交换部分置于一个中央处理器（ＣＰＵ）上，这是典型的２／３层交换机采用的结构，可以用软件方法将处理程序加载到系统中。第２／３层交换机的交换部分可能在端口级具有分布特性，但在数据包对应的会话连接，包括网络地址转换、ＴＣＰ连接绞合等，必须由中央处理器处理后才能由交换部分传送。
这种模式特别适合访问流量从单一端口（如广域网连接）进入的拓扑结构，交换机所有的处理能力和内存被集中起来处理该端口流量。但当会话流量负载很重，或流量从多个端口进入时，所有的会话处理，甚至简单的包交换都得经过中央处理器时，中央处理器很易成为瓶颈。这种结构缺乏扩展性，只适合预计流量较少和只需简单流量管理的环境。
４．２分布式模式
另一种交换机结构是采用基于端口的分布式处理模型。在这种结构中，每个端口都有与之相连的控制和交换部分，其控制和交换部分之间的"距离"几乎为零，所有功能都能在端口本地完成，业务处理速度很快，这种设计适合会话流量从多个端口进入的拓扑环境。但在超过端口处理能力时，一个端口不能利用其他端口的资源，这使得每个端口的成本较高，因为理论上每个端口必须有足够的内存处理进入端口的所有流量；同时，一个端口不能利用其他端口上的信息进行流量决策，会导致某些内容处理的混乱，如访问流量最初进入Ｗｅｂ交换机的某个端口，而后由于拓扑结构的变化导致随后的流量进入其他端口，相邻处理器不能共享会话状态信息，已建立的会话连接将一直持续下去。
４．３二级混合模式
鉴于上述两种结构的缺陷，自然提出了一种折衷方案，就是二级混合模式，这种体系结构将所有控制部分集中在一个中央处理器，同时让每个端口有自己的传递部分，这样Ｗｅｂ交换机能适应网络的拓扑变化，共享控制部分的信息，不需要或很少需要中央处理器的介入，就能执行基于端口的交换。
这种架构的实现方案实际上是将属于第四层的会话交换部分（包括简单网络和ＴＣＰ端口地址转换）分发到各端口处理，而将属于第七层的ＴＣＰ连接集中由中央处理器完成。
这种结构的效率和ＣＰＵ部分可处理的各端口提交的控制处理任务数及ＣＰＵ处理能力有关。在大会话流量和复杂控制的情况下，控制处理器和连接中央控制部分的总线可能会成为潜在的瓶颈。据此，有些厂商提出了所谓虚拟矩阵体系结构（ＶＭＡ），通过将大量网络处理器直接集成在高吞吐能力的交换矩阵上，使得由软件控制的处理和各端口由硬件组成的交换引擎可以直接协同完成Ｗｅｂ交换。
５利用Ｗｅｂ交换技术提升网络性能
具有第四层交换功能的Ｗｅｂ交换机在因特网上可以有很多具体应用，如ＷｅｂＳｅｒｖｅｒ的负载分担、认证服务器（ＲＡＤＩＵＳＳｅｒｖｅｒ）的负载、防火墙负载分担、全透明缓存、域名服务器（ＤＮＳＳｅｒｖｅｒ）的负载分担、函件服务器（ＭａｉｌＳ
ｅｒｖｅｒ）的负载分担等，具体应用因实际网络结构而异，在此仅以一个简单的ＷｅｂＳｅｒｖｅｒ负载分担为例说明其应用。
目前Ｉｎｔｅｒｎｅｔ上广泛使用的ＷｅｂＳｅｒｖｅｒ（如ＡｐａｃｈｅＨＴＴＰＳｅｒｖｅｒ ＭｉｃｒｏｓｏｆｔＩｎｔｅｒｎｅｔＩｎｆｏｒｍａｔｉｏｎＳｅｒｖｅｒ ＮｅｔｓｃａｐｅＥｎｔｅｒｐｒｉｓｅＳｅｒｖｅｒ等），采用的是多进程技术，占用资源较多，一般一台ＷｅｂＳｅｒｖｅｒ只能承受几百个并发用户。解决其扩展性问题，传统的方法是增加多台ＷｅｂＳｅｒｖｅｒ，采用ＤＮＳＲｏｕｎｄＲｏｂｉｎ方式在ＷｅｂＳｅｒｖｅｒ群之间实现负载分担。采用ＲｏｕｎｄＲｏｂｉｎ方式存在着缺陷：
１．可靠性不足
当某台ＷｅｂＳｅｒｖｅｒ不能提供服务时，ＤＮＳＳｅｒｖｅｒ不能发现，仍然按ＲｏｕｎｄＲｏｂｉｎ方式把用户的ＨＴＴＰ请求平均分配到服务器群，导致某些用户不能得到Ｗｅｂ服务，影响系统服务质量。
２．负载分担不能实现
在性能不同的ＷｅｂＳｅｒｖｅｒ之间平均分配请求，显然会造成性能低的设备成为瓶颈，而性能高的设备得不到充分使用；即使是在性能相同的设备之间平均分配请求，也会造成负荷不均，因为ＷｅｂＳｅｒｖｅｒ对每个不同请求返回的数据量不同。
ＷｅｂＳｗｉｔｃｈ监测服务器的可用性，包括物理连接、ＷｅｂＳｅｒｖｅｒ主机等性能状况，当发现某台服务器不能提供服务时，自动将Ｗｅｂ请求分配到另两台服务器上。同时依靠设置每台ＷｅｂＳｅｒｖｅｒ能承受的最大会话数、设置溢出ＷｅｂＳｅｒｖｅｒ、备份ＷｅｂＳｅｒｖｅｒ等手段进一步保证系统的可靠性。现有第四层交换机主要用ＬｅａｓｔＣｏｎｎｅｃｔｉｏｎ、ＲｏｕｎｄＲｏｂｉｎ、ＭｉｎＭｉｓｓ和Ｈａｓｈ等负载分担算法，以解决负载分担。
对某些跨国大型ＩＳＰ，其ＷｅｂＳｅｒｖｅｒ可能不在一个局域网内，也可利用ＷｅｂＳｗｉｔｃｈ的ＧｌｏｂａｌＢａｌａｎｃｅ技术进行广域网范围的平衡。
1、全页面静态化缓存 也就是将页面全部生成html静态页面，用户访问时直接访问的静态页面，而不会去走php服务器解析的流程。此种方式，在CMS系统中比较常见，比如dedecms; 一种比较常用的实现方式是用输出缓存： Ob_start() ******要运行的代码******* $content = Ob_get_contents(); ****将缓存内容写入html文件***** Ob_end_clean(); 2、页面部分缓存 该种方式，是将一个页面中不经常变的部分进行静态缓存，而经常变化的块不缓存，最后组装在一起显示;可以使用类似于ob_get_contents的方式实现，也可以利用类似ESI之类的页面片段缓存策略，使其用来做动态页面中相对静态的片段部分的缓存(ESI技术，请baidu，此处不详讲)。该种方式可以用于如商城中的商品页; 3、数据缓存 顾名思义，就是缓存数据的一种方式;比如，商城中的某个商品信息，当用商品id去请求时，就会得出包括店铺信息、商品信息等数据，此时就可以将这些数据缓存到一个php 文件中，文件名包含商品id来建一个唯一标示;下一次有人想查看这个商品时，首先就直接调这个文件里面的信息，而不用再去数据库查询;其实缓存文件中缓存的就是一个php数组之类; 4、查询缓存 其实这跟数据缓存是一个思路，就是根据查询语句来缓存;将查询得到的数据缓存在一个文件中，下次遇到相同的查询时，就直接先从这个文件里面调数据，不会再去查数据库;但此处的缓存文件名可能就需要以查询语句为基点来建立唯一标示; 5、按内容变更进行缓存 这个也并非独立的缓存技术，需结合着用;就是当数据库内容被修改时，即刻更新缓存文件; 比如，一个人流量很大的商城，商品很多，商品表必然比较大，这表的压力也比较重;我们就可以对商品显示页进行页面缓存;当商家在后台修改这个商品的信息时，点击保存，
JSP页面缓存技术浏览器缓存 一、概述 缓存的思想可以应用在软件分层的各个层面。它是一种内部机制，对外界而言，是不可感知的。 数据库本身有缓存，持久层也可以缓存。（比如：hibernate，还分1级和2级缓存）业务层也可以有缓存（但一般来说，这是一个过程域，不会设缓存）。 表现层/数据服务层（传统web的表现层）也可以设置缓存（jsp cache 就是这一层，实现在app server上的缓存机制） 另外Browser也有缓存（如IE）这个大家也都知道（实现在web server 上的缓存机制）。越上层的缓存效果越好，越底层的缓存影响越深远。 二、缓存实现（浏览器缓存当前访问的JSP动态页面） （一）、服务端方法： <％ response.setHeader("Pragma","No-cache"); response.setHeader("Cache-Control","no-cache"); response.setDateHeader("Expires", -10); ％> （二）、客户端方法： meta是用来在HTML文档中模拟HTTP协议的响应头报文。meta 标签用于网页的＜head＞与＜/head＞中，meta 标签的用处很多。meta 的属性有两种：name和http-equiv。name 属性主要用于描述网页，对应于content（网页内容），以便于搜索引擎机器人查找、分类（目前几乎所有的搜索引擎都使用网上机器人自动查找meta值来给网页分类）。这其中最重要的是description（站点在搜索引擎上的描述）和keywords（分类关键词），所以应该给每页加一个meta值。比较常用的有以下几个： name 属性 1、＜meta name="Generator" contect=""＞用以说明生成工具（如Microsoft FrontPage 4.0）等； 2、＜meta name="KEYWords" contect=""＞向搜索引擎说明你的网页的关键词； 3、＜meta name="DEscription" contect=""＞告诉搜索引擎你的站点的主要内容； 4、＜meta name="Author" contect="你的姓名"＞告诉搜索引擎你的站点的制作的作者； 5、＜meta name="Robots" contect="all|none|index|noindex|follow|nofollow"＞ 其中的属性说明如下： 设定为all：文件将被检索，且页面上的链接可以被查询； 设定为none：文件将不被检索，且页面上的链接不可以被查询； 设定为index：文件将被检索； 设定为follow：页面上的链接可以被查询； 设定为noindex：文件将不被检索，但页面上的链接可以被查询； 设定为nofollow：文件将不被检索，页面上的链接可以被查询。 http-equiv属性 1、＜meta http-equiv="Content-Type" contect="text/html";charset=gb_2312-80"＞ 和＜meta http-equiv="Content-Language" contect="zh-CN"＞用以说明主页制作所使用的文字以及语言；又如英文是ISO-8859-1字符集，还有BIG5、utf-8、shift-Jis、Euc、Koi8-2等字符集； 2、＜meta http-equiv="Refresh" contect="n;url=http://yourlink"＞定时让网页在指定的时间n
页面缓存 1前言 页面缓存一直是前端开发中我们关注比较少的，研究了一些资料，总结了一些心得，记录下来共同探讨。 合理的页面缓存可以让页面执行的效率提高很多（在第一次访问或者CTRL+F5强制刷新的时候，缓存的效果是体现不出来的），而不是我们一味的设置cache-control为no-cache。 当然了如果缓存使用不当，也会带来麻烦，比如缓存参数设置不合理，会导致请求得到的是旧的页面元素。 2缓存原理 首先一开始我们要明确页面缓存的原理以及过程。 缓存的原理大体是在浏览器对资源的第一次请求之后，把资源中的一部分存储在计算机的临时文件空间，再次请求的时候，按照特定的策略加载缓存的资源，减少HTTP请求次数与传输数据量，以此提高浏览效率。 以下是一个请求的过程讲解。 2.1 第一次请求 打开一个浏览器如IE，这时候浏览器会对自身设置的参数进行加载，其中就包括缓存设置参数。 接下来我们在地址栏输入一个url，这时候浏览器会发送一个简单的HTTP请求报文头给应用服务器，这个报文头主要包含的信息是请求的url，接受的编码约定，缓存控制等信息。 典型的请求报文头：
服务器接受到了请求报文头，一堆业务处理完毕之后，会给出HTTP响应报文，响应报文格式分为报文头和报文体，响应报文头中的信息是很重要的，我们以一个图片响应报文头为例讲解相关内容： 这个响应报文头可以看到以下信息： 响应状态码是200，说明是正确返回。 cache-control设定了有效时间，在这个时间内新打开新网页（或者地址栏回车）不 需要去请求服务器。 报文内容类型是image/gif。 最近修改时间是2008-7-30 10:23:00，最近修改时间在浏览器刷新的时候有很大的 用处，浏览器刷新的时候，会发送对该图片请求的报文，得到的响应报文中如果最 近修改时间和缓存的一致，那么浏览器将会从缓存中读取该图片的信息（状态码是 304），如果两个时间不一致，会从服务器请求得到最新的文件，并缓存。 服务器类型等其他信息。 该响应报文接受到之后，浏览器解读报文体内容，并打开显示给用户，这是主要的工作。 除此之外，浏览器还根据报文头的信息，确定一些缓存规则，比如no-cache的不缓存，设置了max-age的再次打开不请求等，更多的信息可以参考三、四章节。 2.2 再次请求 再次请求的时候，才是缓存显现身手的时候。 还是以上面请求的那个图片（设置了max-age）为例。
通过百度优化建议检测网站，出现设置静态内容缓存时间这一项。有很多页面，比如FAILED - (未设置max-age或expires) –https://www.doczj.com/doc/8d17390433.html,/提示“变化很少的静态资源可以设置客户端缓存时间，减少请求”，这个怎么设置呢？ 我们的网站中往往包含大量的页面组件，比如图片、样式表文件、JS脚本文件和Flash动画。这些组件的变化频率非常低，尤其是那些构成网站基本框架的组件，几乎不会发生变化。我们可以将这些变化率很低的组件看作静态内容，并且通过max-age或expires标识设置缓存过期的时间，以便下次更快的访问，节约带宽资源，节省服务器资源、提高用户体验等。 apache配置：
如何清理浏览器缓存 一、为什么要清理浏览器缓存； 因为客户管理系统与资源管理系统统一采用的是EXTJS富客户端的开发技术，这种技术的好处是一次加载以后会在浏览器中保存一个缓存文件，当下次再次登陆系统的时候就无需再次向服务器进行页面文件请求。这样就能很大的提高相应速度和减少服务器压力。但是任何技术都不是完美的，EXTJS也存在天然的制约性，就是当页面已经更新的时候需要手动清理缓存，重新将新的内容缓存到浏览器。 二、如何清理缓存； 2.1谷歌（Google）浏览器： 2.1.1清除当前页面缓存： 在当前页面空白处，鼠标右键选择“重新加载框架”。如图一所示：
（图一） 2.1.2清除浏览器全部缓存： 1)在浏览器的右上角先单击“自定义及控制”按钮，在弹出来的菜单中选 择“历史记录（H）”或者直接快捷键“Crtl+H”; 2)在弹出来的页面中选择“清除浏览数据...”; 3)在弹出的新窗体中选择“清除浏览数据”按钮，清理浏览器的缓存；如 图二、三、四所示。
(图二) （图三）
（图四） 2.2火狐（FireFox）浏览器； 2.2.1清除当前页面缓存： 在当前页面空白处，鼠标右键选择“此框架(H)”。然后选择“重新加载框架(R)”，如图五所示：
(图五) 2.2.2清除浏览器全部缓存： 1)在浏览器左上角点击“FireFox”按钮； 2)在弹出来的菜单中选择“历史”； 3)选择“清除最近的历史记录....”; 4)选择“立即清除”。如图六、图七所示。
(图六) （图七） 2.3IE（Internet Explorer）浏览器； 2.3.1清除当前页面缓存： 在页面的空白位置，使用鼠标右键，在弹出来的菜单中选择“刷新”;
一、说明 随着网站访问量的不断攀升，网站的负荷也不断上升，数据库负荷变化尤其明显，特别是在访问的高峰期，用户浏览器页面显示很缓慢，长时间连一个文本页面都显示不出来，最差的情况是网站直接崩溃，严重的影响了用户的体验，降低了网站的粘性。这个时候，是一定要考虑搭建web缓存服务器的时候了。 我们选择的是一款Fikker 网站加速产品作为参考示例。根据官方的介绍，Fikker 是一款完全基于高速内存的缓存加速产品，无缓存文件生成，支持跨平台（windows和linux），在V3.2.4 之前还没有看到提供对freeBSD 操作系统的支持，我们使用它的免费版本做为示例。搭建web缓存服务器的目的：除了降低网站服务器的负荷和加快页面显示外，还可以隐藏源站，进行流量统计和实时监控，甚至是防盗链等等，最重要的是整个过程不需要修改已有网站程序的源码，全界面化的web缓存配置操作。 二、准备阶段 这个阶段我们先到Fikker 的官方网站下载它，我们下载和使用的是CentOS Linux 版本，不管是Linux 还是Windows 版本，整个安装和配置过程非常类似。我们将下载后的安装包fikkerd-3.2.4-linux-x86.tar.gz 放在/home/meng 下面，通过命令行进行解压： tar zxvf fikkerd-3.2.4-linux-x86.tar.gz 三、配置阶段 1、根据Fikker 安装说明，到了这个阶段，我们可以进行相关的配置了，目前Apache 已经在占用80 端口，为了安全起见，我们先测试后实施，我们现将Fikker 的默认端口80 改成8080，这样子我们就可先将Fikker 配置和测试完成后，再让其投入实际服务当中去，不会对原有的网站有任何影响。首先修改config 目录下面的fikkerd.ini 配置文件（命令行为：vi fikkerd.ini），如下：
在https://www.doczj.com/doc/8d17390433.html,中使用模式dialog时，你会发现每次打开的页面都是相同的内容，页面内容并没有刷新，这是缓存的原因造成的， 解决方法如下： 第一种是https://www.doczj.com/doc/8d17390433.html,清除页面缓存 Response.Buffer = true; Response.ExpiresAbsolute = System.DateTime.Now.AddSeconds(-1); Response.Expires = 0; Response.CacheControl = "no-cache"; Response.AddHeader("Pragma", "No-Cache"); 第二种是HTML方法
第三种是重新调用原页面的时候在给页面传一个参数: href="****.ASPX?random()" 最后一种是在在页面中禁用缓存 在web开发中合理使用缓存可以有效的提高网站的性能，但是在某些场合下因为缓存的存在会带来很多的问题。 例如：因为缓存的存在会造成重复提交数据的问题，验证码图片不能正确显示的问题，等等。这个时候我们就要禁用页面缓存的功能。 我们常用的做法是发送一个“no-cache”的指令，但是实际使用过程中我们发现，这个指令对IE是有效的，但是对Firefox却没有效，这是因为，使用该指令Firefox不缓存HTTPS pages 但是还是会缓存HTTP pages ，这是Firefox的一个BUG，解决的办法很简单，就是使用no-store代替no-cache，同时发送no-store和no-cache指令https://www.doczj.com/doc/8d17390433.html,中的处理方法，在不需要缓存的页面中添加如下代码 Response.Cache.SetCacheability(System.Web.HttpCacheability.NoCache); Response.Cache.SetNoStore();过去几年中，Web应用程序已经从简单的HTML页面堆积演变成使用各种各样的技术构建高可扩展性和交互式的富应用程序。设计和开发这类应用程序变得越来越复杂，此外，决策者正越来越多地寻求构建更丰富的互动功能到这些应用程序中，同时还要保证可维护性和高性能，但高性能意味着高成本。为了构建提供给最终用户体验的是一个牢固的应用程序，开发人员需要解决潜在的性能瓶颈。 本文侧重于缓存——它是交付高性能Web应用程序急需的——也简要介绍一下压缩功能。有一些公司在生产和销售专门的压缩和性能产品。本文旨在简单介绍在寻求专业产品解决性能问题之前开发人员可以在客户端和服务器端对Web应用程序做的一些性能改进。 性能瓶颈 性能瓶颈主要体现在高延时、拥塞和服务器负载。缓存不能完全解决掉这三个问题，但经过详细的设计考虑，缓存是可以提高性能的。在服务器端和客户端都缓存内容，据调查，平均而言，下载HTML只需要总的用户响应时间的10-20%，剩下的80-90%全部用于下载页面中的其它组成内容，这些组成内容通常包括图像，如公司logo，缓存logo可以有效避免到服务器的多次往返。在前日51CTO上发布的加速，加速，再加速：来自Google的网
站加速技巧大全中，Google提到的提升网站速度和性能的低成本技巧中就包括缓存这一条。至于架构设计方面，则可参考51CTO的视频专题：大型网站架构专家谈。 简单地讲，缓存是临时存储。它将数据复制到不同的计算机或不同于原始数据源的位置，有了正确的配置，访问缓存数据的速度比访问原始数据的速度要快得多，使用缓存数据可以减小服务器负载和带宽消耗，从最终用户的角度来看就是性能提高了。 图1显示了Internet如何工作的快速总揽，以及缓存在哪里发生作用。
页面js数据缓存 将js数据比如ajax请求来的数据缓存起来是很早就开始做的事情，原来是用一个全局变量__data来存储，现在基于jquery写的两种实现方式。cache这种方式是很普遍的一种实现方式，icache是将数据缓存到dom中，在使用的过程中依赖json.js可以缓存多种类型的数据。cache和icache有一个差别是icache需要检验key和value，这是因为将数据写入dom时需要将不同类型的数据先转换为字符串，这也是可能需要json.js的原因。 /** * cache. * page data cache in cache. */ (function($) { $.cache = {}; $.extend($.cache, { map : {}, push : function(key, value) { $.cache.map[key] = value; },
remove : function(key) { delete($.cache.map[key]); }, clear : function() { $.cache.map = {}; }, get : function(key) { return $.cache.map[key]; } }); })(jQuery); /** * icache. * page data cache in dom. */
(function($) { $.icache = {}; $.extend($.icache, { validStr : function(str) { return typeof(str) == 'string' ? true : false; }, data : { containerId :'icacheContainer' }, enable : function() { if ($('#' + $.icache.data.containerId).length != 0) return; var container = $('
/** *作者：张荣华 *日期：2007-9-26 **/ 关于缓存的话题，在坛子里已经有很多讨论，简单的来说，如果一个应用中80%的时间内都在访问20%的数据，那么，这时候就应该使用缓存了。这个和长尾理论正好相悖，其实也不是相悖，只是不同的理论使用的场景不同。在80/20原则生效的地方，我们都应该考虑是否可以使用缓存。但即使是这样，缓存也有不同的用法，举个例子，一个网站的首页估计是被访问的次数最多的，我们可以考虑给首页做一个页面缓存，而如果在某个页面上，比如 （假设javaeye是使用hibernate，说javaeye的java版区只有前几个页面是访问最频繁的， 当然这只是假设，我们都知道javaeye是使用ror开发的）那么我们就可以考虑给java版区的record做二级缓存了，因为二级缓存中是按照对象的id来保存的，所以应该来说这前面几页使用的对象会一直存在于缓存之中（如何使用hibernate的二级缓存坛子上也有介绍）。由此可见不同的页面的缓存策略有可能有天壤之别。 本文的目的就是上面所讲的两种情况之一，页面缓存。毫无疑问，几乎所有的网站的首页都是访问率最高的，而首页上的数据来源又是非常广泛的，大多数来自不同的对象，而且有可能来自不同的db，所以给首页做缓存是一个不错的主意，那么主页的缓存策略是什么样子的呢，我认为应该是某个固定时间之内不变的，比如说2分钟更新一次。那么这个缓存应该做在什么地方呢，让我们来看一下，假设您的应用的结构是page-filter-action-service-dao-db，这个过程中的-的地方都是可以做缓存的地方，根据页面缓存的特征，应该把页面缓存做到尽量靠近客户的地方，就是在page和filter之间，这样的优点就是第一个用户请求之后，页面被缓存，第二个用户再来请求的时候，走到filter这个请求就结束了，无需再走后面的action-service-dao-db。带来的好处是服务器压力的减低和客户段页面响应速度的加快。 那么我们来看一下如何使用ehcache做到这一点。 在使用ehcache的页面缓存之前，我们必须要了解ehcache的几个概念， 1 timeToIdleSeconds，多长时间不访问该缓存，那么ehcache就会清除该缓存。 2 timeToLiveSeconds，缓存的存活时间，从开始创建的时间算起。 看到这里，我们知道，首页的页面缓存的存活时间，我们定的是2分钟，那么也就是说我们的timeToLiveSeconds应该设置为120，同时我们的timeToIdleSeconds最好也设置为2分钟，或者大于2分钟。我们来看一下下面这个配置，这个配置片段应该放到ehcache.xml 中： web常用的常用缓存技术有哪些？此贴一网打尽！ 1、Opcode缓存 首先php代码被解析为Tokens，然后再编译为Opcode码，最后执行Opcode码，返回结果；所以，对于相同的php文件，第一次运行时 可以缓存其Opcode码，下次再执行这个页面时，直接会去找到缓存下的opcode码，直接执行最后一步，而不再需要中间的步骤了。2、内存式缓存提到这个，可能大家想到的首先就是Memcached；memcached是高性能的分布式内存缓存服务器。 一般的使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度、 提高可扩展性。它就是将需要缓存的信息，缓存到系统内存中，需要获取信息时，直接到内存中取；比较常用的方式就是key–>value方式； <?php $memcachehost = '192.168.6.191'; $memcacheport = 11211; $memcachelife = 60; $memcache = new Memcache; $memcache->connect($memcachehost,$memcacheport) or die ("Could not connect"); $memcache->set('key','缓存的内容'); $get = $memcache->get($key); //获取信息 ?>复制代码3、php APC缓存扩展Php有一个APC 缓存扩展，windows下面为php_apc.dll，需要先加载这个模块，然后是在php.ini里面进行配置： extension=php_apc.dll apc.rfc1867 = on upload_max_filesize = 100M 背景： oscache作为jsp页面缓存，提供了两种模式： 1、缓存整个页面； 2、缓存局部页面。 或许是我本人的了解不足，我发现oscache存在以下问题： 第一种方式使用简单，但是问题就是不能及时刷新，刷新策略不灵活。 而第二种方式虽然灵活，但是修改的jsp文件太多，侵入太大，可读性变差，并且，根据我的理解, 请求从servlet转发到jsp的时候，jsp所需要的一些值已经查出来了，所以就算做了缓存也是没用的。 这个有点难以理解，举个例子来说： show.jsp 2、自定义filter重写CacheFilter，初始化的时候读取配置文件并解析缓存。 3、在doFilter的方法里面，如果请求的uri匹配上了配置文件里面的配置，则调用 CacheFilter的doFilter 走缓存，否则直接放过去，没有缓存。 4、为了能动态刷新缓存，需要判断缓存的最后更新时间与当前时间差是否超出了配置 文件中配置的时间，是的话就刷新，否则不刷新。这个需要自定义刷新策略：写一 个类实现EntryRefreshPolicy接口，并在我们自己的filter初始化的时候，调用 cacheFilter的setExpiresRefreshPolicy设置新的更新策略。EntryRefreshPolicy的 needsRefresh方法传入一个CacheEntry对象，为了将此对象与配置文件中配置的对 应起来，我们需要自定义CacheEntry的key，使key 中包含我们在配置文件中配置 的id。自定义key的生成规则需要重写cacheFilter的createCacheKey方法。具体参 考下面的代码。 5、动态更新的问题：我们在进行了操作之后，希望能刷新相关的缓存资源。比如我 评论了文章，那么可能需要刷新文章这个页面的缓存。这个时候需要手动调用一 下刷新接口，ServletCacheAdministrator. flushGroup(String group), 而如何获取我们已 知的uri的对应的groupName又成了问题，为此还需要自定义group生成的策略：ICacheGroupsProvider接口，并在我们的filter里面调用cacheFilter的 setCacheGroupsProvider方法设置新的组名生成策略。 6、这样一切问题都做好了，只要评论了一个文章，我们只要调用一下刷新的方法 就好了。 详细代码示例： 1、关于配置文件的东东： 改善Web 2.0 应用程序的性能 探秘不同的浏览器端缓存机制 Jian Qiao Sun, 软件工程师, IBM Hua Pin Shen, 顾问软件工程师, IBM 简介：随着Web 2.0 应用程序的出现和流行，人们使用Internet 的方式已经悄然改变。现在，这些Web 2.0 应用程序拥有许多典型的特征，包括拥有富客户端、大页面、包含许多小项目的页面、大量的JavaScript 编码等等。鉴于目前的浏览器技术，大部分这些特征都会导致浏览器端性能问题，特别是在长距离网络中。本文将分析典型Web 2.0 应用程序的关键方面，并介绍它们如何影响浏览器端性能。本文还将检查浏览器端性能的一个非常重要的部分——浏览器端缓存。 发布日期： 2010 年2 月25 日 级别：中级 其他语言版本：英文 平均分（共2 个评分） 简介 随着Web 2.0 应用程序的出现和流行，Internet 的使用方式已经发生改变，出现了一种新趋势：针对内容管理、信息共享、通信、团队合作等创建一种更加以用户为中心的方法。从技术角度看，Web 2.0 应用程序并没有带来很多新的技术突破。但是，这些应用程序的确带来了一种新的Internet 使用模式。现在，Web 2.0 应用程序拥有许多典型特征，包括拥有富客户端、大页面、包含许多小项目的页面、大量的JavaScript 编码等等。这些特征会导致浏览器端性能问题，特别是在长距离网络中。这些性能问题会对用户体验造成不利影响，但您甚至不会意识到这些问题的存在。由于开发人员拥有很好的网络条件，因此这些性能问题很难完全暴露出来。 本文将首先分析典型的Web 2.0 应用程序的关键方面，解释它们如何影响浏览器端性能。然后，本文介绍浏览器端性能的一个非常重要的部分——浏览器缓存。通过使用适当的缓存设置，您可以向用户提供较好的应用程序体验。如果您没有一个整体缓存策略设计，那么您的缓存策略不仅会导致低劣的性能，还会引发一些功能缺陷。 有许多影响浏览器缓存的规则，其中的部分规则包括Cache-Control、Etag、Expires、Last-Modified 和Vary。所有这些设置拥有不同的含义和最适用的情形。困难之处在于对于相同的设置，并不是所有流行浏览器都拥有相同的行为。因此，在您决定使用这些设置之前，您应该准确了解这些浏览器是如何工作的。本文将检查目前市面上最流行的浏览器的行为：Internet Explorer、Firefox、Chrome 和Safari。 在本文中，我们还使用IBM? Mashups 和开源“Roller Weblogger” 来提供一些示例，展示如何应用不同的指令以最好地使用浏览器缓存。 背景 在当今的Internet 环境中，Web 2.0 应用程序正在变得越来越流行。许多Web 站点都使用Web 2.0 构建，比如Facebook、Youtube 等。IBM 也有Web 2.0 应用程序，比如Lotus Connections 和Lotus Mashups。 以下是一种用于计算浏览器响应时间的基本方法： ?浏览器响应时间= 服务器端时间+ 页面加载时间+ 浏览器呈现时间 ?页面加载时间= （请求数/ 并发数）* 延迟时间+ 页面总大小/ 带宽 nginx缓存html静态文件,解析php 并反向代理IIS,使nginx和iis共存 server { listen 80; server_name k; #碰到域名为k的就交给iis来运行 location / { proxy_pass http://k:8080/;#我的IIS上面的站点即为http://k:8080 } location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|html|htm|css)$ { #指定缓存文件类型 expires 7d; #设置浏览器过期时间 root a; #所有的缓存文件都会保存在这里html等等,他还会缓存文件夹,所以不用担心覆盖,但是要注意时效性，不然你做了修改他依旧读取缓存,你的网站就没有变化了 proxy_store on; #开启缓存机制 proxy_store_access user:rw group:rw all:rw; #缓存读写规则 proxy_temp_path b; #存放静态文件的缓存目录 #include proxy.conf; # 外联proxy理的详细配置如proxy_set_header，client_max_body_size .... if ( !-e $request_filename) { proxy_pass http://k:8080; } } } server { listen 80; server_name j; #碰到域名j 则直接用nginx来解析 #charset koi8-r; #access_log logs/host.access.log main; location / { root html; index index.html index.htm index.php; }web常用的常用缓存技术有哪些此贴一网打尽
关于定制oscache页面缓存
Http页面缓存机制
nginx缓存html静态页面
相关主题
文本预览