本文為譯文，原文為High Performance Web Sites? 章節(jié)B
? ? 在我們進(jìn)行深入分析如何優(yōu)化網(wǎng)頁性能之前，首先要了解超文本傳輸協(xié)議（Hypertext transfer protocol, HTTP）中對性能產(chǎn)生影響的部分。HTTP是連接瀏覽器與WEB服務(wù)器之間交互的橋梁，它是由萬維網(wǎng)聯(lián)盟（World Wide Web Consortium, W3C）和互聯(lián)網(wǎng)工程任務(wù)組（Internet Engineering Task Force ,IETF）聯(lián)合規(guī)范制定，相關(guān)文件RFC 2616。HTTP/1.1 是目前最常用的版本，但是依舊還有瀏覽器與服務(wù)器繼續(xù)在使用HTTP/1.0 。
? ? ? ?HTTP是一個由請求與響應(yīng)組成的客戶端與服務(wù)端交互協(xié)議。瀏覽器發(fā)送一個HTTP請求到指定的URL地址，持有此URL地址的WEB服務(wù)器將反饋回一個HTTP請求。像許多互聯(lián)網(wǎng)服務(wù)里一樣，這項協(xié)議采用簡單的明文格式。請求的類型有GET、POST、HEAD、PUT、DELETE、OPTIONS 和 TRACE等。我們把注意力還是放在最重要最常見的GET請求上。
? ? ? ?一個GET請求包含了URL地址，同時在URL地址后帶上了報頭內(nèi)容。而HTTP響應(yīng)包含了狀態(tài)碼、報頭和內(nèi)容體。下面的這個例子顯示了當(dāng)請求腳本yahoo_2.0.0-b2.js時可能產(chǎn)生的HTTP報頭內(nèi)容。
Compression
壓縮
? ? ? ?HTTP響應(yīng)可以使用壓縮來減小傳輸體積，當(dāng)然這要求瀏覽器和WEB服務(wù)器均支持此項功能。瀏覽器要支持壓縮，需要在請求報頭中加入Accept-Encoding，服務(wù)器端要支持需要在返回報頭中加入Content-Encoding。
? ? ? ?請注意返回的內(nèi)容體是如何被壓縮的。章節(jié)4將解釋如何打開壓縮的方法，并且還會提醒說明由于代理緩存的原因，如何導(dǎo)致邊界情況的發(fā)生。同時，還是討論關(guān)于Vary和Cache-Control 報頭參數(shù)。
Conditional GET Request
條件GET請求
? ? ? 如果瀏覽器緩存中已經(jīng)持有一個HTML內(nèi)容元素的副本，但卻并不能保證這個緩存的內(nèi)容是不是依舊有效的，這個時候，一個條件GET請求就出現(xiàn)了。如果緩存的內(nèi)容依舊有效，瀏覽器將會使用緩存來響應(yīng)，這樣響應(yīng)得速度更快，用戶的體驗性也更好。
? ? ? 通常情況下，一個緩存的內(nèi)容是否有效主要取決于它最近一次的被修改時間，而瀏覽器是根據(jù)返回報頭中的Last-Modified屬性來獲取到這個時間。瀏覽器會在請求報頭中加入If-Modified-Since 屬性到服務(wù)器端。這就好像瀏覽器再說：“這個內(nèi)容元素我已經(jīng)有了一個副本，最近修改時間是這樣的，我就可以直接用它嗎？”
? ? ? 如果這個內(nèi)容元素從那個指定時間點開始到現(xiàn)在還沒有發(fā)生修改，服務(wù)器將返回一個“304 Not Modified” 狀態(tài)碼，然后跳過響應(yīng)的內(nèi)容體，這樣也使得返回更加簡短而快速。在協(xié)議HTTP/1.1 中，ETag 和 If-None-Match 報頭屬性是另外一種執(zhí)行條件GET請求的方式，我們將在章節(jié)13中進(jìn)行討論。
Expires
有效時間
? ? ? 條件GET請求和304響應(yīng)的確能夠加快頁面的加載速度，但是他們依舊需要能夠在客戶端與服務(wù)器端之間進(jìn)行來回驗證。報頭中的Expires參數(shù)可以很好免除這種檢查的煩惱：它能夠明確指出了瀏覽器是否能夠還能夠繼續(xù)使用一個內(nèi)容元素的緩存。
? ? ? 當(dāng)瀏覽器獲取到響應(yīng)報文中的Expires參數(shù)時，它便將此內(nèi)容元素以及其有效時間一起存入到緩存中。只要這個元素還沒有到期，瀏覽器將會使用緩存的元素版本，以盡可能避免產(chǎn)生HTTP請求。章節(jié)3將會進(jìn)一步詳細(xì)討論Expires與Cache-Control參數(shù)
Keep-Alive
長連接
? ? ? ?HTTP在產(chǎn)生在TCP七層結(jié)構(gòu)中的最頂層。在早期的HTTP的具體實現(xiàn)情形中，每個HTTP請求需要單獨新開啟一個socket連接。這其實是非常低效的做法，很多HTTP請求其實指向的是同一個服務(wù)器。比如，一個頁面中，大部分圖片請求都去向了同一個圖片服務(wù)器。針對這種在同一個服務(wù)器下反復(fù)“開啟-關(guān)閉”的低效做法，持續(xù)連接（也就是長連接）應(yīng)運(yùn)而生。瀏覽器和服務(wù)器在報頭中加入Connection參數(shù)來表示對長連接的支持。
? ? ? ?瀏覽器或者服務(wù)器可以通過在報頭中加入“Connection: close”配置項來關(guān)閉這個連接。嚴(yán)格來說，Connection: keep-alive 配置項并不是HTTP/1.1 中要求必須有的，但是絕大部分的瀏覽器和服務(wù)器依舊使用它。
? ? ? ?在HTTP/1.1中有定義到管道技術(shù)，它允許多個請求在無需等待響應(yīng)的情況下，共用一個socket鏈接。管道技術(shù)比長連接有這個更好的性能表現(xiàn)?？上У氖?，管道技術(shù)在IE中并未得到支持（包括IE7以下），并且在FireFox 2中被默認(rèn)關(guān)閉了。所以，在管道技術(shù)被更加廣泛運(yùn)用之前，長連接將是瀏覽器與服務(wù)器之間更有效利用socket鏈接的HTTP鏈接方式。而對于HTTPS來說更是如此，因為每建立一個安全的socket鏈接要花費更多時間。
【譯者注】
考慮到本書為2007年出版，所以關(guān)于管道技術(shù)問題，我在這里進(jìn)行了進(jìn)一步的查詢，發(fā)現(xiàn)到目前為止，大部分瀏覽器對管道技術(shù)的支持依舊非常有限：
http://en.wikipedia.org/wiki/HTTP_pipelining#Implementation_in_web_browsers
以下我便不一一翻譯了，基本說的主流瀏覽器里，除了Opera進(jìn)行支持了以外，其余的要么完全未實現(xiàn)此功能，要么默認(rèn)關(guān)閉。
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.
