1.狀態(tài)碼：

2XX（成功處理了請(qǐng)求狀態(tài)）
      200 服務(wù)器已經(jīng)成功處理請(qǐng)求廉邑，并提供了請(qǐng)求的網(wǎng)頁
      201 用戶新建或修改數(shù)據(jù)成功
      202 一個(gè)請(qǐng)求已經(jīng)進(jìn)入后臺(tái)
      204 用戶刪除成功
  3XX（每次請(qǐng)求使用的重定向不要超過5次）
      304 網(wǎng)頁上次請(qǐng)求沒有更新，節(jié)省帶寬和開銷
  4XX（表示請(qǐng)求可能出錯(cuò)，妨礙了服務(wù)器的處理）
      400 服務(wù)器不理解請(qǐng)求的語法
      401 用戶沒有權(quán)限（用戶名诫给，密碼輸入錯(cuò)誤）
      403 用戶得到授權(quán)（401相反）彬呻，但是訪問被禁止
      404 服務(wù)器找不到請(qǐng)求的網(wǎng)頁，
  5XX（表示服務(wù)器在處理請(qǐng)求的時(shí)候發(fā)生內(nèi)部錯(cuò)誤）
      500 服務(wù)器遇到錯(cuò)誤楷扬，無法完成請(qǐng)求
      503 服務(wù)器目前無法使用（超載或停機(jī)維護(hù)）    

2. 304的緩存原理（添加Etag標(biāo)簽.last-modified） 304 網(wǎng)頁上次請(qǐng)求沒有更新钳吟，節(jié)省帶寬和開銷

1.服務(wù)器首先產(chǎn)生Etag,服務(wù)器可在稍后使用它來判斷頁面是否被修改。本質(zhì)上窘拯，客戶端通過該記號(hào)傳回服務(wù)器要求服務(wù)器驗(yàn)證（客戶端）緩存）
2.304是  HTTP的狀態(tài)碼红且，服務(wù)器用來標(biāo)識(shí)這個(gè)文件沒有被修改，不返回內(nèi)容涤姊，瀏覽器接受到這個(gè)狀態(tài)碼會(huì)去去找瀏覽器緩存的文件
3.流程：客戶端請(qǐng)求一個(gè)頁面A暇番。服務(wù)器返回頁面A，并在A上加一個(gè)Tage客服端渲染該頁面思喊，并把Tage也存儲(chǔ)在緩存中壁酬。客戶端再次請(qǐng)求頁面A
    并將上次請(qǐng)求的資源和ETage一起傳遞給服務(wù)器恨课。服務(wù)器檢查Tage.并且判斷出該頁面自上次客戶端請(qǐng)求之后未被修改舆乔。直接返回304

last-modified: 客服端請(qǐng)求資源，同時(shí)有一個(gè)last-modified的屬性標(biāo)記此文件在服務(wù)器最后修改的時(shí)間
        客服端第二次請(qǐng)求此url時(shí)剂公，根據(jù)http協(xié)議希俩。瀏覽器會(huì)向服務(wù)器發(fā)送一個(gè)If-Modified-Since報(bào)頭，
        詢問該事件之后文件是否被修改纲辽，沒修改返回304

 有了Last-Modified颜武，為什么還要用ETag？
  1拖吼、因?yàn)槿绻谝幻腌娭畠?nèi)對(duì)一個(gè)文件進(jìn)行兩次更改鳞上，Last-Modified就會(huì)不正確（Last—Modified不能識(shí)別秒單位的修改）
  2、某些服務(wù)器不能精確的得到文件的最后修改時(shí)間
  3吊档、一些文件也行會(huì)周期新的更改篙议，但是他的內(nèi)容并不改變（僅僅改變修改的事件），這個(gè)時(shí)候我們并不希望客戶端認(rèn)為文件被修改怠硼，而重新Get

ETag涡上，為什么還要用Last-Modified？
  1拒名、兩者互補(bǔ)吩愧，ETag的判斷的缺陷，比如一些圖片等靜態(tài)文件的修改
  2增显、如果每次掃描內(nèi)容都生成ETag比較雁佳，顯然要比直接比較修改時(shí)間慢的多脐帝。


