知識星球作者：左大人
連結：https://www.jianshu.com/p/27862635c077
序言
Http和Https屬於計算機網路範疇，但作為開發人員，不管是後臺開發或是前臺開發，都很有必要掌握它們。
在學習Http和Https的過程中，主要是參考了阮一峰老師的部落格《阮一峰：HTTP 協議入門》，講的很全面，並且通俗易懂，有興趣的同學可以去學習學習。
這篇文章主要是按照自己的思路來講解對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是指傳輸控制協議/網間協議，是目前世界上應用最廣的協議。
兩種模型區別
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層（現在主流的是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加密傳輸過程：
詳細介紹一下圖中過程：
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提供免費證書。
https://letsencrypt.org/
證書的經銷商也很多，知名度比較高的有亞洲誠信(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演演算法加密過程。
http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html
RSA演演算法的安全保障基於大數分解問題，目前破解過的最大秘鑰是700+位，也就代表1024位秘鑰和2048位秘鑰可以認為絕對安全。
大數分解主要難點在於計算能力，如果未來計算能力有了質的提升，那麼這些秘鑰也是有可能被破解的。
DH加密演演算法
DH也是一種非對稱加密演演算法，DH加密演演算法過程。
https://zh.wikipedia.org/wiki/%E8%BF%AA%E8%8F%B2-%E8%B5%AB%E7%88%BE%E6%9B%BC%E5%AF%86%E9%91%B0%E4%BA%A4%E6%8F%9B
DH演演算法的安全保障是基於離散對數問題。
六、Http協議和Https協議的對比
Http和Https的區別如下：
1、https協議需要到CA申請證書，大多數情況下需要一定費用
2、Http是超文字傳輸協議，資訊採用明文傳輸，Https則是具有安全性SSL加密傳輸協議
3、Http和Https埠號不一樣，Http是80埠，Https是443埠
4、Http連線是無狀態的，而Https採用Http+SSL構建可進行加密傳輸、身份認證的網路協議，更安全。
5、Http協議建立連線的過程比Https協議快。因為Https除了Tcp三次握手，還要經過SSL握手。連線建立之後資料傳輸速度，二者無明顯區別。
總結
經過了3天的學習和總結，總算完成了這篇文章，本文可以幫助讀者大體上把握Http和Https的知識框架。
並沒有深入探討每個主題的內容，當讀者有了自己知識框架之後，可以自行深入瞭解每個知識點的內容。
這邊提供一份總結資料：計算機網路相關知識彙總。
https://github.com/JeffyLu/JeffyLu.github.io/issues/22
●編號804，輸入編號直達本文 ●輸入m獲取文章目錄 Web開發 更多推薦《25個技術類微信公眾號》 涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
