Аутентификация на основе токенов и HMAC
(продолжение предыдущего поста)
Аутентификация на основе токенов и аутентификация HMAC являются распространенными формами аутентификации. Посмотрим, в чем они различаются.
1. Принцип работы
- Аутентификация на основе токенов (Token-based authentication):
1. Клиент отправляет логин и пароль на Authentication Server.
2. Сервер аутентификации генерирует токен (уникальную строку) и передаёт его клиенту.
3. Клиент включает токен в заголовки HTTP-запросов к Web Server при обращении к ресурсам.
4. Web Server проверяет валидность токена и, если он действителен, предоставляет доступ к ресурсу.
Суть: клиент получает токен после успешной аутентификации и использует его для подтверждения своих прав при каждом запросе.
- Аутентификация на основе HMAC (HMAC authentication):
1. Клиент запрашивает API key у Authentication Server.
2. Сервер передаёт клиенту API key (секретный ключ).
3. Клиент генерирует HMAC-подпись (hmac A) на стороне клиента, используя API key и параметры запроса (например, URI, метод HTTP, временная метка).
4. Клиент отправляет запрос к Web Server вместе с HMAC-подписью.
5. Web Server генерирует свою HMAC-подпись (hmac B) с теми же параметрами, используя свой экземпляр API key.
6. Web Server сравнивает hmac A (от клиента) и hmac B (собственно сгенерированный). Если подписи совпадают — запрос считается аутентифицированным.
7. При успешной проверке клиент получает доступ к ресурсу.
Суть: клиент и сервер независимо вычисляют HMAC-подпись, используя общий секретный ключ. Совпадение подписей подтверждает подлинность запроса.
2. Используемые механизмы безопасности
- Токены:
- Используют систему «выдать и использовать» (token issuance and validation).
- Токены могут быть JWT (JSON Web Tokens) с подписями, которые содержат метаданные (истечение срока действия, идентификатор пользователя и т. д.).
- Защита строится на валидации подписи токена и его срока действия.
- HMAC:
- Основан на криптографической функции HMAC (Hash-based Message Authentication Code), которая сочетает хэш-функцию и секретный ключ.
- Гарантирует целостность данных (данные не изменены в пути) и аутентичность отправителя (только владелец секретного ключа может сгенерировать корректную подпись).
- Секретный ключ никогда не передаётся в открытом виде — только используется для генерации подписей.
3. Этапы взаимодействия
- Токены: 4 основных шага (вход → получение токена → отправка запросов с токеном → доступ к ресурсу).
- HMAC: 7 шагов, включая генерацию и сравнение подписей (запрос API key → генерация подписи клиентом → отправка запроса → генерация подписи сервером → сравнение подписей → доступ к ресурсу).
4. Уровень сложности и вычислительных затрат
- Токены: проще в реализации, меньше вычислительных затрат на стороне клиента (только хранение и передача токена).
- HMAC: требует дополнительных вычислений на стороне клиента (генерация HMAC-подписи для каждого запроса), но обеспечивает более высокий уровень безопасности.
5. Сценарии применения
- Токены: подходят для веб-приложений, мобильных приложений, где важна простота и скорость аутентификации. Часто используются в REST API, SPA (Single Page Applications).
- HMAC: предпочтителен для API, где критична безопасность (финансовые сервисы, платёжные системы), а также для микросервисов, где требуется строгая проверка целостности запросов.
6. Уязвимости и защита
- Токены: уязвимы к перехвату (если не используются защищённые каналы, например, HTTPS). JWT могут быть подвержены атакам, если подпись не проверена должным образом.
- HMAC: более устойчив к перехвату, так как даже зная запрос, злоумышленник не сможет сгенерировать корректную подпись без секретного ключа. Однако требует строгой защиты API key.
Краткое резюме:
- Токены — удобны и быстры, но менее безопасны.
- HMAC — более сложен в реализации, но обеспечивает высокий уровень защиты за счёт криптографической проверки целостности и подлинности. Выбор зависит от требований к безопасности и архитектуры системы.
(продолжение предыдущего поста)
Аутентификация на основе токенов и аутентификация HMAC являются распространенными формами аутентификации. Посмотрим, в чем они различаются.
1. Принцип работы
- Аутентификация на основе токенов (Token-based authentication):
1. Клиент отправляет логин и пароль на Authentication Server.
2. Сервер аутентификации генерирует токен (уникальную строку) и передаёт его клиенту.
3. Клиент включает токен в заголовки HTTP-запросов к Web Server при обращении к ресурсам.
4. Web Server проверяет валидность токена и, если он действителен, предоставляет доступ к ресурсу.
Суть: клиент получает токен после успешной аутентификации и использует его для подтверждения своих прав при каждом запросе.
- Аутентификация на основе HMAC (HMAC authentication):
1. Клиент запрашивает API key у Authentication Server.
2. Сервер передаёт клиенту API key (секретный ключ).
3. Клиент генерирует HMAC-подпись (hmac A) на стороне клиента, используя API key и параметры запроса (например, URI, метод HTTP, временная метка).
4. Клиент отправляет запрос к Web Server вместе с HMAC-подписью.
5. Web Server генерирует свою HMAC-подпись (hmac B) с теми же параметрами, используя свой экземпляр API key.
6. Web Server сравнивает hmac A (от клиента) и hmac B (собственно сгенерированный). Если подписи совпадают — запрос считается аутентифицированным.
7. При успешной проверке клиент получает доступ к ресурсу.
Суть: клиент и сервер независимо вычисляют HMAC-подпись, используя общий секретный ключ. Совпадение подписей подтверждает подлинность запроса.
2. Используемые механизмы безопасности
- Токены:
- Используют систему «выдать и использовать» (token issuance and validation).
- Токены могут быть JWT (JSON Web Tokens) с подписями, которые содержат метаданные (истечение срока действия, идентификатор пользователя и т. д.).
- Защита строится на валидации подписи токена и его срока действия.
- HMAC:
- Основан на криптографической функции HMAC (Hash-based Message Authentication Code), которая сочетает хэш-функцию и секретный ключ.
- Гарантирует целостность данных (данные не изменены в пути) и аутентичность отправителя (только владелец секретного ключа может сгенерировать корректную подпись).
- Секретный ключ никогда не передаётся в открытом виде — только используется для генерации подписей.
3. Этапы взаимодействия
- Токены: 4 основных шага (вход → получение токена → отправка запросов с токеном → доступ к ресурсу).
- HMAC: 7 шагов, включая генерацию и сравнение подписей (запрос API key → генерация подписи клиентом → отправка запроса → генерация подписи сервером → сравнение подписей → доступ к ресурсу).
4. Уровень сложности и вычислительных затрат
- Токены: проще в реализации, меньше вычислительных затрат на стороне клиента (только хранение и передача токена).
- HMAC: требует дополнительных вычислений на стороне клиента (генерация HMAC-подписи для каждого запроса), но обеспечивает более высокий уровень безопасности.
5. Сценарии применения
- Токены: подходят для веб-приложений, мобильных приложений, где важна простота и скорость аутентификации. Часто используются в REST API, SPA (Single Page Applications).
- HMAC: предпочтителен для API, где критична безопасность (финансовые сервисы, платёжные системы), а также для микросервисов, где требуется строгая проверка целостности запросов.
6. Уязвимости и защита
- Токены: уязвимы к перехвату (если не используются защищённые каналы, например, HTTPS). JWT могут быть подвержены атакам, если подпись не проверена должным образом.
- HMAC: более устойчив к перехвату, так как даже зная запрос, злоумышленник не сможет сгенерировать корректную подпись без секретного ключа. Однако требует строгой защиты API key.
Краткое резюме:
- Токены — удобны и быстры, но менее безопасны.
- HMAC — более сложен в реализации, но обеспечивает высокий уровень защиты за счёт криптографической проверки целостности и подлинности. Выбор зависит от требований к безопасности и архитектуры системы.
Telegram
METANIT.COM
Аутентификация на основе токенов и HMAC
(продолжение в следующем посте)
(продолжение в следующем посте)
❤6👍5🔥3
Типы криптографии
(продолжение предыдущего поста)
В зависимости от устойчивости к квантовым вычислениям криптография делится на два основных класса:
1. Quantum-breakable (уязвимые для квантовых атак).
2. Quantum-secure (устойчивые к квантовым атакам).
#### 1. Quantum-breakable (уязвимые для квантовых атак)
Эти методы могут быть взломаны с помощью квантовых компьютеров. К ним относятся:
- RSA encryption (шифрование RSA):
- Сообщение шифруется с помощью публичного ключа получателя.
- Расшифровывается с помощью приватного ключа.
- Безопасность основана на сложности разложения на простые множители (вычисления приватного ключа из публичного).
- Diffie-Hellman key exchange (обмен ключами Диффи-Хеллмана):
- Два участника совместно создают общий секретный ключ по незащищённому каналу.
- Этот ключ используется для зашифрованной коммуникации.
- Безопасность основана на сложности задачи дискретного логарифма.
- Elliptic curve cryptography (криптография на эллиптических кривых):
- Используются математические свойства эллиптических кривых для генерации публичных и приватных ключей.
- Сложность восстановления приватного ключа из публичного связана с задачей дискретного логарифма на эллиптических кривых.
#### 2. Quantum-secure (устойчивые к квантовым атакам)
Эти методы разработаны для защиты от потенциальных квантовых атак. К ним относятся:
- Lattice-based cryptography (решётчатая криптография):
- Безопасность основана на сложности нахождения ближайшей точки в решётке с сотнями пространственных измерений.
- Приватный ключ ассоциируется с точкой решётки, а публичный — с произвольной точкой в пространстве.
- Code-based cryptography (криптография на основе кодов):
- Приватный ключ связан с кодом, исправляющим ошибки.
- Публичный ключ — это искажённая и ошибочная версия этого кода.
- Безопасность основана на сложности декодирования общего линейного кода.
- Multivariate cryptography (многомерная криптография):
- Основана на сложности решения систем многомерных полиномиальных уравнений.
- Использует сложные математические конструкции для обеспечения безопасности.
Резюме:
- Quantum-breakable методы эффективны сейчас, но уязвимы для будущих квантовых компьютеров.
- Quantum-secure методы разрабатываются для защиты данных в эпоху квантовых вычислений.
(продолжение предыдущего поста)
В зависимости от устойчивости к квантовым вычислениям криптография делится на два основных класса:
1. Quantum-breakable (уязвимые для квантовых атак).
2. Quantum-secure (устойчивые к квантовым атакам).
#### 1. Quantum-breakable (уязвимые для квантовых атак)
Эти методы могут быть взломаны с помощью квантовых компьютеров. К ним относятся:
- RSA encryption (шифрование RSA):
- Сообщение шифруется с помощью публичного ключа получателя.
- Расшифровывается с помощью приватного ключа.
- Безопасность основана на сложности разложения на простые множители (вычисления приватного ключа из публичного).
- Diffie-Hellman key exchange (обмен ключами Диффи-Хеллмана):
- Два участника совместно создают общий секретный ключ по незащищённому каналу.
- Этот ключ используется для зашифрованной коммуникации.
- Безопасность основана на сложности задачи дискретного логарифма.
- Elliptic curve cryptography (криптография на эллиптических кривых):
- Используются математические свойства эллиптических кривых для генерации публичных и приватных ключей.
- Сложность восстановления приватного ключа из публичного связана с задачей дискретного логарифма на эллиптических кривых.
#### 2. Quantum-secure (устойчивые к квантовым атакам)
Эти методы разработаны для защиты от потенциальных квантовых атак. К ним относятся:
- Lattice-based cryptography (решётчатая криптография):
- Безопасность основана на сложности нахождения ближайшей точки в решётке с сотнями пространственных измерений.
- Приватный ключ ассоциируется с точкой решётки, а публичный — с произвольной точкой в пространстве.
- Code-based cryptography (криптография на основе кодов):
- Приватный ключ связан с кодом, исправляющим ошибки.
- Публичный ключ — это искажённая и ошибочная версия этого кода.
- Безопасность основана на сложности декодирования общего линейного кода.
- Multivariate cryptography (многомерная криптография):
- Основана на сложности решения систем многомерных полиномиальных уравнений.
- Использует сложные математические конструкции для обеспечения безопасности.
Резюме:
- Quantum-breakable методы эффективны сейчас, но уязвимы для будущих квантовых компьютеров.
- Quantum-secure методы разрабатываются для защиты данных в эпоху квантовых вычислений.
Telegram
METANIT.COM
Типы криптографии
(описание в следующем посте)
(описание в следующем посте)
👍11❤2❤🔥2🐳1
Полная шпаргалка по командам Docker
(продолжение предыдущего поста)
#### 1. Установка (Installation)
- Установка Docker Engine (только для Linux): [https://docs.docker.com/engine/install/](https://docs.docker.com/engine/install/).
- Установка Docker Desktop (Linux, macOS, Windows): [https://docs.docker.com/desktop/](https://docs.docker.com/desktop/).
#### 2. Команды для работы с контейнерами (Container commands)
- `docker run <image>` — создаёт и запускает новый контейнер.
- `docker run -p 8080:80 <image>` — публикует порт контейнера (80) на порт хоста (8080).
- `docker run -d <image>` — запускает контейнер в фоновом режиме (detached mode).
- `docker run -v <host>:<container> <image>` — монтирует директорию хоста в контейнер.
- `docker ps` — выводит список запущенных контейнеров.
- `docker ps --all` — выводит список всех контейнеров (запущенных и остановленных).
- `docker logs <container_name>` — получает логи контейнера.
- `docker logs -f <container_name>` — получает логи и следит за их обновлением в реальном времени (follow).
- `docker stop <container_name>` — останавливает запущенный контейнер.
- `docker start <container_name>` — запускает остановленный контейнер.
- `docker rm <container_name>` — удаляет контейнер.
#### 3. Выполнение команд внутри контейнера (Executing commands in a container)
- `docker exec <container_name> <command>` — выполняет команду внутри запущенного контейнера.
- `docker exec -it <container_name> bash` — открывает оболочку (shell) внутри запущенного контейнера для интерактивного взаимодействия.
#### 4. Команды для работы с образами (Image commands)
- `docker build -t <image> .` — создаёт новый образ из Dockerfile в текущей директории и присваивает ему тег (tag).
- `docker images` — выводит список локальных образов.
- `docker rmi <image>` — удаляет образ.
#### 5. Команды для работы с реестром контейнеров (Container registry commands)
- `docker login` — авторизуется в Docker Hub.
- `docker login <server>` — авторизуется в другом реестре контейнеров.
- `docker logout` — выходит из Docker Hub.
- `docker logout <server>` — выходит из другого реестра контейнеров.
- `docker push <image>` — загружает образ в реестр.
- `docker pull <image>` — скачивает образ из реестра.
- `docker search <image>` — ищет образы в Docker Hub.
#### 6. Системные команды (System commands)
- `docker system df` — показывает использование дискового пространства Docker.
- `docker system prune` — удаляет неиспользуемые данные (например, остановленные контейнеры, несуществующие образы).
- `docker system prune -a` — удаляет все неиспользуемые данные (включая остановленные контейнеры и образы).
#### 7. Команды Docker Compose
- `docker compose up` — создаёт и запускает контейнеры.
- `docker compose up -d` — создаёт и запускает контейнеры в фоновом режиме.
- `docker compose up --build` — пересобирает образы перед запуском контейнеров.
- `docker compose stop` — останавливает сервисы.
- `docker compose down` — останавливает и удаляет контейнеры и сети.
- `docker compose ps` — выводит список запущенных контейнеров.
- `docker compose logs` — показывает логи всех контейнеров.
- `docker compose logs <service>` — показывает логи конкретного сервиса.
- `docker compose logs -f` — показывает логи и следит за их обновлением.
- `docker compose pull` — скачивает последние образы.
- `docker compose build` — собирает или пересобирает сервисы.
- `docker compose build --pull` — скачивает последние образы перед сборкой.
(продолжение предыдущего поста)
#### 1. Установка (Installation)
- Установка Docker Engine (только для Linux): [https://docs.docker.com/engine/install/](https://docs.docker.com/engine/install/).
- Установка Docker Desktop (Linux, macOS, Windows): [https://docs.docker.com/desktop/](https://docs.docker.com/desktop/).
#### 2. Команды для работы с контейнерами (Container commands)
- `docker run <image>` — создаёт и запускает новый контейнер.
- `docker run -p 8080:80 <image>` — публикует порт контейнера (80) на порт хоста (8080).
- `docker run -d <image>` — запускает контейнер в фоновом режиме (detached mode).
- `docker run -v <host>:<container> <image>` — монтирует директорию хоста в контейнер.
- `docker ps` — выводит список запущенных контейнеров.
- `docker ps --all` — выводит список всех контейнеров (запущенных и остановленных).
- `docker logs <container_name>` — получает логи контейнера.
- `docker logs -f <container_name>` — получает логи и следит за их обновлением в реальном времени (follow).
- `docker stop <container_name>` — останавливает запущенный контейнер.
- `docker start <container_name>` — запускает остановленный контейнер.
- `docker rm <container_name>` — удаляет контейнер.
#### 3. Выполнение команд внутри контейнера (Executing commands in a container)
- `docker exec <container_name> <command>` — выполняет команду внутри запущенного контейнера.
- `docker exec -it <container_name> bash` — открывает оболочку (shell) внутри запущенного контейнера для интерактивного взаимодействия.
#### 4. Команды для работы с образами (Image commands)
- `docker build -t <image> .` — создаёт новый образ из Dockerfile в текущей директории и присваивает ему тег (tag).
- `docker images` — выводит список локальных образов.
- `docker rmi <image>` — удаляет образ.
#### 5. Команды для работы с реестром контейнеров (Container registry commands)
- `docker login` — авторизуется в Docker Hub.
- `docker login <server>` — авторизуется в другом реестре контейнеров.
- `docker logout` — выходит из Docker Hub.
- `docker logout <server>` — выходит из другого реестра контейнеров.
- `docker push <image>` — загружает образ в реестр.
- `docker pull <image>` — скачивает образ из реестра.
- `docker search <image>` — ищет образы в Docker Hub.
#### 6. Системные команды (System commands)
- `docker system df` — показывает использование дискового пространства Docker.
- `docker system prune` — удаляет неиспользуемые данные (например, остановленные контейнеры, несуществующие образы).
- `docker system prune -a` — удаляет все неиспользуемые данные (включая остановленные контейнеры и образы).
#### 7. Команды Docker Compose
- `docker compose up` — создаёт и запускает контейнеры.
- `docker compose up -d` — создаёт и запускает контейнеры в фоновом режиме.
- `docker compose up --build` — пересобирает образы перед запуском контейнеров.
- `docker compose stop` — останавливает сервисы.
- `docker compose down` — останавливает и удаляет контейнеры и сети.
- `docker compose ps` — выводит список запущенных контейнеров.
- `docker compose logs` — показывает логи всех контейнеров.
- `docker compose logs <service>` — показывает логи конкретного сервиса.
- `docker compose logs -f` — показывает логи и следит за их обновлением.
- `docker compose pull` — скачивает последние образы.
- `docker compose build` — собирает или пересобирает сервисы.
- `docker compose build --pull` — скачивает последние образы перед сборкой.
Telegram
METANIT.COM
Полная шпаргалка по командам Docker
(продолжение в следующем посте)
(продолжение в следующем посте)
❤7👍4👏1
Гендиректор Microsoft призвал пользователей перестать называть «шлаком» ИИ‑контент
Генеральный директор Microsoft Сатья Наделла опубликовал пост в LinkedIn, в котором подвел итоги 2025 года. В нём Наделла заявил о необходимости найти новый баланс во взаимодействии человека и ИИ вместо ставшего привычным разделения ИИ на «слоп» и «высокие технологии».
По мнению управленца, подобное разделение следует считать слишком упрощённым. Наделла отметил, что ИИ следует рассматривать как когнитивный инструмент, который усиливает возможности людей, а не побочный продукт, раскрывает человеческий потенциал.
Глава Microsoft отметил, что главной задачей на ближайшие годы станет ответственное распространение ИИ. По мнению Наделлы, человечество скоро перейдёт от восприятия ИИ как отдельных моделей к внедрению в жизнь людей систем, основанных на ИИ. В то же время развитие ИИ опережает способность общества эффективно его использовать, признал Наделла.
https://snscratchpad.com/posts/looking-ahead-2026/
Генеральный директор Microsoft Сатья Наделла опубликовал пост в LinkedIn, в котором подвел итоги 2025 года. В нём Наделла заявил о необходимости найти новый баланс во взаимодействии человека и ИИ вместо ставшего привычным разделения ИИ на «слоп» и «высокие технологии».
По мнению управленца, подобное разделение следует считать слишком упрощённым. Наделла отметил, что ИИ следует рассматривать как когнитивный инструмент, который усиливает возможности людей, а не побочный продукт, раскрывает человеческий потенциал.
Глава Microsoft отметил, что главной задачей на ближайшие годы станет ответственное распространение ИИ. По мнению Наделлы, человечество скоро перейдёт от восприятия ИИ как отдельных моделей к внедрению в жизнь людей систем, основанных на ИИ. В то же время развитие ИИ опережает способность общества эффективно его использовать, признал Наделла.
https://snscratchpad.com/posts/looking-ahead-2026/
sn scratchpad
Looking Ahead to 2026
As I reflect on the past year and look toward the one ahead, there’s no question 2026 will be a pivotal year for AI. Yes, another one. But this moment feels different in a few notable ways.
😁17💩11🤣5🖕4🤡2👍1
РИА Новости: сильнее всего зарплаты в России за год выросли у издателей ПО
Наиболее сильно за последний год зарплаты в России выросли у издателей программного обеспечения – сразу на 137 тысяч рублей на конец октября, следует из расчетов РИА Новости по данным статистики.
Средняя зарплата в России увеличилась за 12 последних месяцев на 13,1 тысячи рублей и составила в октябре 99,7 тысячи рублей. При этом среди отраслей рост был зафиксирован у сотрудников 258 сфер деятельности, а спад – у семи.
Еще на 69 тысяч они увеличились у рыболовов, а на 55,5 тысячи – у сотрудников холдинговых компаний. В пятерку по темпам роста также вошли занятые в сфере аренды интеллектуальной собственности – на 50,7 тысячи рублей, а также разработчики строительных проектов – на 46,3 тысячи рублей.
https://ria.ru/20260104/zarplaty-2066310216.html
Наиболее сильно за последний год зарплаты в России выросли у издателей программного обеспечения – сразу на 137 тысяч рублей на конец октября, следует из расчетов РИА Новости по данным статистики.
Средняя зарплата в России увеличилась за 12 последних месяцев на 13,1 тысячи рублей и составила в октябре 99,7 тысячи рублей. При этом среди отраслей рост был зафиксирован у сотрудников 258 сфер деятельности, а спад – у семи.
Еще на 69 тысяч они увеличились у рыболовов, а на 55,5 тысячи – у сотрудников холдинговых компаний. В пятерку по темпам роста также вошли занятые в сфере аренды интеллектуальной собственности – на 50,7 тысячи рублей, а также разработчики строительных проектов – на 46,3 тысячи рублей.
https://ria.ru/20260104/zarplaty-2066310216.html
РИА Новости
Названа отрасль, в которой сильнее всего за год выросли зарплаты
Наиболее сильно за последний год зарплаты в России выросли у издателей программного обеспечения – сразу на 137 тысяч рублей на конец октября, следует из... РИА Новости, 04.01.2026
❤7
За последний год ваши доходы выросли или снизились?
Anonymous Poll
14%
Сильно выросли
30%
Немного выросли
35%
Остались на том же уровне
12%
Немного снизились
8%
Сильно снизились
👀11🕊3👏1
Что такое взаимоблокировка (deadlock)
(продолжение предыдущего поста)
Рассмотрим взаимоблокировки: условия возникновения, способы предотвращения и стратегии восстановления.
Взаимоблокировка возникает, когда две или более транзакций ожидают, пока другие освободят блокировки на ресурсах, необходимых им для продолжения обработки. В результате складывается ситуация, при которой ни одна из транзакций не может продвинуться дальше — они бесконечно ожидают друг друга.
Условия Коффмана
Условия Коффмана (названы в честь Эдварда Г. Коффмана‑младшего, который впервые сформулировал их в 1971 году) описывают четыре необходимых условия, которые должны присутствовать одновременно для возникновения взаимоблокировки:
* взаимное исключение (Mutual Exclusion);
* удерживание и ожидание (Hold and Wait);
* отсутствие принудительного изъятия (No Preemption);
* циклическое ожидание (Circular Wait).
Предотвращение взаимоблокировок
* Упорядочивание ресурсов: установить полный порядок для всех типов ресурсов и требовать, чтобы каждый процесс запрашивал ресурсы в строго возрастающем порядке.
* Таймауты: процесс, который удерживает ресурсы слишком долго, может быть откатан назад (выполнен откат).
* Алгоритм банкира (Banker’s Algorithm): алгоритм предотвращения взаимоблокировок, который имитирует распределение ресурсов между процессами и помогает определить, безопасно ли удовлетворять запрос на ресурс, исходя из будущего наличия ресурсов. Это позволяет избегать небезопасных состояний.
Восстановление после взаимоблокировки
* Выбор «жертвы»: большинство современных систем управления базами данных (СУБД) и операционных систем реализуют сложные алгоритмы для обнаружения взаимоблокировок и выбора «жертв». Часто допускается настройка критериев выбора «жертвы» через параметры конфигурации. Выбор может основываться на использовании ресурсов, приоритете транзакции, стоимости отката и т. д.
* Откат (Rollback): база данных может выполнить откат всей транзакции или только её части — достаточной для снятия взаимоблокировки. Откаченные транзакции могут быть автоматически перезапущены системой управления базами данных.
(продолжение предыдущего поста)
Рассмотрим взаимоблокировки: условия возникновения, способы предотвращения и стратегии восстановления.
Взаимоблокировка возникает, когда две или более транзакций ожидают, пока другие освободят блокировки на ресурсах, необходимых им для продолжения обработки. В результате складывается ситуация, при которой ни одна из транзакций не может продвинуться дальше — они бесконечно ожидают друг друга.
Условия Коффмана
Условия Коффмана (названы в честь Эдварда Г. Коффмана‑младшего, который впервые сформулировал их в 1971 году) описывают четыре необходимых условия, которые должны присутствовать одновременно для возникновения взаимоблокировки:
* взаимное исключение (Mutual Exclusion);
* удерживание и ожидание (Hold and Wait);
* отсутствие принудительного изъятия (No Preemption);
* циклическое ожидание (Circular Wait).
Предотвращение взаимоблокировок
* Упорядочивание ресурсов: установить полный порядок для всех типов ресурсов и требовать, чтобы каждый процесс запрашивал ресурсы в строго возрастающем порядке.
* Таймауты: процесс, который удерживает ресурсы слишком долго, может быть откатан назад (выполнен откат).
* Алгоритм банкира (Banker’s Algorithm): алгоритм предотвращения взаимоблокировок, который имитирует распределение ресурсов между процессами и помогает определить, безопасно ли удовлетворять запрос на ресурс, исходя из будущего наличия ресурсов. Это позволяет избегать небезопасных состояний.
Восстановление после взаимоблокировки
* Выбор «жертвы»: большинство современных систем управления базами данных (СУБД) и операционных систем реализуют сложные алгоритмы для обнаружения взаимоблокировок и выбора «жертв». Часто допускается настройка критериев выбора «жертвы» через параметры конфигурации. Выбор может основываться на использовании ресурсов, приоритете транзакции, стоимости отката и т. д.
* Откат (Rollback): база данных может выполнить откат всей транзакции или только её части — достаточной для снятия взаимоблокировки. Откаченные транзакции могут быть автоматически перезапущены системой управления базами данных.
Telegram
METANIT.COM
Что такое взаимоблокировка (deadlock)
(продолжение в следующем посте)
(продолжение в следующем посте)
👍4❤2👏1
C# - язык года по версии TIOBE
Рейтинг TIOBE второй раз за 3 года назвал C# языком программирования года (2025 года). В комментарии от TIOBE отмечается, что "C# заслужил это звание, показав наибольший годовой рост в рейтинге. За эти годы язык претерпел фундаментальные изменения. С точки зрения проектирования языка, C# часто был одним из первых, кто перенимал новые тенденции среди основных языков. В то же время он успешно совершил два крупных парадигмальных сдвига: от языка, предназначенного только для Windows, к кроссплатформенному, и от языка, принадлежащего Microsoft, к языку с открытым исходным кодом. C# постоянно развивался в нужный момент."
Среди других победителей - Perl, который, поднялся с 32-й позиции на 11-ю и вновь вошел в топ-20, и R - вернулся в топ-10 во многом благодаря продолжающемуся росту в области науки о данных и стат. вычислений.
Среди проигравших - Go - окончательно потерял место в топ-10 в 2025 г, и Ruby, который выпал из топ-20.
https://www.tiobe.com/tiobe-index/
Рейтинг TIOBE второй раз за 3 года назвал C# языком программирования года (2025 года). В комментарии от TIOBE отмечается, что "C# заслужил это звание, показав наибольший годовой рост в рейтинге. За эти годы язык претерпел фундаментальные изменения. С точки зрения проектирования языка, C# часто был одним из первых, кто перенимал новые тенденции среди основных языков. В то же время он успешно совершил два крупных парадигмальных сдвига: от языка, предназначенного только для Windows, к кроссплатформенному, и от языка, принадлежащего Microsoft, к языку с открытым исходным кодом. C# постоянно развивался в нужный момент."
Среди других победителей - Perl, который, поднялся с 32-й позиции на 11-ю и вновь вошел в топ-20, и R - вернулся в топ-10 во многом благодаря продолжающемуся росту в области науки о данных и стат. вычислений.
Среди проигравших - Go - окончательно потерял место в топ-10 в 2025 г, и Ruby, который выпал из топ-20.
https://www.tiobe.com/tiobe-index/
🥰37🥴14👍8🔥5👎4❤2🤮1🌚1
Базы данных NoSQL
(продолжение предыдущего поста)
Когда говорят о NoSQL, то естественно имеют ввиду базы данных, которые не используют SQL для выполнения запросов к БД. Однако в реальности мир NoSQL очень многогранен, и каждая NoSQL-БД оптимизирована под конкретные задачи. Рассмотрим основные типы БД NoSQL.
1. MongoDB (Document Store)
- Тип: Документоориентированная БД.
- Особенности:
- использует формат BSON (Binary JSON);
- схема не фиксирована (schema-less);
- горизонтальное масштабирование (sharding);
- репликация для высокой доступности.
- Сценарии использования:
- системы управления контентом (CMS);
- управление каталогами.
2. Cassandra (Wide-Column Store)
- Тип: Колоночная БД.
- Особенности:
- столбцы могут варьироваться в разных строках (wide-column);
- распределённая архитектура;
- язык запросов CQL (SQL-подобный для NoSQL);
- оптимизирована для аналитических запросов.
- Сценарии использования:
- управление временными рядами данных;
- рекомендательные системы.
3. Redis (Key-Value Store)
- Тип: Хранилище «ключ-значение».
- Особенности:
- работает в оперативной памяти (in-memory store);
- поддерживает сложные структуры данных;
- механизмы персистентности (RDB, AOF);
- репликация (primary-replica).
- Сценарии использования:
- кэширование данных;
- управление сессиями;
- таблицы лидеров в играх (gaming leaderboard).
4. Couchbase (Document Store with Key-Value Capabilities)
- Тип: Гибридная БД (документоориентированная + хранилище «ключ-значение»).
- Особенности:
- работает в режиме памяти (memory first);
- репликация между центрами обработки данных (XDCR);
- сочетает операции с документами и хранилищем «ключ-значение».
- Сценарии использования:
- системы управления контентом (CMS);
- платформы электронной коммерции.
5. Neo4j (Graph DB)
- Тип: Графовая БД.
- Особенности:
- поддерживает ACID-транзакции;
- использует язык запросов Cypher;
- индексация без дополнительных таблиц (index-free adjacency);
- кластеризация (HA cluster).
- Сценарии использования:
- социальные сети;
- системы обнаружения мошенничества (fraud detection).
6. Amazon DynamoDB (Key-Value and Document Store)
- Тип: Хранилище «ключ-значение» с поддержкой документов.
- Особенности:
- автоматическое масштабирование;
- управление через AWS;
- распределение данных между узлами;
- поддержка DynamoDB Streams.
- Сценарии использования:
- бессерверные приложения (serverless applications);
- IoT-приложения.
7. Apache HBase (Wide-Column Store)
- Тип: Колоночная БД.
- Особенности:
- основана на Google Bigtable;
- интеграция с Hadoop;
- автоматическое шардирование (auto-sharding);
- сильная согласованность (strong consistency).
- Сценарии использования:
- хранилища данных (data warehouse);
- крупномасштабная обработка данных (large-scale data processing).
8. Elasticsearch (Search Engine)
- Тип: Поисковая система на основе документов.
- Особенности:
- построена на Apache Lucene;
- ориентирована на документы;
- шардирование и репликация;
- RESTful API.
- Сценарии использования:
- полнотекстовый поиск (full-text search);
- анализ логов и событий (log and event data analysis).
9. CouchDB (Document Store)
- Тип: Документоориентированная БД.
- Особенности:
- обеспечивает согласованность данных без блокировок;
- использует RESTful API;
- модель согласованности «в конечном счёте» (eventual consistency).
- Сценарии использования:
- мобильные приложения;
- системы управления контентом (CMS).
В итоге каждая NoSQL БД оптимизирована под конкретные задачи:
- документоориентированные (MongoDB, CouchDB) — для веб-приложений и CMS;
- колоночные (Cassandra, HBase) — для аналитических запросов и временных рядов;
- хранилища «ключ-значение» (Redis, DynamoDB) — для кэширования и сессий;
- графовые (Neo4j) — для моделирования сложных связей (социальные сети, рекомендации);
- поисковые (Elasticsearch) — для полнотекстового поиска и анализа логов.
(продолжение предыдущего поста)
Когда говорят о NoSQL, то естественно имеют ввиду базы данных, которые не используют SQL для выполнения запросов к БД. Однако в реальности мир NoSQL очень многогранен, и каждая NoSQL-БД оптимизирована под конкретные задачи. Рассмотрим основные типы БД NoSQL.
1. MongoDB (Document Store)
- Тип: Документоориентированная БД.
- Особенности:
- использует формат BSON (Binary JSON);
- схема не фиксирована (schema-less);
- горизонтальное масштабирование (sharding);
- репликация для высокой доступности.
- Сценарии использования:
- системы управления контентом (CMS);
- управление каталогами.
2. Cassandra (Wide-Column Store)
- Тип: Колоночная БД.
- Особенности:
- столбцы могут варьироваться в разных строках (wide-column);
- распределённая архитектура;
- язык запросов CQL (SQL-подобный для NoSQL);
- оптимизирована для аналитических запросов.
- Сценарии использования:
- управление временными рядами данных;
- рекомендательные системы.
3. Redis (Key-Value Store)
- Тип: Хранилище «ключ-значение».
- Особенности:
- работает в оперативной памяти (in-memory store);
- поддерживает сложные структуры данных;
- механизмы персистентности (RDB, AOF);
- репликация (primary-replica).
- Сценарии использования:
- кэширование данных;
- управление сессиями;
- таблицы лидеров в играх (gaming leaderboard).
4. Couchbase (Document Store with Key-Value Capabilities)
- Тип: Гибридная БД (документоориентированная + хранилище «ключ-значение»).
- Особенности:
- работает в режиме памяти (memory first);
- репликация между центрами обработки данных (XDCR);
- сочетает операции с документами и хранилищем «ключ-значение».
- Сценарии использования:
- системы управления контентом (CMS);
- платформы электронной коммерции.
5. Neo4j (Graph DB)
- Тип: Графовая БД.
- Особенности:
- поддерживает ACID-транзакции;
- использует язык запросов Cypher;
- индексация без дополнительных таблиц (index-free adjacency);
- кластеризация (HA cluster).
- Сценарии использования:
- социальные сети;
- системы обнаружения мошенничества (fraud detection).
6. Amazon DynamoDB (Key-Value and Document Store)
- Тип: Хранилище «ключ-значение» с поддержкой документов.
- Особенности:
- автоматическое масштабирование;
- управление через AWS;
- распределение данных между узлами;
- поддержка DynamoDB Streams.
- Сценарии использования:
- бессерверные приложения (serverless applications);
- IoT-приложения.
7. Apache HBase (Wide-Column Store)
- Тип: Колоночная БД.
- Особенности:
- основана на Google Bigtable;
- интеграция с Hadoop;
- автоматическое шардирование (auto-sharding);
- сильная согласованность (strong consistency).
- Сценарии использования:
- хранилища данных (data warehouse);
- крупномасштабная обработка данных (large-scale data processing).
8. Elasticsearch (Search Engine)
- Тип: Поисковая система на основе документов.
- Особенности:
- построена на Apache Lucene;
- ориентирована на документы;
- шардирование и репликация;
- RESTful API.
- Сценарии использования:
- полнотекстовый поиск (full-text search);
- анализ логов и событий (log and event data analysis).
9. CouchDB (Document Store)
- Тип: Документоориентированная БД.
- Особенности:
- обеспечивает согласованность данных без блокировок;
- использует RESTful API;
- модель согласованности «в конечном счёте» (eventual consistency).
- Сценарии использования:
- мобильные приложения;
- системы управления контентом (CMS).
В итоге каждая NoSQL БД оптимизирована под конкретные задачи:
- документоориентированные (MongoDB, CouchDB) — для веб-приложений и CMS;
- колоночные (Cassandra, HBase) — для аналитических запросов и временных рядов;
- хранилища «ключ-значение» (Redis, DynamoDB) — для кэширования и сессий;
- графовые (Neo4j) — для моделирования сложных связей (социальные сети, рекомендации);
- поисковые (Elasticsearch) — для полнотекстового поиска и анализа логов.
Telegram
METANIT.COM
Базы данных NoSQL
(продолжение в следующем посте)
(продолжение в следующем посте)
❤7👍4🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Lenovo представила первый в мире складной игровой ноутбук - Legion Pro Rollable
Его главная особенность - уникальный сворачиваемый OLED-экран. Дисплей диагональю 16 дюймов может плавно расширяться с двух сторон до 21,5 или даже 24 дюймов.
Правда, с учетом начинки (высокопроизводительная начинка от Intel и видеокарта NVIDIA GeForce RTX 5090 и т.д.) цена, наверное, будет космическая
https://hi-tech.mail.ru/news/140485-lenovo-predstavila-pervyj-v-mire-skladnoj-igrovoj-noutbuk-i-portativnuyu-konsol-na-steamos
Его главная особенность - уникальный сворачиваемый OLED-экран. Дисплей диагональю 16 дюймов может плавно расширяться с двух сторон до 21,5 или даже 24 дюймов.
Правда, с учетом начинки (высокопроизводительная начинка от Intel и видеокарта NVIDIA GeForce RTX 5090 и т.д.) цена, наверное, будет космическая
https://hi-tech.mail.ru/news/140485-lenovo-predstavila-pervyj-v-mire-skladnoj-igrovoj-noutbuk-i-portativnuyu-konsol-na-steamos
🥴23🔥9👏5🤯5🤡3🤮1
Ограничение скорости по API (rate limiting)
(продолжение предыдущего поста)
Ограничение скорости по API (rate limiting) — это механизм контроля числа запросов к API, который защищает сервер от перегрузки и злоупотреблений. На изображении показаны основные методы ограничения скорости, каждый из которых работает по-своему:
1. Time Windows (временные окна):
* устанавливает фиксированные интервалы времени, в течение которых ограничивается количество запросов;
* если лимит запросов в заданный интервал превышен, система возвращает ошибку «RATE LIMIT EXCEEDED!»;
* подходит для контроля частоты обращений к API.
2. Quota-Based (квотирование):
* задаёт общее количество запросов, разрешённых за определённый период времени (например, в день или месяц);
* как только квота исчерпана, дальнейшие запросы блокируются с сообщением «REQUEST LIMIT REACHED!»;
* позволяет равномерно распределить нагрузку на API в течение заданного периода.
3. Token Bucket (алгоритм «ведра с токенами»):
* использует систему токенов для контроля потока запросов: клиент может отправлять запросы только при наличии токенов;
* токены накапливаются с фиксированной скоростью, что обеспечивает равномерный доступ к API;
* если токенов нет, запросы задерживаются до их появления;
* эффективно сглаживает пики нагрузки.
4. IP-Based Rate (ограничение по IP-адресу):
* ограничивает количество запросов, исходящих с одного IP-адреса;
* помогает предотвратить злоупотребления со стороны отдельных клиентов или ботов;
* система анализирует IP-адрес источника запроса и блокирует дальнейшие обращения, если лимит превышен.
5. API Key-Based (ограничение по ключу API):
* связывает лимиты с конкретным API-ключом, выданным клиенту;
* позволяет настраивать индивидуальные квоты и интервалы для разных пользователей или приложений;
* обеспечивает гибкое управление доступом — например, премиум-клиентам можно выделить больше запросов;
* защищает от несанкционированного использования API.
6. Exponential Backoff (экспоненциальное замедление):
* механизм, который заставляет клиента увеличивать интервал между повторными запросами в случае ошибок или превышения лимитов;
* интервал ожидания растёт экспоненциально с каждой неудачной попыткой;
* снижает нагрузку на сервер при массовых ошибках или перегрузках.
Эти методы могут использоваться по отдельности или в комбинации для создания гибкой и надёжной системы ограничения скорости API. Они защищают сервер, обеспечивают справедливое распределение ресурсов и улучшают стабильность работы API для всех пользователей.
(продолжение предыдущего поста)
Ограничение скорости по API (rate limiting) — это механизм контроля числа запросов к API, который защищает сервер от перегрузки и злоупотреблений. На изображении показаны основные методы ограничения скорости, каждый из которых работает по-своему:
1. Time Windows (временные окна):
* устанавливает фиксированные интервалы времени, в течение которых ограничивается количество запросов;
* если лимит запросов в заданный интервал превышен, система возвращает ошибку «RATE LIMIT EXCEEDED!»;
* подходит для контроля частоты обращений к API.
2. Quota-Based (квотирование):
* задаёт общее количество запросов, разрешённых за определённый период времени (например, в день или месяц);
* как только квота исчерпана, дальнейшие запросы блокируются с сообщением «REQUEST LIMIT REACHED!»;
* позволяет равномерно распределить нагрузку на API в течение заданного периода.
3. Token Bucket (алгоритм «ведра с токенами»):
* использует систему токенов для контроля потока запросов: клиент может отправлять запросы только при наличии токенов;
* токены накапливаются с фиксированной скоростью, что обеспечивает равномерный доступ к API;
* если токенов нет, запросы задерживаются до их появления;
* эффективно сглаживает пики нагрузки.
4. IP-Based Rate (ограничение по IP-адресу):
* ограничивает количество запросов, исходящих с одного IP-адреса;
* помогает предотвратить злоупотребления со стороны отдельных клиентов или ботов;
* система анализирует IP-адрес источника запроса и блокирует дальнейшие обращения, если лимит превышен.
5. API Key-Based (ограничение по ключу API):
* связывает лимиты с конкретным API-ключом, выданным клиенту;
* позволяет настраивать индивидуальные квоты и интервалы для разных пользователей или приложений;
* обеспечивает гибкое управление доступом — например, премиум-клиентам можно выделить больше запросов;
* защищает от несанкционированного использования API.
6. Exponential Backoff (экспоненциальное замедление):
* механизм, который заставляет клиента увеличивать интервал между повторными запросами в случае ошибок или превышения лимитов;
* интервал ожидания растёт экспоненциально с каждой неудачной попыткой;
* снижает нагрузку на сервер при массовых ошибках или перегрузках.
Эти методы могут использоваться по отдельности или в комбинации для создания гибкой и надёжной системы ограничения скорости API. Они защищают сервер, обеспечивают справедливое распределение ресурсов и улучшают стабильность работы API для всех пользователей.
Telegram
METANIT.COM
Ограничение скорости по API (rate limiting)
(продолжение в следующем посте)
(продолжение в следующем посте)
❤8👍3🔥3