Prosljeđivanje kroz forward proxy naspram punog baferovanja odgovora

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

Normalne faze strimovanja mogu se preklapati:

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

Proxy može zapisivati podoban sadržaj u keš dok ga prosljeđuje. Keširanje ne zahtijeva čekanje cijele datoteke. Squidov read_ahead_gap kontroliše dohvatanje 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đer 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 zahtijevati dio ili cijelo tijelo. Kompresija i okviri aplikacije mogu odgoditi koristan izlaz. Na strani klijenta, metoda koja čeka cijeli niz bajtova vraća se tek kasnije, a preglednik može primiti bajtove prije nego što ih može prikazati.

Nakon uspješnog CONNECT-a običan proxy prosljeđuje tok usluge bez potrebe za konačnom dužinom tunelirane datoteke. Pratite prvi nedostajući događaj iznad prije promjene postavki bafera ili vremenskog ograničenja. Kada je curl posmatrač, njegova no-buffer opcija mijenja lokalnu fazu izlaza.