摘要：前言前端開發(fā)中總是要和接口和緩存打交道，所以相關(guān)內(nèi)容多多少少還是要知道一些，干起活來(lái)才能事半功倍。處于中的應(yīng)用層。部分安全性問(wèn)題發(fā)布于年的版本，也是當(dāng)前的最新標(biāo)準(zhǔn)?；诠雀杼岢龅亩鴣?lái)，之前用于瀏覽器中來(lái)訪問(wèn)的加密服務(wù)，在發(fā)布后功成身退。

前端開發(fā)中總是要和接口和緩存打交道，所以HTTP相關(guān)內(nèi)容多多少少還是要知道一些，干起活來(lái)才能事半功倍。下面我從業(yè)務(wù)出發(fā)，簡(jiǎn)單說(shuō)下一些可能會(huì)碰到的知識(shí)點(diǎn)。
為了盡可能減少自己表述上的不嚴(yán)謹(jǐn)，文中會(huì)有不少外鏈，建議大家還是能點(diǎn)進(jìn)去看一下，也歡迎幫忙糾正。

老司機(jī)可以直接忽略本段內(nèi)容，我們先簡(jiǎn)單了解下 HTTP 的基本知識(shí)

HTTP是 Hypertext Transfer Protocol 超文本傳輸協(xié)議 的縮寫，和 HTML 一樣都是出自Hypertext家族的。處于OSI model中的應(yīng)用層。
目前為止，經(jīng)歷了幾個(gè)版本的迭代到了2， HTTP/3目前也是即將要標(biāo)準(zhǔn)化了
關(guān)于目前所有的HTTP相關(guān)協(xié)議的目錄可以直接看這里

The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems.[1] HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser. HTTP was developed to facilitate hypertext and the World Wide Web.
Development of HTTP was initiated by Tim Berners-Lee at CERN in 1989. Development of HTTP standards was coordinated by the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C), culminating in the publication of a series of Requests for Comments (RFCs). The first definition of HTTP/1.1, the version of HTTP in common use, occurred in RFC 2068 in 1997, although this was made obsolete by RFC 2616 in 1999 and then again by the RFC 7230 family of RFCs in 2014.
A later version, the successor HTTP/2, was standardized in 2015 (and HTTP/3 is its proposed successor (Internet Draft), that builds on HTTP/22), and is now supported by major web servers and browsers over Transport Layer Security (TLS) using Application-Layer Protocol Negotiation (ALPN) extension[4] where TLS 1.2 or newer is required.[5]

最早是由萬(wàn)維網(wǎng)的創(chuàng)始人Tim Berners-Lee 在1989年發(fā)起并于1990年完成了第一次服務(wù)器與客戶端之間的通訊。

發(fā)布于1991年的0.9版本，當(dāng)時(shí)只有一個(gè)GET命令，只能回應(yīng)HTML格式的字符串，結(jié)束以后就關(guān)閉TCP連接

發(fā)布于1996年的 1.0 版本，除了最早的 GET 以外還引入了POST 和 HEAD 命令，以及各類標(biāo)識(shí)緩存，請(qǐng)求狀態(tài)等headers，使任何文件都可以通過(guò)http請(qǐng)求進(jìn)行傳輸。

發(fā)布于1999年的 1.1 版本，也是目前使用基數(shù)最大的版本，
新增了幾個(gè)基礎(chǔ) Method

PUT

DELETE

TRACE

OPTIONS

CONNECT

彌補(bǔ)了之前HTTP/1.0的一些不足， 包括：

完善了之前緩存相關(guān)的設(shè)定，也便有了我們現(xiàn)在常說(shuō)的強(qiáng)緩存和協(xié)商緩存的概念

默認(rèn)采用持久連接，并能很好地配合代理服務(wù)器工作。支持以piplining的方式同時(shí)發(fā)送多個(gè)請(qǐng)求，從而降低了線路的負(fù)載也提升了HTTP請(qǐng)求的響應(yīng)速度。

