摘要：協(xié)議發(fā)展協(xié)議是萬(wàn)維網(wǎng)協(xié)會(huì)和工作小組合作的結(jié)果，他們最終發(fā)布了一系列的，定義了版本。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力。來(lái)說(shuō)說(shuō)無(wú)狀態(tài)是一個(gè)無(wú)狀態(tài)協(xié)議，這意味著每個(gè)請(qǐng)求都是獨(dú)立的。

引自Wikipediahttps://en.wikipedia.org/wiki...

超文本傳輸協(xié)議（HTTP）是一個(gè)用于傳輸分布式、協(xié)同、超媒體信息系統(tǒng)的應(yīng)用層協(xié)議。聽(tīng)起來(lái)挺拗口，換句表述：HTTP協(xié)議是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。

HTTP協(xié)議是萬(wàn)維網(wǎng)協(xié)會(huì)（World Wide Web Consortium）和Internet工作小組IETF（Internet Engineering Task Force）合作的結(jié)果，（他們）最終發(fā)布了一系列的RFC，RFC 1945定義了HTTP/1.0版本。其中最著名的就是RFC 2616。RFC 2616定義了今天普遍使用的一個(gè)版本——HTTP 1.1。

1991年發(fā)布的HTTP/0.9。該版本極其簡(jiǎn)單，只有一個(gè)命令GET，且服務(wù)器只能回應(yīng)HTML格式的字符串，服務(wù)器發(fā)送完畢，就關(guān)閉TCP連接。

1996年5月，HTTP/1.0 版本發(fā)布，新增如下

狀態(tài)碼（status code）、多字符集支持、多部分發(fā)送（multi-part type）、權(quán)限（authorization）、緩存（cache）、內(nèi)容編碼（content-encoding）、數(shù)據(jù)格式（Content-Type）

引入POST命令和HEAD命令。

HTTP請(qǐng)求和回應(yīng)的格式也變了。除了數(shù)據(jù)部分，每次通信都必須包括頭信息（HTTP header），用來(lái)描述一些元數(shù)據(jù)。

緩存
HTTP/1.0

   Expires是http1.0提出的一個(gè)表示資源過(guò)期時(shí)間的header，它描述的是一個(gè)絕對(duì)時(shí)間，由服務(wù)器返回，用GMT格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，
   Pragma:no-cache頭域，客戶(hù)端使用該頭域說(shuō)明請(qǐng)求資源不能從cache中獲取，而必須回源獲取。

HTTP/1.1

   Cache-Control描述的是一個(gè)相對(duì)時(shí)間，在進(jìn)行緩存命中的時(shí)候，都是利用客戶(hù)端時(shí)間進(jìn)行判斷，所以相比較Expires，Cache-Control的緩存管理更有效，安全一些。

   注意：這兩個(gè)header可以只啟用一個(gè)，也可以同時(shí)啟用，當(dāng)response header中，Expires和Cache-Control同時(shí)存在時(shí)，Cache-Control優(yōu)先級(jí)高于Expires：

帶寬優(yōu)化Content-Range
HTTP/1.0

   HTTP/1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶(hù)端只是需要某個(gè)對(duì)象的一部分，而服務(wù)器卻將整個(gè)對(duì)象送過(guò)來(lái)了。例如，客戶(hù)端只需要顯示一個(gè)文檔的部分內(nèi)容，又比如下載大文件時(shí)需要支持?jǐn)帱c(diǎn)續(xù)傳功能，而不是在發(fā)生斷連后不得不重新下載完整的包。

HTTP/1.1

   HTTP/1.1中在請(qǐng)求消息中引入了 range頭域，它允許只請(qǐng)求資源的某個(gè)部分。在響應(yīng)消息中Content-Range頭域聲明了返回的這部分對(duì)象的偏移值和長(zhǎng)度。如果服務(wù)器相應(yīng)地返回 了對(duì)象所請(qǐng)求范圍的內(nèi)容，則響應(yīng)碼為206（Partial Content），它可以防止Cache將響應(yīng)誤以為是完整的一個(gè)對(duì)象。

