環(huán)球熱門(mén):國(guó)外在線代理服務(wù)器免費(fèi)網(wǎng)頁(yè)版（國(guó)外在線代理服務(wù)器免費(fèi)）

HTTP 的特點(diǎn)和缺點(diǎn)特點(diǎn)：無(wú)連接、無(wú)狀態(tài)、靈活、簡(jiǎn)單快速

無(wú)連接：每一次請(qǐng)求都要連接一次，請(qǐng)求結(jié)束就會(huì)斷掉，不會(huì)保持連接無(wú)狀態(tài)：每一次請(qǐng)求都是獨(dú)立的，請(qǐng)求結(jié)束不會(huì)記錄連接的任何信息(提起褲子就不認(rèn)人的意思)，減少了網(wǎng)絡(luò)開(kāi)銷，這是優(yōu)點(diǎn)也是缺點(diǎn)靈活：通過(guò)服務(wù)器的程序規(guī)模小，因而通信速度很快缺點(diǎn)：無(wú)狀態(tài)、不安全、明文傳輸、隊(duì)頭阻塞

【資料圖】

無(wú)狀態(tài)：請(qǐng)求不會(huì)記錄任何連接信息，沒(méi)有記憶，就無(wú)法區(qū)分多個(gè)請(qǐng)求發(fā)起者身份是不是同一個(gè)客戶端的，意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大不安全：明文傳輸可能被竊聽(tīng)不安全，缺少身份認(rèn)證也可能遭遇偽裝，還有缺少報(bào)文完整性驗(yàn)證可能遭到篡改明文傳輸：報(bào)文(header部分)使用的是明文，直接將信息暴露給了外界，WIFI陷阱就是復(fù)用明文傳輸?shù)奶攸c(diǎn)，誘導(dǎo)你連上熱點(diǎn)，然后瘋狂抓取你的流量，從而拿到你的敏感信息隊(duì)頭阻塞：開(kāi)啟長(zhǎng)連接(下面有講)時(shí)，只建立一個(gè)TCP連接，同一時(shí)刻只能處理一個(gè)請(qǐng)求，那么當(dāng)請(qǐng)求耗時(shí)過(guò)長(zhǎng)時(shí)，其他請(qǐng)求就只能阻塞狀態(tài)(如何解決下面有講)報(bào)文：由請(qǐng)求報(bào)文和響應(yīng)報(bào)文組成

請(qǐng)求報(bào)文：由請(qǐng)求行、請(qǐng)求頭、空行、請(qǐng)求體四部分組成

響應(yīng)報(bào)文：由狀態(tài)行、響應(yīng)頭、空行、響應(yīng)體四部分組成

請(qǐng)求行：包含

方法

描述

GET

獲取資源

POST

傳輸資源，通常會(huì)造成服務(wù)器資源的修改

HEAD

獲得報(bào)文首部

PUT

更新資源

PATCH

對(duì)PUT的補(bǔ)充，對(duì)已知資源部分更新 菜鳥(niǎo)

DELETE

刪除資源

OPTIONS

列出請(qǐng)求資源支持的請(qǐng)求方法，用來(lái)跨域請(qǐng)求

TRACE

追蹤請(qǐng)求/響應(yīng)路徑，用于測(cè)試或診斷

CONNECT

將連接改為管道方式用于代理服務(wù)器(隧道代理下面有講)

GET 和 POST 的區(qū)別GET在瀏覽器回退時(shí)是無(wú)害的，而POST會(huì)再次發(fā)起請(qǐng)求GET請(qǐng)求會(huì)被瀏覽器主動(dòng)緩存，而POST不會(huì)，除非手動(dòng)設(shè)置GET請(qǐng)求參數(shù)會(huì)被安逗保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會(huì)被保留GET請(qǐng)求在URL中傳遞的參數(shù)有長(zhǎng)度限制(瀏覽器限制大小不同)，而POST沒(méi)有限制GET參數(shù)通過(guò)URL傳遞，POST放在Request body中GET產(chǎn)生的URL地址可以被收藏，而POST不可以GET沒(méi)有POST安全，因?yàn)镚ET請(qǐng)求參數(shù)直接暴露在URL上，所以不能用來(lái)傳遞敏感信息GET請(qǐng)求只能進(jìn)行URL編碼，而POST支持多種編碼方式對(duì)參數(shù)的數(shù)據(jù)類型，GET只接受ASCII字符，而POST沒(méi)有限制GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包，POST產(chǎn)生兩個(gè)數(shù)據(jù)包(Firefox只發(fā)一次)。GET瀏覽器把 : 指示信息——表示請(qǐng)求已接收，繼續(xù)處理

2xx: 成功——表示請(qǐng)求已被成功接收

3xx: 重定向——表示要完成請(qǐng)求必須進(jìn)行進(jìn)一步操作

