HTTP和HTTPS是面試常問的問題，內(nèi)容比較多而且復(fù)雜心肪，HTTPS里面的細(xì)節(jié)很多锭亏，本文只是把主要的東西寫出來，想要弄懂HTTPS還是要多看幾篇博文硬鞍，自己動手走一遍把各個攻擊的case搞明白慧瘤。
1 HTTP
1.1 HTTP基本概念
HTTP 是超?本傳輸協(xié)議，也就是HyperText Transfer Protocol固该。
1.1.1 HTTP常見狀態(tài)碼
| 狀態(tài)碼 | 含義 | 常見狀態(tài)碼 |
|---|---|---|
| 1xx |
1xx 類狀態(tài)碼屬于提示信息锅减，是協(xié)議處理中的?種中間狀態(tài)，實際?到的?較少伐坏。 |
|
| 2xx |
2xx 類狀態(tài)碼表示服務(wù)器成功處理了客戶端的請求 |
200怔匣、204、206 |
| 3xx |
3xx 類狀態(tài)碼表示客戶端請求的資源發(fā)送了變動，需要客戶端?新的 URL 重新發(fā)送請求獲取資源每瞒，也就是重定向金闽。 |
301、302剿骨、304 |
| 4xx |
4xx 類狀態(tài)碼表示客戶端發(fā)送的報?有誤代芜，服務(wù)器?法處理，也就是錯誤碼的含義浓利。 |
400挤庇、403、404 |
| 5xx |
5xx 類狀態(tài)碼表示客戶端請求報?正確贷掖，但是服務(wù)器處理時內(nèi)部發(fā)?了錯誤嫡秕，屬于服務(wù)器端的錯誤碼。 |
500苹威、501昆咽、502 |
1.1.2 HTTP常見字段
Host 字段：客戶端發(fā)送請求時，?來指定服務(wù)器的域名屠升。 Host: www.baidu.com
Content-Length 字段 ：服務(wù)器在返回數(shù)據(jù)時潮改，會有 Content-Length 字段，表明本次回應(yīng)的數(shù)據(jù)長度腹暖。 Content-Length: 1000
Connection 字段 ：Connection 字段最常用于客戶端要求服務(wù)器使? TCP 持久連接汇在，以便其他請求復(fù)?。 HTTP/1.1 版本的默認(rèn)連接都是持久連接脏答，但為了兼容?版本的 HTTP糕殉，需要指定 Connection ?部字段的值為Keep-Alive 。
Content-Type 字段 ：Content-Type 字段?于服務(wù)器回應(yīng)時殖告，告訴客戶端阿蝶，本次數(shù)據(jù)是什么格式 。Content-Type: text/html; charset=utf-8
Content-Encoding 字段 ：Content-Encoding 字段說明數(shù)據(jù)的壓縮?法黄绩。表示服務(wù)器返回的數(shù)據(jù)使用了什么壓縮格式 羡洁。客戶端在請求時爽丹，? Accept-Encoding 字段說明自己可以接受哪些壓縮?法筑煮。 Accept-Encoding: gzip, deflate
下圖為訪問百度的返回字段
1.1.3 HTTP常見方法
| 方法 | 說明 |
|---|---|
| GET | GET方法用于使用給定的URI從給定服務(wù)器中檢索信息，即從指定資源中請求數(shù)據(jù)粤蝎。使用GET方法的請求應(yīng)該只是檢索數(shù)據(jù)真仲，并且不應(yīng)對數(shù)據(jù)產(chǎn)生其他影響。 |
| POST | POST方法用于將數(shù)據(jù)發(fā)送到服務(wù)器以創(chuàng)建或更新資源初澎，它向 URI 指定的資源提交數(shù)據(jù)秸应，數(shù)據(jù)就放在報?的 body 里。 |
| HEAD | HEAD方法與GET方法相同，但沒有響應(yīng)體软啼，僅傳輸狀態(tài)行和標(biāo)題部分桑谍。這對于恢復(fù)相應(yīng)頭部編寫的元數(shù)據(jù)非常有用，而無需傳輸整個內(nèi)容焰宣。 |
| PUT | PUT方法用于將數(shù)據(jù)發(fā)送到服務(wù)器以創(chuàng)建或更新資源霉囚，它可以用上傳的內(nèi)容替換目標(biāo)資源中的所有當(dāng)前內(nèi)容。 |
| DELETE | DELETE方法用來刪除指定的資源匕积，它會刪除URI給出的目標(biāo)資源的所有當(dāng)前內(nèi)容。 |
| CONNECT | CONNECT方法用來建立到給定URI標(biāo)識的服務(wù)器的隧道榜跌；它通過簡單的TCP / IP隧道更改請求連接闪唆，通常實使用解碼的HTTP代理來進(jìn)行SSL編碼的通信。 |
| OPTIONS | OPTIONS方法用來描述了目標(biāo)資源的通信選項钓葫，會返回服務(wù)器支持預(yù)定義URL的HTTP策略悄蕾。 |
| TRACE | TRACE方法用于沿著目標(biāo)資源的路徑執(zhí)行消息環(huán)回測試；它回應(yīng)收到的請求础浮，以便客戶可以看到中間服務(wù)器進(jìn)行了哪些（假設(shè)任何）進(jìn)度或增量帆调。 |
1.2 HTTP特性
優(yōu)點
簡單
HTTP 基本的報?格式就是 header + body ，頭部信息也是 key-value 簡單?本的形式豆同， 易于理解番刊，降低了學(xué)習(xí)和使?的?檻。-
靈活和易于擴(kuò)展
HTTP協(xié)議?的各類請求?法影锈、 URI/URL芹务、狀態(tài)碼、頭字段等每個組成要求都沒有被固定死鸭廷，都允許開發(fā)?員?定義和擴(kuò)充枣抱。同時 HTTP 由于是?作在應(yīng)?層（ OSI 第七層），則它下層可以隨意變化辆床。
HTTPS 也就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層佳晶， HTTP/3 甚?把 TCP 層換成了基于 UDP 的QUIC。
應(yīng)用廣泛和跨平臺
互聯(lián)?發(fā)展?今讼载， HTTP 的應(yīng)?范圍?常的?泛轿秧，從臺式機(jī)的瀏覽器到?機(jī)上的各種 APP，從看新聞维雇、刷貼吧到購物淤刃、理財、吃雞吱型， HTTP 的應(yīng)??地開花逸贾，同時天然具有跨平臺的優(yōu)越性。
缺點
-
無狀態(tài)
?狀態(tài)的好處，因為服務(wù)器不會去記憶 HTTP 的狀態(tài)铝侵，所以不需要額外的資源來記錄狀態(tài)信息灼伤，這能減輕服務(wù)器的負(fù)擔(dān)，能夠把更多的 CPU 和內(nèi)存?來對外提供服務(wù)咪鲜。
?狀態(tài)的壞處狐赡，既然服務(wù)器沒有記憶能?，它在完成有關(guān)聯(lián)性的操作時會?常麻煩疟丙。
解決方案Cookie：Cookie通過在請求和響應(yīng)報?中寫? Cookie 信息來控制客戶端的狀態(tài)颖侄。在客戶端第?次請求后，服務(wù)器會下發(fā)?個裝有客戶信息的「?貼紙」享郊，后續(xù)客戶端請求服務(wù)器的時候览祖，帶上「?貼紙」，服務(wù)器就能認(rèn)得了了炊琉，
明文傳輸展蒂、不安全
1.3 HTTP版本演變
1.3.1 HTTP/1.0 → HTTP/1.1
性能提升：
- 使? TCP ?連接的?式改善了 HTTP/1.0 短連接造成的性能開銷。
- ?持管道（pipeline）網(wǎng)絡(luò)傳輸苔咪，只要第?個請求發(fā)出去了锰悼，不必等其回來，就可以發(fā)第?個請求出去团赏，可以減少整體的響應(yīng)時間箕般。
HTTP/1.1 的性能瓶頸：
- 請求 / 響應(yīng)頭部未經(jīng)壓縮就發(fā)送，?部信息越多延遲越?馆里。只能壓縮
Body的部分隘世； - 發(fā)送冗?的?部。每次互相發(fā)送相同的?部造成的浪費較多鸠踪；
- 服務(wù)器是按請求的順序響應(yīng)的丙者，如果服務(wù)器響應(yīng)慢，會招致客戶端?直請求不到數(shù)據(jù)营密，也就是隊頭阻塞械媒；
- 沒有請求優(yōu)先級控制；
- 請求只能從客戶端開始评汰，服務(wù)器只能被動響應(yīng)纷捞。
1.3.2 HTTP/1.1 → HTTP/2
HTTP/2 協(xié)議是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的被去。
性能提升：
-
頭部壓縮：HTTP/2 會壓縮頭（Header）如果你同時發(fā)出多個請求主儡，他們的頭是?樣的或是相似的，那么惨缆，協(xié)議會幫你消除重復(fù)的部分糜值。
HPACK算法：在客戶端和服務(wù)器同時維護(hù)?張頭信息表丰捷，所有字段都會存?這個表，?成?個索引號寂汇，以后就不發(fā)送同樣字段了病往，只發(fā)送索引號，這樣就提?速度了骄瓣。 -
二進(jìn)制格式：HTTP/2 不再像 HTTP/1.1 ?的純?本形式的報?停巷，?是全?采?了二進(jìn)制格式，頭信息和數(shù)據(jù)體都是二進(jìn)制榕栏，并且統(tǒng)稱為幀（frame）： 頭信息幀和數(shù)據(jù)幀畔勤。
收到報?后，?需再將明?的報?轉(zhuǎn)成二進(jìn)制臼膏，?是直接解析二進(jìn)制報?硼被，這增加了數(shù)據(jù)傳輸?shù)男?/p>
-
數(shù)據(jù)流：HTTP/2 的數(shù)據(jù)包不是按順序發(fā)送的，同?個連接??連續(xù)的數(shù)據(jù)包渗磅，可能屬于不同的回應(yīng)。因此检访，必須要對數(shù)據(jù)包做標(biāo)記始鱼，指出它屬于哪個回應(yīng)。
每個請求或回應(yīng)的所有數(shù)據(jù)包脆贵，稱為?個數(shù)據(jù)流（ Stream ）医清。每個數(shù)據(jù)流都標(biāo)記著?個獨一無二的編號，其中規(guī)定客戶端發(fā)出的數(shù)據(jù)流編號為奇數(shù)卖氨， 服務(wù)器發(fā)出的數(shù)據(jù)流編號為偶數(shù)会烙。
客戶端還可以指定數(shù)據(jù)流的優(yōu)先級。優(yōu)先級?的請求筒捺，服務(wù)器就先響應(yīng)該請求柏腻。
多路復(fù)用：HTTP/2 是可以在
?個連接中并發(fā)多個請求或回應(yīng)，?不用按照順序??對應(yīng)系吭。移除了 HTTP/1.1 中的串行請求五嫂，不需要排隊等待，也就不會再出現(xiàn)「隊頭阻塞」問題肯尺，降低了延遲沃缘，?幅度提?了連接的利用率。服務(wù)器推送：HTTP/2 還在?定程度上改善了傳統(tǒng)的「請求 - 應(yīng)答」工作模式则吟，服務(wù)不再是被動地響應(yīng)槐臀，也可以主動向客戶端發(fā)送消息。
1.3.3 HTTP/2 → HTTP/3
HTTP/2 主要的問題在于氓仲，多個 HTTP 請求在復(fù)??個 TCP 連接水慨，下層的 TCP 協(xié)議是不知道有多少個 HTTP 請求的得糜。所以?旦發(fā)?了丟包現(xiàn)象，就會觸發(fā) TCP 的重傳機(jī)制讥巡，這樣在?個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來掀亩。
- HTTP/1.1 中的管道（ pipeline）傳輸中如果有?個請求阻塞了，那么隊列后請求也統(tǒng)統(tǒng)被阻塞住了欢顷。
- HTTP/2 多個請求復(fù)??個TCP連接槽棍，?旦發(fā)生丟包，就會阻塞住所有的 HTTP 請求抬驴。
這都是基于 TCP 傳輸層的問題炼七，所以 HTTP/3 把 HTTP 下層的 TCP 協(xié)議改成了 UDP。
UDP 發(fā)生是不管順序布持，也不管丟包的豌拙，所以不會出現(xiàn) HTTP/1.1 的隊頭阻塞 和 HTTP/2 的?個丟包全部重傳問題。
UDP 是不可靠傳輸?shù)奶馀?UDP 的 QUIC 協(xié)議 可以實現(xiàn)類似 TCP 的可靠性傳輸按傅。
- QUIC 有??的?套機(jī)制可以保證傳輸?shù)目煽啃缘摹?code>當(dāng)某個流發(fā)生丟包時，只會阻塞這個流胧卤， 其他流不會受到影響唯绍。
- TLS3 升級成了最新的 1.3 版本，頭部壓縮算法也升級成了 QPack 枝誊。
- HTTPS 要建立?個連接况芒，要花費 6 次交互，先是建?三次握?叶撒，然后是 TLS/1.3 的三次握?绝骚。 QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，減少了交互次數(shù)
1.3.4 HTTP各版本層次圖
2 HTTPS
2.1 HTTP 與 HTTPS 的區(qū)別
- HTTP 是超?本傳輸協(xié)議祠够，信息是明?傳輸压汪，存在安全風(fēng)險的問題。
HTTPS 則解決 HTTP 不安全的缺陷哪审，在TCP 和 HTTP 網(wǎng)絡(luò)層之間加?了 SSL/TLS 安全協(xié)議蛾魄，使得報?能夠加密傳輸。 - HTTP 連接建?相對簡單湿滓， TCP 三次握?之后便可進(jìn)? HTTP 的報?傳輸滴须。
而HTTPS 在 TCP 三次握?之后，還需進(jìn)? SSL/TLS 的握?過程叽奥，才可進(jìn)?加密報?傳輸扔水。 - HTTP 的端口號是 80， HTTPS 的端口號是 443朝氓。
- HTTPS 協(xié)議需要向 CA（證書權(quán)威機(jī)構(gòu)）申請數(shù)字證書魔市，來保證服務(wù)器的身份是可信的主届。
2.2 HTTPS安全性實現(xiàn)
混合加密
HTTPS 采?的是對稱加密和?對稱加密結(jié)合的「混合加密」?式：
- 在通信建?前采用?對稱加密的?式交換「會話秘鑰」，后續(xù)就不再使??對稱加密待德。
- 在通信過程中全部使用對稱加密的「會話秘鑰」的?式加密明?數(shù)據(jù)君丁。
采?「混合加密」的?式的原因：
- 對稱加密只使??個密鑰，運算速度快将宪，密鑰必須保密绘闷，無法做到安全的密鑰交換。
- 非對稱加密使用兩個密鑰：公鑰和私鑰较坛，公鑰可以任意分發(fā)?私鑰保密印蔗，解決了密鑰交換問題但速度慢。
摘要算法
摘要算法?來實現(xiàn)完整性丑勤，能夠為數(shù)據(jù)?成獨???的「指紋」华嘹，?于校驗數(shù)據(jù)的完整性，解決了篡改的?險法竞。
客戶端在發(fā)送明?之前會通過摘要算法算出明文的「指紋」耙厚，發(fā)送的時候把「指紋 + 明文」?同加密成密文后，發(fā)送給服務(wù)器岔霸，服務(wù)器解密后颜曾，用相同的摘要算法算出發(fā)送過來的明文，通過?較客戶端攜帶的「指紋」和當(dāng)前算出的「指紋」做?較秉剑，若「指紋」相同，說明數(shù)據(jù)是完整的稠诲。
數(shù)字證書
客戶端先向服務(wù)器端索要公鑰侦鹏，然后?公鑰加密信息，服務(wù)器收到密文后臀叙，???的私鑰解密略水。這就存在些問題，如何保證公鑰不被篡改和信任度劝萤？
所以這?就需要借助第三?權(quán)威機(jī)構(gòu) CA （數(shù)字證書認(rèn)證機(jī)構(gòu)）渊涝，將服務(wù)器公鑰放在數(shù)字證書（由數(shù)字證書認(rèn)證機(jī)構(gòu)頒發(fā)）中，只要證書是可信的床嫌，公鑰就是可信的跨释。
通過數(shù)字證書的?式保證服務(wù)器公鑰的身份，解決冒充的?險 厌处。
證書簽名和驗證過程：
公鑰加密私鑰解密鳖谈，私鑰加密公鑰解密。
CA公鑰已經(jīng)事先置入到了瀏覽器或者操作系統(tǒng)里阔涉。
| 步驟 | 服務(wù)端 | CA | 客戶端 |
|---|---|---|---|
| 1 | 服務(wù)器把自己的公鑰注冊到CA
|
||
| 2 |
CA用自己的私鑰將服務(wù)器的公鑰和域名的其他信息加密成證書并頒發(fā)給服務(wù)器 |
||
| 3 | 客戶端發(fā)起網(wǎng)絡(luò)請求 | ||
| 4 | 客戶端拿到服務(wù)器的數(shù)字證書后使用CA公鑰解密缆娃，確認(rèn)服務(wù)器數(shù)字證書的真實性 |
||
| 5 | 從數(shù)字證書獲取服務(wù)器公鑰后捷绒，使用服務(wù)器公鑰對報文加密傳輸 |
兩種情況：
如果數(shù)字證書被其他人篡改，
由于加密數(shù)據(jù)不是CA私鑰加密而來贯要，所以無法解密成功暖侨。-
如果攻擊者知道A.com使用的是某家CA機(jī)構(gòu)的證書，那么他也去這家CA機(jī)構(gòu)申請一個合法的證書崇渗，然后在瀏覽器請求A.com時對返回的加密證書數(shù)據(jù)進(jìn)行替換字逗。
由于攻擊者申請的證書也是由正規(guī)CA機(jī)構(gòu)制作的，因此這段加密數(shù)據(jù)可以成功被解密显押。但CA機(jī)構(gòu)在制作的證書時除了網(wǎng)站的公鑰外扳肛，還要包含許多其他數(shù)據(jù)，用來輔助進(jìn)行校驗乘碑，比如說網(wǎng)站的域名挖息。如果域名對不上依然檢驗失敗。
2.3 HTTPS建立連接過程
