????????為啥要寫這篇文章呢冗锁，是因為之前也搜過關(guān)于TCP/IP齐唆、HTTP的相關(guān)知識點，但是因為知識點太零散冻河，所以理解的不透徹箍邮，過一陣就忘沒了，只記住了TCP需要三次握手叨叙、TCP是有狀態(tài)的锭弊，UDP是無狀態(tài)的等等。擂错。味滞。 然后最近抽時間將《圖解HTTP》讀了一遍，收獲非常大钮呀，就計劃結(jié)合之前學(xué)習(xí)的零散知識點融合一下寫一篇文章剑鞍，就算是鞏固吧，下面開始正文

????????咱們現(xiàn)在使用的網(wǎng)絡(luò)傳輸數(shù)據(jù)(上網(wǎng)爽醋、聊天)攒暇，都是要遵循"TCP/IP協(xié)議族"的，這是可以通信的基礎(chǔ)子房，而HTTP協(xié)議是TCP/IP協(xié)議族里的一部分。

????????為啥遵循TCP/IP協(xié)議是可以通信的基礎(chǔ)呢就轧？因為無規(guī)矩不成方圓证杭。比如我要給你寄一封信，為啥我給你寄的信你可以收到妒御，是因為我寄信時遵循了好多規(guī)定解愤，比如我必須要把我寫的信放到信封里，我放到一個紙盒子里乎莉，人家就不給我寄送讲，比如我必須要貼郵票奸笤，不貼人家也不給我寄，這就是協(xié)議哼鬓。用信封监右，貼郵票，就是寄信需要遵循的協(xié)議异希，不遵循健盒，信就發(fā)不出去，同樣称簿，TCP/IP協(xié)議族(是一個統(tǒng)稱)就是為網(wǎng)絡(luò)傳輸定制的扣癣，你不遵循這些協(xié)議，就上不了網(wǎng)憨降，發(fā)不了消息父虑，那TCP/IP協(xié)議具體需要遵循啥呢，下面咱們就來說說

????????首先又到了之前聽到吐聽到惡心的OSI模型

????????OSI（Open System Interconnect）授药，即開放式系統(tǒng)互聯(lián)士嚎。 一般都叫OSI參考模型,OSI定義了網(wǎng)絡(luò)互連的七層框架（物理層、數(shù)據(jù)鏈路層烁焙、網(wǎng)絡(luò)層航邢、傳輸層、會話層骄蝇、表示層膳殷、應(yīng)用層）,好了，去他娘的7層九火，誰他媽記得住赚窃。。岔激。勒极。

????????SO...咱們先說簡單的，雖然OSI參考模型是7層虑鼎，但是TCP/IP參考模型就4層辱匿，也就是說支持網(wǎng)絡(luò)傳輸?shù)?b>TCP/IP協(xié)議族可以分為四大塊，一下子少了好多炫彩，就可以容易理解一點了匾七，然后咱們就從4層說起，這4層就是 應(yīng)用層->傳輸層->網(wǎng)絡(luò)層->鏈路層。

比如我給身在美國的你寄一堆好吃的，我得把吃的包裝一下鲫惶，貼上快遞單肴敛，寫上收信人的地址该默，國家仆潮、城市签则、小區(qū)阵具、幾號樓拢驾，然后送到順豐快遞點奖磁，順豐快遞點得先看目的地在哪，然后規(guī)劃出飛機航線独旷，然后就運送到飛機場署穗，裝飛機出發(fā)了。對應(yīng)的關(guān)系如下

應(yīng)用層--負(fù)責(zé)包裝數(shù)據(jù)--將信放到信封嵌洼、貼郵票案疲、寫地址

傳輸層--負(fù)責(zé)運輸數(shù)據(jù)--運送郵件的飛機

網(wǎng)絡(luò)層--負(fù)責(zé)導(dǎo)航規(guī)劃路線--郵局里規(guī)劃路線的人(可能拿著高德地圖)

鏈路層--負(fù)責(zé)將信件弄成可上飛機的標(biāo)準(zhǔn)--郵件在坐上飛機在空中飛之前，需要經(jīng)過安檢貼標(biāo)簽等麻养，弄成符合可以空運的樣子褐啡，下飛機標(biāo)簽再撕掉

那么每一層對應(yīng)到TCP/IP協(xié)議族(協(xié)議族里有很多協(xié)議)里又分別對應(yīng)到哪些呢，請看下面鳖昌，紅色標(biāo)注的是考試的重點备畦，哈哈

應(yīng)用層(負(fù)責(zé)包裝數(shù)據(jù))—-HTPP協(xié)議終于要露臉了，他就是處于該協(xié)議许昨。他的作用就是生成針對目標(biāo)服務(wù)器的請求報文懂盐。那報文包含啥呀，請求報文是由請求方法糕档、請求URL莉恼、協(xié)議版本、可選的請求首部字段速那、內(nèi)容實體構(gòu)成俐银。比如我web端或客戶端要將一個“name”字段傳到服務(wù)器，那么報文就是對name的包裝端仰，比如我是用get還是post請求方法捶惜，請求的URL是啥，內(nèi)容實體"name"荔烧，content-type等吱七，雖然有些是你在代碼里設(shè)置的，但是需要將你設(shè)置的內(nèi)容按照http協(xié)議里要求的格式進(jìn)行封裝鹤竭，然后服務(wù)器也會按照這個協(xié)議定義的格式進(jìn)行解析踊餐，拿到"name"這個字段。所以可以簡單的理解為對數(shù)據(jù)按一定格式包裝诺擅，當(dāng)然FTP協(xié)議也屬于這一層，區(qū)別可自行搜索啡直。在這一層的還有DNS(域名解析)服務(wù)烁涌，將URL解析成對應(yīng)的IP地址苍碟，比如www.baidu.com會解析成192.166.xx.xx，用戶通常使用域名來訪問服務(wù)器撮执，而不是IP地址微峰，因為與一串?dāng)?shù)字的IP地址相比，用字母配合數(shù)字的表現(xiàn)形式來制定計算機名更符合人類的記憶習(xí)慣抒钱，查找過程如圖

傳輸層（負(fù)責(zé)運輸數(shù)據(jù)）---應(yīng)用層把要傳輸?shù)臄?shù)據(jù)包裝好了以后蜓肆，就會給到下一層，也就是傳輸層谋币，傳輸層負(fù)責(zé)兩臺設(shè)備之間的數(shù)據(jù)運輸仗扬，TCP和UDP都屬于這層，這個大家應(yīng)該就很熟悉了吧蕾额，TCP就是提供可靠的字節(jié)流服務(wù)早芭。字節(jié)流服務(wù)，就是可以將大的數(shù)據(jù)分割成小的數(shù)據(jù)進(jìn)行管理傳輸诅蝶，可靠是指可以把數(shù)據(jù)準(zhǔn)確可靠的傳給對方退个。大的數(shù)據(jù)分成小塊的數(shù)據(jù)就不說了，很簡單调炬，為了提供可靠的傳輸语盈，TCP在正式傳輸數(shù)據(jù)前采用了三次捂手的策略，一保證傳輸?shù)目煽啃早峙荩挝媸诌@個也是聽了無數(shù)遍了刀荒，如圖所示:

