关键 Web 服务调用是否需要 CRC？
我的数据存储在本地计算机上并使用 Web 服务定期复制。这些数据对于该程序的应用至关重要，并且与业务交易相关。
TransactionHeader JOIN TransactionDetail
如此往复。
在将数据发送到 Web 服务时，我是否应该使用某种类型的 CRC 检查，或者 TCP 协议本身是否足以处理此问题？
编辑：只是为了清楚起见，在服务器确认收到之前，数据不会从客户端删除，并且我在网络服务中使用强类型参数，但我更多地考虑“损坏的”数据（尽管在所有情况下，但字符串理论上应该会失败数据类型转换） ）。
I have data that is stored on a local machine and periodically replicated using webservices. This data is critical to the application of this program and is along the lines of business transactions.
TransactionHeader JOIN TransactionDetail
So forth.
Should I be using some type of CRC checking when sending the data to the webservice or is this handled by the TCP protocol itself sufficiently?
EDIT: Just to be clear the data isnt deleted from the client until the server acknowledges receipt and I use strongly typed parameters in my webservice but I am more thinking about "mangled" data (although in all cases but string it should theoretically fail datatype casting).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常 tcp 在完整传输数据方面做得很好，但如果该数据对业务至关重要，那么您不应该检查该数据直到 tcp，并且应该
在 tcp 级别使用良好的散列函数，所有内容都会简化为字节字符串，因此如果您传输一个数字，如果该数字由于错误而在传输过程中发生更改，并且碰巧仍然是另一侧的数字，则意味着数据类型转换不会捕获该数字，
如果您处理的主要问题是传输检查，则 crc32 等可以正常工作，但如果这些哈希值用于在接收和存储数据后验证数据，则应使用更好的哈希值，例如 sha1 等
normally tcp does a fine job of transferring data intact but if that data is business critical then you shouldn't leave checking that data up to tcp and should use a good hash function
at the tcp level everything is reduced to byte strings so if you transfered a number if that number was changed in transit due to an error and just happened to still be an number to the other side it would mean that datatype casting wouldn't catch that
if the main problem your dealing with is transfer checking then crc32 or such would work fine but if those hashes are used to verify the data after it's been received and stored a much better hash like sha1 or such should be used