HTTP協(xié)議知識點總結(jié)

HTTP簡介

HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫,是用于從萬維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。

HTTP位于應(yīng)用層猴誊。它的請求是建立在一些底層協(xié)議的基礎(chǔ)上完成的尤勋。如TCP/IP協(xié)議棧中，HTTP需要TCP的三次握手連接成功后才能向服務(wù)器發(fā)起請求规伐。當(dāng)然蟹倾，如果是HTTPS的話，還需要TSL和SSL安全層猖闪。

HTTP.JPG

HTTP協(xié)議工作于客戶端-服務(wù)端架構(gòu)為上鲜棠。瀏覽器作為HTTP客戶端通過URL向HTTP服務(wù)端即WEB服務(wù)器發(fā)送所有請求。Web服務(wù)器根據(jù)接收到的請求后培慌，向客戶端發(fā)送響應(yīng)信息豁陆。

HTTP的特點

支持客戶/服務(wù)器模式。
簡單快速：客戶向服務(wù)器請求服務(wù)時吵护，只需傳送請求方法和路徑盒音。請求方法常用的有GET、HEAD馅而、POST祥诽。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單瓮恭，使得HTTP服務(wù)器的程序規(guī)模小雄坪，因而通信速度很快。
靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象偎血。正在傳輸?shù)念愋陀蒀ontent-Type（Content-Type是HTTP包中用來表示內(nèi)容類型的標(biāo)識）加以標(biāo)記诸衔。
無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求颇玷，并收到客戶的應(yīng)答后笨农，即斷開連接。采用這種方式可以節(jié)省傳輸時間帖渠。
無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議谒亦。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息空郊，則它必須重傳份招，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面狞甚，在服務(wù)器不需要先前信息時它的應(yīng)答就較快锁摔。

HTTP的無連接

早期每個客戶端（即瀏覽器）與服務(wù)器之間交換數(shù)據(jù)的間歇性較大，HTTP被設(shè)計為請求時建連接哼审、請求完釋放連接谐腰，以盡快將資源釋放出來服務(wù)其他客戶端孕豹。

隨著時間的推移，網(wǎng)頁變得越來越復(fù)雜十气，里面可能嵌入了很多圖片励背，這時候每次訪問圖片都需要建立一次 TCP 連接就顯得很低效。后來砸西，Keep-Alive 被提出用來解決這效率低的問題叶眉。

Keep-Alive 功能使客戶端到服務(wù)器端的連接持續(xù)有效，當(dāng)出現(xiàn)對服務(wù)器的后繼請求時芹枷，Keep-Alive 功能避免了建立或者重新建立連接衅疙。

這樣一來，客戶端和服務(wù)器之間的 HTTP 連接就會被保持杖狼，不會斷開（超過 Keep-Alive 規(guī)定的時間炼蛤，意外斷電等情況除外）妖爷，當(dāng)客戶端發(fā)送另外一個請求時蝶涩，就使用這條已經(jīng)建立的連接。

HTTP的無狀態(tài)

HTTP 是一個無狀態(tài)協(xié)議絮识，這意味著每個請求都是獨立的绿聘，Keep-Alive 沒能改變這個結(jié)果。

缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息次舌，則它必須重傳熄攘，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面彼念，在服務(wù)器不需要先前信息時它的應(yīng)答就較快挪圾。

客戶端與服務(wù)器進(jìn)行動態(tài)交互的 Web 應(yīng)用程序出現(xiàn)之后，HTTP 無狀態(tài)的特性嚴(yán)重阻礙了這些應(yīng)用程序的實現(xiàn)逐沙，畢竟交互是需要承前啟后的哲思。于是，兩種用于保持 HTTP 連接狀態(tài)的技術(shù)就應(yīng)運而生了棚赔，一個是 Cookie，而另一個則是 Session徘郭。

Cookie

Cookie誕生的最初目的是為了存儲web中的狀態(tài)信息靠益，以方便服務(wù)器端使用。最典型的應(yīng)用是判定注冊用戶是否已經(jīng)登錄網(wǎng)站残揉。

Cookie的處理流程為：

