超文本傳輸協(xié)議

目錄
·概述
·請求信息
·請求方法
·安全方法
·協(xié)議版本號
·狀態(tài)行
·持久連接
·安全超文本協(xié)議
·例子





超文本傳輸協(xié)議(HTTP，HyperText Transfer Protocol)是因特網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個標準。設(shè)計HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。




概述

HTTP的發(fā)展是萬維網(wǎng)協(xié)會和Internet工作小組合作的結(jié)果，在一系列的RFC發(fā)布了最終的版本，其中最著名的是RFC 2616。在RFC 2616中定義了HTTP 1.1這個今天普遍使用的版本。
HTTP是一個用于在客戶端和服務(wù)器間請求和應(yīng)答的協(xié)議（TCP）。一個HTTP的客戶端，諸如一個web瀏覽器，通過建立一個到遠程主機特殊端口（默認端口為80）的連接，初始化一個請求。一個HTTP服務(wù)器通過監(jiān)聽特殊端口等待客戶端發(fā)送一個請求序列， 就像“GET / HTTP/1.1”（用來請求網(wǎng)頁服務(wù)器的默認頁面），有選擇的接收像email一樣的MIME消息，此消息中包含了大量用來描述請求各個方面的信息頭序列，響應(yīng)一個選擇的保留數(shù)據(jù)主體。接收到一個請求序列后（如果要的話，還有消息），服務(wù)器會發(fā)回一個回復(fù)，如“200 OK”，同時發(fā)回一個它本報的消息，此消息的主體可能是被請求的文件、錯誤消息或者其他的一些信息。
HTTP 并不局限于使用網(wǎng)絡(luò)協(xié)議（TCP/IP）及其相關(guān)支持層，盡管這是它在互聯(lián)網(wǎng)上最為流行的應(yīng)用程序。 事實上，HTTP可以“在任何其他互聯(lián)網(wǎng)協(xié)議之上執(zhí)行，或者在其他網(wǎng)絡(luò)上執(zhí)行。HTTP 只認可可靠的傳輸，任何能夠提供這種保證的協(xié)議都可以被其使用。
HTTP不同于其他基于TCP的協(xié)議，諸如FTP。在HTTP中，一旦一個特殊的請求（或者請求的相關(guān)序列）完成，連接通常被中斷。這個設(shè)計使得對于當前頁面有規(guī)則連接到另一臺服務(wù)器頁面的萬維網(wǎng)來說，HTTP是完美的。當持久連接的缺乏成為保持用戶狀態(tài)的必需選擇的方法時，對網(wǎng)頁設(shè)計者來說，會偶然產(chǎn)生一些問題。而大部分這些方法包括了對“cookies”的使用。
這里有一個HTTP的安全版本稱為HTTPS，HTTPS支持任何的加密算法，只要此加密算法能被頁面雙方所理解。
HTTP（和HTTPS）由統(tǒng)一資源定位器或者簡稱URLs定位。創(chuàng)造這種地址定位的語法為了HTML的鏈接。


請求信息

發(fā)出的請求信息包括以下幾個

請求行，例如GET /images/logo.gif HTTP/1.1，表示從/images 目錄下請求logo.gif 這個文件。
標題，例如Accept-Language: en
空行
可選信息

請求行和標題必須以<CR><LF> 作為結(jié)尾（也就是，回車然后換行）�？招袃�(nèi)必須只有<CR><LF>而無其他空格。在HTTP/1.1 協(xié)議中，所有的標題除主機外都是可選的。


請求方法

HTTP 定義了八種方法來指示確認的資源執(zhí)行所需的行為。
HEAD

要求與GET請求相應(yīng)的回復(fù)一樣的應(yīng)答，但是沒有回應(yīng)的內(nèi)容。這對找回寫在回應(yīng)標題中的
meta-infomation有幫助，不需要傳輸整個內(nèi)容。

GET

請求某個特殊的資源，是目前網(wǎng)上最通用的方法。不應(yīng)該用于一些會造成副作用的操作中
（在網(wǎng)絡(luò)軟件中使用是一個常見的錯誤用法）。參看下個目錄的安全方法。

POST

向確定的資源提交需要處理的數(shù)據(jù)。這些數(shù)據(jù)包括在請求的內(nèi)容里。這可以造成新資源的產(chǎn)生和更新已有資源。

PUT

上傳特定資源

DELETE

刪除特定資源

TRACE

返回接收的請求，客戶端可因此察看在請求過程中什么中間服務(wù)器被加進來或者有所改變。

OPTIONS

