Екі прокси бір файлды жылдамырақ жүктей ала ма?

Әрқайсысында бос өткізу қабілеті бар екі прокси шығысы жүктеу жылдамдығын екі еселеудің оңай жолы сияқты көрінеді. Кәдімгі прокси пулы олай жұмыс істемейді.

Клиент таңдалған бір прокси арқылы қосылым ашады. Сол прокси келесі қосылымды ашады. Прокси тізімінен тағы бір мекенжайды пулға қосу болашақ қосылымдарға тағы бір таңдау береді; ол екінші проксиді қазірдің өзінде жүріп жатқан байт ағынына қоспайды.

Қосылымға негізделген кәдімгі көп-WAN теңгерімдеуде де осындай шектеу бар. Ол әртүрлі қосылымдарды арналарға тарата алады, бұл жалпы сыйымдылықты жақсартады немесе бәсекелестікті азайтады. Басқа механизм бірнеше жолды анық ұсынбаса, бір қосылым бір қосылым болып қалады.

Параллель жүктеулер басқа мәселе болғанда

Клиент файлдың әртүрлі диапазондарын бөлек қосылымдар арқылы сұрап, оларды жергілікті түрде құрастыра алады. Клиент бұл схеманы қолдаса және сервер сұрауларға рұқсат етсе, бұл бірнеше жолды пайдалануы мүмкін.

Бұл талаптар туғызады: диапазондар бірдей көріністі сипаттауы керек, сервер жауаптары сұралған ығысуларға сәйкес келуі керек, ал нысандағы өзгерістер аралас файл тудырмауы керек. Аутентификация, сервер шектеулері және әр шығыс бойынша саясат та параллель диапазон сұрауларын жарамсыз ете алады. Он толық жүктеу бір жүктеудің он бөлігі емес.

Клиентке дейінгі соңғы жол әлі де маңызды. Бірнеше жылдам шығыс бір қаныққан қатынау арнасы арқылы сол арна көтере алатыннан көп дерек жібере алмайды.

Көпжолдылық нақты қолдауды қажет етеді

Multipath TCP — бұл шеткі нүктелері мен желілік құрылымы қолдаған кезде қосылымды бірнеше қосымша ағындар арқылы тасымалдай алатын айқын көлік механизмі. Ол екі байланыссыз HTTP немесе SOCKS проксиін тізімдеу арқылы ғана қосылмайды.

Баяу тасымалдау үшін алдымен шектеу клиент арнасында ма, проксиде ме, келесі маршрутта ма әлде межелі жерде ме екенін анықтаңыз. Пул қосылымдарды бөлу үшін пайдалы. Бір файлдың жылдамдығын екі еселеу туралы мәлімдемені өз механизмі мен дәлелін қажет ететін жеке мүмкіндік ретінде қарастырыңыз.