¿TCP / IP evita la repetición de paquetes?

Question

¿TCP / IP impide que varias copias del mismo paquete lleguen al destino? ¿O depende del punto final para superponer la lógica de idempotencia por encima?

Consulte los párrafos específicos de la especificación TCP / IP si es posible.

Answer 1

Es el trabajo de la pila TCP recuperarse de paquetes duplicados:

  

El TCP debe recuperarse de los datos que están   dañado, perdido, duplicado o       entregado fuera de servicio por el sistema de comunicación de internet. Esta       se logra asignando un número de secuencia a cada octeto       transmitido, y que requiere un reconocimiento positivo (ACK) del       recibiendo TCP. Si el ACK no se recibe dentro de un tiempo de espera       intervalo, los datos se retransmiten. En el receptor, el   secuencia       los números se usan para ordenar correctamente los segmentos que se pueden recibir       fuera de servicio y eliminar duplicados. El daño es manejado por       agregando una suma de verificación a cada segmento transmitido, verificándolo en el       receptor y descartando segmentos dañados.

- RFC 793 - Protocolo de Control de Transmisión, Sección 1.5

Sin embargo, si son los mismos paquetes con nuevos números de secuencia, entonces no.

Answer 2

TCP utiliza números de secuencia para detectar duplicación en el caso de retransmisión, lo que también evitará ataques triviales de reproducción.

Del RFC 793, Sección 3.3 - Números de secuencia:

  

Una noción fundamental en el diseño   es que cada octeto de datos enviado   sobre una conexión TCP tiene una secuencia   número. Como cada octeto es   secuenciados, cada uno de ellos puede ser   admitido. El reconocimiento   mecanismo empleado es acumulativo por lo   que un reconocimiento de secuencia   el número X indica que todos los octetos están arriba   pero sin incluir X han sido   recibido. Este mecanismo permite   detección de duplicados directa   en presencia de retransmisión.   Numeración de octetos dentro de un segmento   es que el primer octeto de datos   inmediatamente después del encabezado es   el número más bajo y el siguiente   los octetos se numeran consecutivamente.

La detección de duplicados asegurará que el mismo paquete no pueda ser retransmitido trivialmente. Los números de secuencia también asegurarán que se perciba la inserción (en lugar del reemplazo) de datos en el flujo de datos, ya que los paquetes legítimos posteriores a los paquetes falsificados tendrán números de secuencia duplicados, lo que interrumpirá el flujo de datos. Esto probablemente hará que esos paquetes se descarten como duplicados, lo que probablemente romperá el protocolo que se está utilizando.

Puede encontrar más información sobre la especificación TCP / IP original (1981) en RFC 793 , y los muchos otros RFC que involucran extensiones o modificaciones al protocolo TCP / IP.

Answer 3

Sí, la capa TCP evita paquetes duplicados. La capa de IP debajo no lo hace.

Detalles en RFC 1122 .

Answer 4

Parece estar preocupado por dos cosas diferentes:

1. Qué garantías ofrece la entrega confiable de TCP
2. ¿Puede un atacante afectar el proceso de mi servidor con un ataque de repetición?

Respuesta a 1:

TCP garantiza la entrega confiable y en orden de una secuencia de bytes. Cualquier dato que la aplicación cliente envíe a TCP a través de write () saldrá exactamente igual durante la llamada read () del servidor.

Respuesta a 2:

Los ataques de reproducción no funcionan bien con TCP, ya que cada conexión depende de dos números aleatorios de 32 bits generados por el cliente y el servidor, respectivamente. Para que un ataque de repetición funcione, el atacante debe adivinar el número de secuencia generado por el servidor para la conexión falsa que está iniciando (en teoría, el atacante tiene una probabilidad de 1/2 ** 32 de adivinar correctamente). Si el atacante adivina incorrectamente, en el peor de los casos causará cierto almacenamiento en búfer de datos en su sistema operativo.

Tenga en cuenta que solo porque un ataque de repetición no funciona, nada impide que un atacante forme una conexión legítima con su servidor y transmita cualquier flujo de datos que desee a su aplicación. Por eso es importante validar siempre la entrada .

Answer 5

Las capas por debajo de TCP pueden experimentar múltiples paquetes o paquetes descartados. Las capas por encima de TCP no experimentan repetición o paquetes descartados.

Answer 6

No sé acerca de la repetición de paquetes, pero nunca la he encontrado usando TCP / IP y sé que garantiza que todos los paquetes lleguen en el orden correcto, por lo que no puedo entender por qué no 't.

