深入淺出了解HTTP協(xié)議

本文地址：http://www.reibang.com/p/13373c6d78c6

image.png

1. 簡介

HTTP（HyperText Transfer Protocol）摔敛，意為超文本傳輸協(xié)議，是目前互聯(lián)網上應用最為廣泛的一種網絡協(xié)議。目前使用最普遍的一個版本是HTTP 1.1。

HTTP協(xié)議是用于從WWW服務器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔抑诸，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先于圖形)等爹殊。

HTTP是一個應用層協(xié)議蜕乡，由請求和響應構成，是一個標準的客戶端服務器模型梗夸。

一次HTTP請求的基本流程一般是层玲，在建立TCP連接后，由客戶端向服務端發(fā)起一次請求 request 绒瘦，而服務器在接收到以后返回給客戶端一個響應 response 称簿。所以我們看到的HTTP請求內容一般就分為請求和響應兩部分。

HTTP協(xié)議通常承載于TCP協(xié)議之上惰帽，有時也承載于TLS或SSL協(xié)議層之上憨降，這個時候，就成了我們常說的HTTPS该酗。默認HTTP的端口號為80授药。

1.1. 無狀態(tài)協(xié)議

HTTP協(xié)議是無狀態(tài)的，也就是說每一次HTTP請求之間都是相互獨立的呜魄，沒有聯(lián)系的悔叽，服務端不知道客戶端具體的狀態(tài)。

比如客戶端訪問一次網頁之后關閉瀏覽器爵嗅，然后再一次啟動瀏覽器娇澎，再訪問該網站睹晒，服務器是不知道客戶關閉了一次瀏覽器的趟庄。

這樣設計的原因是因為Web服務器一般需要面對很多瀏覽器的并發(fā)訪問，為了提高Web服務器對并發(fā)訪問的處理能力伪很，在設計HTTP協(xié)議時規(guī)定Web服務器發(fā)送HTTP應答報文和文檔時戚啥，不保存發(fā)出請求的Web瀏覽器進程的任何狀態(tài)信息。

2. HTTP請求

每一個HTTP請求都由三部分組成锉试，分別是：請求行猫十、請求報頭、請求正文。

2.1. 請求行

請求行一般由請求方法拖云、url路徑贷笛、協(xié)議版本組成，如下所示：

[圖片上傳失敗...(image-85a57d-1544428371370)]

2.2. 請求報頭

請求行下方的是則是請求報頭江兢，HTTP消息報頭包括普通報頭昨忆、請求報頭、響應報頭杉允、實體報頭。每個報頭的形式如下：

名字 + : + 空格 + 值

Host

指定的請求資源的域名（主機和端口號）席里。HTTP請求必須包含HOST叔磷，否則系統(tǒng)會以400狀態(tài)碼返回。
User-Agant

簡稱UA奖磁，內容包含發(fā)出請求的用戶信息改基，通常UA包含瀏覽者的信息，主要是瀏覽器的名稱版本和所用的操作系統(tǒng)咖为。這個UA頭不僅僅是使用瀏覽器才存在秕狰，只要使用了基于HTTP協(xié)議的客戶端軟件都會發(fā)送，無論是手機端還是PDA等躁染，這個UA頭是辨別客戶端所用設備的重要依據鸣哀。
Accept

告訴服務器可以接受的文件格式。通常這個值在各種瀏覽器中都差不多吞彤，不過WAP瀏覽器所能接受的格式要少一些我衬，這也是用來區(qū)分WAP和計算機瀏覽器的主要依據之一，隨著WAP瀏覽器的升級饰恕，其已經和計算機瀏覽器越來越接近挠羔，因此這個判斷所起的作用也越來越弱。
Cookie

Cookie信息埋嵌。
Cache-Control

指定請求和響應遵循的緩存機制破加。在請求消息或響應消息中設置Cache-Control并不會修改另一個消息消息處理過程中的緩存處理過程。請求時的緩存指令包括no-cache雹嗦、no-store范舀、man-age、max-stake俐银、min-fresh尿背、only-if-cached；響應消息中的指令包括 public捶惜、privete田藐、no-cache、no-store、no-transform汽久、must-revalidate鹤竭、proxy-revalidate、max-age景醇。
Referer

頁面跳轉處臀稚，表明產生請求的網頁來自于哪個URL，用戶是從該 Referer頁面訪問到當前請求的頁面三痰。這個屬性可以用來跟蹤Web請求來自哪個頁面吧寺，是從什么網站來的。
Content-Length