ETag是被請(qǐng)求變量的實(shí)體值（文件的索引節(jié)，大小和最后修改的時(shí)間的Hash值）
  1糖权、ETag的值服務(wù)器端對(duì)文件的索引節(jié)堵腹，大小和最后的修改的事件進(jìn)行Hash后得到的。

3.get/post的區(qū)別

1.get數(shù)據(jù)是存放在url之后星澳，以疚顷？分割url和傳輸數(shù)據(jù)，參數(shù)之間以&相連禁偎； post方法是把提交的數(shù)據(jù)放在http包的Body中
2.get提交的數(shù)據(jù)大小有限制腿堤，（因?yàn)闉g覽器對(duì)url的長度有限制），post的方法提交的數(shù)據(jù)沒有限制
3.get需要request.queryString來獲取變量的值如暖，而post方式通過request.from來獲取變量的值
4.get的方法提交數(shù)據(jù)笆檀，會(huì)帶來安全問題，比如登錄一個(gè)頁面盒至，通過get的方式提交數(shù)據(jù)酗洒，用戶名和密碼就會(huì)出現(xiàn)在url上

4.http協(xié)議的理解

1.超文本的傳輸協(xié)議，是用于從萬維網(wǎng)服務(wù)器超文本傳輸?shù)奖镜刭Y源的傳輸協(xié)議
2.基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)（HTML枷遂，圖片資源）
3.基于運(yùn)用層的面向?qū)ο蟮膮f(xié)議樱衷，由于其簡潔、快速的方法酒唉、適用于分布式超媒體信息系統(tǒng)
4.http請(qǐng)求信息request：
    請(qǐng)求行（request line）箫老、請(qǐng)求頭部（header）,空行和請(qǐng)求數(shù)據(jù)四部分構(gòu)成

    請(qǐng)求行，用來說明請(qǐng)求類型,要訪問的資源以及所使用的HTTP版本.
    請(qǐng)求頭部黔州，用來說明服務(wù)器要使用的附加信息
    空行耍鬓，請(qǐng)求頭部后面的空行是必須的
    請(qǐng)求數(shù)據(jù)也叫主體，可以添加任意的其他數(shù)據(jù)流妻。
5.http相應(yīng)信息Response
    狀態(tài)行牲蜀、消息報(bào)頭、空行和響應(yīng)正文

    狀態(tài)行绅这，由HTTP協(xié)議版本號(hào)涣达， 狀態(tài)碼， 狀態(tài)消息 三部分組成
    消息報(bào)頭证薇，用來說明客戶端要使用的一些附加信息
    空行度苔，消息報(bào)頭后面的空行是必須的
    響應(yīng)正文，服務(wù)器返回給客戶端的文本信息浑度。

5.http和https

https：是以安全為目標(biāo)的HTTP通道寇窑，簡單講是HTTP的安全版本，通過SSL加密
http：超文本傳輸協(xié)議箩张。是一個(gè)客服端和服務(wù)器端請(qǐng)求和應(yīng)答的標(biāo)準(zhǔn)（tcp）,使瀏覽器更加高效甩骏，使網(wǎng)絡(luò)傳輸減少

6.http1.0 1.1 2.0的區(qū)別

長連接：HTTP1.0需要使用keep-alive參數(shù)來告知服務(wù)器建立一個(gè)長連接窗市，而HTP1.1默認(rèn)支持長連接
節(jié)約寬帶：HTTP1.1支持只發(fā)送一個(gè)header信息（不帶任何body信息）
host域（設(shè)置虛擬站點(diǎn)，也就是說饮笛，web server上的多個(gè)虛擬站點(diǎn)可以共享同一個(gè)ip端口）：HTTP1.0沒有host域

