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

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

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

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

1991年發(fā)布的HTTP/0.9。該版本極其簡單，只有一個命令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請求和回應(yīng)的格式也變了。除了數(shù)據(jù)部分，每次通信都必須包括頭信息（HTTP header），用來描述一些元數(shù)據(jù)。

緩存
HTTP/1.0

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

HTTP/1.1

   Cache-Control描述的是一個相對時間，在進行緩存命中的時候，都是利用客戶端時間進行判斷，所以相比較Expires，Cache-Control的緩存管理更有效，安全一些。

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

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

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

HTTP/1.1

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

長連接Connection: Keep-Alive
HTTP 1.0

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

HTTP 1.1

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

管道機制/流水線（Pipelining）處理

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

Content-Length 字段

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

Host頭域
HTTP1.0

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

HTTP1.1

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

其他

   1.1版還新增了許多動詞方法：PUT、PATCH、HEAD、 OPTIONS、DELETE

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

二進制協(xié)議

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

多工

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

數(shù)據(jù)流

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

頭信息壓縮

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

服務(wù)器推送

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

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

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

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

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

不驗證通信方的身份,因此有可能遭遇偽裝

無法證明報文的完整性,所以有可能已遭篡改

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

HTTP+ 加密 + 認證 + 完整性保護 =HTTPS（HTTP Secure ）

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

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

HTTPS
握手過程的簡單描述如下：

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

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

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

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

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

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

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

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

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

慢

貴

整個頁面的請求都要使用HTTPS

未完待續(xù)。。。

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