HTTP權(quán)威指南（中文版）

HTTP權(quán)威指南中文版目錄\h第一部分HTTP：Web的基礎(chǔ)\h第1章HTTP概述\h1.1HTTP——因特網(wǎng)的多媒體信使\h1.2Web客戶端和服務(wù)器\h1.3資源\h1.4事務(wù)\h1.5報文\h1.6連接\h1.7協(xié)議版本\h1.8Web的結(jié)構(gòu)組件\h1.9起始部分的結(jié)束語\h1.10更多信息\h第2章URL與資源\h2.1瀏覽因特網(wǎng)資源\h2.2URL的語法\h2.3URL快捷方式\h2.4各種令人頭疼的字符\h2.5方案的世界\h2.6未來展望\h2.7更多信息\h第3章HTTP報文\h3.1報文流\h3.2報文的組成部分\h3.3方法\h3.4狀態(tài)碼\h3.5首部\h3.6更多信息\h第4章連接管理\h4.1TCP連接\h4.2對TCP性能的考慮\h4.3HTTP連接的處理\h4.4并行連接\h4.5持久連接\h4.6管道化連接\h4.7關(guān)閉連接的奧秘\h4.8更多信息\h第二部分HTTP結(jié)構(gòu)\h第5章Web服務(wù)器\h5.1各種形狀和尺寸的Web服務(wù)器\h5.2最小的PerlWeb服務(wù)器\h5.3實際的Web服務(wù)器會做些什么\h5.4第一步——接受客戶端連接\h5.5第二步——接收請求報文\h5.6第三步——處理請求\h5.7第四步——對資源的映射及訪問\h5.8第五步——構(gòu)建響應(yīng)\h5.9第六步——發(fā)送響應(yīng)\h5.10第七步——記錄日志\h5.11更多信息\h第6章代理\h6.1Web的中間實體\h6.2為什么使用代理\h6.3代理會去往何處\h6.4客戶端的代理設(shè)置\h6.5與代理請求有關(guān)的一些棘手問題\h6.6追蹤報文\h6.7代理認(rèn)證\h6.8代理的互操作性\h6.9更多信息\h第7章緩存\h7.1冗余的數(shù)據(jù)傳輸\h7.2帶寬瓶頸\h7.3瞬間擁塞\h7.4距離時延\h7.5命中和未命中的\h7.6緩存的拓?fù)浣Y(jié)構(gòu)\h7.7緩存的處理步驟\h7.8保持副本的新鮮\h7.9控制緩存的能力\h7.10設(shè)置緩存控制\h7.11詳細(xì)算法\h7.12緩存和廣告\h7.13更多信息\h第8章集成點：網(wǎng)關(guān)、隧道及中繼\h8.1網(wǎng)關(guān)\h8.2協(xié)議網(wǎng)關(guān)\h8.3資源網(wǎng)關(guān)\h8.4應(yīng)用程序接口和Web服務(wù)\h8.5隧道\h8.6中繼\h8.7更多信息\h第9章Web機(jī)器人\h9.1爬蟲及爬行方式\h9.2機(jī)器人的HTTP\h9.3行為不當(dāng)?shù)臋C(jī)器人\h9.4拒絕機(jī)器人訪問\h9.5機(jī)器人的規(guī)范\h9.6搜索引擎\h9.7更多信息\h第10章HTTP-NG\h10.1HTTP發(fā)展中存在的問題\h10.2HTTP-NG的活動\h10.3模塊化及功能增強(qiáng)\h10.4分布式對象\h10.5第一層——報文傳輸\h10.6第二層——遠(yuǎn)程調(diào)用\h10.7第三層——Web應(yīng)用\h10.8WebMUX\h10.9二進(jìn)制連接協(xié)議\h10.10當(dāng)前的狀態(tài)\h10.11更多信息\h第三部分識別、認(rèn)證與安全\h第11章客戶端識別與cookie機(jī)制\h11.1個性化接觸\h11.2HTTP首部\h11.3客戶端IP地址\h11.4用戶登錄\h11.5胖URL\h11.6cookie\h11.7更多信息\h第12章基本認(rèn)證機(jī)制\h12.1認(rèn)證\h12.2基本認(rèn)證\h12.3基本認(rèn)證的安全缺陷\h12.4更多信息\h第13章摘要認(rèn)證\h13.1摘要認(rèn)證的改進(jìn)\h13.2摘要的計算\h13.3增強(qiáng)保護(hù)質(zhì)量\h13.4應(yīng)該考慮的實際問題\h13.5安全性考慮\h13.6更多信息\h第14章安全HTTP\h14.1保護(hù)HTTP的安全\h14.2數(shù)字加密\h14.3對稱密鑰加密技術(shù)\h14.4公開密鑰加密技術(shù)\h14.5數(shù)字簽名\h14.6數(shù)字證書\h14.7HTTPS——細(xì)節(jié)介紹\h14.8HTTPS客戶端實例\h14.9通過代理以隧道形式傳輸安全流量\h14.10更多信息\h第四部分實體、編碼和國際化\h第15章實體和編碼\h15.1報文是箱子，實體是貨物\h15.2Content-Length:實體的大小\h15.3實體摘要\h15.4媒體類型和字符集\h15.5內(nèi)容編碼\h15.6傳輸編碼和分塊編碼\h15.7隨時間變化的實例\h15.8驗證碼和新鮮度\h15.9范圍請求\h15.10差異編碼\h15.11更多信息\h第16章國際化\h16.1HTTP對國際性內(nèi)容的支持\h16.2字符集與HTTP\h16.3多語言字符編碼入門\h16.4語言標(biāo)記與HTTP\h16.5國際化的URI\h16.6其他需要考慮的地方\h16.7更多信息\h第17章內(nèi)容協(xié)商與轉(zhuǎn)碼\h17.1內(nèi)容協(xié)商技術(shù)\h17.2客戶端驅(qū)動的協(xié)商\h17.3服務(wù)器驅(qū)動的協(xié)商\h17.4透明協(xié)商\h17.5轉(zhuǎn)碼\h17.6下一步計劃\h17.7更多信息\h第五部分內(nèi)容發(fā)布與分發(fā)\h第18章Web主機(jī)托管\h18.1主機(jī)托管服務(wù)\h18.2虛擬主機(jī)托管\h18.3使網(wǎng)站更可靠\h18.4讓網(wǎng)站更快\h18.5更多信息\h第19章發(fā)布系統(tǒng)\h19.1FrontPage為支持發(fā)布而做的服務(wù)器擴(kuò)展\h19.2WebDAV與協(xié)作寫作\h19.3更多信息\h第20章重定向與負(fù)載均衡\h20.1為什么要重定向\h20.2重定向到何地\h20.3重定向協(xié)議概覽\h20.4通用的重定向方法\h20.5代理的重定向方法\h20.6緩存重定向方法\h20.7因特網(wǎng)緩存協(xié)議\h20.8緩存陣列路由協(xié)議\h20.9超文本緩存協(xié)議\h20.10更多信息\h第21章日志記錄與使用情況跟蹤\h21.1記錄內(nèi)容\h21.2日志格式\h21.3命中率測量\h21.4關(guān)于隱私的考慮\h21.5更多信息\h第六部分附錄\h附錄AURI方案\h附錄BHTTP狀態(tài)碼\h附錄CHTTP首部參考\h附錄DMIME類型（一）\h附錄DMIME類型（二）\h附錄DMIME類型（三）\h附錄DMIME類型（四）\h附錄DMIME類型（五）\h附錄EBase-64編碼\h附錄F摘要認(rèn)證\h附錄G語言標(biāo)記（一）\h附錄G語言標(biāo)記（二）\h附錄G語言標(biāo)記（三）\h附錄G語言標(biāo)記（四）\h附錄HMIME字符集注冊表（一）\h附錄HMIME字符集注冊表（二）\h附錄HMIME字符集注冊表（三）注：原文檔電子版（非掃描），需要的請下載本文檔后留言謝謝。第一部分HTTP：Web的基礎(chǔ)本部分主要概述HTTP協(xié)議。接下來的4章介紹了Web的基礎(chǔ)構(gòu)件以及HTTP的核心技術(shù)。第1章簡要概述HTTP。第2章詳細(xì)介紹了URL的格式，以及URL在因特網(wǎng)上命名的各種類型的資源，并對其向URN的發(fā)展作了概要介紹。第3章詳細(xì)說明了用來傳輸Web內(nèi)容的HTTP報文。第4章討論了一些通過HTTP管理TCP連接時常被誤解且很少有文檔說明的規(guī)則和行為。第1章HTTP概述Web瀏覽器、服務(wù)器和相關(guān)的Web應(yīng)用程序都是通過HTTP相互通信的。HTTP是現(xiàn)代全球因特網(wǎng)中使用的公共語言。本章是對HTTP的簡要介紹。在本章中可以看到Web應(yīng)用程序是如何使用HTTP進(jìn)行通信的，這樣就可以對HTTP如何完成其工作有個大概印象。我們將特別介紹以下方面的內(nèi)容：Web客戶端與服務(wù)器是如何通信的；（表示W(wǎng)eb內(nèi)容的）資源來自何方；Web事務(wù)是怎樣工作的；HTTP通信所使用的報文格式；底層TCP網(wǎng)絡(luò)傳輸；不同的HTTP協(xié)議變體；因特網(wǎng)上安裝的大量HTTP架構(gòu)組件中的一部分。我們有很多話題要討論，就此開始HTTP之旅吧。1.1HTTP——因特網(wǎng)的多媒體信使每天，都有數(shù)以億萬計的JPEG圖片、HTML頁面、文本文件、MPEG電影、WAV音頻文件、Java小程序和其他資源在因特網(wǎng)上游弋。HTTP可以從遍布全世界的Web服務(wù)器上將這些信息塊迅速、便捷、可靠地搬移到人們桌面上的Web瀏覽器上去。HTTP使用的是可靠的數(shù)據(jù)傳輸協(xié)議，因此即使數(shù)據(jù)來自地球的另一端，它也能夠確保數(shù)據(jù)在傳輸?shù)倪^程中不會被損壞或產(chǎn)生混亂。這樣，用戶在訪問信息時就不用擔(dān)心其完整性了，因此對用戶來說，這是件好事。而對因特網(wǎng)應(yīng)用程序開發(fā)人員來說也同樣如此，因為這樣就無需擔(dān)心HTTP通信會在傳輸過程中被破壞、復(fù)制或產(chǎn)生畸變了。開發(fā)人員可以專注于應(yīng)用程序特有細(xì)節(jié)的編寫，而不用考慮因特網(wǎng)中存在的一些缺陷和問題。下面，就讓我們來近距離地觀察一下HTTP是如何傳輸Web流量的。1.2Web客戶端和服務(wù)器Web內(nèi)容都是存儲在Web服務(wù)器上的。Web服務(wù)器所使用的是HTTP協(xié)議，因此經(jīng)常會被稱為HTTP服務(wù)器。這些HTTP服務(wù)器存儲了因特網(wǎng)中的數(shù)據(jù)，如果HTTP客戶端發(fā)出請求的話，它們會提供數(shù)據(jù)?？蛻舳讼蚍?wù)器發(fā)送HTTP請求，服務(wù)器會在HTTP響應(yīng)中回送所請求的數(shù)據(jù)，如圖1-1所示。HTTP客戶端和HTTP服務(wù)器共同構(gòu)成了萬維網(wǎng)的基本組件。圖1-1Web客戶端和服務(wù)器可能你每天都在使用HTTP客戶端。最常見的客戶端就是Web瀏覽器，比如微軟的InternetExplorer或網(wǎng)景的Navigator。Web瀏覽器向服務(wù)器請求HTTP對象，并將這些對象顯示在你的屏幕上。瀏覽一個頁面時（比如\h/index.html），瀏覽器會向服務(wù)器\h發(fā)送一條HTTP請求（參見圖1-1）。服務(wù)器會去尋找所期望的對象（在這個例子中就是/index.html），如果成功，就將對象、對象類型、對象長度以及其他一些信息放在HTTP響應(yīng)中發(fā)送給客戶端。1.3資源Web服務(wù)器是Web資源（Webresource）的宿主。Web資源是Web內(nèi)容的源頭。最簡單的Web資源就是Web服務(wù)器文件系統(tǒng)中的靜態(tài)文件。這些文件可以包含任意內(nèi)容：文本文件、HTML文件、微軟的Word文件、Adobe的Acrobat文件、JPEG圖片文件、AVI電影文件，或所有其他你能夠想到的格式。但資源不一定非得是靜態(tài)文件。資源還可以是根據(jù)需要生成內(nèi)容的軟件程序。這些動態(tài)內(nèi)容資源可以根據(jù)你的身份、所請求的信息或每天的不同時段來產(chǎn)生內(nèi)容。它們可以為你顯示照相機(jī)中活生生的照片，也可以幫你進(jìn)行股票交易，搜索房產(chǎn)數(shù)據(jù)庫，或者從在線商店中購買禮物（參見圖1-2）。圖1-2所有能夠提供Web內(nèi)容的東西都是Web資源總之，所有類型的內(nèi)容來源都是資源。包含公司銷售預(yù)測電子表格的文件是一種資源。掃描本地公共圖書館書架的Web網(wǎng)關(guān)是一種資源。因特網(wǎng)搜索引擎也是一種資源。1.3.1媒體類型因特網(wǎng)上有數(shù)千種不同的數(shù)據(jù)類型，HTTP仔細(xì)地給每種要通過Web傳輸?shù)膶ο蠖即蛏狭嗣麨镸IME類型（MIMEtype）的數(shù)據(jù)格式標(biāo)簽。最初設(shè)計MIME（MultipurposeInternetMailExtension，多用途因特網(wǎng)郵件擴(kuò)展）是為了解決在不同的電子郵件系統(tǒng)之間搬移報文時存在的問題。MIME在電子郵件系統(tǒng)中工作得非常好，因此HTTP也采納了它，用它來描述并標(biāo)記多媒體內(nèi)容。Web服務(wù)器會為所有HTTP對象數(shù)據(jù)附加一個MIME類型（參見圖1-3）。當(dāng)Web瀏覽器從服務(wù)器中取回一個對象時，會去查看相關(guān)的MIME類型，看看它是否知道應(yīng)該如何處理這個對象。大多數(shù)瀏覽器都可以處理數(shù)百種常見的對象類型：顯示圖片文件、解析并格式化HTML文件、通過計算機(jī)聲卡播放音頻文件，或者運(yùn)行外部插件軟件來處理特殊格式的數(shù)據(jù)。圖1-3與數(shù)據(jù)內(nèi)容一同回送的MIME類型MIME類型是一種文本標(biāo)記，表示一種主要的對象類型和一個特定的子類型，中間由一條斜杠來分隔。HTML格式的文本文檔由text/html類型來標(biāo)記。普通的ASCII文本文檔由text/plain類型來標(biāo)記。JPEG格式的圖片為image/jpeg類型。GIF格式的圖片為image/gif類型。Apple的QuickTime電影為video/quicktime類型。微軟的PowerPoint演示文件為application/vnd.ms-powerpoint類型。常見的MIME類型有數(shù)百個，實驗性或用途有限的MIME類型則更多。附錄D提供了一個非常完整的MIME類型列表。1.3.2.URI每個Web服務(wù)器資源都有一個名字，這樣客戶端就可以說明它們感興趣的資源是什么了。服務(wù)器資源名被稱為統(tǒng)一資源標(biāo)識符（UniformResourceIdenti?er，URI）。URI就像因特網(wǎng)上的郵政地址一樣，在世界范圍內(nèi)唯一標(biāo)識并定位信息資源。這是Joe的五金商店的Web服務(wù)器上一個圖片資源的URI：\h/specials/saw-blade.gif圖1-4顯示了URI是怎樣指示HTTP協(xié)議去訪問Joe商店服務(wù)器上的圖片資源的。給定了URI，HTTP就可以解析出對象。URI有兩種形式，分別稱為URL和URN?，F(xiàn)在我們分別來看看這些資源標(biāo)識符類型。圖1-4URL說明了協(xié)議、服務(wù)器和本地資源1.3.3.URL統(tǒng)一資源定位符（URL）是資源標(biāo)識符最常見的形式。URL描述了一臺特定服務(wù)器上某資源的特定位置。它們可以明確說明如何從一個精確、固定的位置獲取資源。圖1-4顯示了URL如何精確地說明某資源的位置以及如何去訪問它。表1-1顯示了幾個URL實例。表1-1URL實例

URL描述\h/index.htmlO'Reilly&Associates公司的主URL\h/images/logo.gifYahoo!的Web站點標(biāo)志URL\h/inventory-check.cgi?item=12731一個查看庫存條目#12731是否有現(xiàn)貨的程序的URLftp://joe:tools4u@/lockingpliers.gif以密碼保護(hù)的FTP作為訪問協(xié)議的lockingpliers.gif圖片文件的URL大部分URL都遵循一種標(biāo)準(zhǔn)格式，這種格式包含三個部分。URL的第一部分被稱為方案（scheme），說明了訪問資源所使用的協(xié)議類型。這部分通常就是HTTP協(xié)議（http://）。第二部分給出了服務(wù)器的因特網(wǎng)地址（比如，\h）。其余部分指定了Web服務(wù)器上的某個資源（比如，/specials/saw-blade.gif）。現(xiàn)在，幾乎所有的URI都是URL。1.3.4.URNURI的第二種形式就是統(tǒng)一資源名（URN）。URN是作為特定內(nèi)容的唯一名稱使用的，與目前的資源所在地?zé)o關(guān)。使用這些與位置無關(guān)的URN，就可以將資源四處搬移。通過URN，還可以用同一個名字通過多種網(wǎng)絡(luò)訪問協(xié)議來訪問資源。比如，不論因特網(wǎng)標(biāo)準(zhǔn)文檔RFC2141位于何處（甚至可以將其復(fù)制到多個地方），都可以用下列URN來命名它：urn:ietf:rfc:2141URN仍然處于試驗階段，還未大范圍使用。為了更有效地工作，URN需要一個支撐架構(gòu)來解析資源的位置。而此類架構(gòu)的缺乏也延緩了其被采用的進(jìn)度。但URN確實為未來發(fā)展作出了一些令人興奮的承諾。我們將在第2章較為詳細(xì)地討論URN，而本書的其余部分討論的基本上都是URL。除非特殊說明，否則本書的其余部分都會使用約定的術(shù)語，并且會不加區(qū)別地使用URI和URL。1.4事務(wù)我們來更仔細(xì)地看看客戶端是怎樣通過HTTP與Web服務(wù)器及其資源進(jìn)行事務(wù)處理的。一個HTTP事務(wù)由一條（從客戶端發(fā)往服務(wù)器的）請求命令和一個（從服務(wù)器發(fā)回客戶端的）響應(yīng)結(jié)果組成。這種通信是通過名為HTTP報文（HTTPmessage）的格式化數(shù)據(jù)塊進(jìn)行的，如圖1-5所示。圖1-5包含請求及響應(yīng)報文的HTTP事務(wù)1.4.1方法HTTP支持幾種不同的請求命令，這些命令被稱為HTTP方法（HTTPmethod）。每條HTTP請求報文都包含一個方法。這個方法會告訴服務(wù)器要執(zhí)行什么動作（獲取一個Web頁面、運(yùn)行一個網(wǎng)關(guān)程序、刪除一個文件等）。表1-2列出了五種常見的HTTP方法。表1-2一些常見的HTTP方法

HTTP方法描述GET從服務(wù)器向客戶端發(fā)送命名資源PUT將來自客戶端的數(shù)據(jù)存儲到一個命名的服務(wù)器資源中去DELETE從服務(wù)器中刪除命名資源POST將客戶端數(shù)據(jù)發(fā)送到一個服務(wù)器網(wǎng)關(guān)應(yīng)用程序HEAD僅發(fā)送命名資源響應(yīng)中的HTTP首部我們會在第3章詳細(xì)討論HTTP方法。1.4.2狀態(tài)碼每條HTTP響應(yīng)報文返回時都會攜帶一個狀態(tài)碼。狀態(tài)碼是一個三位數(shù)字的代碼，告知客戶端請求是否成功，或者是否需要采取其他動作。表1-3顯示了幾種常見的狀態(tài)碼。表1-3一些常見的HTTP狀態(tài)碼

HTTP狀態(tài)碼描述200OK。文檔正確返回302Redirect（重定向）。到其他地方去獲取資源404NotFound（沒找到）。無法找到這個資源伴隨著每個數(shù)字狀態(tài)碼，HTTP還會發(fā)送一條解釋性的“原因短語”文本（參見圖1-5中的響應(yīng)報文）。包含文本短語主要是為了進(jìn)行描述，所有的處理過程使用的都是數(shù)字碼。HTTP軟件處理下列狀態(tài)碼和原因短語的方式是一樣的。200OK

200Documentattached

200Success

200All'scool,dude第3章詳細(xì)解釋了HTTP狀態(tài)碼。1.4.3Web頁面中可以包含多個對象應(yīng)用程序完成一項任務(wù)時通常會發(fā)布多個HTTP事務(wù)。比如，Web瀏覽器會發(fā)布一系列HTTP事務(wù)來獲取并顯示一個包含了豐富圖片的Web頁面。瀏覽器會執(zhí)行一個事務(wù)來獲取描述頁面布局的HTML“框架”，然后發(fā)布另外的HTTP事務(wù)來獲取每個嵌入式圖片、圖像面板、Java小程序等。這些嵌入式資源甚至可能位于不同的服務(wù)器上，如圖1-6所示。因此，一個“Web頁面”通常并不是單個資源，而是一組資源的集合。圖1-6復(fù)合Web頁面要為每個嵌入式資源使用一個單獨(dú)的HTTP事務(wù)1.5報文現(xiàn)在我們來快速瀏覽一下HTTP請求和響應(yīng)報文的結(jié)構(gòu)。第3章會深入研究HTTP報文。HTTP報文是由一行一行的簡單字符串組成的。HTTP報文都是純文本，不是二進(jìn)制代碼，所以人們可以很方便地對其進(jìn)行讀寫1。圖1-7顯示了一個簡單事務(wù)所使用的HTTP報文。1有些程序員會抱怨HTTP的語法解析太困難了，這項工作需要很多技巧，而且很容易出錯，尤其是在設(shè)計高速軟件的時候更是如此。二進(jìn)制格式或更嚴(yán)格的文本格式可能更容易處理，但大多數(shù)HTTP程序員都很欣賞HTTP的可擴(kuò)展性以及可調(diào)試性。圖1-7由一行行的簡單文本結(jié)構(gòu)組成的HTTP報文從Web客戶端發(fā)往Web服務(wù)器的HTTP報文稱為請求報文（requestmessage）。從服務(wù)器發(fā)往客戶端的報文稱為響應(yīng)報文（responsemessage），此外沒有其他類型的HTTP報文。HTTP請求和響應(yīng)報文的格式很類似。HTTP報文包括以下三個部分。起始行報文的第一行就是起始行，在請求報文中用來說明要做些什么，在響應(yīng)報文中說明出現(xiàn)了什么情況。首部字段起始行后面有零個或多個首部字段。每個首部字段都包含一個名字和一個值，為了便于解析，兩者之間用冒號（:）來分隔。首部以一個空行結(jié)束。添加一個首部字段和添加新行一樣簡單。主體空行之后就是可選的報文主體了，其中包含了所有類型的數(shù)據(jù)。請求主體中包括了要發(fā)送給Web服務(wù)器的數(shù)據(jù)；響應(yīng)主體中裝載了要返回給客戶端的數(shù)據(jù)。起始行和首部都是文本形式且都是結(jié)構(gòu)化的，而主體則不同，主體中可以包含任意的二進(jìn)制數(shù)據(jù)（比如圖片、視頻、音軌、軟件程序）。當(dāng)然，主體中也可以包含文本。簡單的報文實例圖1-8顯示了可能會作為某個簡單事務(wù)的一部分發(fā)送的HTTP報文。瀏覽器請求資源\h/tools.html。圖1-8\h/tools.html的GET事務(wù)實例在圖1-8中，瀏覽器發(fā)送了一條HTTP請求報文。這條請求的起始行中有一個GET命令，且本地資源為/tools.html。這條請求說明它使用的是1.0版的HTTP協(xié)議。請求報文沒有主體，因為從服務(wù)器上GET一個簡單的文檔不需要請求數(shù)據(jù)。服務(wù)器會回送一條HTTP響應(yīng)報文。這條響應(yīng)中包含了HTTP的版本號（HTTP/1.0）、一個成功狀態(tài)碼（200）、一個描述性的原因短語（OK），以及一塊響應(yīng)首部字段，在所有這些內(nèi)容之后跟著包含了所請求文檔的響應(yīng)主體。Content-Length首部說明了響應(yīng)主體的長度，Content-Type首部說明了文檔的MIME類型。1.6連接概要介紹了HTTP報文的構(gòu)成之后，我們來討論一下報文是如何通過傳輸控制協(xié)議（TransmissionControlProtocol，TCP）連接從一個地方搬移到另一個地方去的。1.6.1TCP/IPHTTP是個應(yīng)用層協(xié)議。HTTP無需操心網(wǎng)絡(luò)通信的具體細(xì)節(jié)；它把聯(lián)網(wǎng)的細(xì)節(jié)都交給了通用、可靠的因特網(wǎng)傳輸協(xié)議TCP/IP。TCP提供了：無差錯的數(shù)據(jù)傳輸；按序傳輸（數(shù)據(jù)總是會按照發(fā)送的順序到達(dá)）；未分段的數(shù)據(jù)流（可以在任意時刻以任意尺寸將數(shù)據(jù)發(fā)送出去）。因特網(wǎng)自身就是基于TCP/IP的，TCP/IP是全世界的計算機(jī)和網(wǎng)絡(luò)設(shè)備常用的層次化分組交換網(wǎng)絡(luò)協(xié)議集。TCP/IP隱藏了各種網(wǎng)絡(luò)和硬件的特點及弱點，使各種類型的計算機(jī)和網(wǎng)絡(luò)都能夠進(jìn)行可靠地通信。只要建立了TCP連接，客戶端和服務(wù)器之間的報文交換就不會丟失、不會被破壞，也不會在接收時出現(xiàn)錯序了。用網(wǎng)絡(luò)術(shù)語來說，HTTP協(xié)議位于TCP的上層。HTTP使用TCP來傳輸其報文數(shù)據(jù)。與之類似，TCP則位于IP的上層（參見圖1-9）。圖1-9HTTP網(wǎng)絡(luò)協(xié)議棧1.6.2連接、IP地址及端口號在HTTP客戶端向服務(wù)器發(fā)送報文之前，需要用網(wǎng)際協(xié)議（InternetProtocol，IP）地址和端口號在客戶端和服務(wù)器之間建立一條TCP/IP連接。建立一條TCP連接的過程與給公司辦公室的某個人打電話的過程類似。首先，要撥打公司的電話號碼。這樣就能進(jìn)入正確的機(jī)構(gòu)了。其次，撥打要聯(lián)系的那個人的分機(jī)號。在TCP中，你需要知道服務(wù)器的IP地址，以及與服務(wù)器上運(yùn)行的特定軟件相關(guān)的TCP端口號。這就行了，但最初怎么獲得HTTP服務(wù)器的IP地址和端口號呢？當(dāng)然是通過URL了！我們前面曾提到過，URL就是資源的地址，所以自然能夠為我們提供存儲資源的機(jī)器的IP地址。我們來看幾個URL：\h9:80/index.html\h:80/index.html\h/index.html第一個URL使用了機(jī)器的IP地址，9以及端口號80。第二個URL沒有使用數(shù)字形式的IP地址，它使用的是文本形式的域名，或者稱為主機(jī)名（\h）。主機(jī)名就是IP地址比較人性化的別稱。可以通過一種稱為域名服務(wù)（DomainNameService，DNS）的機(jī)制方便地將主機(jī)名轉(zhuǎn)換為IP地址，這樣所有問題就都解決了。第2章會介紹更多有關(guān)DNS和URL的內(nèi)容。最后一個URL沒有端口號。HTTP的URL中沒有端口號時，可以假設(shè)默認(rèn)端口號是80。有了IP地址和端口號，客戶端就可以很方便地通過TCP/IP進(jìn)行通信了。圖1-10顯示了瀏覽器是怎樣通過HTTP顯示位于遠(yuǎn)端服務(wù)器中的某個簡單HTML資源的。圖1-10基本的瀏覽器連接處理步驟如下：(a)瀏覽器從URL中解析出服務(wù)器的主機(jī)名；(b)瀏覽器將服務(wù)器的主機(jī)名轉(zhuǎn)換成服務(wù)器的IP地址；(c)瀏覽器將端口號（如果有的話）從URL中解析出來；(d)瀏覽器建立一條與Web服務(wù)器的TCP連接；(e)瀏覽器向服務(wù)器發(fā)送一條HTTP請求報文；(f)服務(wù)器向瀏覽器回送一條HTTP響應(yīng)報文；(g)關(guān)閉連接，瀏覽器顯示文檔。1.6.3一個使用Telnet的實例由于HTTP使用了TCP/IP傳輸協(xié)議，而且它是基于文本的，沒有使用那些難以理解的二進(jìn)制格式，因此很容易直接與Web服務(wù)器進(jìn)行對話。Telnet程序可以將鍵盤連接到某個目標(biāo)TCP端口，并將此TCP端口的輸出回送到顯示屏上。Telnet常用于遠(yuǎn)程終端會話，但它幾乎可以連接所有的TCP服務(wù)器，包括HTTP服務(wù)器?？梢酝ㄟ^Telnet程序直接與Web服務(wù)器進(jìn)行對話。通過Telnet可以打開一條到某臺機(jī)器上某個端口的TCP連接，然后直接向那個端口輸入一些字符。Web服務(wù)器會將Telnet程序作為一個Web客戶端來處理，所有回送給TCP連接的數(shù)據(jù)都會顯示在屏幕上。我們用Telnet與一個實際的Web服務(wù)器進(jìn)行交互。我們要用Telnet獲取URL\h:80/tools.html所指向的文檔（你可以自己嘗試一下這個實例）。我們來看看會發(fā)生什么情況。首先，查找\h的IP地址，打開一條到那臺機(jī)器端口80的TCP連接。Telnet會為我們完成那些“跑腿兒”的工作。一旦打開了TCP連接，就要輸入HTTP請求了。請求結(jié)束（由一個空行表示）之后，服務(wù)器會在一條HTTP響應(yīng)中將內(nèi)容回送并關(guān)閉連接。例1-1顯示了對\h:80/tools.html的HTTP請求實例。我們輸入的內(nèi)容用粗體字表示。例1-1一個使用Telnet的HTTP事務(wù)%telnet80