1.http2采用的二進(jìn)制文本傳輸數(shù)據(jù)咨察，而非http1文本格式，二進(jìn)制在協(xié)議的解析和擴(kuò)展更好
2.數(shù)據(jù)壓縮：對(duì)信息頭采用了HPACK進(jìn)行壓縮傳輸福青，節(jié)省了信息頭帶來的網(wǎng)絡(luò)流量
3.多路復(fù)用：一個(gè)連接可以并發(fā)處理多個(gè)請(qǐng)求
4.服務(wù)器推送：我們對(duì)支持HTTP2.0的web server請(qǐng)求數(shù)據(jù)的時(shí)候摄狱，服務(wù)器會(huì)順便把一些客戶端需要的資源一起推送到客戶端，免得客戶端再次創(chuàng)建連接發(fā)送請(qǐng)求到服務(wù)器端獲取无午。這種方式非常合適加載靜態(tài)資源

7.web緩存

1.web緩存就是存在于客戶端與服務(wù)器之間的一個(gè)副本媒役、當(dāng)你第一個(gè)發(fā)出請(qǐng)求后，緩存根據(jù)請(qǐng)求保存輸出內(nèi)容的副本
2.緩存的好處
    （1）減少不必要的請(qǐng)求
    （2）降低服務(wù)器的壓力指厌，減少服務(wù)器的消耗
    （3）降低網(wǎng)絡(luò)延遲刊愚，加快頁面打開速度（直接讀取瀏覽器的數(shù)據(jù)）

8.常見的web安全及防護(hù)原理

1.sql注入原理：通郭sql命令插入到web表單遞交或者輸入活命踊跟，達(dá)到欺騙服務(wù)器執(zhí)行的惡意sql命令
        防范：1.對(duì)用戶輸入進(jìn)行校驗(yàn)
             2.不適用動(dòng)態(tài)拼接sql
2.XSS（跨站腳本攻擊）：往web頁面插入惡意的html標(biāo)簽或者js代碼踩验。
                舉例子：在論壇放置一個(gè)看是安全的鏈接，竊取cookie中的用戶信息
            防范：1.盡量采用post而不使用get提交表單
                 2.避免cookie中泄漏用戶的隱式
3.CSRF(跨站請(qǐng)求偽裝）：通過偽裝來自受信任用戶的請(qǐng)求
            舉例子：黃軼老師的webapp音樂請(qǐng)求數(shù)據(jù)就是利用CSRF跨站請(qǐng)求偽裝來獲取QQ音樂的數(shù)據(jù)
            防范：在客服端頁面增加偽隨機(jī)數(shù)商玫，通過驗(yàn)證碼
XSS和CSRF的區(qū)別：
   1.XSS是獲取信息箕憾，不需要提前知道其他用戶頁面的代碼和數(shù)據(jù)包
   2.CSRF代替用戶完成指定的動(dòng)作，需要知道其他頁面的代碼和數(shù)據(jù)包

9.CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）

1.盡可能的避開互聯(lián)網(wǎng)有可能影響數(shù)據(jù)傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)拳昌。使內(nèi)容傳輸?shù)母旄€(wěn)定袭异。
2.關(guān)鍵技術(shù)：內(nèi)容存儲(chǔ)和分發(fā)技術(shù)中
3.基本原理：廣泛采用各種緩存服務(wù)器，將這些緩存服務(wù)器分布到用戶訪問相對(duì)的地區(qū)或者網(wǎng)絡(luò)中炬藤。當(dāng)用戶訪問網(wǎng)絡(luò)時(shí)利用全局負(fù)載技術(shù)
        將用戶的訪問指向距離最近的緩存服務(wù)器御铃，由緩存服務(wù)器直接相應(yīng)用戶的請(qǐng)求（全局負(fù)載技術(shù)）

10.瀏覽器渲染原理及流程 DOM -> CSSOM -> render -> layout -> print

