Опубликована подробная диаграмма стека сети Linux, созданная Hrvoje Horvat из Ericsson Nikola Tesla. Диаграмма охватывает все уровни сетевого стека: виртуализацию и контейнеры, сокеты, TCP/UDP и нижние уровни с GRO, RPS, RFS и GSO, планировщик сети, NetFilter, управление трафиком, драйверы устройств и функции, ускоренные сетевой картой. Каждый раздел содержит советы по оптимизации и статистику.

Диаграмма доступна в формате PDF (5.4 МБ) и является частью книги "Operativni sustavi i računalne mreže - Linux u primjeni". На момент публикации материал получил 515 просмотров и 380 загрузок. Работа распространяется под лицензией Creative Commons Attribution 4.0 International, что позволяет свободно использовать и распространять диаграмму при обязательном указании автора.

• Диаграмма показывает, как пакет проходит через iptables и Netfilter, что вызвало обсуждение о сложности и важности визуализации в Linux.
• Участники обсуждали, что такие диаграммы редко охватывают контейнеры и виртуализацию, и что отсутствие обновлений может сделать их устаревшими.
• Были вопросы о доступности этих диаграм на разных языках и о том, где можно найти больше информации о книге, из которой они были взяты.
• Также обсуждались вопросы о том, как эти диаграммы могут быть использованы в образовательных целях и о том, что делает их такими полезными для понимания сложных систем.
• В конце, обсуждалось, что такие диаграммы могут быть трудны для чтения в формате PDF и что было бы полезно иметь SVG версию.

Крупные компании и хостинг-провайдеры активно внедряют MPTCP (Multipath TCP) для повышения отказоустойчивости и производительности. Например, Google и Meta используют его для распределения трафика между сотовыми сетями и Wi-Fi.

MPTCP позволяет одному соединению использовать несколько сетевых интерфейсов одновременно — например, 5G и Wi-Fi — повышая надёжность: если один путь недоступен, трафик автоматически переключается на другой.

В отличие от обычного TCP, MPTCP также поддерживает многопоточность на уровне ядра Linux, что ускоряет передачу данных. Однако для работы MPTOS требуется поддержка на обоих концах соединения, что пока ограничивает его применение.

• MPTCP и SCTP обсуждаются как способы объединения нескольких каналов, но оба сталкиваются с проблемами: MPTCP требует специфической поддержки в ядре и приложениях, а SCTP не поддерживается большинством маршрутизаторов и имеет проблемы с NAT.
• Пользователи отмечают, что MPTCP теперь имеет улучшенный API и может быть полезен для агрегации полосы пропускания и отказоустойчивости, но его использование ограничено тем, что он не может обрабатывать мобильность (handover) без сохранения старых адресов.
• SCTP, хоть и был предложен как альтернатива, но его поддержка в ядре Linux и в коммерческих устройствах оставляет желать лучшего, и он не может пройти через большинство NAT устройств.
• Вопрос о том, почему SCTP не стал широко используемым, обсуждается в контексте его сложности в прохождении через NAT и отсутствия поддержки в потребительских устройствах.

HTTP/3 — это новая версия протокола HTTP, работающая поверх QUIC (Quick UDP Internet Connections) вместо традиционного TCP. Основное преимущество — решение проблемы "head of line blocking", когда потеря одного пакета блокирует всю передачу данных. HTTP/3 использует UDP, что позволяет параллельно обрабатывать пакеты без ожидания восстановления связи. Протокол включает встроенную безопасность с TLS 1.3 и поддерживает 0-RTT handshakes для снижения задержки при повторных подключениях.

Книга подробно разбирает эволюцию протокола: от HTTP/2 с его ограничениями TCP до современных возможностей QUIC. HTTP/3 сохраняет такие функции HTTP/2, как мультиплексирование запросов и приоритизацию, но с улучшенной производительностью. Особое внимание уделено техническим деталям: работа с потоками, сравнение с HTTP/2, а также критика и перспективы развития. Документ доступен на нескольких языках и представляет собой исчерпывающее руководство для разработчиков, интересующихся современными веб-протоколами.

• Обсуждение охватывает отсутствие обновлений документации HTTP/3, проблемы с потерей пакетов в HTTP/2, и то, что HTTP/3 уже поддерживается большинством браузеров и сайтов, но документация и инструменты отстают.
• Участники обсуждают, что HTTP/3 в основном использует UDP, что вызывает споры о безопасности и приватности, а также то, что TCP может быть выключен в будущем.
• Также обсуждается, что HTTP/3 уже активно используется, но не всегда очевидно, что это именно он, так как внешне это может быть незаметно.
• Участники также отмечают, что документация и инструменты для HTTP/3 развиты недостаточно, и что будущее HTTP/4 неясно.
• В конце обсуждение сдвигается к тому, что HTTP/3 уже здесь и сейчас, и мы должны начать его использовать и развивать экосистему вокруг него.

