5. 使用场景 (Use Cases)

每个 endpoint 按特定 use case 所需的速率和 padding 发送 HeartbeatRequest messages. endpoint 不应期待其 peer 发送 HeartbeatRequests. 两个方向是独立的.

5.1. Path MTU Discovery

DTLS 按 [RFC6347] Section 4.1.1.1 中的描述执行 path MTU discovery. [RFC4821] 给出了如何执行 path MTU discovery 的详细说明. 所需的 probe packets 是 HeartbeatRequest messages.

这种为 DTLS 使用 HeartbeatRequest messages 的方法, 类似于 Stream Control Transmission Protocol (SCTP) 使用 [RFC4820] 中定义的 padding chunk (PAD-chunk) 的方法.

5.2. 存活性检查 (Liveliness Check)

发送 HeartbeatRequest messages 允许发送方确认它可以到达 peer, 且 peer 仍然存活. 即使在 TLS/TCP 的情况下, 这也允许以远高于 TCP keep-alive feature 所允许的速率进行检查.

除了确认 peer 仍可达之外, 发送 HeartbeatRequest messages 还会刷新所有相关 NATs 的 NAT state.

HeartbeatRequest messages SHOULD 只在至少持续多个 round-trip times 的 idle period 之后发送. 该 idle period SHOULD 可配置, 上限为数分钟, 下限为一秒. idle period 的默认值 SHOULD 可配置, 但它 SHOULD 也可按 per-peer basis 调整.