在线乱码卡一卡二卡新HD,最近韩国免费观看视频,国产色无码精品视频国产,亚洲男人的天堂久久香蕉

背景

在特定場景下，我們往往需要實(shí)時(shí)的去獲取最新的數(shù)據(jù)，如獲取消息推送或公告、聊天消息、實(shí)時(shí)的日志和學(xué)情等，都對(duì)數(shù)據(jù)的實(shí)時(shí)性要求很高，面對(duì)這類場景，最常用的可能就是輪詢，但除了輪詢還有長連接（Websocket）和服務(wù)端推送（SSE）方案可供選擇。

輪詢

輪詢就是采用循環(huán)http請(qǐng)求的方式，通過重復(fù)的接口請(qǐng)求去獲取最新的數(shù)據(jù)。

短輪詢（polling）

短輪詢可能是我們用的最多的一種實(shí)時(shí)刷新數(shù)據(jù)的方式了，我們?cè)谥v輪詢方案時(shí)，大部分指的就是短輪詢，其實(shí)現(xiàn)方式和普通的接口無異，改造也只要前端增加定時(shí)器或useRequest配置輪詢參數(shù)即可，其原理也非常簡單，如下圖，如果是http1.1及以上，TCP連接可以復(fù)用，當(dāng)然http1.0及以下也是可以使用，但消耗會(huì)更多。短輪詢的特點(diǎn)就是接口請(qǐng)求立即會(huì)返回，每次請(qǐng)求都可以理解為是一次新的請(qǐng)求。

(資料圖片)

短輪詢的優(yōu)缺點(diǎn)

短輪詢最大的優(yōu)點(diǎn)就是簡單，前端設(shè)置時(shí)間間隔，定時(shí)去請(qǐng)求數(shù)據(jù)，而服務(wù)端只需同步的查詢數(shù)據(jù)返回即可，但缺點(diǎn)也顯而易見：

無用請(qǐng)求過多：從下圖可以看出，每隔固定時(shí)間，一定有請(qǐng)求發(fā)出，且每次接口可能返回一樣的數(shù)據(jù)或返回空結(jié)果，服務(wù)端會(huì)重復(fù)查詢數(shù)據(jù)庫、前端會(huì)重復(fù)重渲染實(shí)時(shí)性不可控，如數(shù)據(jù)更新了，但輪詢請(qǐng)求剛結(jié)束一輪，會(huì)造成輪詢間隔內(nèi)數(shù)據(jù)都得不到更新長輪詢（long polling）

看完了上面關(guān)于短輪詢的介紹，我們知道了輪詢有兩個(gè)主要的缺陷：一個(gè)是無用請(qǐng)求過多，另外一個(gè)是數(shù)據(jù)實(shí)時(shí)性不可控。為了解決這兩個(gè)問題，于是有了更進(jìn)一步的長輪詢方案。

在上圖中，客戶端發(fā)起請(qǐng)求后，服務(wù)端發(fā)現(xiàn)當(dāng)前沒有新的數(shù)據(jù)，這個(gè)時(shí)候服務(wù)端沒有立即返回請(qǐng)求，而是將請(qǐng)求掛起，在等待一段時(shí)間后(一般為30s或者是60s，設(shè)置一個(gè)超時(shí)返回主要是為了考慮過長的無數(shù)據(jù)連接占用會(huì)被網(wǎng)關(guān)或者某層中間件斷開甚至是被運(yùn)營商斷開），如發(fā)現(xiàn)還是沒有數(shù)據(jù)更新的話，就返回一個(gè)空結(jié)果給客戶端?？蛻舳嗽谑盏椒?wù)端的回復(fù)后，立即再次向服務(wù)端發(fā)送新的請(qǐng)求。這次服務(wù)端在接收到客戶端的請(qǐng)求后，同樣等待了一段時(shí)間，這次好運(yùn)的是服務(wù)端的數(shù)據(jù)發(fā)生了更新，服務(wù)端給客戶端返回了最新的數(shù)據(jù)?？蛻舳嗽谀玫浇Y(jié)果后再次發(fā)送下一個(gè)請(qǐng)求，如此反復(fù)。

長輪詢的優(yōu)缺點(diǎn)

長輪詢很完美地解決了短輪詢的問題，首先服務(wù)端在沒有數(shù)據(jù)更新的情況下沒有給客戶端返回?cái)?shù)據(jù)，所以避免了客戶端大量的重復(fù)請(qǐng)求。再者客戶端在收到服務(wù)端的返回后，馬上發(fā)送下一個(gè)請(qǐng)求，這就保證了更好的數(shù)據(jù)實(shí)時(shí)性。不過長輪詢也有缺點(diǎn):

