А вы уже забрали свой подарок ко Дню программиста?

Мы в Tproger вместе с нашими друзьями собрали целую коробку подарков к вашему профессиональному празднику. Переходите по ссылке, трясите коробку и забирайте свой презент: https://tprg.ru/CscV

Cloudflare автоматизировала обмен ключами с серверами сайтов

Cloudflare включила Automatic Key Exchange по умолчанию для доменов. Функция касается защищённого соединения между прокси Cloudflare и сайтом. Раньше Cloudflare начинала обмен по TLS 1.3 с X25519; при другом выборе сервера повтор добавлял полный сетевой круг.

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

При развёртывании доля повторов снизилась примерно с 52% до 3,7%, а задержка на 90-м процентиле сократилась более чем на 150 мс. Сотни тысяч доменов получили постквантовые соединения без ручной настройки. Разбор Cloudflare пригодится тем, кто отвечает за TLS: в панели можно проверить режим и ограничения по стандартам.

Как балансировщик выбирает сервер и почему медианы недостаточно

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

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

В статье на samwho.dev параметры меняются в симуляциях. Читать стоит тем, кто выбирает балансировку: сравнивайте медиану, хвостовые задержки, отказы и поведение под своей нагрузкой.

Как устроен аллокатор памяти и почему свободных байтов может не хватить

Интерактивная статья ведёт от malloc и free к своему аллокатору. Сетка байтов позволяет видеть каждый запрос.

Карта разбора:
1. Простейший аллокатор выдаёт следующий участок, но не возвращает память: он не хранит границы блоков;
2. Универсальный хранит адрес и размер, а при освобождении объединяет соседние участки;
3. 6 свободных байтов не спасают, если они разбиты на два участка по 3 байта;
4. Минимальный блок в 4 байта в показанном примере снижает внешнюю фрагментацию, но при запросах по 1 байту оставляет неиспользованными 75% памяти.

Материал Memory Allocation стоит читать тем, кто хочет написать свой аллокатор. Выбирать способ распределения памяти нужно под размеры и порядок запросов программы: один алгоритм не подходит всем нагрузкам.

Как устроены хеш-функции и зачем им равномерное распределение

Статья с интерактивными визуализациями показывает превращение строки в число и способы оценить результат. Коллизии неизбежны: если диапазон содержит 8 значений, среди 9 разных входов хотя бы два дадут одинаковое число.

Хорошая функция равномерно распределяет результаты и создаёт лавинный эффект: при изменении одного входного бита в среднем меняется 50% выходных. murmur3 сравнивают с функцией, которая суммирует коды символов по модулю 1 000 000. На случайных строках разница почти незаметна, но числа от 1 до 1 000 образуют у простой функции узоры.

Затем автор собирает на JavaScript хеш-таблицу из корзин: хеш ключа выбирает корзину, а поиск перебирает её элементы до совпадения. Статья Hashing связывает знакомый Map с распределением данных и показывает, почему хеш-функцию нельзя оценивать только на случайном вводе.

Как читать Rust-код: карта синтаксиса за полчаса

Это обстоятельный разбор базовой грамматики Rust. Автор читает множество коротких фрагментов и объясняет значение ключевых слов и символов.

Путь начинается с let, типов и повторного объявления имени, которое создаёт новую переменную. Затем идут кортежи, функции и блоки-выражения. На примерах видно, почему отсутствие точки с запятой возвращает значение блока, как _ отбрасывает ненужный результат и чем вызов метода через точку отличается от :: в пути к имени. Отдельно разобраны импорт через use, автоматически доступные стандартные имена, структуры и их разбор на поля.

A half-hour to learn Rust стоит открыть перед первым чтением Rust-кода. Страница обновлялась около семи лет назад: актуальные библиотеки и практики нужно сверять со свежей документацией, а основы синтаксиса здесь остаются удобной системой координат.

Как сделать распределённую блокировку безопасной

Процесс может зависнуть дольше срока блокировки, проснуться после передачи права другому узлу и затереть его запись. Сервис блокировок от этого не спасает.

В обстоятельном разборе распределённых блокировок Мартин Клеппманн разделяет две задачи:
— для экономии допустим редкий повтор работы;
— для корректности два владельца означают потерю данных или расхождение состояния.

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

Разбор пригодится тем, кто полагается на блокировку ради корректности. Проверьте, умеет ли хранилище отвергать устаревшие операции: проверки срока перед записью недостаточно, ведь процесс может остановиться после неё.

Как Discord перенёс триллионы сообщений с Cassandra на ScyllaDB

В обстоятельном разборе Discord показывает перестройку всего пути запроса. В начале 2022 года Cassandra состояла из 177 узлов, но один перегруженный раздел мог замедлить весь кластер.

Между API и базой появились сервисы данных на Rust. Одновременные запросы одной строки объединялись: базу опрашивала одна задача, остальные клиенты получали её результат. Маршрутизация по идентификатору канала направляла такие запросы в один экземпляр сервиса, чтобы объединение срабатывало чаще.

Готовый переносчик оценил миграцию в три месяца. Собственный вариант на Rust сократил оценку до девяти дней и переносил до 3,2 млн сообщений в секунду. Разбор пригодится при защите базы от всплесков и переходе без простоя: смены СУБД недостаточно, параллельные запросы нужно ограничивать до неё, а ответы двух систем сверять во время миграции.

В 2001 году появился SpaceWeb — тогда же весь рунет жил в аське, разбирался с первыми сайтами и понятия не имел, что такое биткоин. К своему 25-летию компания вместе с Типичным программистом сделала анкету, которая возвращает в те годы: школьные вопросы про спорт, лучшего друга и обои на рабочий стол, а рядом — Winamp, QIWI-терминалы во дворах, Покемон Go и попытка заглянуть в будущее.

Как устроен асинхронный веб-краулер на Python

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

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

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

В главе «A Web Crawler With asyncio Coroutines» из 500 Lines or Less код написан для Python 3.4. Читайте ради механики цикла событий; перед копированием сверяйте API с документацией.

Как тестирование на основе свойств отделяет правило от примера

Обстоятельная статья Increment разбирает подход на Python и Hypothesis. Обычный тест проверяет проект с лимитом в 3 участника и тремя пользователями. Название обещает работу с любым лимитом, хотя код подтверждает только этот набор. Тест на основе свойств вместо одного примера задаёт допустимые входы и условие для каждого из них.

Hypothesis получает диапазоны входов через @given. Здесь меняются название проекта и список пользователей с уникальными адресами, а лимит равен длине списка. Случайные детали тестовых данных перестают быть скрытыми требованиями.

На Argon2 подход нашёл старый баг: при hash_len=513 фиксированный буфер C-библиотеки приводил к ошибке проверки созданного хеша. Если поддерживаете тестовую базу, найдите тесты, чьи названия обещают больше одного примера, и отделите меняющиеся входы от проверяемого правила.

Как конечные автоматы индексируют миллиарды строк

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

Далее библиотека fst на Rust и опыты. Индекс 16 млн заголовков Wikipedia объёмом 384 МБ построился за 18,3 секунды и занял 157 МБ. Поиск по регулярному выражению занял 0,023 секунды, нечёткий поиск с двумя правками: 0,094 секунды. Финал: более 1,6 млрд URL из Common Crawl объёмом 134 ГБ.

В лонгриде Эндрю Галланта разобраны границы: нужен быстрый доступ к произвольному участку файла, а структура не универсальна. Читать разработчикам поиска и словарей, чтобы оценить вариант индекса.

Как работает однопошаговый отладчик Linux на ptrace

Обстоятельная статья разбирает основу отладчика. Дочерний процесс вызывает PTRACE_TRACEME и запускает программу через execl. Ядро останавливает её перед первой инструкцией и уведомляет родителя. Тот выполняет PTRACE_SINGLESTEP, ждёт следующей остановки и повторяет цикл.

На этом каркасе автор показывает, как считать инструкции и читать регистры через PTRACE_GETREGS. Тест с Hello World даёт более 100 000 инструкций при динамической компоновке, около 7 000 при статической и ровно 7 в версии на ассемблере. Счётчик захватывает загрузчик библиотек, инициализацию и очистку библиотеки C, а не только main.

Статья Эли Бендерски даёт модель взаимодействия отладчика с ОС. Код для 32-битной Ubuntu зависит от платформы, поэтому переносить его буквально не стоит. Читать системным разработчикам и тем, кто хочет понять механику пошаговой отладки.

Как работает фильтр Блума и когда его неточность экономит память

Фильтр Блума сообщает: «элемента точно нет» или «элемент, возможно, есть». Ложные срабатывания допустимы, но добавленное значение он не пропускает. Так можно отсечь часть запросов перед точной проверкой.

В обстоятельном разборе Bloom Filters при добавлении значения хеш-функции выбирают позиции в битовом массиве и записывают в них единицы. Совпадение всех позиций означает «возможно». Автор объясняет, как заполнение повышает долю ложных срабатываний, как подобрать размер массива и число функций, почему удаление может стереть следы других значений.

