Это не просто пачка лицензий на антивирусы или группа суровых людей из отдела ИБ, запертых в серверной. Это фундаментальное архитектурное свойство системы, её врождённая способность сопротивляться угрозам на всех этапах жизненного цикла: от первой строчки кода до вывода из эксплуатации. Проще говоря, если вы изначально строите дом из песка, то даже лучшая в мире охрана на входе не спасёт ваш домик от рассыпания. Безопасность нельзя «прикрутить» сверху в последний момент — она должна быть вшита в саму логику и структуру проекта, чтобы он оставался устойчивым даже при прямом воздействии.

Поэтому если проект реализуется на коленке с использованием дырявых библиотек и устаревшего инструментария без учёта логики разделения доступа, то ни один безопасник не поможет. Почему? А вот основные причины:

1. Безопасность нельзя просто так взять и навесить сверху. Если архитектура позволяет инъекции в базу данных или разработчик-умничка хранит пароли в открытом виде, то никакой файервол не перекроет все лазейки. Это исключительно системный брак, который лечится только переписыванием кода. Невозможно построить броневик на шасси от самоката.
2. Срок годности технологий. Уязвимости находят каждый день. Порой по несколько штук за сутки, а то и целыми списками. Поэтому если стек устарел (End of Life, или EoL), то для этого инструмента больше не выпускают патчи. Важно понимать: списки CVE публикуются открыто. Не нужно быть хакером из кино, чтобы найти все дыры по конкретной технологии — они доступны любому встречному в два клика. Использовать EoL — это как жить в доме с дверями, к которым ключи есть у всей улицы.
3. Человеческий и процессный фактор. Безопасность — это не результат, а непрерывный процесс. Если разработчики привыкли срезать углы, а менеджмент экономит на обновлении стека, то любой аудит превращается в список невыполнимых рекомендаций. В такой среде ИБ-отдел превращается в декорацию, которая просто фиксирует смерть пациента, пока бизнес надеется на авось.

Поэтому нужно понимать, что системная безопасность — это задача не только отдела ИБ. Это скорее плотная связка в формате «трио»: разработка, ИБ и бизнес. Без этого треугольника конструкция не устоит.

Если разработчик не предпринимает никаких действий по устранению уязвимостей и пропускает мимо ушей рекомендации отдела ИБ — это повод серьезно задуматься о его профпригодности. То же касается и бизнеса: игнорирование технических долгов в угоду скорости фич всегда выходит боком.

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

WannaCry — как самый яркий пример

Если нравятся подробности, то вот статья на Википедии

WannaCry — как самый яркий пример того, что бывает, когда на системную безопасность забивают болт. В 2017 году этот вирус-шифровальщик за считанные дни парализовал работу сотен организаций по всему миру: от больниц Великобритании, где отменяли операции, до заводов и железных дорог.

В чём был основной провал? Вирус использовал дыру в протоколе обмена файлами Windows. Самое смешное и грустное одновременно: Microsoft выпустила критическое обновление, закрывающее эту лазейку, ещё за два месяца до начала эпидемии. Но огромная куча компаний либо сидела на древних системах вроде Windows XP, которые уже давно перешли в статус End of Life, либо просто годами не устанавливала патчи, считая, что «и так работает».

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

Начнём с мотивации. Почему люди идут в IT? Чаще всего — деньги. Откуда-то появилось твёрдое убеждение, что войти в топ самых оплачиваемых профессий можно по щелчку пальцев, пройдя краткий курс. Это опасная иллюзия и заезжанный стереотип. Практический опыт, который нельзя симулировать, не наработан. У таких "спецов" часто не выработаны качества написания чистого, поддерживаемого кода. Просто убери свои первые наработки в ящик, продолжай изучать и развиваться, а через год открой его снова. Я почти уверен, ты сам будешь критиковать этот код. Увы, такова природа профессионального роста.

И сразу после выпуска залететь на позицию сеньора или техлида не получится. Это очевидно: нет навыков. Именно эти роли оправдывают высокие зарплатные ожидания, но у новичка нет ни практических кейсов, ни опыта решения критических проблем. Здесь стоит понять важную вещь: сеньоры и выше часто пишут меньше кода, чем мидлы или джуны. Это роль управленческая. Она подразумевает контроль процессов, умение тушить пожары, понимание цены и меры применения инструментов. Такой специалист видит смысл и принимает компромиссные решения там, где джун, охваченный синдромом "переделать всё на свою реализацию", увидит лишь неидеальность.

Но проблема не только в самих новичках: сход с верной тропы происходит раньше. Каждый год вузы и курсы выпускают огромное количество программистов. Однако учебные программы дают не всегда релевантный, а порой и узкий набор знаний. То, что принято считать "базой", зачастую недостаточно для реальных проектов. В итоге молодые специалисты, опиравшиеся исключительно на лекции и игнорировавшие саморазвитие, сталкиваются с требованиями работодателя, у которого уже сформирован запрос на нишевые, готовые к задачам кадры. И даже найдя человека, компания зачастую вынуждена его переучивать — вкладываться в то, что он упустил в рамках самообразования.

