Streaming prin forward proxy versus tamponarea răspunsului complet

Când o descărcare pare să aștepte, separați trei evenimente: sosirea antetelor răspunsului, sosirea octeților corpului și capacitatea aplicației de a folosi sau afișa rezultatul. Un singur indicator de încărcare nu poate identifica pe care dintre ele întârzie.

Etapele normale de streaming se pot suprapune:

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

Un proxy poate scrie conținut eligibil în cache în timp ce îl retransmite. Memorarea în cache nu necesită așteptarea întregului fișier. read_ahead_gap din Squid controlează preluarea care rulează înaintea livrării, ceea ce este un alt tip de tamponare.

Contrapresiunea poate opri temporar citirile din amonte când un client lent umple cozile de ieșire. Content-Length furnizează de asemenea lungimea fără a necesita tamponare completă. Codificarea HTTP/1.1 chunked permite livrarea incrementală, dar nu poate promite o latență mică dacă o componentă anterioară reține datele.

Apoi inspectați etapele de procesare. Rescrierea sau inspecția pot necesita o parte sau întregul corp. Compresia și încadrarea aplicației pot întârzia ieșirea utilă. Pe client, o metodă care așteaptă tabloul complet de octeți returnează mai târziu, iar un browser poate primi octeți înainte de a-i putea afișa.

După un CONNECT reușit, un proxy obișnuit retransmite fluxul serviciului fără a avea nevoie de lungimea finală a fișierului tunelat. Urmați primul eveniment lipsă de mai sus înainte de a modifica setările de tampon sau de timeout. Când curl este observatorul, opțiunea sa no-buffer modifică etapa locală de ieșire.