長(zhǎng)連接Connection: Keep-Alive
HTTP 1.0

   HTTP 1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求處理后立即斷開(kāi)TCP連接，服務(wù)器不跟蹤 每個(gè)客戶(hù)也不記錄過(guò)去的請(qǐng)求。此外，由于大多數(shù)網(wǎng)頁(yè)的流量都比較小，一次TCP連接很少能通過(guò)slow-start區(qū)，不利于提高帶寬利用率。

HTTP 1.1

   HTTP 1.1支持長(zhǎng)連接（PersistentConnection），在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng) 求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。

管道機(jī)制/流水線（Pipelining）處理

   HTTP 1.1還允許客戶(hù)端不用等待上一次請(qǐng)求結(jié)果返回，就可以發(fā)出下一次請(qǐng)求，但服務(wù)器端必須按照接收到客戶(hù)端請(qǐng)求的先后順序依次回送響應(yīng)結(jié)果，以保證客戶(hù)端能夠區(qū)分出每次請(qǐng)求的響應(yīng)內(nèi)容，這樣也顯著地減少了整個(gè)下載過(guò)程所需要的時(shí)間。

Content-Length 字段

   一個(gè)TCP連接現(xiàn)在可以傳送多個(gè)回應(yīng)，勢(shì)必就要有一種機(jī)制，區(qū)分?jǐn)?shù)據(jù)包是屬于哪一個(gè)回應(yīng)的。這就是Content-length字段的作用，聲明本次回應(yīng)的數(shù)據(jù)長(zhǎng)度。

Host頭域
HTTP1.0

       在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址，因此，請(qǐng)求消息中的URL并沒(méi)有傳遞主機(jī)名（hostname）。但隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī) （Multi-homed Web Servers），并且它們共享一個(gè)IP地址。

HTTP1.1

HTTP1.1的請(qǐng)求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請(qǐng)求消息中如果沒(méi)有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）。此外，服務(wù)器應(yīng)該接受以絕對(duì)路徑標(biāo)記的資源請(qǐng)求。 
在HTTP 1.1中增加Host請(qǐng)求頭字段后，WEB瀏覽器可以使用主機(jī)頭名來(lái)明確表示要訪問(wèn)服務(wù)器上的哪個(gè)WEB站點(diǎn)，這才實(shí)現(xiàn)了在一臺(tái)WEB服務(wù)器上可以在同一個(gè)IP地址和端口號(hào)上使用不同的主機(jī)名來(lái)創(chuàng)建多個(gè)虛擬WEB站點(diǎn)。

其他

   1.1版還新增了許多動(dòng)詞方法：PUT、PATCH、HEAD、 OPTIONS、DELETE

雖然1.1版允許復(fù)用TCP連接，但是同一個(gè)TCP連接里面，所有的數(shù)據(jù)通信是按次序進(jìn)行的。服務(wù)器只有處理完一個(gè)回應(yīng)，才會(huì)進(jìn)行下一個(gè)回應(yīng)。要是前面的回應(yīng)特別慢，后面就會(huì)有許多請(qǐng)求排隊(duì)等著。這稱(chēng)為"隊(duì)頭堵塞"（Head-of-line blocking）。
為了避免這個(gè)問(wèn)題，只有兩種方法：一是減少請(qǐng)求數(shù)，二是同時(shí)多開(kāi)持久連接。這導(dǎo)致了很多的網(wǎng)頁(yè)優(yōu)化技巧，比如合并腳本和樣式表、將圖片嵌入CSS代碼、域名分片（domain sharding）等等。如果HTTP協(xié)議設(shè)計(jì)得更好一些，這些額外的工作是可以避免的。

