OurApache » 未分类 http://ourapache.com 我们致力于一个Apache知识的分享网站 Tue, 13 Apr 2010 05:18:24 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 网络流量尽在掌控 http://ourapache.com/archives/306 http://ourapache.com/archives/306#comments Sat, 05 Sep 2009 16:17:12 +0000 OurApache http://www.ourapache.com/?p=306 导读:了解网络流量的分布、找到优化网络性能的方法、通过网络管理技术来提升网络效能，同时做好网络流量信息安全方面的防护工作，这是网络流量管理的主要工作内容。

中国移动研究院 李洋博士

近十几年来，互联网得到了飞速发展。据统计，互联网目前已成为人类社会最重要的信息基础设施，占人类信息交流的80%。在这种大背景下，面对日益复杂的网络联机及逐渐增加的网络流量，系统和网络管理者必须花更多时间和精力来了解这些网络设备的运作状况，以维持一个企业网络的正常运作。一般来说，网络管理者需要了解各个网段频宽的使用率、网络问题的瓶颈发生于何处，一旦网络发生问题，必须能够很快地分析和判断出问题的发生原因，这些就是网络流量管理的主要工作内容。那么，管理网络流量的时候应该基于什么样的依据，通过什么手段和策略有效地把流量进行识别、分析和管理呢？

网络流量管理的目标

随着网络流量的不断增长以及网络应用的日趋纷繁复杂化，我们不难看到，简单、无限制地增加网络带宽是不能解决网络流量的根本问题的。我们需要对网络流量进行管理，从而保证网络的健康和网络应用的正常服务。

在网络流量管理的过程中，我们首要的问题就要明确网络管理目标。在网络流量管理主要有4个目标： 首先，我们要了解网络流量的使用情况； 其次，要找到优化网络性能的途径；第三，要通过网络管理技术来提升网络效能；最后，还需要做好网络流量信息安全方面的防护工作。

要达到上述4个目标，网络管理员首先要通过有效的分类方式非常明确地知道，我们需要的带宽到底哪些是实际使用的。其次是找到网络性能的瓶颈。网络性能有两个很重要的指标，一个是吞吐量，即网络能够传输的最大数据量，另一个是延迟等。第三，应用成熟的流量监控及控制软件来提升网络性能，从而满足不同的网络应用需求。最后，网管们还可以综合运用入侵检测系统（IDS）、防火墙、统一威胁管理（UTM）设备来对网络流量进行信息安全方面的防护工作。

在日常的网络流量管理中，为了有效实现网络管理4个目标，我们需要采取相应的步骤。这个步骤包括网络流量捕捉和分类、网络流量监视（统计和分析）和控制策略。

1. 网络流量捕捉和分类：这是进行网络流量管理的第一步。只有通过设置捕捉点，对网络流量进行捕捉和分类，才能进行后续的分析和控制工作。这里特别需要强调的是，网络流量分类可以非常宏观化，也可以细化。比如TCP、UDP、ICMP等分类就比较宏观，而HTTP、FTP甚至是诸如Kazza、Skype等P2P流量的分类和识别就比较细化了。在日常工作中，网络管理员可以采用Wireshark、TCPDump等知名的报文捕捉和分析软件进行流量捕捉和分类工作。

2.网络流量监视（分析）：监视用来显示流量的运行状况，帮助找出问题所在和执行相应的管理策略。应用程序和网络管理能够收集分类、展示和收集信息，包括带宽利用率、活跃的主机和网络效率以及活跃的应用程序。该目标可以通过采用市面上常见的NTOP等可视化分析管理工具来协助网络管理员在实际工作中实现。

3. 控制策略：网络流量分析的下一步是根据优先级别分配带宽资源。分配的依据可以是主机、应用等等，特别需要考虑的是注意将消耗资源的P2P程序或者音频视频下载等进行滞后考虑。具体操作时可以应用流行的流量控制工具来进行和实现，如进行分类监视和控制网络流量，这样，我们就可以将网络流量有效管理起来，将原来无序的网络流量变得有序起来。

以下我们具体介绍如何进行网络流量管理工作，包括网络流量的识别、网络流量的分析和控制。

网络流量的识别

流量识别，也叫业务识别（Application Awareness），是网络流量管理的第一步。网络流量识别通过对业务流量从数据链路层到应用层的报文深度检查分析，依据协议类型、端口号、特征字符串和流量行为特征等参数，获取业务类型、业务状态、业务内容和用户行为等信息，并进行分类统计和存储。业务识别的基本目的是帮助网络管理员获得网络层之上的业务层流量信息，如业务类型、业务状态、业务分布、业务流量流向等。

业务识别是一个相对复杂的过程，需要多个功能模块的协同工作，业务识别的工作过程简单描述如下：

1. 识别处理模块采用多通道识别处理，通过对网络流量的源/目的IP地址和源/目的端口号的Hash算法，将网络流量均匀地分配到多个处理通道中。

2. 多处理通道并行执行网络流量的深度报文检查，获取网络流量的特征信息，并与业务识别特征库中的特征进行比对。

3. 将匹配结果送往识别处理模块，并标识特定网络流量。如果存在多个匹配结果，选取优先级较高的匹配结果进行标识。特定网络流量一经识别确定，该网络流量的后续连接将不再进行深度的报文检查，直接将其网络层和传输层信息与已知识别结果进行比对，以提高执行效率。

4. 识别处理模块将网络流量的业务识别结果存储到识别结果存储模块中，为网络流量的统计分析提供依据。

5. 统计分析模块从识别结果存储模块中读取相关信息，并以曲线、饼图、柱状图或者文本的方式将识别结果信息显示或以文件的形式输出。

6. 在结果存储模块中保存的识别结果信息会输出到网络流量管理功能区，为实施网络流量管理提供依据。

目前常用的业务识别技术有两种，即DPI技术和DFI技术。

DPI技术 DPI是深度报文检测（Deep Packet Inspection）的简称。DPI技术之所以称为“深度”的检测技术，是相对于传统的检测技术而言的。传统的流量检测技术仅获取那些寄存在数据包网络层和传输层协议头中的基本信息，包括源/目的IP地址、源/目的传输层端口号、协议号，以及底层的连接状态等。通过这些参数很难获得足够多的业务应用信息，特别是对于当前P2P应用、VoIP应用、IPTV应用被广泛开展的情况，传统的流量检测技术已经不能满足网络流量管理的需要了。

DPI技术对传统的流量检测技术进行了“深度”扩展，在获取数据包基本信息的同时，对多个相关数据包的应用层协议头和协议负荷进行扫描，获取保存在应用层中的特征信息，对网络流量进行精细的检查、监控和分析。

DPI技术通常采用如下的数据包分析方法：

● 传输层端口分析。许多应用使用默认的传输层端口号，例如HTTP协议使用80端口。

● 特征字匹配分析。一些应用在应用层协议头或者应用层负荷中的特定位置包含特征字段，通过特征字段的识别实现数据包检查、监控和分析。

● 通信交互过程分析。对多个会话的事务交互过程进行监控分析，包括包长度、发送的包数目等，实现对网络业务的检查、监控和分析。

该技术如果进行更加详细的划分，还可分为特征字的识别技术、应用层网关识别技术、行为模式识别技术，这三类识别技术分别适用于不同类型的协议，相互之间无法替代，只有综合地运用这三大技术，才能有效、灵活地识别网络上的各类应用，从而实现控制和计费。

DFI技术 DFI是深度流行为检测（Deep Flow Inspection）的简称，也是一种典型的业务识别技术。DFI技术是针对DPl技术的不足提出的，为了解决DPI技术的执行效率、加密流量识别和频繁升级等问题。DFI更关注于网络流量特征的通用性，因此，DFI技术并不对网络流量进行深度的报文检测，而仅通过对网络流量的状态、网络层和传输层信息、业务流持续时间、平均流速率、字节长度分布等参数的统计分析，来获取业务类型、业务状态。

网络流量的统计分析

通过流量统计分析，网络管理者能够知道当前网络中的业务流量的类型、带宽、时间和空间分布、流向等信息。

在管理的过程中，管理员可以采用常见的NTOP工具来协助完成。NTOP工具与传统的tcpdump或ethereal等网络流量捕捉工具有着极大的差异，它主要是提供网络报文的统计数据，而不是报文的内容。此外，NTOP不需要使用Web服务器，它自身就支持HTTP协议。首先，它提供了一种快速容易的方法来得到网络活动的准确信息，并且不使用网络探测或侦听设备。在大多数情况下，网络探测器对追踪网络故障是必需的，而在某些时候可能因为探测器正被使用于监测其他设备而无法获得，就可以使用NTOP工具；其次，在某些给定的网络配置下可能无法与探测器连接，比如两个通过WAN互连的Unix系统，在这种情况下，用户可以应用NTOP工具。

一般说来，使用NTOP工具可以辅助网络管理员完成以下一些工作： 自动从网络中识别有用的信息； 将截获的数据包转换成易于识别的格式；对网络环境中通信失败的情况进行分析； 探测网络环境中的通信瓶颈； 记录网络通信的时间和过程。

