前端知識點(一)

一、請說說從用戶輸入url到呈現網頁，這中間都發生了什麼 ？

一、域名解析

   域名解析的過程：

　　  1）.查詢瀏覽器自身DNS緩存

        2）.若上面沒有查找到，則搜索操做系統自身的dns緩存

        3）.若上面沒有找到，則嘗試讀取hosts文件

        4）.若上面沒有找到，向本地配置的首選DNS服務器發送請求

        5）.win系統 若是上面沒有找到，操做系統查找NetBIOS name cache

        6）.win系統 若是上面沒有找到，查詢wins服務器

        7）.win系統 若是上面沒有找到，廣播查找

        8）.win系統 若是上面沒有找到，讀取LMHOSTS文件

    若以上多沒有找到，解析失敗

二、 TCP三次握手

 a. 爲何須要三次握手
    下面解釋明明兩次就能夠創建鏈接的爲何還要加第三次的確認。
    若是發送兩次就能夠創建鏈接話，那麼只要客戶端發送一個鏈接請求，服務端接收到併發送了確認，就會創建一個鏈接。 
    可能出現的問題：若是一個鏈接請求在網絡中跑的慢，超時了，這時客戶端會從發請求，可是這個跑的慢的請求最後仍是跑到了，而後服務端就接收了兩個鏈接請求，而後所有迴應就會建立兩個鏈接，浪費資源！
    若是加了第三次客戶端確認，客戶端在接受到一個服務端鏈接確認請求後，後面再接收到的鏈接確認請求就能夠拋棄無論了。


 b. 爲何須要四次分手
    TCP是雙向的，因此須要在兩個方向分別關閉，每一個方向的關閉又須要請求和確認，因此一共就4次。


三、瀏覽器向服務器發送http請求

一旦創建了TCP鏈接，Web瀏覽器就會向Web服務器發送請求命令。例如：GET/sample/hello.jsp HTTP/1.1。

四、瀏覽器發送請求頭信息

瀏覽器發送其請求命令以後，還要以頭信息的形式向Web服務器發送一些別的信息，以後瀏覽器發送了一空白行來通知服務器，它已經結束了該頭信息的發送。 

五、服務器處理請求

服務器軟件收到http請求，肯定執行什麼(ASP.net PHP RUBY JAVA等)來處理他。讀取參數並進行邏輯操做後，生成指定的數據。

六、服務器作出應答

客戶機向服務器發出請求後，服務器會客戶機回送應答，HTTP/1.1 200 OK ，應答的第一部分是協議的版本號和應答狀態嗎

七、服務器發送應答頭信息

正如客戶端會隨同請求發送關於自身的信息同樣，服務器也會隨同應答向用戶發送關於它本身的數據及被請求的文檔。 

八、服務器發送數據

Web服務器向瀏覽器發送頭信息後，它會發送一個空白行來表示頭信息的發送到此爲結束，接着，它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據。

九、tcp鏈接關閉

通常狀況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP鏈接，而後若是瀏覽器或者服務器在其頭信息加入了這行代碼：
Connection:keep-alive 
TCP鏈接在發送後將仍然保持打開狀態，因而，瀏覽器能夠繼續經過相同的鏈接發送請求。保持鏈接節省了爲每一個請求創建新鏈接所需的時間，還節約了網絡帶寬

二、請說說瀏覽器渲染頁面的過程 ？

分析：這道題的考察點重點在於瀏覽器渲染頁面的機制上面，只有充分理解渲染機制之後才能去更好的優化我們的頁面，好比css爲何放到head裏面，js爲何放到body後面，重繪重排概念

 參考回答: 瀏覽器渲染頁面是一個從上至下的過程，當拿到html之後首先會生成dom樹，加載解析css構建cssom樹，解析css的時候不會阻塞進程，咱們一般會把首屏樣式放到head裏面，而後加載執行js，在js裏面可能會有動態建立修改dom的邏輯，瀏覽器爲了優化整個渲染過程，會在解析到js的時候阻塞整個進程，咱們一般把js放到body後面來優化首屏的加載速度，當dom以及cssom都構建完成後會生成渲染樹，再根據渲染樹將dom樹上的節點佈局到屏幕上的正確位置，最後遍歷繪製的全部節點，爲其添加對應的樣式 

 延伸理解

