全面瞭解HTTP和HTTPS

引用自：https://www.cnblogs.com/jsersudo/p/10341036.html

序言

Http和Https屬於計算機網絡範疇，但做爲開發人員，無論是後臺開發或是前臺開發，都頗有必要掌握它們。
在學習Http和Https的過程當中，主要是參考了阮一峯老師的博客，講的很全面，而且通俗易懂，有興趣的同窗能夠去學習學習。
這篇文章主要是按照本身的思路來說解對Http和Https的理解。文章將會從如下幾個方面介紹。

目錄樹（暫時還不知道簡書編輯器怎麼經過目錄樹進行頁面內跳轉，哪位同窗知道但願不吝告知）：

• 1、網絡層結構
• 2、Http協議
• 3、Tcp三次握手
• 4、Https協議/SSL協議
• 5、SSL證書
• 6、RSA加密和DH加密
• 7、Http和Https對比

從目錄結構能夠看出，每一個標題展開來講都是一個很大的主題。但本文旨在讓各位同窗對Http和Https相關知識有一個全面的認知，不會太過深刻探討各個主題，有興趣的同窗能夠進行鍼對性研究。

1、網絡層結構

網絡結構有兩種主流的分層方式：OSI七層模型和TCP/IP四層模型。

OSI七層模型和TCP/IP四層模型

OSI是指Open System Interconnect，意爲開放式系統互聯。
TCP/IP是指傳輸控制協議/網間協議，是目前世界上應用最廣的協議。

OSI層	對應TCP/IP層	OSI各層功能	網絡協議	設備
應用層	應用層	應用程序（電子郵件，文件服務）,用戶接口	HTTP，FTP，TFTP，NFS	網關
表示層	應用層	數據的表示，壓縮和加密（數據格式化，代碼轉換，數據加密）	TELNET，SNMP	網關
會話層	應用層	創建、管理和終止會話	SMTP，DNS	網關
傳輸層	傳輸層	提供端到端可靠報文段傳遞和錯誤恢復	TCP，UDP	網關
網絡層	網際互聯層	提供數據包從源到宿的傳遞和網際交互	IP，ICMP，ARP，RARP，UUCP	路由器
鏈路層	網絡接口層	將比特組裝成幀和點到點傳遞	FDDI，SLIP，PPP，PDN	交換機
物理層	網絡接口層	傳輸比特流，以二進制數據形式在物理媒體上傳輸數據	ISO2110，IEEE802，IEEE802.2	集線器，中繼器

兩種模型區別

1. OSI採用七層模型，TCP/IP是四層模型
2. TCP/IP網絡接口層沒有真正的定義，只是概念性的描述。OSI把它分爲2層，每一層功能詳盡。
3. 在協議開發以前，就有了OSI模型，因此OSI模型具備共通性，而TCP/IP是基於協議創建的模型，不適用於非TCP/IP的網絡。
4. 實際應用中，OSI模型是理論上的模型，沒有成熟的產品；而TCP/IP已經成爲國際標準。

2、HTTP協議

Http是基於TCP/IP協議的應用程序協議，不包括數據包的傳輸，主要規定了客戶端和服務器的通訊格式，默認使用80端口。

Http協議的發展歷史

1. 1991年發佈Http/0.9版本，只有Get命令，且服務端直返HTML格式字符串，服務器響應完畢就關閉TCP鏈接。
2. 1996年發佈Http/1.0版本，優勢：能夠發送任何格式內容，包括文字、圖像、視頻、二進制。也豐富了命令Get，Post，Head。請求和響應的格式加入頭信息。缺點：每一個TCP鏈接只能發送一個請求，而新建TCP鏈接的成本很高，致使Http/1.0新能不好。
3. 1997發佈Http/1.1版本，完善了Http協議，直至20年後的今天還是最流行的版本。
   優勢：a. 引入持久鏈接，TCP默認不關閉，可被多個請求複用，對於一個域名，多數瀏覽器容許同時創建6個持久鏈接。b. 引入管道機制，即在同一個TCP鏈接中，能夠同時發送多個請求，不過服務器仍是按順序響應。c. 在頭部加入Content-Length字段，一個TCP能夠同時傳送多個響應，因此就須要該字段來區分哪些內容屬於哪一個響應。d. 分塊傳輸編碼，對於耗時的動態操做，用流模式取代緩存模式，即產生一塊數據，就發送一塊數據。e. 增長了許多命令，頭信息增長Host來指定服務器域名，能夠訪問一臺服務器上的不一樣網站。
   缺點：TCP鏈接中的響應有順序，服務器處理完一個迴應才能處理下一個迴應，若是某個迴應特別慢，後面的請求就會排隊等着（對頭堵塞）。
