Итоги

  • Eric Dumazet в настоящее время указан среди сопровождающих Linux по сетевой подсистеме, TCP и сокетам, а также является членом технического руководящего комитета Netdev Foundation. Эти обязанности разделены с другими сопровождающими и рецензентами, поэтому они дают ему значительную ответственность за принятие патчей, но не единоличную власть над сетевым стеком.
  • Его именная заметная работа — TCP Small Queues, представленная серией патчей в 2012 году, чтобы не дать одному TCP-потоку ставить избыточные данные в очереди ниже транспортного уровня. TSQ привязал локальный кредит очереди сокета к завершению пакетов, уменьшив задержку и давление на память на стороне отправителя, но не устранив все очереди на пути.
  • Его последующая работа надsch_fqи внутренним pacing в TCP перенесла планирование передачи на явную поверхность управления. Справедливая очередь разделяет потоки, а pacing распределяет пакеты во времени. Эти механизмы поддерживают несколько алгоритмов управления перегрузкой, включая среды с BBR, но у BBR отдельные авторы и история проектирования.
  • Его недавняя работа связывает порядок структур данных, движение кэш-линий и состояние конкретного сокета с эффективностью больших флотов. Более широкий вывод: сетевой стек Linux — это система учёта процессора, памяти, глубины очереди и времени. Экономический эффект может быть значительным, но открытые данные не позволяют назвать конкретную финансовую цифру или универсальный результат производительности для всего оборудования.

Быстрый сервер может терять время за собственными пакетами

История начинается в очереди отправки на Linux-хосте. Приложение записало данные, TCP решил, что путь может принять больше, и ядро передало данные на нижние уровни. С точки зрения приложения байты кажутся ушедшими, но они могут оставаться ждать внутри самого устройства.

Пропускная способность может оставаться высокой и скрывать задержку. Интерактивный запрос ждёт за массовой передачей, память остаётся зарезервированной в буферах, а представление TCP о том, что находится «в полёте», расходится с данными, скопившимися локально. TCP Small Queues изменил это соотношение, ограничив то, что сокет может протолкнуть ниже TCP, и снова разрешая отправку, когда завершение пакетов доказывает, что оборудование действительно продвинулось.

Публичный след богат инженерными деталями и намеренно ограничен в личной биографии

Самые сильные доказательства о Dumazet исходят от самого Linux: файлMAINTAINERS, обсуждения патчей, документация, доклады и годы публичного рецензирования. Эти записи подтверждают его нынешние обязанности в сетевой подсистеме, TCP и сокетах, его роль в Netdev Foundation и публичную связь с Google через адрес сопровождающего.

Но они не дают полной биографии, подтверждённой текущей должности или исчерпывающего перечня патчей и рецензий. Выдумывание таких деталей ослабило бы материал. Поэтому профиль сосредоточен на том, что можно проверить: механизмах, проектных решениях и решениях по рецензированию. Dumazet предстаёт инженером технической ответственности; его работа становится общей инфраструктурой только после того, как другие её рецензируют, дорабатывают, тестируют и публикуют.

Статус сопровождающего приближает его к решениям, но не ставит над сообществом

По состоянию на 4 августа 2026 года записи Linux указывали его в сетевой подсистеме, TCP и сокетах. Сопровождающий может потребовать перепроектирования интерфейса, отклонить нагрузку, которую невозможно поддерживать годами, или применить приемлемое изменение и представлять подсистему на пути в mainline.

Те же записи показывают, что власть распределена. David S. Miller, Jakub Kicinski и Paolo Abeni участвуют в сетевой подсистеме, Neal Cardwell — в TCP, а профильные рецензенты подключаются в зависимости от темы патча. Изменения также проходят через архитектуры, драйверы, безопасность, тесты, стабильные ветки и финальный путь ядра. Сила Dumazet — в работе внутри этой системы, а не в обходе её.

Детали Linux превращаются в экономику инфраструктуры при росте числа соединений

На небольшом устройстве никто может не заметить несколько лишних байтов в каждом сокете или один промах кэша. На сервере со сотнями тысяч соединений эти издержки умножаются и начинают конкурировать с приложением за процессор, память и питание.

