理解http

理解http

HTTP協議(HyperText Transfer Protocol,超文本傳輸協議)是因特網上應用最爲廣泛的一種網絡傳輸協議,所有的WWW文件都必須遵守這個標準。

HTTP是一個基於TCP/IP通信協議來傳遞數據(HTML 文件, 圖片文件, 查詢結果等)。

設計目的是保證客戶機與服務器之間的通信。

工作方式是客戶機與服務器之間的請求-應答協議。

web 瀏覽器可能是客戶端,而計算機上的網絡應用程序也可能作爲服務器端。

HTTP之請求消息Request
客戶端發送一個HTTP請求到服務器的請求消息包括以下格式:
請求行(request line)、請求頭部(header)、空行和請求數據四個部分組成。
請求頭的一般組成:

  1. Accept:瀏覽器可接受的MIME類型。
  2. Accept-Charset:瀏覽器可接受的字符集。
  3. Accept-Encoding:瀏覽器能夠進行解碼的數據編碼方式,比如gzip。
  4. Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。Servlet能夠向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。碼的HTML頁面。許多情形下這可以減少5到10倍的下載時間。
  5. Accept-Language:瀏覽器所希望的語言種類,當服務器能夠提供一種以上的語言版本時要用到。
  6. Authorization:授權信息,通常出現在對服務器發送的WWW-Authenticate頭的應答中。
  7. Connection:表示是否需要持久連接。如果Servlet看到這裏的值爲“Keep-Alive”,或者看到請求使用的是HTTP 1.1(HTTP 1.1默認進行持久連接),它就可以利用持久連接的優點,當頁面包含多個元素時(例如Applet,圖片),顯著地減少下載所需要的時間。要實現這一點,Servlet需要在應答中發送一個Content-Length頭,最簡單的實現方法是:先把內容寫入ByteArrayOutputStream,然後在正式寫出內容之前計算它的大小。
  8. Content-Length:表示請求消息正文的長度。
  9. Cookie:這是最重要的請求頭信息之一
  10. From:請求發送者的email地址,由一些特殊的Web客戶程序使用,瀏覽器不會用到它。
  11. Host:初始URL中的主機和端口。
  12. If-Modified-Since:只有當所請求的內容在指定的日期之後又經過修改才返回它,否則返回304“Not Modified”應答。
  13. Pragma:指定“no-cache”值表示服務器必須返回一個刷新後的文檔,即使它是代理服務器而且已經有了頁面的本地拷貝。
  14. Referer:包含一個URL,用戶從該URL代表的頁面出發訪問當前請求的頁面。
  15. User-Agent:瀏覽器類型,如果Servlet返回的內容與瀏覽器類型有關則該值非常有用。
  16. UA-Pixels,UA-Color,UA-OS,UA-CPU:由某些版本的IE瀏覽器所發送的非標準的請求頭,表示屏幕大小、顏色深度、操作系統和CPU類型。
  17. 等等

Get請求例子,使用Charles抓取的request

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent    Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept    image/webp,image/*,*/*;q=0.8
Referer    http://www.imooc.com/
Accept-Encoding    gzip, deflate, sdch
Accept-Language    zh-CN,zh;q=0.8

第一部分:請求行,用來說明請求類型,要訪問的資源以及所使用的HTTP版本.
GET說明請求類型爲GET,[/562f25980001b1b106000338.jpg]爲要訪問的資源,該行的最後一部分說明使用的是HTTP1.1版本。
第二部分:請求頭部,緊接着請求行(即第一行)之後的部分,用來說明服務器要使用的附加信息
從第二行起爲請求頭部,
HOST將指出請求的目的地.
User-Agent,服務器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎.該信息由你的瀏覽器來定義,並且在每個請求中自動發送
等等
第三部分:空行,請求頭部後面的空行是必須的
即使第四部分的請求數據爲空,也必須有空行。
第四部分:請求數據也叫主體,可以添加任意的其他數據。
這個例子的請求數據爲空。

POST請求例子,使用Charles抓取的request:

POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive

name=Professional%20Ajax&publisher=Wiley

第一部分:請求行,第一行明瞭是post請求,以及http1.1版本。
第二部分:請求頭部,第二行至第六行。
第三部分:空行,第七行的空行。
第四部分:請求數據,第八行。

HTTP之響應消息Response
一般情況下,服務器接收並處理客戶端發過來的請求後會返回一個HTTP的響應消息。
HTTP響應也由四個部分組成,分別是:狀態行、消息報頭、空行和響應正文
在這裏插入圖片描述
http常用消息報頭

