Общие заголовки RTSP 2.0 — это заголовки, которые могут использоваться как в запросах, так и в ответах. Общие заголовки RTSP 2.0 перечислены в таблице 1
Поле общего заголовка «Cache-Control» используется для указания директив, которым ДОЛЖНЫ подчиняться все механизмы кэширования в цепочке запросов / ответов.
Директивы кэша ДОЛЖНЫ передаваться через приложение-посредник или шлюз, независимо от их значения для этого приложения, поскольку директивы могут быть применимы ко всем получателям в цепочке запросов / ответов. Невозможно указать кэшированную директиву для конкретного кэша.
Cache-Control следует указывать только в запросе методов DESCRIBE, GET_PARAMETER, SET_PARAMETER и SETUP и его ответе. Примечание. Cache-Control не управляет только кэшированием ответов для сообщений RTSP, но также применяется к потоку мультимедиа, указанному в запросе SETUP. Запросы RTSP обычно не кэшируются; дополнительную информацию см. в разделе 16 из RFC 7826.
Список директив поля общего заголовка Cache-Control в RTSP 2.0:
- no-cache
- public
- private
- no-transform
- only-if-cached
- max-stale
- min-fresh
- must-revalidate
- proxy-revalidate
- max-age
Ниже приведены описания директив кэша, которые могут быть включены в заголовок Cache-Control.
Директива «no-cache»
Директива «no-cache» указывает на то, что медиапоток или ответ RTSP НЕ ДОЛЖНЫ кэшироваться где-либо. Это позволяет исходному серверу предотвращать кэширование даже с помощью кэшей, которые были настроены для возврата устаревших ответов на клиентские запросы. Примечание: нет функции безопасности, предотвращающей кеширование контента.
Директива «public»
Директива «public» указывает на то, что медиапоток или ответ RTSP кэшируется любым кешем.
Директива «private»
Директива «private» указывает, что медиапоток или ответ RTSP предназначен для одного пользователя и НЕ ДОЛЖЕН кэшироваться общим кешем. Частный (не общий) кэш может кэшировать медиапотоки.
Директива «no-transform»
Директива «no-transform» промежуточный кеш (прокси) может оказаться полезным для преобразования типа мультимедиа определенного потока. Прокси-сервер может, например, преобразовывать видеоформаты для экономии места в кеше или уменьшения объема трафика на медленном канале. Однако могут возникнуть серьезные эксплуатационные проблемы, когда эти преобразования были применены к потокам, предназначенным для определенных видов приложений. Например, приложения для медицинской визуализации, анализа научных данных и те, которые используют сквозную аутентификацию, все зависят от приема потока, который бит за битом идентичен исходному потоку мультимедиа или ответу RTSP. Следовательно, если ответ включает в себя директиву без преобразования, промежуточный кеш или прокси НЕ ДОЛЖЕН изменять кодировку потока или ответа. В отличие от HTTP, RTSP не обеспечивает частичное преобразование на этом этапе, например, позволяет переводить на другой язык.
Директива «only-if-cached»
Директива «only-if-cached» в некоторых случаях, например, во время крайне плохого сетевого соединения, клиент может захотеть, чтобы кеш возвращал только те потоки мультимедиа или ответы RTSP, которые он в данный момент сохранил, и не получал их от исходного сервера. Для этого клиент может включить в запрос директиву only-if-cached. Если кэш получает эту директиву, он ДОЛЖЕН либо ответить с использованием кэшированного медиа-потока, либо ответа, который согласуется с другими ограничениями запроса, или ответить с состоянием 504 (время ожидания шлюза). Однако, если группа кэшей работает как единая система с хорошей внутренней связью, такой запрос МОЖЕТ быть перенаправлен в эту группу кэшей.
Директива «max-stale»
Директива «max-stale» указывает, что клиент готов принять поток мультимедиа или ответ RTSP, срок действия которого истек. Если max-stale назначено значение, то клиент готов принять ответ, срок действия которого истек не более чем на указанное количество секунд. Если значение max-stale не назначено, тогда клиент готов принять устаревший ответ любого возраста.
Директива «min-fresh»
Директива «min-fresh» указывает, что клиент готов принять поток мультимедиа или ответ RTSP, время жизни которого не меньше его текущего возраста плюс указанное время в секундах. То есть клиент хочет получить ответ, который все еще будет свежим, по крайней мере, в течение указанного количества секунд.
Директива «must-revalidate»
Директива «must-revalidate» когда директива must-revalidate присутствует в ответе SETUP, полученном кешем, этот кеш НЕ ДОЛЖЕН использовать запись в кеш после того, как она устареет, чтобы ответить на последующий запрос, не проверив ее сначала с помощью исходного сервера. Таким образом, кэш требуется выполнять сквозную повторную проверку каждый раз, если, основываясь только на Expires исходного сервера, кэшированный ответ устарел.
Директива «proxy-revalidate»
Директива «proxy-revalidate» директива proxy-revalidate имеет то же значение, что и директива must-revalidate, за исключением того, что она не применяется к кэшам пользовательских агентов, которые не используются совместно. Он может использоваться в ответе на запрос с проверкой подлинности, чтобы разрешить сохранение в кеше пользователя и последующем возврате ответа без необходимости повторной проверки его (поскольку он уже был один раз аутентифицирован этим пользователем), при этом все еще требуя, чтобы прокси-серверы обслуживали многих пользователей, повторяя проверку каждый раз (чтобы убедиться, что каждый пользователь прошел проверку подлинности). Обратите внимание, что такие аутентифицированные ответы также нуждаются в директиве кеша public, чтобы их вообще можно было кэшировать.
Директива «max-age»
Директива «max-age» когда промежуточный кеш с помощью директивы maxage = 0 вынужден повторно проверять свою собственную запись в кеше, и клиент предоставил свой собственный валидатор в запросе, предоставленный валидатор может отличаться от валидатора, который в настоящее время хранится в записе в кеше. В этом случае кеш МОЖЕТ использовать любой валидатор при создании собственного запроса, не влияя на семантическую прозрачность. Однако выбор валидатора может повлиять на производительность. Наилучшим подходом для промежуточного кэша является использование собственного валидатора при выполнении запроса. Если сервер отвечает 304 (не изменено), то кэш может вернуть клиенту свою теперь проверенную копию с ответом 200 (ОК). Однако если сервер отвечает новым телом сообщения и средством проверки кэша, промежуточный кеш может сравнить возвращенный валидатор с предоставленным в запросе клиента с использованием функции строгого сравнения. Если валидатор клиента равен серверу источника, то промежуточный кеш просто возвращает 304 (не изменено). В противном случае он возвращает новое тело сообщения с ответом 200 (ОК).
Синтаксис поля общего заголовка Cache-Control в RTSP 2.0
Cache-Control = "Cache-Control" HCOLON cache-directive *(COMMA cache-directive)
cache-directive = cache-rqst-directive / cache-rspns-directive
cache-rqst-directive = "no-cache"
/ "max-stale" [EQUAL delta-seconds]
/ "min-fresh" EQUAL delta-seconds
/ "only-if-cached"
/ cache-extension
cache-rspns-directive = "public"
/ "private"
/ "no-cache"
/ "no-transform"
/ "must-revalidate"
/ "proxy-revalidate"
/ "max-age" EQUAL delta-seconds
/ cache-extension
cache-extension = token [EQUAL (token / quoted-string)]
delta-seconds = 1*19DIGIT
Ссылки на документы
Скачать оригинальный документ на английском языке RFC 7826 — Real-Time Streaming Protocol Version 2.0
Читать полную версию документа на русском языке RFC 7826 — Потоковый протокол в реальном времени (RTSP), версия 2.0
Ссылка на синтаксис
