| 網路協議 |
| 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 · PPTP · 更多 |
| 3. 網路層 |
| IP (IPv4 · IPv6) · ARP · RARP · ICMP · ICMPv6 · IGMP · RIP · OSPF · BGP · IS-IS · IPsec · 更多 |
| 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的發展是全球資訊網協會（World Wide Web Consortium）和Internet工作小組（Internet Engineering Task Force）合作的結果，（他們）最終發布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定義了HTTP協議的我們今天普遍使用的一個版本——HTTP 1.1。
HTTP是一個客戶端和伺服器端請求和應答的標準（TCP）。客戶端是終端用戶，伺服器端是網站。通過使用Web瀏覽器、網路爬蟲或者其它的工具，客戶端發起一個到伺服器上指定埠（默認埠為80）的HTTP請求。（我們稱這個客戶端）叫用戶代理（user agent）。應答的伺服器上存儲著（一些）資源，比如HTML文件和圖像。（我們稱）這個應答伺服器為源伺服器（origin server）。在用戶代理和源伺服器中間可能存在多個中間層，比如代理，網關，或者隧道（tunnels）。儘管TCP/IP協議是網際網路上最流行的應用，HTTP協議並沒有規定必須使用它和（基於）它支持的層。 事實上，HTTP可以在任何其他網際網路協議上，或者在其他網路上實現。HTTP只假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。
通常，由HTTP客戶端發起一個請求，建立一個到伺服器指定埠（默認是80埠）的TCP連接。HTTP伺服器則在那個埠監聽客戶端發送過來的請求。一旦收到請求，伺服器（向客戶端）發回一個狀態行，比如"HTTP/1.1 200 OK"，和（響應的）消息，消息的消息體可能是請求的文件、錯誤消息、或者其它一些信息。
HTTP使用TCP而不是UDP的原因在於（打開一個）一個網頁必須傳送很多數據，而TCP協議提供傳輸控制，按順序組織數據，和錯誤糾正。具體細節請參考『TCP和UDP的不同』（http://www.tocatch.info/en/User_Datagram_Protocol#Difference_between_TCP_and_UDP ）。
通過HTTP或者HTTPS協議請求的資源由統一資源定位器（Uniform Resource Identifiers）（或者，更準確一些，URLs）來標識。
發出的請求信息包括以下幾個
請求行和標題必須以<CR><LF> 作為結尾（也就是，回車然後換行）。空行內必須只有<CR><LF>而無其他空格。在HTTP/1.1 協議中，所有的請求頭，除Host外，都是可選的。
HTTP協議中定義了八種方法（有時也叫「動作」）來表示對指定數據的操作。
HEAD
（Head方法）要求响应与相应的GET请求的响应一样，但是没有的响应体（response body）。这用来获得响应头（response header）中的
元数据信息（meta-infomation）有（很）帮助，（因为）它不需要传输所有的内容。
GET
（Get方法用来）请求指定的资源。它是目前网上最常用的方法。它不应该用于一些会造成副作用的操作中 （在网络应用中用它来提交动作是一种常见的错误用法）。（细节请）参考后面的“安全方法”（这一节）。
POST
（POST方法用来）向指定的资源提交需要处理的数据。这些数据写在请求的内容里。（POST请求）可以导致新资源的产生和已有资源的更新。
PUT
上传指定资源
DELETE
删除指定资源
TRACE
（Trace方法告诉服务器端）返回收到的请求。客户端可以（通过此方法）察看在请求过程中中间服务器添加或者改变哪些内容。
OPTIONS
返回服务器（在指定URL上）支持的HTTP方法。通过请求“*”而不是指定的资源，这个方法可以用来检查网络服务器的功能。
CONNECT
将请求的连接转换成透明的TCP/IP通道，通常用来简化通过非加密的HTTP代理的SSL-加密通讯（HTTPS）。
HTTP伺服器至少應該實現Get和Head方法，可能的話，也實現OPTIONS方法。
有些方法（比如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