重繪：改變dom的外觀屬性，如背景色，outline等 

重排:  改變dom的結構，幾何屬性等 

爲了減小瀏覽器的重排重繪，咱們應該將屢次改變樣式的操做合併成一次操做

三、說說http，https的區別，他們的優缺點是什麼？

超文本傳輸協議HTTP協議被用於在Web瀏覽器和網站服務器之間傳遞信息，HTTP協議以明文方式發送內容，不提供任何方式的數據加密，若是攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就能夠直接讀懂其中的信息，所以，HTTP協議不適合傳輸一些敏感信息，好比：信用卡號、密碼等支付信息。

爲了解決HTTP協議的這一缺陷，須要使用另外一種協議：安全套接字層超文本傳輸協議HTTPS，爲了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊加密。

1、HTTP和HTTPS的基本概念

HTTP：是互聯網上應用最爲普遍的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。

HTTPS：是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。

HTTPS協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。

2、HTTP與HTTPS有什麼區別？

HTTP協議傳輸的數據都是未加密的，也就是明文的，所以使用HTTP協議傳輸隱私信息很是不安全，爲了保證這些隱私數據能加密傳輸，因而網景公司設計了SSL（Secure Sockets Layer）協議用於對HTTP協議傳輸的數據進行加密，從而就誕生了HTTPS。

簡單來講，HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全。

HTTPS和HTTP的區別主要以下：

一、https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。

二、http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。

三、http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。

四、http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

3、HTTPS的工做原理

咱們都知道HTTPS可以加密信息，以避免敏感信息被第三方獲取，因此不少銀行網站或電子郵箱等等安全級別較高的服務都會採用HTTPS協議。

一、客戶端發起HTTPS請求

這個沒什麼好說的，就是用戶在瀏覽器裏輸入一個https網址，而後鏈接到server的443端口。

二、服務端的配置

採用HTTPS協議的服務器必需要有一套數字證書，能夠本身製做，也能夠向組織申請，區別就是本身頒發的證書須要客戶端驗證經過，才能夠繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。

這套證書其實就是一對公鑰和私鑰，若是對公鑰和私鑰不太理解，能夠想象成一把鑰匙和一個鎖頭，只是全世界只有你一我的有這把鑰匙，你能夠把鎖頭給別人，別人能夠用這個鎖把重要的東西鎖起來，而後發給你，由於只有你一我的有這把鑰匙，因此只有你才能看到被這把鎖鎖起來的東西。

三、傳送證書

這個證書其實就是公鑰，只是包含了不少信息，如證書的頒發機構，過時時間等等。

四、客戶端解析證書

這部分工做是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，好比頒發機構，過時時間等等，若是發現異常，則會彈出一個警告框，提示證書存在問題。

若是證書沒有問題，那麼就生成一個隨機值，而後用證書對該隨機值進行加密，就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，否則看不到被鎖住的內容。

五、傳送加密信息

這部分傳送的是用證書加密後的隨機值，目的就是讓服務端獲得這個隨機值，之後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密解密了。

六、服務段解密信息

服務端用私鑰解密後，獲得了客戶端傳過來的隨機值(私鑰)，而後把內容經過該值進行對稱加密，所謂對稱加密就是，將信息和私鑰經過某種算法混合在一塊兒，這樣除非知道私鑰，否則沒法獲取內容，而正好客戶端和服務端都知道這個私鑰，因此只要加密算法夠彪悍，私鑰夠複雜，數據就夠安全。

七、傳輸加密後的信息

這部分信息是服務段用私鑰加密後的信息，能夠在客戶端被還原。

八、客戶端解密信息

