फॉरवर्ड प्रॉक्सी स्ट्रीमिंग विरुद्ध पूर्ण-प्रतिसाद बफरिंग

डाउनलोड थांबत असल्यासारखे वाटल्यास तीन घटना वेगळ्या करा: प्रतिसाद हेडर येणे, बॉडी बाइट्स येणे, आणि अ‍ॅप्लिकेशनला निकाल वापरणे किंवा दाखवणे शक्य होणे. केवळ स्पिनर कोणती घटना उशिरा आहे हे ओळखू शकत नाही.

सामान्य स्ट्रीमिंग टप्पे एकमेकांवर येऊ शकतात:

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

प्रॉक्सी रिले करताना योग्य सामग्री कॅशेमध्ये लिहू शकतो. कॅशिंगसाठी संपूर्ण फाइलची वाट पाहणे आवश्यक नाही. Squid चा read_ahead_gap डिलिव्हरीच्या आधी धावणारे पुनर्प्राप्ती नियंत्रित करतो, जो बफरिंगचा दुसरा प्रकार आहे.

संथ क्लायंट आउटपुट रांगा भरल्यावर बॅकप्रेशर वरच्या वाचनाला तात्पुरते थांबवू शकतो. Content-Length देखील पूर्ण बफरिंगशिवाय लांबी देतो. HTTP/1.1 chunked एन्कोडिंग टप्प्याटप्प्याने डिलिव्हरीला परवानगी देते, परंतु आधीचा घटक डेटा धरून ठेवल्यास कमी विलंबाचे वचन देऊ शकत नाही.

त्यानंतर प्रक्रिया टप्पे तपासा. पुनर्लेखन किंवा तपासणीसाठी बॉडीचा भाग किंवा संपूर्ण बॉडी लागू शकते. कॉम्प्रेशन आणि अ‍ॅप्लिकेशन फ्रेमिंग उपयुक्त आउटपुट उशिरा करू शकतात. क्लायंटवर संपूर्ण बाइट अरेची वाट पाहणारी पद्धत उशिरा परतते, आणि ब्राउझर दाखवण्यापूर्वी बाइट्स घेऊ शकतो.

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