部分安全性問(wèn)題

發(fā)布于2015年的 2.0 版本，也是當(dāng)前的最新標(biāo)準(zhǔn)。

基于谷歌提出的SPDY而來(lái)，之前用于Chrome瀏覽器中來(lái)訪問(wèn)Google的SSL加密服務(wù)，在HTTP/2發(fā)布后功成身退。

主要新增了以下內(nèi)容

多路復(fù)用

請(qǐng)求頭壓縮 HPACK: RFC-7541

幀、消息、流和TCP連接

服務(wù)器推送

因?yàn)閺?qiáng)制綁定了TLS，相關(guān)的證書又是一筆新的開支，加上各種歷史遺留問(wèn)題，目前大部分公司對(duì)HTTP/2的支持也是較為尷尬，就如同 ES6 一般，在落地好多年后依舊會(huì)被叫做新特性。
而解決的問(wèn)題如服務(wù)器推送之類的在之前是可以通過(guò)websocket甚至客戶端輪詢等操作解決，而頭部壓縮等也只是對(duì)現(xiàn)有方式進(jìn)行了少部分優(yōu)化，所以實(shí)際應(yīng)用也沒(méi)那么多，而出現(xiàn)的不確定性又增多了，而本身又?jǐn)埩艘恍㏕CP干的活，所以協(xié)議定下后爭(zhēng)議還是挺多的。

可能還需要時(shí)間把老服務(wù)器老電腦老項(xiàng)目老程序員給替換掉才行。

顧名思義，緩存就是瀏覽器存儲(chǔ)數(shù)據(jù)的地方，平時(shí)你可以通過(guò)特定的瀏覽器功能存儲(chǔ)一些數(shù)據(jù)，比如localStorage ,sessionStorage，但這些都是用戶通過(guò)腳本主動(dòng)向?yàn)g覽器添加的東西。
但是還有一些是我們希望加快用戶效率而存下的數(shù)據(jù)，但很多時(shí)候用戶總是特別喜歡用各類管家清理的東西，那就是HTTP的緩存了。

而緩存的作用是方便瀏覽器更快地讀取數(shù)據(jù)而不用反復(fù)和服務(wù)器確認(rèn)。前端對(duì)于緩存這件事，用得好，事半功倍，沒(méi)用對(duì)，可能會(huì)讓你踏入無(wú)底深淵。

那我們首先了解下幾個(gè)常見的緩存相關(guān)的請(qǐng)求頭和響應(yīng)頭：

Expires: 緩存的過(guò)期時(shí)間

Age: 文件的壽命

Cache-Control / Pragma : 在HTTP/1 的年代用Pragma，因?yàn)槟莻€(gè)時(shí)候還沒(méi)Cache-Control, 如果你在請(qǐng)求中看到這個(gè)頭,那多半是為了做兼容

s-max-age

max-age

private

public

no-cache

no-store

must-revalidate

Warning 主要是以幾個(gè)可能會(huì)出現(xiàn)的異常信息的返回碼,參考[iana]

ETag 與 If-None-Match

Last-Modified 與If-Modified-Since (HTTP:1.0 ):

不知道是不是我沒(méi)翻對(duì)地方，還是這本來(lái)就是國(guó)內(nèi)大家都在來(lái)回翻二手資料翻出來(lái)的烏龍，翻了一整個(gè)RFC-7234也沒(méi)翻到和這倆詞匯表達(dá)相關(guān)的內(nèi)容，如果有相關(guān)文獻(xiàn)麻煩告知一二。
不過(guò)在我自己的理解上
網(wǎng)上所說(shuō)的協(xié)商緩存大致就是該不該返回304，避免再拉一遍文件。
而強(qiáng)緩存就是是不是返回200(from disk)的概念
而通過(guò)Cache-Control來(lái)區(qū)別不緩存所有接口只返回200呢還是只做了基本時(shí)間校驗(yàn)的緩存 200(from disk) ,200(from memory)還是需要通過(guò)請(qǐng)求頭以及返回頭來(lái)確認(rèn)文件是否更改的 304(Not Modified)

