શું બે પ્રોક્સી એક ફાઇલને વધુ ઝડપથી ડાઉનલોડ કરી શકે?

બે પ્રોક્સી એક્ઝિટ, દરેકમાં વધારાની બેન્ડવિડ્થ હોય એમ, ડાઉનલોડની ઝડપ બમણી કરવાનો સહેલો રસ્તો લાગે છે. સામાન્ય પ્રોક્સી પૂલ એમ કામ કરતો નથી.

ક્લાયન્ટ એક પસંદ કરેલી પ્રોક્સી દ્વારા કનેક્શન ખોલે છે. તે પ્રોક્સી આગળનું કનેક્શન ખોલે છે. પ્રોક્સી યાદીમાંથી બીજું સરનામું પૂલમાં ઉમેરવાથી ભવિષ્યના કનેક્શનને બીજો વિકલ્પ મળે છે; તે બીજી પ્રોક્સીને પહેલેથી ચાલુ બાઇટ સ્ટ્રીમમાં જોડતું નથી.

સામાન્ય કનેક્શન-આધારિત મલ્ટી-વાન સંતુલનની પણ એવી જ મર્યાદા છે. તે જુદા જુદા કનેક્શનને લિંક વચ્ચે વહેંચી શકે છે, જે એકંદર ક્ષમતા સુધારે છે અથવા સ્પર્ધા ઘટાડે છે. બીજી કોઈ પદ્ધતિ સ્પષ્ટપણે અનેક માર્ગ ન આપે ત્યાં સુધી એક કનેક્શન એક કનેક્શન જ રહે છે.

જ્યારે સમાંતર ડાઉનલોડ અલગ વાત છે

ક્લાયન્ટ એક ફાઇલની જુદી જુદી શ્રેણીઓ અલગ કનેક્શન પર માંગીને સ્થાનિક રીતે જોડી શકે છે. જો ક્લાયન્ટ આ ગોઠવણને સમર્થન આપે અને સર્વર વિનંતીઓને મંજૂરી આપે તો તે એક કરતાં વધુ માર્ગ વાપરી શકે છે.

તે કેટલીક શરતો લાવે છે: શ્રેણીઓએ એ જ રજૂઆતનું વર્ણન કરવું પડે, સર્વરના જવાબો માંગેલા ઓફસેટ સાથે મેળ ખાવા જોઈએ, અને ઑબ્જેક્ટમાં ફેરફારથી મિશ્ર ફાઇલ ન બનવી જોઈએ. પ્રમાણીકરણ, સર્વરની મર્યાદા અને દરેક એક્ઝિટની નીતિ પણ સમાંતર શ્રેણી વિનંતીઓને અયોગ્ય બનાવી શકે છે. દસ પૂર્ણ ડાઉનલોડ એ એક ડાઉનલોડના દસ ટુકડા નથી.

ક્લાયન્ટ સુધીનો અંતિમ માર્ગ હજી પણ મહત્વનો છે. ઘણી ઝડપી એક્ઝિટ એક ભરાયેલી એક્સેસ લિંક દ્વારા તે લિંક જેટલું લઈ જઈ શકે તેનાથી વધુ ડેટા મોકલી શકતી નથી.

મલ્ટિપાથને ખરેખર સમર્થન જોઈએ

Multipath TCP એ સ્પષ્ટ પરિવહન પદ્ધતિ છે જે તેના છેડા અને નેટવર્ક ગોઠવણ સમર્થન આપે ત્યારે અનેક ઉપ-સ્ટ્રીમ વાપરીને કનેક્શન લઈ જઈ શકે છે. ફક્ત બે અસંબંધિત HTTP કે SOCKS પ્રોક્સીની યાદી બનાવવાથી તે સક્રિય થતું નથી.

ધીમા સ્થાનાંતરણ માટે પહેલાં નક્કી કરો કે મર્યાદા ક્લાયન્ટ લિંક પર છે, પ્રોક્સી પર છે, આગળના માર્ગ પર છે કે ગંતવ્ય પર. પૂલ કનેક્શન વહેંચવા માટે ઉપયોગી છે. એક ફાઇલની ઝડપ બમણી કરવાના દાવાને એવી અલગ વિશેષતા તરીકે ગણો જેને પોતાની પદ્ધતિ અને પુરાવા જોઈએ.