整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
比于早些年前后端代碼緊密耦合、后端工程師還得寫前端代碼的時代，如今已發展到前后端分離，這種開發方式大大提升了前后端項目的可維護性與開發效率，讓前后端工程師關注于自己的主業。然而在帶來便利的同時，也帶來了一些弊端，比如首屏渲染時間(FCP)因為首屏需要請求更多內容，比原來多了更多HTTP的往返時間(RTT)，這造成了白屏，如果白屏時間過長，用戶體驗會大打折扣，如果用戶網速差，則FCP會更長。
由此引申出一系列的優化方法，骨架屏也因此被提出，本文就以 Vue 項目中的骨架屏為例，探討一下骨架屏的優缺點和注入方式。
感興趣的同學可以加一下微信群，一起討論吧～
在 Google 提出的以用戶為中心的四個頁面性能衡量指標中，FP/FCP可能是開發者們最熟悉的了：
為了優化首屏渲染時間這個指標，減少白屏時間，前端仔們想了很多辦法：
這里要介紹的就是優化用戶等待體驗的骨架屏，它可以被視為是原來加載菊花圖的一種升級版，結合傳統的首屏優化方法對應用進行優化可以達到不錯的效果。
骨架屏可以理解為是當數據還未加載進來前，頁面的一個空白版本，一個簡單的關鍵渲染路徑。可以看一下下面Facebook的骨架屏實現，可以看到在頁面完全渲染完成之前，用戶會看到一個樣式簡單，描繪了當前頁面的大致框架的骨架屏頁面，然后骨架屏中各個占位部分被實際資源完全替換，這個過程中用戶會覺得內容正在逐漸加載即將呈現，降低了用戶的焦躁情緒，使得加載過程主觀上變得流暢。
可以看一下下面的示例圖，第一個為骨架屏，第二個為菊花圖，第三個為無優化，可以看到相比于傳統的菊花圖會在感官上覺得內容出現的流暢而不突兀，體驗更加優良。
如今這項技術已經在Facebook、Google、支付寶、餓了么、簡書、新浪微博、知乎、美團、領英等公司的產品中被廣泛的使用。在論壇和社區也都有不少文章討論骨架屏的實現和使用場景等。
生成骨架屏的方式主要有：
另外還有個插件 vue-skeleton-webpack-plugin，它將插入骨架屏的方式由手動改為自動，原理在構建時使用 Vue 預渲染功能，將骨架屏組件的渲染結果 HTML 片段插入 HTML 頁面模版的掛載點中，將樣式內聯到 head標簽中。這個插件可以給單頁面的不同路由設置不同的骨架屏，也可以給多頁面設置，同時為了開發時調試方便，會將骨架屏作為路由寫入router中，可謂是相當體貼了。
vue-skeleton-webpack-plugin 的具體使用參考 vue-style-codebase，主要關注build目錄的幾個文件，實例跑起來之后在 Chrome 的 DevTools 中把 network 的網速調為 Gast3G/Slow3G 就能看到效果了~
參考回答：
https 的 SSL 加密是在傳輸層實現的。
(1)http 和 https 的基本概念
http: 超文本傳輸協議， 是互聯網上應用最為廣泛的一種網絡協議， 是一個客戶端和服 務器端請求和應答的標準 (TCP) ， 用于從 WWW 服務器傳輸超文本到本地瀏覽器的傳 輸協議， 它可以使瀏覽器更加高效， 使網絡傳輸減少。
https: 是以安全為目標的 HTTP 通道， 簡單講是 HTTP 的安全版， 即 HTTP 下加入 SSL 層， HTTPS 的安全基礎是 SSL， 因此加密的詳細內容就需要 SSL。
https 協議的主要作用是：建立一個信息安全通道，來確保數組的傳輸，確保網站的真實 性。
(2)http 和 https 的區別？
http 傳輸的數據都是未加密的，也就是明文的， 網景公司設置了 SSL 協議來對 http 協議 傳輸的數據進行加密處理，簡單來說 https 協議是由 http 和 ssl 協議構建的可進行加密傳 輸和身份認證的網絡協議， 比 http 協議的安全性更高。
主要的區別如下：
Https 協議需要 ca 證書， 費用較高。
http 是超文本傳輸協議， 信息是明文傳輸， https 則是具有安全性的 ssl 加密傳輸協議。 使用不同的鏈接方式， 端口也不同， 一般而言， http 協議的端口為 80， https 的端口為443。
http 的連接很簡單，是無狀態的；HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳 輸 、身份認證的網絡協議， 比 http 協議安全。
(3)https 協議的工作原理
客戶端在使用 HTTPS 方式與 Web 服務器通信時有以下幾個步驟， 如圖所示。 客戶使用 https url 訪問服務器， 則要求web 服務器建立 ssl 鏈接。
web 服務器接收到客戶端的請求之后， 會將網站的證書 (證書中包含了公鑰) ， 返回或 者說傳輸給客戶端。
客戶端和 web 服務器端開始協商 SSL 鏈接的安全等級， 也就是加密等級。
客戶端瀏覽器通過雙方協商一致的安全等級，建立會話密鑰，然后通過網站的公鑰來加 密會話密鑰， 并傳送給網站。
web 服務器通過自己的私鑰解密出會話密鑰。
web 服務器通過會話密鑰加密與客戶端之間的通信。
(4)https 協議的優點
使用HTTPS 協議可認證用戶和服務器， 確保數據發送到正確的客戶機和服務器；
HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸 、身份認證的網絡協議， 要比 http 協議安全， 可防止數據在傳輸過程中不被竊取 、改變， 確保數據的完整性 。 HTTPS 是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻 擊的成本。
谷歌曾在 2014 年 8 月份調整搜索引擎算法， 并稱“比起同等 HTTP 網站， 采用 HTTPS 加密的網站在搜索結果中的排名將會更高”。
(5)https 協議的缺點
https 握手階段比較費時， 會使頁面加載時間延長 50%， 增加 10%~20%的耗電。
https 緩存不如 http 高效， 會增加數據開銷。
SSL 證書也需要錢， 功能越強大的證書費用越高。
SSL 證書需要綁定 IP， 不能再同一個 ip 上綁定多個域名， ipv4 資源支持不了這種消耗。
參考回答：
客戶端和服務端都需要直到各自可收發， 因此需要三次握手。
簡化三次握手：
<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 發起請求連接 S 確認，也發起連接 C 確認我們 再看看每次握手的作用： 第一次握手： S 只可以確認 自己可以接受 C 發送的報文段第 二次握手： C 可以確認 S 收到了自己發送的報文段， 并且可以確認 自己可以接受 S 發 送的報文段第三次握手： S 可以確認 C 收到了自己發送的報文段。
參考回答：
( 1) TCP 是面向連接的， udp 是無連接的即發送數據前不需要先建立鏈接。
( 2) TCP 提供可靠的服務 。也就是說， 通過 TCP 連接傳送的數據， 無差錯， 不丟失， 不重復， 且按序到達;UDP 盡最大努力交付， 即不保證可靠交付 。 并且因為 tcp 可靠， 面向連接， 不會丟失數據因此適合大數據量的交換。
( 3) TCP 是面向字節流，UDP 面向報文，并且網絡出現擁塞不會使得發送速率降低 (因 此會出現丟包， 對實時的應用比如 IP 電話和視頻會議等) 。
( 4) TCP 只能是 1 對 1 的， UDP 支持 1 對 1,1 對多。
( 5) TCP 的首部較大為 20 字節， 而 UDP 只有 8 字節。
( 6) TCP 是面向連接的可靠性傳輸， 而 UDP 是不可靠的。
參考回答：
(1)什么是 WebSocket?
WebSocket 是 HTML5 中的協議， 支持持久連續， http 協議不支持持久性連接 。Http1.0 和 HTTP1.1 都不支持持久性的鏈接， HTTP1.1 中的 keep-alive， 將多個 http 請求合并為 1 個
(2)WebSocket 是什么樣的協議， 具體有什么優點？
HTTP 的生命周期通過 Request 來界定， 也就是 Request 一個 Response， 那么在 Http1.0 協議中， 這次 Http 請求就結束了 。在 Http1.1 中進行了改進， 是的有一個 connection： Keep-alive，也就是說，在一個 Http 連接中，可以發送多個 Request，接收多個 Response。 但是必須記住， 在 Http 中一個 Request 只能對應有一個 Response， 而且這個 Response 是被動的， 不能主動發起。
WebSocket 是基于 Http 協議的，或者說借用了 Http 協議來完成一部分握手，在握手階段 與 Http 是相同的。我們來看一個 websocket 握手協議的實現，基本是 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告訴服務器發送的是websocket
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13參考回答：
head： 類似于 get 請求， 只不過返回的響應中沒有具體的內容， 用戶獲取報頭 options： 允許客戶端查看服務器的性能， 比如說服務器支持的請求方式等等。
參考回答：
請求的返回頭里面， 用于瀏覽器解析的重要參數就是 OSS 的 API 文檔里面的返回http 頭， 決定用戶下載行為的參數。
下載的情況下：
x-oss-object-type: Normal
x-oss-request-id: 598D5ED34F29D01FE2925F41
x-oss-storage-class: Standard參考回答：
能夠被殘障人士使用的網站才能稱得上一個易用的 (易訪問的) 網站。 殘障人士指的是那些帶有殘疾或者身體不健康的用戶。
使用 alt 屬性：
<img src="person.jpg" alt="this is a person"/>有時候瀏覽器會無法顯示圖像 。具體的原因有：
用戶關閉了圖像顯示
瀏覽器是不支持圖形顯示的迷你瀏覽器
瀏覽器是語音瀏覽器 (供盲人和弱視人群使用)
如果您使用了alt 屬性， 那么瀏覽器至少可以顯示或讀出有關圖像的描述。
參考回答：
什么是 Bom? Bom 是瀏覽器對象 。有哪些常用的 Bom 屬性呢？
(1)location 對象
location.href-- 返回或設置當前文檔的 URL
location.search -- 返回 URL 中的查詢字符串部分 。 例
如 http://www.dreamdu.com/dreamdu.php?id=5&name=dreamdu 返回包括(?)后面的內 容?id=5&name=dreamdu
location.hash -- 返回 URL#后面的內容， 如果沒有#， 返回空
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 中的協議部分。例如 http://www.dreamdu.com:8080/xhtml/ 返 回(//)前面的內容 http:
location.assign -- 設置當前文檔的 URL
location.replace() -- 設置當前文檔的 URL， 并且在 history 對象的地址列表中移除這個 URL location.replace(url);
location.reload() -- 重載當前頁面
(2)history 對象
history.go() -- 前進或后退指定的頁面數 history.go(num);
history.back() -- 后退一頁
history.forward() -- 前進一頁
(3)Navigator 對象
navigator.userAgent -- 返回用戶代理頭的字符串表示(就是包括瀏覽器版本信息等的字 符串)。
navigator.cookieEnabled -- 返回瀏覽器是否支持(啟用)cookie。
參考回答：
dragstart： 事件主體是被拖放元素， 在開始拖放被拖放元素時觸發， 。
darg： 事件主體是被拖放元素， 在正在拖放被拖放元素時觸發。
dragenter： 事件主體是目標元素， 在被拖放元素進入某元素時觸發。
dragover： 事件主體是目標元素， 在被拖放在某元素內移動時觸發。
dragleave： 事件主體是目標元素， 在被拖放元素移出目標元素是觸發。
drop： 事件主體是目標元素， 在目標元素完全接受被拖放元素時觸發。
dragend： 事件主體是被拖放元素， 在整個拖放操作結束時觸發。
參考回答：
首先補充一下， http 和 https 的區別， 相比于 http,https 是基于 ssl 加密的 http 協議
簡要概括： http2.0 是基于 1999 年發布的 http1.0 之后的首次更新。
提升訪問速度 (可以對于， 請求資源所需時間更少， 訪問速度更快， 相比 http1.0)
允許多路復用：多路復用允許同時通過單一的 HTTP/2 連接發送多重請求-響應信息。改 善了： 在 http1.1 中， 瀏覽器客戶端在同一時間， 針對同一域名下的請求有一定數量限 制 (連接數量) ， 超過限制會被阻塞。
二進制分幀：HTTP2.0 會將所有的傳輸信息分割為更小的信息或者幀，并對他們進行二 進制編碼、首部壓縮、服務器端推送。
參考回答：
(1)400 狀態碼： 請求無效
產生原因：
前端提交數據的字段名稱和字段類型與后臺的實體沒有保持一致。
前端提交到后臺的數據應該是 json 字符串類型， 但是前端沒有將對象 JSON.stringify 轉化成字符串。
解決方法：
對照字段的名稱， 保持一致性，將 obj 對象通過 JSON.stringify 實現序列化。
(2)401 狀態碼： 當前請求需要用戶驗證
(3)403 狀態碼： 服務器已經得到請求， 但是拒絕執行
參考回答：
fetch 發送 post 請求的時候， 總是發送 2 次， 第一次狀態碼是 204， 第二次才成功？
原因很簡單， 因為你用 fetch 的 post 請求的時候， 導致 fetch 第一次發送了一個 Options 請求，詢問服務器是否支持修改的請求頭，如果服務器支持，則在第二次中發送真正的 請求。
參考回答：
在 HTML 頁面中，如果在執行腳本時，頁面的狀態是不可相應的，直到腳本執行完成后， 頁面才變成可相應 。web worker 是運行在后臺的 js， 獨立于其他腳本， 不會影響頁面你 的性能 。并且通過 postMessage 將結果回傳到主線程 。這樣在進行復雜操作的時候， 就 不會阻塞主線程了。
如何創建 web worker：
檢測瀏覽器對于 web worker 的支持性
創建 web worker 文件 (js， 回傳函數等)
創建 web worker 對象
參考回答：
HTML5 語義化標簽是指正確的標簽包含了正確的內容，結構良好，便于閱讀， 比如nav 表示導航條， 類似的還有 article 、header 、footer 等等標簽。
參考回答：
定義： iframe 元素會創建包含另一個文檔的內聯框架
提示： 可以將提示文字放在<iframe></iframe>之間， 來提示某些不支持 iframe 的瀏覽器 缺點： 會阻塞主頁面的 onload 事件 搜索引擎無法解讀這種頁面， 不利于 SEO iframe 和主頁面共享連接池， 而瀏覽器對相同區域有限制所以會影響性能。
參考回答：
Doctype 聲明于文檔最前面， 告訴瀏覽器以何種方式來渲染頁面， 這里有兩種模式， 嚴 格模式和混雜模式。
嚴格模式的排版和 JS 運作模式是 以該瀏覽器支持的最高標準運行。
混雜模式， 向后兼容， 模擬老式瀏覽器， 防止瀏覽器無法兼容頁面。
參考回答：
XSS (跨站腳本攻擊) 是指攻擊者在返回的 HTML 中嵌入 javascript 腳本，為了減輕這些 攻擊， 需要在 HTTP 頭部配上， set-cookie：
httponly-這個屬性可以防止 XSS,它會禁止 javascript 腳本來訪問 cookie。
secure - 這個屬性告訴瀏覽器僅在請求為 https 的時候發送 cookie。
結果應該是這樣的： Set-Cookie=<cookie-value>.....
參考回答：
就是用URL 定位資源， 用 HTTP 描述操作。
參考回答：
可以參考這篇文章：
響應式布局的常用解決方案對比(媒體查詢、百分比、rem 和 vw/vh)
參考回答：
(1)粗暴型， 禁用縮放
<meta name="viewport" content="width=device-width, user-scalable=no">(2)利用 FastClick， 其原理是：
檢測到 touchend 事件后， 立刻出發模擬 click 事件， 并且把瀏覽器 300 毫秒之后真正出 發的事件給阻斷掉。
參考回答：
addEventListener(event, function, useCapture)其中， event 指定事件名； function 指定要事件觸發時執行的函數； useCapture 指定事件 是否在捕獲或冒泡階段執行。
參考回答：
100 Continue 繼續 。客戶端應繼續其請求。
101 Switching Protocols 切換協議。服務器根據客戶端的請求切換協議。只能切換到更 高級的協議， 例如， 切換到HTTP 的新版本協議。
200 OK 請求成功 。一般用于 GET 與 POST 請求。
201 Created 已創建 。成功請求并創建了新的資源。
202 Accepted 已接受 。 已經接受請求， 但未處理完成。
203 Non-Authoritative Information 非授權信息。請求成功。但返回的 meta 信息不在原 始的服務器， 而是一個副本。
204 No Content 無內容 。服務器成功處理， 但未返回內容 。在未更新網頁的情況下， 可確保瀏覽器繼續顯示當前文檔。
205 Reset Content 重置內容。服務器處理成功， 用戶終端 (例如： 瀏覽器) 應重置文 檔視圖 。可通過此返回碼清除瀏覽器的表單域。
206 Partial Content 部分內容 。服務器成功處理了部分 GET 請求。
300 Multiple Choices 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特 征與地址的列表用于用戶終端 (例如： 瀏覽器) 選擇。
301 Moved Permanently 永久移動。請求的資源已被永久的移動到新 URI，返回信息會 包括新的 URI，瀏覽器會自動定向到新 URI。今后任何新的請求都應使用新的 URI 代替。
302 Found 臨時移動。與 301 類似。但資源只是臨時被移動。客戶端應繼續使用原有 URI。
303 See Other 查看其它地址 。與 301 類似 。使用 GET 和 POST 請求查看。
304 Not Modified 未修改 。所請求的資源未修改， 服務器返回此狀態碼時， 不會返回 任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返 回在指定日期之后修改的資源。
305 Use Proxy 使用代理 。所請求的資源必須通過代理訪問。
306 Unused 已經被廢棄的 HTTP 狀態碼。
307 Temporary Redirect 臨時重定向 。與 302 類似 。使用 GET 請求重定向。
400 Bad Request 客戶端請求的語法錯誤， 服務器無法理解。
401 Unauthorized 請求要求用戶的身份認證。
402 Payment Required 保留， 將來使用。
403 Forbidden 服務器理解請求客戶端的請求， 但是拒絕執行此請求。
404 Not Found 服務器無法根據客戶端的請求找到資源 (網頁) 。通過此代碼， 網站 設計人員可設置"您所請求的資源無法找到"的個性頁面。
405 Method Not Allowed 客戶端請求中的方法被禁止。
406 Not Acceptable 服務器無法根據客戶端請求的內容特性完成請求。
407 Proxy Authentication Required 請求要求代理的身份認證， 與 401 類似， 但請求者 應當使用代理進行授權。
408 Request Time-out 服務器等待客戶端發送的請求時間過長， 超時。
409 Conflict 服務器完成客戶端的 PUT 請求是可能返回此代碼，服務器處理請求時發 生了沖突。
410 Gone 客戶端請求的資源已經不存在。410 不同于 404，如果資源以前有現在被永 久刪除了可使用410 代碼， 網站設計人員可通過 301 代碼指定資源的新位置。
411 Length Required 服務器無法處理客戶端發送的不帶 Content-Length 的請求信息。
412 Precondition Failed 客戶端請求信息的先決條件錯誤。
413 Request Entity Too Large 由于請求的實體過大，服務器無法處理， 因此拒絕請求。 為防止客戶端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則 會包含一個 Retry-After 的響應信息。
414 Request-URI Too Large 請求的 URI 過長 ( URI 通常為網址) ， 服務器無法處理。
415 Unsupported Media Type 服務器無法處理請求附帶的媒體格式。
416 Requested range not satisfiable 客戶端請求的范圍無效。
417 Expectation Failed 服務器無法滿足 Expect 的請求頭信息。
500 Internal Server Error 服務器內部錯誤， 無法完成請求。
501 Not Implemented 服務器不支持請求的功能， 無法完成請求。
502 Bad Gateway 作為網關或者代理工作的服務器嘗試執行請求時， 從遠程服務器接 收到了一個無效的響應。
503 Service Unavailable 由于超載或系統維護，服務器暫時的無法處理客戶端的請求。 延時的長度可包含在服務器的 Retry-After 頭信息中。
504 Gateway Time-out 充當網關或代理的服務器， 未及時從遠端服務器獲取請求。
505 HTTP Version not supported 服務器不支持請求的 HTTP 協議的版本， 無法完成處 理。
參考回答：
協議頭 | 說明 |
Accept | 可接受的響應內容類型 (Content-Types) 。 |
Accept-Charset | 可接受的字符集。 |
Accept-Encoding | 可接受的響應內容的編碼方式。 |
Accept-Language | 可接受的響應內容語言列表。 |
Accept-Datetime | 可接受的按照時間來表示的響應內容版本。 |
Authorization | 用于表示 HTTP 協議中需要認證資源的認證信息。 |
Cache-Control | 用來指定當前的請求/回復中的， 是否使用緩存機制。 |
Connection | 客戶端 (瀏覽器) 想要優先使用的連接類型。 |
Cookie | 由之前服務器通過 Set-Cookie(見下文)設置的一個 HTTP 協議 Cookie。 |
Content-Length | 以 8 進制表示的請求體的長度。 |
Content-MD5 | 請求體的內容的二進制 MD5 散列值 (數字簽名) ， 以 Base64 編碼的結果。 |
Content-Type | 請求體的 MIME 類型 (用于 POST 和 PUT 請求中)。 |
Date | 發送該消息的日期和時間 (以RFC 7231中定義的"HTTP 日期"格式 來發送)。 |
Expect | 表示客戶端要求服務器做出特定的行為。 |
From | 發起此請求的用戶的郵件地址。 |
Host | 表示服務器的域名以及服務器所監聽的端口號 。如果所請求的端口 是對應的服務的標準端口 ( 80) ， 則端口號可以省略。 |
If-Match | 僅當客戶端提供的實體與服務器上對應的實體相匹配時， 才進行對應的操作 。主要用于像 PUT 這樣的方法中， 僅當從用戶上次更新 某個資源后， 該資源未被修改的情況下， 才更新該資源。 |
If-Modified-Since | 允許在對應的資源未被修改的情況下返回304 未修改 |
If-None-Match | 允許在對應的內容未被修改的情況下返回304 未修改 ( 304 Not Modified ) ， 參考 超文本傳輸協議 的實體標記 |
If-Range | 如果該實體未被修改過， 則向返回所缺少的那一個或多個部分 。否 則， 返回整個新的實體。 |
If-Unmodified-Since | 僅當該實體自某個特定時間以來未被修改的情況下， 才發送回應。 |
Max-Forwards | 限制該消息可被代理及網關轉發的次數。 |
Origin | 發起一個針對跨域資源共享的請求 (該請求要求服務器在響應中加入一個 Access-Control-Allow-Origin 的消息頭，表示訪問控制所允許 的來源) 。 |
Pragma | 與具體的實現相關， 這些字段可能在請求/回應鏈中的任何時候產 生。 |
Proxy-Authorization | 用于向代理進行認證的認證信息。 |
Range | 表示請求某個實體的一部分， 字節偏移以 0 開始。 |
Referer | 表示瀏覽器所訪問的前一個頁面， 可以認為是之前訪問頁面的鏈接將瀏覽器帶到了當前頁面。Referer 其實是 Referrer 這個單詞，但 RFC 制作標準時給拼錯了， 后來也就將錯就錯使用 Referer 了。 |
TE | 瀏覽器預期接受的傳輸時的編碼方式： 可使用回應協議頭 Transfer-Encoding 中的值 (還可以使用"trailers"表示數據傳輸時的分 塊方式) 用來表示瀏覽器希望在最后一個大小為 0 的塊之后還接收到一些額外的字段。 |
User-Agent | 瀏覽器的身份標識字符串。 |
Upgrade | 要求服務器升級到一個高版本協議。 |
Via | 告訴服務器， 這個請求是由哪些代理發出的。 |
Warning | 一個一般性的警告， 表示在實體內容體中可能存在錯誤。 |
參考回答：
緩存分為兩種： 強緩存和協商緩存， 根據響應的header 內容來決定。
獲取資源形式 | 狀態碼 | 發送請求到服務器 | |
強緩存 | 從緩存取 | 200 (from cache) | 否， 直接從緩存取 |
協商緩存 | 從緩存取 | 304 (not modified) | 是，通過服務器來告知緩存是否可 用 |
強緩存相關字段有 expires， cache-control 。如果 cache-control 與 expires 同時存在的話， cache-control 的優先級高于 expires。
協商緩存相關字段有 Last-Modified/If-Modified-Since， Etag/If-None-Match。
參考回答：
304：如果客戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的內容 (自 上次訪問以來或者根據請求的條件) 并沒有改變， 則服務器應當返回這個 304 狀態碼。
參考回答：
因為服務器上的資源不是一直固定不變的，大多數情況下它會更新，這個時候如果我們 還訪問本地緩存，那么對用戶來說，那就相當于資源沒有更新，用戶看到的還是舊的資 源；所以我們希望服務器上的資源更新了瀏覽器就請求新的資源，沒有更新就使用本地 的緩存， 以最大程度的減少因網絡請求而產生的資源浪費。
參考 https://segmentfault.com/a/1190000008956069
參考回答：
降低請求量： 合并資源， 減少 HTTP 請求數， minify / gzip 壓縮， webP， lazyLoad。
加快請求速度： 預解析 DNS， 減少域名數， 并行加載， CDN 分發。
緩存： HTTP 協議緩存請求， 離線緩存 manifest， 離線數據緩存 localStorage。
渲染： JS/CSS 優化， 加載順序， 服務端渲染， pipeline。
Nginx日志的重要性不言而喻，但也很容易被我們忽略。面對海量日志，很多時候我們無從下手，無奈望洋興嘆。對此我們引發思考：如何才高效分析Nginx日志，暴露“系統”乃至“業務”的問題，輔助開發和測試人員“定位”并“驗證”問題！ 本文將結合日常測試工作中對于accesslog的分析實踐，來詳細介紹日志分析工具 GoAccess，同時結合日常真實案例總結使用策略。
隨著產品日活體量的上漲，Nginx代理服務的日志體量也開始逐步增加，Nginx的日志分為訪問日志access_log和錯誤日志error_log兩大塊，訪問日志access_log主要記錄客戶端訪問nginx的每一個請求，格式可以自定義；錯誤日志error_log主要記錄客戶端訪問Nginx出錯時的日志，格式不支持自定義。前者主要記錄用戶每次訪問的情況，后者則側重于服務器的具體錯誤，比如返回403的具體原因是文件不可讀還是權限不足之類的。
通過錯誤日志，你可以得到系統某個服務或server的性能瓶頸等。而access_log卻百分百記錄了海量的用戶請求行為過程日志，包含更多的業務、語義、行為軌跡相關的信息，這部分的日志同樣具有價值，能夠輔助“分析爬蟲”、“評估客戶端請求合理性”、“分析接口流量”、“帶寬分布”、“分析客戶端請求來源特征”、“請求溯源分析”、“請求地理位置分析”，能夠為 “技術方案設計”乃“至業務方案設計” 提供更多的參考依據。因此，將日志好好利用，你可以得到很多有價值的信息。
awk是行處理器: 相比較屏幕處理的優點，在處理龐大文件時不會出現內存溢出或是處理緩慢的問題，通常用來格式化文本信息 awk處理過程: 依次對每一行進行處理，然后輸出。常用指令如下：
1）總請求數
wc -l access.log |awk '{print $1}'
2）獨立IP數
awk '{print $1}' access.log|sort |uniq |wc -l
3）每秒客戶端請求數 TOP5
awk '{print $6}' access.log|sort|uniq -c|sort -rn|head -5
4）訪問最頻繁IP Top5
awk '{print $1}' access.log|sort |uniq -c |sort -nr |head -5
5）訪問最頻繁的URL TOP5
awk '{print $7}' access.log|sort |uniq -c |sort -nr |head -5
6)響應大于5秒的URL TOP5
awk '{if ($7 > 5){print $6}}' access.log|sort|uniq -c|sort -rn |head -5
7)HTTP狀態碼(非200)統計 Top5
awk '{if ($11 != 200){print $11}}' access.log|sort|uniq -c|sort -rn|head -5
8)分析請求數大于50000的源IP
cat access.log|awk '{print $NF}'|sort |uniq -c |sort -nr|awk '{if ($1 >50000){print $2}}'request-log-analyzer這個工具是一個用ruby寫的gem包，它不僅能分析rails項目的訪問日志，還能分析nginx，apache，MySQL，PostgreSQL的日志，它能統計每個頁面的訪問次數，一天訪問的情況，還有來源分析等。
逐漸無人維護，功能陳舊，目前使用的人越來越少。
nginx_log_analysis是基于Ngx_Lua模塊開發，日志通過UDP協議網絡傳輸到InfluxDB數據庫，可以部署在Nginx和OpenResty上，它有如下的功能：
1、支持Nginx集群日志集中存儲
2、支持正則表達式的URI日志分析
3、支持upstream_time合并，可以正確統計到每條請求在后端的總時長
4、支持URI的 PV統計
5、支持URI平均響應時間計算，
6、支持URI P99,P90,P85的數據報表
7、數據存放InfluxDB，InfluxDB提供強大的函數查詢，可以支持URI各種數據的匯總和自定義分析
8、監控數據可以輕松接口MySQL，完成自定義的需求
9、可設置自定義變量存儲
系一整套日志計算、結果存儲的平臺方案，相對較重。 適用于大盤監控，用作日常分析工具相對較重。
可以從標準文件夾中讀取 Nginx 的日志文件（gzipped 的壓縮文件也可以），并進行分析統計，在控制臺中以可視化的表格形式展示，并且不會產生任何多余的臨時文件或數據。可以按照日期、響應值、請求來源等進行過濾匹配，并進行分析，Rhit 具有很高的效率，每秒可以處理百萬行日志數據。
高效、靈活
缺乏可視化交互，缺少對全體數據進行預處理。
GoAccess旨在成為一個基于終端的快速日志分析器，其核心思想是實時快速分析和查看Web服務器統計信息，GoAccess可分析Apache/Nginx等WEB日志，
1、支持命令行結果交互，同時還支持生成HTML、JSON、CSV等數據報告。
2、GoAccess允許任何自定義日志格式字符串。預定義選項包括Apache，Nginx，Amazon S3，Elastic Load Balancing，CloudFront等 跟蹤提供請求所需的時間。如果您想跟蹤減慢網站速度的網頁，則非常有用。
3、數據持久性強，GoAccess能夠通過磁盤上的B+ Tree數據庫逐步處理日志。
4、您可以針對訪問日志文件運行它，選擇日志格式并讓GoAccess解析訪問日志并顯示統計信息。按小時或日期確定最慢運行請求的匹配數，訪問者數，帶寬數和指標數。
GoAccess是一個開源的網絡日志分析器和交互式查看器，基于終端的日志分析工具。其核心理念是不需要通過 Web 瀏覽器就能快速分析并實時查看 Web 服務器的統計數據(這對于需要使用 SSH 來對訪問日志進行快速分析或者習慣在終端環境下工作的人來說是超贊的)。同時，GoAccess 還支持生成完整的實時 HTML 報告(這對分析、監控以及數據可視化都是極好的)，以及 JSON 和 CSV 格式的報告。
這個工具特別棒的地方在于它可以分析網絡服務器訪問日志，因此它是您可能獲得的關于您的訪問者的“最值得信賴”和“最接近現實”的數據。
頁面示意圖(該圖數據源于goaccess，官網示例demo)：
$ sudo apt install libncursesw5-dev libgeoip-dev libmaxminddb-dev$ wget https://tar.goaccess.io/goaccess-1.5.5.tar.gz
$ tar -xzvf goaccess-1.5.5.tar.gz
$ cd goaccess-1.5.5/
$ ./configure --enable-utf8 --enable-geoip=mmdb
$ make
# make install備注：一定要配置 UTF-8 支持和 GeoIP 功能，否則后續將無法使用地理位置分析功能。
$ goaccess --version
GoAccess - 1.5.5
For more details visit: http://goaccess.io
Copyright (C) 2009-2022 by Gerardo Orellana
Build configure arguments:
--enable-utf8
--enable-geoip=mmdb# log-format
log-format %h %^[%d:%t %^] "%r" %s %b "%R" "%^" "%v" %^ %T "%^"其中，log-format 與 access.log 的 log_format 格式對應，每個參數以空格或者制表符分割。參數說明如下：
%t 匹配time-format格式的時間字段
%d 匹配date-format格式的日期字段
%h host(客戶端ip地址，包括ipv4和ipv6)
%r 來自客戶端的請求行
%m 請求的方法
%U URL路徑
%H 請求協議
%s 服務器響應的狀態碼
%b 服務器返回的內容大小
%R HTTP請求頭的referer字段
%u 用戶代理的HTTP請求報頭
%D 請求所花費的時間，單位微秒
%T 請求所花費的時間，單位秒
%^ 忽略這一字段上述goaccess.conf對應的nginx格式
log_format '$clientip - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" "X" '
'"$host" "$cookie_usertrack" $upstream_response_time $request_time $upstream_addr $upstream_status "$http_user_agent" "$http_x_forwarded_for"';$ goaccess -h
# 常用參數
-a --agent-list 啟用由主機用戶代理的列表。為了更快的解析，不啟用該項
-d --with-output-resolver 在HTML/JSON輸出中開啟IP解析，會使用GeoIP來進行IP解析
-f --log-file 需要分析的日志文件路徑
-p --config-file 配置文件路徑
-o --output 輸出格式，支持html、json、csv
-m --with-mouse 控制面板支持鼠標點擊
-q --no-query-string 忽略請求的參數部分
--real-time-html 實時生成HTML報告
--daemonize 守護進程模式，--real-time-html時使用$ cd ~/yourpath/goaccess/goaccess-1.5.5/
$ goaccess -f /accesslogpath/*.* -p config/goaccess.conf -o /respath/reshtml/res-file-name.html$ goaccess -a -d -f /data/logs/access.log -p /etc/goaccess.conf
控制臺下的操作方法：
F1 主幫助頁面
F5 重繪主窗口
q 退出
1-15 跳轉到對應編號的模塊位置
o 打開當前模塊的詳細視圖
j 當前模塊向下滾動
k 當前模塊向上滾動
s 對模塊排序
/ 在所有模塊中搜索匹配
n 查找下一個出現的位置
g 移動到第一個模塊頂部
G 移動到最后一個模塊底部$ goaccess -a -d -f /data/logs/access.log -p /etc/goaccess.conf -o /data/html/go-access.html --real-time-html --daemonize# 監聽端口7890$ netstat -tunpl | grep "goaccess"tcp 0 0 0.0.0.0:7890 0.0.0.0:* LISTEN 21136/goaccess以守護進程啟動 GoAccess 后，使用 Websocket 建立長連接，它默認監聽 7890 端口，可以通過--port參數指定端口號。
如果被檢測站點啟用了 HTTPS，所以 GoAccess 也需要使用 openssl，在配置文件goaccess.conf中配置ssl-cert和ssl-key項，并確保在安裝過程中 configure 時已添加--with-openssl項來支持 openssl 。當使用 HTTPS 后 Websocket 通信時也應該使用 wss 協議，需要將ws-url項配置為wss://www.domain.com。
# 定時任務內容
0 0 1 * * goaccess -a -d -f /data/logs/access.log -p /etc/goaccess.conf -o /data/html/go-access.html 2> /data/logs/go-access.logHITS 維度的訪問數 VISITORS 維度的訪問數 流量總量數據 以及請求耗時相關數據（因為一般服務都有運維監控平臺，所以可以不關注）
每個URL 按HITS 維度的訪問數 每個URL 按VISITORS 維度的訪問數 每個URL 按流量消耗數據 每個URL 按請求耗時相關數據（因為我們有哨兵監控，所以可以不關注）
有助于業務溯源等角度進行分析（特別在站外投放的活動類的數據分析）
有助于業務溯源等角度進行分析（特別在站外投放的活動類的數據分析）
對比分析客戶端請求方式，發現并解決LOFTER-iOS端請求重復問題，節約服務端資源
異常爬蟲分析
其在請求 /login 接口時返回503，原因分析：部分海外IP觸發特定后端邏輯導致。
各維度采樣策略如下：
數據分析過程：使用goaccess 工具進行初步聚類處理，得到統計后的數據，使用全站請求數據（UNIQUE VISITORS PER DAY）和URL維度請求數據（REQUESTED FILES (URLS)） 分別統計全站請求。最終通過整體單接口平均響應體積瘦身情況，來有效評估網絡協議升級效果。
最后借用《大數據》作者 涂子沛 的一句話結束本文：誰能更好地抓住數據、理解數據、分析數據，誰就能在下一波的社會競爭中脫穎而出。
作者:孫喬
來源-微信公眾號:LOFTER技術團隊
出處:https://mp.weixin.qq.com/s/47HSFE9pKgrHyeO0d8CjmQ
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