Answer 7

Realmente depende de cómo esté recibiendo sus datos, aunque técnicamente el protocolo no debería proporcionarle duplicados (es decir, paquetes con la misma suma de comprobación tcp), otros factores podrían hacer que vea duplicados, por ejemplo, el hardware de red que es utilizando; Además, si está utilizando rastreadores para ver flujos de TCP, en lugar de solo leer un socket abierto en su aplicación, es posible obtener paquetes duplicados de los rastreadores, incluso si los flujos de TCP reales que estaban monitoreando no tenían paquetes duplicados.

Para dar un ejemplo del mundo real: en este momento estoy trabajando en un análisis tcp de redes internas para una bolsa de valores importante, y los datos que estoy viendo provienen de múltiples rastreadores y se están volviendo a unir. Entonces, al extraer los datos, descubrí que necesito hacer una serie de pasos de preprocesamiento, que incluyen encontrar y eliminar duplicados. Por ejemplo, en una secuencia que acabo de leer, de aproximadamente 60,000 paquetes de datos, he localizado y eliminado 95 paquetes duplicados.

La estrategia que tomo aquí es mantener una ventana móvil de las 10 sumas de verificación tcp más recientes e ignorar los paquetes que coinciden con esas sumas de verificación. Tenga en cuenta que esto funciona bien para los paquetes PSH, pero no tan bien para los paquetes ACK, pero de todos modos estoy menos preocupado por ellos.

He escrito una colección especial con el propósito de rastrear esta ventana móvil de sumas de verificación tcp, que podría ser útil para otros:

/// <summary>
/// Combination of a double-linked-list and a hashset with a max bound; 
/// Works like a bounded queue where new incoming items force old items to be dequeued; 
/// Re-uses item containers to avoid GC'ing;
/// Public Add() and Contains() methods are fully thread safe through a ReaderWriterLockSlim;
/// </summary>
public class BoundedHashQueue<T>
{
    private readonly int _maxSize = 100;
    private readonly HashSet<T> _hashSet = new HashSet<T>();
    private readonly ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();
    private readonly Item _head;
    private readonly Item _tail;
    private int _currentCount = 0;

    public BoundedHashQueue(int maxSize)
    {
        _maxSize = maxSize;
        _head = _tail = new Item();
    }

    private class Item
    {
        internal T Value;
        internal Item Next;
        internal Item Previous;
    }

    public void Add(T value)
    {
        _lock.Write(() =>
            {
                if (_currentCount == 0)
                {
                    Item item = new Item();
                    item.Value = value;
                    _head.Next = item;
                    item.Previous = _head;
                    item.Next = _tail;
                    _tail.Previous = item;
                    _currentCount++;
                }
                else
                {
                    Item item;
                    if (_currentCount >= _maxSize)
                    {
                        item = _tail.Previous;
                        _tail.Previous = item.Previous;
                        _tail.Previous.Next = _tail;
                        _hashSet.Remove(item.Value);
                    }
                    else
                    {
                        item = new Item();
                        _currentCount++;
                    }
                    item.Value = value;
                    item.Next = _head.Next;
                    item.Next.Previous = item;
                    item.Previous = _head;
                    _head.Next = item;
                    _hashSet.Add(value);
                }
            });
    }

    public bool Contains(T value)
    {
        return _lock.Read(() => _hashSet.Contains(value));
    }
}}

Answer 8

No entiendes completamente el problema. Ver este enlace: http://en.wikipedia.org/wiki/Transmission_Control_Protocol

En esta página está escrito:

" Las marcas de tiempo TCP, definidas en RFC 1323, ayudan a TCP a calcular el tiempo de ida y vuelta entre el emisor y el receptor. Las opciones de marca de tiempo incluyen un valor de marca de tiempo de 4 bytes, donde el emisor inserta su valor actual de su reloj de marca de tiempo, y un valor de marca de tiempo de respuesta de eco de 4 bytes, donde el receptor generalmente inserta el valor de marca de tiempo más reciente que ha recibido. El remitente utiliza la marca de tiempo de respuesta de eco en un acuse de recibo para calcular el tiempo transcurrido total desde que se envió el segmento acreditado. [2]

Las marcas de tiempo TCP también se usan para ayudar en el caso de que los números de secuencia TCP encuentren su límite 2 ^ 32 y "envuelvan". El espacio del número de secuencia. Este esquema se conoce como Proteger contra los números de secuencia envuelta, o PAWS (ver RFC 1323 para más detalles). & Quot;

Saludos, Conjunto (Polonia)