使用TCP時，我需要使用校驗和來保護消息嗎？

使用TCP作爲網絡協議，我在每條消息的大小（以及可能的校驗和？）之前加上前綴，然後再通過線路發送消息。我想知道，計算和傳輸消息的校驗和是否有意義，以確保消息將被傳遞（如果以及何時將被傳遞）不變，例如，由於一些網絡錯誤。目前，我在發送消息本身之前發送消息的4字節大小+ 2字節校驗和（CRC-16）。另一個端點正確標識預期的消息長度，讀取它並驗證校驗和。我知道TCP具有內部數據包驗證機制，並且我有強烈的感覺，認爲我在應用程序級別的消息驗證是多餘的，但我不確定並需要您的建議，然後才能做出決定。使用TCP時，我需要使用校驗和來保護消息嗎？

我正在開發客戶端 - 服務器應用程序，每天都有數以萬計的潛在服務器連接。即使任何消息中的單個受損字節都可能導致整個不正確的消息鏈交換，這是不可接受的（幾乎所有客戶端 - 服務器應用程序都具有相同的要求，是不是）。所以我想確定 - 我可以放心地信任TCP的內部可靠性，還是提供自己的校驗和驗證機制更好？而我正在談論的是小的兩字節校驗和（CRC-16），我不是在談論數字簽名消息等。（並且系統是使用套接字在.Net（C＃）中開發的，如果這有什麼區別的話）。

來源

2013-10-05 TX_

如何簡單地通過SSL發送一切？這樣你就可以同時獲得安全和防止意外更改。 – CodesInChaos

爲什麼不使用WCF並停止擔心低級別的協議細節。 –

有時候WCF不是一種選擇，當它是時 - 它通常是首選的方法。但是這次我對套接字解決方案很感興趣。 –

TCP並不保證100％您的數據將按其發送方式進行傳輸和接收。

它始終是你的消息3_ABC與CRC 一不小心就會被轉換爲10_FU @0Ээ^ +Ъr具有相同CRC的機會。但是，你仍然應該依靠它。

由於您已經發現了TCP，因此您只需發送每個數據包的校驗和並將其與另一側的內容進行比較即可，您不必自行完成。 TCP還保證數據按發送順序發送，所以如果你堅持[from 4 to 8 bytes of message's length + message itself]這樣的模式就足夠了。

但是，在使用消息模式的情況下，您可能會轉而使用UDP。有一些方法可以完全用UDP實現最大網絡潛在性，而不是TCP。其中之一是Lidgren.Network C＃庫，它可以發送多種可靠性和順序的數據包。

來源

2013-10-05 13:44:08 AgentFire

根據this paper「校驗和將無法檢測大約1/1600萬到100億個數據包中的錯誤」。假設數據包大小爲1024字節，這相當於每16GB到10TB的網絡流量發生一次未檢測到的錯誤。

許多協議，如HTTP，FTP，SMTP和可能更多依賴於底層的校驗和。根據上述數字，我相信這種做法是可疑。

旁註：硬盤驅動器也是如此。典型的桌面驅動器在10 TB讀取時具有1位的錯誤檢測能力。閱讀您的2TB磁盤5次，平均而言，您將遭受一次腐敗事件。

要回答你的問題：如果你的容忍非常罕見，虛假的故障是中等偏高，不要打擾校驗和。如果您無法容忍任何損壞，請在協議中添加校驗和。

來源

2013-10-06 18:59:20 usr

MD5與SHA1部分有點誤導。 MD5找不到意外錯誤的機會與截斷的SHA1的機會相同。對於故意的衝突，沒有128位散列可以被認爲是安全的，並且SHA1也存在嚴重的缺陷。（如果你有攻擊者，交換哈希的問題就會變得更加棘手，所以它甚至不是一個簡單的「選擇強大的哈希」） – CodesInChaos

SHA1在MD5不再存在的情況下實際上可以抵禦攻擊者的攻擊。對於實際的安全性來說，128位的確足夠了（第二次原像攻擊仍然具有2^128的操作複雜度）。另一方面，答案的一部分並不重要，並且簡短有用。刪除。 – usr

對128位哈希的蠻力衝突花費2^64，這是一個強大的攻擊者可以實現的。 128位哈希可以提供可接受的前置圖像電阻，但不能提供抗碰撞性。對於SHA1來說，比暴力衝突攻擊要快，但沒有人打算實施它們。在MD5已經損壞的任何情況下，我都不會感覺舒服。 – CodesInChaos

使用TCP時，我需要使用校驗和來保護消息嗎？

回答

相關問題