計算機通信原理

互聯(lián)網(wǎng)的關(guān)鍵技術(shù)就是TCP/IP協(xié)議暴凑。兩臺計算機之間的通信是通過TCP/IP協(xié)議在因特網(wǎng)上進行的。實際上這個是兩個協(xié)議：

• TCP: Transmission Control Protocol 傳輸控制協(xié)議
• IP: Internet Protocol 網(wǎng)際協(xié)議箫踩。

引自維基百科TCP/IP協(xié)議族是一個網(wǎng)絡(luò)通信模型鹉戚，以及一整個網(wǎng)絡(luò)傳輸協(xié)議家族，為互聯(lián)網(wǎng)的基礎(chǔ)通信架構(gòu)咙冗。該協(xié)議家族的兩個核心協(xié)議：TCP（傳輸控制協(xié)議）和IP（網(wǎng)際協(xié)議），為該家族中最早通過的標準漂彤。這個協(xié)議族由互聯(lián)網(wǎng)工程任務(wù)組負責(zé)維護雾消。

TCP: 應(yīng)用程序之間的通信

TCP確保數(shù)據(jù)包以正確的次序到達，并且嘗試確認數(shù)據(jù)包的內(nèi)容沒有改變挫望。TCP在IP地址之上引端口（port）立润，它允許計算機通過網(wǎng)絡(luò)提供各種服務(wù)。一些端口號為不同的服務(wù)保留媳板，而且這些端口號是眾所周知桑腮。

服務(wù)或者守護進程：在提供服務(wù)的機器上，有程序監(jiān)聽特定端口上的通信流蛉幸。例如大多數(shù)電子郵件通信流出現(xiàn)在端口25上破讨，用于wwww的HTTP通信流出現(xiàn)在80端口上。

當應(yīng)用程序希望通過 TCP 與另一個應(yīng)用程序通信時巨缘，它會發(fā)送一個通信請求添忘。這個請求必須被送到一個確切的地址。在雙方“握手”之后若锁，TCP 將在兩個應(yīng)用程序之間建立一個全雙工 (full-duplex) 的通信搁骑，占用兩個計算機之間整個的通信線路。TCP 用于從應(yīng)用程序到網(wǎng)絡(luò)的數(shù)據(jù)傳輸控制又固。TCP 負責(zé)在數(shù)據(jù)傳送之前將它們分割為 IP 包仲器，然后在它們到達的時候?qū)⑺鼈冎亟M。

TCP/IP 就是TCP 和 IP 兩個協(xié)議在一起協(xié)同工作仰冠，有上下層次的關(guān)系乏冀。

TCP 負責(zé)應(yīng)用軟件（比如你的瀏覽器）和網(wǎng)絡(luò)軟件之間的通信。IP 負責(zé)計算機之間的通信洋只。TCP 負責(zé)將數(shù)據(jù)分割并裝入 IP 包辆沦，IP 負責(zé)將包發(fā)送至接受者，傳輸過程要經(jīng)IP路由器負責(zé)根據(jù)通信量识虚、網(wǎng)絡(luò)中的錯誤或者其他參數(shù)來進行正確地尋址肢扯，然后在它們到達的時候重新組合它們。

IP: 計算機之間的通信

IP協(xié)議是計算機用來相互識別的通信的一種機制担锤，每臺計算機都有一個IP.用來在internet上標識這臺計算機蔚晨。 IP 負責(zé)在因特網(wǎng)上發(fā)送和接收數(shù)據(jù)包。通過 IP肛循，消息（或者其他數(shù)據(jù)）被分割為小的獨立的包铭腕，并通過因特網(wǎng)在計算機之間傳送银择。IP 負責(zé)將每個包路由至它的目的地。

IP協(xié)議僅僅是允許計算機相互發(fā)消息累舷，但它并不檢查消息是否以發(fā)送的次序到達而且沒有損壞（只檢查關(guān)鍵的頭數(shù)據(jù)）浩考。為了提供消息檢驗功能，直接在IP協(xié)議上設(shè)計了傳輸控制協(xié)議TCP被盈。

HTTP

HTTP概念

引自維基百科HTTP:超文本傳輸協(xié)議（英文：HyperText Transfer Protocol怀挠，縮寫：HTTP）是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議害捕。HTTP是萬維網(wǎng)的數(shù)據(jù)通信的基礎(chǔ)。
設(shè)計HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法闷畸。通過HTTP或者HTTPS協(xié)議請求的資源由統(tǒng)一資源標識符（Uniform Resource Identifiers尝盼，URI）來標識。

HTTP協(xié)議層

HTTP（HyperText Transfer Protocol）佑菩，超文本傳輸協(xié)議盾沫，是一個基于TCP實現(xiàn)的應(yīng)用層協(xié)議。

HTTP請求響應(yīng)模型

HTTP由請求和響應(yīng)構(gòu)成殿漠，是一個標準的客戶端服務(wù)器模型（B/S）赴精。HTTP協(xié)議永遠都是客戶端發(fā)起請求，服務(wù)器回送響應(yīng)绞幌。見下圖:

