請(qǐng)求URI定位資源

HTTP協(xié)議使用URI定位互聯(lián)網(wǎng)上的資源。正是因?yàn)?/span>URI的特定功能，在互聯(lián)網(wǎng)上任意位置的資源都能訪問到。

當(dāng)客戶端請(qǐng)求訪問資源而發(fā)送請(qǐng)求時(shí)，URI需要將作為請(qǐng)求報(bào)文中的請(qǐng)求URI包含在內(nèi)。指定請(qǐng)求URI的方式有很多。

除此之外，如果不是訪問特定資源而是對(duì)服務(wù)器本身發(fā)起請(qǐng)求，可以用一個(gè)*來代替請(qǐng)求URI。下面這個(gè)例子是查詢HTTP服務(wù)器端支持的HTTP方法種類。

告知服務(wù)器意圖的HTTP方法

GET：獲取資源

GET方法用來請(qǐng)求訪問已被URI識(shí)別的資源。指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容。也就是說，如果請(qǐng)求的資源是文本，那就保持原樣返回；如果是像CGI（Common Gateway Interface，通用網(wǎng)關(guān)接口）那樣的程序，則返回經(jīng)過執(zhí)行后的輸出結(jié)果。

使用GET方法的請(qǐng)求·響應(yīng)的例子

POST：傳輸實(shí)體主體

POST方法用來傳輸實(shí)體的主體。

雖然用GET方法也可以傳輸實(shí)體的主體，但一般不用GET方法進(jìn)行傳輸，而是用POST方法。雖說POST的功能與GET很相似，但POST的主要目的并不是獲取響應(yīng)的主體內(nèi)容。

PUT：傳輸文件

PUT方法用來傳輸文件。就像FTP協(xié)議的文件上傳一樣，要求在請(qǐng)求報(bào)文的主體中包含文件內(nèi)容，然后保存到請(qǐng)求URI指定的位置。

一般的Web網(wǎng)站不使用該方法。若配合Web應(yīng)用程序的驗(yàn)證機(jī)制，或架構(gòu)設(shè)計(jì)采用REST（Representational State Transfer，表征狀態(tài)轉(zhuǎn)移）標(biāo)準(zhǔn)的同類Web網(wǎng)站，就可能會(huì)開放使用PUT方法。

HEAD：獲得報(bào)文首部

HEAD方法和GET方法一樣，只是不返回報(bào)文主體部分。用于確認(rèn)URI的有效性及資源更新的日期時(shí)間等。

DELETE：刪除文件

DELETE方法用來刪除文件，是與PUT相反的方法。DELETE方法按請(qǐng)求URI刪除指定的資源。

一般的Web網(wǎng)站也不使用DELETE方法。當(dāng)配合Web應(yīng)用程序的驗(yàn)證機(jī)制，或遵守REST標(biāo)準(zhǔn)時(shí)還是有可能會(huì)開放使用的。

使用方法下達(dá)命令

請(qǐng)求URI指定的資源發(fā)送請(qǐng)求報(bào)文時(shí)，采用稱為方法的命令。

方法的作用在于，可以指定請(qǐng)求的資源按期望產(chǎn)生某種行為。方法中有GET、POST和HEAD等。

下表列出了HTTP/1.0和HTTP/1.1支持的方法。另外，方法名區(qū)分大小寫，注意要用大寫字母。

在這里列舉的眾多方法中，LINK和UNLINK已被HTTP/1.1廢棄，不再支持。

持久連接節(jié)省通信量

HTTP協(xié)議的初始版本中，每進(jìn)行一次HTTP通信就要斷開一次TCP連接。

以當(dāng)年的通信情況來說，因?yàn)槎际切┤萘亢苄〉奈谋緜鬏?，所以即使這樣也沒有多大問題?？呻S著HTTP的普及，文檔中包含大量圖片的情況多了起來。