И тут скажу вам: если вас взяли в компанию, и вы чувствуете, что не всё вам по силам, но вас терпят и помогают — вы не обуза, вы инвестиция. Вы не приносите сиюминутную отдачу, но в вас тратят ресурсы, чтобы вырастить компетентного специалиста. Это типичная экономика рынка труда в IT.

Однако картина будет неполной, если не посмотреть шире. Волна "нерелевантности" — это часто вопрос несоответствия. Ожидания рынка изменились: прошел период массового найма "на вырост" на фоне бума айтизации. Сейчас, в эпоху оптимизации, компании чаще ищут более узких, готовых специалистов под конкретные задачи. Выпускник с широким, но поверхностным бэкграундом становится "нерелевантным" не потому, что он плох, а потому, что его профиль не совпадает с острым запросом на специализацию.

Таким образом, ситуация складывается из трёх ключевых факторов: инфляции ожиданий у новичков, отрыва образования от практики и изменившейся конъюнктуры рынка, который сегодня менее склонен к долгим инвестициям и хочет получить больше готовности "здесь и сейчас". Это не приговор для начинающих, а скорее чёткий сигнал: путь в IT требует не только стартовых знаний, но и упорства, способности к самообучению и трезвого понимания, что настоящая ценность и, как следствие, высокий доход — это финишная прямая длинного марафона, а не быстрый спринт с дипломом в руке.

Начнем с определения. Википедия говорит так:

Система реального времени (СРВ) — система, которая должна реагировать на события во внешней среде или воздействовать на нее в рамках строго заданных временных ограничений.

Прочитав первую часть, можно подумать: "А, любая система, которая быстро реагирует, и есть СРВ!". И вот здесь — главное заблуждение большинства.

"Быстро" НЕ равно "в реальном времени".

Суть СРВ — не в скорости, а в детерминированности, то есть предсказуемости. Любая хорошая система стремится быть быстрой (это про пропускную способность). Но СРВ делает фишку на другом: она дает результат не просто "в среднем" быстро, а гарантированно за определенное, часто жестко заданное время.

Пример: если система должна среагировать за 0.1 секунду, она сделает это всегда в промежуток от 0.0 до 0.1с. Это и есть ее предсказуемость — ключевой фактор.

Просто представьте: подушка безопасности в машине должна сработать в первые 0.1 секунды после удара. А теперь представьте, что ее процессор в этот момент занят чем-то другим (ну, например, обновлением) и она "думает" 5 секунд. Вы понимаете, что это — катастрофа. Вот вам и вся разница.

Классификации: "жесткие" и "мягкие" СРВ

Жесткие СРВ (Hard Real-Time). Возвращаемся к примеру с подушкой. Это системы, где нарушение временных рамок — это полный, фатальный отказ с критическими последствиями. Они повсюду в сферах, где ошибка стоит жизней или миллиардов: медицина (дефибрилляторы), авиация (системы управления полетом), АЭС, промышленные роботы.

— То есть, они должны срабатывать точно в срок, и точка?

— Да. Моментально и без права на опоздание.

Мягкие СРВ (Soft Real-Time). Это системы, которые ближе к нам, обычным пользователям. Здесь временные рамки важны, но их нарушение — не фатально. Оно ухудшает качество сервиса, но не ломает его полностью. Классические примеры — стриминговые сервисы (видео, музыка) и онлайн-игры. Пакет данных задержался? Получаем буферизацию или то самое: "Игра лагает!". Сервис деградировал, но не сломался.

— То есть, у "жестких" опоздание — крах, а у "мягких2 — просто косяк и лаг?

— Именно!

А на чем это всё делают?

Тут важно сразу понять: ваши обычные Windows, macOS или стандартный Linux не являются системами реального времени. Их планировщик задач — демократичный. Он может в любой момент прервать важный процесс, чтобы сделать что-то фоновое (проверить обновления, подвинуть окно). Для СРВ это смерть.

Для этого существуют специализированные ОС реального времени (RTOS). У них планировщик — "диктатор". Он заранее знает, какая задача самая важная и сколько у нее есть времени, и не позволит ей опоздать ни при каких условиях:

• QNX — Википедия
• FreeRTOS — Википедия
• VxWorks — Википедия
• RTLinux — Википедия

Языки программирования тоже берут особенные. В ходу C, C++, Ada, Rust, Zig — те, где программист сам управляет памятью, и нет непредсказуемых пауз. А вот Java, C# или Python обычно не годятся — у них есть Garbage Collector (сборщик мусора), который может в самый неподходящий момент взять и остановить программу для уборки, что для СРВ неприемлемо.

Система реального времени — это не про то, чтобы "летать". Это про то, чтобы всегда приземляться точно в заданную секунду. Даже если для этого иногда приходится лететь чуть медленнее, но гарантированно.

