https://www.rfc-editor.org/rfc/rfc6520では、ハートビート リクエスト/レスポンスの往復にペイロードが含まれる理由が説明されていません。ペイロードの余地があり、応答に要求と同じペイロードが含まれている必要があることを指定するだけです。
このペイロードは何に適していますか? 私の質問は次のとおりです。
ハートビート要求に任意のペイロードを含めることを可能にするプロトコルを設計したとき、エンジニアは何を考えたのでしょうか? 利点は何ですか？
このペイロードを応答に含める必要がある理由は何ですか?
任意のペイロードを許可することで、アプリケーションは特定の応答と特定の要求を明確に一致させることができることがわかりました。それが唯一の利点ですか？はいの場合、ペイロードを特定の長さに強制しなかったのはなぜですか? ペイロードの長さの柔軟性は何に適していますか? ハートビート リクエストの長さを予測できないなど、暗号化の概念と関係がありますか?
他の「ハートビート」のようなプロトコル拡張は、正確な要求 (「ping」など) と対応する応答 (「pong」など) を事前に定義するだけです。https://www.rfc-editor.org/rfc/rfc6520が別のルートをたどったのはなぜですか?
これらすべてが巧妙に配置されたバックドアであった可能性があるという仮説を適切に評価するために、RFC6520 で行われた選択の背後にある理由を理解することが重要です。