Streaming via forward-proxy versus buffering van de volledige respons

Wanneer een download te wachten lijkt, onderscheid dan drie gebeurtenissen: responsheaders komen aan, bodybytes komen aan, en de toepassing kan het resultaat gebruiken of weergeven. Een spinner alleen kan niet vaststellen welke daarvan vertraagd is.

De normale streamingfasen kunnen elkaar overlappen:

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

Een proxy kan geschikte inhoud naar de cache schrijven terwijl hij die doorgeeft. Cachen vereist niet dat op het hele bestand wordt gewacht. Squids read_ahead_gap regelt het ophalen dat voorloopt op de aflevering, wat een ander soort buffering is.

Tegendruk kan het lezen stroomopwaarts tijdelijk stoppen wanneer een trage client de uitvoerwachtrijen vult. Content-Length levert ook de lengte zonder volledige buffering te vereisen. HTTP/1.1 chunked-codering staat stapsgewijze aflevering toe, maar kan geen lage latentie beloven als een eerdere component de gegevens tegenhoudt.

Onderzoek daarna de verwerkingsfasen. Herschrijven of inspectie kan een deel of het geheel van de body nodig hebben. Compressie en toepassingsframing kunnen nuttige uitvoer vertragen. Aan de clientzijde wacht een methode die een volledige byte-array vereist voordat hij terugkeert, en een browser kan bytes ontvangen voordat hij ze kan weergeven.

Na een geslaagde CONNECT geeft een gewone proxy de dienststroom door zonder de definitieve lengte van het getunnelde bestand te kennen. Volg de eerste ontbrekende gebeurtenis hierboven voordat u de buffer- of time-outinstellingen wijzigt. Wanneer curl de waarnemer is, wijzigt zijn no-buffer-optie de lokale uitvoerfase.