這里再啰嗦幾句，為啥要進(jìn)行三次握手呢匀谣，看上圖照棋。如果正常情況下，第一次握手武翎，發(fā)送端給接收端發(fā)了一包數(shù)據(jù)烈炭，說明發(fā)送端已經(jīng)準(zhǔn)備就緒，第二次握手接收端給發(fā)送端回了一包數(shù)據(jù)宝恶，說明接收端是準(zhǔn)備就緒的,現(xiàn)在發(fā)送端和接受端都準(zhǔn)備就緒了符隙，完全就可以確認(rèn)雙方都在線，并且可以傳輸數(shù)據(jù)了呀垫毙，為啥還要進(jìn)行三次霹疫。因為三次握手是更嚴(yán)謹(jǐn)?shù)模紤]了異常情況的综芥，比如丽蝎，第一次握手，發(fā)送端給接收端發(fā)送了一包數(shù)據(jù)，結(jié)果恰巧網(wǎng)絡(luò)不好屠阻，等了好幾秒數(shù)據(jù)還沒到接收端红省，此時發(fā)送端放棄了，不準(zhǔn)備繼續(xù)通訊了国觉，自己去玩了吧恃，等了一分鐘，接受端收到了麻诀，然后就回了一包數(shù)據(jù)痕寓，此時第二次捂手結(jié)束，如果這時就默認(rèn)連接成功的話蝇闭，其實發(fā)送端已經(jīng)不在了呻率，白白浪費了一個接受端的資源，所以三次握手更嚴(yán)謹(jǐn)(當(dāng)然我覺得這只是盡可能的避免丁眼，還是無法百分之百避免筷凤，萬一恰巧第三次握手網(wǎng)絡(luò)不好了呢 ~ ~哈哈)

網(wǎng)絡(luò)層（負(fù)責(zé)導(dǎo)航規(guī)劃路線）--傳輸層進(jìn)行握手和傳輸數(shù)據(jù)的時候，如何找到對方的就得靠網(wǎng)絡(luò)層了苞七，?IP協(xié)議就屬于該層藐守，IP協(xié)議的作用就是規(guī)劃數(shù)據(jù)可以走哪條路到達(dá)服務(wù)器，并把數(shù)據(jù)給服務(wù)器蹂风，規(guī)劃的前提是知道服務(wù)器的IP地址和服務(wù)器的MAC地址,IP地址是指上網(wǎng)設(shè)備在網(wǎng)絡(luò)世界中被分配到的地址卢厂，MAC地址是指上網(wǎng)設(shè)備(手機、電腦)中網(wǎng)卡的編號惠啄，IP地址已經(jīng)在應(yīng)用層通過DNS服務(wù)解析出來了慎恒，現(xiàn)在就差服務(wù)器的MAC地址，有了服務(wù)器的IP地址和MAC地址以后撵渡，就可以查找到服務(wù)器了融柬。采用APR(Address Resolution Protocol)地址解析協(xié)議，就可以根據(jù)IP地址反查出電腦的MAC地址（服務(wù)器網(wǎng)卡的地址） 趋距。但是互聯(lián)網(wǎng)世界這么大粒氧，網(wǎng)線中間經(jīng)過了無數(shù)個路由器進(jìn)行連接中轉(zhuǎn)(并不是咱們家里自己用的WIFI發(fā)射信號的路由器)，所以每個路由器都只知道一部分電腦IP地址對應(yīng)的MAC地址节腐，所以根據(jù)APR協(xié)議查找MAC地址時可能需要中轉(zhuǎn)好幾次外盯，如圖

中轉(zhuǎn)幾次就找到去往服務(wù)器的路了 ~

鏈路層（中介）--這一層就是硬件層面的東西了，說白了就是讓計算機這塊塑料金屬組裝的玩意和網(wǎng)絡(luò)世界連接起來的硬件部分翼雀，比如網(wǎng)卡等饱苟。可以將網(wǎng)線傳輸過來的電信號狼渊，轉(zhuǎn)成010101的數(shù)字信號箱熬，然后就可以變成我們想要的數(shù)據(jù)。

然后用一張圖總結(jié)性的表示一下

然后再零散的說一點別的

1. 長鏈接和短鏈接。