Надеюсь, теперь стало понятнее =)

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

Часть 1: Как работают мошенники? (Знать врага в лицо)

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

1. Фишинг («поддельные» сайты и письма):
• Вам приходит СМС или email, якобы от «Госуслуг», с сообщением о блокировке аккаунта, неоплаченной госпошлине или подозрительной активности.
• Ссылка в сообщении ведёт на идеально повторяющий официальный сайт-подделку.
• Вы вводите свои логин, пароль и даже пришедший по СМС код на этом фейковом сайте. Всё - мошенники получили полный доступ.
2. Поддельные звонки («социальная инженерия»):
• Вам звонит «сотрудник службы безопасности Госуслуг», «банка» или «полиции».
• Сообщает, что на ваше имя пытаются оформить кредит или ваш аккаунт взломали.
• Чтобы «заблокировать операцию» или «защитить счёт», он просит продиктовать коды из СМС, которые приходят на ваш телефон. Ни один настоящий сотрудник никогда не будет спрашивать у вас эти коды!
3. Вредоносное ПО:
• Установив троянскую программу (через сомнительный софт, файл в почте), мошенники могут перехватывать СМС, нажатия клавиш и данные с вашего устройства.

Часть 2: Фундамент защиты — создание неприступного аккаунта

1. Суперпароль — это обязательный минимум

• Длина важнее сложности: Не менее 12-15 символов.
• Уникальность: Никогда не используйте этот пароль на других сайтах (соцсети, почта).
• Совет: Придумайте пассфразу — несколько случайных слов, разделённых знаками: Лето#Дождь%СтоЛ2025. Запоминается легче, а взломать сложнее.

2. Двухфакторная аутентификация (2FA) — ГЛАВНЫЙ ЩИТ. Не просто СМС, а TOTP-коды!

СМС-код — это хорошо, но не идеально (риск перехвата через SIM-свап). Настоятельно рекомендуется использовать приложение-аутентификатор (TOTP).

Что это такое и как работает?

• TOTP (Time-based One-Time Password) — это одноразовые коды, которые генерируются в специальном приложении на вашем телефоне (Google Authenticator, Microsoft Authenticator, Яндекс ID). Код обновляется каждые 30 секунд и не зависит от сети.

Можете довериться Яндексу и ознакомиться более детально тут: https://yandex.ru/support/id/ru/authorization/twofa

• Как подключить на Госуслугах:
1. Зайдите в свой профиль на gosuslugi.ru.
2. Перейдите в раздел «Настройки» → «Безопасность».
3. Найдите пункт «Двухфакторная аутентификация» и выберите способ «Мобильное приложение».
4. Отсканируйте QR-код с экрана через ваше приложение-аутентификатор.
5. Введите первый сгенерированный код для подтверждения.
• Результат: Теперь при каждом входе, кроме пароля, вам нужно будет ввести 6-значный код из этого приложения. Напомню: если мошенник узнает ваш пароль, без этого кода с вашего конкретного телефона он не зайдёт.

3. Резервные коды доступа — ваш спасательный круг

При настройке 2FA система предложит вам распечатать или сохранить резервные коды. СДЕЛАЙТЕ ЭТО! Если вы потеряете телефон, эти 10-15 одноразовых кодов — единственный способ восстановить доступ. Храните их в надёжном месте (зашифрованный файл, сейф).

Часть 3: Правила цифровой гигиены

1. Проверяйте адрес сайта: Официальный адрес — gosuslugi.ru. Всегда смотрите на строку браузера. Фишинговые сайты используют похожие адреса: gos-uslugi.ru, gosuslugi.com, gosuslugi.help и т.д.
2. Не переходите по ссылкам из писем и СМС. Если получили тревожное сообщение, не кликайте. Зайдите на портал напрямую, через браузер или приложение, и проверьте уведомления там.
3. Помните про федеральные номера: Официальные службы (банки, Госуслуги, МВД) звонят только с федеральных (общероссийских) номеров, обычно начинающихся на 8 800 или 495, 812 (коды Москвы и СПб). Звонки с мобильных номеров (+79...) от имени этих организаций — 100% мошенничество.
4. Не диктуйте коды никому! Это золотое правило. Код из СМС или приложения — только для вас.
5. Используйте официальное приложение. Скачивайте его только из официальных магазинов: App Store или Google Play.

Часть 4: Что делать, если вы всё же попались на удочку?

Главное — действовать немедленно.

1. Немедленно позвоните на официальную горячую линию Госуслуг:
   8 800 100-70-10 (звонок бесплатный из любого региона России).