NTOP工具可以通过分析网络流量来确定网络上存在的各种问题，也可以用来判断是否有黑客正在攻击网络系统，还可以很方便地显示出特定的网络协议、占用大量带宽的主机、各次通信的目标主机、数据包的发送时间、传递数据包的延时等详细信息。通过了解这些信息，网管员可以对故障做出及时的响应，对网络进行相应的优化调整，以保证网络运行的效率和安全。

网络流量的控制

将流量控制能力添加到网络流量管理中，能够帮助网络管理者对网络资源和业务资源进行带宽控制和资源调度，如对HTTP、FTP、SMTP以及P2P等应用进行管理，尤其是对P2P流量进行抑制来提升传统数据业务的用户体验度。

具备流量控制能力的网络流量管理还能够对严重影响业务运营者收入的未经许可的其他业务进行抑制。比如，对于VoIP业务，我们可以通过对VoIP信令流量和媒体流量的关联检测和统计分析，以及通过截断媒体数据包、伪装信令报文等方式对流量进行管理。还可以通过综合使用网络层、传输层和应用层检测技术，对未经许可的宽带私接用户采取中断连接、主动告警、分时控制等多种管理动作。

流量控制还能够帮助网络流量管理实现业务资源的调度，并能够获得业务资源使用、业务状态的实时情况。当某一网络应用业务服务器负载较大时，可以进行全局的业务资源负载均衡，以平均地承担业务请求；同时也能够对用户的业务请求进行调度，决定是否继续响应用户新的业务请求，并根据用户的优先级优先响应高优先级用户的业务请求，以提升业务运营效率。

流量控制通常的做法是在输出端口处建立一个队列进行流量控制，控制的方式是基于路由，亦即基于目的IP地址或目的子网的网络号。流量控制器基本的功能模块为队列、分类和过滤器。由于目前网络流量种类繁多，网络管理员在管理时通常都采用分类的方式进行。

对于网络流量管理来说，除了应具有上述的流量识别、流量分析和流量控制的功能之外，我们一般还希望其具有和防火墙等网络安全设备协同构建一个主动的安全威胁防御体系的功能，以提升整个网络的安全防护能力，从而更好地保证网络流量。

比如，流量特征识别分析就是一种必要的流量管理手段。它能够主动发现诸如DDoS攻击、病毒和木马等异常流量，较好地弥补其他网络安全设备如防火墙、入侵防护系统（IPS）和统一威胁管理（UTM）等的不足，提升其主动发现安全威胁的能力，并能够及时向其他网络安全设备发出告警，从安全威胁源头开始就进行主动的防御。此外，具备流量识别能力的网络流量管理还能够获取并保存网络流量的网络层信息（例如，源/目的IP地址、应用端口、用户标识ID等信息），通过这些信息，网络管理者能够对安全威胁进行溯源定位。

链接一 DFI技术与DPI技术比较

DFI与DPI两种技术的设计基本目标都是为了实现业务识别，但是两者在实现的着眼点和技术细节方面还是存在着较大区别的。从两种技术的对比情况看，两者互有优势，也都有短处，DPI技术适用于需要精细和准确识别、精细管理的环境，而DFI技术适用于需要高效识别、粗放管理的环境。

从处理速度来看： DFI处理速度相对快，而采用DPI技术由于要逐包进行拆包操作，并与后台数据库进行匹配对比，处理速度会慢些。由于采用DFI技术进行流量分析仅需将流量特征与后台流量模型比较即可，因此，与目前多数基于DPI的带宽管理系统的处理能力仅为线速1Gbit/s相比，基于DFI的系统可以达到线速10Gbit/s，完全可以满足企业网络流量管理的需求。

从维护成本来看： DFI维护成本相对较低，而基于DPI技术的带宽管理系统总是滞后新应用，需要紧跟新协议和新型应用的产生而不断升级后台应用数据库，否则就不能有效识别、管理新技术下的带宽，影响模式匹配效率；而基于DFI技术的系统在管理维护上的工作量要少于DPI系统，因为同一类型的新应用与旧应用的流量特征不会出现大的变化，因此不需要频繁升级流量行为模型。

从识别准确率来看： 两种技术各有所长。由于DPI采用逐包分析、模式匹配技术，因此，可以对流量中的具体应用类型和协议做到比较准确的识别；而DFI仅对流量行为分析，因此只能对应用类型进行笼统分类，如对满足P2P流量模型的应用统一识别为P2P流量，对符合网络语音流量模型的类型统一归类为VoIP流量，但是无法判断该流量是否采用H.323或其他协议。如果数据包是经过加密传输的，采用DPI方式的流控技术则不能识别其具体应用，而DFI方式的流控技术不受影响，因为应用流的状态行为特征不会因加密而根本改变。

链接二 几种常见的网络流量

当前随着网络应用的不断丰富和发展，网络流量也随之变得复杂和种类繁多起来，下面是最为常见的几种网络流量：

1. HTTP流量： HTTP是互联网上使用最为广泛的协议，早就已经取代传统文件下载的主要应用层协议FTP，如今，随着YouTube等视频共享网站的拉动，HTTP协议的网络流量在过去四年里首次超过了P2P应用的流量。

2. FTP流量：从互联网出现的开始，FTP就一直是用户使用频率最高的应用服务之一，重要性仅次于HTTP和SMTP。而随着P2P应用的出现，其重要性地位虽然有所降低，但是仍然是用户们下载文件不可替代的重要应用和途径之一。

3. SMTP流量：电子邮件是整个互联网业务重要的组成部分。据统计，3/4以上的用户上网的主要目的是收发邮件，每天有十数亿封电子邮件在全球传递。特别是由于电子邮件的廉价和操作简便，诱使有人将它作为大量散发自己信息的工具，最终导致了互联网世界中垃圾邮件的泛滥。

4. VoIP流量： 2006年全球IP电话用户从1030万增长到1870万，增幅达83%。2007年VoIP通话量已达到全部通话量的75%。因此，互联网上VoIP的流量也是非常值得管理员关注的。

5. P2P流量：目前网络带宽“消费大户”是P2P文件共享，在中东占据了49%，东欧地区占据了84%。从全球来看，夜间时段的网络带宽有95%被P2P占据。

6. Streaming流量：随着诸如PPLive、PPStream等视频软件的出现，视频直播和点播成为广大互联网用户观看节目和网上娱乐的最佳生活方式，因此其流量也在不断地增加。

无相关文章，以下随机显示

标签：,
]]> http://ourapache.com/archives/306/feed 6 面向站长和网站管理员的Web缓存加速指南 http://ourapache.com/archives/209 http://ourapache.com/archives/209#comments Fri, 27 Feb 2009 03:39:37 +0000 OurApache http://www.ourapache.com/?p=209

原文（英文）地址： http://www.mnot.net/cache_docs/  版权声明：署名-非商业性使用-禁止演绎 2.0

这是一篇知识性的文档，主要目的是为了让Web缓存相关概念更容易被开发者理解并应用于实际的应用环境中。为了简要起见，某些实现方面的细节被简化或省略了。如果你更关心细节实现则完全不必耐心看完本文，后面参考文档和更多深入阅读部分可能是你更需要的内容。

  1. 什么是Web缓存，为什么要使用它？
  2. 缓存的类型：
    1. 浏览器缓存；
    2. 代理服务器缓存；
  3. Web缓存无害吗？为什么要鼓励缓存？
  4. Web缓存如何工作：
  5. 如何控制（控制不）：
    1. HTML Meta标签 vs. HTTP头信息；
    2. Pragma HTTP头信息（为什么不起作用）；
    3. 使用Expires（过期时间）HTTP头信息控制保鲜期；
    4. Cache-Control（缓存控制） HTTP头信息；
    5. 校验参数和校验；
  6. 创建利于缓存网站的窍门；
  7. 编写利于缓存的脚本；
  8. 常见问题解答；
  9. 缓存机制的实现：Web服务器端配置；
  10. 缓存机制的实现：服务器端脚本；
  11. 参考文档和深入阅读；
  12. 关于本文档；

什么是Web缓存，为什么要使用它？

Web缓存位于Web服务器之间（1个或多个，内容源服务器）和客户端之间（1个或多个）：缓存会根据进来的请求保存输出内容的副本，例如html页面， 图片，文件（统称为副本），然后，当下一个请求来到的时候：如果是相同的URL，缓存直接使用副本响应访问请求，而不是向源服务器再次发送请求。

使用缓存主要有2大理由：

  • 减少相应延迟：因为请求从缓存服务器（离客户端更近）而不是源服务器被相应，这个过程耗时更少，让web服务器看上去相应更快；
  • 减少网络带宽消耗：当副本被重用时会减低客户端的带宽消耗；客户可以节省带宽费用，控制带宽的需求的增长并更易于管理。

缓存的类型

浏览器缓存

对于新一代的Web浏览器来说（例如：，Firefox）：一般都能在设置对话框中发现关于缓存的设置，通过在你的电脑上僻处一块硬盘空间用于存储你已经看过的网站的副本。浏览器缓存根据非常简单的规则进行工作：在同一个会话过程中（在当前浏览器没有被关闭之前）会检查一次并确定缓存的副本足够新。这个缓存对于用户点击“后退”或者点击刚访问过的链接特别有用，如果你浏览过程中访问到同一个图片，这些图片可以从浏览器缓存中调出而即时显现。