«Экономика сервера» здесь не означает опубликованную финансовую цифру. Речь о том, как технические издержки превращаются в плотность соединений, остаток процессорного времени для обслуживания, память, зарезервированную под сеть, и задержку, ломающую целевые показатели отклика. Дистрибутивы и операторы выбирают версию ядра, qdisc, алгоритм перегрузки и NIC. Dumazet не управляет этими выборами; он улучшает общую основу, от которой они отталкиваются.

Привычная функция TCP скрывает плотную систему учёта

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

Реализация может быть протокольно корректной, но операционно плохой: глубокий локальный backlog, всплески, конкуренция за блокировки или структуры, съедающие кэш. Общая нить в работе Dumazet — учёт. Байты приписываются сокету, завершение возвращает кредит, вычисляются времена отправки, потоки разделяются, горячие и холодные поля различаются. Цель — использовать необходимые ресурсы, не строя вторую скрытую сеть внутри хоста.

До TSQ отправитель мог выстроить backlog, которым больше не управлял

До TCP Small Queues TCP мог передавать большие объёмы данных в qdisc и драйвер. Окно перегрузки могло быть разумным на уровне пути, тогда как под транспортным уровнем оставалась длинная локальная очередь. Когда появлялся более срочный поток, приложение не могло отозвать то, что уже протолкнуло вниз.

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

Серия патчей TSQ 2012 года вернула бюджет локальной очереди сокету

Патчи 2012 года определили, сколько данных каждый сокет может разместить ниже TCP. Когда локальный кредит исчерпан, отправка останавливается; когда пакеты завершаются, сокет снова получает право отправлять больше.

Идея проста: учитывать локальные байты и использовать завершение как доказательство того, что нижний путь продвинулся. Но важность в том, что управление вернулось транспортному уровню, который понимает поток. Поддержание занятости канала больше не требовало заранее вносить большой батч. Приложения выиграли от более дисциплинированной внутренней базы без изменения своего кода.

Завершение пакета стало практическим сигналом обратной связи внутри хоста

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

Эта локальная обратная связь дополняет удалённый ACK. Первая описывает продвижение уровней ниже транспорта, второй — продвижение пути; статистика qdisc, драйвера и NIC описывает другие части. Ни один сигнал не объясняет всё. TSQ сделал один из сигналов полезным для ограничения локального избытка, не отменяя сквозное управление перегрузкой.

TSQ устранил важный источник bufferbloat, но не все очереди

TSQ не покончил с bufferbloat. Он ограничивает backlog отправителя ниже TCP. Очереди остаются в qdisc, драйвере, NIC, сети доступа, маршрутизаторах, коммутаторах и приёмнике.

Более точная формулировка полезнее: TSQ уменьшает способность одного сокета выстраивать большую скрытую очередь внутри хоста. Он может снизить задержку и потребление памяти и приблизить состояние TCP к продвижению оборудования, но не заменяет активное управление очередями, настройку очередей или управление перегрузкой.

Лимиты, offload'ы и рабочие нагрузки определяют пользу TSQ

Эффект зависит от локального лимита, размера пакета, qdisc, очередей устройства, сегментации и смеси потоков. Интерактивный сервис с короткими передачами не получает той же пользы, что и массовое копирование.

Реализация также развивалась после 2012 года. Поздние участники корректировали лимиты, интеграцию и крайние случаи. Первоначальную идею можно приписывать Dumazet, признавая, что нынешняя форма — результат долгой коллективной поддержки.

sch_fqразделил потоки и ввёл время в планирование

В 2013 году Dumazet опубликовал базовую работу надsch_fq. Планировщик хранит состояние для каждого потока и структуру, упорядоченную по времени, затем выпускает пакеты согласно целевому времени отправки. Новые потоки получают быстрое обслуживание, а потоки с pacing ждут своего времени.

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

Fair queueing — это выбор политики, а не обещание полного равенства

Слово «fair» может обещать больше, чем даёт система. Разделение потоков по очередям не уравнивает производительность приложений. Размер пакета, путь, получатель, алгоритм перегрузки, offload и число соединений по-прежнему важны.

