#flashcards/tcp
#review2

El protocolo TCP

#flashcards/tcp/congestion
#review2

  • Modo de control de congestión de TCP en donde se incrementa la Ventana de congestión en TCP de forma lineal.
  • La Ventana de congestión en TCP (VC) se incrementa en {{una unidad cuando se reciben VC asentimientos.
    • Ejemplo: si la VC es de 10 MSS [1] se podrán enviar 10 segmentos de MSS octetos. Cuando se reciba el ACK que confirma el décimo segmento, la VC pasará a ser de 11.}}
  • Por lo tanto, el VC se incrementa en cada vez que se recibe el ACK de un segmento [1-1].
  • El modo de Evitación de la Congestión finaliza cuando se cumple cualquiera de estos dos eventos:
    • El temporizador vence.
      • Se asume que existe congestión grave en la red.
      • Se actualiza Umbral = 0.5 (Valor VC cuando vence temporizador)
      • Se actualiza VC = 1
      • Se pasa al modo de Arranque Lento
    • Se reciben tres ACKs duplicados.
      • Se asume que existe congestión leve en la red.
      • Se actualiza Umbral = 0.5 (Valor VC cuando vence temporizador)
      • Se actualiza VC = Umbral + 3
      • Se pasa al modo Recuperación Rápida

  1. en el RFC se utiliza la VC anterior y no el valor entero de la misma como hacemos nosotros para simplificar el cálculo.↩︎↩︎

Evitación de la Congestión

#flashcards/tcp
#review2

Control de congestión en TCP

#flashcards/tcp/congestion
#review2

  • Es uno de los algoritmos de control de congestión en TCP.
  • Es el modo en el que se empieza después del establecimiento de La conexión TCP
  • Al empezar en este modo, la Ventana de congestión en TCP (VC) es de {{1 MSS}}.
  • Cuando se recibe un ACK, la VC se incrementa en {{la misma cantidad de octetos reconocidos:
    • Si se recibe un ACK que confirma 1 MSS, la VC se incrementa en 1 MSS. En general, si se confirman n MSSs, la VC se incrementa en n MSSs.}}
  • El modo de Arranque lento finaliza cuando ocurre cualquier de estos tres eventos:
    • Se cumple que VC=Umbral en TCP
    • El temporizador vence.
      • Se asume que existe congestión grave en la red.
      • Se actualiza Umbral = 0.5 (Valor VC cuando vence temporizador)
      • Se actualiza VC = 1
      • Se inicia nuevamente Arranque lento
    • Se reciben tres ACKs duplicados.
      • Se asume que existe congestión leve en la red.
      • Se actualiza Umbral = 0.5 (Valor VC cuando vence temporizador)
      • Se actualiza VC = Umbral + 3
      • Se pasa al modo Recuperación Rápida
Arranque Lento

#flashcards/tcp/congestion
#review2

  • Es un modo recomendado, no obligatorio, aunque actualmente la mayoría de las implementaciones lo incluyen.
  • En este modo se intenta recuperar lo antes posible la pérdida de un segmento.
  • La VC se incrementa {{en un MSS por cada ACK duplicado recibido}}.
  • Cuando se recibe el ACK para el segmento que falta, entonces:
  • Cuando vence el temporizador
    • Umbral = 0.5 (Valor VC cuando vence el temporizador)
    • Se establece VC = 1 MSS.
    • Se pasa al modo Arranque Lento
Recuperación Rápida

#flashcards/tcp/congestion
#review2

Umbral en TCP
Start-here.jpg

#flashcards/tcp/flags
#review2

ACK (TCP flag)

Flags

#flashcards/tcp/flags
#review2

  • Indica a la entidad receptora del segmento que {{pase de inmediato los datos que tiene almacenados a la capa de aplicación}}
PSH (TCP flag)

#flashcards/tcp
#review2

  • Indica el número de secuencia del siguiente octeto que {{procesará la entidad TCP}}
  • Implícitamente confirma la recepción de {{los octetos anteriores al número de asentimiento enviado}}
