Microsoft отказывается рассматривать отчёт об уязвимости, если нет видео вместе с письменным объяснением инцидента
Исследователь по ИБ Уилл Дорманн раскритиковал работу Центра реагирования на угрозы безопасности Microsoft (MSRC) за отказ рассматривать его отчёт об уязвимости, пока белый хакер не предоставил компании подробное видео вместе с письменным объяснением обнаруженного инцидента с подтверждающими скриншотам.
В MSRC потребовали предоставить "чёткое видео POC (доказательство концепции) того, как эксплуатируется указанная уязвимость."
Несмотря на то, что Дорманн все таки записал видео об уязвимости, при попытке отправить видео через портал Microsoft загрузка не удалась из‑за ошибки 403...
https://www.theregister.com/2025/03/17/microsoft_bug_report_troll/
Исследователь по ИБ Уилл Дорманн раскритиковал работу Центра реагирования на угрозы безопасности Microsoft (MSRC) за отказ рассматривать его отчёт об уязвимости, пока белый хакер не предоставил компании подробное видео вместе с письменным объяснением обнаруженного инцидента с подтверждающими скриншотам.
В MSRC потребовали предоставить "чёткое видео POC (доказательство концепции) того, как эксплуатируется указанная уязвимость."
Несмотря на то, что Дорманн все таки записал видео об уязвимости, при попытке отправить видео через портал Microsoft загрузка не удалась из‑за ошибки 403...
https://www.theregister.com/2025/03/17/microsoft_bug_report_troll/
The Register
Microsoft wouldn't look at a bug report without a video. Researcher maliciously complied
: Maddening techno bass loop, Zoolander reference, and 14 minutes of time wasted
🤡29😁5🔥3
Вышла новая версия языка Java - Java 24 вместо с комплектом разработки JDK 24. Основные нововведения:
- Stream Gatherers: функциональность в Stream API, которая добавляет ряд операций по работе с потоками данных
- Class-File API: предоставляет стандартный API для анализа, генерации и преобразования файлов классов Java.
- Ahead-of-Time Class Loading & Linking: уменьшает время запуска приложений с помощью сохранения кэша загруженных классов
- Synchronize Virtual Threads without Pinning: решает проблему блокировки платформенных потоков при использовании виртуальных потоков в synchronized-блоках
- Ограничение использования JNI: использование Java Native Interface (JNI) и Foreign Function & Memory (FFM) теперь приводит к предупреждению, а в будущем планируется выбрасывать исключение
- Прекращена поддержка Windows 32-bit x86
Подробнее все нововведения - https://jdk.java.net/24/release-notes
#java #jdk
- Stream Gatherers: функциональность в Stream API, которая добавляет ряд операций по работе с потоками данных
- Class-File API: предоставляет стандартный API для анализа, генерации и преобразования файлов классов Java.
- Ahead-of-Time Class Loading & Linking: уменьшает время запуска приложений с помощью сохранения кэша загруженных классов
- Synchronize Virtual Threads without Pinning: решает проблему блокировки платформенных потоков при использовании виртуальных потоков в synchronized-блоках
- Ограничение использования JNI: использование Java Native Interface (JNI) и Foreign Function & Memory (FFM) теперь приводит к предупреждению, а в будущем планируется выбрасывать исключение
- Прекращена поддержка Windows 32-bit x86
Подробнее все нововведения - https://jdk.java.net/24/release-notes
#java #jdk
❤🔥7🔥1👏1
HTTP 2 и HTTP 3 — в чем разница?
HTTP 1 появился в 1996 году. Уже в следующем году появился HTTP 1.1.
Прошло еще около 20 лет, прежде чем в 2015 году был стандартизирован HTTP 2. А в 2022 был официально стандартизирован HTTP 3.
HTTP 1.1:
☑️ Постоянные соединения — повторное использование соединений вместо открытия новых.
☑️ Передачи кусками — отправляет данные по частям, не дожидаясь полного ответа.
☑️ Улучшенное кэширование — введены заголовки для лучшего кэширования и управления соединениями.
X Последовательные запросы — запросы блокируют друг друга (HoL-блокировка на уровне запроса)
X Необходимо несколько подключений — браузеры использовали несколько TCP-подключений для скорости
В нем были представлены основные функции, которые используются и по сей день.
HTTP2:
☑️ Мультиплексирование — несколько запросов в одном TCP-соединении
☑️ Сжатие заголовков (HPACK) — Уменьшает размер метаданных
☑️ Приоритезация потоков — обеспечивает загрузку критически важных ресурсов в первую очередь
X Блокировка заголовка очереди (HoL) — потерянный пакет блокирует все потоки
Хотя HTTP 2 оптимизировал TCP, он оставался ограниченным блокировкой начала очереди TCP.
HTTP3:
☑️ Построен на QUIC (UDP) — больше никаких узких мест TCP
☑️ Независимые потоки — потеря пакетов в одном потоке не влияет на другие
☑️ Более быстрые рукопожатия — Объединяет настройку транспорта и шифрования за один шаг
☑️ Обязательное шифрование (TLS 1.3) — Безопасность по умолчанию
☑️ Миграция подключений — плавный переход между изменениями в сети
Вкратце: HTTP 2 оптимизировал TCP, но HTTP 3 с помощью QUIC, делает сетевое взаимодействие быстрее, надежнее и зашифрованным по умолчанию
HTTP 1 появился в 1996 году. Уже в следующем году появился HTTP 1.1.
Прошло еще около 20 лет, прежде чем в 2015 году был стандартизирован HTTP 2. А в 2022 был официально стандартизирован HTTP 3.
HTTP 1.1:
☑️ Постоянные соединения — повторное использование соединений вместо открытия новых.
☑️ Передачи кусками — отправляет данные по частям, не дожидаясь полного ответа.
☑️ Улучшенное кэширование — введены заголовки для лучшего кэширования и управления соединениями.
X Последовательные запросы — запросы блокируют друг друга (HoL-блокировка на уровне запроса)
X Необходимо несколько подключений — браузеры использовали несколько TCP-подключений для скорости
В нем были представлены основные функции, которые используются и по сей день.
HTTP2:
☑️ Мультиплексирование — несколько запросов в одном TCP-соединении
☑️ Сжатие заголовков (HPACK) — Уменьшает размер метаданных
☑️ Приоритезация потоков — обеспечивает загрузку критически важных ресурсов в первую очередь
X Блокировка заголовка очереди (HoL) — потерянный пакет блокирует все потоки
Хотя HTTP 2 оптимизировал TCP, он оставался ограниченным блокировкой начала очереди TCP.
HTTP3:
☑️ Построен на QUIC (UDP) — больше никаких узких мест TCP
☑️ Независимые потоки — потеря пакетов в одном потоке не влияет на другие
☑️ Более быстрые рукопожатия — Объединяет настройку транспорта и шифрования за один шаг
☑️ Обязательное шифрование (TLS 1.3) — Безопасность по умолчанию
☑️ Миграция подключений — плавный переход между изменениями в сети
Вкратце: HTTP 2 оптимизировал TCP, но HTTP 3 с помощью QUIC, делает сетевое взаимодействие быстрее, надежнее и зашифрованным по умолчанию
👍14❤5👏2
Шпаргалка по различным типам баз данных:
🔹 Реляционные БД
Хранят данные в таблицах со строками и столбцами, что позволяет выполнять сложные запросы и транзакции с высокой степенью согласованности и целостности, что идеально подходит для структурированных данных, которые хорошо вписываются в схемы.
🔹 Хранилища Ключ-Значение
Хранят данные в виде пар «ключ-значение», обеспечивая быстрый поиск по ключу, идеально подходят для сценариев, где критически важен быстрый доступ к неструктурированным данным.
🔹 In-Memort (БД в оперативной памяти)
Разработаны для обеспечения высокой скорости за счет хранения данных в оперативной памяти, а не на диске, и предлагают сверхбыстрые возможности чтения/записи, подходящие для аналитики и кэширования в реальном времени.
🔹 Документные БД
Хранят данные в виде документов JSON, BSON или XML, что делает их гибкими для хранения, извлечения и управления полуструктурированными данными.
🔹 БД с широкими столбцами (Wide column)
Используют табличный формат, но каждая строка может иметь разный набор столбцов; отлично подходит для анализа больших наборов данных с возможностью горизонтального масштабирования.
🔹 БД на основе графов
Разработаны для хранения сущностей и их взаимосвязей в графовой структуре, что позволяет эффективно запрашивать сложные и взаимосвязанные данные.
🔹 Бд на основе временных рядов (Time-series)
Оптимизированы для хранения и запроса последовательностей точек данных с течением времени, что делает их идеальными для мониторинга, отслеживания событий и аналитики в контекстах, чувствительных ко времени.
#database
🔹 Реляционные БД
Хранят данные в таблицах со строками и столбцами, что позволяет выполнять сложные запросы и транзакции с высокой степенью согласованности и целостности, что идеально подходит для структурированных данных, которые хорошо вписываются в схемы.
🔹 Хранилища Ключ-Значение
Хранят данные в виде пар «ключ-значение», обеспечивая быстрый поиск по ключу, идеально подходят для сценариев, где критически важен быстрый доступ к неструктурированным данным.
🔹 In-Memort (БД в оперативной памяти)
Разработаны для обеспечения высокой скорости за счет хранения данных в оперативной памяти, а не на диске, и предлагают сверхбыстрые возможности чтения/записи, подходящие для аналитики и кэширования в реальном времени.
🔹 Документные БД
Хранят данные в виде документов JSON, BSON или XML, что делает их гибкими для хранения, извлечения и управления полуструктурированными данными.
🔹 БД с широкими столбцами (Wide column)
Используют табличный формат, но каждая строка может иметь разный набор столбцов; отлично подходит для анализа больших наборов данных с возможностью горизонтального масштабирования.
🔹 БД на основе графов
Разработаны для хранения сущностей и их взаимосвязей в графовой структуре, что позволяет эффективно запрашивать сложные и взаимосвязанные данные.
🔹 Бд на основе временных рядов (Time-series)
Оптимизированы для хранения и запроса последовательностей точек данных с течением времени, что делает их идеальными для мониторинга, отслеживания событий и аналитики в контекстах, чувствительных ко времени.
#database
👍12❤2👏1
This media is not supported in your browser
VIEW IN TELEGRAM
Автор YouTube-канала Attoparsec представил проект «самой бесполезной клавиатуры в мире». Она состоит из 1020 клавиш и печатает слова целиком. При этом на клавиатуре есть только 1000 популярных слов в английском языке и модификаторы окончаний, чтобы можно было слегка расширить доступный словарь.
Автор отмечает, что на реализацию проекта потратил полгода. При этом на обычной QWERTY-клавиатуре его скорость печати составляет 70-80 слов в минуту, а на 1000-клавишной — около 10.
Автор отмечает, что на реализацию проекта потратил полгода. При этом на обычной QWERTY-клавиатуре его скорость печати составляет 70-80 слов в минуту, а на 1000-клавишной — около 10.
👏13😁6💩3🍾2💊2
Microsoft неоднократно призывал обновить ОС до Windows 11 на своих компьютерах. Но если раньше для этого использовались всплывающие окна, то теперь компания рассылает электронные письма с аналогичным уведомлением. В письме говорится, что после 14 октября 2025 года Microsoft больше не будет предоставлять бесплатные обновления программного обеспечения через Центр обновления Windows, техническую поддержку или исправления безопасности для Windows 10.
И там же, в письме на гипотетический вопрос пользователей «что я должен сделать со своим старым компьютером», Microsoft дает следующий ответ: «Продайте его или утилизируйте его с помощью местной организации».
К слову, согласно некоторым оценкам, к концу поддержки Windows 10 составит 1 млрд единиц, а на данный момент «десятка» работает где-то на 58% компьютеров по всему миру. Подавляющее же большинство компьютеров, выпущенных до 2018 года, физически не соответствуют заявленным требованиям Windows 11 и обновиться не могут.
И там же, в письме на гипотетический вопрос пользователей «что я должен сделать со своим старым компьютером», Microsoft дает следующий ответ: «Продайте его или утилизируйте его с помощью местной организации».
К слову, согласно некоторым оценкам, к концу поддержки Windows 10 составит 1 млрд единиц, а на данный момент «десятка» работает где-то на 58% компьютеров по всему миру. Подавляющее же большинство компьютеров, выпущенных до 2018 года, физически не соответствуют заявленным требованиям Windows 11 и обновиться не могут.
😢20🤮10👍5🤬5😁3🤔2🥱1
Шаблоны проектирования — это многоразовые решения распространенных проблем, которые можно применять на разных языках и платформах.
Они делятся на три категории:
🟢 Порождающие паттерны (𝗖𝗿𝗲𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): гибко управляют созданием объектов
🟣 Структурные паттерны (𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): организуют объекты в более крупные структуры
🟡 Поведенческие паттерны (𝗕𝗲𝗵𝗮𝘃𝗶𝗼𝗿𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): управляют тем, как объекты взаимодействуют друг с другом.
Наиболее распространенные 7 шаблонов:
𝟭. 𝗦𝗶𝗻𝗴𝗹𝗲𝘁𝗼𝗻 - Гарантирует существование только одного экземпляра
𝟮. 𝗕𝘂𝗶𝗹𝗱𝗲𝗿 - Строит сложные объекты шаг за шагом
𝟯. 𝗙𝗮𝗰𝘁𝗼𝗿𝘆 - Создает объекты без указания точного класса
𝟰. 𝗙𝗮𝗰𝗮𝗱𝗲 - Упрощает сложные системы с помощью понятного, унифицированного интерфейса
𝟱. 𝗔𝗱𝗮𝗽𝘁𝗲𝗿 - Заставляет несовместимые интерфейсы работать вместе
𝟲. 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 - Динамически меняет алгоритмы
𝟳. 𝗢𝗯𝘀𝗲𝗿𝘃𝗲𝗿 - Для поддержания зависимостей между объектами
Они делятся на три категории:
🟢 Порождающие паттерны (𝗖𝗿𝗲𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): гибко управляют созданием объектов
🟣 Структурные паттерны (𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): организуют объекты в более крупные структуры
🟡 Поведенческие паттерны (𝗕𝗲𝗵𝗮𝘃𝗶𝗼𝗿𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀): управляют тем, как объекты взаимодействуют друг с другом.
Наиболее распространенные 7 шаблонов:
𝟭. 𝗦𝗶𝗻𝗴𝗹𝗲𝘁𝗼𝗻 - Гарантирует существование только одного экземпляра
𝟮. 𝗕𝘂𝗶𝗹𝗱𝗲𝗿 - Строит сложные объекты шаг за шагом
𝟯. 𝗙𝗮𝗰𝘁𝗼𝗿𝘆 - Создает объекты без указания точного класса
𝟰. 𝗙𝗮𝗰𝗮𝗱𝗲 - Упрощает сложные системы с помощью понятного, унифицированного интерфейса
𝟱. 𝗔𝗱𝗮𝗽𝘁𝗲𝗿 - Заставляет несовместимые интерфейсы работать вместе
𝟲. 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 - Динамически меняет алгоритмы
𝟳. 𝗢𝗯𝘀𝗲𝗿𝘃𝗲𝗿 - Для поддержания зависимостей между объектами
❤5👍1🔥1👏1
Наиболее распростраенные архитектурные паттерны
𝟭. Слоистая урхитектура : Разделяет приложения на логические слои (Presentation, Business, Data) с определенными обязанностями. Способствует разделению ответственности между различными частями приложения и упрощает поддержку и развитие приложения
𝟮. Микросервисы: Разбивает приложения на небольшие независимые сервисы, взаимодействующие через API. Каждый реализует одну бизнес-возможность и может быть развернут независимо от других сервисов, обеспечивая автономность и непрерывную доставку
𝟯. Событийная архитектура: Использует события для асинхронной связи между компонентами. Система не ждет завершения обработки событий, что делает ее идеальной для приложений реального времени, требующих высокой масштабируемости
𝟰. 𝗦𝗽𝗮𝗰𝗲-𝗯𝗮𝘀𝗲𝗱: Использует независимые "пространства" как автономные единицы на нескольких серверах. Устраняет отдельные точки отказа в системах с большим объемом данных и преодолевает узкие места в данных и сетевые задержки
𝟱. Микроядерная архитектура: Предоставляет минимальную базовую функциональность с дополнительными службами в виде отдельных модулей. Разработчики могут изменять компоненты, не влияя на базовую функциональность, что идеально подходит для приложений, требующих настройки.
𝟲. 𝗖𝗤𝗥𝗦 (𝗖𝗼𝗺𝗺𝗮𝗻𝗱-𝗤𝘂𝗲𝗿𝘆 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗦𝗲𝗴𝗿𝗲𝗴𝗮𝘁𝗶𝗼𝗻): Разделяет операции чтения и записи на отдельные модели. Улучшает производительность и масштабируемость в сложных доменах за счет независимой оптимизации каждого пути.
𝟳. Гексагональная: Изолирует бизнес-логику от внешних задач. Позволяет приложениям управляться различными источниками и разрабатываться независимо от зависимостей времени выполнения
𝟭. Слоистая урхитектура : Разделяет приложения на логические слои (Presentation, Business, Data) с определенными обязанностями. Способствует разделению ответственности между различными частями приложения и упрощает поддержку и развитие приложения
𝟮. Микросервисы: Разбивает приложения на небольшие независимые сервисы, взаимодействующие через API. Каждый реализует одну бизнес-возможность и может быть развернут независимо от других сервисов, обеспечивая автономность и непрерывную доставку
𝟯. Событийная архитектура: Использует события для асинхронной связи между компонентами. Система не ждет завершения обработки событий, что делает ее идеальной для приложений реального времени, требующих высокой масштабируемости
𝟰. 𝗦𝗽𝗮𝗰𝗲-𝗯𝗮𝘀𝗲𝗱: Использует независимые "пространства" как автономные единицы на нескольких серверах. Устраняет отдельные точки отказа в системах с большим объемом данных и преодолевает узкие места в данных и сетевые задержки
𝟱. Микроядерная архитектура: Предоставляет минимальную базовую функциональность с дополнительными службами в виде отдельных модулей. Разработчики могут изменять компоненты, не влияя на базовую функциональность, что идеально подходит для приложений, требующих настройки.
𝟲. 𝗖𝗤𝗥𝗦 (𝗖𝗼𝗺𝗺𝗮𝗻𝗱-𝗤𝘂𝗲𝗿𝘆 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗦𝗲𝗴𝗿𝗲𝗴𝗮𝘁𝗶𝗼𝗻): Разделяет операции чтения и записи на отдельные модели. Улучшает производительность и масштабируемость в сложных доменах за счет независимой оптимизации каждого пути.
𝟳. Гексагональная: Изолирует бизнес-логику от внешних задач. Позволяет приложениям управляться различными источниками и разрабатываться независимо от зависимостей времени выполнения
❤7👍5👏1
Кэширование позволяет увеличить производительность приложение. И в данном случае важную роль играет коэффициент попадания в кэш (Cache Hit Ratio).
Прежде всего надо сказать, что попадаение в кэш или Cache Hit означает, что данные найдены в кэше. А промах кэша или Cache Miss означает, что данные в кэше не найдены, и надо для получения данных обращаться к хранилищу данных, например, базе данных. И каждый промах кэша — это небольшое снижение производительности.
Коэффициент попадания в кэш рассчитывается путем деления количества попаданий в кэш на общее количество поисков в кэше (попадания и промахи, общее количество запросов к кэшу) с последующим умножением на 100 для получения процента.
Cache Hit Ratio (%) = (Cache Hits / Total Lookups) x 100
Где
Cache Hit Ratio - Коэффициент попаданий в кэш (%),
Cache Hits - Число попаданий в кэш
Total Lookups - Общее количество поисков
Данный коэффициент измеряет, как часто данные извлекаются из кэша, а не из основного хранилища, что отражает эффективность работы кэша.
Проще говоря, это процент, который показывает нам, какая часть от общего числа запросов удовлетворяется кэшем, а не отправляется в основное хранилище (например, базу данных, API и т. д.).
Для контекста рассмотрим простой пример:
• Ваш сервис получает 10 запросов
• Первый запрос запрашивает кэш, ничего не находит (промах кэша / cache miss), запрашивает базу данных, а затем сохраняет результат в кэше.
• Следующие 9 запросов попадают в кэш и обслуживаются немедленно (попадаение в кэш/cache hit).
В этом сценарии у вас будет 9 попаданий в кэш из 10 общих поисков, что дает коэффициент попадания в кэш 90%.
Хотя универсальной цифры не существует, общее руководство следующее:
• Кэширование запросов к базе данных: 85-95%
• Кэширование ответов API: 95-99%
• Крупномасштабные CDN: 99%+
3 способа увеличить коэффициент попадания в кэш
• Предварительно загружайте наиболее запрашиваемые данные в кэша во время развертывания приложения или холодного запуска, чтобы избежать первоначального сильного роста промахов кэша.
• Настройте значение времени жизни (TTL). Если оно слишком короткое, элементы быстро устаревают, что приводит к пропускам. Если слишком большое, вы рискуете предоставить устаревшие данные.
• Убедитесь, что ключи уникальны, но предсказуемы, чтобы предотвратить пропуски записей в кэше.
Высокий коэффициент попадания в кэш — это хорошо, но не за счет предоставления устаревшей информации, поэтому всегда необходим баланс между эффективностью кэширования и актуальностью данных.
Прежде всего надо сказать, что попадаение в кэш или Cache Hit означает, что данные найдены в кэше. А промах кэша или Cache Miss означает, что данные в кэше не найдены, и надо для получения данных обращаться к хранилищу данных, например, базе данных. И каждый промах кэша — это небольшое снижение производительности.
Коэффициент попадания в кэш рассчитывается путем деления количества попаданий в кэш на общее количество поисков в кэше (попадания и промахи, общее количество запросов к кэшу) с последующим умножением на 100 для получения процента.
Cache Hit Ratio (%) = (Cache Hits / Total Lookups) x 100
Где
Cache Hit Ratio - Коэффициент попаданий в кэш (%),
Cache Hits - Число попаданий в кэш
Total Lookups - Общее количество поисков
Данный коэффициент измеряет, как часто данные извлекаются из кэша, а не из основного хранилища, что отражает эффективность работы кэша.
Проще говоря, это процент, который показывает нам, какая часть от общего числа запросов удовлетворяется кэшем, а не отправляется в основное хранилище (например, базу данных, API и т. д.).
Для контекста рассмотрим простой пример:
• Ваш сервис получает 10 запросов
• Первый запрос запрашивает кэш, ничего не находит (промах кэша / cache miss), запрашивает базу данных, а затем сохраняет результат в кэше.
• Следующие 9 запросов попадают в кэш и обслуживаются немедленно (попадаение в кэш/cache hit).
В этом сценарии у вас будет 9 попаданий в кэш из 10 общих поисков, что дает коэффициент попадания в кэш 90%.
Хотя универсальной цифры не существует, общее руководство следующее:
• Кэширование запросов к базе данных: 85-95%
• Кэширование ответов API: 95-99%
• Крупномасштабные CDN: 99%+
3 способа увеличить коэффициент попадания в кэш
• Предварительно загружайте наиболее запрашиваемые данные в кэша во время развертывания приложения или холодного запуска, чтобы избежать первоначального сильного роста промахов кэша.
• Настройте значение времени жизни (TTL). Если оно слишком короткое, элементы быстро устаревают, что приводит к пропускам. Если слишком большое, вы рискуете предоставить устаревшие данные.
• Убедитесь, что ключи уникальны, но предсказуемы, чтобы предотвратить пропуски записей в кэше.
Высокий коэффициент попадания в кэш — это хорошо, но не за счет предоставления устаревшей информации, поэтому всегда необходим баланс между эффективностью кэширования и актуальностью данных.
🔥11👍1