服務(wù)器向客戶端發(fā)送cookie
瀏覽器將cookie保存
之后每次http請求瀏覽器都會將cookie發(fā)送給服務(wù)器端（當(dāng)然胧后，不排除用戶手工刪除Cookie。還有一些Cookie在用戶退出會話的時候就被刪除了抱环，這樣可以有效保護(hù)個人隱私）

Session

Cookie是記錄在客戶端的,而Session是記錄在服務(wù)端的壳快。

當(dāng)客戶端訪問服務(wù)器否個網(wǎng)頁的時候途样，會在服務(wù)器端的內(nèi)存里開辟一塊內(nèi)存，這塊內(nèi)存就叫做session濒憋，而這個內(nèi)存是跟瀏覽器窗口關(guān)聯(lián)在一起的何暇。就是當(dāng)訪問一個頁面的時候服務(wù)器會給瀏覽器創(chuàng)建一個獨一無二的號碼,叫sessionID。這樣就可以在打開同一個網(wǎng)站的第二個頁面時獲取到第一個頁面中session保留下來的對應(yīng)信息凛驮。

session的兩種實現(xiàn)方式：

通過cookies實現(xiàn)：服務(wù)器創(chuàng)建session出來后裆站，會把session的id號，以cookie的形式回寫給客戶機(jī)黔夭，這樣宏胯，只要客戶機(jī)的瀏覽器不關(guān)，再去訪問服務(wù)器時本姥，都會帶著session的id號去肩袍，服務(wù)器發(fā)現(xiàn)客戶機(jī)瀏覽器帶session id過來了，就會使用內(nèi)存中與之對應(yīng)的session為之服務(wù)婚惫。若當(dāng)瀏覽器禁用或不支持cookie的情況下氛赐，就可以通過第二種方式獲取session內(nèi)存中的數(shù)據(jù)資源。
通過URL重寫來實現(xiàn)：當(dāng)禁用cookie了先舷，這就需要每次請求的時候艰管，都需要把session id告訴服務(wù)端，所以可以對訪問的url進(jìn)行重寫蒋川，將session id作為一個參數(shù)添加進(jìn)去牲芋，同樣能達(dá)到確認(rèn)身份的目的。

Cookie和Session的區(qū)別

于Cookie是記錄在客戶端的,而Session是記錄在服務(wù)端的捺球。
cookie在過期時間之前一直有效缸浦，即使窗口或瀏覽器關(guān)閉；客戶端的sessionID在當(dāng)前瀏覽器窗口關(guān)閉后自動刪除氮兵，但服務(wù)器保存的 Session 數(shù)據(jù)不是立即釋放裂逐，此時數(shù)據(jù)還會存在。當(dāng)然我們可以設(shè)置一個 Session 超時時間胆剧，一旦超過規(guī)定時間沒有客戶端請求時絮姆，服務(wù)器就會清除對應(yīng) SessionId 的 Session 信息。
Cookie對于瀏覽器的不同窗口是共享的秩霍。而Session對于瀏覽器的不同窗口不共享
Cookie數(shù)據(jù)大小不能超過4k篙悯，Session雖然也有存儲大小的限制，但比cookie大得多铃绒，可以達(dá)到5M或更大鸽照。

HTTP的各個版本

HTTP/0.9

HTTP協(xié)議的最初版本，功能簡陋颠悬，僅支持請求方式GET澜沟，并且僅能請求訪問HTML格式的資源。

HTTP/1.0

在0.9版本上做了進(jìn)步，增加了請求方式POST和HEAD濒析；

不再局限于0.9版本的HTML格式盾致，根據(jù)Content-Type可以支持多種數(shù)據(jù)格式，即MIME多用途互聯(lián)網(wǎng)郵件擴(kuò)展鉴腻，例如text/html、image/jpeg等；

同時也開始支持cache，就是當(dāng)客戶端在規(guī)定時間內(nèi)訪問統(tǒng)一網(wǎng)站，直接訪問cache即可统翩。

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

但是1.0版本的工作方式是：每次TCP連接只能發(fā)送一個請求，當(dāng)服務(wù)器響應(yīng)后就會關(guān)閉這次連接，下一個請求需要再次建立TCP連接乡摹。

