一、HTTP協(xié)議

HTTP是超文本傳輸協(xié)議，是用于從萬(wàn)維網(wǎng)服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。下面就來(lái)介紹HTTP的組成與特性。
HTTP是?連接， ?狀態(tài)， ?作在應(yīng)?層的協(xié)議。

?連接： http協(xié)議本身是沒(méi)有維護(hù)連接信息的， http的數(shù)據(jù)會(huì)交給?絡(luò)協(xié)議棧傳輸層的TCP協(xié)議， ?TCP是?向連接的。
?狀態(tài)：HTTP 協(xié)議?身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)?保存。也就是說(shuō)在 HTTP 這個(gè)級(jí)別，協(xié)議對(duì)于發(fā)送過(guò)的請(qǐng)求或響應(yīng)都不做持久化處理。

HTTP是無(wú)連接的，不維護(hù)連接信息，那它是否是可靠傳輸？
HTTP是可靠傳輸?shù)?，雖然HTTP無(wú)連接，自身不會(huì)維護(hù)連接信息，但是，它的數(shù)據(jù)最終會(huì)交給傳輸層的TCP協(xié)議，而TCP協(xié)議是可靠傳輸?shù)?，因此HTTP協(xié)議是可靠傳輸?shù)摹?/p>

（1）協(xié)議版本

HTTP協(xié)議有四個(gè)版本，分別是0.9、1.0、1.1、2.0?，F(xiàn)在大部分用的都是1.1版本。
0.9版本：這時(shí)的http協(xié)議沒(méi)有標(biāo)準(zhǔn)格式，僅用于傳輸html（超文本標(biāo)記語(yǔ)言）數(shù)據(jù)，而且只有g(shù)et方法。并且連接方式為短連接
短連接：建立連接，發(fā)送一個(gè)請(qǐng)求，得到相應(yīng)后關(guān)閉連接。

1.0版本:1.0版本正式規(guī)定了HTTP協(xié)議格式，并且增加了多重請(qǐng)求方法，并且支持不同文件格式的數(shù)據(jù)流，同時(shí)部分應(yīng)用商已經(jīng)開(kāi)始使用長(zhǎng)連接（受限制的長(zhǎng)連接）。
1.0定義了三種請(qǐng)求方法： GET, POST 和 HEAD方法。
長(zhǎng)連接：一次連接可以發(fā)送多條請(qǐng)求

1.1版本：增加了更多的請(qǐng)求方法和頭部描述信息，并支持了長(zhǎng)連接和管線化傳輸，新增了五種請(qǐng)求方法：options, put, delete,trace 和 connection方法
管線化傳輸：可以連續(xù)發(fā)送多個(gè)請(qǐng)求，只需要按順序響應(yīng)就行，不需要響應(yīng)后才發(fā)下一個(gè)請(qǐng)求，但是還存在約束條件，響應(yīng)的順序必須與請(qǐng)求的順序保持一致，通過(guò)隊(duì)列實(shí)現(xiàn)，如果不一致則在隊(duì)首阻塞。

2.0版本：采用二進(jìn)制流傳輸，并且進(jìn)行多路復(fù)用，允許服務(wù)端主動(dòng)推送數(shù)據(jù)，多路復(fù)用：響應(yīng)順序可以與請(qǐng)求的順序不一致，因?yàn)轭^部中標(biāo)識(shí)了對(duì)應(yīng)的請(qǐng)求信息。提高了信道的利用率。

3.0版本：在3.0版本中HTTP采取了革命性的變化，其將網(wǎng)絡(luò)協(xié)議從TCP切換至QUIC (Quick UDP Internet Connections), 快速 UDP 互聯(lián)網(wǎng)連接。 ，QUIC是基于UDP協(xié)議的。
解決兩個(gè)問(wèn)題：

