#dev (ilita) | Обсуждение разработки I2Pd | i2pd development discussion | http://i2pd.website/

orignal рестарт илиты через 10 минут

Vort paste.i2pd.xyz/?14a18ccba2ea15ef#ArgqkVQuCH3iH5KioYZ2YYUff4jvYm83Hc4CF1ukmhrM

Vort ^ удалось довольно хорошо пронаблюдать волну количества коннектов от атаки/перегрузки i2p

Vort график у меня общий для Tor и I2P, поэтому общее количество коннектов большое

Vort на графике нагрузки CPU картина примерно такая же

Vort похоже, что импульс перегрузки был относительно короткий - возможно, полчаса

Vort остальные два часа - это уже эффект последствий

Vort никаких признаков нестабильностей перед импульсом не видно, из чего можно делать вывод об его искусственном происхождении

Vort вот что мне волна на графике напомнила: electronics-tutorials.ws/wp-content/uploads/2018/05/filter-fil42.gif

Vort выход интегратора с прямоугольным сигналом на входе

Vort вот картинка ещё более похожая: mbfys.ru.nl/~robvdw/DGCN22/PRACTICUM_2011/LABS_2011/ALTERNATIVE_LABS/Lesson_12.html#22

orignal ну и какой практический вывод?

orignal таки атакуют?

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

Vort ещё один практический вывод - сеть усиливает начальный импульс, этот эффект надо стараться минимизировать

Vort вполне может быть, что многие из источников такого усиления последними изменениями уже убрали, но не помешает поискать ещё

Vort есть один, "дикий" метод поиска импульсов - можно включать debug логи, собирать данные и затем выводить графики по количеству каждого из типов сообщений

Vort затем на графиках искать шипы и прямоугольники

Vort понятно, что часть всплесков будут от эха атаки, но самый чёткий всплеск (не сглаженный) может быть непосредственно из источника атаки

orignal ну даже если мы найдем источник атакаи и обнарудим пачку ротуеров через тор

orignal что это изменит?

Vort мы сможем понять механизмы усиления

Vort поняв, какими именно запросами гадят

orignal так очвевидно же что тоннелями

Vort так тоннели ведь и сама сеть генерирует когда рейт просаживается

Vort как понять, где туннели-источник, а где туннели-эхо ?

orignal мне не кажется что сеть генериурет столько даже при нулевом рейте

orignal зато илита с последними коммитами можно сказать эталон стабильности

orignal а что с тем числом про которое дед говорит?

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

Vort но с определённого момента построения будут постоянные

Vort короч туннели могут быть эхом

orignal но у если ноль

orignal там же все равно запросов не многоэ

orignal 6 запросов в 10 секунд типа того

orignal но никак не тцсчи св секунду

orignal да простроения будут постоянные но они лимитированны

Vort про альфу: подозреваю, что какое значение туда ни вставляй, всё равно будет неправильно

onon1 m_AckDelay (local.GetOwner ()->GetStreamingAckDelay ())

onon1 Что такое GetStreamingAckDelay как считается?

Vort "<~orignal> там же все равно запросов не многоэ" - если мы предполагаем, что атаки в какой-то момент нету, то можно на абсолютное значение не смотреть. достаточно наблюдать прыжок количества

Vort ну а прыжок в 2-3 раза мне не кажется чем-то фантастическим

orignal onon1 это таймер такой

orignal получили мы пакет мы не остылаем акк сразу а ждем некотрое время в надежде на то что пойдет пакет в другую сторону и мы к нему акк присабичм

orignal Vort прыжок в 2-3 раза не объясняет десятки тысяч транзитов

onon1 У нас сримы, в основном, однонаправленные, что мы кроме ACKов шлем на принимающей стороне?

Vort orignal: я думаю, что десятки тысяч - это абьюз. то есть, не атака, а пофигизм. а вот прыжок в 2-3 раза - атака

Vort orignal: про альфу это наверно тебе думать. я могу, если хочешь, перевести S(RTT) на double и поменять альфу. но эффекты предсказывать не возьмусь

orignal onon1 как раз наоброт

orignal запрос к HTTP серверу и он немедленно отвечает

orignal Vort тогда не надо трогать пока и так работает неплохо

Vort onon имеет в виду, небось, полностью однонаправленные стримы