4xx: 客戶端錯(cuò)誤——表示請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)

5xx: 服務(wù)端錯(cuò)誤——表示服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求

常見(jiàn)狀態(tài)碼：

狀態(tài)碼

描述

200

請(qǐng)求成功

206

已完成指定范圍的請(qǐng)求(帶Range頭的GET請(qǐng)求),場(chǎng)景如video,audio播放文件較大,文件分片時(shí)

301

永久重定向

302

臨時(shí)重定向

304

請(qǐng)求資源未修改，可以使用緩存的資源，不用在服務(wù)器取

400

請(qǐng)求有語(yǔ)法錯(cuò)誤

401

沒(méi)有權(quán)限訪問(wèn)

403

服務(wù)器拒絕執(zhí)行請(qǐng)求，場(chǎng)景如不允許直接訪問(wèn)，只能通過(guò)服務(wù)器訪問(wèn)時(shí)

404

請(qǐng)求資源不存在

500

服務(wù)器內(nèi)部錯(cuò)誤，無(wú)法完成請(qǐng)求

503

請(qǐng)求未完成，因服務(wù)器過(guò)載、宕機(jī)或維護(hù)等

什么是持久連接/長(zhǎng)連接協(xié)議為無(wú)連接的協(xié)議)

功能避免了建立或者重新建立連接

如圖：短連接極大的降低了傳輸效率

長(zhǎng)連接優(yōu)缺點(diǎn)優(yōu)點(diǎn)

減少CPU及內(nèi)存的使用，因?yàn)椴恍枰?jīng)常建立和關(guān)閉連接支持管道化的請(qǐng)求及響應(yīng)模式減少網(wǎng)絡(luò)堵塞，因?yàn)闇p少了TCP請(qǐng)求減少了后續(xù)請(qǐng)求的響應(yīng)時(shí)間，因?yàn)椴恍枰却CP、握手、揮手、關(guān)閉TCP的過(guò)程發(fā)生錯(cuò)誤時(shí)，也可在不關(guān)閉連接的情況下進(jìn)行錯(cuò)誤提示缺點(diǎn)

一個(gè)長(zhǎng)連接建立后，如果一直保持連接，對(duì)服務(wù)器來(lái)說(shuō)是多么的浪費(fèi)資源呀，而且長(zhǎng)連接時(shí)間的長(zhǎng)短，直接影響到服務(wù)器的并發(fā)數(shù)

還有就是可能造成隊(duì)頭堵塞(下面有講)，造成信息延遲

如何避免長(zhǎng)連接資源浪費(fèi)？客戶端請(qǐng)求頭聲明：Connection: close，本次通信后就關(guān)閉連接服務(wù)端配置：如Nginx，設(shè)置keepalive_timeout設(shè)置長(zhǎng)連接超時(shí)時(shí)間，keepalive_requests設(shè)置長(zhǎng)連接請(qǐng)求次數(shù)上限系統(tǒng)內(nèi)核參數(shù)設(shè)置： net.ipv4.tcp_keepalive_time = 60，連接閑置60秒后，服務(wù)端嘗試向客戶端發(fā)送偵測(cè)包，判斷TCP連接狀態(tài)，如果沒(méi)有收到ack反饋就在 net.ipv4.tcp_keepalive_intvl = 10，就在10秒后再次嘗試發(fā)送偵測(cè)包，直到收到ack反饋，一共會(huì) net.ipv4.tcp_keepalive_probes = 5，一共會(huì)嘗試5次，要是都沒(méi)有收到就關(guān)閉這個(gè)TCP連接了什么是管線化(管道化)在使用長(zhǎng)連接的情況下，建立一個(gè)連接通道后，連接上消息的傳遞類似于

請(qǐng)求1 – 響應(yīng)1 – 請(qǐng)求2 – 響應(yīng)2 – 請(qǐng)求3 – 響應(yīng)3

管理化連接的消息就變成了類似這樣

請(qǐng)求1 – 請(qǐng)求2 – 請(qǐng)求3 – 響應(yīng)1 – 響應(yīng)2 – 響應(yīng)3

管線化是在同一個(gè)TCP連接里發(fā)一個(gè)請(qǐng)求后不必等其回來(lái)就可以繼續(xù)發(fā)請(qǐng)求出去，這可以減少整體的響應(yīng)時(shí)間，但是服務(wù)器還是會(huì)按照請(qǐng)求的順序響應(yīng)請(qǐng)求，所以如果有許多請(qǐng)求，而前面的請(qǐng)求響應(yīng)很慢，就產(chǎn)生一個(gè)著名的問(wèn)題隊(duì)頭堵塞(下面有講解決方法)

管線化的特點(diǎn)：