4. 2015年發佈Http/2版本，它有幾個特性：二進制協議、多工、數據流、頭信息壓縮、服務器推送。

Http請求和響應格式

Request格式：

GET /barite/account/stock/groups HTTP/1.1 QUARTZ-SESSION: MC4xMDQ0NjA3NTI0Mzc0MjAyNg.VPXuA8rxTghcZlRCfiAwZlAIdCA DEVICE-TYPE: ANDROID API-VERSION: 15 Host: shitouji.bluestonehk.com Connection: Keep-Alive Accept-Encoding: gzip User-Agent: okhttp/3.10.0 

Response格式：

HTTP/1.1 200 OK Server: nginx/1.6.3 Date: Mon, 15 Oct 2018 03:30:28 GMT Content-Type: application/json;charset=UTF-8 Pragma: no-cache Cache-Control: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Encoding: gzip Transfer-Encoding: chunked Proxy-Connection: Keep-alive {"errno":0,"dialogInfo":null,"body":{"list":[{"flag":2,"group_id":1557,"group_name":"港股","count":1},{"flag":3,"group_id":1558,"group_name":"美股","count":7},{"flag":1,"group_id":1556,"group_name":"所有","count":8}]},"message":"success"} 

說明一下請求頭和響應頭的部分字段：

• Host：指定服務器域名，可用來區分訪問一個服務器上的不一樣服務
• Connection：keep-alive表示要求服務器不要關閉TCP鏈接，close表示明確要求關閉鏈接，默認值是keep-alive
• Accept-Encoding：說明本身能夠接收的壓縮方式
• User-Agent：用戶代理，是服務器能識別客戶端的操做系統（Android、IOS、WEB）及相關的信息。做用是幫助服務器區分客戶端，而且針對不一樣客戶端讓用戶看到不一樣數據，作不一樣操做。
• Content-Type：服務器告訴客戶端數據的格式，常見的值有text/plain，image/jpeg，image/png，video/mp4，application/json，application/zip。這些數據類型總稱爲MIME TYPE。
• Content-Encoding：服務器數據壓縮方式
• Transfer-Encoding：chunked表示採用分塊傳輸編碼，有該字段則無需使用Content-Length字段。
• Content-Length：聲明數據的長度，請求和迴應頭部均可以使用該字段。

Tcp三次握手

Http和Https協議請求時都會經過Tcp三次握手創建Tcp鏈接。那麼，三次握手是指什麼呢？

 

 

image.png

那麼，爲何必定要三次握手呢，一次能夠嗎？兩次能夠嗎？帶着這些問題，咱們來分析一下爲何必須是三次握手。

1. 第一次握手，A向B發送信息後，B收到信息。B可確認A的發信能力和B的收信能力
2. 第二次握手，B向A發消息，A收到消息。A可確認A的發信能力和收信能力，A也可確認B的收信能力和發信能力
3. 第三次握手，A向B發送消息，B接收到消息。B可確認A的收信能力和B的發信能力

經過三次握手，A和B都能確認本身和對方的收發信能力，至關於創建了互相的信任，就能夠開始通訊了。

下面，咱們介紹一下三次握手具體發送的內容，用一張圖描述以下：

 

 

image.png

首先，介紹一下幾個概念：

• ACK：響應標識，1表示響應，鏈接創建成功以後，全部報文段ACK的值都爲1
• SYN：鏈接標識，1表示創建鏈接，鏈接請求和鏈接接受報文段SYN=1，其餘狀況都是0
• FIN：關閉鏈接標識，1標識關閉鏈接，關閉請求和關閉接受報文段FIN=1，其餘狀況都是0，跟SYN相似
• seq number：序號，一個隨機數X，請求報文段中會有該字段，響應報文段沒有
• ack number：應答號，值爲請求seq+1，即X+1，除了鏈接請求和鏈接接受響應報文段沒有該字段，其餘的報文段都有該字段