(1) 咱們都知道聊天軟件用的都是Socket長連接城须，為啥用長連接护锤，就是因為會話頻繁，我一句你一句酿傍，可能連續(xù)聊好幾個小時，如果用短連接驱入，發(fā)一句話就斷開赤炒，就會出現(xiàn)連接->斷開->連接->斷開 ~ ~那得浪費多少資源。HTTP協(xié)議的初始版本中亏较，每進(jìn)行一次HTTP通信都要斷開一次TCP連接莺褒，斷開就意味著如果再次連接就要再次進(jìn)行三次握手，就要消耗資源雪情，比如訪問一個網(wǎng)頁遵岩，里面包含很多圖片資源，就會請求很多次巡通，同時也會重復(fù)多次斷開尘执、三次握手、斷開宴凉、三次握手誊锭。。弥锄。 為了解決上述問題丧靡，HTTP/1.1和部分HTTP/1.0添加了持久連接功能(keep-alive),持久連接的特點是，只要任意一點沒有明確提出斷開連接籽暇，則保持TCP連接狀態(tài)温治，也就是一次握手可以通信多次，那既然HTTP都支持長連接了戒悠，為啥聊天軟件用的還是scoket不用http呢熬荆，因為scoket建立長連接后可以是雙向通信的，客戶端可以給服務(wù)端發(fā)救崔，服務(wù)端也可以給客戶端發(fā)惶看，而HTTP只能是單向的，所以還得用socket(scoket是啥呢六孵，剛開始的時候說了纬黎，HTTP屬于應(yīng)該用層，TCP屬于傳輸層劫窒，咱們平時用的HTTP請求是直接操作的HTTP本今，然后HTTP去幫助咱們調(diào)用TCP，咱們沒有直接去調(diào)用TCP，Scoket可以看做是對tcp的封裝冠息，便于咱們直接調(diào)用) ~ ~是Scoket挪凑，拼寫錯誤

2 Cookie

HTTP協(xié)議是一種不保存狀態(tài)的協(xié)議，自身不對請求和響應(yīng)之間的通訊狀態(tài)進(jìn)行保存逛艰，也就是說HTTP這個級別躏碳，對于發(fā)送過的請求或響應(yīng)都不做持久化處理，每次請求響應(yīng)都是全新的都是獨立的散怖，當(dāng)初就是這么設(shè)計的(不需要記錄狀態(tài)菇绵，服務(wù)端減小CPU、內(nèi)存資源消耗)镇眷，但是隨著Web的不斷發(fā)展咬最，這種無狀態(tài)連接的弊端就展現(xiàn)出來了，比如用戶登錄到一家購物網(wǎng)站欠动，即使用戶調(diào)到該站的其他頁面永乌，也需要一直保持登錄狀態(tài)，這個時候網(wǎng)站就得需要記錄用戶的狀態(tài)具伍，判斷是誰發(fā)過來的請求翅雏，這是怎么做到的呢，明明只是在剛開始上傳了用戶名密碼人芽。為了實現(xiàn)保持狀態(tài)的功能枚荣，HTTP/1.1引入的Cookie技術(shù)，Cookie技術(shù)是通過在請求和響應(yīng)報文中寫入Cookie信息來控制客戶端的狀態(tài)啼肩，Cookie會根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)的一個叫做Set-Cookie的首部字段信息橄妆，通知客戶端保存Cookie。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請求時祈坠，客戶端會自動在請求報文中加入Cookie值后發(fā)送出去害碾，服務(wù)端發(fā)現(xiàn)客戶端發(fā)送過來的Cookie以后，會去查這是哪個客戶端發(fā)送過來的赦拘，然后得到之前的狀態(tài)信息(也就是類似在商場門口看自行車收費的慌随，我給你一個小木頭牌子，給車上掛一個木頭牌子躺同，寫著標(biāo)號阁猜，你手里的和車上的標(biāo)號相同，你等你回來把木頭牌子給我蹋艺，根據(jù)標(biāo)號我就知道哪輛自行車是你的)

3 HTTP在傳輸數(shù)據(jù)時可以在傳輸過程中通過編碼提升傳輸速率