管線化機(jī)制通過(guò)持久連接完成，在應(yīng)答模式，報(bào)文必須是一發(fā)一收，就形成了一個(gè)先進(jìn)先出的串行隊(duì)列，沒(méi)有輕重緩急的優(yōu)先級(jí)，只有入隊(duì)的先后順序，排在最前面的請(qǐng)求最先處理，就導(dǎo)致如果隊(duì)首的請(qǐng)求耗時(shí)過(guò)長(zhǎng)，后面的請(qǐng)求就只能處于阻塞狀態(tài)，這就是著名的隊(duì)頭阻塞問(wèn)題。解決如下：

并發(fā)連接因?yàn)橐粋€(gè)域名允許分配多個(gè)長(zhǎng)連接，就相當(dāng)于增加了任務(wù)隊(duì)列，不至于一個(gè)隊(duì)列里的任務(wù)阻塞了其他全部任務(wù)。以前在RFC2616中規(guī)定過(guò)客戶端最多只能并發(fā)2個(gè)連接，但是現(xiàn)實(shí)是很多瀏覽器不按套路出牌，就是遵守這個(gè)標(biāo)準(zhǔn)T_T，所以在RFC7230把這個(gè)規(guī)定取消掉了，現(xiàn)在的瀏覽器標(biāo)準(zhǔn)中一個(gè)域名并發(fā)連接可以有6~8個(gè)，記住是6~8個(gè)，不是6個(gè)(Chrome6個(gè)/Firefox8個(gè))

如果這個(gè)還不能滿足你

繼續(xù)，不要停…

域名分片一個(gè)域名最多可以并發(fā)6~8個(gè)，那咱就多來(lái)幾個(gè)域名

比如a.baidu.com，b.baidu.com，c.baidu.com，多準(zhǔn)備幾個(gè)二級(jí)域名，當(dāng)我們?cè)L問(wèn)baidu.com時(shí)，可以讓不同的資源從不同的二域名中獲取，而它們都指向同一臺(tái)服務(wù)器，這樣能夠并發(fā)更多的長(zhǎng)連接了

而在連接中發(fā)送多個(gè)請(qǐng)求

說(shuō)一下 HTTP 代理常見(jiàn)的代理有兩種：普通代理(中間人代理)，隧道代理

普通代理(中間人代理)

如圖：代理服務(wù)器相當(dāng)于一個(gè)中間人，一直幫兩邊傳遞東西，好可憐~~

不過(guò)它可以在中間可以幫我們過(guò)濾、緩存、負(fù)載均衡(多臺(tái)服務(wù)器共用一臺(tái)代理情況下)等一些處理

注意，實(shí)際場(chǎng)景中客戶端和服務(wù)器之間可能有多個(gè)代理服務(wù)器

隧道代理客戶端通過(guò)CONNECT方法請(qǐng)求隧道代理創(chuàng)建一個(gè)可以到任意目標(biāo)服務(wù)器和端口號(hào)的TCP連接，創(chuàng)建成功之后隧道代理只做請(qǐng)求和響應(yīng)數(shù)據(jù)的轉(zhuǎn)發(fā)，中間它不會(huì)做任何處理

為什么需要隧道代理呢？

我們都知道握手，然后進(jìn)行加密傳輸

可能有人會(huì)問(wèn)，那還要代理干嘛，直接請(qǐng)求服務(wù)器不是更好嗎

代理服務(wù)器，到底有什么好處呢？突破訪問(wèn)限制：如訪問(wèn)一些單位或集團(tuán)內(nèi)部資源，或用國(guó)外代理服務(wù)器(翻墻)，就可以上國(guó)外網(wǎng)站看片等安全性更高：上網(wǎng)者可以通過(guò)這種方式隱藏自己的IP，免受攻擊。還可以對(duì)數(shù)據(jù)過(guò)濾，對(duì)非法IP限流等負(fù)載均衡：客戶端請(qǐng)求先到代理服務(wù)器，而代理服務(wù)器后面有多少源服務(wù)器，IP是多少，客戶端是不知道的。因此，代理服務(wù)器收到請(qǐng)求后，通過(guò)特定的算法(隨機(jī)算法、輪詢、一致性hash、LUR(最近最少使用) 算法這里不細(xì)說(shuō)了)把請(qǐng)求分發(fā)給不同的源服務(wù)器，讓各個(gè)源服務(wù)器負(fù)載盡量均衡緩存代理：將內(nèi)容緩存到代理服務(wù)器(這個(gè)下面一節(jié)詳細(xì)說(shuō))代理最常見(jiàn)的請(qǐng)求頭Via

是一個(gè)能用首部，由代理服務(wù)器添加，適用于正向和反向代理，在請(qǐng)求和響應(yīng)首部均可出現(xiàn)，這個(gè)消息首部可以用來(lái)追蹤消息轉(zhuǎn)發(fā)情況，防止循環(huán)請(qǐng)求，還可以識(shí)別在請(qǐng)求或響應(yīng)傳遞鏈中消息發(fā)送者對(duì)于協(xié)議的支持能力，詳情請(qǐng)看MDN