• 線頭阻塞問(wèn)題：基于TCP的HTTP2.0的多路復(fù)用機(jī)制，盡管從邏輯上來(lái)說(shuō)，不同的流之間相互獨(dú)立，不會(huì)相互影響，但在實(shí)際傳輸方面，數(shù)據(jù)還是要一幀一幀的發(fā)送和接收，一旦某一個(gè)流的數(shù)據(jù)有丟包，則同樣會(huì)阻塞在它之后傳輸?shù)牧鲾?shù)據(jù)傳輸。而基于UDP的QUIC協(xié)議則可以更為徹底地解決這樣的問(wèn)題，讓不同的流之間真正的實(shí)現(xiàn)相互獨(dú)立傳輸，互不干擾。
• 切換網(wǎng)絡(luò)時(shí)的連接保持：當(dāng)前移動(dòng)端的應(yīng)用環(huán)境，用戶(hù)的網(wǎng)絡(luò)可能會(huì)經(jīng)常切換，比如從辦公室或家里出門(mén)，WiFi斷開(kāi)，網(wǎng)絡(luò)切換為移動(dòng)網(wǎng)絡(luò)。基于TCP的協(xié)議，由于切換網(wǎng)絡(luò)之后，IP會(huì)改變，因而之前的連接不可能繼續(xù)保持。而基于UDP的QUIC協(xié)議，則可以?xún)?nèi)建與TCP中不同的連接標(biāo)識(shí)方法，從而在網(wǎng)絡(luò)完成切換之后，恢復(fù)之前與服務(wù)器的連接。

（2）URL

我們所謂的 “網(wǎng)址” 其實(shí)就是說(shuō)的URL。
URL由以下幾部分組成：
協(xié)議://用戶(hù)名:密碼@服務(wù)器ip地址:服務(wù)器端口/文件路徑?查詢(xún)字符串#片段標(biāo)識(shí)符。
如圖：

http：明文傳輸，默認(rèn)端口是80端口
https：加密傳輸(一般用ssl非對(duì)稱(chēng)加密方式,會(huì)對(duì)http雙方發(fā)送的數(shù)據(jù)進(jìn)行加密，公鑰：客戶(hù)端所持有，私鑰：服務(wù)端所持有)，默認(rèn)端口是443端口。
像 / ? : 等這樣的字符, 已經(jīng)被url當(dāng)做特殊意義理解了. 因此這些字符不能隨意出現(xiàn)。比如, 某個(gè)參數(shù)中需要帶有這些特殊字符, 就必須先對(duì)特殊字符進(jìn)行轉(zhuǎn)義。
轉(zhuǎn)義的規(guī)則如下：

• 將需要轉(zhuǎn)碼的字符轉(zhuǎn)為16進(jìn)制，然后從右到左，取4位(不足4位直接處理)，每2位做一位，前面加上%，編碼成%XY格式。

• urlEncode：將字符轉(zhuǎn)換成為16進(jìn)制。

• urlDecode：將16進(jìn)制數(shù)據(jù)轉(zhuǎn)換成字符。

• 使? http: 或 https: 等協(xié)議?案名獲取訪問(wèn)資源時(shí)要指定協(xié)議類(lèi)型。不 區(qū)分字???寫(xiě)，最后附?個(gè)冒號(hào)（:）。

• 登錄信息（認(rèn)證） 指定?戶(hù)名和密碼作為從服務(wù)器端獲取資源時(shí)必要的登錄信息（身份 認(rèn)證）。此項(xiàng)是可選項(xiàng)。

• 服務(wù)器地址 ，必須指定待訪問(wèn)的服務(wù)器地址。地址可以是類(lèi)似 hackr.jp 這種 DNS 可解析的名稱(chēng)，或是192.168.1.1 這類(lèi) IPv4 地址 名，還可以是 [0:0:0:0:0:0:0:1] 這樣??括號(hào)括起來(lái)的 IPv6 地址名。

• 服務(wù)器端?號(hào) 指定服務(wù)器連接的?絡(luò)端?號(hào)。此項(xiàng)也是可選項(xiàng)，若?戶(hù)省略則?動(dòng) 使?默認(rèn)端?號(hào)。

• 帶層次的?件路徑 指定服務(wù)器上的?件路徑來(lái)定位特指的資源。

• 查詢(xún)字符串針對(duì)已指定的?件路徑內(nèi)的資源，可以使?查詢(xún)字符串傳?任意參 數(shù)。此項(xiàng)可選。

• ?段標(biāo)識(shí)符 使??段標(biāo)識(shí)符通?？蓸?biāo)記出已獲取資源中的?資源（?檔內(nèi)的某個(gè) 位置）。該項(xiàng)也為可選項(xiàng)。

HTTP協(xié)議數(shù)據(jù)流:

（3）HTTP協(xié)議格式

HTTP 協(xié)議規(guī)定，請(qǐng)求從客戶(hù)端發(fā)出，最后服務(wù)器端響應(yīng)該請(qǐng)求并返回。換句話說(shuō)，肯定是先從客戶(hù)端開(kāi)始建?通信的，服務(wù)器端在沒(méi)有接收到請(qǐng)求之前不會(huì)發(fā)送響應(yīng)。