知道了上面幾個概念後，看一下三次握手的具體流程：

1. 第一次握手：創建鏈接請求。客戶端發送鏈接請求報文段，將SYN置爲1，seq爲隨機數x。而後，客戶端進入SYN_SEND狀態，等待服務器確認。
2. 第二次握手：確認鏈接請求。服務器收到客戶端的SYN報文段，須要對該請求進行確認，設置ack=x+1（即客戶端seq+1）。同時本身也要發送SYN請求信息，即SYN置爲1，seq=y。服務器將SYN和ACK信息放在一個報文段中，一併發送給客戶端，服務器進入SYN_RECV狀態。
3. 第三次握手：客戶端收到SYN+ACK報文段，將ack設置爲y+1，向服務器發送ACK報文段，這個報文段發送完畢，客戶端和服務券進入ESTABLISHED狀態，完成Tcp三次握手。

從圖中能夠看出，創建鏈接經歷了三次握手，當數據傳輸完畢，須要斷開鏈接，而斷開鏈接經歷了四次揮手：

1. 第一次揮手：主機1（能夠是客戶端或服務器），設置seq和ack向主機2發送一個FIN報文段，此時主機1進入FIN_WAIT_1狀態，表示沒有數據要發送給主機2了
2. 第二次揮手：主機2收到主機1的FIN報文段，向主機1迴應一個ACK報文段，表示贊成關閉請求，主機1進入FIN_WAIT_2狀態。
3. 第三次揮手：主機2向主機1發送FIN報文段，請求關閉鏈接，主機2進入LAST_ACK狀態。
4. 第四次揮手：主機1收到主機2的FIN報文段，想主機2迴應ACK報文段，而後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段後，關閉鏈接。此時主機1等待主機2一段時間後，沒有收到回覆，證實主機2已經正常關閉，主機1頁關閉鏈接。

下面是Tcp報文段首部格式圖，對於理解Tcp協議很重要：

 

 

image.png

Https協議/SSL協議

Https協議是以安全爲目標的Http通道，簡單來講就是Http的安全版。主要是在Http下加入SSL層（如今主流的是SLL/TLS），SSL是Https協議的安全基礎。Https默認端口號爲443。
前面介紹了Http協議，各位同窗能說出Http存在的風險嗎？

1. 竊聽風險：Http採用明文傳輸數據，第三方能夠獲知通訊內容
2. 篡改風險：第三方能夠修改通訊內容
3. 冒充風險：第三方能夠冒充他人身份進行通訊

SSL/TLS協議就是爲了解決這些風險而設計，但願達到：

1. 全部信息加密傳輸，三方竊聽通訊內容
2. 具備校驗機制，內容一旦被篡改，通訊雙發馬上會發現
3. 配備身份證書，防止身份被冒充

下面主要介紹SSL/TLS協議。

SSL發展史（互聯網加密通訊）

1. 1994年NetSpace公司設計SSL協議（Secure Sockets Layout）1.0版本，但未發佈。
2. 1995年NetSpace發佈SSL/2.0版本，很快發現有嚴重漏洞
3. 1996年發佈SSL/3.0版本，獲得大規模應用
4. 1999年，發佈了SSL升級版TLS/1.0版本，目前應用最普遍的版本
5. 2006年和2008年，發佈了TLS/1.1版本和TLS/1.2版本

SSL原理及運行過程

SSL/TLS協議基本思路是採用公鑰加密法（最有名的是RSA加密算法）。大概流程是，客戶端向服務器索要公鑰，而後用公鑰加密信息，服務器收到密文，用本身的私鑰解密。
爲了防止公鑰被篡改，把公鑰放在數字證書中，證書可信則公鑰可信。公鑰加密計算量很大，爲了提升效率，服務端和客戶端都生成對話祕鑰，用它加密信息，而對話祕鑰是對稱加密，速度很是快。而公鑰用來機密對話祕鑰。

下面用一張圖表示SSL加密傳輸過程：

 

 

image.png

詳細介紹一下圖中過程：

