第1章 HTTP概述

Web瀏覽器、服務器和相關的Web應用程序都是通過HTTP相互通信的。HTTP是現代全球因特網中使用的公共語言。

本章是對HTTP的簡要介紹。在本章中可以看到Web應用程序是如何使用HTTP進行通信的，這樣就可以對HTTP如何完成其工作有個大概印象。我們將特別介紹以下方面的內容：

· Web客戶端與服務器是如何通信的；

·（表示Web內容的）資源來自何方；

· Web事務是怎樣工作的；

· HTTP通信所使用的報文格式；

· 底層TCP網絡傳輸；

· 不同的HTTP協議變體；

· 因特網上安裝的大量HTTP架構組件中的一部分。

我們有很多話題要討論，就此開始HTTP之旅吧。

1.1 HTTP——因特網的多媒體信使

每天，都有數以億萬計的JPEG圖片、HTML頁面、文本文件、MPEG電影、WAV音頻文件、Java小程序和其他資源在因特網上游弋。HTTP可以從遍布全世界的Web服務器上將這些信息塊迅速、便捷、可靠地搬移到人們桌面上的Web瀏覽器上去。

HTTP使用的是可靠的數據傳輸協議，因此即使數據來自地球的另一端，它也能夠確保數據在傳輸的過程中不會被損壞或產生混亂。這樣，用戶在訪問信息時就不用擔心其完整性了，因此對用戶來說，這是件好事。而對因特網應用程序開發人員來說也同樣如此，因為這樣就無需擔心HTTP通信會在傳輸過程中被破壞、復制或產生畸變了。開發人員可以專注于應用程序特有細節的編寫，而不用考慮因特網中存在的一些缺陷和問題。

下面，就讓我們來近距離地觀察一下HTTP是如何傳輸Web流量的。

1.2 Web客戶端和服務器

Web內容都是存儲在Web服務器上的。Web服務器所使用的是HTTP協議，因此經常會被稱為HTTP服務器。這些HTTP服務器存儲了因特網中的數據，如果HTTP客戶端發出請求的話，它們會提供數據。客戶端向服務器發送HTTP請求，服務器會在HTTP響應中回送所請求的數據，如圖1-1所示。HTTP客戶端和HTTP服務器共同構成了萬維網的基本組件。

可能你每天都在使用HTTP客戶端。最常見的客戶端就是Web瀏覽器，比如微軟的Internet Explorer或網景的Navigator。Web瀏覽器向服務器請求HTTP對象，并將這些對象顯示在你的屏幕上。

瀏覽一個頁面時（比如http://www.oreilly.com/index.html），瀏覽器會向服務器www.oreilly.com發送一條HTTP請求（參見圖1-1）。服務器會去尋找所期望的對象（在這個例子中就是/index.html），如果成功，就將對象、對象類型、對象長度以及其他一些信息放在HTTP響應中發送給客戶端。

1.3 資源

Web服務器是Web資源（Web resource）的宿主。Web資源是Web內容的源頭。最簡單的Web資源就是Web服務器文件系統中的靜態文件。這些文件可以包含任意內容：文本文件、HTML文件、微軟的Word文件、Adobe的Acrobat文件、JPEG圖片文件、AVI電影文件，或所有其他你能夠想到的格式。

但資源不一定非得是靜態文件。資源還可以是根據需要生成內容的軟件程序。這些動態內容資源可以根據你的身份、所請求的信息或每天的不同時段來產生內容。它們可以為你顯示照相機中活生生的照片，也可以幫你進行股票交易，搜索房產數據庫，或者從在線商店中購買禮物（參見圖1-2）。

總之，所有類型的內容來源都是資源。包含公司銷售預測電子表格的文件是一種資源。掃描本地公共圖書館書架的Web網關是一種資源。因特網搜索引擎也是一種資源。

1.3.1 媒體類型

因特網上有數千種不同的數據類型，HTTP仔細地給每種要通過Web傳輸的對象都打上了名為MIME類型（MIME type）的數據格式標簽。最初設計MIME（Multipurpose Internet Mail Extension，多用途因特網郵件擴展）是為了解決在不同的電子郵件系統之間搬移報文時存在的問題。MIME在電子郵件系統中工作得非常好，因此HTTP也采納了它，用它來描述并標記多媒體內容。