Número de asentimiento de TCP

#flashcards/tcp/flags
#review2

  • Se utiliza en {{los dos primeros segmentos intercambiados por cliente y servidor}}
SYN (TCP flag)

#flashcards/tcp/flags
#review2

  • Se activa cuando una de las entidades TCP {{pide finalizar la conexión}}
FIN (TCP flag)

#flashcards/tcp
#review2

  • La cabecera TCP es de longitud {{variable}}, pero siempre un múltiplo de {{32 bits}}.
    • Existe una parte obligatoria y una parte opcional.
  • El campo Data Offset de la cabecera TCP indica el número de palabras de 32 bits que contiene la cabecera de un segmento determinado.
  • El campo Data Offset tiene 4 bits, por lo que el número máximo de palabras de 32 bits en la cabecera es de 15. Como la parte obligatoria de la cabecera TCP ocupa 5 palabras de 32 bits, quedan 10 para la parte opcional.
Longitud de la cabecera de TCP

#flashcards/tcp/flags
#review2

  • Indica que el segmento {{tiene datos marcados como urgentes por la capa superior}}
  • El campo {{"Puntero de datos urgente"}} debe contener información válida.
URG (TCP flag)

#flashcards/tcp
#review2

  • Indica el {{número el identificador del primer octeto}} que transporta el segmento con respecto al flujo total de octetos en una dirección de la comunicación.
  • En general, cliente y servidor utilizan números de secuencia diferentes.
  • El primer número de secuencia se elige de manera {{aleatoria}} por cliente y servidor de manera independiente durante La conexión TCP.
Número de secuencia de TCP

#flashcards/tcp
#review2

Cabecera_TCP.png

Estructura segmento TCP

#flashcards/tcp/fiabilidad
#review2

  1. en este contexto, desbordar significa que se reciban más datos de los que se puedan procesar en un determinado tiempo.↩︎

Control de flujo en TCP

#flashcards/tcp
#review2

  • El establecimiento de la conexión TCP se realiza en tres fases
    - Intercambio de tres segmentos especiales.
    - Los dos primeros segmentos ({{SYN y SYN+ACK}}) no portan datos de la Capa de Aplicación. Estos dos segmentos incluyen cabeceras opcionales que se utilizan para negociar el MSS.
    - El tercer segmento ({{ACK}}) puede portar datos de la Capa de Aplicación
    - El establecimiento de la conexión TCP finaliza con el establecimiento de {{las variables de estado2 y capacidades en buffers[1]}} que se utilizarán en la fase de envío de datos.
    Ejemplo_conexion_TCP.png

  1. Buffer del receptor en TCP y Buffer del emisor en TCP ↩︎

Establecimiento de la conexión en TCP

#flashcards/tcp
#review2

  • Una vez se ha terminado el intercambio de datos, cualquiera de las dos entidades (digamos, la A) inicia el cierre de la conexión TCP enviando un segmento con los flags FIN y ACK a 1. La otra entidad debe enviar un segmento de confirmación con el ACK a 1. Posteriormente, la entidad B debe enviar otro segmento con los flags FIN y ACK a 1, a lo que responde A con un segmento con el flag ACK a 1.
  • Una vez cerrada la conexión, ambas entidades liberan todos los recursos asignados a la conexión (Buffer del emisor en TCP, Buffer del receptor en TCP, etc.)

Ejemplo_cierre_conexion_TCP.png

Cierre de la conexión TCP

#flashcards/tcp
#review2

  • Mecanismo empleado en TCP para {{detectar posibles errores durante la transmisión}}.
  • El emisor calcula el checksum, que es función del contenido del segmento TCP a transmitir y de la pseudo-cabecera IP[1], para luego incluirlo en el campo correspondiente de la cabecera TCP. El receptor comprueba si el valor incluido en el campo checksum coincide con sus propios cálculos de dicho valor.

  1. la pseudo-cabecera IP incluye las direcciones IP origen y destino, la longitud del segmento TCP y el protocolo de transporte, así como una secuencia fija de ceros (ver Pseudo-Cabecera IP). Esta pseudo-cabecera sólo se utiliza para calcular el checksum, pero no se transmite.↩︎

