16 КиБ (как $2^{14}$B, очевидно, составляет 16 КиБ) ограничение размера записи было верным для каждой спецификации TLS, начиная с TLS 1.0, первой, которая не была разработана Netscape, разработавшей версии SSL до 3.0.Обратите внимание, что сжатие сообщения (до TLS 1.2) и шифрование могут увеличить размер до 16 КиБ — насколько это зависит от версии TLS.
До сих пор я видел, что это объясняется как практическое ограничение буферизации. Вы можете/должны начинать расшифровку/декомпрессию только после того, как вся запись будет получена, и для этого вам нужно выделить буфер. Не все устройства поддерживают больший размер буфера, и накладные расходы, вносимые уровнем записи, уже незначительны по сравнению с данными, содержащимися в записях.
Обратите внимание, что данные в записи определенно не должны использовать 64 КБ, поскольку это размер окна TCP по умолчанию. Зашифрованная запись станет больше, чем это окно, и это потребует большего размера буфера, например. встроенные устройства. С другой стороны, он не должен быть слишком маленьким, иначе сообщения рукопожатия больше не поместятся (в основном из-за включенных цепочек сертификатов).
Просто чтобы обеспечить некоторую поддержку моего утверждения, вот текст в RFC 8449: Расширение ограничения размера записи для TLS
Получение больших защищенных записей может быть особенно сложным для устройства с ограниченной оперативной памятью. Версии TLS 1.2 [RFC5246] и более ранние позволяют отправителям создавать записи размером 16384 октета, а также любое расширение от сжатия и защиты до 2048 октетов (хотя обычно это расширение составляет всего 16 октетов). TLS 1.3 уменьшает допуск на расширение до 256 октетов. Выделение до 18 КБ памяти для зашифрованного текста выходит за рамки возможностей некоторых реализаций.
Обратите внимание, что этот RFC позволяет пользователям еще больше ограничивать размер записи, он не позволяет реализациям увеличивать размер записи сверх допустимого.
А теперь немного истории, спецификации SSL 0.2:
Где byte[0] представляет собой первый полученный байт, а byte[1] — второй полученный байт. Когда используется 3-байтовый заголовок, длина записи вычисляется следующим образом (с использованием нотации, подобной «C»):
RECORD-LENGTH = ((byte[0] & 0x3f) << 8)) | байт[1];
IS-ESCAPE = (byte[0] & 0x40) != 0;
ЗАПОЛНЕНИЕ = байт[2];
что приводит к:
Для двухбайтового заголовка максимальная длина записи составляет 32767 байт. Для трехбайтового заголовка максимальная длина записи составляет 16383 байта. Сообщения протокола SSL Handshake Protocol ограничены тем, что помещаются в одну запись протокола SSL Record. Сообщения протокола приложения могут использовать несколько записей протокола SSL Record.
Таким образом, похоже, что последующие спецификации протокола решили использовать меньшую длину записи (исключая служебные данные).
Отказ от ответственности: K означает Кельвин, k означает килограмм, что буквально переводится как тысяча на древнегреческом языке, а Ki означает киби, двоичный (почти) эквивалент, означающий 1024. b означает биты, а B означает байты. Таким образом, 1 КиБ — это 1024 байта. Байты и октеты в наши дни — это одно и то же.
