一、前言：

先來觀察這兩張圖，第一張訪問域名http://www.12306.cn，谷歌瀏覽器提示不安全鏈接，第二張是https://kyfw.12306.cn/otn/regist/init，瀏覽器顯示安全，為什么會這樣子呢？2017年1月發(fā)布的Chrome 56瀏覽器開始把收集密碼或信用卡數(shù)據(jù)的HTTP頁面標記為“不安全”，若用戶使用2017年10月推出的Chrome 62，帶有輸入數(shù)據(jù)的HTTP頁面和所有以無痕模式瀏覽的HTTP頁面都會被標記為“不安全”，此外，蘋果公司強制所有iOS App在2017年1月1日前使用HTTPS加密。

二、HTTP和HTTPS發(fā)展歷史

什么是HTTP?

超文本傳輸協(xié)議，是一個基于請求與響應，無狀態(tài)的，應用層的協(xié)議，常基于TCP/IP協(xié)議傳輸數(shù)據(jù)，互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議,所有的WWW文件都必須遵守這個標準。設計HTTP的初衷是為了提供一種發(fā)布和接收HTML頁面的方法。

發(fā)展歷史：

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

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

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

HTTP報文格式

什么是HTTPS？

《圖解HTTP》這本書中曾提過HTTPS是身披SSL外殼的HTTP。HTTPS是一種通過計算機網(wǎng)絡進行安全通信的傳輸協(xié)議，經(jīng)由HTTP進行通信，利用SSL/TLS建立全信道，加密數(shù)據(jù)包。HTTPS使用的主要目的是提供對網(wǎng)站服務器的身份認證，同時保護交換數(shù)據(jù)的隱私與完整性。

PS:TLS是傳輸層加密協(xié)議，前身是SSL協(xié)議，由網(wǎng)景公司1995年發(fā)布，有時候兩者不區(qū)分。

參考連接：

1.https://kamranahmed.info/blog/2016/08/13/http-in-depth/

2.https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

3.https://tools.ietf.org/html/rfc1945

4.https://http2.github.io/http2-spec/

5.https://www.zhihu.com/question/34074946

三、HTTP VS HTTPS

HTTP特點：

1. 無狀態(tài)：協(xié)議對客戶端沒有狀態(tài)存儲，對事物處理沒有“記憶”能力，比如訪問一個網(wǎng)站需要反復進行登錄操作
2. 無連接：HTTP/1.1之前，由于無狀態(tài)特點，每次請求需要通過TCP三次握手四次揮手，和服務器重新建立連接。比如某個客戶機在短時間多次請求同一個資源，服務器并不能區(qū)別是否已經(jīng)響應過用戶的請求，所以每次需要重新響應請求，需要耗費不必要的時間和流量。
3. 基于請求和響應：基本的特性，由客戶端發(fā)起請求，服務端響應
4. 簡單快速、靈活
5. 通信使用明文、請求和響應不會對通信方進行確認、無法保護數(shù)據(jù)的完整性

下面通過一個簡單的抓包實驗觀察使用HTTP請求傳輸?shù)臄?shù)據(jù)：

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

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

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

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

HTTPS特點：

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

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

1. 內容加密：采用混合加密技術，中間者無法直接查看明文內容
2. 驗證身份：通過證書認證客戶端訪問的是自己的服務器
3. 保護數(shù)據(jù)完整性：防止傳輸?shù)膬热荼恢虚g人冒充或者篡改

**混合加密：**結合非對稱加密和對稱加密技術。客戶端使用對稱加密生成密鑰對傳輸數(shù)據(jù)進行加密，然后使用非對稱加密的公鑰再對秘鑰進行加密，所以網(wǎng)絡上傳輸?shù)臄?shù)據(jù)是被秘鑰加密的密文和用公鑰加密后的秘密秘鑰，因此即使被黑客截取，由于沒有私鑰，無法獲取到加密明文的秘鑰，便無法獲取到明文數(shù)據(jù)。

**數(shù)字摘要：**通過單向hash函數(shù)對原文進行哈希，將需加密的明文“摘要”成一串固定長度(如128bit)的密文，不同的明文摘要成的密文其結果總是不相同，同樣的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文。

**數(shù)字簽名技術：**數(shù)字簽名建立在公鑰加密體制基礎上，是公鑰加密技術的另一類應用。它把公鑰加密技術和數(shù)字摘要結合起來，形成了實用的數(shù)字簽名技術。

• 收方能夠證實發(fā)送方的真實身份；
• 發(fā)送方事后不能否認所發(fā)送過的報文；
• 收方或非法者不能偽造、篡改報文。

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

四、HTTP通信傳輸

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

報文從運用層傳送到運輸層，運輸層通過TCP三次握手和服務器建立連接，四次揮手釋放連接。

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

比如：client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段，但是server收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個新的連接請求，于是就向client發(fā)出確認報文段，同意建立連接。假設不采用“三次握手”，那么只要server發(fā)出確認，新的連接就建立了，由于client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認，也不會向server發(fā)送數(shù)據(jù)，但server卻以為新的運輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。所以沒有采用“三次握手”，這種情況下server的很多資源就白白浪費掉了。

