ફોર્વર્ડ પ્રોક્સી સ્ટ્રીમિંગ વિરુદ્ધ સંપૂર્ણ-પ્રતિસાદ બફરિંગ

ડાઉનલોડ રાહ જોતું લાગે ત્યારે ત્રણ ઘટનાઓને અલગ કરો: પ્રતિસાદ હેડર આવવા, બોડી બાઇટ્સ આવવા, અને એપ્લિકેશન પરિણામ વાપરી શકે કે દર્શાવી શકે. ફક્ત સ્પિનર કઈ ઘટના મોડી છે તે ઓળખી શકતું નથી.

સામાન્ય સ્ટ્રીમિંગ તબક્કાઓ ઓવરલેપ થઈ શકે છે:

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

પ્રોક્સી રિલે કરતી વખતે યોગ્ય સામગ્રી કેશમાં લખી શકે છે. કેશિંગ આખી ફાઇલની રાહ જવાની જરૂર રાખતું નથી. Squid નું read_ahead_gap ડિલિવરી પહેલાં ચાલતા રિટ્રીવલને નિયંત્રિત કરે છે, જે બીજા પ્રકારનું બફરિંગ છે.

ધીમો ક્લાયન્ટ આઉટપુટ કતાર ભરે ત્યારે બેકપ્રેશર ઉપરના વાંચનને અસ્થાયી રૂપે અટકાવી શકે છે. Content-Length પણ સંપૂર્ણ બફરિંગ વિના લંબાઈ આપે છે. HTTP/1.1 chunked એન્કોડિંગ ક્રમિક ડિલિવરીની મંજૂરી આપે છે, પરંતુ અગાઉનું ઘટક માહિતી રોકી રાખે તો ઓછી લેટન્સીની ખાતરી આપી શકતું નથી.

ત્યારબાદ પ્રોસેસિંગ તબક્કાઓ તપાસો. ફરીથી લખવું કે નિરીક્ષણને બોડીનો ભાગ કે આખી બોડી જોઈએ. કમ્પ્રેશન અને એપ્લિકેશન ફ્રેમિંગ ઉપયોગી આઉટપુટમાં વિલંબ કરી શકે છે. ક્લાયન્ટ પર સંપૂર્ણ બાઇટ એરેની રાહ જતી પદ્ધતિ પાછળથી પરત ફરે છે, અને બ્રાઉઝર રેન્ડર કરી શકે તે પહેલાં બાઇટ્સ મેળવી શકે છે.

સફળ CONNECT પછી સામાન્ય પ્રોક્સી ટનલ કરેલી ફાઇલની અંતિમ લંબાઈની જરૂર વિના સેવા પ્રવાહ રિલે કરે છે. બફર કે ટાઇમઆઉટ સેટિંગ્સ બદલતા પહેલાં ઉપરની પ્રથમ ગુમ થયેલી ઘટના અનુસરો. curl નિરીક્ષક હોય ત્યારે તેનો no-buffer વિકલ્પ સ્થાનિક આઉટપુટ તબક્કો બદલે છે.