比如我們向待發(fā)送郵件內(nèi)增加附件時剃袍，為了使郵件容量變小，我們會先用ZIP壓縮文件之后再添加附件發(fā)送捎谨。HTTP協(xié)議中有一種被稱為內(nèi)容編碼的功能也能進(jìn)行類似的操作民效。內(nèi)容編碼指明應(yīng)用在實體內(nèi)容上的編碼格式憔维，并保持實體信息原樣壓縮。內(nèi)容編碼后的實體由客戶端接收并負(fù)責(zé)解碼畏邢。但是編碼是有計算機來完成业扒，因此會消耗更多CPU等資源。常見的內(nèi)容編碼 1.gzip(GNU zip) ?2.compress(unix系統(tǒng)的標(biāo)準(zhǔn)壓縮) 3.deflate(zlib)

4. HTTP和HTTPS的區(qū)別

(1)HTTP通信使用明文(不加密)內(nèi)容可能被竊取舒萎。由于HTTP本身不具備加密功能程储，所以無法做到對通信的整體進(jìn)行加密，也就是無法對整個報文進(jìn)行加密(請求報文是由請求方法臂寝、請求URL虱肄、協(xié)議版本、可選的請求首部字段交煞、內(nèi)容實體構(gòu)成)只能對咱們自己能控制的請求的內(nèi)容實體進(jìn)行加密

(2)HTTP不驗證對方身份，數(shù)據(jù)可能會遭到竊取斟或，HTTP本身不就被校驗對方的能力素征，你只要有請求我就響應(yīng)，你只要有響應(yīng)萝挤，我就接收御毅，比如我請求了一張正常的圖片，如果這個請求唄攔截怜珍，然后偽造的服務(wù)器或給我返回一張“黃圖” ~ ~ 比如哪天訪問github,界面全是“黃圖”

在網(wǎng)絡(luò)世界中竊取一點數(shù)據(jù)時非常容易的端蛆，比如抓個包啥的，就會導(dǎo)致HTTP請求開始不安全了

上面說了兩點酥泛，第一點今豆，咱們開發(fā)人員還是可以通過別的方法進(jìn)行優(yōu)化的，雖然HTTP不能對整個通訊加密柔袁，但是我可以對我需要傳輸?shù)膮?shù)加密呆躲，比如請求參數(shù)有個{name:xiaoming},可以對"xiaoming"進(jìn)行AES或者別的加密方式加密后再傳輸，雖然不如將整個通訊的內(nèi)容都加密安全捶索，但是至少可以增加破解的難度插掂，但是第二點，確認(rèn)響應(yīng)的服務(wù)器就是自己的服務(wù)器腥例，開發(fā)人員是做不到的,無法確認(rèn)是自己的服務(wù)器辅甥，就會造成請求返回的數(shù)據(jù)，可能是一個假的服務(wù)器返回的假數(shù)據(jù)燎竖。

因為HTTP有這些不足璃弄，所以就在HTTP的基礎(chǔ)上加入了SSL(Secure Socket Layer)安全套接層來對整個通信進(jìn)行加密，HTTPS就誕生了构回，HTTPS就是身批SSH協(xié)議外殼的HTTP,所以HTTPS和HTTP的區(qū)別實際就是谢揪，HTTPS請求蕉陋，是將整個通信都加密了，也就是對整個報文進(jìn)行加密了(請求報文是由請求方法拨扶、請求URL凳鬓、協(xié)議版本、可選的請求首部字段患民、內(nèi)容實體構(gòu)成)缩举，SSL不僅提供加密處理，而且還使用了一種被稱為證書的手段用于確定對方匹颤。證書是由值得信賴的第三方機構(gòu)頒發(fā)的仅孩，并且偽造是異常困難的。（BUT也出現(xiàn)過機構(gòu)泄露證書的時間印蓖，所以加密沒有百分百安全的）辽慕。HTTPS請求會在通信前進(jìn)行證書認(rèn)證身份

然后咱們說說HTTPS是怎么規(guī)避以上兩點缺陷的

