W3Cschool
恭喜您成為首批注冊(cè)用戶(hù)
獲得88經(jīng)驗(yàn)值獎(jiǎng)勵(lì)
長(zhǎng)輪詢(xún)是與服務(wù)器保持持久連接的最簡(jiǎn)單的方式,它不使用任何特定的協(xié)議,例如 WebSocket 或者 Server Sent Event。
它很容易實(shí)現(xiàn),在很多場(chǎng)景下也很好用。
從服務(wù)器獲取新信息的最簡(jiǎn)單的方式是定期輪詢(xún)。也就是說(shuō),定期向服務(wù)器發(fā)出請(qǐng)求:“你好,我在這兒,你有關(guān)于我的任何信息嗎?”例如,每 10 秒一次。
作為響應(yīng),服務(wù)器首先通知自己,客戶(hù)端處于在線(xiàn)狀態(tài),然后 —— 發(fā)送目前為止的消息包。
這可行,但是也有些缺點(diǎn):
因此,如果我們討論的是一個(gè)非常小的服務(wù),那么這種方式可能可行,但總的來(lái)說(shuō),它需要改進(jìn)。
所謂“長(zhǎng)輪詢(xún)”是輪詢(xún)服務(wù)器的一種更好的方式。
它也很容易實(shí)現(xiàn),并且可以無(wú)延遲地傳遞消息。
其流程為:
對(duì)于此方法,瀏覽器發(fā)出一個(gè)請(qǐng)求并與服務(wù)器之間建立起一個(gè)掛起的(pending)連接的情況是標(biāo)準(zhǔn)的。僅在有消息被傳遞時(shí),才會(huì)重新建立連接。
如果連接丟失,可能是因?yàn)榫W(wǎng)絡(luò)錯(cuò)誤,瀏覽器會(huì)立即發(fā)送一個(gè)新請(qǐng)求。
實(shí)現(xiàn)長(zhǎng)輪詢(xún)的客戶(hù)端 ?subscribe
? 函數(shù)的示例代碼:
async function subscribe() {
let response = await fetch("/subscribe");
if (response.status == 502) {
// 狀態(tài) 502 是連接超時(shí)錯(cuò)誤,
// 連接掛起時(shí)間過(guò)長(zhǎng)時(shí)可能會(huì)發(fā)生,
// 遠(yuǎn)程服務(wù)器或代理會(huì)關(guān)閉它
// 讓我們重新連接
await subscribe();
} else if (response.status != 200) {
// 一個(gè) error —— 讓我們顯示它
showMessage(response.statusText);
// 一秒后重新連接
await new Promise(resolve => setTimeout(resolve, 1000));
await subscribe();
} else {
// 獲取并顯示消息
let message = await response.text();
showMessage(message);
// 再次調(diào)用 subscribe() 以獲取下一條消息
await subscribe();
}
}
subscribe();
正如你所看到的,subscribe
函數(shù)發(fā)起了一個(gè) fetch
,然后等待響應(yīng),處理它,并再次調(diào)用自身。
服務(wù)器應(yīng)該可以處理許多掛起的連接
服務(wù)器架構(gòu)必須能夠處理許多掛起的連接。
某些服務(wù)器架構(gòu)是每個(gè)連接對(duì)應(yīng)一個(gè)進(jìn)程,導(dǎo)致進(jìn)程數(shù)和連接數(shù)一樣多,而每個(gè)進(jìn)程都會(huì)消耗相當(dāng)多的內(nèi)存。因此,過(guò)多的連接會(huì)消耗掉全部?jī)?nèi)存。
使用像 PHP 和 Ruby 語(yǔ)言編寫(xiě)的后端程序會(huì)經(jīng)常遇到這個(gè)問(wèn)題。
使用 Node.js 編寫(xiě)的服務(wù)端程序通常不會(huì)出現(xiàn)此類(lèi)問(wèn)題。
也就是說(shuō),這不是編程語(yǔ)言的問(wèn)題。大多數(shù)現(xiàn)代編程語(yǔ)言,包括 PHP 和 Ruby,都允許實(shí)現(xiàn)更適當(dāng)?shù)暮蠖顺绦?。只是?qǐng)確保你的服務(wù)器架構(gòu)在同時(shí)有很多連接的情況下能夠正常工作。
這是一個(gè)聊天演示,你可以下載它并在本地運(yùn)行(如果你熟悉 Node.js 并且可以安裝模塊):
瀏覽器代碼在 browser.js
中。
在消息很少的情況下,長(zhǎng)輪詢(xún)很有效。
如果消息比較頻繁,那么上面描繪的請(qǐng)求-接收(requesting-receiving)消息的圖表就會(huì)變成鋸狀狀(saw-like)。
每個(gè)消息都是一個(gè)單獨(dú)的請(qǐng)求,并帶有 header,身份驗(yàn)證開(kāi)銷(xiāo)(authentication overhead)等。
因此,在這種情況下,首選另一種方法,例如:Websocket 或 Server Sent Events。
Copyright©2021 w3cschool編程獅|閩ICP備15016281號(hào)-3|閩公網(wǎng)安備35020302033924號(hào)
違法和不良信息舉報(bào)電話(huà):173-0602-2364|舉報(bào)郵箱:jubao@eeedong.com
掃描二維碼
下載編程獅App
編程獅公眾號(hào)
聯(lián)系方式:
更多建議: