shared.md

описание

Личный канал для собирания всякого интересного. Иногда новые проекты, заметки и рекомендации. @Auserum

← к каналу @shared_md

890

подписчиков

Охват к подписчикам

160,6%

ERR

Реакции к просмотрам

0,79%

227 на 20 постов

Пересылки к просмотрам

1,86%

531

Постов в день

0,0

всего 20

Где отзываются чаще

доля реакций к просмотрам

19 июн.Закончил первую версию своего кастомного VPN-протокола на основе UDP. Писал практически с нуля, с минимумом зависимостей. Началось всё как попытка разобраться во внутреннем устройстве подобных виртуальных сетей, а сейчас это (почти) полноценный протокол, который уже достаточно стабильно работает. Для проекта решил использовать Go, как идеальный язык для такого рода задач. Общий принцип работы можно описать так: клиент слушает TUN-интерфейс, кодирует входящие пакеты, шифрует payload и пересылает на сервер по UDP. Сервер, соответственно, декодирует их, дешифрует и пишет в свой TUN. Первый и главный этап соединения — рукопожатие (handshake). В нём производится аутентификация клиента по переданному публичному ключу и создание новой сессии. На основе своего приватного ключа и полученного публичного другой стороны на клиенте и сервере вычисляется общий секрет с помощью ECDH. В дальнейшем он используется для симметричного шифрования полезной нагрузки пакетов по AES-GCM. Для стороннего наблюдателя (системы DPI) пакеты не несут в себе известных паттернов стандартных прокси или VPN-соединений. Так что сейчас с блокировками я не сталкиваюсь. Но принципиально блокировка возможна, поскольку каждый пакет имеет характерные признаки: незашифрованный 17-байтовый header и открытое рукопожатие, не говоря уж о явно применяемом шифровании. Буду пока надеяться, что большого дела до таких поделок уполномоченным органам нет. Ещё остаётся много спорных архитектурных решений в коде, негибкая конфигурация и строгая привязка к одной платформе (Linux). Что-то из этого точно будет исправлено потом. https://github.com/nktauserum/catwire | https://nktauserum.mooo.com/nktauserum/catwire2,73%
30 апр.Практически весь этот месяц я с переменным усердием работал над небольшим, но очень интересным для меня проектом. Нормальное название для него в голову не пришло. Это просто хеш-таблица с мьютексом поверх HTTP. Фактически, более простая версия Redis. Главной фишкой является легковесность: используется только стандартная библиотека Си, POSIX threads и специфические линуксовые библиотеки. Из самого основного я реализовал HTTP-сервер по методу finite-state machine, non-blocking IO с epoll и хеш-таблицу. Подробнее принцип работы описан в README. Конечно, на более продвинутых языках реализация заняла бы минут десять, но в этом случае был важен сам процесс. Проект задумывался именно как учебный, предназначенный для лучшего понимания скрытых низкоуровневых процессов. https://github.com/nktauserum/ht Ресурсы и лекции, которые очень помогли мне: https://www.youtube.com/watch?v=JoMAEyHNzs0 https://www.youtube.com/watch?v=pPjDPe0duXc https://www.youtube.com/watch?v=n-S9DBwPGTo https://github.com/h2o/picohttpparser1,57%
11 июл.Любопытно, но буквально все легкоблокирующиеся протоколы можно использовать с обвязкой в виде какого-нибудь туннеля. В цитируемом посте я использовал для этого Yggdrasil Network, а сейчас — свою виртуальную сеть catwire. Теперь трафик до определённых адресов туннелируется за границу, а остальной идёт напрямую через zapret. В качестве транспортного протокола можно использовать хоть чистый VLESS — никаких проблем не будет.1,56%
6 апр.Выложил новый видос про NaiveProxy. Если у вас в последнее время тоже начал отваливаться VLESS или Reality (у меня скорость упала до жалких 0.5 мбит), то этот способ сейчас - самый адекватный. Три дня сидел на ntc.party, пробовал разные каскады и костыли, в итоге остановился на Naive. В видео подробно показал весь процесс: как собрать кастомный Caddy, зачем нужен BBR на сервере и как не накосячить с настройкой SNI на клиенте. Сделал всё максимально подробно, чтобы вам не пришлось наступать на те же грабли. Ссылка на видео: https://youtu.be/vnTgnL1tskw Гайд с командами из видео: https://gist.github.com/swrneko/09e60de4d3d8f9a551a1a2c1ab9283c5 Залетайте, критикуйте. Если что-то не будет получаться — пишите в чат, разберемся1,47%
31 июл.У Яндекса есть одно крайне удобное зеркало, на котором размещаются пакеты, кажется, для любой архитектуры и для любого дистрибутива — mirror.yandex.ru. Задержка всегда незначительная, а скорость высокая. Интересно было узнать побольше про историю этого сервиса и почему его вообще держат открытым. https://t.me/yandexforbackend/10370,90%
11 мая[UPDATE]: Книги почтой (обход белых списков) Запущен в тестовом режиме книжный email-бот по адресу lib@exfreedomist.com Теперь вы можете получать книги на почту, даже если у вас нет VPN для обхода белых списков РКН™️. Потому что вы можете использовать совершенно любые почтовые ящики для отправки писем, в том числе от mailru, vk, яндекса и других. Всё, что надо сделать — отправить письмо с поисковым запросом в теме, получить ответ и выбрать книгу, отправить в ответ письмо — и книга у вас на почте. Подробную справку о работе почтового бота можно получить, отправив письмо с темой /help — для тех, кто пользуется нашими Telegram-ботами, стиль будет знаком. Попробуйте сами и расскажите тем, у кого пропал доступ к книгам, но нет возможности поставить VPN или одолели белые списки! lib@exfreedomist.com0,90%
3 июл.Думаю, многие знают, что из себя представляет обычный Docker-контейнер — изолированное окружение, созданное с помощью средств операционной системы. На первый взгляд выглядит просто, многие знают и умеют использовать в работе такой удобный инструмент. Однако, если начать погружаться в тему глубже, картина становится несколько запутаннее. Даже требуется немного выйти за рамки пользовательского пространства: окинуть беглым взглядом процессы, пространства имён и контрольные группы. Довольно хорошо эта тема была объяснена в данной лекции. Она датирована 2015 годом, но вряд ли сильно устарела. https://www.youtube.com/watch?v=rJRLZfk3a8U Материалы к лекции: https://github.com/krinkin/oslinux-seminars-20150,86%
27 мар.Скрипт для быстрой установки mtproto-прокси для Телеграма с маскировкой под выбранный сайт. Полезно, если не особо хочется над этим заморачиваться. Подробная инструкция также имеется в репозитории. https://github.com/2FrogsStudio/mtproto-installer0,84%
22 июл.Вещи - не то, чем кажутся! Зачастую всё говорит нам об очевидности и неоспоримости одного явления, мы проверяем его на практике и видим совершенно необъяснимое!!! Итак, Go зачастую быстрее, чем Rust. Да, это - мой ответ на вполне обоснованное мнение (с которым я был отчасти согласен, пока не провёл ресёрч) о том, что часто надо выбирать Go, если нет явных причин выбирать язык без управления памятью (типа нужд при написании драйверов или, например, баз данных, если по какой-то причине вы пишете их не на Zig). Чел провёл сравнения и у него Rust проигрывает с треском: https://youtu.be/X1eH3Geu2LU Речь не об обычной нагрузке на ввод-вывод. На каждом запросе выполняется 100 итераций SHA256-хэширования. Ну то есть, не сказать, что тест специально выбран, чтобы Go чувствовал себя на своей территории. К видео дофига вопросов и в комментариях справедливо заметили, что этот рукожоп делает лишние аллокации в коде на Rust (а в Go в аналогичной ситуации использует sync.Pool, чтобы лишних аллокаций избежать). Поэтому автор провёл несколько итераций исправлений бенчмарка, в том числе, с исправлением аллокаций на Rust. Ну и с исправленными аллокациями Rust почти сравнивается с Go. Даже выходит вперёд на 50м перцентиле, но проигрывает на 95м, 99м и на среднем значении (и еще несколько запросов завершились ошибками, тогда как в Go - нет). Из этого следует удивительный вывод. Несмотря на сборщик мусора, Go намного равномернее держит нагрузку в данном конкретном тесте. А в других тестах у других авторов - нет. Ну или да, ахахах. У них то Hyper рвёт Go, то Go рвёт Actix. Сколько людей проводит замеры - столько результатов. Важный инсайт - бенчмарки сложнее, чем кажутся и их никогда нельзя воспринимать однозначно. Очень многое зависит от окружения. Столь разномастные результаты - доказательство того, что Rust и Go в одной лиге и зачастую намного более сложный язык, который может замедлить разработку в несколько раз (ThePrimagen до того как стал Go-фаном и проводил тесты, сказал, что потратил в 5-7 раз больше времени на аналогичный код на Rust, который знал лучше) и это без учета скорости компиляции или, например, способности LLM писать код на одном из этих языков. Тут стоит поговорить про два явления. Встроенные в язык горутины как объект первого класса (против tokio, который замечателен, но всё-таки - не часть языка и развивается отдельно от него) и про волшебный сборщик мусора в Go. Горутины реализованы очень хорошо. Они давно уже не являются примером кооперативной многозадачности, в отличие от tokio. Это значит, что даже если мы загрузим горутину подсчетом числа Pi до миллиардного знака, планировщик пошлёт ей сигнал "приглохнуть и подождать своей очереди", что очень хорошо для latency. Но вообще tokio с горутинами сравнивать - неблагодарное занятия. Они ОЧЕНЬ разные с разными сильными и слабыми сторонами и про это диссертацию написать можно. Сборщик мусора в Go - это вообще не Java. И уж тем более не Java образца 2008. Stop The World звучит страшно, но в случае с Go речь о микросекундах. У него очень хороший GC. Прям ОЧЕНЬ. Возможно лучший в индустрии. И нагрузка на GC поддаётся оптимизации (тот самый sync.Pool, использование буферов байтов вместо аллокации строк и так далее). Думаю, на запредельной нагрузке и на более длинном тесте, можно загнать GC в ситуацию, когда он правда начнёт конкурировать за ресурсы CPU с остальной программой, но автору это не удалось. И тебе не удастся, если твои нагрузки не на грани. Но справедливости ради, я уверен, что будь в тесте более CPU-интенсивное вычисление, Rust вышел бы вперёд, причем сильно (хотя, в бенче уже была нагрузка на CPU). И более того, будь у нас спартанские требования к памяти, Rust тоже смотрелся бы лучше. Ну какие требования... Что-то типа "120MB намного лучше, чем 260MB!!!". Даже при нынешних ценах на RAM, для большинства задач, выбор Rust вместо Go ради лучшей производительности - это экономия на спичках. Если есть особые требования к latency... Не смотря на то, что тест чела, о котором мы говорим, показал, что у Go latency даже лучше, то тут тоже есть преимущество за Rust. Но вы там HFT занимаетесь? Тогда точно лучше язык с большим контролем за тактами процессора (Zig). Иначе - очевидно, что GC в Go справляется и не слишком вредит. Еще один инсайт. Автор ухитрился продолбаться с аллокациями потому что Rust делает их неявно (в Go они делаются явно, но его компилятор может решить, что ты не прав, так что всё тоже не айс). Ну ок, это не справедливо, в Rust довольно явная модель владения памятью, но методы типа Vec::new или .clone или еще что-то, выглядят как обычные функции. Нет какого-то ключевого слова, make или malloc. Ты просто создаёшь какую-то сущность, а она создаётся на куче. Еще один инсайт (уже не из бенчмарка, а просто). В tokio легко обеспечить себе рваную работу планировщика, тогда как горутины тебя подстрахуют. Ну то есть, чтобы выжать из Rust максимум, надо быть уверенным в себе. И в других членах команды. И в себе не выспавшемся, который будет кодить завтра. И в Васе с бодуна. Иначе можно словить фризы. Такие дела. Сложность языка, всё на плечах программиста и типы тут не помогут. В Go ты пишешь просто как в 90х и он всё равно работает дофига "норм". А еще, в Go не использовался fasthttp. Я не модный, не слишком слежу за миром Go, но когда я интересовался в последний раз, он был быстрее, чем стандартный net/http. Я не прав? Короче, нарратив "бери Rust - будет быстрее" - слишком сильное упрощение.0,83%
8 маяВ последнее время GitHub стал работать довольно-таки нестабильно. Помимо ставших привычными внутренних проблем ещё начались блокировки отдельных доменов со стороны РКН, что, разумеется, очень неприятно. Поэтому я решил поднять свой локальный инстанс какой-нибудь похожей на GitHub платформы. Так популярный GitLab отпал быстро: он запускал до ужаса много ненужных сервисов, был жутко непроизводителен и мой сервер с ним сразу начинал вести себя как Боинг-737 на взлёте. В конце концов выбор пал на Gitea, который, в отличие от своих аналогов, значительно легче и быстрее. Кстати, о сервере. Хостится всё это добро на моём любимом домашнем сервере, но пользовательские запросы попадают на него отнюдь не сразу. Входящий трафик сначала попадает на публичный сервер, имеющий публичный IP, где трафик сначала проходит терминацию TLS, затем проверку через WAF и лишь затем по виртуальной сети проксируется на локальный сервер. Всё это абсолютно необходимо, поскольку современный Интернет, увы, кишмя кишит множеством вредоносных ботов. В качестве WAF (Web Application Firewall) здесь был внедрён open-source сервис Anubis — как альтернатива Cloudflare, которую я очень рекомендую. И не только из-за милого маскота, разумеется. По производительности данный сетап показывает себя пока очень хорошо: лишних ресурсов не жрёт и не особо тормозит. С расчётным трафиком в полтора человека неудобств возникать никаких не должно. Пока я перенёс сюда далеко не все проекты (и, наверное, так и не перенесу), но пользоваться столь полезным сервисом теперь будет значительно удобнее. Словом, покойся с миром, GitHub. Можете посмотреть, затестить: https://linkmd.xyz P.S. Перешёл на более легковесный Forgejo.0,82%
7 июл.Вы, наверняка, много раз видели эту аналогию для объяснения связи между кривизной пространства и гравитацией. Мол, масса искривляет пространство, как шарик искривляет ткань, а шарик по этому искривлению катится, вот оно и притяжение. Выглядит красиво и понятно, правда? Сложно представить что-то более далекое от реальности и при этом создающее ложное ощущение понимания. Во-первых, эта аналогия работает только при наличии внешней силы — гравитации, которая собственно и заставляет двигаться шарики. Уберете гравитацию — никакого движения не будет (да и прогиба ткани тоже). То есть, мы "объясняем" гравитацию...используя гравитацию! Во-вторых, она создает иллюзию, что пространство должно искривляться куда-то в дополнительное измерение. Это одна из сложных вещей в общей теории относительности, что трехмерное пространство+время может быть искривленным без наличия четвертого измерения, "в которое" оно искривлено. Кривизина — это то, как ведут себя расстояния между объектами (и углы между прямыми). Для этого не нужно внешнее измерение, это свойство самого пространства(-времени). В-третьих, в режиме слабой гравитации (на Земле, например) сила гравитации возникает в первую очередь не из-за кривизны пространства, а из-за замедления часов. Ближе к массивному объекту часы идут чуть медленнее относительно удаленного наблюдателя. Предположим, что у нас есть два наблюдателя с часами, расположенные на разной высоте относительно поверхности земли (и покоющиеся там). Нижний наблюдатель посылает наверх регулярные импульсы света: каждую секунду по своим часам. Но по часам второго наблюдателя они приходят чуть медленнее, чем через каждую секунду. Ровно такая же картина наблюдалась бы, если бы второй наблюдатель удалялся от первого: импульсу приходится проходить чуть большее расстояние — и это обычное допплеровское смещение сигнала. То есть, в таком эксперименте две системы неподвижны относительно Земли, но движутся относительно свободной инерциальной системы отсчета! Теперь посмотрим, как отсюда берется падение тела. Представим, что у нас есть неподвижный наблюдатель и свободное тело (изначально покоится). Наблюдатель отпускает тело и оно продолжает покоиться, а вот наблюдатель начинает движение относительно этого тела. И не только он, вся земная система отсчета движется начинает движение относительно свободного тела. А наблюдателю кажется, что это тело падает к земле — вот она и "сила" притяжения. Изменение хода часов приводит к тому, что для того, чтобы оставаться на месте относительно поверхности, необходимо непрерывно ускоряться в сторону от Земли (что мы знаем из обычной жизни). Но это же значит, что тело, которое движется свободно без действия каких-то сил и ускорений, будет двигаться к поверхности в системе отсчета земли. Так что правильная картинка получается такая: трехмерная сетка вокруг Земли, заполненная "часами". Те, что ближе к Земле, идут медленнее, и это меняет траектории движущихся вокруг тел: само определение того, что мы понимаем под прямой, меняется. Кривизна пространства при этом не играет значительной роли (по крайней мере пока мы движемся относительно медленно). Конечно, она все равно оказывается важно для точного расчета разных эффектов (типа GPS или орбит планет), но Ньютоновская гравитация связана с гравитационным красным смещением (замедлением времени). Но у такой картинки не сделать красивой интуитивной демонстрации... #гравитация #ОТО0,81%
25 мар.Похоже, я нашёл рабочее (?) решение по обходу ограничений мобильного интернета. Сервис прокидывает wireguard трафик через TURN-сервера ВК, использующиеся для звонков. Должен работать ещё Телемост от Яндекса, но там присутствуют определённые ограничения. Для работы потребуется сервер с установленным wireguard и ссылка на активный звонок в ВК. Пока что у меня не введён режим белых списков, и я не могу полностью проверить работоспособность данного метода, но технически мне удалось его завести. Буду рад любому фидбеку насчёт его эффективности. UPD. На белых списках запустилось, но требуется поставить автоматический DNS для корректного резолвинга. Все инструкции на Github: https://github.com/cacggghp/vk-turn-proxy0,75%