(1)首先說一下，是如何將整個通訊的數(shù)據(jù)都加密的

說之前咱們先了解一下加密方式有幾種赦肃，目前的加密方式分為對稱加密溅蛉、非對稱加密、不可逆加密

對稱加密：只有一把秘鑰他宛，就是加密和解密用的是同一個秘鑰船侧，優(yōu)點是加密時計算量小，加密速度快厅各，缺點就是密鑰容易泄露镜撩，傳遞的過程中被壞人看到、或者是人為的泄露队塘，比如AES就是對稱加密

非對稱機密袁梗，有兩把秘鑰，就是指加密的密鑰和解密的密鑰不是同一個憔古，優(yōu)點是這樣就可以放心的把加密的密鑰公開围段，解密的密鑰自己留著，缺點是加密時計算量大投放，速度慢奈泪，比如RSA

不可逆加密(hash)就是加密以后是解不了的，但是每次加密的結(jié)果是一樣的比如MD5加密灸芳。

假如咱們HTTPS用對稱加密的方式進(jìn)行加密涝桅，在客戶端請求服務(wù)器時，客戶端會生成一把對稱加密的秘鑰烙样，然后給服務(wù)器冯遂，說我之后發(fā)給你的數(shù)據(jù)都是用這個秘鑰加密的，你要用這個秘鑰解密谒获，你回應(yīng)給我的數(shù)據(jù)也要用這個秘鑰加密蛤肌，加密方式是好的壁却，因為對稱加密速度快，但是有一個弊端那就是下圖

你的秘鑰在給服務(wù)器的過程中裸准，很容易被人竊取展东，壞人知道秘鑰以后，你之后傳輸?shù)挠眠@把秘鑰加密的數(shù)據(jù)炒俱，壞人都是可以解密看到的盐肃，所以這種加密時行不通的

上述方法行不通那就嘗試一下非對稱加密的方式進(jìn)行加密，非對稱加密就是服務(wù)端生成一個公鑰一個私鑰权悟，將公鑰給客戶端砸王，客戶端發(fā)送的數(shù)據(jù)用服務(wù)端給的公鑰加密，服務(wù)器接收到數(shù)據(jù)用自己的私鑰解密峦阁，反過來一樣谦铃，客戶端也生成一對秘鑰,公鑰給服務(wù)端，私鑰自己留著

如圖所示榔昔，公鑰雖然可以被壞人看到驹闰，但是是無所謂的，之后雙方傳輸?shù)臄?shù)據(jù)都是用對方的公鑰加密件豌，想看到數(shù)據(jù)得用私鑰解密，但是私鑰都在各自手里控嗜，所以看不到茧彤，數(shù)據(jù)安全是沒問題的，但是又帶來另一個問題疆栏，就是非對稱加密曾掂，加密解密都比較慢，影響傳輸效率壁顶，所以最終HTTPS選了珠洗，對稱加密和非對稱加密結(jié)合的方式，如下圖

HTTPS采用的是對稱加密和非對稱加密都用的混合加密若专，為了傳輸效率高许蓖，在傳輸數(shù)據(jù)時用的是對稱加密，但是客戶端為了把對稱加密的key安全的傳給服務(wù)器调衰，結(jié)合了非對稱加密膊爪，服務(wù)端生成一個公鑰，一個私鑰嚎莉，給客戶端一個公鑰米酬，自己留著一個私鑰，然后客戶端拿著服務(wù)器的公鑰將自己產(chǎn)生的 "對稱加密的key" 用公鑰加密趋箩，然后傳給服務(wù)器赃额，服務(wù)器用自己的私鑰解密加派，安全的拿到key。雖然在傳輸過程中可以被壞人看到跳芳，但是傳輸?shù)氖怯霉€加密的key芍锦，但是因為不知道私鑰，解密不了筛严，拿不到對稱加密的秘鑰醉旦，所以也只能眼睜睜的看著他在眼前經(jīng)過 ~

