一禁谦、HTTP和HTTPS發(fā)展歷史

• 什么是HTTP?

超文本傳輸協(xié)議绝编，是一個(gè)基于請求與響應(yīng)僻澎，無狀態(tài)的，應(yīng)用層的協(xié)議十饥，晨卟基于TCP/IP協(xié)議傳輸數(shù)據(jù)，互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)逗堵。設(shè)計(jì)HTTP的初衷是為了提供一種發(fā)布和接收HTML頁面的方法秉氧。

• 發(fā)展歷史：

  版本	產(chǎn)生時(shí)間	內(nèi)容	發(fā)展現(xiàn)狀
  HTTP/0.9	1991年	不涉及數(shù)據(jù)包傳輸，規(guī)定客戶端和服務(wù)器之間通信格式蜒秤，只能GET請求	沒有作為正式的標(biāo)準(zhǔn)
  HTTP/1.0	1996年	傳輸內(nèi)容格式不限制汁咏，增加PUT、PATCH作媚、HEAD攘滩、 OPTIONS、DELETE命令	正式作為標(biāo)準(zhǔn)
  HTTP/1.1	1997年	持久連接(長連接)纸泡、節(jié)約帶寬漂问、HOST域、管道機(jī)制、分塊傳輸編碼	2015年前使用最廣泛
  HTTP/2	2015年	多路復(fù)用蚤假、服務(wù)器推送栏饮、頭信息壓縮、二進(jìn)制協(xié)議等	逐漸覆蓋市場

  這個(gè)Akamai公司建立的一個(gè)官方的演示磷仰，使用HTTP/1.1和HTTP/2同時(shí)請求379張圖片抡爹，觀察請求的時(shí)間，明顯看出HTTP/2性能占優(yōu)勢芒划。

  
  
  image.png
  
  

  多路復(fù)用：通過單一的HTTP/2連接請求發(fā)起多重的請求-響應(yīng)消息冬竟，多個(gè)請求stream共享一個(gè)TCP連接，實(shí)現(xiàn)多留并行而不是依賴建立多個(gè)TCP連接民逼。

• HTTP報(bào)文格式
  image.png

• 什么是HTTPS泵殴？

《圖解HTTP》這本書中曾提過HTTPS是身披SSL外殼的HTTP。HTTPS是一種通過計(jì)算機(jī)網(wǎng)絡(luò)進(jìn)行安全通信的傳輸協(xié)議拼苍，經(jīng)由HTTP進(jìn)行通信笑诅，利用SSL/TLS建立全信道，加密數(shù)據(jù)包疮鲫。HTTPS使用的主要目的是提供對網(wǎng)站服務(wù)器的身份認(rèn)證吆你，同時(shí)保護(hù)交換數(shù)據(jù)的隱私與完整性。
PS:TLS是傳輸層加密協(xié)議俊犯，前身是SSL協(xié)議妇多，由網(wǎng)景公司1995年發(fā)布，有時(shí)候兩者不區(qū)分燕侠。

二者祖、HTTP VS HTTPS

HTTP特點(diǎn)：

• 無狀態(tài)：協(xié)議對客戶端沒有狀態(tài)存儲，對事物處理沒有“記憶”能力绢彤，比如訪問一個(gè)網(wǎng)站需要反復(fù)進(jìn)行登錄操作
• 無連接：HTTP/1.1之前七问，由于無狀態(tài)特點(diǎn)，每次請求需要通過TCP三次握手四次揮手茫舶，和服務(wù)器重新建立連接械巡。比如某個(gè)客戶機(jī)在短時(shí)間多次請求同一個(gè)資源，服務(wù)器并不能區(qū)別是否已經(jīng)響應(yīng)過用戶的請求饶氏，所以每次需要重新響應(yīng)請求讥耗，需要耗費(fèi)不必要的時(shí)間和流量。
• 基于請求和響應(yīng)：基本的特性嚷往，由客戶端發(fā)起請求葛账，服務(wù)端響應(yīng)
• 簡單快速、靈活
• 通信使用明文皮仁、請求和響應(yīng)不會對通信方進(jìn)行確認(rèn)、無法保護(hù)數(shù)據(jù)的完整性
  下面通過一個(gè)簡單的抓包實(shí)驗(yàn)觀察使用HTTP請求傳輸?shù)臄?shù)據(jù)：