比如，使用瀏覽器瀏覽一個(gè)包含多張圖片的HTML頁面時(shí)，在發(fā)送請(qǐng)求訪問HTML頁面資源的同時(shí)，也會(huì)請(qǐng)求該HTML頁面里包含的其他資源。因此，每次的請(qǐng)求都會(huì)造成無謂的TCP連接建立和斷開，增加通信量的開銷。

持久連接

為解決上述TCP連接的問題，HTTP/1.1和一部分的HTTP/1.0想出了持久連接（HTTP Persistent Connections，也稱為HTTP keep-alive或HTTP connectionreuse）的方法。持久連接的特點(diǎn)是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態(tài)。

持久連接的好處在于減少了TCP連接的重復(fù)建立和斷開所造成的額外開銷，減輕了服務(wù)器端的負(fù)載。另外，減少開銷的那部分時(shí)間，使HTTP請(qǐng)求和響應(yīng)能夠更早地結(jié)束，這樣Web頁面的顯示速度也就相應(yīng)提高了。

在HTTP/1.1中，所有的連接默認(rèn)都是持久連接，但在HTTP/1.0內(nèi)并未標(biāo)準(zhǔn)化。雖然有一部分服務(wù)器通過非標(biāo)準(zhǔn)的手段實(shí)現(xiàn)了持久連接，但服務(wù)器端不一定能夠支持持久連接。毫無疑問，除了服務(wù)器端，客戶端也需要支持持久連接。

管線化

持久連接使得多數(shù)請(qǐng)求以管線化（pipelining）方式發(fā)送成為可能。從前發(fā)送請(qǐng)求后需等待并收到響應(yīng)，才能發(fā)送下一個(gè)請(qǐng)求。管線化技術(shù)出現(xiàn)后，不用等待響應(yīng)亦可直接發(fā)送下一個(gè)請(qǐng)求。

這樣就能夠做到同時(shí)并行發(fā)送多個(gè)請(qǐng)求，而不需要一個(gè)接一個(gè)地等待響應(yīng)了。

比如，當(dāng)請(qǐng)求一個(gè)包含10張圖片的HTML Web頁面，與挨個(gè)連接相比，用持久連接可以讓請(qǐng)求更快結(jié)束。而管線化技術(shù)則比持久連接還要快。請(qǐng)求數(shù)越多，時(shí)間差就越明顯。

使用Cookie的狀態(tài)管理

HTTP是無狀態(tài)協(xié)議，它不對(duì)之前發(fā)生過的請(qǐng)求和響應(yīng)的狀態(tài)進(jìn)行管理。也就是說，無法根據(jù)之前的狀態(tài)進(jìn)行本次的請(qǐng)求處理。

假設(shè)要求登錄認(rèn)證的Web頁面本身無法進(jìn)行狀態(tài)的管理（不記錄已登錄的狀態(tài)），那么每次跳轉(zhuǎn)新頁面就要再次登錄，或者要在每次請(qǐng)求報(bào)文中附加參數(shù)來管理登錄狀態(tài)。

不可否認(rèn)，無狀態(tài)協(xié)議當(dāng)然也有它的優(yōu)點(diǎn)。由于不必保存狀態(tài)，自然可減少服務(wù)器的CPU及內(nèi)存資源的消耗。從另一側(cè)面來說，也正是因?yàn)?/span>HTTP協(xié)議本身是非常簡單的，所以才會(huì)被應(yīng)用在各種場景里。

保留無狀態(tài)協(xié)議這個(gè)特征的同時(shí)又要解決類似的矛盾問題，于是引入了Cookie技術(shù)。Cookie技術(shù)通過在請(qǐng)求和響應(yīng)報(bào)文中寫入Cookie信息來控制客戶端的狀態(tài)。Cookie會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請(qǐng)求時(shí)，客戶端會(huì)自動(dòng)在請(qǐng)求報(bào)文中加入Cookie值后發(fā)送出去。服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的Cookie后，會(huì)去檢查究竟是從哪一個(gè)客戶端發(fā)來的連接請(qǐng)求，然后對(duì)比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。