Web服務器會為所有HTTP對象數據附加一個MIME類型（參見圖1-3）。當Web瀏覽器從服務器中取回一個對象時，會去查看相關的MIME類型，看看它是否知道應該如何處理這個對象。大多數瀏覽器都可以處理數百種常見的對象類型：顯示圖片文件、解析并格式化HTML文件、通過計算機聲卡播放音頻文件，或者運行外部插件軟件來處理特殊格式的數據。

MIME類型是一種文本標記，表示一種主要的對象類型和一個特定的子類型，中間由一條斜杠來分隔。

· HTML格式的文本文檔由text/html類型來標記。

· 普通的ASCII文本文檔由text/plain類型來標記。

· JPEG格式的圖片為image/jpeg類型。

· GIF格式的圖片為image/gif類型。

· Apple的QuickTime電影為video/quicktime類型。

· 微軟的PowerPoint演示文件為application/vnd.ms-powerpoint類型。

常見的MIME類型有數百個，實驗性或用途有限的MIME類型則更多。附錄D提供了一個非常完整的MIME類型列表。

1.3.2 URI

每個Web服務器資源都有一個名字，這樣客戶端就可以說明它們感興趣的資源是什么了。服務器資源名被稱為統一資源標識符（Uniform Resource Identifier, URI）。URI就像因特網上的郵政地址一樣，在世界范圍內唯一標識并定位信息資源。

這是Joe的五金商店的Web服務器上一個圖片資源的URI：

http://www.joes-hardware.com/specials/saw-blade.gif

圖1-4顯示了URI是怎樣指示HTTP協議去訪問Joe商店服務器上的圖片資源的。給定了URI, HTTP就可以解析出對象。URI有兩種形式，分別稱為URL和URN?，F在我們分別來看看這些資源標識符類型。

1.3.3 URL

統一資源定位符（URL）是資源標識符最常見的形式。URL描述了一臺特定服務器上某資源的特定位置。它們可以明確說明如何從一個精確、固定的位置獲取資源。圖1-4顯示了URL如何精確地說明某資源的位置以及如何去訪問它。表1-1顯示了幾個URL實例。

大部分URL都遵循一種標準格式，這種格式包含三個部分。

· URL的第一部分被稱為 方案（scheme），說明了訪問資源所使用的協議類型。這部分通常就是HTTP協議（http://）。

· 第二部分給出了服務器的因特網地址（比如，www.joes-hardware.com）。

· 其余部分指定了Web服務器上的某個資源（比如，/specials/saw-blade.gif）。

現在，幾乎所有的URI都是URL。

1.3.4 URN

URI的第二種形式就是統一資源名（URN）。URN是作為特定內容的唯一名稱使用的，與目前的資源所在地無關。使用這些與位置無關的URN，就可以將資源四處搬移。通過URN，還可以用同一個名字通過多種網絡訪問協議來訪問資源。

比如，不論因特網標準文檔RFC 2141位于何處（甚至可以將其復制到多個地方），都可以用下列URN來命名它：

urn:ietf:rfc:2141

URN仍然處于試驗階段，還未大范圍使用。為了更有效地工作，URN需要一個支撐架構來解析資源的位置。而此類架構的缺乏也延緩了其被采用的進度。但URN確實為未來發展作出了一些令人興奮的承諾。我們將在第2章較為詳細地討論URN，而本書的其余部分討論的基本上都是URL。

除非特殊說明，否則本書的其余部分都會使用約定的術語，并且會不加區別地使用URI和URL。

1.4 事務

我們來更仔細地看看客戶端是怎樣通過HTTP與Web服務器及其資源進行事務處理的。一個HTTP事務由一條（從客戶端發往服務器的）請求命令和一個（從服務器發回客戶端的）響應結果組成。這種通信是通過名為HTTP報文（HTTP message）的格式化數據塊進行的，如圖1-5所示。

1.4.1 方法

HTTP支持幾種不同的請求命令，這些命令被稱為HTTP方法（HTTP method）。每條HTTP請求報文都包含一個方法。這個方法會告訴服務器要執行什么動作（獲取一個Web頁面、運行一個網關程序、刪除一個文件等）。表1-2列出了五種常見的HTTP方法。

