3. Heartbeat 协议
Heartbeat 协议是在记录层之上运行的新协议. 该协议本身由两种消息类型组成: HeartbeatRequest 和 HeartbeatResponse.
enum {
heartbeat_request(1),
heartbeat_response(2),
(255)
} HeartbeatMessageType;
HeartbeatRequest 消息几乎可以在连接生命周期内的任何时间到达. 每当收到 HeartbeatRequest 消息时, 都应 (SHOULD) 使用相应的 HeartbeatResponse 消息进行应答.
但是, 不应 (SHOULD NOT) 在握手期间发送 HeartbeatRequest 消息. 如果在某个 HeartbeatRequest 仍在传输中时发起握手, 发送对等方必须 (MUST) 停止该消息的 DTLS 重传定时器. 如果该消息在握手期间到达, 接收对等方应 (SHOULD) 静默丢弃它. 对于 DTLS, 应 (SHOULD) 丢弃来自较旧 epoch 的 HeartbeatRequest 消息.
任何时候都不得 (MUST NOT) 有超过一个 HeartbeatRequest 消息处于传输中. 在收到对应 HeartbeatResponse 消息之前, 或重传定时器到期之前, HeartbeatRequest 消息都被视为处于传输中.
使用 Datagram Congestion Control Protocol (DCCP) 或 UDP 等不可靠传输协议时, HeartbeatRequest 消息必须 (MUST) 使用 [RFC6347] 第 4.2.4 节中描述的 DTLS 对 flight 使用的简单超时和重传方案进行重传. 特别是, 在多次重传后仍未收到具有预期载荷的对应 HeartbeatResponse 消息时, 应 (SHOULD) 终止 DTLS 连接. 用于此操作的阈值应 (SHOULD) 与 DTLS 握手消息相同. 请注意, 监管 HeartbeatRequest 消息的定时器到期后, 该消息不再被视为处于传输中. 因此, HeartbeatRequest 消息有资格重传. 重传方案与一次只允许一个 HeartbeatRequest 处于传输中的限制相结合, 可确保在传输协议本身不提供拥塞控制时 (例如 DTLS over UDP), 拥塞控制得到适当处理.
使用 Stream Control Transmission Protocol (SCTP) 或 TCP 等可靠传输协议时, HeartbeatRequest 消息只需要发送一次. 传输层会处理重传. 如果经过一段时间后仍未收到对应 HeartbeatResponse 消息, 发起发送 HeartbeatRequest 消息的应用可以 (MAY) 终止 DTLS/TLS 连接.