請(qǐng)求格式圖：

響應(yīng)格式圖：

（4）請(qǐng)求方法

說(shuō)到請(qǐng)求行，我們要說(shuō)一下它的方法：
1. GET：獲取資源，GET 方法用來(lái)請(qǐng)求訪問(wèn)已被 URI 識(shí)別的資源。指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容。也就是說(shuō)，如果請(qǐng)求的資源是文本，那就保持原樣返回；(GET既能從服務(wù)器中去獲取數(shù)據(jù)，也能向服務(wù)器中提交少量數(shù)據(jù)，提交的數(shù)據(jù)在URL中)。
2.POST：傳輸實(shí)體主體，雖然用 GET 方法也可以傳輸實(shí)體的主體，但一般不用 GET 方法進(jìn)行傳輸，而是用 POST 方法。雖說(shuō) POST 的功能與 GET 很相似，但 POST 的主要目的并不是獲取響應(yīng)的主體內(nèi)容。(給服務(wù)器提交某些數(shù)據(jù)，提交的數(shù)據(jù)在正文中)，假設(shè)我們要在某個(gè)網(wǎng)頁(yè)進(jìn)行登錄，使用POST請(qǐng)求就會(huì)將我們的賬號(hào)，密碼放在請(qǐng)求正文中進(jìn)行提交
3.PUT：傳輸?件，PUT ?法?來(lái)傳輸?件。就像 FTP 協(xié)議的?件上傳?樣，要求在請(qǐng)求報(bào)?的主體中包含?件內(nèi)容，然后保存到請(qǐng)求 URI 指定的位置。 但是，鑒于 HTTP/1.1 的 PUT ?法?身不帶驗(yàn)證機(jī)制，任何?都可以上傳?件 , 存在安全性問(wèn)題，因此?般的 Web ?站不使?該?法
4.HEAD：獲得報(bào)??部，HEAD方法和GET方法一樣，只是不返回報(bào)文主體部分，用來(lái)確認(rèn)資源的有效性。HEAD方法是不需要服務(wù)端返回響應(yīng)正文的，使用HEAD方法，服務(wù)器只會(huì)返回響應(yīng)首行、響應(yīng)報(bào)頭、空行。
5.DELETE：刪除?件，DELETE ?法?來(lái)刪除?件，是與 PUT 相反的?法。但是， HTTP/1.1 的 DELETE ?法本身和 PUT ?法?樣不帶驗(yàn)證機(jī)制，所以?般的 Web ?站也不使? DELETE ?法。
6.OPTIONS：詢(xún)問(wèn)?持的?法，OPTIONS方法用來(lái)查詢(xún)針對(duì)請(qǐng)求URL指定的資源支持的方法。即客戶(hù)端詢(xún)問(wèn)當(dāng)前服務(wù)器都支持哪些方法。

（5）請(qǐng)求頭部

我們?cè)偕钊肓私庖幌耯eader也就是請(qǐng)求頭部信息。
描述本次響應(yīng)的關(guān)鍵字段信息，由key:value形式的鍵值對(duì)組成，并且每個(gè)鍵值對(duì)以\r\n作為結(jié)尾。
下面是請(qǐng)求頭帶的部分信息：

Content-Type: 數(shù)據(jù)類(lèi)型;
Content-Length: 正文的長(zhǎng)度 ;
Transfer-Encoding:實(shí)體正文的傳輸方式;
Expires:緩存過(guò)期時(shí)間;
Referer: 當(dāng)前頁(yè)面是從哪個(gè)頁(yè)面跳轉(zhuǎn)過(guò)來(lái)的;
Location: xx重定向的新地址;
Connection：keep-alive保持長(zhǎng)鏈接
Host: 客戶(hù)端告知服務(wù)器,所請(qǐng)求的資源是在哪個(gè)主機(jī)的哪個(gè)端口上;
User-Agent: 聲明用戶(hù)的操作系統(tǒng)和瀏覽器版本信息;
Cookie: 客戶(hù)端上保存的數(shù)據(jù)，客戶(hù)端每次通信時(shí)從cookie文件中讀取數(shù)據(jù)，并通過(guò)cookie字段向服務(wù)端傳遞信息（用于維持客戶(hù)端狀態(tài)信息）