為了解決TCP連接的新建成本很高的問題板熊，有些瀏覽器在請求時，用了一個非標(biāo)準(zhǔn)的keep-alive Connection字段情萤。這個字段要求服務(wù)器不要關(guān)閉TCP連接，以便其他請求復(fù)用柒傻。

HTTP/1.1

持久連接

1.1 版的最大變化，就是引入了持久連接（persistent connection）较木，即TCP連接默認(rèn)不關(guān)閉伐债，一個TCP連接可以允許多個HTTP請求復(fù)用糜芳，不用聲明Connection: keep-alive傲茄【诎瘢客戶端和服務(wù)器發(fā)現(xiàn)對方一段時間沒有活動盘榨，就可以主動關(guān)閉連接。不過型酥，規(guī)范的做法是山憨，客戶端在最后一個請求時查乒，發(fā)送Connection: close，明確要求服務(wù)器關(guān)閉TCP連接郁竟。

管道機(jī)制

加入了管道機(jī)制玛迄，在同一個TCP連接里，允許多個請求同時發(fā)送棚亩，增加了并發(fā)性蓖议，進(jìn)一步改善了HTTP協(xié)議的效率。舉例來說讥蟆，客戶端需要請求兩個資源勒虾。以前的做法是，在同一個TCP連接里面瘸彤，先發(fā)送A請求修然，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出B請求钧栖。管道機(jī)制則是允許瀏覽器同時發(fā)出A請求和B請求低零，但是服務(wù)器還是按照順序，先回應(yīng)A請求拯杠，完成后再回應(yīng)B請求掏婶。

雖然1.1版允許復(fù)用TCP連接，但是同一個TCP連接里面潭陪，所有的數(shù)據(jù)通信是按次序進(jìn)行的雄妥。服務(wù)端是按隊列順序處理請求的，服務(wù)器只有處理完一個回應(yīng)依溯，才會進(jìn)行下一個回應(yīng)老厌。假如前面的請求處理時間很長，后面就會有許多請求排隊等著黎炉，這樣就造成了“隊頭阻塞”的問題枝秤。

為了避免這個問題可以減少請求數(shù)，或者同時多開持久連接慷嗜。SPDY也允許給每個request設(shè)置優(yōu)先級淀弹，這樣重要的請求就會優(yōu)先得到響應(yīng)。比如瀏覽器加載首頁庆械，首頁的html內(nèi)容應(yīng)該優(yōu)先展示薇溃，之后才是各種靜態(tài)資源文件，腳本文件等加載缭乘，這樣可以保證用戶能第一時間看到網(wǎng)頁內(nèi)容沐序。

一個TCP連接現(xiàn)在可以傳送多個回應(yīng)，勢必就要有一種機(jī)制，區(qū)分?jǐn)?shù)據(jù)包是屬于哪一個回應(yīng)的策幼。這就是Content-length字段的作用邑时，聲明本次回應(yīng)的字節(jié)長度。后面的字節(jié)就屬于下一個回應(yīng)了垄惧。

分塊傳輸編碼

使用Content-Length字段的前提條件是刁愿，服務(wù)器發(fā)送回應(yīng)之前，必須知道回應(yīng)的數(shù)據(jù)長度到逊。而對于一些很耗時的動態(tài)操作來說铣口，這意味著，服務(wù)器要等到所有操作完成觉壶，才能發(fā)送數(shù)據(jù)脑题，顯然這樣的效率不高。更好的處理方法是铜靶，產(chǎn)生一塊數(shù)據(jù)叔遂，就發(fā)送一塊，采用"流模式"（stream）取代"緩存模式"（buffer）争剿。

因此已艰，1.1版規(guī)定可以不使用Content-Length字段，而使用"分塊傳輸編碼"（chunked transfer encoding）蚕苇。只要請求或回應(yīng)的頭信息有
Transfer-Encoding: chunked哩掺，就表明回應(yīng)將由數(shù)量未定的數(shù)據(jù)塊組成。