我們會在第3章詳細討論HTTP方法。

1.4.2 狀態碼

每條HTTP響應報文返回時都會攜帶一個狀態碼。狀態碼是一個三位數字的代碼，告知客戶端請求是否成功，或者是否需要采取其他動作。表1-3顯示了幾種常見的狀態碼。

伴隨著每個數字狀態碼，HTTP還會發送一條解釋性的“原因短語”文本（參見圖1-5中的響應報文）。包含文本短語主要是為了進行描述，所有的處理過程使用的都是數字碼。

HTTP軟件處理下列狀態碼和原因短語的方式是一樣的。

200 OK
200 Document attached
200 Success
200 All's cool, dude

第3章詳細解釋了HTTP狀態碼。

1.4.3 Web頁面中可以包含多個對象

應用程序完成一項任務時通常會發布多個HTTP事務。比如，Web瀏覽器會發布一系列HTTP事務來獲取并顯示一個包含了豐富圖片的Web頁面。瀏覽器會執行一個事務來獲取描述頁面布局的HTML“框架”，然后發布另外的HTTP事務來獲取每個嵌入式圖片、圖像面板、Java小程序等。這些嵌入式資源甚至可能位于不同的服務器上，如圖1-6所示。因此，一個“Web頁面”通常并不是單個資源，而是一組資源的集合。

1.5 報文

現在我們來快速瀏覽一下HTTP請求和響應報文的結構。第3章會深入研究HTTP報文。

HTTP報文是由一行一行的簡單字符串組成的。HTTP報文都是純文本，不是二進制代碼，所以人們可以很方便地對其進行讀寫。圖1-7顯示了一個簡單事務所使用的HTTP報文。

從Web客戶端發往Web服務器的HTTP報文稱為請求報文（request message）。從服務器發往客戶端的報文稱為響應報文（response message），此外沒有其他類型的HTTP報文。HTTP請求和響應報文的格式很類似。

HTTP報文包括以下三個部分。

· 起始行

報文的第一行就是起始行，在請求報文中用來說明要做些什么，在響應報文中說明出現了什么情況。

· 首部字段

起始行后面有零個或多個首部字段。每個首部字段都包含一個名字和一個值，為了便于解析，兩者之間用冒號（:）來分隔。首部以一個空行結束。添加一個首部字段和添加新行一樣簡單。

· 主體

空行之后就是可選的報文主體了，其中包含了所有類型的數據。請求主體中包括了要發送給Web服務器的數據；響應主體中裝載了要返回給客戶端的數據。起始行和首部都是文本形式且都是結構化的，而主體則不同，主體中可以包含任意的二進制數據（比如圖片、視頻、音軌、軟件程序）。當然，主體中也可以包含文本。

簡單的報文實例

圖1-8顯示了可能會作為某個簡單事務的一部分發送的HTTP報文。瀏覽器請求資源http://www.joes-hardware.com/tools.html。

在圖1-8中，瀏覽器發送了一條HTTP請求報文。這條請求的起始行中有一個GET命令，且本地資源為/tools.html。這條請求說明它使用的是1.0版的HTTP協議。請求報文沒有主體，因為從服務器上GET一個簡單的文檔不需要請求數據。

服務器會回送一條HTTP響應報文。這條響應中包含了HTTP的版本號（HTTP/1.0）、一個成功狀態碼（200）、一個描述性的原因短語（OK），以及一塊響應首部字段，在所有這些內容之后跟著包含了所請求文檔的響應主體。Content-Length首部說明了響應主體的長度，Content-Type首部說明了文檔的MIME類型。

1.6 連接

概要介紹了HTTP報文的構成之后，我們來討論一下報文是如何通過傳輸控制協議（Transmission Control Protocol, TCP）連接從一個地方搬移到另一個地方去的。

1.6.1 TCP/IP

HTTP是個應用層協議。HTTP無需操心網絡通信的具體細節；它把聯網的細節都交給了通用、可靠的因特網傳輸協議TCP/IP。

TCP提供了：

· 無差錯的數據傳輸；

· 按序傳輸（數據總是會按照發送的順序到達）；

· 未分段的數據流（可以在任意時刻以任意尺寸將數據發送出去）。