Даже определение потока — это политика. Одно приложение может открывать много соединений, а другое — одно.sch_fqуменьшает доминирование одного потока на локальном уровне, но не определяет справедливость между пользователями или организациями. Это инструмент планирования, а не всеобщий суд о справедливости.

Pacing превращает оценку скорости в последовательность времён отправки

Алгоритм перегрузки может выбрать правильное среднее, а затем разрешить отправить весь объём разом. Среднее остаётся верным, но всплеск временно заполняет очередь.

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

Pacing и управление перегрузкой решают разные задачи

Алгоритм перегрузки решает, сколько пути использовать; pacing решает, когда выпускать разрешённые данные. Всплески могут испортить хорошую модель, а отличный pacing может исполнять плохую скорость.

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

BBR использует инфраструктуру pacing, но у него другие авторы и история

BBR часто связывают с именем Dumazet, потому что он опирается на pacing и вырос в среде Google TCP. Эта связь не делает Dumazet его единственным изобретателем. У BBR есть отдельные авторы, модель и версии.

Точная формулировка: очереди, pacing, метрики и учёт сокетов сделали возможным развёртывание более поздних алгоритмов. Эта формулировка сохраняет ценность работы Dumazet и оставляет заслугу Neal Cardwell и другим инженерам по управлению перегрузкой.

TSO экономит процессор, но может вернуть всплеск, который pacing пытался предотвратить

TCP Segmentation Offload позволяет ядру передавать большой сегмент NIC для последующего разделения. Это снижает стоимость каждого пакета, но добавляет аппаратный слой между решением о времени отправки и реальной передачей.

Если большой сегмент выпускается как единое целое, NIC может создать всплеск. TSQ, qdisc, TSO, драйвер и оборудование следует понимать как одну систему. Оптимизация может быть выгодна для процессора и вредна для задержки, если не согласована с формой трафика.

Quantum, временные метки и поведение NIC должны сходиться к единой реальности

Ядро работает с единицами планирования, точностью таймеров, временными метками, единицами offload и аппаратными очередями. Большой quantum возвращает всплески, маленький потребляет CPU, а различия в реализации NIC меняют то, что происходит на проводе.

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

Внутренний pacing TCP снизил зависимость от конкретного qdisc

В 2017 году Dumazet опубликовал pacing внутри TCP. Транспорт стал лучше способен задерживать отправку по своей скорости и таймерам, не полагаясь полностью на наличие конкретного qdisc ожидаемым образом.

qdisc не стал неважным; он по-прежнему упорядочивает и применяет политику. Часть логики перешла к слою, владеющему намерением, но итоговое время остаётся совместным результатом TCP, qdisc, драйвера и NIC.

Выбор qdisc остаётся решением оператора, реально меняющим сервис

Linux предлагает очереди для разных целей.sch_fqподходит для pacing; FQ-CoDel сочетает разделение потоков с активным управлением очередями. Это не одно и то же.

Настройки по умолчанию различаются между дистрибутивами, облачными образами, устройствами и хостами контейнеров, а offload может перенести реализацию в оборудование. Ядро даёт возможность; оператор решает, станет ли она реальным поведением сервиса.

Несколько байтов на сокет превращаются в ограничение для целого флота

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

Сокращение памяти на сокет может повысить плотность, а лучший порядок — уменьшить промахи кэша и трафик когерентности между ядрами. Это самая сильная связь с экономикой серверов, но она не позволяет назвать универсальный процент экономии или личную финансовую ценность.

Кэш-линия становится инфраструктурой, когда её трогают с каждым пакетом

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

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

Работа 2024 года над структурами показывает зрелую стадию инженерии производительности

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

В зрелой архитектуре выигрыш может прийти от устранения промаха кэша или переноса поля, а не от нового алгоритма. Это менее эффектно, но может определять реальную производительность в масштабе.

Профили в масштабе hyperscale — сильное доказательство, но не полное публичное знание

Крупные операторы видят масштабы соединений, NIC и трафика, которые трудно воспроизвести. Они могут выявить издержки, невидимые в лаборатории. Связь Dumazet с Google даёт такого рода производственные доказательства.

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

Блокировки и очереди приёма относятся к той же истории о ресурсах

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