HTTP是一個無狀態(tài)的協(xié)議蕾哟。無狀態(tài)是指客戶機（Web瀏覽器）和服務(wù)器之間不需要建立持久的連接，這意味著當一個客戶端向服務(wù)器端發(fā)出請求莲蜘，然后服務(wù)器返回響應(yīng)(response)谭确，連接就被關(guān)閉了，在服務(wù)器端不保留連接的有關(guān)信息.HTTP遵循請求(Request)/應(yīng)答(Response)模型票渠≈鸸客戶機（瀏覽器）向服務(wù)器發(fā)送請求，服務(wù)器處理請求并返回適當?shù)膽?yīng)答问顷。所有HTTP連接都被構(gòu)造成一套請求和應(yīng)答昂秃。

HTTP工作過程

一次HTTP操作稱為一個事務(wù)，其工作整個過程如下：

地址解析

如用客戶端瀏覽器請求這個頁面：http://localhost.com:8080/index.htm

從中分解出協(xié)議名杜窄、主機名肠骆、端口、對象路徑等部分羞芍，對于我們的這個地址哗戈，解析得到的結(jié)果如下：

協(xié)議名：http
主機名：localhost.com
端口：8080
對象路徑：/index.htm

在這一步，需要域名系統(tǒng)DNS解析域名localhost.com,得主機的IP地址荷科。

封裝HTTP請求數(shù)據(jù)包

把以上部分結(jié)合本機自己的信息唯咬，封裝成一個HTTP請求數(shù)據(jù)包

封裝成TCP包纱注，建立TCP連接（TCP的三次握手）

在HTTP工作開始之前，客戶機（Web瀏覽器）首先要通過網(wǎng)絡(luò)與服務(wù)器建立連接胆胰，該連接是通過TCP來完成的狞贱，該協(xié)議與IP協(xié)議共同構(gòu)建Internet，即著名的TCP/IP協(xié)議族蜀涨，因此Internet又被稱作是TCP/IP網(wǎng)絡(luò)瞎嬉。HTTP是比TCP更高層次的應(yīng)用層協(xié)議，根據(jù)規(guī)則厚柳，只有低層協(xié)議建立之后才能氧枣，才能進行更層協(xié)議的連接，因此别垮，首先要建立TCP連接便监，一般TCP連接的端口號是80。這里是8080端口碳想。

客戶機發(fā)送請求命令

建立連接后烧董，客戶機發(fā)送一個請求給服務(wù)器，請求方式的格式為：統(tǒng)一資源標識符（URL）胧奔、協(xié)議版本號逊移，后邊是MIME信息包括請求修飾符、客戶機信息和可內(nèi)容龙填。

服務(wù)器響應(yīng)

服務(wù)器接到請求后胳泉，給予相應(yīng)的響應(yīng)信息，其格式為一個狀態(tài)行觅够，包括信息的協(xié)議版本號胶背、一個成功或錯誤的代碼，后邊是MIME信息包括服務(wù)器信息喘先、實體信息和可能的內(nèi)容钳吟。

實體消息是服務(wù)器向瀏覽器發(fā)送頭信息后，它會發(fā)送一個空白行來表示頭信息的發(fā)送到此為結(jié)束窘拯，接著红且，它就以Content-Type應(yīng)答頭信息所描述的格式發(fā)送用戶所請求的實際數(shù)據(jù)

服務(wù)器關(guān)閉TCP連接

一般情況下，一旦Web服務(wù)器向瀏覽器發(fā)送了請求數(shù)據(jù)涤姊，它就要關(guān)閉TCP連接暇番，然后如果瀏覽器或者服務(wù)器在其頭信息加入了這行代碼

Connection:keep-alive

TCP連接在發(fā)送后將仍然保持打開狀態(tài)，于是思喊，瀏覽器可以繼續(xù)通過相同的連接發(fā)送請求壁酬。保持連接節(jié)省了為每個請求建立新連接所需的時間，還節(jié)約了網(wǎng)絡(luò)帶寬。

HTTP工作過程用到的概念

報文格式

HTTP1.0的報文有兩種類型：請求和響應(yīng)舆乔。其報文格式分別為：

請求報文格式

請求方法 URL HTTP/版本號
請求首部字段(可選)
空行
body(只對Post請求有效)

例如：

GET http://m.baidu.com/ HTTP/1.1
Host m.baidu.com
Connection Keep-Alive
...// 其他header

key=iOS

響應(yīng)報文格式

HTTP/版本號 返回碼 返回碼描述
應(yīng)答首部字段(可選)
空行
body

例如：

HTTP/1.1 200 OK
Content-Type text/html;charset=UTF-8
...// 其他header

<html>...

URL的結(jié)構(gòu)

使用HTTP協(xié)議訪問資源是通過URL（Uniform Resource Locator）統(tǒng)一資源定位符來實現(xiàn)的岳服。URL的格式如下：

scheme://host:port/path?query

scheme: 表示協(xié)議，如Http, Https, Ftp等希俩；
host: 表示所訪問資源所在的主機名：如：www.baidu.com;
port: 表示端口號吊宋，默認為80；
path: 表示所訪問的資源在目標主機上的儲存路徑颜武；
query: 表示查詢條件璃搜；

例如： http://www.baidu.com/search?words=Baidu

HTTP的請求方法

