環(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)銷(xiāo)，這是優(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è)客戶(hù)端的，意味著如果后續(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ù)類(lèi)型，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: 客戶(hù)端錯(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)？客戶(hù)端請(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ù)端嘗試向客戶(hù)端發(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è)連接通道后，連接上消息的傳遞類(lèi)似于

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

管理化連接的消息就變成了類(lèi)似這樣

請(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ò)客戶(hù)端最多只能并發(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)景中客戶(hù)端和服務(wù)器之間可能有多個(gè)代理服務(wù)器

隧道代理客戶(hù)端通過(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ù)載均衡：客戶(hù)端請(qǐng)求先到代理服務(wù)器，而代理服務(wù)器后面有多少源服務(wù)器，IP是多少，客戶(hù)端是不知道的。因此，代理服務(wù)器收到請(qǐng)求后，通過(guò)特定的算法(隨機(jī)算法、輪詢(xún)、一致性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:

記錄客戶(hù)端請(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)求的客戶(hù)端的IP，還有X-Forwarded-Host和X-Forwarded-Proto分別記錄真實(shí)發(fā)出請(qǐng)求的客戶(hù)端的域名和協(xié)議名

代理中客戶(hù)端IP偽造問(wèn)題以及如何預(yù)防？X-Forwarded-For是可以偽造的，比如一些通過(guò)X-Forwarded-For獲取到客戶(hù)端IP來(lái)限制刷票的系統(tǒng)就可以通過(guò)偽造該請(qǐng)求頭達(dá)到刷票的目的，如果客戶(hù)端請(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連接客戶(hù)端的IP，不會(huì)讀取偽造的

從右到左遍歷X-Forwarded-For的IP，排除已知代理服務(wù)器IP和內(nèi)網(wǎng)IP，獲取到第一個(gè)符合條件的IP就可以了正向代理和反向代理正向代理工作在客戶(hù)端的代理為正向代理。使用正向代理的時(shí)候，需要在客戶(hù)端配置需要使用的代理服務(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ì)用戶(hù)訪問(wèn)進(jìn)行授權(quán)反向代理工作在服務(wù)端的代理稱(chēng)為反向代理。使用反向代理的時(shí)候，不需要在客戶(hù)端進(jìn)行設(shè)置，反向代理對(duì)客戶(hù)端透明。如Nginx就是反向代理

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

代理中的長(zhǎng)連接在各個(gè)代理和服務(wù)器、客戶(hù)端節(jié)點(diǎn)之間是一段一段的TCP連接，客戶(hù)端通過(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緩存，客戶(hù)端緩存過(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ì)稱(chēng)加密算法通信，密鑰長(zhǎng)度128，分組模式GCM。TLS 1.3中只剩下稱(chēng)加密算法有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ì)稱(chēng)加密算法

就是加密和解密使用同一個(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ù)和加密方法，直接傳給客戶(hù)端，那過(guò)程中就很可能被竊取，別人就能成功解密拿到數(shù)據(jù)，往下看

不對(duì)稱(chēng)加密算法

就是一對(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ì)稱(chēng)密鑰至少要2048位才能保證安全性，這就導(dǎo)致性能上要比對(duì)稱(chēng)加密要差很多

所以！

TLS實(shí)際用的是兩種算法的混合加密。通過(guò) 非對(duì)稱(chēng)加密算法 交換 對(duì)稱(chēng)加密算法 的密鑰，交換完成后，再使用對(duì)稱(chēng)加密進(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ù)都屬于這類(lèi)算法，其特點(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)求被中間人截獲，中間人把他自己的公鑰給了客戶(hù)端，客戶(hù)端收到公鑰就把信息發(fā)給中間人了，中間人解密拿到數(shù)據(jù)后，再請(qǐng)求實(shí)際服務(wù)器，拿到服務(wù)器公鑰，再把信息發(fā)給服務(wù)器

這樣不知不覺(jué)間信息就被人竊取了，所以在結(jié)合對(duì)稱(chēng)和非對(duì)稱(chēng)加密的基礎(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ū)，以后客戶(hù)端連接服務(wù)器，都先把證書(shū)發(fā)給客戶(hù)端驗(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ū)，客戶(hù)端驗(yàn)證證書(shū)雙向認(rèn)證：服務(wù)器和客戶(hù)端分別提供證書(shū)給對(duì)方，并互相驗(yàn)證對(duì)方的證書(shū)

不過(guò)大多數(shù)服務(wù)器都是單向認(rèn)證，如果服務(wù)器需要驗(yàn)證客戶(hù)端的身份，一般通過(guò)用戶(hù)名、密碼、手機(jī)驗(yàn)證碼等之類(lèi)的憑證來(lái)驗(yàn)證。只有更高級(jí)別的要求的系統(tǒng)，比如大額網(wǎng)銀轉(zhuǎn)賬等，就會(huì)提供雙向認(rèn)證的場(chǎng)景，來(lái)確保對(duì)客戶(hù)身份提供認(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：就是客戶(hù)端和服務(wù)器首次連接手各自保存會(huì)話ID，并存儲(chǔ)會(huì)話密鑰，下次再連接時(shí)，客戶(hù)端發(fā)送ID過(guò)來(lái)，服務(wù)器這邊再查找ID，如果找到了就直接復(fù)用會(huì)話，密鑰也不用重新生成

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

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

這樣就萬(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)。這種方式被稱(chēng)為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)證，保證用戶(hù)訪問(wèn)正確。如訪問(wèn)百度，即使DNS被劫持到第三方站點(diǎn)，也會(huì)提醒用戶(hù)沒(méi)有訪問(wèn)百度服務(wù)，可能被劫持?jǐn)?shù)據(jù)完整性，防止內(nèi)容被第三方冒充或篡改雖然不是絕對(duì)安全，但是現(xiàn)行架構(gòu)下最安全的解決文案了，大大增加了中間人的攻擊成本缺點(diǎn)

要錢(qiá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)化用戶(hù)的網(wǎng)絡(luò)使用體驗(yàn)

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

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

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

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