Trying5...

Connectedto.

Escapecharacteris'^]'.GET/tools.htmlHTTP/1.1Host:

HTTP/1.1200OK

Date:Sun,01Oct200023:25:17GMT

Server:Apache/1.3.11BSafe-SSL/1.38(Unix)FrontPage/

Last-Modified:Tue,04Jul200009:46:21GMT

ETag:"373979-193-3961b26d"

Accept-Ranges:bytes

Content-Length:403

Connection:close

Content-Type:text/html

<HTML>

<HEAD><TITLE>Joe'sTools</TITLE></HEAD>

<BODY>

<H1>ToolsPage</H1>

<H2>Hammers</H2>

<P>Joe'sHardwareOnlinehasthelargestselectionofhammersonthe

earth.</P>

<H2><ANAME=drills></A>Drills</H2>

<P>Joe'sHardwarehasacompletelineofcordlessandcordeddrills,

aswellasthelatest

inplutonium-poweredatomicdrills,forthosebigaroundthehouse

jobs.</P>...

</BODY>

</HTML>

Connectionclosedbyforeignhost.Telnet會查找主機(jī)名并打開一條連接，連接到在\h的端口80上監(jiān)聽的Web服務(wù)器。這條命令之后的三行內(nèi)容是Telnet的輸出，告訴我們它已經(jīng)建立了連接。然后我們輸入最基本的請求命令GET/tools.htmlHTTP/1.1，發(fā)送一個提供了源端主機(jī)名的Host首部，后面跟上一個空行，請求從服務(wù)器\h上獲取資源tools.html。隨后，服務(wù)器會以一個響應(yīng)行、幾個響應(yīng)首部、一個空行和最后面的HTML文檔主體來應(yīng)答。要明確的是，Telnet可以很好地模擬HTTP客戶端，但不能作為服務(wù)器使用。而且對Telnet做腳本自動化是很繁瑣乏味的。如果想要更靈活的工具，可以去看看nc（netcat）。通過nc可以很方便地操縱基于UDP和TCP的流量（包括HTTP），還可以為其編寫腳本。更多細(xì)節(jié)參見\h/tutorials/utilities/nc.php\h1。1.該鏈接已失效，讀者可以訪問\h/wiki/Netcat。（編者注）1.7協(xié)議版本現(xiàn)在使用的HTTP協(xié)議有幾個版本。HTTP應(yīng)用程序要盡量強(qiáng)健地處理各種不同的HTTP協(xié)議變體。目前仍在使用的版本如下。HTTP/0.9HTTP的1991原型版本稱為HTTP/0.9。這個協(xié)議有很多嚴(yán)重的設(shè)計缺陷，只應(yīng)該用于與老客戶端的交互。HTTP/0.9只支持GET方法，不支持多媒體內(nèi)容的MIME類型、各種HTTP首部，或者版本號。HTTP/0.9定義的初衷是為了獲取簡單的HTML對象，它很快就被HTTP/1.0取代了。HTTP/1.01.0是第一個得到廣泛使用的HTTP版本。HTTP/1.0添加了版本號、各種HTTP首部、一些額外的方法，以及對多媒體對象的處理。HTTP/1.0使得包含生動圖片的Web頁面和交互式表格成為可能，而這些頁面和表格促使萬維網(wǎng)為人們廣泛地接受。這個規(guī)范從未得到良好地說明。在這個HTTP協(xié)議的商業(yè)演進(jìn)和學(xué)術(shù)研究都在快速進(jìn)行的時代，它集合了一系列的最佳實踐。HTTP/1.0+在20世紀(jì)90年代中葉，很多流行的Web客戶端和服務(wù)器都在飛快地向HTTP中添加各種特性，以滿足快速擴(kuò)張且在商業(yè)上十分成功的萬維網(wǎng)的需要。其中很多特性，包括持久的keep-alive連接、虛擬主機(jī)支持，以及代理連接支持都被加入到HTTP之中，并成為非官方的事實標(biāo)準(zhǔn)。這種非正式的HTTP擴(kuò)展版本通常稱為HTTP/1.0+。HTTP/1.1HTTP/1.1重點關(guān)注的是校正HTTP設(shè)計中的結(jié)構(gòu)性缺陷，明確語義，引入重要的性能優(yōu)化措施，并刪除一些不好的特性。HTTP/1.1還包含了對20世紀(jì)90年代末正在發(fā)展中的更復(fù)雜的Web應(yīng)用程序和部署方式的支持。HTTP/1.1是當(dāng)前使用的HTTP版本。HTTP-NG（又名HTTP/2.0）HTTP-NG是HTTP/1.1后繼結(jié)構(gòu)的原型建議，它重點關(guān)注的是性能的大幅優(yōu)化，以及更強(qiáng)大的服務(wù)邏輯遠(yuǎn)程執(zhí)行框架。HTTP-NG的研究工作終止于1998年，編寫本書時，還沒有任何要用此建議取代HTTP/1.1的推廣計劃。更多信息請參見第10章。1.8Web的結(jié)構(gòu)組件在本章的概述中，我們重點介紹了兩個Web應(yīng)用程序（Web瀏覽器和Web服務(wù)器）是如何相互發(fā)送報文來實現(xiàn)基本事務(wù)處理的。在因特網(wǎng)上，要與很多Web應(yīng)用程序進(jìn)行交互。在本節(jié)中，我們將列出其他一些比較重要的應(yīng)用程序，如下所示。代理位于客戶端和服務(wù)器之間的HTTP中間實體。緩存HTTP的倉庫，使常用頁面的副本可以保存在離客戶端更近的地方。網(wǎng)關(guān)連接其他應(yīng)用程序的特殊Web服務(wù)器。隧道對HTTP通信報文進(jìn)行盲轉(zhuǎn)發(fā)的特殊代理。Agent代理發(fā)起自動HTTP請求的半智能Web客戶端。1.8.1代理首先我們來看看HTTP代理服務(wù)器，這是Web安全、應(yīng)用集成以及性能優(yōu)化的重要組成模塊。如圖1-11所示，代理位于客戶端和服務(wù)器之間，接收所有客戶端的HTTP請求，并將這些請求轉(zhuǎn)發(fā)給服務(wù)器（可能會對請求進(jìn)行修改之后轉(zhuǎn)發(fā)）。對用戶來說，這些應(yīng)用程序就是一個代理，代表用戶訪問服務(wù)器。圖1-11在客戶端和服務(wù)器之間轉(zhuǎn)發(fā)流量的代理出于安全考慮，通常會將代理作為轉(zhuǎn)發(fā)所有Web流量的可信任中間節(jié)點使用。代理還可以對請求和響應(yīng)進(jìn)行過濾。比如，在企業(yè)中對下載的應(yīng)用程序進(jìn)行病毒檢測，或者對小學(xué)生屏蔽一些成人才能看的內(nèi)容。我們將在第6章詳細(xì)介紹代理。1.8.2緩存Web緩存（Webcache）或代理緩存（proxycache）是一種特殊的HTTP代理服務(wù)器，可以將經(jīng)過代理傳送的常用文檔復(fù)制保存起來。下一個請求同一文檔的客戶端就可以享受緩存的私有副本所提供的服務(wù)了（參見圖1-12）。圖1-12保存常用文檔本地副本以提高性能的代理緩存客戶端從附近的緩存下載文檔會比從遠(yuǎn)程Web服務(wù)器下載快得多。HTTP定義了很多功能，使得緩存更加高效，并規(guī)范了文檔的新鮮度和緩存內(nèi)容的隱私性。第7章介紹了緩存技術(shù)。1.8.3網(wǎng)關(guān)網(wǎng)關(guān)（gateway）是一種特殊的服務(wù)器，作為其他服務(wù)器的中間實體使用。通常用于將HTTP流量轉(zhuǎn)換成其他的協(xié)議。網(wǎng)關(guān)接受請求時就好像自己是資源的源端服務(wù)器一樣?？蛻舳丝赡懿⒉恢雷约赫谂c一個網(wǎng)關(guān)進(jìn)行通信。例如，一個HTTP/FTP網(wǎng)關(guān)會通過HTTP請求接收對FTPURI的請求，但通過FTP協(xié)議來獲取文檔（參見圖1-13）。得到的文檔會被封裝成一條HTTP報文，發(fā)送給客戶端。第8章將探討網(wǎng)關(guān)。圖1-13HTTP/FTP網(wǎng)關(guān)1.8.4隧道隧道（tunnel）是建立起來之后，就會在兩條連接之間對原始數(shù)據(jù)進(jìn)行盲轉(zhuǎn)發(fā)的HTTP應(yīng)用程序。HTTP隧道通常用來在一條或多條HTTP連接上轉(zhuǎn)發(fā)非HTTP數(shù)據(jù)，轉(zhuǎn)發(fā)時不會窺探數(shù)據(jù)。HTTP隧道的一種常見用途是通過HTTP連接承載加密的安全套接字層（SSL，SecureSocketsLayer）流量，這樣SSL流量就可以穿過只允許Web流量通過的防火墻了。如圖1-14所示，HTTP/SSL隧道收到一條HTTP請求，要求建立一條到目的地址和端口的輸出連接，然后在HTTP信道上通過隧道傳輸加密的SSL流量，這樣就可以將其盲轉(zhuǎn)發(fā)到目的服務(wù)器上去了。圖1-14隧道可以在非HTTP網(wǎng)絡(luò)上轉(zhuǎn)發(fā)數(shù)據(jù)（顯示的是HTTP/SSL隧道）1.8.5.Agent代理用戶Agent代理（或者簡稱為Agent代理）是代表用戶發(fā)起HTTP請求的客戶端程序。所有發(fā)布Web請求的應(yīng)用程序都是HTTPAgent代理。到目前為止，我們只提到過一種HTTPAgent代理：Web瀏覽器，但用戶Agent代理還有很多其他類型。比如，有些自己會在Web上閑逛的自動用戶Agent代理，可以在無人監(jiān)視的情況下發(fā)布HTTP事務(wù)并獲取內(nèi)容。這些自動代理的名字通常都很生動，比如“網(wǎng)絡(luò)蜘蛛”（spiders）或者“Web機(jī)器人”（Webrobots）（參見圖1-15）。網(wǎng)絡(luò)蜘蛛會在Web上閑逛，搜集信息以構(gòu)建有效的Web內(nèi)容檔案，比如一個搜索引擎的數(shù)據(jù)庫或者為比較購物機(jī)器人生成的產(chǎn)品目錄。更多信息請參見第9章。圖1-15自動搜索引擎“網(wǎng)絡(luò)蜘蛛”就是Agent代理，可以從世界范圍內(nèi)獲取Web頁面1.9起始部分的結(jié)束語這就是我們對HTTP的簡要介紹。本章中，我們重點介紹了作為多媒體傳輸協(xié)議使用的HTTP。概要說明了HTTP是怎樣使用URI來命名遠(yuǎn)程服務(wù)器上的多媒體資源的，粗略介紹了如何利用HTTP請求和響應(yīng)報文操縱遠(yuǎn)程服務(wù)器上的多媒體資源，最后考察了幾種使用HTTP的Web應(yīng)用程序。本書的其余章節(jié)會更加詳細(xì)地介紹HTTP協(xié)議、應(yīng)用程序及資源的技術(shù)機(jī)制。1.10更多信息本書稍后的章節(jié)將更深入地研究HTTP，下面這些資源中也包含了與本章所涵蓋的特定主題有關(guān)的背景知識。1.10.1HTTP協(xié)議信息HTTPPocketReference（《HTTP口袋書》）ClintonWong著，O'Reilly&Associates出版公司。這本書詳細(xì)介紹了HTTP，可以作為構(gòu)成HTTP事務(wù)的首部和狀態(tài)碼的快速參考手冊。\h/Protocols/這個W3C的Web頁面中包含了很多與HTTP協(xié)議有關(guān)的重要鏈接。\h/rfc/rfc2616.txtRFC2616“超文本傳輸協(xié)議——HTTP/1.1”是當(dāng)前HTTP協(xié)議版本HTTP/1.1的官方規(guī)范。這個規(guī)范是一本編寫流暢、組織良好而且非常詳細(xì)的HTTP參考手冊，但并不適于那些希望了解HTTP底層概念和動因，或者原理與實際應(yīng)用之間區(qū)別的讀者閱讀。希望本書能夠?qū)@些底層概念進(jìn)行補(bǔ)充，以便讀者更好地使用這個規(guī)范。\h/rfc/rfc1945.txtRFC1945“超文本傳輸協(xié)議——HTTP/1.0”是一個描述了HTTP現(xiàn)代基礎(chǔ)的知識性RFC。它對編寫此規(guī)范時，已得到官方認(rèn)可且具有“最佳實踐”的Web應(yīng)用程序行為進(jìn)行了詳細(xì)描述。。還討論了一些雖被HTTP/1.1所摒棄，但在一些老舊的應(yīng)用程序中仍在廣泛使用的行為。\h/Protocols/HTTP/AsImplemented.html這個Web頁面介紹了1991年的HTTP/0.9協(xié)議，這個協(xié)議只實現(xiàn)了GET請求，而且不包含內(nèi)容類型。1.10.2歷史透視\h/Protocols/WhyHTTP.html這個簡要的Web頁面從1991年開始，從HTTP作者的角度，介紹了HTTP的一些起源以及初級目標(biāo)。\h/History.html“ALittleHistoryoftheWorldWideWeb”（萬維網(wǎng)的簡要?dú)v史）對萬維網(wǎng)和HTTP的一些早期目標(biāo)和構(gòu)建基礎(chǔ)進(jìn)行了簡短但有趣的剖析。\h/DesignIssues/Architecture.html“WebArchitecturefrom50,000feet”（高空俯瞰Web結(jié)構(gòu)）繪制了一幅廣闊、遠(yuǎn)大的萬維網(wǎng)藍(lán)圖，并詳述了影響HTTP和相關(guān)Web技術(shù)的設(shè)計原則。1.10.3其他萬維網(wǎng)信息\hW3C是Web的科技驅(qū)動團(tuán)隊。W3C致力于促進(jìn)Web演化的互操作性技術(shù)（規(guī)范、準(zhǔn)則、軟件及工具）研究。W3C站點是一個包含了Web技術(shù)簡介和詳細(xì)文檔的寶庫。\h/rfc/rfc2396.txtRFC2396“UniformResourceIdentifiers（URI）：GenericSyntax”，（“統(tǒng)一資源標(biāo)識符（URI）：通用語法”）是URI和URL的詳細(xì)參考。\hhttp://www.ieft.ofg/rfc/rfc2141.txtRFC2141“URNSyntax”（“URN的語法”）是一個寫于1997年的描述URN語法的規(guī)范。\h/rfc/rfc2046.txtRFC2046“MIMEPart2：MediaTypes”（“MIME第II部分：媒體類型”）是為進(jìn)行多媒體內(nèi)容管理而定義的多用途因特網(wǎng)郵件擴(kuò)展標(biāo)準(zhǔn)的五部因特網(wǎng)規(guī)范中的第二部。\h/Drafts/draft-ietf-wrec-taxonomy-06.txt這個因特網(wǎng)草案“InternetWebReplicationandCachingTaxonomy”（“因特網(wǎng)Web復(fù)制和緩存分類法”）解釋了Web結(jié)構(gòu)組件中的標(biāo)準(zhǔn)術(shù)語。第2章URL與資源我們可以把因特網(wǎng)當(dāng)作一個巨大的正在擴(kuò)張的城市，里面充滿了各種可看的東西，可做的事情。你和其他居民，以及到這個正在蓬勃發(fā)展的社區(qū)旅游的游客都要為這個城市大量的景點和服務(wù)使用標(biāo)準(zhǔn)命名規(guī)范。博物館、飯店和家庭住址要使用街道地址，消防局、老板的秘書，以及抱怨你太少打電話給她的母親要使用電話號碼。所有的東西都有一個標(biāo)準(zhǔn)化的名字，以幫助人們尋找城市中的各種資源。書籍有ISBN號，公交車有線路號，銀行賬戶有賬戶編碼，個人有社會保險號碼。明天，你要到機(jī)場的31號出口去接你的生意伙伴。每天早上你都要乘坐紅線火車，并在Kendall廣場站出站。所有人都對這些名字的標(biāo)準(zhǔn)達(dá)成了一致，所以才能方便地共享這座城市的寶藏。你告訴出租車司機(jī)把你載到McAllister大街246號，他就知道你是什么意思了（即使他走的是一條很遠(yuǎn)的路）。URL就是因特網(wǎng)資源的標(biāo)準(zhǔn)化名稱。URL指向一條條電子信息片段，告訴你它們位于何處，以及如何與之進(jìn)行交互。本章，我們將介紹以下內(nèi)容：URL語法，以及各種URL組件的含義及其所做的工作；很多Web客戶端都支持的URL快捷方式，包括相對URL和自動擴(kuò)展URL；URL編碼和字符規(guī)則；支持各種因特網(wǎng)信息系統(tǒng)的常見URL方案；URL的未來，包括URN——這種框架可以在對象從一處搬移到另一處時，保持穩(wěn)定的訪問名稱。2.1瀏覽因特網(wǎng)資源URL是瀏覽器尋找信息時所需的資源位置。通過URL，人類和應(yīng)用程序才能找到、使用并共享因特網(wǎng)上大量的數(shù)據(jù)資源。URL是人們對HTTP和其他協(xié)議的常用訪問點：一個人將瀏覽器指向一個URL，瀏覽器就會在幕后發(fā)送適當(dāng)?shù)膮f(xié)議報文來獲取人們所期望的資源。URI是一類更通用的資源標(biāo)識符，URL實際上是它的一個子集。URI是一個通用的概念，由兩個主要的子集URL和URN構(gòu)成，URL是通過描述資源的位置來標(biāo)識資源的，而URN（本章稍后會介紹）則是通過名字來識別資源的，與它們當(dāng)前所處位置無關(guān)。HTTP規(guī)范將更通用的概念URI作為其資源標(biāo)識符，但實際上，HTTP應(yīng)用程序處理的只是URI的URL子集。本書有時會不加區(qū)分地使用URI和URL，但我們講的基本上都是URL。比如說，你想要獲取URL\h/seasonal/index-fall.html。那么URL分以下三部分。URL的第一部分（http）是URL方案（scheme）。方案可以告知Web客戶端怎樣訪問資源。在這個例子中，URL說明要使用HTTP協(xié)議。URL的第二部分（\h）指的是服務(wù)器的位置。這部分告知Web客戶端資源位于何處。URL的第三部分（/seasonal/index-fall.html）是資源路徑。路徑說明了請求的是服務(wù)器上哪個特定的本地資源。對此的說明請參見圖2-1。圖2-1URL是怎樣與瀏覽器、客戶端、服務(wù)器以及服務(wù)器文件系統(tǒng)中的位置進(jìn)行關(guān)聯(lián)的URL可以通過HTTP之外的其他協(xié)議來訪問資源。它們可以指向因特網(wǎng)上的任意資源，或者個人的email賬戶：mailto:president@或者通過其他協(xié)議（比如FTP協(xié)議）訪問的各種文件：/pub/complete-price-list.xls或者從流視頻服務(wù)器上下載電影：rtsp://:554/interview/cto_videoURL提供了一種統(tǒng)一的資源命名方式。大多數(shù)URL都有同樣的：“方案://服務(wù)器位置/路徑”結(jié)構(gòu)。因此，對網(wǎng)絡(luò)上的每個資源以及獲取這些資源的每種方式來說，命名資源的方法都只有一種，這樣不管是誰都可以用名字來找到這個資源了。但是，事情并不是一開始就是這樣的。URL出現(xiàn)之前的黑暗歲月在Web和URL出現(xiàn)之前，人們要靠分類雜亂的應(yīng)用程序來訪問分布在網(wǎng)絡(luò)中的數(shù)據(jù)。大多數(shù)人都不會幸運(yùn)地?fù)碛兴泻线m的應(yīng)用程序，或者不能夠理解，也沒有足夠的耐心來使用這些程序。在URL出現(xiàn)之前，要想和朋友共享complete-catalog.xls文件，就得說這樣一些話：“用FTP連接到上。用匿名登錄，然后輸入你的用戶名作為密碼。變換到pub目錄。轉(zhuǎn)換為二進(jìn)制模式?，F(xiàn)在，可以將名為complete-catalog.xls的文件下載到本地文件系統(tǒng)，并在那里瀏覽這個文件了。”現(xiàn)在，像網(wǎng)景的Navigator和微軟的InternetExplorer這樣的瀏覽器都將很多這樣的功能捆綁成一個便捷包。通過URL，這些應(yīng)用程序就可以通過一個接口，以統(tǒng)一的方式去訪問許多資源了。只要說“將瀏覽器指向/pub/complete-catalog.xls”就可以取代上面那些復(fù)雜的指令了。URL為應(yīng)用程序提供了一種訪問資源的手段。實際上，很多用戶可能都不知道他們的瀏覽器在獲取所請求資源時所使用的協(xié)議和訪問方法。有了Web瀏覽器，就不再需要用新聞閱讀器來閱讀因特網(wǎng)新聞，或者用FTP客戶端來訪問FTP服務(wù)器上的文件了，而且也無需用電子郵件程序來收發(fā)E-mail報文了。URL告知瀏覽器如何對資源進(jìn)行訪問和處理，這有助于簡化復(fù)雜的網(wǎng)絡(luò)世界1。應(yīng)用程序可以使用URL來簡化信息的訪問過程。1瀏覽器通常會用其他應(yīng)用程序來處理特殊的資源。比如，InternetExplorer就啟動了一個E-mail應(yīng)用程序來處理那些表示E-mail資源的URL。URL為用戶及他們的瀏覽器提供了找到信息所需的所有條件。URL定義了用戶所需的特定資源，它位于何處以及如何獲取它。2.2URL的語法URL提供了一種定位因特網(wǎng)上任意資源的手段，但這些資源是可以通過各種不同的方案（比如HTTP、FTP、SMTP）來訪問的，因此URL語法會隨方案的不同而有所不同。這是不是意味著每種不同的URL方案都會有完全不同的語法呢？實際上，不是的。大部分URL都遵循通用的URL語法，而且不同URL方案的風(fēng)格和語法都有不少重疊。大多數(shù)URL方案的URL語法都建立在這個由9部分構(gòu)成的通用格式上：<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>幾乎沒有哪個URL中包含了所有這些組件。URL最重要的3個部分是方案（scheme）、主機(jī)（host）和路徑（path）。表2-1對各種組件進(jìn)行了總結(jié)。表2-1通用URL組件