Linux снижает это с помощью батчинга, переноса работы и уменьшения конкуренции. Принцип тот же: координация, достаточная для корректности, чтобы учёт не съедал мощность приложения.

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

Группировка пакетов или завершений распределяет стоимость блокировок, вызовов и движения кэша. NAPI, драйверы и offload'ы опираются на это.

Но батч ждёт накопления и может прийти как всплеск. Чем он больше, тем лучше амортизация, но тем дольше ждёт первый элемент или тем сильнее доминирует один поток. TSQ, fair queueing и pacing не воюют с группировкой; они ставят ей пределы, сохраняющие обратную связь и задержку.

Производительность TCP складывается из слоёв, которые могут гасить друг друга

Алгоритм перегрузки определяет намерение, TCP создаёт пакеты и тайминги, TSQ ограничивает backlog, qdisc упорядочивает, TSO группирует, драйвер готовит память, NIC отправляет, а сеть добавляет свои очереди и потери.

Грубый offload может свести на нет точный pacing, чрезмерная постановка в очередь может переполнить qdisc с низкой задержкой, а новая блокировка может съесть выигрыш от компоновки. Работа Dumazet важна, потому что касается стыков между этими слоями.

Публичное рецензирование патчей превращает локальную оптимизацию в общую инфраструктуру

Изменение начинается с обещания производительности: меньше задержки, памяти или CPU. Чтобы попасть в Linux, оно проходит вопросы netdev об измерениях, общности, редких архитектурах, тестах и будущей стоимости поддержки.

Сопровождающий может попросить разделить серию, отклонить абстракцию под конкретного вендора или отложить неготовое изменение. Путь медленнее, чем внутренний патч, но устойчивее. Часть власти Dumazet — оценка того, сможет ли Linux поддерживать изменение годами.

netиnet-nextразделяют срочные исправления и будущую разработку

Исправления обычно идут вnet, а функции и рефакторинг — вnet-next. Это не даёт смешивать поддержку настоящего с изменениями следующего релиза.

Граница требует суждения. «Исправление» может менять поведение, а функция может вскрыть старый дефект. Сопровождающие требуют разделять серии, чтобы показать риски, а сроки релиза вендора не становятся достаточным основанием для принятия.

Рецензирование, отклонения и перепроектирование не видны в числе коммитов

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

Профиль должен сочетать атрибутируемые TSQ,sch_fq, pacing и компоновку с управленческой работой, которую нельзя свести к таблице лидеров. И не всё, что принял Dumazet, — его личное изобретение.

Тесты снижают риски, но не представляют каждое устройство, с которым столкнётся Linux

Сборки, selftests, KUnit, syzbot, лаборатории драйверов и downstream-развёртывания выявляют многие регрессии, но не покрывают каждый CPU, NIC, qdisc и рабочую нагрузку.

Изменение может улучшить hyperscale и навредить редкому устройству. Опыт, совместимость и откат остаются необходимыми. Тесты усиливают управление, но не отменяют суждение.

Бэкпорт в stable создаёт второе решение после mainline

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

Изменения производительности часто зависят от контекста, которого нет в старой ветке. Эффект распространяется поэтапно: upstream, затем stable, затем дистрибутив, затем облако, затем конфигурация. Ни один человек не контролирует всю цепочку.

Текущая поддержка TCP и сокетов намеренно разделена

MAINTAINERSраспределяет ответственность между Dumazet, Neal Cardwell и другими. Это снижает зависимость от одного человека и объединяет знания о перегрузке, сокетах, драйверах и тестах.

Но разделение требует чёткого владения. Пересекающиеся области могут оставить пустоту, если каждый думает, что отвечает кто-то другой. Здоровая преемственность передаёт обоснования, тесты и полномочия, а не только имена.

Netdev Foundation может финансировать, не становясь органом принятия патчей

Фонд под эгидой Linux Foundation поддерживает CI, инструменты, поездки и исследования, а Dumazet входит в TSC. Грант не гарантирует принятие патча.

Глубокая поддержка требует денег, времени и оборудования. Признание этого не означает перенос легитимности upstream на финансирующую сторону. Деньги должны усиливать способность сообщества принимать решения, а не покупать исключения.

