websocket解決了什么問題
學(xué)習(xí)：https://www.cnblogs.com/unclekeith/p/8087182.html
服務(wù)器輪訓(xùn)的演變
ajax短輪詢，客戶端定時發(fā)送http請求去問詢服務(wù)端，不管服務(wù)端有沒有結(jié)果都會給客戶端進(jìn)行返回。通過http1.1長連接，進(jìn)行一次tcp連接可以發(fā)送多個http請求，一個request對一個reponse
ajax長輪詢，客戶端向服務(wù)端發(fā)出HTTP請求后，服務(wù)端保持連接，服務(wù)端有更新后則將結(jié)果返回給客戶端，當(dāng)連接超時后，服務(wù)端會給客戶端發(fā)送超時反饋，客戶端會向服務(wù)端重新發(fā)送HTTP請求。一個request對一個reponse
t- HTTP流，HTTP協(xié)議+TCP連接后，服務(wù)端會保持連接持續(xù)向客戶端發(fā)送更新的數(shù)據(jù)，一個request對應(yīng)多個reponse。以ajax發(fā)起異步請求為例，通過監(jiān)聽onreadystatechange事件查看響應(yīng)狀態(tài)，當(dāng)readyState為3時，是在響應(yīng)中，當(dāng)readyState為4時表示響應(yīng)完畢，將reponseText返回。
- websocket應(yīng)用層協(xié)議，是基于TCP協(xié)議的子集，需要借助HTTP1.1協(xié)議的101狀態(tài)碼進(jìn)行協(xié)議的升級，升級到websocket協(xié)議后，可以進(jìn)行ws全雙工雙向通信，客戶端和服務(wù)端都可以主動進(jìn)行雙向的收發(fā)數(shù)據(jù)。連接的過程首先：
1、客戶端發(fā)起升級協(xié)議的請求，需要設(shè)置請求頭HTTP1.1；connction:Upgrade；upgrade: WebSocket；Sec-WebSocket-Key；驗(yàn)證是websocket請求而不是http請求。
2、服務(wù)端返回狀態(tài)碼101；Sec-WebSocket-Accept；驗(yàn)證是否為websocket請求。Sec-WebSocket-Location；對應(yīng)請求頭的host。
為什么需要數(shù)據(jù)掩碼?
攻擊：https://www.cnblogs.com/lxwphp/p/8241194.html
代理服務(wù)器攻擊，攻擊者通過一些實(shí)現(xiàn)不完善的http代理服務(wù)器，只能識別http請求，攻擊者通過偽造的客戶端和服務(wù)端，通過代理服務(wù)端的http協(xié)議升級websocket過程，再通過偽造的客戶端，經(jīng)過剛剛建立起的websocket通道，向偽造的服務(wù)端發(fā)起偽造的請求（偽造請求的url和host），偽造的服務(wù)端把惡意資源返回給代理服務(wù)器，那么普通用戶去訪問代理服務(wù)器的時候，代理服務(wù)器在不知情的情況下將惡意資源發(fā)送給用戶。雖然加密的的算法是公開的但是，js代碼不能獲取掩碼，所以這樣就使得攻擊者無法偽造websocket請求，大大增加了攻擊的難度。
webpack熱更新 --watch
開發(fā)過程中我們通過使用DevServer啟動一個HTTP服務(wù)器，webpack會再構(gòu)建出的js代碼中注入一個客戶端，服務(wù)端和客戶端之間通過webSocket協(xié)議進(jìn)行通信，webpack發(fā)現(xiàn)入口文件所依賴的文件發(fā)生變化時，會通知DevServer，服務(wù)端再通知客戶端進(jìn)行網(wǎng)頁刷新、
// 配置
watch: true,
watchOptions: {
ignore: '/node_modules',
aggreateTime: 300ms, //300ms后觸發(fā)更新
poll: 1000 //每秒詢問1000次
}
// 模塊熱更新
devServer：{
hot: true
}
模塊熱替換 --hot
無需手動刷新 通過websocket推送實(shí)現(xiàn)自動刷新
