क्या दो प्रॉक्सी एक फ़ाइल तेज़ी से डाउनलोड कर सकते हैं?

दो प्रॉक्सी एग्ज़िट, जिनमें से प्रत्येक के पास अतिरिक्त बैंडविड्थ है, डाउनलोड की गति दोगुनी करने का आसान तरीका लगते हैं। सामान्य प्रॉक्सी पूल इस तरह काम नहीं करता।

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

सामान्य कनेक्शन-आधारित मल्टी-वान संतुलन की भी ऐसी ही सीमा है। यह अलग-अलग कनेक्शनों को लिंकों पर फैला सकता है, जिससे कुल क्षमता बढ़ती है या प्रतिस्पर्धा घटती है। एक कनेक्शन एक ही कनेक्शन रहता है, जब तक कोई अन्य तंत्र स्पष्ट रूप से कई पथ न दे।

जब समानांतर डाउनलोड अलग बात हों

क्लाइंट किसी फ़ाइल की अलग-अलग श्रेणियाँ अलग कनेक्शनों पर माँगकर स्थानीय रूप से जोड़ सकता है। अगर क्लाइंट इस व्यवस्था का समर्थन करता है और सर्वर अनुरोधों की अनुमति देता है, तो यह एक से अधिक मार्ग का उपयोग कर सकता है।

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

क्लाइंट तक का अंतिम मार्ग अब भी मायने रखता है। कई तेज़ एग्ज़िट किसी एक भरी हुई एक्सेस लिंक से उतना ही डेटा भेज सकते हैं जितना वह लिंक उठा सकती है, उससे अधिक नहीं।

मल्टीपाथ को वास्तविक समर्थन चाहिए

Multipath TCP एक स्पष्ट परिवहन तंत्र है जो अपने अंतिम बिंदुओं और नेटवर्क व्यवस्था के समर्थन करने पर कई उप-स्ट्रीमों का उपयोग करके कनेक्शन ले जा सकता है। केवल दो असंबंधित HTTP या SOCKS प्रॉक्सी सूचीबद्ध करने से यह सक्रिय नहीं होता।

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