因特網自身就是基于TCP/IP的，TCP/IP是全世界的計算機和網絡設備常用的層次化分組交換網絡協議集。TCP/IP隱藏了各種網絡和硬件的特點及弱點，使各種類型的計算機和網絡都能夠進行可靠的通信。

只要建立了TCP連接，客戶端和服務器之間的報文交換就不會丟失、不會被破壞，也不會在接收時出現錯序了。

用網絡術語來說，HTTP協議位于TCP的上層。HTTP使用TCP來傳輸其報文數據。與之類似，TCP則位于IP的上層（參見圖1-9）。

1.6.2 連接、IP地址及端口號

在HTTP客戶端向服務器發送報文之前，需要用網際協議（Internet Protocol, IP）地址和端口號在客戶端和服務器之間建立一條TCP/IP連接。

建立一條TCP連接的過程與給公司辦公室的某個人打電話的過程類似。首先，要撥打公司的電話號碼。這樣就能進入正確的機構了。其次，撥打要聯系的那個人的分機號。

在TCP中，你需要知道服務器的IP地址，以及與服務器上運行的特定軟件相關的TCP端口號。

這就行了，但最初怎么獲得HTTP服務器的IP地址和端口號呢？當然是通過URL了！我們前面曾提到過，URL就是資源的地址，所以自然能夠為我們提供存儲資源的機器的IP地址。我們來看幾個URL：

http://207.200.83.29:80/index.html

http://www.netscape.com:80/index.html

http://www.netscape.com/index.html

第一個URL使用了機器的IP地址，207.200.83.29以及端口號80。

第二個URL沒有使用數字形式的IP地址，它使用的是文本形式的域名，或者稱為主機名（www.netscape.com）。主機名就是IP地址比較人性化的別稱?？梢酝ㄟ^一種稱為域名服務（Domain Name Service, DNS）的機制方便地將主機名轉換為IP地址，這樣所有問題就都解決了。第2章會介紹更多有關DNS和URL的內容。

最后一個URL沒有端口號。HTTP的URL中沒有端口號時，可以假設默認端口號是80。有了IP地址和端口號，客戶端就可以很方便地通過TCP/IP進行通信了。圖1-10顯示了瀏覽器是怎樣通過HTTP顯示位于遠端服務器中的某個簡單HTML資源的。

步驟如下：

(a) 瀏覽器從URL中解析出服務器的主機名；

(b) 瀏覽器將服務器的主機名轉換成服務器的IP地址；

(c) 瀏覽器將端口號（如果有的話）從URL中解析出來；

(d) 瀏覽器建立一條與Web服務器的TCP連接；

(e) 瀏覽器向服務器發送一條HTTP請求報文；

(f) 服務器向瀏覽器回送一條HTTP響應報文；

(g) 關閉連接，瀏覽器顯示文檔。

1.6.3 一個使用Telnet的實例

由于HTTP使用了TCP/IP傳輸協議，而且它是基于文本的，沒有使用那些難以理解的二進制格式，因此很容易直接與Web服務器進行對話。

Telnet程序可以將鍵盤連接到某個目標TCP端口，并將此TCP端口的輸出回送到顯示屏上。Telnet常用于遠程終端會話，但它幾乎可以連接所有的TCP服務器，包括HTTP服務器。

可以通過Telnet程序直接與Web服務器進行對話。通過Telnet可以打開一條到某臺機器上某個端口的TCP連接，然后直接向那個端口輸入一些字符。Web服務器會將Telnet程序作為一個Web客戶端來處理，所有回送給TCP連接的數據都會顯示在屏幕上。

我們用Telnet與一個實際的Web服務器進行交互。我們要用Telnet獲取URL http://www.joes-hardware.com:80/tools.html所指向的文檔（你可以自己嘗試一下這個實例）。

我們來看看會發生什么情況。

· 首先，查找www.joes-hardware.com的IP地址，打開一條到那臺機器端口80的TCP連接。Telnet會為我們完成那些“跑腿兒”的工作。

· 一旦打開了TCP連接，就要輸入HTTP請求了。

· 請求結束（由一個空行表示）之后，服務器會在一條HTTP響應中將內容回送并關閉連接。