內容長度散劫。
Content-Range

響應的資源范圍稚机。可以在每次請求中標記請求的資源范圍获搏，在連接斷開重連時赖条，客戶端只請求該資源未下載的部分，而不是重新請求整個資源常熙，實現(xiàn)斷點續(xù)傳纬乍。迅雷就是基于這個原，使用多線程分段讀取網絡上的資源裸卫，最后再合并仿贬。
Accept-Encoding

指定所能接收的編碼方式，通常服務器會對頁面進行GZIP壓縮后再輸出以減少流量彼城，一般瀏覽器均支持對這種壓縮后的數(shù)據進行處理诅蝶，但對于我們來說，如果不想接收到這些看似亂碼的數(shù)據募壕，可以指定不接收任何服務器端壓縮處理调炬，要求其原樣返回。
Accept-Language

指瀏覽器可以接受的語言種類 en舱馅、en-us指英語 zh缰泡、zh-cn指中文。
Connection

客戶端與服務器鏈接類型代嗤，keep-alive:保持鏈接棘钞，close:關閉鏈接。

2.3. 請求正文

請求正文通常是使用POST方法進行發(fā)送的數(shù)據干毅，GET方法是沒有請求正文的宜猜。

請求正文跟上面的消息報頭一般由一個空行隔開。

3. HTTP響應

HTTP響應同樣也是由狀態(tài)行硝逢、響應報頭姨拥、報文主體三部分組成绅喉。

3.1. 狀態(tài)行

狀態(tài)行由HTTP協(xié)議版本號，狀態(tài)碼叫乌，狀態(tài)消息三部分組成柴罐。如下所示：

[圖片上傳失敗...(image-c24044-1544428371370)]

3.2. 響應報頭

Allow

服務器支持哪些請求方法（如GET、POST等）憨奸。
Date

表示消息發(fā)送的時間革屠，時間的描述格式由rfc822定義。例如排宰，Date:Mon,31Dec200104:25:57GMT似芝。Date描述的時間表示世界標準時，換算成本地時間板甘，需要知道用戶所在的時區(qū)国觉。
Set-Cookie

非常重要的header, 用于把cookie發(fā)送到客戶端瀏覽器，每一個寫入cookie都會生成一個Set-Cookie虾啦。
Expires

指明應該在什么時候認為文檔已經過期，從而不再緩存它痕寓，重新從服務器獲取傲醉，會更新緩存。過期之前使用本地緩存呻率。
Content-Type

WEB服務器告訴客戶端自己響應的對象的類型和字符集硬毕。
Content-Encoding

文檔的編碼（Encode）方法。只有在解碼之后才可以得到Content-Type頭指定的內容類型礼仗。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間吐咳。
Content-Length

指明實體正文的長度，以字節(jié)方式存儲的十進制數(shù)字來表示元践。
Location

用于重定向一個新的位置韭脊，包含新的URL地址。表示客戶應當?shù)侥睦锶ヌ崛∥臋n单旁。
Refresh

表示瀏覽器應該在多少時間之后刷新文檔沪羔，以秒計。

3.3. 響應正文

服務器返回的數(shù)據象浑。

4. URL

URL（Uniform Resource Locator）蔫饰，中文叫統(tǒng)一資源定位符。是用來標識某一處資源的地址愉豺。以下面這個URL為例篓吁，介紹下普通URL的各部分組成：

[圖片上傳失敗...(image-445825-1544428371370)]

協(xié)議部分：該URL的協(xié)議部分為“http：”，這代表網頁使用的是HTTP協(xié)議蚪拦。在"HTTP"后面的“//”為分隔符杖剪。
域名部分：該URL的域名部分為www.aspxfans.com冻押。一個URL中，也可以使用IP地址作為域名使用摘盆。
端口部分：跟在域名后面的是端口翼雀，域名和端口之間使用 : 作為分隔符。端口不是一個URL必須的部分孩擂，如果省略端口部分狼渊，將采用默認端口。
路徑部分：從域名后的第一個“/”開始到最后一個“类垦？”為止狈邑，是路徑部分，如果沒有“?”,則是從域名后的最后一個“/”開始到“#”為止蚤认，是路徑部分米苹，如果沒有“？”和“#”砰琢，那么從域名后的最后一個“/”開始到結束蘸嘶，都是路徑部分。

