Кратко

  • RFC 3320 запускал для каждого сигнального сообщения отдельную виртуальную машину распаковки с ограниченными ресурсами — даже если программу для неё присылал отправитель.
  • Успешная распаковка сама по себе не давала права на долговременное состояние: приложение должно было аутентифицировать результат и вернуть действительный идентификатор compartment, прежде чем разрешить сохранение состояния или обратную связь компрессору.

Вместе с сообщением передавалась и программа

Опубликованная в январе 2003 года RFC 3320 определила Signaling Compression (SigComp) для прикладных протоколов, например SIP и RTSP. Она не исходила из того, что у обеих сторон заранее установлен один и тот же компрессор. Отправитель мог выбрать алгоритм и, если требовалось, включить байткод для исполнения универсальной виртуальной машиной распаковки (Universal Decompressor Virtual Machine, UDVM) на принимающей стороне. Получателю нужна была гибкость, но нельзя было превращать удалённо управляемые вычисления в неограниченный контроль над хостом.

Поэтому исторический вопрос шире, чем «сколько байтов удалось сэкономить». Важно и то, какие вычисления может вызвать входящее сообщение и какую память оно вправе оставить у получателя. RFC описывают границы протокола, но не доказывают распространённость SigComp и не измеряют экономию трафика в работающих сетях. Отправителю предоставлялась возможность предложить ограниченное вычисление; принимающая сторона сохраняла контроль над ресурсами и над тем, какие сведения переживут обработку текущего сообщения.

Для каждого сообщения начиналось новое выполнение

Каждое полученное сообщение SigComp запускает отдельный экземпляр UDVM. Память для распаковки ограничена на сообщение; каждая конечная точка должна предоставлять для этой цели не менее 2 048 байт. Число инструкций тоже зависит от длины сообщения и параметра cycles_per_bit: для сообщения из n байт предел равен (8*n + 1000) * cycles_per_bit, а минимальное значение параметра — 16. Это ограничения одного выполнения, а не формула совокупного потребления ресурсов хостом и не гарантия защиты от всех разновидностей отказа в обслуживании.

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

Распаковать и сохранить — разные полномочия

SigComp отделяет временную память распаковки от памяти состояния, выделенной compartment. Приложение определяет такие compartment для контекста связи и может закрыть их, когда контекст заканчивается. Конечная точка, которая не хочет хранить состояние, может указать нулевую ёмкость. Значит, сохранение состояния не является условием для распаковки текущего сообщения.

Решающая норма применяется после распаковки. Приложение получает восстановленное сообщение и может аутентифицировать его с учётом протокола и контекста. Только если оно готово связать сообщение с действительным идентификатором compartment, уровень SigComp получает право создать новое состояние в этом compartment и передать обратную связь компрессору. Если уверенности недостаточно, приложение не возвращает действительный идентификатор. UDVM завершается, не сохраняя запрошенное состояние и не пересылая обратную связь.

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

Для чтения уже существующего состояния нужен другой контроль

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

Вопросы «может ли это сообщение прочитать ранее установленное состояние компрессии?» и «может ли аутентифицированное содержимое создать или изменить долговременную память?» различны. Они возникают на разных этапах и опираются на разные свидетельства. Если смешать их, правила могут показаться противоречивыми. На деле первое позволяет продолжить распаковку под контролем, а второе ждёт, пока приложение оценит смысл содержимого.

Позднейшие документы разобрали соседние задачи

RFC 3321 добавила расширенные операции и подтверждения; при ненадёжном транспорте отправителю важно получить подтверждение до того, как он начнёт полагаться на состояние у получателя. RFC 4077 описала отрицательное подтверждение ошибок распаковки. RFC 5049 задала требования SigComp для SIP; их нельзя автоматически переносить на все приложения. RFC 4464 — руководство пользователя, а RFC 4465 — набор предельных тестов. Эти документы дают пояснения, сообщения об ошибках и профильные требования, но сами по себе не доказывают внедрение или измеренный эффект.

Долговременный вклад RFC 3320 — разделение полномочий. Сообщение может запросить ограниченное вычисление; приложение решает, достаточно ли доверия к его смыслу, чтобы превратить его в память для следующих сообщений. Разделение делает видимыми ресурсную и доверительную границы — и не позволяет незаметно подменить «распаковано» на «сохранено».

Источники