每個非空的數(shù)據(jù)塊之前涩笤，會有一個16進(jìn)制的數(shù)值嚼吞，表示這個塊的長度。最后是一個大小為0的塊蹬碧，就表示本次回應(yīng)的數(shù)據(jù)發(fā)送完了舱禽。例如：

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
 
25
This is the data in the first chunk
 
1C
and this is the second one
 
4
last
 
0

斷點續(xù)傳

定義了斷點續(xù)傳相關(guān)的HTTP頭 Range和Content-Range字段，一個最簡單的斷點續(xù)傳實現(xiàn)大概如下：

1.客戶端下載一個1024K的文件恩沽，已經(jīng)下載了其中512K

網(wǎng)絡(luò)中斷誊稚，客戶端請求續(xù)傳，因此需要在HTTP頭中申明本次需要續(xù)傳的片段：

Range:bytes=512000-

通知服務(wù)端從文件的512K位置開始傳輸文件

服務(wù)端收到斷點續(xù)傳請求罗心，從文件的512K位置開始傳輸片吊，并且在HTTP頭中增加：

Content-Range:bytes 512000-/1024000

并且此時服務(wù)端返回的HTTP狀態(tài)碼應(yīng)該是206，而不是200协屡。

HTTP/2.0

多路復(fù)用

即不僅客戶端能夠同時發(fā)送多個請求，服務(wù)端也能同時處理多個請求全谤，而且不用按照順序一一對應(yīng)肤晓。解決了隊頭堵塞的問題。

舉例來說，在一個TCP連接里面补憾，服務(wù)器同時收到了A請求和B請求漫萄，于是先回應(yīng)A請求，結(jié)果發(fā)現(xiàn)處理過程非常耗時盈匾，于是就發(fā)送A請求已經(jīng)處理好的部分腾务，接著回應(yīng)B請求，完成后削饵，再發(fā)送A請求剩下的部分岩瘦。

多路復(fù)用.jpg

數(shù)據(jù)流

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

HTTP/2 將每個請求或回應(yīng)的所有數(shù)據(jù)包，稱為一個數(shù)據(jù)流（stream）跛璧。每個數(shù)據(jù)流都有一個獨一無二的編號严里。數(shù)據(jù)包發(fā)送的時候，都必須標(biāo)記數(shù)據(jù)流ID追城，用來區(qū)分它屬于哪個數(shù)據(jù)流刹碾。另外還規(guī)定，客戶端發(fā)出的數(shù)據(jù)流漓柑，ID一律為奇數(shù)教硫，服務(wù)器發(fā)出的，ID為偶數(shù)辆布。

數(shù)據(jù)流發(fā)送到一半的時候瞬矩，客戶端和服務(wù)器都可以發(fā)送信號（RST_STREAM幀），取消這個數(shù)據(jù)流锋玲。1.1版取消數(shù)據(jù)流的唯一方法景用，就是關(guān)閉TCP連接。這就是說惭蹂，HTTP/2 可以取消某一次請求伞插，同時保證TCP連接還打開著，可以被其他請求使用盾碗。

客戶端還可以指定數(shù)據(jù)流的優(yōu)先級媚污。優(yōu)先級越高，服務(wù)器就會越早回應(yīng)廷雅。

服務(wù)器推送

HTTP/2 允許服務(wù)器未經(jīng)請求耗美，主動向客戶端發(fā)送資源京髓，這叫做服務(wù)器推送（server push）。

意思是說商架，當(dāng)我們對支持HTTP2.0的web server請求數(shù)據(jù)的時候堰怨，服務(wù)器會順便把一些客戶端需要的資源一起推送到客戶端，免得客戶端再次創(chuàng)建連接發(fā)送請求到服務(wù)器端獲取蛇摸。這種方式非常合適加載靜態(tài)資源备图。

常見場景是客戶端請求一個網(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ā)給客戶端了购岗。

服務(wù)端推送能把客戶端所需要的資源伴隨著index.html一起發(fā)送到客戶端汰聋，省去了客戶端重復(fù)請求的步驟。正因為沒有發(fā)起請求喊积，建立連接等操作烹困，所以靜態(tài)資源通過服務(wù)端推送的方式可以極大地提升速度。

服務(wù)器推送.png

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

