13 Caching (缓存)

13 Caching (缓存)

在 HTTP 中, 缓存 response-request pairs (响应-请求对)。RTSP 在这方面差异显著。除 DESCRIBE 返回或随 ANNOUNCE 附带的 presentation description (演示描述) 外, 响应不可缓存。 (由于除 DESCRIBE 与 GET_PARAMETER 外的响应不返回数据, 对这些请求而言缓存并非实质问题。) 然而, 希望缓存通常相对 RTSP out-of-band (带外) 投递的 continuous media data (连续媒体数据) 以及会话描述。

收到 SETUP 或 PLAY 请求时, 代理确定其是否拥有 continuous media content (连续媒体内容) 及其描述的最新副本。可分别通过发出 SETUP 或 DESCRIBE 并将 Last-Modified 头部与缓存副本比较来判断是否最新。若副本非最新, 则酌情修改 SETUP 传输参数并将请求转发至 origin server (源服务器)。随后 PLAY 或 PAUSE 等控制命令可不经修改通过代理。代理向客户端投递连续媒体数据, 同时可能生成本地副本供日后复用。缓存允许的确切行为由第 12.8 节所述 cache-response directives (缓存响应指令) 规定。若缓存当前正向请求方服务该流, 则 MUST 应答任何 DESCRIBE 请求, 因为源服务器上流描述的低层细节可能已变化。

注意 RTSP 缓存与 HTTP 缓存不同, 属 "cut-through (直通)" 类型。缓存不从源服务器取回整个资源, 仅在流媒体数据经其流向客户端时复制。因此不引入额外 latency (时延)。

对客户端而言, RTSP proxy cache (代理缓存) 如同常规媒体服务器; 对媒体源服务器而言如同客户端。正如 HTTP 缓存须存储所缓存对象的 content type, content language 等, 媒体缓存须存储 presentation description (演示描述)。通常缓存会从演示描述中去除所有 transport-references (传输引用) (即组播信息), 因为这些与从缓存到客户端的数据投递无关。编码信息保持不变。若缓存能转码已缓存的媒体数据, 将生成新的演示描述, 列出其可提供的全部编码可能。