onon1 Качаем картинки, да

Vort onon1: картинки не полностью однонаправленные

Vort а вот iperf3 - может. не проверял

orignal с картиниками как раз все нормально

Vort ещё немного размышлений про альфу. это, по сути, фильтр - отделяющий шум от полезного сигнала. так вот для оценки правильности его работы надо как минимум понимать, что есть шум, а что - нет

Vort мне по крайней мере пока что не очевидно, какие колебания пинга нам надо оставлять, а какие - отфильтровывать

orignal для меня это "много букафф" ))

Vort какие-то колебания SRTT работе алгоритма помогут, а какие-то - помешают :)

Vort цель полезные оставить, вредные убрать

onon1 Поэтому пока пусть будет среднее значение, а как подробнее разберёмся, поменяем.

onon1 По-хорошему, там нужно много чего поменять

onon1 Но я пока разбираюсь.

Vort onon1: оно среднее хоть так, хоть эдак :) вопрос в том, какая "частота среза", (очень) грубо говоря

orignal так я это 10 лет говорю что там надо менять ))))

Vort ну и раз речь о частоте - то привязываемся к времени. а сейчас семплы rtt идут неравномерно, seqn и время - вещи сильно различающиеся

orignal я вот чего думаю

Vort короч, первое, как я понимаю, - это надо собрать данные о работе реального носителя пакетов (среды) - какие данные по RTT он выдаёт

orignal а не попробовать ли нам реализовать обычный TCP протокол?

orignal проверх чесносной сессии

orignal ведь TCP вообще сетевая адресация не важна

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

Vort если стримы это и так "почти TCP", то просто чинить их надо да и всё

Vort если с починкой дела идут туго, то о создании альтернативы смысла думать мало

onon1 TCP не шлёт аски одним пакетом

Vort а один пакет, небось, из-за паддинга до ~килобайта

Vort так что...

onon1 Причем с неподтвердаемой доставкой

Vort у TCP другие свойства "носителя" - там мелкие пакеты не так "дороги"

orignal в TCP нет этого уродства под названием NAXK

orignal в TCP все эти алгоритмы исследоаны и отлажены массой народу

Vort так что - моё предположение о причине различий в дороговизне "пыли" - верное или нет?

orignal насчет 1K?

Vort да

Vort тут нельзя наспамить мелкими ответами. в TCP - можно

orignal так тут по хорошему надо делать перепаковку на уровне чеснока

orignal если у тебя акки идут с нескольких стримов в один адрес

orignal точнее не чеснова а тоннеля

orignal так надо отправлять их пачкой а не по одному

orignal и это все тоже надо оптимизировать потому что счас не сделано нихуя

Vort простой сценарий - один стрим на один адрес. который просто качает какие-то жирные данные

orignal если надо отослать пакет мы отсылаем сразу

Vort для начала простой сценарий должен работать чётко

orignal отправять акк каждые 20 миллисекунд

orignal делов то

Vort потом уже усложнять

orignal тут все просто

Vort "<~orignal> отправять акк каждые 20 миллисекунд" - и каждая отправка - 1 килобайт?

orignal да

orignal а кого это ебет?

onon1 Только деду эту переписку не показывайте...

orignal поток 50 килобайт в секунду

orignal в наше то время

onon1 У него инфаркт случится. Он же каждый килобайт считает.

Vort в общем, я думаю, что кардинально ничего менять сейчас (и в ближайшее время) не нужно

Vort пока что есть много возможностей по улучшению в рамках существующей архитектуры

onon1 Есть проблема, что туннель в который мы отправляем аски плохой, и у нас это, похоже, ника не обрабатывается.

Vort вот когда её улучшить уже будет нельзя (всё будет улучшено) - тогда можно задуматься о переделке

onon1 Мы не можем получить аск на аск и переотправить в другой туннель

onon1 наск* на аск

orignal да вроде он уже ничего не считает

Vort думаю, сейчас имеет смысл ловить поломки стримов и дестинейшенов - когда либо данные вообще течь перестают либо когда даже сам стрим создать не выходит

Vort такие проблемы особых измерений и обсуждений не требуют - и так понятно, что надо чинить

Vort эти исправления же откроют возможность надёжного тестирования "твиков" (настройки параметров алгоритма)

