Kan to proxyar lasta ned éi fil raskare?

To proxyutgangar, kvar med ledig bandbreidd, ser ut som ein enkel måte å dobla farten på ei nedlasting. Ein vanleg proxypool fungerer ikkje slik.

Ein klient opnar ei tilkopling gjennom éin vald proxy. Den proxyen opnar den vidare tilkoplinga. Å leggja til ei anna adresse frå ei proxyliste i poolen gjev framtidige tilkoplingar eitt val til; det skøyter ikkje den andre proxyen inn i bytestraumen som alt er i gang.

Vanleg tilkoplingsbasert multi-WAN-balansering har ei liknande avgrensing. Ho kan spreia ulike tilkoplingar over lenkjer, noko som betrar samla kapasitet eller reduserer konkurranse. Éi tilkopling blir verande éi tilkopling med mindre ein annan mekanisme eksplisitt gjev fleire vegan.

Når parallelle nedlastingar er noko anna

Ein klient kan be om ulike område av ei fil over separate tilkoplingar og setja dei saman lokalt. Det kan bruka meir enn éin rute dersom klienten støttar ordninga og tenaren tillèt førespurnadene.

Det fører med seg krav: områda må skildra same representasjon, svara frå tenaren må samsvara med dei førespurde forskyvingane, og endringar i objektet må ikkje gje ei blanda fil. Autentisering, tenargrenser og reglar per utgang kan òg gjera parallelle områdeførespurnader ueigna. Ti komplette nedlastingar er ikkje ti bitar av éi nedlasting.

Den siste vegen til klienten tel framleis. Fleire raske utgangar kan ikkje senda meir data gjennom éi metta tilgangslenkje enn lenkja kan bera.

Multipath treng reell støtte

Multipath TCP er ein eksplisitt transportmekanisme som kan bera ei tilkopling med fleire understraumar når endepunkta og nettverksoppsettet støttar det. Han blir ikkje aktivert berre ved å lista to uavhengige HTTP- eller SOCKS-proxyar.

Ved ei langsam overføring bør du først finna ut om taket ligg på klientlenkja, proxyen, den vidare ruta eller destinasjonen. Ein pool er nyttig for fordeling av tilkoplingar. Handsama påstanden om å dobla farten til éi fil som ein eigen funksjon som treng sin eigen mekanisme og sine eigne prov.