Los protocolos de la capa de transporte proporcionan una comunicación lógica entre procesos de diferentes hosts
📤 Emisor → Divide los mensajes en segmentos y los pasa a al capa de red
📥 Receptor → Recompone los segmentos y los pasa a la capa de aplicación
Protocolos de la capa de transporte → TCP y UDP
📬
Protocolo TCP
Características proporcionada
Orientado a conexión → Antes de transferir los datos, se establece la conexión
Entrega fiable y en orden → No se pierden paquetes, y se entregan en orden
Control de flujo → Evita desbordar el buffer de destino
Control de congestión → Puede adaptar el tamaño de los paquetes si la red está saturada
📬
Protocolo UDP
Características proporcionadas
Ligero y Simple → Mínimas cabeceras y configuraciones
No orientado a conexión → No es necesario establecer una conexión antes de enviar los datos
No fiable y sin orden → Se pueden perder paquetes. No se garantiza que lleguen en orden
Integridad → Control de errores mínimo
Otras características no proporcionadas
Control de flujo
Control de congestión
Temporización
Tasa de transferencia mínima
Seguridad
💡
Características no proporcionadas hace referencia a que si se desean en el protocolo, se deben implementar manualmente desde la capa de aplicación
Multiplexación y Demimultiplexación
📖
Conceptos
📤
Multiplexación (N→1)
Pasa los mensajes de muchos sockets a una única vía en la capa de red
📥
Demimultiplexación (1→N)
Pasa los mensajes de una vía en la capa de red al socket correspondiente (muchos)en la capa de transporte
💡
Lo de sin conexión previahace referencia a que el protocolo no requere una fase de establecimiento de conexión con el servidor. El cliente enviará datos tan pronto como desee
📥
Demultiplexación sin conexión previa (los datos se envían directamente): UDP
El host recibe un datagrama IP (capa de red)que contiene:
Una cabecera con la IP de origen y una IP de destino
Un segmento de la capa de transporte que contiene un número de puerto de origen y otro de destino
Representación de un segmento
El host utiliza las direcciones IP para entregar el datagrama al host adecuado y el número de puerto para entregar el segmento al socket adecuado
🏷️
Los sockets UDP se identifican por el par IP_DST:PUERTO, por lo que los datos enviados por cualquier host desde cualquier puerto llegarán a este mismo socket.
Esto quiere decir que el servidor no distingue entre los paquetes que vengan de diferentes destinos
📥
Demultiplexación orientada a conexión: TCP
🏷️
Los sockets TCP se identifican por una tupla de cuatro valores (IP_ORI, PUERTO_ORI, IP_DST, PUERTO_DST), por lo que cada puerto del host de destino está reservado, y puede ser utilizado únicamente por un host a través de un puerto concreto
Esto quiere decir que que el servidor distingue entre los paquete que vienen de diferentes destinos (dirección y puerto)
Transporte sin conexión previa: UDP
📨
Características básicas de UDP
Este protocolo implementa las mínimas características que debe tener un protocolo de capa de transporte
📨
Proporciona un servidor de best effort. Los segmentos UDP se pueden perder o ser entregados desordenados
🥷🏻
No requiere una conexión previa con el servidor
No hay negociación entre emisor y receptor
Cada segmento UDP se trata como si fuera único, no como parte de un conjunto o cadena
🧠 Razones para usar UDP
Control más preciso sobre los datos que se envían en las cabeceras del segmento y el estado del segmento
Control más preciso de cuando se envían los mensajes (al no tener control de congestión)
Sin retardos de establecimiento de conexión
Paquetes más ligeros
💡 Protocolos que usan UDP → DNS, SNMP, RIP, …
🏗️Estructura de un segmento UDP
Representación de un segmento UDP
🕷️
Comprobación de errores: Checksum💡 Qué es y para que sirve el checksum
Durante la transmisión, algunos bits del mensaje puende haber sido alterados por error (interferencias). Por ello, los mensajes contienen un campo que contiene el resultado de hacer una operación con todos los bits, de tal manera que si un bit se altera, al repetir dicha operación en destino, el resultado no coincidirá con el valor almacenado en el campo mencionado. Por lo tanto el receptor se dará cuando de que el mensaje está corrupto.
🧮Como se calcula el checksum
Agrupa los bits en grupos de 16-bits
Se suman los resultados, y si en cada suma aparece un acarreo, se suma 1 a la suma
Finalmente, se hace el complemento a 1 del resultado, y ese será el checksum
📥Qué se hace con el checksum en destino
Calcula el checksum de los datos recibidos (sin el campo checksum)
Suma el resultado obtenido más el valor del campo checksum
Resultado igual a 0xFFFF→ Sin errores ✅
Resultado diferente → Error detectado ⚠️
✏️Ejemplo del cálculo del checksum
Campo
Valor del campo (HEX 1B)
—— Datagrama ——
——————————
IP Origen
C0 A8 01 65
IP Destino
10 00 00 05
Protocolo
00 11
Longitud del segmento
00 16
—— Segmento ——
——————————
Puerto de origen
40 00
Puerto de destino
00 50
Longitud del mensaje
00 16
Checksum
?? ??
Mensaje
47 45 54 20 3f 20 48 54 50 2f 31 2e 31
Cálculos acumulados
Para cada campo vamos a agrupar los valores en grupos de 2 Bytes y vamos a sumarlos al valor acumulado
Ejemplo para campo: IP Origen
C0A8 + 0165 = C20D
Entonces ahora sumaremos a este valor los siguientes 16-bits (2 Bytes)
En el momento en el la suma desborde, sumaremos el acarreo al bit menos significativo de la suma
Sumamos todos los campos menos el checksum (ya que ni siquiera lo sabemos, es lo que estamos calculando)
Campo y bytes
Suma acumulada
IP Origen (1) C0A8
C0A8
IP Origen (2) 0165
C20D
IP Destino (1)
D20D
IP Destino (2)
D212
Protocolo
D223
Longitud del segmento
D239
Puerto de origen
1 1239 → 123A (acarreo detectado)
Puerto de destino
128A
Longitud del mensaje
12A0
Mensaje
D7C2
El resultado es D7C2, ahora solo queda hacer el complemento a 1 (alternar todos los bits) y ese será el valor del campo checksum: 283D
Servicio de transferencia de datos fiable
ℹ️
Para decir que la transferencia de datos de un servicio es fiable, debe implementar las siguietes características
Asegurar la integridad de los datos (ningún bit se ha corrompido)
No se pierden paquetes
Los paquetes se entregan en orden
Cuando un canal es fiable se le llama RDT (Reliable Data Transfer)
💡
Si el canal sobre el que se van a transmitir los datos no es fiable, podemos construir nosotros un protocolo que proporcione las características necesarias para convertirlo en fiable
🤖
Para especificar las características del protocolo, usaremos la notación de las FSM (Finite State Machine)
Donde, cada nodo es un estado, cada flecha, una transición a otro estado, y el texto sobre la fecha indica:
Lo de encima de la linea, lo que debe ocurrir para que se transicione al nuevo estado apuntado por la flecha (evento/trigger).
Lo de debajo de la linea, las acciones externas que se realizarán al hacer la transición al nuevo estado (acciones a realizar por el evento)
🚧
En los siguientes ejemplos de FSMs se va a usar el siguiente esquema con unos métodos imaginarios para ayudar a describir el procesoEsquema
ℹ️
RDT 1.0 → Canal TOTALMENTE fiable
El canal que se va a utilizar es perfectamente fiable, sin errores de bit ni perdida de paquetes. Por ello, el protocolo de capa de transporte no necesita implementar ningún mecanismos de control adicional
📤 FSM Emisor
Al ejecutarse la función rdt_enviar(datos), los datos se envían a la capa inferior.
En la capa inferior creamos paquetes con crear_pqt(datos) para posteriormente enviarlos con udt_enviar(paquete)
📥 FSM Receptor
El servidor ejecutará rdt_recibir(paquete) para recibir desde la capa inferior un paquete.
Cuando tengamos el paquete, se extraen los datos de el mismo (ignorando las cabeceras de la capa actual que no forman parte de los datos) con extraer(paquete, datos) para finalmente pasar los datos a la capa superior con entregar_datos(datos)
ℹ️
RDT 2.0 → Canal susceptible de ERRORES DE BIT
El canal que se va a utilizar puede recibir paquetes que contengan bits corruptos. Para evitar que esto ocurra, debemos implementar un checksum al protocolo.
Un mecanismo para recuperar los paquetes corruptos consiste en el envío de paquetes de reconocimiento
El servidor envía un paquete y espera la respuesta del receptor (protocolo stop and wait)
🟢 Reconocimiento positivo (ACK) → Paquete recibido con éxito
🔴 Reconocimiento negativo (NAK) → Paquete recibido con errores. El emisor retransmite el paquete
📤 FSM Emisor
Empezamos en el estado Esperar petición Aplicación, enviamos datos con rdt_Enviar(datos) . Se pasa a la capa inferior donde se crean los paquetes y se distribuyen con edt_enviar
A continuación pasamos al estado Esperar ACK o NCK, en este punto tenemos dos opciones:
Si recibimos ACK transicionamos por la arista de abajo al estado inicial
Si recibimos NAK enviaremos el mismo paquete otra vez al receptor y nos quedamos en el mismo estado
📥 FSM Receptor
Estando en le estado Esperar datos Capa Red, podemos transicionar a través de dos aristas, al mismo estado, pero cada una de estas implica realizar una acción diferente en función del estado de los datos recibidos
Estado del paquete:
No corrupto: El paquete pasa la validación con el checksum por lo que extraemos la información y la pasamos a la capa superior
Corrupto: Se han detectado errores al comprobar el checksum por lo que se envía un mensaje NAK
💡 La FSM vuelve al mismo estado al ejecutarse la transición
🆕 RDT 2.0 respecto de RDT 1.0
ℹ️
Dado que RDT 2.0 es susceptible a errores de bit, los protocolos RDT 2.0 introducen las siguientes características
Detección de errores
Feedback del receptor (ACK y NAK)
Retransmisión de paquetes (NAK)
🕷️ Problemas del RDT 2.0
ℹ️
Si los paquetes ACK o NAK están corruptos. Estos casos no se contemplan en la FSM. Se podría decidir retransmitir el mismo paquete (asumiendo que la confirmación era NAK). Pero esto podría generar duplicados en el receptor si este caso no está contemplado
La solución consiste en añadir un número de secuencia a cada paquete para poder identificar los paquetes que son idénticos en el receptor. Ahora el emisor puede retransmitir el mismo paquete si el ACK o NAK llega corrupto
Si el receptor recibe un paquete que no corresponde con el paquete esperado, este enviarán un ACK del último paquete recivido correctamente (utiliza el checksum para identificar el paquete).
ℹ️
En el ejemplo se muestra una máquina de estado para paquetes cuyo código de secuencia es o 0 o 1. Lo cual es suficiente para el caso ya que los paquetes se mandan de uno en uno. Cada paquete par tendrá el número de secuencia 0 y los impares el 1. Como los paquetes se mandan secuencialmente (no se envía el siguiente hasta que no llega la confirmación del actual) entonces solo nos vale con un número de secuencia que nos ayude a identificar: Un paquete y el siguiente
📤 FSM Emisor
Tenemos dos tipos de estados, los de mandar datos (Esperar llamada…) y los de esperar la confirmación (Esperar ACK…)
Empezamos en Esperar llamada 0…, cuando queremos mandar datos transicionamos hasta Esperar ACK…0 a la vez que mandamos el paquete con número de secuencia 0
En el estado Esperar ACK…0 puede ser que el paquete llegue corrupto, o que el servidor lo haya recibido corrupto (NAK)
Si el paquete ha llegado corrupto o NAK, se vuelve a mandar el mismo paquete, el 0
Si el paquete ha llegado correcto, se transiciona hacia el siguiente estado
En el estado Esperar llamada 1…, cuando se desee mandar datos, transicionaremos al siguiente estado y mandaremos el paquete con número de secuencia 1
En el estado Esperar ACK…1 sucede lo mismo que en el estado Esperar ACK…0
📥 FSM Receptor
En este caso, el receptor siempre se encuentra esperando un paquete con un número de secuencia determinado.
Si el receptor espera el paquete 0, solo transicionará al siguiente estado si el paquete que recibe tiene ese número de secuencia, entonces ahora esperará un paquete con número de secuencia 1. Si el paquete que recive, está corrupto o no tiene el número de secuencia esperado, entonces solicitará el paquete de nuevo.
Si el paquete recivido contiene un 1 en lugar de un 0, enviará un ACK con el checksum del último paquete recivido correctmente
ℹ️
RDT 2.2 → Protocolo sin NAK
Esta versión implementa todo lo de la 2.1, pero esta reemplazará el NAK, por un ACK del último paquete recibido correctamente.
Si el receptor recibe un ACK con un número de secuencia anterior al que esperaba, entonces entiende que el paquete no ha llegado correctamente y lo volverá a mandar desde el paquete con número de secuencia inmediatamente superior al del ACK recibido
ℹ️
RDT 3.0 → Canal con perdidas y errores de bit
Esta versión implementa todo lo de la versión 2.2, pero para poder manejar la perdida de paquetes (datos o ACKs)entonces debemos implementar un mecanismo adicional.
Este mecanismo consiste en un temporizador que, pasado un tiempo razonable, asume que el paquete se ha perdido (datos o ACK)y retransmite de nuevo los datos.
Si el paquete se retrasa, el paquete se va a duplicar, ya que el emisor lo ha retransmitido, pero esto no es problema gracias a los números de secuencia (introducidos en el RDT 2.1) ya que permiten identificar los paquetes y descartar aquellos que ya tienen.
🌐
Ver diapositivas 46en adelantepara ver un par de ejemplos de comunicación con RDT 3.0
📤 FSM Emisor
Empezando en el estado Esperar llamada 0
Si se recive un paquete, no se hace nada ya que no lo estabamos esperando.
Si se envía un paquete. Se realizan las acciones correspondientes y se transiciona al siguiente estado.
Se crea el paquete
Se envia el paquete
Se inicia el temporizador
En el estado Esperar ACK 0
Si se recive un paquete, y este está corrupto o contiene un ACK de otro paquete, no hacemos nada.
Si se acaba el temporizador, se vuelve a enviar el paquete y se reinicia el temporizador
Si se recive un paquete, está correcto, y es el que esperabamos, entonces paramos el temporizador y pasamos al siguiente estado
En el estado Esperar llamada 0
Si se recive un paquete, no hacemos nada ya que no esperabamos ningún paquete
Si se envía un paquete. Se realizan las acciones correspondientes y se transiciona al siguiente estado.
Se crea el paquete
Se envia el paquete
Se inicia el temporizador
En el estado Esperar ACK 1
Si se recive un paquete, y este está corrupto o contiene un ACK de otro paquete, no hacemos nada.
Si se acaba el temporizador, se vuelve a enviar el paquete y se reinicia el temporizador
Si se recive un paquete, está correcto, y es el que esperabamos, entonces paramos el temporizador y pasamos al siguiente estado
📥 FSM Receptor
Empezamos en el estado Esperar 0
Si recivimos un paquete, pero este está corrupto, o su número de secuencia no corresponde con el esperado en el estado actual. Enviamos al receptor un ACK del último paquete recivido correctamente (estado anteriror)
Si recibimos un paquete, está correcto, y tiene el número de secuencia que esperabamos. Realizamos las acciones correspondientes y transicionamos al siguiente estado
Extraemos los datos y los pasamos a la capa superior
Mandamos el ACK al emisor del paquete recibido con su checksum
En el estado Esperar 1
Si recivimos un paquete, pero este está corrupto, o su número de secuencia no corresponde con el esperado en el estado actual. Enviamos al receptor un ACK del último paquete recivido correctamente (estado anteriror)
Si recibimos un paquete, está correcto, y tiene el número de secuencia que esperabamos. Realizamos las acciones correspondientes y transicionamos al siguiente estado
Extraemos los datos y los pasamos a la capa superior
Mandamos el ACK al emisor del paquete recibido con su checksum
🧮
El RTT es el tiempo que transcurre desde que se envía el paquete hasta que se recibe la respuesta del servidor
Tiempo de colocación
Tiempo que pasa desde que se coloca el primer bit en el enlace hasta que se coloca el último
Tc=VeS
S → Tamaño del paquete en bits
Ve → Velocidad del enlace en bits/seg
Tiempo de respuesta
Tiempo que transcurre desde que se coloca el primer bit en el enlace hasta que se recibe la respuesta del servidor
Tr=RTT+Tc
Tasa de utilización del emisor
Tiempo que está el cliente enviando datos respecto del tiempo total (Tr), el tiempo que está enviando datos más el tiempo que está esperando una respuesta
Ue=RTT+TcTc
Protocolos de procesamiento en cadena: Pipelining
ℹ️
Protocolos de procesamiento en cadena (Pipelining)
Estos protocolos permiten al emisor enviar varios paquetes seguidos (en cadena) sin esperar a la respuesta del servidor entre uno y otro.
El rango de números de secuencia debe aumentar (ya no serán solo 0 y 1)
El emisor y el receptor deben contar con un buffer para almacenar varios paquetes
RTT → Tiempo que transcurre desde que se manda el último bit del primer paquete de la cadena, hasta que se recive la respuesta de dicho paquete
🔙
Pipeline GBN (Go Back N)
Este método consiste en mandar N paquetes seguidos y esperar la respuesta (ACKs).
Es receptor solo aceptará los paquetes en orden, si recive un paquete desordenado, lo descartará y mandará el ACK del último paquete recivido correctamente
⚠️
Esto este protocolo no se usa buffer en el receptor, por lo que si le llega el dato n+1 antes que el n, lo descartará
El ACK es acumulativo, por lo que si se recibe el ACK del paquete n, entonces se asumirá como que se han recibido correctamente todos los paquetes con número de secuencia menor que n.
💡
El ACK acumulativo es util ya que si se pierde el ACK de un paquete, pero llega correctamente el ACK del siguiente, dicho ACK reconocerá ambos paquetes en el emisor
🔖
Lenguage usado para referirnos a los elementos de una cadena de paquetes
Ventana → Conjunto de paquetes que ya ha sido enviados (esperando respuesta)
Base → Primer paquete de la ventana
Signumsec → Último paquete de la cadena +1 (número de secuencia del siguiente paquete en entrar en la ventana)
Temporizador → Inicia con el primer paquete de la cadena y se reinicia con cada ACK recibido con el número de secuencia esperado
Representación de una cadena
Los verdes son paquete ya enviados y recibido correctamente su ACK
Los amarillosson paquetes enviados, pero todavía no recivido su ACK
Los azulesson paquetes que forman parte de la ventana y que van a ser enviados inmediatamente, pero todavía siguen en el emisor esperando a ser colocados en el enlace
Los blancos son paquetes que no forman parte de la ventana por lo que hasta que la ventana no avance, estos no serán enviados (o al menos entrarán en la cola de envíos)
🌐
Ver diapositivas 110en adelantepara ver un ejemplo de comunicación por GBN
📤 FSM Emisor
Esta FSM tiene un único estado, pero tiene varias transiciones que realizan diferentes acciones en función de si se dan ciertas condiciones
Si se acaba el temporizador
Se reinicia el temporizador
Se envía de nuevo toda la cadena (desde base)
Si se recibe el paquete corruptono hacemos nada
Si se recibe el paquete correctamente (ACK)
Si el número de secuencia es menor que el número base de la cadena, entonces no se hace nada.
Si el número de secuencia forma parte de la ventana
Se actualiza la base (ultimo ACK recibido correctamente +1)
Si el paquete era el último de la ventana, para el temporizador
Si no era el último, reinicia el temporizador
Si se envía un paquete
Si el paquete cabe en la ventana
Creamos el paquete
Enviamos el paquete
Si el número de secuencia del paquete es el que esperamos, reiniciamos el temporizador
Incrementamos el signumsec
Si no cabe en la ventana, rechazamos los datos
📥 FSM Receptor
Al inicio
Se ajusta el número de paquete esperado
Se crea un paquete para enviar como ACK en caso de que se reciba el primer paquete mal
Si se recive un paquete corrupto o con un número de secuencia diferente al esperado. Entonces se enviará el ACK del último paquete recivido correctamente
Si se recive un paquete correcto
Se extraen los datos y se entregan a la capa superior
Se envía el ACK al emisor
Se incrementa el número de paquete esperado
🔂
Pipelining por repetición selectiva
Este protocolo es una versión mas eficiente del anterior ya que implementa:
El emisor tiene un temporizador por cada paquete
El receptor envía el ACK correspondiente de cada paquete que recibido
El receptor tiene un buffer de paquetes recibidos (para almacenarlos cuando se han recibido en desorden)
De esta manera, podemos ver que este protocolo enviará solo los paquetes que no ha recibido su ACK cuando se acaba el temporizador de estos. El receptor, cuando recive un paquete que no está en el orden que esperaba, lo guarda por si los paquetes que faltan llegan más tarde. De esta manera, cuando falla un paquete, el emisor no se necesita reenvíar todo el resto de paquetes consecutivos si estos han llegado correctamente
⏩
La ventana avanza cada vez que se recibe el ACK del paquete con menor número de secuencia de la ventana (base de la ventana)
Representación de los paquetes en emisor y receptor
⚠️ Dilema con el pipeline de repetición selectiva
Si el tamaño de la ventana y la cantidad de números de secuencia es similar, entonces puede ser que al fallar algunos paquetes, pero avanza la ventana, puede llegar el siguiente paquete con número de secuencia 0, pero el servidor no estará seguro si es un nuevo paquete, o es que el ACK del paquete 0 recivido anteriormente no llegó correctamente
Punto a punto → Hay solo un emisor, y un receptor, nada más
Fiable → Los paquetes se pasan a capa superior en orden
En cadena (pipelined) → El control de flujo y el control de congestión de TCP definen el tamaño de la ventana
Buffers → Existen buffers para los paquetes en el emisor y receptor
Full duplex → La comunicación entre el emisor y receptor es bidireccional y ocurre simultaneamente (no se turnan para comunicarse)
Maximum Segment Size (MSS) → Limita el tamaño del paquete, sin tener en cuenta los headers del protocolo TCP, solo la carga útil (payload), osea los datos de la capa de aplicación
Orientado a conexión → Three-way handshaking para establecer la conexión
Control de flujo → Limita el tamaño de los paquetes que el receptor debe mandar
ACKs → Los ACKs son acumulativos, esto significa que cuando se recive un ACK, este reconoce todos los paquetes con número de secuencia menores que el valor del ACK
Temporizador → Hay un único temporizador y este se correspondo con el paquete en la base de la ventana de emisión.
Cuando se avanza la ventana de emisión, se reinicia el temporizador.
Cuando se termina el temporizador, se retransmite solo el paquete en la base de la ventana, se duplica el tiempo del temporizador
🏗️
Estructura de un paquete TCP
🗃️Campos del paquete TCP
Número de puerto de origen
Número de puerto de destino
Número de secuencia (SEQ)
ℹ️
La secuencia de datos es el conjunto de datos que conforman la conversación entre dos hosts. El paquete de establecimiento de conexión tiene como valor de secuencia 0, pero cuando se completa el establecimiento de conexión, este valor pasa a ser 1 dado que tras el establecimiento de conexión es cuando se puede mandar el primer byteEjemplo
Si se desea enviar desde el HOST1 los datos 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF , estos datos imaginemos que se dividen en 4 paquetes
PQT1 → 00 11 22 33
PQT2 → 44 55 66 77
PQT3 → 88 99 AA BB
PQT4 → CC DD EE FF
Entonces PQT1, tendrá como número de secuencia 1, PQT2 tendrá
el 5, PQT3 será 9 y PQT4 será 13
Si mandaramos un quinto paquete con F0 F1 este tendrá como número de secuencia el 17, pero el siguiente paquete si lo hubiera tendría el 19
Dentro de una secuencia, este valor se corresponde con el número de byte, del primer byte de los datos que contiene el paquete
Número de reconocimiento (ACK)
El ACK aquí funciona como petición de el siguiente paquete, el lugar de servir como confirmación de recepción de un paquete. El valor del ACK en la respuesta será el número inmediatemente superior al número de secuencia del paquete más la longitud del mismo
Ejemplo
Si el paquete que hace la petición tiene seq=18 y contiene 20 bytes len=20 , el paquete de respuesta contendrá el valor ack=38
Longitud cabecera
Este campo ocupa 4-bits y especifica el tamaño en wordsde los headers del paquete TCP
💡 Un paquete sin opciones adicionales ocupa 20 Bytes, por lo que este campo contendrá el valor 5.
(5×4=20) (las palabras son 4 bytes)
Flags
U(URG) → Indica que hay datos urgentes apuntados por el puntero del campo Puntero datos urgente
A(ACK)→ Indica que el valor del campo ACK contiene un valor válido
P(PSH)→ Indica que hay que pasar los datos de este paquete inmediatamente a la capa superior (no meter al buffer)
R(RST) → Indica que se debe reestablecer la conexión
S(SYN) → Indica que se desea establecer una conexión (lo que implica que el valor del número de secuencia del paquete actual será en 0 relativo)
F (FIN) → Indica que se desea cerrar la conexión
Ventana de recepción (MSS)
Control de flujo
Limita el tamaño de los segmentos TCP que le emisor está dispuesto a aceptar en la respuestas
Se utiliza para negociar el tamaño de la MSS o para establecer el multiplicador del tamaño de la ventana en redes de alta velocidad
Datos (Segmento TCP)
🌐
Ver diapositivas 153en adelantepara ver un ejemplo de como evolucionan los valores de SEQ y ACK
⌛
Elección del valor de Timeout
El timeout es el tiempo máximo que se le da a la respuesta de un paquete para volver, y no ser considerado como paquete perdido
🧮
El cálculo del RTT se realiza mediante una media ponderada que da mayor importancia a los paquetes más recientes respecto de los más antiguos
El RTTMuestra (RTTM), es el tiempo real que tarda un paquete concreto en volver
El RTTEstimado(RTTE),es el tiempo que, usando el cálculo explicado anteriormente, consideramos como un aceptable de RTT
El valor de alfa α es una constante la cual representa el peso/pondración que le vamos a dar a los paquetes más antiguos respecto de los más nuevos
⁍
RTTE=(1−α)×RTTE+α×RTTM
💡
Esta formula usa su antiguo valor para calcular el nuevo
Una vez tenemos el RTTEstimado calculado, podemos establecer un timeout basado en este valor
Temporizador=RTTE+(4×RTTDesv)
Siendo RTTDesv
RTTDesv=(1−β)×RTTDesv+β×∣RTTM−RTTE∣
Siendo β=0.25, estamos dando más peso al los valores antiguos de RTTDesv para componsar los valores atípico
Retransmisión rápida
💡
Como el timeout suele ser un tiempo relativamente largo, cuando se pierde un paquete pasa mucho tiempo hasta que se retransmite un paquete perdido. Por ello, TCP implementa un mecanismo de retransmisión rápida
🏎️
La retransmisión rápida consiste en considerar un paquete como perdido si se da la siguiente condición:
Se reciben 3 ACKs duplicados (4 ACKs iguales en total, el que reconoce la secuencia, y 3 más iguales)
Tipos de ACKs
🐌
ACK Retrasado
🎯 Si el segmento que llega es el esperado
📤 Se esperan unos 500ms y si no ha llegado otro paquete en ese tiempo, se envía el ACK del segmento recibido. En caso de recibir otro paquete en ese tiempo, se envía un único ACK del último segmento recibido
📚
ACK Acumulativo
🎯 Si, teniendo uno o varios paquetes en el buffer de receptor; Si recibimos el paquete que faltaba para pasar a capa superior todos lo paquetes acumulados en el buffer
📤 Se enviará el ACK correspondiente del páquete con número de secuencia más alto recibido por el receptor (el más alto de los del buffer)
🔂
ACK Duplicado
🎯 Si se recibe un paquete con un código de secuencia diferente al esperado
📤 Se enviará un ACK duplicado del último segmento recibido en orden
Control de flujo en TCP
💡
Puede ser que el proceso de capa de aplicación no esté sacando paquetes de la capa inferior con la suficiente velocidad, por lo que el buffer de recepcción podría llenarse. Para evitar esto usamos el control de flujo
👮🏻
El control de flujo es usado por el receptor para comunicar al servidor el espacio disponible en el buffer de recepción. El emisor, con esta información, ajustará la velocidad o el tamaño de los paquetes para no saturar al receptor.
A la cantidad de bytes disponible en buffer del receptor se le llama Ventana de Recepción (VR) (o como sale en wireshark: win). Cuando el receptor se queda sin espacio en el buffer, enviará un ACK del último byte recivido correctamente (pero con valor de ACK de tal manera que no solicita el siguiente byte) y además con el valor de win=0
El receptor manda un SYN ACK aceptando el número de secuencia (mandado ahora por el campo ACK+1) y manda su propio número de secuencia
El emisor manda un ACK aceptando el número de secuencia del receptor
💔Finalización de la conexión
El emisor manda un FIN para indicar que desea finalizar la conexión
El receptor manda un ACK para indicar que ha recibido el paquete de FIN
El receptor manda un FIN para indicar que está lista para cerrar la conexión
El emisor manda un ACK para confirmar que ha recividor el FIN del servidor
El emisor esperará 30s antes de finalizar definitivamente la conexión
Principios del control de la congestión
💡
La congestión ocurre cuando la red por la que viajan los paquetes está saturada con paquetes de otras conexiones. Esto puede derivar en pérdida de paquetes o retardos.
⚠️
No confundir el control de congestión con el control de flujo
Control de congestión → Ajustar el envío de paquetes debido a saturación de la red (el camino está saturado)
Control de flujo → Ajustar el envío de paquetes debido la saturación en el buffer de recepción (el destino está saturado)
ℹ️
Hay dos formas de informar al receptor del estado de la conexión
1️⃣ Directo (Choke Packet) → Se envía un paquete al receptor cuyo único objetivo es informar del estado de la red
2️⃣ Indirecto → Se utiliza un campo de un paquete que vaya a ser enviado para informar del estado de la red
📖
Conceptos
Goodput → Es la cantidad de información útil(la información que pasará a capa de aplicación, osea no se cuentan duplicados ni cabeceras) que pasa a través de un enlace por unidad de tiempo
Throughput → Es la cantidad de datos que pasan a través de un enlace por unidad de tiempo
ℹ️
Redes ATM con ABR
Las redes ATM (Asynchronous Transfer Mode) son un tipo de red estándar que permite la transmisión de voz y datos. Estas son unas redes privadas basadas en circuitos virtuales lo que permite aprovechar mejor el ancho de banda dado que proporcionan mecanismos de control de congestión
El ABR (Available Bit Rate)es un servicio de las redes ATM que permite aprovechar mejor los recursos de la red cuando un emisor y un receptor no necesitan estar sincronizados. Se dice que ABR es elástico
🏷️
Nomenclatura
Celdas de datos = Datagramas
Dispositivos de congestión = Routers
Cada 32 celdas de datos enviadas, se envía una celda de gestión de recursos (RM), estas celdas contiene unos campos que son modificados por los conmutadores (routers)
Bit CI (Congestion indication) → Indica congestión severa
Bit NI (No Increase) → Congestión leve
Campo ER (Explicit Rate) → El emisor indicará la tasa, pero podrá se reducida por los conmutadores
Bit EFCI (Explicit Forward Congestion Indication) → Indica que debe ser el receptor el que rellene el campo CI
Mecanismo de control de la congestión de TCP
💡
Para evitar que se congestione la red, iremos reduciendo o aumentando la ventana de emisión en función de si todos lo paquetes que enviamos se reciven correctamente, o se están perdiendo.
ℹ️
El emisor limita la velocidad de transmisión usando una variable llamada Ventana de Congestión (VC), ⚠️ no confundir con la Ventana de Recepción (RC)
En función de el tratamiento de la VC estudiaremos dos versiones de TCP:TCP-Tahoe y TCP-Reno
🌐
TCP-Tahoe
Esta versión de TCP tiene dos fases
Arranque lento (crecimiento exponencial, de todo menos lento 🙃)
ℹ️
La VC empieza en 1, pero crece exponencialmente con cada ACK recibido
Esta fase termina cuando la VC supera el umbral de arranque lento (inicalmente 64kb).
Evitación de la congestión (crecimiento lineal)
ℹ️
La VC aumenta linealmente con cada ACK recibido según la siguiente fórmula
VC=VC+MSS×VCMSS
🛑 Si se reciben 3 ACKs duplicados, pasamos a la fase de Arranque lento y el umbral de arranque lento se reduce a la mitad
Máquina de estados
🌐
TCP-Reno
Esta versión de TCP es similar a TCP-Tahoe, pero introduce una fase más para tratar cuando se recibe un triple ACK duplicado
Arranque lento (crecimiento exponencial, de todo menos lento 🙃)
ℹ️
La VC empieza en 1, pero crece exponencialmente con cada ACK recibido
Esta fase termina cuando la VC supera el umbral de arranque lento (inicalmente 64kb).
Recuperación rápida
ℹ️
Cuando se recibe un triple ACK duplicado, se recude el umbrál de arranque lento a la mitad, y la VC se situa en el umbrál +3
Si se recibe el ACK correcto se pasa al estado de evitación de la congestión
Evitación de la congestión (crecimiento lineal)
ℹ️
La VC aumenta linealmente con cada ACK recibido según la siguiente fórmula
VC=VC+MSS×VCMSS
Máquina de estados
Equidad en TCP
ℹ️
La red reparte el ancho de banda disponible entre todas la conexiones existentes, de forma equitativa.
💡 Si iniciamos 10 conexiones para la transferencia de un archivo, tendremos 10 veces más velocidad ya que la red reparte el ancho de banda entre las conexiones sin importar el origen
Equidad en UDP
ℹ️
Los paquetes UDP no son equitativos, por lo que intentarán acaparar todo el ancho de banda disponible