返回服務(wù)器支持的HTTP方法，這可以用來檢查網(wǎng)絡(luò)服務(wù)器的功能。

CONNECT

將請求連接轉(zhuǎn)換成透明的TCP/IP通道，通常通過非加密的HTTP代理利用SSL-加密通訊（HTTPS）。



安全方法

有些方法（比如HEAD, GET, OPTIONS, and TRACE) 被定義為安全方法，這些方法針對的只是信息的返回，并不會改變服務(wù)器的狀態(tài)（換句話說就是這些方法不會產(chǎn)生副作用）。不安全的方法（例如POST, PUT and DELETE) 應(yīng)該用特殊的方式向用戶展示，通常是按鈕而不是鏈接，這樣就可以使用戶意識到可能要負的責(zé)任（例如一個按鈕帶來的資金交易。）

冪等方法和網(wǎng)絡(luò)應(yīng)用軟件


協(xié)議版本號

超文本傳輸協(xié)議已經(jīng)演化出了很多版本，它們中的大部分都是向下兼容的。客戶端在請求的開始告訴服務(wù)器它采用的協(xié)議版本號，而后者則在響應(yīng)中采用相同或者更早的協(xié)議版本。

0.9
已過時。只接受 GET 一種請求方法，沒有在通訊中指定版本號，且不支持請求頭。由于該版本不支持 POST 方法，所以客戶端無法向服務(wù)器傳遞太多信息。

HTTP/1.0
這是第一個在通訊中指定版本號的 HTTP 協(xié)議版本，至今仍被廣泛采用，特別是在代理服務(wù)器中。

HTTP/1.1
當前版本。持久連接被默認采用，并能很好地配合代理服務(wù)器工作。還支持以管道方式在同時發(fā)送多個請求，以便降低線路負載，提高傳輸速度。
此版相較于 HTTP/1.0 協(xié)議的區(qū)別主要體現(xiàn)在：

緩存處理
帶寬及網(wǎng)絡(luò)連接的管理
安全性及完整性



狀態(tài)行


參見：HTTP狀態(tài)碼

所有 HTTP 響應(yīng)的第一行都是狀態(tài)行, 依次是當前 HTTP 版本號，3位數(shù)字組成的狀態(tài)代碼，以及描述狀態(tài)的短語，彼此由空格分隔。
狀態(tài)代碼的第一個數(shù)字代表當前響應(yīng)的類型：

1xx 消息——請求已被服務(wù)器接收，繼續(xù)處理
2xx 成功——請求已成功被服務(wù)器接收、理解、并接受
3xx 重定向——需要后續(xù)操作才能完成這一請求
4xx 請求錯誤——請求含有詞法錯誤或者無法被執(zhí)行
5xx 服務(wù)器錯誤——服務(wù)器在處理某個正確請求時發(fā)生錯誤

雖然 RFC 2616 中已經(jīng)推薦了描述狀態(tài)的短語，例如"200 OK"，"404 Not Found"，但是 WEB 開發(fā)者仍然能夠自行決定采用何種短語，用以顯示本地化的狀態(tài)描述或者自定義信息。


持久連接



安全超文本協(xié)議



例子

下面是一個HTTP客戶端與服務(wù)器之間會話的例子，運行于www.google.com，端口80
客戶端請求：

GET / HTTP/1.1
Host：www.google.com

（緊跟著一個換行，通過敲入回車實現(xiàn)）
服務(wù)器應(yīng)答：

HTTP/1.1 200 OK
Content-Length: 3059
Server: GWS/2.0
Date: Sat, 11 Jan 2003 02:44:04 GMT
Content-Type: text/html
Cache-control: private
Set-Cookie: PREF=ID=73d4aef52e57bae9:TM=1042253044:LM=1042253044:S=SMCc_HRPCQiqy
X9j; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Connection: keep-alive

（緊跟著一個空行，并且由HTML格式的文本組成了Google的主頁）
在HTTP1.0中，客戶端發(fā)送一個請求至服務(wù)器，服務(wù)器發(fā)送一個應(yīng)答至客戶端。之后，連接將被釋放。另一方面，HTTP1.1支持持久連接。這使得客戶端可以發(fā)送請求并且接收應(yīng)答，然后迅速的發(fā)送另一個請求和接收另一個應(yīng)答。因為多個額外的請求，TCP連接并沒有被釋放，而每個請求中關(guān)于TCP的負載相對較少。同時，在得到上一個請求的應(yīng)答之前發(fā)送多個請求（通常是兩個）也成為可能。這個技術(shù)被稱為“流水線”。

• 通信詞典解釋