建站
咨詢
售后
建站咨詢
新聞中心
我們前面說(shuō)過(guò)了 CDN的知識(shí)，也通過(guò)抓包分析了 TCP建立鏈接的過(guò)程。今天一起聊一聊應(yīng)用層的協(xié)議 HTTP/HTTPS;這是應(yīng)用工程師日常中接觸最久的協(xié)議了。但是你真的了解他嗎?
創(chuàng)新互聯(lián)建站是一家專注網(wǎng)站建設(shè)、網(wǎng)絡(luò)營(yíng)銷(xiāo)策劃、微信小程序定制開(kāi)發(fā)、電子商務(wù)建設(shè)、網(wǎng)絡(luò)推廣、移動(dòng)互聯(lián)開(kāi)發(fā)、研究、服務(wù)為一體的技術(shù)型公司。公司成立10余年以來(lái)，已經(jīng)為上1000家水泥攪拌車(chē)各業(yè)的企業(yè)公司提供互聯(lián)網(wǎng)服務(wù)?，F(xiàn)在，服務(wù)的上1000家客戶與我們一路同行，見(jiàn)證我們的成長(zhǎng)；未來(lái)，我們一起分享成功的喜悅。
今天我們不講 HTTP協(xié)議 的幾種請(qǐng)求方式，主要介紹HTTP及HTTPS整個(gè)發(fā)送數(shù)據(jù)的過(guò)程。
消息結(jié)構(gòu)
還記得前面講的 DNS 的過(guò)程嗎?通過(guò)DNS我們拿到了服務(wù)端的IP地址，然后通過(guò)TCP協(xié)議，完成了瀏覽器與應(yīng)用服務(wù)器的連接建立。HTTP協(xié)議是建立在TCP協(xié)議之上的(上層協(xié)議必然依賴下層協(xié)議)，連接建立后，自然是開(kāi)始通信。那么通信的格式是什么呢?
看上面這張圖，HTTP的請(qǐng)求與響應(yīng)格式基本如此。我們分開(kāi)來(lái)說(shuō)。
對(duì)于 請(qǐng)求消息 ，由三部分構(gòu)成：請(qǐng)求行、請(qǐng)求頭、請(qǐng)求的Body;所謂的請(qǐng)求行，就是：POST / HTTP/1.1 這部分內(nèi)容。接下來(lái)的就是請(qǐng)求頭，也就是我們常說(shuō)的HTTP頭;然后換行后緊接著的內(nèi)容就是請(qǐng)求的Body，也就是正兒八經(jīng)發(fā)送給應(yīng)用的參數(shù)。
對(duì)于 響應(yīng)消息 ，也是由三部分構(gòu)成：狀態(tài)行、響應(yīng)頭、響應(yīng)的Body;關(guān)于響應(yīng)行就是標(biāo)記本次請(qǐng)求獲得的結(jié)果是什么，這里主要有：20X、30X、40X、50X這幾個(gè)范圍的狀態(tài)碼，需要熟記。響應(yīng)頭里邊重要的主要有跟緩存相關(guān)的東西，這部分內(nèi)容會(huì)知道瀏覽器、CDN等緩存體的緩存行為，需要有一定的了解;最后的實(shí)體就是你請(qǐng)求的想要的結(jié)構(gòu)，比如：HTML、Json等等。
傳輸過(guò)程
消息構(gòu)建后，如何發(fā)送進(jìn)行傳輸呢?我們上面圖片中看到的是字符串內(nèi)容，HTTP本身是不能進(jìn)行網(wǎng)絡(luò)傳輸?shù)模仨氁蕾嚨牡讓拥腡CP協(xié)議建立的連接來(lái)發(fā)送數(shù)據(jù)。因此它實(shí)際上就是把這些構(gòu)建好的字符串傳給下層的TCP，至于TCP如何傳輸?shù)目梢钥瓷掀恼?，這里不展開(kāi)了。
WebService 收到數(shù)據(jù)后會(huì)對(duì)數(shù)據(jù)進(jìn)行處理然后交給應(yīng)用服務(wù)器，應(yīng)用服務(wù)器自然是將請(qǐng)求的Body作為輸入，然后根據(jù)要求產(chǎn)生輸出。輸出的行為受到請(qǐng)求頭中部分信息的控制，比如：格式(Content-Type)、編碼(Accept-Charset)等。而產(chǎn)生的輸出各個(gè)地方也會(huì)根據(jù)響應(yīng)頭進(jìn)行處理。
看到這里大家有沒(méi)有發(fā)現(xiàn)幾個(gè)問(wèn)題：HTTP依賴底層的TCP連接，也就是每個(gè)HTTP都需要進(jìn)行三次握手，效率是不是會(huì)非常慢?這種方式總需要瀏覽器端主動(dòng)發(fā)起鏈接，服務(wù)端想主動(dòng)推送些什么很無(wú)能為力;
針對(duì)上面這些問(wèn)題，HTTP2.0 協(xié)議也就誕生了，當(dāng)然上面這些問(wèn)題在 HTTP1.1 時(shí)代也有些解決方案。HTTP2.0 主要解決了協(xié)議頭進(jìn)行壓縮，傳輸同樣含義的內(nèi)容，占用帶寬更少速度更快;將上面的單向鏈接的方式改成二進(jìn)制流的方式，服務(wù)端有能力主動(dòng)推送數(shù)據(jù);一個(gè)鏈接里邊支持傳輸多種數(shù)據(jù)流。
關(guān)于 HTTP2.0 的內(nèi)容不是文本主要想說(shuō)的，大家可以自行了解下。接下來(lái)又到了 核心部分，關(guān)于 HTTPS 為什么安全、以及如何加密的解釋。這部分內(nèi)容算是面試的重要考點(diǎn)。
HTTPS為什么可靠
現(xiàn)在大網(wǎng)站基本都適用了HTTPS協(xié)議，那么它跟HTTP是什么關(guān)系呢?它其實(shí)就是HTTP加上TLS(SSL)安全層，合在一起就叫 HTTPS。為什么有了這層處理數(shù)據(jù)就安全了呢?
很簡(jiǎn)單，要想安全就得加密。加密的方式現(xiàn)在無(wú)非就是：對(duì)稱加密 與 非對(duì)稱加密。
對(duì)稱加密： 加密與解密都是使用相同的密鑰，因此這種方式加密數(shù)據(jù)，密鑰一定不能丟失。
非對(duì)稱加密： 有兩把密鑰，私鑰與公鑰。使用私鑰加密的數(shù)據(jù)必須使用公鑰進(jìn)行解密，反之依然。
安全的代價(jià)
看起來(lái) 非對(duì)稱加密 非常安全。不過(guò)對(duì)稱加密的效率非常高。HTTPS正是綜合使用這兩種加密方式，讓整個(gè)傳輸過(guò)程變得安全。接下來(lái)看看這個(gè)過(guò)程是如何完成的。
對(duì)稱加密
我們先來(lái)看看，如果HTTPS只使用 對(duì)稱加密，能否滿足安全的需要呢?由于這種情況只有一個(gè)密鑰，服務(wù)端怎么把這個(gè)密鑰交給客戶端呢?線上傳輸肯定會(huì)泄漏。
所以單單有對(duì)稱加密是不能滿足需求?？磥?lái)得換個(gè)路子。
非對(duì)稱加密
使用非對(duì)稱加密的私鑰加密數(shù)據(jù)，發(fā)給客戶端?？蛻舳擞霉€解密就得到了數(shù)據(jù)?？雌饋?lái)好像沒(méi)有什么問(wèn)題。
但是這里有個(gè)問(wèn)題，由于服務(wù)端發(fā)出來(lái)的數(shù)據(jù)是使用的私鑰，由于公鑰是公開(kāi)，這相當(dāng)于沒(méi)有加密。大家都能夠看到。并且服務(wù)端發(fā)出去的公鑰這個(gè)過(guò)程也可能被串改啊，你怎么知道你收到的公鑰就是服務(wù)器給你的呢?就跟現(xiàn)在很多詐騙公司一樣，看起來(lái)有模有樣，實(shí)則就是一皮包公司。
第三方公正
為了解決上述問(wèn)題，出現(xiàn)了一個(gè)所謂的 CA 機(jī)構(gòu)，它怎么解決這個(gè)信任問(wèn)題呢?它將服務(wù)器的公鑰放到 CA證書(shū) 里邊傳給客戶端(這里指瀏覽器)，瀏覽器拿到后驗(yàn)證一下這個(gè)證書(shū)是否真實(shí)有效，因?yàn)镃A機(jī)構(gòu)是有限可追溯的。就跟你的護(hù)照一樣，可辨別真?zhèn)?，所以CA證書(shū)證明了有效，那么CA證書(shū)中攜帶的公鑰自然也證明了自己的身份。
是不是看起來(lái)整個(gè)過(guò)程非常麻煩?沒(méi)有辦法為了安全，這點(diǎn)代價(jià)非常值得。這也是為什么我們常常說(shuō)HTTPS的效率略低于HTTP的原因。
工作模式
了解完上面的知識(shí)，我們來(lái)看看HTTPS到底是如何工作的?
客戶端發(fā)起了一個(gè)https請(qǐng)求，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機(jī)數(shù)random_c，擴(kuò)展字段等信息。這個(gè)過(guò)程此時(shí)是明文的。
然后服務(wù)器會(huì)進(jìn)行回復(fù)，根據(jù)客戶端支持的算法信息、套件等，服務(wù)器選擇一個(gè)告訴客戶端，我們就用這個(gè)吧，同時(shí)也會(huì)返回一個(gè)隨機(jī)數(shù)random_s，后面協(xié)商密鑰有用。
服務(wù)端響應(yīng)客戶端，這個(gè)響應(yīng)中包含了證書(shū)的鏈接，用于交換密鑰。
客戶端對(duì)收到的數(shù)據(jù)進(jìn)行檢查，先把證書(shū)給拉下來(lái)，然后檢查各種指標(biāo)，如果不合法，會(huì)看到瀏覽器提醒不安全。
如果驗(yàn)證通過(guò)，就會(huì)生成一個(gè) 隨機(jī)數(shù)字 Pre-master，并用證書(shū)公鑰加密(非對(duì)稱加密)，發(fā)送給服務(wù)器。
此時(shí)的客戶端已經(jīng)有了生成證書(shū)的全部?jī)?nèi)容，它會(huì)計(jì)算協(xié)商的密鑰(對(duì)稱密鑰)，然后告訴服務(wù)端以后通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信。緊接著會(huì)用協(xié)商的密鑰加密一段數(shù)據(jù)發(fā)給服務(wù)端，看看是否能夠正常。
上面這步里邊，客戶端發(fā)送了三個(gè)請(qǐng)求。服務(wù)器先將收到的 Pre-master 用自己的私鑰解密出來(lái)。然后驗(yàn)證客戶端用對(duì)稱加密發(fā)過(guò)來(lái)的數(shù)據(jù)，如果通過(guò)，則也會(huì)告知客戶端后續(xù)的通信都采用協(xié)商的密鑰與算法進(jìn)行加密通信。
并且服務(wù)端也會(huì)用對(duì)稱加密生成一段加密信息給客戶端讓客戶端試試(對(duì)稱密鑰)。
客戶端使用對(duì)稱密鑰正確完成解密。握手結(jié)束。開(kāi)始使用對(duì)稱密鑰的方式進(jìn)行數(shù)據(jù)傳輸。
總結(jié)
由于不讓文章顯得過(guò)于復(fù)雜，我只介紹了最簡(jiǎn)單的單向認(rèn)證。這種安全性并不是最高，單日常中也足夠了。
本文從源頭講了為什么只有對(duì)稱加密搞不定這件事;一步步演化出HTTPS的整個(gè)過(guò)程。
首先，為了效率，整個(gè)過(guò)程只采用了一次非對(duì)稱加密來(lái)加密 Pre-master;
其次，客戶端、服務(wù)端分別使用了一次對(duì)稱加密來(lái)進(jìn)行密鑰有效性的驗(yàn)證，來(lái)防止中間人攻擊;
最后，也說(shuō)了為什么整個(gè)過(guò)程需要CA機(jī)構(gòu)的參與。
本文標(biāo)題：你需要知道，高并發(fā)架構(gòu)下的HTTP
當(dāng)前地址：http://m.5511xx.com/article/dpdecii.html
