????傳送門????

寒冬期前端準(zhǔn)備總結(jié)---JS篇
寒冬期前端準(zhǔn)備總結(jié)---瀏覽器篇
[寒冬期前端準(zhǔn)備總結(jié)---服務(wù)器和網(wǎng)絡(luò)篇]
寒冬期前端準(zhǔn)備總結(jié)---CSS篇
寒冬期前端準(zhǔn)備總結(jié)---框架篇
寒冬期前端準(zhǔn)備總結(jié)---算法篇

• HTTP和HTTPS的區(qū)別

* HTPPS是在HTTP的基礎(chǔ)上加入了SSL協(xié)議，SSL依靠證書來驗(yàn)證服務(wù)器的身份蛔糯，并為客戶端和服務(wù)器之間的通信加密
* HTTPS協(xié)議需要到CA申請(qǐng)證書或者自制證書
* HTTP的信息是明文傳輸拯腮；HTTPS是具有安全性的ssl加密的
* HTTP是直接與TCP進(jìn)行數(shù)據(jù)傳輸；HTTPS和TCP之間多了一層SSL/TCS安全傳輸層
* HTTP的連接是無狀態(tài)的蚁飒，不會(huì)記錄下用戶請(qǐng)求的一些臨時(shí)數(shù)據(jù)动壤，類似于登錄狀態(tài)，（結(jié)合cookie實(shí)現(xiàn)HTTP的連接有狀態(tài)）

* HTTP無連接：每一次連接只能處理一個(gè)請(qǐng)求
* HTTP無狀態(tài)：對(duì)所有的請(qǐng)求都沒有記憶功能淮逻，后面的請(qǐng)求需要前面請(qǐng)求的數(shù)據(jù)時(shí)琼懊，就需要重新傳遞數(shù)據(jù)

* cookie是服務(wù)端生成保存在客戶端的蜒灰，4K，session是服務(wù)端保存的肩碟，數(shù)據(jù)量不宜過多

• 請(qǐng)求報(bào)文和響應(yīng)報(bào)文

請(qǐng)求報(bào)文
* 請(qǐng)求方法
* 請(qǐng)求URL
* http版本
* 請(qǐng)求頭
* 請(qǐng)求體
響應(yīng)報(bào)文
* 狀態(tài)碼
* 響應(yīng)頭
* 響應(yīng)體
* HTTP版本

• HTTP2與HTTP1.x對(duì)比

* HTTP2使用的是二進(jìn)制格式傳送尘颓；HTTP1.x是文本傳送朽寞，二進(jìn)制協(xié)議解析起來更高效
* HTTP2支持多路復(fù)用，同一域名下的請(qǐng)求共享一個(gè)TCP連接，HTTP1.x每一個(gè)請(qǐng)求會(huì)創(chuàng)建一個(gè)TCP連接遗嗽，且同一域名下的TCP連接數(shù)量有限
* HTTP2進(jìn)行頭部壓縮，減少傳輸大小以及避免重復(fù)header的傳輸
* HTTP2支持服務(wù)器推送

• TCP/UDP

* UDP連接不需要三次握手和四次揮手嘴拢，而且不會(huì)對(duì)數(shù)據(jù)報(bào)文進(jìn)行處理仗处，就直接傳遞出去了，這樣想傳輸就傳輸?shù)臄?shù)據(jù)不太安全吨拍，不過它支持一對(duì)多褪猛、多對(duì)多的傳輸方式
* TCP需要三次握手和四次揮手，接收確認(rèn)標(biāo)示和序列號(hào)這些信息保證數(shù)據(jù)的可靠性

• TCP三次握手

* 客戶端向服務(wù)端發(fā)送握手信號(hào)以及seq序列號(hào)
* 服務(wù)端接收到信號(hào)后羹饰，發(fā)送新的seq序列號(hào)和連接確認(rèn)號(hào)到客戶端
* 客戶端發(fā)送初始序列號(hào)+1和服務(wù)端確認(rèn)號(hào)+1伊滋，表明接收到服務(wù)端信號(hào)，TCP連接成功

• TCP四次揮手

* A發(fā)送給B一個(gè)釋放連接報(bào)文队秩，B收到后發(fā)送確認(rèn)笑旺，此時(shí)A不能向B發(fā)送，但是A會(huì)接受B的發(fā)送請(qǐng)求 半關(guān)閉狀態(tài)
* 之后B向A發(fā)送釋放連接報(bào)文馍资，A收到后發(fā)送確認(rèn)筒主，TCP連接完全斷開連接