代理服务器缓存

Web代理服务器使用同样的缓存原理，只是规模更大。代理服务器群为成百上千用户服务使用同样的机制；大公司和ISP经常在他们的防火墙上架设代理缓存或者单独的缓存设备；

由于带路服务器缓存并非客户端或者源服务器的一部分，而是位于原网络之外，请求必须路由到他们才能起作用。一个方法是手工设置你的浏览器：告诉浏览器使用 那个代理，另外一个是通过中间服务器：这个中间服务器处理所有的web请求，并将请求转发到后台网络，而用户不必配置代理，甚至不必知道代理的存在；

代理服务器缓存：是一个共享缓存，不只为一个用户服务，经常为大量用户使用，因此在减少相应时间和带宽使用方面很有效：因为同一个副本会被重用多次。

网关缓存

也被称为反向代理缓存或间接代理缓存，网关缓存也是一个中间服务器，和内网管理员部署缓存用于节省带宽不同：网关缓存一般是网站管理员自己部署：让他们的网站更容易扩展并获得更好的性能；
请求有几种方法被路由到网关缓存服务器上：其中典型的是让用一台或多台负载均衡服务器从客户端看上去是源服务器；

网络内容发布商  (Content delivery networks CDNs)分布网关缓存到整个（或部分）互联网上，并出售缓存服务给需要的网站，Speedera和Akamai就是典型的网络内容发布商(下文简称CDN)。

本问主要关注于浏览器和代理缓存，当然，有些信息对于网关缓存也同样有效；

Web缓存无害吗？为什么要鼓励缓存？

Web缓存在互联网上最容易被误解的技术之一：网站管理员经常怕对网站失去控制，由于代理缓存会“隐藏”他们的用户，让他们感觉难以监控谁在使用他们的网站。
不幸的是：就算不考虑Web缓存，互联网上也有很多网站使用非常多的参数以便管理员精确地跟踪用户如何使用他们的网站；如果这类问题也是你关心的，本文将告诉你如何获得精确的统计而不必将网站设计的非常缓存不友好。
另外一个抱怨是缓存会给用户过期或失效的数据；无论如何：本文可以告诉你怎样配置你的服务器来控制你的内容将被如何缓存。

CDN是另外一个有趣的方向，和其他代理缓存不同：CDN的网关缓存为希望被缓存的网站服务，没有以上顾虑。即使你使用了CDN，你也要考虑后续的代理服务器缓存和浏览器缓存问题。

另外一方面：如果良好地规划了你的网站，缓存会有助于网站服务更快，并节省服务器负载和互联网的链接请求。这个改善是显著的：一个难以缓存的网站可能需要几秒去载入页面，而对比有缓存的网站页面几乎是即时显现：用户更喜欢速度快的网站并更经常的访问；

这样想：很多大型互联网公司为全世界服务器群投入上百万资金，为的就是让用户访问尽可能快，客户端缓存也是这个目的，只不过更靠近用户一端，而且最好的一点是你甚至根本不用为此付费。

事实上，无论你是否喜欢，代理服务器和浏览器都回启用缓存。如果你没有配置网站正确的缓存，他们会按照缺省或者缓存管理员的策略进行缓存。

缓存如何工作

所有的缓存都用一套规则来帮助他们决定什么时候使用缓存中的副本提供服务（假设有副本可用的情况下）；一些规则在协议中有定义（HTTP协议1.0和1.1），一些规则由缓存的管理员设置（浏览器的用户或者代理服务器的管理员）；
一般说来：遵循以下基本的规则（不必担心，你不必知道所有的细节，细节将随后说明）

  1. 如果响应头信息：告诉缓存器不要保留缓存，缓存器就不会缓存相应内容；
  2. 如果请求信息是需要认证或者安全加密的，相应内容也不会被缓存；
  3. 如果在回应中不存在校验器（ETag或者Last-Modified头信息），缓存服务器会认为缺乏直接的更新度信息，内容将会被认为不可缓存。
  4. 一个缓存的副本如果含有以下信息：内容将会被认为是足够新的
    • 含有完整的过期时间和寿命控制头信息，并且内容仍在保鲜期内；
    • 浏览器已经使用过缓存副本，并且在一个会话中已经检查过内容的新鲜度；
    • 缓存代理服务器近期内已经使用过缓存副本，并且内容的最后更新时间在上次使用期之前；
    • 够新的副本将直接从缓存中送出，而不会向源服务器发送请求；
  5. 如果缓存的副本已经太旧了，缓存服务器将向源服务器发出请求校验请求，用于确定是否可以继续使用当前拷贝继续服务；

总之：新鲜度和校验是确定内容是否可用的最重要途径： 

如果副本足够新，从缓存中提取就立刻能用了；
而经缓存器校验后发现副本的原件没有变化，系统也会避免将副本内容从源服务器整个重新传输一遍。

如何控制（控制不）缓存

有很多工具可以帮助设计师和网站管理员调整缓存服务器对待网站的方式，这也许需要你亲自下手对服务器的配置进行一些调整，但绝对值得；了解如何使用这些工具请参考后面的实现章节；

HTML meta标签和HTTP 头信息

HTML的编写者会在文档的<HEAD>区域中加入描述文档的各种属性，这些META标签常常被用于标记文档不可以被缓存或者标记多长时间后过期；
META标签使用很简单：但是效率并不高，因为只有几种浏览器会遵循这个标记（那些真正会“读懂”HTML的浏览器），没有一种缓存代理服务器能遵循这个 规则（因为它们几乎完全不解析文档中HTML内容）；有事会在Web页面中增加：Pragma: no-cache这个META标记，如果要让页面保持刷新，这个标签其实完全没有必要。
如果你的网站托管在ISP机房中，并且机房可能不给你权限去控制HTTP的头信息（如：Expires和Cache-Control），大声控诉：这些机制对于你的工作来说是必须的；
另外一方面： HTTP头信息可以让你对浏览器和代理服务器如何处理你的副本进行更多的控制。他们在HTML代码中是看不见的，一般由Web服务器自动生成。但是，根据 你使用的服务，你可以在某种程度上进行控制。在下文中：你将看到一些有趣的HTTP头信息，和如何在你的站点上应用部署这些特性。

HTTP头信息发送在HTML代码之前，只有被浏览器和一些中间缓存能看到，一个典型的HTTP 1.1协议返回的头信息看上去像这样：

HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: “3e86-410-3596fbbc”
Content-Length: 1040
Content-Type: text/html

在头信息空一行后是HTML代码的输出，关于如何设置HTTP头信息请参考实现章节；

Pragma HTTP头信息 (为什么它不起作用)

很多人认为在HTTP头信息中设置了Pragma: no-cache后会让内容无法被缓存。但事实并非如此：HTTP的规范中，响应型头信息没有任何关于Pragma属性的说明，而讨论了的是请求型头信息 Pragma属性（头信息也由浏览器发送给服务器），虽然少数集中缓存服务器会遵循这个头信息，但大部分不会。用了Pragma也不起什么作用，要用就使 用下列头信息：

使用Expires（过期时间）HTTP头信息来控制保鲜期

Expires（过期时间） 属性是HTTP控制缓存的基本手段，这个属性告诉缓存器：相关副本在多长时间内是新鲜的。过了这个时间，缓存器就会向源服务器发送请求，检查文档是否被修改。几乎所有的缓存服务器都支持Expires（过期时间）属性；

大部分Web服务器支持你用几种方式设置Expires属性；一般的：可以设计一个绝对时间间隔：基于客户最后查看副本的时间（最后访问时间）或者根据服务器上文档最后被修改的时间；

Expires头信息：对于设置静态图片文件（例如导航栏和图片按钮）可缓存特别有用；因为这些图片修改很少，你可以给它们设置一个特别长的过期时间，这会使你的网站对用户变得相应非常快；他们对于控制有规律改变的网页也很有用，例如：你每天早上6点更新新闻页，你可以设置副本的过期时间也是这个时间，这样缓存 服务器就知道什么时候去取一个更新版本，而不必让用户去按浏览器的“刷新”按钮。

过期时间头信息属性值只能是HTTP格式的日期时间，其他的都会被解析成当前时间“之前”，副本会过期，记住：HTTP的日期时间必须是格林威治时间（GMT），而不是本地时间。举例：

Expires: Fri, 30 Oct 1998 14:19:41 GMT

所以使用过期时间属性一定要确认你的Web服务器时间设置正确，一个途径是通过网络时间同步协议（Network Time Protocol NTP），和你的系统管理员那里你可以了解更多细节。
虽然过期时间属性非常有用，但是它还是有些局限，首先：是牵扯到了日期，这样Web服务器的时间和缓存服务器的时间必须是同步的，如果有些不同步，要么是应该缓存的内容提前过期了，要么是过期结果没及时更新。
还有一个过期时间设置的问题也不容忽视：如果你设置的过期时间是一个固定的时间，如果你返回内容的时候又没有连带更新下次过期的时间，那么之后所有访问请求都会被发送给源Web服务器，反而增加了负载和响应时间；

Cache-Control（缓存控制） HTTP头信息