Via: 1.1 vegurVia:

記錄客戶端請(qǐng)求的來(lái)源IP，每經(jīng)過(guò)一級(jí)代理(匿名代理除外)，代理服務(wù)器都會(huì)把這次請(qǐng)求的來(lái)源IP追加進(jìn)去

X-Forwarded-For: client,proxy1,proxy2復(fù)制代碼注意：與服務(wù)器直連的代理服務(wù)器的IP不會(huì)被追加進(jìn)去，該代理可能過(guò)TCP連接的Remote Address字段獲取到與服務(wù)器直連的代理服務(wù)器IP

X-Real-IP

一般記錄真實(shí)發(fā)出請(qǐng)求的客戶端的IP，還有X-Forwarded-Host和X-Forwarded-Proto分別記錄真實(shí)發(fā)出請(qǐng)求的客戶端的域名和協(xié)議名

代理中客戶端IP偽造問(wèn)題以及如何預(yù)防？X-Forwarded-For是可以偽造的，比如一些通過(guò)X-Forwarded-For獲取到客戶端IP來(lái)限制刷票的系統(tǒng)就可以通過(guò)偽造該請(qǐng)求頭達(dá)到刷票的目的，如果客戶端請(qǐng)求顯示指定了

X-Forwarded-For：192.168.1.108復(fù)制代碼那么服務(wù)端收到的這個(gè)請(qǐng)求頭，第一個(gè)IP就是偽造的

預(yù)防

在對(duì)外Nginx服務(wù)器上配置location / { proxy_set_header X-Forwarded-For $remote_addr}復(fù)制代碼這樣第一個(gè)IP就是從TCP連接客戶端的IP，不會(huì)讀取偽造的

從右到左遍歷X-Forwarded-For的IP，排除已知代理服務(wù)器IP和內(nèi)網(wǎng)IP，獲取到第一個(gè)符合條件的IP就可以了正向代理和反向代理正向代理工作在客戶端的代理為正向代理。使用正向代理的時(shí)候，需要在客戶端配置需要使用的代理服務(wù)器，正向代理對(duì)服務(wù)端透明。比如抓包工具Fiddler、Charles以及訪問(wèn)一些外網(wǎng)網(wǎng)站的代理工具都是正向代理

正向代理通常用于

緩存屏蔽某些不健康的網(wǎng)站通過(guò)代理訪問(wèn)原本無(wú)法訪問(wèn)的網(wǎng)站上網(wǎng)認(rèn)證，對(duì)用戶訪問(wèn)進(jìn)行授權(quán)反向代理工作在服務(wù)端的代理稱為反向代理。使用反向代理的時(shí)候，不需要在客戶端進(jìn)行設(shè)置，反向代理對(duì)客戶端透明。如Nginx就是反向代理

反向代理通常用于：負(fù)載均衡、服務(wù)端緩存、流量隔離、日志、金絲雀發(fā)布

代理中的長(zhǎng)連接在各個(gè)代理和服務(wù)器、客戶端節(jié)點(diǎn)之間是一段一段的TCP連接，客戶端通過(guò)代理訪問(wèn)目標(biāo)服務(wù)器也叫逐段傳輸，用于逐段傳輸?shù)恼?qǐng)求頭叫逐段傳輸頭。

逐段傳輸頭會(huì)在每一段傳輸?shù)闹虚g代理中處理掉，不會(huì)傳給下一個(gè)代理

標(biāo)準(zhǔn)的逐段傳輸頭有：Keep-Alive、Transfer-Encoding、TE、Connection、Trailer、Upgrade、Proxy-Authorization、Proxy-Authenticate。

Connection頭決定當(dāng)前事務(wù)完成后是否關(guān)閉連接，如果該值為keep-alive，則連接是持久連接不會(huì)關(guān)閉，使得對(duì)同一服務(wù)器的請(qǐng)求可以繼續(xù)在該連接上完成

說(shuō)一下 緩存在上一篇文章里有了詳細(xì)介紹 (建議收藏)為什么第二次打開(kāi)頁(yè)面快？五步吃透前端緩存，讓頁(yè)面飛起

緩存代理就是讓代理服務(wù)器接管一部分的服務(wù)端的http緩存，客戶端緩存過(guò)期之后就近到代理服務(wù)器的緩存中獲取，代理緩存過(guò)期了才請(qǐng)求源服務(wù)器，這樣流量大的時(shí)候能明顯降低源服務(wù)器的壓力

注意響應(yīng)頭字段

Cache-Control： 值有public時(shí)，表示可以被所有終端緩存，包括代理服務(wù)器、CDN。值有private時(shí)，只能被終端瀏覽器緩存，CDN、代理等中繼服務(wù)器都不可以緩存。

