networking - trafico - tcp dup ack que es
¿Puede una suma de comprobación de TCP no detectar un error? Si es así, ¿cómo se soluciona esto? (6)
¿Puede una suma de comprobación TCP producir un falso positivo?
Sí. La suma de comprobación es considerablemente más pequeña que el paquete, por lo que muchos paquetes diferentes pueden coincidir con una suma de comprobación determinada.
Si es así, ¿cómo se soluciona esto?
En TCP, nada. Sin embargo, la mayoría de las corrupciones de datos se notarán en un nivel superior, por ejemplo, su XML ya no está bien formado; su correo electrónico ya no es inglés, etc.
Si una carga útil TCP se corrompe en tránsito, la suma de verificación recalculada no coincidirá con la suma de verificación transmitida. Genial, todo bien hasta ahora.
Si una suma de comprobación de TCP se corrompe en tránsito, la suma de verificación recomputada no coincidirá con la suma de comprobación ahora corrompida. Genial, todo bien hasta ahora.
¿Qué ocurre cuando tanto la carga como la suma de comprobación se corrompen y la suma de comprobación recalculada, aunque es diferente de lo que debería ser, coincide con la suma de comprobación ahora corrompida?
Puedo ver con un buen algoritmo de suma de comprobación (y sumas de comprobación adicionales en niveles inferiores) esto podría ser muy, muy poco probable, pero ¿TCP no tiene la intención de ser 100% confiable? ¿Cómo resuelve estos falsos positivos?
y sumas de verificación adicionales en niveles inferiores
Algunos de estos son más estrictos que las sumas de comprobación, por ejemplo, Ethernet utiliza un CRC lugar de una suma de comprobación.
esto podría ser muy poco probable, pero ¿no se supone que TCP es 100% confiable? ¿Cómo resuelve estos falsos positivos?
No creo que pueda Incluso si envió un duplicado a través de una copia impresa y una paloma mensajera, un rayo cósmico o efectos cuánticos podrían teóricamente arruinar el duplicado exactamente de la misma manera. Es muy, muy poco probable.
También puede implementar un control de integridad arbitrariamente fuerte en la capa de la aplicación (por encima de TCP), por ejemplo, utilizando la firma criptográfica.
Algo que debería tenerse en cuenta aquí, y que la mayoría de la gente pasa 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 de 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 viceversa). Con datos distribuidos uniformemente, se espera detectar otros tipos de errores a una tasa 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 16 bits es la misma, independientemente del orden en que aparezcan los valores.
Fuente: ftp://ftp.cis.upenn.edu/pub/mbgreen/papers/ton98.pdf
Por lo tanto, si invierte aleatoriamente cualquier número en cualquier parte de la parte de datos del paquete, las posibilidades son de 1 a 65536 de que este error no se detecte, incluso si no toca la suma de verificación como los datos nuevos, aunque totalmente corrupto, tiene de hecho la misma suma de comprobación que el anterior. Si solo intercambia dos valores de 16 bits en la parte de datos, independientemente de cuáles e independientemente de la frecuencia, las posibilidades 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 corruptos, la verdad es que todos los días, millones de paquetes TCP en Internet solo tienen los datos dañados y este error no se detecta porque la suma de comprobación no corrupta aún coincide con los datos dañados.
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.
Asumir
paquete de carga útil: 1000 byte
suma de comprobación de paquete: 2 bytes
probabilidad de paquete con doble error, uno de los cuales es en suma de comprobación (supongamos que P es muy pequeño, menos de 1/10 ^ 5):
A = 8P*(1000*8P) = 6*10^4 * P^2
probabilidad de suma de comprobación exacta:
B = 1/2^16 = 6/10^4
probabilidad de falso positivo:
A * B = 40 * P^2
La probabilidad es baja (P = 1/10 ^ 6, luego la probabilidad de falso positivo A * B = 4/10 ^ 11) pero en cualquier caso con cualquier algoritmo crc no puede ser cero. La probabilidad de que un paquete aleatorio de 1000 bytes aparezca como otro paquete aleatorio de 1000 bytes es P ^ 8000, como si todos los bytes tuvieran errores.
Si P es alto, por ejemplo de 1/10 ^ 3 a 1, los cálculos anteriores no se aplican. En ese caso, A = 1 (todos los paquetes contienen errores dobles) y la probabilidad de falso positivo es solo A * B = 6/10 ^ 4. No es un caso muy relevante porque más del 99% de los paquetes recibidos contendrán errores en crc.
Me imagino que la probabilidad es de uno en billones de billones de billones, porque si los datos de TCP están dañados, que es la capa de transporte, también significará que las otras capas (enlace de datos y red) también estarán dañadas. Creo que al menos la capa de enlace de datos tiene una suma de comprobación para la integridad, por lo que tendría que tener ambas sumas de comprobación.
Corromper de tal manera que al menos dos sumas de control separadas fallen, es astronómicamente improbable, tal vez incluso imposible.
No, no puede ser 100% confiable: este documento menciona 1 en 16 millones a 10 mil millones de paquetes no detectados por el sistema de control de errores. Te dejaré calcular las ocurrencias por día / semana :)