HTTP 1.1介绍了另外一组头信息属性：Cache-Control响应头信息，让网站的发布者可以更全面的控制他们的内容，并定位过期时间的限制。
有用的 Cache-Control响应头信息包括：

  • max-age=[秒] — 执行缓存被认为是最新的最长时间。类似于过期时间，这个参数是基于请求时间的相对时间间隔，而不是绝对过期时间，[秒]是一个数字，单位是秒：从请求时间开始到过期时间之间的秒数。
  • s-maxage=[秒] — 类似于max-age属性，除了他应用于共享（如：代理服务器）缓存
  • public — 标记认证内容也可以被缓存，一般来说： 经过HTTP认证才能访问的内容，输出是自动不可以缓存的；
  • no-cache — 强制每次请求直接发送给源服务器，而不经过本地缓存版本的校验。这对于需要确认认证应用很有用（可以和public结合使用），或者严格要求使用最新数据的应用（不惜牺牲使用缓存的所有好处）；
  • no-store — 强制缓存在任何情况下都不要保留任何副本
  • must-revalidate — 告诉缓存必须遵循所有你给予副本的新鲜度的，HTTP允许缓存在某些特定情况下返回过期数据，指定了这个属性，你高速缓存，你希望严格的遵循你的规则。
  • proxy-revalidate — 和 must-revalidate类似，除了他只对缓存代理服务器起作用

举例:

Cache-Control: max-age=3600, must-revalidate

如果你计划试用Cache-Control属性，你应该看一下这篇HTTP文档，详见参考和深入阅读；

校验参数和校验

在Web缓存如何工作： 我们说过：校验是当副本已经修改后，服务器和缓存之间的通讯机制；使用这个机制：缓存服务器可以避免副本实际上仍然足够新的情况下重复下载整个原件。
校验参数非常重要，如果1个不存在，并且没有任何信息说明保鲜期（Expires或Cache-Control）的情况下，缓存将不会存储任何副本；
最常见的校验参数是文档的最后修改时间，通过最后Last-Modified头信息可以，当一份缓存包含Last-Modified信息，他基于此信息，通过添加一个If-Modified-Since请求参数，向服务器查询：这个副本从上次查看后是否被修改了。
HTTP 1.1介绍了另外一个校验参数： ETag，服务器是服务器生成的唯一标识符ETag，每次副本的标签都会变化。由于服务器控制了ETag如何生成，缓存服务器可以通过If-None-Match请求的返回没变则当前副本和原件完全一致。
所有的缓存服务器都使用Last-Modified时间来确定副本是否够新，而ETag校验正变得越来越流行；
所有新一代的Web服务器都对静态内容（如：文件）自动生成ETag和Last-Modified头信息，而你不必做任何设置。但是，服务器对于动态内容（例如：CGI,ASP或数据库生成的网站）并不知道如何生成这些信息，参考一下编写利于缓存的脚本章节；

创建利于缓存网站的窍门

除了使用新鲜度信息和校验，你还有很多方法使你的网站缓存友好。

  • 保持URL稳定： 这是缓存的金科玉律，如果你给在不同的页面上，给不同用户或者从不同的站点上提供相同的内容，应该使用相同的URL，这是使你的网站缓存友好最简单，也是 最高效的方法。例如：如果你在页面上使用 “/index.html” 做为引用，那么就一直用这个地址；
  • 使用一个共用的库存放每页都引用的图片和其他页面元素；
  • 对于不经常改变的图片/页面启用缓存，并使用Cache-Control: max-age属性设置一个较长的过期时间；
  • 对于定期更新的内容设置一个缓存服务器可识别的max-age属性或过期时间；
  • 如果数据源（特别是下载文件）变更，修改名称，这样：你可以让其很长时间不过期，并且保证服务的是正确的版本；而链接到下载文件的页面是一个需要设置较短过期时间的页面。
  • 万不得已不要改变文件，否则你会提供一个非常新的Last-Modified日期；例如：当你更新了网站，不要复制整个网站的所有文件，只上传你修改的文件。
  • 只在必要的时候使用Cookie，cookie是非常难被缓存的，而且在大多数情况下是不必要的，如果使用cookie，控制在动态网页上；
  • 减少试用SSL，加密的页面不会被任何共享缓存服务器缓存，只在必要的时候使用，并且在SSL页面上减少图片的使用；
  • 使用可缓存性评估引擎，这对于你实践本文的很多概念都很有帮助；

编写利于缓存的脚本

脚本缺省不会返回校验参数（返回Last-Modified或ETag头信息）或其他新鲜度信息（Expires或Cache-Control），有些动态脚本的确是动态内容（每次相应内容都不一样），但是更多（搜索引擎，数据库引擎网站）网站还是能从缓存友好中获益的。
一般说来，如果脚本生成的输出在未来一段时间（几分钟或者几天）都是可重复复制的，那么就是可缓存的。如果脚本输出内容只随URL变化而变化，也是可缓存的；但如果输出会根据cookie，认证信息或者其他外部条件变化，则还是不可缓存的。

  • 最利于缓存的脚本就是将内容改变时导出成静态文件，Web服务器可以将其当作另外一个网页并生成和试用校验参数，让一些都变得更简单，只需要写入文件即可，这样最后修改时间也有了；
  • 另外一个让脚本可缓存的方法是对一段时间内能保持较新的内容设置一个相对寿命的头信息，虽然通过Expires头信息也可以实现，但更容易的是用Cache-Control: max-age属性，它会让首次请求后一段时间内缓存保持新鲜；
  • 如果以上做法你都做不到，你可以让脚本生成一个校验属性，并对 If-Modified-Since 和/或If-None-Match请求作出反应，这些属性可以从解析HTTP头信息得到，并对符合条件的内容返回304 Not Modified（内容未改变），可惜的是，这种做法比不上前2种高效；

其他窍门：

  • 尽量避免使用POST，除非万不得已，POST模式的返回内容不会被大部分缓存服务器保存，如果你发送内容通过URL和查询（通过GET模式）的内容可以缓存下来供以后使用；
  • 不要在URL中加入针对每个用户的识别信息：除非内容是针对每个用户不同的；
  • 不要统计一个用户来自一个地址的所有请求，因为缓存常常是一起工作的；
  • 生成并返回Content-Length头信息，如果方便的话，这个属性让你的脚本在可持续链接模式时：客户端可以通过一个TCP/IP链接同时请求多个副本，而不是为每次请求单独建立链接，这样你的网站相应会快很多；

具体定义请参考实现章节。

常见问题解答

让网站变得可缓存的要点是什么？

好的策略是确定那些内容最热门，大量的复制（特别是图片）并针对这些内容先部署缓存。

如何让页面通过缓存达到最快相应？

缓存最好的副本是那些可以长时间保持新鲜的内容；基于校验虽然有助于加快相应，但是它不得不和源服务器联系一次去检查内容是否够新，如果缓存服务器上就知道内容是新的，内容就可以直接相应返回了。

我理解缓存是好的，但是我不得不统计多少人访问了我的网站！

如果你必须知道每次页面访问的，选择【一】个页面上的小元素，或者页面本身，通过适当的头信息让其不可缓存，例如： 可以在每个页面上部署一个1×1像素的透明图片。Referer头信息会有包含这个图片的每个页面信息；
明确一点：这个并不会给你一个关于你用户精确度很高的统计，而且这对互联网和你的用户这都不太好，消耗了额外的带宽，强迫用户去访问无法缓存的内容。了解更多信息，参考访问统计资料。

我如何能看到HTTP头信息的内容？

很多浏览器在页面属性或类似界面中可以让你看到Expires 和Last-Modified信息；如果有的话：你会找到页面信息的菜单和页面相关的文件（如图片），并且包含他们的详细信息；
看到完整的头信息，你可以用telnet手工连接到Web服务器；
为此：你可能需要用一个字段指定端口（缺省是80），或者链接到www.example.com:80 或者 www.example.com 80(注意是空格)，更多设置请参考一下telnet客户端的文档；
打开网站链接：请求一个查看链接，如果你想看到http://www.example.com/foo.html 连接到www.example.com的80端口后，键入：

GET /foo.html HTTP/1.1 [回车]
GET /foo.html HTTP/1.1 [return]
Host: www.example.com [回车][回车]
Host: www.example.com [return][return]

在[回车]处按键盘的回车键；在最后，要按2次回车，然后，就会输出头信息及完整页面，如果只想看头信息，将GET换成HEAD。

我的页面是密码保护的，代理缓存服务器如何处理他们？

缺省的，网页被HTTP认证保护的都是私密内容，它们不会被任何共享缓存保留。但是，你可以通过设置Cache-Control: public让认证页面可缓存，HTTP 1.1标准兼容的缓存服务器会认出它们可缓存。
如果你认为这些可缓存的页面，但是需要每个用户认证后才能看，可以组合使用Cache-Control: public和no-cache头信息，高速缓存必须在提供副本之前，将将新客户的认证信息提交给源服务器。设置就是这样：

Cache-Control: public, no-cache

无论如何：这是减少认证请求的最好方法，例如： 你的图片是不机密的，将它们部署在另外一个目录，并对此配置服务器不强制认证。这样，那些图片会缺省都缓存。

我们是否要担心用户通过cache访问我的站点？

