网站加速基础知识
0/5 (0投票)
2004年3月25日
22分钟阅读
37482
本文概述了一种常识性、经济高效的方法，旨在降低总拥有成本并提高网站和Web应用程序性能。
这是我们CodeProject赞助商的展示评论。这些评论旨在为您提供我们认为对开发人员有用且有价值的产品和服务信息。
性能始于Web服务器
摘要
本文概述了一种常识性、经济高效的方法，旨在根据两个简单原则降低总拥有成本并提高网站和Web应用程序性能
- 尽可能少地发送数据
- 尽可能不频繁地发送
在我们研究每种策略时，我们将从三个关键指标的角度探讨对各种不同网站和应用程序的潜在好处
- 更快的网页加载和改进的用户体验，转化为更高的收入和更高的效率
- 减少带宽利用率并增加持续节约
- 整合交付现有站点和应用程序所需的服务器资源数量
测量网站性能
从最终用户的角度来看，网站性能最有价值的衡量标准是显示请求的网页所需的时间量。页面加载时间最重要的指标是首次字节时间（TTFB）。TTFB定义为将请求页面的第一个字节传送到最终用户所需的时间量，它代表访问者对网站或应用程序正在响应的初步确认。首次字节时间之后是吞吐量指标，即网站或应用程序在给定时间段内可以服务的请求数量。用户期望文本、图像和其他元素能够快速、有条不紊地加载——这些指标中的任何一项失败都会导致性能不佳的感觉，这很快会导致访问者沮丧并放弃网站。
如果预算足够大，用于重大的基础设施改进，任何服务器与互联网的连接总能得到改善。然而，我们感兴趣的是由于不可控的网络条件导致网站性能的这些常见衡量指标下降，并且昂贵、复杂的硬件解决方案不可行或不理想的情况。随着网站和应用程序因庞大的代码和第三方应用程序而变得日益复杂，用户（其中许多人仍在使用拨号连接）必须下载越来越多的数据才能访问网站或应用程序。即使在企业外联网等快速广域网（WAN）上提供高效的应用程序，网络中的某些部分也总是容易出现瓶颈，用户可能会遇到无法接受的长时间页面加载。如果Web服务器的源代码和管理软件没有优化以跟上不断增长的网站流量和应用程序复杂性，管理员将浪费服务器资源和带宽，用户将面临速度更慢、更容易放弃的网站。
万维网联盟进行的案例研究已证明优化内容和内容交付可以提高网页交付速度，Andy King 等网站优化专家也对此表示支持。直到最近，内容优化仍需要困难且耗时的手动编码，但现在可以通过实施廉价的软件工具和对开发和部署流程进行不显眼的更改来实现。同样，虽然内容交付优化曾需要昂贵的硬件和基础设施投资，但如今可以通过经济实惠、易于部署的服务器软件工具来完成。
代码优化、缓存控制和HTTP压缩是专注于尽可能少、尽可能不频繁地发送数据以优化现有Web应用程序前端代码和向Web浏览器交付内容的源Web服务器性能的策略。
代码优化
源代码优化是“尽可能少地发送数据”原则的一个重要但经常被忽视的应用。作为一种网站或应用程序加速策略，其主要优点是该技术可以在不要求源服务器进行任何额外处理的情况下，大幅减少网络负载。源代码优化应作为部署前步骤实施，所有对前端源代码（包括标记、样式表和客户端脚本）的添加和更改通常在上传到“实时”生产站点或应用程序之前都会经过此步骤。
超越空白字符移除
虽然传统的“空白字符移除”（消除多余的空格、制表符、换行符和注释）可以在典型的HTML和CSS文件中节省10%到15%的少量空间，但仿照传统软件编译器设计的代码优化器可以在所有基于文本的文件上实现更高水平的优化。因为它具有站点范围的上下文感知能力，这样的工具可以采用更积极的策略，包括压缩函数和变量名、重新映射冗长的标识符和URL或URI路径，并通过使用真正的JavaScript解析器，甚至简化代码行。
直到最近，这种方法一直是JavaScript专家独有的领域，他们有时间有耐心编写非常简洁的代码。此外，手动编码仍然对站点扩展和代码可读性存在限制，因为它为开发和部署维护了一个单一的优化代码库。使用像w3compiler这样的下一代开发工具更安全、更高效，这些工具既保留了对开发人员友好的网站文件版本，也保留了专门用于网络交付的高度优化版本。
当作为最终部署前流程集成到正常的开发人员工作流中时，优化可以应用于不断增长的网站，而不会破坏现代Web前端中普遍存在的外部引用，包括在一个文件中定义或初始化并在另一个文件中引用的函数和变量名。这种高度激进的优化方法可以使JavaScript文件平均节省20%到30%，在经过测试的“真实世界”案例中甚至高达70%。
对激进源代码优化的一种合理反对是，它会降低在Web浏览器中“查看源代码”时代码的可读性。这是一个特别过时的反对意见，因为它本质上对最终用户没有任何价值，事实上，它可能通过让竞争对手轻易复制独特的客户端功能而构成安全威胁。更令人不安的是，未优化的源代码也为黑客通过“源代码筛选”寻找其潜在漏洞的线索来对Web应用程序进行侦察提供了便利。可读且注释良好的代码在初始开发过程中显然是一个优势，但它不适合用于交付业务关键型Web应用程序的格式。
代码优化代表了通过减少服务器必须交付给最终用户的初始网络负载来改善网站和应用程序性能的第一步。一旦该内容在开发人员端得到优化，注意力就转移到如何以其最优化和最高效的形式交付该内容。
缓存控制
什么是缓存？它如何应用于网络？
缓存是计算机科学中一个众所周知的概念：当程序不断访问同一组指令时，通过将这些指令存储在RAM中可以实现巨大的性能优势。这可以防止程序在执行过程中数千甚至数百万次访问磁盘，而是从RAM中快速检索它们。Web上的缓存与此类似，它避免了每次请求资源时都往返源Web服务器，而是从本地计算机的浏览器缓存或更靠近用户的代理缓存中检索文件。
Web上最常见的缓存是用户Web浏览器（如Internet Explorer、Mozilla和Netscape）中的缓存。当通过浏览器请求网页、图像或JavaScript文件时，这些资源中的每一个都可能附带HTTP头指令，告诉浏览器该对象可以被视为“新鲜”的时间长度，即资源可以直接从浏览器缓存而不是从源服务器或代理服务器检索的时间长度。由于浏览器代表了离最终用户最近的缓存，因此当内容可以存储在那里时，它提供了最大的性能优势。
常见的HTTP请求/响应周期
当浏览器对网站进行初始请求时——例如，对主页的GET请求——服务器通常返回200 OK响应代码和主页。此外，服务器将为该页面中引用的每个依赖资源（如图形、样式表和JavaScript文件）返回200 OK响应和指定的对象。如果没有适当的 freshness 头，对该主页的后续请求将导致对每个资源的“条件”GET请求。此条件GET使用其可用于比较的任何方法（通常是资源的Last-Modified时间戳）验证资源的 freshness（如果Last-Modified不可用，例如动态文件，则会发送一个无条件GET，完全绕过缓存）。通过往返服务器，将确定服务器上项目的Last-Modified值是否与浏览器中缓存项目的Last-Modified值匹配，然后服务器将返回一个带有200 OK响应的新版本，或者返回304 Not-Modified响应头，指示缓存中的文件有效并可以再次使用。
这种验证的一个主要缺点是，对于Web上的大多数文件，进行往返验证请求所需的时间几乎与实际从服务器返回资源所需的时间一样长。当不必要地进行此操作时，会浪费带宽并减慢页面加载时间。在默认设置下，在没有足够的缓存控制头的情况下，主导的Internet Explorer浏览器将在每个新会话开始时发送一个条件GET。这意味着大多数重复访问网站或应用程序的用户都在不必要地一次又一次地请求相同的资源。
幸运的是，有一种简单的方法可以消除这些不必要的往返服务器。如果每次原始响应都带有 freshness 指示符，浏览器可以在后续请求中直接从浏览器缓存中提取文件，而无需服务器验证，直到达到分配给对象的过期时间。当资源直接从用户的浏览器缓存中检索时，网站的响应速度会显著提高，给人一种网站或应用程序更快的印象。当用户在同一浏览器会话中重新访问网页时，这种缓存检索行为可以清楚地看到——图像几乎是瞬间渲染的。当正确的缓存控制头被整合到服务器的响应中时，只要对象未过期或用户手动清空其缓存，这种性能改进和网络流量减少将持续任意数量的后续会话。
在腐烂的鱼和燃烧的货币之间
通过HTTP头进行Web缓存在HTTP/1.1，RFC 2616的第13节中概述。规范本身的语言有助于定义Web上缓存的预期效果和权衡。该规范为用户代理（浏览器）在未充分利用缓存时发出的明确警告提供了建议。对于浏览器设置配置为阻止对过期对象进行验证的情况，规范建议用户代理可以显示一张腐烂的鱼的图片。对于不必要地验证（或重新发送，尽管是新鲜的）对象的情况，建议的图片是燃烧的货币，以便用户“不会无意中消耗过多的资源或遭受过度的延迟”。
服务器可以使用缓存控制头向浏览器提供准确处理网站资源所需的信息。通过设置值以防止缓存高度易变的对象，可以帮助确保文件不会受到“烂鱼待遇”。对于通过设计长时间保持一致的对象，例如网站的导航按钮和徽标，设置较长的过期时间可以避免“燃烧货币待遇”。无论对象的期望生命周期如何，没有充分的理由说明每个资源不应在每次响应中都附带与缓存相关的头信息。
各种与缓存相关的头部优于 Last-Modified 头部，因为它们不仅能提供关于资源版本的信息，还能让管理员控制条件 GET 或对 Web 服务器的验证请求发生的频率。编写良好的缓存控制头部有助于确保浏览器在必要时总是检索最新的资源，或者告知浏览器验证检查可以推迟多久。这可以通过消除多余的验证来显著减少网络通信，并有助于保持信道畅通，以便进行动态或其他文件的基本检索。
Expires 头（用于 HTTP 1.0）和带有其 max-age 指令的 Cache-control 头（用于 HTTP/1.1）允许 Web 开发人员定义每个资源保持新鲜的时间。该值指定了一段时间，在此之后，浏览器需要再次与服务器核对以验证对象是否已更新。
通过使用像这个Cacheability Engine这样的缓存控制头检查工具，可以很容易地通过Last-Modified头值看到许多图片、样式表和JavaScript文件在多久没有更改。通常，某些图片自上次修改以来已经过了一年甚至更长时间。这意味着过去一年中对这些对象的所有往返Web服务器的验证都是不必要的，从而导致更高的带宽开销和用户页面加载速度变慢。
缓存控制在Web服务器性能中承担着繁重的工作
为网站制定缓存策略——确定哪些资源不应被缓存，哪些资源应该被缓存，以及缓存多长时间——是提高网站性能的关键一步。如果资源是动态页面，并且每次请求都包含时间敏感的数据库查询，那么应该使用缓存控制头来确保页面永远不会被缓存。如果页面中的数据是特定于用户或会话的，但时间敏感度不高，则缓存控制指令可以将缓存限制在用户的私人浏览器缓存中。任何其他在网站中多次访问的不变资源，例如徽标或导航图形，都应在初始请求期间仅检索一次，之后尽可能不频繁地进行验证。
这就提出了一个问题：“谁最清楚缓存策略应该是什么？”在Microsoft IIS Web服务器上，目前网站管理员通过MMC控制面板拥有对缓存控制相关标头的唯一访问权限，这表明管理员最适合确定策略。然而，通常情况下，最熟悉网站资源的是应用程序开发人员，因此他们最适合建立和控制策略。让开发人员能够使用基于规则的方法为整个网站的资源设置缓存控制标头是理想的，因为它允许他们为单个对象、目录对象或基于MIME类型设置适当的策略。开发人员缓存管理的额外好处是减轻了站点管理员的工作量。尝试使用CacheRight进行Microsoft IIS缓存控制管理和集中式缓存规则管理。
无论您的网站或应用程序做什么，或者您的网络环境包含什么，通过为网站上的资源实施缓存策略，都可以提高性能。通过消除不必要的往返服务器，缓存控制在实现尽可能少、尽可能不频繁地发送数据的双重目标方面大有帮助。然而，在资源是动态的或快速变化的情况下，每次请求都无法避免往返服务器。在这种情况下，仍可以通过使用HTTP压缩来最小化有效负载。
HTTP压缩
低成本、高效能的性能调优不容忽视
HTTP压缩是一个长期建立的Web标准，直到现在才受到应有的关注。其实现早在HTTP/1.0 (RFC 1945) 中就已经草拟，并于1999年在HTTP/1.1 (RFC 2616 涵盖 accept-encoding 和 content-encoding) 中完全指定。WC3 早在1997年进行的案例研究就证明了压缩能够显著减少带宽使用并提高Web性能（参见他们的拨号和局域网压缩研究）。
在HTTP压缩的情况下，标准 gzip 或 deflate 编码方法应用于 HTTP 响应的有效负载，在资源通过 Web 传输之前对其进行显著压缩。Gzip (RFC 1952) 是一种无损压缩数据格式，几十年来在计算机科学中得到了广泛应用。Gzip 使用的 deflate 算法 (RFC 1951) 与 zip 和 zlib 等常见库共享，是 LZ77 (Lempel-Ziv 1977) 算法的开源、免专利变体。由于应用压缩和解压缩的稳定性已得到验证，该技术自 4.X 版本早期 (针对 Internet Explorer 和 Netscape) 以来已在所有主流浏览器实现中得到支持。
虽然 gzip 和 deflate 的应用相对简单，但有两个主要因素限制了 HTTP 压缩作为网站和应用程序性能增强策略的广泛采用。最值得注意的是，早期服务器实现和支持压缩的浏览器中存在的孤立错误导致服务器向实际上无法处理压缩资源的浏览器发送压缩资源。
当数据使用 gzip 或 deflate 等压缩格式编码时，它通过需要一种内容协商类型，增加了 HTTP 请求/响应交互的复杂性。每当应用压缩时，它会创建资源的两个版本：一个压缩版本（适用于可以处理压缩数据的浏览器）和一个未压缩版本（适用于不能处理压缩数据的浏览器）。浏览器只需要准确地请求它想要接收哪个版本。然而，在某些情况下，一些浏览器在其 HTTP 请求头中表示能够处理某种 MIME 类型资源的 gzip 压缩版本，但实际上它们不能。这些浏览器错误导致了许多针对 Microsoft IIS Web 服务器的第三方压缩工具，这些工具使管理员能够正确配置其服务器以处理每个有问题浏览器和 MIME 类型所需的异常情况。
阻碍HTTP压缩发展的第二个因素是某种历史和经济巧合。2001年前庞大的技术预算和对高带宽互联网连接普及的宏伟预测，导致了许多更复杂和昂贵的解决方案来应对由于高延迟网络条件造成的性能下降。尽管安全实现HTTP压缩的要素已经到位，但Akamai和其他采用边缘缓存技术的内容分发网络却吸引了市场的注意力。虽然HTTP压缩不应被视为这些更昂贵选项的直接替代品，但在可靠的配置和管理工具的帮助下，压缩应作为性能增强的补充性、经济实惠的初步步骤。
压缩将提供更小的Web传输负载和更高的性能
通常，HTTP 压缩在服务器端作为过滤器或模块实现，当服务器发出响应时，该过滤器或模块会将 gzip 算法应用于响应。任何基于文本的内容都可以压缩。对于纯静态内容，例如标记、样式表和 JavaScript，通常可以缓存压缩表示，从而减轻 CPU 反复压缩同一文件的负担。当压缩真正的动态内容时，通常每次请求时都必须重新压缩（尽管对于准动态内容，如果压缩引擎足够智能，可能会有例外）。这意味着需要在处理器利用率和有效负载减少之间进行权衡。高度可配置的压缩工具使管理员能够通过设置 Web 站点上所有资源的压缩级别来调整处理器利用率和压缩资源大小之间的权衡点，从而避免在“过度压缩”对象上浪费 CPU 周期，这些对象可能在较低级别设置下与在较高级别设置下同样紧密地压缩。这还允许将二进制图像文件排除在 HTTP 压缩之外，因为大多数图像在 Illustrator 等编辑器中创建时就已经优化。避免不必要的图像重新压缩，因为这实际上可能会增加其文件大小或引入失真。
压缩在文本类型文件上可显著节省文件大小。节省的确切百分比将取决于文件中字符序列的冗余或重复程度，但在许多情况下，单个文件可能减少70%甚至80%。即使是相对不均匀的文本文件通常也会缩小60%。请记住，在查看网站整体节省时，这些极高的压缩率将被无法有效压缩的图像MIME类型所抵消。典型网站或应用程序的总压缩节省可能在30%到40%之间。这个免费在线工具将帮助您查看压缩任何Web资源所获得的文件大小节省和传输改进。
如果带宽节省是主要目标，策略应该是压缩所有基于文本的输出。理想情况下，这不仅应包括静态文本文件（如HTML和CSS），还应包括生成文本媒体MIME类型输出的文件（如ASP和ASP.NET文件），以及基于文本但属于其他媒体类型的文件（如外部JavaScript文件）。这个免费在线工具将帮助您估算压缩任何Web资源所能实现的带宽成本节省。
像IBM这样的案例研究已经证明了使用压缩可以实现的性能改进，尤其是在包含高流量和高延迟区域的广域网环境中。一般原则很明确：管道越拥挤，路由中的跳数越多，发送尽可能小的有效载荷的潜在收益就越大。当资源大小大幅减小（就像文本文件应用gzip压缩后那样），发送的数据包数量也随之减少，从而降低了数据包丢失和重传的可能性。所有这些HTTP压缩的优势都带来了更快、更高效的传输。
在Microsoft IIS 4.0和5.0 Web服务器上，httpZip是最佳的压缩解决方案，因为它解决了Windows NT/2000在功能、自定义和报告方面的一些不足，这些不足催生了第三方工具市场。随着Windows Server 2003和IIS 6.0的发布，Microsoft选择将压缩功能作为优先事项，其内部IIS 6.0压缩软件确实有效——尽管您必须深入IIS元数据库才能对其进行简单“开/关”决策之外的管理。您可以使用像ZipEnable这样的工具来解锁并极大地增强IIS 6.0内置压缩的配置和管理选项。
让您的Web服务器成为更快、更高效的资源
在探索了这些Web服务器性能优化的三种技术之后，您如何将这些知识付诸实践？我们上面提到了我们的一些Port80软件工具，但以下指南将帮助您找到适合您自己Web服务器性能策略的正确解决方案。
选择代码优化工具
一个有效的源代码优化器应该将Web标准意识与进行激进优化的能力相结合，只有将整个站点作为一个整体处理才能做到这一点。完全解析代码的能力是这里的关键。在JavaScript和DHTML优化的情况下尤其如此，如果按文件进行优化，外部引用很容易被破坏。
选择缓存控制工具
缓存控制工具应提供以基于规则的方法实施缓存控制策略的能力，以便以最适当和最有效的方式缓存和验证每个资源。它还应包含一种机制，允许站点和应用程序开发人员参与这些规则的生成，而无需服务器管理员干预。
选择HTTP压缩工具
源服务器压缩解决方案首先应该是高度可配置的。尽管现代浏览器广泛支持压缩，但仍存在一些已知错误。这些潜在问题最好通过在服务器端正确配置每个特定浏览器的问题MIME类型的异常来解决。对于非常小或非常大的文件，或出于其他特殊原因不应压缩的文件，也可以做出类似的异常。能够调整不同文件类型的压缩级别并能够监控和记录压缩结果也很有帮助。
强大的性能是您网络存在的基础
为了实现最大的网站和应用程序性能，至关重要的是要审视完整的链条——从源代码开发、服务器端进程、服务器与最终用户之间的连接，一直到最终用户的网络浏览器——并检查链条中的每个环节，寻找潜在的陷阱和改进的机会。实施代码优化、缓存控制和压缩的三重策略将显著减少传输的网站和应用程序数据量，并确保您的数据以最有效的方式发送。利用您现有Web基础设施的资源，采用这里介绍的策略，这些策略都不是特别昂贵。在开发和部署实践中实施这些不显眼的更改将有助于您的Web开发人员、站点管理员和用户。结果将不言自明：更高效的Web服务器、更低的带宽费用以及为您的用户带来更快的使用体验，所有这些都有助于推动收入增长、降低成本并使您的Web系统现代化。