了

SSL/TLS一張圖讓你理解SSL和TLS的關(guān)系

如圖，TLS是SSL的升級(jí)版，而且TLS1.2版本以下都已廢棄，目前主要用的是TLS 1.2和TLS 1.3。而OpenSSL則是開(kāi)源版本的

那么它到底是個(gè)啥呢？

瀏覽器和服務(wù)器通信之前會(huì)先協(xié)商，選出它們都支持的加密套件，用來(lái)實(shí)現(xiàn)安全的通信。常見(jiàn)加密套件

隨便拿出一個(gè)加密套件舉例，如：RSA-PSK-AES128-GCM-SHA256，就是長(zhǎng)這樣，代表什么意思呢，我們看圖

RSA：表示握手時(shí)用RSA算法交換密鑰PSK：表示使用PSK算法簽名AES128-GCM：表示使用AES256對(duì)稱加密算法通信，密鑰長(zhǎng)度128，分組模式GCM。TLS 1.3中只剩下稱加密算法有AES和CHACHA20，分組模式只剩下GCM和POLY1305SHA256：表示使用SHA256算法驗(yàn)證信息完整性并生成隨機(jī)數(shù)。TLS 1.3中哈希摘要算法只剩下SHA256和SHA384了為什么需要用到這么多算法呢？

為了保證安全，TLS需要保證信息的：機(jī)密性、可用性、完整性、認(rèn)證性、不可否認(rèn)性，每一種算法都有其特定的用處

的證書(shū)校驗(yàn)過(guò)程是怎么樣的？證書(shū)校驗(yàn)用到了哪些算法？

對(duì)稱加密算法

就是加密和解密使用同一個(gè)密鑰。如AES、DES。加解密過(guò)程：

瀏覽器給服務(wù)器發(fā)送一個(gè)隨機(jī)數(shù)client-random和一個(gè)支持的加密方法列表服務(wù)器給瀏覽器返回另一個(gè)隨機(jī)數(shù)server-random和雙方都支持的加密方法然后兩者用加密方法將兩個(gè)隨機(jī)數(shù)混合生成密鑰，這就是通信雙上加解密的密鑰問(wèn)題是雙方如何安全的傳遞兩個(gè)隨機(jī)數(shù)和加密方法，直接傳給客戶端，那過(guò)程中就很可能被竊取，別人就能成功解密拿到數(shù)據(jù)，往下看

不對(duì)稱加密算法

就是一對(duì)密鑰，有公鑰(public key)和私鑰(private key)，其中一個(gè)密鑰加密后的數(shù)據(jù)，只能讓另一個(gè)密鑰進(jìn)行解密。如RSA、ECDHE。加解密過(guò)程：

瀏覽器給服務(wù)器發(fā)送一個(gè)隨機(jī)數(shù)client-random和一個(gè)支持的加密方法列表服務(wù)器把另一個(gè)隨機(jī)數(shù)server-random、加密方法、公鑰傳給瀏覽器然后瀏覽器用公鑰將兩個(gè)隨機(jī)數(shù)加密，生成密鑰，這個(gè)密鑰只能用私鑰解密使用公鑰反推出私鑰是非常困難，但不是做不到，隨著計(jì)算機(jī)運(yùn)算能力提高，非對(duì)稱密鑰至少要2048位才能保證安全性，這就導(dǎo)致性能上要比對(duì)稱加密要差很多

所以！

TLS實(shí)際用的是兩種算法的混合加密。通過(guò) 非對(duì)稱加密算法 交換 對(duì)稱加密算法 的密鑰，交換完成后，再使用對(duì)稱加密進(jìn)行加解密傳輸數(shù)據(jù)。這樣就保證了會(huì)話的機(jī)密性。過(guò)程如下

瀏覽器給服務(wù)器發(fā)送一個(gè)隨機(jī)數(shù)client-random和一個(gè)支持的加密方法列表服務(wù)器把另一個(gè)隨機(jī)數(shù)server-random、加密方法、公鑰傳給瀏覽器瀏覽器又生成另一個(gè)隨機(jī)數(shù)pre-random，并用公鑰加密后傳給服務(wù)器服務(wù)器再用私鑰解密，得到pre-random瀏覽器和服務(wù)器都將三個(gè)隨機(jī)數(shù)用加密方法混合生成最終密鑰這樣即便被截持，中間人沒(méi)有私鑰就拿不到pre-random，就無(wú)法生成最終密鑰。

可又有問(wèn)題來(lái)了，如果一開(kāi)始就被DNS截持，我們拿到的公鑰是中間人的，而不是服務(wù)器的，數(shù)據(jù)還是會(huì)被竊取，所以數(shù)字證書(shū)來(lái)了，往下看，先簡(jiǎn)單說(shuō)一下摘要算法