流程：解析html以及構(gòu)建dom樹 -> 構(gòu)建render樹 ->  布局render樹 -> 繪制render樹
概念：1.構(gòu)建DOM樹： 渲染引擎解析HTML文檔，首先將標(biāo)簽轉(zhuǎn)換成DOM樹中的DOM node(包括js生成的標(biāo)簽)生成內(nèi)容樹
      2.構(gòu)建渲染樹： 解析對(duì)應(yīng)的css樣式文件信息（包括js生成的樣式和外部的css）
      3.布局渲染樹：從根節(jié)點(diǎn)遞歸調(diào)用沈矿，計(jì)算每一個(gè)元素的大小上真，位置等。給出每個(gè)節(jié)點(diǎn)所在的屏幕的精準(zhǔn)位置
      4.繪制渲染樹：遍歷渲染樹羹膳，使用UI后端層來繪制每一個(gè)節(jié)點(diǎn)

重繪：當(dāng)盒子的位置睡互、大小以及其他屬性，例如顏色陵像、字體大小等到確定下來之后就珠，瀏覽器便把這些顏色都按照各自的特性繪制一遍，將內(nèi)容呈現(xiàn)在頁面上
    觸發(fā)重繪的條件：改變?cè)赝庥^屬性醒颖。如：color妻怎，background-color等
    重繪是指一個(gè)元素外觀的改變所觸發(fā)的瀏覽器行為，瀏覽器會(huì)根據(jù)元素的新屬性重新繪制泞歉，使元素呈現(xiàn)新的外觀
注意：table及其內(nèi)部元素需要多次計(jì)算才能確定好其在渲染樹中節(jié)點(diǎn)的屬性值蹂季，比同等元素要多發(fā)時(shí)間冕广，要盡量避免使用table布局

重排（重構(gòu)/回流/reflow）： 當(dāng)渲染書中的一部分（或全部）因?yàn)樵氐囊?guī)模尺寸，布局偿洁，隱藏等改變而需要重新構(gòu)建撒汉，這就是回流。
    每個(gè)頁面都需要一次回流涕滋，就是頁面第一次渲染的時(shí)候

重排一定會(huì)影響重繪睬辐，但是重繪不一定會(huì)影響重排

11.為什么css放在頂部而js寫在后面

1.瀏覽器預(yù)先加載css后，可以不必等待HTML加載完畢就可以渲染頁面了
2.其實(shí)HTML渲染并不會(huì)等到完全加載完在渲染頁面宾肺，而是一邊解析DOM一邊渲染溯饵。
3.js寫在尾部，主要是因?yàn)閖s主要扮演事件處理的功能锨用，一方面很多操作是在頁面渲染后才執(zhí)行的丰刊。另一方面可以節(jié)省加載時(shí)間，使頁面能夠更加的加載增拥，提高用戶的良好體驗(yàn)

但是隨著JS技術(shù)的發(fā)展啄巧，JS也開始承擔(dān)頁面渲染的工作。比如我們的UI其實(shí)可以分被對(duì)待掌栅，把渲染頁面的js放在前面秩仆，時(shí)間處理的js放在后面

12.存儲(chǔ)方式與傳輸方式

1.indexBD: 是h5的本地存儲(chǔ)庫，把一些數(shù)據(jù)存儲(chǔ)到瀏覽器中猾封，沒網(wǎng)絡(luò)澄耍，瀏覽器可以從這里讀取數(shù)據(jù)，離線運(yùn)用晌缘。5m
2.Cookie: 通過瀏覽器記錄信息確認(rèn)用戶身份齐莲，最大4kb,這也就限制了傳輸?shù)臄?shù)據(jù)，請(qǐng)求的性能會(huì)受到影響
3.Session: 服務(wù)器端使用的一種記錄客戶狀態(tài)的機(jī)制（session_id存在set_cookie發(fā)送到客服端磷箕，保存為cookie）
4.localStroage: h5的本地存儲(chǔ)选酗，數(shù)據(jù)永久保存在客服端

13.token、cookie搀捷、session三者的理解

1星掰、token就是令牌，比如你授權(quán)(登錄)一個(gè)程序時(shí),他就是個(gè)依據(jù),判斷你是否已經(jīng)授權(quán)該軟件（最好的身份認(rèn)證嫩舟，安全性好氢烘，且是唯一的）
    用戶身份的驗(yàn)證方式    

