RTMP握手中遇到的一个问题

搜到的时间，比较靠前的一篇类似文章是：RTMP HandShake中的问题

在ffmpeg中rtmp的实现，在handshake中C1是，time字段填充0，zero字段填充的client_ver，生下来的1528这么处理：先填伪随机数，接着加密一段key在其中某个位置。因为暂不关注其伪随机数产生算法及加密算法，所以这里说的模棱两可的。

这是ffmpeg中的两个key

#define PLAYER_KEY_OPEN_PART_LEN 30   ///< length of partial key used for first client digest signing
/** Client key used for digest signing */
static const uint8_t rtmp_player_key[] = {
    'G', 'e', 'n', 'u', 'i', 'n', 'e', ' ', 'A', 'd', 'o', 'b', 'e', ' ',
    'F', 'l', 'a', 's', 'h', ' ', 'P', 'l', 'a', 'y', 'e', 'r', ' ', '0', '0', '1',

    0xF0, 0xEE, 0xC2, 0x4A, 0x80, 0x68, 0xBE, 0xE8, 0x2E, 0x00, 0xD0, 0xD1, 0x02,
    0x9E, 0x7E, 0x57, 0x6E, 0xEC, 0x5D, 0x2D, 0x29, 0x80, 0x6F, 0xAB, 0x93, 0xB8,
    0xE6, 0x36, 0xCF, 0xEB, 0x31, 0xAE
};

#define SERVER_KEY_OPEN_PART_LEN 36   ///< length of partial key used for first server digest signing
/** Key used for RTMP server digest signing */
static const uint8_t rtmp_server_key[] = {
    'G', 'e', 'n', 'u', 'i', 'n', 'e', ' ', 'A', 'd', 'o', 'b', 'e', ' ',
    'F', 'l', 'a', 's', 'h', ' ', 'M', 'e', 'd', 'i', 'a', ' ',
    'S', 'e', 'r', 'v', 'e', 'r', ' ', '0', '0', '1',

    0xF0, 0xEE, 0xC2, 0x4A, 0x80, 0x68, 0xBE, 0xE8, 0x2E, 0x00, 0xD0, 0xD1, 0x02,
    0x9E, 0x7E, 0x57, 0x6E, 0xEC, 0x5D, 0x2D, 0x29, 0x80, 0x6F, 0xAB, 0x93, 0xB8,
    0xE6, 0x36, 0xCF, 0xEB, 0x31, 0xAE
};

将ffmpeg中的rtmp_validate_digest及相关依赖函数抽出来，对S1（fms4）进行测试，都含有rtmp_server_key这段密文，因为sha（安全散列算法）加密是不可逆的，所以只能检测在这段序列中有无该密文。

遇到的问题是，在某些情况下，客户端发送的C1是完全随机的，并且对没有对rtmp_player_key进行加密，然后在途中（网络的某个节点，这里及不明说了，只对问题结论做一点点阐述）被劫，导致handshake无法链接成功。在加入这段密文后，便可以握手成功。这问题的确有点捣蛋。

纠正：

经过测试，用FME（flash media encoder）推流也是，没有遇到该问题的。或许，有多个公开的、可用的key，而flashplayer没有任何key？还是知道flashplayer的key，对其进行限制？