HTTP/1.1 版的頭信息肯定是文本（ASCII編碼）乾吻，數(shù)據(jù)體可以是文本髓梅，也可以是二進(jìn)制。HTTP/2 則是一個徹底的二進(jìn)制協(xié)議绎签，頭信息和數(shù)據(jù)體都是二進(jìn)制枯饿，并且統(tǒng)稱為"幀"（frame）：頭信息幀和數(shù)據(jù)幀。

HTTP 請求和響應(yīng)報文

HTTP 請求報文

一個HTTP請求報文由請求行（request line）诡必、請求頭部（header）奢方、空行和請求數(shù)據(jù)4個部分組成：

HTTP請求報文.png

請求行（request line）

請求行由請求方法字段、URL字段和HTTP協(xié)議版本字段3個字段組成爸舒，它們用空格分隔蟋字。例如，GET /index.html HTTP/1.1扭勉。

HTTP/1.1的請求方法有9種：

GET 請求指定的頁面信息鹊奖，并返回實體主體。
HEAD    類似于 GET 請求涂炎，只不過返回的響應(yīng)中沒有具體的內(nèi)容嫉入，用于獲取報頭
POST    向指定資源提交數(shù)據(jù)進(jìn)行處理請求（例如提交表單或者上傳文件）焰盗。數(shù)據(jù)被包含在請求體中。POST 請求可能會導(dǎo)致新的資源的建立和/或已有資源的修改咒林。
PUT 從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
DELETE  請求服務(wù)器刪除指定的頁面爷光。
CONNECT HTTP/1.1 協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器垫竞。
OPTIONS 允許客戶端查看服務(wù)器的性能。
TRACE   回顯服務(wù)器收到的請求蛀序，主要用于測試或診斷欢瞪。
PATCH   是對 PUT 方法的補(bǔ)充，用來對已知資源進(jìn)行局部更新 徐裸。

請求頭部（header）

請求頭部由關(guān)鍵字/值對組成遣鼓，每行一對，關(guān)鍵字和值用英文冒號“:”分隔重贺。請求頭部通知服務(wù)器有關(guān)于客戶端請求的信息骑祟，典型的請求頭有：

User-Agent：產(chǎn)生請求的瀏覽器類型。

Accept：客戶端可識別的內(nèi)容類型列表气笙。

Host：請求的主機(jī)名次企，允許多個域名同處一個IP地址，即虛擬主機(jī)潜圃。

空行

最后一個請求頭之后是一個空行缸棵，發(fā)送回車符和換行符，通知服務(wù)器以下不再有請求頭谭期。

請求數(shù)據(jù)

請求數(shù)據(jù)不在GET方法中使用堵第，而是在POST方法中使用。POST方法適用于需要客戶填寫表單的場合隧出。與請求數(shù)據(jù)相關(guān)的最常使用的請求頭是Content-Type和Content-Length踏志。

HTTP 響應(yīng)報文

HTTP響應(yīng)報文由三個部分組成：狀態(tài)行、消息報頭鸳劳、響應(yīng)正文：

HTTP響應(yīng)報文.png

狀態(tài)行

狀態(tài)行由HTTP版本號狰贯，狀態(tài)碼（Status-Code）和原因組成。根據(jù)狀態(tài)碼可以知道返回信息的狀態(tài)赏廓。狀態(tài)碼規(guī)定如下：