Access-Control-Allow-Origin 指定哪些網站可以跨域源資源共享 Access-Control-Allow-Origin: * 臨時
Accept-Patch 指定服務器所支持的文檔補丁格式 Accept-Patch: text/example;charset=utf-8 固定
Accept-Ranges 服務器所支持的內容範圍 Accept-Ranges: bytes 固定
Age 響應對象在代理緩存中存在的時間,以秒爲單位 Age: 12 固定
Allow 對於特定資源的有效動作; Allow: GET, HEAD 固定
Cache-Control 通知從服務器到客戶端內的所有緩存機制,表示它們是否可以緩存這個對象及緩存有效時間。其單位爲秒 Cache-Control: max-age=3600 固定
Connection 針對該連接所預期的選項 Connection: close 固定
Content-Disposition 對已知MIME類型資源的描述,瀏覽器可以根據這個響應頭決定是對返回資源的動作,如:將其下載或是打開。 Content-Disposition: attachment; filename=“fname.ext” 固定
Content-Encoding 響應資源所使用的編碼類型。 Content-Encoding: gzip 固定
Content-Language 響就內容所使用的語言 Content-Language: zh-cn 固定
Content-Length 響應消息體的長度,用8進制字節表示 Content-Length: 348 固定
Content-Location 所返回的數據的一個候選位置 Content-Location: /index.htm 固定
Content-MD5 響應內容的二進制 MD5 散列值,以 Base64 方式編碼 Content-MD5: IDK0iSsgSW50ZWd0DiJUi== 已淘汰
Content-Range 如果是響應部分消息,表示屬於完整消息的哪個部分 Content-Range: bytes 21010-47021/47022 固定
Content-Type 當前內容的MIME類型 Content-Type: text/html; charset=utf-8 固定
Date 此條消息被髮送時的日期和時間(以RFC 7231中定義的"HTTP日期"格式來表示) Date: Tue, 15 Nov 1994 08:12:31 GMT 固定
ETag 對於某個資源的某個特定版本的一個標識符,通常是一個 消息散列 ETag: “737060cd8c284d8af7ad3082f209582d” 固定
Expires 指定一個日期/時間,超過該時間則認爲此迴應已經過期 Expires: Thu, 01 Dec 1994 16:00:00 GMT 固定: 標準
Last-Modified 所請求的對象的最後修改日期(按照 RFC 7231 中定義的“超文本傳輸協議日期”格式來表示) Last-Modified: Dec, 26 Dec 2015 17:30:00 GMT 固定
Link 用來表示與另一個資源之間的類型關係,此類型關係是在RFC 5988中定義 Link: ; rel=“alternate” 固定
Location 用於在進行重定向,或在創建了某個新資源時使用。 Location: http://www.itbilu.com/nodejs 固定
P3P P3P策略相關設置 P3P: CP="This is not a P3P policy! 固定
Pragma 與具體的實現相關,這些響應頭可能在請求/迴應鏈中的不同時候產生不同的效果 Pragma: no-cache 固定
Proxy-Authenticate 要求在訪問代理時提供身份認證信息。 Proxy-Authenticate: Basic 固定
Public-Key-Pins 用於防止中間攻擊,聲明網站認證中傳輸層安全協議的證書散列值 Public-Key-Pins: max-age=2592000; pin-sha256="……"; 固定
Refresh 用於重定向,或者當一個新的資源被創建時。默認會在5秒後刷新重定向。 Refresh: 5; url=http://itbilu.com
Retry-After 如果某個實體臨時不可用,那麼此協議頭用於告知客戶端稍後重試。其值可以是一個特定的時間段(以秒爲單位)或一個超文本傳輸協議日期。 示例1:Retry-After: 120 示例2: Retry-After: Dec, 26 Dec 2015 17:30:00 GMT 固定
Server 服務器的名稱 Server: nginx/1.6.3 固定
Set-Cookie 設置HTTP cookie Set-Cookie: UserID=itbilu; Max-Age=3600; Version=1 固定: 標準
Status 通用網關接口的響應頭字段,用來說明當前HTTP連接的響應狀態。 Status: 200 OK
Trailer Trailer用戶說明傳輸中分塊編碼的編碼信息 Trailer: Max-Forwards 固定
Transfer-Encoding 用表示實體傳輸給用戶的編碼形式。包括:chunked、compress、 deflate、gzip、identity。 Transfer-Encoding: chunked 固定
Upgrade 要求客戶端升級到另一個高版本協議。 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 固定
Vary 告知下游的代理服務器,應當如何對以後的請求協議頭進行匹配,以決定是否可使用已緩存的響應內容而不是重新從原服務器請求新的內容。 Vary: * 固定
Via 告知代理服務器的客戶端,當前響應是通過什麼途徑發送的。 Via: 1.0 fred, 1.1 itbilu.com (nginx/1.6.3) 固定
Warning 一般性警告,告知在實體內容體中可能存在錯誤。 Warning: 199 Miscellaneous warning 固定
WWW-Authenticate 表示在請求獲取這個實體時應當使用的認證模式。 WWW-Authenticate: Basic 固定

例子

HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8

<html>
      <head></head>
      <body>
            <!--body goes here-->
      </body>
</html>

第一部分:狀態行,由HTTP協議版本號, 狀態碼, 狀態消息 三部分組成。
第一行爲狀態行,(HTTP/1.1)表明HTTP版本爲1.1版本,狀態碼爲200,狀態消息爲(ok)

第二部分:消息報頭,用來說明客戶端要使用的一些附加信息
第二行和第三行爲消息報頭,
Date:生成響應的日期和時間;
Content-Type:指定了MIME類型的HTML(text/html),編碼類型是UTF-8

第三部分:空行,消息報頭後面的空行是必須的
第四部分:響應正文,服務器返回給客戶端的文本信息。
空行後面的html部分爲響應正文。

兩種 HTTP 請求方法:GET 和 POST
在客戶機和服務器之間進行請求-響應時,兩種最常被用到的方法是:GET 和 POST。
GET - 從指定的資源請求數據。
POST - 向指定的資源提交要被處理的數據
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
其他 HTTP 請求方法
在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章