代理服务器上SSL页面不会被缓存（不推荐被缓存），所以你不必为此担心。但是，由于缓存保存了非SSL请求和从他们抓取的URL，你要意识到没有安全保护的网站，可能被不道德的管理员可能搜集用户隐私，特别是通过URL。
实际上，位于服务器和客户端之间的管理员可以搜集这类信息。特别是通过CGI脚本在通过URL传递用户名和密码的时候会有很大问题；这对泄露用户名和密码是一个很大的漏洞；
如果你初步懂得互联网的安全机制，你不会对缓存服务器有任何。

我在寻找一个包含在Web发布系统解决方案，那些是比较有缓存意识的系统？

这很难说，一般说来系统越复杂越难缓存。最差就是全动态发布并不提供校验参数；你无发缓存任何内容。可以向系统提供商的技术人员了解一下，并参考后面的实现说明。

我的图片设置了1个月后过期，但是我现在需要现在更新。

过期时间是绕不过去的，除非缓存（浏览器或者代理服务器）空间不足才会删除副本，缓存副本在过期之间会被一直使用。
最好的办法是改变它们的链接，这样，新的副本将会从源服务器上重新下载。记住：引用它们的页面本身也会被缓存。因此，使用静态图片和类似内容是很容易缓存的，而引用他们的HTML页面则要保持非常更新；
如果你希望对指定的缓存服务器重新载入一个副本，你可以强制使用“刷新”（在FireFox中在reload的时候按住shift键：就会有前面提到恶Pragma: no-cache头信息发出）。或者你可以让缓存的管理员从他们的界面中删除相应内容；

我运行一个Web托管服务，如何让我的用户发布缓存友好的网页？

如果你使用apahe，可以考虑允许他们使用.htaccess文件并提供相应的文档；
另外一方面： 你也可以考虑在各种虚拟主机上建立各种缓存策略。例如： 你可以设置一个目录 /cache-1m 专门用于存放访问1个月的访问，另外一个 /no-cache目录则被用提供不可存储副本的服务。
无论如何：对于大量用户访问还是应该用缓存。对于大网站，这方面的节约很明显（带宽和服务器负载）；

我标记了一些网页是可缓存的，但是浏览器仍然每次发送请求给服务。如何强制他们保存副本？

缓存服务器并不会总保存副本并重用副本；他们只是在特定情况下会不保存并使用副本。所有的缓存服务器都回基于文件的大小，类型（例如：图片 页面），或者服务器空间的剩余来确定如何缓存。你的页面相比更热门或者更大的文件相比，并不值得缓存。
所以有些缓存服务器允许管理员根据文件类型确定缓存副本的优先级，允许某些副本被永久缓存并长期有效；

缓存机制的实现 – Web服务器端配置

一般说来，应该选择最新版本的Web服务器程序来部署。不仅因为它们包含更多利于缓存的功能，新版本往往在性能和安全性方面都有很多的改善。

Apache HTTP服务器

Apache有些可选的模块来包含这些头信息： 包括Expires和Cache-Control。 这些模块在1.2版本以上都支持；
这些模块需要和apache一起编译；虽然他们已经包含在发布版本中，但缺省并没有启用。为了确定相应模块已经被启用：找到httpd程序并运行httpd -l 它会列出可用的模块，我们需要用的模块是mod_expires和mod_headers

  • 如果这些模块不可用，你需要联系管理员，重新编译并包含这些模块。这些模块有时候通过配置文件中把注释掉的配置启用，或者在编译的时候增加-enable -module=expires和-enable-module=headers选项（在apache 1.3和以上版本）。 参考Apache发布版中的INSTALL文件；

Apache一旦启用了相应的模块，你就可以在.htaccess文件或者在服务器的access.conf文件中通过mod_expires设置副本什 么时候过期。你可设置过期从访问时间或文件修改时间开始计算，并且应用到某种文件类型上或缺省设置，参考模块的文档获得更多信息，或者遇到问题的时候向你身边的apache专家讨教。
应用Cache-Control头信息，你需要使用mod_headers,它将允许你设置任意的HTTP头信息，参考mod_headers的文档可以获得更多资料；
这里有个例子说明如何使用头信息：

  • .htaccess文件允许web发布者使用命令只在配置文件中用到的命令。他影响到所在目录及其子目录；问一下你的服务器管理员确认这个功能是否启用了。
### 启用 mod_expires
ExpiresActive On
### 设置 .gif 在被访问过后1个月过期。
ExpiresByType image/gif A2592000
### 其他文件设置为最后修改时间1天后过期
### (用了另外的语法)
ExpiresDefault “modification plus 1 day”
### 在index.html文件应用 Cache-Control头属性
<Files index.html>
Header append Cache-Control “public, must-revalidate”
</Files>       
  • 注意： 在适当情况下mod_expires会自动计算并插入Cache-Control:max-age 头信息

Apache 2.0的配置和1.3类似，更多信息可以参考2.0的mod_expires和mod_headers文档；

Microsoft IIS服务器

Microsoft的IIS可以非常容易的设置头信息，注意：这只针对IIS 4.0服务器，并且只能在NT服务器上运行。
为网站的一个区域设置头信息，先要到管理员工具界面中，然后设置属性。选择HTTP Header选单，你会看到2个有趣的区域：启用内容过期和定制HTTP头信息。头一个设置会自动配置，第二个可以用于设置Cache-Control头信息；
设置asp页面的头信息可以参考后面的ASP章节，也可以通过ISAPI模块设置头信息，细节请参考MSDN。

Netscape/iPlanet企业服务器

3.6版本以后，Netscape/iPlanet已经不能设置Expires头信息了，他从3.0版本开始支持HTTP 1.1的功能。这意味着HTTP 1.1的缓存（代理服务器/浏览器）优势都可以通过你对Cache-Control设置来获得。
使用Cache-Control头信息，在管理服务器上选择内容管理|缓存设置目录。然后：使用资源选择器，选择你希望设置头信息的目录。设置完头信息后，点击“OK”。更多信息请参考Netscape/iPlanet企业服务器的手册。

缓存机制的实现：服务器端脚本

需要注意的一点是：也许服务器设置HTTP头信息比脚本语言更容易，但是两者你都应该使用。
因为服务器端的脚本主要是为了动态内容，他本身不产生可缓存的文件页面，即使内容实际是可以缓存的。如果你的内容经常改变，但是不是每次页面请求都改变， 考虑设置一个Cache-Control: max-age头信息；大部分用户会在短时间内多次访问同一页面。例如： 用户点击“后退”按钮，即使没有新内容，他们仍然要再次从服务器下载内容查看。

CGI程序

CGI脚本是生成内容最流行的方式之一，你可以很容易在发送内容之前的扩展HTTP头信息；大部分CGI实现都需要你写 Content-Type头信息，例如这个Perl脚本：

#!/usr/bin/perl
print “Content-type: text/html\n”;
print “Expires: Thu, 29 Oct 1998 17:04:19 GMT\n”;
print “\n”;
### 后面是内容体…

由于都是文本，你可以很容易通过内置函数生成Expires和其他日期相关的头信息。如果你使用Cache-Control: max-age;会更简单；

print “Cache-Control: max-age=600\n”;

这样脚本可以在被请求后缓存10分钟；这样用户如果按“后退”按钮，他们不会重新提交请求；
CGI的规范同时也允许客户端发送头信息，每个头信息都有一个‘HTTP_’的前缀；这样如果一个客户端发送一个If-Modified-Since请求，就是这样的：

HTTP_IF_MODIFIED_SINCE = Fri, 30 Oct 1998 14:19:41 GMT

参考一下cgi_buffer库，一个自动处理ETag的生成和校验的库，生成Content-Length属性和对内容进行gzip压缩。在Python脚本中也只需加入一行；

服务器端包含 Server Side Includes

SSI（经常使用.shtml扩展名）是网站发布者最早可以生成动态内容的方案。通过在页面中设置特别的标记，也成为一种嵌入HTML的脚本；
大部分SSI的实现无法设置校验器，于是无法缓存。但是Apache可以通过对特定文件的组执行权限设置实现允许用户设置那种SSI可以被缓存；结合XbitHack调整整个目录。更多文档请参考mod_include文档。

PHP

PHP是一个内建在web服务器中的服务器端脚本语言，当做为HTML嵌入式脚本，很像SSI，但是有更多的选项，PHP可以在各种Web服务器上设置为CGI模式运行，或者做为Apache的模块；
缺省PHP生成副本没有设置校验器，于是也无法缓存，但是开发者可以通过Header()函数来生成HTTP的头信息；
例如：以下代码会生成一个Cache-Control头信息，并设置为3天以后过期的Expires头信息；

<?php
 Header(“Cache-Control: must-revalidate”);

 $offset = 60 * 60 * 24 * 3;
 $ExpStr = “Expires: ” . gmdate(“D, d M Y H:i:s”, time() + $offset) . ” GMT”;
 Header($ExpStr);
?>

记住： Header()的输出必须先于所有其他HTML的输出；
正如你看到的：你可以手工创建HTTP日期；PHP没有为你提供专门的函数（新版本已经让这个越来越容易了，请参考PHP的日期相关函数文档），当然，最简单的还是设置Cache-Control: max-age头信息，而且对于大部分情况都比较适用；
更多信息，请参考header相关的文档；
也请参考一下cgi_buffer库，自动处理ETag的生成和校验，Content-Length生成和内容的gzip压缩，PHP脚本只需包含1行代码；