結(jié)果分析：HTTP協(xié)議傳輸數(shù)據(jù)以明文形式顯示

針對無狀態(tài)的一些解決策略：

場景：逛電商商場用戶需要使用的時(shí)間比較長，需要對用戶一段時(shí)間的HTTP通信狀態(tài)進(jìn)行保存贷祈，比如執(zhí)行一次登陸操作趋急，在30分鐘內(nèi)所有的請求都不需要再次登陸。

通過Cookie/Session技術(shù)
HTTP/1.1持久連接（HTTP keep-alive）方法势誊，只要任意一端沒有明確提出斷開連接呜达，則保持TCP連接狀態(tài)，在請求首部字段中的Connection: keep-alive即為表明使用了持久連接

HTTPS特點(diǎn)：

• 基于HTTP協(xié)議粟耻，通過SSL或TLS提供加密處理數(shù)據(jù)查近、驗(yàn)證對方身份以及數(shù)據(jù)完整性保護(hù)

• 通過抓包可以看到數(shù)據(jù)不是明文傳輸，而且HTTPS有如下特點(diǎn)：

• 內(nèi)容加密：采用混合加密技術(shù)挤忙，中間者無法直接查看明文內(nèi)容

• 驗(yàn)證身份：通過證書認(rèn)證客戶端訪問的是自己的服務(wù)器

• 保護(hù)數(shù)據(jù)完整性：防止傳輸?shù)膬?nèi)容被中間人冒充或者篡改

混合加密：結(jié)合非對稱加密和對稱加密技術(shù)霜威。客戶端使用對稱加密生成密鑰對傳輸數(shù)據(jù)進(jìn)行加密册烈，然后使用非對稱加密的公鑰再對秘鑰進(jìn)行加密戈泼，所以網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)是被秘鑰加密的密文和用公鑰加密后的秘密秘鑰，因此即使被黑客截取赏僧，由于沒有私鑰大猛，無法獲取到加密明文的秘鑰，便無法獲取到明文數(shù)據(jù)淀零。
數(shù)字摘要：通過單向hash函數(shù)對原文進(jìn)行哈希挽绩，將需加密的明文“摘要”成一串固定長度(如128bit)的密文，不同的明文摘要成的密文其結(jié)果總是不相同驾中，同樣的明文其摘要必定一致琼牧，并且即使知道了摘要也不能反推出明文。
數(shù)字簽名技術(shù)：數(shù)字簽名建立在公鑰加密體制基礎(chǔ)上哀卫，是公鑰加密技術(shù)的另一類應(yīng)用巨坊。它把公鑰加密技術(shù)和數(shù)字摘要結(jié)合起來，形成了實(shí)用的數(shù)字簽名技術(shù)此改。

• 收方能夠證實(shí)發(fā)送方的真實(shí)身份趾撵；
• 發(fā)送方事后不能否認(rèn)所發(fā)送過的報(bào)文；
• 收方或非法者不能偽造共啃、篡改報(bào)文占调。

image.png

非對稱加密過程需要用到公鑰進(jìn)行加密，那么公鑰從何而來移剪？其實(shí)公鑰就被包含在數(shù)字證書中究珊，數(shù)字證書通常來說是由受信任的數(shù)字證書頒發(fā)機(jī)構(gòu)CA，在驗(yàn)證服務(wù)器身份后頒發(fā)纵苛，證書中包含了一個(gè)密鑰對（公鑰和私鑰）和所有者識別信息剿涮。數(shù)字證書被放到服務(wù)端言津，具有服務(wù)器身份驗(yàn)證和數(shù)據(jù)傳輸加密功能。

三取试、HTTP通信傳輸

image.png

客戶端輸入U(xiǎn)RL回車悬槽，DNS解析域名得到服務(wù)器的IP地址，服務(wù)器在80端口監(jiān)聽客戶端請求瞬浓，端口通過TCP/IP協(xié)議（可以通過Socket實(shí)現(xiàn)）建立連接初婆。HTTP屬于TCP/IP模型中的運(yùn)用層協(xié)議，所以通信的過程其實(shí)是對應(yīng)數(shù)據(jù)的入棧和出棧猿棉。