下面是響應(yīng)頭部的部分信息
Set-Cookie：服務(wù)端通過(guò)Set-cookie向客服務(wù)端傳遞的信息，會(huì)被保存在客戶(hù)端瀏覽器的cookie文件中;

（7）單獨(dú)拎出來(lái)理解Cookie和Session

Session:服務(wù)端為客戶(hù)端創(chuàng)建的會(huì)話，會(huì)話信息中描述了客戶(hù)端的身份認(rèn)證信息和狀態(tài)信息，保存在服務(wù)端，可以通過(guò)cookie將session id返回給客戶(hù)端，客戶(hù)端每次通信都會(huì)通過(guò)cookie傳輸帶有自己session的id。
cookie上面已介紹。
理解：
cookie是服務(wù)端返回給瀏覽器的，由瀏覽器進(jìn)行保存cookie，在訪問(wèn)服務(wù)器的其他界面的時(shí)候，由瀏覽器自動(dòng)在請(qǐng)求體當(dāng)中加上cookie。
作用：服務(wù)端通過(guò)cookie當(dāng)中的value值，可以得到服務(wù)器端生成的sessionid，通過(guò)會(huì)話id，可以在服務(wù)端查詢(xún)出來(lái)是哪一個(gè)用戶(hù)的session，也就是說(shuō)瀏覽器通過(guò)請(qǐng)求當(dāng)中的cookie信息交到服務(wù)端，服務(wù)端就可以通過(guò)cookie保存的會(huì)話信息，進(jìn)行會(huì)話校驗(yàn)。
Cookie的工作原理：
瀏覽器端第一次發(fā)送請(qǐng)求到服務(wù)器端，服務(wù)器端創(chuàng)建Cookie，該Cookie中包含用戶(hù)的信息，然后將該Cookie發(fā)送到瀏覽器端，瀏覽器端再次訪問(wèn)服務(wù)器端時(shí)會(huì)攜帶服務(wù)器端創(chuàng)建的Cookie，服務(wù)器端通過(guò)Cookie中攜帶的數(shù)據(jù)區(qū)分不同的用戶(hù)。
如圖：

Session的工作原理
瀏覽器端第一次發(fā)送請(qǐng)求到服務(wù)器端，服務(wù)器端創(chuàng)建一個(gè)Session，同時(shí)會(huì)創(chuàng)建一個(gè)特殊的Cookie（name為JSESSIONID的固定值，value為session對(duì)象的ID），然后將該Cookie發(fā)送至瀏覽器端。
瀏覽器端發(fā)送第N（N>1）次請(qǐng)求到服務(wù)器端,瀏覽器端訪問(wèn)服務(wù)器端時(shí)就會(huì)攜帶該name為JSESSIONID的Cookie對(duì)象，服務(wù)器端根據(jù)name為JSESSIONID的Cookie的，中的Value(sessionId),去查詢(xún)Session對(duì)象，從而區(qū)分不同用戶(hù)。
感性理解：
因?yàn)镠TTP是無(wú)狀態(tài)的，但在實(shí)際情況中，我們還是需要保持狀態(tài)的
那么如何讓HTTP來(lái)保持狀態(tài)呢，是借助Cookie和Session來(lái)維持。
舉例：
比如明天就是618,618是一個(gè)大型的購(gòu)物節(jié)，在一天的不同時(shí)間段，許多店鋪都會(huì)有不同的活動(dòng)打折，這天會(huì)有很多人進(jìn)入如淘寶等購(gòu)物網(wǎng)站進(jìn)行購(gòu)物，但是因?yàn)镠TTP是無(wú)狀態(tài)的，所以它并不會(huì)記錄我們的任何信息。
所以我們?cè)诿看卧L問(wèn)時(shí)都需要重新登陸來(lái)確認(rèn)用戶(hù)的身份，這是一種很麻煩的事情，所以大佬們?yōu)镠TTP加入了Cookie來(lái)幫助其維持狀態(tài)，在每次通信后，會(huì)將服務(wù)端的一些臨時(shí)驗(yàn)證信息保存在客戶(hù)端的cookie文件中。這樣下次通信時(shí)，就可以通過(guò)讀取cookie中保存的驗(yàn)證信息，將其傳遞給服務(wù)端，來(lái)維持客戶(hù)端的狀態(tài)，這樣就可以避免多次登錄。
但是需要注意：
但是Cookie的使用不夠安全，因?yàn)镃ookie保存在客戶(hù)端，如果將這些重要的信息保存在本地，則很容易就會(huì)被腳本、爬蟲(chóng)等截取，造成不必要的損失，所以Cookie需要搭配Session使用。
Session其實(shí)就是服務(wù)端為客戶(hù)端創(chuàng)建的會(huì)話，其中描述了客戶(hù)端的身份認(rèn)證信息和狀態(tài)信息，并且將其保存在服務(wù)端。服務(wù)端每次通信結(jié)束后都會(huì)將Session id（本次會(huì)話的ID）保存在客戶(hù)端的Cookie中，客戶(hù)端在下次通信時(shí)通過(guò)Cookie將保存的Session id傳遞給服務(wù)端，這樣服務(wù)端就可以通過(guò)對(duì)應(yīng)的Session id來(lái)查找到客戶(hù)端的身份認(rèn)證信息和狀態(tài)信息，來(lái)為客戶(hù)端維持狀態(tài)，這樣就可以避免重復(fù)登錄，而且因?yàn)镃ookie和Session分別保存在客戶(hù)端和服務(wù)端，保證了一定的安全性。
Cookie和Session的區(qū)別對(duì)比：
Cookie保存在客戶(hù)端上，是一些臨時(shí)存儲(chǔ)的數(shù)據(jù)，用于持續(xù)與服務(wù)端進(jìn)行信息傳遞的一種手段。
Session保存在服務(wù)端上，是一種會(huì)話的控制，會(huì)話信息中包含客戶(hù)端的身份狀態(tài)信息，通過(guò)Cookie傳遞Session id來(lái)查找到對(duì)應(yīng)的身份狀態(tài)信息，來(lái)實(shí)現(xiàn)狀態(tài)維持。
session會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上，當(dāng)訪問(wèn)增多，會(huì)比較占用服務(wù)器的性能，如果主要考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用cookie。
將登陸信息等重要信息存放為SESSION;其他信息如果需要保留，可以放在cookie中。

