फ़ॉरवर्ड प्रॉक्सी स्ट्रीमिंग बनाम पूर्ण-प्रतिक्रिया बफ़रिंग

जब डाउनलोड रुकता दिखे, तो तीन घटनाओं को अलग कीजिए: प्रतिक्रिया हेडर का आना, बॉडी बाइट्स का आना, और ऐप्लिकेशन का परिणाम उपयोग या प्रदर्शित कर पाना। केवल स्पिनर यह नहीं बता सकता कि कौन सी घटना विलंबित है।

सामान्य स्ट्रीमिंग चरण एक-दूसरे पर पड़ सकते हैं:

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

प्रॉक्सी रिले करते समय उपयुक्त सामग्री कैश में लिख सकता है। कैशिंग के लिए पूरी फ़ाइल की प्रतीक्षा आवश्यक नहीं है। Squid का read_ahead_gap डिलीवरी से आगे चलने वाली रिट्रीवल को नियंत्रित करता है, जो बफ़रिंग का दूसरा प्रकार है।

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

इसके बाद प्रोसेसिंग चरण देखिए। पुनर्लेखन या निरीक्षण के लिए बॉडी का भाग या पूरी बॉडी चाहिए हो सकती है। कम्प्रेशन और एप्लिकेशन फ़्रेमिंग उपयोगी आउटपुट में देरी कर सकते हैं। क्लाइंट पर पूर्ण बाइट ऐरे की प्रतीक्षा करने वाली विधि देर से लौटती है, और ब्राउज़र बाइट्स प्राप्त कर सकता है इससे पहले कि वह उन्हें प्रदर्शित कर सके।

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