Кратко

  • TLS сначала допускал 16 КиБ, затем клиент мог выбрать меньший max_fragment_length, общий для обоих направлений. Так скрывалось, что полная защищённая запись прежде всего нагружает память получателя.
  • RFC 8449 ввёл две направленные декларации: каждая сторона сообщает, что способна принять, а отправитель подбирает записи только для потока к ней.

Направление меняет стоимость

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

Размер распределяет обязанность. Отправитель выбирает объём защищённой единицы, получатель оплачивает атомарную память для её хранения и проверки. Одинаковый протокол не означает одинаковое оборудование. RFC 8449 сделал число заявлением получателя, а не симметричным свойством канала.

От общего потолка к первой уступке

TLS 1.2 помещает данные в TLSPlaintext не более 2^14 байт. Сообщение может занимать несколько записей, а несколько однотипных сообщений — одну. Граница TLS не равна границе приложения, TCP-сегмента или IP-пакета.

Большие записи экономят заголовки и криптографические операции, но создают обязанность принять максимум. Защита и сжатие могут увеличить объект на линии. Для малой RAM буфер становился определяющим.

max_fragment_length, появившийся в 2006 году и сохранённый RFC 6066, позволял клиенту запросить 512, 1024, 2048 или 4096 байт. Сервер повторял ровно выбранное значение; обе стороны сразу дробили и данные, и handshake. Предел действовал в течение сессии, включая тогдашнее возобновление.

Профиль IoT RFC 7925 считал механизм полезным: клиенту не требовался входной буфер под обычные 16 КиБ. Внутреннее ограничение стало видимым партнёру.

Одно значение заставляло два разных приёмника притворяться одинаковыми

Старое расширение выражало максимум 4096, не обычные 16384. Способный клиент рисковал без нужды уменьшить записи, увеличить заголовки, защитную надбавку и число операций. Сервер не мог предложить собственный меньший предел. Значение выбирал клиент, и оно действовало туда и обратно.

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

record_size_limit направлен на заявителя

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

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

Превышение в TLS вызывает фатальный record_overflow; DTLS может отбросить запись. Значение ниже 64 незаконно, однако 64 не является рекомендацией. Слишком мелкие записи увеличивают работу, снижают пропускную способность и могут расширить поверхность отказа в обслуживании.

Что входит в счёт

В TLS 1.2 и ранее предел охватывает вход в сжатие и шифрование; padding шифра учитывается отдельно. В TLS 1.3 считается весь TLSInnerPlaintext: содержимое, внутренний тип и padding записи. Маскировка длины расходует ту же входную ёмкость, что и полезные данные.

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

Это не измерение пути

Малый предел и малая PMTU дают меньшие единицы, но доказывают разное. Предел записи задаёт конечная точка на handshake; PMTU задаёт маршрут, она ограничивает пакеты и меняется со временем. Несколько малых записей DTLS всё ещё помещаются в один UDP-датаграмм.

Расширение не ограничивает HTTP-ответ, цепочку сертификатов или прикладное сообщение: они пересекают записи. Оно не обещает CPU, полосу, размер кода, батарею или общую защиту памяти. Решается одна атомарная обязанность.

IANA сейчас помечает record_size_limit (28) как Recommended, а max_fragment_length (1) — как нерекомендуемый. Реестр описывает стандарт, не распространённость и не оптимальный размер.

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

Источники и границы

Использованы RFC 4366, RFC 5246, RFC 6066, RFC 7925, RFC 8446, RFC 8449 и реестр IANA. Они не измеряют внедрение, RAM продуктов или универсально лучший размер.