- Dlhé dotazovanie simuluje odosielanie údajov serverom cez HTTP, ale trpí problémami s preťažením hlavičiek, zvláštnosťami časového limitu a obmedzeniami zdrojov.
- Proxy servery, limity pripojenia prehliadača a ukladanie do vyrovnávacej pamäte môžu vo veľkom rozsahu nenápadne narušiť alebo zhoršiť správanie dlhých dotazov.
- Protokoly ako Bayeux a BOSH sú založené na dlhom dotazovaní a ponúkajú obojsmerné posielanie správ, často popri streamovaní.
- Optimalizované časové limity, dávkovanie, kompresia a starostlivá logika opakovania sú nevyhnutné pre udržanie robustnosti dlhého dotazovania v JavaScripte.
Dlhé dotazovanie v JavaScripte vyzerá klamlivo jednoducho: ponechať HTTP požiadavku otvorenú, kým server nemá čo povedať, vrátiť dáta a okamžite otvoriť novú požiadavku. Zvonku to pôsobí takmer ako komunikácia v reálnom čase, takže neprekvapuje, že chatovacie aplikácie, dashboardy, hry a notifikačné systémy sa na ňu spoliehajú už roky. Pod kapotou sa však skrývajú jemné úskalia týkajúce sa výkonu, škálovateľnosti a spoľahlivosti, ktoré sa prejavia hneď, ako vaša aplikácia prerastie hranicu hŕstky používateľov.
Pochopenie skutočných problémov dlhého dotazovania v JavaScripte znamená ísť nad rámec základného popisu „klient odosiela požiadavku, server čaká, server odpovedá“ a pozrieť sa na sémantiku HTTP, limity prehliadača, proxy, časové limity a alternatívy, ako sú WebSockets, HTTP streamovanie a udalosti odoslané serverom. V tejto príručke sa podrobne zaoberáme tým, ako dlho funguje dotazovanie, aké problémy identifikovala IETF a hlavní dodávatelia a ako sa rozhodnúť, kedy ho použiť, kedy ho optimalizovať a kedy ho úplne nahradiť.
Čo vlastne je dlhé polling v JavaScripte
Jednoducho povedané, dlhé dotazovanie je vzorec vybudovaný na základe bežného HTTP, kde prehliadač odošle požiadavku a server zámerne odloží odpoveď, kým nebudú k dispozícii nové údaje alebo kým neuplynie časový limit. Hneď ako prehliadač dostane odpoveď, spracuje údaje a okamžite odošle ďalšiu požiadavku, pričom pripojenie zostáva „takmer stále“ v stave čakajúcej na vyžiadanie.
Tento postup sa veľmi líši od klasického krátkeho dotazovania, kde klient v pevne stanovenom intervale kladie na server otázku „je niečo nové?“ bez ohľadu na to, či sú k dispozícii aktualizácie. Pri dlhom dotazovaní server ponecháva požiadavku otvorenú počas období nečinnosti, takže klient nemusí opakovane odosielať prázdne dotazníky, keď sa nič nezmenilo.
Typická dlhá slučka dotazovania v JavaScripte vyzerá ako rekurzívna funkcia subscribe, ktorá volá fetch (alebo XMLHttpRequest), čaká na odpoveď, spracováva užitočné zaťaženie a potom znova volá samu seba. Ak sa sieť preruší alebo sa vyskytne chyba, kód sa okamžite alebo po krátkom oneskorení pokúsi o opakované spustenie a snaží sa udržať čakajúce pripojenie čo najdlhšie aktívne.
Tento prístup funguje obzvlášť dobre, keď sú správy relatívne zriedkavé, pretože čas nečinnosti pripojenia nespôsobuje sieťovú prevádzku ani zaťaženie CPU nad rámec nákladov na udržiavanie otvoreného socketu. Používateľ zažíva takmer okamžité aktualizácie, zatiaľ čo server sa vyhýba neustálemu zahlteniu kontrolami.
Hneď ako sa však udalosti stanú častými, každá udalosť má tendenciu spustiť celý cyklus odpovede HTTP – stavový riadok, hlavičky, autentifikácia, telo – takže cena za správu môže explodovať a vzorec prenosu začne vyzerať ako pílovitý nárast požiadaviek/odpovedí. Práve tu sa v reálnych aplikáciách začínajú objavovať problémy so škálovaním a réžiou.
Krátke pollingy vs. dlhé pollingy vs. streamovanie
Pre skutočné pochopenie problémového priestoru je užitočné porovnať dlhé pollingy s krátkymi pollingmi a HTTP streamingom, pretože všetky tri sú spôsoby, ako predstierať „pretlačenie“ cez v podstate protokol požiadavky/odpovede, akým je HTTP.
Krátke dotazovanie je naivný variant: klient periodicky odosiela HTTP požiadavky (napríklad každých 5-10 sekúnd) a server okamžite odpovie všetkými správami, ktoré prišli od posledného dotazovania. Ak nie je nič k dispozícii, server stále odpovie, často s prázdnym dátovým zaťažením, a klient jednoducho čaká do ďalšieho intervalu.
Tento model má dve zjavné nevýhody: latencia správ môže byť taká vysoká ako interval dotazovania a server je nútený spracovávať opakované požiadavky, aj keď nie sú k dispozícii žiadne nové údaje. Pre malé systémy alebo systémy s nízkou prevádzkou to môže byť prijateľné, ale vo veľkom meradle to plytvá cyklami CPU, šírkou pásma siete a môže spôsobiť znateľné oneskorenia pre používateľov.
Dlhé dotazovanie to vylepšuje tým, že server nechá každú požiadavku „otvorenú“, kým sa nestane niečo zaujímavé – udalosť na doručenie alebo časový limit. Latencia pre nové správy sa teraz blíži k jednej spiatočnej ceste siete a prázdne odpovede sa vyskytujú oveľa menej často, čím sa znižuje plytvanie prevádzkou.
HTTP streamovanie ide ešte o krok ďalej tým, že odpoveď vôbec neuzatvára: server odošle jednu HTTP odpoveď a potom streamuje viacero blokov dát cez to isté pripojenie, oddelených určitým rámovaním na úrovni aplikácie. Klient číta stream postupne namiesto čakania na dokončenie celej odpovede.
V HTTP/1.1 sa to zvyčajne implementuje pomocou kódovania rozdeleného prenosu, kde server nastaví Transfer-Encoding: chunked a potom odošle každý kus dát ako samostatný chunk s vlastnou hlavičkou dĺžky. V nastaveniach štýlu HTTP/1.0 je možné streamovanie dosiahnuť aj vynechaním Content-Length a použitím connection close ako značky konca streamu.
Zásadný rozdiel spočíva v tom, že dlhé dotazovanie ukončí odpoveď po každej správe a vynúti novú požiadavku pre ďalšiu udalosť, zatiaľ čo streamovanie udržiava rovnakú odpoveď aktívnu a odosiela správy hneď, ako sa objavia. To má zásadné dôsledky pre latenciu, využitie pamäte, proxy a spôsob, akým rámujete správy na aplikačnej vrstve.
Ako funguje HTTP dlhé dotazovanie v podstate
Z pohľadu HTTP protokolu dlhé dotazovanie nezavádza žiadne nové metódy ani stavové kódy; iba rozširuje bežnú sémantiku požiadavky, ktorá čaká na odpoveď. Analýza „obojsmerného HTTP“ zo strany IETF jasne ukazuje, že dlhé dotazovanie je stále platné pre HTTP 1.0/1.1, ale posúva model blízko k jeho limitom.
Základný životný cyklus dlhej interakcie s dotazovaním vyzerá takto: klient odošle počiatočnú požiadavku a pozastaví ju, server odloží odpoveď, kým nenastane udalosť, zmena stavu alebo uplynutie časového limitu, potom server vráti úplnú odpoveď HTTP (často 200 OK) s údajmi o udalosti a nakoniec klient rýchlo vydá novú požiadavku.
Tento vzor môže bežať cez trvalé aj dočasné HTTP pripojenia; s trvalými pripojeniami sa vyhnete réžii opakovaných TCP handshakes opätovným použitím toho istého socketu pre viacero dlhých žiadostí o kontrolu. V praxi je udržiavanie rovnakého TCP pripojenia aktívne takmer vždy výhodnejšie z hľadiska výkonu.
Servery, ktoré implementujú dlhé dotazovanie, musia zvyčajne spravovať dva sektory zdrojov na klienta: samotné TCP pripojenie a nevybavenú HTTP požiadavku čakajúcu v nejakom rade alebo slučke udalostí. Operačné systémy zvyčajne dokážu efektívne spracovať veľké množstvo otvorených soketov, ale niektoré HTTP servery alebo brány alokujú na požiadavku značné množstvo pamäte, čo sa môže stať skutočným úzkym hrdlom.
Jednou zaujímavou vlastnosťou dlhého dotazovania je, že pri veľkom zaťažení má tendenciu elegantne degradovať zvyšovaním latencie, a nie zlyhávať. Ak je server pomalý, správy určené pre klienta sa zaraďujú do frontu, kým sa neodošle odpoveď; viacero udalostí v fronte sa môže dokonca zhromaždiť do jednej dlhej odpovede na výzvu, čo mimochodom znižuje réžiu jednotlivých správ.
Problémy a obmedzenia dlhého prieskumu verejnej mienky
Napriek tomu, že sa v praxi široko používa a štandardizuje, dlhé dotazovanie prináša niekoľko známych technických problémov, ktoré sa dajú ľahko narušiť JavaScriptom, ak nie ste opatrní. Tieto problémy sa prejavujú vo využívaní šírky pásma, latencii, správe pripojenia a správaní sprostredkovateľov, ako sú proxy a vyrovnávacie pamäte.
Prvým nákladom, s ktorým sa stretnete, sú náklady na hlavičky: každá dlhá požiadavka a odpoveď na prieskum je kompletná HTTP správa, zvyčajne so súbormi cookie, hlavičkami autorizácie a ďalšími metadátami, ktoré môžu zatieniť skutočné užitočné zaťaženie. Pre malé, zriedkavé správy môže byť táto réžia prijateľná, ale v scenároch fakturácie založenej na objeme alebo v sieťach s obmedzenou šírkou pásma môže byť rozdiel medzi veľkosťou hlavičky a veľkosťou užitočného zaťaženia drahý.
Maximálna latencia je ďalším jemným problémom: zatiaľ čo priemerná latencia dlhého dotazovania na nové udalosti je zhruba jeden sieťový tranzit, oneskorenie v najhoršom prípade môže byť viac ako tri tranzity. Ak správa príde hneď po odoslaní odpovede zo servera, server musí čakať na ďalšiu požiadavku od klienta, kým bude môcť túto správu doručiť, a strata alebo opakovaný prenos TCP paketov môže tento čas ešte predĺžiť.
Nadväzovanie pripojenia sa často spomína ako problém, najmä keď ľudia porovnávajú dlhé dotazovanie s WebSockets. Ak by každá odpoveď na dlhý dotaz spôsobila zatvorenie HTTP pripojenia (a podkladového TCP pripojenia), náklady na opakované otváranie soketov by boli obrovské. Našťastie, dlhý dotaz môže a mal by byť vrstvený nad trvalé pripojenia, aby sa krátka prestávka medzi odpoveďami neinterpretovala ako nečinnosť; to umožňuje, aby transport zostal otvorený a opakovane použiteľný.
Alokácia zdrojov servera a proxy je hlavným praktickým obmedzením: každá nevybavená požiadavka spotrebuje pamäť a v synchrónnych architektúrach prípadne aj vlákno alebo pracovníka. Mnohé staršie alebo blokujúce servery jednoducho nedokážu škálovať na desiatky tisíc súbežných dlhých hlásení, pretože ich model súbežnosti očakáva rýchle dokončenie každej požiadavky; pre tieto systémy je asynchrónny I/O alebo dizajn riadený udalosťami takmer nevyhnutný.
Správanie pri ukladaní do vyrovnávacej pamäte môže tiež prerušiť dlhé dotazovanie, ak nie je explicitne potlačené. Sprostredkovateľské vyrovnávacie pamäte sa môžu rozhodnúť o opätovnom použití alebo uložení odpovedí, pokiaľ jasne neoznačíte dlhé požiadavky a odpovede na prieskum pomocou Cache-Control: no-cache (a súvisiacich hlavičiek), čím zabezpečíte, že každá požiadavka skutočne dorazí na pôvodný server a nebudú doručené zastarané údaje.
Časové limity, proxy a správanie sprostredkovateľov
Jedným z najotravnejších problémov dlhého dotazovania v JavaScripte v reálnom svete je, že nemáte úplnú kontrolu nad sieťou medzi prehliadačom a serverom. Proxy, brány, vyrovnávače záťaže a dokonca aj predvolené nastavenia prehliadača, všetky ukladajú časové limity alebo stratégie ukladania do vyrovnávacej pamäte, ktoré môžu narušiť ilúziu živého pripojenia.
Dlhé žiadosti o hlasovanie majú zostať otvorené až do udalosti alebo časového limitu, ktorý určujete, ale v skutočnosti mnoho sprostredkovateľov preruší spojenie po kratšom, pevne stanovenom období. Aj keď prehliadače môžu štandardne povoliť až približne 300 sekúnd, niektoré proxy servery vynucujú oveľa kratšie časové limity, čo znamená, že váš dlhý prieskum sa skončí s chybou HTTP 504 Gateway Timeout alebo iba s resetom, čo núti klienta pripájať sa častejšie, ako ste zamýšľali.
Experimenty a prevádzkové skúsenosti naznačujú, že časové limity okolo 30 sekúnd sú v mnohých prostrediach bezpečnejším kompromisom, pričom 120 sekúnd často funguje, ale je krehkejšie. Dodávatelia sieťových zariadení, ktorí chcú byť ústretoví k dlhým anketám, sa vyzývajú, aby používali časové limity výrazne dlhšie ako typické prenosové časy strednej siete, aby sa legitímne dlhé ankety predčasne neukončili.
Reverzné proxy a združovanie pripojení prinášajú ďalšiu triedu problémov. Niektoré nastavenia proxy zdieľajú malú skupinu upstreamových pripojení medzi mnohými klientmi; ak dlhé výzvy obsadzujú tieto zdieľané pripojenia dlhší čas, iné požiadavky môžu byť zablokované alebo zaradené do frontu za nimi, čo znižuje výkon celej lokality.
Pri streamovaní HTTP je sprostredkovateľské ukladanie do vyrovnávacej pamäte ešte väčším rizikom, pretože proxy servery môžu ukladať do vyrovnávacej pamäte čiastočné odpovede a preposielať dáta až po nahromadení úplnej odpovede. V takom prípade by streamovací server, ktorý odosiela malé kúsky JavaScriptu očakávajúce okamžité spustenie v prehliadači, mohol zistiť, že sprostredkovateľ uchováva všetko až do ukončenia pripojenia, čím by sa úplne zničilo správanie v reálnom čase.
Limity prehliadača a počet pripojení
Z JavaScriptu nikdy priamo nemanipulujete s TCP pripojeniami; vidíte iba konštrukty vysokej úrovne ako fetch alebo XMLHttpRequest, ale prehliadače si vynucujú obmedzenia počtu paralelných pripojení, ktoré je možné otvoriť k rovnakému hostiteľovi. Historicky bol tento limit dve pripojenia na pôvod, čo robilo techniky štýlu Comet obzvlášť zložitými.
Moderné prehliadače zmiernili tieto obmedzenia na približne šesť alebo osem pripojení na hostiteľa, ale stále neexistuje štandardný spôsob, ako v JavaScripte odpovedať na otázku „koľko pripojení ešte zostáva?“ alebo koordinovať používanie medzi kartami a prvkami iframe. Každá karta môže nezávisle spustiť vlastnú dlhú anketu, čím sa rýchlo vyčerpajú dostupné sloty a zablokujú sa ďalšie dôležité požiadavky, ako sú CSS, obrázky alebo volania API.
Osvedčeným postupom na strane servera je používať súbory cookie alebo nejaký korelačný mechanizmus na detekciu viacerých dlhých ankiet pochádzajúcich z tej istej inštancie prehliadača a vyhnúť sa ich odloženiu. Rýchlou reakciou na mimoriadne dlhé ankety a skutočným zachytením iba jednej alebo malého počtu môžete znížiť riziko nedostatku pripojenia alebo rušenia kanála.
Niektoré protokoly vyššej úrovne postavené na dlhom dotazovaní, ako napríklad Bayeux a BOSH, explicitne navrhujú okolo limitov pripojenia prehliadača. Často používajú maximálne dva nevybavené HTTP požiadavky naraz a vyhýbajú sa spoliehaniu sa na HTTP pipeline, ktorý je slabo podporovaný a nedá sa ovládať z JavaScriptu.
HTTP pipeline, rámovanie a zoradenie správ
Hoci HTTP pipeline (odosielanie viacerých požiadaviek za sebou cez to isté pripojenie pred získaním odpovedí) by teoreticky mohlo znížiť dlhú latenciu dotazovania, v praxi je krehké a implementované nekonzistentne. RFC 2616 je opatrný, pokiaľ ide o pipeline, najmä pre POST požiadavky, a sprostredkovatelia alebo klienti ho môžu úplne zakázať.
Protokoly, ktoré sa snažia využiť pipeline na dlhé dotazovanie, musia najprv zistiť, či je pipeline spoľahlivo podporovaný od začiatku do konca; ak nie, vrátia sa ku konzervatívnemu, nepipelined správaniu. Z prostredia JavaScriptu prehliadača nemáte na správu tohto procesu žiadne háčiky, takže väčšina dlhých pollingových zásobníkov založených na JavaScripte jednoducho predpokladá, že pipeline nie je k dispozícii.
Rámovanie – spôsob, akým rozdeľujete súvislý prúd bajtov na samostatné aplikačné správy – je ďalším jemným rozdielom medzi dlhým dotazovaním a streamovaním HTTP. Pri dlhom dotazovaní každá HTTP odpoveď prirodzene obsahuje presne jednu alebo dávku správ, takže vaše rámovanie je implicitné: jedna odpoveď sa rovná jednému bloku zmysluplných údajov.
Pri streamovaní sa nemôžete spoliehať na hranice HTTP chunk ako rámovanie aplikácie, pretože proxy môžu dátový stream preskupiť, zlúčiť chunky alebo ich rozdeliť inak. To znamená, že aplikácia musí do užitočného zaťaženia vložiť vlastné oddeľovače alebo predpony dĺžky a podľa toho ich analyzovať na klientovi.
Samotné dlhé dotazovanie nezaručuje poradie správ a ich spoľahlivosť; závisia od aplikačného protokolu a úložnej vrstvy. Ak sa klient odpojí a znova pripojí uprostred streamu, potrebujete explicitné mechanizmy (ako sú poradové čísla alebo ID posledných udalostí), aby ste zabezpečili, že sa žiadne správy nestratia alebo nebudú doručené v nesprávnom poradí.
Bezpečnostné aspekty pre dlhé dotazovanie v JavaScripte
Dlhé dotazovanie ako technika nemení základný bezpečnostný model HTTP, ale spôsob, akým sa často implementuje – najmä v prehliadačoch používajúcich JavaScript – môže otvoriť dvere ďalším rizikám.
Mnohé riešenia dlhého dotazovania medzi doménami sa spoliehajú na vykonávanie JavaScriptu vráteného zo servera, niekedy prostredníctvom spätných volaní v štýle JSONP alebo iného dynamického vkladania skriptov. Ak je váš server zraniteľný voči útokom typu injection, útočník môže do týchto odpovedí potenciálne prepašovať ľubovoľný kód, ktorý potom prehliadač spustí s oprávneniami stránky.
Používanie HTTPS všade je nevyhnutné: šifrovanie prenosu chráni pred manipuláciou a odpočúvaním dlhodobých pripojení zo strany človeka uprostred. V kombinácii s robustným overovaním a autorizáciou (napríklad overovanie na základe tokenov a riadenie prístupu na základe rolí) môžete obmedziť koncové body dlhého dotazovania na určených klientov.
Keďže dlhé dotazovanie udržiava veľa pripojení otvorených dlhý čas, môže to urobiť útoky DoS atraktívnejšími: útočník sa môže pokúsiť vyčerpať zdroje servera otvorením mnohých falošných dlhých dotazovaní. Obmedzenie rýchlosti, kvóty pripojenia na IP adresu alebo token a rozumné časové limity sú nevyhnutnými obrannými opatreniami.
Hrozby špecifické pre prehliadač, ako napríklad CSRF, sú zvyčajne menej dôležité pre čisto XHR/fetch dlhé ankety, ktoré sa nespoliehajú na ambientné súbory cookie, ale ak sú zahrnuté súbory cookie, mali by ste s týmito koncovými bodmi zaobchádzať rovnako ako s akýmkoľvek iným citlivým rozhraním API. Súbory cookie SameSite, tokeny CSRF tam, kde je to vhodné, a prísne zásady CORS sú súčasťou prísneho nastavenia.
Dlhé dotazovanie verzus WebSockets a udalosti odoslané serverom
Z pohľadu vývojára JavaScriptu sú dlhé dotazovanie, WebSockety a udalosti odoslané serverom spôsoby, ako dosiahnuť funkcie „pocit v reálnom čase“, ale kompromisy sa dosť líšia.
WebSockety vytvárajú skutočne perzistentný, plne duplexný kanál medzi prehliadačom a serverom. Po úvodnom nadviazaní spojenia s HTTP aktualizáciou môžu dátové rámce plynúť oboma smermi bez réžie HTTP hlavičiek pre každú správu, čím sa minimalizuje latencia na správu a využitie šírky pásma.
Vďaka tomu sú WebSockety ideálne pre scenáre s vysokou frekvenciou, ako sú hry pre viacerých hráčov, kolaboratívna editácia alebo telemetrické streamy, kde sú správy malé, ale časté. Nevýhodou je, že niektoré firemné firewally, staré proxy alebo starší klienti stále nefungujú dobre s aktualizáciami WebSocket a servery musia používať iný programovací model a infraštruktúru vyladenú pre veľký počet dlhodobých socketov.
SSE je jednoduchšie ako WebSockets, keď potrebujete iba odosielanie správ medzi serverom a klientom, ale nemôže posielať správy z prehliadača späť cez ten istý kanál; stále sa spoliehate na bežné HTTP požiadavky pre komunikáciu medzi klientom a serverom. Taktiež to vyžaduje, aby sprostredkovatelia tolerovali streamovanie a nadmerne neukladali čiastočné odpovede do vyrovnávacej pamäte.
V porovnaní s tým je dlhé dotazovanie často „najmenším spoločným menovateľom“, ktorý funguje vo viacerých prostrediach vrátane starších prehliadačov a konzervatívnych sieťových nastavení. Preto mnoho platforiem pracujúcich v reálnom čase historicky používalo dlhé dotazovanie ako záložnú možnosť, keď boli WebSockety blokované, a postupne aktualizovalo pripojenia podľa toho, ako to možnosti dovoľovali.
Reálne protokoly na báze dlhého dotazovania: Bayeux, BOSH, API podobné SSE
Okrem dlhého dotazovania a streamovania bolo vybudovaných niekoľko protokolov vyššej úrovne, aby sa pred vývojármi aplikácií skryla zložitosť a poskytlo sa konzistentné API. Pochopenie toho, ako používajú dlhé prieskumy, pomáha objasniť silné aj slabé stránky tejto techniky.
Protokol Bayeux, spopularizovaný projektom CometD, podporuje ako možnosti prenosu HTTP dlhé dotazovanie aj streamovanie. Klient Bayeux zvyčajne používa dve HTTP pripojenia k serveru, aby správy mohli plynúť oboma smermi asynchrónne bez toho, aby boli blokované dlhými požiadavkami na výzvu.
Počas úvodného nadväzovania kontaktov klient a server dohodnú, ktoré obojsmerné techniky sú podporované – dlhé dotazovanie, streamovanie atď. – a klient si vyberie jednu z prekrývajúcich sa možností. Pre klientov JavaScript sa Bayeux zvyčajne vyhýba závislosti od HTTP pipeline a namiesto toho sa obmedzuje na dve nevybavené požiadavky, aby sa predišlo problémom s limitom pripojenia prehliadača.
BOSH (Bidirectional-streams Over Synchronous HTTP) pochádza zo sveta XMPP a bol navrhnutý tak, aby emuloval reláciu podobnú TCP cez HTTP pomocou dlhého dotazovania. Správca pripojení BOSH drží požiadavku klienta otvorenú a odpovedá iba vtedy, keď má údaje z aplikačného servera; hneď ako klient dostane túto odpoveď, odošle novú požiadavku a takmer stále udržiava aspoň jeden čakajúci dlhý prieskum.
BOSH môže použiť jeden alebo dva paralelné páry HTTP požiadavky a odpovede, dohodnuté na začiatku relácie, a starostlivo ich spravuje tak, aby rešpektoval limity pripojenia prehliadača a zároveň umožňoval asynchrónne obojsmerné posielanie správ. Zakazuje blokové prenosové kódovanie, aby sa predišlo problémom s vyrovnávacou pamäťou v sprostredkovateľoch, a pre efektívnosť umožňuje kompresiu pomocou Content-Encoding.
Udalosti odoslané serverom, hoci sa zvyčajne implementujú prostredníctvom streamovania a nie dlhého dotazovania, sú v duchu úzko prepojené. Špecifikácia W3C opisuje použitie textových/event-stream odpovedí a navrhuje zakázať HTTP chunking, pokiaľ nie je frekvencia udalostí dostatočne vysoká, opäť aby sa predišlo určitým problémom s vyrovnávacou pamäťou a sprostredkovateľským problémom, ktoré sa vyskytujú pri streamovaní cez HTTP/1.1.
Optimalizácia a sprísnenie dlhého dotazovania v JavaScriptových aplikáciách
Ak sa rozhodnete, že dlhé dotazovanie je správna voľba alebo nevyhnutná záložná možnosť pre vašu JavaScriptovú aplikáciu, existuje niekoľko stratégií, ako ju zefektívniť, škálovať a zvýšiť jej robustnosť.
Najprv si premyslene nastavte časové limity. Príliš krátke a plytváte zdrojmi pri spracovaní častých opätovných pripojení a riskujete hromadné opätovné pripojenie všetkých klientov naraz; príliš dlhé a zvyšujete pravdepodobnosť prekročenia limitov proxy alebo vyrovnávača záťaže, čo spôsobuje záhadné odpojenia. V praxi hodnoty v rozsahu 20 – 30 sekúnd pre WaitTimeSeconds (v API ako Amazon SQS) a podobné časové limity na úrovni aplikácie často dosahujú dobrú rovnováhu.
Ďalej zvážte dávkovanie udalostí na strane servera, keď je pre klienta zaradených viacero správ do frontu. Doručenie viacerých aktualizácií v jednej dlhej odpovedi na prieskum dramaticky znižuje réžiu jednotlivých správ a môže pomôcť systému elegantnejšie sa degradovať pri zaťažení tým, že sa latencia vymení za priepustnosť.
Kompresia je ďalším jednoduchým víťazstvom: povolenie gzip alebo podobného kódovania obsahu pre užitočné zaťaženia JSON pri dlhom dotazovaní môže znížiť využitie šírky pásma, najmä ak správy zdieľajú opakujúcu sa štruktúru. Nevýhodou sú dodatočné náklady na CPU pri kompresii, ale v mnohých reálnych nasadeniach je to vyvážené skráteným časom prenosu v sieti.
Z hľadiska JavaScriptu je robustné spracovanie chýb a logika opakovania nevyhnutné. Vaša slučka odberu by mala detegovať sieťové chyby, časové limity alebo chybné odpovede a skúsiť to znova s odkladom, namiesto toho, aby zahlcovala server. Exponenciálny odklad s jitterom je bežný vzorec na zabránenie synchronizovaným búrkam opakovaných pokusov počas výpadkov.
Nakoniec buďte opatrní pri čistení pripojenia po odpojení komponentov alebo zatvorení kariet. Zombie cykly dotazovania, ktoré bežia na pozadí, môžu spotrebovať zdroje klienta aj kapacitu servera, preto sa vždy uistite, že máte mechanizmus na zrušenie nevybavených načítaní alebo prerušenie ovládačov, keď je zobrazenie zničené alebo používateľ odíde.
Dlhé dotazovanie v JavaScripte zostáva výkonným nástrojom na vytváranie funkcií takmer v reálnom čase v prostrediach, kde nie sú k dispozícii WebSockety alebo SSE, ale prináša so sebou množstvo skrytých nákladov týkajúcich sa hlavičiek, časových limitov, proxy serverov a využívania zdrojov, ktorým musíte porozumieť a spravovať ich, ak chcete, aby sa vaša aplikácia plynulo škálovala.
