HTTP/HTTPS基本知識

按照網上的參考，根據自己的理解思維進行整理，持續更新。

1、HTTPS科普

1.1 基礎

HTTPS科普掃盲帖
講的比較通俗易懂，參考着先看下。
HTTPS實際就是：數據通訊前驗證對方密鑰確保安全，隨後http報文經過ssl加密處理進行的http通訊，結構如下：

HTTP
↓
SSL
↓
TCP
↓
IP
↓
數據鏈路層
↓
物理層

OSI模型那一套東西。
所以要了解https，要先了解http，再瞭解ssl如何驗證密鑰，怎麼把數據加密。
瞭解http，建議看David.Gourley的《HTTP權威指南》，講的很詳細且易懂。

1.2 http編碼

默認支持的編碼爲ISO-8859-1，如果數據中含有非該編碼的字符，就需要進行url編碼，該標準包含了

ASCII字符集（1-127）
標準 ISO 字符集
希臘字母、其他符號（160-255）

2、CA證書和x509

2.1 CA

Certificate Authority，即頒發數字證書的機構，與SSL密切相關的就是CA證書了。

CA中心爲每個使用公開密鑰的用戶發放一個數字證書，數字證書的作用是證明證書中列出的用戶合法擁有證書中列出的公開密鑰。

CA 也擁有一個證書（內含公鑰）和私鑰。網上的公衆用戶通過驗證 CA 的簽字從而信任 CA ，任何人都可以得到 CA 的證書（含公鑰），用以驗證它所簽發的證書。

如果用戶想得到一份屬於自己的證書，他應先向 CA 提出申請。在 CA 判明申請者的身份後，便爲他分配一個公鑰，並且 CA 將該公鑰與申請者的身份信息綁在一起，併爲之簽字後，便形成證書發給申請者。

如果一個用戶想鑑別另一個證書的真僞，他就用 CA 的公鑰對那個證書上的簽字進行驗證，一旦驗證通過，該證書就被認爲是有效的。

2.2 x509

指的是CA數字證書的標準，還有其他標準：

符合PKI ITU-T X509標準，傳統標準（.DER .PEM .CER .CRT）
符合PKCS#7 加密消息語法標準(.P7B .P7C .SPC .P7R)
符合PKCS#10 證書請求標準(.p10)
符合PKCS#12 個人信息交換標準（.pfx *.p12）

X509是數字證書的基本規範，而P7和P12則是兩個實現規範，P7用於數字信封，P12則是帶有私鑰的證書實現規範。
具體這邊講的比較詳細：數字證書常見格式整理

一個標準的X.509數字證書包含以下一些內容：

1、證書的版本信息；
2、證書的序列號，每個證書都有一個唯一的證書序列號；
3、證書所使用的簽名算法；
4、證書的發行機構名稱，命名規則一般採用X.500格式；
5、證書的有效期，通用的證書一般採用UTC時間格式；
6、證書所有人的名稱，命名規則一般採用X.500格式；
7、證書所有人的公開密鑰；
8、證書發行者對證書的簽名。

2.3 CA證書申請流程

2.4 客戶端證書

客戶端需要有個客戶端證書以及CA證書
客戶端證書給服務器驗證客戶端合法性
CA證書用來認證服務器證書合法性

如果是嵌入式設備，那麼證書申請方就要給嵌入式設備內置客戶端證書和CA證書

3、對稱密鑰算法與非對稱密鑰算法

參考了這篇文章對稱密鑰算法與非對稱密鑰算法

國密算法
可分爲對稱算法和非對稱算法

對稱算法，包括了SM1,SM4,SM7,祖沖之密碼（zuc)，SM1和SM7對外是不公開的，想要調用的話，需要通過加密芯片的接口才可以

非對稱算法，包括SM2，SM9，SM3（哈希算法）

3.1 對稱密鑰算法

加密和解密使用相同密鑰的算法。（加密Key=解密key）
對稱密鑰算法又分爲分組密碼 (Block Cipher)和流密碼(Stream Cipher)。

常用算法包括

