Transmetimi përmes proxy përpara kundrejt buferimit të përgjigjes së plotë

Kur një shkarkim duket se pret, ndani tre ngjarje: mbërritja e kokave të përgjigjes, mbërritja e bajteve të trupit dhe aftësia e aplikacionit për të përdorur ose shfaqur rezultatin. Vetëm një tregues ngarkimi nuk mund të identifikojë cila prej tyre është vonuar.

Fazat normale të transmetimit mund të mbivendosen:

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

Një proxy mund të shkruajë përmbajtje të përshtatshme në cache ndërsa e përcjell. Ruajtja në cache nuk kërkon pritjen e të gjithë skedarit. read_ahead_gap i Squid kontrollon marrjen që shkon përpara dorëzimit, i cili është një lloj tjetër buferimi.

Kundërpresioni mund të ndalojë përkohësisht leximet në rrjedhën e sipërme kur një klient i ngadaltë mbush radhët e daljes. Content-Length gjithashtu jep gjatësinë pa kërkuar buferim të plotë. Kodimi HTTP/1.1 chunked lejon dorëzim gradual, por nuk mund të premtojë vonesë të ulët nëse një komponent i mëparshëm i mban të dhënat.

Më pas shqyrtoni fazat e përpunimit. Rishkrimi ose inspektimi mund të kërkojnë një pjesë ose të gjithë trupin. Kompresimi dhe kornizimi i aplikacionit mund të vonojnë daljen e dobishme. Në klient, një metodë që pret grupin e plotë të bajteve kthehet më vonë, dhe shfletuesi mund të marrë bajte përpara se t'i shfaqë ato.

Pas një CONNECT të suksesshëm, një proxy i zakonshëm përcjell rrjedhën e shërbimit pa pasur nevojë për gjatësinë përfundimtare të skedarit të tunelizuar. Ndiqni ngjarjen e parë që mungon më sipër përpara se të ndryshoni cilësimet e buferit ose të afatit kohor. Kur curl është vëzhguesi, opsioni i tij no-buffer ndryshon fazën lokale të daljes.