Еще в копилку интересных вопросов: у SeaweedFS функция self-healing заявлена, как опция платной Enterprise версии. При этом некоторые механизмы ее вроде как в open source версии есть. Не очень понятен смысл репликации X2, если при этом нет self-healing и его нужно делать в ручном режиме. Ну то есть закачали файл, он скопировался в два места, а дальше? Допустим диск медленно "умирает" и у одного файла (из тысячи) перестала сходится CRC, как копия переедет на другой диск ("живой")?
Звучит как бизнес-план. Только два вопроса - в какой юрисдикции размещать файлы и как это монетизировать, что бы хотя бы аренду железа отбить. Кстати, а какая система монетизации у самого Spotify?
RPC is usually heavy on processing logic and therefore cannot handle I/O serially. But Go's standard library net is designed for blocking I/O APIs, so that the RPC framework can only follow the One Conn One Goroutine design. It will waste a lot of cost for context switching, due to a large number of goroutines under high concurrency. Besides, net.Conn has no API to check Alive, so it is difficult to make an efficient connection pool for RPC framework, because there may be a large number of failed connections in the pool.
On the other hand, the open source community currently lacks Go network libraries that focus on RPC scenarios. Similar repositories such as: evio, gnet, etc., are all focus on scenarios like Redis, HAProxy.
Жирным выделен главный фундаментальный недостаток, и почти все поголовно так пишут, например, Caddy или CoreDNS...
И без вот этого TLS не получится написать высокопроизводительные аналоги nginx или unbound... И про "focus on scenarios like Redis, HAProxy" тоже самое, TLS там же тоже не нужен...
Не исключаю такой вариант, что миф, беглый поиск в google на сейчас указывает только на энциклопедию Касперского (ENG). Хотя учитывая года, сотрудники Касперского это в книжке какой могли прочитать, а не в Интернете.
Ок, я просто сам контрибьютор в github.com/miekg/dns. И там реально могли быть проблемы типа утечки тредов, например. Дело в том, что там используется антипаттерн «пришел запрос — спавним рутину» для обработки (в стандартном http go тоже он используется, откуда и распространился по миру). Это все чревато тем, что под большой нагрузкой сервер получит OOM (в какой то момент спавн рутин начинает занимать намного больше времени, чем тратиться на обработку). Я пытался продвинуть идею пула воркеров (сначала фиксированное количество), но ее не приняли (потому что количество нужно было подбирать — а оно зависит от железа и ожидаемой нагрузки). Потом была попытка продвинуть идею динамических воркеров (прирост перфоманса был ~ 20% и меньшее потребление памяти), но в процессе codereview вся идея была испохаблена путем добавления логики до 10.000 рутин спавним воркеры, после этого лимита спавним рутины. Эта версия даже была некоторое время в репе (в v1.0.14 в частности), потом у них возникли проблемы с пиками потребления памяти, и все мои правки откатили (это opensource, детка) без попытки какого-либо анализа, с комментами типа: «у нас это работало 8 лет» и «мы потом разберемся» (уже год прошел) — это все, что нужно знать об opensource. У нас на проекте сейчас есть кастомный код с воркерами на базе github.com/panjf2000/ants, но лимит так и приходится подбирать, так что режим выключен по умолчанию (ждем OOM на проде, хе-хе).
Например, в нашей компании мы при обновлении API на 2ю версию, сразу завезли туда gRPC
Было бы неплохо это сразу в статье отразить. А то у меня впечатление, что наши «эффективные» project манагеры просто зацепились за фразу, что gRPC — это круто, и пошло-поехало…
git checkout v1.0.14
staticcheck | grep server.go
server.go:543:21: argument should be pointer-like to avoid allocations (SA6002)
server.go:626:19: argument should be pointer-like to avoid allocations (SA6002)
server.go:722:19: argument should be pointer-like to avoid allocations (SA6002)
текущая версия из master
git checkout v1.1.29
staticcheck | grep server.go
server.go:474:21: argument should be pointer-like to avoid allocations (SA6002)
server.go:586:20: argument should be pointer-like to avoid allocations (SA6002)
server.go:606:19: argument should be pointer-like to avoid allocations (SA6002)
server.go:647:19: argument should be pointer-like to avoid allocations (SA6002)
множество go-рутин создают некую структуру для TCP- соединений, помечает их как false и никогда не удаляет
На скриншотах виден и проблемный участок кода и структура, которая не очищалась при закрытии UDP-сессии.
Причем тут UDP, если мы говорим про TCP, причем для UDP объект conns не используется.
А на скриншоте мы видим, что len(conns)=1.152.090 (то есть открытых TCP соединений) — это нормально вообще?
И вообще — почему версии не обновлялись вовремя? Обновили бы, может и не увидели проблему вообще. А так начали глубоко копать, а по факту в чем конкретно проблема и как ее пофиксить не разобрались до конца.
Возможно не тема для конкретно этой статьи, но: зачем этот overhead с лишним сервисом grpc-gateway, если клиенты REST API работают по HTTP 1 и по факту ресурсов будет потребляться больше? Так имеет делать смысл, если фронтенд тоже использует gRPC (есть «промышленные» примеры WebUI на нем?). А у нас вот просто «эффективные» project манагеры приняли такое решение (везде grpc-gateway) именно потому что swagger и еще пару grpc interceptor прикручены, для лога и авторизации запросов (можно ли текущему пользователю использовать тот или иной запрос или нет). А WebUI использует просто HTTP 1.
Что тут можно еще сказать? Наверное, под Windows разработчики из Equation Group используют Visual Studio =).
Резюме: доказательство «притянуто за уши», кроме как заявлений от Shadow Brokers о том, что взломана Equation Group, больше ничего нет. Что не умаляет того факта, что в архиве таки есть инструменты из каталога NSA, работоспособность которых подтвердили производители сетевого оборудования.
… имплементация алгоритмов шифрования RC5 и RC6 в утечке совпадает с таковой у The Equation.
А вот в этом материале (Kaspersky’s Analysis of Equation Group’s RC6 is Wrong) говорится, что специалисты Касперского ошибаются и «нестандартная» имплементация — это всего лишь «происки» компилятора GCC по оптимизации кода.
Прочитал развернутый отчет от Kaspersky, cам себе отвечаю — ботагент Turla резолвит DNS C&C и вот этот IP принадлежит диапазону какого-нибудь спутникового провайдера. Первый пакет, естественно, ASK, причем на порт, который точно закрыт. И тут фишка в том, что бы выбранный IP не ответил на этот пакет ответом RST или FIN. И именно по этому признаку операторы Turla ищут IP. Перехватив пакет со спутника, формируется пакет SYN/ASK c dest IP жертвы и src IP подставного IP. Таким образом устанавливается TCP сессия. Ну и дальше идет обмен данными.
Правильно ли я понимаю, что для Turla идет речь не о сокрытии управляющего центра, а о сокрытии хранилища данных, куда сливается украденная информация? Как ботагент Turla узнаёт, что ему нужно отправлять информацию какому-то пользователю в Африке, что бы ее потом можно было перехватить со спутника?
LJ - Про кнопочные телефоны
Еще в копилку интересных вопросов: у SeaweedFS функция self-healing заявлена, как опция платной Enterprise версии. При этом некоторые механизмы ее вроде как в open source версии есть. Не очень понятен смысл репликации X2, если при этом нет self-healing и его нужно делать в ручном режиме. Ну то есть закачали файл, он скопировался в два места, а дальше? Допустим диск медленно "умирает" и у одного файла (из тысячи) перестала сходится CRC, как копия переедет на другой диск ("живой")?
Звучит как бизнес-план. Только два вопроса - в какой юрисдикции размещать файлы и как это монетизировать, что бы хотя бы аренду железа отбить. Кстати, а какая система монетизации у самого Spotify?
Из README.md от https://github.com/cloudwego/netpoll:
RPC is usually heavy on processing logic and therefore cannot handle I/O serially. But Go's standard library net is designed for blocking I/O APIs, so that the RPC framework can only follow the One Conn One Goroutine design. It will waste a lot of cost for context switching, due to a large number of goroutines under high concurrency. Besides, net.Conn has no API to check Alive, so it is difficult to make an efficient connection pool for RPC framework, because there may be a large number of failed connections in the pool.
On the other hand, the open source community currently lacks Go network libraries that focus on RPC scenarios. Similar repositories such as: evio, gnet, etc., are all focus on scenarios like Redis, HAProxy.
Жирным выделен главный фундаментальный недостаток, и почти все поголовно так пишут, например, Caddy или CoreDNS...
https://github.com/tidwall/evio first commit - Jul 4, 2017
https://github.com/panjf2000/gnet first commit - Sep 7, 2019
https://github.com/cloudwego/netpoll first commit - Feb 25, 2021
Традиция уже походу, каждые два года изобретать очередной event based net pool...
Меду тем ключевой вопрос - как прикрутить TLS - не могут допилить годами (в том числе потому, что стек TLS в golang нужно переписывать под асинхрон):
https://github.com/tidwall/evio/issues/28 "TLS support ?" - Nov 13, 2018
https://github.com/panjf2000/gnet/issues/16 "TLS support ?" - Sep 24, 2019
И без вот этого TLS не получится написать высокопроизводительные аналоги nginx или unbound... И про "focus on scenarios like Redis, HAProxy" тоже самое, TLS там же тоже не нужен...
Не исключаю такой вариант, что миф, беглый поиск в google на сейчас указывает только на энциклопедию Касперского (ENG). Хотя учитывая года, сотрудники Касперского это в книжке какой могли прочитать, а не в Интернете.
А что за книга?
Знать бы, чем разработчиков не устроил DRPC, который тоже про "простоту" как twirp, но с поддержкой streams.
Было бы неплохо это сразу в статье отразить. А то у меня впечатление, что наши «эффективные» project манагеры просто зацепились за фразу, что gRPC — это круто, и пошло-поехало…
не вижу ругани на github.com/miekg/dns/blob/v1.0.14/server.go#L260
проблемная версия
текущая версия из master
По коду v1.0.14 не вижу, почему не удаляются, есть строка github.com/miekg/dns/blob/v1.0.14/server.go#L581. И причем здесь false, если создается map[interface{}]struct{}?
Причем тут UDP, если мы говорим про TCP, причем для UDP объект conns не используется.
А на скриншоте мы видим, что len(conns)=1.152.090 (то есть открытых TCP соединений) — это нормально вообще?
И вообще — почему версии не обновлялись вовремя? Обновили бы, может и не увидели проблему вообще. А так начали глубоко копать, а по факту в чем конкретно проблема и как ее пофиксить не разобрались до конца.
Берем один из первых попавшихся примеров по запросу «rc6 implementation cpp» проектов (от 2002 года) и грузим его в отладчик. И что мы видим?
Отнимается константа 61C88647h, хотя в cpp коде мы имеем:
Что тут можно еще сказать? Наверное, под Windows разработчики из Equation Group используют Visual Studio =).
Резюме: доказательство «притянуто за уши», кроме как заявлений от Shadow Brokers о том, что взломана Equation Group, больше ничего нет. Что не умаляет того факта, что в архиве таки есть инструменты из каталога NSA, работоспособность которых подтвердили производители сетевого оборудования.
статьязаметка…