Связь с Google даёт инженерные возможности, но не владение TCP в Linux

Адрес Google доказывает связь, но не полную должность. Гиперскейлер может финансировать профилирование, оборудование и время на рецензирование, от которых после upstream выигрывают все.

Проблема в том, что часть данных закрыта, а приоритеты большого флота более заметны. Публичное рецензирование — это баланс: патч должен оставаться общим, понятным и приемлемым за пределами Google. Компания даёт время и доказательства, но не владеет стеком.

Downstream-операторы решают, изменит ли улучшение upstream их сервис

Дистрибутивы выбирают ядро и бэкпорты, облака выбирают qdisc и перегрузку, устройства закрепляют старые версии, вендор NIC определяет возможности, а приложения формируют трафик. Надёжного глобального опроса об использовании TSQ илиsch_fqнет.

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

Пользовательские стеки конкурируют за специализированные нагрузки, а не за всю роль Linux

DPDK, VPP и прикладные стеки обходят части ядра ради высоких скоростей и точного контроля, но часто требуют выделенных ядер, huge pages, привязки устройств и отдельной модели эксплуатации.

Linux TCP даёт более широкую интеграцию с сокетами, безопасностью, namespace'ами, мониторингом и драйверами. Работа Dumazet снижает стоимость общего пути, не утверждая, что он лучший для каждого случая. Обход остаётся для особых ситуаций, а Linux — общей основой для большинства.

Linux остаётся выбором по умолчанию, потому что интеграция шире, чем сырая скорость пакетов

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

Приложение использует обычный сокет и наследует TSQ, pacing и учёт памяти. Эта невидимость — часть силы архитектуры: эффект остаётся, даже если пользователь не знает имени автора.

Более быстрый хост не доказывает, что сетевой путь лучше

Лучшая локальная очередь не исправит перегруженный канал доступа, загруженный приёмник или маршрутизаторы, теряющие пакеты. TSQ и pacing настраивают отправителя и не контролируют весь путь.

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

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

Размер пакета, число соединений, CPU, кэш, NIC, offload'ы, qdisc, таймеры, версия ядра и рабочая нагрузка меняют результат. Профиль из Google показывает реальную стоимость, но не предсказывает точный процент на другом флоте.

Хороший отчёт сохраняет условия измерений. Доклады Dumazet — атрибутированное операционное свидетельство, а обобщение требует публичных тестов и независимых измерений.

Преемственность — техническая проблема, потому что часть дизайна живёт в человеческой памяти

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

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

Аппаратный pacing и память устройств могут снова сдвинуть границу

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

Задача становится координационной: Linux должен выражать намерение, видеть, что сделало оборудование, и восстанавливаться при расхождениях. API, временные метки и ошибки становятся не менее важны, чем скорость. Принципы Dumazet остаются: учёт рядом с владельцем намерения, обратная связь, пределы для скрытых очередей и прозрачность границ.

Следующие выигрыши могут прийти из экономики кэша, а не из новых схем передачи

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

Это изменения без бренда, полезные многим алгоритмам. Работа 2024 года показывает зрелую стадию, на которой стек измеряется своими физическими издержками. Вопрос меняется с «какой протокол побеждает?» на «сколько машины молча потребляет каждое соединение?»

Устойчивый вклад Dumazet — дисциплина ресурсов, а не миф об одиноком герое

Плохой нарратив делает его единственным изобретателем современного TCP и BBR; другой нарратив стирает человека внутри сообщества. Доказательства поддерживают более точную середину.

Он представил TSQ, внёс вклад в основуsch_fq, развил внутренний pacing, показал важность компоновки и сегодня несёт ответственность в рамках общей системы поддержки. Суть его вклада — отношение к пакетам и сокетам как к требованиям на ограниченное время, память, очереди и локальность CPU.

Итоговое влияние распределено между проектированием, рецензированием, слиянием и эксплуатацией. Коммит легко атрибутировать; плотность флота или предотвращённый сбой атрибутировать трудно. Эта трудность не оправдывает ни преувеличения, ни стирания; она показывает, что ценность инфраструктуры возникает из конкретных инженерных решений и коллективного исполнения.