Magic Wormhole позволяет безопасно передавать файлы и сетевые потоки между компьютерами напрямую или через ретранслятор. Для соединения используется одноразовый код из легко запоминаемых слов, который вводится на обоих концах. Это обеспечивает сквозное шифрование через протокол PAKE (SPAKE2), защищающий от перехвата даже при ретрансляции.

Система автоматически выбирает оптимальный метод подключения: прямое соединение в локальной сети, через публичный IP или ретранслятор при NAT. Помимо передачи файлов, инструмент поддерживает TCP-потоки, интеграцию с Git и совместные терминальные сессии. Реализации включают CLI, GUI для GNOME и мобильное приложение для Android.

• Рекомендации инструментов для передачи файлов между устройствами: Wormhole William и Destiny для Android/iOS, croc (с поддержкой возобновления), localsend (с автоматическим обнаружением в LAN), PairDrop, Tailscale Funnel, Copyparty и другие.
• Обсуждение преимуществ Magic Wormhole: простота использования, безопасность (шифрование через SPAKE2), надежность даже за NAT, удобство для быстрой передачи больших файлов или настройки новых устройств.
• Критика и ограничения: отсутствие возобновления передачи в базовой версии, путаница из-за схожих названий инструментов, ограничения мобильных версий (размер файлов), необходимость ручного ввода кодов на телефонах.
• Технические детали: использование сервера-посредника (mailbox) для установления соединения, попытка прямого P2P-подключения с fallback на реле, обсуждение безопасности коротких паролей и роли сервера в защите от перебора.
• Альтернативы и сравнения: croc предпочтительнее для некоторых из-за скорости и возобновления, Syncthing для постоянной синхронизации, WireGuard для VPN, Web Wormhole для браузеров.

SSH3 — это новая реализация SSH, построенная поверх HTTP/3 и QUIC вместо традиционного TCP. Она обещает значительно более низкую задержку установки соединения, многопоточность и встроенную поддержку мультиплексирования. Это позволяет ускорить интерактивные сессии, особенно в условиях нестабильных сетей.

Проект также включает улучшенные возможности, такие как передача файлов через HTTP и использование современных криптографических алгоритмов. Уже есть черновик IETF и техническая статья на arXiv, демонстрирующая производительность и совместимость. SSH3 может стать практичной альтернативой для DevOps и удалённого управления.

• Скептицизм по поводу заявлений о скорости: некоторые участники сомневаются в значительном преимуществе SSH3, отмечая, что основная задержка часто связана не с установкой соединения, а с настройкой сессии (PAM и т.д.).
• Критика имени "SSH3" и интеграции в HTTP: многие считают название неудачным и выражают сожаление по поводу поглощения прикладных протоколов HTTP, что увеличивает сложность и потенциальные риски безопасности.
• Обеспокоенность безопасностью и аудируемостью: новая, не испытанная в боях реализация вызывает опасения; участники подчеркивают необходимость тщательного аудита перед использованием в production.
• Вопросы к практической полезности и статусу проекта: обсуждается отсутствие commits за последний год, целесообразность поддержки OAuth для входа на сервер и необходимость таких функций, как миграция соединений.
• Технические аспекты и потенциальные преимущества: отмечается возможность решения проблемы head-of-line blocking за счёт мультиплексирования в QUIC/HTTP3, а также преимущества скрытия сервера за HTTP-прокси.

TernFS — экзабайтная распределенная файловая система с поддержкой нескольких регионов

XTX — алгоритмическая торговая фирма, использующая статистические модели для прогнозирования цен. По мере роста вычислительных мощностей потребности в хранилищах также увеличивались. Изначально использовались NFS и коммерческие решения, но в итоге было принято решение разработать собственную файловую систему — TernFS.

TernFS теперь доступна как открытое ПО на GitHub. В статье объясняется её архитектура и ключевые детали реализации.

Зачем ещё одна файловая система?

Крупные tech-компании часто разрабатывают собственные распределенные файловые системы из-за их критической важности. XTX оказалась в аналогичной ситуации и создала TernFS как универсальное решение для хранения — от «холодных» данных до временных файлов для обмена между GPU-задачами.

Возможности TernFS:

