整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
tml文件即超文本標記語言文件文檔，是擴展名、后綴名為html的文件。超文本標記語言的結構包括頭部分（Head）、和主體部分（Body），其中頭部（head）提供關于網頁的信息，主體（body）部分提供網頁的具體內容。html文件能夠被多種網頁瀏覽器讀取，傳遞。我們可以使用電腦上自帶的記事本進行編輯htm文件。那么html文件刪除如何恢復？
通常情況下當您從電腦存儲設備中刪除html文件時，該html文件會保存在回收站中。 可以根據需要通過單擊還原選項將其還原。 但是不好運的情況下，如果您清空回收站或文件未經過回收站、或使用永久刪除鍵Shift + Delete將文件刪除怎么恢復呢？我們可以通過使用數據恢復軟件來恢復。
html文件刪除恢復步驟如下:
1、首先到官網下載并安裝好云騎士數據恢復軟件（注意：軟件不能安裝在丟失盤中），打開云騎士數據恢復軟件，根據需要選擇恢復功能，這里選擇場景模式下的誤刪除文件。
2、選擇好以后選擇需要恢復數據的分區，如果是外接設備則可以將它插入電腦中，或者通過讀卡器插入電腦，點擊開始掃描。
3、掃描結束以后，你會發現有很多數據，這時我們可以通過文件類型進行查找，這里勾選其他文件類型，然后找到了需要的html格式文件。
因為文件丟失后有可能會因各種原因受損，所以遵循先預覽再恢復原則，通過預覽模式判斷文件是否正常再進行恢復。對于無法預覽或者不支持預覽的是無法判斷數據是好的還是壞的，只能恢復出來才能進行查看的。
4、接著在需要恢復的html文件前面進行勾選，選擇好以后點擊立即恢復按鈕。
5、彈出設置文件路徑窗口，將文件存儲在安全區域中（如果存儲盤不夠內存，可以外接其他設備進行存儲），點擊確定按鈕。
6、耐心等待文件導出完成，點擊查看即可查看恢復出來的html文件了。
知識普及：
導致html文件丟失常見幾種原因：
采用來源于Internet的各種各樣沒經驗證的第三方應用程序也許會使您的html文件遭遇風險。
偶爾在下載那些應用程序時，某些惡意病毒也許會進入系統并破壞html文件結構，亦或它們也許會刪除桌面上的所有html文件，因此致使大量數據丟失。
在重新分區或調整硬盤大小時，那些html文件也許會遺失。在重新分區時，一個重大的錯誤也會刪除存儲了所必需文件的分區，例如DOC、PPT、XLSX和HTML。
總結：以上就是html文件刪除恢復教程了，如果在軟件使用過程中有不懂的問題，可以咨詢專業的在線客服人員為您解答~
本文來自 yqssjhf.com>> 創作不易，轉載請注明出處。
今年國慶假期終于可以憋在家里了不用出門了，不用出去看后腦了，真的是一種享受。這么好的光陰怎么浪費，睡覺、吃飯、打豆豆這怎么可能（耍多了也煩），完全不符合我們程序員的作風，趕緊起來把文章寫完。
這篇文章比較基礎，在國慶期間的業余時間寫的，這幾天又完善了下，力求把更多的前端所涉及到的關于文件上傳的各種場景和應用都涵蓋了,若有疏漏和問題還請留言斧正和補充。
以下是本文所涉及到的知識點，break or continue ?
原理很簡單，就是根據 http 協議的規范和定義，完成請求消息體的封裝和消息體的解析，然后將二進制內容保存到文件。
我們都知道如果要上傳一個文件，需要把 form 標簽的enctype設置為multipart/form-data,同時method必須為post方法。
那么multipart/form-data表示什么呢？
multipart互聯網上的混合資源，就是資源由多種元素組成，form-data表示可以使用HTML Forms 和 POST 方法上傳文件，具體的定義可以參考RFC 7578。
multipart/form-data 結構
看下 http 請求的消息體
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryDCntfiXcSkPhS4PN 表示本次請求要上傳文件，其中boundary表示分隔符，如果要上傳多個表單項，就要使用boundary分割，每個表單項由———XXX開始，以———XXX結尾。
每一個表單項又由Content-Type和Content-Disposition組成。
Content-Disposition: form-data 為固定值，表示一個表單元素，name 表示表單元素的 名稱，回車換行后面就是name的值，如果是上傳文件就是文件的二進制內容。
Content-Type：表示當前的內容的 MIME 類型，是圖片還是文本還是二進制數據。
解析
客戶端發送請求到服務器后，服務器會收到請求的消息體，然后對消息體進行解析，解析出哪是普通表單哪些是附件。
可能大家馬上能想到通過正則或者字符串處理分割出內容，不過這樣是行不通的，二進制buffer轉化為string,對字符串進行截取后，其索引和字符串是不一致的，所以結果就不會正確，除非上傳的就是字符串。
不過一般情況下不需要自行解析，目前已經有很成熟的三方庫可以使用。
至于如何解析，這個也會占用很大篇幅，后面的文章在詳細說。
使用 form 表單上傳文件
在 ie時代，如果實現一個無刷新的文件上傳那可是費老勁了，大部分都是用 iframe 來實現局部刷新或者使用 flash 插件來搞定，在那個時代 ie 就是最好用的瀏覽器（別無選擇）。
DEMO
這種方式上傳文件，不需要 js ，而且沒有兼容問題，所有瀏覽器都支持，就是體驗很差，導致頁面刷新，頁面其他數據丟失。
HTML
<form method="post" action="http://localhost:8100" enctype="multipart/form-data">
選擇文件:
<input type="file" name="f1"/> input 必須設置 name 屬性，否則數據無法發送<br/>
<br/>
標題：<input type="text" name="title"/><br/><br/><br/>
<button type="submit" id="btn-0">上 傳</button>
</form>
復制代碼服務端文件的保存基于現有的庫koa-body結合 koa2實現服務端文件的保存和數據的返回。
在項目開發中，文件上傳本身和業務無關，代碼基本上都可通用。
在這里我們使用koa-body庫來實現解析和文件的保存。
koa-body 會自動保存文件到系統臨時目錄下，也可以指定保存的文件路徑。
然后在后續中間件內得到已保存的文件的信息，再做二次處理。
NODE
/**
* 服務入口
*/
var http = require('http');
var koaStatic = require('koa-static');
var path = require('path');
var koaBody = require('koa-body');//文件保存庫
var fs = require('fs');
var Koa = require('koa2');
var app = new Koa();
var port = process.env.PORT || '8100';
var uploadHost= `http://localhost:${port}/uploads/`;
app.use(koaBody({
formidable: {
//設置文件的默認保存目錄，不設置則保存在系統臨時目錄下 os
uploadDir: path.resolve(__dirname, '../static/uploads')
},
multipart: true // 開啟文件上傳，默認是關閉
}));
//開啟靜態文件訪問
app.use(koaStatic(
path.resolve(__dirname, '../static')
));
//文件二次處理，修改名稱
app.use((ctx) => {
var file = ctx.request.files.f1;//得道文件對象
var path = file.path;
var fname = file.name;//原文件名稱
var nextPath = path+fname;
if(file.size>0 && path){
//得到擴展名
var extArr = fname.split('.');
var ext = extArr[extArr.length-1];
var nextPath = path+'.'+ext;
//重命名文件
fs.renameSync(path, nextPath);
}
//以 json 形式輸出上傳文件地址
ctx.body = `{
"fileUrl":"${uploadHost}${nextPath.slice(nextPath.lastIndexOf('/')+1)}"
}`;
});
/**
* http server
*/
var server = http.createServer(app.callback());
server.listen(port);
console.log('demo1 server start ...... ');
復制代碼CODE
https://github.com/Bigerfe/fe-learn-code/
HTTP車是由蒂姆·伯納斯-李（ TimBerners—Lee ）于1989年在歐洲核子研究組織（ CERN ）所發起
其中最著名的是 1999 年 6 月公布的 RFC 2616 ，定義了 HTTP 協議中現今廣泛使用的一個版本—— HTTP 1.1
全稱：超文本傳輸協議（ HyperText Transfer Protocol ）
概念： HTTP 是一種能夠獲取像 HTML 、圖片等網絡資源的通訊協議（ protocol ）。它是在 web 上進行數據交換的基礎，是一種 client-server 協議
HTTP ——因特網的多媒體信使 ——《HTTP權威指南》。 HTTP 在因特網的角色：充當一個信使的角色，干的就是一個跑腿的活，在客戶端和服務端之間傳遞信息，但我們又不能缺少它。 HTTP 協議是應用層的協議，是與前端開發最息息相關的協議。平時我們遇到的 HTTP 請求、 HTTP 緩存、 Cookies 、跨域等其實都跟 HTTP 息息相關
也就是說， HTTP 依賴于面向連接的 TCP 進行消息傳遞，但連接并不是必須的。只需要它是可靠的，或不丟失消息的（至少返回錯誤）。
HTTP/1.0 默認為每一對 HTTP 請求/響應都打開一個單獨的 TCP 連接。當需要連續發起多個請求時，這種模式比多個請求共享同一個 TCP 鏈接更低效。為此， HTTP 1.1 持久連接的概念，底層 TCP 連接可以通過 connection 頭部實現。但 HTTP 1.1 在連接上也是不完美的，后面我們會提到。
HTTP 的組件系統包括客戶端、 web 服務器和代理
瀏覽器，特殊比如是工程師使用的程序，以及 Web 開發人員調試應用程序
由 Web Server 來服務并提供客戶端所請求的文檔。每一個發送到服務器的請求，都會被服務器處理并返回一個消息，也就是 response
在瀏覽器和服務器之間，有很多計算機和其他設備轉發了 HTTP 消息。它們可能出現在傳輸層、網絡層和物理層上，對于 HTTP 應用層而言就是透明的
有如下的一些作用
HTTP 有兩種類型的消息：
HTTP 消息由采用 ASCII 編碼的多行文本構成的。在 HTTP/1.1 以及更早的版本中，這些消息通過連接公開的發送。在 HTTP2.0 中，消息被分到了多個 HTTP 幀中。通過配置文件（用于代理服務器或者服務器）， API （用于瀏覽器）或者其他接口提供 HTTP 消息
HTTP 請求和響應都包括起始行（ start line ）、請求頭（ HTTP Headers ）、空行（ empty line ）以及 body 部分，如下圖所示：
下面詳細說下請求 Path ，請求路徑（ Path ）有以下幾種：
1）一個絕對路徑，末尾跟上一個 ' ? ' 和查詢字符串。這是最常見的形式，稱為 原始形式 ( origin form )，被 GET ， POST ， HEAD 和 OPTIONS 方法所使用
POST / HTTP/1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0
復制代碼2）一個完整的 URL 。主要在使用 GET 方法連接到代理的時候使用
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
復制代碼3）由域名和可選端口（以':'為前綴）組成的 URL 的 authority component ，稱為 authority form 。僅在使用 CONNECT 建立 HTTP 隧道時才使用
CONNECT developer.mozilla.org:80 HTTP/1.1
復制代碼4）星號形式 ( asterisk form )，一個簡單的星號('*')，配合 OPTIONS 方法使用，代表整個服務器。
OPTIONS * HTTP/1.1
復制代碼請求 Body 部分： 有些請求將數據發送到服務器以便更新數據：常見的的情況是 POST 請求（包含 HTML 表單數據）。請求報文的 Body 一般為兩類。一類是通過 Content-Type 和 Content-Length 定義的單文件 body 。另外一類是由多 Body 組成，通常是和 HTML Form 聯系在一起的。兩者的不同表現在于 Content-Type 的值。
1） Content-Type —— application/x-www-form-urlencoded 對于 application/x-www-form-urlencoded 格式的表單內容，有以下特點:
I.其中的數據會被編碼成以&分隔的鍵值對
II.字符以URL編碼方式編碼。
// 轉換過程: {a: 1, b: 2} -> a=1&b=2 -> 如下(最終形式)
"a%3D1%26b%3D2"
復制代碼2) Content-Type —— multipart/form-data
請求頭中的 Content-Type 字段會包含 boundary ，且 boundary 的值有瀏覽器默認指定。例: Content-Type: multipart/form-data;boundary=----WebkitFormBoundaryRRJKeWfHPGrS4LKe 。
數據會分為多個部分，每兩個部分之間通過分隔符來分隔，每部分表述均有 HTTP 頭部描述子包體，如 Content-Type ，在最后的分隔符會加上--表示結束。
Content-Disposition: form-data;name="data1";
Content-Type: text/plain
data1
----WebkitFormBoundaryRRJKeWfHPGrS4LKe
Content-Disposition: form-data;name="data2";
Content-Type: text/plain
data2
----WebkitFormBoundaryRRJKeWfHPGrS4LKe--
復制代碼響應 Body 部分：
1）由已知長度的單個文件組成。該類型 body 有兩個 header 定義： Content-Type 和 Content-Length
2）由未知長度的單個文件組成，通過將 Transfer-Encoding 設置為 chunked 來使用 chunks 編碼。
關于 Content-Length 在下面 HTTP 1.0 中會提到，這個是 HTTP 1.0 中新增的非常重要的頭部。
安全方法： HTTP 定義了一組被稱為安全方法的方法。 GET 方法和 HEAD 方法都被認為是安全的，這意味著 GET 方法和 HEAD 方法都不會產生什么動作 —— HTTP 請求不會再服務端產生什么結果，但這并不意味著什么動作都沒發生，其實這更多的是 web 開發者決定的
首先要了解下副作用和冪等的概念，副作用指的是對服務器端資源做修改。冪等指發送 M 和 N 次請求（兩者不相同且都大于 1），服務器上資源的狀態一致。應用場景上，get是無副作用的，冪等的。post 主要是有副作用的，不冪等的情況
技術上有以下的區分：
HTTP Headers
1.通用首部（ General headers ）同時適用于請求和響應消息，但與最終消息主體中傳輸的數據無關的消息頭。如 Date
2.請求首部（ Request headers ）包含更多有關要獲取的資源或客戶端本身信息的消息頭。如 User-Agent
3.響應首部（ Response headers ）包含有關響應的補充信息
4.實體首部（ Entity headers ）含有關實體主體的更多信息，比如主體長( Content-Length )度或其 MIME 類型。如 Accept-Ranges
詳細的 Header 見 HTTP Headers 集合
HTTP（HyperText Transfer Protocol） 是萬維網（ World Wide Web ）的基礎協議。 Tim Berners-Lee 博士和他的團隊在 1989-1991 年間創造出它。【HTTP、網絡瀏覽器、服務器】
在 1991 年發布了 HTTP 0.9 版，在 1996 年發布 1.0 版，1997 年是 1.1 版，1.1 版也是到今天為止傳輸最廣泛的版本。2015 年發布了 2.0 版，其極大的優化了 HTTP/1.1 的性能和安全性，而 2018 年發布的 3.0 版，繼續優化 HTTP/2 ，激進地使用 UDP 取代 TCP 協議，目前， HTTP/3 在 2019 年 9 月 26 日 被 Chrome ， Firefox ，和 Cloudflare 支持
單行協議，請求由單行指令構成。以唯一可用的方法 GET 開頭。后面跟的是目標資源的路徑
GET /mypage.html
復制代碼響應：只包括響應文檔本身
<HTML>
這是一個非常簡單的HTML頁面
</HTML>
復制代碼HTML
RFC 1945 提出了 HTTP1.0 ， 構建更好可拓展性
媒體類型是一種標準。用來表示文檔、文件或者字節流的性質和格式。瀏覽器通常使用 MIME （ Multipurpose Internet Mail Extensions ）類型來確定如何處理 URL ，因此 Web 服務器在響應頭中配置正確的 MIME 類型會非常的重要。如果配置不正確，可能會導致網站無法正常的工作。 MIME 的組成結構非常簡單；由類型與子類型兩個字符串中間用'/'分隔而組成。
HTTP 從 MIME type 取了一部分來標記報文 body 部分的數據類型，這些類型體現在 Content-Type 這個字段，當然這是針對于發送端而言，接收端想要收到特定類型的數據，也可以用 Accept 字段。
這兩個字段的取值可以分為下面幾類:
- text： text/html, text/plain, text/css 等
- image: image/gif, image/jpeg, image/png 等
- audio/video: audio/mpeg, video/mp4 等
- application: application/json, application/javascript, application/pdf, application/octet-stream
復制代碼同時為了約定請求的數據和響應數據的壓縮方式、支持語言、字符集等，還提出了以下的 Header
1.壓縮方式:發送端： Content-Encoding （服務端告知客戶端，服務器對實體的主體部分的編碼方式） 和 接收端： Accept-Encoding （用戶代理支持的編碼方式），值有 gzip: 當今最流行的壓縮格式；deflate: 另外一種著名的壓縮格式；br: 一種專門為 HTTP 發明的壓縮算法
2.支持語言： Content-Language 和 Accept-Language （用戶代理支持的自然語言集）
3.字符集：發送端： Content-Type 中，以 charset 屬性指定。接收端： Accept-Charset （用戶代理支持的字符集）。
// 發送端
Content-Encoding: gzip
Content-Language: zh-CN, zh, en
Content-Type: text/html; charset=utf-8
// 接收端
Accept-Encoding: gzip
Accept-Language: zh-CN, zh, en
Accept-Charset: charset=utf-8
復制代碼雖然 HTTP1.0 在 HTTP 0.9 的基礎上改進了很多，但還是存在這不少的缺點
HTTP/1.0 版的主要缺點是，每個 TCP 連接只能發送一個請求。發送數據完畢，連接就關閉，如果還要請求其他資源，就必須再新建一個連接。 TCP 連接的新建成本很高，因為需要客戶端和服務器三次握手，并且開始時發送速率較慢（ slow start ）。
HTTP 最早期的模型，也是 HTTP/1.0 的默認模型，是短連接。每一個 HTTP 請求都由它自己獨立的連接完成；這意味著發起每一個 HTTP 請求之前都會有一次 TCP 握手，而且是連續不斷的。
HTTP/1.1 在1997年1月以 RFC 2068 文件發布。
HTTP 1.1 消除了大量歧義內容并引入了多項技術
虛擬主機（ virtual hosting ）即共享主機（ shared web hosting ），可以利用虛擬技術把一臺完整的服務器分成若干個主機，因此可以在單一主機上運行多個網站或服務。
舉個例子，有一臺 ip 地址為 61.135.169.125 的服務器，在這臺服務器上部署著谷歌、百度、淘寶的網站。為什么我們訪問 https://www.google.com 時，看到的是 Google 的首頁而不是百度或者淘寶的首頁？原因就是 Host 請求頭決定著訪問哪個虛擬主機。
2015年， HTTP2.0 面世。 rfc7540
HTTP 2.0 中的幀將 HTTP/1.x 消息分成幀并嵌入到流 ( stream ) 中。數據幀和報頭幀分離，這將允許報頭壓縮。將多個流組合，這是一個被稱為多路復用 ( multiplexing ) 的過程，它允許更有效的底層 TCP 連接。
也就是說，流用來承載消息，消息又是有一個或多個幀組成。二進制傳輸的方式更加提升了傳輸性能。 每個數據流都以消息的形式發送，而消息又由一個或多個幀組成。 幀是流中的數據單位。
HTTP 幀現在對 Web 開發人員是透明的。在 HTTP/2 中，這是一個在 HTTP/1.1 和底層傳輸協議之間附加的步驟。 Web 開發人員不需要在其使用的 API 中做任何更改來利用 HTTP 幀；當瀏覽器和服務器都可用時， HTTP/2 將被打開并使用。
之前我們提到，雖然 HTTP 1.1 有了長連接和管道化的技術，但是還是會存在 隊頭阻塞。而 HTTP 2.0 就解決了這個問題 HTTP/2 中新的二進制分幀層突破了這些限制，實現了完整的請求和響應復用：客戶端和服務器可以將 HTTP 消息分解為互不依賴的幀，然后交錯發送，最后再在另一端把它們重新組裝起來。
如上圖所示，快照捕捉了同一個連接內并行的多個數據流。 客戶端正在向服務器傳輸一個 DATA 幀（數據流 5），與此同時，服務器正向客戶端交錯發送數據流 1 和數據流 3 的一系列幀。因此，一個連接上同時有三個并行數據流。
將 HTTP 消息分解為獨立的幀，交錯發送，然后在另一端重新組裝是 HTTP 2 最重要的一項增強。事實上，這個機制會在整個網絡技術棧中引發一系列連鎖反應，從而帶來巨大的性能提升，讓我們可以： 1.并行交錯地發送多個請求，請求之間互不影響。 2.并行交錯地發送多個響應，響應之間互不干擾。 3.使用一個連接并行發送多個請求和響應。 4.消除不必要的延遲和提高現有網絡容量的利用率，從而減少頁面加載時間。 5.不必再為繞過 HTTP/1.x 限制而做很多工作(比如精靈圖) ...
連接共享，即每一個 request 都是是用作連接共享機制的。一個 request 對應一個 id ，這樣一個連接上可以有多個 request ，每個連接的 request 可以隨機的混雜在一起，接收方可以根據 request 的 id 將 request 再歸屬到各自不同的服務端請求里面。
HTTP 1.1 和 HTTP 2.0 的對比，可以參考這個 網站 demo 演示
HTTP 1.1 演示如下：
HTTP2.0 演示如下：
使用 HTTP/1.1 和 HTTP/2 對于站點和應用來說是透明的。擁有一個最新的服務器和新點的瀏覽器進行交互就足夠了。只有一小部分群體需要做出改變，而且隨著陳舊的瀏覽器和服務器的更新，而不需 Web 開發者做什么，用的人自然就增加了
HTTPS 也是通過 HTTP 協議進行傳輸信息，但是采用了 TLS 協議進行了加密
對稱加密就是兩邊擁有相同的秘鑰，兩邊都知道如何將密文加密解密。但是因為傳輸數據都是走的網絡，如果將秘鑰通過網絡的方式傳遞的話，一旦秘鑰被截獲就沒有加密的意義的
非對稱加密
公鑰大家都知道，可以用公鑰加密數據。但解密數據必須使用私鑰，私鑰掌握在頒發公鑰的一方。首先服務端將公鑰發布出去，那么客戶端是知道公鑰的。然后客戶端創建一個秘鑰，并使用公鑰加密，發送給服務端。服務端接收到密文以后通過私鑰解密出正確的秘鑰
TLS 握手的過程采用的是非對稱加密
強緩存主要是由 Cache-control 和 Expires 兩個 Header 決定的
Expires 的值和頭里面的 Date 屬性的值來判斷是否緩存還有效。 Expires 是 Web 服務器響應消息頭字段，在響應 http 請求時告訴瀏覽器在過期時間前瀏覽器可以直接從瀏覽器緩存取數據，而無需再次請求。 Expires 的一個缺點就是，返回的到期時間是服務器端的時間，這是一個絕對的時間，這樣存在一個問題，如果客戶端的時間與服務器的時間相差很大（比如時鐘不同步，或者跨時區），那么誤差就很大。
Cache-Control 指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據還是重新發請求到服務器取數據。但是其設置的是一個相對時間。
指定過期時間： max-age 是距離請求發起的時間的秒數，比如下面指的是距離發起請求 31536000S 內都可以命中強緩存
Cache-Control: max-age=31536000
復制代碼表示沒有緩存
Cache-Control: no-store
復制代碼有緩存但要重新驗證
Cache-Control: no-cache
復制代碼私有和公共緩存
public 表示響應可以被任何中間人（比如中間代理、 CDN 等緩存） 而 private 則表示該響應是專用于某單個用戶的，中間人不能緩存此響應，該響應只能應用于瀏覽器私有緩存中。
Cache-Control: private
Cache-Control: public
復制代碼驗證方式：以下表示一旦資源過期（比如已經超過 max-age ），在成功向原始服務器驗證之前，緩存不能用該資源響應后續請求
Cache-Control: must-revalidate
復制代碼Cache-control 優先級比 Expires 優先級高
以下是一個 Cache-Control 強緩存的過程：
Last-Modified 表示本地文件最后修改日期，瀏覽器會在 request header 加上 If-Modified-Since （上次返回的 Last-Modified 的值），詢問服務器在該日期后資源是否有更新，有更新的話就會將新的資源發送回來
但是如果在本地打開緩存文件，就會造成 Last-Modified 被修改，所以在 HTTP / 1.1 出現了 ETag
Etag 就像一個指紋，資源變化都會導致 ETag 變化，跟最后修改時間沒有關系， ETag 可以保證每一個資源是唯一的。 If-None-Match 的 header 會將上次返回的 Etag 發送給服務器，詢問該資源的 Etag 是否有更新，有變動就會發送新的資源回來
If-none-match 、 ETags 優先級高于 If-Modified-Since、Last-Modified
第一次請求：
第二次請求相同網頁：
協商緩存，假如沒有改動的話，返回 304 ，改動了返回 200 資源
現在的200 (from cache) 已經變成了 disk cache (磁盤緩存)和 memory cache (內存緩存)兩種
上面提到 HTTP 緩存相關，但是很多有時候，我們希望上線之后需要更新線上資源。
web 開發者發明了一種被 Steve Souders 稱之為 revving 的技術。不頻繁更新的文件會使用特定的命名方式：在 URL 后面（通常是文件名后面）會加上版本號。
弊端：更新了版本號，所有引用這些的資源的地方的版本號都要改變
web 開發者們通常會采用自動化構建工具在實際工作中完成這些瑣碎的工作。當低頻更新的資源（ js/css ）變動了，只用在高頻變動的資源文件（ html ）里做入口的改動。
HTTP Cookie （也叫 Web Cookie 或瀏覽器 Cookie ）是服務器發送到用戶瀏覽器并保存在本地的一小塊數據，它會在瀏覽器下次向同一服務器再發起請求時被攜帶并發送到服務器上。
Set-Cookie 響應頭部和 Cookie 請求頭部
Set-Cookie: <cookie名>=<cookie值>
復制代碼會話期Cookie是最簡單的 Cookie ：瀏覽器關閉之后它會被自動刪除，也就是說它僅在會話期內有效。會話期 Cookie 不需要指定過期時間（ Expires ）或者有效期（ Max-Age ）。需要注意的是，有些瀏覽器提供了會話恢復功能，這種情況下即使關閉了瀏覽器，會話期 Cookie 也會被保留下來，就好像瀏覽器從來沒有關閉一樣
和關閉瀏覽器便失效的會話期 Cookie 不同，持久性 Cookie 可以指定一個特定的過期時間（ Expires ）或有效期（ Max-Age ）。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
復制代碼標記為 Secure 的 Cookie 只應通過被 HTTPS 協議加密過的請求發送給服務端。
標記為 Secure 的 Cookie 只應通過被 HTTPS 協議加密過的請求發送給服務端。但即便設置了 Secure 標記，敏感信息也不應該通過 Cookie 傳輸，因為 Cookie 有其固有的不安全性， Secure 標記也無法提供確實的安全保障
通過 JavaScript 的 Document.cookie API 是無法訪問帶有 HttpOnly 標記的 cookie 。這么做是為了避免跨域腳本攻擊（ XSS ）
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
復制代碼Domain 和 Path 標識定義了 Cookie 的作用域：即 Cookie 應該發送給哪些 URL 。
Domain 標識指定了哪些主機可以接受 Cookie 。如果不指定，默認為當前的主機（不包含子域名）。如果指定了 Domain ，則一般包含子域名。
例如，如果設置 Domain=mozilla.org ，則 Cookie 也包含在子域名中（如 developer.mozilla.org ）。
Path 標識指定了主機下的哪些路徑可以接受 Cookie （該 URL 路徑必須存在于請求 URL 中）。以字符 %x2F ("/") 作為路徑分隔符，子路徑也會被匹配。
例如，設置 Path=/docs ，則以下地址都會匹配：
/docs
/docs/Web/
/docs/Web/HTTP
復制代碼SameSite Cookie 允許服務器要求某個 cookie 在跨站請求時不會被發送，從而可以阻止跨站請求偽造攻擊
Set-Cookie: key=value; SameSite=Strict
復制代碼None Strict Lax
在新版本的瀏覽器（ Chrome 80 之后）中， SameSite 的默認屬性是 SameSite=Lax 。換句話說，當 Cookie 沒有設置 SameSite 屬性時，將會視作 SameSite 屬性被設置為 Lax —— 這意味著 Cookies 將不會在當前用戶使用時被自動發送。如果想要指定 Cookies 在同站、跨站請求都被發送，那么需要明確指定 SameSite 為 None 。因為這一點，我們需要好好排查舊系統是否明確指定 SameSite ，以及推薦新系統明確指定 SameSite ，以兼容新舊版本 Chrome
更多 cookie 相關，可以查看我之前總結的一篇關于 cookie 的文章 前端須知的 Cookie 知識小結
跨域資源共享（ CORS ）是一種機制，它使用額外的 HTTP 頭告訴瀏覽器，讓運行在一個 origin ( domain ) 上的 web 應用被準許訪問來自不同源服務器上的指定的資源
跨域資源共享標準新增了一組 HTTP 首部字段，允許服務器聲明哪些源站通過瀏覽器有權限訪問哪些資源。
簡單請求（不會觸發 CORS 的預檢請求）需要同時滿足以下三點：
以下為一個簡單請求的請求報文以及響應報文
簡化以下：
請求首部字段 Origin 表明該請求來源于 http://foo.example
本例中，服務端返回的 Access-Control-Allow-Origin: * 表明，該資源可以被任意外域訪問。如果服務端僅允許來自 http://foo.example 的訪問，該首部字段的內容如下：
Access-Control-Allow-Origin: http://foo.example
復制代碼Access-Control-Allow-Origin 應當為 * 或者包含由 Origin 首部字段所指明的域名。
規范要求，對那些可能對服務器數據產生副作用的 HTTP 請求方法。瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求（ preflight request ），從而獲知服務端是否允許該跨域請求。
服務器確認允許之后，才發起實際的 HTTP 請求。在預檢請求的返回中，服務器端也可以通知客戶端，是否需要攜帶身份憑證（包括 Cookies 和 HTTP 認證相關數據）
預檢請求中同時攜帶了下面兩個首部字段：
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
復制代碼首部字段 Access-Control-Request-Method 告知服務器，實際請求將使用 POST 方法。首部字段 Access-Control-Request-Headers 告知服務器，實際請求將攜帶兩個自定義請求首部字段： X-PINGOTHER 與 Content-Type 。服務器據此決定，該實際請求是否被允許。
預檢請求的響應中，包括了以下幾個字段
Access-Control-Allow-Origin: http://foo.example
// 表明服務器允許客戶端使用 POST, GET 和 OPTIONS 方法發起請求
Access-Control-Allow-Methods: POST, GET, OPTIONS
// 表明服務器允許請求中攜帶字段 X-PINGOTHER 與 Content-Type
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
// 表明該響應的有效時間為 86400 秒，也就是 24 小時。在有效時間內，瀏覽器無須為同一請求再次發起預檢請求。
Access-Control-Max-Age: 86400
復制代碼一般而言，對于跨域 XMLHttpRequest 或 Fetch 請求，瀏覽器不會發送身份憑證信息。如果要發送憑證信息，需要設置 XMLHttpRequest 的某個特殊標志位。比如說 XMLHttpRequest 的 withCredentials 標志設置為 true ，則可以發送 cookie 到服務端。
對于附帶身份憑證的請求，服務器不得設置 Access-Control-Allow-Origin 的值為“*”。 這是因為請求的首部中攜帶了 Cookie 信息，如果 Access-Control-Allow-Origin 的值為“*”，請求將會失敗。而將 Access-Control-Allow-Origin 的值設置為 http://foo.example ，則請求將成功執行。
CORS 涉及到的請求和響應頭如下： HTTP 響應首部字段
HTTP 請求首部字段
Origin
Access-Control-Request-Method
Access-Control-Request-Headers有感興趣的朋友可以關注一下我的公眾號：前端維他命，不定時更新優秀文章。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