Checksum en TCP

#flashcards/tcp
#review2

MSS

¿Qué es?

  • {{Cantidad máxima de datos que puede transportar un segmento TCP}}

¿De qué depende?

  • {{Depende de la MTU[1] y del tamaño de las cabeceras de nivel de red y de transporte: MSS = MTU - cabecera_red - cabecera_transporte}}

¿Cuándo se acuerda la MSS de la conexión TCP?

  • {{En la fase de establecimiento de conexión, ya que el cliente envía su MSS, luego el servidor contesta con su propio MSS y finalmente ambas entidades calculan el MSS de la conexión como el valor mínimo anunciado por ambos extremos. Cada entidad envía sus respectivos MSS en un campo opcional de la cabecera TCP sólo en los dos primeros segmentos (SYN y SYN+ACK)}}

  1. MTU↩︎

MSS - Maximum Segment Size

#flashcards/tcp
#review2

  • La entidad que envía un segmento TCP incluye en este campo {{el número de octetos que puede almacenar en su memoria o Buffer del receptor en TCP [1].}}

  1. en toda conexión TCP, ambas entidades reservan una cierta cantidad de memoria para almacenar temporalmente los segmentos que recibe de la entidad contraria (ver Control de flujo en TCP).↩︎

Ventana de recepción en TCP

#flashcards/tcp
#review2

  • Es el {{espacio de memoria reservado en cada conexión TCP para almacenar provisionalmente los segmentos recibidos de la entidad TCP par, hasta que puedan ser procesados.}}
  • Una vez procesados, los datos pueden ser leídos por la aplicación y eliminados del búffer del receptor.
Buffer del receptor en TCP

#flashcards/tcp
#review2

  • TCP es full-duplex
    • Esto significa que {{ambas entidades pueden enviar datos a su entidad par[1]}}
  • En TCP hay flujo de octetos, no de mensajes.
    • Para TCP lo que recibe del nivel de aplicación es una cadena de octetos, y por lo tanto en el receptor el nivel de TCP no tiene la noción de mensajes.
  • TCP es un protocolo punto a punto (sólo hay dos entidades conectadas)
    • No permite Multicast (un equipo envía a un grupo de equipos) ni Broadcast (un equipo envía al resto de equipos de la red)
  • Se necesita establecer una conexión TCP antes de enviar segmentos con datos, para negociar los parámetros de la conexión (ver Establecimiento de la conexión en TCP)
  • Una vez la fase de establecimiento de la conexión TCP termina:
    • El proceso Cliente pasa datos a la capa TCP utilizando el {{Socket TCP}} creado.
    • TCP realiza Segmentación si fuese necesario, añade Cabecera TCP a dichos segmentos y genera PDUs
  • Una vez se termina el intercambio de datos se debe cerrar la conexión TCP (ver Cierre de la conexión TCP)

Socket_TCP.png

  1. Entidades par↩︎

La conexión TCP
Ejemplo_conexion_TCP.png
Ejemplo_cierre_conexion_TCP.png

#flashcards/tcp
#review2

  • Al enviar el primer segmento con datos, la entidad TCP almacena en la variable local BaseEmision el identificador del segmento enviado.
  • Los segmentos enviados se almacenan en el Buffer del emisor en TCP, por si fuese necesario reenviarlo (ver Fiabilidad en TCP)
Envío de Segmentos en TCP

#flashcards/tcp

  • Recomendación según RFCs 1122 y 2581.
  • NO descarta segmentos recibidos fuera de secuencia. Los asentimientos son acumulativos.
  • Ante la llegada de un segmento de la entidad contraria:
Identificador Evento Acción del Receptor TCP
CR1 Establecimiento o cierre de la conexión TCP Se envía ACK de forma inmediata
CR2 Hay datos que enviar a la entidad contraria Se envía ACK de forma inmediata
CR3 Se recibe segmento con Nº de secuencia esperado. Nºs de secuencia anteriores ya reconocidos. No hay otro segmento en orden esperando transmisión de un ACK. ACK retardado*. Se espera 500 mseg la llegada de otro segmento en secuencia. Si no llega, se envía ACK.
CR4 Se recibe segmento con Nº de secuencia esperado. Hay otro segmento en orden esperando transmisión de ACK. ACK único acumulativo. De inmediato se reconocen ambos segmentos ordenados.
CR5 Se recibe segmento fuera de secuencia, con Nº mayor que el esperado. Se detecta un “hueco”. ACK duplicado. Se envía de inmediato ACK con Nº de secuencia del siguiente octeto esperado (límite inferior del “hueco”).
CR6 Se recibe segmento que completa parcial o totalmente “hueco” en los datos recibidos. ACK inmediato. Se envía ACK de inmediato si el segmento comienza en el límite inferior del “hueco”. De lo contrario, ACK duplicado de inmediato.
Política de generación de ACKs en TCP

#flashcards/tcp/fiabilidad/temporizadores
#review2

  • Al recibir un ACK, la entidad TCP que tenga segmentos pendientes de ser confirmados debe:
    • Comparar el valor del Número de asentimiento de TCP (AN) con la variable interna BaseEmision, que almacena {{el Número de secuencia de TCP más antiguo pendiente de ser confirmado}}
    • Si el AN > BaseEmision esto significa que {{el ACK confirma uno o más segmentos que estaban pendientes de ser confirmados}}. Por lo tanto:
      • Se actualiza el valor de la variable BaseEmision al número de secuencia más antiguo esperando por ser asentido.
      • Si quedan segmentos por confirmar, se actualiza el valor del temporizador (Temporizadores en TCP - Cálculo) y {{se inicia un nuevo temporizador}} asociado al segmento {{más antiguo pendiente de ser confirmado}}.
Procesamiento de ACKs

#flashcards/tcp/fiabilidad
#review2

  • Una entidad TCP debe almacenar los segmentos enviados en una memoria temporal, o buffer del emisor.
  • Tan pronto se reciba confirmación de la correcta recepción del segmento, la entidad TCP puede eliminar el segmento de su buffer de emisor.
  • En el caso de ser necesaria la retransmisión de un segmento, este se obtiene del buffer del emisor.
Buffer del emisor en TCP

#flashcards/tcp
#review2

  • En TCP, los reconocimientos son acumulativos. Esto quiere decir que si se recibe un segmento cuyo campo Número de asentimiento de TCP es , esto indica al receptor de dicho segmento que todos los segmentos enviados hasta el octeto han llegado correctamente a la otra entidad par.
Reconocimientos acumulativos

#flashcards/tcp/fiabilidad

Retransmisión en TCP

#flashcards/tcp/fiabilidad/temporizadores
#review2

  • Al recibir un mensaje del Nivel de aplicación, TCP lo segmenta (Segmentación) si es necesario, añade la cabecera TCP correspondiente, y se lo pasa a su Nivel de red (en el caso del modelo de Internet, al Protocolo IP).
  • Si no hay ningún temporizador activo, {{se inicia un temporizador asociado a dicho segmento}}.
Temporizadores en TCP - Mensajes

#flashcards/tcp/fiabilidad
#review2

  • Los segmentos TCP se protegen con un checksum
  • Si una entidad receptora detecta un error, descarta el segmento recibido.
Detección de errores en TCP

#flashcards/tcp/fiabilidad/temporizadores
#review2

  • La gestión de los temporizadores requiere muchos recursos, por lo que para TCP, el RFC 2988 recomienda
    • Un único temporizador de retransmisión, independientemente del número de segmentos pendientes de ser confirmados.
  • Sucesos importantes en el emisor TCP, relativos a la transmisión y retransmisión de datos, son:
Temporizadores en TCP