報(bào)文從運(yùn)用層傳送到運(yùn)輸層磅叛，運(yùn)輸層通過TCP三次握手和服務(wù)器建立連接，四次揮手釋放連接萨赁。

為什么需要三次握手呢弊琴？為了防止已失效的連接請求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤位迂。

• 防止舊的重復(fù)連接初始化造成混亂访雪，避免資源浪費(fèi)。

謝希仁版《計(jì)算機(jī)網(wǎng)絡(luò)》中的例子是這樣的掂林，“已失效的連接請求報(bào)文段” 的產(chǎn)生在這樣一種情況下：
client發(fā)出的第一個(gè)連接請求報(bào)文段并沒有丟失臣缀，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server泻帮。本來這是一個(gè)早已失效的報(bào)文段精置，但是server收到此失效的連接請求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請求锣杂，于是就向client發(fā)出確認(rèn)報(bào)文段脂倦，同意建立連接。
假設(shè)不采用“三次握手”元莫，那么只要server發(fā)出確認(rèn)赖阻，新的連接就建立了，由于client并沒有發(fā)出建立連接的請求踱蠢，因此不會理睬server的確認(rèn)火欧，也不會向server發(fā)送數(shù)據(jù)，但server卻以為新的運(yùn)輸連接已經(jīng)建立茎截，并一直等待client發(fā)來數(shù)據(jù)苇侵。所以沒有采用“三次握手”，這種情況下server的很多資源就白白浪費(fèi)掉了企锌。
白話一點(diǎn)就是榆浓，如果只有兩次握手，那么：
1. A 向 B 發(fā)送了第一個(gè)請求撕攒，但是因?yàn)榫W(wǎng)絡(luò)堵塞沒有到達(dá)
2. 超時(shí)后陡鹃，于是 A 又發(fā)送了第二個(gè)請求烘浦，這此正常到達(dá)，而且 B 回復(fù)收到了
3. A 這時(shí)就開始和 B 相互通信杉适，并一段時(shí)間后結(jié)束了連接
4. 此時(shí)最開始的請求到達(dá)了 B谎倔，B 以為 A 又請求了連接柳击，并且回復(fù)了 A
5. 但 A 認(rèn)為自己并沒有發(fā)送請求猿推，所以并不會理睬 B， B 就只能一直等著

• 同步雙方的初始序列號

三次握手主要是為了初始化 Sequence Number,即上述中的 seq捌肴，seq的作用就是確保數(shù)據(jù)包的有序傳輸蹬叭，數(shù)據(jù)也是通過 seq 進(jìn)行數(shù)據(jù)的拼接
舉例：
1. 客戶端先發(fā)送了一個(gè)請求連接的數(shù)據(jù)包，初始 seq = 100 状知， 因?yàn)榫W(wǎng)絡(luò)阻塞收不到回復(fù)秽五，于是又發(fā)送了一個(gè)請求連接的數(shù)據(jù)包，初始 seq = 200
2. 此時(shí)網(wǎng)絡(luò)又恢復(fù)了正常饥悴，服務(wù)端接收到了最開始發(fā)送的 seq = 100坦喘， 于是返回 ack = 101
3. 客戶端比較上下文，發(fā)現(xiàn)自己希望收到的 ack 應(yīng)該是 201西设，于是發(fā)送了 RST 給服務(wù)端瓣铣，中止連接。
4. 一段時(shí)間后 seq = 200 到達(dá)了服務(wù)端贷揽，并返回了 ack = 201 以及自己的 seq 客戶端確認(rèn)信息棠笑，返回服務(wù)端的 seq + 1，建立TCP連接

為什么需要四次揮手呢禽绪？

