Strumado per antaŭa prokurilo kontraŭ bufrado de la tuta respondo

Kiam elŝuto ŝajnas atendi, apartigu tri eventojn: alveno de respondaj kaplinioj, alveno de korpaj bajtoj, kaj la kapablo de la aplikaĵo uzi aŭ montri la rezulton. Ŝpinilo sola ne povas identigi kiun el ili malfruas.

La normalaj strumadaj etapoj povas interkovriĝi:

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

Prokurilo povas skribi taŭgan enhavon en la kaŝmemoron dum ĝi plusendas ĝin. Kaŝado ne postulas atendi la tutan dosieron. read_ahead_gap de Squid regas la elprenon, kiu antaŭas la transdonon, do alia speco de bufrado.

Retropremo povas portempe haltigi suprajn legadojn kiam malrapida kliento plenigas elirajn vicojn. Content-Length ankaŭ donas la longon sen postuli plenan bufradon. La chunked-kodado de HTTP/1.1 permesas laŭpaŝan transdonon, sed ne povas promesi malaltan latenton se pli frua komponanto tenas la datumojn.

Poste ekzamenu la prilaborajn etapojn. Reskribo aŭ inspektado povas bezoni parton aŭ la tutan korpon. Kunpremado kaj aplikada kadrigo povas malfruigi utilan eligon. Ĉe la kliento, metodo kiu atendas kompletan bajtaron redonas pli malfrue, kaj retumilo povas ricevi bajtojn antaŭ ol ĝi povas montri ilin.

Post sukcesa CONNECT, ordinara prokurilo plusendas la servan fluon sen bezoni la finan longon de la tunelita dosiero. Sekvu la unuan mankantan eventon supre antaŭ ol ŝanĝi ĝiajn bufrajn aŭ tempolimajn agordojn. Kiam curl estas la observanto, ĝia opcio no-buffer ŝanĝas la lokan eliran etapon.