請求URI定位資源

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

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

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

告知服務器意圖的HTTP方法

GET：獲取資源

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

使用GET方法的請求·響應的例子

POST：傳輸實體主體

POST方法用來傳輸實體的主體。

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

PUT：傳輸文件

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

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

HEAD：獲得報文首部

HEAD方法和GET方法一樣，只是不返回報文主體部分。用于確認URI的有效性及資源更新的日期時間等。

DELETE：刪除文件

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

一般的Web網(wǎng)站也不使用DELETE方法。當配合Web應用程序的驗證機制，或遵守REST標準時還是有可能會開放使用的。

使用方法下達命令

請求URI指定的資源發(fā)送請求報文時，采用稱為方法的命令。

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

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

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

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

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

以當年的通信情況來說，因為都是些容量很小的文本傳輸，所以即使這樣也沒有多大問題?？呻S著HTTP的普及，文檔中包含大量圖片的情況多了起來。

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

持久連接

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

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

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

管線化

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

這樣就能夠做到同時并行發(fā)送多個請求，而不需要一個接一個地等待響應了。

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

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

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

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

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

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