А почему так трудно реализовать балансировку интернет-соединения программно для домашнего роутера?

торренты в /dev/null качать

Пользователи с лимитом на трафик будут весьма рады /s.

юзер сидит на канале А

А как оно поймет скорость А, если юзер там википедию читает?

На так ты сядь, напиши код, попользуйся и тогда осознаешь проблемы, а не в носу ковыряй

то что ты хочешь - 10 строк скрипта на шелле, который дергает iperf или speedtest и по результатам вызывает route del default, route add default

но вероятно результат всего этого тебя не устроит, потому что обычно люди хотят стабильное быстрое соединение из двух не очень стабильных и быстрых :)

А надо посмотреть, может, squid так может - тогда для http покатит.

Я всегда думал, что такое уже давно есть.

Ну, во-первых, как уже сказали, сложно определять текущую скорость, во-вторых нельзя просто взять и переключить сетевой интерфейс, если отключить старый, разорвутся текущие соединения, ну и естественно сменится айпи адрес, что может сбить с толку некоторые приложения. Но такие решения есть, я видел даже для openwrt. Есть даже кое-что покруче, что-то типа vpn до сервера в интернете, который гонит пакеты по обеим линкам, что фиксит проблему со сменой айпи и обрывом коннекта. Пользовался таким проприетарным решением, но и опенсорсные есть.

Результат не устроит потому что ему будет дропать коннекты в момент переключения.

А никто не пробовал сделать bond из нескольких туннельных интерфейсов, которые работают через разных провайдеров за счёт например, policy routing (по портам назначения), но при этом через один и тот же удалённый туннельный выходной хост ?

squid точно может балансировку апстрим проксей, у меня их 3, но на счёт правил по которым он это делает я не уверен, возможно просто round-robin

Если скорость на канале Б 10 Мбит/с, а на канале А 1 Мбит/с

Когда 10 Мбит/с - это значит зима на дворе.
Когда 1 Мбит/с - это значит лето пришло
Когда 100 Kбит/с - это значит лето и выходной день.

Каждый год одна и та же пытка. Приезжает туча дачников со своими мобилками и забивают напрочь канал единственной вышки на всю округу. Вероятно даже ничего не качая сознательно, просто самим фактом постоянных разговоров мобилок по интернетам.

Ничего нельзя сделать. Хоть замониторься.

А как оно поймет скорость А, если юзер там википедию читает?

глубокий анализ пакетов dpi пусть делает

Wireguard две симки, два модема в одном роутере в суммированием. (комментарий)

Может у него своя as есть 😊

ЯННП, ну забил у вас юзер канал A, вы переключаете его на Б, он забивает канал Б, вы опять переключаете на А. Вот и какой смысл в этих шаманских переключениях?

но и опенсорсные есть.

Вроде даже здесь кто-то тему поднимал.

Вы качаете mp3 с тырнета. С канала А. Скорость у вас 1 Мбит/с, всё долго, муторно. Отошли, грубо говоря, в сортир. Mp3шка докачалась, Роутер быстренько зачекал скорость на канале А, сравнил со скоростью канала Б, переключился на Б. Вы возвращаетесь из сортира… и обнаруживаете, что mp3 начали качаться в 10 раз быстрее.

Профит!

Потому, что в TCP нет такого понятия, как «переключить соединение». В TCP есть адрес одной стороны и адрес второй стороны и в рамках соединения они не могут меняться.

С UDP такое можно пытаться делать, но нужна поддержка с другой стороны, чтобы они принимали пакеты от любого IP, т.е. это тоже не в любом приложении будет работать, а только в специально подготовленном.

Что реально можно делать в теории:

1. Арендуешь сервер.

2. Устанавливаешь несколько VPN-соединений к нему. По одному для каждого твоего провайдера.

3. Далее весь твой трафик идёт через этот VPN. А для конечной точки весь трафик идёт от указанного сервера, каким бы путём к этому серверу не пришёл пакет.

4. Сервер и твой клиент отслеживают состояние каждого VPN-соединения и вот они уже могут балансировать пакеты нужным образом.

На практике я не слышал про такие решения. Но протоколы позволяют это делать и это будет совместимо. Наверняка кто-то делал.

