超文本傳輸協議(HTTP)

  超文本傳輸協議(HyperText Transfer Protocol,Http)是從服務器傳輸數據到客戶端的傳輸協議。html

  HTTP協議的主要特色可歸納以下:
  1.支持客戶/服務器模式。
  2.簡單快速:客戶向服務器請求服務時,只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單,使得HTTP服務器的程序規模小,於是通訊速度很快。
  3.靈活:HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
  4.無鏈接:無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求,並收到客戶的應答後,即斷開鏈接。採用這種方式能夠節省傳輸時間。
  5.無狀態:HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息,則它必須重傳,這樣可能致使每次鏈接傳送的數據量增大。另外一方面,在服務器不須要先前信息時它的應答就較快。git

  客戶端和服務器端交互過程:github

  一、客戶發起鏈接;數據庫

  二、客戶發送請求;瀏覽器

  三、服務器響應請求;服務器

  四、服務器關閉鏈接。session

  請求消息結構併發

  一個請求消息是由請求行、請求頭字段、一個空行和消息主體構成。如:測試

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: example.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate

  請求行ui

  請求消息的第一行就是請求行。它指明使用的請求方法、資源標識符和HTTP版本,如:  

GET /hello.htm HTTP/1.1

  請求方法

  請求方法用來定義操做資源的方式,HTTP/1.1協議中定義了八種請求方法:

  • GET:讀取資源數據
  • POST:新建資源數據
  • PUT:更新資源數據
  • DELETE:刪除資源數據
  • HEAD:讀取資源的元數據
  • OPTIONS:讀取該資源所支持的全部請求方法
  • TRACE:回顯服務器收到的請求,主要用於測試或診斷
  • CONNECT:HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。一般用於SSL加密服務器的連接(經由非加密的HTTP代理服務器)

此外,除上述方法,特定的HTTP服務器還能擴展自定義方法。

  資源標識符

  URI、URL和URN用來識別、定位和命名互聯網上的資源。

  URI:Uniform Resource Identifier,統一資源標識符

  URL:Uniform Resource Locator,統一資源定位符

  URN:Uniform Resource Name,統一資源名稱

  URL和URN都屬於URI。

  請求頭字段

  用來傳遞客戶端的更多信息,以及傳遞解析信息消息主體的必要信息,如:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: example.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate

  常見請求頭字段有:

  • Accpt客戶端接收哪些Mine類型。如Accept:text/html
  • Accept-Encoding:支持的編碼類型。如gzip,deflate, sdch
  • Accept-Language:可接受的語言。如en-us,en;q=0.8
  • User-Ahent:一個標識客戶端的字符串。如User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
  • Cookie:Cookie。如sessionid=...;theme=4
  • Referer:從哪一個頁面到該頁面

  空行

  指示頭字段區完成,消息主題開始(若是有消息主體的話)。

  消息主體

  消息主體時請求消息的承載數據。好比在提交POST表單,而且表單方法不是GET時,表單數據就是打包在消息主體內的。消息主題是可選的。

  響應消息結構

  響應消息由一個狀態行、響應頭字段、一個空行、消息主體構成。如:

