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

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

SSH (Secure Shell) обеспечивает безопасное удалённое управление операционной системой с использованием шифрования, обеспечивая защищённый обмен данными между клиентом и сервером благодаря:

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

Процесс работы SSH можно разделить на несколько этапов, как показано на схеме:

1. Установление соединения (Connection Establishment)
- SSH-сервер слушает запросы на подключение (шаг 1: «Listens to connection requests»).
- SSH-клиент отправляет запрос на соединение (шаг 2: «Sends a connection request»).
- Устанавливается TCP-соединение между клиентом и сервером (шаг 3: «Establishes a TCP connection»).

2. Согласование версии (Version Negotiation)
- Сервер отправляет список поддерживаемых версий протокола SSH (шаг 4: «Sends the supported versions»).
- Клиент отвечает, указывая версию, которую будет использовать (шаг 5: «Responds with the version to be used»).
- Сервер проверяет, успешна ли negotiation версии (шаг 6: «Checks whether the version negotiation is successful»).

3. Согласование алгоритмов (Algorithm Negotiation)
- Клиент отправляет информацию о поддерживаемых алгоритмах шифрования (шаг 7: «Sends information about the supported algorithms»).
- Клиент и сервер согласовывают алгоритмы, которые будут использоваться для шифрования и аутентификации (шаг 8: «Negotiates various algorithms in sequence»).

4. Обмен ключами (Key Exchange)
- Сервер отправляет клиенту простые числа (G, P) и свой публичный ключ (y) (шаг 10: «Sends prime numbers G, P, and server public key y»).
- Клиент отправляет свой публичный ключ (x) (шаг 11: «Sends client public key x»).

5. Расчёт сеансового ключа (Session Key Calculation)
- Клиент вычисляет сеансовый ключ (K), используя:
- публичный ключ сервера (y);
- свой приватный ключ (a) (отмечено как шаг 12: «Calculates the session key K based on the server public key y and the client private key a»).
- Сервер вычисляет тот же сеансовый ключ (K), используя:
- публичный ключ клиента (x);
- свой приватный ключ (b) (отмечено как шаг 12: «Calculates the session key K based on the client public x and the server private key b»).

6. Аутентификация пользователя (User Authentication / Key Authentication)
- Клиент использует свой приватный ключ для подписи сообщений (шаг 13: «Uses the client private key for signature»).
- Клиент отправляет подписанные сообщения на сервер (шаг 14: «Sends signed messages»).
- Сервер использует публичный ключ клиента для проверки подписи (шаг 15: «Uses the client public key for signature verification»).

7. Запрос сеанса (Session Request)
- После успешной аутентификации клиент отправляет запрос на начало сеанса (шаг 16: «Sends a session request»).
- Сервер отвечает на запрос, подтверждая начало сеанса (шаг 17: «Responds to the session request»).

8. Взаимодействие в сеансе (Session Interaction)
- Клиент отправляет зашифрованный запрос команды на сервер (шаг 18: «Sends an encrypted command request»).
- Сервер расшифровывает запрос с помощью сеансового ключа (шаг 19: «Decrypts the command request using the session key»), выполняет команду и отправляет зашифрованный результат обратно клиенту (шаг 20: «Sends the encrypted execution result»).
- Клиент расшифровывает результат с помощью сеансового ключа и отображает его в терминале (шаг 21: «Uses the session key to decrypt the execution result and displays it on the terminal»).

В Калифорнии принят закон об интеграции в ОС API для проверки возраста

Сенат штата Калифорния одобрил и губернатор затем подписал закон, который предписывает добавbnm в операционные системы возможности для указания возраста пользователя на этапе регистрации учётной записи и предоставления приложениям программного интерфейса для определения возраста текущего пользователя.
Законопроект вступит в силу 1 января 2027 года и, судя по всему, касается в том числе Windows, MacOS и Linux. Аналогичный законопроект находится на рассмотрении в штате Колорадо.

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

Загруженные и запущенные приложения должны иметь возможность получать от операционной системы информацию о возрасте в 4 градациях: младше 13 лет, от 13 до 16 лет, от 16 до 18 лет, 18 лет и старше.
Разработчик приложения должен использовать полученную информацию о возрасте для соблюдения законодательства о защите детей в интернете.

https://news.ycombinator.com/item?id=47181208

Некоторые программисты настолько суровы, что даже конструкцию if считают плохой практикой

Стратегии масштабирования распределённых систем
(продолжение в следующем посте)

Стратегии масштабирования распределённых систем
(продолжение предыдущего поста)

1. Stateless Services (сервисы без хранения состояния)
* суть: сервисы не сохраняют состояние между запросами — каждый запрос обрабатывается независимо;
* преимущества: лёгкость горизонтального масштабирования, так как экземпляры сервисов можно добавлять без влияния на работу других;
* реализация: размещение нескольких экземпляров сервисов в разных зонах доступности (AZ — Availability Zone), с сохранением состояния в отдельной базе данных;
* пример: микросервисы, обрабатывающие HTTP-запросы без сохранения сессии.

2. Horizontal Scaling (горизонтальное масштабирование)
* суть: добавление дополнительных серверов/инстансов для распределения нагрузки;
* механизм: использование группы автоматического масштабирования (Auto Scaling Group), которая добавляет/удаляет инстансы в зависимости от нагрузки;
* параметры:
* Desired Capacity (желаемая ёмкость) — целевое количество инстансов;
* Maximum Capacity (максимальная ёмкость) — лимит на количество инстансов;
* Scale out as needed (расширение по мере необходимости) — автоматическое добавление инстансов при росте нагрузки;
* примеры: веб-серверы, микросервисы в Kubernetes.

3. Load Balancing (балансировка нагрузки)
* суть: распределение входящих запросов между несколькими серверами для равномерной загрузки;
* задачи:
* предотвращение перегрузки отдельных серверов;
* повышение отказоустойчивости (при выходе из строя одного сервера нагрузка перераспределяется);
* сокращение времени отклика;
* компоненты: балансировщик нагрузки (Load Balancer), который направляет запросы на доступные серверы;
* примеры: NGINX, AWS ELB (Elastic Load Balancer), HAProxy.

4. Caching (кэширование)
* суть: хранение часто используемых данных в быстрой памяти (кэше) для ускорения доступа;
* этапы:
1. Read from Cache (чтение из кэша) — сначала система проверяет наличие данных в кэше;
2. Read from Database (чтение из базы данных) — если данных нет в кэше, они загружаются из БД;
3. Update Cache (обновление кэша) — полученные данные сохраняются в кэше для последующих запросов;
* технологии: Redis, Memcached, кэширование на уровне приложения;
* преимущества: снижение нагрузки на БД, ускорение работы приложения.

5. Database Replication (репликация базы данных)
* суть: создание копий (реплик) базы данных для распределения нагрузки и повышения доступности;
* архитектура:
* Primary (основная БД) — принимает записи (writes) и синхронизирует изменения с репликами;
* Replica (реплики) — копируют данные из Primary, обрабатывают чтения (reads);
* преимущества:
* повышение доступности (при сбое Primary запросы перенаправляются на реплики);
* распределение нагрузки (чтения распределяются между репликами);
* резервное копирование данных.
* примеры: MySQL Replication, PostgreSQL Streaming Replication.

6. Database Sharding (шардирование базы данных)
* суть: разделение базы данных на части (шарды) и размещение их на разных серверах для горизонтального масштабирования;
* механизм: данные распределяются по ключу (например, ID пользователя), чтобы запросы обрабатывались на соответствующем шарде;
* преимущества:
* масштабирование write-операций (записи распределяются по шардам);
* ускорение запросов за счёт параллельной обработки;
* управление объёмом данных (каждый шард обрабатывается отдельным сервером).
* недостатки: усложнение логики запросов (особенно для операций, затрагивающих несколько шардов).
* примеры: MongoDB Sharding, Cassandra.

7. Async Processing (асинхронная обработка)
* суть: отделение обработки задач от основного потока выполнения для повышения производительности и масштабируемости;
* архитектура:
* Server (сервер) — принимает запросы и помещает задачи в очередь;
* Workers (воркеры) — отдельные процессы/контейнеры, которые обрабатывают задачи из очереди;
* компоненты:
* очередь задач (Task Queue) — промежуточное хранилище для задач (например, RabbitMQ, Kafka);
* воркеры — обрабатывают задачи параллельно;
* преимущества:
* снижение нагрузки на основной сервер;
* возможность масштабирования обработки (добавление воркеров при росте нагрузки);
* устойчивость к пикам нагрузки (задачи накапливаются в очереди и обрабатываются постепенно).
* примеры: обработка платежей, отправка уведомлений, ETL-процессы.

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

Алгоритмическая сложность различных типов сортировок массива

Ключевые Архитектурные паттерны
(продолжение в следующем посте)

Ключевые Архитектурные паттерны
(продолжение предыдущего поста)

1. Client-Server Architecture (Клиент-серверная архитектура)
- Суть: задачи распределены между клиентами и серверами. Клиенты отправляют запросы, серверы обрабатывают их и возвращают результаты.
- Компоненты:
- Клиент (Client) — инициирует запросы (например, веб-браузер, мобильное приложение).
- Интернет (Internet) — канал передачи данных.
- Load Balancer (балансировщик нагрузки) — распределяет запросы между серверами для оптимизации производительности.
- Сервис (Service) — обрабатывает запросы и взаимодействует с базой данных.
- CDN (Content Delivery Network) — ускоряет доставку статического контента, снижая нагрузку на сервер.
- Преимущества: масштабируемость, централизованное управление, надёжность.
- Недостатки: зависимость от сервера, затраты на инфраструктуру, необходимость постоянного подключения к сети.
- Примеры: веб-сайты, электронная почта, онлайн-игры

2. Async Task Execution with Queues (Асинхронное выполнение задач с очередями)
- Суть: задачи выполняются асинхронно через очереди, что позволяет контролировать параллелизм и порядок выполнения.
- Компоненты:
- Presentation Layer (уровень представления) — взаимодействует с пользователем.
- Business Logic Layer (уровень бизнес-логики) — обрабатывает логику приложения.
- Data Access Layer (уровень доступа к данным) — работает с базой данных.
- Очереди — хранят задачи для асинхронной обработки.
- Преимущества: предотвращение перегрузки системы, управление ресурсами, последовательное выполнение задач (например, финансовые транзакции).
- Примеры использования: обработка больших объёмов запросов, фоновые задачи (отправка писем, обработка изображений)

3. Serverless Architecture (Бессерверная архитектура)
- Суть: разработчики не управляют серверами, а фокусируются на написании функций, которые запускаются по требованию облачным провайдером.
- Компоненты:
- Lambda Function — основная функция, обрабатывающая события.
- Lambda Worker — исполнители задач, запускаемые по мере необходимости.
- Особенности: модель Functions as a Service (FaaS) — код загружается в облако, провайдер управляет ресурсами.
- Преимущества: масштабируемость, снижение затрат, ускорение разработки, автоматическое управление инфраструктурой.
- Недостатки: ограниченный контроль над средой выполнения, сложности с отладкой, потенциальные проблемы с безопасностью.
- Примеры: AWS Lambda, Google Cloud Functions

4. Pipes and Filters (Каналы и фильтры)
- Суть: процесс обработки данных разбивается на шаги, каждый из которых выполняется отдельным обработчиком (фильтром). Данные передаются через каналы.
- Компоненты:
- Data Source (источник данных) — начальная точка потока данных.
- Filters (Filter 1, Filter 2, Filter 3) — обрабатывают данные, трансформируя их.
- Data Sink (потребитель данных) — конечная точка потока.
- Преимущества: модульность, возможность параллельной обработки, лёгкость замены и перестановки фильтров.
- Недостатки: фильтры могут тратить больше времени на преобразование данных, чем на их обработку.
- Примеры: оболочка UNIX Shell, архитектура компилятора (лексер, парсер, семантический анализатор, генератор кода)

5. Event-Driven Architecture (Событийно-ориентированная архитектура)
- Суть: компоненты системы реагируют на события (изменения состояния кода, действия пользователя). Взаимодействие асинхронное.
- Компоненты:
- Producer (производитель) — генерирует события.
- Consumers (потребители) — обрабатывают события.
- Особенности: события передаются по каналам (TCP/IP, файлы JSON/XML), брокеры обеспечивают сохранность событий при сбоях.
- Преимущества: высокая масштабируемость, гибкость, бесшовная интеграция, быстрая реакция на события.
- Недостатки: сложность проектирования, обеспечение согласованности событий в распределённых системах.
- Примеры: обработка заказов в интернет-магазинах, системы IoT, платформы Uber, Netflix

6. Microservices Architecture (Микросервисная архитектура)
- Суть: приложение разбивается на небольшие независимые сервисы, которые взаимодействуют через API.
- Компоненты:
- Service — отдельный микросервис, выполняющий конкретную функцию.
- Базы данных — каждая служба может иметь свою базу данных.
- Преимущества: лёгкость масштабирования, независимость развёртывания, возможность использования разных технологий для разных сервисов.
- Недостатки: сложность тестирования, накладные расходы на обмен данными между сервисами, необходимость синхронизации.
- Примеры: крупные веб-приложения, системы с высокой нагрузкой (например, Amazon, Netflix)

7. Monolithic Architecture (Монолитная архитектура)
- Суть: все компоненты приложения объединены в единую кодовую базу и развёртываются как единое целое.
- Компоненты:
- Web Layer (веб-слой) — взаимодействует с пользователем.
- Components (Component A, B, C) — модули приложения, выполняющие различные функции.
- Shared DB (общая база данных) — хранит данные для всех компонентов.
- Преимущества: простота разработки и развёртывания, низкая сложность взаимодействия между компонентами.
- Недостатки: сложность масштабирования, зависимость компонентов друг от друга, трудности с внедрением новых технологий.
- Примеры: традиционные корпоративные приложения, небольшие веб-сайты

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

Предприниматели по всему миру с энтузиазмом внедряют ИИ, хотя помощь компьютера далеко не всегда идет им на пользу.

Владелец небольшого онлайн-магазина из Великобритании завел чат-бота, чтобы тот отвечал на вопросы клиентов с 18:00 до 9:00, когда бизнесмен отдыхает. Полгода все шло отлично, пока в начале февраля не попался хитрый покупатель. Вместо того чтобы расспрашивать помощника о товарах, он принялся выпрашивать скидку. Сначала ИИ согласился скинуть 25%, а через час дошел и до 80%.

Стартап Hello Patient поручил ИИ проводить онлайн-собеседования с кандидатами на работу. Все шло прекрасно, пока один из соискателей не поленился и не отправил вместо себя другой ИИ. Два бота вступили в переписку и быстро нашли общий язык. По итогам разговора ИИ дал кандидату высшую оценку.

В ноябре прошлого года руководство одной фирмы доверило ИИ анализировать весь ее бизнес. Искусственный разум покорил начальство, мгновенно выдавая подробные отчеты, снабженные красивыми графиками. Более 2 месяцев на основе этих данных принимались важнейшие решения вроде расширения географии продаж, а также готовились финансовые презентации для совета директоров и инвесторов. Судя по отчетам, бизнес компании стремительно шел в гору – пока кто-то не попросил перепроверить одну из цифр, упомянутых ИИ. Однако этого показателя нигде не нашлось. Инцидент стал поводом для масштабного аудита, который выявил множество расхождений отчетов нейросети с реальностью.
ИИ путал данные про разные продукты и придумывал нужные цифры, лишь бы отчет получался красивым. Теперь компания пересматривает все решения за IV квартал, принятые на основе сгенерированной ИИ информации.

