Straumēšana caur forward proxy pret pilnas atbildes buferēšanu

Kad lejupielāde šķietami gaida, atdaliet trīs notikumus: atbildes galveņu pienākšanu, ķermeņa baitu pienākšanu un lietojumprogrammas spēju izmantot vai attēlot rezultātu. Viens ielādes indikators vien nevar noteikt, kurš no tiem kavējas.

Parastie straumēšanas posmi var pārklāties:

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

Proxy var rakstīt piemērotu saturu kešatmiņā, vienlaikus to pārsūtot. Kešošana neprasa gaidīt visu failu. Squid read_ahead_gap kontrolē izgūšanu, kas notiek pirms piegādes, un tā ir cita veida buferēšana.

Pretspiediens var īslaicīgi apturēt augšupējas lasīšanu, kad lēns klients piepilda izvades rindas. Content-Length arī nodrošina garumu bez pilnas buferēšanas. HTTP/1.1 chunked kodējums pieļauj pakāpenisku piegādi, bet nevar apsolīt zemu latentumu, ja iepriekšēja komponente aiztur datus.

Pēc tam pārbaudiet apstrādes posmus. Pārrakstīšanai vai inspicēšanai var būt vajadzīga daļa vai viss ķermenis. Saspiešana un lietojumprogrammas ietvars var aizkavēt lietderīgu izvadi. Klientā metode, kas gaida pilnu baitu masīvu, atgriežas vēlāk, un pārlūks var saņemt baitus, pirms spēj tos attēlot.

Pēc veiksmīga CONNECT parasts proxy pārsūta pakalpojuma straumi, nezinot tunelētā faila galīgo garumu. Pirms bufera vai taimauta iestatījumu maiņas sekojiet pirmajam iepriekš trūkstošajam notikumam. Kad curl ir novērotājs, tā opcija no-buffer maina lokālo izvades posmu.