• 緩存

緩存位置
* Service Worker：運(yùn)行在瀏覽器背后的獨(dú)立線程，通過請(qǐng)求攔截的方式查詢是否命中緩存鸟蟹，需要https協(xié)議來保障安全乌妙，是持續(xù)性緩存
* Memory Cache：瀏覽器內(nèi)存緩存，讀取高效建钥，但是緩存持續(xù)性很短藤韵，會(huì)隨進(jìn)程的釋放而釋放，例如關(guān)閉tab頁锦针，大文件不存
* Disk Cache：硬盤上的緩存荠察，相對(duì)于內(nèi)存緩存，優(yōu)勢(shì)在于容量和時(shí)效性
* Push Cache：推送緩存奈搜，HTTP2的內(nèi)容悉盆；只在會(huì)話中存在，會(huì)話結(jié)束被釋放馋吗，時(shí)效性短
    
強(qiáng)緩存和協(xié)商緩存
強(qiáng)緩存不會(huì)向服務(wù)器發(fā)送請(qǐng)求焕盟，不關(guān)心服務(wù)端的文件是否更新，直接從緩存中讀取資源，通過設(shè)置兩種Http Header實(shí)現(xiàn)強(qiáng)緩存：expires（響應(yīng)頭）和cache-control（通用頭）
* expires（V1.0）緩存過期時(shí)間脚翘，是服務(wù)器的時(shí)間節(jié)點(diǎn)灼卢，受限于本地時(shí)間
* cache-control（V1.1）控制網(wǎng)頁緩存：no-cache、max-age等
* cache-control的優(yōu)先級(jí)大于expires来农，expires用于兼容

協(xié)商緩存是強(qiáng)緩存失效后鞋真，瀏覽器攜帶緩存標(biāo)識(shí)向服務(wù)器發(fā)起請(qǐng)求，由服務(wù)器根據(jù)緩存標(biāo)識(shí)來決定是否使用緩存的過程沃于，通過設(shè)置兩種Http Header：last-modified（響應(yīng)頭）/ if-modified-since（請(qǐng)求頭） 和ETag（響應(yīng)頭）/if-none-match（請(qǐng)求頭）
* 協(xié)商緩存生效涩咖，返回304和Not modified；協(xié)商緩存失效繁莹，返回200和請(qǐng)求結(jié)果
* last-modified和if-modified-since通過判斷文件的最后修改日期檩互，以及是否修改標(biāo)識(shí)判斷
* ETag和if-none-match，其中ETag是由服務(wù)器生成的唯一符咨演，資源變化便重新生成ETag

* 強(qiáng)緩存（200）：第一次向服務(wù)器請(qǐng)求闸昨，直接下載請(qǐng)求數(shù)據(jù)，存到本地薄风，第二次請(qǐng)求時(shí)直接使用本地緩存
* 協(xié)商緩存（304）：第一次向服務(wù)器請(qǐng)求時(shí)饵较，保存緩存標(biāo)記和緩存時(shí)間，緩存到本地村刨，第二次請(qǐng)求時(shí)服務(wù)器判斷重新請(qǐng)求數(shù)據(jù)告抄，還是直接使用緩存

cache-control的值（響應(yīng)頭和請(qǐng)求頭都可以設(shè)置）
* private: 客戶端可以緩存（響應(yīng)頭）
* public: 客戶端和代理服務(wù)器都可緩存（響應(yīng)頭）
* max-age=xxx: 緩存的內(nèi)容將在 xxx 秒后失效
* no-cache: 需要使用對(duì)比緩存來驗(yàn)證緩存數(shù)據(jù)
* no-store: 所有內(nèi)容都不會(huì)緩存撰茎，強(qiáng)制緩存嵌牺，對(duì)比緩存都不會(huì)觸發(fā)

• HTTP的POST和GET

使用上區(qū)別
* GET是從服務(wù)器上獲取數(shù)據(jù)，POST是向服務(wù)器傳送數(shù)據(jù)
* GET是通過URL進(jìn)行傳輸（不安全）龄糊，POST是通過請(qǐng)求體傳輸數(shù)據(jù)（較安全）
* GET的傳輸數(shù)據(jù)量不能大于2K逆粹，POST的傳輸數(shù)據(jù)不限
* GET可以通過URL的歷史訪問、緩存可以查到數(shù)據(jù)炫惩，不安全

