Можно начать с простого тезиса, что пакетики теряются даже на loopback, в пределах хоста ;)
Я вам посоветую поменять оборудование сеть и провайдера и не придумывать несуществующие проблем
Yuriy
Roman
И я хз что у вас за сеть если у вас 30% трафика теряется. Даже 3g 5% теряет. Вы там по диалапу работаете?
Никогда аварий не видели? Ну или lag из трёх портов и один из них чудит
Yuriy
SIP по вашей логике вообще работать не должен
Yuriy
Никогда аварий не видели? Ну или lag из трёх портов и один из них чудит
Аварий на проводе где исключительно udp гоняется?
Roman
У меня все например в пределах одной серверной и ничего не теряется.
В пределах серверной ещё интереснее бывает.
Roman
Я вам посоветую поменять оборудование сеть и провайдера и не придумывать несуществующие проблем
Что если я сам себе провайдер и с оборудованием у меня всё норм?
Yuriy
Что если я сам себе провайдер и с оборудованием у меня всё норм?
Тогда все ещё хуже у вас ибо вы плохой провайдер если у вас в сети даже loopback дохнет 😂
Egor
Что если я сам себе провайдер и с оборудованием у меня всё норм?
интересно, какой там у вас латенси между двумя стойками? да даже соседними серверами в одной стойке? 100-500?
Roman
Тогда все ещё хуже у вас ибо вы плохой провайдер если у вас в сети даже loopback дохнет 😂
Да нет же. Если вы хотите без потерь, то это надо довольно забавные велосипеды вроде dcb в свитчах
Yuriy
Да нет же. Если вы хотите без потерь, то это надо довольно забавные велосипеды вроде dcb в свитчах
Почему у вас на свичах теряется 30% а в гугл клауд при их софтовой сети не теряется ничего?
Roman
интересно, какой там у вас латенси между двумя стойками? да даже соседними серверами в одной стойке? 100-500?
Б-же, да причем тут лейтенси, если у нас протокол без flow control, окон и вообще какой-то обратной связи?
Snusmumriken
На самом деле, я успел попробовать заддосить одну машину маленькими udp-логами с кучи серверов, и пока нагрузки нет (меньше условно пары тысяч сообщений в секунду), оно как бы и неплохо работает, теряя разве что 2-3 процента сообщений когда ну слишком уж много прислали в данную наносекунду. А вот когда суммарный объём сообщенек за один цикл приёма превышает 64кб, то всё что сверху уже теряется, а там может быть неограниченный объём. Ах да, всё написано на луях. Поэтому переписывал всё нафиг, переводя на tcp с буферизацией на отправляющей машине, распределяем нагрузку по времени (чтобы не было потерь на бурстах). Сама передача оказывается медленнее, но хоть не надо костылить регулятор скорости.
Roman
Почему у вас на свичах теряется 30% а в гугл клауд при их софтовой сети не теряется ничего?
30% - это в случае ахтунгов. В реальности потери меньше, но даже 1% это очень заметно
Yuriy
Да нет же. Если вы хотите без потерь, то это надо довольно забавные велосипеды вроде dcb в свитчах
Отправляю по udp пакет и он... Доходит! Что я делаю не так?
Egor
Б-же, да причем тут лейтенси, если у нас протокол без flow control, окон и вообще какой-то обратной связи?
бог это я. и у меня не теряются пакеты в таких количествах, недавно смотрел. из 100 тысяч записей я потерял...хмм 10 . а может просто позже дошло. там nginx- (udp) syslog-> (udp) kafka -> CH
Yuriy
На самом деле, я успел попробовать заддосить одну машину маленькими udp-логами с кучи серверов, и пока нагрузки нет (меньше условно пары тысяч сообщений в секунду), оно как бы и неплохо работает, теряя разве что 2-3 процента сообщений когда ну слишком уж много прислали в данную наносекунду. А вот когда суммарный объём сообщенек за один цикл приёма превышает 64кб, то всё что сверху уже теряется, а там может быть неограниченный объём. Ах да, всё написано на луях. Поэтому переписывал всё нафиг, переводя на tcp с буферизацией на отправляющей машине, распределяем нагрузку по времени (чтобы не было потерь на бурстах). Сама передача оказывается медленнее, но хоть не надо костылить регулятор скорости.
Буфер же приёма можно увеличить ( хотя в случае lua сервера не помню можно ли) но у меня принимающий на go. Там буфферизация контролируемая
Roman
Отправляю по udp пакет и он... Доходит! Что я делаю не так?
Сделайте простой тест: шлем пакет с payload в виде sha256 предыдущего пакета. А на приемной стороне верифицируем цепочку
Snusmumriken
Буфер же приёма можно увеличить ( хотя в случае lua сервера не помню можно ли) но у меня принимающий на go. Там буфферизация контролируемая
У луёв надо собирать луасокет с друим размером буфера, но тем не менее, увеличение буфера это не панацея, при повышении нагрузки оно снова вылезет, нужен конкретно контроль передачи.
Roman
Буфер же приёма можно увеличить ( хотя в случае lua сервера не помню можно ли) но у меня принимающий на go. Там буфферизация контролируемая
Во-первых, ядро дропнет пакет как только места в so_rcvbuf кончится. Во-вторых, при более-менее приличном пакетрейте ядро начнет не успевать процессить прилетающие пакеты и тоже будет их дропать.
Yuriy
Сделайте простой тест: шлем пакет с payload в виде sha256 предыдущего пакета. А на приемной стороне верифицируем цепочку
Так и делаю. У меня Oauth во многих проектах работает для sip. Все работает. Ниче не теряется. Я вам больше скажу. Sip парсер выплюнет плохой пакет. У меня на это дело счётчик стоит в нескольких проектах. Так вот его значение практически везде от 0 до 2 пакетов в минуту
Snusmumriken
Roman
Так и делаю. У меня Oauth во многих проектах работает для sip. Все работает. Ниче не теряется. Я вам больше скажу. Sip парсер выплюнет плохой пакет. У меня на это дело счётчик стоит в нескольких проектах. Так вот его значение практически везде от 0 до 2 пакетов в минуту
Сколько у вас этого сипа в pps и гагабитах?
Snusmumriken
В общем, чистый udp в таких вещах, без оболочек сверху это хорошо, но только как индикатор "всё ещё норм или уже плохо" : )
Или с параллельным TCP со служебной фигнёй, по которому запрашиваются недошедшие данные.
Roman
Я гонял пачку full hd видео и оно сыпется даже на loopback. Чем выше битрейт, тем более заметны потери.
И увеличение буферов не помогает.
Yuriy
Сколько у вас этого сипа в pps и гагабитах?
5000 звонков одновременных. Умножим на 5 чтобы получить среднее количество пакетов SIP на один звонок и ещё на 100 - rtp траффик в секунду. Но там пакеты мелкие
Egor
Я гонял пачку full hd видео и оно сыпется даже на loopback. Чем выше битрейт, тем более заметны потери.
И увеличение буферов не помогает.
до скольки увеличивал? у уменя вот стоит 512kb
Snusmumriken
5000 звонков одновременных. Умножим на 5 чтобы получить среднее количество пакетов SIP на один звонок и ещё на 100 - rtp траффик в секунду. Но там пакеты мелкие
И их не так уж много, оно сжимается хорошо.
Roman
А у свитчей тоже свои буфера и как только случается микроберст и места в пакетном буфере нет, свитч тоже дропнет фрейм
Snusmumriken
Сиповый трафик.
Snusmumriken
(кодек)
Roman
5000 звонков одновременных. Умножим на 5 чтобы получить среднее количество пакетов SIP на один звонок и ещё на 100 - rtp траффик в секунду. Но там пакеты мелкие
А rtp ж бегает напрямую, а через sip proxy только сигналка
Yuriy
А при чем тут кодек?
Roman
до скольки увеличивал? у уменя вот стоит 512kb
До 16мб. Смысла мало, да и udp в ядре не так сильно оптимизирован как tcp.
Snusmumriken
А при чем тут кодек?
Ой всё, я кажись влез туда где я не очень шарю, но я смотрел вайршарком пакеты всяких айпи-телефоний в процессе разговора, и там три-пять небольших пакетов в секунду пересылалось на один завонок, и норм слышно было.
Roman
5000 звонков одновременных. Умножим на 5 чтобы получить среднее количество пакетов SIP на один звонок и ещё на 100 - rtp траффик в секунду. Но там пакеты мелкие
Так у тебя rtp бежит через тот же хост?
Yuriy
Ой всё, я кажись влез туда где я не очень шарю, но я смотрел вайршарком пакеты всяких айпи-телефоний в процессе разговора, и там три-пять небольших пакетов в секунду пересылалось на один завонок, и норм слышно было.
Все зависит от jitter буфера. Но как правило rtp сплиттятся по 20ms внутри. Сам пакет при сжатии кодека конечно будет весить меньше. Но тем не менее количество пакетов будет примерно одинаклвым
Roman
бог это я. и у меня не теряются пакеты в таких количествах, недавно смотрел. из 100 тысяч записей я потерял...хмм 10 . а может просто позже дошло. там nginx- (udp) syslog-> (udp) kafka -> CH
А как с реордерингом, например? Или, конечно же, не тестили? )))
Yuriy
И b2bua в других местах стоят.
Я в общем это все к чему:
Стресс тестами я поднимал и до 50000 звонков. Сеть ни разу не положил ни чем. Клал сами сервера b2bua , но не сеть.
Roman
И b2bua в других местах стоят.
Я в общем это все к чему:
Стресс тестами я поднимал и до 50000 звонков. Сеть ни разу не положил ни чем. Клал сами сервера b2bua , но не сеть.
Не имеет значения само количество звонков )) а вот cps - имеет ) вот к тебе разом придут эти 50к, сколько из них будет успешны?
Yuriy
Roman
Впрочем, 50к это немного, если переводить на pps
Yuriy
И все были успешными?
Да. 50000 CPS это пиковая выявленная работоспособность серверов при нагрузочном тестировании.
Все звонки прошли
На 51000 почти сервис помер но опять же не из за сети.
Yuriy
Ну, тех серверов на которы тест производился
Yuriy
Впрочем, 50к это немного, если переводить на pps
Посчитаем:
RTP траффик это 20 мс в среднем = 200 пакетов в секунду на звонок
Сигналку считать не будем так как она будет значительно меньше
200 + 50000 = 10 000 000
Roman
Yuriy
У вас 10 гигабитная сеть?
Я не помню честно говоря размер интерфейсов сетки в тестируемой среде, но я не думаю что меньше
Yuriy
мы делали тесты также и в gcloud
там ситуация скромнее - но опять же там машины сильно слабее были виртуальные.
Yuriy
и все упиралось не в сеть а в загрузку машин
Roman
Ну и от 10mpps машине будет не очень хорошо.
Yuriy
Ну и от 10mpps машине будет не очень хорошо.
ну мб ей и будет так себе - но тесты покаали что норм. Это пиковая нагрузка, но тем не менее уперлись мы не в сетевой интерфейс
Roman
Посчитаем:
RTP траффик это 20 мс в среднем = 200 пакетов в секунду на звонок
Сигналку считать не будем так как она будет значительно меньше
200 + 50000 = 10 000 000
Но это немного другой тест. Представьте что к вам ломится с invite неавторизованный пользователь и вам его надо отбить. Только ломится их в виде 1-2mpps и со всего интернета
Yuriy
Я в общем все это к ему - я к томму при упределенных условиях урон от потерь пакетов по UDP очень сильно переоценен.
Yuriy
Но это немного другой тест. Представьте что к вам ломится с invite неавторизованный пользователь и вам его надо отбить. Только ломится их в виде 1-2mpps и со всего интернета
Я естно говоря ни разу не наблюдал такого ddos
Я баню тех кто больше 5 раз в секунду такое делает
Roman
Я в общем все это к ему - я к томму при упределенных условиях урон от потерь пакетов по UDP очень сильно переоценен.
Это если кодек умеет хендлить потери. Собственно, что gsm, что всякие ilbc/729/723 умеют жить с потерями.
Roman
Egor
у меня наружу только 80 и 443 порты смотрят .
Yuriy
Это если кодек умеет хендлить потери. Собственно, что gsm, что всякие ilbc/729/723 умеют жить с потерями.
Все умеют жить с потерями. Это толкьо ан качество данных будет влиять и на комфорт слушания
729 ткровенно говоря себе дороже ииспользвать ибо он очень сильно грузит систему при транскодинге котороый на b2bua случается довольно часто
Roman
нет
Прилетит тебе udp с invite, а src addr там будет 8.8.8.8, например ))
Или одного из твоих sip peer
Yuriy
Вообще вопрос того как банить - решать можно по разному.
И он реается по разному.
Очень многие улетаеют еще не доходя до аутентификации ибо мозгов подменить user-agent Хедер не хватает поменять
Yuriy
Прилетит тебе udp с invite, а src addr там будет 8.8.8.8, например ))
Или одного из твоих sip peer
Так а что мне 8.8.8.8 на sip уровне?
Roman
Вообще вопрос того как банить - решать можно по разному.
И он реается по разному.
Очень многие улетаеют еще не доходя до аутентификации ибо мозгов подменить user-agent Хедер не хватает поменять
А толку? Ты все равно этот пакет должен поднять в приложение, чтобы оно решило что там что-то не так
Yuriy
А толку? Ты все равно этот пакет должен поднять в приложение, чтобы оно решило что там что-то не так
ну так оно решит, посмотрит что такой IP есть в бан листе и не пойдет с нимм дальше.
kamailio/opensips сложно такими штуками положить
Roman
Так а что мне 8.8.8.8 на sip уровне?
Я как пример, что адрес может быть любым и верить ему нельзя.
Roman
Yuriy
Инетерсно что быстрее помрет - кам или сетевой интерфейс