摘要算法

主要用于保證信息的完整性。常見(jiàn)的MD5算法、散列函數(shù)、哈希函數(shù)都屬于這類算法，其特點(diǎn)就是單向性、無(wú)法反推原文

假如信息被截取，并重新生成了摘要，這時(shí)候就判斷不出來(lái)是否被篡改了，所以需要給摘要也通過(guò)會(huì)話密鑰進(jìn)行加密，這樣就看不到明文信息，保證了安全性，同時(shí)也保證了完整性

如何保證數(shù)據(jù)不被篡改？簽名原理和證書(shū)?數(shù)字證書(shū)(數(shù)字簽名)

它可以幫我們驗(yàn)證服務(wù)器身份。因?yàn)槿绻麤](méi)有驗(yàn)證的話，就可能被中間人劫持，假如請(qǐng)求被中間人截獲，中間人把他自己的公鑰給了客戶端，客戶端收到公鑰就把信息發(fā)給中間人了，中間人解密拿到數(shù)據(jù)后，再請(qǐng)求實(shí)際服務(wù)器，拿到服務(wù)器公鑰，再把信息發(fā)給服務(wù)器

這樣不知不覺(jué)間信息就被人竊取了，所以在結(jié)合對(duì)稱和非對(duì)稱加密的基礎(chǔ)上，又添加了數(shù)字證書(shū)認(rèn)證的步驟，讓服務(wù)器證明自己的身份

數(shù)字證書(shū)需要向有權(quán)威的認(rèn)證機(jī)構(gòu)(CA)獲取授權(quán)給服務(wù)器。首先，服務(wù)器和CA機(jī)構(gòu)分別有一對(duì)密鑰(公鑰和私鑰)，然后是如何生成數(shù)字證書(shū)的呢？

CA機(jī)構(gòu)通過(guò)摘要算法生成服務(wù)器公鑰的摘要(哈希摘要)CA機(jī)構(gòu)通過(guò)CA私鑰及特定的簽名算法加密摘要，生成簽名把簽名、服務(wù)器公鑰等信息打包放入數(shù)字證書(shū)，并返回給服務(wù)器服務(wù)器配置好證書(shū)，以后客戶端連接服務(wù)器，都先把證書(shū)發(fā)給客戶端驗(yàn)證并獲取服務(wù)器的公鑰。

證書(shū)驗(yàn)證流程：

使用CA公鑰和聲明的簽名算法對(duì)CA中的簽名進(jìn)行解密，得到服務(wù)器公鑰的摘要內(nèi)容再用摘要算法對(duì)證書(shū)里的服務(wù)器公鑰生成摘要，再把這個(gè)摘要和上一步得到的摘要對(duì)比，如果一致說(shuō)明證書(shū)合法，里面的公鑰也是正確的，否則就是非法的證書(shū)認(rèn)證又分為單向認(rèn)證和雙向認(rèn)證

單向認(rèn)證：服務(wù)器發(fā)送證書(shū)，客戶端驗(yàn)證證書(shū)雙向認(rèn)證：服務(wù)器和客戶端分別提供證書(shū)給對(duì)方，并互相驗(yàn)證對(duì)方的證書(shū)

不過(guò)大多數(shù)服務(wù)器都是單向認(rèn)證，如果服務(wù)器需要驗(yàn)證客戶端的身份，一般通過(guò)用戶名、密碼、手機(jī)驗(yàn)證碼等之類的憑證來(lái)驗(yàn)證。只有更高級(jí)別的要求的系統(tǒng)，比如大額網(wǎng)銀轉(zhuǎn)賬等，就會(huì)提供雙向認(rèn)證的場(chǎng)景，來(lái)確保對(duì)客戶身份提供認(rèn)證性

連接

TLS連接是怎么回事呢，根據(jù)TLS版本和密鑰交換法不同，過(guò)程也不一樣，有三種方式

RSA握手早期的TLS密鑰交換法都是使用RSA算法，它的握手流程是這樣子的

瀏覽器給服務(wù)器發(fā)送一個(gè)隨機(jī)數(shù)client-random和一個(gè)支持的加密方法列表服務(wù)器把另一個(gè)隨機(jī)數(shù)server-random、加密方法、公鑰傳給瀏覽器瀏覽器又生成另一個(gè)隨機(jī)數(shù)pre-random，并用公鑰加密后傳給服務(wù)器服務(wù)器再用私鑰解密，得到pre-random，此時(shí)瀏覽器和服務(wù)器都得到三個(gè)隨機(jī)數(shù)了，各自將三個(gè)隨機(jī)數(shù)用加密方法混合生成最終密鑰然后開(kāi)始通信

TLS 1.2 版TLS 1.2版的用的是ECDHE密鑰交換法，看圖

