Кратко

  • В испытании из RFC 2348 передача файла размером 2,25 МБ заняла 23,85 секунды без промежуточного шлюза при блоке 512 октетов и 4,90 секунды при блоке 8 192 октета.
  • Размер блока вырос в 16 раз, а измеренное время сократилось примерно на 80%, а не в 16 раз. RFC прямо предупреждает: превышение MTU пути добавляет расходы на фрагментацию и сборку пакетов.

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

В мае 1998 года RFC 2348 предложила согласовывать параметр blksize. Общий механизм расширений был задан в RFC 2347: клиент добавлял опцию к запросу чтения или записи, а сервер мог ответить пакетом OACK. Для размера блока сервер мог принять только значение не выше запрошенного; он не мог самостоятельно предложить опцию, которую клиент не запрашивал. Клиент должен был использовать подтверждённое значение или завершить передачу. Старый сервер мог проигнорировать опцию, после чего стороны продолжали обычный обмен TFTP. Расширение сохраняло совместимость и не требовало одновременного обновления всех узлов.

Допустимый размер составлял от 8 до 65 464 октетов данных на блок, без четырёх октетов заголовка TFTP. В качестве примера RFC приводила 1 428 октетов — расчёт на основе Ethernet MTU после учёта заголовков TFTP, UDP и IP. Это иллюстрация расчёта, а не универсальная настройка. Согласие двух процессов TFTP не доказывало, что каждый канал, туннель и промежуточный узел способен передать получившуюся IP-дейтаграмму без фрагментации.

Авторы описали условия прототипного испытания: две системы HP-UX 9000, слабо загруженный Ethernet, режим octet и файлы по 2,25 МБ. Для каждого размера блока усреднялись пять передач; измерялись пути без промежуточного шлюза и с одним шлюзом. При 512 октетах результаты составили 23,85 и 37,05 секунды. При 8 192 — 4,90 и 6,15 секунды. Время передачи стало меньше примерно в 4,87 раза без шлюза и в 6,02 раза с ним; снижение составило около 79,5% и 83,4%.

Поэтому «16x» в сравнительной таблице — это отношение размеров блоков: 8 192 к 512. Это не означает, что файл передавался в 16 раз быстрее. Сокращение времени приблизительно на 80% соответствует опубликованным средним значениям. Размер блока, число пакетов и полное время — разные показатели. Выигрыш всё же был существенным: крупный блок сокращал число пакетов данных, подтверждений и пауз, а также накладные расходы на обработку каждого пакета.

Ограничение было указано рядом с результатом. Если блок превышал MTU пути, IP-фрагментация и сборка добавляли издержки; при большем числе шлюзов они должны были стать заметнее. Значение, подходящее для тестового Ethernet, могло не подойти за более узким каналом или дополнительной инкапсуляцией. Авторы не тестировали множество интернет-маршрутов, не публиковали разброс значений и не определяли размер блока, оптимальный для всех. Это результат прототипа в описанных условиях, а не статистика развёртываний.

Позже появился ещё один параметр: RFC 7440 определила windowsize, позволяющий передать несколько блоков до ожидания подтверждения. Размер блока и глубина окна влияют на ожидание по-разному. Более поздняя RFC 8900 обсуждает эксплуатационную хрупкость IP-фрагментации, но не доказывает, что испытание 1998 года было неудачным. Первоначального предупреждения достаточно: согласованное значение не подтверждает пригодность всего пути.

Исторический вывод из RFC 2348 — не «чем больше, тем быстрее». Простой протокол получил возможность согласовывать размер единицы передачи с сетью, показал заметный выигрыш при явно описанных условиях и обозначил границу MTU, способную этот выигрыш уменьшить. Это не магическое число, а повод измерить маршрут, по которому действительно идёт передача.

Базовая спецификация TFTP содержится в RFC 1350. Опции тайм-аута и размера передачи того же периода описаны в RFC 2349; они помогают не смешивать blksize с другими согласуемыми параметрами.