HTTP详解(1)-工作原理
?????
1. HTTP簡(jiǎn)介
???????? HTTP協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計(jì)算機(jī)正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。
?????????在了解HTTP如何工作之前，我們先了解計(jì)算機(jī)之間的通信。
2. 計(jì)算機(jī)相互之間的通信
??????? 互聯(lián)網(wǎng)的關(guān)鍵技術(shù)就是TCP/IP協(xié)議。兩臺(tái)計(jì)算機(jī)之間的通信是通過(guò)TCP/IP協(xié)議在因特網(wǎng)上進(jìn)行的。實(shí)際上這個(gè)是兩個(gè)協(xié)議：
??????? TCP : Transmission Control Protocol 傳輸控制協(xié)議和IP： Internet Protocol? 網(wǎng)際協(xié)議。
IP：計(jì)算機(jī)之間的通信
?????? ?IP協(xié)議是計(jì)算機(jī)用來(lái)相互識(shí)別的通信的一種機(jī)制，每臺(tái)計(jì)算機(jī)都有一個(gè)IP.用來(lái)在internet上標(biāo)識(shí)這臺(tái)計(jì)算機(jī)。? IP 負(fù)責(zé)在因特網(wǎng)上發(fā)送和接收數(shù)據(jù)包。通過(guò) IP，消息（或者其他數(shù)據(jù)）被分割為小的獨(dú)立的包，并通過(guò)因特網(wǎng)在計(jì)算機(jī)之間傳送。IP 負(fù)責(zé)將每個(gè)包路由至它的目的地。
??????? IP協(xié)議僅僅是允許計(jì)算機(jī)相互發(fā)消息，但它并不檢查消息是否以發(fā)送的次序到達(dá)而且沒有損壞（只檢查關(guān)鍵的頭數(shù)據(jù)）。為了提供消息檢驗(yàn)功能，直接在IP協(xié)議上設(shè)計(jì)了傳輸控制協(xié)議TCP.
????????
TCP : 應(yīng)用程序之間的通信
?????? TCP確保數(shù)據(jù)包以正確的次序到達(dá)，并且嘗試確認(rèn)數(shù)據(jù)包的內(nèi)容沒有改變。TCP在IP地址之上引端口（port），它允許計(jì)算機(jī)通過(guò)網(wǎng)絡(luò)提供各種服務(wù)。一些端口號(hào)為不同的服務(wù)保留，而且這些端口號(hào)是眾所周知。
?????? 服務(wù)或者守護(hù)進(jìn)程：在提供服務(wù)的機(jī)器上，有程序監(jiān)聽特定端口上的通信流。例如大多數(shù)電子郵件通信流出現(xiàn)在端口25上，用于wwww的HTTP通信流出現(xiàn)在80端口上。
???????當(dāng)應(yīng)用程序希望通過(guò) TCP 與另一個(gè)應(yīng)用程序通信時(shí)，它會(huì)發(fā)送一個(gè)通信請(qǐng)求。這個(gè)請(qǐng)求必須被送到一個(gè)確切的地址。在雙方“握手”之后，TCP 將在兩個(gè)應(yīng)用程序之間建立一個(gè)全雙工 (full-duplex) 的通信，占用兩個(gè)計(jì)算機(jī)之間整個(gè)的通信線路。TCP 用于從應(yīng)用程序到網(wǎng)絡(luò)的數(shù)據(jù)傳輸控制。TCP 負(fù)責(zé)在數(shù)據(jù)傳送之前將它們分割為 IP 包，然后在它們到達(dá)的時(shí)候?qū)⑺鼈冎亟M。
?????? TCP/IP 就是TCP 和 IP 兩個(gè)協(xié)議在一起協(xié)同工作，有上下層次的關(guān)系。
?????? TCP 負(fù)責(zé)應(yīng)用軟件（比如你的瀏覽器）和網(wǎng)絡(luò)軟件之間的通信。IP 負(fù)責(zé)計(jì)算機(jī)之間的通信。TCP 負(fù)責(zé)將數(shù)據(jù)分割并裝入 IP 包，IP 負(fù)責(zé)將包發(fā)送至接受者，傳輸過(guò)程要經(jīng)IP路由器負(fù)責(zé)根據(jù)通信量、網(wǎng)絡(luò)中的錯(cuò)誤或者其他參數(shù)來(lái)進(jìn)行正確地尋址，然后在它們到達(dá)的時(shí)候重新組合它們。
3. HTTP協(xié)議所在的協(xié)議層
????? HTTP是基于TCP協(xié)議之上的。在TCP/IP協(xié)議參考模型的各層對(duì)應(yīng)的協(xié)議如下圖,其中HTTP是應(yīng)用層的協(xié)議。
?????
?
4. HTTP請(qǐng)求響應(yīng)模型
?????? HTTP由請(qǐng)求和響應(yīng)構(gòu)成，是一個(gè)標(biāo)準(zhǔn)的客戶端服務(wù)器模型（B/S）。HTTP協(xié)議永遠(yuǎn)都是客戶端發(fā)起請(qǐng)求，服務(wù)器回送響應(yīng)。見下圖:
???
?????? HTTP是一個(gè)無(wú)狀態(tài)的協(xié)議。無(wú)狀態(tài)是指客戶機(jī)（Web瀏覽器）和服務(wù)器之間不需要建立持久的連接，這意味著當(dāng)一個(gè)客戶端向服務(wù)器端發(fā)出請(qǐng)求，然后服務(wù)器返回響應(yīng)(response)，連接就被關(guān)閉了，在服務(wù)器端不保留連接的有關(guān)信息.HTTP遵循請(qǐng)求(Request)/應(yīng)答(Response)模型。客戶機(jī)（瀏覽器）向服務(wù)器發(fā)送請(qǐng)求，服務(wù)器處理請(qǐng)求并返回適當(dāng)?shù)膽?yīng)答。所有HTTP連接都被構(gòu)造成一套請(qǐng)求和應(yīng)答。
5. HTTP工作過(guò)程
???? 一次HTTP操作稱為一個(gè)事務(wù)，其工作整個(gè)過(guò)程如下：
???? 1 ) 、地址解析，
???? 如用客戶端瀏覽器請(qǐng)求這個(gè)頁(yè)面：http://localhost.com:8080/index.htm
???? 從中分解出協(xié)議名、主機(jī)名、端口、對(duì)象路徑等部分，對(duì)于我們的這個(gè)地址，解析得到的結(jié)果如下：
???? 協(xié)議名：http
???? 主機(jī)名：localhost.com
???? 端口：8080
???? 對(duì)象路徑：/index.htm
????? 在這一步，需要域名系統(tǒng)DNS解析域名localhost.com,得主機(jī)的IP地址。
??? 2）、封裝HTTP請(qǐng)求數(shù)據(jù)包
???? 把以上部分結(jié)合本機(jī)自己的信息，封裝成一個(gè)HTTP請(qǐng)求數(shù)據(jù)包
?????3）封裝成TCP包，建立TCP連接（TCP的三次握手）
???????在HTTP工作開始之前，客戶機(jī)（Web瀏覽器）首先要通過(guò)網(wǎng)絡(luò)與服務(wù)器建立連接，該連接是通過(guò)TCP來(lái)完成的，該協(xié)議與IP協(xié)議共同構(gòu)建Internet，即著名的TCP/IP協(xié)議族，因此Internet又被稱作是TCP/IP網(wǎng)絡(luò)。HTTP是比TCP更高層次的應(yīng)用層協(xié)議，根據(jù)規(guī)則，只有低層協(xié)議建立之后才能，才能進(jìn)行更層協(xié)議的連接，因此，首先要建立TCP連接，一般TCP連接的端口號(hào)是80。這里是8080端口
?????4）客戶機(jī)發(fā)送請(qǐng)求命令
?????? 建立連接后，客戶機(jī)發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為：統(tǒng)一資源標(biāo)識(shí)符（URI）、協(xié)議版本號(hào)，后邊是MIME信息包括請(qǐng)求修飾符、客戶機(jī)信息和可內(nèi)容。
這里順便說(shuō)明個(gè)人理解
URI：? 統(tǒng)一資源標(biāo)識(shí)符，用來(lái)唯一的標(biāo)識(shí)一個(gè)資源，是一種語(yǔ)義上的抽象概念。
URL ：統(tǒng)一資源定位符，它是一種具體的URI，即URL可以用來(lái)標(biāo)識(shí)一個(gè)資源，而且還指明了如何訪問(wèn)到這個(gè)資源
URI是以一種抽象的，高層次概念定義統(tǒng)一資源標(biāo)識(shí)，標(biāo)記了一個(gè)網(wǎng)絡(luò)資源，而URL則是具體的資源標(biāo)識(shí)的方式。
簡(jiǎn)單比喻 - URI唯一標(biāo)識(shí)一個(gè)人（例如身份證）， URL定義了如何訪問(wèn)到這個(gè)人（例如家庭地址）
???? 5）服務(wù)器響應(yīng)
?????服務(wù)器接到請(qǐng)求后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行，包括信息的協(xié)議版本號(hào)、一個(gè)成功或錯(cuò)誤的代碼，后邊是MIME信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容。
??????? 實(shí)體消息是服務(wù)器向?yàn)g覽器發(fā)送頭信息后，它會(huì)發(fā)送一個(gè)空白行來(lái)表示頭信息的發(fā)送到此為結(jié)束，接著，它就以Content-Type應(yīng)答頭信息所描述的格式發(fā)送用戶所請(qǐng)求的實(shí)際數(shù)據(jù)
???? 6）服務(wù)器關(guān)閉TCP連接
?????一般情況下，一旦Web服務(wù)器向?yàn)g覽器發(fā)送了請(qǐng)求數(shù)據(jù)，它就要關(guān)閉TCP連接，然后如果瀏覽器或者服務(wù)器在其頭信息加入了這行代碼
????Connection:keep-alive
?? TCP連接在發(fā)送后將仍然保持打開狀態(tài)，于是，瀏覽器可以繼續(xù)通過(guò)相同的連接發(fā)送請(qǐng)求。保持連接節(jié)省了為每個(gè)請(qǐng)求建立新連接所需的時(shí)間，還節(jié)約了網(wǎng)絡(luò)帶寬。
6. HTTP協(xié)議棧中各層數(shù)據(jù)流??????
?????????????首先我們看看客戶端請(qǐng)求的時(shí)候，數(shù)據(jù)在各層協(xié)議的數(shù)據(jù)組織如下圖：
????????
??????????? 而服務(wù)器解析客戶機(jī)請(qǐng)求就是反向操作的過(guò)程，如下圖：
??????????
???????
?????? 客戶機(jī)發(fā)起一次請(qǐng)求的時(shí)候：
?????? 客戶機(jī)會(huì)將請(qǐng)求封裝成http數(shù)據(jù)包-->封裝成Tcp數(shù)據(jù)包-->封裝成Ip數(shù)據(jù)包--->封裝成數(shù)據(jù)幀--->硬件將幀數(shù)據(jù)轉(zhuǎn)換成bit流（二進(jìn)制數(shù)據(jù)）-->最后通過(guò)物理硬件（網(wǎng)卡芯片）發(fā)送到指定地點(diǎn)。
????? ?服務(wù)器硬件首先收到bit流....... 然后轉(zhuǎn)換成ip數(shù)據(jù)包。于是通過(guò)ip協(xié)議解析Ip數(shù)據(jù)包，然后又發(fā)現(xiàn)里面是tcp數(shù)據(jù)包，就通過(guò)tcp協(xié)議解析Tcp數(shù)據(jù)包，接著發(fā)現(xiàn)是http數(shù)據(jù)包通過(guò)http協(xié)議再解析http數(shù)據(jù)包得到數(shù)據(jù)。
7. HTTPS實(shí)現(xiàn)原理? ??
??????? HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL。其所用的端口號(hào)是443。
?????? SSL：SSL（Secure Socket Layer，安全套接字層），是netscape公司設(shè)計(jì)的主要用于web的安全傳輸協(xié)議。這種協(xié)議在WEB上獲得了廣泛的應(yīng)用。通過(guò)證書認(rèn)證來(lái)確保客戶端和網(wǎng)站服務(wù)器之間的通信數(shù)據(jù)是加密安全的。
?????? SSL協(xié)議位于TCP/IP協(xié)議與各種應(yīng)用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持。SSL協(xié)議可分為兩層： SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。 SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開始前，通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。
??????? TLS：TLS(Transport Layer Security，傳輸層安全協(xié)議)，用于兩個(gè)應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務(wù)組）制定的一種新的協(xié)議，它建立在SSL 3.0協(xié)議規(guī)范之上，是SSL 3.0的后續(xù)版本，可以理解為SSL 3.1(可簡(jiǎn)單理解為同一事物不同階段的不同稱呼)，它是寫入了 RFC 的。該協(xié)議由兩層組成： TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）。較低的層為 TLS 記錄協(xié)議，位于某個(gè)可靠的傳輸協(xié)議（例如 TCP）上面。
?SSL和TLS的主要區(qū)別?
TLS的主要目標(biāo)是使SSL更安全，并使協(xié)議的規(guī)范更精確和完善。另外,TLS版本號(hào)也與SSL的不同(TLS的版本1.0使用的版本號(hào)為SSLv3.1).
?
7.1、加解密算法
有兩種基本的加解密算法類型：
? ? ? 1)、對(duì)稱加密（symmetrcic encryption）：密鑰只有一個(gè)，加密解密為同一個(gè)密碼，且加解密速度快，典型的對(duì)稱加密算法有DES、AES，RC5，3DES等；例如我們使用WinRAR創(chuàng)建一個(gè)帶密碼（口令）的加密壓縮包。當(dāng)你下次要把這個(gè)壓縮文件解開的時(shí)候，你需要輸入【同樣的】密碼。在這個(gè)例子中，密碼/口令就如同剛才說(shuō)的“密鑰”。
? ? ? ?對(duì)稱加密主要問(wèn)題是共享秘鑰，除你的計(jì)算機(jī)（客戶端）知道另外一臺(tái)計(jì)算機(jī)（服務(wù)器）的私鑰秘鑰，否則無(wú)法對(duì)通信流進(jìn)行加密解密。解決這個(gè)問(wèn)題的方案非對(duì)稱秘鑰。
? ? ? 2)、非對(duì)稱加密：使用兩個(gè)秘鑰：公共秘鑰和私有秘鑰。私有秘鑰由一方密碼保存（一般是服務(wù)器保存），另一方任何人都可以獲得公共秘鑰。一般來(lái)說(shuō)指:加密時(shí)使用公鑰,解密時(shí)使用私鑰。
? ? ? 這種密鑰成對(duì)出現(xiàn)（且根據(jù)公鑰無(wú)法推知私鑰，根據(jù)私鑰也無(wú)法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對(duì)對(duì)稱加密速度較慢，典型的非對(duì)稱加密算法有RSA、DSA等。
7.2、https的單向認(rèn)證通信過(guò)程
非對(duì)稱加密很耗時(shí)，不可能對(duì)實(shí)際的數(shù)據(jù)都非對(duì)稱加密來(lái)傳輸。HTTPS采用的是處理信息的方式是：結(jié)合對(duì)稱加密+非對(duì)稱加密這兩種方式。我們可以用非對(duì)稱加密的方式來(lái)傳輸對(duì)稱加密過(guò)程中的密鑰，之后我們就可以采取對(duì)稱加密的方式來(lái)傳輸數(shù)據(jù)了。
簡(jiǎn)單工作過(guò)程如下：
1、客戶端請(qǐng)求公鑰：服務(wù)器用明文的方式給客戶端發(fā)送自己的公鑰（對(duì)應(yīng)的私鑰還在服務(wù)端手上，沒有泄露）。
2、客戶端生成隨機(jī)數(shù)密鑰：客戶端收到公鑰之后，會(huì)生成一個(gè)隨機(jī)數(shù)密鑰(對(duì)稱加密用的)，然后用服務(wù)器的公鑰對(duì)這把隨機(jī)數(shù)密鑰進(jìn)行加密，之后再把隨機(jī)數(shù)密鑰傳輸給服務(wù)器。
3、服務(wù)器使用私鑰解密隨機(jī)數(shù)密鑰：服務(wù)器收到隨機(jī)數(shù)密鑰之后用私鑰解密得到隨機(jī)數(shù)解密，此時(shí)，客戶端和服務(wù)端都擁有了這個(gè)隨機(jī)數(shù)密鑰，并且它沒有被泄露。即使黑客截取了公鑰或者加密后的隨機(jī)數(shù)都無(wú)法解密（因?yàn)楣€加密的隨機(jī)數(shù)只能用私鑰解密）
4、對(duì)稱加密傳輸：最后服務(wù)器安全得到這把隨機(jī)數(shù)密鑰了，而客戶端也有同樣一把隨機(jī)數(shù)密鑰，他們就可以進(jìn)行對(duì)稱加密傳輸數(shù)據(jù)了。
過(guò)程大致如下："握手階段"涉及四次通信，我們一個(gè)個(gè)來(lái)看。需要注意的是，"握手階段"的所有通信都是明文的。
1、客戶端發(fā)出TSL請(qǐng)求（ClientHello）：
由于客戶端(如瀏覽器)對(duì)一些加解密算法的支持程度不一樣，但是在TLS協(xié)議傳輸過(guò)程中必須使用同一套加解密算法才能保證數(shù)據(jù)能夠正常的加解密。在TLS握手階段，客戶端首先要告知服務(wù)端，自己支持哪些加密算法，所以客戶端需要將本地支持的加密套件(Cipher Suite)的列表傳送給服務(wù)端。除此之外，客戶端還要產(chǎn)生一個(gè)隨機(jī)數(shù)，這個(gè)隨機(jī)數(shù)一方面需要在客戶端保存，另一方面需要傳送給服務(wù)端，客戶端的隨機(jī)數(shù)需要跟服務(wù)端產(chǎn)生的隨機(jī)數(shù)結(jié)合起來(lái)產(chǎn)生后面要講到的 Master Secret 。
綜上，在這一步，客戶端主要向服務(wù)器提供以下信息：
2、 服務(wù)器回應(yīng)（SeverHello->Server Hello Done)
server_hello：服務(wù)端返回協(xié)商的信息結(jié)果，包括選擇使用的協(xié)議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method、隨機(jī)數(shù) ServerRnd等，其中隨機(jī)數(shù)用于后續(xù)的密鑰協(xié)商;
server_certificates：服務(wù)器端配置對(duì)應(yīng)的證書鏈，用于身份驗(yàn)證與密鑰交換;
server_hello_done：通知客戶端 server_hello 信息發(fā)送結(jié)束;
從Server Hello到Server Done，有些服務(wù)端的實(shí)現(xiàn)是每條單獨(dú)發(fā)送，有服務(wù)端實(shí)現(xiàn)是合并到一起發(fā)送。Sever Hello和Server Done都是只有頭沒有內(nèi)容的數(shù)據(jù)。從抓包圖中，數(shù)據(jù)包是分段發(fā)送的：
服務(wù)端在接收到客戶端的Client Hello之后，服務(wù)端需要將自己的證書發(fā)送給客戶端。這個(gè)證書是對(duì)于服務(wù)端的一種認(rèn)證。例如，客戶端收到了一個(gè)來(lái)自于稱自己是www.aliyun.com的數(shù)據(jù)，但是如何證明對(duì)方是合法的aliyun呢？這就是證書的作用，aliyun的證書可以證明它是aliyun，而不是其他云。證書是需要申請(qǐng)，并由專門的數(shù)字證書認(rèn)證機(jī)構(gòu)(CA)通過(guò)非常嚴(yán)格的審核之后頒發(fā)的電子證書。頒發(fā)證書的同時(shí)會(huì)產(chǎn)生一個(gè)私鑰和公鑰。私鑰由服務(wù)端自己保存，不可泄漏。公鑰則是附帶在證書的信息中，可以公開的。證書本身也附帶一個(gè)證書電子簽名，這個(gè)簽名用來(lái)驗(yàn)證證書的完整性和真實(shí)性，可以防止證書被串改。另外，證書還有個(gè)有效期。
在服務(wù)端向客戶端發(fā)送的證書中沒有提供足夠的信息（證書公鑰）的時(shí)候，還可以向客戶端發(fā)送一個(gè) Server Key Exchange，
此外，對(duì)于非常重要的保密數(shù)據(jù)，服務(wù)端還需要對(duì)客戶端進(jìn)行驗(yàn)證，以保證數(shù)據(jù)傳送給了安全的合法的客戶端。服務(wù)端可以向客戶端發(fā)出 Cerficate Request 消息，要求客戶端發(fā)送證書對(duì)客戶端的合法性進(jìn)行驗(yàn)證。比如，金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，就會(huì)向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。
跟客戶端一樣，服務(wù)端也需要產(chǎn)生一個(gè)隨機(jī)數(shù)發(fā)送給客戶端。客戶端和服務(wù)端都需要使用這兩個(gè)隨機(jī)數(shù)來(lái)產(chǎn)生Master Secret。
最后服務(wù)端會(huì)發(fā)送一個(gè)Server Hello Done消息給客戶端，表示Server Hello消息結(jié)束了。
綜上，在這一步，服務(wù)器的回應(yīng)包含以下內(nèi)容：
3、客戶端回應(yīng)（Certificate Verify）
client_key_exchange+change_cipher_spec+encrypted_handshake_message
Client Key Exchange：
如果服務(wù)端需要對(duì)客戶端進(jìn)行驗(yàn)證，在客戶端收到服務(wù)端的 Server Hello 消息之后，首先需要向服務(wù)端發(fā)送客戶端的證書，讓服務(wù)端來(lái)驗(yàn)證客戶端的合法性。
Certificate Verify （驗(yàn)證證書的合法性）：
接著，客戶端需要對(duì)服務(wù)端的證書進(jìn)行檢查：頒發(fā)證書的機(jī)構(gòu)是否合法、證書中的域名與實(shí)際域名不一致、證書已經(jīng)過(guò)期等等。如果是瀏覽器客戶端，若證書受信任，則瀏覽器欄里面會(huì)顯示一個(gè)小鎖頭，否則會(huì)給出證書不受信的提示。
如果證書沒有問(wèn)題，客戶端就會(huì)從服務(wù)器證書中取出服務(wù)器的公鑰。然后，向服務(wù)器發(fā)送下面幾項(xiàng)項(xiàng)信息：
上面第一項(xiàng)的隨機(jī)數(shù)，是整個(gè)握手階段出現(xiàn)的第三個(gè)隨機(jī)數(shù)，它是客戶端使用一些加密算法(例如：RSA, Diffie-Hellman)產(chǎn)生一個(gè)48個(gè)字節(jié)的Key，這個(gè)Key叫 PreMaster Secret，很多材料上也被稱作 PreMaster Key。
此時(shí)客戶端已經(jīng)獲取全部的計(jì)算協(xié)商密鑰需要的信息：兩個(gè)明文隨機(jī)數(shù) ClientRnd和 ServerRnd與自己計(jì)算產(chǎn)生的 PreMasterSecret ，計(jì)算得到協(xié)商密鑰;?
enc_key（SessionSecret）=Fuc(ClientRnd, ServerRnd, PreMasterSecret )
Change Cipher Spec:??
Change Cipher Spec客戶端通知服務(wù)器后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信;
Change Cipher Spec是一個(gè)獨(dú)立的協(xié)議，體現(xiàn)在數(shù)據(jù)包中就是一個(gè)字節(jié)的數(shù)據(jù)，用于告知服務(wù)端，客戶端已經(jīng)切換到之前協(xié)商好的加密套件（Cipher Suite）的狀態(tài)，準(zhǔn)備使用之前協(xié)商好的加密套件加密數(shù)據(jù)并傳輸了。
Encrypted Handshake Message:?
在Change cipher Spec傳輸完畢之后，通過(guò)之前交換的數(shù)據(jù)(前面發(fā)送的所有內(nèi)容)生成一個(gè) ClientHash 數(shù)據(jù)。 ? 客戶端會(huì)使用之前協(xié)商好的加密算法和SessionSecret加密ClientHash 數(shù)據(jù)傳送給服務(wù)端，此ClientHash 數(shù)據(jù)是為了在正式傳輸應(yīng)用數(shù)據(jù)之前對(duì)剛剛握手建立起來(lái)的加解密通道進(jìn)行驗(yàn)證。
4、服務(wù)器的最后回應(yīng)（Server Finish）
4.1. 使用自己證書的私鑰解密出 PreMasterSecret
4.2. 生成SessionSecret：服務(wù)端根據(jù)之前的隨機(jī)數(shù)（ClientRnd ，ServerRnd，PreMasterSecret ）和約定的加密算法，生成用于加密后續(xù)傳輸數(shù)據(jù)的會(huì)話密鑰 SessionSecret。
enc_key=Fuc(ClientRnd, ServerRnd, PreMasterSecret )
4.3.校驗(yàn) clientHash (確認(rèn)不是假的客戶端）和密鑰SessionSecret正確性：
計(jì)算之前所有接收信息的 hash 值，即為serverHash。然后解密客戶端發(fā)送encrypted_handshake_message的ClientHash，驗(yàn)證數(shù)據(jù)和密鑰正確性（即serverHash ==ClientHash? 是否為true）；
4.4. Change Cipher Spec確認(rèn)變更編碼:? 會(huì)給客戶端發(fā)送一個(gè) ChangeCipherSpec，告知客戶端已經(jīng)切換到協(xié)商過(guò)的加密套件狀態(tài)，準(zhǔn)備使用加密套件和 Session Secret加密數(shù)據(jù)了。
4.5. Encrypted Handshake Message Finish信息：服務(wù)器也結(jié)合所有當(dāng)前的通信參數(shù)信息生成一段Finish消息數(shù)據(jù)，并采用協(xié)商密鑰SessionSecret? 與算法加密并發(fā)送到客戶端， 以驗(yàn)證之前通過(guò)握手建立起來(lái)的加解密通道是否成功。
5、握手結(jié)束
客戶端計(jì)算所有接收信息的 hash 值，并采用協(xié)商密鑰解密 encrypted_handshake_message，驗(yàn)證服務(wù)器發(fā)送的數(shù)據(jù)和密鑰，驗(yàn)證通過(guò)則握手完成;
==========================================================
6、數(shù)據(jù)傳輸：
根據(jù)之前的握手信息，如果客戶端和服務(wù)端都能對(duì)Finish信息進(jìn)行正常加解密且消息正確的被驗(yàn)證，則說(shuō)明握手通道已經(jīng)建立成功，接下來(lái)，雙方可以使用上面產(chǎn)生的Session Secret對(duì)數(shù)據(jù)進(jìn)行加密傳輸了。
在這個(gè)過(guò)程中，有幾個(gè)關(guān)鍵點(diǎn)：
- 前兩次的隨機(jī)數(shù)（客戶端隨機(jī)數(shù)、服務(wù)端隨機(jī)數(shù)）是明文傳輸?shù)?/strong>
- 非對(duì)稱密鑰算法只被使用了一次，即客戶端使用證書公鑰加密 PreMasterSecret，服務(wù)端使用證書私鑰解密出 PreMasterSecret
- 應(yīng)用數(shù)據(jù)的傳輸使用的是對(duì)稱密鑰算法，客戶端/服務(wù)端都使用會(huì)話密鑰進(jìn)行加/解密
在握手階段，安全與否的關(guān)鍵在于 PreMasterSecret 是否能夠被破解，雖然理論上通過(guò) RSA 算法加密是比較安全的，但還是有破解的可能性。最安全的做法是不發(fā)送 PreMasterSecret，而是根據(jù)一系列參數(shù)由客戶端和服務(wù)端分別計(jì)算出 PreMasterSecret，這個(gè)算法就是迪菲－赫爾曼密鑰交換。
有了PreMasterSecret 以后，客戶端和服務(wù)器就同時(shí)有了三個(gè)隨機(jī)數(shù)，接著雙方就用事先商定的加密方法，各自生成本次會(huì)話所用的同一把"會(huì)話密鑰"。至于為什么一定要用三個(gè)隨機(jī)數(shù)，來(lái)生成"會(huì)話密鑰"，dog250解釋得很好：
"不管是客戶端還是服務(wù)器，都需要隨機(jī)數(shù)，這樣生成的密鑰才不會(huì)每次都一樣。由于SSL協(xié)議中證書是靜態(tài)的，因此十分有必要引入一種隨機(jī)因素來(lái)保證協(xié)商出來(lái)的密鑰的隨機(jī)性。
對(duì)于RSA密鑰交換算法來(lái)說(shuō)，pre-master-key本身就是一個(gè)隨機(jī)數(shù)，再加上hello消息中的隨機(jī)，三個(gè)隨機(jī)數(shù)通過(guò)一個(gè)密鑰導(dǎo)出器最終導(dǎo)出一個(gè)對(duì)稱密鑰。
pre master的存在在于SSL協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)，如果隨機(jī)數(shù)不隨機(jī)，那么pre master secret就有可能被猜出來(lái)，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機(jī)因素，那么客戶端和服務(wù)器加上pre master secret三個(gè)隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了，一個(gè)偽隨機(jī)可能完全不隨機(jī)，可是是三個(gè)偽隨機(jī)就十分接近隨機(jī)了，每增加一個(gè)自由度，隨機(jī)性增加的可不是一。"
https通信的優(yōu)點(diǎn)：
1）客戶端產(chǎn)生的密鑰只有客戶端和服務(wù)器端能得到；
2）加密的數(shù)據(jù)只有客戶端和服務(wù)器端才能得到明文；
3）客戶端到服務(wù)端的通信是安全的
7.3、非對(duì)稱加密算法RSA的加密解密原理
1、每個(gè)用戶都有一對(duì)私鑰和公鑰。
- ?? 私鑰用來(lái)進(jìn)行解密和簽名，是給自己用的。
- ?公鑰由本人公開，用于加密和驗(yàn)證簽名，是給別人用的。
2、當(dāng)該用戶發(fā)送文件時(shí)，用私鑰簽名，別人用他給的公鑰解密，可以保證該信息是由他發(fā)送的。即數(shù)字簽名。
3、當(dāng)該用戶接受文件時(shí)，別人用他的公鑰加密，他用私鑰解密，可以保證該信息只能由他看到。即安全傳輸.
7.4、數(shù)字證書和CA
數(shù)字證書（Digital Certificate）是用來(lái)證明公鑰（非對(duì)稱密鑰算法中用于加密的密鑰）所有者身份的。
1、數(shù)字證書是CA對(duì)公鑰簽名：數(shù)字證書則是由證書認(rèn)證機(jī)構(gòu)（CA）對(duì)證書申請(qǐng)者真實(shí)身份驗(yàn)證之后，用CA的根證書對(duì)申請(qǐng)人的一些基本信息以及申請(qǐng)人的公鑰進(jìn)行簽名（相當(dāng)于加蓋發(fā)證書機(jī)構(gòu)的公章）后形成的一個(gè)數(shù)字文件。
2、數(shù)字證書公開的：CA完成簽發(fā)證書后，會(huì)將證書發(fā)布在CA的證書庫(kù)（目錄服務(wù)器）中，任何人都可以查詢和下載，因此數(shù)字證書和公鑰一樣是公開的。實(shí)際上，數(shù)字證書就是經(jīng)過(guò)CA認(rèn)證過(guò)的公鑰。
3、如何認(rèn)證公鑰可靠：我們?nèi)巳硕伎梢宰约荷梢粋€(gè)公鑰，但是這個(gè)公鑰是否能代表是你的，這個(gè)認(rèn)證的過(guò)程需要一個(gè)權(quán)威機(jī)構(gòu)執(zhí)行，這個(gè)機(jī)構(gòu)就是證書授權(quán)中心。
證書授權(quán)中心（Certificate Authority）負(fù)責(zé)證書頒發(fā)。CA 是行業(yè)內(nèi)信得過(guò)的組織機(jī)構(gòu)，它具有權(quán)威性，由它頒發(fā)的證書大家都相信是可靠的。
一般我們自己也生成HTTPS證書，但是自己生成的HTTPS證書卻是不能用的。因?yàn)闉g覽器只會(huì)承認(rèn)受信任CA所簽發(fā)出來(lái)的證書，其他個(gè)人自簽的HTTPS證書瀏覽器是不會(huì)承認(rèn)的，一律會(huì)顯示“此網(wǎng)站不安全”的安全提示。所以不要嘗試自己去生成HTTPS證書，需要HTTPS證書我們就去找受信任的CA機(jī)構(gòu)進(jìn)行申請(qǐng)。
7.5、CA認(rèn)證流程
SSL雙向認(rèn)證步驟：
通過(guò)上述介紹，我們得知使用 SSL/TLS 需要做如下準(zhǔn)備：
下面我們針對(duì)自建 CA 做一個(gè)完整的示例（證書相關(guān)使用 Linux 的 openssl 命令，客戶端、服務(wù)端使用 Golang）。
- 數(shù)字證書：可以找權(quán)威的證書授權(quán)中心頒發(fā)證書（有付費(fèi)的，也有免費(fèi)的），也可以自己做 CA，然后自己給自己頒發(fā)證書
- 服務(wù)端使用證書，比如配置 NGINX 來(lái)使用
- 客戶端使用 SSL/TLS 協(xié)議和服務(wù)端進(jìn)行通訊，如果是自己的 CA 頒發(fā)的證書，還需要在客戶端導(dǎo)入 CA 的根證書
建立 CA
- 生成 CA 私鑰：openssl genrsa -out ca.key 2048
- 生成 CA 根證書：openssl req -new -x509 -days 3650-key ca.key -out ca.crt
頒發(fā)證書
- 生成證書私鑰：openssl genrsa -out auto.pem 1024
- 生成證書公鑰：openssl rsa -in auto.pem -out auto.key
- 生成簽名請(qǐng)求：openssl req -new -key auto.pem -out auto.csr，其中的 Common Name 一定要填寫客戶端訪問(wèn)時(shí)的域名，并且不能是 IP
- CA 簽名（頒發(fā)）證書：openssl x509 -req -sha256 -in auto.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 -out auto.crt
最終我們需要的就是公鑰 auto.key 以及證書 auto.crt。
?
7.6、瀏覽器內(nèi)置常用證書
一個(gè)重要的問(wèn)題是，如何安全轉(zhuǎn)交認(rèn)證機(jī)構(gòu)的公鑰是一件很困難的事，因此，大多數(shù)瀏覽器開發(fā)商發(fā)布版本時(shí)，會(huì)事先植入常用認(rèn)證機(jī)關(guān)的公鑰。
我們可以Google Chrome為例：打開瀏覽器的設(shè)置選項(xiàng)，選擇高級(jí)，可以看到隱私設(shè)置和安全性下面的一些設(shè)置，其中管理證書就可以看到谷歌瀏覽器一些內(nèi)置證書，如圖：
7.8雙向認(rèn)證
雙向認(rèn)證和單向認(rèn)證原理基本差不多，主要區(qū)別是除了客戶端需要認(rèn)證服務(wù)端以外，服務(wù)端對(duì)客戶端也需要認(rèn)證。什么場(chǎng)景下需要驗(yàn)證客戶端呢？比如一些銀行業(yè)務(wù)，銀行會(huì)要求客戶必須在電腦上插入它們簽發(fā)的U盾之類的東西，或者安裝什么控件，這里就類似客戶端證書的概念，沒有這個(gè)證書的人無(wú)法使用銀行提供的業(yè)務(wù)。
8. HTTP各種長(zhǎng)度限制? ?
1. URL長(zhǎng)度限制
在Http1.1協(xié)議中并沒有提出針對(duì)URL的長(zhǎng)度進(jìn)行限制，RFC協(xié)議里面是這樣描述的，HTTP協(xié)議并不對(duì)URI的長(zhǎng)度做任何的限制，服務(wù)器端必須能夠處理任何它們所提供服務(wù)多能接受的URI，并且能夠處理無(wú)限長(zhǎng)度的URI,如果服務(wù)器不能處理過(guò)長(zhǎng)的URI,那么應(yīng)該返回414狀態(tài)碼。
雖然Http協(xié)議規(guī)定了，但是Web服務(wù)器和瀏覽器對(duì)URI都有自己的長(zhǎng)度限制。
服務(wù)器的限制:我接觸的最多的服務(wù)器類型就是Nginx和Tomcat,對(duì)于url的長(zhǎng)度限制，它們都是通過(guò)控制http請(qǐng)求頭的長(zhǎng)度來(lái)進(jìn)行限制的，nginx的配置參數(shù)為large_client_header_buffers，tomcat的請(qǐng)求配置參數(shù)為maxHttpHeaderSize,都是可以自己去進(jìn)行設(shè)置。
瀏覽器的限制:每種瀏覽器也會(huì)對(duì)url的長(zhǎng)度有所限制，下面是幾種常見瀏覽器的url長(zhǎng)度限制:(單位:字符)
IE : 2803
Firefox:65536
Chrome:8182
Safari:80000
Opera:190000
對(duì)于get請(qǐng)求，在url的長(zhǎng)度限制范圍之內(nèi)，請(qǐng)求的參數(shù)個(gè)數(shù)沒有限制。
2. Post數(shù)據(jù)的長(zhǎng)度限制
Post數(shù)據(jù)的長(zhǎng)度限制與url長(zhǎng)度限制類似，也是在Http協(xié)議中沒有規(guī)定長(zhǎng)度限制,長(zhǎng)度限制可以在服務(wù)器端配置最大http請(qǐng)求頭長(zhǎng)度的方式來(lái)實(shí)現(xiàn)。
3. Cookie的長(zhǎng)度限制
Cookie的長(zhǎng)度限制分這么幾個(gè)方面來(lái)總結(jié)。
(1) 瀏覽器所允許的每個(gè)域下的最大cookie數(shù)目,沒有去自己測(cè)試，從網(wǎng)上找到的資料大概是這么個(gè)情況
IE :原先為20個(gè)，后來(lái)升級(jí)為50個(gè)
Firefox: 50個(gè)
Opera:30個(gè)
Chrome:180個(gè)
Safari:無(wú)限制
當(dāng)Cookie數(shù)超過(guò)限制數(shù)時(shí)瀏覽器的行為：IE和Opera會(huì)采用LRU算法將老的不常使用的Cookie清除掉，Firefox的行為是隨機(jī)踢出某些Cookie的值。當(dāng)然無(wú)論怎樣的策略，還是盡量不要讓Cookie數(shù)目超過(guò)瀏覽器所允許的范圍。
(2) 瀏覽器所允許的每個(gè)Cookie的最大長(zhǎng)度
Firefox和Safari:4079字節(jié)
Opera:4096字節(jié)
IE:4095字節(jié)
(3) 服務(wù)器中Http請(qǐng)求頭長(zhǎng)度的限制。Cookie會(huì)被附在每次http請(qǐng)求頭中傳遞給服務(wù)器，因此還會(huì)受到服務(wù)器請(qǐng)求頭長(zhǎng)度的影響。
4. Html5 LocalStorage
Html5提供了本地存儲(chǔ)機(jī)制來(lái)供Web應(yīng)用在客戶端存儲(chǔ)數(shù)據(jù)，盡管這個(gè)并不屬于Http協(xié)議的一部分，但是隨著Html5的流行，我們可能需要越來(lái)越多使用LocalStorage,甚至當(dāng)它普及的時(shí)候跟它打交道就會(huì)同今天我們跟Cookie打交道一樣多。
對(duì)于LocalStorage的長(zhǎng)度限制，同Cookie的限制類似，也是瀏覽器針對(duì)域來(lái)限制,只不過(guò)cookie限制的是個(gè)數(shù)，LocalStorage限制的是長(zhǎng)度:
Firefox\Chrome\Opera都是允許每個(gè)域的最大長(zhǎng)度為5MB
但是這次IE比較大方，允許的最大長(zhǎng)度是10MB
總結(jié)
以上是生活随笔為你收集整理的HTTP详解(1)-工作原理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 【BMC】Redfish简述
- 下一篇： 三相锁相环仿真及其代码验证，附C语言源码