• Масштабируемость до десятков экзабайт, триллионов файлов и миллионов одновременных клиентов.
• Избыточное хранение данных для защиты от сбоев дисков.
• Отсутствие единой точки отказа в службах метаданных.
• Поддержка снимков файлов для защиты от случайного удаления.
• Работа в нескольких регионах.
• Агностичность к оборудованию, использование TCP/IP.
• Эффективное использование разных типов хранилищ (SSD, HDD).
• Доступ через собственный API (TCP/UDP) и модуль ядра Linux.
• Минимальные зависимости для сборки (C++, Go, RocksDB).

Ограничения:

• Файлы неизменяемы после записи.
• Не подходит для очень маленьких файлов (медиана — 2 МБ).
• Ограниченная пропускная способность при создании/удалении директорий.
• Отсутствие встроенной системы разрешений.

Разработка началась в 2022 году, с 2023 года система используется в production. К середине 2024 года все ML-задачи работают на TernFS. По состоянию на сентябрь 2025 года система хранит более 500 ПБ на 30 000 дисках и 10 000 SSD в трёх дата-центрах, с пиковой пропускной способностью в несколько ТБ/с. Потерь данных не зафиксировано.

Высокоуровневая архитектура

Основной API TernFS реализован четырьмя службами:

• Шарды метаданных — хранят структуру директорий и метаданные файлов.
• Координатор междиректорных транзакций (CDC) — выполняет транзакции между шардами.
• Службы блоков — хранят содержимое файлов.
• Реестр — хранит информацию обо всех службах и мониторит их.

Диаграмма взаимодействия служб TernFS и клиентов.

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

• Обсуждение технических особенностей TernFS: отсутствие RDMA, использование TCP/IP, репликация данных, ограничение на минимальный размер файла (~2MB), специализированная система метаданных.
• Сравнение с другими файловыми системами (CephFS, Lustre, GPFS): различия в архитектуре, производительности, поддержке POSIX и целевых use cases.
• Вопросы о бизнес-модели и масштабах данных XTX: хранение >500PB для ML-моделей в трейдинге, критика "отсутствия реальной ценности".
• Обсуждение лицензии (GPLv2-or-later/Apache-2.0) и предложения по улучшению документации (добавление примеров использования).
• Замечания о нишевых решениях для больших данных: акцент на immutable-данные, сложности с метаданными для tiny files, специализация под конкретные задачи.

sping — терминальный мониторинг задержек HTTP/TCP с живыми графиками. Установка: pip install service-ping-sping.

Быстрый старт

sping google.com                 # HTTP
sping tcp://google.com:80        # TCP
sping https://api.example.com -i 0.5 -c 20
sping example.com --json -c 5

Возможности

• HTTP/HTTPS/TCP, разбивка по фазам (DNS, TLS, запрос, ответ).
• Авто-обнаружение выбросов по MAD (6× медиана).
• Пороги warning/critical, выбор IPv4/IPv6, кэш DNS.
• Процентили p50-p99, экспорт JSON, 8 цветовых тем.
• Bearer/Basic-аутентификация, кастомный User-Agent.

Примеры

sping api.example.com -X POST --body --auth "bearer:token"
sping tcp://localhost:5432 -i 0.1
sping example.com --warn 100 --crit 500 --percentiles

Ключи

-i интервал, -c число запросов, --timeout, --ipv4/--ipv6, --resolve-once, --body, --no-keepalive, --insecure, --warn/--crit, --percentiles, --palette <theme>.

• Пользователи хвалят визуальный ping-утилиту sping, но предлагают переписать её на Go/Rust для статического бинарника без зависимостей.
• Автор подтвердил, что проект полностью сделан с помощью ChatGPT и Claude, а README «украшен» эмодзи.
• Найдены мелкие баги: ошибка палитры цветов и сбой при выводе финального резюме.
• Некоторые сравнивают инструмент с mtr, tracepath и nping --tr, отмечая, что нужен более дружелюбный аналог.

Zig 0.15 сменил IO: std.Io.Reader и std.Io.Writer.
Старый способ тормозил и путался из-за anytype.

Подключаемся к www.openmymind.net:443:

const std = @import("std");