1xx: 信息響應(yīng)類涵紊，表示接收到請求并且繼續(xù)處理
100——必須繼續(xù)發(fā)出請求
101——要求服務(wù)器根據(jù)請求轉(zhuǎn)換HTTP協(xié)議版本
2xx: 處理成功響應(yīng)類，表示動作被成功接收幔摸、理解和接受
200——交易成功
201——提示知道新文件的URL
202——接受和處理摸柄、但處理未完成
203——返回信息不確定或不完整
204——請求收到，但返回信息為空
205——服務(wù)器完成了請求既忆，用戶代理必須復(fù)位當(dāng)前已經(jīng)瀏覽過的文件
206——服務(wù)器已經(jīng)完成了部分用戶的GET請求
3xx: 重定向響應(yīng)類驱负，為了完成指定的動作嗦玖，必須接受進(jìn)一步處理
300——請求的資源可在多處得到
301——刪除請求數(shù)據(jù)
302——在其他地址發(fā)現(xiàn)了請求數(shù)據(jù)
303——建議客戶訪問其他URL或訪問方式
304——客戶端已經(jīng)執(zhí)行了GET，但文件未變化
305——請求的資源必須從服務(wù)器指定的地址得到
306——前一版本HTTP中使用的代碼跃脊，現(xiàn)行版本中不再使用
307——申明請求的資源臨時性刪除
4xx: 客戶端錯誤宇挫，客戶請求包含語法錯誤或者是不能正確執(zhí)行
400——錯誤請求，如語法錯誤
401——未授權(quán)
402——保留有效ChargeTo頭響應(yīng)
403——禁止訪問
404——沒有發(fā)現(xiàn)文件酪术、查詢或URl
405——在Request-Line字段定義的方法不允許
406——根據(jù)發(fā)送的Accept器瘪，請求資源不可訪問
407——用戶必須首先在代理服務(wù)器上得到授權(quán)
408——客戶端沒有在指定的時間內(nèi)完成請求
409——對當(dāng)前資源狀態(tài)，請求不能完成
410——服務(wù)器不再有此資源且無進(jìn)一步地址
411——服務(wù)器拒絕用戶定義的Content-Length
412——一個或多個請求頭字段在當(dāng)前請求中錯誤
413——請求的資源大于服務(wù)器允許的大小
414——請求的資源URL長于服務(wù)器允許的長度
415——請求資源不支持請求項目格式
416——請求中包含Range請求頭字段绘雁，在當(dāng)前請求資源范圍內(nèi)沒有range指示值橡疼，請求也不包含If-Range請求頭字段
417——服務(wù)器不滿足請求Expect頭字段指定的期望值，如果是代理服務(wù)器庐舟，可能是下一級服務(wù)器不能滿足請求長欣除。
5xx: 服務(wù)端錯誤，服務(wù)器不能正確執(zhí)行一個正確的請求
500——內(nèi)部服務(wù)器錯誤
501——未實現(xiàn)
502——網(wǎng)關(guān)錯誤

HTTPS

HTTP 有著一個致命的缺陷挪略，那就是內(nèi)容是明文傳輸?shù)睦悖瑳]有經(jīng)過任何加密，而這些明文數(shù)據(jù)會經(jīng)過WiFi瘟檩、路由器抹缕、運營商、機(jī)房等多個物理設(shè)備節(jié)點墨辛，如果在這中間任意一個節(jié)點被監(jiān)聽卓研，傳輸?shù)膬?nèi)容就會完全暴露，這一攻擊手法叫做MITM（Man In The Middle）中間人攻擊睹簇。

HTTPS基于HTTP協(xié)議奏赘，通過SSL或TLS提供加密處理數(shù)據(jù)、驗證對方身份以及數(shù)據(jù)完整性保護(hù)太惠。

HTTPS的加解密流程

HTTPS.png

用戶在瀏覽器發(fā)起HTTPS請求磨淌，默認(rèn)使用服務(wù)端的443端口進(jìn)行連接；
HTTPS需要使用一套CA數(shù)字證書凿渊，證書內(nèi)會附帶一個公鑰Pub梁只，而與之對應(yīng)的私鑰Private保留在服務(wù)端不公開；
服務(wù)端收到請求埃脏，返回配置好的包含公鑰Pub的證書給客戶端搪锣；
客戶端收到證書，校驗合法性彩掐，主要包括是否在有效期內(nèi)构舟、證書的域名與請求的域名是否匹配，上一級證書是否有效（遞歸判斷堵幽，直到判斷到系統(tǒng)內(nèi)置或瀏覽器配置好的根證書）狗超，如果不通過弹澎，則顯示HTTPS警告信息，如果通過則繼續(xù)努咐；
客戶端生成一個用于對稱加密的隨機(jī)Key苦蒿，并用證書內(nèi)的公鑰Pub進(jìn)行加密，發(fā)送給服務(wù)端麦撵；
服務(wù)端收到隨機(jī)Key的密文刽肠，使用與公鑰Pub配對的私鑰Private進(jìn)行解密，得到客戶端真正想發(fā)送的隨機(jī)Key免胃；
服務(wù)端使用客戶端發(fā)送過來的隨機(jī)Key對要傳輸?shù)腍TTP數(shù)據(jù)進(jìn)行對稱加密，將密文返回客戶端惫撰；
客戶端使用隨機(jī)Key對稱解密密文羔沙，得到HTTP數(shù)據(jù)明文；
后續(xù)HTTPS請求使用之前交換好的隨機(jī)Key進(jìn)行對稱加解密厨钻。

