1.1憎茂、如何通過三次握手建立連接
首先我們要清楚一個(gè)概念：http請(qǐng)求與TCP鏈接之間的關(guān)系透敌，在客戶端向服務(wù)端請(qǐng)求和返回的過程中领斥，是需要去創(chuàng)建一個(gè)TCP connection嫉拐， 因?yàn)閔ttp是不存在鏈接這樣的概念的鳍悠，它只有請(qǐng)求和響應(yīng)的概念税娜，請(qǐng)求和響應(yīng)都是一個(gè)數(shù)據(jù)包，中間要通過一個(gè)傳輸通道藏研，這個(gè)傳輸通道就是在TCP里面創(chuàng)建了一個(gè)從客戶端發(fā)起和服務(wù)端接收的一個(gè)鏈接敬矩，TCP 鏈接在創(chuàng)建的時(shí)候是有一個(gè)三次握手(三次網(wǎng)絡(luò)傳輸)這樣一個(gè)消耗在的。
TCP的核心思想：為了保證傳輸?shù)目煽?/strong>蠢挡。 其次弧岳，保證傳輸效率。
為什么是三次握手： 第一次握手CLIENT告訴SERVER“我將要開始傳輸數(shù)據(jù)了”业踏。 第二次握手SERVER告訴CLIENT“我已經(jīng)知道你將要傳輸數(shù)據(jù)了禽炬，我已經(jīng)做好準(zhǔn)備”。 第三次握手CLIENT告訴SERVER“我已經(jīng)知道你已經(jīng)知道'我知道你已經(jīng)做好準(zhǔn)備'”勤家，SERVER端收到這個(gè)信號(hào)腹尖，開始傳輸數(shù)據(jù)。
TCP標(biāo)示: SYN(synchronous
同步建立聯(lián)機(jī))伐脖、 ACK(acknowledgement 確認(rèn))热幔、 Sequence number(順序號(hào)碼)
第一次握手： 建立連接，客戶端A發(fā)送SYN = 1晓殊，隨機(jī)產(chǎn)生Seq=client_isn的數(shù)據(jù)包到服務(wù)器B断凶，等待服務(wù)器確認(rèn)。
第二次握手：服務(wù)器B收到請(qǐng)求后確認(rèn)聯(lián)機(jī)(可以接收數(shù)據(jù))巫俺， 發(fā)起第二次握手請(qǐng)求认烁， ACK=(A的Seq+1)、SYN=1, 隨機(jī)產(chǎn)生Seq=client_isn的數(shù)據(jù)包到A。
第三次握手：A收到后檢查ACK是否正確却嗡。若正確舶沛，A會(huì)在發(fā)送確認(rèn)包ACK=服務(wù)器B的Seq+1、ACK=1窗价， 服務(wù)器B收到后確認(rèn)Seq 值與 ACK值如庭，若正確，則建立連接撼港。
TCP的狀態(tài) (SYN, FIN, ACK, PSH, RST, URG) eg
狀態(tài) 標(biāo)志狀態(tài) 備注 SYN 表示建立連接 只是單個(gè)的一個(gè)SYN坪它，它表示的只是建立連接。 FIN 表示關(guān)閉連接 SYN與FIN是不會(huì)同時(shí)為1的帝牡。 ACK 表示響應(yīng) TCP的幾次握手就是通過這樣的ACK表現(xiàn)出來的往毡。 PSH 表示有 DATA數(shù)據(jù)傳輸 PSH為1表示的是有真正的TCP數(shù)據(jù)包內(nèi)容被傳遞。 RST 表示連接重置 RST一般是在FIN之后才會(huì)出現(xiàn)為1的情況靶溜。 URG urgent緊急
1.2开瞭、三次握手?jǐn)?shù)據(jù)包詳細(xì)分析
Wireshark（前稱Ethereal）是一個(gè)網(wǎng)絡(luò)數(shù)據(jù)包分析軟件。網(wǎng)絡(luò)數(shù)據(jù)包分析軟件的功能是截取網(wǎng)絡(luò)數(shù)據(jù)包罩息，并盡可能顯示出最為詳細(xì)的網(wǎng)絡(luò)數(shù)據(jù)包數(shù)據(jù)嗤详。Wireshark使用WinPCAP作為接口，直接與網(wǎng)卡進(jìn)行數(shù)據(jù)報(bào)文交換瓷炮。使用技巧
ip.addr == 服務(wù)器端ip 演示例子
- 第一次握手請(qǐng)求葱色，如下圖： 客戶端發(fā)送一個(gè)TCP，標(biāo)志位為 SYN崭别，Seq(序列號(hào))=0冬筒，代表客戶端請(qǐng)求建立鏈接 。
- 第二次握手請(qǐng)求茅主，服務(wù)器發(fā)回?cái)?shù)據(jù)包舞痰，標(biāo)志位為[SYN, ACK]，ACK設(shè)置為客戶端第一次握手請(qǐng)求的Seq+1诀姚，即ACK=0+1=1响牛，在隨機(jī)產(chǎn)生一個(gè)Seq的數(shù)據(jù)包到客戶端。
- 第三次握手請(qǐng)求赫段，客戶端在次發(fā)送確認(rèn)數(shù)據(jù)包呀打，標(biāo)識(shí)位為ACK，把服務(wù)器發(fā)來的Seq+1糯笙，即ACK=0+1贬丛，發(fā)送給服務(wù)器，服務(wù)器成功收到ACK報(bào)文段之后给涕，連接就建立成功了豺憔。
2.1 瀏覽器緩存
瀏覽器緩存控制機(jī)制有兩種：
HTML Meta標(biāo)簽 (非HTTP協(xié)議定義的緩存機(jī)制)
HTTP頭信息 (HTTP協(xié)議定義的緩存機(jī)制), 今天主要講解HTTP頭信息控制緩存额获。
2.1.1 為什么需要瀏覽器緩存？
我們知道通過HTTP協(xié)議恭应，在客戶端和瀏覽器建立連接時(shí)需要消耗時(shí)間抄邀，而大的響應(yīng)需要在客戶端和服務(wù)器之間進(jìn)行多次往返通信才能獲得完整的響應(yīng)，這拖延了瀏覽器可以使用和處理內(nèi)容的時(shí)間昼榛。這就增加了訪問服務(wù)器的數(shù)據(jù)和資源的成本境肾，因此利用瀏覽器的緩存機(jī)制重用以前獲取的數(shù)據(jù)就變成了性能優(yōu)化時(shí)需要考慮的事情。
首先胆屿，思考兩個(gè)問題：
在頁面中引入靜態(tài)資源文件（css,img,js等）奥喻，為什么靜態(tài)資源文件改變后，再次發(fā)起請(qǐng)求還是之前的內(nèi)容非迹，沒有變化呢衫嵌？
在使用webpack等一些打包工具時(shí)，為什么要加上一串hash碼彻秆？
2.1.2 瀏覽器請(qǐng)求流程圖
- 瀏覽器第一次請(qǐng)求流程圖（圖片來源網(wǎng)絡(luò)）：
- 瀏覽器再次請(qǐng)求時(shí)（圖片來源網(wǎng)絡(luò)）：
2.1.3 重要概念 詳情
- Etag/If-None-Match：Etag/If-None-Match也要配合Cache-Control使用。
Etag：web服務(wù)器響應(yīng)請(qǐng)求時(shí)结闸，告訴瀏覽器當(dāng)前資源在服務(wù)器的唯一標(biāo)識(shí)（生成規(guī)則由服務(wù)器決定）唇兑。通常情況下，ETag更類似于資源指紋(fingerprints)桦锄，如果資源發(fā)生變化了就會(huì)生成一個(gè)新的指紋，這樣可以快速的比較資源的變化。
If-None-Match：當(dāng)資源過期時(shí)（使用Cache-Control標(biāo)識(shí)的max-age）放仗，發(fā)現(xiàn)資源具有Etage聲明崎脉，則再次向web服務(wù)器請(qǐng)求時(shí)帶上頭If-None-Match （Etag的值）。web服務(wù)器收到請(qǐng)求后發(fā)現(xiàn)有頭If-None-Match 則與被請(qǐng)求資源的相應(yīng)校驗(yàn)串進(jìn)行比對(duì)图甜，決定返回200或304碍粥。
- Last-Modified/If-Modified-Since：Last-Modified/If-Modified-Since要配合Cache-Control使用。
Last-Modified：標(biāo)示這個(gè)響應(yīng)資源的最后修改時(shí)間黑毅。web服務(wù)器在響應(yīng)請(qǐng)求時(shí)嚼摩，告訴瀏覽器資源的最后修改時(shí)間。If-Modified-Since：當(dāng)資源過期時(shí)（使用Cache-Control標(biāo)識(shí)的max-age）矿瘦，發(fā)現(xiàn)資源具有Last-Modified聲明枕面，則再次向web服務(wù)器請(qǐng)求時(shí)帶上頭 If-Modified-Since，表示請(qǐng)求時(shí)間缚去。web服務(wù)器收到請(qǐng)求后發(fā)現(xiàn)有頭If-Modified-Since 則與被請(qǐng)求資源的最后修改時(shí)間進(jìn)行比對(duì)潮秘。若最后修改時(shí)間較新，說明資源又被改動(dòng)過易结，則響應(yīng)整片資源內(nèi)容（寫在響應(yīng)消息包體內(nèi)）枕荞，HTTP 200柜候；若最后修改時(shí)間較舊，說明資源無新修改买猖，則響應(yīng)HTTP 304 (無需包體改橘，節(jié)省瀏覽)，告知瀏覽器繼續(xù)使用所保存的cache玉控。
Expires策略：Expires是Web服務(wù)器響應(yīng)消息頭字段飞主，在響應(yīng)http請(qǐng)求時(shí)告訴瀏覽器在過期時(shí)間前瀏覽器可以直接從瀏覽器緩存取數(shù)據(jù)，而無需再次請(qǐng)求高诺。不過Expires 是HTTP 1.0的東西碌识，現(xiàn)在默認(rèn)瀏覽器均默認(rèn)使用HTTP 1.1，所以它的作用基本忽略虱而。Expires 的一個(gè)缺點(diǎn)就是筏餐，返回的到期時(shí)間是服務(wù)器端的時(shí)間，這樣存在一個(gè)問題牡拇，如果客戶端的時(shí)間與服務(wù)器的時(shí)間相差很大（比如時(shí)鐘不同步魁瞪，或者跨時(shí)區(qū)），那么誤差就很大惠呼，所以在HTTP 1.1版開始导俘，使用Cache-Control: max-age=秒替代。Cache-control策略（重點(diǎn)關(guān)注）：Cache-Control與Expires的作用一致剔蹋，都是指明當(dāng)前資源的有效期旅薄，控制瀏覽器是否直接從瀏覽器緩存取數(shù)據(jù)還是重新發(fā)請(qǐng)求到服務(wù)器取數(shù)據(jù)。只不過Cache-Control的選擇更多泣崩，設(shè)置更細(xì)致少梁，如果同時(shí)設(shè)置的話，其優(yōu)先級(jí)高于Expires矫付。
值可以是public凯沪、private、no-cache技即、no- store著洼、no-transform、must-revalidate而叼、proxy-revalidate身笤、max-age
| Cache-Control值 | 說明 | 特性 |
|---|---|---|
| Public | 指示響應(yīng)可被任何緩存區(qū)緩存。 | 可緩存性 |
| Private | 指示對(duì)于單個(gè)用戶的整個(gè)或部分響應(yīng)消息葵陵，不能被共享緩存處理液荸。 這允許服務(wù)器僅僅描述當(dāng)用戶的部分響應(yīng)消息， 此響應(yīng)消息對(duì)于其他用戶的請(qǐng)求無效脱篙。 | 可緩存性 |
| no-cache | 指示請(qǐng)求或響應(yīng)消息不能緩存娇钱，該選項(xiàng)并不是說可以設(shè)置 ”不緩存“伤柄，切勿望文生義~~ | 可緩存性 |
| max-age | 指示客戶機(jī)可以接收生存期不大于指定時(shí)間（以秒為單位）的響應(yīng)。 | 到期 |
| s-maxage | 會(huì)代替max-age文搂，只有在代理服務(wù)器（nginx代理服務(wù)器）才會(huì)生效 | 到期 |
| max-stale | 是發(fā)起請(qǐng)求方主動(dòng)帶起的一個(gè)頭适刀，是代表即便緩存過期， 但是在max-stale這個(gè)時(shí)間內(nèi)還可以使用過期的緩存煤蹭， 而不需要愿服務(wù)器請(qǐng)求新的內(nèi)容 | 到期 |
| must-revalidate | 如果max-age設(shè)置的內(nèi)容過期笔喉，必須要向服務(wù)器請(qǐng)求重新獲取 數(shù)據(jù)驗(yàn)證內(nèi)容是否過期 | 驗(yàn)證 |
| proxy-revalidate | 主要用在緩存服務(wù)器，指定緩存服務(wù)器在過期后重新從原服務(wù)器獲取硝皂， 不能從本地獲取 | 驗(yàn)證 |
| min-fresh | 指示客戶機(jī)可以接收響應(yīng)時(shí)間小于當(dāng)前時(shí)間加上指定時(shí)間的響應(yīng)常挚。 | |
| no-store | 用于防止重要的信息被無意的發(fā)布。在請(qǐng)求消息中發(fā)送將 使得請(qǐng)求和響應(yīng)消息都不使用緩存稽物，完全不存下來奄毡。 | |
| no-transform | 主要用于proxy服務(wù)器，告訴代理服務(wù)器不要隨意改動(dòng)返回的內(nèi)容 |
Cache-control 案例
// cache-control.html
<html>
<head>
<meta charset="utf-8" />
<title>cache-control</title>
</head>
<body>
<script src="/script.js"></script>
cache
</body>
</html>
// cache-control.js
?
const http = require('http');
const fs = require('fs');
const port = 3010;
?
http.createServer((request, response) => {
console.log('request url: ', request.url);
?
if (request.url === '/') {
const html = fs.readFileSync('cache.html', 'utf-8');
response.writeHead(200, {
'Content-Type': 'text/html',
});
?
response.end(html);
} else if (request.url === '/script.js') {
response.writeHead(200, {
'Content-Type': 'text/javascript',
'Cache-Control': 'max-age=200',
// 'Cache-Control': 'no-cache',
});
?
response.end("console.log('script load !! -- 1')");
}
?
}).listen(port);
?
console.log(`Server started at http://localhost:${port}`)
控制臺(tái)運(yùn)營(yíng)結(jié)果: 第一次請(qǐng)求了script.js 贝或，而第二次沒有吼过。
指請(qǐng)求了/ 并沒有請(qǐng)求 /script.js
瀏覽器結(jié)果
以上結(jié)果瀏覽器并沒有返回給我們服務(wù)端修改的結(jié)果，這是為什么呢咪奖？是因?yàn)槲覀冋?qǐng)求的url /script.js沒有變那先，那么瀏覽器就不會(huì)經(jīng)過服務(wù)端的驗(yàn)證，會(huì)直接從客戶端緩存去讀赡艰，就會(huì)導(dǎo)致一個(gè)問題，我們的js靜態(tài)資源更新之后斤葱，不會(huì)立即更新到我們的客戶端慷垮，這也是前端開發(fā)中常見的一個(gè)問題，我們是希望瀏覽器去緩存我們的靜態(tài)資源文件（js揍堕、css料身、img等）我們也不希望服務(wù)端內(nèi)容更新了之后客戶端還是請(qǐng)求的緩存的資源， 解決辦法也就是我們?cè)谧鰆s構(gòu)建流程時(shí)衩茸，把打包完成的js文件名上根據(jù)它內(nèi)容hash值加上一串hash碼芹血，這樣你的js文件或者css文件等內(nèi)容不變，這樣生成的hash碼就不會(huì)變楞慈，反映到頁面上就是你的url沒有變幔烛，如果你的文件內(nèi)容有變化那么嵌入到頁面的文件url就會(huì)發(fā)生變化，這樣就可以達(dá)到一個(gè)更新緩存的目的囊蓝，這也是目前前端來說比較常見的一個(gè)靜態(tài)資源方案饿悬。