Cold Fusion

Cold Fusion是Macromedia的商业服务器端脚本引擎，并且支持多种Windows平台，Linux平台和多种Unix平台。Cold Fusion通过CFHEADER标记设置HTTP头信息相对容易。可惜的是：以下的Expires头信息的设置有些容易误导；

<CFHEADER NAME=”Expires” VALUE=”#Now()#”>

它并不像你想像的那样工作，因为时间（本例中为请求发起的时间）并不会被转换成一个符合HTTP时间，而且打印出副本的Cold fusion的日期/时间对象，大部分客户端会忽略或者将其转换成1970年1月1日。
但是：Cold Fusion另外提供了一套日期格式化函数， GetHttpTimeSTring. 结合DateAdd函数，就很容易设置过期时间了，这里我们设置一个Header声明副本在1个月以后过期；

<cfheader name=”Expires” value=”#GetHttpTimeString(DateAdd(‘m’, 1, Now()))#”>

你也可以使用CFHEADER标签来设置Cache-Control: max-age等其他头信息；
记住：Web服务器也会将头信息设置转给Cold Fusion(做为CGI运行的时候)，检查你的服务器设置并确定你是否可以利用服务器设置代替Cold Fusion。

ASP和ASP.NET

在asp中设置HTTP头信息是：确认Response方法先于HTML内容输出前被调用，或者使用 Response.Buffer暂存输出；同样的：注意某些版本的IIS缺省设置会输出Cache-Control: private 头信息，必须声明成public才能被共享缓存服务器缓存。
IIS的ASP和其他web服务器都允许你设置HTTP头信息，例如： 设置过期时间，你可以设置Response对象的属性；

<% Response.Expires=1440 %>

设置请求的副本在输出的指定分钟后过期，类似的：也可以设置绝对的过期时间（确认你的HTTP日期格式正确）

<% Response.ExpiresAbsolute=#May 31,1996 13:30:15 GMT# %>

Cache-Control头信息可以这样设置：

<% Response.CacheControl=”public” %>

在ASP.NET中，Response.Expires 已经不推荐使用了，正确的方法是通过Response.Cache设置Cache相关的头信息；

Response.Cache.SetExpires ( DateTime.Now.AddMinutes ( 60 ) ) ;
Response.Cache.SetCacheability ( HttpCacheability.Public ) ;

参考MSDN文档可以找到更多相关新年系；

参考文档和深入阅读

HTTP 1.1 规范定义

HTTP 1.1的规范有大量的扩展用于页面缓存，以及权威的接口实现指南，参考章节：13, 14.9, 14.21, 以及 14.25.

Web-Caching.com

非常精彩的介绍缓存相关概念，并介绍其他在线资源。

关于非连续性访问统计

Jeff Goldberg内容丰富的演说告诉你为什么不应该过度依赖访问统计和计数器；

可缓存性检测引擎

可缓存的引擎设计，检测网页并确定其如何与Web缓存服务器交互， 这个引擎配合这篇指南是一个很好的调试工具，

cgi_buffer库

包含库：用于CGI模式运行的Perl/Python/PHP脚本，自动处理ETag生成/校验，Content-Length生成和内容压缩。正确地。 Python版本也被用作其他大量的CGI脚本。

关于本文档

本文版权属于Mark Nottingham <mnot@pobox.com>，本作品遵循创作共用版权。
如果你镜像本文，请通过以上邮件告知，这样你可以在更新时被通知；
所有的商标属于其所有人。
虽然作者确信内容在发布时的正确性，但不保证其应用或引申应用的正确性，如有误传，错误或其他需要澄清的问题请尽快告知作者；
本文最新版本可以从 http://www.mnot.net/cache_docs/ 获得；
翻译版本包括： 捷克语版，法语版和中文版。
版本： 1.81 – 2007年3月16日
创作共用版权声明
翻译： 车东 2007年9月6日

相关文章

标签：,
]]> http://ourapache.com/archives/209/feed 0 IE环境下的安全警告汇总收藏 http://ourapache.com/archives/151 http://ourapache.com/archives/151#comments Thu, 19 Feb 2009 04:37:21 +0000 OurApache http://www.ourapache.com/?p=151 可能大家都对环境下访问站点的一些安全警告有过接触，比如HTTP和HTTPS之间的互相跳转会弹出警告……；
但是这并不是全部，IE环境下访问HTTPS站点还有很多类型的安全警告，下面将一一道来；
以后如果大家遇到此类提醒也可以知道是怎么回事，对解决一些用户的疑问也会有所帮助；
第1类：进入或离开安全页面
1
2
         这里说的安全页面就是通过HTTPS进行访问的页面；这类型的警告是最常见的；
         该类型的警告可以被关闭，勾选《以后不再显示该警告》即可，对应于 Internet选项 – 高级 – 在安全和非安全模式之间转换时发出警告此选项；
         若没有勾选上面提到的选项，则每次页面的切换都会出现一次这个警告，比如HTTP – > HTTPS – > HTTP – > HTTPS，这样就会跳出三次！
         注意：这里的进入或离开安全页面指的是同一页面内的页面跳转，比如在http页面中通过<a href=’https://’>标签跳转到安全页面，一般目标页面的http返回状态码为200；
若通过iframe嵌入的方式，则不会出现该警告，比如http页面中包含了一个iframe，iframe内的页面为https的，这样是不会弹出警告的；
第2类：从安全页面重定向到非安全页面
3
        这种情况一般出现在https页面内部操作完成之后，通过redirect的方式重定向到一个http的url，此时就会跳出警告，而且无法避免；比如我们在https login页面进行登陆，到login!validate.jspa验证，成功之后重定向到http页面；此时登陆验证地址login!validate.jspa的http返回状态码为302；
第3类：安全页面中包含有非安全元素
41
        这种情况一般出现在https页面中引用了http页面元素，比如引用了http://xxx.com/a.jpg、js、css等；MS该警告信息也无法避免，只能要求我们系统实现时尽量避免在同一页面中包括http和https两种类型请求；
第4类：证书发行方为不信任机构
5
        
         该类型的警告出现在：发行方的证书发行方不在IE信任的发行方列表中；比如我们ali的内网，他的证书是自签名的，所以不在IE的信任列表中；
         IE信任的发行方列表可以参考 Internet选项 – 高级 – 证书 – 受信任的根证书颁发机构选项，比如我们所熟知的verisign就在此信任列表中；
         若证书是通过信任列表中的颁发机构签名认证的，则不会出现此警告，比如alipay.com，trade.alisoft.com；
         该警告只会在第一次访问不被信任https站点时出现，如果IE不关闭，继续浏览该站点的话是不会再次出现该警告的；
         若要屏蔽掉该警告的话，网上有一些建议，比如取消勾选 Internet选项 – 高级 – 对无效站点证书发出警告/检查发行商的证书吊销这两项；但是我在好几台机器上测试了一把，遗憾的是都没有成功，所以暂时还没有找到能够去掉这个警告的办法，不知其他同学有没有好的method？
第5类：试图打开受信任站点列表
        
6
         该类警告只有在从非受信站点访问受信站点时出现，而且无法屏蔽（我没有找到办法，不知其他同学有没有办法？）；非信任站点间、信任站点间、信任站点到非信任站点都不会出现此警告；
         这里的受信站点指的是 Internet选项 – 安全 – 受信任的站点中添加过的站点；
第6类：选择数字证书
7
        
         该类应该算提示信息，而非安全警告；一般出现在客户端需要向服务器端出示证书的时候，比如我们的内网系统，每个人都需要向intranet申请一个数字证书，服务器端依靠发行给用户的证书来判断是否为合法访问用户；
         该类提示信息可以屏蔽掉，将需要访问的站点添加到受信站点列表中即可；若不在受信列表中，则该提示在第一次访问站点时出现，若IE不关闭，之后不会再次提示；
 
以上几类警告可能会同时出现，这样你就需要点击很多个确认，允许之类的按钮，可以按照自己的需要屏蔽掉一些烦人的提示信息，呵呵；

无相关文章，以下随机显示

标签：, , ,
]]> http://ourapache.com/archives/151/feed 0 meta标签的一些解释 http://ourapache.com/archives/126 http://ourapache.com/archives/126#comments Tue, 10 Feb 2009 07:50:50 +0000 OurApache http://www.ourapache.com/?p=126 meta是用来在HTML文档中模拟HTTP协议的响应头报文。 标签用于网页的head与/head中， 标签的用处很多。 的属性有两种：name和http-equiv。name属性主要用于描述网页，对应于content（网页内容），以便于搜索引擎机器人查找、分类（目 前几乎所有的搜索引擎都使用网上机器人自动查找meta值来给网页分类）。这其中最重要的是description（站点在搜索引擎上的描述）和 keywords（分类关键词），所以应该给每页加一个meta值。比较常用的有以下几个：

name 属性

1、meta name=”Generator” content=””用以说明生成工具（如Microsoft FrontPage 4.0）等；

2、meta name=”KEYWords” content=””向搜索引擎说明你的网页的关键词；

