Továbbító proxy streamelés szemben a teljes válasz pufferelésével

Amikor egy letöltés úgy tűnik, hogy vár, válasszon szét három eseményt: a válaszfejlécek megérkezését, a törzs bájtjainak megérkezését és azt, hogy az alkalmazás tudja-e használni vagy megjeleníteni az eredményt. Egy töltésjelző önmagában nem tudja megmondani, melyik késik.

A szokásos streamelési szakaszok átfedhetik egymást:

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

A proxy a továbbítás közben alkalmas tartalmat írhat a gyorsítótárba. A gyorsítótárazás nem igényli a teljes fájl kivárását. A Squid read_ahead_gap beállítása a szállítást megelőző lekérést szabályozza, ami a pufferelés másik fajtája.

Az ellennyomás átmenetileg leállíthatja a felfelé irányuló olvasást, amikor egy lassú kliens megtölti a kimeneti sorokat. A Content-Length a hosszt is megadja teljes pufferelés nélkül. A HTTP/1.1 chunked kódolás lehetővé teszi a fokozatos szállítást, de nem ígérhet alacsony késleltetést, ha egy korábbi komponens visszatartja az adatokat.

Ezután vizsgálja meg a feldolgozási szakaszokat. Az átírás vagy az ellenőrzés a törzs egy részét vagy egészét igényelheti. A tömörítés és az alkalmazáskeretezés késleltetheti a hasznos kimenetet. Az ügyfélen a teljes bájttömböt váró metódus később tér vissza, és a böngésző bájtokat kaphat, mielőtt meg tudná jeleníteni őket.

Sikeres CONNECT után egy közönséges proxy továbbítja a szolgáltatásfolyamot anélkül, hogy ismerné az alagútozott fájl végleges hosszát. Mielőtt módosítaná a puffer- vagy időtúllépési beállításokat, kövesse a fenti első hiányzó eseményt. Ha a curl a megfigyelő, a no-buffer kapcsolója módosítja a helyi kimeneti szakaszt.