दोन प्रॉक्सी एक फाइल जलद डाउनलोड करू शकतात का?

प्रत्येकाकडे अतिरिक्त बँडविड्थ असलेले दोन प्रॉक्सी एक्झिट डाउनलोडचा वेग दुप्पट करण्याचा सोपा मार्ग वाटतात. पण सामान्य प्रॉक्सी पूल असे काम करत नाही.

क्लायंट निवडलेल्या एका प्रॉक्सीमधून कनेक्शन उघडतो. ती प्रॉक्सी पुढील कनेक्शन उघडते. प्रॉक्सी यादीमधील दुसरा पत्ता पूलमध्ये जोडल्याने भविष्यातील कनेक्शनना आणखी एक पर्याय मिळतो; त्यामुळे दुसरी प्रॉक्सी आधीच सुरू असलेल्या बाइट प्रवाहात जोडली जात नाही.

सामान्य कनेक्शन-आधारित मल्टी-वान संतुलनालाही अशीच मर्यादा आहे. तो वेगवेगळी कनेक्शन लिंकवर पसरवू शकतो, ज्यामुळे एकूण क्षमता सुधारते किंवा स्पर्धा कमी होते. दुसरे कोणतेही यंत्रणा स्पष्टपणे अनेक मार्ग देत नाही तोपर्यंत एक कनेक्शन एक कनेक्शनच राहते.

जेव्हा समांतर डाउनलोड वेगळी गोष्ट असते

क्लायंट एका फाइलच्या वेगवेगळ्या श्रेणी वेगळ्या कनेक्शनवर मागून त्या स्थानिक पातळीवर जोडू शकतो. क्लायंटने ही रचना समर्थित केली आणि सर्व्हरने विनंत्या अनुमत केल्या तर तो एकापेक्षा जास्त मार्ग वापरू शकतो.

त्यामुळे काही अटी येतात: श्रेणींनी तीच प्रस्तुती वर्णन करणे आवश्यक आहे, सर्व्हरची उत्तरे मागितलेल्या ऑफसेटशी जुळली पाहिजेत, आणि ऑब्जेक्टमधील बदलांमुळे मिश्रित फाइल तयार होऊ नये. प्रमाणीकरण, सर्व्हरच्या मर्यादा आणि प्रत्येक एक्झिटची धोरणे यामुळेही समांतर श्रेणी विनंत्या अयोग्य होऊ शकतात. दहा पूर्ण डाउनलोड एका डाउनलोडचे दहा तुकडे नाहीत.

क्लायंटपर्यंतचा अंतिम मार्ग अजूनही महत्त्वाचा आहे. अनेक वेगवान एक्झिट एका भरलेल्या प्रवेश लिंकमधून ती लिंक वाहून नेऊ शकेल त्यापेक्षा जास्त डेटा पाठवू शकत नाहीत.

मल्टीपाथला खरे समर्थन लागते

Multipath TCP ही एक स्पष्ट वाहतूक यंत्रणा आहे जी त्याचे टोक आणि नेटवर्क रचना समर्थित करतात तेव्हा अनेक उप-प्रवाहांद्वारे कनेक्शन वाहू शकते. फक्त दोन असंबंधित HTTP किंवा SOCKS प्रॉक्सी सूचीबद्ध केल्याने ते सक्रिय होत नाही.

हळू हस्तांतरणासाठी प्रथम मर्यादा क्लायंट लिंकवर आहे, प्रॉक्सीवर आहे, पुढील मार्गावर आहे की गंतव्यस्थानावर हे ठरवा. पूल कनेक्शन वाटण्यासाठी उपयुक्त आहे. एका फाइलचा वेग दुप्पट होतो या दाव्याकडे स्वतःची यंत्रणा आणि पुरावे लागणारे वेगळे वैशिष्ट्य म्हणून पाहा.