В примере список из миллиона вредоносных ссылок занимает 20 МБ. Фильтр с одним ложным срабатыванием на миллион проверок занимает 3,59 МБ, на 82% меньше; ответ «возможно» можно сверить с полной базой через API. Для отсева заранее оцените объём данных и приемлемую долю ошибок.

Как собрать модель пиковой нагрузки из боевой телеметрии

Обстоятельный гайд о замене выгрузок, таблиц и догадок запросами к телеметрии. В примере ручная подготовка занимает 13–22 человеко-часа, автоматическая: менее 5 минут.

Метод ведёт от самого нагруженного дня к часу и минуте. Затем пик переводят в запросы в секунду, рассчитывают доли сценариев и число одновременно работающих виртуальных пользователей. Запросы даны для New Relic и Dynatrace.

Peak Workload Analyzer выполняет шесть этапов и формирует HTML-панель, JSON-отчёт и карту пользовательских путей. Для запуска нужны Java 11+, Maven 3.6+ и минимум 30 дней боевого трафика с известным пиком.

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

Как проверять изменения без риска для всего трафика

Компактный разбор о снижении риска при выкатывании изменений. Если сразу перевести на новую версию весь рабочий трафик, поломка проявится у пользователей.

Четыре слоя проверки дополняют друг друга. Канареечный выпуск постепенно увеличивает долю трафика под наблюдением за ошибками, задержками, ресурсами и повторами запросов. Зеркалирование копирует рабочие запросы в новую версию, но игнорирует её ответы.

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

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

Почему одни движки регулярных выражений зависают, а другие нет

Обстоятельная статья Расса Кокса сравнивает алгоритм, применяемый Perl и рядом языков, с автоматом Томпсона, построенным из состояний и переходов.

В тесте 2007 года Perl сопоставлял строку из 29 букв «a» больше 60 секунд, а реализация автомата Томпсона справилась за 20 микросекунд, в миллион раз быстрее. Её код занимал менее 400 строк на C. Автор ведёт от синтаксиса выражений и конечных автоматов к преобразованию выражения в автомат и его реализации.

Граница: обратные ссылки вроде \1 выводят шаблон за пределы регулярных языков и в худшем случае требуют экспоненциального поиска. Материал стоит читать разработчикам движков и тем, кто выбирает библиотеку: для шаблонов без обратных ссылок проверяйте, использует ли она автомат Томпсона.

Как процессор предсказывает ветвления

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

В учебной модели ветвления составляют 20% инструкций, а промах стоит 20 тактов. Без предсказания получается 4,8 такта на инструкцию, с идеальным — один. Прогноз по последнему результату ветвления повышает точность до 85%.

Материал «Branch prediction» ведёт от статических правил к таблице истории и объясняет, почему разные переходы могут занять одну её ячейку. Читать стоит тем, кто исследует низкоуровневую производительность или хочет понимать работы о предсказателях. Расчёты сделаны на упрощённой модели, поэтому цену ветвлений в коде нужно измерять.

Как LMAX вынесла торговую логику в один поток

Разбор архитектуры LMAX показывает, почему многопоточность не всегда ускоряет критический путь. Бизнес-логика торговой платформы последовательно обрабатывала заявки в памяти. На сервере с двумя четырёхъядерными процессорами Nehalem по 3 ГГц и 32 ГБ памяти один поток достигал 6 млн заявок в секунду. Это исторический результат 2011 года, а не ориентир для любой системы.

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

Статья Мартина Фаулера об архитектуре LMAX даёт карту этих компромиссов. Читать стоит разработчикам высоконагруженных систем: чтобы перед добавлением потоков отделить вычисления от ввода-вывода и измерить варианты на своей нагрузке.

Как выбрать равновероятную выборку из потока неизвестной длины

Интерактивный разбор объясняет reservoir sampling, или резервуарную выборку. Алгоритм держит k элементов. Для элемента с номером n шанс попасть в массив равен k/n; при выборе он заменяет один из сохранённых случайным образом. Поэтому каждый элемент потока имеет равный шанс остаться в результате.

Механизм показан на картах, а затем на сервисе сбора логов. При k=5 сервис хранит не больше пяти сообщений и раз в секунду отправляет выборку: при потоке до пяти сообщений сохраняет все, а во время всплеска выбирает пять без преимущества у первых событий. Цена предсказуемой памяти: логи поступают пачками, а не непрерывно.

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