HTTP協議

超文本傳輸協議（英語：HyperText Transfer Protocol，縮寫：HTTP）是一種用於分佈式、協做式和超媒體信息系統的應用層協議[1]。HTTP是萬維網的數據通訊的基礎。

HTTP 報文組成

HTTP 報文又能夠分爲請求報文和響應報文，它們的結構都都由三個部分組成。請求報文由請求行、報文首部和主體組成；而響應報文則由狀態行、報文首部和主體組成。

請求報文

請求報文的組成部分有請求行、報文首部和主體。


HTTP 協議請求報文示例代碼：

GET / HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

主體

代碼1

請求行

請求行是位於請求報文的最開頭部分，它也是由另外三個更小的部分組成的，分別是請求方法、請求 URL 和協議版本。


如上代碼 1 的第一行即是請求行的信息：

GET / HTTP/1.1

請求方法

請求行的最開頭部分是請求方法，HTTP/1.1協議中共定義了八種方法（也叫「動做」）來以不一樣方式操做指定的資源：

• GET

向指定的資源發出「顯示」請求。使用GET方法應該只用在讀取數據，而不該當被用於產生「反作用」的操做中

• HEAD

與GET方法同樣，都是向服務器發出指定資源的請求。只不過服務器將不傳回資源的本文部分。

• POST

向指定資源提交數據，請求服務器進行處理（例如提交表單或者上傳文件）

• PUT

向指定資源位置上傳其最新內容

• DELETE

請求服務器刪除Request-URI所標識的資源

• TRACE

回顯服務器收到的請求，主要用於測試或診斷

• OPTIONS

這個方法可以使服務器傳回該資源所支持的全部HTTP請求方法

• CONNECT

HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。一般用於SSL加密服務器的連接

方法名稱是區分大小寫的。當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當返回狀態碼405（Method Not Allowed），當服務器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501（Not Implemented）。

請求 URL

URL就是因特網資源的標準化名稱。URL指向每一條電子信息，告訴你它們位於何處，以及如何與之進行交互。


大多數URL方案的URL語法都創建在這個由9部分構成的通用格式上：

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

各個通用組件的含義以下：

• 方案(scheme)

訪問服務器資源的指定的具體的協議，如：HTTP、FTP、SMB 等

• 用戶(user)

某些方案訪問資源時須要的用戶名

• 密碼(password)

用戶名後面可能須要密碼，中間須要用 : 隔開

• 主機(host)

資源宿主服務器的主機名或者點分 IP 地址

• 端口(port)

資源宿主服務器正在監聽的端口號，不少協議都會有默認端口號，如： HTTP:80、HTTPS:44三、SSH:22 等

• 路徑(path)

服務器資源的本地名稱

• 參數(params)

某些協議會使用這個組件來指定輸入的參數 

• 查詢(query)

某些協議會使用這個組件來指定輸入的參數 ，如 HTTP

• 片斷(frag)

一小片或一小部分的資源名字，在客戶端內部使用，不會傳給服務器

協議版本

超文本傳輸協議已經演化出了不少版本，它們中的大部分都是向下兼容的。客戶端在請求的開始告訴服務器它採用的協議版本號，然後者則在響應中採用相同或者更早的協議版本。


可用的協議版本有一下這些

• HTTP/1.0

這是第一個在通信中指定版本號的HTTP協議版本，至今仍被普遍採用，特別是在代理服務器中

• HTTP/1.1

持久鏈接被默認採用，並能很好地配合代理服務器工做。還支持以管道方式在同時發送多個請求，以便下降線路負載，提升傳輸速度。

• HTTP/2

HTTP/2 更高效、強大.它在傳輸層解決了之前咱們HTTP1.x中一直存在的問題。可是目前爲止尚未普遍地被使用

報文首部

報文首部就是請求行後面和空白行前面的部份內容，它們定義了一個超文本傳輸協議事務中的操做參數。HTTP頭部字段能夠本身根據須要定義，所以可能在 Web 服務器和瀏覽器上發現非標準的頭字段。


如上代碼 1 的第二到第五行即是報文首部的信息：

GET...
Host: www.baidu.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

從示例代碼可用看出，報文首部的字段是以明文的字符串格式傳輸，是以冒號分隔的鍵名與鍵值對，以回車(CR)加換行(LF)符號序列結尾。


HTTP 頭字段根據實際用途被分爲如下 4 種類型：

• 通用頭字段(英語：General Header Fields)
• 請求頭字段(英語：Request Header Fields)
• 響應頭字段(英語：Response Header Fields)
• 實體頭字段(英語：Entity Header Fields)

一些經常使用的請求報文首部定義以下：

