學(xué)長(zhǎng)筆記開源了！
大家好，我是小林。
昨晚不是發(fā)了一篇讀者（車干學(xué)長(zhǎng)）看圖解網(wǎng)絡(luò)的學(xué)習(xí)心得嘛：我上 B 站了？
沒想到他還做了小筆記，就是他把在面試過程中高頻出現(xiàn)的網(wǎng)絡(luò)面試題做了筆記。
一直有很多同學(xué)問我，看書記不住知識(shí)怎么辦，其實(shí)最好的方式就是記筆記，學(xué)到的知識(shí)用自己語言輸出出來，這樣影響才會(huì)深刻的。
像我平?；卮鹨恍┳x者提問的 TCP 問題，我基本都能秒答，不是我記憶牛逼，是因?yàn)槲覍懙奶嗔?，不想記住都難。
我把昨天那位讀者學(xué)圖解網(wǎng)絡(luò)時(shí)記的筆記要過來了，是一個(gè)精練版的筆記，適合面試時(shí)突擊看看。但是不適合小白理解，因?yàn)槎际俏淖置枋?，沒有圖的方式來講解，所以小白還是先看圖解網(wǎng)絡(luò)，或者看視頻。
這位讀者（車干學(xué)長(zhǎng)）因?yàn)檎业氖乔岸碎_發(fā)工作，所以他寫的筆記都是 HTTP 相關(guān)的，而 TCP 的內(nèi)容就涉及很少。TCP 的內(nèi)容看我的圖解網(wǎng)絡(luò)就行了。
下面的筆記來源于讀者（B站：車干學(xué)長(zhǎng)）學(xué)習(xí)圖解網(wǎng)絡(luò)時(shí)的筆記，他也補(bǔ)充了一些我沒寫到的點(diǎn)，比如強(qiáng)制緩存/協(xié)商緩存之類的知識(shí)。
全文共 1w 字，干貨滿滿！發(fā)車！
HTTP 篇
get 與 post的關(guān)系
get的含義就是獲取網(wǎng)絡(luò)資源。
post的含義就是發(fā)布新的網(wǎng)絡(luò)資源。
安全、冪等方面，在安全方面，他們都是明文傳輸不存在安全的問題。然后就是get只是獲取服務(wù)器的資源，不會(huì)對(duì)服務(wù)器內(nèi)容進(jìn)行修改所以說，不存在安全問題。
對(duì)于冪等方面，get請(qǐng)求得到的結(jié)果都是一樣的，但是對(duì)于post而言卻不是一樣的。
HTTP 的特征
優(yōu)點(diǎn)：
良好的跨平臺(tái)性
不足：
明文傳輸 無狀態(tài)
HTTP/1.1 的特點(diǎn)
1.長(zhǎng)鏈接 connection：keep-alive
2.管道化傳輸，pipline
3.隊(duì)頭阻塞。
HTTP 與 HTTPS 的區(qū)別？
1.HTTP是超文本傳輸協(xié)議，信息是明文傳輸，存在安全風(fēng)險(xiǎn)。對(duì)于https而言就不存在這樣的問題，https在tcp和http中使用了ssl/tls來進(jìn)行數(shù)據(jù)加密。
2.HTTP的建立過程相對(duì)來說簡(jiǎn)單一些，HTTP在進(jìn)行了tcp/ip協(xié)議的三次握手之后建立了鏈接就可以進(jìn)行報(bào)文傳輸了。然而HTTPS在TCP三次握手之后還需要進(jìn)行TLS/SSL的握手才能進(jìn)行通信。
3.HTTP的端口號(hào)是80，HTTPS的端口號(hào)為443.
4.HTTPS需要向CA機(jī)構(gòu)申請(qǐng)數(shù)字證書，來保證服務(wù)器身份的可信度。
由于HTTP是明文傳輸所以說在傳輸過程中主要有以下幾個(gè)問題：
竊聽風(fēng)險(xiǎn)，通過抓包工具就可以獲取到http傳輸過程中的數(shù)據(jù)內(nèi)容。 篡改風(fēng)險(xiǎn)，通過抓包工具可以獲取到http傳輸?shù)膬?nèi)容進(jìn)行修改之后，再發(fā)送出去。 冒充風(fēng)險(xiǎn)，由于冒充者可以收到發(fā)送方的信息，那么冒充者就可以冒充真正的發(fā)送方給接收方發(fā)送信息。
HTTPS在HTTP和TCP層之間加入了SSL/TLS協(xié)議，可以很好的解決這個(gè)問題，一下是SSL/TLS的一些特征。
信息加密，解決的竊聽風(fēng)險(xiǎn)。 校驗(yàn)機(jī)制，因?yàn)閔ttps傳輸中都有校驗(yàn)和，如果被修改了，校驗(yàn)和將無法通過。 身份證書，對(duì)于冒充風(fēng)險(xiǎn)而言，利用權(quán)威機(jī)構(gòu)發(fā)布的CA就可以證明該服務(wù)器的身份。
HTTPS如何來解決HTTP的三個(gè)問題的呢？
混合加密，首先是HTTPS使用混合加密的方式來解決竊聽風(fēng)險(xiǎn)。 摘要算法，摘要算法的方式去實(shí)現(xiàn)完整性。他可以使得數(shù)據(jù)生成獨(dú)一無二的指紋，指紋用于校驗(yàn)傳輸數(shù)據(jù)的完整性，解決了篡改的風(fēng)險(xiǎn)。 CA中存放服務(wù)器公鑰，冒充風(fēng)險(xiǎn)，主要來源于密鑰傳輸?shù)目赡艽嬖陲L(fēng)險(xiǎn)，那么我們就可以直接將公鑰放置在證書中，讓別人無法去篡改公鑰，而后實(shí)現(xiàn)加密通信。
下面是以上三個(gè)問題的詳細(xì)展開：
混合加密：通過混合加密的方式，解決了通信過程中的竊聽風(fēng)險(xiǎn)，保證了信息的機(jī)密性。HTTPS使用的是對(duì)稱加密和非堆成加密相結(jié)合的混合加密方式。 對(duì)稱加密只需要使用一個(gè)密鑰，加解密的速度比較快，但是密鑰必須要保密，所以在進(jìn)行密鑰交換的時(shí)候就很困難。 非對(duì)稱加密使用了公鑰和密鑰，然后公鑰可以任意發(fā)放，然而密鑰卻需要自己保存，解決了對(duì)稱加密的密鑰交換問題。 在通訊建立的時(shí)候使用非對(duì)稱加密的方式來溝通密鑰。 然后再正常溝通的過程中使用對(duì)稱加密的方式來進(jìn)行溝通。 采用混合加密的方式原因如下： 摘要算法：客戶端在發(fā)送數(shù)據(jù)之前，就會(huì)將自己的數(shù)據(jù)全部進(jìn)行一次hash，得出指紋，然后用于校驗(yàn)和，解決了篡改問題。如果在傳輸過程中數(shù)據(jù)被修改了那么我們的數(shù)據(jù)包就不能通過數(shù)據(jù)校驗(yàn)的過程。 數(shù)字證書：客戶端先向服務(wù)端索取共鑰，然后使用公鑰進(jìn)行加密傳輸，服務(wù)端收到信息之后使用自己的私鑰進(jìn)行解密。但是這個(gè)時(shí)候就會(huì)存在問題，如果確保這個(gè)公鑰是服務(wù)端發(fā)送過來的，中間的篡改者一樣可以發(fā)送公鑰給客戶端，然后和客戶端建立聯(lián)系，然后客戶端的信息產(chǎn)生巨大的威脅。所以就需要一個(gè)值得信任的第三方機(jī)構(gòu)CA（數(shù)字證書認(rèn)證機(jī)構(gòu)），將服務(wù)器的公鑰封鎖到證書中去。只要證書是可信的，那么公鑰就是可信的。因此通過數(shù)字證書的方式，保證了服務(wù)器公鑰的身份，解決了冒充者的問題。
HTTPS是如何建立的，其間經(jīng)歷了什么？
SSL/TLS協(xié)議的基本流程為：客戶端向服務(wù)端索取公鑰，然后雙方協(xié)商會(huì)話密鑰，然后利用該會(huì)話密鑰，進(jìn)行加密通信。一共三步，前兩步是SSL/TLS的建立過程，也就是握手階段。握手階段進(jìn)行了四次通信。具體流程如下所示。
1.ClientHello
首先客戶端向服務(wù)端發(fā)起加密通信請(qǐng)求。這一步中主要包含了以下信息。（1）客戶端支持的SSL/TLS協(xié)議版本版本。（2）客戶端生產(chǎn)的隨機(jī)數(shù)（Client Random），后面用于生產(chǎn)「會(huì)話秘鑰」。（3）客戶端支持的加密算法，如RSA加密算法。
2.ServerHello
服務(wù)端接受到客戶端發(fā)送的請(qǐng)求之后，返回給客戶端一個(gè)回應(yīng)，主要包含內(nèi)容為：（1）確認(rèn)SSL/TLS版本。（2）服務(wù)端生成的隨機(jī)數(shù)，以后可以用于生成會(huì)話密鑰。（3）客戶端支持的加密算法，比如說RSA算法。（4）服務(wù)器的數(shù)字證書。
3.客戶端響應(yīng)
客戶端收到服務(wù)器的相應(yīng)之后，首先通過瀏覽器或者操作系統(tǒng)中的CA公鑰，確認(rèn)服務(wù)器的數(shù)字公鑰的正確性。如果服務(wù)器的公鑰沒有問題，那么我們就會(huì)利用該公鑰，對(duì)發(fā)送的內(nèi)容進(jìn)行加密。加密的內(nèi)容主要包含了一下三個(gè)方面：（1）客戶端隨機(jī)數(shù)，用于會(huì)話密鑰的生成。（2）服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束，之后的通信都用會(huì)話密鑰進(jìn)行通信。（3）這一項(xiàng)將之前所有的通信內(nèi)容做一個(gè)摘要供服務(wù)端校驗(yàn)。
4.服務(wù)端響應(yīng)
（1）加密方式改變通知，（2）服務(wù)端握手結(jié)束通知，并將之前的通信做一次摘要。
至此，整個(gè) SSL/TLS 的握手階段全部結(jié)束。接下來，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的 HTTP 協(xié)議，只不過用「會(huì)話秘鑰」加密內(nèi)容。
HTTP/1.1、HTTP/2、HTTP/3 演變
首先談及的是HTTP1.1相對(duì)于HTTP1.0提升了什么。
主要（1）HTTP1.1引入了長(zhǎng)鏈接，這樣的發(fā)送多個(gè)HTTP請(qǐng)求就不需要進(jìn)行多次建立連接了，使用connection：keep-alive來進(jìn)行控制。（2）就是管道化網(wǎng)絡(luò)傳輸（pipline），在沒有接受到客戶端第一個(gè)請(qǐng)求回應(yīng)的時(shí)候，就可以發(fā)送第二個(gè)網(wǎng)絡(luò)請(qǐng)求。
HTTP1.1的問題：（1）頭部阻塞：在http1.1的管道化傳輸中，雖然可以同時(shí)發(fā)送多個(gè)請(qǐng)求，但是只有收到第一個(gè)請(qǐng)求之后才能接受之后的請(qǐng)求，所以說如果第一個(gè)（對(duì)頭）發(fā)生了阻塞，那么我們之后所有的請(qǐng)求都會(huì)被阻塞。（2）頭部冗長(zhǎng)重復(fù)：每次發(fā)送http都要發(fā)送一個(gè)冗長(zhǎng)的請(qǐng)求，但是絕大部分重復(fù)的部分居多。（3）在該過程中，客戶端永遠(yuǎn)都是發(fā)起方，服務(wù)端永遠(yuǎn)都是被動(dòng)方。
HTTP2.0相對(duì)于HTTP1.1的性能提升之處：
頭部壓縮，HTTP/2會(huì)壓縮頭部，對(duì)于HTTP1.1中的大量重復(fù)冗余的頭部而言，可以消除重復(fù)的部分。 二進(jìn)制格式，不再像HTTP1.1中那種純文本格式的報(bào)文，而是全面采用了二進(jìn)制格式，頭信息和數(shù)據(jù)體都是二進(jìn)制，緊切統(tǒng)稱為幀：頭信息幀和數(shù)據(jù)幀。二進(jìn)制幀的形式，計(jì)算機(jī)在收到報(bào)文之后，不需要轉(zhuǎn)化為二進(jìn)制，而是直接將該報(bào)文解析，這增加了數(shù)據(jù)傳輸?shù)男省?/section> 數(shù)據(jù)流（多路復(fù)用）：HTTP/2 中的數(shù)據(jù)包不是按照順序發(fā)送的，同一個(gè)鏈接中可能包含了多個(gè)不同的回應(yīng)。因此，必須要對(duì)數(shù)據(jù)包做標(biāo)記，指出它屬于哪個(gè)回應(yīng)。能夠讓各個(gè)請(qǐng)求都能獨(dú)立。 服務(wù)端推送：HTTP/2還在一定程度上改善了傳統(tǒng)的請(qǐng)求-應(yīng)答機(jī)制，服務(wù)不再是被動(dòng)的等待響應(yīng)，也可以主動(dòng)給客戶端發(fā)送消息。
HTTP3相對(duì)于HTTP2的提升？
HTTP/2 主要的問題在于，多個(gè)HTTP請(qǐng)求在復(fù)用一個(gè)TCP連接，下層的TCP協(xié)議是不轉(zhuǎn)掉有多少個(gè)HTTP請(qǐng)求的。所以一旦發(fā)送丟包的情況，就會(huì)觸發(fā)TCP的重傳機(jī)制，這樣在一個(gè)TCP連接中的所有的HTTP請(qǐng)求都必須要去等待這個(gè)丟了的包被重傳回來。
HTTP/1.1中的管道（pipline）傳輸中如果有一個(gè)請(qǐng)求阻塞了，那么隊(duì)列后請(qǐng)求也統(tǒng)統(tǒng)會(huì)被阻塞住。 HTTP/2多個(gè)請(qǐng)求服用一個(gè)TCP鏈接，一旦發(fā)生了丟包，就會(huì)阻塞住所有的HTTP請(qǐng)求。
這些其實(shí)都是在TCP傳輸層出了問題，所以HTTP3的時(shí)候就把HTTP下層的TCP更換為了UDP！UDP實(shí)現(xiàn)了一個(gè)不可靠傳輸，但是基于 UDP 的 QUIC 協(xié)議可以實(shí)現(xiàn)類似于 TCP 的可靠傳輸。
QUIC 有自己的一套機(jī)制可以保證傳輸?shù)目煽啃?。?dāng)某一個(gè)流發(fā)生丟包的時(shí)候，只會(huì)阻塞這個(gè)流，不會(huì)影響到其他的流。 TLS3 升級(jí)到最新的1.3版本，頭部壓縮變?yōu)镼Pack。 HTTPS要建立連接的話，要花費(fèi)6次交互，先是要建立三次握手，然后是TLS的三次握手。QUIC直接把之前的TCP和TLS/1.3的三次握手合并為了3次，減少了交互的次數(shù)。所以說QUIC是一個(gè)新的協(xié)議，它是一個(gè)偽TCP+TLS+HTTP/2的多路復(fù)用的協(xié)議。
websocket 的特點(diǎn)是什么？
websocket解決了一個(gè)HTTP的致命問題：請(qǐng)求只能由客戶端發(fā)起的問題，即使HTTP2中新增了服務(wù)端推送，但是依然是在客戶端發(fā)起請(qǐng)求之后才新增的。
HTTP協(xié)議依然不能向客戶端發(fā)起推送信息。這種單向推送造成了不少的問題，就是如果說，服務(wù)器又連續(xù)的狀態(tài)變化，客戶端獲知就非常麻煩，只能通過輪詢的方法來獲取。
其特點(diǎn)為：
建立在TCP之上，服務(wù)器的實(shí)現(xiàn)比較簡(jiǎn)單 與HTTP協(xié)議有著良好的兼容性。默認(rèn)端口為80和443，并且握手階段采用和HTTP一樣的方式。 數(shù)據(jù)格式比較輕巧 可以發(fā)送文本，也可以放松二進(jìn)制數(shù)據(jù) 沒有同源策略限制 標(biāo)識(shí)符號(hào)為ws和wss
HTTP/1.1 優(yōu)化篇
主要有三個(gè)思路來優(yōu)化HTTP1.1協(xié)議，比如有三種思路來實(shí)現(xiàn)。
盡量避免發(fā)送HTTP請(qǐng)求 在需要發(fā)送HTTP請(qǐng)求的時(shí)候，考慮如何減少請(qǐng)求次數(shù) 減少服務(wù)器的HTTP響應(yīng)數(shù)據(jù)大小
下面就針對(duì)這三種思路具體看看有哪些優(yōu)化的方法。
一、盡量避免發(fā)送請(qǐng)求
緩存技術(shù)，客戶端會(huì)把第一次請(qǐng)求以及其響應(yīng)的數(shù)據(jù)保存在本地磁盤中，其中可以將通過key:value的形式去保存緩存的數(shù)據(jù)。
1.1 強(qiáng)制緩存，協(xié)商緩存的關(guān)系與區(qū)別：
瀏覽器第一次打開一個(gè)網(wǎng)頁獲取資源后，根據(jù)返回的header信息來告訴如何緩存資源。瀏覽器第一次請(qǐng)求。
瀏覽器發(fā)送請(qǐng)求，無緩存的情況下，請(qǐng)求響應(yīng)之后，根據(jù)響應(yīng)的頭部告訴我們?nèi)绾芜M(jìn)行緩存。1.expires 有效期至什么時(shí)候。2 cache-control ?3.Etag ? ?4.last-modified
在后續(xù)的請(qǐng)求中，在發(fā)送之前，會(huì)首先檢查本地緩存，是否含有該請(qǐng)求的結(jié)果。如果有的話，就先去檢查其頭部是否命中強(qiáng)制緩存（Expires 、cache-control），若命中直接從緩存中獲取資源信息，包括緩存header信息，本次請(qǐng)求就不會(huì)與服務(wù)器進(jìn)行通信。如果沒有命中的話，就會(huì)發(fā)送網(wǎng)絡(luò)請(qǐng)求，但是在發(fā)送的時(shí)候需要帶上其頭部有關(guān)的字段（Etag/If-none-match ?和 ?Last-modified/If-modified-since）由服務(wù)器來判斷是否命中協(xié)商緩存，如果命中的話，就返回一個(gè) 304 not modified，那么客戶端直接從緩存中獲取數(shù)據(jù)，如果返回了新的數(shù)據(jù)，那么就在緩存中更新相關(guān)的信息。
強(qiáng)制緩存相關(guān)字段
Expires策略：
expires是web服務(wù)器中響應(yīng)消息頭字段，在響應(yīng)http請(qǐng)求時(shí)告訴瀏覽器在過期時(shí)間前瀏覽器可以直接從瀏覽器緩存取數(shù)據(jù)，而無需再次請(qǐng)求。Expires設(shè)置失效時(shí)間，精確到時(shí)分秒。不過Expires 是HTTP 1.0的東西，現(xiàn)在默認(rèn)瀏覽器均默認(rèn)使用HTTP 1.1，所以它的作用基本忽略。
Cache-control策略：
cache-control與Expires的作用一致，都是指明當(dāng)前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存拿到數(shù)據(jù)還是從服務(wù)器端去獲取數(shù)據(jù)。只不過Cache-control的選項(xiàng)更多一些，設(shè)置更加精細(xì)，如果同時(shí)設(shè)置的話，其優(yōu)先級(jí)高于Expires。
Http協(xié)議頭：Cache-control 其value可以為 private、 no-cache 、no-store、 no-transform、 must-revalidate 、proxy-revalidate 、max-age
各個(gè)消息中的指令含義如下：
Public指示響應(yīng)可被任何緩存區(qū)緩存。 private指示對(duì)于單個(gè)用戶的整個(gè)或者部分響應(yīng)消息，不能被共享緩存處理。這允許服務(wù)器僅僅描述用戶的部分響應(yīng)消息，此相應(yīng)消息對(duì)于其他用戶的請(qǐng)求無效。 no-cache代表不緩存過期的資源，緩存會(huì)向服務(wù)器進(jìn)行有效處理確認(rèn)之后處理資源，do-not-serve-from-cache-without-revalidation no-store表示全面禁止緩存。 max-age指示客戶機(jī)可以接收生存期不大于指定時(shí)間（以秒為單位）的響應(yīng)。
如果cache-control與expires同時(shí)存在的話，cache-control的優(yōu)先級(jí)高于expires
協(xié)商緩存的相關(guān)字段
Last-modified/If-Modified-since 和 Etag/If-None-Match 這兩組搭檔是成對(duì)出現(xiàn)的，也就說第一次請(qǐng)求中出現(xiàn)了Last-modified，那么接下來的請(qǐng)求中就會(huì)帶上If-Modified-Since字段，如果第一次請(qǐng)求中帶有Etag字段的話，那么接下來的請(qǐng)求中就會(huì)帶有If-None-Match字段。
這兩個(gè)字段都需要配合Cache-control來使用，只有在未能命中強(qiáng)制緩存的時(shí)候，才能發(fā)起帶有協(xié)商緩存字段的請(qǐng)求。
Last-modified/If-Modified-since
last-modified：標(biāo)示這個(gè)響應(yīng)資源的最后修改時(shí)間。web服務(wù)器在響應(yīng)請(qǐng)求的時(shí)候，告訴服務(wù)器的請(qǐng)求最終修改時(shí)間。 If-modified-since：當(dāng)資源過期了，發(fā)現(xiàn)響應(yīng)頭中具有l(wèi)ast-modified聲明，則再次發(fā)起請(qǐng)求的時(shí)候帶上last-modified的時(shí)間，服務(wù)器收到請(qǐng)求后發(fā)現(xiàn)有if-modified-since則與被請(qǐng)求資源的最后修改時(shí)間進(jìn)行對(duì)比（Last-Modified）,若最后修改時(shí)間較新（大），說明資源又被改過，則返回最新資源，HTTP 200 OK;若最后修改時(shí)間較舊（?。?，說明資源無新修改，響應(yīng)HTTP 304 走緩存。
Etag/If-None-Match
Etag：服務(wù)器響應(yīng)時(shí)，告訴瀏覽器當(dāng)前資源在服務(wù)器的唯一標(biāo)識(shí)（生成規(guī)則由服務(wù)器決定）。Apache中，ETag的值，默認(rèn)是對(duì)文件的索引節(jié)（INode），大?。⊿ize）和最后修改時(shí)間（MTime）進(jìn)行Hash后得到的。 If-None-Match：當(dāng)資源過期時(shí)，瀏覽器發(fā)現(xiàn)響應(yīng)頭里有Etag,則再次像服務(wù)器請(qǐng)求時(shí)帶上請(qǐng)求頭 if-none-match(值是Etag的值)。服務(wù)器收到請(qǐng)求進(jìn)行比對(duì)，決定返回200或304。
Etag和Last-modified兩者為何并存？
看上去兩者的功能很是相似都是為了實(shí)現(xiàn)協(xié)商緩存，Etag的出現(xiàn)主要目的是為了解決幾個(gè)Last-modified不好解決的問題。
因?yàn)橛械奈募侵芷谛宰兓?，?duì)于客戶端來說意義不大，不需要客戶端去檢測(cè)到它的變化，所以采用大的版本控制的方式去檢測(cè)就可以了。這時(shí)，利用Etag能夠更加準(zhǔn)確的控制緩存，因?yàn)镋tag是服務(wù)器自動(dòng)生成或者由開發(fā)者生成的對(duì)應(yīng)資源在服務(wù)器端的唯一標(biāo)識(shí)符。
Etag和last-modified同時(shí)存在的時(shí)候Etag的優(yōu)先級(jí)更高
二、盡量減少HTTP請(qǐng)求次數(shù)
盡量減少重定向次數(shù) 合并請(qǐng)求 延遲發(fā)送請(qǐng)求
盡量減少重定向次數(shù)
減少重定向次數(shù)，服務(wù)器上的一個(gè)資源可能由于遷移、維護(hù)等原因從url轉(zhuǎn)移到url2后，而客戶端并不知道，客戶端此時(shí)并不會(huì)不會(huì)簡(jiǎn)單粗暴的返回錯(cuò)誤，而是通過302響應(yīng)碼和Location頭部，告訴客戶端該資源已經(jīng)遷移到url2上了，于是客戶端需要再次發(fā)送url2請(qǐng)求以獲取到服務(wù)器資源。那么如果重定向的次數(shù)過多了，每次客戶端都要多次發(fā)起HTTP請(qǐng)求，每一次的HTTP請(qǐng)求得經(jīng)過網(wǎng)絡(luò)，這無疑會(huì)降低網(wǎng)絡(luò)性能。
301: Moved Permanently ?資源永久重定向到另外一個(gè)URI
302: Found/Moved Temporarily 資源臨時(shí)重定向到另外一個(gè)URI中
合并請(qǐng)求
可以將多個(gè)小文件的請(qǐng)求合并為一個(gè)大的請(qǐng)求，雖然傳輸?shù)目傎Y源是一定的，但是減少了請(qǐng)求的次數(shù)，這就意味著減少了重復(fù)發(fā)送HTTP頭部。
延遲發(fā)送請(qǐng)求
圖片懶加載等等。
三、減小HTTP響應(yīng)的數(shù)據(jù)大小
減少HTTP響應(yīng)數(shù)據(jù)的大小，從而提高網(wǎng)絡(luò)傳輸?shù)男省?duì)數(shù)據(jù)進(jìn)行壓縮。
HTTPS RSA 篇
TLS握手過程
HTTP由于是明文傳輸，也就是說客戶端與服務(wù)端通信的信息都是肉眼可見的，隨意使用一個(gè)抓包工具都是可以截獲通信的內(nèi)容。
竊聽風(fēng)險(xiǎn)、篡改風(fēng)險(xiǎn)、冒充風(fēng)險(xiǎn)這三種風(fēng)險(xiǎn)。
SSL/TLS是通過，信息加密：HTTP交互的信息被加密之后，第三方就無法竊聽。校驗(yàn)機(jī)制：校驗(yàn)信息傳輸過程中是否有被第三方篡改過，如果被篡改過，則會(huì)有警告提示。身份驗(yàn)證，證明真的是該網(wǎng)站。
通常經(jīng)過【四個(gè)消息】就可以完成TLS握手，也就說需要兩個(gè)RTT的時(shí)延，然后通信就是建立了TLS連接。事實(shí)上不同的密鑰交換算法，TLS的握手過程可能會(huì)有不同，在該文章中，我們只介紹RSA密鑰交換算法，來看看它的TLS握手過程。
TLS第一次握手：
客戶端與服務(wù)端在進(jìn)行完畢TCP/IP協(xié)議的三次握手之后，發(fā)送一個(gè)Hello Server消息，TLS版本信息，支持的密碼套件等信息。注意此處包含三個(gè)信息，一：隨機(jī)數(shù)，二：密碼套件（加密算法等等），三，TLS版本信息
TLS第二次握手：
當(dāng)服務(wù)端收到客戶端的消息之后，就會(huì)確認(rèn)TLS版本號(hào)是否支持，從密碼套件列表中選擇一個(gè)密碼套件，以及生成隨機(jī)數(shù)，之后還會(huì)返回證書，來證明自己的身份。值得注意的是，在此處，我們注意到一共發(fā)送了四個(gè)內(nèi)容，分別為：TLS版本號(hào)，密碼套件，隨機(jī)數(shù)，還有證書。其中客戶端驗(yàn)證證書是需要通過證書鏈來進(jìn)行驗(yàn)證的。
TLS第三次握手：
客戶端驗(yàn)證完證書之后，認(rèn)為可信則繼續(xù)往下走。接著，客戶端就會(huì)生成一個(gè)新的隨機(jī)數(shù)，用服務(wù)器的RSA公鑰對(duì)該隨機(jī)數(shù)進(jìn)行加密，服務(wù)端收到隨機(jī)數(shù)之后，用之前的三個(gè)隨機(jī)數(shù)合并成為一個(gè)會(huì)話密鑰。他是對(duì)稱密鑰，用于對(duì)后續(xù)的HTTP請(qǐng)求/響應(yīng)的數(shù)據(jù)進(jìn)行加密?？蛻舳藢⑺械闹暗臄?shù)據(jù)做一個(gè)摘要，以供服務(wù)端驗(yàn)證。通知服務(wù)端該用新的對(duì)稱加密方式。
TLS第四次握手：
同樣的操作，服務(wù)端也通知客戶端改變加密方式。
RSA算法的缺陷：
RSA密鑰協(xié)商算法最大的問題再約不支持 前向保密。因?yàn)榭蛻舳藗鬟f隨機(jī)數(shù)給服務(wù)端時(shí)候使用公鑰進(jìn)行加密，服務(wù)端收到之后會(huì)使用私鑰進(jìn)行解密。一旦服務(wù)端的私鑰泄漏了，過去被第三方截獲的所有TLS通信密文都會(huì)被破解。
于是就有了DH密鑰協(xié)商算法，服務(wù)端和客戶端個(gè)字會(huì)生成隨機(jī)數(shù)，并一次作為私鑰，然后根據(jù)公開的DH計(jì)算出各自的公鑰，通過TLS握手雙方的公鑰和自己的私鑰算出一個(gè)隨機(jī)數(shù)。這個(gè)隨機(jī)數(shù)的值就可以作為后續(xù)堆成加密算法的密鑰。
客戶端驗(yàn)證證書：
數(shù)字證書和CA機(jī)構(gòu)：
在說校驗(yàn)數(shù)字證書是否可信的過程前，我們先來看看數(shù)字證書是什么，一個(gè)數(shù)字證書通常包含了：
公鑰 持有者信息 CA機(jī)構(gòu)的信息 證書認(rèn)證機(jī)構(gòu)（CA）的信息 CA對(duì)此份文件的數(shù)字簽名以及使用的算法 證書有效期等
為了讓服務(wù)端的公鑰能被大家信任，服務(wù)端的證書都是由CA機(jī)構(gòu)簽名的，CA就是網(wǎng)絡(luò)世界中的公安局，具有極高的可信度，所以由他來給各個(gè)公鑰簽名，信任的一方簽發(fā)的證書，必定也是可信任的。之所以要簽名，是因?yàn)楹灻淖饔每梢员苊庵虚g人在獲取證書時(shí)對(duì)證書內(nèi)容進(jìn)行篡改。
數(shù)字證書的簽發(fā)和驗(yàn)證流程：
CA簽發(fā)證書的過程中，如上圖左側(cè)部分：首先CA會(huì)把持有者的公鑰、用途、頒發(fā)者、有效期等等信息打成一個(gè)包，然后對(duì)這些信息進(jìn)行Hash計(jì)算，得到一個(gè)Hash值。然后使用自己的私鑰對(duì)該Hash值進(jìn)行加密，生成一個(gè)Certificate Signature，也就是對(duì)證書做了一個(gè)簽名。最后將其添加到證書中。
證書的驗(yàn)證過程?？蛻舳藭?huì)使用同樣的Hash算法獲取該證書的Hash值H1，然后瀏覽器和操作系統(tǒng)中集成了CA的公鑰來解密Certificate Signature內(nèi)容來得到一個(gè)Hash2，將二者進(jìn)行比較。
如果相同則證明該證書是可信的，如果不相同，則證明是不可信的。
證書鏈：
事實(shí)上，證書的驗(yàn)證過程中還存在一個(gè)證書信任鏈的問題，因?yàn)槲覀兿駽A申請(qǐng)的證書一般來說都不是根證書簽發(fā)的，二是由中間證書簽發(fā)的。
服務(wù)端收到 baidu.com 的證書之后，發(fā)現(xiàn)這個(gè)證書的簽發(fā)者不是根證書，就無法根據(jù)本地已有的證書中的公鑰去驗(yàn)證 baidu.com 的證書是否可信。于是，客戶端根據(jù) baidu.com 證書中的簽發(fā)者，找到該證書的簽發(fā)機(jī)構(gòu)是 "GlobalSign Organization Validation CA -SHA-256-G2"，然后向CA請(qǐng)求該中間證書。
請(qǐng)求到證書后發(fā)現(xiàn) "GlobalSign Organization Validation CA -SHA-256-G2" 證書是由根CA 簽發(fā)的，由于根CA沒有再上級(jí)的機(jī)構(gòu)，應(yīng)用軟件就會(huì)檢查該證書是否已經(jīng)加載在根證書清單中。如果有，用根證書公鑰去驗(yàn)證"GlobalSign Organization Validation CA -SHA-256-G2"的證書，如果驗(yàn)證通過，那么就信任該中間公鑰的是可信，中間證書可信之后，再根據(jù)中間證書的公鑰去獲取最底層的證書公鑰。
HTTPS ECDHE 篇
HTTPS常用的密鑰協(xié)商算法有兩種分別為RSA和ECDHE。其中RSA是比較傳統(tǒng)的密鑰交換算法，不具備前向安全的性質(zhì)，因此現(xiàn)在很少瀏覽器使用的。而ECDHE算法具有前向安全，所以被廣泛使用。（我在上一篇文章中已經(jīng)講述了RSA的握手過程）
ECDHE算法是從DH算法演變而來的，所以我們先從DH算法說起。DH算法是非對(duì)稱加密算法，因此他可以用于密鑰交換，該算法的核心數(shù)學(xué)思想就是離散對(duì)數(shù)。
首先科普一下對(duì)數(shù)的基本知識(shí)（算了吧，下面的推倒和證明的東西都有在小林的圖解網(wǎng)絡(luò)中說明了，我就不講了。。）
TCP 篇
什么是 TCP？
TCP是面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。這里面有三個(gè)關(guān)鍵詞，分別為面向連接的、可靠的、基于字節(jié)流
面向連接的：指的是一對(duì)一的連接方式、不能像 UDP 那樣可以一個(gè)主機(jī)同時(shí)向多個(gè)主機(jī)發(fā)送消息，也就是說一對(duì)多是無法實(shí)現(xiàn)的。
可靠的：無論網(wǎng)絡(luò)狀況出現(xiàn)了怎樣的鏈路變化，TCP 都能保證一個(gè)報(bào)文一定能夠到達(dá)接收端。
字節(jié)流：消息是沒有邊界的，所以無論我們消息有多大都可以進(jìn)行傳輸。并且消息是有序的，當(dāng)前一個(gè)消息沒有收到的時(shí)候，即使他先收到后面的字節(jié)，那么也不能扔給應(yīng)用層去處理，同時(shí)對(duì)于重復(fù)的報(bào)文會(huì)自動(dòng)丟棄。
TCP 和 UDP 的區(qū)別
連接方面：
TCP 是面向連接的傳輸層協(xié)議傳輸之前首先要建立連接。
UDP 是不需要建立連接的，即可傳輸數(shù)據(jù)。
服務(wù)對(duì)象：
TCP是一對(duì)一的兩點(diǎn)服務(wù)，即一條連接只有兩個(gè)端點(diǎn)。 UDP支持一對(duì)一、一對(duì)多、多對(duì)多的交通通信。
可靠性：
TCP是可靠交付數(shù)據(jù)的，數(shù)據(jù)可以無差別、不丟失、不重復(fù)、按需到達(dá)。
UDP是盡最大可能交付，不保證可靠交付數(shù)據(jù)。
擁塞控制、流量控制：
TCP有擁塞控制和流量控制機(jī)制，考證數(shù)據(jù)傳輸?shù)陌踩浴?/p>
UDP則沒有，即使網(wǎng)絡(luò)非常擁堵了，也不會(huì)影響UDP的發(fā)送速率。
首部開銷：
TCP手部長(zhǎng)度較長(zhǎng)，會(huì)有一定的開銷，收不在沒有使用【選項(xiàng)】字段有20個(gè)字節(jié)，如果使用了【選項(xiàng)】字段會(huì)更長(zhǎng)。
UDP首部只有8個(gè)字節(jié)，并且是固定不變的、開銷較小。
傳輸方式：
TCP是流式傳輸、沒有邊界，但保證順序和可靠。
網(wǎng)絡(luò)安全篇
XSS
xss（cross-site script）
反射型XSS：<非持久化> 攻擊者事先制作好攻擊鏈接, 需要欺騙用戶自己去點(diǎn)擊鏈接才能觸發(fā)XSS代碼（服務(wù)器中沒有這樣的頁面和內(nèi)容），一般容易出現(xiàn)在搜索頁面。比如說將script腳本放置在請(qǐng)求參數(shù)中，然后頁面中需要用到請(qǐng)求參數(shù)，就會(huì)直接執(zhí)行該script標(biāo)簽。 存儲(chǔ)型XSS：<持久化> 代碼是存儲(chǔ)在服務(wù)器中的，如在個(gè)人信息或發(fā)表文章等地方，加入代碼，如果沒有過濾或過濾不嚴(yán)，那么這些代碼將儲(chǔ)存到服務(wù)器中，每當(dāng)有用戶訪問該頁面的時(shí)候都會(huì)觸發(fā)代碼執(zhí)行，這種XSS非常危險(xiǎn)，容易造成蠕蟲，大量盜竊cookie（雖然還有種DOM型XSS，但是也還是包括在存儲(chǔ)型XSS內(nèi)）。同上面的情況類似，入侵者將script標(biāo)簽寫到了數(shù)據(jù)庫中，然后每次發(fā)送請(qǐng)求之后，每次打開頁面之后都會(huì)執(zhí)行script標(biāo)簽。
防御：
標(biāo)簽轉(zhuǎn)譯：分為黑名單轉(zhuǎn)譯，將所有的<,>,/,都給轉(zhuǎn)譯為其他字符。">"為">" "<"為"<".白名單的話就是使用xss庫?？梢园演斎氲奈淖侄冀o部分轉(zhuǎn)譯一下。
應(yīng)為xss主要的目的是為了獲取你的cookie，然后那么我只需要設(shè)置在cookie中設(shè)置，http-only，就可以了，因?yàn)閤ss是要先從document中獲取到cookie，然后再發(fā)送出去，實(shí)際上呢我們將其設(shè)置為只有在發(fā)送http請(qǐng)求的時(shí)候才能帶上cookie。
CSP 內(nèi)容安全策略（CSP）是一個(gè)額外的安全層，用于檢測(cè)并削弱某些特定類型的攻擊，包括跨站腳本和數(shù)據(jù)注入攻擊等。無論是數(shù)據(jù)盜取、網(wǎng)站內(nèi)容污染還是散發(fā)惡意軟件，這些都是主要的手段。我們可以通過CSP來盡量減少XSS攻擊，CSP本質(zhì)上也是建立白名單，規(guī)定了瀏覽器只能夠執(zhí)行特定來源的代碼。通常我們可以通過HTTP Header中的
Content-Security-Policy來開啟CSP只允許加載本站資源
Content-Security-Policy:?default-src?'self'只允許加載HTTPS協(xié)議圖片
Content-Security-Policy:?img-src?https://*允許加載任何來源
Content-Security-Policy:child-src?'none'
CSRF
CSRF（Cross-site request forgery），中文名稱：跨站請(qǐng)求偽造，也被稱為：one click attack/session riding，縮寫為：CSRF/XSRF。
它主要就是利用你的瀏覽器保存了你的登陸信息，通過另外一個(gè)網(wǎng)址，在該網(wǎng)址中發(fā)送一個(gè)跨站請(qǐng)求，攜帶者你的身份認(rèn)證，這樣就可以成功的對(duì)你的賬號(hào)進(jìn)行操作了。
防御方式：
reference check，但是很多時(shí)候，reference是可以修改的。 cookie hash的方法，在表單中植入md5密碼，雖然md5的安全性不太行，但是還是應(yīng)對(duì)此問題已經(jīng)夠用了，因?yàn)槊總€(gè)表單中的隨機(jī)數(shù)都是不一樣的。 手機(jī)驗(yàn)證碼 sameSite：可以對(duì)Cookie進(jìn)行設(shè)置，Samesite屬性。該屬性設(shè)置Cookie不隨著跨域請(qǐng)求發(fā)送，該屬性可以很大程度上減少CSRF的攻擊。
點(diǎn)擊劫持
這是一種視覺欺騙的方式，讓你以為在點(diǎn)擊一個(gè)正確的按鈕的時(shí)候發(fā)送了一個(gè)別的請(qǐng)求。將該網(wǎng)站放置在一個(gè)iframe中，然后造成視覺的誤差。
防御：
X-Frame-Options：deny
請(qǐng)求劫持
DNS劫持（DNS解析被劫持）
HTTP劫持（使用HTTPS）
DDOS（distributed denial of service）
syn flood http flood
完！