3、meta name=”DEscription” content=””告诉搜索引擎你的站点的主要内容；

4、meta name=”Author” content=”你的姓名”告诉搜索引擎你的站点的制作的作者；

5、meta name=”Robots” content= “all|none|index|noindex|follow|nofollow”

其中的属性说明如下：

设定为all：文件将被检索，且页面上的链接可以被查询；

设定为none：文件将不被检索，且页面上的链接不可以被查询；

设定为index：文件将被检索；

设定为follow：页面上的链接可以被查询；

设定为noindex：文件将不被检索，但页面上的链接可以被查询；

设定为nofollow：文件将不被检索，页面上的链接可以被查询。

http-equiv属性

1、meta http-equiv=”Content-Type” content=”text/html”;charset=gb_2312-80″

和 meta http-equiv=”Content-Language” content=”zh-CN”用以说明主页制作所使用的文字以及语言；

又如英文是ISO-8859-1字符集，还有BIG5、utf-8、shift-Jis、Euc、Koi8-2等字符集；

2、meta http-equiv=”Refresh” content=”n;url=http://yourlink”定时让网页在指定的时间n内，跳转到页面http://yourlink；

3、meta http-equiv=”Expires” content=”Mon,12 May 2001 00:20:00 GMT”可以用于设定网页的到期时间，一旦过期则必须到服务器上重新调用。需要注意的是必须使用GMT时间格式；

4、meta http-equiv=”Pragma” content=”no-cache”是用于设定禁止浏览器从本地机的缓存中调阅页面内容，设定后一旦离开网页就无法从Cache中再调出；

5、meta http-equiv=”set-cookie” content=”Mon,12 May 2001 00:20:00 GMT”cookie设定，如果网页过期，存盘的cookie将被删除。需要注意的也是必须使用GMT时间格式；

6、meta http-equiv=”Pics-label” content=””网页等级评定，在IE的internet选项中有一项内容设置，可以防止浏览一些受限制的网站，而网站的限制级别就是通过meta属性来设置的；

7、meta http-equiv=”windows-Target” content=”_top”强制页面在当前窗口中以独立页面显示，可以防止自己的网页被别人当作一个frame页调用；

8、 meta http-equiv=”Page-Enter” content=”revealTrans(duration=10,transtion= 50)”和meta http-equiv=”Page-Exit” content=”revealTrans(duration=20，transtion=6)”设定进入和离开页面时的特殊效果，这个功能即 FrontPage中的“格式/网页过渡”，不过所加的页面不能够是一个frame页面。

无相关文章，以下随机显示

标签：,
]]> http://ourapache.com/archives/126/feed 0 YouTube 架构学习 http://ourapache.com/archives/82 http://ourapache.com/archives/82#comments Fri, 06 Feb 2009 06:24:52 +0000 OurApache http://www.ourapache.com/?p=82 YouTube发展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。

平台

Apache
Python
Linux(SuSe)
MySQL
psyco，一个动态的Python到C的编译器
lighttpd代替Apache做视频查看

状态

支持每天超过1亿的视频点击量
成立于2005年2月
于2006年3月达到每天3千万的视频点击量
于2006年7月达到每天1亿的视频点击量
2个系统管理员，2个伸缩性软件架构师
2个软件开发工程师，2个网络工程师，1个DBA

处理飞速增长的流量

代码

 

  1. while (true)
  2. {
  3. identify_and_fix_bottlenecks();
  4. drink();
  5. sleep();
  6. notice_new_bottleneck();
  7. }

每天运行该循环多次

Web服务器
1，NetScaler用于负载均衡和静态内容缓存
2，使用mod_fast_cgi运行Apache
3，使用一个Python应用服务器来处理请求的路由
4，应用服务器与多个数据库和其他信息源交互来获取数据和格式化html页面
5，一般可以通过添加更多的机器来在Web层提高伸缩性
6，Python的Web层代码通常不是性能瓶颈，大部分时间阻塞在RPC
7，Python允许快速而灵活的开发和部署
8，通常每个页面服务少于100毫秒的时间
9，使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环
10，对于像加密等密集型CPU活动，使用C扩展
11，对于一些开销昂贵的块使用预先生成并缓存的html
12，数据库里使用行级缓存
13，缓存完整的Python对象
14，有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个使用不当的策略。应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，然后发送。

视频服务
1，花费包括带宽，硬件和能源消耗
2，每个视频由一个迷你集群来host，每个视频被超过一台机器持有
3，使用一个集群意味着：
-更多的硬盘来持有内容意味着更快的速度
-failover。如果一台机器出故障了，另外的机器可以继续服务
-在线备份
4，使用lighttpd作为Web服务器来提供视频服务：
-Apache开销太大
-使用epoll来等待多个fds
-从单进程配置转变为多进程配置来处理更多的连接
5，大部分流行的内容移到CDN：
-CDN在多个地方备份内容，这样内容离用户更近的机会就会更高
-CDN机器经常内存不足，因为内容太流行以致很少有内容进出内存的颠簸
6，不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器
-长尾效应。一个视频可以有多个播放，但是许多视频正在播放。随机硬盘块被访问
-在这种情况下缓存不会很好，所以花钱在更多的缓存上可能没太大意义。
-调节RAID控制并注意其他低级问题
-调节每台机器上的内存，不要太多也不要太少

视频服务关键点
1，保持简单和廉价
2，保持简单网络路径，在内容和用户间不要有太多设备
3，使用常用硬件，昂贵的硬件很难找到帮助文档
4，使用简单而常见的工具，使用构建在Linux里或之上的大部分工具
5，很好的处理随机查找(SATA，tweaks)

缩略图服务
1，做到高效令人惊奇的难
2，每个视频大概4张缩略图，所以缩略图比视频多很多
3，缩略图仅仅host在几个机器上
4，持有一些小东西所遇到的问题：
-OS级别的大量的硬盘查找和inode和页面缓存问题
-单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让Ext3允许大目录，但在一个文件系统里存储大量文件不是个好主意
-每秒大量的请求，因为Web页面可能在页面上显示60个缩略图
-在这种高负载下Apache表现的非常糟糕
-在Apache前端使用squid，这种方式工作了一段时间，但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个
-尝试使用lighttpd但是由于使用单线程它陷于困境。遇到多进程的问题，因为它们各自保持自己单独的缓存
-如此多的图片以致一台新机器只能接管24小时
-重启机器需要6-10小时来缓存
5，为了解决所有这些问题YouTube开始使用Google的BigTable，一个分布式数据存储：
-避免小文件问题，因为它将文件收集到一起
-快，错误容忍
-更低的延迟，因为它使用分布式多级缓存，该缓存与多个不同collocation站点工作
-更多信息参考Google Architecture，GoogleTalk Architecture和BigTable

数据库
1，早期
-使用MySQL来存储元数据，如用户，tags和描述
-使用一整个10硬盘的RAID 10来存储数据
-依赖于信用卡所以YouTube租用硬件
-YouTube经过一个常见的革命：单服务器，然后单master和多read slaves，然后数据库分区，然后sharding方式
-痛苦与备份延迟。master数据库是多线程的并且运行在一个大机器上所以它可以处理许多工作，slaves是单线程的并且通常运行在小一些的服务器上并且备份是异步的，所以slaves会远远落后于master
-更新引起缓存失效，硬盘的慢I/O导致慢备份
-使用备份架构需要花费大量的money来获得增加的写性能
-YouTube的一个解决方案是通过把数据分成两个集群来将传输分出优先次序：一个视频查看池和一个一般的集群
2，后期
-数据库分区
-分成shards，不同的用户指定到不同的shards
-扩散读写
-更好的缓存位置意味着更少的IO
-导致硬件减少30%
-备份延迟降低到0
-现在可以任意提升数据库的伸缩性

数据中心策略
1，依赖于信用卡，所以最初只能使用受管主机提供商
2，受管主机提供商不能提供伸缩性，不能控制硬件或使用良好的网络协议
3，YouTube改为使用colocation arrangement。现在YouTube可以自定义所有东西并且协定自己的契约
4，使用5到6个数据中心加CDN
5，视频来自任意的数据中心，不是最近的匹配或其他什么。如果一个视频足够流行则移到CDN
6，依赖于视频带宽而不是真正的延迟。可以来自任何colo
7，图片延迟很严重，特别是当一个页面有60张图片时
8，使用BigTable将图片备份到不同的数据中心，代码查看谁是最近的

学到的东西
1，Stall for time。创造性和风险性的技巧让你在短期内解决问题而同时你会发现长期的解决方案
2，Proioritize。找出你的服务中核心的东西并对你的资源分出优先级别
3，Pick your battles。别怕将你的核心服务分出去。YouTube使用CDN来分布它们最流行的内容。创建自己的网络将花费太多时间和太多money
4，Keep it simple！简单允许你更快的重新架构来回应问题
5，Shard。Sharding帮助隔离存储，CPU，内存和IO，不仅仅是获得更多的写性能
6，Constant iteration on bottlenecks：
-软件：DB，
-OS：硬盘I/O
-硬件：内存，RAID
7，You succeed as a team。拥有一个跨越条律的了解整个系统并知道系统内部是什么样的团队，如安装打印机，安装机器，安装网络等等的人。With a good team all things are possible。