GET: 獲取URL指定的資源；
POST：傳輸實體信息
PUT：上傳文件
DELETE：刪除文件
HEAD：獲取報文首部鳞上，與GET相比这吻，不返回報文主體部分
OPTIONS：詢問支持的方法
TRACE：追蹤請求的路徑；
CONNECT：要求在與代理服務(wù)器通信時建立隧道篙议，使用隧道進行TCP通信橘原。主要使用SSL和TLS將數(shù)據(jù)加密后通過網(wǎng)絡(luò)隧道進行傳輸。

報文字段

HTTP首部字段由字段名和字段值組成涡上，中間以":"分隔，如Content-Type: text/html.其中拒名，同一個字段名可對應(yīng)多個字段值吩愧。

HTTP的報文字段分為5種：

• 請求報文字段
• 應(yīng)答報文字段
• 實體首部字段
• 通用報文字段
• 其他報文字段

請求報文字段

HTTP請求中支持的報文字段。

Accept：客戶端能夠處理的媒體類型增显。如text/html, 表示客戶端讓服務(wù)器返回html類型的數(shù)據(jù)雁佳，如果沒有，返回text
類型的也可以同云。媒體類型的格式一般為：type/subType, 表示優(yōu)先請求subType類型的數(shù)據(jù)糖权，如果沒有，返回type類型
數(shù)據(jù)也可以炸站。

常見的媒體類型：
文本文件：text/html, text/plain, text/css, application/xml
圖片文件：iamge/jpeg, image/gif, image/png;
視頻文件：video/mpeg
應(yīng)用程序使用的二進制文件：application/octet-stream, application/zip