協議頭字段名	說明	示例
Accept	可以接受的迴應內容類型（Content-Types）	Accept: text/plain
Accept-Charset	可以接受的字符集	Accept-Charset: utf-8
Accept-Encoding	可以接受的編碼方式列表。	Accept-Encoding: gzip, deflate
Accept-Language	可以接受的迴應內容的天然語言列表。	Accept-Language: en-US
Accept-Datetime	可以接受的按照時間來表示的版本	Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT
Authorization	用於超文本傳輸協議的認證的認證信息	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control	用來指定在此次的請求/響應鏈中的全部緩存機制 都必須 遵照的指令	Cache-Control: no-cache
Connection	該瀏覽器想要優先使用的鏈接類型	Connection: keep-alive Connection: Upgrade
Cookie	以前由服務器經過 Set- Cookie （下文詳述）發送的一個 超文本傳輸協議Cookie	Cookie: $Version=1; Skin=new;
Content-Length	以 八位字節數組 （8位的字節）表示的請求體的長度	Content-Length: 348
Content-MD5	請求體的內容的二進制 MD5 散列值，以 Base64 編碼的結果	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Type	請求體的 多媒體類型 （用於POST和PUT請求中）	Content-Type: application/x-www-form-urlencoded
Date	發送該消息的日期和時間(按照 RFC 7231 中定義的"超文本傳輸協議日期"格式來發送)	Date: Tue, 15 Nov 1994 08:12:31 GMT
Expect	代表客戶端要求服務器作出特定的行爲	Expect: 100-continue
From	發起此請求的用戶的郵件地址	From: user@example.com
Host	服務器的域名(用於虛擬主機 )，以及服務器所監聽的傳輸控制協議端口號。若是所請求的端口是對應的服務的標準端口，則端口號可被省略。	Host: en.wikipedia.org:80 Host: en.wikipedia.org
If-Match	僅當客戶端提供的實體與服務器上對應的實體相匹配時，才進行對應的操做。主要做用時，用做像 PUT 這樣的方法中，僅當從用戶上次更新某個資源以來，該資源未被修改的狀況下，才更新該資源。	If-Match: "737060cd8c284d8af7ad3082f209582d"
If-Modified-Since	容許在對應的內容未被修改的狀況下返回304未修改（ 304 Not Modified ）	If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match	容許在對應的內容未被修改的狀況下返回304未修改（ 304 Not Modified ），參考 超文本傳輸協議 的實體標記	If-None-Match: "737060cd8c284d8af7ad3082f209582d"
If-Range	若是該實體未被修改過，則向我發送我所缺乏的那一個或多個部分；不然，發送整個新的實體	If-Range: "737060cd8c284d8af7ad3082f209582d"
If-Unmodified-Since	僅當該實體自某個特定時間已來未被修改的狀況下，才發送迴應。	If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Max-Forwards	限制該消息可被代理及網關轉發的次數。	Max-Forwards: 10
Origin	發起一個針對 跨來源資源共享 的請求（要求服務器在迴應中加入一個‘訪問控制-容許來源’（'Access-Control-Allow-Origin'）字段）。	Origin: http://www.example-social-network.com
Pragma	與具體的實現相關，這些字段可能在請求/迴應鏈中的任什麼時候候產生多種效果。	Pragma: no-cache
Proxy-Authorization	用來向代理進行認證的認證信息。	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range	僅請求某個實體的一部分。字節偏移以0開始。	Range: bytes=500-999
Referer	表示瀏覽器所訪問的前一個頁面，正是那個頁面上的某個連接將瀏覽器帶到了當前所請求的這個頁面。	Referer: http://en.wikipedia.org/wiki/Main_Page
TE	瀏覽器預期接受的傳輸編碼方式：可以使用迴應協議頭 Transfer-Encoding 字段中的值；另外還可用"trailers"（與"分塊 "傳輸方式相關）這個值來代表瀏覽器但願在最後一個尺寸爲0的塊以後還接收到一些額外的字段。	TE: trailers, deflat
User-Agent	瀏覽器的瀏覽器身份標識字符串	User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0
Upgrade	要求服務器升級到另外一個協議。	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Via	向服務器告知，這個請求是由哪些代理髮出的。	Via: 1.0 fred, 1.1 example.com (Apache/1.1)
Warning	一個通常性的警告，告知，在實體內容體中可能存在錯誤。	Warning: 199 Miscellaneous warning

一些經常使用的響應報文首部定義以下：