服務(wù)端資源大量消耗: 服務(wù)端會(huì)一直hold住客戶端的請(qǐng)求，這部分請(qǐng)求會(huì)占用服務(wù)器的資源。對(duì)于某些語言來說，每一個(gè)HTTP連接都是一個(gè)獨(dú)立的線程，過多的HTTP連接會(huì)消耗掉服務(wù)端的內(nèi)存資源。難以處理數(shù)據(jù)更新頻繁的情況: 如果數(shù)據(jù)更新頻繁，會(huì)有大量的連接創(chuàng)建和重建過程，這部分消耗是很大的。雖然HTTP有TCP連接復(fù)用，但每次拿到數(shù)據(jù)后客戶端都需要重新請(qǐng)求，因此相對(duì)于WebSocket和SSE它多了一個(gè)發(fā)送新請(qǐng)求的階段，對(duì)實(shí)時(shí)性和性能還是有影響的。

從上面的描述來看，長輪詢的次數(shù)和時(shí)延似乎可以更少，那是不是長輪詢更好呢？其實(shí)不是的，這個(gè)兩種輪詢方式都有優(yōu)劣勢和適合的場景。

短輪詢，長輪詢?cè)趺催x？

長輪詢多用于操作頻繁，點(diǎn)對(duì)點(diǎn)的通訊，而且連接數(shù)不能太多情況，每個(gè)TCP連接都需要三步握手，這需要時(shí)間，如果每個(gè)操作都是先連接，再操作的話那么處理速度會(huì)降低很多，所以每個(gè)操作完后都不斷開，次處理時(shí)直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。例如：數(shù)據(jù)庫的連接用長連接， 如果用短連接頻繁的通信會(huì)造成socket錯(cuò)誤，而且頻繁的socket 創(chuàng)建也是對(duì)資源的浪費(fèi)。

而像WEB網(wǎng)站的http服務(wù)一般都用短輪詢，因?yàn)殚L連接對(duì)于服務(wù)端來說會(huì)耗費(fèi)一定的資源，而像WEB網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會(huì)更省一些資源，如果用長連接，而且同時(shí)有成千上萬的用戶，如果每個(gè)用戶都占用一個(gè)連接的話，那可想而知吧。所以并發(fā)量大，但每個(gè)用戶無需頻繁操作情況下需用短連好。

長連接?WebSocket?

上面說到長輪詢不適用于服務(wù)端資源頻繁更新的場景，而解決這類問題的一個(gè)方案就是WebSocket。用最簡單的話來介紹WebSocket就是：客戶端和服務(wù)器之間建立一個(gè)持久的長連接，這個(gè)連接是雙工的，客戶端和服務(wù)端都可以實(shí)時(shí)地給對(duì)方發(fā)送消息。下面是WebSocket的圖示:

WebSocket對(duì)于前端的同學(xué)來說是非常常見了，因?yàn)闊o論是webpack還是vite，用來HMR的reload就是通過WebSocket來進(jìn)行的，有代碼改動(dòng)，工程重新編譯，新變更的模塊通知到瀏覽器加載新的模塊，這里的通知瀏覽器加載新模塊就是通過WebSocket的進(jìn)行的。如上圖，通過握手（協(xié)議轉(zhuǎn)換）建立連接后，雙方就保持持久連接，由于歷史的關(guān)系，WebSocket建立連接是依賴HTTP的，但是其建連請(qǐng)求有明顯的特征，目的是客戶端和服務(wù)端都能識(shí)別并保持連接。

請(qǐng)求特征

請(qǐng)求頭特征

HTTP 必須是 1.1 GET 請(qǐng)求HTTP Header 中 Connection 字段的值必須為 UpgradeHTTP Header 中 Upgrade 字段必須為 websocketSec-WebSocket-Key 字段的值是采用 base64 編碼的隨機(jī) 16 字節(jié)字符串Sec-WebSocket-Protocol 字段的值記錄使用的子協(xié)議，比如 binary base64Origin 表示請(qǐng)求來源

響應(yīng)頭特征

狀態(tài)碼是 101 表示 Switching ProtocolsUpgrade / Connection / Sec-WebSocket-Protocol 和請(qǐng)求頭一致Sec-WebSocket-Accept 是通過請(qǐng)求頭的 Sec-WebSocket-Key 生成兼容性

WebSocket 協(xié)議在2008年誕生，2011年成為國際標(biāo)準(zhǔn)?，F(xiàn)在所有瀏覽器都已經(jīng)支持了。

實(shí)現(xiàn)一個(gè)簡單的WebSocket

基于原生WebSocket我們實(shí)現(xiàn)一個(gè)簡單的長連。

連接

// 連接只需實(shí)例一個(gè)WebSocket const ws = new WebSocket(`wss://${url}`);

發(fā)送消息

ws.send("這是一條消息：" + count);

監(jiān)聽消息

ws.onmessage = function (event) { console.log(event.data);}

關(guān)閉連接

ws.close();?在工程上使用WebSocket?

在工程上，很少直接基于原生WebSocket實(shí)現(xiàn)業(yè)務(wù)需求，使用WebSocket需要完成下面幾個(gè)問題：

