全面瞭解HTTP和HTTPS

Http和Https屬於計算機網路範疇，但作為開發人員，不管是後臺開發或是前臺開發，都很有必要掌握它們。
在學習Http和Https的過程中，主要是參考了阮一峰老師的部落格，講的很全面，並且通俗易懂，有興趣的同學可以去學習學習。
這篇文章主要是按照自己的思路來講解對Http和Https的理解。文章將會從以下幾個方面介紹。

• 一、網路層結構
• 二、Http協議
• 三、Tcp三次握手
• 四、Https協議/SSL協議
• 五、SSL證書
• 六、RSA加密和DH加密
• 七、Http和Https對比

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

一、網路層結構

網路結構有兩種主流的分層方式：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已經成為國際標準。

二、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連線。那麼，三次握手是指什麼呢？

那麼，為什麼一定要三次握手呢，一次可以嗎？兩次可以嗎？帶著這些問題，我們來分析一下為什麼必須是三次握手。

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

通過三次握手，A和B都能確認自己和對方的收發信能力，相當於建立了互相的信任，就可以開始通訊了。

下面，我們介紹一下三次握手具體傳送的內容，用一張圖描述如下：

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

• 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協議很重要：

Https協議/SSL協議

Https協議是以安全為目標的Http通道，簡單來說就是Http的安全版。主要是在Http下加入SSL層（現在主流的是SSL/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加密傳輸過程：

詳細介紹一下圖中過程：

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證書瀏覽器位址列樣式：

OV證書瀏覽器位址列樣式：

 

DV證書瀏覽器樣式：

 

按覆蓋範圍分類：

• 單域名證書：只能用於單域名，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、RC5、Blowfish、IDEA
非對稱加密演算法複雜，加解密速度慢，但安全性高，一般與對稱加密結合使用（對稱加密通訊內容，非對稱加密對稱祕鑰）。常見的非對稱加密演算法有RSA、DH、DSA、ECC
Hash演算法特性是：輸入值一樣，經過雜湊函式得到相同的雜湊值，但並非雜湊值相同則輸入值也相同。常見的Hash加密演算法有MD5、SHA-1、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握手。連線建立之後資料傳輸速度，二者無明顯區別。

總結

經過了3天的學習總結，總算完成了這篇文章，本文可以幫助讀者大體上把握Http和Https的知識框架。並沒有深入探討每個主題的內容，當讀者有了自己知識框架之後，可以自行深入瞭解每個知識點的內容。
這邊提供一份總結資料：計算機網路相關知識彙總。

作者：左大人
連結：https://www.jianshu.com/p/27862635c077
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。