pub fn main() !void {
    var gpa = std.heap.DebugAllocator(.{}).init;
    defer gpa.deinit();
    const a = gpa.allocator();

    const s = try std.net.tcpConnectToHost(a, "www.openmymind.net", 443);
    defer s.close();

    var wbuf: [std.crypto.tls.max_ciphertext_record_len]u8 = undefined;
    var rbuf: [std.crypto.tls.max_ciphertext_record_len]u8 = undefined;
    var w = s.writer(&wbuf);
    var r = s.reader(&rbuf);

    var bundle = std.crypto.Certificate.Bundle{};
    try bundle.rescan(a);
    defer bundle.deinit(a);

    var tls_buf: [std.crypto.tls.max_ciphertext_record_len]u8 = undefined;
    var tls = try std.crypto.tls.Client.init(
        r.interface(),
        &w.interface,
        .{
            .ca = .{ .bundle = bundle },
            .host = .{ .explicit = "www.openmymind.net" },
            .read_buffer = &.{},
            .write_buffer = &tls_buf,
        },
    );
    defer tls.end() catch {};

    try tls.writer.writeAll("GET / HTTP/1.1\r\n\r\n");

    var out: [1024]u8 = undefined;
    var fw = std.Io.Writer.fixed(&out);
    const n = try tls.reader.stream(&fw, .limited(out.len));
    std.debug.print("read: {s}\n", .{out[0..n]});
}

Ключевые моменты

• stream.reader() и writer() требуют буфер.
• Чтобы передать их в tls.Client, нужно .interface() и &interface.
• tls.Client.init обязательно просит ca, host, read_buffer, write_buffer.
• Чтение ответа: tls.reader.stream в std.Io.Writer.

• Автору пришлось вручную вызывать flush у двух обёрток и разбираться с тем, что первое чтение всегда возвращает 0.
• Основная жалоба — отсутствие документации и примеров; сообщество отвечает «читай исходники», но участники признают, что API ещё нестабилен.
• Некоторые считают новый I/O-интерфейс элегантным, но сложным даже для «Hello, world!»; другие предпочитают прямое использование системных API.
• Zig позиционируется как язык системного программирования, близкий к C, с преимуществами вроде discriminated unions и comptime, но сопровождается постоянными breaking changes.

20 августа 2025 г. с 00:34 до 01:48 по Пекину GFW безусловно сбрасывал все TCP-соединения на 443-порт, разрывая трафик между Китаем и остальным миром.

Ключевые факты

• Цель: только 443/tcp; 22, 80, 8443 не трогались.
• Механизм:
  • из Китая: SYN или SYN+ACK вызывали три поддельных RST+ACK;
  • в Китай: RST посылались только на SYN+ACK сервера.
• Оборудование: отпечатки не совпадают с известными GFW-узлами ⇒ либо новое устройство, либо сбой.

Примеры трафика

Из Китая наружу

CN_IP → NON_CN_IP:443 [SYN]
NON_CN_IP:443 → CN_IP [RST+ACK] (seq 0, ack 1, win 1980-1982)
NON_CN_IP:443 → CN_IP [SYN+ACK]
NON_CN_IP:443 → CN_IP [RST+ACK] (seq 1, ack 1, win 3293-3295)

Снаружи в Китай

192.168.0.162 → baidu.com:443 [SYN]
baidu.com:443 → 192.168.0.162 [SYN+ACK]
baidu.com:443 → 192.168.0.162 [RST+ACK] (seq 1, ack 1, win 2072-2074)

Инцидент длился 74 минуты; приглашаем сообщить дополнительные наблюдения.

• Пользователи обсуждают масштабные сбои/блокировки в китайском интернете, многие называют это «комендантским часом» и опасаются повторения на Западе.
• Возникли вопросы о топологии «Великого фаервола»: централизован ли он, действует ли между всеми узлами или только между домашними и коммерческими сетями.
• Некоторые считают инцидентом ошибку конфигурации, другие — «сухую тренировку» перед будущими ограничениями, особенно в военное время.
• Упоминаются последствия для удалённых работников и иностранцев: падение VPN, пропущенные созвоны, поиск запасных каналов (Starlink, LoRa, V2Ray).
• Подчёркивается, что внутри Китая даже запуск личного блога требует лицензии ICP, а HTTPS-сертификаты часто отсутствуют.

IPv4 Games
Justine Tunney, 16 авг 2025

Сервис ipv4.games предлагает «захватывать» IP-адреса: достаточно установить TCP-соединение с виртуальной машиной Google. Игрок femboy.cat из Европы уже «забрал» 20 млн адресов (≈ 9 % IPv4-узлов по Censys). Как он это делает? Кто станет североамериканским конкурентом?

• «ipv4.games» считает IP «захваченным», если он хоть раз загрузил скрытый 1×1-пиксельный трекер; никаких проверок владения не требуется.
• 9 % — это 20 млн из ~220 млн IP, которые Censys видит с открытыми портами, а не из всего адресного пространства IPv4.
• Лидеры просто встроили трекер в популярные сайты, рекламу или npm-пакеты, заставляя посетителей «захватывать» IP за них.
• Версии о спуфинге X-Forwarded-For или массовом использовании прокси пока не подтверждены; сервер, судя по tcpdump, видит реальные TCP-сессии.
• Игра — это скорее маркетинговый трюк, чем показатель реального контроля над адресами.

