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

Question

[dollar]

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

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

Например, предположу, что теоретически каждый пакет можно каким-то образом отправлять дважды (избыточность). Тогда шанс потери будет уже не 50%, а 25%. Возможно такое?

Comments

[pfg21]

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

[Akina]

есть некий провайдер с хорошим каналом
...
У провайдера стабильно 50% потерь пакетов

Вот как-то канал с половиной потерь никогда не считал хорошим...

[dollar]

Akina, я имел в виду с широким, а природа потерь может быть иная. Например, CPU 100% на узле, или что-то искусственное типа rand()%2.

Answer 1

[ValdikSS]

Попробуйте kcptun, он создан как раз для таких ситуаций.

Answer 2

[Rsa97]

В TCP пакеты и так перепосылаются при недоставке.
В UDP тупо перепосылать пакеты нельзя. Поскольку сам UDP не предусматривает контроль за доставкой, то два одинаковых пришедших UDP-пакета могут быть поняты как два независимых запроса/команды.

Comments

[dollar]

Akina, а можно ли, например, установить некое ПО типа особого VPN с избыточностью в паре с таким же ПО на своём сервере, и таким образом пересылать по несколько пакетов UDP (завёрнутых в свои пакеты, чтобы различать дубли)? Хотя бы в теории?

[Rsa97]

dollar, OpenVPN в TCP-режиме

[pfg21]

dollar, в таком случае внутрь UDP встраивать свой протокол выявления дублирующих пакетов, если уж хочется слать дублирующие пакеты, но в данных условиях это не решит проблему.

Answer 3

[mayton2019]

Дело в том что нельзя решать проблемы TCP находясь выше уровня TCP.

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

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

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

Вобщем схема очень напоминает скачивание большого торрент-файла по UDP в условиях рандомного порядка
следования чанков этого самого файла. Кому такая схема нужна? Это нединамично и неотзывчиво. Никаких онлайн
игр и стриминга тут нельзя построить.

Comments

[dollar]

Почему нельзя решать проблемы TCP находясь выше уровня TCP? Звучит красиво, но это теорема или аксиома?

Повторная пересылка пакета происходит ценой времени ожидания пакета + времени повторной пересылки. И если данных в единицу времени много, то это будет означать "подвисание" TCP соединения.

Я же гипотетически предлагаю весь трафик (включая TCP) поделить на кусочки и завернуть в другой протокол с избыточностью, в котором каждый "кусочек" пересылается дважды, а то и трижды. Пакеты в таком случае идут параллельно, и пересылка как таковая не требуется. Если все дубли не пришли, то пакет просто считается потерянным. Но из-за избыточности снижается процент потерь пакетов в целом для провайдера.

[mayton2019]

Какого пакета? TCP это стриминговый протокол. И ты не управляешь отдельными пакетами.

Это и есть стек сетевых протоколов. Ты - на прикладном уровне.

А когда ты предлагаешь заворачивать в другой протокол - ты опускается на уровень ниже. Это то о чем я говорил.

Answer 4

[nApoBo3]

1. Вы не совсем понимаете, что такое потеря 50% пакетов. В вашем гипотетическом сценарии, это потеря каждого второго пакета, но в реальной жизни это не так.
Удвоением кол-ва пакетов вы проблему усугубите.
2. И да, эту проблему можно для части протоколов решить программно, но не уверен, что такие решения есть в готовом виде. Вам потребуется реализовать собственный аналог tcp для ситуации с большой потерей пакетов, работающий поверх udp или более низких протоколов, плюс промежуточный прокси.
Возможно подобные решения есть, я про подобные вещи когда-то читал для нефтяники на спутниковых каналах, там были свои протоколы, для ускорения передачи данных, поскольку tcp плохо подходит для каналов с большими задержками.

Comments

[dollar]

1. 50% потерь показывает ICMP. Хотите сказать, что среди UDP пакетов будет при этом не 50% потерь? Про TCP я знаю, что он решает проблему пересылкой, но некое подобие VPN предполагает, что тот же TCP (и любой другой протокол выше сетевого) заворачивается программно, а потом снова пересылается через тот же TCP/UDP. И на этапе этого заворачивания можно придумать всякие штуки типа избыточности. На самом деле это самое простое, что приходит в голову, поэтому это наверняка либо есть, либо есть объяснение, почему так нельзя.

2. Почему только для части протоколов? Я же в вопросе ищу решение для всего трафика в целом, со всеми включёнными в него протоколами. Моя идея была, что в общем случае канал не используется на 100% и можно увеличить количество пересылаемых данных, уменьшив тем самым величину случайных потерь. Конечно, для чего-то типа торрентов это не сработает (да и не потребуется), но почти для всего остального должно сработать. Собственный протокол - слишком круто, но мне кажется, идея избыточности слишком проста, поэтому о создании своего протокола уже думали раньше и не раз.

[nApoBo3]

Потеря 50% для ICMP говорит лишь о том, что до вас в 50% случае не доходят ICMP ответы, возможно они не доходят до получателя, возможно не возвращаются к вам, возможно получатель не считает нужным все их обрабатывать. ICMP вообще слабо отражает реальный процент потерь пакетов или "переотправок" в TCP.

Борьба с потерей пакетов не универсальна и требует понимания причины потерь.
Простой пример, у вас потеря пакетов из-за перегрузки промежуточного оборудования. Вы отправляете на него 1000 пакетов в секунду, а оно может переварить только 500, а другие 500 "теряет", вы предлагаете начать отправлять на него 2000 пакетов в секунду, как решение проблемы, типа 1000 долетит, но нет, у вас просто станет теряться уже не 500 пакетов, а 1500. Плюс, потеря пакетов часто происходит пачками, т.е. не 50% через одного, а 1000 прошла, а потом 1000 потерялась.( с таким я не встречался, но и 50% это полностью не годный гипотетический канал, даже на 10% уже работать практически невозможно ), у вас просто ПО начнет в таком сценарии по таймауту отваливаться, например тот же DNS.

Answer 5

[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

Answer 6

[Drno]

Нет, не возможно.