HTTP協議全覽

http(超文本傳輸協議)是一個基於請求與響應模式的、無狀態的、應用層的協議,常基於TCP的連接方式,成熟的版本是HTTP1.0和1.1,HTTP1.1版本中給出一種持續連接的機制,絕大多數的Web開發,都是構建在HTTP協議之上的Web應用。
HTTP協議以明文方式發送內容,不提供任何方式的數據加密,如果攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文,就可以直接讀懂其中的信息,因此HTTP協議不適合傳輸一些敏感信息,比如信用卡號、密碼等。
HTTPS(Hypertext Transfer Protocol over Secure Socket Layer),是以安全爲目標的HTTP通道,簡單講是HTTP的安全版。HTTPS在HTTP的基礎上加入了SSL協議,SSL依靠證書來驗證服務器的身份,併爲瀏覽器和服務器之間的通信加密。

1. HTTP URL

URL是一種特殊類型的URI,包含了用於查找某個資源的足夠的信息,格式如下:

http[s]://host[":"port][abs_path]

  • http表示要通過HTTP協議來定位網絡資源;https是使用
  • host表示合法的Internet主機域名或者IP地址;

如果URL中沒有給出abs_path,那麼當它作爲請求URI時,必須以“/”的形式給出,通常這個工作瀏覽器自動幫我們完成。
當輸入:www.baidu.com
瀏覽器自動轉換成:https://www.baidu.com/

2. HTTP請求

http請求由三部分組成,分別是:請求行、消息報頭、請求正文

Request Line<CRLF>
Header-Name: header-value<CRLF>
Header-Name: header-value<CRLF>
//一個或多個,均以<CRLF>結尾
<CRLF>
body//請求正文

1、請求行以一個方法符號開頭,以空格分開,後面跟着請求的URI和協議的版本,格式如下:

Method Request-URI HTTP-Version CRLF

其中 Method表示請求方法;Request-URI是一個統一資源標識符;HTTP-Version表示請求的HTTP協議版本;CRLF表示回車和換行(除了作爲結尾的CRLF外,不允許出現單獨的CR或LF字符)。

2、請求方法(所有方法全爲大寫)有多種,各個方法的解釋如下:

  • GET 請求獲取Request-URI所標識的資源
  • POST 在Request-URI所標識的資源後附加新的數據
  • HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭
  • PUT 請求服務器存儲一個資源,並用Request-URI作爲其標識
  • DELETE 請求服務器刪除Request-URI所標識的資源
  • TRACE 請求服務器回送收到的請求信息,主要用於測試或診斷
  • CONNECT 保留將來使用
  • OPTIONS 請求查詢服務器的性能,或者查詢與資源相關的選項和需求

應用舉例:
GET方法:在瀏覽器的地址欄中輸入網址的方式訪問網頁時,瀏覽器採用GET方法向服務器獲取資源,eg:
GET /form.html HTTP/1.1 (CRLF)

POST方法要求被請求服務器接受附在請求後面的數據,常用於提交表單。eg:

POST /reg.jsp HTTP/ (CRLF)
Accept:image/gif,image/x-xbit,... (CRLF)
...
HOST:www.guet.edu.cn (CRLF)
Content-Length:22 (CRLF)
Connection:Keep-Alive (CRLF)
Cache-Control:no-cache (CRLF)
(CRLF)         //該CRLF表示消息報頭已經結束,在此之前爲消息報頭
user=jeffrey&pwd=1234  //此行以下爲提交的數據