客戶端用以前生成的私鑰解密服務段傳過來的信息，因而獲取瞭解密後的內容，整個過程第三方即便監聽到了數據，也一籌莫展。

6、HTTPS的優勢

正是因爲HTTPS很是的安全，攻擊者沒法從中找到下手的地方，從站長的角度來講，HTTPS的優勢有如下2點：

一、SEO方面

谷歌曾在2014年8月份調整搜索引擎算法，並稱「比起同等HTTP網站，採用HTTPS加密的網站在搜索結果中的排名將會更高」。

二、安全性

儘管HTTPS並不是絕對安全，掌握根證書的機構、掌握加密算法的組織一樣能夠進行中間人形式的攻擊，但HTTPS還是現行架構下最安全的解決方案，主要有如下幾個好處：

（1）、使用HTTPS協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器；

（2）、HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程當中不被竊取、改變，確保數據的完整性。

（3）、HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增長了中間人攻擊的成本。

7、HTTPS的缺點

雖說HTTPS有很大的優點，但其相對來講，仍是有些不足之處的，具體來講，有如下2點：

一、SEO方面

據ACM CoNEXT數據顯示，使用HTTPS協議會使頁面的加載時間延長近50%，增長10%到20%的耗電，此外，HTTPS協議還會影響緩存，增長數據開銷和功耗，甚至已有安全措施也會受到影響也會所以而受到影響。

並且HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼做用。

最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家能夠控制CA根證書的狀況下，中間人攻擊同樣可行。

二、經濟方面

（1）、SSL證書須要錢，功能越強大的證書費用越高，我的網站、小網站沒有必要通常不會用。

（2）、SSL證書一般須要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展能夠部分解決這個問題，可是比較麻煩，並且要求瀏覽器、操做系統支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。

（3）、HTTPS鏈接緩存不如HTTP高效，大流量網站如非必要也不會採用，流量成本過高。

（4）、HTTPS鏈接服務器端資源佔用高不少，支持訪客稍多的網站須要投入更大的成本，若是所有采用HTTPS，基於大部分計算資源閒置的假設的VPS的平均成本會上去。

（5）、HTTPS協議握手階段比較費時，對網站的相應速度有負面影響，如非必要，沒有理由犧牲用戶體驗。

四、請說說js裏的this的指向

參考回答:
js中this的指向老是指向一個對象，而具體指向哪一個對象是在運行時基於函數的執行環境動態綁定的， 而非函數被聲明時的環境

具體到實際應用中，this 的指向大體能夠分爲如下幾種
* 做爲對象的方法調用指向當前對象
* 做爲普通函數調用指向全局window
* 構造函數調用指向返回的對象
* call,apply 調用指向其第一個參數

五、怎麼理解js中的原型鏈？如何實現繼承？

參考回答:

每一個構造函數都有一個原型對象
每一個原型對象都包含一個指向構造函數的指針
每一個實例都包含一個指向原型對象的指針
查找方式是一層層向上查找直至頂層Object.prototype

實現繼承的方式經常使用的有:

原型鏈繼承
借用構造函數(call,apply)
組合繼承(原型鏈＋構造函數)
原型式繼承
寄生式組合式繼承 

延伸理解:

優缺點?
每一種繼承的方式都有本身的優缺點
組合繼承的特色是會調用構造函數兩次,
都是將多種繼承方式組合到一塊兒相輔相成.

new 運算符具體幹了什麼?

建立一個空的對象
將空的對象的__proto__成員指向構造函數的prototype成員對象
調用構造函數將this指向前面建立的對象

六、Js中的內存泄露怎麼理解？

參考回答:
內存泄漏的定義爲當程序再也不須要的內存，因爲某種緣由其不會返回到操做系統或可用內存池，內存泄漏會致使一系列問題，好比: 運行緩慢，崩潰，高延遲等

js中常見的內存泄露:

意外的全局變量
遺忘的計時器或回調函數
脫離文檔的DOM引用
閉包

七、如何理解瀏覽器的跨域問題？經常使用的解決方式有哪些？