怎么保證保證服務(wù)器給客戶端下發(fā)的公鑰是真正的公鑰扼雏，而不是中間人偽造的公鑰呢？

問題的描述：

中間人篡改公鑰.png

出現(xiàn)這一問題的核心原因是客戶端無法確認(rèn)收到的公鑰是不是真的是服務(wù)端發(fā)來的夯膀。為了解決這個問題诗充，互聯(lián)網(wǎng)引入了一個公信機(jī)構(gòu)，這就是CA诱建。

服務(wù)端在使用HTTPS前蝴蜓，去經(jīng)過認(rèn)證的CA機(jī)構(gòu)申請頒發(fā)一份數(shù)字證書，數(shù)字證書里包含有證書持有者俺猿、證書有效期茎匠、公鑰等信息，服務(wù)端將證書發(fā)送給客戶端押袍，客戶端校驗證書身份和要訪問的網(wǎng)站身份確實一致后再進(jìn)行后續(xù)的加密操作诵冒。

但是，如果中間人也聰明一點谊惭，只改動了證書中的公鑰部分汽馋，客戶端依然不能確認(rèn)公鑰是否被篡改。

解決的方法

數(shù)字證書認(rèn)證機(jī)構(gòu)（CA圈盔，Certificate Authority）是客戶端與服務(wù)器雙方都可信賴的第三方機(jī)構(gòu)豹芯。

服務(wù)端在使用HTTPS前，去經(jīng)過認(rèn)證的CA機(jī)構(gòu)申請頒發(fā)一份數(shù)字證書（申請時發(fā)出自己的公鑰Pub）药磺，申請到的數(shù)字證書里包含有證書持有者告组、證書有效期、公鑰等信息癌佩，服務(wù)端再將證書發(fā)送給客戶端木缝，客戶端校驗證書身份和要訪問的網(wǎng)站身份確實一致后再進(jìn)行后續(xù)的加密操作便锨。

具體過程如下：

1.（簽名，Signing）CA機(jī)構(gòu)擁有自己的一對公鑰和私鑰

2.（簽名我碟，Signing）CA機(jī)構(gòu)在頒發(fā)證書時對證書明文信息Data以服務(wù)端公鑰Pub作為輸入放案，進(jìn)行哈希，得到一個特有的Hash值矫俺。

3.（簽名吱殉，Signing）將Hash值用CA機(jī)構(gòu)私鑰進(jìn)行加簽得到數(shù)字簽名Signature，并將該簽名與服務(wù)端公鑰Pub厘托，CA證書明文綁定到一起

4.（認(rèn)證友雳，Verification）客戶端得到證書，分解得到服務(wù)端公鑰Pub铅匹，明文部分Data和數(shù)字簽名Signature

5.（認(rèn)證押赊，Verification）用CA機(jī)構(gòu)的公鑰對數(shù)字簽名進(jìn)行解簽，得到Hash值（由于CA機(jī)構(gòu)是一種公信身份包斑，因此在系統(tǒng)或瀏覽器中會內(nèi)置CA機(jī)構(gòu)的證書和公鑰信息）

6.（認(rèn)證流礁，Verification）用證書里聲明的哈希算法和服務(wù)端公鑰Pub對明文Data部分進(jìn)行哈希得到Hash

7.（認(rèn)證，Verification）當(dāng)自己計算得到的哈希值與解簽后的Hash值相等罗丰，表示證書和服務(wù)端公鑰都可信神帅，沒有被篡改