• Сообщите оператору о случившемся.
• Попросите заблокировать ваш аккаунт, чтобы мошенники не смогли ничего сделать.
2. Смените пароль (после разблокировки аккаунта или параллельно, если доступ ещё есть) на новый, сверхнадежный.
3. Проверьте все действия в аккаунте: Зайдите в «Настройки» → «Безопасность» → «История входов». Там будут видны все устройства и места, откуда заходили в ваш профиль. Если видите незнакомые — завершите эти сеансы.
4. Подайте заявление в полицию. Особенно если были совершены какие-либо действия (оформлен кредит, списаны деньги). Это важно для вашего же правового защиты.
5. Предупредите свой банк, если платежные данные или карты были привязаны к аккаунту.

Краткая памятка-чеклист

• Пароль от Госуслуг — длинный, сложный и уникальный.
• Включена двухфакторная аутентификация через приложение (TOTP), а не только СМС.
• Резервные коды доступа сохранены в надёжном месте.
• Я НИКОГДА и НИКОМУ не называю коды из СМС или приложения.
• Я знаю, что официальный сайт — только gosuslugi.ru.
• Я помню, что звонки о проблемах с аккаунтом с мобильных номеров — это мошенники.
• Я сохранил номер официальной горячей линии: 8 800 100-70-10.

Итог: Безопасность вашего аккаунта на 90% зависит от ваших действий. Включив двухфакторную аутентификацию через приложение и следуя простым правилам бдительности, вы сводите риск взлома практически к нулю. Берегите свои данные!

И помните, если вам всё-таки не повезло (потому что вы не прочитали эту статью ранее), вы всегда можете найти справочную информацию тут:
https://www.gosuslugi.ru/help/faq/personal_data/4562

Впервые я узнал об этой игре в 2019 году. Сначала я не понимал, чем там занимаются мои друзья - говорили что-то вроде "найди в браузере, и всё". Меня это заинтриговало, и я решил посмотреть сам.

Оказалось, всё гораздо проще, чем я думал: игра была браузерной.

С этого момента я начал глубже изучать её устройство. Она позиционировалась как социальная, но техническая реализация показалась мне чрезвычайно интересной.

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

Время шло, я занимался другими проектами, но мысль о подобной игре не отпускала.

На дворе стоял уже 2021 год, и желание создать что-то подобное Pony Town снова стало настойчивым. Я решил попробовать.

Использование игровых движков - это стандартный путь: он ускоряет разработку, да и при масштабировании проекта проще найти людей, которые смогут быстро включиться в работу без глубокого погружения. Я выбрал Construct 2. Да, он очень упрощал и ускорял процесс, но некоторые моменты в нём меня не устраивали. К тому же, на тот момент его уже активно вытеснял Construct 3.

Разработка сначала шла полным ходом, но потом постепенно замедлилась и, в конце концов, проект попал в стопку "архивных" - тех, что висят в состоянии "заморожен или заброшен".

И вот на дворе апрель, весна 2023 года. Я по-прежнему интересуюсь технической стороной Pony Town, и тут мне попадается объявление о поиске программиста в команду разработчиков самой игры.

Оно выглядело так:

Мы ищем опытных программистов, обладающих навыками разработки игр, игровых движков или серверной части. По окончании ознакомительного периода ожидается, что вы справитесь с разработкой основных функций (сравнимых с системой друзей или чатов), не требуя, чтобы вас держали за руку.
Мы планируем добавить множество важных функций для формирования игры, и вы сыграете значительную роль в их создании.
Должность оплачиваемая и на полный рабочий день, при этом вся работа выполняется удалённо.

Мне показалось это очень интересным и перспективным предложением, к тому же - удалёнка =)

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

После этого меня чудесным образом заблокировали в игре. Это был первый раз. Потом я потерял интерес и забил на эту затею. Висели и другие проекты, я занимался своими делами - откровенно говоря, было не до этого.

Наступил 2025 год. Я каким-то образом вспомнил об игре и решил глянуть, что там и как. Создал новый аккаунт, зашёл... и снова увидел всё то же самое. Но вскоре снова получил бан. И вот с этого момента начинается основная часть моей истории.

Начало разработки

Меня задело, что меня снова забанили. Бан со стороны игры был формально оправдан: создание нескольких аккаунтов. Но немного позже я всё-таки решил взяться и реализовать свою версию.

В этот раз я хотел сделать что-то более инновационное. Я отвык от игровых движков, и в итоге пришёл к идее монорепозитория с бэкендом и фронтендом, реализованными на нативном TypeScript. Это решение имело как плюсы, так и минусы, но я начал работу.

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

Первым делом на canvas появились точки, каждая из которых имела набор символов (условный ник, а на деле - идентификатор подключения).

Затем я отправился в "темницу" бесплатных текстур под названием itch.io и снова нашёл тот самый набор, который использовал ещё в 2023-м. Решил: "было раньше так - будет и сейчас". В наборе были все основные направления спрайтов (но, увы, не хватало диагоналей). Я накидал первый прототип.

Как видно на скриншоте, я добавил отображение вектора скорости (velocity), чтобы персонаж выбирал направление движения.

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

