Streamovanie cez forward proxy verzus bufferovanie celej odpovede

Keď sa sťahovanie zdá čakať, oddeľte tri udalosti: príchod hlavičiek odpovede, príchod bajtov tela a možnosť aplikácie výsledok použiť alebo vykresliť. Samotný indikátor načítania nedokáže určiť, ktorá z nich sa zdržiava.

Bežné fázy streamovania sa môžu prekrývať:

origin produces a chunk → proxy forwards bytes → client consumes them

Proxy môže zapisovať vhodný obsah do medzipamäte, zatiaľ čo ho preposiela. Ukladanie do medzipamäte nevyžaduje čakať na celý súbor. read_ahead_gap v Squide riadi načítavanie, ktoré beží pred doručením, čo je iný druh bufferovania.

Spätný tlak môže dočasne zastaviť čítanie proti prúdu, keď pomalý klient zaplní výstupné fronty. Content-Length tiež udáva dĺžku bez potreby plného bufferovania. Kódovanie HTTP/1.1 chunked umožňuje postupné doručovanie, ale nemôže sľúbiť nízku latenciu, ak dáta drží skorší komponent.

Ďalej preskúmajte fázy spracovania. Prepisovanie alebo kontrola môžu potrebovať časť alebo celé telo. Kompresia a rámovanie aplikácie môžu zdržať užitočný výstup. Na strane klienta metóda čakajúca na celé pole bajtov vracia výsledok neskôr a prehliadač môže prijať bajty skôr, než ich dokáže vykresliť.

Po úspešnom CONNECT bežná proxy preposiela tok služby bez potreby poznať konečnú dĺžku tunelovaného súboru. Pred zmenou nastavení buffera alebo časového limitu sledujte prvú chýbajúcu udalosť vyššie. Keď je pozorovateľom curl, jeho voľba no-buffer mení miestnu fázu výstupu.