HEAD方法與GET方法幾乎是一樣的,對於HEAD請求的迴應部分來說,它的HTTP頭部中包含的信息與通過GET請求所得到的信息是相同的。利用這個方法,不必傳輸整個資源內容,就可以得到Request-URI所標識的資源的信息。該方法常用於測試超鏈接的有效性,是否可以訪問,以及最近是否更新。
3、請求報頭
見博客:http://blog.csdn.net/u010487568/article/details/17394089
常用的請求報頭
Accept
Accept請求報頭域用於指定客戶端接受哪些類型的信息。eg:Accept:image/gif,表明客戶端希望接受GIF圖象格式的資源;Accept:text/html,表明客戶端希望接受html文本。
Accept-Charset
Accept-Charset請求報頭域用於指定客戶端接受的字符集。eg:Accept-Charset:iso-8859-1,gb2312.如果在請求消息中沒有設置這個域,缺省是任何字符集都可以接受。
Accept-Encoding
Accept-Encoding請求報頭域類似於Accept,但是它是用於指定可接受的內容編碼。eg:Accept-Encoding:gzip.deflate.如果請求消息中沒有設置這個域服務器假定客戶端對各種內容編碼都可以接受。
Accept-Language
Accept-Language請求報頭域類似於Accept,但是它是用於指定一種自然語言。eg:Accept-Language:zh-cn.如果請求消息中沒有設置這個報頭域,服務器假定客戶端對各種語言都可以接受。
Authorization
Authorization請求報頭域主要用於證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時,如果收到服務器的響應代碼爲401(未授權),可以發送一個包含Authorization請求報頭域的請求,要求服務器對其進行驗證。
Host(發送請求時,該報頭域是必需的)
Host請求報頭域主要用於指定被請求資源的Internet主機和端口號,它通常從HTTP URL中提取出來的,eg:
我們在瀏覽器中輸入:http://www.guet.edu.cn/index.html
瀏覽器發送的請求消息中,就會包含Host請求報頭域,如下:
Host:www.guet.edu.cn
此處使用缺省端口號80,若指定了端口號,則變成:Host:www.guet.edu.cn:指定端口號
User-Agent:瀏覽器標識信息。

3、HTTP響應

在接收和解釋請求消息後,服務器返回一個HTTP響應消息。HTTP響應也是由三個部分組成,分別是:狀態行、消息報頭、響應正文:

Response Line<CRLF>
Header-Name: header-value<CRLF>
Header-Name: header-value<CRLF>
//一個或多個,均以<CRLF>結尾
<CRLF>
body//響應正文

1、狀態行格式如下:

HTTP-Version Status-Code Reason-Phrase CRLF

其中,HTTP-Version表示服務器HTTP協議的版本;Status-Code表示服務器發回的響應狀態代碼;Reason-Phrase表示狀態代碼的文本描述。
狀態代碼有三位數字組成,第一個數字定義了響應的類別,且有五種可能取值:
1xx:指示信息–表示請求已接收,繼續處理
2xx:成功–表示請求已被成功接收、理解、接受
3xx:重定向–要完成請求必須進行更進一步的操作
4xx:客戶端錯誤–請求有語法錯誤或請求無法實現
5xx:服務器端錯誤–服務器未能實現合法的請求
常見狀態代碼、狀態描述、說明:
200 OK //客戶端請求成功
400 Bad Request //客戶端請求有語法錯誤,不能被服務器所理解
401 Unauthorized //請求未經授權,這個狀態代碼必須和WWW-Authenticate報頭域一起使用
403 Forbidden //服務器收到請求,但是拒絕提供服務
404 Not Found //請求資源不存在,eg:輸入了錯誤的URL
500 Internal Server Error //服務器發生不可預期的錯誤
503 Server Unavailable //服務器當前不能處理客戶端的請求,一段時間後可能恢復正常
eg:HTTP/1.1 200 OK (CRLF)
詳見博客http://blog.csdn.net/u010487568/article/details/17149589
2、響應報頭
見博客:http://blog.csdn.net/u010487568/article/details/17394089
常用的響應報頭
Location:Location響應報頭域用於重定向接受者到一個新的位置。Location響應報頭域常用在更換域名的時候。
Server:Server響應報頭域包含了服務器用來處理請求的軟件信息。與User-Agent請求報頭域是相對應的。下面是
Server響應報頭域的一個例子:
Server:Apache-Coyote/1.1
WWW-Authenticate
WWW-Authenticate響應報頭域必須被包含在401(未授權的)響應消息中,客戶端收到401響應消息時候,併發送Authorization報頭域請求服務器對其進行驗證時,服務端響應報頭就包含該報頭域。
eg:WWW-Authenticate:Basic realm=”Basic Auth Test!” //可以看出服務器對請求資源採用的是基本驗證機制。