為什么需要四次揮手呢？TCP是全雙工模式，當client發(fā)出FIN報文段時，只是表示client已經(jīng)沒有數(shù)據(jù)要發(fā)送了，client告訴server，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是，這個時候client還是可以接受來server的數(shù)據(jù)；當server返回ACK報文段時，表示它已經(jīng)知道client沒有數(shù)據(jù)發(fā)送了，但是server還是可以發(fā)送數(shù)據(jù)到client的；當server也發(fā)送了FIN報文段時，這個時候就表示server也沒有數(shù)據(jù)要發(fā)送了，就會告訴client，我也沒有數(shù)據(jù)要發(fā)送了，如果收到client確認報文段，之后彼此就會愉快的中斷這次TCP連接。

五、HTTPS實現(xiàn)原理

SSL建立連接過程

1. client向server發(fā)送請求https://baidu.com，然后連接到server的443端口，發(fā)送的信息主要是隨機值1和客戶端支持的加密算法。
2. server接收到信息之后給予client響應握手信息，包括隨機值2和匹配好的協(xié)商加密算法，這個加密算法一定是client發(fā)送給server加密算法的子集。
3. 隨即server給client發(fā)送第二個響應報文是數(shù)字證書。服務端必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請。區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面，這套證書其實就是一對公鑰和私鑰。傳送證書，這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發(fā)機構，過期時間、服務端的公鑰，第三方證書認證機構(CA)的簽名，服務端的域名信息等內容。
4. 客戶端解析證書，這部分工作是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發(fā)機構，過期時間等等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個隨即值（預主秘鑰）。
5. 客戶端認證證書通過之后，接下來是通過隨機值1、隨機值2和預主秘鑰組裝會話秘鑰。然后通過證書的公鑰加密會話秘鑰。
6. 傳送加密信息，這部分傳送的是用證書加密后的會話秘鑰，目的就是讓服務端使用秘鑰解密得到隨機值1、隨機值2和預主秘鑰。
7. 服務端解密得到隨機值1、隨機值2和預主秘鑰，然后組裝會話秘鑰，跟客戶端會話秘鑰相同。
8. 客戶端通過會話秘鑰加密一條消息發(fā)送給服務端，主要驗證服務端是否正常接受客戶端加密的消息。
9. 同樣服務端也會通過會話秘鑰加密一條消息回傳給客戶端，如果客戶端能夠正常接受的話表明SSL層連接建立完成了。

問題：
1.怎么保證保證服務器給客戶端下發(fā)的公鑰是真正的公鑰，而不是中間人偽造的公鑰呢？

2.證書如何安全傳輸，被掉包了怎么辦？

數(shù)字證書內容
包括了加密后服務器的公鑰、權威機構的信息、服務器域名，還有經(jīng)過CA私鑰簽名之后的證書內容（經(jīng)過先通過Hash函數(shù)計算得到證書數(shù)字摘要，然后用權威機構私鑰加密數(shù)字摘要得到數(shù)字簽名)，簽名計算方法以及證書對應的域名。

驗證證書安全性過程

1. 當客戶端收到這個證書之后，使用本地配置的權威機構的公鑰對證書進行解密得到服務端的公鑰和證書的數(shù)字簽名，數(shù)字簽名經(jīng)過CA公鑰解密得到證書信息摘要。
2. 然后證書簽名的方法計算一下當前證書的信息摘要，與收到的信息摘要作對比，如果一樣，表示證書一定是服務器下發(fā)的，沒有被中間人篡改過。因為中間人雖然有權威機構的公鑰，能夠解析證書內容并篡改，但是篡改完成之后中間人需要將證書重新加密，但是中間人沒有權威機構的私鑰，無法加密，強行加密只會導致客戶端無法解密，如果中間人強行亂修改證書，就會導致證書內容和證書簽名不匹配。

那第三方攻擊者能否讓自己的證書顯示出來的信息也是服務端呢？（偽裝服務端一樣的配置）顯然這個是不行的，因為當?shù)谌焦粽呷A那邊尋求認證的時候CA會要求其提供例如域名的whois信息、域名管理郵箱等證明你是服務端域名的擁有者，而第三方攻擊者是無法提供這些信息所以他就是無法騙CA他擁有屬于服務端的域名。

六、運用與總結

安全性考慮：

1. HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什么作用
2. SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行

中間人攻擊（MITM攻擊）是指，黑客攔截并篡改網(wǎng)絡中的通信數(shù)據(jù)。又分為被動MITM和主動MITM，被動MITM只竊取通信數(shù)據(jù)而不修改，而主動MITM不但能竊取數(shù)據(jù)，還會篡改通信數(shù)據(jù)。最常見的中間人攻擊常常發(fā)生在公共wifi或者公共路由上。

成本考慮：

1. SSL證書需要購買申請，功能越強大的證書費用越高
2. SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、操作系統(tǒng)支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。
3. 根據(jù)ACM CoNEXT數(shù)據(jù)顯示，使用HTTPS協(xié)議會使頁面的加載時間延長近50%，增加10%到20%的耗電。
4. HTTPS連接緩存不如HTTP高效，流量成本高。
5. HTTPS連接服務器端資源占用高很多，支持訪客多的網(wǎng)站需要投入更大的成本。
6. HTTPS協(xié)議握手階段比較費時，對網(wǎng)站的響應速度有影響，影響用戶體驗。比較好的方式是采用分而治之，類似12306網(wǎng)站的主頁使用HTTP協(xié)議，有關于用戶信息等方面使用HTTPS。

最后插播下廣告，對IOS感興趣的或者校招同學可以看這兩篇文章-：
看一篇就夠入門Objective-C
手把手教學IOS自定義cell-仿微信消息列表
面試必備操作系統(tǒng)

總結

以上是生活随笔為你收集整理的http协议详解(HTTP协议是一种什么协议)(HTTP协议超级详解)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。