Следующим камнем преткновения стала тайловая карта. Мне нужна была система, совместимая с тайлами из моего набора с itch.io.

Немного подумав, я решил сделать простой двумерный массив на сервере, который клиент бы отрисовывал, используя ID тайлов из ячеек для графического отображения. Так появилась первая версия с тайлами.

Выглядело это, конечно, несуразно, потому что вот так выглядел этот массив в реальности:

Планировать карту таким способом было невероятно сложно. Заниматься лвл-дизайном в голом JSON - то ещё удовольствие.

Вот буквально моя попытка написать слово "СВОБОДА", которые так и не увенчалась успехом:

Тут я вспомнил, что у админа в Pony Town (как я видел в одном из обзоров приватного сервера) была возможность редактировать мир прямо в игре. Да и у обычных игроков на личных островах была механика украшения. Я понял, как мне стоит поступить: сделать микро-редактор мира с выбором тайла и живой перезаписью JSON карты.

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

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

Но чем дальше я продвигался, тем больше понимал, что накосячил с архитектурой. Я ушёл слишком далеко вперёд, чтобы легко возвращаться и менять структуру. Моё стремление изначально писать "правильно", используя принципы SOLID, разбилось о суровую реальность: у меня получился почти что монолит.

Например, модель клиента и сервера была тесно переплетена. Сервер не только обеспечивал мультиплеер, но и раздавал статический контент. В случае его падения пользователь не мог бы даже загрузить страницу, не понимая, упал сайт или игра закрыта навсегда.

И вот тут я разделил архитектуру на две части:

• Серверная часть: занимается только вебсокетами, игровой логикой и серверными функциями.
• Клиентская часть: была вынесена отдельно. Её можно разместить на CDN, чтобы игра загружалась мгновенно, а экземпляры бэкенда можно раскидать по регионам для лучшей локализации и производительности.

Это привело меня в настоящий экстаз! Хотя первый прототип уже работал, он мне не нравился. Я решил переделать механику камеры. Снова начал с пустого мира, снова разделил сервер и клиент.

И вот что в итоге получилось:

Следующие фичи сложно показать скринами, но они включают:

• Плавная камера, следующая за персонажем.
• Функция "Обзор": зажав V, можно осмотреть местность в радиусе 800 условных единиц. Алгоритм проработан так, что вы видите всё пространство между вами и курсором.
• Функция "Наблюдение": можно закрепить фокус на другом игроке. Игра будет показывать расстояние до него, а ваш персонаж автоматически повернётся в сторону объекта наблюдения.

Структура проекта наконец-то начала радовать глаз:

Далее я решил отвлечься на что-то более приятное - интерфейс (да, я знаю, что нарушил принцип YAGNI, но дедлайнов нет, это пет-проект).

Пока баловался с GUI, я уже размышлял, как превратить этот пет-проект из простой социальной игры в полноценную MMORPG... Но это были просто идеи, чтобы отвлечься, потому что я очень глубоко погрузился в разработку и мне нужен был отдых (на тот момент я уже 5 дней подряд жил этим проектом).

Я начал нагружать видеокарту различными эффектами:

Затем встала задача оптимизации. Те, кто занимался разработкой игр, знают: часто быстрее перерисовать объект, чем постоянно хранить его в памяти. Я вернулся к одной из плановых задач и реализовал отрисовку мира по тайлам "на лету".

Оптимизировав концепцию, я добился максимальной производительности даже с эффектами размытия и плавной камерой.

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

Вот для сравнения скриншоты на максимальных настройках графики и на минимальных:

Затем я занялся внутриигровым взаимодействием, тем же слежением за персонажем. Помимо функции обзора, добавилась фиксация фокуса на другом игроке с расчётом расстояния до него:

И снова я вернулся к вопросу с тайлами. Как сделать это правильно? Я решил, что этот вопрос пока второстепенен, так как многое другое требовало внимания. Обошёлся простым генератором квадратных комнат, заполненных тайлами.

И снова я пошёл нарушать YAGNI: раз уж есть смена дня и ночи, почему бы не сделать динамичные тени?

Из нюансов: я не использовал WebGL и сторонние графические библиотеки, решив пойти "тёмным" путём. Вот что из этого вышло:

Сюр при попытке дать поиграть знакомому

Пожалуй, это один из ключевых моментов. Мой знакомый поинтересовался прогрессом и захотел посмотреть на игру. Я решил показать ему вторую концепцию (первую он уже видел, а я её полностью переделал).

И тут я столкнулся с проблемой: у меня не было готовой методики развёртывания. Я-то понимал, как всё устроено, но к такому резкому повороту событий готов не был. У меня не было готового docker-compose, никаких инструкций. Задача сместилась: нужно было срочно навести порядок в деплое.

Я настроил webpack, прописал сценарии сборки для монорепозитория, проверил, как всё билдится и устанавливается. На деле это было сделано быстро, но перепроверить всё стоило.