4、HTTP 普通頭和實體頭

HTTP協議中最重要的就是前面所述的請求和響應,以及相應的請求頭和響應頭。但除此之外還定義了普通頭和實體頭,以及支持其他推薦和用戶自定義的擴展頭。

1、普通頭

在普通報頭中,有少數報頭域用於所有的請求和響應消息,但並不用於被傳輸的實體,只用於傳輸的消息。

  • Cache-Control 用於指定緩存指令,緩存指令是單向的(響應中出現的緩存指令在請求中未必會出現),且是獨立的(一個消息的緩存指令不會影響另一個消息處理的緩存機制),HTTP1.0使用的類似的報頭域爲Pragma。請求時的緩存指令包括:no-cache(用於指示請求或響應消息不能緩存)、no-store、max-age、max-stale、min-fresh、only-if-cached;響應時的緩存指令包括:public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage. eg:爲了指示IE瀏覽器(客戶端)不要緩存頁面,服務器端的JSP程序可以編寫如下:response.sehHeader(“Cache-Control”,”no-cache”);//response.setHeader(“Pragma”,”no-cache”);作用相當於上述代碼,通常兩者//合用這句代碼將在發送的響應消息中設置普通報頭域:Cache-Control:no-cache
  • Date:普通報頭域表示消息產生的日期和時間
  • Connection:普通報頭域允許發送指定連接的選項。例如指定連接是連續”keep-alive”,或者指定“close”選項,通知服務器,在響應完成後,關閉連接。其中keep-alive再HTTP1.1才支持,也是默認的方式。

2、實體頭

請求和響應消息都可以傳送一個實體。一個實體由實體報頭域和實體正文組成,但並不是說實體報頭域和實體正文要在一起發送,可以只發送實體報頭域。實體報頭定義了關於實體正文(eg:有無實體正文)和請求所標識的資源的元信息。
常用的實體報頭

  • Content-Encoding:被用作媒體類型的修飾符,它的值指示了已經被應用到實體正文的附加內容的編碼,因而要獲得Content-Type報頭域中所引用的媒體類型,必須採用相應的解碼機制。Content-Encoding這樣用於記錄文檔的壓縮方法,eg:Content-Encoding:gzip
  • Content-Language:描述了資源所用的自然語言。沒有設置該域則認爲實體內容將提供給所有的語言閱讀者。eg:Content-Language:zh-cn
  • Content-Length:用於指明實體正文的長度,以字節方式存儲的十進制數字來表示。
  • Content-Type:用語指明發送給接收者的實體正文的媒體類型。eg:Content-Type:text/html;charset=ISO-8859-1;Content-Type:text/html;charset=GB2312
  • Last-Modified:用於指示資源的最後修改日期和時間。
  • Expires:給出響應過期的日期和時間。

3、擴展頭

HTTP協議中有些推薦的擴展頭,定義在其他RFC文檔,如Cookie、Set-Cookie、Referer、Content-Disposition等,這些頭分別用來解決一類重要的問題,從而單獨使用RFC文檔進行了描述,一般現代瀏覽器均實現了這些頭。除此之外,協議還支持用戶自定義擴展頭,頭的名稱和意義均由用戶自行根據應用場景進行設定,從而爲HTTP協議的應用範圍帶來了極大的靈活性。

5、HTTP緩存

