Strimovanje kroz forward proxy nasuprot punom baferovanju odgovora

Kada se čini da preuzimanje čeka, razdvojite tri događaja: dolazak zaglavlja odgovora, dolazak bajtova tela i mogućnost da aplikacija iskoristi ili prikaže rezultat. Sam pokazivač učitavanja ne može utvrditi koji od njih kasni.

Normalne faze strimovanja mogu se preklapati:

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

Proksi može upisivati podoban sadržaj u keš dok ga prosleđuje. Keširanje ne zahteva čekanje cele datoteke. Squidov read_ahead_gap upravlja dohvatanjem koje ide ispred isporuke, što je druga vrsta baferovanja.

Povratni pritisak može privremeno zaustaviti čitanje uzvodno kada spor klijent napuni izlazne redove. Content-Length takođe daje dužinu bez punog baferovanja. HTTP/1.1 chunked kodiranje dopušta postepenu isporuku, ali ne može obećati nisku latenciju ako prethodna komponenta drži podatke.

Zatim pregledajte faze obrade. Prepisivanje ili inspekcija mogu zahtevati deo ili celo telo. Kompresija i okviri aplikacije mogu odložiti koristan izlaz. Na strani klijenta metoda koja čeka ceo niz bajtova vraća se kasnije, a pregledač može primiti bajtove pre nego što ih može prikazati.

Nakon uspešnog CONNECT-a obični proksi prosleđuje tok usluge bez potrebe za konačnom dužinom tunelirane datoteke. Pratite prvi nedostajući događaj gore pre promene postavki bafera ili vremenskog ograničenja. Kada je curl posmatrač, njegova no-buffer opcija menja lokalnu fazu izlaza.