Algo que debe tenerse en cuenta aquí, y que la mayoría de las personas pasan por alto por completo, es el hecho de que la suma de comprobación TCP es en realidad una suma de comprobación muy pobre.
La suma de comprobación TCP es una suma complementaria de 16 bits de los datos. Esta suma detectará cualquier error de ráfaga de 15 bits o menos, y todos los errores de ráfaga de 16 bits, excepto aquellos que reemplazan un complemento de 1 con otro (es decir, 16 bits adyacentes reemplazados por 16 bits cero o vice -versa). Con datos distribuidos uniformemente, se espera detectar otros tipos de errores a una velocidad proporcional a 1 en 2^16. La suma de comprobación también tiene una limitación importante: la suma de un conjunto de valores de de 16 bits es la misma, independientemente del orden en que aparezcan los valores .
Fuente: ftp://ftp.cis.upenn.edu/pub/mbgreen/papers/ton98.pdf
Así que si le da la vuelta al azar cualquier número de bits en cualquier lugar en la parte de datos del paquete, las posibilidades son de 1 a 65536 que no se detecta este error, incluso si no se toca la suma de comprobación en absoluto, ya que los datos nuevos, aunque totalmente corruptos, tienen de hecho la misma suma de comprobación que la anterior. Si solo intercambia dos valores de 16 bits en la parte de datos, independientemente de cuáles e independientemente de la frecuencia, las probabilidades son incluso del 100% de que no se detecte este error, ya que el orden en que aparecen los valores de 16 bits en la parte de datos del el paquete es totalmente irrelevante para el valor de la suma de comprobación calculada.
Lo que trato de decir aquí es que no tiene que preocuparse demasiado por el caso poco probable de que los datos y la suma de comprobación se corrompan y este error no se detecte porque la suma de comprobación corrompida coincide con los datos dañados. la verdad es que todos los días millones de paquetes TCP en Internet tienen solo los datos corruptos y este error no se detecta porque la suma de comprobación no corrompida aún coincide con los datos corruptos.
Si necesita transferir datos y desea asegurarse de que los datos no se corrompan, la suma de comprobación TCP por sí sola no es suficiente para esta tarea. Incluso me atrevo a decir que una suma de comprobación CRC no es suficiente para esta tarea, ya que un CRC32 puede no detectar un error en el que se ven afectados más de 32 bits en una fila (estos errores pueden "cancelarse" entre sí). La suma de comprobación mínima que necesitaría para garantizar una transferencia de datos perfecta es el valor MD5 de los datos. Por supuesto, cualquier cosa mejor que eso (SHA-1, SHA-256, SHA-384, SHA-512, Whirlpool, etc.) funcionará aún mejor, pero MD5 es suficiente. Puede que MD5 ya no sea lo suficientemente seguro para la seguridad criptográfica (ya que se ha roto varias veces en el pasado), pero como suma de comprobación de datos, MD5 es absolutamente suficiente.
Si bien Ethernet tiene una buena integridad de comprobación ¿qué pasa con otras formas de red? –
Espero que desee diseñar la verificación de integridad para que coincida con la tasa de error de su enlace de datos. Por ejemplo, [PPP] (http://en.wikipedia.org/wiki/Point-to-Point_Protocol) también usa un CRC. – ChrisW
Eso tiene sentido. Para una conexión larga a través de diferentes tipos de enlace de datos (ethernet, ppp, atm), creo que estará a merced del peor enlace de componente (que podría no tener comprobación de integridad en absoluto). –