瀏覽器給服務(wù)器發(fā)送一個(gè)隨機(jī)數(shù)client-random、TLS版本和一個(gè)支持的加密方法列表服務(wù)器生成一個(gè)橢圓曲線參數(shù)server-params、隨機(jī)數(shù)server-random、加密方法、證書(shū)等傳給瀏覽器瀏覽器又生成橢圓曲線參數(shù)client-params，握手?jǐn)?shù)據(jù)摘要等信息傳給服務(wù)器服務(wù)器再返回摘要給瀏覽器確認(rèn)應(yīng)答這個(gè)版本不再生成橢圓曲線參數(shù)cliend-params和server-params，而是在服務(wù)器和瀏覽器兩邊都得到server-params和client-params之后，就用ECDHE算法直接算出pre-random，這就兩邊都有了三個(gè)隨機(jī)數(shù)，然后各自再將三個(gè)隨機(jī)加密混合生成最終密鑰

TLS 1.3版在TLS1.3版本中廢棄了RSA算法，因?yàn)镽SA算法可能泄露私鑰導(dǎo)致歷史報(bào)文全部被破解，而ECDHE算法每次握手都會(huì)生成臨時(shí)的密鑰，所以就算私鑰被破解，也只能破解一條報(bào)文，而不會(huì)對(duì)之前的歷史信息產(chǎn)生影響，，所以在TLS 1.3中徹底取代了RSA。目前主流都是用ECDHE算法來(lái)做密鑰交換的

TLS1.3版本中握手過(guò)程是這樣子的

瀏覽器生成client-params、和client-random、TLS版本和加密方法列表發(fā)送給服務(wù)器服務(wù)器返回server-params、server-random、加密方法、證書(shū)、摘要等傳給瀏覽器瀏覽器確認(rèn)應(yīng)答，返回握手?jǐn)?shù)據(jù)摘要等信息傳給服務(wù)器簡(jiǎn)單說(shuō)就是簡(jiǎn)化了握手過(guò)程，只有三步，把原來(lái)的兩個(gè)RTT打包成一個(gè)發(fā)送了，所以減少了傳輸次數(shù)。這種握手方式也叫1-RTT握手

這種握手方還有優(yōu)化空間嗎？

有的，用會(huì)話復(fù)用

會(huì)話復(fù)用會(huì)話復(fù)用有兩種方式：Session ID 和 Session Ticket

Session ID：就是客戶端和服務(wù)器首次連接手各自保存會(huì)話ID，并存儲(chǔ)會(huì)話密鑰，下次再連接時(shí)，客戶端發(fā)送ID過(guò)來(lái)，服務(wù)器這邊再查找ID，如果找到了就直接復(fù)用會(huì)話，密鑰也不用重新生成

可是這樣的話，在客戶端數(shù)量龐大的時(shí)候，對(duì)服務(wù)器的存儲(chǔ)壓力可就大了

所以出來(lái)了第二種方式 Session Ticket：就是雙方連接成功后服務(wù)器加密會(huì)話信息，用Session Ticket消息發(fā)給客戶端存儲(chǔ)起來(lái)，下次再連接時(shí)就把這個(gè)Session Ticket解密，驗(yàn)證有沒(méi)有過(guò)期，如果沒(méi)有過(guò)期就復(fù)用會(huì)話。原理就是把存儲(chǔ)壓力分給客戶端。

這樣就萬(wàn)無(wú)一失了嗎？

No，這樣也存在安全問(wèn)題。因?yàn)槊看我靡粋€(gè)固定的密鑰來(lái)解密Session Ticket，一旦密鑰被竊取，那所有歷史記錄也就被破解了，所以只能盡量避免這種問(wèn)題定期更換密鑰。畢竟節(jié)省了不少生成會(huì)話密鑰和這些算法的耗時(shí)，性能還是提升了嘛

那剛說(shuō)了1-RTT，那能不能優(yōu)化到0-RTT呢

還真可以，做法就是發(fā)送Session Ticket的時(shí)候帶上應(yīng)用數(shù)據(jù)，不用等服務(wù)端確認(rèn)。這種方式被稱為PSK(Pre-Shared Key)

這樣萬(wàn)無(wú)一失了嗎？

尷了個(gè)尬，還是不行。這PSK要是被竊取，人家不斷向服務(wù)器重發(fā)，就直接增加了服務(wù)器被攻擊的風(fēng)險(xiǎn)

雖然不是絕對(duì)安全，但是現(xiàn)行架構(gòu)下最安全的解決文案了，大大增加了中間人的攻擊成本

優(yōu)缺點(diǎn)優(yōu)點(diǎn)

