Streaming amb proxy directe versus emmagatzematge de la resposta completa

Quan una descàrrega sembla esperar, separeu tres esdeveniments: l'arribada de les capçaleres de resposta, l'arribada dels bytes del cos i la capacitat de l'aplicació d'usar o mostrar el resultat. Un indicador giratori no pot identificar quin d'ells s'endarrereix.

Les etapes normals d'streaming es poden solapar:

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

Un proxy pot escriure contingut apte a la memòria cau mentre el retransmet. L'emmagatzematge no requereix esperar el fitxer sencer. El read_ahead_gap de Squid controla la recuperació que va per davant del lliurament, que és un altre tipus d'emmagatzematge.

La contrapressió pot aturar temporalment les lectures ascendents quan un client lent omple les cues de sortida. Content-Length també proporciona la longitud sense necessitat d'emmagatzematge complet. La codificació HTTP/1.1 chunked permet el lliurament incremental, però no pot prometre baixa latència si un component anterior reté les dades.

A continuació, reviseu les etapes de processament. La reescriptura o la inspecció poden necessitar part o tot el cos. La compressió i l'emmarcat de l'aplicació poden endarrerir la sortida útil. Al client, un mètode que espera la matriu de bytes completa torna més tard, i un navegador pot rebre bytes abans de poder-los mostrar.

Després d'un CONNECT correcte, un proxy ordinari retransmet el flux del servei sense necessitar la longitud final del fitxer tunelitzat. Seguiu el primer esdeveniment absent anterior abans de canviar la configuració de memòria cau o de temps d'espera. Quan curl és l'observador, la seva opció no-buffer canvia l'etapa de sortida local.