參考回答:

瀏覽器的同源策略會致使跨域，這裏同源策略又分爲如下兩種 ：

DOM同源策略：禁止對不一樣源頁面DOM進行操做。這裏主要場景是iframe跨域的狀況，不一樣域名的iframe是限制互相訪問的。

XmlHttpRequest同源策略：禁止使用XHR對象向不一樣源的服務器地址發起HTTP請求。只要協議、域名、端口有任何一個不一樣，都被看成是不一樣的域，之間的請求就是跨域操做

注：協議、域名、端口有任何一個不一樣，都視爲不一樣的域

經常使用的解決方式: 

1.CORS(Cross-origin resource sharing) 跨域資源共享  
注: 這種方式若是想要攜帶cookie須要xhr設置withCredentials爲true, 服務端 Access-Control-Allow-Credentials:true

2.jsonp實現跨域(動態建立script,利用src屬性進行跨域)

3.服務器代理(瀏覽器有跨域限制，服務端沒有)

4.document.domain

5.window.name

6.hash傳值 

7.possMessage

八、函數防抖，函數節流的基本概念以及工做中實際使用到的場景？實現的思路是？

函數防抖，函數節流的基本概念以及工做中實際使用到的場景？實現的思路是？

參考回答:

函數防抖(debounce)

基本概念: 在事件被觸發n秒後再執行回調，若是在這n秒內又被觸發，則從新計時。

舉例理解: 咱們用手指一直按住一個彈簧，它將不會立刻彈起直到你鬆手爲止

使用場景:

按鈕重複點擊
輸入框連續輸入
判斷scroll是否滑到底部

簡單實現:

const debounce = (fn,delay) => {
    let timer = null
    return () => {
        let ctx = this, args = arguments
        clearTimeout(timer)
        timer = setTimeout( ()=> {
          fn.apply(ctx,args)
        }, delay)
    }
}
函數節流(throttle)

基本概念: 在規定的時間範圍內相同的操做觸發屢次只執行一次

DOM拖拽
Canvas畫筆
窗口resize

簡單實現:

const throttle = (fn,gapTime = 100) => {
    let timer = null
    let start_time = new Date().getTime()
    return () => {
        let ctx = this, args = arguments,
        current_time = new Date().getTime()
        clearTimeout(timer)
        if(curr_time - start_time >= gapTime()){
          fn.apply(ctx,args)
          start_time = current_time
        }else{
          timer = setTimeout( ()=> {
          fn.apply(ctx,args)
          }, gapTime)
        }
    }
}

九、說說js中的eventloop機制？

參考回答:

首先javascript是單線程機制，就是指當咱們在執行一個任務的時候，其它的事情都得等待他執行完畢

在js中全部任務分爲兩種, 同步任務及異步任務

執行棧執行主線程任務，當有操做dom，ajax交互，使用定時器異步操做的時候，這些任務會被移入到 callback queue 任務隊列中 當主線程任務執行完畢爲空時，會讀取callback queue隊列中的函數，進入主線程執行 上述過程會不斷重複，也就是常說的Event Loop(事件循環)

在一個事件循環中,異步任務返回結果後會被扔進一個任務列隊中，根據異步事件上的類型，這個事件會被放到對應的宏任務或者微任務列隊中去， 當執行棧爲空的時候，主線程會先查看微任務中的事件列隊，若是微任務不是空先依次執行微任務，若是是空的再去宏任務列隊中取出一個事件並把對應的回調加入到當前執行棧，如此反覆，進入循環

下面用一道題來加深印象

setTimeout(function () {
    console.log(1);
});

new Promise( (resolve,reject) => {
    console.log(2)
}).then( (val) => {
    console.log(val);
})

輸出的結果是2,1

十、web安全攻擊手段有哪些？以及如何防範

常見的有xss, csrf, sql注入

xss(cross site scripting) 跨站腳本攻擊
定義: 指攻擊者在網頁嵌入腳本，用戶瀏覽網頁觸發惡意腳本執行