Vort сейчас же тестируешь-тестируешь - хренак - сломалось. и не понять, то ли изменение плохое, то ли просто не повезло

onon1 Давай ещё скорость роста окна в стрмах поправим, и я на время от тебя отстану.

Vort меня беспокоит, что из-за таких изменений стрим может залипнуть в состоянии большого окна. даже более медленное сбрасывание окна несёт такой риск

onon1 Он его сбрасывает если не получает асков, что может пойти не так?

onon1 Если он получает аски - все так.

Vort такие изменения (подкручивания параметров) обычно не бывают 100% полезными - есть и обратная сторона. и вот оценки её эффекта я пока что не видел

onon1 Обратная сторона - увеличение нагрузки на транспорты соседних узлов

onon1 Но там перегрузок, похоже нет, там проблемы другого рода.

Vort "<onon1> Обратная сторона - увеличение нагрузки на транспорты соседних узлов" - нагрузки полезными юзерскими данными? или перепосылками/чем-то таким служебным?

onon1 Естественно, полезными. Просто отправлять их быстрее.

Vort так передача полезных данных - это полезный эффект. а я считаю, что могут существовать и вредные эффекты

onon1 Проблема в больших задержках. Мы отправляем следующую порцию данных только при получении подтверждения.

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

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

onon1 Я пока не предлагаю ставить окно сразу в максимум, хотя я это протестировал, и это работает лучше всего.

onon1 Я предлагаю пока хотя бы увеличить скорость роста окна.

Vort так вот причины, по которым скорость роста не бесконечна - однозначно существуют. и игнорирование их - признак плохой проработки вопроса

onon1 Ограничено буферами на промежуточных узлах

Vort рост тут при чём? я не про максимум окна, а про скорость изменения говорю

orignal а что решили с SSU2?

orignal насчет окна

Vort orignal: раз там тот же код, то и вопросы к коду те же

onon1 Я туда пока не лазил, там другая ситуация, там прямой коннект.

Vort я против плохо обоснованных изменений, так как место это важное и поломать там что-то проще всего

orignal значит там тоже надо сделать что для стримов я так понимаю

Vort а релизы редко

orignal ну релизы можно и чаще

onon1 Не так, в стримах и в SSU2 разные условия.

orignal угу

Vort значит там не должен быть один и тот же код. надо запомнить

orignal но окно надо считать тоже умно а не как счас

orignal счас

orignal блин передайте уже ацетону чтобы обновился до транка

Vort и со включенными оптимизациями )

Vort orignal: тестировался ли i2pd вообще со сценариями 100% CPU загрузки ?

orignal я не пробовал

Vort :) я так и подумал

orignal когда то давно на первой малине во времена эь гамаля загразка была всегда почти 100%

Vort тогда же SSU2 не было?

onon1 > во времена эь гамаля

onon1 Это когда он ещё живой был?

orignal разумеется это было SSU1

orignal то вся нагрузка шла от построения тоннелей

Vort вот у меня подозрение, что SSU2 глючит на 100% нагрузке

Vort доказательства пока не собрал

orignal естественно глючит

Vort так сейчас это, похоже, распространённая ситуация

Vort грубый вариант - вычислять перегрузку, ставить congestion и прекращать принимать транзиты

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

orignal когда большая нагзука окно нало резать

Vort вроде правильно. только эту нагрузку надо научиться вычислять

Vort хотя ещё и доказательства глюков надо собрать. я просто видел зависающие стримы на SSU2

Vort и видел это при 100% загрузке CPU

Vort но, может, глючить не сам SSU2, а что-то другое

onon1 SSU2 дропает коннект при перегрузке. Я сделал SSU2-only через один свой роутер. Запустил один стрим - нормально, два стрима - нормально, три стрима - в лог полезли сообщения о превышении очереди в 500 сообщений

onon1 И транспорт начал дропаться и пересоздаваться, стримы продолжали работать. Я запустил четыре стрима - транспорт дропнулся и не пересоздался, а роутер был забанен.

orignal ну так понятное дело

onon1 Ну так я ничего криминального не делал, просто 4 файла одновременно качал

onon1 Запиши в инструции к итупи что больше 4 файлов за раз качать запрещено.

onon1 Поэтому у нас роутеры в бане и сидят все.

onon1 Парятся

Vort основная причина банов явно другая )

