Вышел Cloudflare 2024 Year in Review

Из интересного:
Starlink продолжает революцию в подключении:
Значительный рост трафика в новых рынках, таких как Зимбабве и Малави, показывает огромный потенциал спутникового интернета. Особенно интересен 900-кратный рост трафика в Парагвае.

Постквантовое шифрование набирает популярность:
Постквантовая криптография защищает данные от угроз со стороны квантовых компьютеров, которые теоретически смогут взламывать традиционные алгоритмы шифрования (например, RSA или ECC). В 2024 году доля трафика, использующего постквантовое шифрование в TLS 1.3, выросла до 13%, что стало значительным скачком по сравнению с 2% в начале года.

Уменьшение активности некоторых ИИ-ботов:
Падение активности Bytespider от ByteDance может сигнализировать об изменении стратегий сбора данных для моделей ИИ, возможно, из-за регуляторного давления.

Аномальное поведение TCP-соединений:
TCP-соединения часто завершаются неожиданно на разных стадиях без передачи полезных данных. В 2024 году 20.7% соединений с Cloudflare прерывались на ранних этапах, и почти половина из них завершалась после получения сервера SYN, но до передачи подтверждающего пакета ACK.
Возможные причины:
Сканирование и тестирование: Скрипты и программы для сканирования сети могут инициировать соединения, но не доводить их до конца.
DoS-атаки: Злоумышленники часто создают массовое количество неполных соединений, чтобы перегрузить серверы.
Фильтрация трафика: Провайдеры или посредники могут прерывать соединения, особенно в странах с ограничением доступа к определенным сайтам или сервисам.

Неравномерность внедрения HTTP/3:
2024
HTTP/3, который работает на основе нового протокола QUIC, обещает улучшенную производительность и встроенную шифрацию, но его использование остается неравномерным. В 2024 году только 20.5% запросов использовали HTTP/3, несмотря на его преимущества. В то же время 49.6% запросов все еще используют HTTP/2, а почти 30% — старые версии HTTP/1.x.

Опасность новых TLD:
Некоторые новые доменные зоны, такие как .bar, .rest и .uno, продемонстрировали, что более 99% писем с таких доменов являются либо спамом, либо вредоносными. Среди национальных доменов (ccTLD) худший результат у .ws (Западное Самоа), где более 90% писем оказались вредоносными.
Многие из этих доменов предоставляются по заниженной стоимости или используются для "парковки" доменных имен, что привлекает злоумышленников.
Отсутствие строгого контроля или регулирования делает их "серыми зонами" для размещения сомнительного контента..

Рост языка Go для API-запросов:
Факт, что Go обогнал NodeJS, подчеркивает сдвиг в сторону высокопроизводительных и масштабируемых решений. Это может быть связано с ростом микросервисной архитектуры и потребностью в быстрой обработке запросов.

Разбираемся в дефолтных и откладываемых (деферрабельных) констрейнах в PostgreSQL

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

UPDATE numbers SET number = number + 1; \-\- Ошибка: Duplicate key value violates unique constraint

Почему так происходит? Дело в том, что проверка ограничений выполняется для каждой строки в транзакции, и если хотя бы одна из них нарушает уникальность, операция завершается ошибкой. Это неудобно, особенно если вы хотите массово изменить данные в рамках одной транзакции. Но постгрес так же позволяет создавать деферрабельные (отложенные) констрейны, которые проверяются не сразу, а только в момент завершения транзакции при выполнении команды COMMIT.

Отложенные ограничения можно настроить двумя способами. Первый — DEFERRABLE INITIALLY IMMEDIATE — позволяет отложить проверку ограничений вручную, изменив поведение внутри транзакции с помощью команды SET CONSTRAINTS <constraint_name> DEFERRED. Второй вариант — DEFERRABLE INITIALLY DEFERRED — изначально предполагает, что проверка всегда будет происходить в конце транзакции, что особенно полезно в случаях, когда временное нарушение ограничений не критично и будет исправлено до завершения транзакции.

На первый взгляд кажется логичным сделать все ограничения отложенными, ведь это позволяет избежать ошибок при массовых обновлениях и сложных операциях. Однако на практике это может привести к проблемам. Во-первых, использование отложенных ограничений снижает производительность. Планировщик запросов в PostgreSQL полагается на уникальность данных для оптимизации выполнения запросов. Если уникальность не гарантируется на каждом шаге транзакции, то некоторые оптимизации становятся невозможными, и выполнение запросов замедляется.

Также стоит учитывать, что отложенные проверки нельзя использовать для ограничений типа NOT NULL и CHECK. Эти типы ограничений всегда проверяются немедленно, что ограничивает применение деферрабельных настроек.

больше примеров использование деферрабельных констрейнов можно посмотреть тут:
https://emmer.dev/blog/deferrable-constraints-in-postgresql/

https://gekk.info/articles/traceroute.htm

tldr: Traceroute - это хак, а не настоящий сетевой протокол. Он работает случайно и ненадёжно. Маршрутизаторы не обязаны на него отвечать, и часто не отвечают. В современных сетях (особенно с MPLS) он показывает неверную информацию. Отсутствие ответа или высокая задержка в traceroute ничего не значат.