无相关文章，以下随机显示

标签：, ,
]]> http://ourapache.com/archives/82/feed 0 gzip 与 deflate http://ourapache.com/archives/72 http://ourapache.com/archives/72#comments Fri, 06 Feb 2009 06:07:24 +0000 OurApache http://www.ourapache.com/?p=72 新东家还没有报道，就安排先做一个小任务：把 nginx 的 换成 ，问为什么，老大说能省 18 个字节。

在baidu上搜了好久，搜到的中文基本上都是讲 apache 的 gzip（apache 1.3） 和 deflate（apache 2.x）的配置的，仅有的几个跟 nginx 相关的，也逃不出配置文件的范畴。至于原理，算法等等，只有去 Google 英文资料了。

换了关键词，直接搜 zlib ，终于找到一些有用的东西，在 http://www.cppblog.com/jinq0123/archive/2007/07/09/HttpCompressConv.html 处看到这样一段话：

deflate与gzip解压的代码几乎相同，应该可以合成一块代码。
区别仅有：

  1. deflate使用inflateInit()，而gzip使用inflateInit2()进行初始化，比 inflateInit()多一个参数: -MAX_WBITS，表示处理raw deflate数据。因为gzip数据中的zlib压缩数据块没有zlib header的两个字节。使用inflateInit2时要求zlib库忽略zlib header。在zlib手册中要求windowBits为8..15，但是实际上其它范围的数据有特殊作用，见zlib.h中的注释，如负数表示raw deflate。
  2. Apache的deflate变种可能也没有zlib header，需要添加假头后处理。即MS的错误deflate (raw deflate).zlib头第1字节一般是0×78, 第2字节与第一字节合起来的双字节应能被31整除，详见rfc1950。例如Firefox的zlib假头为0×7801，python zlib.compress()结果头部为0x789c。

再去检查 zlib.h 中的注释说明，在 zlib-1.2.3/zlib.h Line 500 的地方发现这样一段话：

The windowBits parameter is the base two logarithm of the window size
(the size of the history buffer). It should be in the range 8..15 for this
version of the library. Larger values of this parameter result in better
compression at the expense of memory usage. The default value is 15 if
deflateInit is used instead.

windowBits can also be -8..-15 for raw deflate. In this case, -windowBits
determines the window size. deflate() will then generate raw deflate data
with no zlib header or trailer, and will not compute an adler32 check value.

windowBits can also be greater than 15 for optional gzip encoding. Add
16 to windowBits to write a simple gzip header and trailer around the
compressed data instead of a zlib wrapper. The gzip header will have no
file name, no extra data, no comment, no modification time (set to zero),
no header crc, and the operating system will be set to 255 (unknown).  If a
gzip stream is being written, strm->adler is a crc32 instead of an adler32.

回过头来看 nginx 和 apache 的实现：

 nginx-0.6.34/src/http/modules/ngx_http_gzip_filter_module.c Line 335：

rc = deflateInit2(&ctx->zstream, (int) conf->level, Z_DEFLATED,
-wbits, memlevel, Z_DEFAULT_STRATEGY);

httpd-2.0.63/modules/filters/mod_deflate.c Line 374:

zRC = deflateInit2(&ctx->stream, c->compressionlevel, Z_DEFLATED,
c->windowSize, c->memlevel,
Z_DEFAULT_STRATEGY);

(Line 153: c->windowSize = i * -1; )

也就是说，nginx 和 apache 在程序里处理的都是 raw deflate data ，windowBits 都是负数，那为什么 Content-Encoding 都写的是 gzip 而不是 deflate 呢？

在 apache 的 mod_deflate.c 里，首先发现了这样一个写入 gzip header 的动作：

       /* RFC 1952 Section 2.3 dictates the gzip header:
*
* +—+—+—+—+—+—+—+—+—+—+
* |ID1|ID2|CM |FLG|     MTIME     |XFL|OS |
* +—+—+—+—+—+—+—+—+—+—+
*
* If we wish to populate in MTIME (as hinted in RFC 1952), do:
* putLong(date_array, apr_time_now() / APR_USEC_PER_SEC);
* where date_array is a char[4] and then print date_array in the
* MTIME position.  WARNING: ENDIANNESS ISSUE HERE.
*/
buf = apr_psprintf(r->pool, “%c%c%c%c%c%c%c%c%c%c”, deflate_magic[0],
deflate_magic[1], Z_DEFLATED, 0 /* flags */,
0, 0, 0, 0 /* 4 chars for mtime */,
0 /* xflags */, OS_CODE);

deflate_magic 是这样定义的：

/* magic header */
static char deflate_magic[2] = { ‘37′, ’213′ };

而 OS_CODE 是在 zutil.h 里定义的，AMIGA 是 1，VAXC 是 2，OS2 是 6，WIN32 是 11，默认 unix 是 3（从这个顺序也可以看出操作系统的发展历史了）

数一下，10个字节，再联想到老大说的 18 个字节，仔细找找，终于在 Line 462 里发现这样一个附加 tail 的动作：

buf = apr_palloc(r->pool, 8) ;
putLong((unsigned char *)&buf[0], ctx->crc);
putLong((unsigned char *)&buf[4], ctx->stream.total_in);

b = apr_bucket_pool_create(buf, 8, r->pool, f->c->bucket_alloc);
APR_BRIGADE_INSERT_TAIL(ctx->bb, b);

不多不少，8个字节。10个字节的头加上 8 个字节的尾巴，就是老大说的多出来的 18 个字节。apache 调用 zlib 的接口产生了 raw defalte 的数据，然后手工的添加了 gzip 头和尾。

同样的，在 nginx 的 ngx_http_gzip_filter_module.c 首先在 Line 179看到 Igor Sysoev 同学很不负责任的定义了这样一个 gzip header：

static u_char  gzheader[10] = { 0x1f, 0x8b, Z_DEFLATED, 0, 0, 0, 0, 0, 0, 3 };

仔细看最后一位！居然直接写了一个 3 ！这会不会导致 windows 上编译的 nginx 在输出 gzip 压缩过的页面的时候，客户端解压不正常？回头有空再去看看 zlib 里关于解压的算法代码中，对于这个 OS_CODE 是怎么处理的吧。

继续寻找，在 Line 351 的地方，作者还写了一段注释（虽然我越看越不明白他在试图表达什么意思）：

        b->memory = 1;
b->pos = gzheader;
b->last = b->pos + 10;

out.buf = b;
out.next = NULL;

/*
* We pass the gzheader to the next filter now to avoid its linking
* to the ctx->busy chain.  zlib does not usually output the compressed
* data in the initial iterations, so the gzheader that was linked
* to the ctx->busy chain would be flushed by ngx_http_write_filter().
*/

大致是说把 gzheader 传给下一个 filter 去处理，这个 filter 只出来 raw deflate 数据，以及附加的 tail 吧。在 Line 605 的地方：

#if (NGX_HAVE_LITTLE_ENDIAN && NGX_HAVE_NONALIGNED)

trailer->crc32 = ctx->crc32;
trailer->zlen = ctx->zin;

#else
trailer->crc32[0] = (u_char) (ctx->crc32 & 0xff);
trailer->crc32[1] = (u_char) ((ctx->crc32 >> 8) & 0xff);
trailer->crc32[2] = (u_char) ((ctx->crc32 >> 16) & 0xff);
trailer->crc32[3] = (u_char) ((ctx->crc32 >> 24) & 0xff);

trailer->zlen[0] = (u_char) (ctx->zin & 0xff);
trailer->zlen[1] = (u_char) ((ctx->zin >> 8) & 0xff);
trailer->zlen[2] = (u_char) ((ctx->zin >> 16) & 0xff);
trailer->zlen[3] = (u_char) ((ctx->zin >> 24) & 0xff);
#endif

幸亏有 IBM MOTOROLA  们造了 Big Endian 机器，这样一来，这段代码的意思再明白不过了。

连上网搜资料加读代码，一共花了大约3个小时，到现在，大约清楚了这么几个问题：

  1. deflate 是最基础的算法，在 zlib 里面有实现
  2. gzip 在 deflate 的 raw data 前增加了 10 个字节的 gzheader，尾部添加了 8 个字节的校验字节（可选 crc32 和 adler32） 和长度标识字节，gzip 的 magic number 是 0x1f, 0x8b
  3. zlib 自己也有 header 和尾部校验的数据，如果使用 deflateInit 而不是 deflateInit2，或者 windowBits 设置为正数8~15的话
  4. zlib windowBits 设置为 16 的时候，zlib 自己会产生一个 gzip 的头和尾，这种情况下 OS_CODE 被设置为 255（unknown），尾部校验使用 crc32 。问题是，既然 zlib 本身就提供了这种功能，为什么 apache 和 nginx 不用，反而都选择手工添加呢？
  5. 为 nginx 添加 deflate 支持，只需要把输出中的头，尾去掉，并把 Content-Encoding 改为 deflate 即可。18 个字节，就这样省下来了。

参考资料：

PS，在腾讯最后一天上班，并祝所有爱我的和我爱的人小年快乐！大年也快乐！

相关文章

标签：, ,
]]> http://ourapache.com/archives/72/feed 0