將CRC32值減少爲16或8位

在消息成幀方案中，我希望通過CRC錯誤檢測來保護數據包。這些數據包通過TCP連接發送。將CRC32值減少爲16或8位

對於長度小於16字節的小包，我會選擇CRC8。對於小於4096字節的數據包，使用CRC16算法。對於大數據包CRC32算法。

由於硬件支持（至少在某些Intel CPU上），目前最有吸引力的CRC實現是CRC32C。但是對於8bit和16bit CRC沒有特別的說明。

我現在的問題是：是否有可能將CRC32C算法的32位值減少到16位或8位值，而不會影響與本地CRC16或CRC8算法相比的錯誤檢測性能？

一個例子：

char buffer[256]; 
... 
uint32_t crc32 = compute_crc32c_of_block(buffer, 256); 
uint16_t fake_crc16 = (crc32 >> 16)^crc32; 
uint8_t fake_crc8 = (fake_crc16 >> 8)^fake_crc16;

是fake_crc8作爲一個真正的CRC8落實好？

在此先感謝。

來源

2014-03-12 Markus Fangerau

有趣的問題。我只是想知道，減少3個字節的有效載荷大小是否真的具有投資回報？考慮到處理特殊情況的運行時影響（我假設你將有不同的結構定義），字節對齊而不是雙字對齊等。 –

是的，數據包是字節對齊的，但是成員的內部偏移符合相應數據類型的要求。對於報頭壓縮，一些（主要是信令）報文可能會縮小至2字節，使用額外的4字節校驗值對於這些看起來有點過分。該協議應該在慢速移動連接上使用最小的成幀開銷，即GSM，其中所有帶寬應該給予實際有效載荷。 –

32位CRC的低8位不會像8位CRC那樣具有良好的錯誤校正屬性，確保檢測突發錯誤。但是，根據噪聲源的特性，它可能足以滿足您的應用需求。如果你的位置有很多相關的位錯誤，那麼你應該使用一個真正的CRC。如果您有少量翻轉或大量錯誤，那麼CRC的一部分可能也會起作用。

有沒有替代測試，看看他們如何執行。

來源

2014-03-12 15:36:24

感謝您使用較低8/16位的建議。這可能會比通過XOR摺疊減少甚至更好。通常不應該有任何錯誤，因爲錯誤的數據應該在達到應用層協議之前通過TCP/IP或鏈路層錯誤檢測來捕獲。然而，在關鍵的醫療環境/用例中，我不能依賴TCP堆棧來保證數據的完整性，所以CRC似乎是在上一次接收階段檢測傳輸錯誤的好工具。 –

將CRC32值減少爲16或8位

回答

相關問題