服務端可以對用戶的響應進行緩存,瀏覽器也有瀏覽器緩存。這些都要基於HTTP協議的緩存協商策略來進行。

  • Expires策略:Expires是Web服務器響應消息頭字段,在響應http請求時告訴瀏覽器在過期時間前瀏覽器可以直接從瀏覽器緩存取數據,而無需再次請求。不過Expires 是HTTP 1.0的東西,Pragma也是HTTP1.0中的,現在默認瀏覽器均默認使用HTTP 1.1,所以它的作用基本忽略。Expires 的一個缺點就是,返回的到期時間是服務器端的時間,這樣存在一個問題,如果客戶端的時間與服務器的時間相差很大(比如時鐘不同步,或者跨時區),那麼誤差就很大,所以在HTTP 1.1版開始,使用Cache-Control: max-age=秒替代。
  • Cache-control策略(HTTP1.1提出):Cache-Control與Expires的作用一致,都是指明當前資源的有效期,控制瀏覽器是否直接從瀏覽器緩存取數據還是重新發請求到服務器取數據。只不過Cache-Control的選擇更多,設置更細緻,如果同時設置的話,其優先級高於Expires。Last-Modified/If-Modified-Since這兩個響應、請求頭配合Cache-Control使用,分別得到上一次更新的時刻,從而計算出距離當前時間間隔,並與Cache-Control中設置的過期時間來進行比對,判斷是否緩存過期。
  • Etag/If-None-Match:Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的唯一標識符,能夠更加準確的控制緩存。Last-Modified與ETag一起使用時,服務器會優先驗證ETag。Etag/If-None-Match也要配合Cache-Control使用。

詳細使用的參數如下:

Cache-Control值可以是public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age.各個消息中的指令含義如下:
Public指示響應可被任何緩存區緩存。
Private指示對於單個用戶的整個或部分響應消息,不能被共享緩存處理。這允許服務器僅僅描述當用戶的部分響應消息,此響應消息對於其他用戶的請求無效。
no-cache指示請求或響應消息不能緩存,該選項並不是說可以設置”不緩存“,容易望文生義~
no-store用於防止重要的信息被無意的發佈。在請求消息中發送將使得請求和響應消息都不使用緩存,完全不存下來。
max-age指示客戶機可以接收生存期不大於指定時間(以秒爲單位)的響應。
min-fresh指示客戶機可以接收響應時間小於當前時間加上指定時間的響應。
max-stale指示客戶機可以接收超出超時期間的響應消息。如果指定max-stale消息的值,那麼客戶機可以接收超出超時期指定值之內的響應消息。
Last-Modified:標示這個響應資源的最後修改時間。web服務器在響應請求時,告訴瀏覽器資源的最後修改時間。
Etag:web服務器響應請求時,告訴瀏覽器當前資源在服務器的唯一標識(生成規則由服務器決定)。Apache中,ETag的值,默認是對文件的索引節(INode),大小(Size)和最後修改時間(MTime)進行Hash後得到的。
If-None-Match:當資源過期時(使用Cache-Control標識的max-age),發現資源具有Etage聲明,則再次向web服務器請求時帶上頭If-None-Match (Etag的值)。web服務器收到請求後發現有頭If-None-Match 則與被請求資源的相應校驗串進行比對,決定返回200或304。

HTTP1.1中同時提出Last-Modify和Etag來配合Cache-Control進行緩存控制的原因是:Last-Modified標註的最後修改只能精確到秒級,如果某些文件在1秒鐘以內,被修改多次的話,它將不能準確標註文件的修改時間;如果某些文件會被定期生成,當有時內容並沒有任何變化,但Last-Modified卻改變了,導致文件沒法使用緩存
有可能存在服務器沒有準確獲取文件修改時間,或者與代理服務器時間不一致等情形。

緩存與用戶行爲的總結:

用戶操作 Expires/Cache-Control Last-Modified/Etag
地址欄回車 有效 有效
頁面鏈接跳轉 有效 有效
新開窗口 有效 有效
前進、後退 有效 有效
F5/按鈕刷新 無效(BR重置max-age=0) 有效
Ctrl+F5刷新 無效(重置CC=no-cache) 無效(請求頭丟棄該選項)

6、HTTP斷點續傳

HTTP1.1的GET方法支持請求某個資源一部分,響應status code用206(partial)來標識,使用Content-Range來標識請求的資源的部分內容。格式:
Content-Range:306320-604047/606060
表示這個資源一共有606060字節,當前請求的是第306320到604047字節的內容。客戶端可以通過多個線程同時請求較大的文件的多個部分,來實現對文件的併發下載,如FlashGet、迅雷等均是利用此原理。

HTTP協議構成了當今流行的web應用和基於HTTP協議實現的多重應用,因此還有很多方方面面需要關注。

發佈了158 篇原創文章 · 獲贊 42 · 訪問量 33萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章