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

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

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

【資料圖】

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

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

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

請求行：包含

方法

描述

GET

獲取資源

POST

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

HEAD

獲得報(bào)文首部

PUT

更新資源

PATCH

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

DELETE

刪除資源

OPTIONS

列出請求資源支持的請求方法，用來跨域請求

TRACE

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

CONNECT

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

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

2xx: 成功——表示請求已被成功接收

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

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

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

常見狀態(tài)碼：

狀態(tài)碼

描述

200

請求成功

206

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

301

永久重定向

302

臨時(shí)重定向

304

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

400

請求有語法錯(cuò)誤

401

沒有權(quán)限訪問

403

服務(wù)器拒絕執(zhí)行請求，場景如不允許直接訪問，只能通過服務(wù)器訪問時(shí)

404

請求資源不存在

500

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

503

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

什么是持久連接/長連接協(xié)議為無連接的協(xié)議)

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

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

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

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

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

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

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

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

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

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

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

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

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

并發(fā)連接因?yàn)橐粋€(gè)域名允許分配多個(gè)長連接，就相當(dāng)于增加了任務(wù)隊(duì)列，不至于一個(gè)隊(duì)列里的任務(wù)阻塞了其他全部任務(wù)。以前在RFC2616中規(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è)，那咱就多來幾個(gè)域名

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

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

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

普通代理(中間人代理)

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

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

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

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

為什么需要隧道代理呢？

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

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

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

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

Via: 1.1 vegurVia:

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

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

X-Real-IP

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

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

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

預(yù)防

在對外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ù)器，正向代理對服務(wù)端透明。比如抓包工具Fiddler、Charles以及訪問一些外網(wǎng)網(wǎng)站的代理工具都是正向代理

正向代理通常用于

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

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

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

逐段傳輸頭會(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)閉，使得對同一服務(wù)器的請求可以繼續(xù)在該連接上完成

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

緩存代理就是讓代理服務(wù)器接管一部分的服務(wù)端的http緩存，客戶端緩存過期之后就近到代理服務(wù)器的緩存中獲取，代理緩存過期了才請求源服務(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則是開源版本的

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

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

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

RSA：表示握手時(shí)用RSA算法交換密鑰PSK：表示使用PSK算法簽名AES128-GCM：表示使用AES256對稱加密算法通信，密鑰長度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)性，每一種算法都有其特定的用處

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

對稱加密算法

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

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

不對稱加密算法

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

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

所以！

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

瀏覽器給服務(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ù)用加密方法混合生成最終密鑰這樣即便被截持，中間人沒有私鑰就拿不到pre-random，就無法生成最終密鑰。

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

摘要算法

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

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

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

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

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

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

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

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

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

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

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

連接

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

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ù)用加密方法混合生成最終密鑰然后開始通信

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ù)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ì)對之前的歷史信息產(chǎn)生影響，，所以在TLS 1.3中徹底取代了RSA。目前主流都是用ECDHE算法來做密鑰交換的

TLS1.3版本中握手過程是這樣子的

瀏覽器生成client-params、和client-random、TLS版本和加密方法列表發(fā)送給服務(wù)器服務(wù)器返回server-params、server-random、加密方法、證書、摘要等傳給瀏覽器瀏覽器確認(rèn)應(yīng)答，返回握手?jǐn)?shù)據(jù)摘要等信息傳給服務(wù)器簡單說就是簡化了握手過程，只有三步，把原來的兩個(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過來，服務(wù)器這邊再查找ID，如果找到了就直接復(fù)用會(huì)話，密鑰也不用重新生成

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

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

這樣就萬無一失了嗎？

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

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

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

這樣萬無一失了嗎？

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

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

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

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

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

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

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

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

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

主要通過幀、多路復(fù)用、請求優(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核心人員后來都參加到的支持

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

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

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

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

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

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

特點(diǎn)：

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

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

標(biāo)簽：