#flashcards/tcp/fiabilidad/temporizadores
#review2

  • Al vencer un temporizador, TCP retransmite {{el segmento asociado a dicho temporizador}} que, siguiendo la recomendación del RFC 2988, será el {{más antiguo pendiente de ser confirmado}}.
  • Se redefine el tiempo del temporizador como {{el doble del valor del temporizador anterior}}.
  • Se inicia un nuevo temporizador asociado al segmento reenviado.
Temporizadores en TCP - Timeout

#flashcards/tcp/fiabilidad/temporizadores
#review2

  • El valor al que se inicializa un temporizador en TCP, o timeout se calcula para adaptarse a las condiciones de la red (ver RTT)
  • , donde
    • es el valor medio de los medidos [1].
    • es la desviación típica de los medidos.
  • Cuando un temporizador activo vence, se recalcula el timeout como el doble del timeout anterior.

  1. cuando se envía un segmento, la entidad TCP emisora inicia un cronómetro, que se detiene cuando se recibe un asentimiento que confirma dicho segmento. Así se pueden obtener muestras de los valores del para diferentes segmentos.↩︎

Temporizadores en TCP - Cálculo

#review2

  • Ejemplos utilizando la figura 1 que se puede ver más abajo.
    • Cuando se transmite el segmento con SN=1 se activa un temporizador asociado a dicho segmento. Cuando se recibe el segmento con AN=11, que confirma la recepción del segmento transmitido anteriormente, se desactiva el temporizador del segmento con SN=1.
    • Cuando se transmite el segmento con SN=11 se activa un temporizador, asociado a dicho segmento, ya que no existe ningún temporizador activo. Al transmitirse el segmento con SN=21, no se activa ningún temporizador para dicho segmento [1]. Cuando se recibe el asentimiento que confirma los dos segmentos enviados anteriormente, se desactiva el temporizador activo, asociado al SN=11.

Figura 1:
Ejemplo_Temporizadores_1.png

  • Ejemplos utilizando la figura 2 que se puede ver más abajo.
    • Cuando se transmite el segmento con SN=31, se activa un temporizador asociado a dicho segmento. Los segmentos con SN 41, 51 y 61 no generan nuevos temporizadores, ya que en el momento de su transmisión ya hay un temporizador activo.
    • Al recibir el AN=51 en el host A, se detecta que se confirma el segmento al que está asociado el temporizador activo. Por lo tanto, se desactiva el temporizador activo. Además, y como los segmentos SN=51 y SN=61 están aún pendiente de confirmación, se activa un nuevo temporizador asociado al más antiguo de ellos, es decir, para el SN=51.
    • Cuando se recibe el AN=71, se desactiva el temporizador activo, ya que se confirma el segmento asociado a dicho temporizador. Como no hay ningún segmento pendiente de ser confirmado, no se activa ningún temporizador.
    • Al enviar el segmento con SN=71, se activa un temporizador para dicho segmento. Como dicho segmento se pierde, el host B al recibir el SN=81 (fuera de secuencia) envía un ACK duplicado con AN=71.
    • Ya que un sólo ACK duplicado no genera ningún evento, el temporizador asociado al segmento SN=71 vence, por lo que se envía otra vez el segmento SN=71. El host B envía un ACK con AN=91, que al llegar al host A, desactiva el temporizador activo.

Figura 2:
Ejemplo_Temporizadores_2.png

  1. se asume que sólo puede haber un temporizador activo, como se recomienda en el RFC 2988 Temporizadores en TCP↩︎

Ejemplos temporizadores en TCP

#flashcards/tcp/fiabilidad
#review2

Fiabilidad en TCP
Ejemplo_Temporizadores_1.png
Ejemplo_Temporizadores_2.png
Socket_TCP.png
Cabecera_TCP.png

#review2

Ejercicios de TCP
3
1
2
4
5
6
Interactive Graph
Table Of Contents
Flags
MSS
¿Qué es?
¿De qué depende?
¿Cuándo se acuerda la MSS de la conexión TCP?