本例中的文件名是“index.asp”陪汽。文件名部分也不是一個URL必須的部分训唱，如果省略該部分，則使用默認的文件名挚冤。
參數(shù)部分：從“况增？”開始到“#”為止之間的部分為參數(shù)部分。本例中的參數(shù)部分為“boardID=5&ID=24618&page=1”训挡。參數(shù)可以允許有多個參數(shù)澳骤，參數(shù)與參數(shù)之間用“&”作為分隔符。
錨部分：從“#”開始到最后澜薄，都是錨部分为肮。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分表悬。

錨部分是用來定位到頁面中某個元素的弥锄。

5. HTTP請求方法

HTTP協(xié)議中定義的請求方法有以下幾種：

序號	方法	描述
1	GET	請求指定的頁面信息，并返回實體主體蟆沫。
2	HEAD	類似于get請求籽暇，只不過返回的響應中沒有具體的內容，用于獲取報頭
3	POST	向指定資源提交數(shù)據進行處理請求（例如提交表單或者上傳文件）饭庞。數(shù)據被包含在請求體中戒悠。POST請求可能會導致新的資源的建立和/或已有資源的修改。
4	PUT	從客戶端向服務器傳送的數(shù)據取代指定的文檔的內容舟山。
5	DELETE	請求服務器刪除指定的頁面绸狐。
6	CONNECT	HTTP/1.1協(xié)議中預留給能夠將連接改為管道方式的代理服務器卤恳。
7	OPTIONS	允許客戶端查看服務器的性能。
8	TRACE	回顯服務器收到的請求寒矿，主要用于測試或診斷突琳。

雖然HTTP請求中定義的方法有這么多種，但是我們平常使用的基本只有GET和POST兩種方法符相，而且大部分網站都是禁用掉了除GET和POST外其他的方法拆融。

因為其他幾種方法通過GET或者POST都能實現(xiàn)，而且對于網站來說更加的安全和可控啊终。

GET

其實簡單來說镜豹，GET方法一般用來負責獲取數(shù)據，或者將一些簡短的數(shù)據放到URL參數(shù)中傳遞到服務器蓝牲。比POST更加高效和方便趟脂。
POST

由于GET方法最多在url中攜帶1024字節(jié)數(shù)據，且將數(shù)據放到URL中傳遞太不安全例衍，數(shù)據量大時URL也會變得冗長昔期。所以傳遞數(shù)據量大或者安全性要求高的數(shù)據的時候，最好使用POST方法來傳遞數(shù)據佛玄。

6. 狀態(tài)碼

當客戶端向服務端發(fā)起一次請求后镇眷，服務端在返回的響應頭中會包含一個HTTP狀態(tài)碼，以表明這一次請求的狀態(tài)翎嫡。下面是一些常見的狀態(tài)碼：

200 - 請求成功
301 - 資源（網頁等）被永久轉移到其它URL
404 - 請求的資源（網頁等）不存在
500 - 內部服務器錯誤

HTTP的狀態(tài)碼是由三位數(shù)字來表示的，由第一位數(shù)字來表示狀態(tài)碼的類型永乌，一般來說有五種類型：

分類	分類描述
1**	信息惑申，服務器收到請求，需要請求者繼續(xù)執(zhí)行操作
2**	成功翅雏，操作被成功接收并處理
3**	重定向圈驼，需要進一步的操作以完成請求
4**	客戶端錯誤，請求包含語法錯誤或無法完成請求
5**	服務器錯誤望几，服務器在處理請求的過程中發(fā)生了錯誤

以下是詳細的狀態(tài)碼列表：

狀態(tài)碼	狀態(tài)碼英文名稱	中文描述
100	Continue	繼續(xù)绩脆。客戶端應繼續(xù)其請求
101	Switching Protocols	切換協(xié)議橄抹。服務器根據客戶端的請求切換協(xié)議靴迫。只能切換到更高級的協(xié)議，例如楼誓，切換到HTTP的新版本協(xié)議