（8） HTTP狀態(tài)碼 &狀態(tài)碼解釋

200(OK)：表示從客戶(hù)端發(fā)來(lái)的請(qǐng)求在服務(wù)器端被正常處理了。
204(No Content)：請(qǐng)求處理成功了，但沒(méi)有資源要返回(沒(méi)有正文)。
206(Partial Content)：客戶(hù)端進(jìn)行了范圍請(qǐng)求，服務(wù)器成功執(zhí)行這一請(qǐng)求。
3xx.重定向：表明瀏覽器需要進(jìn)行附加操作以完成請(qǐng)求
301：永久性重定向，高訴服務(wù)器某一資源已被永久放在另一個(gè)URL中，以后訪問(wèn)需訪問(wèn)新的URL。
302：臨時(shí)性重定向，客戶(hù)端要請(qǐng)求的資源臨時(shí)被放到新的服務(wù)器中，以后訪問(wèn)此資源還是訪問(wèn)這個(gè)舊服務(wù)器
告訴服務(wù)器某一資源已被永久放在另一個(gè)URL中，以后訪問(wèn)需訪問(wèn)新的URL
如下圖：

303(See Other)，要訪問(wèn)的資源已經(jīng)更新:
4XX :表明客戶(hù)端發(fā)生錯(cuò)誤。
400(Bad Request)：服務(wù)端無(wú)法理解客戶(hù)端發(fā)送的請(qǐng)求，請(qǐng)求格式錯(cuò)誤
401(Unauthorized)：認(rèn)證失敗
403(Forbidden)：客戶(hù)端請(qǐng)求訪問(wèn)某一資源被服務(wù)器拒絕了，即沒(méi)有資格(權(quán)限)訪問(wèn)某一資源
404(Not Found):服務(wù)器無(wú)法找到客戶(hù)端請(qǐng)求的資源
5XX 服務(wù)器錯(cuò)誤:表明服務(wù)器處理請(qǐng)求出錯(cuò)
500(Internal Server Error):該狀態(tài)碼表明服務(wù)器端在執(zhí)行請(qǐng)求時(shí)發(fā)生錯(cuò)誤，也有可能是Web應(yīng)用存在的bug或某些臨時(shí)的故障
503(Service Unavailable):服務(wù)器繁忙文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-631414.html

到了這里，關(guān)于Linux 計(jì)算機(jī)網(wǎng)絡(luò) 深入理解HTTP協(xié)議的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！