dollar
@dollar
Делай добро и бросай его в воду.

Как программно решить проблему потери пакетов или хотя бы сгладить её?

Предположим есть некий провайдер с хорошим каналом, через который осуществляется доступ в Интернет, другого нет, но в остальном нет финансовых ограничений (арендовать сервер и т.п.). У провайдера стабильно 50% потерь пакетов (без нагрузки со стороны пользователя), что сказывается на многом.

Можно ли как-то снизить этот процент программными средствами?

Например, предположу, что теоретически каждый пакет можно каким-то образом отправлять дважды (избыточность). Тогда шанс потери будет уже не 50%, а 25%. Возможно такое?
  • Вопрос задан
  • 397 просмотров
Решения вопроса 1
ValdikSS
@ValdikSS
Попробуйте kcptun, он создан как раз для таких ситуаций.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 5
Rsa97
@Rsa97
Для правильного вопроса надо знать половину ответа
В TCP пакеты и так перепосылаются при недоставке.
В UDP тупо перепосылать пакеты нельзя. Поскольку сам UDP не предусматривает контроль за доставкой, то два одинаковых пришедших UDP-пакета могут быть поняты как два независимых запроса/команды.
Ответ написан
mayton2019
@mayton2019
Bigdata Engineer
Дело в том что нельзя решать проблемы TCP находясь выше уровня TCP.

Сами потери пакетов этот протокол решает повторной пересылкой (TCP Retransmission).
Тоесть технически это уже решено в самом протоколе. Разумеется не безплатно и ценой
потери времени. Когда у вас примерно 50% теряется - это ситуация "очень плохо".

Так работать нельзя и нужно решать эту проблему именно в том месте где она возникает. Если
это физический уровень то надо менять кабели (антены) или если это работа шейперов и firewalls
то решать это соотв там.

По поводу удвоения трафика и избыточности. Можно использовать различные коды Хемминга и РидаСоломона
но они требуют буфера. Причем если единица потери у вас это TCP-пакет то для удачного восстановления
надо хотя-бы передать 1000 пакетов оснащённых кодами восстановления (и при этом гарантировать
что ретрансмиссий не будет ибо они не нужны) и на выходе где-то (интересно где?) их всех собрать
в один массив и быстринько проверить что инфы для восстановления уже достаточно чтоб пролечить
потерянный пакет. Как это сделать - ума не приложу. Но это полюбому будет на уровне IP/UDP
и это совершенно новый протокол. Крайне ресурсоёмкий по памяти и с длинным лагом по TTFB.

Вобщем схема очень напоминает скачивание большого торрент-файла по UDP в условиях рандомного порядка
следования чанков этого самого файла. Кому такая схема нужна? Это нединамично и неотзывчиво. Никаких онлайн
игр и стриминга тут нельзя построить.
Ответ написан
@nApoBo3
1. Вы не совсем понимаете, что такое потеря 50% пакетов. В вашем гипотетическом сценарии, это потеря каждого второго пакета, но в реальной жизни это не так.
Удвоением кол-ва пакетов вы проблему усугубите.
2. И да, эту проблему можно для части протоколов решить программно, но не уверен, что такие решения есть в готовом виде. Вам потребуется реализовать собственный аналог tcp для ситуации с большой потерей пакетов, работающий поверх udp или более низких протоколов, плюс промежуточный прокси.
Возможно подобные решения есть, я про подобные вещи когда-то читал для нефтяники на спутниковых каналах, там были свои протоколы, для ускорения передачи данных, поскольку tcp плохо подходит для каналов с большими задержками.
Ответ написан
hint000
@hint000
у админа три руки
Попробую уточнить вопрос, как я его понял.
В UDP тупо перепосылать пакеты нельзя.
Про UDP согласен, забудем про него.
В TCP пакеты и так перепосылаются при недоставке.
Есть ли тонкие настройки (для ядра Linux и т.п.) параметров TCP, такие, чтобы минимизировать задержки при повторной отправке пакетов, ценой большей утилизации пропускной способности, когда заведомо известно о больших потерях?

Исходя из уточненной формулировки гуглим: https://www.google.com/search?q=high+tcp+packet+lo...
Попадаем сюда: xgu.ru/wiki/TCP_tuning
Потом сюда: https://www.linux.org.ru/forum/talks/10310095
И сюда: https://habr.com/ru/post/168407/
И, наконец, попытаемся призвать в топик самого ValdikSS , может быть с момента публикации статьи появилось что-то новое по этой теме.

Собственно,
sysctl -w net.ipv4.tcp_congestion_control=westwood
Ответ написан
Комментировать
@Drno
Нет, не возможно.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы