Heartbeat の RFC 6520 を読んだ後、いくつかの質問が残っています。
https://www.rfc-editor.org/rfc/rfc6520
具体的には、ハートビートに任意のペイロードやパディングを含める必要がある理由がわかりません。私が理解していることから、ハートビートの目的は、相手が回線の反対側でまだ注意を払っていることを確認することです。
これらの可変長のカスタム ペイロードが提供するもので、固定の要求と応答では提供されないものは何ですか?
例えば
Alice: still alive?
Bob: still alive!
結局のところ、FTP は NOOP コマンドを使用して接続を維持しますが、これは正常に機能しているようです。
(以下は直接的な回答ではありませんが、Heartbleed に関する別の質問に関連するコメントを強調するためにここに記載されています。)
任意の制限を許可するプロトコル設計に反対する議論があります-ペイロードが存在しないはずであった（またはエコー/ハートビート機能さえも）、または小さな有限/固定ペイロードがより良い設計だった.
Is the heartbleed bug a manifestation of the classic buffer overload explore in C?の受け入れられた回答に関するコメントから
(R..) 最後の質問に関しては、大きなエコー リクエストは悪意があると言えます。まったく役に立たないことをするために、サーバー リソース (帯域幅、お金がかかります) を消費しています。ハートビート操作がゼロ以外の長さをサポートする正当な理由は実際にはありません
(Eric Lippert) API の設計者が、バッファの受け渡しをまったく許可しないと信じていたなら、明らかに信じていませんでした。エコー機能をサポートするには、設計上の理由が必要です。なぜそれが固定サイズの 4 バイト バッファではなかったのか、私には十分に思えますが、わかりません。
(R..) .. セキュリティの観点から考えると、任意のエコー要求をサポートすることが合理的であると考える人はいないでしょう。ハートブリード オーバーフローの問題がなかったとしても、ピアが送信するコンテンツをそのように制御することに関連して、暗号化の弱点が存在する可能性があります。これはありそうにないように思えますが、[n echo] 機能をサポートする強力な理由がない場合、暗号化システムはそれをサポートすべきではありません。できるだけシンプルにする必要があります。
実際、 RFC 6520内のこのペイロード/パディングには理由があります。
ドキュメントから：
ユーザーは新しい HeartbeatRequest メッセージを使用できます。このメッセージには、ピアが HeartbeartResponse ですぐに応答する必要があります。[RFC4821]で説明されているように、PMTU 検出を実行するために、パディングを含む HeartbeatRequest メッセージをプローブ パケットとして使用できます 。
受信した HeartbeatResponse メッセージに予想されるペイロードが含まれていない場合、メッセージは黙って破棄する必要があります。予想されるペイロードが含まれている場合は、再送信タイマーを停止する必要があります。
HackerNewsのpwgの功績によるものです。そこにも適切で関連性のある議論があります。