我正在构建一个图像服务器。如果客户端上传图像，当它从客户端到服务器的旅程到达服务器时，图像是否有可能被损坏？

可能的？当然，但在您担心之前，让我们再深入了解一下。

以太网包含一个 CRC 值以帮助防止损坏。IPv4、TCP 和 UDP 都使用校验和值来帮助防止损坏（注意：IPv6 没有）。CRC 和校验和是两种不同的方法来计算数据不变。因此，单个 IPv4 数据包将具有 CRC 和两个不同的校验和操作。

两种方法都可以检测到数据中引入的任何单个位错误。当数据中有多个位错误时，就会出现问题。可能有多个位错误提供有效的 CRC。也可能有多个位错误来提供有效的校验和。然而，同时提供有效 CRC 和校验和的多个位错误是非常不可能的（但是是的，可能）。

在所有情况下，当检测到损坏时，它会导致数据被丢弃。TCP 包含一种重新传输丢弃段的机制，通常情况下您在使用时不会遇到数据丢失。

但是，如果使用 UDP 而不是 TCP，如果检测到三个级别（以太网、IPv4 或 UDP）中的任何一个损坏，则数据将被丢弃，并由更高级别的进程（即应用​​程序、文件格式、等）来检测和修复丢失的数据。

到目前为止，所有这些都完全基于网络，但传输数据的应用程序通常也有一些检查数据完整性的方法。此外，某些文件格式也可能具有某种验证完整性的方法，尤其是在它们被压缩的情况下。

再说一次，是的，这是可能的，但不太可能。当您的计算机或服务器正在向磁盘或内存读取/写入数据时，您可能同样有可能引入数据损坏。我还要指出，图像文件中的数据损坏通常会导致严重问题或不明显。

如果是，是否有一些 tcp 机制可以解决此问题，例如奇偶校验等？

正如我所详述的，TCP（以及 UDP、IPv4 和以太网）都有检测数据错误的方法。只有 TCP 有重传机制，所以如果不使用 TCP，数据就会被丢弃。好消息是大多数文件传输确实使用 TCP。

除此之外，它将依赖于应用程序来修复错误。例如，大多数压缩数据都有某种错误检测/纠正。所以压缩文件格式通常在文件中内置了一些度量。此外，如果通过网络发送的数据被压缩（例如启用了 HTTP 压缩的浏览器和服务器），则将涉及到这一点。

并且这不包括应用程序本身内置的任何措施，即使在使用同一台计算机/服务器处理数据时，也应该考虑数据完整性。

以太网帧头中有一个 CRC，如果检测到损坏，它将丢弃一个帧。

IPv4 有一个标头校验和来检测 IP 标头中的损坏（IPv6 没有这个）。

TCP 对整个 TCP 段有一个校验和来检测数据损坏，并且 TCP 保证交付和无序重组。

UDP 具有校验和，但它是一种即发即弃、尽力而为的协议，不期望传送或接收，因此如果您使用 UDP，则需要将其构建到应用程序层中。

您无法确定存储在接收服务器上的图像与发送器上存储的图像完全相同，因为TCP 的 CRC 机制无法检测到某些错误

正如已经回应的那样，jpg 和其他图像格式可以容忍合理数量的错误，但事实是您的图像可能“终生”存储错误，因此每次将其显示给用户时，它都会包含错误。

防止这种情况的一种方法是使用 md5 比较，例如在下载操作系统的大型 iso 映像时使用。但不幸的是，上传对您的用户来说太麻烦了。

另一种方法是使用 https (TLS)，这将保证您没有端到端的错误，因为在较低层未捕获到线路错误的情况下，解密将失败。

如果您不能强制使用 https，防止错误的最佳方法可能是鼓励对用户上传的 gzip 压缩，如果使用 Apache，您可以使用 SetInputFilter DEFLATE 激活