Ĉu du prokuroj povas elŝuti unu dosieron pli rapide?

Du prokur-elirejoj, ĉiu kun libera bendolarĝo, ŝajnas facila maniero duobligi la rapidon de elŝuto. Ordinara prokuraro ne funkcias tiel.

Kliento malfermas konekton tra unu elektita prokuro. Tiu prokuro malfermas la pluan konekton. Aldoni alian adreson el prokur-listo al la provizo donas al estontaj konektoj alian elekton; ĝi ne enmetas la duan prokuron en la bajtan fluon jam okazantan.

Ordinara konekto-bazita mult-WAN balancado havas similan limigon. Ĝi povas disdoni malsamajn konektojn inter ligiloj, plibonigante la totalan kapaciton aŭ malpliigante konkuradon. Unu konekto restas unu konekto, krom se alia meĥanismo eksplicite provizas plurajn vojojn.

Kiam paralelaj elŝutoj estas alia afero

Kliento povas peti malsamajn intervalojn de dosiero tra apartaj konektoj kaj kunmeti ilin loke. Tio povas uzi pli ol unu vojon, se la kliento subtenas tiun aranĝon kaj la servilo permesas la petojn.

Tio enkondukas postulojn: la intervaloj devas priskribi la saman prezenton, la respondoj de la servilo devas kongrui kun la petitaj deŝovoj, kaj ŝanĝoj al la objekto ne rajtas produkti miksitan dosieron. Aŭtentikigo, limoj de la servilo kaj politikoj por ĉiu elirejo ankaŭ povas igi paralelajn intervalpetojn neaŭgaj. Dek kompletaj elŝutoj ne estas dek pecoj de unu elŝuto.

La fina vojo al la kliento ankoraŭ gravas. Pluraj rapidaj elirejoj ne povas sendi pli da datumoj tra unu saturita alirligilo ol tiu ligilo povas porti.

Multvojo bezonas veran subtenon

Multipath TCP estas eksplicita transporta meĥanismo, kiu povas porti konekton per pluraj subfluoj, kiam ĝiaj finpunktoj kaj la reta aranĝo subtenas tion. Ĝi ne aktiviĝas simple listigante du ne rilatajn HTTP aŭ SOCKS prokurojn.

Ĉe malrapida transigo, unue determini ĉu la plafono estas ĉe la klienta ligilo, la prokuro, la plua vojo aŭ la celo. Provizo utilas por disdonado de konektoj. Traktu aserton pri duobligo de la rapido de unu dosiero kiel apartan funkcion, kiu bezonas sian propran meĥanismon kaj pruvojn.