本文为译文，原文为High Performance Web Sites  章节B

原书下载地址：http://pan.baidu.com/s/1pJocRwB

    在我们进行深入分析如何优化网页性能之前，首先要了解超文本传输协议（Hypertext transfer protocol, HTTP）中对性能产生影响的部分。HTTP是连接浏览器与WEB服务器之间交互的桥梁，它是由万维网联盟（World Wide Web Consortium, W3C）和互联网工程任务组（Internet Engineering Task Force ,IETF）联合规范制定，相关文件RFC 2616。HTTP/1.1 是目前最常用的版本，但是依旧还有浏览器与服务器继续在使用HTTP/1.0 。

       HTTP是一个由请求与响应组成的客户端与服务端交互协议。浏览器发送一个HTTP请求到指定的URL地址，持有此URL地址的WEB服务器将反馈回一个HTTP请求。像许多互联网服务里一样，这项协议采用简单的明文格式。请求的类型有GET、POST、HEAD、PUT、DELETE、OPTIONS 和 TRACE等。我们把注意力还是放在最重要最常见的GET请求上。

       一个GET请求包含了URL地址，同时在URL地址后带上了报头内容。而HTTP响应包含了状态码、报头和内容体。下面的这个例子显示了当请求脚本yahoo_2.0.0-b2.js时可能产生的HTTP报头内容。

请求脚本yahoo_2.0.0-b2.js

Compression

压缩

       HTTP响应可以使用压缩来减小传输体积，当然这要求浏览器和WEB服务器均支持此项功能。浏览器要支持压缩，需要在请求报头中加入Accept-Encoding，服务器端要支持需要在返回报头中加入Content-Encoding。

采用压缩请求脚本yahoo_2.0.0-b2.js

       请注意返回的内容体是如何被压缩的。章节4将解释如何打开压缩的方法，并且还会提醒说明由于代理缓存的原因，如何导致边界情况的发生。同时，还是讨论关于Vary和Cache-Control 报头参数。

Conditional GET Request

条件GET请求

      如果浏览器缓存中已经持有一个HTML内容元素的副本，但却并不能保证这个缓存的内容是不是依旧有效的，这个时候，一个条件GET请求就出现了。如果缓存的内容依旧有效，浏览器将会使用缓存来响应，这样响应得速度更快，用户的体验性也更好。

      通常情况下，一个缓存的内容是否有效主要取决于它最近一次的被修改时间，而浏览器是根据返回报头中的Last-Modified属性来获取到这个时间。浏览器会在请求报头中加入If-Modified-Since 属性到服务器端。这就好像浏览器再说：“这个内容元素我已经有了一个副本，最近修改时间是这样的，我就可以直接用它吗？”

带条件的GET请求

      如果这个内容元素从那个指定时间点开始到现在还没有发生修改，服务器将返回一个“304 Not Modified” 状态码，然后跳过响应的内容体，这样也使得返回更加简短而快速。在协议HTTP/1.1 中，ETag 和 If-None-Match 报头属性是另外一种执行条件GET请求的方式，我们将在章节13中进行讨论。

Expires

有效时间

      条件GET请求和304响应的确能够加快页面的加载速度，但是他们依旧需要能够在客户端与服务器端之间进行来回验证。报头中的Expires参数可以很好免除这种检查的烦恼：它能够明确指出了浏览器是否能够还能够继续使用一个内容元素的缓存。

带有效时间

      当浏览器获取到响应报文中的Expires参数时，它便将此内容元素以及其有效时间一起存入到缓存中。只要这个元素还没有到期，浏览器将会使用缓存的元素版本，以尽可能避免产生HTTP请求。章节3将会进一步详细讨论Expires与Cache-Control参数

Keep-Alive

长连接

       HTTP在产生在TCP七层结构中的最顶层。在早期的HTTP的具体实现情形中，每个HTTP请求需要单独新开启一个socket连接。这其实是非常低效的做法，很多HTTP请求其实指向的是同一个服务器。比如，一个页面中，大部分图片请求都去向了同一个图片服务器。针对这种在同一个服务器下反复“开启-关闭”的低效做法，持续连接（也就是长连接）应运而生。浏览器和服务器在报头中加入Connection参数来表示对长连接的支持。

长连接参数

       浏览器或者服务器可以通过在报头中加入“Connection: close”配置项来关闭这个连接。严格来说，Connection: keep-alive 配置项并不是HTTP/1.1 中要求必须有的，但是绝大部分的浏览器和服务器依旧使用它。

       在HTTP/1.1中有定义到管道技术，它允许多个请求在无需等待响应的情况下，共用一个socket链接。管道技术比长连接有这个更好的性能表现。可惜的是，管道技术在IE中并未得到支持（包括IE7以下），并且在FireFox 2中被默认关闭了。所以，在管道技术被更加广泛运用之前，长连接将是浏览器与服务器之间更有效利用socket链接的HTTP链接方式。而对于HTTPS来说更是如此，因为每建立一个安全的socket链接要花费更多时间。

【译者注】

考虑到本书为2007年出版，所以关于管道技术问题，我在这里进行了进一步的查询，发现到目前为止，大部分浏览器对管道技术的支持依旧非常有限：

http://en.wikipedia.org/wiki/HTTP_pipelining#Implementation_in_web_browsers

以下我便不一一翻译了，基本说的主流浏览器里，除了Opera进行支持了以外，其余的要么完全未实现此功能，要么默认关闭。

Implementation in web browsers[edit]

Out of all the major browsers, only Opera based on Presto layout engine had a fully working implementation that was enabled by default. In all other browsers HTTP pipelining is disabled or not implemented.

Internet Explorer 8 does not pipeline requests, due to concerns regarding buggy proxies and head-of-line blocking.

Mozilla browsers (such as Mozilla Firefox, SeaMonkey and Camino) support pipelining, however it is disabled by default. Pipelining is disabled by default to avoid issues with misbehaving servers.When pipelining is enabled, Mozilla browsers use some heuristics, especially to turn pipelining off for older IIS servers.

Konqueror 2.0 supports pipelining, but it's disabled by default.[citation needed]

Google Chrome supports pipelining for HTTP in the stable release as a non-default option (starting with version 18). There is no support for pipelining HTTPS yet. As of version 26, the flag to enable HTTP pipelining in Chrome has been disabled.