二進(jìn)制協(xié)議

   HTTP/1.1 版的頭信息肯定是文本（ASCII編碼），數(shù)據(jù)體可以是文本，也可以是二進(jìn)制。HTTP/2 則是一個(gè)徹底的二進(jìn)制協(xié)議，頭信息和數(shù)據(jù)體都是二進(jìn)制，并且統(tǒng)稱(chēng)為"幀"（frame）：頭信息幀和數(shù)據(jù)幀。二進(jìn)制協(xié)議的一個(gè)好處是，可以定義額外的幀。

多工

   HTTP/2 復(fù)用TCP連接，在一個(gè)連接里，客戶(hù)端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請(qǐng)求或回應(yīng)，而且不用按照順序一一對(duì)應(yīng)，這樣就避免了"隊(duì)頭堵塞"。
   舉例來(lái)說(shuō)，在一個(gè)TCP連接里面，服務(wù)器同時(shí)收到了A請(qǐng)求和B請(qǐng)求，于是先回應(yīng)A請(qǐng)求，結(jié)果發(fā)現(xiàn)處理過(guò)程非常耗時(shí)，于是就發(fā)送A請(qǐng)求已經(jīng)處理好的部分， 接著回應(yīng)B請(qǐng)求，完成后，再發(fā)送A請(qǐng)求剩下的部分。

數(shù)據(jù)流

   因?yàn)?HTTP/2 的數(shù)據(jù)包是不按順序發(fā)送的，同一個(gè)連接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)。因此，必須要對(duì)數(shù)據(jù)包做標(biāo)記，指出它屬于哪個(gè)回應(yīng)。

頭信息壓縮

   HTTP 協(xié)議不帶有狀態(tài)，每次請(qǐng)求都必須附上所有信息。所以，請(qǐng)求的很多字段都是重復(fù)的，比如Cookie和User Agent，一模一樣的內(nèi)容，每次請(qǐng)求都必須附帶，這會(huì)浪費(fèi)很多帶寬，也影響速度。
   HTTP/2 對(duì)這一點(diǎn)做了優(yōu)化，引入了頭信息壓縮機(jī)制（header compression）。一方面，頭信息使用gzip或compress壓縮后再發(fā)送；另一方面，客戶(hù)端和服務(wù)器同時(shí)維護(hù)一張頭信息表，所有字段都會(huì)存入這個(gè)表，生成一個(gè)索引號(hào)，以后就不發(fā)送同樣字段了，只發(fā)送索引號(hào)，這樣就提高速度了。

服務(wù)器推送

   HTTP/2 允許服務(wù)器未經(jīng)請(qǐng)求，主動(dòng)向客戶(hù)端發(fā)送資源，這叫做服務(wù)器推送（server push）。
   常見(jiàn)場(chǎng)景是客戶(hù)端請(qǐng)求一個(gè)網(wǎng)頁(yè)，這個(gè)網(wǎng)頁(yè)里面包含很多靜態(tài)資源。正常情況下，客戶(hù)端必須收到網(wǎng)頁(yè)后，解析HTML源碼，發(fā)現(xiàn)有靜態(tài)資源，再發(fā)出靜態(tài) 資源請(qǐng)求。其實(shí)，服務(wù)器可以預(yù)期到客戶(hù)端請(qǐng)求網(wǎng)頁(yè)后，很可能會(huì)再請(qǐng)求靜態(tài)資源，所以就主動(dòng)把這些靜態(tài)資源隨著網(wǎng)頁(yè)一起發(fā)給客戶(hù)端了。
   

1.支持客戶(hù)/服務(wù)器模式。
2.簡(jiǎn)單快速：客戶(hù)向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶(hù)與服務(wù)器聯(lián)系的類(lèi)型不同。由于HTTP協(xié)議簡(jiǎn)單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類(lèi)型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念?lèi)型由Content-Type加以標(biāo)記。
4.無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶(hù)的請(qǐng)求，并收到客戶(hù)的應(yīng)答后，即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間。早期這么做的原因是請(qǐng)求資源少，追求快。后來(lái)通過(guò)Connection: Keep-Alive實(shí)現(xiàn)長(zhǎng)連接
5.無(wú)狀態(tài)：HTTP協(xié)議是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