組件描述默認(rèn)值方案訪問服務(wù)器以獲取資源時要使用哪種協(xié)議無用戶某些方案訪問資源時需要的用戶名匿名密碼用戶名后面可能要包含的密碼，中間由冒號（:）分隔<E-mail地址>主機(jī)資源宿主服務(wù)器的主機(jī)名或點分IP地址無端口資源宿主服務(wù)器正在監(jiān)聽的端口號。很多方案都有默認(rèn)端口號（HTTP的默認(rèn)端口號為80）每個方案特有路徑服務(wù)器上資源的本地名，由一個斜杠（/）將其與前面的URL組件分隔開來。路徑組件的語法是與服務(wù)器和方案有關(guān)的（本章稍后會講到URL路徑可以分為若干個段，每段都可以有其特有的組件。）無參數(shù)某些方案會用這個組件來指定輸入?yún)?shù)。參數(shù)為名/值對。URL中可以包含多個參數(shù)字段，它們相互之間以及與路徑的其余部分之間用分號（;）分隔無查詢某些方案會用這個組件傳遞參數(shù)以激活應(yīng)用程序（比如數(shù)據(jù)庫、公告板、搜索引擎以及其他因特網(wǎng)網(wǎng)關(guān)）。查詢組件的內(nèi)容沒有通用格式。用字符“?”將其與URL的其余部分分隔開來無片段一小片或一部分資源的名字。引用對象時，不會將frag字段傳送給服務(wù)器；這個字段是在客戶端內(nèi)部使用的。通過字符“#”將其與URL的其余部分分隔開來無比如，我們來看看URL：\h:80/index.html，其方案是http，主機(jī)為\h，端口是80，路徑為/index.html。2.2.1方案——使用什么協(xié)議方案實際上是規(guī)定如何訪問指定資源的主要標(biāo)識符，它會告訴負(fù)責(zé)解析URL的應(yīng)用程序應(yīng)該使用什么協(xié)議。在我們這個簡單的HTTPURL中所使用的方案就是http。方案組件必須以一個字母符號開始，由第一個“:”符號將其與URL的其余部分分隔開來。方案名是大小寫無關(guān)的，因此URL“\h”和“\hHTTP://”是等價的。2.2.2主機(jī)與端口要想在因特網(wǎng)上找到資源，應(yīng)用程序要知道是哪臺機(jī)器裝載了資源，以及在那臺機(jī)器的什么地方可以找到能對目標(biāo)資源進(jìn)行訪問的服務(wù)器。URL的主機(jī)和端口組件提供了這兩組信息。主機(jī)組件標(biāo)識了因特網(wǎng)上能夠訪問資源的宿主機(jī)器?？梢杂蒙鲜鲋鳈C(jī)名（\h），或者IP地址來表示主機(jī)名。比如，下面兩個URL就指向同一個資源——第一個URL是通過主機(jī)名，第二個是通過IP地址指向服務(wù)器的：\h:80/index.html\h5:80/index.html端口組件標(biāo)識了服務(wù)器正在監(jiān)聽的網(wǎng)絡(luò)端口。對下層使用了TCP協(xié)議的HTTP來說，默認(rèn)端口號為80。2.2.3用戶名和密碼更有趣的組件是用戶和密碼組件。很多服務(wù)器都要求輸入用戶名和密碼才會允許用戶訪問數(shù)據(jù)。FTP服務(wù)器就是這樣一個常見的實例。這里有幾個例子：/pub/gnuftp://anonymous@/pub/gnuftp://anonymous:my_passwd@/pub/gnu\hhttp://joe:joespasswd@/sales_info.txt第一個例子沒有用戶或密碼組件，只有標(biāo)準(zhǔn)的方案、主機(jī)和路徑。如果某應(yīng)用程序使用的URL方案要求輸入用戶名和密碼，比如FTP，但用戶沒有提供，它通常會插入一個默認(rèn)的用戶名和密碼。比如，如果向瀏覽器提供一個FTPURL，但沒有指定用戶名和密碼，它就會插入anonymous（匿名用戶）作為你的用戶名，并發(fā)送一個默認(rèn)的密碼（InternetExplorer會發(fā)送IEUser，NetscapeNavigator則會發(fā)送mozilla）。第二個例子顯示了一個指定為anonymous的用戶名。這個用戶名與主機(jī)組件組合在一起，看起來就像E-mail地址一樣。字符“@”將用戶和密碼組件與URL的其余部分分隔開來。在第三個例子中，指定了用戶名（anonymous）和密碼（my_passwd），兩者之間由字符“:”分隔。2.2.4路徑URL的路徑組件說明了資源位于服務(wù)器的什么地方。路徑通常很像一個分級的文件系統(tǒng)路徑。比如：\h:80/seasonal/index-fall.html這個URL中的路徑為/seasonal/index-fall.html，很像UNIX文件系統(tǒng)中的文件系統(tǒng)路徑。路徑是服務(wù)器定位資源時所需的信息。1可以用字符“/”將HTTPURL的路徑組件劃分成一些路徑段（pathsegment）（還是與UNIX文件系統(tǒng)中的文件路徑類似）。每個路徑段都有自己的參數(shù)（param）組件。1這是一種簡化的說法。在18.2節(jié)我們會看到，路徑并不總能為資源定位提供足夠的信息。有時服務(wù)器還需要其他的信息。2.2.5參數(shù)對很多方案來說，只有簡單的主機(jī)名和到達(dá)對象的路徑是不夠的。除了服務(wù)器正在監(jiān)聽的端口，以及是否能夠通過用戶名和密碼訪問資源外，很多協(xié)議都還需要更多的信息才能工作。負(fù)責(zé)解析URL的應(yīng)用程序需要這些協(xié)議參數(shù)來訪問資源。否則，另一端的服務(wù)器可能就不會為請求提供服務(wù)，或者更糟糕的是，提供錯誤的服務(wù)。比如，像FTP這樣的協(xié)議，有兩種傳輸模式，二進(jìn)制和文本形式。你肯定不希望以文本形式來傳送二進(jìn)制圖片，這樣的話，二進(jìn)制圖片可能會變得一團(tuán)糟。為了向應(yīng)用程序提供它們所需的輸入?yún)?shù)，以便正確地與服務(wù)器進(jìn)行交互，URL中有一個參數(shù)組件。這個組件就是URL中的名值對列表，由字符“;”將其與URL的其余部分（以及各名值對）分隔開來。它們?yōu)閼?yīng)用程序提供了訪問資源所需的所有附加信息。比如：/pub/gnu;type=d在這個例子中，有一個參數(shù)type=d，參數(shù)名為type，值為d。如前所述，HTTPURL的路徑組件可以分成若干路徑段。每段都可以有自己的參數(shù)。比如：\h/hammers;sale=false/index.html;graphics=true這個例子就有兩個路徑段，hammers和index.html。hammers路徑段有參數(shù)sale，其值為false。index.html段有參數(shù)graphics，其值為true。2.2.6查詢字符串很多資源，比如數(shù)據(jù)庫服務(wù)，都是可以通過提問題或進(jìn)行查詢來縮小所請求資源類型范圍的。假設(shè)Joe的五金商店在數(shù)據(jù)庫中維護(hù)著一個未售貨物的清單，并可以對清單進(jìn)行查詢，以判斷產(chǎn)品是否有貨，那就可以用下列URL來查詢Web數(shù)據(jù)庫網(wǎng)關(guān)，看看編號為12731的條目是否有貨：\h/inventory-check.cgi?item=12731這個URL的大部分都與我們見過的其他URL類似。只有問號（?）右邊的內(nèi)容是新出現(xiàn)的。這部分被稱為查詢（query）組件。URL的查詢組件和標(biāo)識網(wǎng)關(guān)資源的URL路徑組件一起被發(fā)送給網(wǎng)關(guān)資源。基本上可以將網(wǎng)關(guān)當(dāng)作訪問其他應(yīng)用程序的訪問點（第8章會對網(wǎng)關(guān)進(jìn)行詳細(xì)的討論）。圖2-2中有一個作為Joe的五金商店清單查詢應(yīng)用程序的網(wǎng)關(guān)的服務(wù)器，在這個例子中向此服務(wù)器發(fā)送了一個查詢組件。查詢的目的是檢查清單中是否有尺寸為large、顏色為blue的條目12731。圖2-2發(fā)送給網(wǎng)關(guān)應(yīng)用程序的URL查詢組件在本章稍后會看到，除了有些不合規(guī)則的字符需要特別處理之外，對查詢組件的格式?jīng)]什么要求。按照常規(guī)，很多網(wǎng)關(guān)都希望查詢字符串以一系列“名/值”對的形式出現(xiàn)，名值對之間用字符“&”分隔：\h/inventory-check.cgi?item=12731&color=blue在這個例子中，查詢組件有兩個名/值對：item=12731和color=blue。2.2.7片段有些資源類型，比如HTML，除了資源級之外，還可以做進(jìn)一步的劃分。比如，對一個帶有章節(jié)的大型文本文檔來說，資源的URL會指向整個文本文檔，但理想的情況是，能夠指定資源中的那些章節(jié)。為了引用部分資源或資源的一個片段，URL支持使用片段（frag）組件來表示一個資源內(nèi)部的片段。比如，URL可以指向HTML文檔中一個特定的圖片或小節(jié)。片段掛在URL的右手邊，最前面有一個字符“#”。比如：\h/tools.html#drills在這個例子中，片段drills引用了Joe的五金商店Web服務(wù)器上頁面/tools.html中的一個部分。這部分的名字叫做drills。HTTP服務(wù)器通常只處理整個對象，2而不是對象的片段，客戶端不能將片段傳送給服務(wù)器（參見圖2-3）。瀏覽器從服務(wù)器獲得了整個資源之后，會根據(jù)片段來顯示你感興趣的那部分資源。2在15.9節(jié)會看到HTTPAgent代理可能會請求某個字節(jié)范圍內(nèi)的對象，但在URL片段的上下文中，服務(wù)器會發(fā)送整個對象，由Agent代理將片段標(biāo)識符應(yīng)用于資源。圖2-3服務(wù)器處理的是整個對象，因此URL片段僅由客戶端使用2.3URL快捷方式Web客戶端可以理解并使用幾種URL快捷方式。相對URL是在某資源內(nèi)部指定一個資源的便捷縮略方式。很多瀏覽器還支持URL的“自動擴(kuò)展”，也就是用戶輸入URL的一個關(guān)鍵（可記憶的）部分，然后由瀏覽器將其余部分填充起來。2.3.2節(jié)對此進(jìn)行了解釋。2.3.1相對URLURL有兩種方：絕對的和相對的。到目前為止，我們只見過絕對URL。絕對URL中包含有訪問資源所需的全部信息。另一方面，相對URL是不完整的。要從相對URL中獲取訪問資源所需的全部信息，就必須相對于另一個，被稱為其基礎(chǔ)（base）的URL進(jìn)行解析。相對URL是URL的一種便捷縮略記法。如果你手工寫過HTML的話，可能就會發(fā)現(xiàn)相對URL是多么便捷了。例2-1是一個嵌入了相對URL的HTML文檔實例。例2-1帶有相對URL的HTML代碼片段<HTML>