HTTP/1.1 200 OK
Date:Mon,27 Jul 2009 12:22:12 GMT
Server:Apache/2.2.14(Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:34 GMT
Content-Length: 88
Content-Type:text/html
Connection:Closed

<html>
    <body>
         <h1>Hello, World</h1>
    </body>
</html>

  狀態行

由http版本、狀態碼、狀態描述文字構成。如:

HTTP/1.1 200 OK

  狀態碼

  HTTP狀態碼是以表示網頁服務器http響應狀態的3位數字代碼。

  全部的裝代碼的第一個數字表明瞭響應的五種狀態之一:

  • 1xx:表明請求已被接受,須要繼續處理。這類響應是臨時響應,只包含狀態行和某些可選的響應頭信息,並以空行結束。
  • 2xx:表明請求接收、理解而且接收。
  • 3xx:表明須要客戶端採起進一步的操做才能完成請求。一般,這些狀態碼用來重定向,後續的請求地址(重定向目標)在本次響應的Location域中指明。當且僅當後續的請求所使用的方法是GET或者HEAD時,用戶瀏覽器才能夠在沒有用戶介入的狀況下自動提交所需的後續請求。
  • 4xx:表明了客戶端看起來可能發生了錯誤,妨礙了服務器的處理。除非響應的是一個HEAD請求,不然服務器就應該返回一個解釋當前錯誤情況的實體,以及這是臨時的仍是永久性的情況。
  • 5xx:表明了服務器在處理請求的過程當中有錯誤或者異常狀態發生,也有多是服務器意識到以當前的軟硬件資源沒法完成對請求的處理。

  常見狀態碼有: 

  100 Continue  初始的請求已經接受,客戶應當繼續發送請求的其他部分
  101 Switching Protocols  服務器將聽從客戶的請求轉換到另一種協議
  200 OK  一切正常,對GET和POST請求的應答文檔跟在後面
  201 Created  服務器已經建立了文檔,Location頭給出了它的URL。
  202 Accepted  已經接受請求,但處理還沒有完成。
  203 Non-Authoritative Information  文檔已經正常地返回,但一些應答頭可能不正確,由於使用的是文檔的拷貝
  204 No Content  沒有新文檔,瀏覽器應該繼續顯示原來的文檔。若是用戶按期地刷新頁面,而Servlet能夠肯定用戶文檔足夠新,這個狀態代碼是頗有用的
  205 Reset Content  沒有新的內容,但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容
  206 Partial Content  客戶發送了一個帶有Range頭的GET請求,服務器完成了它
  300 Multiple Choices  客戶請求的文檔能夠在多個位置找到,這些位置已經在返回的文檔內列出。若是服務器要提出優先選擇,則應該在Location應答頭指明。
  301 Moved Permanently  客戶請求的文檔在其餘地方,新的URL在Location頭中給出,瀏覽器應該自動地訪問新的URL。
  302 Found  相似於301,但新的URL應該被視爲臨時性的替代,而不是永久性的。
  303 See Other  相似於301/302,不一樣之處在於,若是原來的請求是POST,Location頭指定的重定向目標文檔應該經過GET提取
  304 Not Modified  客戶端有緩衝的文檔併發出了一個條件性的請求(通常是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔)。服務器告訴客戶,原來緩衝的文檔還能夠繼續使用。
  305 Use Proxy  客戶請求的文檔應該經過Location頭所指明的代理服務器提取
  307 Temporary Redirect  和302(Found)相同。許多瀏覽器會錯誤地響應302應答進行重定向,即便原來的請求是 POST,即便它實際上只能在POST請求的應答是303時才能重定向。因爲這個緣由,HTTP 1.1新增了307,以便更加清除地區分幾個狀態代碼: 當出現303應答時,瀏覽器能夠跟隨重定向的GET和POST請求;若是是307應答,則瀏覽器只能跟隨對GET請求的重定向。
  400 Bad Request  請求出現語法錯誤。
  401 Unauthorized  客戶試圖未經受權訪問受密碼保護的頁面。應答中會包含一個WWW-Authenticate頭,瀏覽器據此顯示用戶名字/密碼對話框,而後在填寫合適的Authorization頭後再次發出請求。
  403 Forbidden  資源不可用。
  404 Not Found  沒法找到指定位置的資源
  405 Method Not Allowed  請求方法(GET、POST、HEAD、Delete、PUT、TRACE等)對指定的資源不適用。
  406 Not Acceptable  指定的資源已經找到,但它的MIME類型和客戶在Accpet頭中所指定的不兼容
  407 Proxy Authentication Required  相似於401,表示客戶必須先通過代理服務器的受權。
  408 Request Timeout  在服務器許可的等待時間內,客戶一直沒有發出任何請求。客戶能夠在之後重複同一請求。
  409 Conflict  一般和PUT請求有關。因爲請求和資源的當前狀態相沖突,所以請求不能成功。
  410 Gone  所請求的文檔已經再也不可用,並且服務器不知道應該重定向到哪個地址。它和404的不一樣在於,返回407表示文檔永久地離開了指定的位置,而404表示因爲未知的緣由文檔不可用。
  411 Length Required  服務器不能處理請求,除非客戶發送一個Content-Length頭。
  412 Precondition Failed  請求頭中指定的一些前提條件失敗
  413 Request Entity Too Large  目標文檔的大小超過服務器當前願意處理的大小。若是服務器認爲本身可以稍後再處理該請求,則應該提供一個Retry-After頭
  414 Request URI Too Long  URI太長
  416 Requested Range Not Satisfiable  服務器不能知足客戶在請求中指定的Range頭
  500 Internal Server Error  服務器遇到了意料不到的狀況,不能完成客戶的請求
  501 Not Implemented  服務器不支持實現請求所須要的功能。例如,客戶發出了一個服務器不支持的PUT請求
  502 Bad Gateway  服務器做爲網關或者代理時,爲了完成請求訪問下一個服務器,但該服務器返回了非法的應答
  503 Service Unavailable  服務器因爲維護或者負載太重未能應答。例如,Servlet可能在數據庫鏈接池已滿的狀況下返回503。服務器返回503時能夠提供一個Retry-After頭
  504 Gateway Timeout  由做爲代理或網關的服務器使用,表示不能及時地從遠程服務器得到應答
  505 HTTP Version Not Supported  服務器不支持請求中所指明的HTTP版本

 

  響應頭字段

  和請求消息相似,首部字段會包括服務器自己的一些信息指示、以及響應消息自己的元數據。如:

Date:Mon,27 Jul 2009 12:22:12 GMT
Server:Apache/2.2.14(Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:34 GMT
Content-Length: 88
Content-Type:text/html
Connection:Closed

  常見響應頭有:

  • Content-Encoding:數據的編碼類型。如:Content-Encoding:gzip
  • Server:服務器的名稱。如Server:thin 1.5.0 codename Knife
  • Location:通知客戶端新的資源位置。如:L哦擦條呢:http://www.github.com/login
  • Content-Type:響應數據的類型。如:Content-type:text/html;charset=UTF-8
  • Content-Encoding:響應數據的編碼格式。如:gzip。客戶端會根據該值對響應內容解碼。

  消息主體

  消息主體時響應消息的承載數據。

相關文章
相關標籤/搜索