1. 客戶端給出協議版本號、一個客戶端隨機數A（Client random）以及客戶端支持的加密方式
2. 服務端確認雙方使用的加密方式，並給出數字證書、一個服務器生成的隨機數B（Server random）
3. 客戶端確認數字證書有效，生成一個新的隨機數C（Pre-master-secret），使用證書中的公鑰對C加密，發送給服務端
4. 服務端使用本身的私鑰解密出C
5. 客戶端和服務器根據約定的加密方法，使用三個隨機數ABC，生成對話祕鑰，以後的通訊都用這個對話祕鑰進行加密。

SSL證書

上面提到了，Https協議中須要使用到SSL證書。
SSL證書是一個二進制文件，裏面包含通過認證的網站公鑰和一些元數據，須要從經銷商購買。
證書有不少類型，按認證級別分類：

• 域名認證（DV=Domain Validation）：最低級別的認證，能夠確認申請人擁有這個域名
• 公司認證（OV=Organization Validation）：確認域名全部人是哪家公司，證書裏面包含公司的信息
• 擴展認證（EV=Extended Validation）：最高級別認證，瀏覽器地址欄會顯示公司名稱。

EV證書瀏覽器地址欄樣式：

 

 

image.png

OV證書瀏覽器地址欄樣式：

 

 

image.png

DV證書瀏覽器樣式：

 

 

image.png

按覆蓋範圍分類：

• 單域名證書：只能用於單域名，foo.com證書不能用不www.foo.com
• 通配符證書：可用於某個域名及全部一級子域名，好比*.foo.com的證書可用於foo.com，也可用於www.foo.com
• 多域名證書：可用於多個域名，好比foo.com和bar.com

認證級別越高，覆蓋範圍越廣的證書，價格越貴。也有免費的證書，爲了推廣Https，電子前哨基金會成立了Let's Encrypt提供免費證書。
證書的經銷商也不少，知名度比較高的有亞洲誠信(Trust Asia)。

RSA加密和DH加密

加密算法分類

加密算法分爲對稱加密、非對稱加密和Hash加密算法。

• 對稱加密：甲方和乙方使用同一種加密規則對信息加解密
• 非對稱加密：乙方生成兩把祕鑰（公鑰和私鑰）。公鑰是公開的，任何人均可以獲取，私鑰是保密的，只存在於乙方手中。甲方獲取公鑰，而後用公鑰加密信息，乙方獲得密文後，用私鑰解密。
• Hash加密：Hash算法是一種單向密碼體制，即只有加密過程，沒有解密過程

對稱加密算法加解密效率高，速度快，適合大數據量加解密。常見的堆成加密算法有DES、AES、RC五、Blowfish、IDEA
非對稱加密算法複雜，加解密速度慢，但安全性高，通常與對稱加密結合使用（對稱加密通訊內容，非對稱加密對稱祕鑰）。常見的非對稱加密算法有RSA、DH、DSA、ECC
Hash算法特性是：輸入值同樣，通過哈希函數獲得相同的散列值，但並不是散列值相同則輸入值也相同。常見的Hash加密算法有MD五、SHA-一、SHA-X系列

下面着重介紹一下RSA算法和DH算法。

RSA加密算法

Https協議就是使用RSA加密算法，能夠說RSA加密算法是宇宙中最重要的加密算法。
RSA算法用到一些數論知識，包括互質關係，歐拉函數，歐拉定理。此處不具體介紹加密的過程，若是有興趣，能夠參照RSA算法加密過程。
RSA算法的安全保障基於大數分解問題，目前破解過的最大祕鑰是700+位，也就表明1024位祕鑰和2048位祕鑰能夠認爲絕對安全。
大數分解主要難點在於計算能力，若是將來計算能力有了質的提高，那麼這些祕鑰也是有可能被破解的。

DH加密算法

DH也是一種非對稱加密算法，DH加密算法過程。
DH算法的安全保障是基於離散對數問題。

Http協議和Https協議的對比

Http和Https的區別以下：

• https協議須要到CA申請證書，大多數狀況下須要必定費用
• Http是超文本傳輸協議，信息採用明文傳輸，Https則是具備安全性SSL加密傳輸協議
• Http和Https端口號不同，Http是80端口，Https是443端口
• Http鏈接是無狀態的，而Https採用Http+SSL構建可進行加密傳輸、身份認證的網絡協議，更安全。
• Http協議創建鏈接的過程比Https協議快。由於Https除了Tcp三次握手，還要通過SSL握手。鏈接創建以後數據傳輸速度，兩者無明顯區別。