郊用芪帐峙c性能優(yōu)化)
1. 從“明文快遞”到“武裝押運(yùn)”HTTP與HTTPS的本質(zhì)透視干了這么多年開發(fā)每次面試新人或者和同行聊起網(wǎng)絡(luò)基礎(chǔ)HTTP和HTTPS這對(duì)“兄弟”總是繞不開的話題。表面上看就是一個(gè)“S”的差別但背后牽扯到的安全、性能、協(xié)議棧乃至整個(gè)互聯(lián)網(wǎng)的信任體系水可深了。很多人背了一堆“HTTP不安全、HTTPS安全”、“端口80和443”的面試八股但被問(wèn)到“為什么安全”、“具體怎么實(shí)現(xiàn)的”時(shí)往往就卡殼了。今天我就結(jié)合自己踩過(guò)的坑和實(shí)際項(xiàng)目中的經(jīng)驗(yàn)把這哥倆從里到外掰開揉碎了講清楚讓你不僅能在面試中對(duì)答如流更能真正理解它們?cè)谀銓懙拿恳恍写a、設(shè)計(jì)的每一個(gè)系統(tǒng)里扮演的角色。簡(jiǎn)單來(lái)說(shuō)你可以把HTTP想象成在熙熙攘攘的集市上用大喇叭喊話傳遞明信片。你說(shuō)的話請(qǐng)求、對(duì)方回的話響應(yīng)還有明信片上的內(nèi)容數(shù)據(jù)所有路過(guò)的人都能聽見、看見甚至能篡改、冒充。這就是HTTP超文本傳輸協(xié)議它簡(jiǎn)單、高效但毫無(wú)隱私和安全性可言。而HTTPS則像是為這條通信線路雇傭了頂尖的安保公司——它給整個(gè)對(duì)話過(guò)程加了一個(gè)堅(jiān)固的保險(xiǎn)箱加密并且由權(quán)威機(jī)構(gòu)CA給這個(gè)保險(xiǎn)箱和通信雙方都簽發(fā)了無(wú)法偽造的“身份證”數(shù)字證書。從此你們的對(duì)話變成了加密的密文只有持有正確鑰匙的雙方才能解密閱讀中間人既看不懂也改不了。這個(gè)“S”代表的就是“Secure”安全它的核心是在HTTP之下、TCP之上加入了一個(gè)SSL/TLS協(xié)議層專門負(fù)責(zé)加密和身份認(rèn)證。這篇文章我會(huì)帶你深入這個(gè)“保險(xiǎn)箱”內(nèi)部看看加密和證書到底是怎么工作的對(duì)比兩者在握手、性能、使用場(chǎng)景上的具體差異并整理出那些真正高頻、能考察出你理解深度的面試題和實(shí)戰(zhàn)要點(diǎn)。無(wú)論你是前端、后端、運(yùn)維還是安全工程師這些內(nèi)容都是你技術(shù)棧里不可或缺的基石。2. HTTP協(xié)議簡(jiǎn)單高效的“明文信使”2.1 核心工作原理與報(bào)文結(jié)構(gòu)HTTP是一個(gè)無(wú)狀態(tài)的、應(yīng)用層的協(xié)議它建立在可靠的TCP連接之上。它的工作模式極其經(jīng)典請(qǐng)求-響應(yīng)Request-Response。客戶端通常是瀏覽器發(fā)起一個(gè)請(qǐng)求到服務(wù)器服務(wù)器處理后再返回一個(gè)響應(yīng)。這個(gè)模型簡(jiǎn)單直觀也是它能夠快速普及的原因之一。一個(gè)完整的HTTP報(bào)文無(wú)論是請(qǐng)求還是響應(yīng)都包含三部分起始行Start Line對(duì)于請(qǐng)求它包含方法Method、URL和HTTP版本對(duì)于響應(yīng)它包含HTTP版本、狀態(tài)碼Status Code和原因短語(yǔ)Reason Phrase。頭部字段Headers一系列鍵值對(duì)傳遞關(guān)于報(bào)文或主體的元信息比如內(nèi)容類型Content-Type、內(nèi)容長(zhǎng)度Content-Length、緩存控制Cache-Control等。頭部和主體之間用一個(gè)空行分隔。消息主體Body可選部分承載實(shí)際傳輸?shù)臄?shù)據(jù)比如POST請(qǐng)求提交的表單數(shù)據(jù)或者服務(wù)器返回的HTML、JSON數(shù)據(jù)。這里我重點(diǎn)說(shuō)一下方法和狀態(tài)碼因?yàn)檫@是日常開發(fā)和調(diào)試中最常打交道的。HTTP方法Method定義了客戶端希望服務(wù)器對(duì)資源執(zhí)行的操作GET獲取資源。應(yīng)該是冪等的多次執(zhí)行結(jié)果相同且不應(yīng)有副作用不修改服務(wù)器數(shù)據(jù)。這是最常用的方法。POST提交數(shù)據(jù)通常用于創(chuàng)建新資源或觸發(fā)一個(gè)處理數(shù)據(jù)的操作。非冪等。PUT替換整個(gè)資源。冪等。DELETE刪除指定資源。冪等。PATCH對(duì)資源進(jìn)行部分修改。非冪等。HEAD只獲取資源的頭部信息不返回主體。常用于檢查資源是否存在或是否被修改。OPTIONS獲取目標(biāo)資源支持的通信選項(xiàng)。在CORS跨域資源共享預(yù)檢請(qǐng)求中扮演關(guān)鍵角色。HTTP狀態(tài)碼是一個(gè)三位數(shù)字服務(wù)器用它來(lái)告訴客戶端請(qǐng)求的結(jié)果。它被分為五類1xx信息性請(qǐng)求已接收繼續(xù)處理。如101協(xié)議切換。2xx成功請(qǐng)求已成功被服務(wù)器接收、理解、并接受。最熟悉的就是200 OK。3xx重定向需要客戶端采取進(jìn)一步的操作以完成請(qǐng)求。例如301 Moved Permanently永久重定向、302 Found臨時(shí)重定向但注意瀏覽器通常按303處理、304 Not Modified資源未修改使用緩存。4xx客戶端錯(cuò)誤請(qǐng)求包含語(yǔ)法錯(cuò)誤或無(wú)法完成。404 Not Found資源不存在和400 Bad Request錯(cuò)誤請(qǐng)求是最常見的。401 Unauthorized表示需要身份驗(yàn)證而403 Forbidden是服務(wù)器理解請(qǐng)求但拒絕執(zhí)行。5xx服務(wù)器錯(cuò)誤服務(wù)器在處理請(qǐng)求的過(guò)程中發(fā)生了錯(cuò)誤。500 Internal Server Error內(nèi)部服務(wù)器錯(cuò)誤和502 Bad Gateway壞網(wǎng)關(guān)、503 Service Unavailable服務(wù)不可用是運(yùn)維同學(xué)的“噩夢(mèng)”。實(shí)操心得很多人分不清401和403。簡(jiǎn)單記401是“你是誰(shuí)請(qǐng)先登錄”缺少或無(wú)效的身份憑證403是“我知道你是誰(shuí)但你不配訪問(wèn)這個(gè)”身份有效但權(quán)限不足。調(diào)試API時(shí)看清狀態(tài)碼能幫你快速定位問(wèn)題是出在客戶端參數(shù)4xx還是服務(wù)器內(nèi)部5xx。2.2 連接管理與性能演進(jìn)早期的HTTP/1.0版本非常簡(jiǎn)單每次請(qǐng)求都需要建立一次TCP連接收到響應(yīng)后立即斷開。這種“短連接”模式對(duì)于早期簡(jiǎn)單的網(wǎng)頁(yè)文字少量圖片還行但現(xiàn)代網(wǎng)頁(yè)包含幾十甚至上百個(gè)資源CSS、JS、圖片反復(fù)建立斷開TCP連接的成本三次握手、四次揮手就太高了。于是HTTP/1.1引入了持久連接Persistent Connection也稱為連接復(fù)用。通過(guò)在請(qǐng)求頭中設(shè)置Connection: keep-aliveHTTP/1.1默認(rèn)可以在一個(gè)TCP連接上順序發(fā)送多個(gè)請(qǐng)求和接收多個(gè)響應(yīng)。這大大減少了延遲和系統(tǒng)開銷。但是HTTP/1.1的持久連接有一個(gè)致命問(wèn)題隊(duì)頭阻塞Head-of-Line Blocking。雖然連接可以復(fù)用但同一時(shí)間只能處理一個(gè)請(qǐng)求-響應(yīng)事務(wù)。如果第一個(gè)請(qǐng)求的響應(yīng)很慢比如一個(gè)大圖片后面的所有請(qǐng)求都會(huì)被阻塞即使它們需要的資源已經(jīng)準(zhǔn)備好了。為了緩解這個(gè)問(wèn)題瀏覽器通常會(huì)與同一個(gè)域名建立多個(gè)通常是6個(gè)并行連接但這又增加了服務(wù)器的負(fù)擔(dān)和連接管理的復(fù)雜性。HTTP/1.1時(shí)代的另一個(gè)重要優(yōu)化是管道化Pipelining它允許客戶端在同一個(gè)連接上連續(xù)發(fā)送多個(gè)請(qǐng)求而不必等待響應(yīng)。然而由于實(shí)現(xiàn)復(fù)雜且隊(duì)頭阻塞問(wèn)題依然存在響應(yīng)必須按請(qǐng)求順序返回它并未被廣泛支持現(xiàn)代瀏覽器默認(rèn)都是關(guān)閉的。注意事項(xiàng)在設(shè)計(jì)和調(diào)試后端服務(wù)時(shí)要特別注意HTTP/1.1的隊(duì)頭阻塞問(wèn)題。如果一個(gè)慢查詢接口或一個(gè)耗時(shí)的文件下載操作可能會(huì)阻塞同一連接上其他用戶或接口的請(qǐng)求。合理的連接超時(shí)、請(qǐng)求超時(shí)設(shè)置以及將耗時(shí)任務(wù)異步化是常見的解決方案。2.3 無(wú)狀態(tài)與有狀態(tài)管理的博弈HTTP協(xié)議本身是**無(wú)狀態(tài)Stateless**的。這意味著服務(wù)器不會(huì)在兩個(gè)請(qǐng)求之間記住任何客戶端信息。每個(gè)請(qǐng)求都是獨(dú)立的就像失憶的服務(wù)器每次見面都問(wèn)“你是誰(shuí)”。這對(duì)于服務(wù)器集群的擴(kuò)展性是好事任何服務(wù)器都能處理任何請(qǐng)求但對(duì)于需要“登錄狀態(tài)”、“購(gòu)物車”這樣的Web應(yīng)用來(lái)說(shuō)就是災(zāi)難。因此實(shí)踐中我們使用各種技術(shù)來(lái)“制造”狀態(tài)最主要的就是Cookie和Session。Cookie由服務(wù)器通過(guò)響應(yīng)頭Set-Cookie發(fā)送給瀏覽器的一小段數(shù)據(jù)。瀏覽器會(huì)保存它并在后續(xù)對(duì)同一服務(wù)器的請(qǐng)求中通過(guò)Cookie請(qǐng)求頭自動(dòng)攜帶回去。Cookie通常用于存儲(chǔ)會(huì)話標(biāo)識(shí)符Session ID、用戶偏好等。Session服務(wù)器端的一種機(jī)制用于存儲(chǔ)特定用戶會(huì)話的數(shù)據(jù)。服務(wù)器為每個(gè)會(huì)話創(chuàng)建一個(gè)唯一的Session ID并通過(guò)Cookie或URL重寫傳遞給客戶端。客戶端后續(xù)請(qǐng)求攜帶這個(gè)ID服務(wù)器就能找到對(duì)應(yīng)的會(huì)話數(shù)據(jù)。Cookie vs. Session 核心區(qū)別存儲(chǔ)位置Cookie存儲(chǔ)在客戶端瀏覽器Session數(shù)據(jù)存儲(chǔ)在服務(wù)器端內(nèi)存、數(shù)據(jù)庫(kù)、Redis等。安全性Cookie在客戶端可能被竊取或篡改雖然可以設(shè)置HttpOnly和Secure屬性來(lái)增強(qiáng)安全因此敏感信息如密碼絕不應(yīng)放在Cookie中。Session ID本身雖然也可能被竊取會(huì)話劫持但敏感數(shù)據(jù)在服務(wù)器端相對(duì)安全。性能與擴(kuò)展性Cookie數(shù)據(jù)每次請(qǐng)求都會(huì)攜帶增加帶寬消耗。Session數(shù)據(jù)在服務(wù)器端對(duì)服務(wù)器內(nèi)存或存儲(chǔ)有壓力在分布式環(huán)境下需要共享Session方案如用Redis集群。常見問(wèn)題排查“用戶登錄后跳轉(zhuǎn)個(gè)頁(yè)面又變未登錄了” 十有八九是Session或Cookie出了問(wèn)題。檢查點(diǎn)1. Session過(guò)期時(shí)間設(shè)置是否太短2. 分布式環(huán)境下請(qǐng)求是否被負(fù)載均衡到了沒有對(duì)應(yīng)Session數(shù)據(jù)的服務(wù)器3. Cookie的Domain和Path設(shè)置是否正確是否被瀏覽器攔截4. 是否使用了HttpOnly和Secure的Cookie但在非HTTPS環(huán)境下訪問(wèn)3. HTTPS為HTTP穿上“加密鎧甲”3.1 SSL/TLS協(xié)議層安全的基石HTTPS不是一個(gè)新的協(xié)議而是HTTP over SSL/TLS。你可以理解為在HTTP和TCP之間插入了一個(gè)安全套接字層SSL或其繼任者傳輸層安全TLS協(xié)議。當(dāng)前廣泛使用的是TLS 1.2和TLS 1.3。這個(gè)協(xié)議層主要解決了三個(gè)核心問(wèn)題機(jī)密性Confidentiality通過(guò)加密算法確保傳輸?shù)臄?shù)據(jù)無(wú)法被第三方竊聽。完整性Integrity通過(guò)消息認(rèn)證碼MAC確保數(shù)據(jù)在傳輸過(guò)程中未被篡改。身份認(rèn)證Authentication通過(guò)數(shù)字證書確保你正在通信的服務(wù)器就是它聲稱的那個(gè)而不是中間人偽裝的。3.2 核心加密機(jī)制混合加密的智慧HTTPS的加密并非使用單一的一種算法而是巧妙地結(jié)合了非對(duì)稱加密和對(duì)稱加密取長(zhǎng)補(bǔ)短。非對(duì)稱加密Asymmetric Encryption有一對(duì)密鑰公鑰Public Key和私鑰Private Key。公鑰可以公開給任何人用于加密數(shù)據(jù)私鑰必須嚴(yán)格保密用于解密用對(duì)應(yīng)公鑰加密的數(shù)據(jù)。反之用私鑰加密簽名的數(shù)據(jù)可以用公鑰驗(yàn)證。它的特點(diǎn)是安全性高但計(jì)算非常緩慢。RSA和ECC橢圓曲線是常見的非對(duì)稱加密算法。對(duì)稱加密Symmetric Encryption加密和解密使用同一把密鑰。它的特點(diǎn)是計(jì)算速度快適合加密大量數(shù)據(jù)。AES是當(dāng)前最主流、最安全的對(duì)稱加密算法。HTTPS的握手過(guò)程核心目的之一就是安全地協(xié)商出一個(gè)只有客戶端和服務(wù)器知道的對(duì)稱加密密鑰稱為“會(huì)話密鑰”后續(xù)所有應(yīng)用數(shù)據(jù)HTTP報(bào)文都用這個(gè)密鑰進(jìn)行快速的對(duì)稱加密傳輸。為什么不用非對(duì)稱加密直接傳數(shù)據(jù)因?yàn)樘恕Ｈ绻看蝹鬏斁W(wǎng)頁(yè)內(nèi)容都用RSA加密用戶體驗(yàn)會(huì)極其糟糕。為什么不用對(duì)稱加密從頭到尾因?yàn)槊荑€分發(fā)問(wèn)題。如何把對(duì)稱加密的密鑰安全地告訴對(duì)方在互聯(lián)網(wǎng)上直接發(fā)送密鑰會(huì)被中間人截獲。HTTPS的解決方案是用非對(duì)稱加密來(lái)安全地傳遞對(duì)稱加密的密鑰。這就是“混合加密”的精髓。3.3 TLS握手流程深度解析以RSA密鑰交換為例以經(jīng)典的TLS 1.2握手為例TLS 1.3更精簡(jiǎn)但原理相通我們看看會(huì)話密鑰是如何安全建立的Client Hello客戶端向服務(wù)器發(fā)起連接發(fā)送一個(gè)隨機(jī)數(shù)Client Random以及自己支持的TLS版本、加密套件Cipher Suites列表等。Server Hello服務(wù)器回應(yīng)選擇一個(gè)雙方都支持的TLS版本和加密套件也發(fā)送一個(gè)隨機(jī)數(shù)Server Random。同時(shí)服務(wù)器將自己的數(shù)字證書發(fā)送給客戶端。證書驗(yàn)證這是最關(guān)鍵的一步客戶端收到證書后會(huì)進(jìn)行一系列驗(yàn)證檢查證書是否由自己信任的證書頒發(fā)機(jī)構(gòu)CA簽發(fā)瀏覽器和操作系統(tǒng)內(nèi)置了受信任的根CA列表。檢查證書是否在有效期內(nèi)。檢查證書中的域名是否與正在訪問(wèn)的域名匹配。利用證書中的CA公鑰驗(yàn)證證書的數(shù)字簽名是否有效以確保證書本身未被篡改。 如果任何一項(xiàng)驗(yàn)證失敗瀏覽器就會(huì)彈出著名的“您的連接不是私密連接”警告。Pre-master Secret生成與加密證書驗(yàn)證通過(guò)后客戶端信任了服務(wù)器的公鑰從證書中獲取。客戶端生成第三個(gè)隨機(jī)數(shù)稱為預(yù)主密鑰Pre-master Secret。然后用服務(wù)器的公鑰加密這個(gè)預(yù)主密鑰發(fā)送給服務(wù)器。注意只有擁有對(duì)應(yīng)私鑰的服務(wù)器才能解密這個(gè)信息。中間人即使截獲也無(wú)法解密。會(huì)話密鑰生成現(xiàn)在客戶端和服務(wù)器都擁有了三個(gè)隨機(jī)數(shù)Client Random, Server Random, 和 Pre-master Secret。雙方使用相同的密鑰派生函數(shù)根據(jù)這三個(gè)隨機(jī)數(shù)生成相同的主密鑰Master Secret進(jìn)而派生出用于本次會(huì)話的對(duì)稱加密密鑰會(huì)話密鑰和消息認(rèn)證碼MAC密鑰。握手完成安全通信開始雙方交換“Change Cipher Spec”和“Finished”消息確認(rèn)后續(xù)通信將使用剛剛協(xié)商出的會(huì)話密鑰進(jìn)行加密。至此握手完成開始傳輸加密的HTTP數(shù)據(jù)。TLS 1.3的優(yōu)化TLS 1.3大幅簡(jiǎn)化了握手過(guò)程將原來(lái)的兩個(gè)RTT兩次往返減少到了1個(gè)RTT甚至通過(guò)“0-RTT”模式在某些情況下實(shí)現(xiàn)零往返延遲。它完全廢棄了RSA密鑰交換只支持前向安全Forward Secrecy更好的密鑰交換算法如ECDHE即使服務(wù)器私鑰未來(lái)泄露也無(wú)法解密過(guò)去截獲的通信。3.4 數(shù)字證書與CA信任鏈數(shù)字證書是HTTPS身份認(rèn)證的載體。它遵循X.509標(biāo)準(zhǔn)里面包含了證書持有者的信息如域名、組織證書持有者的公鑰證書簽發(fā)者CA的信息簽發(fā)者的數(shù)字簽名有效期信任鏈Chain of Trust是這套體系的核心。我們信任根證書頒發(fā)機(jī)構(gòu)Root CA。根CA用自己的私鑰為中間CAIntermediate CA的證書簽名。中間CA再用自己的私鑰為最終服務(wù)器證書簽名。你的瀏覽器或操作系統(tǒng)內(nèi)置了根CA的公鑰它可以逐級(jí)驗(yàn)證簽名最終信任服務(wù)器證書。這形成了一個(gè)信任鏈。實(shí)操心得自簽名證書與內(nèi)網(wǎng)開發(fā)在開發(fā)測(cè)試環(huán)境我們經(jīng)常使用自簽名證書自己充當(dāng)CA給自己簽發(fā)證書。瀏覽器會(huì)因?yàn)樗皇怯墒苄湃蔚腃A簽發(fā)而報(bào)警。處理方式有兩種一是將自簽名的根證書導(dǎo)入到系統(tǒng)的受信任根證書存儲(chǔ)區(qū)僅限測(cè)試環(huán)境二是在訪問(wèn)時(shí)手動(dòng)點(diǎn)擊“高級(jí)”-“繼續(xù)前往不安全”。對(duì)于像localhost或內(nèi)網(wǎng)IP現(xiàn)代瀏覽器可能有更寬松的策略但最好還是正確配置。4. HTTP與HTTPS全方位對(duì)比與選型考量理解了原理我們?cè)購(gòu)亩鄠€(gè)維度系統(tǒng)對(duì)比一下兩者這不僅是面試重點(diǎn)更是技術(shù)選型的依據(jù)。對(duì)比維度HTTPHTTPS協(xié)議與端口應(yīng)用層協(xié)議默認(rèn)端口80HTTP over SSL/TLS默認(rèn)端口443安全性明文傳輸數(shù)據(jù)易被竊聽、篡改、冒充加密傳輸具備機(jī)密性、完整性、身份認(rèn)證握手過(guò)程TCP三次握手后直接傳輸數(shù)據(jù)在TCP握手后需進(jìn)行TLS握手額外1-2個(gè)RTT性能開銷無(wú)加密解密開銷性能高有加解密、證書驗(yàn)證開銷連接建立稍慢但可通過(guò)優(yōu)化緩解SEO與瀏覽器策略處于劣勢(shì)現(xiàn)代瀏覽器對(duì)HTTP頁(yè)面標(biāo)記“不安全”搜索引擎如Google給予排名加權(quán)是PWAs等現(xiàn)代Web特性的前提證書要求無(wú)需證書需要向CA申請(qǐng)或使用自簽名證書含公鑰、私鑰適用場(chǎng)景內(nèi)網(wǎng)環(huán)境、不涉密的資訊類網(wǎng)站、設(shè)備管理界面如路由器所有涉及用戶數(shù)據(jù)、登錄、交易、隱私的網(wǎng)站現(xiàn)代Web默認(rèn)標(biāo)準(zhǔn)關(guān)于性能的深度討論很多人認(rèn)為HTTPS一定慢這是個(gè)誤區(qū)。額外的TLS握手確實(shí)會(huì)引入延遲但這主要體現(xiàn)在建立連接的階段。一旦連接建立使用對(duì)稱加密如AES對(duì)數(shù)據(jù)進(jìn)行加解密的開銷在現(xiàn)代CPU上已經(jīng)非常低通常只占請(qǐng)求處理時(shí)間的1%以下。而且通過(guò)以下優(yōu)化HTTPS的性能可以非常接近HTTP會(huì)話恢復(fù)Session Resumption包括Session ID和更高效的Session Ticket機(jī)制允許客戶端在短時(shí)間內(nèi)重連時(shí)跳過(guò)完整的密鑰協(xié)商實(shí)現(xiàn)0-RTT或1-RTT握手。TLS False Start客戶端在發(fā)送Change Cipher Spec后不必等待服務(wù)器的Finished消息就可以開始發(fā)送加密的應(yīng)用數(shù)據(jù)減少了一個(gè)RTT。OCSP Stapling服務(wù)器在握手時(shí)附帶證書的吊銷狀態(tài)避免客戶端再去CA的OCSP服務(wù)器查詢減少延遲。HTTP/2 或 HTTP/3這些新一代HTTP協(xié)議通常要求使用HTTPS。它們帶來(lái)的多路復(fù)用、頭部壓縮等特性帶來(lái)的性能提升遠(yuǎn)遠(yuǎn)超過(guò)了TLS握手帶來(lái)的微小開銷。事實(shí)上一個(gè)配置了HTTP/2的HTTPS網(wǎng)站其整體性能通常遠(yuǎn)超一個(gè)使用HTTP/1.1的HTTP網(wǎng)站。技術(shù)選型結(jié)論在當(dāng)今的互聯(lián)網(wǎng)環(huán)境下除非有極其特殊且可控的理由如極度受限的嵌入式設(shè)備內(nèi)網(wǎng)通信否則所有面向公網(wǎng)的Web服務(wù)都應(yīng)該使用HTTPS。它已經(jīng)是安全、可信和現(xiàn)代Web的入場(chǎng)券。5. 實(shí)戰(zhàn)配置、問(wèn)題排查與面試核心5.1 從HTTP到HTTPS的遷移實(shí)戰(zhàn)要點(diǎn)將一個(gè)現(xiàn)有HTTP站點(diǎn)遷移到HTTPS遠(yuǎn)不止是買個(gè)證書、改個(gè)端口那么簡(jiǎn)單。以下是關(guān)鍵步驟和坑點(diǎn)獲取證書購(gòu)買商業(yè)證書從DigiCert、Sectigo、Let‘s Encrypt免費(fèi)等CA購(gòu)買。選擇單域名、泛域名*.example.com還是多域名證書。使用Let‘s Encrypt通過(guò)ACME協(xié)議如Certbot工具自動(dòng)化申請(qǐng)和續(xù)期免費(fèi)證書非常適合個(gè)人項(xiàng)目和小型企業(yè)。服務(wù)器配置以Nginx為例server { listen 443 ssl http2; # 啟用SSL并建議同時(shí)啟用HTTP/2 server_name yourdomain.com; ssl_certificate /path/to/your/fullchain.pem; # 證書鏈文件包含服務(wù)器證書和中間CA證書 ssl_certificate_key /path/to/your/private.key; # 私鑰文件務(wù)必保密 # 安全強(qiáng)化配置 ssl_protocols TLSv1.2 TLSv1.3; # 禁用不安全的SSLv2, v3, TLSv1.0, v1.1 ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:...; # 使用現(xiàn)代、安全的加密套件 ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; # ... 其他location配置 } # 強(qiáng)制HTTP跳轉(zhuǎn)到HTTPS server { listen 80; server_name yourdomain.com; return 301 https://$server_name$request_uri; }重要提示私鑰文件.key的權(quán)限必須嚴(yán)格限制如600防止泄露。應(yīng)用內(nèi)容調(diào)整混合內(nèi)容Mixed Content問(wèn)題這是遷移后最常見的問(wèn)題。HTTPS頁(yè)面中如果通過(guò)HTTP加載了腳本、樣式表、圖片、iframe等資源瀏覽器會(huì)阻止加載或警告。必須將頁(yè)面內(nèi)所有資源的URL都改為HTTPS或使用協(xié)議相對(duì)URL//example.com/resource.js。更新硬編碼的絕對(duì)URL檢查代碼、數(shù)據(jù)庫(kù)、配置文件中是否有硬編碼的http://鏈接。更新第三方服務(wù)配置如CDN、統(tǒng)計(jì)代碼、社交分享插件等確保它們支持HTTPS。測(cè)試與驗(yàn)證使用瀏覽器訪問(wèn)檢查地址欄是否有鎖標(biāo)志。使用在線工具如 SSL Labs Server Test 全面測(cè)試服務(wù)器SSL配置獲取安全評(píng)級(jí)最好達(dá)到A或A。檢查所有功能是否正常特別是涉及Cookie、Session、重定向和第三方集成的部分。5.2 高頻面試題深度剖析HTTPS是如何保證數(shù)據(jù)安全的標(biāo)準(zhǔn)回答通過(guò)SSL/TLS協(xié)議。它使用數(shù)字證書進(jìn)行身份認(rèn)證防止中間人攻擊使用非對(duì)稱加密協(xié)商出對(duì)稱加密的會(huì)話密鑰使用對(duì)稱加密對(duì)傳輸?shù)腍TTP數(shù)據(jù)進(jìn)行加密保證機(jī)密性使用消息認(rèn)證碼MAC保證數(shù)據(jù)完整性。加分回答能說(shuō)出前向安全Forward Secrecy的概念。即即使服務(wù)器私鑰未來(lái)被泄露攻擊者也無(wú)法解密過(guò)去截獲的通信記錄。這依賴于使用ECDHE等密鑰交換算法每次會(huì)話的臨時(shí)密鑰在握手后即丟棄。詳細(xì)描述一次HTTPS的握手過(guò)程。參考上文3.3節(jié)清晰地描述Client Hello, Server Hello含證書客戶端驗(yàn)證證書并發(fā)送加密的Pre-master Secret雙方生成會(huì)話密鑰最后切換至加密通信的步驟。能說(shuō)出“三個(gè)隨機(jī)數(shù)”和“會(huì)話密鑰”的生成是關(guān)鍵。為什么HTTPS是安全的抓包工具為什么能抓到HTTPS的數(shù)據(jù)HTTPS的安全建立在可信的CA體系和服務(wù)器私鑰的保密性上。抓包工具如Fiddler, Charles之所以能解密HTTPS流量是因?yàn)樗鼈冊(cè)诳蛻舳顺洚?dāng)了“中間人”。你需要手動(dòng)在客戶端設(shè)備上安裝抓包工具自己的根證書相當(dāng)于你信任了這個(gè)“偽造”的CA這樣工具就能用自己的證書冒充服務(wù)器與客戶端和服務(wù)器分別建立TLS連接從而解密和查看明文數(shù)據(jù)。這恰恰證明了HTTPS在正常情況下能有效防止中間人攻擊。HTTP/2和HTTP/3有什么特點(diǎn)它們和HTTPS的關(guān)系HTTP/2主要特性是二進(jìn)制分幀、多路復(fù)用、頭部壓縮、服務(wù)器推送。它解決了HTTP/1.1的隊(duì)頭阻塞問(wèn)題在應(yīng)用層大幅提升性能。HTTP/2在實(shí)踐中幾乎總是與HTTPS一起使用因?yàn)闉g覽器只對(duì)HTTPS連接支持HTTP/2。HTTP/3基于QUIC協(xié)議運(yùn)行在UDP上。它將TLS 1.3作為內(nèi)置部分并且從傳輸層解決了隊(duì)頭阻塞問(wèn)題因?yàn)槊總€(gè)流獨(dú)立。連接遷移能力更強(qiáng)如從WiFi切換到4G。它代表了未來(lái)。GET和POST的區(qū)別語(yǔ)義GET獲取資源POST提交數(shù)據(jù)。冪等性與安全性GET是冪等且安全的不應(yīng)改變服務(wù)器狀態(tài)POST非冪等。數(shù)據(jù)攜帶GET參數(shù)在URL中有長(zhǎng)度限制受瀏覽器和服務(wù)器限制且明文可見POST數(shù)據(jù)在請(qǐng)求體中更安全可傳輸更大數(shù)據(jù)。緩存GET請(qǐng)求可被緩存POST一般不會(huì)。后退/刷新瀏覽器對(duì)GET無(wú)害對(duì)POST會(huì)提示重新提交表單。面試陷阱不要只說(shuō)“POST更安全”。安全性取決于是否使用HTTPS。在HTTP下GET參數(shù)在URL里POST數(shù)據(jù)在Body里但都是明文都能被抓包看到。在HTTPS下兩者都被加密。5.3 常見運(yùn)維與開發(fā)問(wèn)題排查證書相關(guān)問(wèn)題證書過(guò)期最常見的錯(cuò)誤。表現(xiàn)是瀏覽器訪問(wèn)顯示“您的連接不是私密連接”NET::ERR_CERT_DATE_INVALID。解決方案及時(shí)續(xù)期證書。使用Let‘s Encrypt配合自動(dòng)化腳本如crontab可避免此問(wèn)題。證書鏈不完整服務(wù)器只發(fā)送了站點(diǎn)證書沒有發(fā)送中間CA證書導(dǎo)致客戶端無(wú)法構(gòu)建完整的信任鏈。解決方案配置Web服務(wù)器時(shí)ssl_certificate應(yīng)指向包含服務(wù)器證書和中間CA證書的鏈文件fullchain.pem。域名不匹配證書的Common Name (CN) 或 Subject Alternative Names (SAN) 不包含你訪問(wèn)的域名。解決方案申請(qǐng)包含正確域名的證書或使用泛域名證書。HTTPS站點(diǎn)部分資源加載失敗Mixed Content表現(xiàn)控制臺(tái)出現(xiàn)警告或錯(cuò)誤如“Mixed Content: The page at ‘https://...‘ was loaded over HTTPS, but requested an insecure resource ‘http://...‘”。排查使用瀏覽器開發(fā)者工具的“網(wǎng)絡(luò)Network”面板篩選出狀態(tài)為“阻塞blocked”或協(xié)議為“http”的請(qǐng)求。解決將資源鏈接改為HTTPS或使用協(xié)議相對(duì)URL。性能問(wèn)題TLS握手慢可能是由于客戶端或服務(wù)器不支持會(huì)話恢復(fù)或者OCSP查詢被墻/慢。優(yōu)化啟用ssl_session_cache和ssl_session_tickets配置OCSP Stapling。CPU占用高大量HTTPS連接加解密消耗CPU。優(yōu)化啟用TLS硬件加速如果服務(wù)器支持考慮使用更高效的ECDSA證書相比RSA升級(jí)到支持AES-NI指令集的CPU。后端服務(wù)獲取客戶端真實(shí)IP問(wèn)題當(dāng)網(wǎng)站前端有負(fù)載均衡器如Nginx或CDN做HTTPS終結(jié)Termination時(shí)后端應(yīng)用服務(wù)器收到的請(qǐng)求來(lái)自負(fù)載均衡器其源IP是負(fù)載均衡器的IP而非真實(shí)用戶IP。解決負(fù)載均衡器需要在轉(zhuǎn)發(fā)請(qǐng)求的HTTP頭中如X-Forwarded-For或X-Real-IP添加用戶的真實(shí)IP。后端應(yīng)用需要讀取這個(gè)頭部而非直接取TCP連接的遠(yuǎn)程地址。理解HTTP和HTTPS不僅僅是背下幾個(gè)面試題答案更是構(gòu)建安全、可靠、高性能Web應(yīng)用的基石。從簡(jiǎn)單的明文傳輸?shù)綇?fù)雜的加密握手從無(wú)狀態(tài)請(qǐng)求到有狀態(tài)會(huì)話管理每一步演進(jìn)都對(duì)應(yīng)著真實(shí)世界的需求與挑戰(zhàn)。在實(shí)際工作中無(wú)論是設(shè)計(jì)API、配置服務(wù)器、調(diào)試跨域問(wèn)題還是優(yōu)化頁(yè)面加載速度這些知識(shí)都會(huì)時(shí)刻發(fā)揮作用。我的建議是在本地環(huán)境用Wireshark抓一下HTTP包用openssl命令模擬一下TLS握手親手配置一遍Nginx的HTTPS這些實(shí)操帶來(lái)的理解遠(yuǎn)比讀十篇文章要深刻。技術(shù)總是在發(fā)展HTTP/3和QUIC正在走來(lái)但牢牢掌握這些基礎(chǔ)原理會(huì)讓你在面對(duì)任何新協(xié)議時(shí)都能快速抓住本質(zhì)。 HTTP與HTTPS核心原理：從明文傳輸?shù)郊用芪帐峙c性能優(yōu)化
1. 從“明文快遞”到“武裝押運(yùn)”HTTP與HTTPS的本質(zhì)透視干了這么多年開發(fā)每次面試新人或者和同行聊起網(wǎng)絡(luò)基礎(chǔ)HTTP和HTTPS這對(duì)“兄弟”總是繞不開的話題。表面上看就是一個(gè)“S”的差別但背后牽扯到的安全、性能、協(xié)議棧乃至整個(gè)互聯(lián)網(wǎng)的信任體系水可深了。很多人背了一堆“HTTP不安全、HTTPS安全”、“端口80和443”的面試八股但被問(wèn)到“為什么安全”、“具體怎么實(shí)現(xiàn)的”時(shí)往往就卡殼了。今天我就結(jié)合自己踩過(guò)的坑和實(shí)際項(xiàng)目中的經(jīng)驗(yàn)把這哥倆從里到外掰開揉碎了講清楚讓你不僅能在面試中對(duì)答如流更能真正理解它們?cè)谀銓懙拿恳恍写a、設(shè)計(jì)的每一個(gè)系統(tǒng)里扮演的角色。簡(jiǎn)單來(lái)說(shuō)你可以把HTTP想象成在熙熙攘攘的集市上用大喇叭喊話傳遞明信片。你說(shuō)的話請(qǐng)求、對(duì)方回的話響應(yīng)還有明信片上的內(nèi)容數(shù)據(jù)所有路過(guò)的人都能聽見、看見甚至能篡改、冒充。這就是HTTP超文本傳輸協(xié)議它簡(jiǎn)單、高效但毫無(wú)隱私和安全性可言。而HTTPS則像是為這條通信線路雇傭了頂尖的安保公司——它給整個(gè)對(duì)話過(guò)程加了一個(gè)堅(jiān)固的保險(xiǎn)箱加密并且由權(quán)威機(jī)構(gòu)CA給這個(gè)保險(xiǎn)箱和通信雙方都簽發(fā)了無(wú)法偽造的“身份證”數(shù)字證書。從此你們的對(duì)話變成了加密的密文只有持有正確鑰匙的雙方才能解密閱讀中間人既看不懂也改不了。這個(gè)“S”代表的就是“Secure”安全它的核心是在HTTP之下、TCP之上加入了一個(gè)SSL/TLS協(xié)議層專門負(fù)責(zé)加密和身份認(rèn)證。這篇文章我會(huì)帶你深入這個(gè)“保險(xiǎn)箱”內(nèi)部看看加密和證書到底是怎么工作的對(duì)比兩者在握手、性能、使用場(chǎng)景上的具體差異并整理出那些真正高頻、能考察出你理解深度的面試題和實(shí)戰(zhàn)要點(diǎn)。無(wú)論你是前端、后端、運(yùn)維還是安全工程師這些內(nèi)容都是你技術(shù)棧里不可或缺的基石。2. HTTP協(xié)議簡(jiǎn)單高效的“明文信使”2.1 核心工作原理與報(bào)文結(jié)構(gòu)HTTP是一個(gè)無(wú)狀態(tài)的、應(yīng)用層的協(xié)議它建立在可靠的TCP連接之上。它的工作模式極其經(jīng)典請(qǐng)求-響應(yīng)Request-Response。客戶端通常是瀏覽器發(fā)起一個(gè)請(qǐng)求到服務(wù)器服務(wù)器處理后再返回一個(gè)響應(yīng)。這個(gè)模型簡(jiǎn)單直觀也是它能夠快速普及的原因之一。一個(gè)完整的HTTP報(bào)文無(wú)論是請(qǐng)求還是響應(yīng)都包含三部分起始行Start Line對(duì)于請(qǐng)求它包含方法Method、URL和HTTP版本對(duì)于響應(yīng)它包含HTTP版本、狀態(tài)碼Status Code和原因短語(yǔ)Reason Phrase。頭部字段Headers一系列鍵值對(duì)傳遞關(guān)于報(bào)文或主體的元信息比如內(nèi)容類型Content-Type、內(nèi)容長(zhǎng)度Content-Length、緩存控制Cache-Control等。頭部和主體之間用一個(gè)空行分隔。消息主體Body可選部分承載實(shí)際傳輸?shù)臄?shù)據(jù)比如POST請(qǐng)求提交的表單數(shù)據(jù)或者服務(wù)器返回的HTML、JSON數(shù)據(jù)。這里我重點(diǎn)說(shuō)一下方法和狀態(tài)碼因?yàn)檫@是日常開發(fā)和調(diào)試中最常打交道的。HTTP方法Method定義了客戶端希望服務(wù)器對(duì)資源執(zhí)行的操作GET獲取資源。應(yīng)該是冪等的多次執(zhí)行結(jié)果相同且不應(yīng)有副作用不修改服務(wù)器數(shù)據(jù)。這是最常用的方法。POST提交數(shù)據(jù)通常用于創(chuàng)建新資源或觸發(fā)一個(gè)處理數(shù)據(jù)的操作。非冪等。PUT替換整個(gè)資源。冪等。DELETE刪除指定資源。冪等。PATCH對(duì)資源進(jìn)行部分修改。非冪等。HEAD只獲取資源的頭部信息不返回主體。常用于檢查資源是否存在或是否被修改。OPTIONS獲取目標(biāo)資源支持的通信選項(xiàng)。在CORS跨域資源共享預(yù)檢請(qǐng)求中扮演關(guān)鍵角色。HTTP狀態(tài)碼是一個(gè)三位數(shù)字服務(wù)器用它來(lái)告訴客戶端請(qǐng)求的結(jié)果。它被分為五類1xx信息性請(qǐng)求已接收繼續(xù)處理。如101協(xié)議切換。2xx成功請(qǐng)求已成功被服務(wù)器接收、理解、并接受。最熟悉的就是200 OK。3xx重定向需要客戶端采取進(jìn)一步的操作以完成請(qǐng)求。例如301 Moved Permanently永久重定向、302 Found臨時(shí)重定向但注意瀏覽器通常按303處理、304 Not Modified資源未修改使用緩存。4xx客戶端錯(cuò)誤請(qǐng)求包含語(yǔ)法錯(cuò)誤或無(wú)法完成。404 Not Found資源不存在和400 Bad Request錯(cuò)誤請(qǐng)求是最常見的。401 Unauthorized表示需要身份驗(yàn)證而403 Forbidden是服務(wù)器理解請(qǐng)求但拒絕執(zhí)行。5xx服務(wù)器錯(cuò)誤服務(wù)器在處理請(qǐng)求的過(guò)程中發(fā)生了錯(cuò)誤。500 Internal Server Error內(nèi)部服務(wù)器錯(cuò)誤和502 Bad Gateway壞網(wǎng)關(guān)、503 Service Unavailable服務(wù)不可用是運(yùn)維同學(xué)的“噩夢(mèng)”。實(shí)操心得很多人分不清401和403。簡(jiǎn)單記401是“你是誰(shuí)請(qǐng)先登錄”缺少或無(wú)效的身份憑證403是“我知道你是誰(shuí)但你不配訪問(wèn)這個(gè)”身份有效但權(quán)限不足。調(diào)試API時(shí)看清狀態(tài)碼能幫你快速定位問(wèn)題是出在客戶端參數(shù)4xx還是服務(wù)器內(nèi)部5xx。2.2 連接管理與性能演進(jìn)早期的HTTP/1.0版本非常簡(jiǎn)單每次請(qǐng)求都需要建立一次TCP連接收到響應(yīng)后立即斷開。這種“短連接”模式對(duì)于早期簡(jiǎn)單的網(wǎng)頁(yè)文字少量圖片還行但現(xiàn)代網(wǎng)頁(yè)包含幾十甚至上百個(gè)資源CSS、JS、圖片反復(fù)建立斷開TCP連接的成本三次握手、四次揮手就太高了。于是HTTP/1.1引入了持久連接Persistent Connection也稱為連接復(fù)用。通過(guò)在請(qǐng)求頭中設(shè)置Connection: keep-aliveHTTP/1.1默認(rèn)可以在一個(gè)TCP連接上順序發(fā)送多個(gè)請(qǐng)求和接收多個(gè)響應(yīng)。這大大減少了延遲和系統(tǒng)開銷。但是HTTP/1.1的持久連接有一個(gè)致命問(wèn)題隊(duì)頭阻塞Head-of-Line Blocking。雖然連接可以復(fù)用但同一時(shí)間只能處理一個(gè)請(qǐng)求-響應(yīng)事務(wù)。如果第一個(gè)請(qǐng)求的響應(yīng)很慢比如一個(gè)大圖片后面的所有請(qǐng)求都會(huì)被阻塞即使它們需要的資源已經(jīng)準(zhǔn)備好了。為了緩解這個(gè)問(wèn)題瀏覽器通常會(huì)與同一個(gè)域名建立多個(gè)通常是6個(gè)并行連接但這又增加了服務(wù)器的負(fù)擔(dān)和連接管理的復(fù)雜性。HTTP/1.1時(shí)代的另一個(gè)重要優(yōu)化是管道化Pipelining它允許客戶端在同一個(gè)連接上連續(xù)發(fā)送多個(gè)請(qǐng)求而不必等待響應(yīng)。然而由于實(shí)現(xiàn)復(fù)雜且隊(duì)頭阻塞問(wèn)題依然存在響應(yīng)必須按請(qǐng)求順序返回它并未被廣泛支持現(xiàn)代瀏覽器默認(rèn)都是關(guān)閉的。注意事項(xiàng)在設(shè)計(jì)和調(diào)試后端服務(wù)時(shí)要特別注意HTTP/1.1的隊(duì)頭阻塞問(wèn)題。如果一個(gè)慢查詢接口或一個(gè)耗時(shí)的文件下載操作可能會(huì)阻塞同一連接上其他用戶或接口的請(qǐng)求。合理的連接超時(shí)、請(qǐng)求超時(shí)設(shè)置以及將耗時(shí)任務(wù)異步化是常見的解決方案。2.3 無(wú)狀態(tài)與有狀態(tài)管理的博弈HTTP協(xié)議本身是**無(wú)狀態(tài)Stateless**的。這意味著服務(wù)器不會(huì)在兩個(gè)請(qǐng)求之間記住任何客戶端信息。每個(gè)請(qǐng)求都是獨(dú)立的就像失憶的服務(wù)器每次見面都問(wèn)“你是誰(shuí)”。這對(duì)于服務(wù)器集群的擴(kuò)展性是好事任何服務(wù)器都能處理任何請(qǐng)求但對(duì)于需要“登錄狀態(tài)”、“購(gòu)物車”這樣的Web應(yīng)用來(lái)說(shuō)就是災(zāi)難。因此實(shí)踐中我們使用各種技術(shù)來(lái)“制造”狀態(tài)最主要的就是Cookie和Session。Cookie由服務(wù)器通過(guò)響應(yīng)頭Set-Cookie發(fā)送給瀏覽器的一小段數(shù)據(jù)。瀏覽器會(huì)保存它并在后續(xù)對(duì)同一服務(wù)器的請(qǐng)求中通過(guò)Cookie請(qǐng)求頭自動(dòng)攜帶回去。Cookie通常用于存儲(chǔ)會(huì)話標(biāo)識(shí)符Session ID、用戶偏好等。Session服務(wù)器端的一種機(jī)制用于存儲(chǔ)特定用戶會(huì)話的數(shù)據(jù)。服務(wù)器為每個(gè)會(huì)話創(chuàng)建一個(gè)唯一的Session ID并通過(guò)Cookie或URL重寫傳遞給客戶端。客戶端后續(xù)請(qǐng)求攜帶這個(gè)ID服務(wù)器就能找到對(duì)應(yīng)的會(huì)話數(shù)據(jù)。Cookie vs. Session 核心區(qū)別存儲(chǔ)位置Cookie存儲(chǔ)在客戶端瀏覽器Session數(shù)據(jù)存儲(chǔ)在服務(wù)器端內(nèi)存、數(shù)據(jù)庫(kù)、Redis等。安全性Cookie在客戶端可能被竊取或篡改雖然可以設(shè)置HttpOnly和Secure屬性來(lái)增強(qiáng)安全因此敏感信息如密碼絕不應(yīng)放在Cookie中。Session ID本身雖然也可能被竊取會(huì)話劫持但敏感數(shù)據(jù)在服務(wù)器端相對(duì)安全。性能與擴(kuò)展性Cookie數(shù)據(jù)每次請(qǐng)求都會(huì)攜帶增加帶寬消耗。Session數(shù)據(jù)在服務(wù)器端對(duì)服務(wù)器內(nèi)存或存儲(chǔ)有壓力在分布式環(huán)境下需要共享Session方案如用Redis集群。常見問(wèn)題排查“用戶登錄后跳轉(zhuǎn)個(gè)頁(yè)面又變未登錄了” 十有八九是Session或Cookie出了問(wèn)題。檢查點(diǎn)1. Session過(guò)期時(shí)間設(shè)置是否太短2. 分布式環(huán)境下請(qǐng)求是否被負(fù)載均衡到了沒有對(duì)應(yīng)Session數(shù)據(jù)的服務(wù)器3. Cookie的Domain和Path設(shè)置是否正確是否被瀏覽器攔截4. 是否使用了HttpOnly和Secure的Cookie但在非HTTPS環(huán)境下訪問(wèn)3. HTTPS為HTTP穿上“加密鎧甲”3.1 SSL/TLS協(xié)議層安全的基石HTTPS不是一個(gè)新的協(xié)議而是HTTP over SSL/TLS。你可以理解為在HTTP和TCP之間插入了一個(gè)安全套接字層SSL或其繼任者傳輸層安全TLS協(xié)議。當(dāng)前廣泛使用的是TLS 1.2和TLS 1.3。這個(gè)協(xié)議層主要解決了三個(gè)核心問(wèn)題機(jī)密性Confidentiality通過(guò)加密算法確保傳輸?shù)臄?shù)據(jù)無(wú)法被第三方竊聽。完整性Integrity通過(guò)消息認(rèn)證碼MAC確保數(shù)據(jù)在傳輸過(guò)程中未被篡改。身份認(rèn)證Authentication通過(guò)數(shù)字證書確保你正在通信的服務(wù)器就是它聲稱的那個(gè)而不是中間人偽裝的。3.2 核心加密機(jī)制混合加密的智慧HTTPS的加密并非使用單一的一種算法而是巧妙地結(jié)合了非對(duì)稱加密和對(duì)稱加密取長(zhǎng)補(bǔ)短。非對(duì)稱加密Asymmetric Encryption有一對(duì)密鑰公鑰Public Key和私鑰Private Key。公鑰可以公開給任何人用于加密數(shù)據(jù)私鑰必須嚴(yán)格保密用于解密用對(duì)應(yīng)公鑰加密的數(shù)據(jù)。反之用私鑰加密簽名的數(shù)據(jù)可以用公鑰驗(yàn)證。它的特點(diǎn)是安全性高但計(jì)算非常緩慢。RSA和ECC橢圓曲線是常見的非對(duì)稱加密算法。對(duì)稱加密Symmetric Encryption加密和解密使用同一把密鑰。它的特點(diǎn)是計(jì)算速度快適合加密大量數(shù)據(jù)。AES是當(dāng)前最主流、最安全的對(duì)稱加密算法。HTTPS的握手過(guò)程核心目的之一就是安全地協(xié)商出一個(gè)只有客戶端和服務(wù)器知道的對(duì)稱加密密鑰稱為“會(huì)話密鑰”后續(xù)所有應(yīng)用數(shù)據(jù)HTTP報(bào)文都用這個(gè)密鑰進(jìn)行快速的對(duì)稱加密傳輸。為什么不用非對(duì)稱加密直接傳數(shù)據(jù)因?yàn)樘恕Ｈ绻看蝹鬏斁W(wǎng)頁(yè)內(nèi)容都用RSA加密用戶體驗(yàn)會(huì)極其糟糕。為什么不用對(duì)稱加密從頭到尾因?yàn)槊荑€分發(fā)問(wèn)題。如何把對(duì)稱加密的密鑰安全地告訴對(duì)方在互聯(lián)網(wǎng)上直接發(fā)送密鑰會(huì)被中間人截獲。HTTPS的解決方案是用非對(duì)稱加密來(lái)安全地傳遞對(duì)稱加密的密鑰。這就是“混合加密”的精髓。3.3 TLS握手流程深度解析以RSA密鑰交換為例以經(jīng)典的TLS 1.2握手為例TLS 1.3更精簡(jiǎn)但原理相通我們看看會(huì)話密鑰是如何安全建立的Client Hello客戶端向服務(wù)器發(fā)起連接發(fā)送一個(gè)隨機(jī)數(shù)Client Random以及自己支持的TLS版本、加密套件Cipher Suites列表等。Server Hello服務(wù)器回應(yīng)選擇一個(gè)雙方都支持的TLS版本和加密套件也發(fā)送一個(gè)隨機(jī)數(shù)Server Random。同時(shí)服務(wù)器將自己的數(shù)字證書發(fā)送給客戶端。證書驗(yàn)證這是最關(guān)鍵的一步客戶端收到證書后會(huì)進(jìn)行一系列驗(yàn)證檢查證書是否由自己信任的證書頒發(fā)機(jī)構(gòu)CA簽發(fā)瀏覽器和操作系統(tǒng)內(nèi)置了受信任的根CA列表。檢查證書是否在有效期內(nèi)。檢查證書中的域名是否與正在訪問(wèn)的域名匹配。利用證書中的CA公鑰驗(yàn)證證書的數(shù)字簽名是否有效以確保證書本身未被篡改。 如果任何一項(xiàng)驗(yàn)證失敗瀏覽器就會(huì)彈出著名的“您的連接不是私密連接”警告。Pre-master Secret生成與加密證書驗(yàn)證通過(guò)后客戶端信任了服務(wù)器的公鑰從證書中獲取。客戶端生成第三個(gè)隨機(jī)數(shù)稱為預(yù)主密鑰Pre-master Secret。然后用服務(wù)器的公鑰加密這個(gè)預(yù)主密鑰發(fā)送給服務(wù)器。注意只有擁有對(duì)應(yīng)私鑰的服務(wù)器才能解密這個(gè)信息。中間人即使截獲也無(wú)法解密。會(huì)話密鑰生成現(xiàn)在客戶端和服務(wù)器都擁有了三個(gè)隨機(jī)數(shù)Client Random, Server Random, 和 Pre-master Secret。雙方使用相同的密鑰派生函數(shù)根據(jù)這三個(gè)隨機(jī)數(shù)生成相同的主密鑰Master Secret進(jìn)而派生出用于本次會(huì)話的對(duì)稱加密密鑰會(huì)話密鑰和消息認(rèn)證碼MAC密鑰。握手完成安全通信開始雙方交換“Change Cipher Spec”和“Finished”消息確認(rèn)后續(xù)通信將使用剛剛協(xié)商出的會(huì)話密鑰進(jìn)行加密。至此握手完成開始傳輸加密的HTTP數(shù)據(jù)。TLS 1.3的優(yōu)化TLS 1.3大幅簡(jiǎn)化了握手過(guò)程將原來(lái)的兩個(gè)RTT兩次往返減少到了1個(gè)RTT甚至通過(guò)“0-RTT”模式在某些情況下實(shí)現(xiàn)零往返延遲。它完全廢棄了RSA密鑰交換只支持前向安全Forward Secrecy更好的密鑰交換算法如ECDHE即使服務(wù)器私鑰未來(lái)泄露也無(wú)法解密過(guò)去截獲的通信。3.4 數(shù)字證書與CA信任鏈數(shù)字證書是HTTPS身份認(rèn)證的載體。它遵循X.509標(biāo)準(zhǔn)里面包含了證書持有者的信息如域名、組織證書持有者的公鑰證書簽發(fā)者CA的信息簽發(fā)者的數(shù)字簽名有效期信任鏈Chain of Trust是這套體系的核心。我們信任根證書頒發(fā)機(jī)構(gòu)Root CA。根CA用自己的私鑰為中間CAIntermediate CA的證書簽名。中間CA再用自己的私鑰為最終服務(wù)器證書簽名。你的瀏覽器或操作系統(tǒng)內(nèi)置了根CA的公鑰它可以逐級(jí)驗(yàn)證簽名最終信任服務(wù)器證書。這形成了一個(gè)信任鏈。實(shí)操心得自簽名證書與內(nèi)網(wǎng)開發(fā)在開發(fā)測(cè)試環(huán)境我們經(jīng)常使用自簽名證書自己充當(dāng)CA給自己簽發(fā)證書。瀏覽器會(huì)因?yàn)樗皇怯墒苄湃蔚腃A簽發(fā)而報(bào)警。處理方式有兩種一是將自簽名的根證書導(dǎo)入到系統(tǒng)的受信任根證書存儲(chǔ)區(qū)僅限測(cè)試環(huán)境二是在訪問(wèn)時(shí)手動(dòng)點(diǎn)擊“高級(jí)”-“繼續(xù)前往不安全”。對(duì)于像localhost或內(nèi)網(wǎng)IP現(xiàn)代瀏覽器可能有更寬松的策略但最好還是正確配置。4. HTTP與HTTPS全方位對(duì)比與選型考量理解了原理我們?cè)購(gòu)亩鄠€(gè)維度系統(tǒng)對(duì)比一下兩者這不僅是面試重點(diǎn)更是技術(shù)選型的依據(jù)。對(duì)比維度HTTPHTTPS協(xié)議與端口應(yīng)用層協(xié)議默認(rèn)端口80HTTP over SSL/TLS默認(rèn)端口443安全性明文傳輸數(shù)據(jù)易被竊聽、篡改、冒充加密傳輸具備機(jī)密性、完整性、身份認(rèn)證握手過(guò)程TCP三次握手后直接傳輸數(shù)據(jù)在TCP握手后需進(jìn)行TLS握手額外1-2個(gè)RTT性能開銷無(wú)加密解密開銷性能高有加解密、證書驗(yàn)證開銷連接建立稍慢但可通過(guò)優(yōu)化緩解SEO與瀏覽器策略處于劣勢(shì)現(xiàn)代瀏覽器對(duì)HTTP頁(yè)面標(biāo)記“不安全”搜索引擎如Google給予排名加權(quán)是PWAs等現(xiàn)代Web特性的前提證書要求無(wú)需證書需要向CA申請(qǐng)或使用自簽名證書含公鑰、私鑰適用場(chǎng)景內(nèi)網(wǎng)環(huán)境、不涉密的資訊類網(wǎng)站、設(shè)備管理界面如路由器所有涉及用戶數(shù)據(jù)、登錄、交易、隱私的網(wǎng)站現(xiàn)代Web默認(rèn)標(biāo)準(zhǔn)關(guān)于性能的深度討論很多人認(rèn)為HTTPS一定慢這是個(gè)誤區(qū)。額外的TLS握手確實(shí)會(huì)引入延遲但這主要體現(xiàn)在建立連接的階段。一旦連接建立使用對(duì)稱加密如AES對(duì)數(shù)據(jù)進(jìn)行加解密的開銷在現(xiàn)代CPU上已經(jīng)非常低通常只占請(qǐng)求處理時(shí)間的1%以下。而且通過(guò)以下優(yōu)化HTTPS的性能可以非常接近HTTP會(huì)話恢復(fù)Session Resumption包括Session ID和更高效的Session Ticket機(jī)制允許客戶端在短時(shí)間內(nèi)重連時(shí)跳過(guò)完整的密鑰協(xié)商實(shí)現(xiàn)0-RTT或1-RTT握手。TLS False Start客戶端在發(fā)送Change Cipher Spec后不必等待服務(wù)器的Finished消息就可以開始發(fā)送加密的應(yīng)用數(shù)據(jù)減少了一個(gè)RTT。OCSP Stapling服務(wù)器在握手時(shí)附帶證書的吊銷狀態(tài)避免客戶端再去CA的OCSP服務(wù)器查詢減少延遲。HTTP/2 或 HTTP/3這些新一代HTTP協(xié)議通常要求使用HTTPS。它們帶來(lái)的多路復(fù)用、頭部壓縮等特性帶來(lái)的性能提升遠(yuǎn)遠(yuǎn)超過(guò)了TLS握手帶來(lái)的微小開銷。事實(shí)上一個(gè)配置了HTTP/2的HTTPS網(wǎng)站其整體性能通常遠(yuǎn)超一個(gè)使用HTTP/1.1的HTTP網(wǎng)站。技術(shù)選型結(jié)論在當(dāng)今的互聯(lián)網(wǎng)環(huán)境下除非有極其特殊且可控的理由如極度受限的嵌入式設(shè)備內(nèi)網(wǎng)通信否則所有面向公網(wǎng)的Web服務(wù)都應(yīng)該使用HTTPS。它已經(jīng)是安全、可信和現(xiàn)代Web的入場(chǎng)券。5. 實(shí)戰(zhàn)配置、問(wèn)題排查與面試核心5.1 從HTTP到HTTPS的遷移實(shí)戰(zhàn)要點(diǎn)將一個(gè)現(xiàn)有HTTP站點(diǎn)遷移到HTTPS遠(yuǎn)不止是買個(gè)證書、改個(gè)端口那么簡(jiǎn)單。以下是關(guān)鍵步驟和坑點(diǎn)獲取證書購(gòu)買商業(yè)證書從DigiCert、Sectigo、Let‘s Encrypt免費(fèi)等CA購(gòu)買。選擇單域名、泛域名*.example.com還是多域名證書。使用Let‘s Encrypt通過(guò)ACME協(xié)議如Certbot工具自動(dòng)化申請(qǐng)和續(xù)期免費(fèi)證書非常適合個(gè)人項(xiàng)目和小型企業(yè)。服務(wù)器配置以Nginx為例server { listen 443 ssl http2; # 啟用SSL并建議同時(shí)啟用HTTP/2 server_name yourdomain.com; ssl_certificate /path/to/your/fullchain.pem; # 證書鏈文件包含服務(wù)器證書和中間CA證書 ssl_certificate_key /path/to/your/private.key; # 私鑰文件務(wù)必保密 # 安全強(qiáng)化配置 ssl_protocols TLSv1.2 TLSv1.3; # 禁用不安全的SSLv2, v3, TLSv1.0, v1.1 ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:...; # 使用現(xiàn)代、安全的加密套件 ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; # ... 其他location配置 } # 強(qiáng)制HTTP跳轉(zhuǎn)到HTTPS server { listen 80; server_name yourdomain.com; return 301 https://$server_name$request_uri; }重要提示私鑰文件.key的權(quán)限必須嚴(yán)格限制如600防止泄露。應(yīng)用內(nèi)容調(diào)整混合內(nèi)容Mixed Content問(wèn)題這是遷移后最常見的問(wèn)題。HTTPS頁(yè)面中如果通過(guò)HTTP加載了腳本、樣式表、圖片、iframe等資源瀏覽器會(huì)阻止加載或警告。必須將頁(yè)面內(nèi)所有資源的URL都改為HTTPS或使用協(xié)議相對(duì)URL//example.com/resource.js。更新硬編碼的絕對(duì)URL檢查代碼、數(shù)據(jù)庫(kù)、配置文件中是否有硬編碼的http://鏈接。更新第三方服務(wù)配置如CDN、統(tǒng)計(jì)代碼、社交分享插件等確保它們支持HTTPS。測(cè)試與驗(yàn)證使用瀏覽器訪問(wèn)檢查地址欄是否有鎖標(biāo)志。使用在線工具如 SSL Labs Server Test 全面測(cè)試服務(wù)器SSL配置獲取安全評(píng)級(jí)最好達(dá)到A或A。檢查所有功能是否正常特別是涉及Cookie、Session、重定向和第三方集成的部分。5.2 高頻面試題深度剖析HTTPS是如何保證數(shù)據(jù)安全的標(biāo)準(zhǔn)回答通過(guò)SSL/TLS協(xié)議。它使用數(shù)字證書進(jìn)行身份認(rèn)證防止中間人攻擊使用非對(duì)稱加密協(xié)商出對(duì)稱加密的會(huì)話密鑰使用對(duì)稱加密對(duì)傳輸?shù)腍TTP數(shù)據(jù)進(jìn)行加密保證機(jī)密性使用消息認(rèn)證碼MAC保證數(shù)據(jù)完整性。加分回答能說(shuō)出前向安全Forward Secrecy的概念。即即使服務(wù)器私鑰未來(lái)被泄露攻擊者也無(wú)法解密過(guò)去截獲的通信記錄。這依賴于使用ECDHE等密鑰交換算法每次會(huì)話的臨時(shí)密鑰在握手后即丟棄。詳細(xì)描述一次HTTPS的握手過(guò)程。參考上文3.3節(jié)清晰地描述Client Hello, Server Hello含證書客戶端驗(yàn)證證書并發(fā)送加密的Pre-master Secret雙方生成會(huì)話密鑰最后切換至加密通信的步驟。能說(shuō)出“三個(gè)隨機(jī)數(shù)”和“會(huì)話密鑰”的生成是關(guān)鍵。為什么HTTPS是安全的抓包工具為什么能抓到HTTPS的數(shù)據(jù)HTTPS的安全建立在可信的CA體系和服務(wù)器私鑰的保密性上。抓包工具如Fiddler, Charles之所以能解密HTTPS流量是因?yàn)樗鼈冊(cè)诳蛻舳顺洚?dāng)了“中間人”。你需要手動(dòng)在客戶端設(shè)備上安裝抓包工具自己的根證書相當(dāng)于你信任了這個(gè)“偽造”的CA這樣工具就能用自己的證書冒充服務(wù)器與客戶端和服務(wù)器分別建立TLS連接從而解密和查看明文數(shù)據(jù)。這恰恰證明了HTTPS在正常情況下能有效防止中間人攻擊。HTTP/2和HTTP/3有什么特點(diǎn)它們和HTTPS的關(guān)系HTTP/2主要特性是二進(jìn)制分幀、多路復(fù)用、頭部壓縮、服務(wù)器推送。它解決了HTTP/1.1的隊(duì)頭阻塞問(wèn)題在應(yīng)用層大幅提升性能。HTTP/2在實(shí)踐中幾乎總是與HTTPS一起使用因?yàn)闉g覽器只對(duì)HTTPS連接支持HTTP/2。HTTP/3基于QUIC協(xié)議運(yùn)行在UDP上。它將TLS 1.3作為內(nèi)置部分并且從傳輸層解決了隊(duì)頭阻塞問(wèn)題因?yàn)槊總€(gè)流獨(dú)立。連接遷移能力更強(qiáng)如從WiFi切換到4G。它代表了未來(lái)。GET和POST的區(qū)別語(yǔ)義GET獲取資源POST提交數(shù)據(jù)。冪等性與安全性GET是冪等且安全的不應(yīng)改變服務(wù)器狀態(tài)POST非冪等。數(shù)據(jù)攜帶GET參數(shù)在URL中有長(zhǎng)度限制受瀏覽器和服務(wù)器限制且明文可見POST數(shù)據(jù)在請(qǐng)求體中更安全可傳輸更大數(shù)據(jù)。緩存GET請(qǐng)求可被緩存POST一般不會(huì)。后退/刷新瀏覽器對(duì)GET無(wú)害對(duì)POST會(huì)提示重新提交表單。面試陷阱不要只說(shuō)“POST更安全”。安全性取決于是否使用HTTPS。在HTTP下GET參數(shù)在URL里POST數(shù)據(jù)在Body里但都是明文都能被抓包看到。在HTTPS下兩者都被加密。5.3 常見運(yùn)維與開發(fā)問(wèn)題排查證書相關(guān)問(wèn)題證書過(guò)期最常見的錯(cuò)誤。表現(xiàn)是瀏覽器訪問(wèn)顯示“您的連接不是私密連接”NET::ERR_CERT_DATE_INVALID。解決方案及時(shí)續(xù)期證書。使用Let‘s Encrypt配合自動(dòng)化腳本如crontab可避免此問(wèn)題。證書鏈不完整服務(wù)器只發(fā)送了站點(diǎn)證書沒有發(fā)送中間CA證書導(dǎo)致客戶端無(wú)法構(gòu)建完整的信任鏈。解決方案配置Web服務(wù)器時(shí)ssl_certificate應(yīng)指向包含服務(wù)器證書和中間CA證書的鏈文件fullchain.pem。域名不匹配證書的Common Name (CN) 或 Subject Alternative Names (SAN) 不包含你訪問(wèn)的域名。解決方案申請(qǐng)包含正確域名的證書或使用泛域名證書。HTTPS站點(diǎn)部分資源加載失敗Mixed Content表現(xiàn)控制臺(tái)出現(xiàn)警告或錯(cuò)誤如“Mixed Content: The page at ‘https://...‘ was loaded over HTTPS, but requested an insecure resource ‘http://...‘”。排查使用瀏覽器開發(fā)者工具的“網(wǎng)絡(luò)Network”面板篩選出狀態(tài)為“阻塞blocked”或協(xié)議為“http”的請(qǐng)求。解決將資源鏈接改為HTTPS或使用協(xié)議相對(duì)URL。性能問(wèn)題TLS握手慢可能是由于客戶端或服務(wù)器不支持會(huì)話恢復(fù)或者OCSP查詢被墻/慢。優(yōu)化啟用ssl_session_cache和ssl_session_tickets配置OCSP Stapling。CPU占用高大量HTTPS連接加解密消耗CPU。優(yōu)化啟用TLS硬件加速如果服務(wù)器支持考慮使用更高效的ECDSA證書相比RSA升級(jí)到支持AES-NI指令集的CPU。后端服務(wù)獲取客戶端真實(shí)IP問(wèn)題當(dāng)網(wǎng)站前端有負(fù)載均衡器如Nginx或CDN做HTTPS終結(jié)Termination時(shí)后端應(yīng)用服務(wù)器收到的請(qǐng)求來(lái)自負(fù)載均衡器其源IP是負(fù)載均衡器的IP而非真實(shí)用戶IP。解決負(fù)載均衡器需要在轉(zhuǎn)發(fā)請(qǐng)求的HTTP頭中如X-Forwarded-For或X-Real-IP添加用戶的真實(shí)IP。后端應(yīng)用需要讀取這個(gè)頭部而非直接取TCP連接的遠(yuǎn)程地址。理解HTTP和HTTPS不僅僅是背下幾個(gè)面試題答案更是構(gòu)建安全、可靠、高性能Web應(yīng)用的基石。從簡(jiǎn)單的明文傳輸?shù)綇?fù)雜的加密握手從無(wú)狀態(tài)請(qǐng)求到有狀態(tài)會(huì)話管理每一步演進(jìn)都對(duì)應(yīng)著真實(shí)世界的需求與挑戰(zhàn)。在實(shí)際工作中無(wú)論是設(shè)計(jì)API、配置服務(wù)器、調(diào)試跨域問(wèn)題還是優(yōu)化頁(yè)面加載速度這些知識(shí)都會(huì)時(shí)刻發(fā)揮作用。我的建議是在本地環(huán)境用Wireshark抓一下HTTP包用openssl命令模擬一下TLS握手親手配置一遍Nginx的HTTPS這些實(shí)操帶來(lái)的理解遠(yuǎn)比讀十篇文章要深刻。技術(shù)總是在發(fā)展HTTP/3和QUIC正在走來(lái)但牢牢掌握這些基礎(chǔ)原理會(huì)讓你在面對(duì)任何新協(xié)議時(shí)都能快速抓住本質(zhì)。