2、cookie是寫在客戶端一個(gè)txt文件家厌，里面包括登錄信息之類的播玖，這樣你下次在登錄某個(gè)網(wǎng)站，就會(huì)自動(dòng)調(diào)用cookie自動(dòng)登錄用戶名
    服務(wù)器生成饭于，發(fā)送到瀏覽器蜀踏、瀏覽器保存维蒙，下次請(qǐng)求再次發(fā)送給服務(wù)器（存放著登錄信息）

3、session是一類用來客戶端和服務(wù)器之間保存狀態(tài)的解決方案果覆，會(huì)話完成被銷毀（代表的就是服務(wù)器和客戶端的一次會(huì)話過程）
    cookie中存放著sessionID颅痊，請(qǐng)求會(huì)發(fā)送這個(gè)id。sesion因?yàn)閞equest對(duì)象而產(chǎn)生局待。

14.說下cookie斑响，sessionStorage，localStorage

• 1钳榨、cookie舰罚，sessionStorage，localStorage是存放在客戶端薛耻，session對(duì)象數(shù)據(jù)是存放在服務(wù)器上 實(shí)際上瀏覽器和服務(wù)器之間僅需傳遞session id即可营罢，服務(wù)器根據(jù)session-id找到對(duì)應(yīng)的用戶session對(duì)象 session存儲(chǔ)數(shù)據(jù)更安全一些，一般存放用戶信息饼齿，瀏覽器只適合存儲(chǔ)一般的數(shù)據(jù)

• 2饲漾、cookie數(shù)據(jù)始終在同源的http請(qǐng)求中攜帶，在瀏覽器和服務(wù)器來回傳遞候醒，里面存放著session-id sessionStorage能颁，localStorage僅在本地保存

• 3杂瘸、大小限制區(qū)別倒淫，cookie數(shù)據(jù)不超過4kb，localStorage在谷歌瀏覽中2.6MB

• 4败玉、數(shù)據(jù)有效期不同敌土，cookie在設(shè)置的（服務(wù)器設(shè)置）有效期內(nèi)有效，不管窗口和瀏覽器關(guān)閉 sessionStorage僅在當(dāng)前瀏覽器窗口關(guān)閉前有效运翼，關(guān)閉即銷毀（臨時(shí)存儲(chǔ)） localStorage始終有效

SessionStorage和localStorage區(qū)別：

• 1.sessionStorage用于本地存儲(chǔ)一個(gè)會(huì)話（session）中的數(shù)據(jù)返干，這些數(shù)據(jù)只有在用一個(gè)會(huì)話的頁面中才能被訪問（也就是說在第一次通信過程中） 并且在會(huì)話結(jié)束后數(shù)據(jù)也隨之銷毀，不是一個(gè)持久的本地存儲(chǔ)血淌，會(huì)話級(jí)別的儲(chǔ)存

• 2.localStorage用于持久化的本地存儲(chǔ)矩欠，除非主動(dòng)刪除數(shù)據(jù)，否則不會(huì)過期

15.說下基于Token的身份驗(yàn)證：（最簡單的token: uid用戶唯一的身份識(shí)別 + time當(dāng)前事件戳 + sign簽名）

1悠夯、用戶通過用戶名和密碼發(fā)送請(qǐng)求
2癌淮、服務(wù)器端驗(yàn)證
3、服務(wù)器端返回一個(gè)帶簽名的token沦补，給客戶端
4乳蓄、客戶端儲(chǔ)存token，并且每次用于發(fā)送請(qǐng)求
5夕膀、服務(wù)器驗(yàn)證token并且返回?cái)?shù)據(jù)
每一次請(qǐng)求都需要token

16.Cookie的利弊有哪些虚倒？

優(yōu)勢：保存客戶端數(shù)據(jù)美侦，分擔(dān)了服務(wù)器存儲(chǔ)的負(fù)擔(dān)

缺點(diǎn)：1、數(shù)量和長度的限制魂奥。每個(gè)特定的域名下最多生成20個(gè)cookie（chorme和safari沒有限制）
2菠剩、安全性問題。

17耻煤。前端如何實(shí)現(xiàn)即時(shí)通訊赠叼？

