有时将错误的字节写入磁盘。硬件有问题吗？

我已经使用C ++ 11（VS2013）编写了基于UDP的传输协议。它的速度非常快-而且在99.9％的时间内都可以正常工作。

但是我观察到几次将错误的字节写入磁盘（Samsung 250 GB SSD 850 EVO）-或至少看起来如此。

基本上，这是我传输6GB测试文件时发生的情况：

1. 该文件被分成较小的UDP数据包-大小为64K。（网络层会破坏UDP数据报并将其重组为更大的包）。
2. 客户端将数据包（udp）发送到服务器-有效负载使用AES256（OpenSSL）加密，并且包含数据+元数据。有效负载还包含整个有效负载的SHA256哈希-作为对UDP校验和的补充的额外完整性检查。
3. 服务器接收数据包，将“ ACK”包发送回客户端，然后计算SHA256哈希。哈希值与客户的哈希值相同-一切都很好
4. 然后，服务器将程序包的数据写入磁盘（由于巨大的性能差异，请使用fwrite而不是流）。服务器一次只处理一个程序包-每个文件指针都有一个互斥保护，可以防止另一个工作线程关闭该文件互锁，该工作线程关闭了10秒钟不活动的文件指针。
5. 客户端收到UDP“ ACK”包，然后重新发送尚未确认的包（这意味着他们没有成功）。ACK包的传入速率控制客户端的发送速度（即拥塞控制/节流）。在服务器上接收到的程序包的顺序无关紧要，因为每个程序包都包含一个Position值（应在文件中写入数据的位置）。

传输完整个文件后，我在服务器和客户端上都对6GB文件进行了完整的SHA256哈希处理，但令我感到恐惧的是，最近几天我两次观察到哈希值都不相同（进行约20次测试传输时） ）。

在Beyond Compare中比较了文件之后，我通常会发现服务器端有一个或两个位（在6 GB的文件中）有问题。

请参见下面的屏幕截图：

服务器代码-在验证DataPackage哈希值之后调用

void WriteToFile(long long position, unsigned char * data, int lengthOfData){

    boost::lock_guard<std::mutex> guard(filePointerMutex);

    //Open if required
    if (filePointer == nullptr){
        _wfopen_s(&filePointer, (U("\\\\?\\") + AbsoluteFilePathAndName).c_str(), L"wb");
    }

    //Seek
    fsetpos(filePointer, &position);

    //Write - not checking the result of the fwrite operation - should I?
    fwrite(data, sizeof(unsigned char), lengthOfData, filePointer);

    //Flush
    fflush(filePointer);

    //A separate worker thread is closing all stale filehandles 
    //(and setting filePointer to NULLPTR). This isn't invoked until 10 secs
    //after the file has been transferred anyways - so shouldn't matter
}

总结一下：

• 字符*在服务器上的内存中正确-否则服务器SHA256哈希将失败-对吗？（与sha256发生哈希冲突的可能性极小）。
• 写入磁盘时似乎发生了损坏。由于在发送6GB文件时大约有95.000个64k软件包写入磁盘-并且仅发生一次或两次（完全发生），因此这是一种罕见的现象

怎么会这样 是我的硬件（坏ram / disk）造成的吗？

我是否真的需要在写入后从磁盘读取数据，并进行memcmp等操作以确保100％确保将正确的字节写入磁盘？（哦，男孩-表现会如何……）