（2）第二點HTTPS比HTTP高明的地方還有就是可以識別是不是自己的服務(wù)器，是怎么做到的呢（結(jié)合下面的圖看）

上面已經(jīng)說了桨啃，為了安全的傳輸對稱加密的秘鑰车胡，服務(wù)端會生成公鑰(1)和私鑰(1)，私鑰(1)自己留著照瘾，公鑰(1)給客戶端匈棘，但是客戶端怎么知道這個公鑰(1)就是咱們自己服務(wù)器不是冒充的，那得用到權(quán)威的證書頒發(fā)機構(gòu)(CA)析命，這個機構(gòu)必須是百分之百的安全主卫，人們必須完全信任他，在這個前提下鹃愤，服務(wù)端在給客戶端公鑰(1)之前簇搅，服務(wù)端先拿著公鑰(1)去證書頒發(fā)機構(gòu)申請證書簽名(如下圖第1步)，證書頒發(fā)機構(gòu)會用服務(wù)端給的公鑰(1)软吐，并且再加上一點別的信息瘩将，比如這個服務(wù)器的域名等信息，加上別的信息之后進(jìn)行hash運算(不可逆加密)凹耙，運算后的信息叫“信息摘要”姿现，證書頒發(fā)機構(gòu)用自己的私鑰(2)對摘要進(jìn)行加密，加密后的數(shù)據(jù)叫“數(shù)字簽名”肖抱，然后給到服務(wù)器申請人員(如下圖第2步)备典，然后服務(wù)端給客戶端公鑰(1)的時候，將證書頒發(fā)機構(gòu)生成的“數(shù)字簽名”和“公鑰(1)”一起給到客戶端(如下圖第3步),

證書頒發(fā)機構(gòu)讓手機廠家提前將自己的公鑰(2)預(yù)置到手機里(在下圖中服務(wù)器的公鑰私鑰編號為(1)意述，認(rèn)證機構(gòu)的公鑰私鑰編號為(2))提佣，當(dāng)服務(wù)端將 “公鑰(1)+數(shù)字簽名” 一起給到客戶端時，證書頒發(fā)機構(gòu)預(yù)置到手機里的公鑰(2)荤崇，會將數(shù)字簽名解密镐依，如果能解密，說明這是一個合法的天试、經(jīng)過認(rèn)證機構(gòu)加密的數(shù)據(jù)槐壳，如果是偽造的，是解密不了的喜每。然后將 "解密出來的數(shù)據(jù)(也就是上面說的信息摘要)" ?和 "服務(wù)端傳過來公鑰(1)再次加上上面所說的別的信息比如本次請求的域名务唐，進(jìn)行hash" 對比雳攘，是否一樣。如果是枫笛，則說明這個服務(wù)器就是自己的服務(wù)器吨灭。(如果一個偽造者將自己的服務(wù)器在認(rèn)證機構(gòu)申請的"數(shù)字簽名+偽造者的公鑰"給客戶端，雖然客戶端能解密刑巧，但是"解密出來的hash值" 和 "用本次請求域名+傳過來的公鑰(1)hash出來的值"是不一樣的喧兄，因為域名肯定不一樣，所以不會認(rèn)證通過啊楚，請求會終止)

5 抓包工具是怎么抓取數(shù)據(jù)的

首先了解一下“代理”吠冤，代理是一種有轉(zhuǎn)發(fā)功能的應(yīng)用程序，它扮演了位于服務(wù)器和客戶端“中間人”的角色恭理，接收由客戶端發(fā)送的請求并轉(zhuǎn)發(fā)給服務(wù)器拯辙，同時也接收服務(wù)器返回的響應(yīng)并轉(zhuǎn)發(fā)給客戶端。

抓包工具颜价，咱們都知道涯保，抓包工具，抓包前的首要配置就是要將手機的代理打開周伦，代理的地址就是電腦的IP,這樣就可以讓抓包工具充當(dāng)代理的角色夕春。

