Forward-proxyn suoratoisto vs. koko vastauksen puskurointi

Kun lataus näyttää odottavan, erota kolme tapahtumaa: vastauksen otsakkeiden saapuminen, rungon tavujen saapuminen ja sovelluksen kyky käyttää tai näyttää tulos. Pelkkä latauskuvake ei kerro, mikä niistä viivästyy.

Normaalit suoratoistovaiheet voivat mennä päällekkäin:

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

Proxy voi kirjoittaa kelvollista sisältöä välimuistiin välittäessään sitä. Välimuistiin tallentaminen ei edellytä koko tiedoston odottamista. Squidin read_ahead_gap ohjaa noutoa, joka kulkee toimituksen edellä, ja se on toisenlainen puskurointi.

Vastapaine voi tilapäisesti pysäyttää ylävirran luvut, kun hidas asiakas täyttää lähtöjonoja. Content-Length antaa pituuden ilman täyttä puskurointia. HTTP/1.1 chunked -koodaus sallii asteittaisen toimituksen, mutta ei voi luvata matalaa viivettä, jos aiempi komponentti pitää tietoja hallussaan.

Tarkastele seuraavaksi käsittelyvaiheita. Uudelleenkirjoitus tai tarkastus voi vaatia osan rungosta tai koko rungon. Pakkaus ja sovelluksen kehystys voivat viivästyttää hyödyllistä tulostetta. Asiakkaassa kokonaista tavutaulukkoa odottava menetelmä palaa myöhemmin, ja selain voi vastaanottaa tavuja ennen kuin se voi näyttää ne.

Onnistuneen CONNECTin jälkeen tavallinen proxy välittää palvelun virran tarvitsematta tunneloidun tiedoston lopullista pituutta. Seuraa yllä olevaa ensimmäistä puuttuvaa tapahtumaa ennen puskurin tai aikakatkaisun asetusten muuttamista. Kun curl on tarkkailija, sen no-buffer-vaihtoehto muuttaa paikallista tulostusvaihetta.