Раз реализация подразумевала подключение к разным серверам, нужно было оформить главную страницу. Сначала я сделал простое меню с вводом ника и выбором сервера:

И вот, всё было готово для создания первой альфа-версии. Я решил использовать сервисы, которые могут подключаться напрямую к GitHub-репозиторию. Игра вытягивалась двумя разными серверами, каждый из которых по своему сценарию разворачивал систему через npm. Клиентская часть улетала на CDN, а бэкенд оставался с меткой "сервер".

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

Вот такая получилась история о том, почему и как я реализовал этот пет-проект.

Актуально на октябрь 2025 года | Версия .NET: 8.0

Введение

Тут инфа как установить .NET SDK 8.0 на операционную систему Debian 13. .NET SDK включает в себя все необходимое для разработки, сборки и запуска приложений на платформе .NET.

Подготовка системы

Перед установкой .NET рекомендуется обновить систему до последних доступных версий пакетов:

sudo apt update && sudo apt upgrade -y

Установка необходимых зависимостей

Для работы с репозиториями Microsoft потребуется установить дополнительные пакеты:

sudo apt install -y apt-transport-https ca-certificates gnupg wget

Эти пакеты обеспечивают:

• apt-transport-https - поддержку HTTPS-соединений для APT
• ca-certificates - доверенные SSL-сертификаты
• gnupg - работу с GPG-ключами
• wget - загрузку файлов из интернета

Добавление репозитория Microsoft

Добавляем официальный репозиторий Microsoft в систему:

# Загружаем пакет с настройками репозитория
wget https://packages.microsoft.com/config/debian/12/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
# Устанавливаем пакет
sudo dpkg -i packages-microsoft-prod.deb
# Удаляем загруженный файл (больше не нужен)
rm packages-microsoft-prod.deb

Установка .NET SDK 8.0

Обновляем информацию о пакетах и устанавливаем .NET SDK 8.0:

sudo apt update
sudo apt install -y dotnet-sdk-8.0

Проверка установки

Убедимся, что .NET успешно установлен:

dotnet --version

kaurcev@debian:$ dotnet --version
8.0.414
kaurcev@debian:$

Пример работы

# Создаем новое консольное приложение
dotnet new console -n MyTestApp

# Переходим в директорию проекта
cd MyTestApp

# Запускаем приложение
dotnet run

Можно найти в GitHub Gist: https://gist.github.com/kaurcev/617bb52920a953279a07cef52a3c41b8

Введение: почему децентрализация становится актуальной

Появление национального мессенджера МАХ в 2025 году действительно вызвало важную дискуссию о балансе между удобством, безопасностью и приватностью. Критические замечания ФСБ, касающиеся защиты персональных данных и требований по созданию модели угроз, подчеркивают фундаментальную проблему централизованных систем: чем больше контроль, тем выше риски для приватности.

Этот контекст побудил исследовать альтернативные подходы к коммуникации, в частности - технологии peer-to-peer (P2P), позволяющие создавать мессенджеры без центрального сервера. Актуальность такого подхода подтверждается растущим интересом к децентрализованным технологиям и Web3.

WebRTC: технологическая основа децентрализованной коммуникации

Архитектурные принципы

WebRTC (Web Real-Time Communication) - это не просто протокол, а целая экосистема стандартов W3C и IETF, предназначенная для организации прямой связи между браузерами и другими приложениями. Ключевое отличие от традиционных мессенджеров - отсутствие необходимости в промежуточных серверах для передачи данных.

Технический стек WebRTC включает:

• RTCPeerConnection - ядро системы, управляющее установлением соединения
• RTCDataChannel - би-directional канал для произвольных данных
• getUserMedia - API для доступа к медиаустройствам
• STUN/TURN - инфраструктура для преодоления NAT

Механизм установления соединения

Процесс "рукопожатия" в WebRTC - это сложная последовательность этапов:

1. Обмен сигнальной информацией

Сигнальный обмен - единственный этап, требующий стороннего сервера. В проекте использовался файловый обмен (.kae файлы) как альтернатива традиционному сигнальному серверу:

const offerData = {
    type: 'offer',
    sdp: peerConnection.localDescription.sdp,
    candidates: localIceCandidates,
    timestamp: new Date().toISOString()
};

SDP (Session Description Protocol) содержит информацию о поддерживаемых кодеках, параметрах сети и возможностях устройств. В проекте SDP генерируется автоматически при создании оффера и включает данные о поддерживаемых форматах и сетевых возможностях.

2. Сбор ICE-кандидатов

ICE (Interactive Connectivity Establishment) Framework решает проблему NAT-траверсала. Каждый клиент собирает список "кандидатов" - возможных путей для соединения:

• Host candidates - локальные IP-адреса (192.168.x.x, 10.x.x.x)
• SRFLX candidates - публичные IP-адреса через NAT, полученные от STUN-серверов
• Relay candidates - через TURN-серверы, используются когда прямое соединение невозможно