1. 短輪詢

短輪詢的原理很簡單，每隔一段時(shí)間客戶端就發(fā)出一個(gè)請(qǐng)求违霞，去獲取服務(wù)器最新的數(shù)據(jù)嘴办，一定程度上模擬實(shí)現(xiàn)了即時(shí)通訊。

• 優(yōu)點(diǎn)：兼容性強(qiáng)买鸽，實(shí)現(xiàn)非常簡單
• 缺點(diǎn)：延遲性高涧郊，非常消耗請(qǐng)求資源，影響性能

2. comet

comet有兩種主要實(shí)現(xiàn)手段眼五，一種是基于 AJAX 的長輪詢（long-polling）方式妆艘，另一種是基于 Iframe 及 htmlfile 的流（streaming）方式，通常被叫做長連接看幼。

3. 長輪詢優(yōu)缺點(diǎn)：

• 優(yōu)點(diǎn)：兼容性好批旺，資源浪費(fèi)較小
• 缺點(diǎn)：服務(wù)器hold連接會(huì)消耗資源，返回?cái)?shù)據(jù)順序無保證诵姜，難于管理維護(hù)

4. 長連接優(yōu)缺點(diǎn)：

• 優(yōu)點(diǎn)：兼容性好汽煮，消息即時(shí)到達(dá)，不發(fā)無用請(qǐng)求
• 缺點(diǎn)：服務(wù)器維護(hù)長連接消耗資源

5. SSE（Server-Sent Event棚唆，服務(wù)端推送事件）是一種允許服務(wù)端向客戶端推送新數(shù)據(jù)的HTML5技術(shù)暇赤。

• 優(yōu)點(diǎn)：基于HTTP而生，因此不需要太多改造就能使用宵凌，使用方便鞋囊，而websocket非常復(fù)雜，必須借助成熟的庫或框架
• 缺點(diǎn)：基于文本傳輸效率沒有websocket高瞎惫，不是嚴(yán)格的雙向通信溜腐，客戶端向服務(wù)端發(fā)送請(qǐng)求無法復(fù)用之前的連接，需要重新發(fā)出獨(dú)立的請(qǐng)求

6. Websocket

Websocket是一個(gè)全新的瓜喇、獨(dú)立的協(xié)議挺益，基于TCP協(xié)議，與http協(xié)議兼容欠橘、卻不會(huì)融入http協(xié)議矩肩，僅僅作為html5的一部分，其作用就是在服務(wù)器和客戶端之間建立實(shí)時(shí)的雙向通信。

• 優(yōu)點(diǎn)：真正意義上的實(shí)時(shí)雙向通信黍檩，性能好叉袍，低延遲
• 缺點(diǎn)：獨(dú)立與http的協(xié)議，因此需要額外的項(xiàng)目改造刽酱，使用復(fù)雜度高喳逛，必須引入成熟的庫，無法兼容低版本瀏覽器

18.HTTP的緩存的過程是怎樣的棵里？

通常情況下的步驟是:

1. 客戶端向服務(wù)器發(fā)出請(qǐng)求润文，請(qǐng)求資源
2. 服務(wù)器返回資源，并通過響應(yīng)頭決定緩存策略
3. 客戶端根據(jù)響應(yīng)頭的策略決定是否緩存資源（這里假設(shè)是）殿怜，并將響應(yīng)頭與資源緩存下來
4. 在客戶端再次請(qǐng)求且命中資源的時(shí)候典蝌，此時(shí)客戶端去檢查上次緩存的緩存策略，根據(jù)策略的不同头谜、是否過期等判斷是直接讀取本地緩存還是與服務(wù)器協(xié)商緩存

19.同樣是重定向307骏掀，303，302的區(qū)別柱告？

302是http1.0的協(xié)議狀態(tài)碼截驮，在http1.1版本的時(shí)候?yàn)榱思?xì)化302狀態(tài)碼又出來了兩個(gè)303和307。

