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

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

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

HTTP是 Hypertext Transfer Protocol 超文本傳輸協(xié)議 的縮寫，和 HTML 一樣都是出自Hypertext家族的。處于OSI model中的應(yīng)用層。
目前為止，經(jīng)歷了幾個版本的迭代到了2， HTTP/3目前也是即將要標準化了
關(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ǎng)的創(chuàng)始人Tim Berners-Lee 在1989年發(fā)起并于1990年完成了第一次服務(wù)器與客戶端之間的通訊。

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

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

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

PUT

DELETE

TRACE

OPTIONS

CONNECT

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

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

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

部分安全性問題

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

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

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

多路復(fù)用

請求頭壓縮 HPACK: RFC-7541

幀、消息、流和TCP連接

服務(wù)器推送

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

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

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

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

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

Expires: 緩存的過期時間

Age: 文件的壽命

Cache-Control / Pragma : 在HTTP/1 的年代用Pragma，因為那個時候還沒Cache-Control, 如果你在請求中看到這個頭,那多半是為了做兼容

s-max-age

max-age

private

public

no-cache

no-store

must-revalidate

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

ETag 與 If-None-Match

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

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

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

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

地方太遠，運費太貴[網(wǎng)絡(luò)超時]

比如地址填錯快遞無法送達[404]

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

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

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

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

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

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

【待續(xù)】