TCP是全雙工模式蓖救，當(dāng)client發(fā)出FIN報(bào)文段時(shí)，只是表示client已經(jīng)沒有數(shù)據(jù)要發(fā)送了印屁，client告訴server循捺，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是雄人，這個(gè)時(shí)候client還是可以接受來server的數(shù)據(jù)从橘；當(dāng)server返回ACK報(bào)文段時(shí)，表示它已經(jīng)知道client沒有數(shù)據(jù)發(fā)送了柠衍，但是server還是可以發(fā)送數(shù)據(jù)到client的洋满；當(dāng)server也發(fā)送了FIN報(bào)文段時(shí)，這個(gè)時(shí)候就表示server也沒有數(shù)據(jù)要發(fā)送了珍坊，就會告訴client牺勾，我也沒有數(shù)據(jù)要發(fā)送了，如果收到client確認(rèn)報(bào)文段阵漏，之后彼此就會愉快的中斷這次TCP連接驻民。

四翻具、HTTPS實(shí)現(xiàn)原理

SSL建立連接過程：

1. client向server發(fā)送請求https://baidu.com，然后連接到server的443端口回还，首先正常的TCP三次握手是不變的裆泳，客戶端會在第三次TCP握手或者在新發(fā)送的TCP報(bào)文段中發(fā)送的信息主要是隨機(jī)值1和客戶端支持的加密算法。
2. server接收到信息之后給予client響應(yīng)握手信息柠硕，包括隨機(jī)值2和匹配好的協(xié)商加密算法工禾，這個(gè)加密算法一定是client發(fā)送給server加密算法的子集。
3. 隨即server給client發(fā)送第二個(gè)響應(yīng)報(bào)文是數(shù)字證書蝗柔。服務(wù)端必須要有一套數(shù)字證書闻葵，可以自己制作，也可以向組織申請癣丧。區(qū)別就是自己頒發(fā)的證書需要客戶端驗(yàn)證通過槽畔，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面胁编，這套證書其實(shí)就是一對公鑰和私鑰厢钧。傳送證書，這個(gè)證書其實(shí)就是公鑰嬉橙，只是包含了很多信息早直，如證書的頒發(fā)機(jī)構(gòu)，過期時(shí)間憎夷、服務(wù)端的公鑰莽鸿，第三方證書認(rèn)證機(jī)構(gòu)(CA)的簽名，服務(wù)端的域名信息等內(nèi)容拾给。
4. 客戶端解析證書祥得，這部分工作是由客戶端的TLS來完成的，首先會驗(yàn)證公鑰是否有效蒋得，比如頒發(fā)機(jī)構(gòu)级及，過期時(shí)間等等，如果發(fā)現(xiàn)異常额衙，則會彈出一個(gè)警告框饮焦，提示證書存在問題。如果證書沒有問題窍侧，那么就生成一個(gè)隨即值（預(yù)主秘鑰）县踢。
5. 客戶端認(rèn)證證書通過之后，接下來是通過隨機(jī)值1伟件、隨機(jī)值2和預(yù)主秘鑰組裝會話秘鑰硼啤。然后通過證書的公鑰加密會話秘鑰。
6. 傳送加密信息斧账，這部分傳送的是用證書加密后的會話秘鑰谴返，目的就是讓服務(wù)端使用秘鑰解密得到隨機(jī)值1煞肾、隨機(jī)值2和預(yù)主秘鑰。
7. 服務(wù)端解密得到隨機(jī)值1嗓袱、隨機(jī)值2和預(yù)主秘鑰籍救，然后組裝會話秘鑰，跟客戶端會話秘鑰相同渠抹。
8. 客戶端通過會話秘鑰加密一條消息發(fā)送給服務(wù)端蝙昙，主要驗(yàn)證服務(wù)端是否正常接受客戶端加密的消息。
9. 同樣服務(wù)端也會通過會話秘鑰加密一條消息回傳給客戶端逼肯，如果客戶端能夠正常接受的話表明SSL層連接建立完成了耸黑。

那么問題來了：

1.怎么保證保證服務(wù)器給客戶端下發(fā)的公鑰是真正的公鑰桃煎，而不是中間人偽造的公鑰呢篮幢？
2.證書如何安全傳輸，被掉包了怎么辦为迈？

數(shù)字證書內(nèi)容
包括了加密后服務(wù)器的公鑰三椿、權(quán)威機(jī)構(gòu)的信息、服務(wù)器域名葫辐，還有經(jīng)過CA私鑰簽名之后的證書內(nèi)容（經(jīng)過先通過Hash函數(shù)計(jì)算得到證書數(shù)字摘要搜锰，然后用權(quán)威機(jī)構(gòu)私鑰加密數(shù)字摘要得到數(shù)字簽名)，簽名計(jì)算方法以及證書對應(yīng)的域名耿战。