字段名	說明	例子
Server	服務器的名字	Server: Apache/2.4.1 (Unix)
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	對於特定資源有效的動做。針對HTTP/405這一錯誤代碼而使用	Allow: GET, HEAD
Cache-Control	向從服務器直到客戶端在內的全部緩存機制告知，它們是否能夠緩存這個對象。其單位爲秒	Cache-Control: max-age=3600
Connection	針對該鏈接所預期的選項	Connection: close
Content-Disposition	一個可讓客戶端下載文件並建議文件名的頭部。文件名須要用雙引號包裹。	Content-Disposition: attachment; filename="fname.ext"
Content-Encoding	在數據上使用的編碼類型。參考 超文本傳輸協議壓縮 。	Content-Encoding: gzip
Content-Language	內容所使用的語言	Content-Language: da
Content-Length	迴應消息體的長度，以 字節 （8位爲一字節）爲單位	Content-Length: 348
Content-Location	所返回的數據的一個候選位置	Content-Location: /index.htm
Content-MD5	迴應內容的二進制 MD5 散列，以 Base64 方式編碼	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range	這條部分消息是屬於某條完整消息的哪一個部分	Content-Range: bytes 21010-47021/47022
Content-Type	當前內容的MIME類型	Content-Type: text/html; charset=utf-8
Date	此條消息被髮送時的日期和時間(按照 RFC 7231 中定義的「超文本傳輸協議日期」格式來表示)	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: Tue, 15 Nov 1994 12:45:26 GMT
Link	用來表達與另外一個資源之間的類型關係，此處所說的類型關係是在 RFC 5988 中定義的	Link: </feed>; rel="alternate"
Location	用來 進行重定向，或者在建立了某個新資源時使用。	Location: http://www.w3.org/pub/WWW/People.html
P3P	用於支持設置P3P策略，標準格式爲「P3P:CP="your_compact_policy"」。然而P3P規範並不成功，大部分現代瀏覽器沒有完整實現該功能，而大量網站也將該值設爲假值，從而足以用來欺騙瀏覽器的P3P插件功能並受權給第三方Cookies。	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="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
Refresh	用於設定可定時的重定向跳轉。右邊例子設定了5秒後跳轉至「http://www.w3.org/pub/WWW/People.html」。	Refresh: 5; url=http://www.w3.org/pub/WWW/People.html
Retry-After	若是某個實體臨時不可用，則，此協議頭用來告知客戶端往後重試。其值能夠是一個特定的時間段(以秒爲單位)或一個超文本傳輸協議日期。	Retry-After: 120 Retry-After: Fri, 07 Nov 2014 23:59:59 GMT
Set-Cookie	HTTP cookie	Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Status	通用網關接口 協議頭字段，用來講明當前這個超文本傳輸協議迴應的 狀態 。普通的超文本傳輸協議迴應，會使用單獨的「狀態行」（"Status-Line"）做爲替代，這一點是在 RFC 7230 中定義的。	Status: 200 OK
Strict-Transport-Security	HTTP 嚴格傳輸安全這一頭部告知客戶端緩存這一強制 HTTPS 策略的時間，以及這一策略是否適用於其子域名。	Strict-Transport-Security: max-age=16070400; includeSubDomains
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 example.com (Apache/1.1)
Warning	通常性的警告，告知在實體內容體中可能存在錯誤。	Warning: 199 Miscellaneous warning
WWW-Authenticate	代表在請求獲取這個實體時應當使用的認證模式。	WWW-Authenticate: Basic

主體

HTTP報文的第三部分是可選的實體主體部分。實體的主體是HTTP報文的負荷。

響應報文

響應報文是由服務器發送的，用來做爲請求報文的迴應。


響應報文和請求報文的格式差很少，也是由三部分組成，它們分別是狀態行、報文首部和主體


HTTP 協議請求報文示例代碼：

HTTP/1.1 200 OK
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html
Date: Mon, 06 Apr 2020 04:13:51 GMT
Server: BWS/1.1
Set-Cookie: delPer=0; path=/; domain=.baidu.com
Set-Cookie: BD_CK_SAM=1;path=/

主體

代碼 2

狀態行

狀態行在響應報文的第一行，它包含三部份內容，協議版本、狀態碼和緣由短語。


協議部分在前面已經說過了，這裏說一下狀態碼和短語。

狀態碼

• 1xx消息

請求已被服務器接收，繼續處理

• 2xx成功

請求已成功被服務器接收、理解、並接受

200 OK 請求沒問題

• 3xx重定向

須要後續操做才能完成這一請求

301 Move Permantly 永久重定向資源
302 Found 臨時重定向資源

• 4xx請求錯誤

請求含有詞法錯誤或者沒法被執行

400 Bad Request 錯誤的請求
403 Forbidden 請求被服務器拒絕
404 Not Found 服務器找不到資源

• 5xx服務器錯誤

服務器在處理某個正確請求時發生錯誤

502 Bad Gateway 網關錯誤
503 Service Un-available 服務不可用
504 GatewayTimeout 網關超時

報文首部

前面已經提過了。

主體

HTTP報文的第三部分是可選的實體主體部分。實體的主體是HTTP報文的負荷。就是HTTP要傳輸的內容。HTTP報文能夠承載不少類型的數字數據：圖片、視頻、HTML文檔、軟件應用程序、信用卡事務、電子郵件等。