數據包中的 RTMP / TCP 額外字節？
我正在分析 RTMP（實時消息傳遞協議）並發現一些非常奇怪的東西。在其中一個擷取的數據包中，TCP 有效負載長度比預期的要長。這是 Wireshark 中的數據包：
該
C3字節使 RTMP 比預期的要長。在 RTMP 有效負載視圖中令人驚訝的是：
如您所見，該
C3字節在 RTMP 視圖中消失了。但它是 TCP 有效負載的一部分。我不知道為什麼會這樣，我懷疑：
- 一些更長的 UTF-8 字元？
根據維基百科，AMF0 中的字元串被編碼為 16 位 UTF-8。這意味著它可以是 8/16 位。但是，
\u33C3和\uC32E都是韓文字元，在第二張圖片中顯示這不是我的情況。 2. TCP有效負載的填充/轉義字元？不…我從來沒有聽說過… 3. 關於 TCP 的一些我不知道的事情？
這是我發現的：
一種。它不是 RTMP 消息的片段，TCP 數據包包含 RTMP 消息所需的所有內容。
灣。校驗和很好，一切似乎都很好。
C。數據包被對端正確確認（圖中未顯示）
d。這是可複制的，通過使用流媒體軟體 Wirecast
我在這裡錯過了什麼嗎？為什麼 Wireshark 可以正確解碼有效載荷？為什麼 Wireshark 簡單地刪除
C3（這表明它與 AMF0 編解碼器無關）？我很困惑。請幫忙 ：’（RTMP 協議規範在這裡：https ://wwwimages2.adobe.com/content/dam/acom/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf
哦，我終於想通了！根據 Adobe 的文件，
最大塊大小預設為 128 字節
和
5.3.1.2.4。類型 3
類型 3 塊沒有消息頭…由大小、流 ID 和時間間隔完全相同的消息組成的流應該對類型 2 塊之後的所有塊使用這種類型。
（Chunk header，也叫“chunk basic header”，不是消息頭，完全不一樣！）
這裡
type 3指的是塊頭類型 3，它位於具有 value 的第一個字節的前兩位0b11xxxxxx。六個字節的重置是流ID（這裡是3，0bxx000011）。這兩個語句與我的問題的行為相匹配：偏移 128 字節上的新塊（消息頭不計數）與塊頭type 3。Wireshark 確實正確解析了它。有點令人困惑：他們不將塊頭視為消息的一部分，這是有道理的。但是他們確實將類型 0-2 的塊頭視為消息的一部分（第一個0x03），這沒有意義。另外，我在這裡找到了一個參考（搜尋
C3並……你明白了……）： https ://en.wikipedia.org/wiki/Real-Time_Messaging_Protocol