本文地址：http://www.itdecent.cn/p/13373c6d78c6

image.png

1. 簡介

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

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

HTTP是一個應(yīng)用層協(xié)議，由請求和響應(yīng)構(gòu)成，是一個標(biāo)準(zhǔn)的客戶端服務(wù)器模型。

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

HTTP協(xié)議通常承載于TCP協(xié)議之上，有時也承載于TLS或SSL協(xié)議層之上，這個時候，就成了我們常說的HTTPS。默認(rèn)HTTP的端口號為80。

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

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

比如客戶端訪問一次網(wǎng)頁之后關(guān)閉瀏覽器，然后再一次啟動瀏覽器，再訪問該網(wǎng)站，服務(wù)器是不知道客戶關(guān)閉了一次瀏覽器的。

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

2. HTTP請求

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

2.1. 請求行

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

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

2.2. 請求報頭

請求行下方的是則是請求報頭，HTTP消息報頭包括普通報頭、請求報頭、響應(yīng)報頭、實體報頭。每個報頭的形式如下：

名字 + : + 空格 + 值

• Host

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

• User-Agant

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

• Accept

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

• Cookie

  Cookie信息。

• Cache-Control

  指定請求和響應(yīng)遵循的緩存機(jī)制。在請求消息或響應(yīng)消息中設(shè)置Cache-Control并不會修改另一個消息消息處理過程中的緩存處理過程。請求時的緩存指令包括no-cache、no-store、man-age、max-stake、min-fresh、only-if-cached；響應(yīng)消息中的指令包括 public、privete、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。

• Referer

  頁面跳轉(zhuǎn)處，表明產(chǎn)生請求的網(wǎng)頁來自于哪個URL，用戶是從該 Referer頁面訪問到當(dāng)前請求的頁面。這個屬性可以用來跟蹤Web請求來自哪個頁面，是從什么網(wǎng)站來的。

• Content-Length

  內(nèi)容長度。

• Content-Range

  響應(yīng)的資源范圍。可以在每次請求中標(biāo)記請求的資源范圍，在連接斷開重連時，客戶端只請求該資源未下載的部分，而不是重新請求整個資源，實現(xiàn)斷點(diǎn)續(xù)傳。迅雷就是基于這個原，使用多線程分段讀取網(wǎng)絡(luò)上的資源，最后再合并。

• Accept-Encoding

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

• Accept-Language

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

• Connection

  客戶端與服務(wù)器鏈接類型，keep-alive:保持鏈接，close:關(guān)閉鏈接。

2.3. 請求正文

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

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

3. HTTP響應(yīng)

HTTP響應(yīng)同樣也是由狀態(tài)行、響應(yīng)報頭、報文主體三部分組成。

3.1. 狀態(tài)行

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

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

3.2. 響應(yīng)報頭

• Allow

  服務(wù)器支持哪些請求方法（如GET、POST等）。

• Date

  表示消息發(fā)送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標(biāo)準(zhǔn)時，換算成本地時間，需要知道用戶所在的時區(qū)。

• Set-Cookie

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

• Expires

  指明應(yīng)該在什么時候認(rèn)為文檔已經(jīng)過期，從而不再緩存它，重新從服務(wù)器獲取，會更新緩存。過期之前使用本地緩存。

• Content-Type

  WEB服務(wù)器告訴客戶端自己響應(yīng)的對象的類型和字符集。

• Content-Encoding

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

• Content-Length

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

• Location

  用于重定向一個新的位置，包含新的URL地址。表示客戶應(yīng)當(dāng)?shù)侥睦锶ヌ崛∥臋n。

• Refresh

  表示瀏覽器應(yīng)該在多少時間之后刷新文檔，以秒計。

3.3. 響應(yīng)正文

服務(wù)器返回的數(shù)據(jù)。

4. URL

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

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

1. 協(xié)議部分：該URL的協(xié)議部分為“http：”，這代表網(wǎng)頁使用的是HTTP協(xié)議。在"HTTP"后面的“//”為分隔符。

2. 域名部分：該URL的域名部分為www.aspxfans.com。一個URL中，也可以使用IP地址作為域名使用。

3. 端口部分：跟在域名后面的是端口，域名和端口之間使用 : 作為分隔符。端口不是一個URL必須的部分，如果省略端口部分，將采用默認(rèn)端口。

4. 路徑部分：從域名后的第一個“/”開始到最后一個“？”為止，是路徑部分，如果沒有“?”,則是從域名后的最后一個“/”開始到“#”為止，是路徑部分，如果沒有“？”和“#”，那么從域名后的最后一個“/”開始到結(jié)束，都是路徑部分。

   本例中的文件名是“index.asp”。文件名部分也不是一個URL必須的部分，如果省略該部分，則使用默認(rèn)的文件名。

5. 參數(shù)部分：從“？”開始到“#”為止之間的部分為參數(shù)部分。本例中的參數(shù)部分為“boardID=5&ID=24618&page=1”。參數(shù)可以允許有多個參數(shù)，參數(shù)與參數(shù)之間用“&”作為分隔符。

6. 錨部分：從“#”開始到最后，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分。

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

5. HTTP請求方法

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

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

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

• GET

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

• POST

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

6. 狀態(tài)碼

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

• 200 - 請求成功

• 301 - 資源（網(wǎng)頁等）被永久轉(zhuǎn)移到其它URL

• 404 - 請求的資源（網(wǎng)頁等）不存在

• 500 - 內(nèi)部服務(wù)器錯誤

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

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

7. Cookie

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

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

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

7.1. 作用

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

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

7.2. 內(nèi)容

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

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

7.3. domain屬性

域名一般來說分為頂級域名，二級域名，三級域名等等。

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

而在我們的Cookie來說，都有一個domain屬性，這個屬性限制了訪問哪些域名時可以使用這一條Cookie。因為每個網(wǎng)站基本上都會分發(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è)置其值為一個時間，那么當(dāng)?shù)竭_(dá)此時間后，此cookie失效。不設(shè)置的話默認(rèn)值是Session，意思是cookie會和session一起失效。當(dāng)瀏覽器關(guān)閉(不是瀏覽器標(biāo)簽頁，而是整個瀏覽器) 后，此cookie失效。

8. Session

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

而我們web領(lǐng)域，一般使用的是其本義，一個瀏覽器窗口從打開到關(guān)閉這個期間。

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

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

一般SessionID會在瀏覽器被關(guān)閉時丟棄，或者服務(wù)器會驗證Session的活躍程度，例如30分鐘某一個SessionID都沒有活躍，那么也會被識別為失效。