這幾年前端體系越來(lái)越健全，spa也開始大行其道，一名初出茅廬的前端新人也能基于開源項(xiàng)目快速構(gòu)建出一個(gè)單頁(yè)應(yīng)用。
那么你是否碰到過(guò)新版本項(xiàng)目打包了上線了，結(jié)果一進(jìn)去卻是緩存，還需要刷新一下才行，有時(shí)候刷新可能都不一定有用？
而更新本來(lái)就是悄咪咪進(jìn)行的，用戶如果打不開頁(yè)面就換個(gè)服務(wù)了，根本不會(huì)給你第二次機(jī)會(huì)。
所以我們肯定要把這個(gè)文件的緩存去掉，但除了html文件不緩存以外，其他的js、css文件我又要做緩存而且越久越好，但業(yè)務(wù)要更新的時(shí)候我可能又要把老的文件的緩存去掉，那該怎么辦？

先簡(jiǎn)單說(shuō)下CDN是個(gè)什么東西，我們的代碼就像一個(gè)放在服務(wù)器的包裹，而用戶從我們的服務(wù)器中取包裹就像網(wǎng)購(gòu)一般，要先判斷能不能拿到，比如

地方太遠(yuǎn)，運(yùn)費(fèi)太貴[網(wǎng)絡(luò)超時(shí)]

比如地址填錯(cuò)快遞無(wú)法送達(dá)[404]

打包的下班了，服務(wù)器重啟服務(wù)[500]

快遞太多服務(wù)器吃不消

而普通的用服務(wù)器發(fā)版就是很早以前淘寶小商戶的模式，你要準(zhǔn)備倉(cāng)庫(kù)又準(zhǔn)備很多錢提前租倉(cāng)庫(kù)囤貨找員工，但是你又不知道會(huì)有多少客戶來(lái)買東西，萬(wàn)一客戶少了就賠本，萬(wàn)一客戶多了又忙不過(guò)來(lái)爆倉(cāng)或者貨準(zhǔn)備太少不夠發(fā)，而且很多海外的客戶快遞也沒(méi)辦法發(fā)。
而CDN就像一個(gè)分布于全國(guó)的物流倉(cāng)儲(chǔ)點(diǎn)，你把代碼告訴一臺(tái)主服務(wù)器，然后這個(gè)服務(wù)器就會(huì)把這份數(shù)據(jù)復(fù)制很多份發(fā)到分部于全國(guó)各地的代理數(shù)據(jù)倉(cāng)庫(kù)。
然后對(duì)應(yīng)地區(qū)的客戶去找對(duì)應(yīng)的代理服務(wù)器拿貨，這樣速度也快，存貨也足，價(jià)格也便宜。
但是隨之而來(lái)的問(wèn)題就是發(fā)出去的貨容易，收回來(lái)難，嗯，我把代碼發(fā)出去就沒(méi)準(zhǔn)備收回來(lái)。
所以發(fā)出去的代碼我們需要在后面加上對(duì)應(yīng)的hash指紋
這就是為什么很多webpack配置腳手架打包的文件都帶個(gè)hash
至于找到它們的事情就交給index.html吧

生成的html文件我們有了幾個(gè)新去處，可以發(fā)到公司服務(wù)器里的nginx再加上一行不緩存的header

location ~ .*.(htm|html )$ {
    add_header Cache-Control no-store;
}

然后可以通過(guò)替換html文件做一個(gè)簡(jiǎn)單的脫離后端服務(wù)的無(wú)感知更新
甚至可以配合后端實(shí)現(xiàn)藍(lán)綠部署

【待續(xù)】