«Скорость» Интернета зависит не только от того, что вам дает ваш провайдер, но и от того, что вам дают серверы, а последнее не зависит от вашего провайдера, поэтому независимо от того, сколько вы платите за Интернет, некоторые сайты (большинство) не сильно улучшатся. Единственный раз, когда я действительно вижу потенциал соединения, это когда загружаешь (совершенно легальный) торрент с большими файлами и большим количеством сидов, например, копию Ubuntu, у серверов больше пропускной способности, чем они вам дают, они просто сохраняют ее для других пользователей.
Я хочу узнать, как использовать несколько прокси-серверов для доступа к серверу из разных точек одновременно, тем самым получая большую общую скорость, а затем разбить данные и направить их обратно по основному соединению (я, возможно, не очень хорошо это объясняю, но кто-то может понять, о чем я говорю). Желательно, чтобы это работало со всеми протоколами, не только для просмотра веб-страниц, но и для сторонних приложений, игр и т. д.
решение1
Вы не можете - Интернет не работает так, как вам бы хотелось - в частности
- Ни UDP, ни TCP не предлагают встроенных механизмов для разделения трафика, что делает универсальное решение нереалистичным.
- Интернет-провайдеры обычно используют входные и выходные фильтры для предотвращения маршрутизации IP-адресов, не являющихся исходными/целевыми через их сеть, — для предотвращения определенных типов атак (что делает универсальное решение нереалистичным).
- Скорость вашего соединения зависит от ряда факторов, помимо скорости вашего соединения, включая задержку соединения и объем потери пакетов.
- Большинство серверов будут стараться справедливо распределять нагрузку, но не будут оставлять полосу пропускания без дела, однако они будут отдавать приоритет полосе пропускания.
- Прокси-сервер определяет исходный и целевой IP-адреса — несколько прокси-серверов будут иметь разные исходные адреса, поэтому целевой сервер будет обрабатывать их как разные сеансы (правильно)
решение2
Это не совсем жизнеспособный подход с точки зрения клиента. Я не верю, что есть какие-либо технологии, которые поддерживают описанную вами технику.
Во-первых, для загрузок, HTTP/FTP загрузки являются единым двоичным потоком ответа, поэтому данные, которые вы загружаете, приходят в результате одного запроса. Если сервер поддерживает PARTIAL CONTENT (206), то вы можете организовать систему, в которой вы устанавливаете несколько загрузок с вычисленным смещением и длиной, чтобы сделать это через несколько соединений, но это не будет работать для каждого сервера. В любом случае, по крайней мере, механизм должен знать, что он манипулирует HTTP-соединением, поэтому он будет работать только для HTTP-данных.
Во-вторых, большинство современных веб-сайтов больше не являются просто статическими документами, а программно конструируются на стороне сервера, поэтому они часто полагаются на концепцию сеанса. Сеансы, как правило, ограничены подключением пользователя, поэтому если вы подключаетесь из двух разных мест, это два разных сеанса. Попытка составить и отобразить страницу, сделанную из Get, которые пришли из разных сеансов, будет практически невозможна, потому что у каждого сеанса есть свои собственные файлы cookie, скрипты и т. д., и существуют барьеры безопасности, призванные не дать злоумышленникам сделать то, о чем вы думаете.
В конечном итоге такой инструмент мог бы существовать, но он должен был бы обладать большим объемом протокольного интеллекта (чтобы он мог переписывать данные, специфичные для протокола, для использования других соединений через другие пути) и был бы ограничен в своих возможностях по перенаправлению изолированных GET-запросов на другие соединения из-за ограничений, налагаемых серверными протоколами и операциями.