Vort но мягкое ограничение какое-то для параллельного скачивания всё же, думаю, нужно

orignal а как страницы открывать?

orignal где сотни картинок

onon1 Дроп сообщений на транспорте кажется более логичным, чем дроп коннекта.

Vort не должно ничего ломаться от нагрузки вообще никогда

Vort должна уменьшаться скорость и всё

Vort но вот реально ли это сделать с нынешней архитектурой - не знаю

Vort сейчас считается, что большое количество сообщений в очереди - это признак перегрузки узла. но есть ещё один сценарий - высокоскоростная связь с высоким пингом - для неё большое количество пакетов "в полёте" - естественное состояние

onon1 Выход - растить буферы на транзитах... Тем самым ещё больше увеличивая задержки.

Vort может, удастся настроить congestion control с помощью дропов сообщений

onon1 Как вариант

Vort я вот только думаю, что помимо юзерских данных есть ещё и служебные сообщения, которые дропать нежелательно

Vort построения туннелей, пинги

onon1 Приоритезация трафика =)

Vort а если всё шифрованное, то хз, получится ли разделить

Vort так вот вопрос в том, реально ли это с нынешней архитектурой

Vort а можно ли сделать отдельные очереди для отдельных направлений?

Vort какое-то направление перегружено - туда дропать, остальные - не дропать

onon1 Что значит направлений?

onon1 Транспорты имеются в виду?

Vort ну сообщения же куда-то направляются. я плохо знаю, как сейчас сделано

onon1 У нас на один транспорт могут лететь сообщения с сотен узлов

Vort ну вот с одного узла в одну очередь складывать, с другого - в другую. что-то такое

onon1 И пускать их поочерёдно?

onon1 Из каждой очереди?

Vort дропать сообщения с самого нагруженного источника в первую очередь к примеру

onon1 Есть над чем подумать. Получится тысячи очередей

Vort ну да, тут думать надо. так сразу сделать, похоже, не выйдет

onon1 Но если сделать их небольшими...

onon1 А оверхед дропать

Vort или сделать несколько и перемещать между ними

onon1 То самые настойчивые будут терять пакеты, а медленные получат свой поток

onon1 Грубо говоря 10 узлов стучатся на какой-то узел через нас. Каждому делаем очередь

onon1 И если кто-то шлёт больше, чем влезает в очередь дропаем

onon1 А у кого влезает, те по очереди отправляются по назначению

Vort напоминает алгоритмы разделения процессорного времени в операционках :)

Vort Round Robin и так далее, куча их

onon1 Ну смысл же такой же,

onon1 Есть много желающих получить ресурс

Vort ага, есть один ресурс и надо его поделить

Vort :)

onon1 Ну так давай реализуй, потестируем.

Vort я не настолько хорошо ещё понимаю работу i2p + считаю, что до релиза масштабных изменений лучше не делать - только явные баги пришибать

onon1 Ну так после релиза сеть ляжет...

onon1 Потому что скорости мы подняли, а дропы коннектов нет...

Vort ну посмотри опять на очереди во вкладке транспортов :)

Vort сеть так тупит, что даже в 10 раз быстрее - всё равно очередей много не наберётся

Vort локальные тесты через хорошие узлы - это отдельная история

weko [15:24:34] <orignal> блин передайте уже ацетону чтобы обновился до транка

weko Я написал вчера

Vort ещё по поводу очередей - если цель лимита в том, чтобы не набивались старые пакеты - то можно подумать о дропах при медленном движении очереди, сделав при этом лимиты размера довольно большими

Vort если очередь быстро движется, то не сильно важно, если у неё большой размер

Vort RAM, думаю, проблемой не будет, так как быстро двигать очередь можно только при скоростной сети, а скоростей больших у юзеров обычно нету

orignal да дропы это хорошая идея

orignal weko еще раз передай ))

weko чего передать то

weko а

weko ладно )

orignal чтобы пересобрался

orignal а то его шатает

Vort где-то вообще есть информация о надёжности NTCP2/SSU2? попробовал нагуглить - хрен там. java доки - это задница. а i2pd доки... их мало

orignal ну я тебе скажу по i2pd

orignal NTCP2 надежный

Vort про NTCP есть только то, что он основан на TCP, который надёжный )

orignal SSU2 теоретически быстрее

orignal и позволяет за натом сидеть

