Utiririshaji kupitia proksi ya mbele dhidi ya uhifadhi wa jibu kamili

Wakati upakuaji unaonekana kusubiri, tenganisha matukio matatu: kuwasili kwa vichwa vya jibu, kuwasili kwa baiti za mwili, na uwezo wa programu kutumia au kuonyesha matokeo. Kionyeshi cha mzunguko peke yake hakiwezi kutambua ni kipi kinachochelewa.

Hatua za kawaida za utiririshaji zinaweza kupishana:

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

Proksi inaweza kuandika maudhui yanayofaa kwenye akiba wakati inayapeleka. Uhifadhi hauhitaji kusubiri faili yote. read_ahead_gap ya Squid hudhibiti upataji unaotangulia uwasilishaji, ambao ni aina nyingine ya uhifadhi.

Shinikizo la nyuma linaweza kusimamisha kwa muda usomaji wa juu wakati mteja wa polepole anajaza foleni za pato. Content-Length pia hutoa urefu bila kuhitaji uhifadhi kamili. Usimbaji wa HTTP/1.1 chunked huruhusu uwasilishaji wa hatua kwa hatua, lakini hauwezi kuahidi ucheleweshaji mdogo ikiwa sehemu ya awali inashikilia data.

Kisha chunguza hatua za uchakataji. Kuandika upya au ukaguzi kunaweza kuhitaji sehemu au mwili wote. Ukandamizaji na uundaji wa mfumo wa programu vinaweza kuchelewesha pato muhimu. Kwa upande wa mteja, mbinu inayosubiri safu kamili ya baiti hurudi baadaye, na kivinjari kinaweza kupokea baiti kabla ya kuzionyesha.

Baada ya CONNECT kufanikiwa, proksi ya kawaida hupeleka mtiririko wa huduma bila kuhitaji urefu wa mwisho wa faili iliyofunikwa. Fuata tukio la kwanza linalokosekana hapo juu kabla ya kubadilisha mipangilio ya akiba au muda. Wakati curl ndiye mwangalizi, chaguo lake la no-buffer hubadilisha hatua ya pato la ndani.