STUN (Session Traversal Utilities for NAT) серверы выполняют критически важную функцию - помогают клиентам определить свои публичные IP-адреса и типы NAT. В проекте используется распределенная публичная инфраструктура:

const configuration = {
    iceServers: [
        { urls: 'stun:stun.l.google.com:19302' },
        { urls: 'stun:stun1.l.google.com:19302' },
        { urls: 'stun:stun2.l.google.com:19302' },
        { urls: 'stun:stun3.l.google.com:19302' },
        { urls: 'stun:stun4.l.google.com:19302' },
        { urls: 'stun:stun.services.mozilla.com' },
        { urls: 'stun:stun.stunprotocol.org:3478' }
    ]
};

Эта конфигурация обеспечивает высокую отказоустойчивость: 7 различных STUN-серверов от разных провайдеров (Google, Mozilla, STUN Protocol) гарантируют работу даже при частичных отказах инфраструктуры.

Data Channels: транспортный уровень мессенджера

Архитектура каналов данных

RTCDataChannel предоставляет надежный, упорядоченный канал для передачи произвольных данных с низкой задержкой. В отличие от WebSocket, Data Channels работают поверх SCTP (Stream Control Transmission Protocol), что обеспечивает:

• Multiplexing - несколько независимых потоков в одном соединении
• Partial reliability - гибкие настройки надежности доставки
• Message-oriented - передача дискретных сообщений вместо потока байтов

Реализация в проекте

dataChannel = peerConnection.createDataChannel('chatChannel', {
    ordered: true,  // Гарантирует порядок доставки сообщений
});

Канал настраивается с параметром ordered: true, что обеспечивает последовательную доставку сообщений - критически важная функция для чата, где порядок сообщений имеет значение.

Оптимизация передачи файлов и медиа

Чанкинг больших данных

WebRTC имеет ограничения на размер передаваемых сообщений (обычно 16-64KB). Для передачи файлов и изображений реализован sophisticated механизм чанкинга:

const CHUNK_SIZE = 16000; // Оптимальный размер для минимизации фрагментации
const totalChunks = Math.ceil(fileBuffer.byteLength / CHUNK_SIZE);

// Метаданные передачи
const fileMessage = {
    type: 'file_start',
    id: fileId,
    fileName: file.name,
    fileSize: file.size,
    fileType: file.type,
    chunkCount: totalChunks
};

Размер чанка в 16000 байт выбран как компромисс между эффективностью использования канала и накладными расходами на обработку.

Система прогресса передачи

// Визуализация прогресса отправки
function updateFileProgress(messageElement, progress) {
    const progressBar = messageElement.querySelector('.progress-bar');
    if (progressBar) {
        progressBar.style.width = progress + '%';
    }
}

// Блокировка повторной отправки во время передачи
let isSendingFile = false;

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

Качество изображений: технический компромисс

Проблема качества изображений в прототипе имеет системный характер:

photoCanvas.width = 1024;
photoCanvas.height = 768;

Установка высокого разрешения canvas (1024x768) позволяет сохранять детализацию изображений, однако используемый механизм передачи через ImageData имеет ограничения:

1. Canvas compression - преобразование в ImageData приводит к потере качества из-за RGB-представления без сжатия
2. Chunking overhead - накладные расходы на разбивку и сборку (~5-7% от общего размера)
3. Bandwidth constraints - адаптация под ограничения каналов связи

Перспективное решение: использование современных форматов типа WebP или AVIF могло бы значительно улучшить качество при тех же объемах данных.

Persistent Storage: локальное хранение с IndexedDB

Архитектура хранения сообщений

const DB_NAME = 'ChatDB';
const DB_VERSION = 1;
const STORE_NAME = 'messages';

function openDB() {
    return new Promise((resolve, reject) => {
        const request = indexedDB.open(DB_NAME, DB_VERSION);
        
        request.onerror = () => reject(request.error);
        request.onsuccess = () => resolve(request.result);
        
        request.onupgradeneeded = (event) => {
            const db = event.target.result;
            if (!db.objectStoreNames.contains(STORE_NAME)) {
                const store = db.createObjectStore(STORE_NAME, { 
                    keyPath: 'id', 
                    autoIncrement: true 
                });
                store.createIndex('timestamp', 'timestamp', { unique: false });
            }
        };
    });
}

IndexedDB обеспечивает persistent хранение сообщений даже после закрытия браузера. Схема данных включает автоматическую инкрементацию ID и индекс по времени для эффективного поиска.

Пагинация и оптимизация памяти

Реализация lazy loading сообщений предотвращает перегрузку DOM и оптимизирует использование памяти:

const MESSAGES_PER_PAGE = 20; // Оптимальное количество для рендеринга
let currentMessageOffset = 0; 
let renderedMessages = new Set(); // Предотвращение дубликатов

