3. Heartbeat-Protokoll

Das Heartbeat-Protokoll ist ein neues Protokoll, das auf der Record-Schicht (Record Layer) läuft. Das Protokoll selbst besteht aus zwei Nachrichtentypen: HeartbeatRequest und HeartbeatResponse.

enum {
   heartbeat_request(1),
   heartbeat_response(2),
   (255)
} HeartbeatMessageType;

Eine HeartbeatRequest-Nachricht kann fast zu jedem Zeitpunkt während der Lebensdauer einer Verbindung eintreffen. Wann immer eine HeartbeatRequest-Nachricht empfangen wird, SOLLTE (SHOULD) sie mit einer entsprechenden HeartbeatResponse-Nachricht beantwortet werden.

Eine HeartbeatRequest-Nachricht SOLLTE (SHOULD NOT) jedoch NICHT während Handshakes gesendet werden. Wenn ein Handshake initiiert wird, während eine HeartbeatRequest noch unterwegs ist, MUSS (MUST) der sendende Peer den DTLS-Wiederholungstimer dafür stoppen. Der empfangende Peer SOLLTE (SHOULD) die Nachricht stillschweigend verwerfen, wenn sie während des Handshakes eintrifft. Im Fall von DTLS SOLLTEN (SHOULD) HeartbeatRequest-Nachrichten aus älteren Epochen verworfen werden.

Es DARF (MUST NOT) NICHT mehr als eine HeartbeatRequest-Nachricht gleichzeitig unterwegs sein. Eine HeartbeatRequest-Nachricht gilt als unterwegs, bis die entsprechende HeartbeatResponse-Nachricht empfangen wird oder bis der Wiederholungstimer abläuft.

Bei Verwendung eines unzuverlässigen Transportprotokolls wie des Datagram Congestion Control Protocol (DCCP) oder UDP MÜSSEN (MUST) HeartbeatRequest-Nachrichten unter Verwendung des einfachen Timeout- und Wiederholungsschemas, das DTLS für Flüge verwendet, wie in Abschnitt 4.2.4 von [RFC6347] beschrieben, wiederholt gesendet werden. Insbesondere nach einer Anzahl von Wiederholungen ohne Empfang einer entsprechenden HeartbeatResponse-Nachricht mit der erwarteten Nutzlast SOLLTE (SHOULD) die DTLS-Verbindung beendet werden. Der hierfür verwendete Schwellenwert SOLLTE (SHOULD) derselbe sein wie für DTLS-Handshake-Nachrichten. Bitte beachten Sie, dass nach Ablauf des Timers, der eine HeartbeatRequest-Nachricht überwacht, diese Nachricht nicht mehr als unterwegs betrachtet wird. Daher ist die HeartbeatRequest-Nachricht für eine Wiederholung berechtigt. Das Wiederholungsschema in Kombination mit der Einschränkung, dass nur eine HeartbeatRequest unterwegs sein darf, stellt sicher, dass die Überlaststeuerung angemessen gehandhabt wird, falls das Transportprotokoll keine bereitstellt, wie im Fall von DTLS über UDP.

Bei Verwendung eines zuverlässigen Transportprotokolls wie des Stream Control Transmission Protocol (SCTP) oder TCP müssen HeartbeatRequest-Nachrichten nur einmal gesendet werden. Die Transportschicht übernimmt die Wiederholungen. Wenn nach einiger Zeit keine entsprechende HeartbeatResponse-Nachricht empfangen wurde, KANN (MAY) die DTLS/TLS-Verbindung von der Anwendung beendet werden, die das Senden der HeartbeatRequest-Nachricht initiiert hat.