5.6 缓存

CoAP端点为了减少响应时间和网络带宽消耗，它可以缓存响应。

CoAP中缓存的目标是通过重利用先前的响应消息来应答当前的请求。在某些情况下：甚至无需网络请求，就能够重利用已经存储的响应，从而减少延时和网络回传；一种名为"freshness"的机制用于这个目标(参考5.6.1节)。甚至当有一个新请求时，通常可以重利用先前响应的payload来应答该请求，从而减少了网络带宽的消耗；一种名为"validation"的机制用于这个目标(参考5.6.2节)。

与HTTP不同，CoAP响应的缓存能力并不依赖于请求方法，而是依赖于返回码(Response Code)。在5.9节中返回码定义中列出了每种返回码代表的缓存能力。端点标示成功和无法识别的响应码必须不能被缓存。

对于已提出的请求，CoAP端点一定不能使用已存储的响应，除非：

• 已提出的请求方法和用于获取存储响应的方法相匹配

• 已提出的请求和那些用于获取存储回复的请求(包含请求URI)的所有选项相匹配，除了不需要匹配标记为NoCacheKey的任何请求选项(Section 5.4)或者能被缓存识别并且相对于缓存行为能够完全解释的选项匹配(比如在5.10.6中描述的ETag请求选项，也可以参考5.4.2)

• 已存储的回复是按照下面将要定义的更新或者成功验证。

用于匹配缓存入口的请求选项族可以全体称为“Cache-Key“。比起coap和coaps，在URI格式中，构成请求URI的选项匹配可以在URI格式下的特定规则中执行。