例1-1顯示了對http://www.joes-hardware.com:80/tools.html的HTTP請求實例。我們輸入的內容用粗體字表示。

例1-1 一個使用Telnet的HTTP事務

% telnet www.joes-hardware.com 80
Trying 161.58.228.45...
Connected to joes-hardware.com.
Escape character is '^]'.
GET /tools.html HTTP/1.1
Host: www.joes-hardware.com

HTTP/1.1200 OK
Date: Sun, 01 Oct 2000 23:25:17 GMT
Server: Apache/1.3.11 BSafe-SSL/1.38 (Unix) FrontPage/4.0.4.3
Last-Modified: Tue, 04 Jul 2000 09:46:21 GMT
ETag: "373979-193-3961b26d"
Accept-Ranges: bytes
Content-Length: 403
Connection: close
Content-Type: text/html

<HTML>
<HEAD><TITLE>Joe's Tools</TITLE></HEAD>
<BODY>
<H1>Tools Page</H1>
<H2>Hammers</H2>
<P>Joe's Hardware Online has the largest selection of hammers on the
earth.</P>
<H2><A NAME=drills></A>Drills</H2>
<P>Joe's Hardware has a complete line of cordless and corded drills,
as well as the latest
in plutonium-powered atomic drills, for those big around the house
jobs.</P> ...
</BODY>
</HTML>
Connection closed by foreign host.

Telnet會查找主機名并打開一條連接，連接到在www.joes-hardware.com的端口80上監聽的Web服務器。這條命令之后的三行內容是Telnet的輸出，告訴我們它已經建立了連接。

然后我們輸入最基本的請求命令GET /tools.html HTTP/1.1，發送一個提供了源端主機名的Host首部，后面跟上一個空行，請求從服務器www.joes-hardware.com@@上獲取資源tools.html。隨后，服務器會以一個響應行、幾個響應首部、一個空行和最后面的HTML文檔主體來應答。

要明確的是，Telnet可以很好地模擬HTTP客戶端，但不能作為服務器使用。而且對Telnet做腳本自動化是很繁瑣乏味的。如果想要更靈活的工具，可以去看看nc（netcat）。通過nc可以很方便地操縱基于UDP和TCP的流量（包括HTTP），還可以為其編寫腳本。更多細節參見http://www.bgw.org/tutorials/utilities/nc.php。

1.7 協議版本

現在使用的HTTP協議有幾個版本。HTTP應用程序要盡量強健地處理各種不同的HTTP協議變體。目前仍在使用的版本如下。

· HTTP/0.9

HTTP的1991原型版本稱為HTTP/0.9。這個協議有很多嚴重的設計缺陷，只應該用于與老客戶端的交互。HTTP/0.9只支持GET方法，不支持多媒體內容的MIME類型、各種HTTP首部，或者版本號。HTTP/0.9定義的初衷是為了獲取簡單的HTML對象，它很快就被HTTP/1.0取代了。

· HTTP/1.0

1.0是第一個得到廣泛使用的HTTP版本。HTTP/1.0添加了版本號、各種HTTP首部、一些額外的方法，以及對多媒體對象的處理。HTTP/1.0使得包含生動圖片的Web頁面和交互式表格成為可能，而這些頁面和表格促使萬維網為人們廣泛地接受。這個規范從未得到良好地說明。在這個HTTP協議的商業演進和學術研究都在快速進行的時代，它集合了一系列的最佳實踐。

· HTTP/1.0+

在20世紀90年代中葉，很多流行的Web客戶端和服務器都在飛快地向HTTP中添加各種特性，以滿足快速擴張且在商業上十分成功的萬維網的需要。其中很多特性，包括持久的keep-alive連接、虛擬主機支持，以及代理連接支持都被加入到HTTP之中，并成為非官方的事實標準。這種非正式的HTTP擴展版本通常稱為HTTP/1.0+。

· HTTP/1.1

HTTP/1.1重點關注的是校正HTTP設計中的結構性缺陷，明確語義，引入重要的性能優化措施，并刪除一些不好的特性。HTTP/1.1還包含了對20世紀90年代末正在發展中的更復雜的Web應用程序和部署方式的支持。HTTP/1.1是當前使用的HTTP版本。

· HTTP-NG（又名HTTP/2.0）

