Как работает SSH Tunnels Remote Port Forwarding
(продолжение в следующем посте)

Как работает SSH Tunnels Remote Port Forwarding
(продолжение предыдущего поста)

SSH Remote Port Forwarding («удалённое перенаправление портов») позволяет открыть порт на удалённом SSH-сервере, а трафик с этого порта перенаправить на локальный компьютер (или другую указанную цель). Это создаёт защищённый SSH-туннель между клиентом и сервером.
SSH Remote Port Forwarding позволяет безопасно «опубликовать» локальные сервисы в интернете через защищённый туннель, управляя трафиком между клиентом, сервером и внешними пользователями.

2. Основные компоненты на схеме

- SSH Client (клиент SSH) — локальная машина (например, компьютер Джеймса), где запущен сервис (веб-сервер на localhost:80).
- Public SSH Server (публичный SSH-сервер) — сервер, к которому подключается клиент для создания туннеля. Служит «мостом» между клиентом и внешним миром.
- Remote Side Private Network (удалённая приватная сеть) — сторона, откуда идёт запрос к публичному SSH-серверу (например, пользователь Кей).
- SSH Tunnel (SSH-туннель) — зашифрованный канал передачи данных между клиентом и сервером.

3. Процесс работы

Шаг 1. Установка SSH-соединения с параметром `-R`

Клиент (Джеймс) инициирует SSH-сессию с публичным сервером, используя команду:

ssh -R 0.0.0.0:8080:localhost:80 user@pub-ssh-server

Где:
- -R — флаг для удалённого перенаправления портов;
- 0.0.0.0:8080 — адрес и порт на SSH-сервере, которые будут слушать трафик (0.0.0.0 означает «все интерфейсы»);
- localhost:80 — локальный адрес и порт, куда перенаправляется трафик (веб-сервер Джеймса);
- user@pub-ssh-server — учётная запись и адрес SSH-сервера.

Шаг 2. Настройка GatewayPorts

По умолчанию SSH слушает только интерфейс 127.0.0.1 (loopback). Чтобы сервер принимал соединения со всех интерфейсов (0.0.0.0), нужно в файле sshd_config на SSH-сервере установить:

GatewayPorts yes

Альтернативно можно использовать GatewayPorts clientspecified, чтобы сервер использовал адрес из команды -R.

Шаг 3. Перенаправление трафика

1. Пользователь (Кей) на удалённой стороне отправляет запрос на публичный SSH-сервер (curl public-ssh-server:8080).
2. SSH-сервер получает запрос на порт 8080 и перенаправляет его через туннель на локальный компьютер Джеймса (localhost:80).
3. Веб-сервер Джеймса обрабатывает запрос и возвращает ответ через тот же туннель.
4. Публичный SSH-сервер передаёт ответ пользователю (Кей).

4. Ключевые особенности

- Безопасность: весь трафик зашифрован благодаря SSH-туннелю.
- Доступность локальных сервисов: сервисы, доступные только локально (например, веб-сервер на localhost:80), становятся доступны извне через публичный SSH-сервер.
- Гибкость: можно пробрасывать любые порты (базы данных, API, RDP и т. д.).
- Контроль доступа: доступ к перенаправленным портам можно ограничить настройками SSH-сервера.

5. Пример из схемы

- Джеймс запускает веб-сервер на localhost:80.
- Создаёт SSH-туннель с публичным сервером, пробрасывая порт 8080 на свой веб-сервер.
- Кей может открыть public-ssh-server:8080 в браузере и увидеть веб-страницу Джеймса, хотя сервер работает только в локальной сети.

Еще один мессенджер.

