The heartbeat protocol requires the other end to reply with the same data that was sent to it, to know that the other end is alive. Wouldn't sending a certain fixed message be simpler? Is it to prevent some kind of attack?
问问题
380 次
2 回答
3
至少数据包的大小似乎是相关的，因为根据 RFC6520，5.1 心跳消息将与 DTLS（例如 UDP 上的 TLS）一起用于 PMTU 发现 - 在这种情况下，它需要不同大小的消息。除此之外，它可能只是在 ICMP ping 之后建模，您还可以在其中无缘无故地指定有效负载内容。
于 2014-04-11T19:06:41.980 回答
1
就像使用 ICMP Ping 一样，其想法是确保您可以将收到的“pong”心跳响应与您发出的任何“ping”心跳请求相匹配。有些数据包可能会丢失或乱序到达，如果您发送请求的速度足够快并且所有响应内容都相同，则无法判断您的哪些请求得到了响应。
有人可能会想，“谁在乎？我刚刚得到了回应；因此，另一方还活着，准备好了接受我的命令：D！” 但是，如果响应实际上是针对 10 分钟前的心跳请求（极端情况，可能是由于服务器过载）呢？如果您只是在几秒钟前发送了另一个心跳请求，并且预期的响应对所有人都是相同的（“固定消息”），那么您将无法区分。
及时响应对于确定连接的健康状况很重要。从RFC6520第 3 页：
...在多次重传后没有收到具有预期有效负载的相应HeartbeatResponse 消息，DTLS 连接应该被终止。
通过允许请求者指定返回负载（并假设请求者总是生成一个唯一的负载），请求者可以将心跳响应与发出的特定心跳请求相匹配，因此能够计算往返时间，到期适当时连接。
当然，这只有在您通过 UDP 而不是 TCP 等不可靠协议使用 TLS 时才有意义。
那么为什么允许请求者指定有效载荷的长度呢？不能推断吗？
看到这个很好的答案：https ://security.stackexchange.com/a/55608/44094
...似乎是通用性和连贯性尝试的一部分。在 SSL/TLS 标准中，所有消息都遵循常规编码规则，使用特定的表示语言。协议的任何部分都没有从记录长度“推断”长度。
不从外部结构推断长度的一个好处是它可以更容易地在之后包含可选扩展。例如，这是通过 ClientHello 消息完成的。
简而言之，是的，它本来可以，但是为了与现有格式保持一致以及为了将来的校对，指定了大小，以便其他数据可以遵循相同的消息。
于 2014-04-17T21:29:24.807 回答