進(jìn)階
* 都是通過http協(xié)議請(qǐng)求僻弹，沒有差異
* get也可以發(fā)送請(qǐng)求體，只要服務(wù)端做處理
* url的傳輸限制長度只是瀏覽器的限制他嚷，跟請(qǐng)求無關(guān)

• HTTP的長連接和短連接（即TCP的長短連接）

* 短連接：客戶端和服務(wù)器每進(jìn)行一次HTTP操作蹋绽，就建立一個(gè)連接，但任務(wù)結(jié)束就會(huì)中斷連接
* 長連接：HTTP1.1 默認(rèn)長連接筋蓖。數(shù)據(jù)傳輸完成后保持TCP的連接卸耘，等待同域名下的請(qǐng)求繼續(xù)使用這個(gè)連接通道
  減少重連的耗時(shí)，服務(wù)器可以利用這個(gè)連接主動(dòng)推送消息到客戶端
  HTTP的頭部字段Connection：keep-alive顯示設(shè)置期望長連接

• options預(yù)請(qǐng)求

跨域請(qǐng)求時(shí)粘咖，瀏覽器自動(dòng)發(fā)起options請(qǐng)求蚣抗，用于判斷服務(wù)器是否支持此次跨域請(qǐng)求，會(huì)發(fā)送兩次請(qǐng)求

瀏覽器自動(dòng)觸發(fā)預(yù)請(qǐng)求的條件
* http的請(qǐng)求方法為：PUT/DELETE/PUTCH/CONNECT/OPTIONS/TRACE（非get/post）
* 人為設(shè)置請(qǐng)求頭部的字段：
           Accept/Accept-Language/Content-Type/Content-Language/DPR/Downlink/Save-Data/Viewport-Width/Width
* Content-Type的值為非以下屬性值：（例如application/json）
           application/x-www-form-urlencoded瓮下、multiple/form-data翰铡、text/plain

• 請(qǐng)求頭部屬性

Request Header和Response Header
通用
* Cache-Control：緩存機(jī)制和緩存類型
* Connection：是否保持長連接
* Transfer-Encoding：文件編碼
* content-type：實(shí)體報(bào)文的內(nèi)容類型
Request
* Accept：客戶端希望接受的響應(yīng)數(shù)據(jù)類型
* User-Agent：客戶端的信息
* Authorization：web認(rèn)證信息
Response
* Location：客戶端的重定向URI
* Server服務(wù)器信息
* Content-type：返回內(nèi)容的媒體類型

• Web攻擊

XSS:cross site script 跨站腳本攻擊钝域，往頁面插入惡意的腳本，document.cookie盜用cookie實(shí)現(xiàn)無密碼登錄
CSRF：cross site request forgery 跨站請(qǐng)求偽造锭魔，盜用用戶身份例证，發(fā)送惡意請(qǐng)求
   瀏覽器會(huì)自動(dòng)帶上cookie，但是不會(huì)帶上token迷捧，token為了防止CSRF

XSS
- DOM xss:使用DOM更換文檔內(nèi)容战虏，完全由客戶端進(jìn)行DOM解析
- 反射型 xss:非持久性，在客戶端發(fā)送請(qǐng)求時(shí)党涕，將代碼拼接在URL中烦感，提交到服務(wù)端，服務(wù)端返回?cái)y帶不安全腳本的響應(yīng)內(nèi)容膛堤，再由客戶端渲染
- 存儲(chǔ)型 xss:持久性手趣，代碼被提交后，被服務(wù)端接收并存儲(chǔ)肥荔，每次請(qǐng)求都會(huì)帶上腳本绿渣，每一次用戶訪問時(shí)都存在

?利用虛假輸入表單騙取用戶信息
?利用腳本竊取用戶的cookie，在用戶不知情的情況下燕耿，幫助攻擊者發(fā)送惡意請(qǐng)求
?頁面重定向

?httpOnly：服務(wù)端response設(shè)置header時(shí)cookie設(shè)置HttpOnly中符，保證無法通過js腳本拿到cookie信息
?用戶輸入內(nèi)容做校驗(yàn)，防止插入script腳本
?對(duì)于跳轉(zhuǎn)鏈接的url要校驗(yàn)內(nèi)容誉帅，禁止javascript鏈接
?不對(duì)內(nèi)容格式過濾時(shí)淀散，要對(duì)標(biāo)簽進(jìn)行轉(zhuǎn)義