<HEAD><TITLE>Joe'sTools</TITLE></HEAD>

<BODY>

<H1>ToolsPage</H1>

<H2>Hammers<H2>

<P>Joe'sHardwareOnlinehasthelargestselectionof<AHREF="./hammers.html">hammers

</A>onearth.

</BODY>

</HTML>例2-1是資源：\h/tools.html的HTML文檔。在這個HTML文檔中有一個包含了URL./hammers.html的超鏈接。這個URL看起來是不完整的，但實際上是個合法的相對URL。可以相對于它所在文檔的URL對其進(jìn)行解釋；在這個例子中，就是相對于Joe的五金商店Web服務(wù)器的資源/tools.html。使用縮略形式的相對URL語法，HTML的編寫者就可以省略URL中的方案、主機(jī)和其他一些組件了。這些組件可以從它們所屬資源的基礎(chǔ)URL中推導(dǎo)出來。其他資源的URL也可以用這種縮略形式來表示。在例2-1中，基礎(chǔ)URL為：\h/tools.html用這個URL作為基礎(chǔ)，可以推導(dǎo)出缺失的信息。我們知道資源名為./hammers.html，但并不知道方案或主機(jī)名是什么。通過這個基礎(chǔ)URL，可以推導(dǎo)出方案為http，主機(jī)為\h。圖2-4對此進(jìn)行了說明。圖2-4使用基礎(chǔ)URL相對URL只是URL的片段或一小部分。處理URL的應(yīng)用程序（比如瀏覽器）要能夠在相對和絕對URL之間進(jìn)行轉(zhuǎn)換。還需要注意的是，相對URL為保持一組資源（比如一些HTML頁面）的可移植性提供了一種便捷方式。如果使用的是相對URL，就可以在搬移一組文檔的同時，仍然保持鏈接的有效性，因為相對URL都是相對于新基礎(chǔ)進(jìn)行解釋的。這樣就可以實現(xiàn)在其他服務(wù)器上提供鏡像內(nèi)容之類的功能了?；A(chǔ)URL轉(zhuǎn)換處理的第一步就是找到基礎(chǔ)URL?；A(chǔ)URL是作為相對URL的參考點使用的?？梢詠碜砸韵聨讉€不同的地方。在資源中顯式提供有些資源會顯式地指定基礎(chǔ)URL。比如，HTML文檔中可能會包含一個定義了基礎(chǔ)URL的HTML標(biāo)記<BASE>，通過它來轉(zhuǎn)換那個HTML文檔中的所有相對URL。封裝資源的基礎(chǔ)URL如果在一個沒有顯式指定基礎(chǔ)URL的資源中發(fā)現(xiàn)了一個相對URL，如例2-1所示，可以將它所屬資源的URL作為基礎(chǔ)（如例中所示）。沒有基礎(chǔ)URL在某些情況下，沒有基礎(chǔ)URL。這通常意味著你有一個相對URL；但有時可能只是一個不完整或損壞了的URL。解析相對引用前面我們介紹了URL的基本組件和語法。要將相對URL轉(zhuǎn)換為一個絕對URL，下一步要做的就是將相對URL和基礎(chǔ)URL劃分成組件段。實際上，這樣只是在解析URL，但這種做法會將其劃分成一個個組件，因此通常會稱作分解（decomposing）URL。只要將基礎(chǔ)和相對URL劃分成了組件，就可以應(yīng)用圖2-5中的算法來完成轉(zhuǎn)換了。圖2-5將相對URL轉(zhuǎn)換成絕對URL這個算法將一個相對URL轉(zhuǎn)換成了其絕對模式，之后就可以用它來引用資源了。這個算法最初是在RFC1808中制定的，后來被合并到了RFC2396中?？梢詫?-1中的./hammers.html實例使用圖2-5中描述的算法。路徑為./hammers.html，基礎(chǔ)URL為\h/tools.html。方案為空，沿著圖表的左半邊向下處理，繼承基礎(chǔ)URL方案（HTTP）。至少一個組件非空，一直處理到底端，繼承主機(jī)和端口組件。將來自相對URL（路徑：./hammers.html）的組件與我們繼承來的組件（方案：http，主機(jī)：\h，端口：80）合并起來，得到新的絕對URL：\h/hammers.html。2.3.2自動擴(kuò)展URL有些瀏覽器會在用戶提交URL之后，或者在用戶輸入的時候嘗試著自動擴(kuò)展URL。這就為用戶提供了一條捷徑：用戶不需要輸入完整的URL，因為瀏覽器會自動擴(kuò)展。這些“自動擴(kuò)展”特性有以下兩種方式。主機(jī)名擴(kuò)展在主機(jī)名擴(kuò)展中，只要有些小提示，瀏覽器通常就可以在沒有幫助的情況下，將你輸入的主機(jī)名擴(kuò)展為完整的主機(jī)名。比如，如果在地址欄中輸入yahoo，瀏覽器就會自動在主機(jī)名中插入www.和.com，構(gòu)建出\h。如果找不到與yahoo匹配的站點，有些瀏覽器會在放棄之前嘗試幾種擴(kuò)展形式。瀏覽器通過這些簡單的技巧來節(jié)省你的時間，減少找不到的可能。但是，這些主機(jī)名擴(kuò)展技巧可能會為其他一些HTTP應(yīng)用程序帶來問題，比如代理。第6章將詳細(xì)討論這些問題。歷史擴(kuò)展瀏覽器用來節(jié)省用戶輸入URL時間的另一種技巧是，將以前用戶訪問過的URL歷史存儲起來。當(dāng)你輸入URL時，它們就可以將你輸入的URL與歷史記錄中URL的前綴進(jìn)行匹配，并提供一些完整的選項供你選擇。因此，如果你輸入了一個以前訪問過的URL的開始部分，比如http://www.joes-，瀏覽器就可能會建議使用\h。然后你就可以選擇這個地址，不用輸入完整的URL了。注意，與代理共同使用時，URL自動擴(kuò)展的行為可能會有所不同。6.5.6節(jié)將對此進(jìn)行進(jìn)一步討論。2.4各種令人頭疼的字符URL是可移植的（portable）。它要統(tǒng)一地命名因特網(wǎng)上所有的資源，這也就意味著要通過各種不同的協(xié)議來傳送這些資源。這些協(xié)議在傳輸數(shù)據(jù)時都會使用不同的機(jī)制，所以，設(shè)計URL，使其可以通過任意因特網(wǎng)協(xié)議安全地傳輸是很重要的。安全傳輸意味著URL的傳輸不能丟失信息。有些協(xié)議，比如傳輸電子郵件的簡單郵件傳輸協(xié)議（SimpleMailTransferProtocol，SMTP），所使用的傳輸方法就會剝?nèi)ヒ恍┨囟ǖ淖址?為了避開這些問題，URL只能使用一些相對較小的、通用的安全字母表中的字符。1這是由報文的7位二進(jìn)制碼編碼造成的