Перейти к содержимому 
Функция «TCP Small Queues» ограничивает количество ожидающих байтов в канале передачи Linux для каждого потока TCP и тем самым снижает Латентность включая «Bufferbloat», целенаправленно снижая. Я покажу, как этот механизм работает в сетевые технологии в Linux Stack показывает, как я устанавливаю разумные ограничения и какие взаимодействия возникают с Pacing, QDiscs и Congestion Control.
Центральные пункты
- Предельное значение расхода: TSQ ограничивает количество ожидающих байтов для каждого сокета TCP.
- Меньше «буферного раздувания»: Сокращение очередей снижает RTT.
- Противодавление: При достижении этого предела приложения записывают данные медленнее.
- Справедливость: Ни один отдельный поток не занимает всю очередь целиком.
- Адаптивный Управление: ограничение зависит от скорости и размера сегмента.
Как работает механизм TCP Small Queues
TSQ начинает работу с того места, где TCP присоединяет сегменты к QDisc и передает драйверу. Когда я записываю данные в сокет, ядро перед каждой операцией добавления в очередь проверяет количество байтов, уже выделенных для этого потока. Если поток достигает лимита, логика помечает сокет как ограниченный и останавливает дальнейшее добавление в очередь. Только после того, как сетевая карта освободит буфер, сокет снова может отправлять данные, и я могу вновь помещать данные в стек. Этот жесткий контроль обратной связи поддерживает Очереди короткий и позволяет сделать время реакции более предсказуемым.
Почему длинные очереди увеличивают время отклика
Создание больших очередей драйверов и QDisc буферный раздув, особенно при использовании TSO/GSO и больших объемах трафика. Крупный файл для скачивания может переполнить исходящие очереди, в то время как интерактивные потоки, такие как SSH, вызовы API или VoIP, остаются в конце очереди. Переполненная очередь тогда доминирует над RTT вместо фактического времени связи. Система управления перегрузкой реагирует с задержкой, поскольку подтверждения (Ack) поступают с опозданием, и принимает менее оптимальные решения по cwnd. TSQ ограничивает количество предварительно буферизованных байтов на каждый поток, чтобы небольшие пакеты, для которых время имеет решающее значение, быстро попадали в канал.
Заглянем «под капот»: что учитывает ядро
На самом деле ядро подсчитывает не „пакеты“, а байты, а точнее — байты памяти, уже помещенные сокетом в очередь. Решающее значение имеет то, что стек содержит структуры skbuff вместе с truesize был выделен, но ещё не обработан NIC. TSQ связывает с ним Увеличение/уменьшение подачи топлива‑Путь: если сокет достигает лимита, стек устанавливает флаг ограничения и вызывает его снова только после завершения передачи (TX) (NAPI/IRQ) write_space() , чтобы приложение могло отправить данные заново. Эта обратная связь действует быстрее, чем сигналы, основанные исключительно на потерях, используемые в механизме управления перегрузкой, и срабатывает до того, как вступает в действие QDisc. При использовании TSO/GSO этот механизм остается эффективным, поскольку ограничение устанавливается на до исходит из байтового бюджета, заложенного при сегментации: большие суперфреймы пропускаются в QDisc только при наличии достаточного свободного кредита, что позволяет сдерживать всплески трафика.
Динамические ограничения и темп работы
Я получаю выгоду от TSQ, потому что лимит не остается неизменным, а зависит от Тариф и учитывает размер сегмента. Цель — обеспечить время прохождения данных по каналу передачи на уровне примерно одной миллисекунды на каждый поток, независимо от того, идет ли речь о 100 Мбит, 1 Гбит или 10 Гбит. При высокой скорости линии допустимый байтовый кредит увеличивается, при низкой — уменьшается. В сочетании с TCP-Pacing всплески трафика остаются небольшими, а подтверждения (Ack) возвращаются быстрее. Таким образом я добиваюсь заметно меньшего Пики задержки, не снижая при этом производительности без необходимости.
Взаимодействие на уровне сокетов и приложений
TSQ проявляет свою эффективность только в том случае, если система подачи также ощущает противодавление. Поэтому я учитываю такие настройки, как SO_SNDBUF, TCP_NOTSENT_LOWAT и автокоркинг. Слишком большое окно буфера передачи может на короткое время занять в стеке много байтов; TSQ, конечно, замедляет работу, но приложение замечает это только тогда, когда send() блокируется или возвращает EAGAIN. С помощью TCP_NOTSENT_LOWAT я ограничиваю „неотправленную“ часть в пользовательском пространстве и тем самым дополняю TSQ на стороне ядра. Автокоркинг (или явно TCP_CORK/MSG_MORE) помогает объединять мелкие записи, не вызывая пиков задержки. Ограничения по темпу для каждого сокета (например, через SO_MAX_PACING_RATE) гармонируют с TSQ: частота сглаживает во времени, а ограничение по количеству байтов — в пространстве. Важно: TCP_NODELAY отключает Nagle и может повысить интерактивность, но без TSQ возрастает риск всплеска; с TSQ я контролирую и то, и другое.
Практическое руководство: целесообразные значения TSQ
Общие рамки я определяю с помощью net.ipv4.tcp_limit_output_bytes (Sysctl). Обычные значения по умолчанию колеблются в пределах 128–262 КБ на поток. Для многих веб- и API-нагрузок я выбираю более низкие значения, чтобы интерактивные ответы оставались быстрыми. Для резервного копирования или репликации я умеренно повышаю этот лимит, при условии, что RTT остаётся стабильным. Те, кто хочет глубже изучить страницу очередей, найдут основы по Очереди пакетов на сервере, которые помогают в классификации.
| Сценарий | Скорость обмена данными | Рекомендующее значение параметра tcp_limit_output_bytes | Цель |
|---|---|---|---|
| API/HTTP — очень интерактивный | 100 Мбит — 1 Гбит | 64–128 КБ | низкий RTT, короткие шипы |
| Смешанная нагрузка: веб-страницы + загрузки | 1–10 Гбит | 128–256 КБ | Баланс Пропускная способность и задержка |
| Репликация/резервное копирование | 1–10 Гбит | 256–512 КБ | постоянный объемный расход, приемлемый Латентность |
| WAN с высоким показателем RTT | 10–100 Мбит | 96–192 КБ | более короткие серии, более справедливые Кии |
Взаимодействие QDisc и системы управления перегрузкой
TSQ работает на входе в QDisc, в то время как алгоритмы, такие как fq_codel, управляют заторами на линии. Вместе они сокращают очереди и обеспечивают справедливое распределение. С помощью TCP BBR я получаю дополнительную выгоду, поскольку более реалистичные измерения RTT позволяют улучшить распределение нагрузки и управление cwnd. CUBIC также работает более плавно, когда я устраняю чрезмерные задержки в очереди. Таким образом, пропускная способность органично растет, в то время как Время отклика остается под контролем.
Виртуализация и облачные стеки
В виртуальных машинах суммируются несколько уровней буферизации: QDisc гостевой системы, очереди virtio/vhost, QDisc хоста и физическая сетевая карта. Я оставляю TSQ активным в гостевой системе и устанавливаю там консервативный лимит, чтобы в хост не попадали мощные всплески трафика. На уровне гипервизора я обеспечиваю короткие цепочки задержек с помощью справедливых QDisc, умеренных TX-колец и чёткой привязки IRQ. SR-IOV может снизить задержку, но перекладывает ответственность на гостевые системы: без TSQ в гостевой системе возникает риск образования длинных очередей VF. В контейнерах TSQ применяется для каждого NetNS как обычно; с помощью cgroup-pacing и ограничений CPU я предотвращаю ситуацию, когда «шумный» сосед косвенно увеличивает задержку. Важно также обратить внимание на коалесцирование и переносы обработки в тракте virtio: чрезмерное объединение удлиняет время подтверждений (Ack), а недостаточное снижает эффективность — я настраиваю параметры в соответствии с целевым показателем задержки, а не слепо следую каким-то догмам.
Wi-Fi и встроенные системы: правильное решение особых случаев
В случае Wi-Fi-соединений важно Агрегация на уровне MAC. Если я оставляю слишком мало байтов в канале передачи, драйвер не сможет объединять столько фреймов, что снизит эффективность. В таких конфигурациях я осторожно увеличиваю лимит и проверяю степень агрегации. Кроме того, платформы OpenWrt и встраиваемые системы выигрывают от оптимизированных путей в драйверах и меньшего количества атомарных операций. Я тестирую каждую настройку в условиях реальной радионагрузки, прежде чем Профиль широко раскатать.
Мониторинг и показатели, которые действительно важны
Я наблюдаю за RTT— Распределение по сокетам и анализ аномальных значений, а не только средних значений. С помощью ss, tc и экспортеров я считываю длину очередей, количество повторных передач и показатель pacing_rate. Программы eBPF передают мне события, когда сокеты ограничиваются и снова становятся доступными. Показатели «время до первого байта» (Time-to-First-Byte) и 95-й/99-й процентили показывают, эффективно ли работает TSQ. Без измеренных значений любая Оптимизация полет вслепую.
Информативные A/B-тесты и тесты нагрузки
Я измеряю эффекты TSQ с воспроизводимыми результатами: сначала базовые показатели без изменений, затем изолированные сканирования параметров (например, 64, 96, 128, 192 КБ). Для смешанных рабочих нагрузок я запускаю параллельные потоки (массовые запросы + множество коротких запросов) и сравниваю 95-й и 99-й процентили задержек, а не только медиану. Даже если я чётко разделяю тестовые прогоны (разминка, окно измерения, заминка), артефакты остаются заметными. Я слежу за постоянными параметрами: одинаковые шаблоны полезной нагрузки, идентичные маршруты/MTU, одинаковые тактовые частоты процессоров сервера и клиента. На участках WAN я моделирую задержку, джиттер и потери с помощью tc netem, чтобы проверить, не достигают ли пределы TSQ при высоком значении BDP слишком рано. Только когда процентили становятся более узкими, а количество повторных передач и потерь остается стабильным, я переношу значения в производственную среду.
Настройка оборудования и сведения о драйверах
Я проверяю настройки TSO/GSO, кольцевой буфер сетевой карты и управление IRQ, чтобы TSQ работает четко. Слишком большие TX-кольца удлиняют очередь на устройстве; слишком маленькие — снижают загрузку. Грубая группировка прерываний задерживает подтверждения (Ack), тонкая группировка увеличивает нагрузку на ЦП. Исходя из практического опыта, я корректирую подход и для начала рекомендую ознакомиться с Коалесценция прерываний. Цель по-прежнему заключается в обеспечении надежной Латентность при достаточной пропускной способности.
NUMA, RSS и аффинность процессора
Короткие очереди мало что дают, если пакеты постоянно перемещаются через границы NUMA. Я привязываю очереди RX/TX с помощью RSS/irqbalance к ядрам того же NUMA-домена, на котором работает приложение. С помощью XPS/RPS я управляю тем, какие процессоры берут на себя работу TX, и таким образом избегаю переходов между сокетами. Меньшее количество промахов кэша и меньшая конкуренция за блокировки косвенно помогают TSQ: подтверждения завершения обрабатываются быстрее, сокет раньше „разблокируется“, и не возникают пики задержки. При очень большом количестве потоков на хост я планирую достаточное количество очередей и избегаю коллизий нескольких «шумных» потоков на одном TX-кольце.
Пошаговая инструкция: проверка работоспособности TSQ
Начну с того, что посмотрю на Sysctl: Команда sysctl net.ipv4.tcp_limit_output_bytes отображает текущее ограничение. Затем я запрашиваю данные с помощью ss -tin для отдельных сокетов, обращаю внимание на send‑q и rtt и сравниваю фазы нагрузки с настройкой ограничения и без неё. С помощью iperf3 я создаю фоновую нагрузку и параллельно измеряю время отклика API, чтобы выявить приоритеты. Команда tc -s qdisc предоставляет мне данные о количестве пакетов и отказов в исходящей дисциплине. Если 95-й и 99-й процентили остаются близкими, и CPU‑Нагрузка в раме, подберите подходящее ограничение.
Распространенные ошибки и антипаттерны
- „Больший буфер = большая производительность“: это верно для тестов пропускной способности без целевого значения задержки, но не работает в случае интерактивных сервисов. TSQ заменяет чрезмерно большие очереди на кредит, выделяемый по мере необходимости для каждого потока.
- „TSQ снижает пропускную способность“: при правильной настройке TSQ ограничивает всплески, а не среднюю скорость. При обработке массовых нагрузок я умеренно повышаю этот предел и измеряю процентили, а не только пиковые значения в Мбит/с.
- „Одного лишь пейсинга достаточно“: сглаживание по времени важно, но без ограничения размера байта большие кадры GSO всё равно попадают в QDisc. TSQ и пейсинг дополняют друг друга.
- „Одно значение для всех“: рабочие нагрузки, ссылки и сетевые адаптеры различаются. Я работаю с диапазонными значениями и провожу проверку для каждой среды.
- „Затронут только TCP“: основное внимание уделяется TCP, но в системе есть и другие настройки (например, для нагрузки UDP). Я предотвращаю бесконтрольное переполнение одних и тех же очередей параллельными протоколами.
Вывод: целенаправленный контроль за задержкой
TSQ переносит управление очередями драйверов на розетка и тем самым снижает заторы непосредственно у источника. Я ограничиваю количество предварительно буферизованных байтов для каждого потока, обеспечивая таким образом быстрые подтверждения (Ack), меньшее время RTT и справедливое распределение очередей. В сочетании с fq_codel и современными алгоритмами управления перегрузкой время отклика остается стабильным даже при высокой нагрузке. Особые случаи, связанные с Wi-Fi и встроенными системами, я рассматриваю с помощью адаптированных ограничений и тестов в реальных условиях. Тот, кто отслеживает показатели и постепенно корректирует ограничения, сохраняет Латентность постоянно на низком уровне, без потери ненужной пропускной способности.