DES (Data Encryption Standard，數據加密算法) 
3DES (Triple Data Encryption Algorithm，三重數據加密算法)
AES (Advanced Encryption Standard，高級加密標準，又稱Rijndael加密法) 
PBE (Password-based encryption，基於密碼驗證)
RC2、RC4、RC5(來自Rivest Cipher 4的縮寫)
SM1、SM4、SM7、祖沖之密碼（zuc)（都是國密算法）

優點：加密速度快，便於硬件實現和大規模生產
缺點：需要保障密鑰安全；無法用來簽名和抗抵賴；

3.2 非對稱祕鑰算法

非對稱密碼體制也叫公開密鑰密碼體制、雙密鑰密碼體制。
其原理是加密密鑰與解密密鑰不同，形成一個密鑰對，用其中一個密鑰加密的結果，可以用另一個密鑰來解密。
特點：加密和解密使用不同的密鑰；一個密鑰公開，稱公鑰；一個密鑰保密，稱私鑰

常用算法：
RSA、Elgamal、Elgamal（離散對數）、Rabin、D-H、ECC（橢圓曲線加密算法），
還有國密算法（SM2，SM9，SM3（哈希算法））
使用最廣泛的是RSA算法，Elgamal是另一種常用的非對稱加密算法。

優點：密鑰分配，不必保持信道的保密性；可以用來簽名和防抵賴

3.3 HASH算法

HASH算法：MD5，SHA1，SHA256

4、https流程

參考了https 證書傳遞、驗證和數據加密、解密過程解析

4.1 https組成

由兩部分組成：http + SSL / TLS，也就是在http上又加了一層處理加密信息的模塊。

TLS（傳輸層安全）是更爲安全的升級版 SSL，可以說TLS就是SSL的新版本3.1。

由於 SSL 這一術語更爲常用，因此我們仍然將我們的安全證書稱作 SSL。
但當您從賽門鐵克購買 SSL 時，您真正購買的是最新的 TLS 證書，有 ECC、RSA 或 DSA 三種加密方式可以選擇。

服務端和客戶端的信息傳輸都會通過TLS進行加密，所以傳輸的數據都是加密後的數據。

4.2 https交互流程

1.客戶端發起https請求
　　客戶端向服務端發起HTTPS請求，客戶端給出協議版本號、一個客戶端隨機數A（Client random）以及客戶端支持的加密方式（SSL/TLS信息），連接到服務端的443端口，Http則是80端口。
　　
2. 傳送證書
　　服務端確認雙方使用的加密方式，並給出數字證書，這個數字證書其實就是公鑰，只是包含了很多信息，如證書的頒發機構、擁有者和證書過期時間等等。

服務器端的配置
採用https協議的服務器必須要有一套SSL數字證書，需要向CA組織(如WoSign沃通CA)申請。
這套SSL證書其實就是一對公鑰和私鑰。
如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭。
只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然後發給你。
因爲只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。
SSL證書是網站實現https加密協議的先決條件，可以向CA機構申請免費SSL證書。
也可以付費購買高級別的SSL證書。目前沃通CA提供3年期免費SSL證書申請http://freessl.wosign.com。

3. 客戶端解析證書
　　這部分工作是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就通過對稱加密算法，如SM4，生成對話祕鑰。然後用證書公鑰對該對話祕鑰進行加密。就好像上面說的，把對話祕鑰用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。
　　
4. 傳送加密信息
　　這部分傳送的是用服務端的SSL證書加密後的對話祕鑰，目的就是讓服務端得到這個對話祕鑰，以後客戶端和服務端的通信就可以通過這個對話祕鑰來進行加密解密了。
　　
5. 服務段解密信息
　　服務端用私鑰解密後，得到了客戶端傳過來的對話祕鑰，然後把內容通過該值進行對稱加密。所謂對稱加密就是，將信息和私鑰通過某種算法（比如國密SM4算法）混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密算法夠彪悍，私鑰夠複雜，數據就夠安全。
　　
6. 傳輸加密後的信息
　　這部分信息是服務端用對話祕鑰加密後的信息，可以在客戶端被還原。
　　
7. 客戶端解密信息
　　客戶端用之前生成的私鑰解密服務段傳過來的信息，於是獲取瞭解密後的內容。整個過程第三方即使監聽到了數據，也束手無策。

5、SSL在互聯網模型中的位置