• CSS

  • min-width: auto (по умолчанию) имеет приоритет над flex-shrink, overflow: hidden, width: 0; задайте min-width: 0.
  • Горизонталь и вертикаль различаются: width: auto растягивается, height: auto по содержимому; margin: 0 auto центрирует по горизонтали, но не по вертикали (в flex-direction: column работает).
  • BFC (display: flow-root) предотвращает схлопывание margin и «обнуление» высоты родителя с float-потомками.
  • Новый stacking context создают transform, filter, opacity, position: fixed/sticky, z-index + absolute/relative и др.; z-index действует только внутри контекста.
  • На мобильных 100vh включает скрытые панели; используйте 100dvh.
  • position: absolute ориентируется на ближайший «positioned» ancestor, а не на родителя.
  • float не работает внутри flex/grid-родителя.
  • Процентные width/height не работают, если размер родителя не задан.
  • display: inline игнорирует width, height, вертикальные margin.
  • Пробелы между inline-block элементами рендерятся; в flex/grid — нет.
  • box-sizing: content-box (по умолчанию) не включает padding/border; включите border-box.
  • Указывайте width/height у <img> для предотвращения CLS.
  • Загрузка файлов не показывается в DevTools; используйте chrome://net-export/.
  • Внутри <script> строка </script> ломает парсинг.

• Unicode

  • Отличайте code point и grapheme cluster (последнее — то, что видит пользователь).

• Маршрутизаторы могут тихо обрывать простаивающие TCP-соединения; настройте TCP-keepalive или HTTP-заголовки.
• Возвращать null из Optional<T> — антипаттерн; Kotlin и аннотации уже решают это.
• UTF-16 в Java/C#/JS — деталь реализации; в Go строки — просто байты.
• min-width: auto работает не везде; CSS-свойства нельзя читать изолированно.
• Регексы, YAML, LF/CRLF, rm -rf $DIR/ — каждый язык/платформа имеет свои подводные камни.

TCP: увеличить initcwnd снова

Google в 2011 г. подняли начальное окно TCP (initcwnd) с 1 до 10 пакетов; RFC 6928 сделало это стандартом. Сегодня, при среднем размере страницы ~2 МБ и RTT 30–100 мс, 10 пакетов (~14 КБ) всё ещё тормозит старт.

Почему расти

• 75 % HTTP-ответов ≤ 32 КБ; 10 пакетов передают лишь 40 %.
• У Google, Meta, Akamai уже 32–64 пакета без потерь.
• Современные сети: 100 Гбит, AQM, ECN, BBR — потери редки.

Риски

• Пакет потеряют лишь 0,01 % сессий при initcwnd=30.
• Re-buffering в YouTube снизился на 3 % при 30 пакетах.

Вывод
initcwnd=30–50 пакетов безопасно и ускоряет web на 5–15 %. Пора обновить RFC.

• Участники считают, что статья поверхностна и ошибочна в выводах о TCP initcwnd и BBR.
• QUIC/HTTP-3 всё равно использует алгоритмы управления перегрузкой (CUBIC, BBR); «окна нет» — миф.
• L4S позволяет получать сигналы о перегрузке без потери пакетов, помогая молодым соединениям.
• Увеличение initcwnd может лишь временно скрыть «раздутый» фронтенд-код, пока бизнес не пострадает.
• BBR и другие алгоритмы плохо переносят высокую джиттерность RTT в беспроводных сетях.
• Bufferbloat всё ещё актуален (особенно на мобильных и Wi-Fi), несмотря на улучшения в кабеле/волокне.

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

Вдохновение дали:

• TIS-100 — псевдоассемблер в игровой форме.
• Space Traders — космическая торговля через REST API.
• Protohackers — челленджи по сетевым протоколам.

Старт:

nc clearsky.dev 29438

Приятного погружения!

• Участники делятся ссылкой на похожий Sci-Fi-контест 2006 года, где нужно писать собственную VM.
• Появился новый TCP-пазл на clearsky.dev:29438; при подключении требуется отправить 0-байт + «XR2K» для документации.
• Сервер перегружен HN, поэтому текст иногда не выводится или после команды ничего не происходит.
• Некоторые пробуют использовать LLM для упрощения игры.
• Один из игроков ждёт ответа «Colonel Arhci» по atlantiamail.