整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
參考回答：
https 的 SSL 加密是在傳輸層實現(xiàn)的。
(1)http 和 https 的基本概念
http: 超文本傳輸協(xié)議， 是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議， 是一個客戶端和服 務(wù)器端請求和應(yīng)答的標(biāo)準(zhǔn) (TCP) ， 用于從 WWW 服務(wù)器傳輸超文本到本地瀏覽器的傳 輸協(xié)議， 它可以使瀏覽器更加高效， 使網(wǎng)絡(luò)傳輸減少。
https: 是以安全為目標(biāo)的 HTTP 通道， 簡單講是 HTTP 的安全版， 即 HTTP 下加入 SSL 層， HTTPS 的安全基礎(chǔ)是 SSL， 因此加密的詳細(xì)內(nèi)容就需要 SSL。
https 協(xié)議的主要作用是：建立一個信息安全通道，來確保數(shù)組的傳輸，確保網(wǎng)站的真實 性。
(2)http 和 https 的區(qū)別？
http 傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的， 網(wǎng)景公司設(shè)置了 SSL 協(xié)議來對 http 協(xié)議 傳輸?shù)臄?shù)據(jù)進(jìn)行加密處理，簡單來說 https 協(xié)議是由 http 和 ssl 協(xié)議構(gòu)建的可進(jìn)行加密傳 輸和身份認(rèn)證的網(wǎng)絡(luò)協(xié)議， 比 http 協(xié)議的安全性更高。
主要的區(qū)別如下：
Https 協(xié)議需要 ca 證書， 費(fèi)用較高。
http 是超文本傳輸協(xié)議， 信息是明文傳輸， https 則是具有安全性的 ssl 加密傳輸協(xié)議。 使用不同的鏈接方式， 端口也不同， 一般而言， http 協(xié)議的端口為 80， https 的端口為443。
http 的連接很簡單，是無狀態(tài)的；HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳 輸 、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議， 比 http 協(xié)議安全。
(3)https 協(xié)議的工作原理
客戶端在使用 HTTPS 方式與 Web 服務(wù)器通信時有以下幾個步驟， 如圖所示。 客戶使用 https url 訪問服務(wù)器， 則要求web 服務(wù)器建立 ssl 鏈接。
web 服務(wù)器接收到客戶端的請求之后， 會將網(wǎng)站的證書 (證書中包含了公鑰) ， 返回或 者說傳輸給客戶端。
客戶端和 web 服務(wù)器端開始協(xié)商 SSL 鏈接的安全等級， 也就是加密等級。
客戶端瀏覽器通過雙方協(xié)商一致的安全等級，建立會話密鑰，然后通過網(wǎng)站的公鑰來加 密會話密鑰， 并傳送給網(wǎng)站。
web 服務(wù)器通過自己的私鑰解密出會話密鑰。
web 服務(wù)器通過會話密鑰加密與客戶端之間的通信。
(4)https 協(xié)議的優(yōu)點
使用HTTPS 協(xié)議可認(rèn)證用戶和服務(wù)器， 確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器；
HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸 、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議， 要比 http 協(xié)議安全， 可防止數(shù)據(jù)在傳輸過程中不被竊取 、改變， 確保數(shù)據(jù)的完整性 。 HTTPS 是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻 擊的成本。
谷歌曾在 2014 年 8 月份調(diào)整搜索引擎算法， 并稱“比起同等 HTTP 網(wǎng)站， 采用 HTTPS 加密的網(wǎng)站在搜索結(jié)果中的排名將會更高”。
(5)https 協(xié)議的缺點
https 握手階段比較費(fèi)時， 會使頁面加載時間延長 50%， 增加 10%~20%的耗電。
https 緩存不如 http 高效， 會增加數(shù)據(jù)開銷。
SSL 證書也需要錢， 功能越強(qiáng)大的證書費(fèi)用越高。
SSL 證書需要綁定 IP， 不能再同一個 ip 上綁定多個域名， ipv4 資源支持不了這種消耗。
參考回答：
客戶端和服務(wù)端都需要直到各自可收發(fā)， 因此需要三次握手。
簡化三次握手：
<img width="487" alt="2018-07-10 3 42 11" src="https://user-images.githubusercontent.com/ 17233651/42496289-1c6d668a-8458-11e8-98b3-65db50f64d48.png">從圖片可以得到三次握手可以簡化為：C 發(fā)起請求連接 S 確認(rèn)，也發(fā)起連接 C 確認(rèn)我們 再看看每次握手的作用： 第一次握手： S 只可以確認(rèn) 自己可以接受 C 發(fā)送的報文段第 二次握手： C 可以確認(rèn) S 收到了自己發(fā)送的報文段， 并且可以確認(rèn) 自己可以接受 S 發(fā) 送的報文段第三次握手： S 可以確認(rèn) C 收到了自己發(fā)送的報文段。
參考回答：
( 1) TCP 是面向連接的， udp 是無連接的即發(fā)送數(shù)據(jù)前不需要先建立鏈接。
( 2) TCP 提供可靠的服務(wù) 。也就是說， 通過 TCP 連接傳送的數(shù)據(jù)， 無差錯， 不丟失， 不重復(fù)， 且按序到達(dá);UDP 盡最大努力交付， 即不保證可靠交付 。 并且因為 tcp 可靠， 面向連接， 不會丟失數(shù)據(jù)因此適合大數(shù)據(jù)量的交換。
( 3) TCP 是面向字節(jié)流，UDP 面向報文，并且網(wǎng)絡(luò)出現(xiàn)擁塞不會使得發(fā)送速率降低 (因 此會出現(xiàn)丟包， 對實時的應(yīng)用比如 IP 電話和視頻會議等) 。
( 4) TCP 只能是 1 對 1 的， UDP 支持 1 對 1,1 對多。
( 5) TCP 的首部較大為 20 字節(jié)， 而 UDP 只有 8 字節(jié)。
( 6) TCP 是面向連接的可靠性傳輸， 而 UDP 是不可靠的。
參考回答：
(1)什么是 WebSocket?
WebSocket 是 HTML5 中的協(xié)議， 支持持久連續(xù)， http 協(xié)議不支持持久性連接 。Http1.0 和 HTTP1.1 都不支持持久性的鏈接， HTTP1.1 中的 keep-alive， 將多個 http 請求合并為 1 個
(2)WebSocket 是什么樣的協(xié)議， 具體有什么優(yōu)點？
HTTP 的生命周期通過 Request 來界定， 也就是 Request 一個 Response， 那么在 Http1.0 協(xié)議中， 這次 Http 請求就結(jié)束了 。在 Http1.1 中進(jìn)行了改進(jìn)， 是的有一個 connection： Keep-alive，也就是說，在一個 Http 連接中，可以發(fā)送多個 Request，接收多個 Response。 但是必須記住， 在 Http 中一個 Request 只能對應(yīng)有一個 Response， 而且這個 Response 是被動的， 不能主動發(fā)起。
WebSocket 是基于 Http 協(xié)議的，或者說借用了 Http 協(xié)議來完成一部分握手，在握手階段 與 Http 是相同的。我們來看一個 websocket 握手協(xié)議的實現(xiàn)，基本是 2 個屬性，upgrade， connection。
基本請求如下：
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com
多了下面 2 個屬性：
Upgrade:webSocket
Connection:Upgrade告訴服務(wù)器發(fā)送的是websocket
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13參考回答：
head： 類似于 get 請求， 只不過返回的響應(yīng)中沒有具體的內(nèi)容， 用戶獲取報頭 options： 允許客戶端查看服務(wù)器的性能， 比如說服務(wù)器支持的請求方式等等。
參考回答：
請求的返回頭里面， 用于瀏覽器解析的重要參數(shù)就是 OSS 的 API 文檔里面的返回http 頭， 決定用戶下載行為的參數(shù)。
下載的情況下：
x-oss-object-type: Normal
x-oss-request-id: 598D5ED34F29D01FE2925F41
x-oss-storage-class: Standard參考回答：
能夠被殘障人士使用的網(wǎng)站才能稱得上一個易用的 (易訪問的) 網(wǎng)站。 殘障人士指的是那些帶有殘疾或者身體不健康的用戶。
使用 alt 屬性：
<img src="person.jpg" alt="this is a person"/>有時候瀏覽器會無法顯示圖像 。具體的原因有：
用戶關(guān)閉了圖像顯示
瀏覽器是不支持圖形顯示的迷你瀏覽器
瀏覽器是語音瀏覽器 (供盲人和弱視人群使用)
如果您使用了alt 屬性， 那么瀏覽器至少可以顯示或讀出有關(guān)圖像的描述。
參考回答：
什么是 Bom? Bom 是瀏覽器對象 。有哪些常用的 Bom 屬性呢？
(1)location 對象
location.href-- 返回或設(shè)置當(dāng)前文檔的 URL
location.search -- 返回 URL 中的查詢字符串部分 。 例
如 http://www.dreamdu.com/dreamdu.php?id=5&name=dreamdu 返回包括(?)后面的內(nèi) 容?id=5&name=dreamdu
location.hash -- 返回 URL#后面的內(nèi)容， 如果沒有#， 返回空
location.host -- 返回 URL 中的域名部分， 例如 www.dreamdu.com
location.hostname -- 返回 URL 中的主域名部分， 例如 dreamdu.com
location.pathname -- 返回 URL 的域名后的部分 。例如 http://www.dreamdu.com/xhtml/ 返 回/xhtml/
location.port -- 返回 URL 中的端口部分 。 例如 http://www.dreamdu.com:8080/xhtml/ 返回8080
location.protocol -- 返回 URL 中的協(xié)議部分。例如 http://www.dreamdu.com:8080/xhtml/ 返 回(//)前面的內(nèi)容 http:
location.assign -- 設(shè)置當(dāng)前文檔的 URL
location.replace() -- 設(shè)置當(dāng)前文檔的 URL， 并且在 history 對象的地址列表中移除這個 URL location.replace(url);
location.reload() -- 重載當(dāng)前頁面
(2)history 對象
history.go() -- 前進(jìn)或后退指定的頁面數(shù) history.go(num);
history.back() -- 后退一頁
history.forward() -- 前進(jìn)一頁
(3)Navigator 對象
navigator.userAgent -- 返回用戶代理頭的字符串表示(就是包括瀏覽器版本信息等的字 符串)。
navigator.cookieEnabled -- 返回瀏覽器是否支持(啟用)cookie。
參考回答：
dragstart： 事件主體是被拖放元素， 在開始拖放被拖放元素時觸發(fā)， 。
darg： 事件主體是被拖放元素， 在正在拖放被拖放元素時觸發(fā)。
dragenter： 事件主體是目標(biāo)元素， 在被拖放元素進(jìn)入某元素時觸發(fā)。
dragover： 事件主體是目標(biāo)元素， 在被拖放在某元素內(nèi)移動時觸發(fā)。
dragleave： 事件主體是目標(biāo)元素， 在被拖放元素移出目標(biāo)元素是觸發(fā)。
drop： 事件主體是目標(biāo)元素， 在目標(biāo)元素完全接受被拖放元素時觸發(fā)。
dragend： 事件主體是被拖放元素， 在整個拖放操作結(jié)束時觸發(fā)。
參考回答：
首先補(bǔ)充一下， http 和 https 的區(qū)別， 相比于 http,https 是基于 ssl 加密的 http 協(xié)議
簡要概括： http2.0 是基于 1999 年發(fā)布的 http1.0 之后的首次更新。
提升訪問速度 (可以對于， 請求資源所需時間更少， 訪問速度更快， 相比 http1.0)
允許多路復(fù)用：多路復(fù)用允許同時通過單一的 HTTP/2 連接發(fā)送多重請求-響應(yīng)信息。改 善了： 在 http1.1 中， 瀏覽器客戶端在同一時間， 針對同一域名下的請求有一定數(shù)量限 制 (連接數(shù)量) ， 超過限制會被阻塞。
二進(jìn)制分幀：HTTP2.0 會將所有的傳輸信息分割為更小的信息或者幀，并對他們進(jìn)行二 進(jìn)制編碼、首部壓縮、服務(wù)器端推送。
參考回答：
(1)400 狀態(tài)碼： 請求無效
產(chǎn)生原因：
前端提交數(shù)據(jù)的字段名稱和字段類型與后臺的實體沒有保持一致。
前端提交到后臺的數(shù)據(jù)應(yīng)該是 json 字符串類型， 但是前端沒有將對象 JSON.stringify 轉(zhuǎn)化成字符串。
解決方法：
對照字段的名稱， 保持一致性，將 obj 對象通過 JSON.stringify 實現(xiàn)序列化。
(2)401 狀態(tài)碼： 當(dāng)前請求需要用戶驗證
(3)403 狀態(tài)碼： 服務(wù)器已經(jīng)得到請求， 但是拒絕執(zhí)行
參考回答：
fetch 發(fā)送 post 請求的時候， 總是發(fā)送 2 次， 第一次狀態(tài)碼是 204， 第二次才成功？
原因很簡單， 因為你用 fetch 的 post 請求的時候， 導(dǎo)致 fetch 第一次發(fā)送了一個 Options 請求，詢問服務(wù)器是否支持修改的請求頭，如果服務(wù)器支持，則在第二次中發(fā)送真正的 請求。
參考回答：
在 HTML 頁面中，如果在執(zhí)行腳本時，頁面的狀態(tài)是不可相應(yīng)的，直到腳本執(zhí)行完成后， 頁面才變成可相應(yīng) 。web worker 是運(yùn)行在后臺的 js， 獨(dú)立于其他腳本， 不會影響頁面你 的性能 。并且通過 postMessage 將結(jié)果回傳到主線程 。這樣在進(jìn)行復(fù)雜操作的時候， 就 不會阻塞主線程了。
如何創(chuàng)建 web worker：
檢測瀏覽器對于 web worker 的支持性
創(chuàng)建 web worker 文件 (js， 回傳函數(shù)等)
創(chuàng)建 web worker 對象
參考回答：
HTML5 語義化標(biāo)簽是指正確的標(biāo)簽包含了正確的內(nèi)容，結(jié)構(gòu)良好，便于閱讀， 比如nav 表示導(dǎo)航條， 類似的還有 article 、header 、footer 等等標(biāo)簽。
參考回答：
定義： iframe 元素會創(chuàng)建包含另一個文檔的內(nèi)聯(lián)框架
提示： 可以將提示文字放在<iframe></iframe>之間， 來提示某些不支持 iframe 的瀏覽器 缺點： 會阻塞主頁面的 onload 事件 搜索引擎無法解讀這種頁面， 不利于 SEO iframe 和主頁面共享連接池， 而瀏覽器對相同區(qū)域有限制所以會影響性能。
參考回答：
Doctype 聲明于文檔最前面， 告訴瀏覽器以何種方式來渲染頁面， 這里有兩種模式， 嚴(yán) 格模式和混雜模式。
嚴(yán)格模式的排版和 JS 運(yùn)作模式是 以該瀏覽器支持的最高標(biāo)準(zhǔn)運(yùn)行。
混雜模式， 向后兼容， 模擬老式瀏覽器， 防止瀏覽器無法兼容頁面。
參考回答：
XSS (跨站腳本攻擊) 是指攻擊者在返回的 HTML 中嵌入 javascript 腳本，為了減輕這些 攻擊， 需要在 HTTP 頭部配上， set-cookie：
httponly-這個屬性可以防止 XSS,它會禁止 javascript 腳本來訪問 cookie。
secure - 這個屬性告訴瀏覽器僅在請求為 https 的時候發(fā)送 cookie。
結(jié)果應(yīng)該是這樣的： Set-Cookie=<cookie-value>.....
參考回答：
就是用URL 定位資源， 用 HTTP 描述操作。
參考回答：
可以參考這篇文章：
響應(yīng)式布局的常用解決方案對比(媒體查詢、百分比、rem 和 vw/vh)
參考回答：
(1)粗暴型， 禁用縮放
<meta name="viewport" content="width=device-width, user-scalable=no">(2)利用 FastClick， 其原理是：
檢測到 touchend 事件后， 立刻出發(fā)模擬 click 事件， 并且把瀏覽器 300 毫秒之后真正出 發(fā)的事件給阻斷掉。
參考回答：
addEventListener(event, function, useCapture)其中， event 指定事件名； function 指定要事件觸發(fā)時執(zhí)行的函數(shù)； useCapture 指定事件 是否在捕獲或冒泡階段執(zhí)行。
參考回答：
100 Continue 繼續(xù) 。客戶端應(yīng)繼續(xù)其請求。
101 Switching Protocols 切換協(xié)議。服務(wù)器根據(jù)客戶端的請求切換協(xié)議。只能切換到更 高級的協(xié)議， 例如， 切換到HTTP 的新版本協(xié)議。
200 OK 請求成功 。一般用于 GET 與 POST 請求。
201 Created 已創(chuàng)建 。成功請求并創(chuàng)建了新的資源。
202 Accepted 已接受 。 已經(jīng)接受請求， 但未處理完成。
203 Non-Authoritative Information 非授權(quán)信息。請求成功。但返回的 meta 信息不在原 始的服務(wù)器， 而是一個副本。
204 No Content 無內(nèi)容 。服務(wù)器成功處理， 但未返回內(nèi)容 。在未更新網(wǎng)頁的情況下， 可確保瀏覽器繼續(xù)顯示當(dāng)前文檔。
205 Reset Content 重置內(nèi)容。服務(wù)器處理成功， 用戶終端 (例如： 瀏覽器) 應(yīng)重置文 檔視圖 。可通過此返回碼清除瀏覽器的表單域。
206 Partial Content 部分內(nèi)容 。服務(wù)器成功處理了部分 GET 請求。
300 Multiple Choices 多種選擇。請求的資源可包括多個位置，相應(yīng)可返回一個資源特 征與地址的列表用于用戶終端 (例如： 瀏覽器) 選擇。
301 Moved Permanently 永久移動。請求的資源已被永久的移動到新 URI，返回信息會 包括新的 URI，瀏覽器會自動定向到新 URI。今后任何新的請求都應(yīng)使用新的 URI 代替。
302 Found 臨時移動。與 301 類似。但資源只是臨時被移動。客戶端應(yīng)繼續(xù)使用原有 URI。
303 See Other 查看其它地址 。與 301 類似 。使用 GET 和 POST 請求查看。
304 Not Modified 未修改 。所請求的資源未修改， 服務(wù)器返回此狀態(tài)碼時， 不會返回 任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返 回在指定日期之后修改的資源。
305 Use Proxy 使用代理 。所請求的資源必須通過代理訪問。
306 Unused 已經(jīng)被廢棄的 HTTP 狀態(tài)碼。
307 Temporary Redirect 臨時重定向 。與 302 類似 。使用 GET 請求重定向。
400 Bad Request 客戶端請求的語法錯誤， 服務(wù)器無法理解。
401 Unauthorized 請求要求用戶的身份認(rèn)證。
402 Payment Required 保留， 將來使用。
403 Forbidden 服務(wù)器理解請求客戶端的請求， 但是拒絕執(zhí)行此請求。
404 Not Found 服務(wù)器無法根據(jù)客戶端的請求找到資源 (網(wǎng)頁) 。通過此代碼， 網(wǎng)站 設(shè)計人員可設(shè)置"您所請求的資源無法找到"的個性頁面。
405 Method Not Allowed 客戶端請求中的方法被禁止。
406 Not Acceptable 服務(wù)器無法根據(jù)客戶端請求的內(nèi)容特性完成請求。
407 Proxy Authentication Required 請求要求代理的身份認(rèn)證， 與 401 類似， 但請求者 應(yīng)當(dāng)使用代理進(jìn)行授權(quán)。
408 Request Time-out 服務(wù)器等待客戶端發(fā)送的請求時間過長， 超時。
409 Conflict 服務(wù)器完成客戶端的 PUT 請求是可能返回此代碼，服務(wù)器處理請求時發(fā) 生了沖突。
410 Gone 客戶端請求的資源已經(jīng)不存在。410 不同于 404，如果資源以前有現(xiàn)在被永 久刪除了可使用410 代碼， 網(wǎng)站設(shè)計人員可通過 301 代碼指定資源的新位置。
411 Length Required 服務(wù)器無法處理客戶端發(fā)送的不帶 Content-Length 的請求信息。
412 Precondition Failed 客戶端請求信息的先決條件錯誤。
413 Request Entity Too Large 由于請求的實體過大，服務(wù)器無法處理， 因此拒絕請求。 為防止客戶端的連續(xù)請求，服務(wù)器可能會關(guān)閉連接。如果只是服務(wù)器暫時無法處理，則 會包含一個 Retry-After 的響應(yīng)信息。
414 Request-URI Too Large 請求的 URI 過長 ( URI 通常為網(wǎng)址) ， 服務(wù)器無法處理。
415 Unsupported Media Type 服務(wù)器無法處理請求附帶的媒體格式。
416 Requested range not satisfiable 客戶端請求的范圍無效。
417 Expectation Failed 服務(wù)器無法滿足 Expect 的請求頭信息。
500 Internal Server Error 服務(wù)器內(nèi)部錯誤， 無法完成請求。
501 Not Implemented 服務(wù)器不支持請求的功能， 無法完成請求。
502 Bad Gateway 作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請求時， 從遠(yuǎn)程服務(wù)器接 收到了一個無效的響應(yīng)。
503 Service Unavailable 由于超載或系統(tǒng)維護(hù)，服務(wù)器暫時的無法處理客戶端的請求。 延時的長度可包含在服務(wù)器的 Retry-After 頭信息中。
504 Gateway Time-out 充當(dāng)網(wǎng)關(guān)或代理的服務(wù)器， 未及時從遠(yuǎn)端服務(wù)器獲取請求。
505 HTTP Version not supported 服務(wù)器不支持請求的 HTTP 協(xié)議的版本， 無法完成處 理。
參考回答：
協(xié)議頭 | 說明 |
Accept | 可接受的響應(yīng)內(nèi)容類型 (Content-Types) 。 |
Accept-Charset | 可接受的字符集。 |
Accept-Encoding | 可接受的響應(yīng)內(nèi)容的編碼方式。 |
Accept-Language | 可接受的響應(yīng)內(nèi)容語言列表。 |
Accept-Datetime | 可接受的按照時間來表示的響應(yīng)內(nèi)容版本。 |
Authorization | 用于表示 HTTP 協(xié)議中需要認(rèn)證資源的認(rèn)證信息。 |
Cache-Control | 用來指定當(dāng)前的請求/回復(fù)中的， 是否使用緩存機(jī)制。 |
Connection | 客戶端 (瀏覽器) 想要優(yōu)先使用的連接類型。 |
Cookie | 由之前服務(wù)器通過 Set-Cookie(見下文)設(shè)置的一個 HTTP 協(xié)議 Cookie。 |
Content-Length | 以 8 進(jìn)制表示的請求體的長度。 |
Content-MD5 | 請求體的內(nèi)容的二進(jìn)制 MD5 散列值 (數(shù)字簽名) ， 以 Base64 編碼的結(jié)果。 |
Content-Type | 請求體的 MIME 類型 (用于 POST 和 PUT 請求中)。 |
Date | 發(fā)送該消息的日期和時間 (以RFC 7231中定義的"HTTP 日期"格式 來發(fā)送)。 |
Expect | 表示客戶端要求服務(wù)器做出特定的行為。 |
From | 發(fā)起此請求的用戶的郵件地址。 |
Host | 表示服務(wù)器的域名以及服務(wù)器所監(jiān)聽的端口號 。如果所請求的端口 是對應(yīng)的服務(wù)的標(biāo)準(zhǔn)端口 ( 80) ， 則端口號可以省略。 |
If-Match | 僅當(dāng)客戶端提供的實體與服務(wù)器上對應(yīng)的實體相匹配時， 才進(jìn)行對應(yīng)的操作 。主要用于像 PUT 這樣的方法中， 僅當(dāng)從用戶上次更新 某個資源后， 該資源未被修改的情況下， 才更新該資源。 |
If-Modified-Since | 允許在對應(yīng)的資源未被修改的情況下返回304 未修改 |
If-None-Match | 允許在對應(yīng)的內(nèi)容未被修改的情況下返回304 未修改 ( 304 Not Modified ) ， 參考 超文本傳輸協(xié)議 的實體標(biāo)記 |
If-Range | 如果該實體未被修改過， 則向返回所缺少的那一個或多個部分 。否 則， 返回整個新的實體。 |
If-Unmodified-Since | 僅當(dāng)該實體自某個特定時間以來未被修改的情況下， 才發(fā)送回應(yīng)。 |
Max-Forwards | 限制該消息可被代理及網(wǎng)關(guān)轉(zhuǎn)發(fā)的次數(shù)。 |
Origin | 發(fā)起一個針對跨域資源共享的請求 (該請求要求服務(wù)器在響應(yīng)中加入一個 Access-Control-Allow-Origin 的消息頭，表示訪問控制所允許 的來源) 。 |
Pragma | 與具體的實現(xiàn)相關(guān)， 這些字段可能在請求/回應(yīng)鏈中的任何時候產(chǎn) 生。 |
Proxy-Authorization | 用于向代理進(jìn)行認(rèn)證的認(rèn)證信息。 |
Range | 表示請求某個實體的一部分， 字節(jié)偏移以 0 開始。 |
Referer | 表示瀏覽器所訪問的前一個頁面， 可以認(rèn)為是之前訪問頁面的鏈接將瀏覽器帶到了當(dāng)前頁面。Referer 其實是 Referrer 這個單詞，但 RFC 制作標(biāo)準(zhǔn)時給拼錯了， 后來也就將錯就錯使用 Referer 了。 |
TE | 瀏覽器預(yù)期接受的傳輸時的編碼方式： 可使用回應(yīng)協(xié)議頭 Transfer-Encoding 中的值 (還可以使用"trailers"表示數(shù)據(jù)傳輸時的分 塊方式) 用來表示瀏覽器希望在最后一個大小為 0 的塊之后還接收到一些額外的字段。 |
User-Agent | 瀏覽器的身份標(biāo)識字符串。 |
Upgrade | 要求服務(wù)器升級到一個高版本協(xié)議。 |
Via | 告訴服務(wù)器， 這個請求是由哪些代理發(fā)出的。 |
Warning | 一個一般性的警告， 表示在實體內(nèi)容體中可能存在錯誤。 |
參考回答：
緩存分為兩種： 強(qiáng)緩存和協(xié)商緩存， 根據(jù)響應(yīng)的header 內(nèi)容來決定。
獲取資源形式 | 狀態(tài)碼 | 發(fā)送請求到服務(wù)器 | |
強(qiáng)緩存 | 從緩存取 | 200 (from cache) | 否， 直接從緩存取 |
協(xié)商緩存 | 從緩存取 | 304 (not modified) | 是，通過服務(wù)器來告知緩存是否可 用 |
強(qiáng)緩存相關(guān)字段有 expires， cache-control 。如果 cache-control 與 expires 同時存在的話， cache-control 的優(yōu)先級高于 expires。
協(xié)商緩存相關(guān)字段有 Last-Modified/If-Modified-Since， Etag/If-None-Match。
參考回答：
304：如果客戶端發(fā)送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內(nèi)容 (自 上次訪問以來或者根據(jù)請求的條件) 并沒有改變， 則服務(wù)器應(yīng)當(dāng)返回這個 304 狀態(tài)碼。
參考回答：
因為服務(wù)器上的資源不是一直固定不變的，大多數(shù)情況下它會更新，這個時候如果我們 還訪問本地緩存，那么對用戶來說，那就相當(dāng)于資源沒有更新，用戶看到的還是舊的資 源；所以我們希望服務(wù)器上的資源更新了瀏覽器就請求新的資源，沒有更新就使用本地 的緩存， 以最大程度的減少因網(wǎng)絡(luò)請求而產(chǎn)生的資源浪費(fèi)。
參考 https://segmentfault.com/a/1190000008956069
參考回答：
降低請求量： 合并資源， 減少 HTTP 請求數(shù)， minify / gzip 壓縮， webP， lazyLoad。
加快請求速度： 預(yù)解析 DNS， 減少域名數(shù)， 并行加載， CDN 分發(fā)。
緩存： HTTP 協(xié)議緩存請求， 離線緩存 manifest， 離線數(shù)據(jù)緩存 localStorage。
渲染： JS/CSS 優(yōu)化， 加載順序， 服務(wù)端渲染， pipeline。
WebP 是一種同時提供了有損壓縮與無損壓縮的圖片文件格式。可以大大壓縮圖片的大小，并且圖片的質(zhì)量和 png、jpeg 等相同。WebP 的無損壓縮比 png 格式的文件平均少了 45％ 的大小。
這里是使用了同一張圖片轉(zhuǎn)換為不同格式的圖片后，對圖片的大小進(jìn)行對比的測試結(jié)果：
格式 | webp | jpeg | png | gif |
大小 | 1.65MB | 2.24MB | 7.51MB | 4.64MB |
使用 webp 壓縮后圖片大小減少百分比 | ↓ 26% | ↓ 78% | ↓ 64% |
目前大約 95.77% 的瀏覽器都支持 WebP 格式的圖片，其中 Safari 瀏覽器僅在 Big Sur 及以上的macOS 系統(tǒng)才支持 WebP；針對不兼容的情況下，我們需要進(jìn)行相應(yīng)的降級措施。
降級處理原則
降級處理方式
降級處理示例
拿淘寶首頁舉個例子
圖片 URL：img.alicdn.com/imgextra/i2…
在 chrome 中加載的是 webp 格式的圖片：
在 IE 中加載的則是 jpg 格式的圖片：
可以看出淘寶是對圖片的 URL 進(jìn)行了特殊處理，通過在原始圖片后加上 _.webp 后綴來做降級處理，如果當(dāng)前瀏覽器支持 webp 格式的圖片，則加載 webp 格式的圖片，若不支持則去掉 _.webp 的后綴加載 jpg 格式的圖片。
如果你覺得此文對你有一丁點幫助，點個贊。或者可以加入我的開發(fā)交流群：1025263163相互學(xué)習(xí)，我們會有專業(yè)的技術(shù)答疑解惑
如果你覺得這篇文章對你有點用的話，麻煩請給我們的開源項目點點star: https://gitee.com/ZhongBangKeJi/CRMEB不勝感激 ！
像是web上提供的最基本的內(nèi)容類型之一。他們說一張圖片勝過千言萬語。但是如果你不小心的話，圖片大小有時高達(dá)幾十兆。
因此，雖然網(wǎng)絡(luò)圖像需要清晰明快，但它們尺寸可以縮小壓縮的，使用加載時間保持在可接受的水平。
在我的網(wǎng)站上，我注意到我的主頁的頁面大小 超過了 1.1MB，圖片占了約88%，我還注意到我提供的圖像比它們需要的大(在分辨率方面)，顯然，還有很多改進(jìn)的空間。
我開始閱讀 Addy Osmani 的優(yōu)秀 Essential Image Optimization電子書，并開始在我的網(wǎng)站上按照他們的建議做了一些圖片的優(yōu)化。，然后再對響應(yīng)式圖像進(jìn)行了一些研究并應(yīng)用了它。
這使得頁面大小減少到 445kb，約 62% !
什么是圖像壓縮?
壓縮圖像就是在圖片保持在可接受的清晰度范圍內(nèi)同時減少文件大小，我使用 imagemin 來壓縮站點上的圖像。
要使用 imagemin，確保你已經(jīng)安裝了 Node.js，然后打開一個終端窗口，cd 進(jìn)入項目，并運(yùn)行以下命令:
npm install imagemin
然后創(chuàng)建一個名為 imagemin.js 的新文件，寫入下面的內(nèi)容：
constimagemin =require('imagemin');constPNGImages ='assets/images/*.png';constJPEGImages ='assets/images/*.jpg';constoutput ='build/images';
你可以根據(jù)自己的需要更改 PNGImages、JPEGImages 和 output 的值，以符合你的項目結(jié)構(gòu)。
此外要執(zhí)行圖片壓縮，還需要根據(jù)要壓縮的圖像類型安裝對應(yīng)的插件。
JPEG/JPG
JPG 的優(yōu)點
JPG 最大的特點是 有損壓縮。這種高效的壓縮算法使它成為了一種非常輕巧的圖片格式。另一方面，即使被稱為“有損”壓縮，JPG的壓縮方式仍然是一種高質(zhì)量的壓縮方式：當(dāng)我們把圖片體積壓縮至原有體積的 50% 以下時，JPG 仍然可以保持住 60% 的品質(zhì)。此外，JPG 格式以 24 位存儲單個圖，可以呈現(xiàn)多達(dá) 1600 萬種顏色，足以應(yīng)對大多數(shù)場景下對色彩的要求，這一點決定了它壓縮前后的質(zhì)量損耗并不容易被我們?nèi)祟惖娜庋鬯煊X——前提是你用對了業(yè)務(wù)場景。
JPG 使用場景
JPG 適用于呈現(xiàn)色彩豐富的圖片，在我們?nèi)粘ｉ_發(fā)中，JPG 圖片經(jīng)常作為大的背景圖、輪播圖或 Banner 圖出現(xiàn)。
JPG 的缺陷
有損壓縮在上文所展示的輪播圖上確實很難露出馬腳，但當(dāng)它處理矢量圖形和 Logo 等線條感較強(qiáng)、顏色對比強(qiáng)烈的圖像時，人為壓縮導(dǎo)致的圖片模糊會相當(dāng)明顯。
此外，JPEG 圖像不支持透明度處理，透明圖片需要召喚 PNG 來呈現(xiàn)。
使用 MozJPEG 壓縮 jpeg
這里使用 Mozilla 的 MozJPEG 工具，該工具可以通過 imagemin-mozjpeg 作為 Imagemin 插件使用。你可以通過運(yùn)行以下命令來安裝它:
npm install imagemin-mozjpeg
然后將以下內(nèi)容添加到的 imagemin.js 中:
constimageminMozjpeg =require('imagemin-mozjpeg');constoptimiseJPEGImages =()=>imagemin([JPEGImages], output, {plugins: [ imageminMozjpeg({quality:70, }), ] });optimiseJPEGImages() .catch(error=>console.log(error));
可以通過在終端中運(yùn)行 node imagemin.js 來運(yùn)行腳本。這將處理所有JPEG圖像，并將優(yōu)化后的版本放 build/images 文件夾中。
我發(fā)現(xiàn)將 quality 設(shè)置為 70 在大多數(shù)情況下可以產(chǎn)生足夠清晰的圖像，但你的項目需求可能不同，可以自行設(shè)置合適的值。
默認(rèn)情況下，MozJPEG 生成漸進(jìn)式 jpeg，這會導(dǎo)致圖像從低分辨率逐漸加載到高分辨率，直到圖片完全加載為止。由于它們的編碼方式，它們也比原始的 jpeg 略小。
你可以使用 Sindre Sorhus 提供的這個命令行工具來檢查JPEG圖像是否是漸進(jìn)式的。
Addy Osmani 已經(jīng)很好地總結(jié)了使用漸進(jìn)式 jpeg 的優(yōu)缺點。對我來說，我覺得利大于弊，所以我堅持使用默認(rèn)設(shè)置。
如果你更喜歡使用原始的jpeg，可以在 options 對象中將 progressive 設(shè)置為 false。另外，請確保 imagemin-mozjpeg版本的變化，請重新查看對應(yīng)文檔。
PNG (PNG-8 與 PNG-24)
PNG 的優(yōu)缺點
PNG（可移植網(wǎng)絡(luò)圖形格式）是一種無損壓縮的高保真的圖片格式。8 和 24，這里都是二進(jìn)制數(shù)的位數(shù)。按照我們前置知識里提到的對應(yīng)關(guān)系，8 位的 PNG 最多支持 256 種顏色，而 24 位的可以呈現(xiàn)約 1600 萬種顏色。
PNG 圖片具有比 JPG 更強(qiáng)的色彩表現(xiàn)力，對線條的處理更加細(xì)膩，對透明度有良好的支持。它彌補(bǔ)了上文我們提到的 JPG 的局限性，唯一的缺點就是體積太大。
PNG 應(yīng)用場景
前面我們提到，復(fù)雜的、色彩層次豐富的圖片，用 PNG 來處理的話，成本會比較高，我們一般會交給 JPG 去存儲。
考慮到 PNG 在處理線條和顏色對比度方面的優(yōu)勢，我們主要用它來呈現(xiàn)小的 Logo、顏色簡單且對比強(qiáng)烈的圖片或背景等。
使用 pngquant 優(yōu)化 PNG 圖像
pngquant 是我優(yōu)化PNG圖像的首選工具，你可以通過 imagemin-pngquant 使用它:
npm install imagemin-pngquant
然后將以下內(nèi)容添加到 imagemin.js 文件中:
constimageminPngquant =require('imagemin-pngquant');constoptimisePNGImages =()=>imagemin([PNGImages], output, {plugins: [ imageminPngquant({quality:'65-80'}) ], });optimiseJPEGImages() .then(()=>optimisePNGImages()) .catch(error=>console.log(error));
我發(fā)現(xiàn)將 quality 設(shè)置為 65-80 可以在文件大小和圖像質(zhì)量之間較好的折衷方案。
有了這些設(shè)置，我可以得到一個屏幕截圖，我的網(wǎng)站從 913kb 到 187kb，沒有任何明顯的視覺損失，驚人的79% 的降幅!
這是兩個文件。看一看，自己判斷一下:
原圖(913kb)
優(yōu)化后的圖像(187kb)
代碼部署后可能存在的BUG沒法實時知道，事后為了解決這些BUG，花了大量的時間進(jìn)行l(wèi)og 調(diào)試，這邊順便給大家推薦一個好用的BUG監(jiān)控工具 Fundebug。
WebP
WebP 的優(yōu)點
WebP 像 JPEG 一樣對細(xì)節(jié)豐富的圖片信手拈來，像 PNG 一樣支持透明，像 GIF 一樣可以顯示動態(tài)圖片——它集多種圖片文件格式的優(yōu)點于一身。
WebP 的官方介紹對這一點有著更權(quán)威的闡述：
與 PNG 相比，WebP 無損圖像的尺寸縮小了 26％。在等效的 SSIM 質(zhì)量指數(shù)下，WebP 有損圖像比同類 JPEG 圖像小25-34％。 無損 WebP 支持透明度（也稱為 alpha 通道），僅需 22％ 的額外字節(jié)。對于有損 RGB 壓縮可接受的情況，有損 WebP 也支持透明度，與 PNG 相比，通常提供 3 倍的文件大小。
將 WebP 圖像提供給支持它們的瀏覽器
WebP 是谷歌引入的一種相對較新的格式，它的目標(biāo)是通過以無損和有損格式編碼圖像來提供更小的文件大小，使其成為 JPEG 和 PNG 的一個很好的替代方案。
WebP 圖像的清晰度通常可以與 JPEG 和 PNG相提并論，而且文件大小要小得多。例如，當(dāng)我將屏幕截圖從上面轉(zhuǎn)換到 WebP 時，我得到了一個 88kb 的文件，其質(zhì)量與 913kb 的原始圖像相當(dāng)，減少了90% !
看看這三張圖片，你能說出區(qū)別嗎?
原圖PNG (913kb)
優(yōu)化PNG圖像(187kb)
WebP圖像(88kb，可在Chrome或Opera瀏覽器中瀏覽)
就我個人而言，我認(rèn)為視覺效果是可以比較的，而且節(jié)省下來的大小是不容忽視的。
既然我們已經(jīng)認(rèn)識到在可能的情況下使用WebP格式是有價值的，那么很重要的一點是—它不能完全替代 JPEG 和 PNG，因為瀏覽器對 WebP 支持并不普遍。
在撰寫本文時，F(xiàn)irefox、Safari 和 Edge 都是不支持WebP的瀏覽器。
然而，根據(jù) caniuse.com 的數(shù)據(jù)，全球超過70%的用戶使用支持WebP的瀏覽器。這意味著，通過使用 WebP 圖像，可以為大約 70% 的客戶提供更快的 web 頁面及更好的體驗。
安裝它，運(yùn)行以下命令：
npm install imagemin-webp
然后將以下內(nèi)容添加到你的 imagemin.js 文件中:
constimageminWebp =require('imagemin-webp');constconvertPNGToWebp =()=>imagemin([PNGImages], output, {use: [ imageminWebp({quality:85, }), ] });constconvertJPGToWebp =()=>imagemin([JPGImages], output, {use: [ imageminWebp({quality:75, }), ] });optimiseJPEGImages() .then(()=>optimisePNGImages()) .then(()=>convertPNGToWebp()) .then(()=>convertJPGToWebp()) .catch(error=>console.log(error));
我發(fā)現(xiàn)，將 quality 設(shè)置為 85 會生成質(zhì)量與 PNG 相當(dāng)?shù)〉枚嗟?WebP 圖像。對于 jpeg，我發(fā)現(xiàn)將 quality 設(shè)置為 75 可以在視覺和文件大小之間取得很好的平衡。
提供 HTML格式的WebP圖像
一旦有了 WebP 圖像，可以使用以下標(biāo)記將它們提供給可以使用它們的瀏覽器，同時向不兼容 WebP 的瀏覽器使用 png 或者 jpeg。
使用此標(biāo)記，理解 image/webp 媒體類型的瀏覽器將下載 Webp 圖片并顯示它，而其他瀏覽器將下載 JPEG 圖片。
任何不支持 <picture> 的瀏覽器都將跳過所有 source 標(biāo)簽，并加載底部 img 標(biāo)簽。因此，我們通過提供對所有瀏覽器類的支持，逐步增強(qiáng)了我們的頁面。
請注意，在所有情況下，img 標(biāo)記都是實際呈現(xiàn)給頁面的內(nèi)容，因此它確實是語法的必需部分。 如果省略 img 標(biāo)記，則不會渲染任何圖像。
標(biāo)簽和其中定義的所有 source 都在那里，以便瀏覽器可以選擇要使用的圖片的路徑。 選擇源圖像后，其 URL 將傳給 img 標(biāo)記，這就是顯示的內(nèi)容。
這意味著你無需設(shè)置 <picture> 或 source 標(biāo)記的樣式，因為瀏覽器不會渲染這些標(biāo)記。 因此，你可以像以前一樣繼續(xù)使用 img 標(biāo)簽進(jìn)行樣式設(shè)置。
總結(jié)
正如你所看到的，優(yōu)化 web 上使用的圖像的過程并不復(fù)雜，通過減少頁面加載時間，可以為客戶帶來更好的用戶體驗，希望本文對你有所幫助，共進(jìn)步！
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