XSS攻擊分爲3類：存儲型（持久型）、反射型（非持久型）、基於DOM

如何防範:

設置HttpOnly以免cookie劫持的危險 
過濾，對諸如<script>、<img>、<a>等標籤進行過濾 
編碼，像一些常見的符號，如<>在輸入的時候要對其進行轉換編碼 
限制，對於一些能夠預期的輸入能夠經過限制長度強制截斷來進行防護

csrf(cross site request forgery) 跨站請求僞造
定義: 是一種劫持受信任用戶向服務器發送非預期請求的攻擊方式

如何防範:

驗證 HTTP Referer 字段

請求地址中添加 token 並驗證

HTTP 頭中自定義屬性並驗證

sql注入(SQL injection)
定義: 在未受權狀況下，非法訪問數據庫信息

如何防範:

杜絕用戶提交的參數入庫而且執行 
在代碼層，不許出現sql語句 
在web輸入參數處，對全部的參數作sql轉義 
上線測試，須要使用sql自動注入工具進行全部的頁面sql注入測試

十一、說說你對前端模塊化的理解。

模塊的定義:
能夠理解成實現特定功能的相互獨立的一組方法

爲何要使用模塊化:
可維護性

命名空間

可複用性

模塊化規範
CommonJS

AMD

UMD

CMD

Module(es6)

CommonJS
CommonJS 擴展了JavaScript聲明模塊的API,

經過CommonJS，每一個JS文件獨立地存儲它模塊的內容（就像一個被括起來的閉包同樣）。在這種做用域中，咱們經過 module.exports 語句來導出對象爲模塊，再經過 require 語句來引入

如：

function myModule() {
  this.hello = function() {
    return 'hello!';
  }
}
module.exports = myModule;
AMD （Asynchronous Module Definition）
特色: 
提倡依賴前置，在定義模塊的時候就要聲明其依賴的模塊

如：

require([module], callback);
CMD (Common Module Definition)
CMD規範是國內SeaJS的推廣過程當中產生的 
提倡就近依賴（按需加載），在用到某個模塊的時候再去require

define(function (require, exports, module) {
  var one = require('./one')
  one.do()
// 就近依賴，按需加載
  var  two = require('./two')
  two.do() 
})
UMD (Universal Module Definition)
AMD和CommonJS的結合,跨平臺的解決方案,UMD先判斷是否支持Node.js的模塊（exports）是否存在，存在則使用Node.js模塊模式。在判斷是否支持AMD（define是否存在），存在則使用AMD方式加載模塊

如：

(function (window, factory) {
    if (typeof exports === 'object') {
        module.exports = factory();
    } else if (typeof define === 'function' && define.amd) {
        define(factory);
    } else {
        window.eventUtil = factory();
    }
})(this, function () {
    //module ...
});
Module
原生ＪＳ(es6)解決方案

如:

 export default myModule
 import myModule from './myModule'

十二、Call，apply，bind的使用與區別，如何實現一個bind？

相同點:

都是使用於方法借用及明確this指向場景

第一個參數都是this要指向的對象

均可以利用後續參數傳參

不一樣點:

參數傳遞方式不一樣

call,apply是當即調用,bind是動態調用

基本使用:

Array.prototype.slice.call(obj,0,1,2)
Array.prototype.slice.apply(obj,[0,1,2])
Array.prototype.slice.bind(obj)(0,1,2)
從上面的例子能夠看出來call,apply 使用上幾乎保持一致，而bind其實是返回了一個函數

簡易bind實現

Function.prototype.bind = function(context){
    const _this = this
    return function() {
        _this.apply(context, Array.prototype.slice.call(arguments))
    }
}
上面的bind只實現了方法的做用域綁定，參數已經固定，若是想要動態的參數咱們得改寫一下

Function.prototype.bind = function(context){
    const _this = this
    const argus = Array.prototype.slice.apply(arguments,[1])
    return function() {
        _this.apply(context, argus.concat(Array.prototype.slice.call(arguments)))
    }
}