SSL介於應用層和TCP層之間。應用層數據不再直接傳遞給傳輸層，而是傳遞給SSL層，SSL層對從應用層收到的數據進行加密，並增加自己的SSL頭。

6、兩種 HTTP 請求方法：GET 和 POST

在客戶機和服務器之間進行請求-響應時，兩種最常被用到的方法是：GET 和 POST。

GET：從指定的資源請求數據。
POST：向指定的資源提交要被處理的數據

7、http報文格式

7.1 報文組成

http報文都是由起始行(start line)+首部(header)+主體(body,可選)組成。

起始行：主要就是描述數據請求方式、地址和版本。
首部：包括通用首部、請求首部、響應首部、實體首部、擴展首部5種類型。
主體：真正要處理的數據，主要和首部結合，首部中的實體首部+主體組成了報文中最重要的數據實體，實體首部描述了主體的編碼方式，比如：

HTTP/1.0 200 OK				//起始行
Date: Thu, 11 Jul 2015 15:33:24 GMT	//首部，通用首部
Content-type: text/plain	//首部，實體首部，說明實體屬性，比如可以是application/json
Content-length: 19
							//CRLF 空行
hi, i'm a message.			//主體，實體主體

7.2 報文分類

7.2.1 定義

種類分爲兩類：請求報文（request message）和響應報文（response message）；

兩個報文只有起始行不一樣，但都是起始行+首部+實體結構，具體如下：

1	請求報文	響應報文
起始行	`<method> <request-URL> <version>\r\n`	`<version> <status> <reason-phase> \r\n`
首部	`keyn: valuen\r\n` // n個key和n個value組成，可以有0個或多個	`keyn: valuen\r\n` // n個key和n個value組成，可以有0個或多個
空行	`\r\n`	`\r\n`
主體	`<entity-body>\r\n`	`<entity-body>\r\n`

7.2.2 報文各個字段解析

method：客戶端希望服務器對資源執行的操作，主要有以下幾種方式：

GET、HEAD、POST（HTTP1.0)
OPTIONS、PUT、 DELETE、TRACE和CONNECT（HTTP1.1）

request-URL：所請求資源的路徑。

version：報文所使用的http版本，格式爲：HTTP/<major>.<minor>，如：HTTP/1.1。

headers：由0個或多個首部組成：key:[空格]value，到空行結束，首部主要有五種類型：
通用首部、請求首部、響應首部、實體首部、擴展首部

entity-body：由任意數據組成的數據塊，並不是必須要有的字段。

status：狀態碼，成功、出錯等錯誤碼提示：
100~199，信息提示
200~299，成功
300~399，資源已被移走，重定向
400~499，客戶端請求出錯
500~599，服務器出錯

reason-phase：status的可讀狀態，status是數字，不直觀，這邊顯示OK或NOT OK等字符，直觀顯示。

7.2.3 例子

請求報文：舉個POST用 json 的例子：

POST http://www.example.com HTTP/1.1
Content-Type: application/json; charset=utf-8
 
{"title":"test","sub":[1,2,3]}

響應報文：

HTTP/1.0 200 OK				//起始行
Content-type: text/plain	//首部
Content-length: 19
							//CRLF 空行
hi, i'm a message.			//主體

7.3 實體的結構

實體由實體首部+實體主體組成。

實體首部，是http報文的首部(headers)的一部分。
實體主體，就是主體(body)，是實際傳輸處理的數據，主體可以有很多種格式。這個格式也可以稱作MIME類型（用來描述報文主體內容的一些標準化名稱，通常用Content-type: 來定義），常見的有以下幾種：

Content-type: text/html：HTML 格式的文本文檔 　　
Content-type: text/plain：普通的 ASCII 文本文檔
Content-type: image/jpeg：JPEG格式的圖片 　　
Content-type: image/gif：GIF格式的圖片 　　
Content-type: video/quicktime：Apple 的QuickTime 電影 　　
Content-type: application/vnd.ms-powerpoint：微軟的powerpoint文件

//POST提交數據的請求方式常用以下幾種MIME類型
Content-type: application/x-www-form-urlencoded //默認使用
Content-type: application/json
Content-type: multipart/form-data	//一般用來上傳文件

詳細MIME類型可以看這個博客園的文章《MIME類型集合》