Accept字段可設(shè)置多個字段值星澳，這樣服務(wù)器依次進行匹配，并返回最先匹配到的媒體類型旱易，當然禁偎，也可通過q參數(shù)來設(shè)置
媒體類型的權(quán)重，權(quán)重越高阀坏，優(yōu)先級越高如暖。q的取值為[0, 1], 可取小數(shù)點后3位，默認為1.0忌堂。例如：
Accept: text/html, application/xml; q=0.9, */*

Accept-Charset: 表示客戶端支持的字符集盒至。例如：Accept-Charset: GB2312, ISO-8859-1

Accept-Encoding： 表示客戶端支持的內(nèi)容編碼格式。如：Accept-Encoding：gzip

常用的內(nèi)容編碼：
gzip: 由文件壓縮程序gzip生成的編碼格式；
compress: 由Unix文件壓縮程序compress生成的編碼格式枷遂；
deflate: 組合使用zlib和deflate壓縮算法生成的編碼格式樱衷；
identity：默認的編碼格式，不執(zhí)行壓縮登淘。

Accept-Language：表示客戶端支持的語言箫老。如：Accept-Language: zh-cn, en

Authorization：表示客戶端的認證信息∏荩客戶端在訪問需要認證的也是時耍鬓，服務(wù)器會返回401，隨后客戶端將認證信息
加在Authorization字段中發(fā)送到服務(wù)器后流妻，如果認證成功牲蜀，則返回200. 如Linux公社下的Ftp服務(wù)器就是這種流程：
ftp://ftp1.linuxidc.com。

Host: 表示訪問資源所在的主機名绅这，即URL中的域名部分涣达。如：m.baidu.com

If-Match: If-Match的值與所請求資源的ETag值（實體標記，與資源相關(guān)聯(lián)证薇。資源變化度苔，實體標記跟著變化）一致時，
服務(wù)器才處理此請求浑度。

If-Modified-Since: 用于確認客戶端擁有的本地資源的時效性寇窑。 如果客戶端請求的資源在If-Modified-Since指定
的時間后發(fā)生了改變，則服務(wù)器處理該請求箩张。如：If-Modified-Since:Thu 09 Jul 2018 00:00:00, 表示如果客戶
端請求的資源在2018年1月9號0點之后發(fā)生了變化甩骏，則服務(wù)器處理改請求。通過該字段我們可解決以下問題：有一個包含大
量數(shù)據(jù)的接口先慷，且實時性較高饮笛，我們在刷新時就可使用改字段，從而避免多余的流量消耗论熙。

If-None-Match: If-Match的值與所請求資源的ETag值不一致時服務(wù)器才處理此請求福青。

If-Range： If-Range的值（ETag值或時間）與所訪問資源的ETag值或時間相一致時，服務(wù)器處理此請求脓诡，并返回
Range字段中設(shè)置的指定范圍的數(shù)據(jù)素跺。如果不一致，則返回所有內(nèi)容誉券。If-Range其實算是If-Match的升級版指厌，因為它
的值不匹配時，依然能夠返回數(shù)據(jù)踊跟，而If-Match不匹配時踩验，請求不會被處理鸥诽，需要數(shù)據(jù)時需再次進行請求。


If-Unmodified-Since：與If-Modified-Since相反箕憾，表示請求的資源在指定的時間之后未發(fā)生變化時牡借，才處理請求，
否則返回412袭异。

Max-Forwards：表示請求可經(jīng)過的服務(wù)器的最大數(shù)目钠龙，請求每被轉(zhuǎn)發(fā)一次，Max-Forwards減1御铃，當Max-Forwards為0
時碴里，所在的服務(wù)器將不再轉(zhuǎn)發(fā)，而是直接做出應(yīng)答上真。通過此字段可定位通信問題咬腋，比如之前支付寶光纖被挖斷，就可通過設(shè)
置Max-Forwards來定位大概的位置睡互。

Proxy-Authorization：當客戶端接收到來自代理服務(wù)器的認證質(zhì)詢時根竿，客戶端會將認證信息添加到
Proxy-Authorization來完成認證。與Authorization類似就珠，只不過Authorization是發(fā)生在客戶端與服務(wù)端之間寇壳。

Range：獲取部分資源，例如：Range: bytes=500-1000表示獲取指定資源的第500到1000字節(jié)之間的內(nèi)容妻怎，如果服務(wù)器
能夠正確處理九巡，則返回206作為應(yīng)答，表示返回了部分數(shù)據(jù)蹂季，如果不能處理這種范圍請求，則以200作為應(yīng)答疏日，返回完整的
數(shù)據(jù)偿洁，

Referer：告知服務(wù)器請求是從哪個頁面發(fā)起的。例如在百度首頁中搜索某個關(guān)鍵字沟优，結(jié)果頁面的請求頭部就會有這個字段涕滋，
其值為https://www.baidu.com/。通過這個字段可統(tǒng)計廣告的點擊情況挠阁。

User-Agent：將發(fā)起請求的瀏覽器和代理名稱等信息發(fā)送給服務(wù)端宾肺，例如：
User-Agent: Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/63.0.3239.84 Mobile Safari/537.36

應(yīng)答報文字段

HTTP應(yīng)答中支持的報文字段。

表示不能處理侵俗。

Age：服務(wù)端告知客戶端锨用，源服務(wù)器（而不是緩存服務(wù)器）在多久之前創(chuàng)建了響應(yīng)。
單位為秒隘谣。

ETag： 實體資源的標識增拥，可用來請求指定的資源。

Location：請求的資源所在的新位置。

Proxy-Authenticate：將代理服務(wù)器需要的認證信息發(fā)送給客戶端掌栅。

Retry-After：服務(wù)端告知客戶端多久之后再重試秩仆，一般與503和3xx重定向類型的應(yīng)答一起使用。

Server：告知服務(wù)端當前使用的HTTP服務(wù)器應(yīng)用程序的相關(guān)信息猾封。

WWW-Authenticate：告知客戶端適用于所訪問資源的認證方案澄耍，如Basic或Digest。401的響應(yīng)中肯定帶有
WWW-Authenticate字段晌缘。

實體首部字段

Allow：通知客戶端齐莲，服務(wù)器所支持的請求方法。但服務(wù)器收到不支持的請求方法時枚钓，會以405（Method Not Allowed）
作為響應(yīng)铅搓。
    
Content-Encoding：告知客戶端，服務(wù)器對資源的內(nèi)容編碼搀捷。
  
Content-Language：告知客戶端星掰，資源所使用的自然語言。
  
Content-Length：告知客戶端資源的長度
  
Content-Location：告知客戶端資源所在的位置嫩舟。
  
Content-Type：告知客戶端資源的媒體類型氢烘，取值同請求首部字段中的Accept。
  
Expires：告知客戶端資源的失效日期家厌〔ゾ粒可用于對緩存的處理。
  
Last-Modified：告知客戶端資源最后一次修改的時間饭于。

通用報文字段

即可在HTTP請求中使用蜀踏，也可在HTTP應(yīng)答中使用的報文字段。

Cache-Control：控制緩存行為掰吕；

Connection：管理持久連接果覆，設(shè)置其值為Keep-Alive可實現(xiàn)長連接。

Date：創(chuàng)建HTTP報文的日期和時間殖熟。

Pragma：Http/1.1之前的歷史遺留字段局待，僅作為HTTP/1.0向后兼容而定義，雖然是通用字段菱属，當通常被使用在客戶單的
請求中钳榨，如Pragma: no-cache, 表示客戶端在請求過程中不循序服務(wù)端返回緩存的數(shù)據(jù)；

Transfer-Encoding：規(guī)定了傳輸報文主題時使用的傳輸編碼纽门，如Transfer-Encoding: chunked

Upgrade: 用于檢查HTTP協(xié)議或其他協(xié)議是否有可使用的更高版本薛耻。

Via：追蹤客戶端和服務(wù)端之間的報文的傳輸路徑，還可避免會環(huán)的發(fā)生赏陵，所以在經(jīng)過代理時必須添加此字段昭卓。

Warning：Http/1.1的報文字段愤钾，從Http/1.0的AfterRetry演變而來，用來告知用戶一些與緩存相關(guān)的警告信息候醒。

其他報文字段

這些字段不是HTTP協(xié)議中定義的能颁，但被廣泛應(yīng)用于HTTP請求中。

• Cookie：屬于請求型報文字段倒淫，在請求時添加Cookie, 以實現(xiàn)HTTP的狀態(tài)記錄伙菊。

• Set-Cookie：屬于應(yīng)答型報文字段。服務(wù)器給客戶端傳遞Cookie信息時敌土，就是通過此字段實現(xiàn)的镜硕。

Set-Cookie的字段屬性：

NAME=VALUE：賦予Cookie的名稱和值；
expires=DATE: Cookie的有效期返干；
path=PATH: 將服務(wù)器上的目錄作為Cookie的適用對象兴枯，若不指定，則默認為文檔所在的文件目錄矩欠；
domin=域名：作為Cookies適用對象的域名财剖，若不指定，則默認為創(chuàng)建Cookie的服務(wù)器域名癌淮；
Secure: 僅在HTTPS安全通信是才會發(fā)送Cookie躺坟；
HttpOnly: 使Cookie不能被JS腳本訪問；

如：Set-Cookie:BDSVRBFE=Go; max-age=10; domain=m.baidu.com; path=/

HTTP應(yīng)答狀態(tài)碼

常見應(yīng)答狀態(tài)碼：

了解應(yīng)答狀態(tài)碼的含義乳蓄，有助于我們在開發(fā)過程中定位問題咪橙，比如出現(xiàn)4xx, 我們首先需要檢查的是請求是否有問題，而出現(xiàn)5xx時虚倒，則應(yīng)讓服務(wù)端做相應(yīng)的檢查工作美侦。

HTTP缺點

• 通信使用明文，可能被竊聽
• 不驗證通信方的身份魂奥，可能遭遇偽裝
• 無法證明報文的完整性菠剩，有可能遭遇篡改

以上是HTTP的缺點，這在網(wǎng)絡(luò)通信中對企業(yè)安全是很致命的問題捧弃。那HTTPS能解決這些問題嗎？下面講講HTTPS擦囊。

HTTPS

HTTP+加密+認證+完整性保護 = HTTPS

HTTPS概念

引自維基百科HTTPS：超文本傳輸安全協(xié)議（英語：Hypertext Transfer Protocol Secure违霞，縮寫：HTTPS，常稱為HTTP over TLS瞬场，HTTP over SSL或HTTP Secure）是一種通過計算機網(wǎng)絡(luò)進行安全通信的傳輸協(xié)議买鸽。HTTPS經(jīng)由HTTP進行通信，但利用SSL/TLS來加密數(shù)據(jù)包贯被。HTTPS開發(fā)的主要目的眼五，是提供對網(wǎng)站服務(wù)器的身份認證妆艘，保護交換數(shù)據(jù)的隱私與完整性。這個協(xié)議由網(wǎng)景公司（Netscape）在1994年首次提出看幼，隨后擴展到互聯(lián)網(wǎng)上批旺。歷史上，HTTPS連接經(jīng)常用于萬維網(wǎng)上的交易支付和企業(yè)信息系統(tǒng)中敏感信息的傳輸诵姜。在2000年代晚期和2010年代早期汽煮，HTTPS開始廣泛使用于保護所有類型網(wǎng)站上的網(wǎng)頁真實性，保護賬戶和保持用戶通信棚唆，身份和網(wǎng)絡(luò)瀏覽的私密性暇赤。

HTTP協(xié)議采用明文傳輸信息，存在信息竊聽宵凌、信息篡改和信息劫持的風(fēng)險鞋囊，而協(xié)議TLS/SSL具有身份驗證、信息加密和完整性校驗的功能瞎惫，可以避免此類問題發(fā)生溜腐。

TLS/SSL全稱安全傳輸層協(xié)議Transport Layer Security, 是介于TCP和HTTP之間的一層安全協(xié)議，不影響原有的TCP協(xié)議和HTTP協(xié)議微饥，所以使用HTTPS基本上不需要對HTTP頁面進行太多的改造逗扒。

HTTPS是在HTTP上建立SSL加密層，并對傳輸數(shù)據(jù)進行加密欠橘，是HTTP協(xié)議的安全版矩肩。HTTPS主要作用是：

• 對數(shù)據(jù)進行加密，并建立一個信息安全通道肃续，來保證傳輸過程中的數(shù)據(jù)安全
• 對網(wǎng)站服務(wù)器進行真實身份認證

HTTPS和HTTP的區(qū)別

可以看到HTTPS比HTTP多了一層TLS/SSL協(xié)議黍檩，這個協(xié)議是干嘛的，有什么作用呢始锚？
下面講解TLS/SSL工作原理刽酱。

TLS/SSL工作原理

HTTPS協(xié)議的主要功能基本都依賴于TLS/SSL協(xié)議，TLS/SSL的功能實現(xiàn)主要依賴于三類基本算法：散列函數(shù) Hash瞧捌、對稱加密和非對稱加密棵里，其利用非對稱加密實現(xiàn)身份認證和密鑰協(xié)商，對稱加密算法采用協(xié)商的密鑰對數(shù)據(jù)加密姐呐，基于散列函數(shù)驗證信息的完整性殿怜。

散列函數(shù)Hash

常見的有 MD5、SHA1曙砂、SHA256头谜，該類函數(shù)特點是函數(shù)單向不可逆、對輸入非常敏感鸠澈、輸出長度固定柱告，針對數(shù)據(jù)的任何修改都會改變散列函數(shù)的結(jié)果截驮，用于防止信息篡改并驗證數(shù)據(jù)的完整性;
在信息傳輸過程中，散列函數(shù)不能單獨實現(xiàn)信息防篡改际度，因為明文傳輸葵袭，中間人可以修改信息之后重新計算信息摘要，因此需要對傳輸?shù)男畔⒁约靶畔⒄M行加密;

對稱加密

常見的有AES-CBC甲脏、DES眶熬、3DES、AES-GCM等块请，相同的密鑰可以用于信息的加密和解密娜氏，掌握密鑰才能獲取信息，能夠防止信息竊聽墩新，通信方式是1對1;
對稱加密的優(yōu)勢是信息傳輸1對1贸弥，需要共享相同的密碼，密碼的安全是保證信息安全的基礎(chǔ)海渊，服務(wù)器和 N 個客戶端通信绵疲，需要維持 N 個密碼記錄，且缺少修改密碼的機制;

非對稱加密

即常見的 RSA 算法臣疑，還包括 ECC盔憨、DH 等算法，算法特點是讯沈，密鑰成對出現(xiàn)郁岩，一般稱為公鑰(公開)和私鑰(保密)，公鑰加密的信息只能私鑰解開缺狠，私鑰加密的信息只能公鑰解開问慎。因此掌握公鑰的不同客戶端之間不能互相解密信息，只能和掌握私鑰的服務(wù)器進行加密通信挤茄，服務(wù)器可以實現(xiàn)1對多的通信如叼，客戶端也可以用來驗證掌握私鑰的服務(wù)器身份。
非對稱加密的特點是信息傳輸1對多穷劈，服務(wù)器只需要維持一個私鑰就能夠和多個客戶端進行加密通信笼恰，但服務(wù)器發(fā)出的信息能夠被所有的客戶端解密，且該算法的計算復(fù)雜歇终，加密速度慢社证。

結(jié)合三類算法的特點，TLS的基本工作方式是练湿，客戶端使用非對稱加密與服務(wù)器進行通信猴仑，實現(xiàn)身份驗證并協(xié)商對稱加密使用的密鑰审轮，
然后對稱加密算法采用協(xié)商密鑰對信息以及信息摘要進行加密通信肥哎，不同的節(jié)點之間采用的對稱密鑰不同辽俗，從而可以保證信息只能通信雙方獲取。

PKI體系

RSA身份驗證的隱患

身份驗證和密鑰協(xié)商是TLS的基礎(chǔ)功能篡诽，要求的前提是合法的服務(wù)器掌握著對應(yīng)的私鑰忆肾。但RSA算法無法確保服務(wù)器身份的合法性袁梗，因為公鑰并不包含服務(wù)器的信息，存在安全隱患:

• 客戶端C和服務(wù)器S進行通信，中間節(jié)點M截獲了二者的通信;
• 節(jié)點M自己計算產(chǎn)生一對公鑰pub_M和私鑰pri_M;
• C向S請求公鑰時阔蛉，M把自己的公鑰pub_M發(fā)給了C;
• C使用公鑰 pub_M加密的數(shù)據(jù)能夠被M解密，因為M掌握對應(yīng)的私鑰pri_M友绝，而 C無法根據(jù)公鑰信息判斷服務(wù)器的身份屎篱，從而 C和 * M之間建立了"可信"加密連接;
• 中間節(jié)點 M和服務(wù)器S之間再建立合法的連接，因此 C和 S之間通信被M完全掌握啰劲，M可以進行信息的竊聽梁沧、篡改等操作。
• 另外蝇裤，服務(wù)器也可以對自己的發(fā)出的信息進行否認廷支，不承認相關(guān)信息是自己發(fā)出。

因此該方案下至少存在兩類問題：中間人攻擊和信息抵賴栓辜。

身份驗證CA和證書

解決上述身份驗證問題的關(guān)鍵是確保獲取的公鑰途徑是合法的恋拍，能夠驗證服務(wù)器的身份信息，為此需要引入權(quán)威的第三方機構(gòu)CA(如沃通CA)藕甩。CA 負責(zé)核實公鑰的擁有者的信息施敢，并頒發(fā)認證"證書"，同時能夠為使用者提供證書驗證服務(wù)辛萍，即PKI體系(PKI基礎(chǔ)知識)悯姊。

基本的原理為，CA負責(zé)審核信息贩毕，然后對關(guān)鍵信息利用私鑰進行"簽名"悯许，公開對應(yīng)的公鑰，客戶端可以利用公鑰驗證簽名辉阶。CA也可以吊銷已經(jīng)簽發(fā)的證書先壕，基本的方式包括兩類 CRL 文件和 OCSP。CA使用具體的流程如下：

a.服務(wù)方S向第三方機構(gòu)CA提交公鑰谆甜、組織信息垃僚、個人信息(域名)等信息并申請認證;

b.CA通過線上、線下等多種手段驗證申請者提供信息的真實性规辱，如組織是否存在谆棺、企業(yè)是否合法，是否擁有域名的所有權(quán)等;

c.如信息審核通過罕袋，CA會向申請者簽發(fā)認證文件-證書改淑。
證書包含以下信息：申請者公鑰碍岔、申請者的組織信息和個人信息、簽發(fā)機構(gòu) CA的信息朵夏、有效時間蔼啦、證書序列號等信息的明文，同時包含一個簽名;
簽名的產(chǎn)生算法：首先仰猖，使用散列函數(shù)計算公開的明文信息的信息摘要捏肢，然后，采用 CA的私鑰對信息摘要進行加密饥侵，密文即簽名;

d.客戶端 C 向服務(wù)器 S 發(fā)出請求時鸵赫，S 返回證書文件;

e.客戶端 C讀取證書中的相關(guān)的明文信息，采用相同的散列函數(shù)計算得到信息摘要躏升，然后奉瘤，利用對應(yīng) CA的公鑰解密簽名數(shù)據(jù)，對比證書的信息摘要煮甥，如果一致盗温，則可以確認證書的合法性，即公鑰合法;

f.客戶端然后驗證證書相關(guān)的域名信息成肘、有效時間等信息;

g.客戶端會內(nèi)置信任CA的證書信息(包含公鑰)卖局，如果CA不被信任，則找不到對應(yīng) CA的證書双霍，證書也會被判定非法砚偶。

在這個過程注意幾點：

a.申請證書不需要提供私鑰，確保私鑰永遠只能服務(wù)器掌握;

b.證書的合法性仍然依賴于非對稱加密算法洒闸，證書主要是增加了服務(wù)器信息以及簽名;

c.內(nèi)置 CA 對應(yīng)的證書稱為根證書染坯，頒發(fā)者和使用者相同，自己為自己簽名丘逸，即自簽名證書（為什么說"部署自簽SSL證書非常不安全"）

d.證書=公鑰+申請者與頒發(fā)者信息+簽名;

證書鏈

如 CA根證書和服務(wù)器證書中間增加一級證書機構(gòu)单鹿，即中間證書，證書的產(chǎn)生和驗證原理不變深纲，只是增加一層驗證仲锄，只要最后能夠被任何信任的CA根證書驗證合法即可。

a.服務(wù)器證書 server.pem 的簽發(fā)者為中間證書機構(gòu) inter湃鹊，inter 根據(jù)證書 inter.pem 驗證 server.pem 確實為自己簽發(fā)的有效證書;

b.中間證書 inter.pem 的簽發(fā) CA 為 root儒喊，root 根據(jù)證書 root.pem 驗證 inter.pem 為自己簽發(fā)的合法證書;

c.客戶端內(nèi)置信任 CA 的 root.pem 證書，因此服務(wù)器證書 server.pem 的被信任币呵。

服務(wù)器證書怀愧、中間證書與根證書在一起組合成一條合法的證書鏈，證書鏈的驗證是自下而上的信任傳遞的過程。
二級證書結(jié)構(gòu)存在的優(yōu)勢：

a.減少根證書結(jié)構(gòu)的管理工作量芯义，可以更高效的進行證書的審核與簽發(fā);

b.根證書一般內(nèi)置在客戶端中肛搬，私鑰一般離線存儲，一旦私鑰泄露毕贼，則吊銷過程非常困難，無法及時補救;

c.中間證書結(jié)構(gòu)的私鑰泄露蛤奢，則可以快速在線吊銷鬼癣，并重新為用戶簽發(fā)新的證書;

d.證書鏈四級以內(nèi)一般不會對 HTTPS 的性能造成明顯影響。

證書鏈有以下特點：

a.同一本服務(wù)器證書可能存在多條合法的證書鏈啤贩。
因為證書的生成和驗證基礎(chǔ)是公鑰和私鑰對待秃，如果采用相同的公鑰和私鑰生成不同的中間證書，針對被簽發(fā)者而言痹屹，該簽發(fā)機構(gòu)都是合法的 CA章郁，不同的是中間證書的簽發(fā)機構(gòu)不同;

b.不同證書鏈的層級不一定相同，可能二級志衍、三級或四級證書鏈暖庄。
中間證書的簽發(fā)機構(gòu)可能是根證書機構(gòu)也可能是另一個中間證書機構(gòu)，所以證書鏈層級不一定相同楼肪。

證書吊銷

CA 機構(gòu)能夠簽發(fā)證書培廓，同樣也存在機制宣布以往簽發(fā)的證書無效。證書使用者不合法春叫，CA 需要廢棄該證書;或者私鑰丟失肩钠，使用者申請讓證書無效。主要存在兩類機制：CRL 與 OCSP暂殖。

CRL

Certificate Revocation List, 證書吊銷列表(什么是證書吊銷列表(CRL)价匠？吊銷列表起什么作用)，一個單獨的文件呛每。該文件包含了 CA 已經(jīng)吊銷的證書序列號(唯一)與吊銷日期踩窖，同時該文件包含生效日期并通知下次更新該文件的時間，當然該文件必然包含 CA 私鑰的簽名以驗證文件的合法性晨横。
證書中一般會包含一個 URL 地址 CRL Distribution Point毙石，通知使用者去哪里下載對應(yīng)的 CRL 以校驗證書是否吊銷。該吊銷方式的優(yōu)點是不需要頻繁更新颓遏，但是不能及時吊銷證書徐矩，因為 CRL 更新時間一般是幾天，這期間可能已經(jīng)造成了極大損失叁幢。

OCSP

Online Certificate Status Protocol, 證書狀態(tài)在線查詢協(xié)議滤灯，一個實時查詢證書是否吊銷的方式。請求者發(fā)送證書的信息并請求查詢，服務(wù)器返回正常鳞骤、吊銷或未知中的任何一個狀態(tài)窒百。證書中一般也會包含一個 OCSP 的 URL 地址，要求查詢服務(wù)器具有良好的性能豫尽。部分 CA 或大部分的自簽 CA (根證書)都是未提供 CRL 或 OCSP 地址的篙梢，對于吊銷證書會是一件非常麻煩的事情。

HTTPS性能與優(yōu)化

HTTPS性能損耗

前文討論了HTTPS原理與優(yōu)勢：身份驗證美旧、信息加密與完整性校驗等渤滞，且未對TCP和HTTP協(xié)議做任何修改。但通過增加新協(xié)議以實現(xiàn)更安全的通信必然需要付出代價榴嗅，HTTPS協(xié)議的性能損耗主要體現(xiàn)如下：

• 增加延時

分析前面的握手過程妄呕，一次完整的握手至少需要兩端依次來回兩次通信，至少增加延時2* RTT嗽测，利用會話緩存從而復(fù)用連接绪励，延時也至少1* RTT*

• 消耗較多的CPU資源

除數(shù)據(jù)傳輸之外，HTTPS通信主要包括對對稱加解密唠粥、非對稱加解密(服務(wù)器主要采用私鑰解密數(shù)據(jù));壓測 TS8 機型的單核 CPU：對稱加密算法AES-CBC-256 吞吐量 600Mbps疏魏，非對稱 RSA 私鑰解密200次/s。不考慮其它軟件層面的開銷晤愧，10G 網(wǎng)卡為對稱加密需要消耗 CPU 約17核蠢护，24核CPU最多接入 HTTPS 連接 4800;
靜態(tài)節(jié)點當前10G 網(wǎng)卡的 TS8 機型的 HTTP 單機接入能力約為10w/s，如果將所有的HTTP連接變?yōu)镠TTPS連接养涮，則明顯RSA的解密最先成為瓶頸葵硕。因此，RSA的解密能力是當前困擾HTTPS接入的主要難題贯吓。

HTTPS接入優(yōu)化

CDN接入

HTTPS 增加的延時主要是傳輸延時 RTT懈凹，RTT 的特點是節(jié)點越近延時越小，CDN 天然離用戶最近悄谐，因此選擇使用 CDN 作為 HTTPS 接入的入口介评，將能夠極大減少接入延時。CDN 節(jié)點通過和業(yè)務(wù)服務(wù)器維持長連接爬舰、會話復(fù)用和鏈路質(zhì)量優(yōu)化等可控方法们陆，極大減少 HTTPS 帶來的延時。

會話緩存

雖然前文提到 HTTPS 即使采用會話緩存也要至少1*RTT的延時情屹，但是至少延時已經(jīng)減少為原來的一半坪仇，明顯的延時優(yōu)化;同時，基于會話緩存建立的 HTTPS 連接不需要服務(wù)器使用RSA私鑰解密獲取 Pre-master 信息垃你，可以省去CPU 的消耗椅文。如果業(yè)務(wù)訪問連接集中喂很，緩存命中率高，則HTTPS的接入能力講明顯提升皆刺。當前TRP平臺的緩存命中率高峰時期大于30%少辣，10k/s的接入資源實際可以承載13k/的接入，收效非诚鄱辏可觀漓帅。

硬件加速

為接入服務(wù)器安裝專用的SSL硬件加速卡，作用類似 GPU痴怨，釋放 CPU忙干，能夠具有更高的 HTTPS 接入能力且不影響業(yè)務(wù)程序的。測試某硬件加速卡單卡可以提供35k的解密能力腿箩，相當于175核 CPU，至少相當于7臺24核的服務(wù)器劣摇，考慮到接入服務(wù)器其它程序的開銷珠移，一張硬件卡可以實現(xiàn)接近10臺服務(wù)器的接入能力。

遠程解密

本地接入消耗過多的 CPU 資源末融，浪費了網(wǎng)卡和硬盤等資源钧惧，考慮將最消耗 CPU 資源的RSA解密計算任務(wù)轉(zhuǎn)移到其它服務(wù)器，如此則可以充分發(fā)揮服務(wù)器的接入能力勾习，充分利用帶寬與網(wǎng)卡資源浓瞪。遠程解密服務(wù)器可以選擇 CPU 負載較低的機器充當，實現(xiàn)機器資源復(fù)用巧婶，也可以是專門優(yōu)化的高計算性能的服務(wù)器乾颁。當前也是 CDN 用于大規(guī)模HTTPS接入的解決方案之一。

SPDY/HTTP2

前面的方法分別從減少傳輸延時和單機負載的方法提高 HTTPS 接入性能艺栈，但是方法都基于不改變 HTTP 協(xié)議的基礎(chǔ)上提出的優(yōu)化方法英岭，SPDY/HTTP2 利用 TLS/SSL 帶來的優(yōu)勢，通過修改協(xié)議的方法來提升 HTTPS 的性能湿右，提高下載速度等诅妹。

關(guān)注我

歡迎關(guān)注公眾號：jackyshan，技術(shù)干貨首發(fā)微信毅人，第一時間推送吭狡。