1三、前端的緩存有哪些？都適用什麼場景？區別是什麼？

參考回答
前端緩存分爲兩部分:

http 緩存

瀏覽器緩存

http 緩存
強緩存

強緩存主要是採用響應頭中的Cache-Control和Expires兩個字段進行控制的

Cache-Control 值理解:
max-age 指定設置緩存最大的有效時間(單位爲s) 
public 指定響應會被緩存，而且在多用戶間共享 
private 響應只做爲私有的緩存，不能在用戶間共享 
no-cache 指定不緩存響應，代表資源不進行緩存 
no-store 絕對禁止緩存

Expires 理解:
緩存過時時間，用來指定資源到期的時間，是服務器端的具體的時間點, 須要和Last-modified結合使用

Last-modified 理解
服務器端文件的最後修改時間，須要和cache-control共同使用，是檢查服務器端資源是否更新的一種方式

ETag 理解
根據實體內容生成一段hash字符串，標識資源的狀態，由服務端產生。瀏覽器會將這串字符串傳回服務器，驗證資源是否已經修改

協商緩存(304)

協商緩存是指當強緩存機制若是檢測到緩存失效，就須要進行服務器再驗證

瀏覽器緩存
Cookie

LocalStorage

SessionStorage

Service Worker

Cookie
Cookie主要用於用戶信息的存儲, 容量爲4KB

LocalStorage
LocalStorage的數據將一直保存在瀏覽器內，直到用戶清除瀏覽器緩存數據爲止, 容量爲5MB

SessionStorage
SessionStorage的其餘屬性同LocalStorage, 不一樣是的當頁面關閉時會隨之清除

Service Worker
主要是爲了提升web app的用戶體驗，能夠實現離線應用消息推送等等一系列的功能, 能夠看作是一個獨立於瀏覽器的Javascript代理腳本, 在離線狀態下也能提供基本的功能。 出於安全性的考慮，Service Worker 只能在https協議下使用分

1四、Http常見狀態碼及其含義?

http狀態碼分爲5個大類

1** 信息相關

2** 請求成功

3** 重定向相關

4** 客戶端錯誤相關，或沒法完成請求

5** 服務端錯誤相關


301—永久移動。被請求的資源已被永久移動位置；

302—請求的資源如今臨時從不一樣的 URI 響應請求；

305—使用代理。被請求的資源必須經過指定的代理才能被訪問；

307—臨時跳轉。被請求的資源在臨時從不一樣的URL響應請求；

400—錯誤請求；

402—須要付款。該狀態碼是爲了未來可能的需求而預留的，用於一些數字貨幣或者是微支付；

403—禁止訪問。服務器已經理解請求，可是拒絕執行它；

404—找不到對象。請求失敗，資源不存在；

406—不可接受的。請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體；

408—請求超時；

409—衝突。因爲和被請求的資源的當前狀態之間存在衝突，請求沒法完成；

410—遺失的。被請求的資源在服務器上已經再也不可用，並且沒有任何已知的轉發地址；

413—響應實體太大。服務器拒絕處理當前請求，請求超過服務器所能處理和容許的最大值。

417—指望失敗。在請求頭 Expect 中指定的預期內容沒法被服務器知足；

418—我是一個茶壺。超文本咖啡罐控制協議，可是並無被實際的HTTP服務器實現；

420—方法失效。

422—不可處理的實體。請求格式正確，可是因爲含有語義錯誤，沒法響應；

500—服務器內部錯誤。服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理

1五、前端優化手段有哪些？

前端優化手段有哪些？

靜態資源合併壓縮(js,css, images)

請求數量優化

Gzip壓縮

帶寬優化

CDN

就近節點，減小DNS查找

按需加載

lazyload

減小請求

骨架屏

優化白屏

web緩存

緩存ajax數據

減小重繪和重排

批量更新ＤＯＭ樣式

頁面結構

將樣式表放在頂部，將腳本放在底部，儘早刷新文檔的輸出