async function loadMessagesFromDB(offset = 0, limit = MESSAGES_PER_PAGE) {
    // ... загрузка с пагинацией
    const start = Math.max(0, allMessages.length - offset - limit);
    const end = allMessages.length - offset;
    const messages = allMessages.slice(start, end);
}

Использование Set для отслеживания отрендеренных сообщений предотвращает дублирование при динамической подгрузке. Пагинация по 20 сообщений обеспечивает баланс между производительностью и удобством использования.

Безопасность и приватность: анализ рисков

Криптографические возможности WebRTC

WebRTC включает встроенное шифрование через DTLS-SRTP, обеспечивающее:

• Confidentiality - защита от прослушивания с использованием AES-128/GCM
• Integrity - защита от модификации данных через HMAC-SHA1
• Authentication - верификация участников через X.509-сертификаты

Все данные, передаваемые через DataChannel, автоматически шифруются на транспортном уровне.

Ограничения и уязвимости

1. Сигнальный канал - в данном проекте SDP-описания передаются через файлы (.kae), что исключает перехват в процессе передачи, но требует безопасного обмена файлами
2. STUN-серверы - возможность сбора метаданных (IP-адреса, порты) сторонними провайдерами
3. WebRTC leaks - риск утечки реальных IP-адресов через ICE-кандидаты
4. Локальное хранение - сообщения сохраняются в IndexedDB, что требует защиты устройства от несанкционированного доступа

Меры противодействия в реализации

// Очистка чувствительных данных при разрыве соединения
function cleanupConnection() {
    if (peerConnection) {
        peerConnection.close();
        peerConnection = null;
    }
    localIceCandidates = [];
    dataChannel = null;
}

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

Производительность и масштабируемость

Метрики производительности

На основе тестирования реализации можно ожидать следующие показатели:

• Latency: 20-100ms для текстовых сообщений (зависит от качества сети)
• Throughput: 2-8 Mbps для файловых передач (ограничено WebRTC и браузером)
• Connection time: 2-10 секунд для установления соединения (включая ICE-negotiation)
• Memory usage: ~50-150MB при активном использовании (зависит от объема истории)

Ограничения масштабируемости

WebRTC оптимален для 1:1 коммуникации. Архитектура проекта предполагает:

• Только парные соединения - не поддерживаются групповые чаты
• Локальное хранение - история не синхронизируется между устройствами
• Ручной обмен сигналами - не подходит для массового использования

Для масштабирования на группы потребовались бы:

• SFU/MCU архитектуры для многопользовательских сессий
• Centralized signaling для автоматического установления соединений
• Distributed storage для синхронизации истории между устройствами

Будущее развитие технологии

WebTransport и QUIC

Новые стандарты обещают улучшить производительность:

• Multiplexing без блокировки головы линии
• Улучшенное восстановление после потерь
• Низкая задержка установления соединения

Децентрализованная идентификация

Интеграция с DIDs (Decentralized Identifiers) могла бы обеспечить:

• Self-sovereign identity - пользователи контролируют свои идентификаторы
• Verifiable credentials - криптографически проверяемые атрибуты
• Decentralized authentication - без зависимости от центральных провайдеров

Service Workers для офлайн-работы

Расширение функциональности через Service Workers позволило бы:

• Фоновую синхронизацию при появлении соединения
• Push-уведомления для входящих сообщений
• Кэширование ресурсов для быстрой загрузки

Заключение: перспективы децентрализованных мессенджеров

Данная реализация демонстрирует, что создание работающего P2P-мессенджера возможно с использованием современных веб-технологий. WebRTC представляет собой технологически зрелую платформу для децентрализованных коммуникационных решений.

Ключевые преимущества подхода:

• Полный контроль над данными - отсутствие центрального сервера
• Прямое шифрование - встроенная защита на транспортном уровне
• Независимость от инфраструктуры - работа даже при отказе отдельных компонентов

Основные вызовы:

• UX-сложности - ручной обмен сигналами неудобен для обычных пользователей
• Ограниченная функциональность - отсутствие групповых чатов, push-уведомлений
• Зависимость от публичной инфраструктуры - STUN-серверы контролируются третьими сторонами

В эпоху возрастающего внимания к цифровому суверенитету и приватности, технологии типа WebRTC предлагают практический компромисс между удобством и контролем над собственными данными. Будущее, вероятно, увидит гибридные подходы, сочетающие преимущества как централизованных, так и децентрализованных архитектур.

Развитие стандартов WebTransport, QUIC и децентрализованной идентификации откроет новые возможности для создания полностью децентрализованных коммуникационных платформ, где пользователи сохраняют полный контроль над своими данными без потери удобства использования.

Данный проект служит proof-of-concept, демонстрирующим техническую осуществимость подхода и открывающим путь для дальнейших исследований в области децентрализованных коммуникаций.

Побаловаться можно ссылке: https://chat.kaurcev.dev или https://kaurcev.dev/chat

Ссылка на GitHub репозиторий: https://github.com/kaurcev/webrtc-chat-example