整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
ttp和Https屬于計(jì)算機(jī)網(wǎng)絡(luò)范疇，但作為開發(fā)人員，不管是后臺開發(fā)或是前臺開發(fā)，都很有必要掌握它們。
在學(xué)習(xí)Http和Https的過程中，主要是參考了阮一峰老師的博客《阮一峰：HTTP 協(xié)議入門》，講的很全面，并且通俗易懂，有興趣的同學(xué)可以去學(xué)習(xí)學(xué)習(xí)。
這篇文章主要是按照自己的思路來講解對Http和Https的理解。文章將會從以下幾個方面介紹。
目錄樹：
從目錄結(jié)構(gòu)可以看出，每個標(biāo)題展開來說都是一個很大的主題。但本文旨在讓各位同學(xué)對Http和Https相關(guān)知識有一個全面的認(rèn)知，不會太過深入探討各個主題，有興趣的同學(xué)可以進(jìn)行針對性研究。
一、網(wǎng)絡(luò)層結(jié)構(gòu)
網(wǎng)絡(luò)結(jié)構(gòu)有兩種主流的分層方式：OSI七層模型和TCP/IP四層模型。
OSI七層模型和TCP/IP四層模型
OSI是指Open System Interconnect，意為開放式系統(tǒng)互聯(lián)。
TCP/IP是指傳輸控制協(xié)議/網(wǎng)間協(xié)議，是目前世界上應(yīng)用最廣的協(xié)議。
兩種模型區(qū)別
1、OSI采用七層模型，TCP/IP是四層模型
2、TCP/IP網(wǎng)絡(luò)接口層沒有真正的定義，只是概念性的描述。OSI把它分為2層，每一層功能詳盡。
3、在協(xié)議開發(fā)之前，就有了OSI模型，所以O(shè)SI模型具有共通性，而TCP/IP是基于協(xié)議建立的模型，不適用于非TCP/IP的網(wǎng)絡(luò)。
4、實(shí)際應(yīng)用中，OSI模型是理論上的模型，沒有成熟的產(chǎn)品;而TCP/IP已經(jīng)成為國際標(biāo)準(zhǔn)。
二、HTTP協(xié)議
Http是基于TCP/IP協(xié)議的應(yīng)用程序協(xié)議，不包括數(shù)據(jù)包的傳輸，主要規(guī)定了客戶端和服務(wù)器的通信格式，默認(rèn)使用80端口。
Http協(xié)議的發(fā)展歷史
1、1991年發(fā)布Http/0.9版本，只有Get命令，且服務(wù)端直返HTML格式字符串，服務(wù)器響應(yīng)完畢就關(guān)閉TCP連接。
2、1996年發(fā)布Http/1.0版本，優(yōu)點(diǎn)：可以發(fā)送任何格式內(nèi)容，包括文字、圖像、視頻、二進(jìn)制。也豐富了命令Get，Post，Head。請求和響應(yīng)的格式加入頭信息。缺點(diǎn)：每個TCP連接只能發(fā)送一個請求，而新建TCP連接的成本很高，導(dǎo)致Http/1.0新能很差。
3、1997發(fā)布Http/1.1版本，完善了Http協(xié)議，直至20年后的今天仍是最流行的版本。
優(yōu)點(diǎn)：a. 引入持久連接，TCP默認(rèn)不關(guān)閉，可被多個請求復(fù)用，對于一個域名，多數(shù)瀏覽器允許同時建立6個持久連接。b. 引入管道機(jī)制，即在同一個TCP連接中，可以同時發(fā)送多個請求，不過服務(wù)器還是按順序響應(yīng)。c. 在頭部加入Content-Length字段，一個TCP可以同時傳送多個響應(yīng)，所以就需要該字段來區(qū)分哪些內(nèi)容屬于哪個響應(yīng)。d. 分塊傳輸編碼，對于耗時的動態(tài)操作，用流模式取代緩存模式，即產(chǎn)生一塊數(shù)據(jù)，就發(fā)送一塊數(shù)據(jù)。e. 增加了許多命令，頭信息增加Host來指定服務(wù)器域名，可以訪問一臺服務(wù)器上的不同網(wǎng)站。
缺點(diǎn)：TCP連接中的響應(yīng)有順序，服務(wù)器處理完一個回應(yīng)才能處理下一個回應(yīng)，如果某個回應(yīng)特別慢，后面的請求就會排隊(duì)等著(對頭堵塞)。
4、2015年發(fā)布Http/2版本，它有幾個特性：二進(jìn)制協(xié)議、多工、數(shù)據(jù)流、頭信息壓縮、服務(wù)器推送。
Http請求和響應(yīng)格式
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"}
說明一下請求頭和響應(yīng)頭的部分字段：
三、Tcp三次握手
Http和Https協(xié)議請求時都會通過Tcp三次握手建立Tcp連接。
那么，三次握手是指什么呢?
那么，為什么一定要三次握手呢，一次可以嗎?兩次可以嗎?
帶著這些問題，我們來分析一下為什么必須是三次握手。
1、第一次握手，A向B發(fā)送信息后，B收到信息。B可確認(rèn)A的發(fā)信能力和B的收信能力
2、第二次握手，B向A發(fā)消息，A收到消息。A可確認(rèn)A的發(fā)信能力和收信能力，A也可確認(rèn)B的收信能力和發(fā)信能力
3、第三次握手，A向B發(fā)送消息，B接收到消息。B可確認(rèn)A的收信能力和B的發(fā)信能力
通過三次握手，A和B都能確認(rèn)自己和對方的收發(fā)信能力，相當(dāng)于建立了互相的信任，就可以開始通信了。
下面，我們介紹一下三次握手具體發(fā)送的內(nèi)容，用一張圖描述如下：
首先，介紹一下幾個概念：
知道了上面幾個概念后，看一下三次握手的具體流程：
1、第一次握手：建立連接請求。客戶端發(fā)送連接請求報(bào)文段，將SYN置為1，seq為隨機(jī)數(shù)x。然后，客戶端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)。
2、第二次握手：確認(rèn)連接請求。服務(wù)器收到客戶端的SYN報(bào)文段，需要對該請求進(jìn)行確認(rèn)，設(shè)置ack=x+1(即客戶端seq+1)。同時自己也要發(fā)送SYN請求信息，即SYN置為1，seq=y。服務(wù)器將SYN和ACK信息放在一個報(bào)文段中，一并發(fā)送給客戶端，服務(wù)器進(jìn)入SYN_RECV狀態(tài)。
3、第三次握手：客戶端收到SYN+ACK報(bào)文段，將ack設(shè)置為y+1，向服務(wù)器發(fā)送ACK報(bào)文段，這個報(bào)文段發(fā)送完畢，客戶端和服務(wù)券進(jìn)入ESTABLISHED狀態(tài)，完成Tcp三次握手。
從圖中可以看出，建立連接經(jīng)歷了三次握手，當(dāng)數(shù)據(jù)傳輸完畢，需要斷開連接，而斷開連接經(jīng)歷了四次揮手：
1、第一次揮手：主機(jī)1(可以是客戶端或服務(wù)器)，設(shè)置seq和ack向主機(jī)2發(fā)送一個FIN報(bào)文段，此時主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài)，表示沒有數(shù)據(jù)要發(fā)送給主機(jī)2了
2、第二次揮手：主機(jī)2收到主機(jī)1的FIN報(bào)文段，向主機(jī)1回應(yīng)一個ACK報(bào)文段，表示同意關(guān)閉請求，主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)。
3、第三次揮手：主機(jī)2向主機(jī)1發(fā)送FIN報(bào)文段，請求關(guān)閉連接，主機(jī)2進(jìn)入LAST_ACK狀態(tài)。
4、第四次揮手：主機(jī)1收到主機(jī)2的FIN報(bào)文段，想主機(jī)2回應(yīng)ACK報(bào)文段，然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài);主機(jī)2收到主機(jī)1的ACK報(bào)文段后，關(guān)閉連接。此時主機(jī)1等待主機(jī)2一段時間后，沒有收到回復(fù)，證明主機(jī)2已經(jīng)正常關(guān)閉，主機(jī)1頁關(guān)閉連接。
下面是Tcp報(bào)文段首部格式圖，對于理解Tcp協(xié)議很重要：
四、Https協(xié)議/SSL協(xié)議
Https協(xié)議是以安全為目標(biāo)的Http通道，簡單來說就是Http的安全版。主要是在Http下加入SSL層(現(xiàn)在主流的是SLL/TLS)，SSL是Https協(xié)議的安全基礎(chǔ)。Https默認(rèn)端口號為443。
前面介紹了Http協(xié)議，各位同學(xué)能說出Http存在的風(fēng)險(xiǎn)嗎?
1、竊聽風(fēng)險(xiǎn)：Http采用明文傳輸數(shù)據(jù)，第三方可以獲知通信內(nèi)容
2、篡改風(fēng)險(xiǎn)：第三方可以修改通信內(nèi)容
3、冒充風(fēng)險(xiǎn)：第三方可以冒充他人身份進(jìn)行通信
SSL/TLS協(xié)議就是為了解決這些風(fēng)險(xiǎn)而設(shè)計(jì)，希望達(dá)到：
1、所有信息加密傳輸，三方竊聽通信內(nèi)容
2、具有校驗(yàn)機(jī)制，內(nèi)容一旦被篡改，通信雙發(fā)立刻會發(fā)現(xiàn)
3、配備身份證書，防止身份被冒充
下面主要介紹SSL/TLS協(xié)議。
SSL發(fā)展史(互聯(lián)網(wǎng)加密通信)
1、1994年NetSpace公司設(shè)計(jì)SSL協(xié)議(Secure Sockets Layout)1.0版本，但未發(fā)布。
2、1995年NetSpace發(fā)布SSL/2.0版本，很快發(fā)現(xiàn)有嚴(yán)重漏洞
3、1996年發(fā)布SSL/3.0版本，得到大規(guī)模應(yīng)用
4、1999年，發(fā)布了SSL升級版TLS/1.0版本，目前應(yīng)用最廣泛的版本
5、2006年和2008年，發(fā)布了TLS/1.1版本和TLS/1.2版本
SSL原理及運(yùn)行過程
SSL/TLS協(xié)議基本思路是采用公鑰加密法(最有名的是RSA加密算法)。大概流程是，客戶端向服務(wù)器索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文，用自己的私鑰解密。
為了防止公鑰被篡改，把公鑰放在數(shù)字證書中，證書可信則公鑰可信。公鑰加密計(jì)算量很大，為了提高效率，服務(wù)端和客戶端都生成對話秘鑰，用它加密信息，而對話秘鑰是對稱加密，速度非常快。而公鑰用來機(jī)密對話秘鑰。
下面用一張圖表示SSL加密傳輸過程：
詳細(xì)介紹一下圖中過程：
1、客戶端給出協(xié)議版本號、一個客戶端隨機(jī)數(shù)A(Client random)以及客戶端支持的加密方式
2、服務(wù)端確認(rèn)雙方使用的加密方式，并給出數(shù)字證書、一個服務(wù)器生成的隨機(jī)數(shù)B(Server random)
3、客戶端確認(rèn)數(shù)字證書有效，生成一個新的隨機(jī)數(shù)C(Pre-master-secret)，使用證書中的公鑰對C加密，發(fā)送給服務(wù)端
4、服務(wù)端使用自己的私鑰解密出C
5、客戶端和服務(wù)器根據(jù)約定的加密方法，使用三個隨機(jī)數(shù)ABC，生成對話秘鑰，之后的通信都用這個對話秘鑰進(jìn)行加密。
SSL證書
上面提到了，Https協(xié)議中需要使用到SSL證書。
SSL證書是一個二進(jìn)制文件，里面包含經(jīng)過認(rèn)證的網(wǎng)站公鑰和一些元數(shù)據(jù)，需要從經(jīng)銷商購買。
證書有很多類型，按認(rèn)證級別分類：
EV證書瀏覽器地址欄樣式：
OV證書瀏覽器地址欄樣式：
DV證書瀏覽器樣式：
按覆蓋范圍分類：
認(rèn)證級別越高，覆蓋范圍越廣的證書，價(jià)格越貴。也有免費(fèi)的證書，為了推廣Https，電子前哨基金會成立了Let's Encrypt提供免費(fèi)證書。
https://letsencrypt.org/
證書的經(jīng)銷商也很多，知名度比較高的有亞洲誠信(Trust Asia)。
五、RSA加密和DH加密
加密算法分類
加密算法分為對稱加密、非對稱加密和Hash加密算法。
對稱加密算法加解密效率高，速度快，適合大數(shù)據(jù)量加解密。常見的堆成加密算法有DES、AES、RC5、Blowfish、IDEA
非對稱加密算法復(fù)雜，加解密速度慢，但安全性高，一般與對稱加密結(jié)合使用(對稱加密通信內(nèi)容，非對稱加密對稱秘鑰)。
常見的非對稱加密算法有RSA、DH、DSA、ECC
Hash算法特性是：輸入值一樣，經(jīng)過哈希函數(shù)得到相同的散列值，但并非散列值相同則輸入值也相同。常見的Hash加密算法有MD5、SHA-1、SHA-X系列
下面著重介紹一下RSA算法和DH算法。
RSA加密算法
Https協(xié)議就是使用RSA加密算法，可以說RSA加密算法是宇宙中最重要的加密算法。
RSA算法用到一些數(shù)論知識，包括互質(zhì)關(guān)系，歐拉函數(shù)，歐拉定理。此處不具體介紹加密的過程，如果有興趣，可以參照RSA算法加密過程。
http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html
RSA算法的安全保障基于大數(shù)分解問題，目前破解過的最大秘鑰是700+位，也就代表1024位秘鑰和2048位秘鑰可以認(rèn)為絕對安全。
大數(shù)分解主要難點(diǎn)在于計(jì)算能力，如果未來計(jì)算能力有了質(zhì)的提升，那么這些秘鑰也是有可能被破解的。
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算法的安全保障是基于離散對數(shù)問題。
六、Http協(xié)議和Https協(xié)議的對比
Http和Https的區(qū)別如下：
1、https協(xié)議需要到CA申請證書，大多數(shù)情況下需要一定費(fèi)用
2、Http是超文本傳輸協(xié)議，信息采用明文傳輸，Https則是具有安全性SSL加密傳輸協(xié)議
3、Http和Https端口號不一樣，Http是80端口，Https是443端口
4、Http連接是無狀態(tài)的，而Https采用Http+SSL構(gòu)建可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，更安全。
5、Http協(xié)議建立連接的過程比Https協(xié)議快。因?yàn)镠ttps除了Tcp三次握手，還要經(jīng)過SSL握手。連接建立之后數(shù)據(jù)傳輸速度，二者無明顯區(qū)別。
經(jīng)過了3天的學(xué)習(xí)和總結(jié)，總算完成了這篇文章，本文可以幫助讀者大體上把握Http和Https的知識框架。
Http和Https屬于計(jì)算機(jī)網(wǎng)絡(luò)范疇，但作為開發(fā)人員，不管是后臺開發(fā)或是前臺開發(fā)，都很有必要掌握它們。
在學(xué)習(xí)Http和Https的過程中，主要是參考了阮一峰老師的博客，講的很全面，并且通俗易懂，有興趣的同學(xué)可以去學(xué)習(xí)學(xué)習(xí)。
這篇文章主要是按照自己的思路來講解對Http和Https的理解。文章將會從以下幾個方面介紹。
目錄樹（暫時還不知道簡書編輯器怎么通過目錄樹進(jìn)行頁面內(nèi)跳轉(zhuǎn)，哪位同學(xué)知道希望不吝告知）：
從目錄結(jié)構(gòu)可以看出，每個標(biāo)題展開來說都是一個很大的主題。但本文旨在讓各位同學(xué)對Http和Https相關(guān)知識有一個全面的認(rèn)知，不會太過深入探討各個主題，有興趣的同學(xué)可以進(jìn)行針對性研究。
網(wǎng)絡(luò)結(jié)構(gòu)有兩種主流的分層方式：OSI七層模型和TCP/IP四層模型。
OSI七層模型和TCP/IP四層模型
OSI是指Open System Interconnect，意為開放式系統(tǒng)互聯(lián)。
TCP/IP是指傳輸控制協(xié)議/網(wǎng)間協(xié)議，是目前世界上應(yīng)用最廣的協(xié)議。
Http是基于TCP/IP協(xié)議的應(yīng)用程序協(xié)議，不包括數(shù)據(jù)包的傳輸，主要規(guī)定了客戶端和服務(wù)器的通信格式，默認(rèn)使用80端口。
Http請求和響應(yīng)格式
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"}
說明一下請求頭和響應(yīng)頭的部分字段：
Http和Https協(xié)議請求時都會通過Tcp三次握手建立Tcp連接。那么，三次握手是指什么呢？
image.png
那么，為什么一定要三次握手呢，一次可以嗎？兩次可以嗎？帶著這些問題，我們來分析一下為什么必須是三次握手。
通過三次握手，A和B都能確認(rèn)自己和對方的收發(fā)信能力，相當(dāng)于建立了互相的信任，就可以開始通信了。
下面，我們介紹一下三次握手具體發(fā)送的內(nèi)容，用一張圖描述如下：
image.png
首先，介紹一下幾個概念：
知道了上面幾個概念后，看一下三次握手的具體流程：
從圖中可以看出，建立連接經(jīng)歷了三次握手，當(dāng)數(shù)據(jù)傳輸完畢，需要斷開連接，而斷開連接經(jīng)歷了四次揮手：
下面是Tcp報(bào)文段首部格式圖，對于理解Tcp協(xié)議很重要：
image.png
Https協(xié)議是以安全為目標(biāo)的Http通道，簡單來說就是Http的安全版。主要是在Http下加入SSL層（現(xiàn)在主流的是SLL/TLS），SSL是Https協(xié)議的安全基礎(chǔ)。Https默認(rèn)端口號為443。
前面介紹了Http協(xié)議，各位同學(xué)能說出Http存在的風(fēng)險(xiǎn)嗎？
SSL/TLS協(xié)議就是為了解決這些風(fēng)險(xiǎn)而設(shè)計(jì)，希望達(dá)到：
下面主要介紹SSL/TLS協(xié)議。
SSL原理及運(yùn)行過程
SSL/TLS協(xié)議基本思路是采用公鑰加密法（最有名的是RSA加密算法）。大概流程是，客戶端向服務(wù)器索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文，用自己的私鑰解密。
為了防止公鑰被篡改，把公鑰放在數(shù)字證書中，證書可信則公鑰可信。公鑰加密計(jì)算量很大，為了提高效率，服務(wù)端和客戶端都生成對話秘鑰，用它加密信息，而對話秘鑰是對稱加密，速度非常快。而公鑰用來機(jī)密對話秘鑰。
下面用一張圖表示SSL加密傳輸過程：
image.png
詳細(xì)介紹一下圖中過程：
上面提到了，Https協(xié)議中需要使用到SSL證書。
SSL證書是一個二進(jìn)制文件，里面包含經(jīng)過認(rèn)證的網(wǎng)站公鑰和一些元數(shù)據(jù)，需要從經(jīng)銷商購買。
證書有很多類型，按認(rèn)證級別分類：
EV證書瀏覽器地址欄樣式：
image.png
OV證書瀏覽器地址欄樣式：
image.png
DV證書瀏覽器樣式：
image.png
按覆蓋范圍分類：
認(rèn)證級別越高，覆蓋范圍越廣的證書，價(jià)格越貴。也有免費(fèi)的證書，為了推廣Https，電子前哨基金會成立了Let's Encrypt提供免費(fèi)證書。
證書的經(jīng)銷商也很多，知名度比較高的有亞洲誠信(Trust Asia)。
加密算法分類
加密算法分為對稱加密、非對稱加密和Hash加密算法。
對稱加密算法加解密效率高，速度快，適合大數(shù)據(jù)量加解密。常見的堆成加密算法有DES、AES、RC5、Blowfish、IDEA
非對稱加密算法復(fù)雜，加解密速度慢，但安全性高，一般與對稱加密結(jié)合使用（對稱加密通信內(nèi)容，非對稱加密對稱秘鑰）。常見的非對稱加密算法有RSA、DH、DSA、ECC
Hash算法特性是：輸入值一樣，經(jīng)過哈希函數(shù)得到相同的散列值，但并非散列值相同則輸入值也相同。常見的Hash加密算法有MD5、SHA-1、SHA-X系列
下面著重介紹一下RSA算法和DH算法。
RSA加密算法
Https協(xié)議就是使用RSA加密算法，可以說RSA加密算法是宇宙中最重要的加密算法。
RSA算法用到一些數(shù)論知識，包括互質(zhì)關(guān)系，歐拉函數(shù)，歐拉定理。此處不具體介紹加密的過程，如果有興趣，可以參照RSA算法加密過程。
RSA算法的安全保障基于大數(shù)分解問題，目前破解過的最大秘鑰是700+位，也就代表1024位秘鑰和2048位秘鑰可以認(rèn)為絕對安全。
大數(shù)分解主要難點(diǎn)在于計(jì)算能力，如果未來計(jì)算能力有了質(zhì)的提升，那么這些秘鑰也是有可能被破解的。
DH加密算法
DH也是一種非對稱加密算法，DH加密算法過程。
DH算法的安全保障是基于離散對數(shù)問題。
Http協(xié)議和Https協(xié)議的對比
Http和Https的區(qū)別如下：
經(jīng)過了3天的學(xué)習(xí)總結(jié)，總算完成了這篇文章，本文可以幫助讀者大體上把握Http和Https的知識框架。并沒有深入探討每個主題的內(nèi)容，當(dāng)讀者有了自己知識框架之后，可以自行深入了解每個知識點(diǎn)的內(nèi)容。
藍(lán)字“CSDN云計(jì)算”關(guān)注我們哦！
作者:左大人 | 來源 公眾號 程序員小樂
來源：jianshu.com/p/27862635c077
00 前言
Http和Https屬于計(jì)算機(jī)網(wǎng)絡(luò)范疇，但作為開發(fā)人員，不管是后臺開發(fā)或是前臺開發(fā)，都很有必要掌握它們。在學(xué)習(xí)Http和Https的過程中，主要是參考了阮一峰老師的博客，講的很全面，并且通俗易懂，有興趣的同學(xué)可以去學(xué)習(xí)學(xué)習(xí)。
http://www.ruanyifeng.com/blog/2016/08/http.html
這篇文章主要是按照自己的思路來講解對Http和Https的理解。文章將會從以下幾個方面介紹。
目錄樹：
一、網(wǎng)絡(luò)層結(jié)構(gòu)
二、Http協(xié)議
三、Tcp三次握手
四、Https協(xié)議/SSL協(xié)議
五、SSL證書
六、RSA加密和DH加密
七、Http和Https對比
從目錄結(jié)構(gòu)可以看出，每個標(biāo)題展開來說都是一個很大的主題。但本文旨在讓各位同學(xué)對Http和Https相關(guān)知識有一個全面的認(rèn)知，不會太過深入探討各個主題，有興趣的同學(xué)可以進(jìn)行針對性研究。
01 網(wǎng)絡(luò)層結(jié)構(gòu)
網(wǎng)絡(luò)結(jié)構(gòu)有兩種主流的分層方式：OSI七層模型和TCP/IP四層模型。
OSI是指Open System Interconnect，意為開放式系統(tǒng)互聯(lián)。
TCP/IP是指傳輸控制協(xié)議/網(wǎng)間協(xié)議，是目前世界上應(yīng)用最廣的協(xié)議。
OSI采用七層模型，TCP/IP是四層模型
TCP/IP網(wǎng)絡(luò)接口層沒有真正的定義，只是概念性的描述。OSI把它分為2層，每一層功能詳盡。
在協(xié)議開發(fā)之前，就有了OSI模型，所以O(shè)SI模型具有共通性，而TCP/IP是基于協(xié)議建立的模型，不適用于非TCP/IP的網(wǎng)絡(luò)。
實(shí)際應(yīng)用中，OSI模型是理論上的模型，沒有成熟的產(chǎn)品；而TCP/IP已經(jīng)成為國際標(biāo)準(zhǔn)。
02 HTTP協(xié)議
Http是基于TCP/IP協(xié)議的應(yīng)用程序協(xié)議，不包括數(shù)據(jù)包的傳輸，主要規(guī)定了客戶端和服務(wù)器的通信格式，默認(rèn)使用80端口。
1991年發(fā)布Http/0.9版本，只有Get命令，且服務(wù)端直返HTML格式字符串，服務(wù)器響應(yīng)完畢就關(guān)閉TCP連接。
1996年發(fā)布Http/1.0版本，優(yōu)點(diǎn)：可以發(fā)送任何格式內(nèi)容，包括文字、圖像、視頻、二進(jìn)制。也豐富了命令Get，Post，Head。請求和響應(yīng)的格式加入頭信息。缺點(diǎn)：每個TCP連接只能發(fā)送一個請求，而新建TCP連接的成本很高，導(dǎo)致Http/1.0新能很差。
1997發(fā)布Http/1.1版本，完善了Http協(xié)議，直至20年后的今天仍是最流行的版本。
優(yōu)點(diǎn)：a. 引入持久連接，TCP默認(rèn)不關(guān)閉，可被多個請求復(fù)用，對于一個域名，多數(shù)瀏覽器允許同時建立6個持久連接。b. 引入管道機(jī)制，即在同一個TCP連接中，可以同時發(fā)送多個請求，不過服務(wù)器還是按順序響應(yīng)。c. 在頭部加入Content-Length字段，一個TCP可以同時傳送多個響應(yīng)，所以就需要該字段來區(qū)分哪些內(nèi)容屬于哪個響應(yīng)。d. 分塊傳輸編碼，對于耗時的動態(tài)操作，用流模式取代緩存模式，即產(chǎn)生一塊數(shù)據(jù)，就發(fā)送一塊數(shù)據(jù)。e. 增加了許多命令，頭信息增加Host來指定服務(wù)器域名，可以訪問一臺服務(wù)器上的不同網(wǎng)站。
缺點(diǎn)：TCP連接中的響應(yīng)有順序，服務(wù)器處理完一個回應(yīng)才能處理下一個回應(yīng)，如果某個回應(yīng)特別慢，后面的請求就會排隊(duì)等著（對頭堵塞）。
2015年發(fā)布Http/2版本，它有幾個特性：二進(jìn)制協(xié)議、多工、數(shù)據(jù)流、頭信息壓縮、服務(wù)器推送。
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":,"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"}
說明一下請求頭和響應(yīng)頭的部分字段：
Host：指定服務(wù)器域名，可用來區(qū)分訪問一個服務(wù)器上的不同服務(wù)
Connection：keep-alive表示要求服務(wù)器不要關(guān)閉TCP連接，close表示明確要求關(guān)閉連接，默認(rèn)值是keep-alive
Accept-Encoding：說明自己可以接收的壓縮方式
User-Agent：用戶代理，是服務(wù)器能識別客戶端的操作系統(tǒng)（Android、IOS、WEB）及相關(guān)的信息。作用是幫助服務(wù)器區(qū)分客戶端，并且針對不同客戶端讓用戶看到不同數(shù)據(jù)，做不同操作。
Content-Type：服務(wù)器告訴客戶端數(shù)據(jù)的格式，常見的值有text/plain，image/jpeg，image/png，video/mp4，application/json，application/zip。這些數(shù)據(jù)類型總稱為MIME TYPE。
Content-Encoding：服務(wù)器數(shù)據(jù)壓縮方式
Transfer-Encoding：chunked表示采用分塊傳輸編碼，有該字段則無需使用Content-Length字段。
Content-Length：聲明數(shù)據(jù)的長度，請求和回應(yīng)頭部都可以使用該字段。
03 Tcp三次握手
Http和Https協(xié)議請求時都會通過Tcp三次握手建立Tcp連接。
那么，三次握手是指什么呢？
那么，為什么一定要三次握手呢，一次可以嗎？兩次可以嗎？
帶著這些問題，我們來分析一下為什么必須是三次握手。
第一次握手，A向B發(fā)送信息后，B收到信息。B可確認(rèn)A的發(fā)信能力和B的收信能力
第二次握手，B向A發(fā)消息，A收到消息。A可確認(rèn)A的發(fā)信能力和收信能力，A也可確認(rèn)B的收信能力和發(fā)信能力
第三次握手，A向B發(fā)送消息，B接收到消息。B可確認(rèn)A的收信能力和B的發(fā)信能力
通過三次握手，A和B都能確認(rèn)自己和對方的收發(fā)信能力，相當(dāng)于建立了互相的信任，就可以開始通信了。
下面，我們介紹一下三次握手具體發(fā)送的內(nèi)容，用一張圖描述如下：
首先，介紹一下幾個概念：
ACK：響應(yīng)標(biāo)識，1表示響應(yīng)，連接建立成功之后，所有報(bào)文段ACK的值都為1
SYN：連接標(biāo)識，1表示建立連接，連接請求和連接接受報(bào)文段SYN=1，其他情況都是0
FIN：關(guān)閉連接標(biāo)識，1標(biāo)識關(guān)閉連接，關(guān)閉請求和關(guān)閉接受報(bào)文段FIN=1，其他情況都是0，跟SYN類似
seq number：序號，一個隨機(jī)數(shù)X，請求報(bào)文段中會有該字段，響應(yīng)報(bào)文段沒有
ack number：應(yīng)答號，值為請求seq+1，即X+1，除了連接請求和連接接受響應(yīng)報(bào)文段沒有該字段，其他的報(bào)文段都有該字段
知道了上面幾個概念后，看一下三次握手的具體流程：
第一次握手：建立連接請求。客戶端發(fā)送連接請求報(bào)文段，將SYN置為1，seq為隨機(jī)數(shù)x。然后，客戶端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)。
第二次握手：確認(rèn)連接請求。服務(wù)器收到客戶端的SYN報(bào)文段，需要對該請求進(jìn)行確認(rèn)，設(shè)置ack=x+1（即客戶端seq+1）。同時自己也要發(fā)送SYN請求信息，即SYN置為1，seq=y。服務(wù)器將SYN和ACK信息放在一個報(bào)文段中，一并發(fā)送給客戶端，服務(wù)器進(jìn)入SYN_RECV狀態(tài)。
第三次握手：客戶端收到SYN+ACK報(bào)文段，將ack設(shè)置為y+1，向服務(wù)器發(fā)送ACK報(bào)文段，這個報(bào)文段發(fā)送完畢，客戶端和服務(wù)券進(jìn)入ESTABLISHED狀態(tài)，完成Tcp三次握手。
從圖中可以看出，建立連接經(jīng)歷了三次握手，當(dāng)數(shù)據(jù)傳輸完畢，需要斷開連接，而斷開連接經(jīng)歷了四次揮手：
第一次揮手：主機(jī)1（可以是客戶端或服務(wù)器），設(shè)置seq和ack向主機(jī)2發(fā)送一個FIN報(bào)文段，此時主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài)，表示沒有數(shù)據(jù)要發(fā)送給主機(jī)2了
第二次揮手：主機(jī)2收到主機(jī)1的FIN報(bào)文段，向主機(jī)1回應(yīng)一個ACK報(bào)文段，表示同意關(guān)閉請求，主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)。
第三次揮手：主機(jī)2向主機(jī)1發(fā)送FIN報(bào)文段，請求關(guān)閉連接，主機(jī)2進(jìn)入LAST_ACK狀態(tài)。
第四次揮手：主機(jī)1收到主機(jī)2的FIN報(bào)文段，想主機(jī)2回應(yīng)ACK報(bào)文段，然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài)；主機(jī)2收到主機(jī)1的ACK報(bào)文段后，關(guān)閉連接。此時主機(jī)1等待主機(jī)2一段時間后，沒有收到回復(fù)，證明主機(jī)2已經(jīng)正常關(guān)閉，主機(jī)1頁關(guān)閉連接。
下面是Tcp報(bào)文段首部格式圖，對于理解Tcp協(xié)議很重要：
04 Https協(xié)議/SSL協(xié)議
Https協(xié)議是以安全為目標(biāo)的Http通道，簡單來說就是Http的安全版。主要是在Http下加入SSL層（現(xiàn)在主流的是SLL/TLS），SSL是Https協(xié)議的安全基礎(chǔ)。Https默認(rèn)端口號為443。
前面介紹了Http協(xié)議，各位同學(xué)能說出Http存在的風(fēng)險(xiǎn)嗎？
竊聽風(fēng)險(xiǎn)：Http采用明文傳輸數(shù)據(jù)，第三方可以獲知通信內(nèi)容
篡改風(fēng)險(xiǎn)：第三方可以修改通信內(nèi)容
冒充風(fēng)險(xiǎn)：第三方可以冒充他人身份進(jìn)行通信
SSL/TLS協(xié)議就是為了解決這些風(fēng)險(xiǎn)而設(shè)計(jì)，希望達(dá)到：
所有信息加密傳輸，三方竊聽通信內(nèi)容
具有校驗(yàn)機(jī)制，內(nèi)容一旦被篡改，通信雙發(fā)立刻會發(fā)現(xiàn)
配備身份證書，防止身份被冒充
下面主要介紹SSL/TLS協(xié)議。
1994年NetSpace公司設(shè)計(jì)SSL協(xié)議（Secure Sockets Layout）1.0版本，但未發(fā)布。
1995年NetSpace發(fā)布SSL/2.0版本，很快發(fā)現(xiàn)有嚴(yán)重漏洞
1996年發(fā)布SSL/3.0版本，得到大規(guī)模應(yīng)用
1999年，發(fā)布了SSL升級版TLS/1.0版本，目前應(yīng)用最廣泛的版本
2006年和2008年，發(fā)布了TLS/1.1版本和TLS/1.2版本
SSL/TLS協(xié)議基本思路是采用公鑰加密法（最有名的是RSA加密算法）。大概流程是，客戶端向服務(wù)器索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文，用自己的私鑰解密。
為了防止公鑰被篡改，把公鑰放在數(shù)字證書中，證書可信則公鑰可信。公鑰加密計(jì)算量很大，為了提高效率，服務(wù)端和客戶端都生成對話秘鑰，用它加密信息，而對話秘鑰是對稱加密，速度非常快。而公鑰用來機(jī)密對話秘鑰。
下面用一張圖表示SSL加密傳輸過程：
詳細(xì)介紹一下圖中過程：
客戶端給出協(xié)議版本號、一個客戶端隨機(jī)數(shù)A（Client random）以及客戶端支持的加密方式
服務(wù)端確認(rèn)雙方使用的加密方式，并給出數(shù)字證書、一個服務(wù)器生成的隨機(jī)數(shù)B（Server random）
客戶端確認(rèn)數(shù)字證書有效，生成一個新的隨機(jī)數(shù)C（Pre-master-secret），使用證書中的公鑰對C加密，發(fā)送給服務(wù)端
服務(wù)端使用自己的私鑰解密出C
客戶端和服務(wù)器根據(jù)約定的加密方法，使用三個隨機(jī)數(shù)ABC，生成對話秘鑰，之后的通信都用這個對話秘鑰進(jìn)行加密。
05 SSL證書
上面提到了，Https協(xié)議中需要使用到SSL證書。
SSL證書是一個二進(jìn)制文件，里面包含經(jīng)過認(rèn)證的網(wǎng)站公鑰和一些元數(shù)據(jù)，需要從經(jīng)銷商購買。
證書有很多類型，按認(rèn)證級別分類：
域名認(rèn)證（DV=Domain Validation）：最低級別的認(rèn)證，可以確認(rèn)申請人擁有這個域名
公司認(rèn)證（OV=Organization Validation）：確認(rèn)域名所有人是哪家公司，證書里面包含公司的信息
擴(kuò)展認(rèn)證（EV=Extended Validation）：最高級別認(rèn)證，瀏覽器地址欄會顯示公司名稱。
EV證書瀏覽器地址欄樣式：
OV證書瀏覽器地址欄樣式：
DV證書瀏覽器樣式：
按覆蓋范圍分類：
單域名證書：只能用于單域名，foo.com證書不能用不www.foo.com
通配符證書：可用于某個域名及所有一級子域名，比如*.foo.com的證書可用于foo.com，也可用于www.foo.com
多域名證書：可用于多個域名，比如foo.com和bar.com
認(rèn)證級別越高，覆蓋范圍越廣的證書，價(jià)格越貴。也有免費(fèi)的證書，為了推廣Https，電子前哨基金會成立了Let's Encrypt提供免費(fèi)證書。
https://letsencrypt.org/
證書的經(jīng)銷商也很多，知名度比較高的有亞洲誠信(Trust Asia)。
06 RSA加密和DH加密
加密算法分為對稱加密、非對稱加密和Hash加密算法。
對稱加密：甲方和乙方使用同一種加密規(guī)則對信息加解密
非對稱加密：乙方生成兩把秘鑰（公鑰和私鑰）。公鑰是公開的，任何人都可以獲取，私鑰是保密的，只存在于乙方手中。甲方獲取公鑰，然后用公鑰加密信息，乙方得到密文后，用私鑰解密。
Hash加密：Hash算法是一種單向密碼體制，即只有加密過程，沒有解密過程
對稱加密算法加解密效率高，速度快，適合大數(shù)據(jù)量加解密。常見的堆成加密算法有DES、AES、RC5、Blowfish、IDEA
非對稱加密算法復(fù)雜，加解密速度慢，但安全性高，一般與對稱加密結(jié)合使用（對稱加密通信內(nèi)容，非對稱加密對稱秘鑰）。
常見的非對稱加密算法有RSA、DH、DSA、ECC
Hash算法特性是：輸入值一樣，經(jīng)過哈希函數(shù)得到相同的散列值，但并非散列值相同則輸入值也相同。常見的Hash加密算法有MD5、SHA-1、SHA-X系列
下面著重介紹一下RSA算法和DH算法。
Https協(xié)議就是使用RSA加密算法，可以說RSA加密算法是宇宙中最重要的加密算法。
RSA算法用到一些數(shù)論知識，包括互質(zhì)關(guān)系，歐拉函數(shù)，歐拉定理。此處不具體介紹加密的過程，如果有興趣，可以參照RSA算法加密過程。
http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html
RSA算法的安全保障基于大數(shù)分解問題，目前破解過的最大秘鑰是700+位，也就代表1024位秘鑰和2048位秘鑰可以認(rèn)為絕對安全。
大數(shù)分解主要難點(diǎn)在于計(jì)算能力，如果未來計(jì)算能力有了質(zhì)的提升，那么這些秘鑰也是有可能被破解的。
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算法的安全保障是基于離散對數(shù)問題。
07 Http協(xié)議和Https協(xié)議的對比
Http和Https的區(qū)別如下：
https協(xié)議需要到CA申請證書，大多數(shù)情況下需要一定費(fèi)用
Http是超文本傳輸協(xié)議，信息采用明文傳輸，Https則是具有安全性SSL加密傳輸協(xié)議
Http和Https端口號不一樣，Http是80端口，Https是443端口
Http連接是無狀態(tài)的，而Https采用Http+SSL構(gòu)建可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，更安全。
Http協(xié)議建立連接的過程比Https協(xié)議快。因?yàn)镠ttps除了Tcp三次握手，還要經(jīng)過SSL握手。連接建立之后數(shù)據(jù)傳輸速度，二者無明顯區(qū)別。
08 總結(jié)
經(jīng)過了3天的學(xué)習(xí)和總結(jié)，總算完成了這篇文章，本文可以幫助讀者大體上把握Http和Https的知識框架。
并沒有深入探討每個主題的內(nèi)容，當(dāng)讀者有了自己知識框架之后，可以自行深入了解每個知識點(diǎn)的內(nèi)容。這邊提供一份總結(jié)資料：計(jì)算機(jī)網(wǎng)絡(luò)相關(guān)知識匯總。
福利
掃描添加小編微信，備注“姓名+公司職位”，加入【云計(jì)算學(xué)習(xí)交流群】，和志同道合的朋友們共同打卡學(xué)習(xí)！
推薦閱讀：
真香，朕在看了！
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
