Кратко

  • RFC 3150 рассматривал время передачи пакета как проблему совместно используемого канала: крупный пакет на очень медленном соединении мог занимать интерфейс достаточно долго, чтобы другие потоки ощутимо задерживались.
  • Диапазон 100–200 миллисекунд был контекстной рекомендацией Best Current Practice, а не универсальным правилом MTU; меньшие пакеты сокращают время занятия канала, но увеличивают накладные расходы на заголовки и другие затраты, зависящие от пути.

У пакета есть длительность, а не только размер

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

Такова менее очевидная задача в RFC 3150 «End-to-end Performance Implications of Slow Links». Документ опубликован в июле 2001 года как Best Current Practice 48. Он рассматривает маршруты через каналы с очень низкой скоростью и приводит в качестве примеров модем на 56 Кбит/с и беспроводной доступ на 4,8 Кбит/с. Это не отчёт конкретного оператора и не тест определённого оборудования, а рекомендации для обычного интернет-трафика на ограниченном пути.

В разделе о MTU RFC отмечает, что передача сравнительно крупного пакета может занять заметное время и задержать другие потоки, использующие тот же интерфейс. В документе приводятся 100–200 миллисекунд как воспринимаемый интервал и рекомендуется выбирать MTU так, чтобы интерфейс не монополизировался существенно дольше. Значение 296 байт для модемного доступа с компрессией заголовков описано как компромисс, близкий к 200 миллисекундам на линии 9,6 Кбит/с.

От байтов к общей задержке

Расчёт показывает компромисс. Если не учитывать кадрирование и заголовки, за 100 миллисекунд на скорости 56 Кбит/с передаются 700 байт, а на 4,8 Кбит/с — только 60. Удвоение интервала удваивает эти значения. Это иллюстрация времени сериализации, а не предписание MTU: кадрирование канального уровня, инкапсуляция и реальная скорость меняют время занятия линии.

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

Уменьшение MTU тоже не бесплатно. Заголовки повторяются чаще, а при оплате за пакет передача того же объёма может стать дороже. При этом на медленном канале с потерями небольшие сегменты иногда помогают иначе: в небольшое окно перегрузки помещается больше сегментов, что может способствовать восстановлению по дублирующим ACK; очередь из того же числа пакетов содержит меньше байтов. Результат зависит от пути и поведения протоколов — общего правила «меньше всегда быстрее» здесь нет.

Задержку сериализации важно отличать от задержки в очереди. Сериализация — время, когда биты пакета занимают канал; очередь — ожидание за ранее отправленными пакетами. Меньшая MTU может сократить отдельный цикл передачи и повлиять на динамику очереди, но это разные величины. Замечание RFC 3150 о заметном времени занятия канала одним пакетом само по себе не доказывает ни длинную очередь, ни медленную работу приложения.

Практическая рекомендация, а не единая глобальная настройка

RFC 3150 собрал несколько способов оптимизации медленных каналов: компрессию заголовков и полезной нагрузки, поведение TCP при перегрузке, автоматическую настройку буферов, восстановление потерь при малом окне и Limited Transmit. Механизмы взаимодействуют, но не делают все медленные пути одинаковыми. Компрессия заголовков меняет число передаваемых битов; настройка окна приёма меняет объём данных, который отправитель может держать в полёте; активное управление очередями касается места и времени сигнализации о перегрузке. Ни один из этих механизмов не равен времени сериализации отдельного пакета.

Поэтому совет удерживать время занятия канала около воспринимаемого интервала оставлял конкретный выбор реализации и условиям пути. В документе не утверждается, что 100–200 миллисекунд — вечная психофизическая константа, обязательное требование стандарта или оптимум для каждой технологии. Вместо этого к выбору размера пакета применяется вопрос, важный для пользователя: сколько длится очередь для всех остальных?

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

Исторический вклад невелик, но показателен: RFC 3150 рассматривал пакетизацию как распределение времени ожидания между потоками, а не только как эффективную передачу байтов. В качестве редакционных линз я использую заметку Лу Хэна № 64 о минимальной спецификации и локальном выборе, а также заметку № 20 о различии между формальным описанием и наблюдаемой реальностью. Это редакционная рамка, а не утверждения авторов RFC.

Источники

  1. RFC 3150 — End-to-end Performance Implications of Slow Links
  2. Запись RFC 3150 у RFC Editor
  3. RFC 1144 — Compressing TCP/IP Headers for Low-Speed Serial Links
  4. RFC 2416 — When TCP Starts Up With Four Packets Into Only Three Buffers
  5. RFC 2689 — Providing Integrated Services Over Low-bitrate Links
  6. RFC 3155 — End-to-end Performance Implications of Links with Errors
  7. RFC 3449 — TCP Performance Implications of Network Path Asymmetry
  8. RFC 7567 — IETF Recommendations Regarding Active Queue Management
  9. Лу Хэн, заметка 64
  10. Лу Хэн, заметка 20