Strujanje kroz forward proxy nasuprot punom međuspremanju odgovora

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

Normalne faze strujanja mogu se preklapati:

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

Proxy može zapisivati prikladan sadržaj u predmemoriju dok ga prosljeđuje. Predmemoriranje ne zahtijeva čekanje cijele datoteke. Squidov read_ahead_gap upravlja dohvaćanjem koje ide ispred isporuke, što je druga vrsta međuspremanja.

Povratni tlak može privremeno zaustaviti čitanje uzvodno kada spor klijent napuni izlazne redove. Content-Length također daje duljinu bez potrebe za punim međuspremanjem. HTTP/1.1 chunked kodiranje dopušta postupnu 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 kasnije, a preglednik može primiti bajtove prije nego što ih može prikazati.

Nakon uspješnog CONNECT-a obični proxy prosljeđuje tok usluge bez potrebe za konačnom duljinom tunelirane datoteke. Pratite prvi nedostajući događaj gore prije promjene postavki međuspremnika ili vremenskog ograničenja. Kada je curl promatrač, njegova no-buffer opcija mijenja lokalnu fazu izlaza.