| 網路協議 |
| 5. 應用層 |
|
DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTSP · TLS · SDP · SOAP · GTP · STUN · NTP · 更多 |
| 4. 傳輸層 |
| TCP · UDP · DCCP · SCTP · RTP · RSVP · IGMP · PPTP · 更多 |
| 3. 網路層 |
| IP (IPv4 · IPv6 · IPv9) · OSPF · IS-IS · BGP · IPsec · ARP · RARP · RIP · ICMP · ICMPv6 · 更多 |
| 2. 資料鏈結層 |
| 802.11 · 802.16 · Wi-Fi · WiMAX · ATM · DTM · 令牌環 · 乙太網 · FDDI · 幀中繼 · GPRS · EVDO · HSPA · HDLC · PPP · L2TP · ISDN · 更多 |
| 1. 實體層 |
| 乙太網實體層 · 數據機 · PLC · SONET/SDH · G.709 · 光導纖維 · 同軸電纜 · 雙絞線 · 更多 |
|
本模板: 檢視 • 討論 • 編輯 • 歷史
|
超文件傳輸協定(HTTP，HyperText Transfer Protocol)是網際網路上應用最為廣泛的一種網路協議。所有的WWW文件都必須遵守這個標準。設計HTTP最初的目的是為了提供一種發佈和接收HTML頁面的方法。
目錄 |
HTTP的發展是萬維網協會和Internet工作小組合作的結果，在一系列的RFC發佈了最終的版本，其中最著名的是RFC 2616。在RFC 2616中定義了HTTP 1.1這個今天普遍使用的版本。
HTTP是一個用於在客戶端和伺服器間請求和應答的協議。一個HTTP的客戶端，諸如一個web瀏覽器，通過建立一個到遠程主機特殊埠（默認埠為80）的連接，初始化一個請求。一個HTTP伺服器通過監聽特殊埠等待客戶端發送一個請求序列， 就像「GET / HTTP/1.1」（用來請求網頁伺服器的默認頁面），有選擇的接收像email一樣的MIME消息，此消息中包含了大量用來描述請求各個方面的信息頭序列，響應一個選擇的保留數據主體。接收到一個請求序列後（如果要的話，還有消息），伺服器會發回一個回覆，如「200 OK」，同時發回一個它本報的消息，此消息的主體可能是被請求的文件、錯誤消息或者其他的一些信息。
HTTP 並不局限於使用網路協議（TCP/IP）及其相關支持層，儘管這是它在互聯網上最為流行的應用程序。 事實上，HTTP可以“在任何其他互聯網協議之上執行，或者在其他網路上執行。HTTP 只認可可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。
HTTP不同於其他基於TCP的協議，諸如FTP。在HTTP中，一旦一個特殊的請求（或者請求的相關序列）完成，連接通常被中斷。這個設計使得對於當前頁面有規則連接到另一臺伺服器頁面的萬維網來說，HTTP是完美的。當持久連接的缺乏成為保持用戶狀態的必需選擇的方法時，對網頁設計者來說，會偶然產生一些問題。而大部分這些方法包括了對「cookies」的使用。
這裡有一個HTTP的安全版本稱為HTTPS，HTTPS支持任何的加密演算法，只要此加密演算法能被頁面雙方所理解。
HTTP（和HTTPS）由統一資源定位器或者簡稱URLs定位。創造這種地址定位的語法為了HTML的鏈接。
發出的請求信息包括以下幾個
請求行和標題必須以<CR><LF> 作為結尾（也就是，回車然後換行）。空行內必須只有<CR><LF>而無其他空格。在HTTP/1.1 協議中，所有的標題除主機外都是可選的。
HTTP 定義了八種方法來指示確認的資源執行所需的行為。
HEAD
要求與GET請求相應的回覆一樣的應答，但是沒有回應的內容。這對找回寫在回應標題中的
meta-infomation有幫助，不需要傳輸整個內容。
GET
請求某個特殊的資源，是目前網上最通用的方法。不應該用於一些會造成副作用的操作中 （在網路軟體中使用是一個常見的錯誤用法）。參看下個目錄的安全方法。
POST
向確定的資源提交需要處理的數據。這些數據包括在請求的內容里。這可以造成新資源的產生和更新已有資源。
PUT
上傳特定資源
DELETE
刪除特定資源
TRACE
返回接收的請求，客戶端可因此察看在請求過程中什麼中間伺服器被加進來或者有所改變。
OPTIONS
返回伺服器支持的HTTP方法，這可以用來檢查網路伺服器的功能。
CONNECT
將請求連接轉換成透明的TCP/IP通道，通常通過非加密的HTTP代理利用SSL-加密通訊（HTTPS）。
有些方法（比如HEAD, GET, OPTIONS, and TRACE) 被定義為安全方法，這些方法針對的只是信息的返回，並不會改變伺服器的狀態（換句話說就是這些方法不會產生副作用）。不安全的方法（例如POST, PUT and DELETE) 應該用特殊的方式向用戶展示，通常是按鈕而不是鏈接，這樣就可以使用戶意識到可能要負的責任（例如一個按鈕帶來的資金交易。）
超文本傳輸協議已經演化出了很多版本，它們中的大部分都是向下兼容的。客戶端在請求的開始告訴伺服器它採用的協議版本號，而後者則在響應中採用相同或者更早的協議版本。
已過時。只接受 GET 一種請求方法，沒有在通訊中指定版本號，且不支持請求頭。由於該版本不支持 POST 方法，所以客戶端無法向伺服器傳遞太多信息。
這是第一個在通訊中指定版本號的 HTTP 協議版本，至今仍被廣泛採用，特別是在代理伺服器中。
當前版本。持久連接被默認採用，並能很好地配合代理伺服器工作。還支持以管道方式在同時發送多個請求，以便降低線路負載，提高傳輸速度。
此版相較於 HTTP/1.0 協議的區別主要體現在：
所有 HTTP 響應的第一行都是狀態行, 依次是當前 HTTP 版本號，3位數字組成的狀態代碼，以及描述狀態的短語，彼此由空格分隔。
狀態代碼的第一個數字代表當前響應的類型：
雖然 RFC 2616 中已經推薦了描述狀態的短語，例如"200 OK"，"404 Not Found"，但是 WEB 開發者仍然能夠自行決定採用何種短語，用以顯示本地化的狀態描述或者自定義信息。
下麵是一個HTTP客戶端與伺服器之間會話的例子，運行於www.google.com，埠80
客戶端請求：
GET / HTTP/1.1 Host：www.google.com
（緊跟著一個換行，通過敲入回車實現）
伺服器應答：
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中，客戶端發送一個請求至伺服器，伺服器發送一個應答至客戶端。之後，連接將被釋放。另一方面，HTTP1.1支持持久連接。這使得客戶端可以發送請求並且接收應答，然後迅速的發送另一個請求和接收另一個應答。因為多個額外的請求，TCP連接並沒有被釋放，而每個請求中關於TCP的負載相對較少。同時，在得到上一個請求的應答之前發送多個請求（通常是兩個）也成為可能。這個技術被稱為「流水線」。
Why are we here?
All text is available under the terms of the GNU Free Documentation License
This page is cache of Wikipedia. History