Pretakanje skozi forward proxy proti medpomnjenju celotnega odgovora

Ko se prenos zdi, da čaka, ločite tri dogodke: prihod glav odgovora, prihod bajtov telesa in zmožnost aplikacije, da rezultat uporabi ali prikaže. Sam indikator nalaganja ne more ugotoviti, katera od njih se zamika.

Običajne stopnje pretakanja se lahko prekrivajo:

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

Proxy lahko med posredovanjem zapisuje primerno vsebino v predpomnilnik. Predpomnjenje ne zahteva čakanja na celotno datoteko. read_ahead_gap v Squidu nadzoruje pridobivanje, ki teče pred dostavo, kar je druga vrsta medpomnjenja.

Povratni pritisk lahko začasno ustavi branje navzgor, ko počasen odjemalec napolni izhodne čakalne vrste. Content-Length prav tako poda dolžino brez popolnega medpomnjenja. Kodiranje HTTP/1.1 chunked omogoča postopno dostavo, ne more pa obljubiti nizke zakasnitve, če podatke zadržuje prejšnja komponenta.

Nato preglejte stopnje obdelave. Prepisovanje ali pregledovanje lahko potrebuje del ali celotno telo. Stiskanje in okvirjanje aplikacije lahko odložita uporaben izhod. Na odjemalcu se metoda, ki čaka na celotno polje bajtov, vrne pozneje, brskalnik pa lahko prejme bajte, preden jih lahko prikaže.

Po uspešnem CONNECT običajni proxy posreduje tok storitve brez potrebe po končni dolžini tunelirane datoteke. Preden spremenite nastavitve predpomnilnika ali časovne omejitve, sledite prvega manjkajočega dogodka zgoraj. Ko je curl opazovalec, njegova možnost no-buffer spremeni lokalno stopnjo izhoda.