Como han señalado otros, hay muchas posibilidades de corrupción de datos donde cualquier suma de verificación en la capa de transporte no puede ayudar, como la corrupción que ya ocurre antes de que la suma de verificación se calcule en el lado emisor, un MITM que intercepta y modifica la secuencia (datos también como sumas de verificación), corrupción que ocurre después de validar la suma de verificación en el extremo receptor, etc.
Si ignoramos todas estas otras posibilidades y nos centramos en los detalles de la suma de verificación TCP en sí y lo que realmente hace en términos de validación de la integridad de los datos, resulta que las propiedades de esta suma de verificación no son del todo completas en términos de detección de errores. La forma en que se eligió este algoritmo de suma de verificación refleja más bien el requisito de velocidad en combinación con el período de tiempo (finales de los 70).
Así es como se calcula la suma de verificación TCP :
Suma de comprobación: 16 bits
El campo de suma de verificación es el complemento de 16 bits de la suma de complemento de todas las palabras de 16 bits en el encabezado y el texto. Si un segmento contiene un número impar de octetos de encabezado y texto para sumar, el último octeto se rellena a la derecha con ceros para formar una palabra de 16 bits para propósitos de suma de verificación. El pad no se transmite como parte del segmento. Mientras se calcula la suma de verificación, el campo de suma de verificación se reemplaza por ceros.
Esto significa que cualquier corrupción que se equilibre al sumar los datos de esta manera no se detectará. Hay una serie de categorías de corrupción en los datos que esto permitirá, pero solo como un ejemplo trivial: cambiar el orden de las palabras de 16 bits siempre pasará desapercibido.
En la práctica, detecta muchos errores típicos pero no garantiza en absoluto la integridad. También ayuda la forma en que la capa L2 también realiza comprobaciones de integridad (por ejemplo, CRC32 de tramas Ethernet), aunque solo para la transmisión en el enlace local, y muchos casos de datos corruptos ni siquiera pasan a la pila TCP.
Validar los datos utilizando un hash fuerte, o preferiblemente una firma criptográfica, se encuentra en un nivel completamente diferente en términos de garantizar la integridad de los datos. Los dos apenas se pueden comparar.