В декабре 2025 г. у облачного сервиса Amazon Web Services произошел сбой, на устранение которого ушло около 13 часов. Как узнала Financial Times, инженеры разрешили ИИ-инструменту Kiro внести изменения в систему. Алгоритм решил, что проще всего будет стереть весь код и переписать его заново. В самой компании отрицают причастность ИИ к проблеме. К ошибке привели некорректные действия одного из пользователей. Сбой затронул только один сервис в одном из двух регионов материкового Китая, уверяют там.

https://www.vedomosti.ru/technology/articles/2026/02/28/1179513-iskusstvennaya-pomosch

Cокеты и вообще сетевые возможности .NET на Linux получат прирост производительности – они перерабатываются для использования API io_uring (io_uring – это интерфейс системного вызова для Linux, он нужен для асинхронных операций ввода-вывода)

Один из разработчиков .NET - Бен Адамс (Ben Adams) подтвердил существенное улучшение производительности сокетов Linux .NET благодаря переходу на API io_uring.
По его словам, обновление снизит нагрузку на центральный процессор на 15-40% при каждом запросе HTTP/1.1. Пропускная способность на одно соединение HTTP/2 улучшится на 5-15%. Кроме того, обновление снизит нагрузку на оперативную память для неактивных соединений на 30-50%; снизит задержки на 10-20% на запрос для кратковременных соединений при исходящих запросах HttpClient (между микросервисами), уменьшит задержки на 5-15% на каждый запрос при работе с драйверами баз данных (Npgsql, MySQL Connector, Redis)

https://www.neowin.net/news/linux-about-to-get-big-performance-boost-from-a-native-feature-windows-11-already-borrowed/

Эффект стратегий масштабирования
(продолжение в следующем посте)

Эффект стратегий масштабирования
(продолжение предыдущего поста)

Стратегии масштабирования можно разделить на две категории: с ограниченным воздействием и с высокой эффективностью.

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

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

Разберем четыре простых примера:

1. Вертикальное масштабирование

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

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

Плюсы:
* Быстрота и простота реализации, не требуется вносить изменения в приложение.
* Низкая сложность и минимальные операционные издержки.

Минусы:
* Ограниченная масштабируемость — в конечном итоге достигаются аппаратные ограничения.
* Единый сервер означает единую точку отказа.
* Значительный рост затрат на оборудование при достижении высоких уровней нагрузки.


2. Горизонтальное дублирование

Запуск нескольких копий приложения на отдельных серверах с распределением трафика через балансировщик нагрузки.

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

Плюсы:
* Высокая доступность и отказоустойчивость.
* Простое масштабирование за счёт добавления новых экземпляров.

Минусы:
* Усложнение управления системой.
* Возможные проблемы с поддержанием согласованного состояния данных на разных экземплярах.


3. Разбиение данных (шардинг)

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

Когда использовать: когда база данных достигает пределов ёмкости или начинает работать медленнее, разбиение помогает распределить нагрузку и справиться со значительным ростом объёма данных.

Плюсы:
* Высокая масштабируемость за счёт распределения данных.
* Эффективное использование ресурсов.

Минусы:
* Сложная реализация и необходимость постоянного обслуживания.
* Трудности при выполнении запросов, затрагивающих несколько разделов данных.


4. Функциональная декомпозиция (микросервисы)

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

Когда использовать: когда приложение становится слишком сложным для поддержки и масштабирования, микросервисы позволяют масштабировать отдельные компоненты независимо и упрощают обслуживание.

Плюсы:
* Максимальная масштабируемость и гибкость.
* Независимые сервисы могут развиваться отдельно друг от друга.
* Лучшая изоляция сбоев.

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

РКН опроверг информацию о закрытии прямого подключения к иностранным VPN

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

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

https://ria.ru/20260302/vpn-2077991897.html

Шаблон конкурирующих потребителей
(продолжение в следующем посте)