HTTP-NG是HTTP/1.1后繼結構的原型建議，它重點關注的是性能的大幅優化，以及更強大的服務邏輯遠程執行框架。HTTP-NG的研究工作終止于1998年，編寫本書時，還沒有任何要用此建議取代HTTP/1.1的推廣計劃。更多信息請參見第10章。

1.8 Web的結構組件

在本章的概述中，我們重點介紹了兩個Web應用程序（Web瀏覽器和Web服務器）是如何相互發送報文來實現基本事務處理的。在因特網上，要與很多Web應用程序進行交互。在本節中，我們將列出其他一些比較重要的應用程序，如下所示。

· 代理

位于客戶端和服務器之間的HTTP中間實體。

· 緩存

HTTP的倉庫，使常用頁面的副本可以保存在離客戶端更近的地方。

· 網關

連接其他應用程序的特殊Web服務器。

· 隧道

對HTTP通信報文進行盲轉發的特殊代理。

· Agent代理

發起自動HTTP請求的半智能Web客戶端。

1.8.1 代理

首先我們來看看HTTP代理服務器，這是Web安全、應用集成以及性能優化的重要組成模塊。

如圖1-11所示，代理位于客戶端和服務器之間，接收所有客戶端的HTTP請求，并將這些請求轉發給服務器（可能會對請求進行修改之后轉發）。對用戶來說，這些應用程序就是一個代理，代表用戶訪問服務器。

出于安全考慮，通常會將代理作為轉發所有Web流量的可信任中間節點使用。代理還可以對請求和響應進行過濾。比如，在企業中對下載的應用程序進行病毒檢測，或者對小學生屏蔽一些成人才能看的內容。我們將在第6章詳細介紹代理。

1.8.2 緩存

Web緩存（Web cache）或代理緩存（proxy cache）是一種特殊的HTTP代理服務器，可以將經過代理傳送的常用文檔復制保存起來。下一個請求同一文檔的客戶端就可以享受緩存的私有副本所提供的服務了（參見圖1-12）。

客戶端從附近的緩存下載文檔會比從遠程Web服務器下載快得多。HTTP定義了很多功能，使得緩存更加高效，并規范了文檔的新鮮度和緩存內容的隱私性。第7章介紹了緩存技術。

1.8.3 網關

網關（gateway）是一種特殊的服務器，作為其他服務器的中間實體使用。通常用于將HTTP流量轉換成其他的協議。網關接受請求時就好像自己是資源的源端服務器一樣?？蛻舳丝赡懿⒉恢雷约赫谂c一個網關進行通信。

例如，一個HTTP/FTP網關會通過HTTP請求接收對FTP URI的請求，但通過FTP協議來獲取文檔（參見圖1-13）。得到的文檔會被封裝成一條HTTP報文，發送給客戶端。第8章將探討網關。

1.8.4 隧道

隧道（tunnel）是建立起來之后，就會在兩條連接之間對原始數據進行盲轉發的HTTP應用程序。HTTP隧道通常用來在一條或多條HTTP連接上轉發非HTTP數據，轉發時不會窺探數據。

HTTP隧道的一種常見用途是通過HTTP連接承載加密的安全套接字層（SSL, Secure Sockets Layer）流量，這樣SSL流量就可以穿過只允許Web流量通過的防火墻了。如圖1-14所示，HTTP/SSL隧道收到一條HTTP請求，要求建立一條到目的地址和端口的輸出連接，然后在HTTP信道上通過隧道傳輸加密的SSL流量，這樣就可以將其盲轉發到目的服務器上去了。

1.8.5 Agent代理

用戶Agent代理（或者簡稱為Agent代理）是代表用戶發起HTTP請求的客戶端程序。所有發布Web請求的應用程序都是HTTP Agent代理。到目前為止，我們只提到過一種HTTP Agent代理：Web瀏覽器，但用戶Agent代理還有很多其他類型。

比如，有些自己會在Web上閑逛的自動用戶Agent代理，可以在無人監視的情況下發布HTTP事務并獲取內容。這些自動代理的名字通常都很生動，比如“網絡蜘蛛”（spiders）或者“Web機器人”（Web robots）（參見圖1-15）。網絡蜘蛛會在Web上閑逛，搜集信息以構建有效的Web內容檔案，比如一個搜索引擎的數據庫或者為比較購物機器人生成的產品目錄。更多信息請參見第9章。

