时，我是否需要使用校验和来保护我的消息？使用TCP作为网络协议，在通过网络发送之前，我在每条消息前加上大小（可能还有校验和？）。我想知道，计算和传输消息的校验和是否有意义，以确保消息将（如果和何时）不变地传递，例如由于某些网络错误。目前，我在发送消息之前发送消息的4字节大小+2字节校验和(CRC-16)。另一个端点正确识别预期的消息长度，读取它并验证校验和。我知道TCP有内部数据包验证机制，我有一种强烈的感觉，我在应用程序级别的消息验证是多余的，但我不确定，在做出决定之前需要你的建议。我正在开发一个客户端-服务器应用程序，每天有数以万计的潜在服务器连接。即使是任何消息中的单个损坏字节也可能导致整个错误消息链被交换，这是不可接受的（好吧，几乎所有客户端-服务器应用程序都有相同的要求，而不是它们）。所以我试图确定——我可以安全地信任TCP的内部可靠性，还是提供我自己的校验和验证机制更好。我说的是小的双字节校验和(CRC-16)，我不是在谈论数字签名消息等（如果没有区别的话，系统是使用套接字在.Net(C#)中开发的）。根据该论文，“校验和将无法检测到大约1600万到100亿个数据包中的错误”。假设数据包大小为1024字节，那么每16GB到10TB的网络流量就会产生一个未检测到的错误。许多协议（如HTTP、FTP、SMTP等）可能都依赖于底层校验和。鉴于以上数字，我认为这种方法有问题。旁注：硬盘驱动器也是如此。典型的桌面驱动器在10TB读取时具有1位错误检测。读取您的2TB磁盘5次，平均您将遭受一次损坏事件。回答您的问题：如果您对非常罕见的虚假故障有中到高的容忍度，请不要理会校验和。如果您不能容忍任何损坏，请向协议添加校验和。就TCP而言，正如其他人所指出的那样，它不是100%可靠的，并且某些消息在传输过程中可能会损坏。为了保持消息完整性，您必须在应用程序级别使用CRC。但是，如果您使用的是SSL/TLS，则不必在应用程序级别执行CRC，因为它已经完成了。通过SSL/TLS交换的消息由图书馆检查完整性。SSL/TLS密码套件中的几乎所有算法都执行消息身份验证。要知道哪种算法HMAC没有或有更可靠的算法，您必须查看它的名称。算法名称由三部分组成。例如“TLS_RSA_WITH_AES_256_GCM_SHA384”有以下三部分；TSL_RSA=>初始握手期间密钥交换的非对称算法。AES_256_GCM=>消息加密的对称算法。因此TLS/SSL中的上述算法，SHA384=>HMACformessage对于消息验证，这就是您不必在应用程序中执行CRC的原因。TCP不能100%保证您的数据将按照发送方式进行传输和接收。使用相同的CRC，您的消息3_ABC和CRC42偶然被意外转换为10_FU@0Ээ^+Ъr。但是，您仍然应该依赖它。由于TCP已经弄清楚了，只需发送每个数据包的校验和并将其与另一端的内容进行比较，您不必自己做。TCP还保证数据按发送顺序排列，因此如果您坚持模式[从4到8个字节的消息长度+消息本身]就足够了。但是，在消息模式的情况下，您可能会改用UDP。有一些方法可以准确地使用UDP而不是TCP来实现最大的网络潜力。其中之一是Lidgren.NetworkC#库，它可以按各种可靠性和顺序发送数据包。以上是C#学习教程：使用TCP时，是否需要使用校验和来保护我的消息？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