非HTTPS的抓包，咱們就不用說了专挪，因為傳輸?shù)臅r候都是未經(jīng)過加密傳輸?shù)募爸荆裕グぞ咦鳛榇肀吩椋姓埱蠛晚憫?yīng)的數(shù)據(jù)都經(jīng)過他困肩，都是可以看到的划纽，但是HTTPS請求傳輸?shù)臄?shù)據(jù)都是經(jīng)過對稱加密方式加密的脆侮，然后又不知道秘鑰，只能抓取到一堆亂碼勇劣。咱們都知道要想用抓包工具抓取HTTPS的請求靖避，咱們都得下載一個證書，并且需要在手機里信任此證書比默，那么抓包工具是為啥需要信任這個證書才能抓取到HTTPS傳輸?shù)脑紨?shù)據(jù)呢幻捏，要想看到原始數(shù)據(jù)首先要獲得對稱加密的秘鑰，因為最終傳輸數(shù)據(jù)時命咐，用的是對稱加密的秘鑰篡九，但是對稱加密的秘鑰傳輸過程中是用服務(wù)端的公鑰(1)加密過的，抓包工具沒有服務(wù)端的秘鑰(1),所以攔截到也解密不出來醋奠，那該怎么辦呢榛臼，如下圖(黑色X表示線路被截斷伊佃，藍(lán)色的步驟是比正常請求多的)

在下圖第3步，服務(wù)器給客戶端 "數(shù)字簽名+公鑰(1)" 的時候沛善，被抓包工具攔截(如圖第4步)航揉，然后給了客戶端一個自己的公鑰(3)，以及自己對公鑰(3)進(jìn)行簽名加密的數(shù)字征證書(如圖第5步)金刁，理論上來說帅涂，客戶端是會認(rèn)為抓包工具給的這些東西是不合法的，因為這不是認(rèn)證機構(gòu)給的數(shù)字證書尤蛮，內(nèi)置在手機里的認(rèn)證機構(gòu)的公鑰(2)解析不了媳友，但是手機卻當(dāng)成合法的了，為啥呢抵屿，關(guān)鍵的一步就是在這庆锦，上面咱們說了，要想 抓取HTTPS的請求轧葛，要下載一個抓包工具給的證書搂抒，并且在手機里信任該根證書，就是因為信任了這個證書尿扯，所以當(dāng)抓包工具將自己偽造的公鑰以及數(shù)字證書給到客戶端時求晶，你剛才下載并且信任的那個抓包工具的根證書站出來說，這個是合法的衷笋，所以抓包工具的公鑰和證書就被認(rèn)為是合法的放行了芳杏，驗證通過以后，繼續(xù)后面正常的流程辟宗，就是用給的"公鑰(3)"(客戶端以為是服務(wù)端的公鑰爵赵，實際上是被抓包工具掉包了，是抓包工具的)將對稱加密的秘鑰進(jìn)行加密泊脐，并且傳給到服務(wù)端(如圖紅色的第4步),給到服務(wù)器的過程中又被抓包工具攔截到如圖第6步空幻，因為是用自己的公鑰(3)加密的，自己有私鑰(3)容客，所以就可以解密秕铛，解密后拿到了對稱加密的秘鑰,走到這就基本大功告成了，但是還有最后一步缩挑，就是這個經(jīng)過加密的秘鑰不能直接轉(zhuǎn)發(fā)給服務(wù)器但两，因為服務(wù)器是解密不了的，因為不是服務(wù)器的公鑰(1)加密的供置，如果解密不了谨湘，這個請求就會終止，所以接下來就是用第4步攔截下來的公鑰(1),將自己解密出來的秘鑰進(jìn)行加密，并且轉(zhuǎn)發(fā)給服務(wù)器(圖第7步),這樣的話服務(wù)端就可以用自己的秘鑰(1)進(jìn)行解密紧阔，獲取到對稱加密的秘鑰谎僻，然后就開始進(jìn)行數(shù)據(jù)傳輸了。