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，對其進行限制？