Кароч, я понял, одним роутером сделать не выйдет, нужна ещё специальным образом настроенная VPS

И чем оно поможет?

Поймём, что пользователь Википедию читает.

Я думаю и даже уверен, что есть роутеры, которые делают балансировку нескольких апстримов, по крайней мере быстрый гугл находит множество советов этого рода. Просто надо понимать, что одно соединение всегда пойдёт через одного провайдера. Т.е. если ты начал качать mp3 в браузере и он пошёл через медленного провайдера, то он так и будет оттуда качать, пока не докачает или не вернёт ошибку. Но если ты качаешь торрент, где закачка идёт кусками через множество пиров, то это уже получится раскидать на нескольких провайдеров и в теории ты будешь качать с суммарной скоростью.

Допустим, пусть хотя бы канал переключит, бог уж с ней, с суммарной скоростью.

Понятно, что раз уж пользователь начал качать mp3/смотреть кинцо - пусть докачивает/досматривает, тут вряд ли что-то можно придумать. А вот если читает википедию - можно и канал переключить, да и соединение, так-то, можно разорвать, это не будет слишком болезненно для юзера. Скорее всего, там вся страница закешировалась моментально.

Допустим ты понял, что юзер читает википедию, как ты сравнишь толщину а и б?

Если пользователь читает википедию, можно смело стартовать закачку торрентов, из А, а потом из Б - юзер не заметит ничего.

Для начала попробуй надежно определить лежит канал или нет :)
Даже это нифига не простая задача. Потому что канал может как-то работать, и даже на большой скорости, но реальная связность есть только с 20% интернета. Это считается канал работает или нет?

Да, это проблема. Но, решаемая. Мы же про домашний роутер говорим. Собирая статистику, мы запросто можем обнаружить, что юзер использует в своей жизни 0.00001% от всего интернета, и тупо пропинговать всю эту сотню адресов.

Торренты могут несколько минут раскачиваются, за это время юзер успеет на ютюбчик уйти.

Понял ещё меньше. Вы предлагаете мерять скорость при не загруженном канале?

Ну, тогда сделать, как это делает спидтест. Чтоб побыстрее.

Понял ещё меньше. Вы предлагаете мерять скорость при не загруженном канале?

Да

Так оно в договоре должно быть прописано, а в случае если оно отличается от того, что прописано в договоре, то это повод стучать по голове прову, а не автоматизировать переключение каналов.

Адреса могут не пинговаться, и это нормально. Они имеют полное право отвечать только на определённые пакеты, содержимое которых ты заранее не знаешь. Например, esp пакеты.

Когда 10 Мбит/с - это значит зима на дворе.

Когда 1 Мбит/с - это значит лето пришло

Когда 100 Kбит/с - это значит лето и выходной день.

Ну, и толку стучать по голове прову? Он скажет, «Оптимизация запланирована на 2050 год»

Но, имея на руках список адресов, доступность их как-то же можно определить, не так ли?

Готов спорить, что в договрое написано "до NNN Кбит/сек"

Ну, и толку стучать по голове прову?

А вы пробовали? А то пока все сидят и думают, что оно само рассосется, пров тоже не особо прыгать будет.

А у меня проблемы, как в ОП, в принципе не стоит. У меня 100 мбит/с по проводу, и удовлетворяет на 150%.

Мне техническая проблема реализации интересна.

Но, имея на руках список адресов, доступность их как-то же можно определить, не так ли?

Не всегда.

В домашнем на 99.999999% да. Но если у вас весь инет внезапно становиться 1кбит/с, то поинтересоваться у прова на тему WTF? все-таки стоит.

Если они умышленно прячутся, определить их доступность затруднительно. Разве что наблюдать за пакетами которые идут через твой маршрутизатор.
Та же фигня с шириной канала: часто важна скорость до определённых узлов, а ее торрентами ты не измеришь. Особенно если они не откликаются на запросы случайных посетителей.

Про технические грабли здесь уже вроде все описали. Переключение канала чревато потерей установленных соединений. А через какое время то или иное соединение будет установлено заново зависит от конкретных реализаций и от таймаутов системы.