來(lái)說(shuō)說(shuō)無(wú)狀態(tài)
HTTP 是一個(gè)無(wú)狀態(tài)協(xié)議，這意味著每個(gè)請(qǐng)求都是獨(dú)立的。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力，服務(wù)器不知道客戶(hù)端是什么狀態(tài)。即我們給服務(wù)器發(fā)送 HTTP 請(qǐng)求之后，服務(wù)器根據(jù)請(qǐng)求，會(huì)給我們發(fā)送數(shù)據(jù)過(guò)來(lái)，但是，發(fā)送完，不會(huì)記錄任何信息。
但對(duì)于一下需要狀態(tài)的頁(yè)面，如用戶(hù)主頁(yè)需要用戶(hù)登錄信息、購(gòu)物下單時(shí)需要選中的商品等，服務(wù)器必須知道瀏覽器的當(dāng)前狀態(tài)。兩種用于保持HTTP連接狀態(tài)的技術(shù)就應(yīng)運(yùn)而生了，一個(gè)是Cookie，而另一個(gè)則是Session。

Cookie是通過(guò)客戶(hù)端保持狀態(tài)的解決方案，存放于HTTP響應(yīng)頭（Response Header），每次請(qǐng)求時(shí)，請(qǐng)求頭都會(huì)帶上Cookie，從而保持瀏覽器狀態(tài)。瀏覽器中“記住密碼”的功能就是根據(jù)Cookie做的。
Session是通過(guò)服務(wù)器來(lái)保持狀態(tài)的。服務(wù)器創(chuàng)建Session并為該Session生成唯一的Session id，而這個(gè)Session id在隨后的請(qǐng)求中會(huì)被用來(lái)重新獲得已經(jīng)創(chuàng)建的Session；在Session被創(chuàng)建之后，就可以調(diào)用Session相關(guān)的方法往Session中增加 內(nèi)容了，而這些內(nèi)容只會(huì)保存在服務(wù)器中，發(fā)到客戶(hù)端的只有Session id；當(dāng)客戶(hù)端再次發(fā)送請(qǐng)求的時(shí)候，會(huì)將這個(gè)Session id帶上，服務(wù)器接受到請(qǐng)求之后就會(huì)依據(jù)Session id找到相應(yīng)的Session，從而再次使用之。正式這樣一個(gè)過(guò)程，用戶(hù)的狀態(tài)也就得以保持了。

通信使用明文(不加密),內(nèi)容可能會(huì)被竊聽(tīng)

不驗(yàn)證通信方的身份,因此有可能遭遇偽裝

無(wú)法證明報(bào)文的完整性,所以有可能已遭篡改

HTTP 協(xié)議中沒(méi)有加密機(jī)制,但可以通 過(guò)和 SSL(Secure Socket Layer,安全套接層)或 TLS(Transport Layer Security,安全層傳輸協(xié)議)的組合使用,加密 HTTP 的通信內(nèi)容。屬于通信加密，即在整個(gè)通信線路中加密。

HTTP+ 加密 + 認(rèn)證 + 完整性保護(hù) =HTTPS（HTTP Secure ）

SSL/TSL
SSL(Secure Sockets Layer 安全套接層)
TLS：(Transport Layer Security，傳輸層安全協(xié)議)