200	OK	請求成功玉锌。一般用于GET與POST請求
201	Created	已創(chuàng)建。成功請求并創(chuàng)建了新的資源
202	Accepted	已接受疟羹。已經接受請求主守，但未處理完成
203	Non-Authoritative Information	非授權信息禀倔。請求成功。但返回的meta信息不在原始的服務器参淫，而是一個副本
204	No Content	無內容救湖。服務器成功處理，但未返回內容涎才。在未更新網頁的情況下鞋既，可確保瀏覽器繼續(xù)顯示當前文檔
205	Reset Content	重置內容。服務器處理成功憔维，用戶終端（例如：瀏覽器）應重置文檔視圖涛救。可通過此返回碼清除瀏覽器的表單域
206	Partial Content	部分內容业扒。服務器成功處理了部分GET請求

300	Multiple Choices	多種選擇检吆。請求的資源可包括多個位置，相應可返回一個資源特征與地址的列表用于用戶終端（例如：瀏覽器）選擇
301	Moved Permanently	永久移動程储。請求的資源已被永久的移動到新URI蹭沛，返回信息會包括新的URI，瀏覽器會自動定向到新URI章鲤。今后任何新的請求都應使用新的URI代替
302	Found	臨時移動摊灭。與301類似。但資源只是臨時被移動败徊≈愫簦客戶端應繼續(xù)使用原有URI
303	See Other	查看其它地址。與301類似皱蹦。使用GET和POST請求查看
304	Not Modified	未修改煤杀。所請求的資源未修改，服務器返回此狀態(tài)碼時沪哺，不會返回任何資源沈自。客戶端通常會緩存訪問過的資源辜妓，通過提供一個頭信息指出客戶端希望只返回在指定日期之后修改的資源
305	Use Proxy	使用代理枯途。所請求的資源必須通過代理訪問
306	Unused	已經被廢棄的HTTP狀態(tài)碼
307	Temporary Redirect	臨時重定向。與302類似籍滴。使用GET請求重定向

400	Bad Request	客戶端請求的語法錯誤酪夷，服務器無法理解
401	Unauthorized	請求要求用戶的身份認證
402	Payment Required	保留，將來使用
403	Forbidden	服務器理解請求客戶端的請求孽惰，但是拒絕執(zhí)行此請求
404	Not Found	服務器無法根據客戶端的請求找到資源（網頁）捶索。通過此代碼，網站設計人員可設置"您所請求的資源無法找到"的個性頁面
405	Method Not Allowed	客戶端請求中的方法被禁止
406	Not Acceptable	服務器無法根據客戶端請求的內容特性完成請求
407	Proxy Authentication Required	請求要求代理的身份認證灰瞻，與401類似腥例，但請求者應當使用代理進行授權
408	Request Time-out	服務器等待客戶端發(fā)送的請求時間過長辅甥，超時
409	Conflict	服務器完成客戶端的PUT請求是可能返回此代碼，服務器處理請求時發(fā)生了沖突
410	Gone	客戶端請求的資源已經不存在燎竖。410不同于404璃弄，如果資源以前有現(xiàn)在被永久刪除了可使用410代碼，網站設計人員可通過301代碼指定資源的新位置
411	Length Required	服務器無法處理客戶端發(fā)送的不帶Content-Length的請求信息
412	Precondition Failed	客戶端請求信息的先決條件錯誤
413	Request Entity Too Large	由于請求的實體過大构回，服務器無法處理夏块，因此拒絕請求。為防止客戶端的連續(xù)請求纤掸，服務器可能會關閉連接脐供。如果只是服務器暫時無法處理，則會包含一個Retry-After的響應信息
414	Request-URI Too Large	請求的URI過長（URI通常為網址）借跪，服務器無法處理
415	Unsupported Media Type	服務器無法處理請求附帶的媒體格式
416	Requested range not satisfiable	客戶端請求的范圍無效
417	Expectation Failed	服務器無法滿足Expect的請求頭信息

500	Internal Server Error	服務器內部錯誤政己，無法完成請求
501	Not Implemented	服務器不支持請求的功能，無法完成請求
502	Bad Gateway	充當網關或代理的服務器掏愁，從遠端服務器接收到了一個無效的請求
503	Service Unavailable	由于超載或系統(tǒng)維護歇由，服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中
504	Gateway Time-out	充當網關或代理的服務器果港，未及時從遠端服務器獲取請求
505	HTTP Version not supported	服務器不支持請求的HTTP協(xié)議的版本沦泌，無法完成處理

7. Cookie

Cookie有時也用其復數(shù)形式 Cookies，英文是餅干的意思辛掠。指某些網站為了辨別用戶身份谢谦、進行 session 跟蹤而儲存在用戶本地終端上的數(shù)據（通常經過加密）。最新的規(guī)范是 RFC6265 萝衩。