1.9 起始部分的結束語

這就是我們對HTTP的簡要介紹。本章中，我們重點介紹了作為多媒體傳輸協議使用的HTTP。概要說明了HTTP是怎樣使用URI來命名遠程服務器上的多媒體資源的，粗略介紹了如何利用HTTP請求和響應報文操縱遠程服務器上的多媒體資源，最后考察了幾種使用HTTP的Web應用程序。

本書的其余章節會更加詳細地介紹HTTP協議、應用程序及資源的技術機制。

1.10 更多信息

本書稍后的章節將更深入地研究HTTP，下面這些資源中也包含了與本章所涵蓋的特定主題有關的背景知識。

1.10.1 HTTP協議信息

· HTTP Pocket Reference（《HTTP口袋書》）

Clinton Wong著，O'Reilly & Associates出版公司。這本書詳細介紹了HTTP，可以作為構成HTTP事務的首部和狀態碼的快速參考手冊。

· http://www.w3.org/Protocols/

這個W3C的Web頁面中包含了很多與HTTP協議有關的重要鏈接。

· http://www.ietf.org/rfc/rfc2616.txt

RFC2616“超文本傳輸協議——HTTP/1.1”是當前HTTP協議版本HTTP/1.1的官方規范。這個規范是一本編寫流暢、組織良好而且非常詳細的HTTP參考手冊，但并不適于那些希望了解HTTP底層概念和動因，或者原理與實際應用之間區別的讀者閱讀。希望本書能夠對這些底層概念進行補充，以便讀者更好地使用這個規范。

· http://www.ietf.org/rfc/rfc1945.txt

RFC1945“超文本傳輸協議——HTTP/1.0”是一個描述了HTTP現代基礎的知識性RFC。它對編寫此規范時，已得到官方認可且具有“最佳實踐”的Web應用程序行為進行了詳細描述，還討論了一些雖被HTTP/1.1所摒棄，但在一些老舊的應用程序中仍在廣泛使用的行為。

· http://www.w3.org/Protocols/HTTP/AsImplemented.html

這個Web頁面介紹了1991年的HTTP/0.9協議，這個協議只實現了GET請求，而且不包含內容類型。

1.10.2 歷史透視

· http://www.w3.org/Protocols/WhyHTTP.html

這個簡要的Web頁面從1991年開始，從HTTP作者的角度，介紹了HTTP的一些起源以及初級目標。

· http://www.w3.org/History.html

“A Little History of the World Wide Web”（萬維網的簡要歷史）對萬維網和HTTP的一些早期目標和構建基礎進行了簡短但有趣的剖析。

· http://www.w3.org/DesignIssues/Architecture.html

“Web Architecture from 50,000 feet”（高空俯瞰Web結構）繪制了一幅廣闊、遠大的萬維網藍圖，并詳述了影響HTTP和相關Web技術的設計原則。

1.10.3 其他萬維網信息

· http://www.w3.org

W3C是Web的科技驅動團隊。W3C致力于促進Web演化的互操作性技術（規范、準則、軟件及工具）研究。W3C站點是一個包含了Web技術簡介和詳細文檔的寶庫。

· http://www.ietf.org/rfc/rfc2396.txt

RFC 2396“Uniform Resource Identifiers（URI）:Generic Syntax”,（“統一資源標識符（URI）：通用語法”）是URI和URL的詳細參考。

· http://www.ieft.ofg/rfc/rfc2141.txt

RFC2141“URN Syntax”（“URN的語法”）是一個寫于1997年的描述URN語法的規范。

· http://www.ietf.org/rfc/rfc2046.txt

RFC2046“MIME Part 2:Media Types”（“MIME第II部分：媒體類型”）是為進行多媒體內容管理而定義的多用途因特網郵件擴展標準的五部因特網規范中的第二部。

· http://www.wrec.org/Drafts/draft-ietf-wrec-taxonomy-06.txt

這個因特網草案“Internet Web Replication and Caching Taxonomy”（“因特網Web復制和緩存分類法”）解釋了Web結構組件中的標準術語。