驗(yàn)證證書安全性過程
當(dāng)客戶端收到這個(gè)證書之后蛋叼，使用本地配置的權(quán)威機(jī)構(gòu)的公鑰對證書進(jìn)行解密得到服務(wù)端的公鑰和證書的數(shù)字簽名，數(shù)字簽名經(jīng)過CA公鑰解密得到證書信息摘要剂陡。
然后證書簽名的方法計(jì)算一下當(dāng)前證書的信息摘要狈涮，與收到的信息摘要作對比，如果一樣鸭栖，表示證書一定是服務(wù)器下發(fā)的歌馍，沒有被中間人篡改過。因?yàn)橹虚g人雖然有權(quán)威機(jī)構(gòu)的公鑰晕鹊，能夠解析證書內(nèi)容并篡改松却，但是篡改完成之后中間人需要將證書重新加密，但是中間人沒有權(quán)威機(jī)構(gòu)的私鑰溅话，無法加密晓锻，強(qiáng)行加密只會導(dǎo)致客戶端無法解密，如果中間人強(qiáng)行亂修改證書飞几，就會導(dǎo)致證書內(nèi)容和證書簽名不匹配砚哆。
那第三方攻擊者能否讓自己的證書顯示出來的信息也是服務(wù)端呢？（偽裝服務(wù)端一樣的配置）顯然這個(gè)是不行的循狰，因?yàn)楫?dāng)?shù)谌焦粽呷A那邊尋求認(rèn)證的時(shí)候CA會要求其提供例如域名的whois信息窟社、域名管理郵箱等證明你是服務(wù)端域名的擁有者券勺，而第三方攻擊者是無法提供這些信息所以他就是無法騙CA他擁有屬于服務(wù)端的域名。

五灿里、運(yùn)用與總結(jié)

安全性考慮：

• HTTPS協(xié)議的加密范圍也比較有限关炼，在黑客攻擊、拒絕服務(wù)攻擊匣吊、服務(wù)器劫持等方面幾乎起不到什么作用
• SSL證書的信用鏈體系并不安全儒拂，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行
  中間人攻擊（MITM攻擊）是指色鸳，黑客攔截并篡改網(wǎng)絡(luò)中的通信數(shù)據(jù)社痛。又分為被動MITM和主動MITM，被動MITM只竊取通信數(shù)據(jù)而不修改命雀，而主動MITM不但能竊取數(shù)據(jù)蒜哀，還會篡改通信數(shù)據(jù)。最常見的中間人攻擊常常發(fā)生在公共wifi或者公共路由上吏砂。

成本考慮：

• SSL證書需要購買申請撵儿，功能越強(qiáng)大的證書費(fèi)用越高
• SSL證書通常需要綁定IP，不能在同一IP上綁定多個(gè)域名狐血，IPv4資源不可能支撐這個(gè)消耗（SSL有擴(kuò)展可以部分解決這個(gè)問題淀歇，但是比較麻煩，而且要求瀏覽器匈织、操作系統(tǒng)支持浪默，Windows XP就不支持這個(gè)擴(kuò)展，考慮到XP的裝機(jī)量缀匕，這個(gè)特性幾乎沒用）纳决。
• 根據(jù)ACM CoNEXT數(shù)據(jù)顯示，使用HTTPS協(xié)議會使頁面的加載時(shí)間延長近50%弦追，增加10%到20%的耗電岳链。
• HTTPS連接緩存不如HTTP高效，流量成本高劲件。
• HTTPS連接服務(wù)器端資源占用高很多掸哑，支持訪客多的網(wǎng)站需要投入更大的成本。
• HTTPS協(xié)議握手階段比較費(fèi)時(shí)零远，對網(wǎng)站的響應(yīng)速度有影響苗分，影響用戶體驗(yàn)。比較好的方式是采用分而治之牵辣，類似12306網(wǎng)站的主頁使用HTTP協(xié)議摔癣，有關(guān)于用戶信息等方面使用HTTPS。