HTTPS 采用共享密鑰加密（對(duì)稱(chēng)）和公開(kāi)密鑰加密（非對(duì)稱(chēng)）兩者并用的混合加密機(jī)制。若密鑰能夠?qū)崿F(xiàn)安全交換,那么有可能會(huì)考慮僅使用公開(kāi)密鑰加密 來(lái)通信。但是公開(kāi)密鑰加密與共享密鑰加密相比,其處理速度要慢。
所以應(yīng)充分利用兩者各自的優(yōu)勢(shì),將多種方法組合起來(lái)用于通信。 在交換密鑰環(huán)節(jié)使用公開(kāi)密鑰加密方式,之后的建立通信交換報(bào)文階段 則使用共享密鑰加密方式。

HTTPS
握手過(guò)程的簡(jiǎn)單描述如下：

1.瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站。

 服務(wù)器獲得瀏覽器公鑰

2.網(wǎng)站從中選出一組加密算法與HASH算法，并將自己的身份信息以證書(shū)的形式發(fā)回給瀏覽器。證書(shū)里面包含了網(wǎng)站地址，加密公鑰，以及證書(shū)的頒發(fā)機(jī)構(gòu)等信息。

 瀏覽器獲得服務(wù)器公鑰

3.獲得網(wǎng)站證書(shū)之后瀏覽器要做以下工作：
a) 驗(yàn)證證書(shū)的合法性（頒發(fā)證書(shū)的機(jī)構(gòu)是否合法，證書(shū)中包含的網(wǎng)站地址是否與正在訪問(wèn)的地址一致等），如果證書(shū)受信任，則瀏覽器欄里面會(huì)顯示一個(gè)小鎖頭，否則會(huì)給出證書(shū)不受信的提示。
b) 如果證書(shū)受信任，或者是用戶(hù)接受了不受信的證書(shū)，瀏覽器會(huì)生成一串隨機(jī)數(shù)的密碼（接下來(lái)通信的密鑰），并用證書(shū)中提供的公鑰加密（共享密鑰加密）。
c) 使用約定好的HASH計(jì)算握手消息，并使用生成的隨機(jī)數(shù)對(duì)消息進(jìn)行加密，最后將之前生成的所有信息發(fā)送給網(wǎng)站。

 瀏覽器驗(yàn)證->隨機(jī)密碼，并用服務(wù)器的公鑰加密->生成HASH握手，用密碼加密

4.網(wǎng)站接收瀏覽器發(fā)來(lái)的數(shù)據(jù)之后要做以下的操作：
a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發(fā)來(lái)的握手消息，并驗(yàn)證HASH是否與瀏覽器發(fā)來(lái)的一致。
b) 使用密碼加密一段握手消息，發(fā)送給瀏覽器。

服務(wù)器用自己的密鑰解出隨機(jī)密碼->用密碼解密握手消息（共享密鑰通信）->驗(yàn)證HASH與瀏覽器是否一致（驗(yàn)證瀏覽器）

5.瀏覽器解密并計(jì)算握手消息的HASH，如果與服務(wù)端發(fā)來(lái)的HASH一致，
此時(shí)握手過(guò)程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機(jī)密碼并利用對(duì)稱(chēng)加密算法進(jìn)行加密。

慢

貴

整個(gè)頁(yè)面的請(qǐng)求都要使用HTTPS

未完待續(xù)。。。

參考文章
1.HTTP 協(xié)議入門(mén)
2.淺談HTTP的無(wú)狀態(tài)性
3.深入理解HTTP協(xié)議
4.HTTP請(qǐng)求響應(yīng)過(guò)程 與HTTPS區(qū)別_Linux教程_Linux公社-Linux系統(tǒng)...
5.寫(xiě)給后端程序員的HTTP緩存原理介紹
6 TCP的三次握手(建立連接）和四次揮手(關(guān)閉連接）
7 HTTP/1.1與HTTP/1.0的區(qū)別
8 HTTP 頭部詳細(xì)解釋
9 HTTP 1.1與HTTP 1.0的比較
10 如何理解HTTP協(xié)議的“無(wú)連接,無(wú)狀態(tài)”特點(diǎn)?
11 《圖解HTTP》