內(nèi)容加密，中間無(wú)法查看原始內(nèi)容身份認(rèn)證，保證用戶訪問(wèn)正確。如訪問(wèn)百度，即使DNS被劫持到第三方站點(diǎn)，也會(huì)提醒用戶沒(méi)有訪問(wèn)百度服務(wù)，可能被劫持?jǐn)?shù)據(jù)完整性，防止內(nèi)容被第三方冒充或篡改雖然不是絕對(duì)安全，但是現(xiàn)行架構(gòu)下最安全的解決文案了，大大增加了中間人的攻擊成本缺點(diǎn)

要錢，功能越強(qiáng)大的證書(shū)費(fèi)用越貴證書(shū)需要綁定IP，不能在同一個(gè)IP上綁定多個(gè)域名，而且只支持純文本內(nèi)容，早已過(guò)時(shí)就不講了

地址缺點(diǎn)：主要是連接緩慢，服務(wù)器只能按順序響應(yīng)，如果某個(gè)請(qǐng)求花了很長(zhǎng)時(shí)間，就會(huì)出現(xiàn)請(qǐng)求隊(duì)頭阻塞

雖然出了很多優(yōu)化技巧：為了增加并發(fā)請(qǐng)求，做域名拆分、資源合并、精靈圖、資源預(yù)取…等等

最終為了推進(jìn)從協(xié)議上進(jìn)行優(yōu)化，Google跳出來(lái)，推出SPDY協(xié)議

SPDY(2009年)SPDY（讀作“SPeeDY”）是Google開(kāi)發(fā)的基于TCP的會(huì)話層協(xié)議

主要通過(guò)幀、多路復(fù)用、請(qǐng)求優(yōu)先級(jí)、HTTP報(bào)頭壓縮、服務(wù)器推送以最小化網(wǎng)絡(luò)延遲，提升網(wǎng)絡(luò)速度，優(yōu)化用戶的網(wǎng)絡(luò)使用體驗(yàn)

原理是在SSL層上增加一個(gè)SPDY會(huì)話層，以在一個(gè)TCP連接中實(shí)現(xiàn)并發(fā)流。通常的為編碼和傳輸數(shù)據(jù)設(shè)計(jì)了一個(gè)新的幀格式。因?yàn)榱魇请p向的，所以可以在客戶端和服務(wù)端啟動(dòng)

雖然誕生后很快被所有主流瀏覽器所采用，并且服務(wù)器和代理也提供了支持，但是SPDY核心人員后來(lái)都參加到的支持

中至少三個(gè)新特性？

使用新的二進(jìn)制協(xié)議，不再是純文本，避免文本歧義，縮小了請(qǐng)求體積多路復(fù)用，同域名下所有通信都是在單鏈接(雙向數(shù)據(jù)流)完成，提高連接的復(fù)用率，在擁塞控制方面有更好的能力提升使用HPACK算法將頭部壓縮，用哈夫曼編碼建立索表，傳送索引大大節(jié)約了帶寬允許服務(wù)端主動(dòng)推送數(shù)據(jù)給客戶端增加了安全性，使用使用虛擬的流傳輸消息，解決了應(yīng)用層的隊(duì)頭阻塞問(wèn)題缺點(diǎn)

TCP以及TCP+TLS建立連接的延時(shí)，協(xié)議層的隊(duì)頭阻塞還沒(méi)有解決。

TCP在丟包的時(shí)候會(huì)進(jìn)行重傳，前面有一個(gè)包沒(méi)收到，就只能把后面的包放到緩沖區(qū)，應(yīng)用層是無(wú)法取數(shù)據(jù)的，也就是說(shuō)的丟失恢復(fù)機(jī)制不管用，因此丟失或重新排序的數(shù)據(jù)都會(huì)導(dǎo)致交互掛掉

為了解決這個(gè)問(wèn)題，Google又發(fā)明了QUIC協(xié)議

并在2018年11月將QUIC正式改名為

特點(diǎn)：

在傳輸層直接干掉TCP，用UDP替代實(shí)現(xiàn)了一套新的擁塞控制算法，徹底解決TCP中隊(duì)頭阻塞的問(wèn)題實(shí)現(xiàn)了類似TCP的流量控制、傳輸可靠性的功能。雖然UDP不提供可靠性的傳輸，但QUIC在UDP的基礎(chǔ)之上增加了一層來(lái)保證數(shù)據(jù)可靠性傳輸。它提供了數(shù)據(jù)包重傳、擁塞控制以及其他一些TCP中存在的特性實(shí)現(xiàn)了快速握手功能。由于QUIC是基于UDP的，所以QUIC可以實(shí)現(xiàn)使用0-RTT或者1-RTT來(lái)建立連接，這意味著QUIC可以用最快的速度來(lái)發(fā)送和接收數(shù)據(jù)。集成了TLS加密功能。目前QUIC使用的是TLS1.3結(jié)語(yǔ)點(diǎn)贊支持、手留余香、與有榮焉

感謝你能看到這里，加油哦！

標(biāo)簽：