鑒權(quán)：防止惡意連接連接進(jìn)來接收消息心跳：客戶端意外斷開，導(dǎo)致死鏈占用服務(wù)端資源，長時(shí)間無消息的連接可能會(huì)被中間網(wǎng)關(guān)或運(yùn)營商斷開登錄：通過建連需要識(shí)別出該連接是哪個(gè)用戶，有無權(quán)限，需要推送哪些消息日志：監(jiān)控連接，錯(cuò)誤上報(bào)后臺(tái)：能方便的查看在線連接的客戶端數(shù)量，消息傳輸量服務(wù)端推送（SSE）

SSE全稱Server-sent Events，是HTML 5 規(guī)范的一個(gè)組成部分，該規(guī)范十分簡單，主要由兩個(gè)部分組成：第一個(gè)部分是服務(wù)器端與瀏覽器端之間的通訊協(xié)議，第二部分則是在瀏覽器端可供 JavaScript 使用的 EventSource 對(duì)象。通訊協(xié)議是基于純文本的簡單協(xié)議。服務(wù)器端的響應(yīng)的內(nèi)容類型是“text/event-stream”。響應(yīng)文本的內(nèi)容可以看成是一個(gè)事件流，由不同的事件所組成。每個(gè)事件由類型和數(shù)據(jù)兩部分組成，同時(shí)每個(gè)事件可以有一個(gè)可選的標(biāo)識(shí)符。不同事件的內(nèi)容之間通過僅包含回車符和換行符的空行（“rn”）來分隔。每個(gè)事件的數(shù)據(jù)可能由多行組成。

?和 Websocket對(duì)比?

SSE	WebSocket
單向：僅服務(wù)端能發(fā)送消息	雙向：客戶端、服務(wù)端雙向發(fā)送
僅文本數(shù)據(jù)	二進(jìn)制、文本都可
常規(guī)HTTP協(xié)議	WebSocket協(xié)議

?兼容性??數(shù)據(jù)格式?

服務(wù)器向?yàn)g覽器發(fā)送的 SSE 數(shù)據(jù)，必須是 UTF-8 編碼的文本，

響應(yīng)頭

Content-Type: text/event-streamCache-Control: no-cacheConnection: keep-alive數(shù)據(jù)傳輸

服務(wù)端每次發(fā)送消息，由若干message?組成，使用\n\n?分隔，如果單個(gè)messag?過長，可以用\n分隔。

field取值

dataeventidretry

例子

// 注釋，用于心跳包: this is a test stream\n\n// 設(shè)置斷鏈1000ms重試一次retry:1000 \n\nevent: 自定義消息\n\ndata: some text\n\ndata: another message\ndata: with two lines \n\n?實(shí)現(xiàn)一個(gè)簡單的SSE?web端

實(shí)例化EventSource?，監(jiān)聽open、message、error

const source = new EventSource(url, { withCredentials: true });// 監(jiān)聽消息source.onmessage = function (event) { // handle message};source.addEventListener("message", function (event) { // handle message}, false);// 監(jiān)聽錯(cuò)誤source.onerror = function (event) { // handle error};source.addEventListener("error", function (event) { // handle error}, false);// 關(guān)閉連接source.close()服務(wù)端

以nodejs為例，服務(wù)端代碼和普通請(qǐng)求無異，并沒有新的處理類庫。

res.writeHead(200, { "Content-Type":"text/event-stream", "Cache-Control":"no-cache", "Connection":"keep-alive", "Access-Control-Allow-Origin": "*", }); res.write("retry: 10000\n\n"); res.write("event: connecttime\n\n"); res.write("data: " + (new Date()) + "\n"); res.write("data: " + (new Date()) + "\n\n"); // 模擬收到消息推送給客戶端 interval = setInterval(function () { res.write("data: " + (new Date()) + "\n\n"); }, 1000);

和WebSocket不同，SSE并不是新的通信協(xié)議，其本質(zhì)是在普通HTTP請(qǐng)求的基礎(chǔ)上定義一個(gè)Content-Type?，保持上連接，通過普通的接口也能模擬出SSE的效果，以XMLHttpRequest為例

const xhr = new XMLHttpRequest(); xhr.open("GET", "http://localhost:8844/long", true); xhr.onload = (e) => { console.log("onload", xhr.responseText); }; xhr.onprogress = (e) => { // 每次服務(wù)端寫入response的數(shù)據(jù)，都會(huì)傳輸過來，并產(chǎn)生一次onprogress事件 console.log("onprogress", xhr.responseText); }; xhr.send();參考文獻(xiàn)

rfc6455.pdf[1]

WebSocket協(xié)議中文版（rfc6455）[2]

深入剖析WebSocket的原理 - 知乎[3]

HTTP長連接實(shí)現(xiàn)原理 - 掘金[4]

WebSocket() - Web API 接口參考 | MDN[5]

EventSource - Web API 接口參考 | MDN[6]?

關(guān)鍵詞： 發(fā)送消息 數(shù)據(jù)更新 服務(wù)器端 關(guān)閉連接 成千上萬