Cookie其實就是由服務器發(fā)給客戶端的特殊信息他宛，而這些信息以文本文件的方式存放在客戶端，然后客戶端每次向服務器發(fā)送請求的時候都會帶上這些特殊的信息欠气。服務器在接收到Cookie以后，會驗證Cookie的信息镜撩，以此來辨別用戶的身份预柒。

Cookie可以理解為一個臨時通行證。

7.1. 作用

Cookie其實是HTTP請求頭的擴展部分袁梗，由于HTTP協(xié)議是無狀態(tài)的協(xié)議宜鸯，所以為了在網頁上實現(xiàn)登陸之類的需求，所以擴展了Cookie這樣的功能遮怜。

每一次HTTP請求在數(shù)據交換完畢之后就會關閉連接淋袖，所以下一次HTTP請求就無法讓服務端得知你和上一次請求的關系。而使用了Cookie之后锯梁，你在第一次登陸之類的請求成功之后即碗，服務器會在Response的頭信息中給你返回Cookie信息焰情，你下一次訪問的時候帶上這個Cookie信息，則服務器就能識別你為上一次成功登陸的用戶剥懒。

7.2. 內容

Cookie一般保存的格式為json格式内舟，由一些屬性組成。

name：Cookie的名稱
value：Cookie的值
domain：可以使用此Cookie的域名
path：可以使用此Cookie的頁面路徑
expires/Max-Age：此Cookie的超時時間
secure：設置是否只能通過https來傳遞此條Cookie

7.3. domain屬性

域名一般來說分為頂級域名初橘，二級域名验游，三級域名等等。

例如baidu.com是一個頂級域名保檐，而www.baidu.com和map.baidu.com就是二級域名耕蝉，依次類推。

而在我們的Cookie來說夜只，都有一個domain屬性垒在，這個屬性限制了訪問哪些域名時可以使用這一條Cookie。因為每個網站基本上都會分發(fā)Cookie盐肃，所以domain屬性就可以讓我們在訪問新浪時不會帶上百度分發(fā)給我們的Cookie爪膊。

而在同一系的域名中，頂級域名是無法使用其二級域名的Cookie的砸王，也就是說訪問baidu.com的時候是不會帶上map.baidu.com分發(fā)的Cookie的推盛，二級域名之間的Cookie也不可以共享。但訪問二級域名時是可以使用頂級域名的Cookie的谦铃。

7.4. path屬性

path屬性為可以訪問此cookie的頁面路徑耘成。比如domain是abc.com，path是/test驹闰，那么只有/test路徑下的頁面可以讀取此cookie瘪菌。

7.5. expires/Max-Age屬性

字段為此cookie超時時間。若設置其值為一個時間嘹朗，那么當?shù)竭_此時間后师妙，此cookie失效。不設置的話默認值是Session屹培，意思是cookie會和session一起失效默穴。當瀏覽器關閉(不是瀏覽器標簽頁，而是整個瀏覽器) 后蓄诽，此cookie失效。

8. Session

Session媒吗，中文經常翻譯為會話仑氛，其本來的含義是指有始有終的一系列動作/消息，比如打電話時從拿起電話撥號到掛斷電話這中間的一系列過程可以稱之為一個session。這個詞在各個領域都有在使用锯岖。

而我們web領域介袜，一般使用的是其本義，一個瀏覽器窗口從打開到關閉這個期間嚎莉。

Session的目的則是米酬，在一個客戶從打開瀏覽器到關閉瀏覽器這個期間內，發(fā)起的所有請求都可以被識別為同一個用戶趋箩。而實現(xiàn)的方式則是赃额，在一個客戶打開瀏覽器開始訪問網站的時候，會生成一個SessionID叫确，這個ID每次的訪問都會帶上跳芳，而服務器會識別這個SessionID并且將與這個SessionID有關的數(shù)據保存在服務器上。由此來實現(xiàn)客戶端的狀態(tài)識別竹勉。

Session與Cookie相反飞盆，Session是存儲在服務器上的數(shù)據，只由客戶端傳上來的SessionId來進行判定次乓，所以相對于Cookie吓歇，Session的安全性更高。

一般SessionID會在瀏覽器被關閉時丟棄票腰，或者服務器會驗證Session的活躍程度城看，例如30分鐘某一個SessionID都沒有活躍，那么也會被識別為失效杏慰。