orignal но надежность хуевая

weko ну щас его приконнектит

orignal не потому что протокол плохой а я его ниасилил до конца

weko надо стримы доделать, тогда заебок будет

Vort так меня интересует - имеет ли право узел дропать сообщения?

Vort где вообще об этом написано?

orignal Vort в давние времена i2pd был стабильнее джавы потому что давал приоритет NTCP ))

weko конечно

orignal именно

orignal от деда изветсно

weko узел может делать что угодно

weko вопрос в том будем ли мы его ограничивать)

Vort в доках нету? это ж основная характеристика протокола. писец

Vort я имею в виду, как узел должен себя вести, если он не злонамеренный

weko ну в идеале не дропать

weko если он дропает значит он просто плохой

weko не обязательно злонамеренный

Vort протокол определяет ожидания сторон

Vort вот мне и удивительно, что не написано - ожидать гарантированной доставки от NTCP2/SSU2 или нет

onon NTCP2 я четырьмя стримами "завалить" не смог.

Vort от этого ведь зависит архитектура последующий слоёв

onon Он просто равномерно разделил скорости по стримам.

Vort последующих*

Vort onon: мне кажется, NTCP2 меньше тупит и поэтому меньше пакетов накапливается в очереди

orignal Vort по NTCP2 узел тоже может дропнуть

Vort orignal: ну по факту да, а надо это в доках чтобы было

Vort orignal: ну и дальше вопрос - все ли протоколы, основанные на NTCP2/SSU2, учитывают возможность дропа и корректно такую ситуацию могут обработать и обрабатывают?

orignal а вот x3

Vort :))

orignal ну так а все же что привело к такой стабильности илиты?

` Духовные скрепы.

` Здесь настолько зашкаливающая концетрация урапатриотофф, что вся ИЛИТА преисполнена вплоть до антиматерии.

Vort у меня нету

Vort "<~orignal> ну так а все же что привело к такой стабильности илиты?" недавний перезапуск, может?

orignal нее оно же почти сутки уже

onon1 Сам там чего-то подкрутил небось, и не хочет нам говорить, интригует.

orignal ничего вот последние коммиты

orignal думаю таки изменения с тагами

Vort с какого коммита обновление было?

orignal с последнего

orignal а до этого где я откатил измнения с тага но не до конца

orignal там где был баг с очисткой тагов

onon Значительная часть SSU2: Unexpected message type это занатовцы, которые не могут к нам подключиться.

orignal то есть не получают наши ответы что ли?

onon Ну иногда у них просто не получается SSU2: Session with 97.138.140.218:27235 was not established after 5 seconds

onon А иногда не распознается сообщение

orignal так вот почему не распознается?

onon Это я хз пока

orignal вот это и надо понять что это за сообшения

orignal скорее всего у нас уже сессия в другом состоянии а те сообщения повтор старых

onon Мне кажется где-то или сдвиг или двойное шифрование

orignal нет это просто не то сообещние что ожидается

orignal вот надо понять

onon Тогда бы была established с этим же пиром

onon А нету

onon Может там нат хочет в пакете поменять адрес на свой, и что-нибудь нам сдвигает?

orignal нет такого не может быть

orignal это же пейлоад

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

orignal но кстати да ендпойт мог поменяться

orignal первое соообщение с одним мы ответили

orignal а второе уже с другго и мы сессию не находим

onon1 Как будто у нас транспортная сессия рвётся, а UDP продолжает туда слать.

orignal такое возможно

onon Я смотрю в ntcp2 перед отправкой проверяется !m_IsSending а в SSU2 - нет.

onon Может мы слишком часто дёргаем сокет?

orignal так NTCP2 потоковый

orignal а SSU2 датаграмный

orignal отправка в SSU2 мгновенная

onon1 Ну да, она в буфер UDP складывает, понял.

onon SSU2_MAX_WINDOW_SIZE = 256 это же 256 кб?

onon SSU2_SOCKET_MIN_BUFFER_SIZE = 128 * 1024 а тут 128 кб?

orignal это число сообщений

onon Логи показывают что NTCP2 тоже можно довести до закрытия сессии NTCP2: Outgoing messages queue size to tIL6jNt-2BPjH16461S2uOwN2RK~WFmmR9HjS6yaXzY= exceeds 500