Потому, что в TCP нет такого понятия, как «переключить соединение». В TCP есть адрес одной стороны и адрес второй стороны и в рамках соединения они не могут меняться.

Я, конечно, админ локалхоста… но четверть 21 века уже почти прошла. IPv6 на дворе. TCP соединение, исходящее из компа или сервера и проходящее через роутер по одному из двух (или более) маршрутов, не меняет адреса сторон. Разве не так?

P. S. Хотя обратные пакеты, видимо, будут возвращаться всегда одним маршрутом.

Не всегда.

А это как? Т.е. интернет у пользователя есть, а программно доступность адреса мы проверить не можем?

У себя использую скриптик, который в цикле пингует гуглоDNS через разные интерфейсы. Таймаут пинга - интерфейс мертв. По результатам скана строится строка для route replace с наличием или отсутствием нужных маршрутов, а также нужными «весами». Каналы обычно используются параллельно, приоритеты можно менять на ходу.

Дальше уже можно играть приоритетами по тем или иным факторам. Например, часть скрипта - контроль трафика на определенном интерфейсе (куда воткнут роутер мобильного оператора) и где меняется приоритет интерфейса по достижению примерно 3 ГБ трафика (у оператора при этом сильно снижается предельная скорость до полуночи - особенность тарифа).

При желании можно сделать обвязку и регулировать вес интерфейса по результатам speedtest'а, например.

Если они умышленно прячутся, определить их доступность затруднительно. Разве что наблюдать за пакетами которые идут через твой маршрутизатор.

Идут же. Значит, можно.

Та же фигня с шириной канала: часто важна скорость до определённых узлов, а ее торрентами ты не измеришь

Но, список определённых узлов у нас же есть. Значит, и измерить можно.

У себя использую скриптик, который в цикле пингует гуглоDNS через разные интерфейсы. Таймаут пинга - интерфейс мертв. По результатам скана строится строка для route replace с наличием или отсутствием нужных маршрутов, а также нужными «весами». Каналы обычно используются параллельно, приоритеты можно менять на ходу.

Вон, мне выше написали,

Адреса могут не пинговаться, и это нормально. Они имеют полное право отвечать только на определённые пакеты, содержимое которых ты заранее не знаешь. Например, esp пакеты.

Значит, вы неправильно делаете?

Нет, IPv6 ещё не на дворе для очень многих людей. Хотя это не имеет значение в контексте данного вопроса.

В конечном счёте соединение к серверу будет сделано от публичного адреса провайдера. У каждого провайдера свой публичный адрес. После установления соединения все пакеты, относящиеся к этому соединению, будут идти только между этими адресами.

Даже если у тебя два публичных IPv6 адреса на компьютере и ты попытаешься (через сырые сокеты, т.к. у ОС нет такого API) всунуть в существующее соединение пакет, исходящий из другого адреса, то сервер такой пакет откинет, как невалидный. TCP соединение идентифицируется по четвёрке значений (source address, source port, destination address, destination port) и никак иначе. Сменить source address нельзя. Получить один IP адрес через нескольких домашних провайдеров тоже нельзя.

На Гайдара БС стоит у Пятерочки. Это не самый восточный Королев. Я восточнее, на расстоянии 794 м от вашей БС. От нее только 2G900, голос. 4G1800 всегда был от БС у ст. Загорянская, 1447 м. Неделю назад его отключили. Далее по моему тексту. Абонслужба цитирует технарей: зона пеуверенного приема, надо ставить новое радиооборудование, срок до 18 декабря 2018 года. Правда или нет? Где и что? Вот в чем вопрос. P.S. Граница Королева и Загорянкого (Щелковский район) по ул. Ермоловой.

Вот человек жалуется, что от МТС у него дома только 2G. И да, в 2018 году ему так ничего и не починили, он ушёл на Т2.

Т.е. интернет у пользователя есть, а программно доступность адреса мы проверить не можем?

Да, это так. Например есть сервак с ресурсом/ресурсами открывающимися по port knocking, не зная «магии» для вас этот адрес недоступен. Или вариант udp когда вам в ответ на неправильный пакет ничего не говорят.