РФ и Китай создают собственную платформу для коммуникаций под кодовым названием Molniya. Разработкой «Молнии» занимаются китайская Passion и российская «Ред Софт». Планировалось, что в приложении будут доступны функции для общения, трансляций и коротких видео - сплав мессенджера и соцсетей.
Но мессенджер будет только одной из функциональных возможностей «Молнии», уже на начальном этапе разработчики собирались реализовать сервисы для бизнеса, в частности, планируется внедрение финансового сервиса, который позволит выполнять конвертацию валют, оплачивать покупки посредством QR-кодов, выполнять трансграничные переводы и т.д. В платформу будут добавлены инструменты для создания внутренних маркетплейсов, а также «социального слоя», говорит Михаил Толпышкин, генеральный директор компании «Молния».


Сам запуск мессенджера «Молния», разработкой которого занимаются специалисты из России и Китая, перенесли на начало 2026 года. Изначально планировалось, что мессенджер запустят в сентябре этого года.
Разработчики планировали, что в течение полутора лет после запуска аудитория «Молнии» достигнет 15 миллионов человек.

https://tass.ru/ekonomika/25811121

Матрица вращения для трехмерных объектов

Линус Торвальдс все еще использует Fedora с GNOME
Потому что, по его мнению, Fedora больше подходит для разработки ядра. В ней все для этого упрощено
В то время как Ubuntu более ориентированна на потребителя и меньше подходит для разработки ядра. И, как вспоминает Линус, когда он попробовал Ubuntu много-много лет назад, она усложнила для него обновление ядра,

OpenAI законтрактовала до 40% всех мировых поставок DRAM, а теперь производители пытаются выкупить память обратно у ритейлеров

Рынок оперативной памяти настолько перегрелся, что, по словам инсайдеров, крупнейшие бренды RAM уже пытаются выкупать свои модули обратно у розничных сетей, чтобы перебросить их под более выгодные корпоративные контракты. Одному из заказчиков при попытке оформить крупную поставку DDR5 назвали срок отгрузки уже на конец 2026 года.

Все начилось со сделки, которую OpenAI заключила в начале октября: компания объявила о партнерстве сразу с Samsung и SK hynix, речь идет примерно о 900 000 пластин DRAM в месяц, то есть до 40% прогнозируемой мировой мощности по выпуску DRAM в 2025 году. Память нужна для проекта дата-центров Stargate, бюджет которого оценивают в $500 млрд. По данным инсайдеров, даже сами Samsung и SK hynix до дня объявления не до конца представляли масштаб, так как не знали о соглашении с конкурентом. Рынок по сути проснулся в мире, где почти половину будущих поставок DRAM уже зарезервировали под одного клиента.

Ситуацию усугубляет то, что OpenAI покупает не готовые модули, а сырые пластины — неразрезанные, не протестированные и пока даже не привязанные к конкретному стандарту (DDR5, HBM и т.п.). По версии MLID, такие запасы проще всего трактовать не как "страховку от будущего спроса", а как попытку вывести память с рынка и оставить конкурентов без DRAM: пластины можно просто копить на складах и решать позже, в какой вид продукции их превратить.

Для конечных покупателей это уже обернулось ценовым безумием: 4-гигабайтные комплекты DDR5-6400 от TeamGroup и других производителей, которые еще летом можно было купить за $200–250, сейчас на Newegg торгуются за $700–800. России схожие комплекты тоже ушли в заоблачный диапазон.

По оценкам Moore's Law Is Dead, производители DRAM уже сейчас называют для новых партий DDR5 сроки поставки до 13 месяцев, а аналитики не ждут нормализации раньше 2026–2027 годов. И это очень оптимистичная оценка

https://www.mooreslawisdead.com/post/sam-altman-s-dirty-dram-deal

Что такое REST API?
(продолжение в следующем посте)

Что такое REST API?
(продолжение предыдущего поста)

REST API (Representational State Transfer) — архитектурный стиль взаимодействия компонентов распределённой системы для передачи данных между сервером и клиентом с использованием протокола HTTP. Проще говоря, это способ взаимодействия сайтов и веб-приложений с сервером для получения, изменения или удаления данных. REST API широко используется в веб-разработке, мобильных приложениях и облачных сервисах благодаря своей простоте и эффективности.

6 ключевых принципов работы REST API:

1. Client-Server (Клиент-сервер):
* клиент (пользовательский интерфейс, например, веб-страница или приложение) и сервер разделены;
* код запросов остаётся на стороне клиента, а код для доступа к данным — на стороне сервера;
* это упрощает масштабирование и перенос интерфейса на другие платформы.

2. Stateless (Отсутствие состояния):
* сервер не хранит информацию о состоянии клиента (истории запросов);
* каждый запрос от клиента должен содержать всю необходимую информацию для обработки;
* сервер и клиент не сохраняют данные о предыдущих взаимодействиях (как показано на схеме: «Do not store state info»).

3. Uniform Interface (Единый интерфейс):
* все запросы к данным выполняются через единый URL-адрес с использованием стандартных HTTP-методов (GET, POST, PUT, DELETE, PATCH);
* ресурсы (например, /products, /users) доступны по чётким URL-адресам (например, https://example.com/api/v3/products);
* это упрощает архитектуру и делает взаимодействие с сервером более понятным.

4. Cacheable (Кэшируемость):
* данные могут быть кэшированы (сохранены в буфере) для ускорения повторных запросов;
* клиент может обращаться к кэшу вместо сервера, если данные не изменились;
* пример на схеме: ответ сервера с заголовком Cache-Control: public, max-age=3600.

5. Layered Systems (Многоуровневая система):
* архитектура состоит из нескольких уровней (например, Load Balancer, Auth Service, Product Database), которые взаимодействуют только с ближайшими уровнями;
* это повышает безопасность, упрощает масштабирование и позволяет изолировать компоненты системы (как показано на схеме с Load Balancer и Auth Service).

6. Code on Demand (Код по запросу, опционально):
* сервер может отправлять клиенту код (например, скрипт noscript.js) по требованию;
* это позволяет усложнять логику приложения только при необходимости (пример на схеме: GET /noscript.js).

### Основные HTTP-методы, используемые в REST API:
* GET — получение данных (например, GET /products);
* POST — добавление новых данных;
* PUT — обновление данных;
* DELETE — удаление данных;
* PATCH — частичное обновление данных.

Наглядно типы кабелей

Минцифры предупредило о постепенном отказе от входа на «Госуслуги» по смс
Ведомство объясняет такие меры борьбой с мошенничеством. Пока это решение касается только входа на «Госуслуги» через мобильные устройства

Некоторые пользователи портала «Госуслуги» уже столкнулись с проблемой при авторизации. После входа в аккаунт пользователям предлагают установить мессенджр MAX, однако возможность нажать кнопку «пропустить» отсутствует.

Мобильная версия сервиса настаивает на установке приложения, и избежать этого невозможно. При этом при входе в аккаунт через браузер на компьютере, пользователи могут нажать на кнопку «пропустить».

https://www.rbc.ru/society/05/12/2025/6932ee189a794711fc60e3ab?from=from_main_2

5 популярных архитектурных паттернов: VIPER, MVVM, MVC, MVP, MVI
(продолжение в следующем посте)

5 популярных архитектурных паттернов: VIPER, MVVM, MVC, MVP, MVI
(продолжение предыдущего поста)

#### 1. VIPER (View, Interactor, Presenter, Entity, Router)
Компоненты (на изображении выделены блоками):
* View — отвечает за отображение данных и сбор пользовательских взаимодействий (иконка «User → View»).
* Interactor — содержит бизнес-логику приложения (иконка с человеком за ноутбуком, подписана «Interactor»).
* Presenter — связующее звено между View и Interactor: подготавливает данные для отображения и реагирует на действия пользователя (иконка «Presenter»).
* Entity — хранит базовые структуры данных приложения (обозначен как «Entity»).
* Router — управляет навигацией (выделен как «Router» в центре схемы).

Особенности (согласно изображению):
* приложение делится на 5 чётких частей;
* улучшает тестируемость и разделение ответственности;
* данные передаются через уведомления (Notify) и обновления (Updates).

Идеально подходит для крупных приложений со сложной бизнес-логикой.

#### 2. MVVM (Model-View-ViewModel)
Компоненты:
* View — отображает данные, состояние контролируется ViewModel (иконка «View»).
* ViewModel — абстрагирует View, включает логику изменения состояния View, связывает Model и View (обозначен как «View model»).
* Model — содержит основную функциональность и данные (иконка «Model»).

Ключевые особенности (на схеме):
* ViewModel связывает данные модели с View;
* поддерживает двустороннюю привязку данных (Data binding, показано стрелками между View и ViewModel);
* изменения состояния (Change state) передаются от ViewModel к Model.

Применяется в WPF, Xamarin и других XAML-фреймворках.

#### 3. MVC (Model-View-Controller)
Компоненты (показаны на схеме):
* Model — хранит данные и логику приложения (иконка «Model»).
* View — отображает информацию пользователю (иконка «View»).
* Controller — обрабатывает пользовательский ввод, взаимодействует с Model и обновляет View (центральная иконка «Controller»).

Логика взаимодействия (на изображении):
1. Пользователь делает запрос → Controller.
2. Controller взаимодействует с Model.
3. Model возвращает данные → Controller обновляет View.

Особенности:
* один из старейших и наиболее распространённых паттернов;
* контроллер управляет вводом и обновлениями.

Подходит для простых приложений с чёткой структурой.

#### 4. MVP (Model-View-Presenter)
Компоненты:
* View — пассивное представление данных (иконка «View»), не обрабатывает логику.
* Model — хранит данные (иконка «Model»).
* Presenter — управляет взаимодействием между View и Model (иконка «Presenter»).

Взаимодействие (на схеме):
1. View передаёт обновления → Presenter.
2. Presenter взаимодействует с Model → получает данные.
3. Presenter возвращает данные в View.

Ключевые особенности:
* Presenter связывает Model и пассивное View;
* Presenter обрабатывает логику пользовательского интерфейса (UI logic).

Используется там, где важно отделить логику представления от View.

#### 5. MVI (Model-View-Intent)
Компоненты (согласно изображению):
* View — отображает интерфейс (иконка «View»).
* Intent — представляет пользовательские действия (намерения), запускает изменения состояния (центральная иконка «Intent» с мишенью).
* Model — обрабатывает логику и хранит состояние (иконка «Model»).

Особенности потока данных (на схеме):
* Однонаправленный поток: Intent → Model → View.
* Фокус на состоянии (state) и реактивности (reactivity) — изменения состояния обрабатываются предсказуемо.
* Данные поступают из интернета или локальных источников → обрабатываются Model → отображаются в View.

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

Краткий совет по Linux:

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

Команда mkdir поддерживает расширение с помощью фигурных скобок — это позволяет создать множество вложенных директорий за один раз.

$ mkdir -p ~/noscripts/{site-01,site-02}/{backup,monitoring,network}

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

Удобный способ сэкономить время и поддерживать упорядоченную структуру директорий.

Некоторые базовые математические обозначения

7 концепций, которые нужно освоить для работы с кэшем
(продолжение в следующем посте)

7 концепций, которые нужно освоить для работы с кэшем
(продолжение предыдущего поста)

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

Политики вытеснения (Eviction Policies)
Они определяют, какие данные остаются в кэше, а какие удаляются — это вопрос эффективности.

Распространённые политики:
* наименее недавно использованные данные (Least Recently Used, LRU);
* наиболее недавно использованные данные (Most Recently Used, MRU);
* наименее часто используемые данные (Least Frequently Used, LFU).

Согласованность кэша (Cache Coherence)
В распределённых системах всё становится сложнее.
Крайне важно поддерживать согласованность данных во всех кэшах.
Согласованность кэша гарантирует, что все копии элемента данных отражают самую последнюю версию.

Зернистость кэша (Cache Granularity)
Речь идёт о размере единиц данных, хранящихся в кэше.
Решения о зернистости влияют на эффективность кэша и коэффициент попаданий.
Сколько данных нужно сохранять при каждой операции?

Прогрев кэша (Cache Warm-up)
Предварительная загрузка кэша данными, которые предположительно будут востребованы, повышает производительность.
Особенно в системах, где попадания в кэш критически важны для скорости работы.

Разделение кэша (Cache Partitioning)
Представьте хорошо организованный ящик с инструментами, в котором есть отдельные отсеки или лотки для разных инструментов.
Разделение кэша работает по тому же принципу: кэш делится на разные секции, каждая из которых предназначена для определённого типа данных или запросов.
Такая организация улучшает работу кэша, поскольку извлечение данных становится проще и быстрее.

Сжатие кэша (Cache Compression)
Когда место ограничено, сжатие данных в кэше позволяет хранить больше информации.
Однако это влечёт за собой накладные расходы на обработку при сжатии и распаковке.

Кэширование — это не просто «скинуть данные куда‑нибудь и забыть о них».
Это также про то, *какие* данные, *как* и *когда* сохранять, чтобы сделать систему быстрее.

Разработчики в 2020 vs разработчики в 2025

Rate Limit (Ограничение частоты запросов к API)
(продолжение в следующем посте)

Rate Limit (Ограничение частоты запросов к API)
(продолжение предыдущего поста)

Ограничение частоты запросов к API — это метод контроля количества запросов, которые клиент может отправить в определённый промежуток времени. Это защищает серверную часть от злоупотребления, обеспечивает справедливое использование сервиса среди клиентов и поддерживает стабильную производительность даже при высокой нагрузке.

Почему важно ограничивать частоту запросов к API

* Предотвращает перегрузку сервера.
* Блокирует вредоносные боты и попытки подбора методом перебора.
* Обеспечивает справедливое распределение ресурсов.
* Повышает надёжность и время безотказной работы API.
* Помогает контролировать расходы на API и использование инфраструктуры.

Основные методы ограничения частоты запросов

1. Ограничение по фиксированному окну (Fixed Window Rate Limiting)

* Запросы учитываются в рамках фиксированного промежутка времени (например, 100 запросов в минуту).
* Простота реализации.
* Может приводить к всплескам запросов на границах окон.

2. Журнал скользящего окна (Sliding Window Log)

* Фиксирует время каждого запроса в журнале.
* Более точное сглаживание трафика.
* Повышенное потребление памяти.

3. Счётчик скользящего окна (Sliding Window Counter)

* Объединяет методы фиксированного окна и журнала.
* Обеспечивает сглаженные ограничения без значительного объёма хранения данных.
* Снижает проблемы, связанные со «всплесками» запросов.

4. Алгоритм Token Bucket

* Клиенты накапливают «токены» с фиксированной скоростью.
* Каждый запрос использует один токен.
* Позволяет контролируемые всплески запросов при соблюдении ограничений.

5. Алгоритм Leaky Bucket

* Обрабатывает запросы с постоянной фиксированной скоростью.
* Очередь хранит избыточные запросы.
* Помогает сгладить колебания трафика.

Где применяется ограничение частоты запросов

* API‑шлюзы (Kong, NGINX, AWS API Gateway).
* Обратные прокси‑серверы.
* Уровень серверного приложения.
* Узлы CDN (Cloudflare, Akamai).
* Уровень взаимодействия микросервисов.

Типичные HTTP‑ответы при ограничении частоты запросов

* 429 Too Many Requests — клиент превысил лимит.
* Заголовок Retry‑After — указывает клиенту, сколько времени нужно подождать.

Лучшие практики

* Устанавливайте лимиты в зависимости от ролей пользователей (бесплатный тариф против премиум).
* Предоставляйте чёткие сообщения об ошибках с инструкциями по повторной попытке.
* Используйте системы кэширования, такие как Redis, для счётчиков.
* Регистрируйте все нарушения лимитов для анализа.
* Избегайте чрезмерно строгих ограничений, которые затрудняют использование сервиса.
* Применяйте адаптивные лимиты для различных нагрузок.