CSRF
- 冒充用戶發(fā)起請(qǐng)求，在用戶不知情的情況下
?強(qiáng)制用戶交互蚜锨，比如驗(yàn)證碼档插，再完成用戶請(qǐng)求
?使用post方法發(fā)起請(qǐng)求，也是交互
?通過token進(jìn)行校驗(yàn)請(qǐng)求方是否合法

• Https 中間人攻擊過程

* 服務(wù)器向客戶端發(fā)送公鑰
* 攻擊者攔截公鑰
* 攻擊者生成偽造的公鑰發(fā)送給客戶端
* 客戶端收到偽造公鑰生成加密后的hash值
* 攻擊者獲得加密后的hash亚再，用自己的私鑰解密獲得真秘鑰
* 同時(shí)生成假的加密的hash郭膛，發(fā)送給服務(wù)端
* 服務(wù)器用私鑰解密獲得假秘鑰
* 服務(wù)器用假秘鑰加密傳輸數(shù)據(jù)
實(shí)際中，服務(wù)器向客戶端發(fā)送公鑰的時(shí)候加證書

• 前端加密的場(chǎng)景和方法

密碼傳輸：
* 前端使用Base64/Unicode等方式加密成非明文氛悬，后端解開存入MD5/MD6
* 前端使用MD5/MD6取得hash则剃，后端直接存hash的hash
展示成果加密
* 反爬蟲

• http狀態(tài)碼：服務(wù)器對(duì)請(qǐng)求的響應(yīng)狀態(tài)

* 1**：表示臨時(shí)響應(yīng)
* 2**：表示請(qǐng)求成功
* 3**：表示重定向
* 4**：表示客戶端錯(cuò)誤
* 5**：表示服務(wù)端錯(cuò)誤
* 200：成功
* 202：服務(wù)端接收請(qǐng)求，但并未響應(yīng)
* 204：服務(wù)端成功處理請(qǐng)求如捅，但不需要返回任何實(shí)體內(nèi)容
* 205：服務(wù)端成功處理請(qǐng)求棍现，但不需要返回任何實(shí)體內(nèi)容。不同于204伪朽，要求請(qǐng)求者重置文檔視圖
* 301：永久性重定向
* 302：臨時(shí)性重定向
* 304：瀏覽器的緩存數(shù)據(jù)依然有效（協(xié)商緩存）
* 400：客戶端請(qǐng)求有誤轴咱，無法被服務(wù)端理解
* 401：當(dāng)前請(qǐng)求需要用戶驗(yàn)證
* 403：服務(wù)器理解請(qǐng)求，通過身份驗(yàn)證，但是身份沒有權(quán)限朴肺，拒絕執(zhí)行請(qǐng)求
* 404：請(qǐng)求資源未找到
* 405：身份驗(yàn)證通過窖剑，http方法不在用戶權(quán)限內(nèi)
* 500：內(nèi)部服務(wù)器錯(cuò)誤
* 502：網(wǎng)關(guān)錯(cuò)誤
* 503：服務(wù)器過載，當(dāng)前無法處理請(qǐng)求

• restful 和 graphQL

* restful
  前后端接口定義的規(guī)范戈稿，通過API命名語義化
* graphQL
  前端想后端傳遞需要返回的數(shù)據(jù)結(jié)構(gòu)西土，偏查詢，減少數(shù)據(jù)冗余
- restful狀態(tài)碼
* GET:200 OK
* POST:201 Created
* PUT:200 OK
* PATCH:200 OK
* DELETE:204 No Content

• 請(qǐng)求冪等性（使用上鞍盗，非強(qiáng)制）

多次請(qǐng)求結(jié)果一致需了，無副作用
* get: 冪等
* post: 非冪等，新建資源
* put: 冪等般甲，更新資源肋乍，整體替換
* patch: 非冪等，局部更新敷存，請(qǐng)求一次修改一次
* delete: 冪等墓造，刪除資源

• 跨域

同源策略：協(xié)議+域名+端口號(hào)
* 利用script標(biāo)簽的跨域能力，發(fā)送get 請(qǐng)求锚烦，執(zhí)行請(qǐng)求回調(diào)
* jsonp請(qǐng)求觅闽，只能發(fā)送get請(qǐng)求，
* webSocket跨域 socket.io插件
* 設(shè)置網(wǎng)絡(luò)代理服務(wù)器
* CORS通過origin設(shè)置跨域資源共享
* iframe跨域
* postMessage方法：iframe.currentWindow.postMessage / window.parent.postMessage