ஃபார்வர்டு ப்ராக்ஸி ஸ்ட்ரீமிங் மற்றும் முழு-பதில் பஃபரிங்

பதிவிறக்கம் காத்திருப்பது போல் தோன்றும்போது மூன்று நிகழ்வுகளைப் பிரிக்கவும்: பதில் தலைப்புகள் வருதல், உடல் பைட்டுகள் வருதல், மற்றும் பயன்பாடு முடிவைப் பயன்படுத்தவோ காட்டவோ முடிவது. சுழலி மட்டும் எது தாமதமாகிறது என்பதைக் கண்டறிய முடியாது.

சாதாரண ஸ்ட்ரீமிங் நிலைகள் ஒன்றோடொன்று மேற்பொருந்தலாம்:

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

ப்ராக்ஸி அனுப்பும்போதே தகுதியான உள்ளடக்கத்தை தற்காலிக சேமிப்பில் எழுதலாம். தற்காலிக சேமிப்புக்கு முழு கோப்பையும் காத்திருக்க தேவையில்லை. Squid இன் read_ahead_gap விநியோகத்திற்கு முன்னால் ஓடும் மீட்பைக் கட்டுப்படுத்துகிறது, இது மற்றொரு வகை பஃபரிங்.

மெதுவான கிளையண்ட் வெளியீட்டு வரிசைகளை நிரப்பும்போது பின்னழுத்தம் மேல்நோக்கிய வாசிப்பை தற்காலிகமாக நிறுத்தலாம். Content-Length-உம் முழு பஃபரிங் இல்லாமல் நீளத்தை வழங்குகிறது. HTTP/1.1 chunked குறியாக்கம் படிப்படியான விநியோகத்தை அனுமதிக்கிறது, ஆனால் முந்தைய கூறு தரவை வைத்திருந்தால் குறைந்த தாமதத்தை உறுதியளிக்க முடியாது.

அடுத்து செயலாக்க நிலைகளை ஆராயுங்கள். மீள எழுதுதல் அல்லது ஆய்வுக்கு உடலின் ஒரு பகுதி அல்லது முழு உடல் தேவைப்படலாம். சுருக்கம் மற்றும் பயன்பாட்டு சட்டகம் பயனுள்ள வெளியீட்டை தாமதப்படுத்தலாம். கிளையண்டில் முழு பைட் வரிசைக்காக காத்திருக்கும் முறை தாமதமாகத் திரும்பும், உலாவி காட்டும் முன்பே பைட்டுகளைப் பெறலாம்.

வெற்றிகரமான CONNECT க்குப் பிறகு சாதாரண ப்ராக்ஸி சுரங்கப்பாதை கோப்பின் இறுதி நீளம் தெரியாமல் சேவை ஸ்ட்ரீமை அனுப்புகிறது. பஃபர் அல்லது நேர வரம்பு அமைப்புகளை மாற்றும் முன் மேலே உள்ள முதல் காணாமல் போன நிகழ்வைப் பின்பற்றுங்கள். curl பார்வையாளராக இருக்கும்போது அதன் no-buffer விருப்பம் உள்ளூர் வெளியீட்டு நிலையை மாற்றுகிறது.