फर्वार्ड प्रोक्सी स्ट्रिमिङ बनाम पूर्ण-प्रतिक्रिया बफरिङ

डाउनलोड पर्खिरहेको देखिँदा तीन घटना अलग गर्नुहोस्: प्रतिक्रिया हेडर आउनु, बडी बाइट आउनु, र एप्लिकेसनले नतिजा प्रयोग वा देखाउन सक्नु। स्पिनर मात्रले कुन ढिलो भइरहेको छ पहिचान गर्न सक्दैन।

सामान्य स्ट्रिमिङ चरणहरू एकअर्कामा पर्न सक्छन्:

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

प्रोक्सीले रिले गर्दै उपयुक्त सामग्री क्यासमा लेख्न सक्छ। क्यासिङका लागि पूरै फाइल पर्खनु आवश्यक छैन। Squid को read_ahead_gap ले डेलिभरीभन्दा अगाडि चल्ने पुनःप्राप्ति नियन्त्रण गर्छ, जो बफरिङको अर्को प्रकार हो।

ढिलो क्लाइन्टले आउटपुट लाइन भरिदिँदा ब्याकप्रेसरले माथिल्लो पढाइ अस्थायी रूपमा रोक्न सक्छ। Content-Length ले पूर्ण बफरिङ बिना पनि लम्बाइ दिन्छ। HTTP/1.1 chunked इन्कोडिङले क्रमिक डेलिभरी दिन्छ, तर अघिल्लो कम्पोनेन्टले डाटा राखेको खण्डमा कम लेटेन्सीको वाचा गर्न सक्दैन।

त्यसपछि प्रशोधन चरणहरू जाँच्नुहोस्। पुनर्लेखन वा निरीक्षणलाई बडीको भाग वा पूरै चाहिन सक्छ। कम्प्रेसन र एप्लिकेसन फ्रेमिङले उपयोगी आउटपुट ढिलो गर्न सक्छ। क्लाइन्टमा पूर्ण बाइट एरे पर्खने विधि ढिलो फर्कन्छ, र ब्राउजरले देखाउन सक्नुअघि बाइट प्राप्त गर्न सक्छ।

सफल CONNECT पछि सामान्य प्रोक्सीले टनेल गरिएको फाइलको अन्तिम लम्बाइ नजानी सेवा स्ट्रिम रिले गर्छ। बफर वा टाइमआउट सेटिङ बदल्नुअघि माथिको पहिलो हराएको घटना पछ्याउनुहोस्। जब curl पर्यवेक्षक हुन्छ, यसको no-buffer विकल्पले स्थानीय आउटपुट चरण बदल्छ।