303明確表示客戶端應(yīng)當(dāng)采用get方法獲取資源际度，他會(huì)把POST請(qǐng)求變?yōu)镚ET請(qǐng)求進(jìn)行重定向葵袭。 307會(huì)遵照瀏覽器標(biāo)準(zhǔn)，不會(huì)從post變?yōu)間et乖菱。

20.HTTP的keep-alive是干什么的坡锡？

在早期的HTTP/1.0中，每次http請(qǐng)求都要?jiǎng)?chuàng)建一個(gè)連接块请，而創(chuàng)建連接的過程需要消耗資源和時(shí)間娜氏，為了減少資源消耗拳缠，縮短響應(yīng)時(shí)間墩新，就需要重用連接。在后來的HTTP/1.0中以及HTTP/1.1中窟坐，引入了重用連接的機(jī)制海渊，就是在http請(qǐng)求頭中加入Connection: keep-alive來告訴對(duì)方這個(gè)請(qǐng)求響應(yīng)完成后不要關(guān)閉，下一次咱們還用這個(gè)請(qǐng)求繼續(xù)交流哲鸳。協(xié)議規(guī)定HTTP/1.0如果想要保持長連接臣疑，需要在請(qǐng)求頭中加上Connection: keep-alive。

keep-alive的優(yōu)點(diǎn)：

• 較少的CPU和內(nèi)存的使用（由于同時(shí)打開的連接的減少了）
• 允許請(qǐng)求和應(yīng)答的HTTP管線化
• 降低擁塞控制 （TCP連接減少了）
• 減少了后續(xù)請(qǐng)求的延遲（無需再進(jìn)行握手）
• 報(bào)告錯(cuò)誤無需關(guān)閉TCP連

21.HTTPS是如何保證安全的徙菠？

過程比較復(fù)雜讯沈，我們得先理解兩個(gè)概念

對(duì)稱加密：即通信的雙方都使用同一個(gè)秘鑰進(jìn)行加解密，比如特務(wù)接頭的暗號(hào)婿奔，就屬于對(duì)稱加密

對(duì)稱加密雖然很簡單性能也好缺狠，但是無法解決首次把秘鑰發(fā)給對(duì)方的問題问慎，很容易被黑客攔截秘鑰。

非對(duì)稱加密：

1. 私鑰 + 公鑰= 密鑰對(duì)
2. 即用私鑰加密的數(shù)據(jù),只有對(duì)應(yīng)的公鑰才能解密,用公鑰加密的數(shù)據(jù),只有對(duì)應(yīng)的私鑰才能解密
3. 因?yàn)橥ㄐ烹p方的手里都有一套自己的密鑰對(duì),通信之前雙方會(huì)先把自己的公鑰都先發(fā)給對(duì)方
4. 然后對(duì)方再拿著這個(gè)公鑰來加密數(shù)據(jù)響應(yīng)給對(duì)方,等到到了對(duì)方那里,對(duì)方再用自己的私鑰進(jìn)行解密

非對(duì)稱加密雖然安全性更高挤茄，但是帶來的問題就是速度很慢如叼，影響性能。

解決方案：

那么結(jié)合兩種加密方式穷劈，將對(duì)稱加密的密鑰使用非對(duì)稱加密的公鑰進(jìn)行加密笼恰，然后發(fā)送出去，接收方使用私鑰進(jìn)行解密得到對(duì)稱加密的密鑰歇终，然后雙方可以使用對(duì)稱加密來進(jìn)行溝通社证。

此時(shí)又帶來一個(gè)問題，中間人問題：

如果此時(shí)在客戶端和服務(wù)器之間存在一個(gè)中間人,這個(gè)中間人只需要把原本雙方通信互發(fā)的公鑰,換成自己的公鑰,這樣中間人就可以輕松解密通信雙方所發(fā)送的所有數(shù)據(jù)评凝。

所以這個(gè)時(shí)候需要一個(gè)安全的第三方頒發(fā)證書（CA）猴仑，證明身份的身份，防止被中間人攻擊肥哎。

證書中包括：簽發(fā)者辽俗、證書用途、使用者公鑰篡诽、使用者私鑰崖飘、使用者的HASH算法、證書到期時(shí)間等