Redes y Servicios elemáticosTRedes y Servicios elemáticosT - Arquitectura TCP/IP Luis Diez...
Transcript of Redes y Servicios elemáticosTRedes y Servicios elemáticosT - Arquitectura TCP/IP Luis Diez...
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Redes y Servicios Telemáticos
Tema 2 - Protocolos de Capa de Transporte
Luis Diez
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Índice
1 Introducción
2 User Datagram Protocol (UDP)
3 Transmission Control Protocol (TCP)
2 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Índice1 Introducción2 User Datagram Protocol (UDP)
Formato de mensajesPuertos y aplicaciones
3 Transmission Control Protocol (TCP)Funcionalidades TCPFormato de segmento TCPConexión TCPGestión de trá�coControl de �ujoControl de congestión
3 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
La capa de transporte
Servicio de transporte de bits a las aplicaciones que se comunican
Solo existe en las entidades extremas ⇒ extremo a extremo
Servicio orientado a la conexión provee garantía de entrega,protección frente a errores, pérdidas y duplicación• Transmission Control Protocol (TCP)• Unidad básica de información: segmento
Servicio no orientado a la conexión no con�rma recepción, niprotege la transmisión• User Datagram Protocol (UDP)• Unidad básica de información: mensaje
4 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Direccionamiento a nivel de transporte
Se necesita poder tener varias aplicaciones accediendo a la vez ala red
Todos los �ujos de datos procedentes de las aplicaciones semultiplexan sobre la misma dirección IP• Para el trá�co de salida en principio no habría inconveniente• ¾Cómo saber a qué aplicación va destinado un datagrama si sólo
tengo una dirección IP?
Aparecen los conceptos de puerto y socket, para posibilitardireccionamiento a nivel de transporte
5 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Direccionamiento a nivel de transporte
6 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Direccionamiento a nivel de transporte
Socket: combinación de dirección IP y puerto que identi�ca unaaplicación ⇒ <Dirección IP/Nombre host>:<Puerto>
Por ejemplo, 5 ventanas del navegador abriendo una página delservidor ⇒ cada ventana tiene asignado un puerto conectado almismo puerto del servidor
7 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Modelo cliente-servidor
Una aplicación (servicio) se mantiene a la escucha en un puerto�jo y otra establece contacto
La información �uye en ambos sentidos, típicamente en modopetición respuesta
Cliente Servidor
Programa arbitrario Propósito especí�coEjecución temporal Ejecución permanenteInicia la comunicación Espera pasivamente a clientesComunicación con un solo servidor Gestiona múltiples clientes
8 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Direccionamiento a nivel de transporte
Los puertos están numerados dentro del rango [0, 65535]
Es necesario conocer los puertos de escucha de los procesos.
Las aplicaciones más comunes tienen puertos reservadosasignados por la IANA• Puertos asignados (well known) [0, 1023]: usados por las
aplicaciones más comunes• Puertos registrados [1024, 49151]: se van asignando a nuevas
aplicaciones• Puertos privados [49152, 65535]: la IANA no los reserva, usados
para aplicaciones privadas
Clientes usan puertos efímeros, típicamente en el rango[1024, 4999]
9 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Índice1 Introducción2 User Datagram Protocol (UDP)
Formato de mensajesPuertos y aplicaciones
3 Transmission Control Protocol (TCP)Funcionalidades TCPFormato de segmento TCPConexión TCPGestión de trá�coControl de �ujoControl de congestión
10 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Protocolo de datagrama de usuario
Se basa en el mismo principio no �able y no orientado a laconexión de IP• No tiene reconocimientos• No proporciona control de �ujo• No proporciona llegada en orden de la información
La aplicación que utiliza UDP debe implementar lasfuncionalidades necesarias
Utilizado para aplicaciones que requieren poco retardo y permitenpérdidas (e.g. streaming de vídeo)
11 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Formato de mensajes
Cabecera de tamaño �jo de 8 bytes
Contenido alineado a 2 bytes
Puertos origen y destino: identi�can emisor y receptor. Puertoorigen opcional (0 por defecto)
Longitud: número de octetos de cabecera y datos, siendo el valormínimo 8
Checksum (opcional): proporciona integridad (IP no compruebaintegridad de datos)
12 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Formato de mensajes
Para el cálculo del checksum se utiliza una pseudo-cabecera IP de11+ 1 bytes
Este es el mismo procedimiento que el checksum de TCP
Complemento a uno de la suma de la pseudo-cabecera, cabeceraUDP y datos en fragmentos de 16 bits
Longitud: la misma que en la cabecera UDP
13 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Multiplexación/demultiplexación de puertos
La multiplexación de trá�co de aplicaciones se realiza a través depuertos
Internamente cada puerto tiene asociada una cola
En recepción a nivel IP se comprueba que se puede recibir eldatagrama• Si el puerto no está disponible se genera un comando ICMP de
puerto inalcanzable y se descarta el datagrama• Si se encuentra el puerto el datagrama se manda a la cola UDP• Si el bu�er de la cola está lleno, se descarta el datagrama
14 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Aplicaciones basadas en UDPPuerto Protocolo Descripción13 DAYTIME Servicio horario (anterior a NTP)37 TIME Servicio horario (anterior a NTP)53 Domain Name Server (DNS) Usa UDP para mensajes cortos67/68 Bootstrap Protocol (BOOTP)
and Dynamic Host Con�gura-tion Protocol (DHCP)
Con�guración de equipos
69 Trivial File Transfer Protocol(TFTP)
Diseñado para compartir �cheros peque-ños
123 Network Time Protocol Sincronización de equipos161/162 Simple Network Management
Protocol (SNMP)Protocolo de gestión
520/521 Routing Information Protocol(RIP)
Protocolo de encaminamiento, compartetabla de rutas
2049 Network File System (NFS) Compartición de archivos, inicialmentebasado en UDP, hoy implementado conTCP
Servicios streaming: Real Time protocol (RTP) o Real TimeStreaming Protocol (RTSP)
15 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Índice1 Introducción2 User Datagram Protocol (UDP)
Formato de mensajesPuertos y aplicaciones
3 Transmission Control Protocol (TCP)Funcionalidades TCPFormato de segmento TCPConexión TCPGestión de trá�coControl de �ujoControl de congestión
16 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Funcionalidades
Servicio orientado a la conexión
Flujo continuo de bytes durante la conexión
Información dividida en segmentos
Transmisión con reconocimientos y re-envíos
Integridad de la información (checksum obligatorio)
Asegura información ordenada a nivel de aplicación
Control de �ujo y control de congestión
17 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Cabecera TCP
No de secuencia: posición del primer byte del campo de datos delsegmento
No de reconocimiento: no de secuencia del siguiente octeto que seespera recibir
Tamaño de la ventana: tamaño de la ventana de recepción sinusar (típicamente en bytes)
Longitud de la cabecera: mínimo 20 bytes, pudiendo llegar hasta60
19 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Flags de la cabecera
URG: indica datos urgentes
ACK: se usa el campo de reconocimiento. Siempre habilitadoexcepto en el primer envío
PSH: subir datos a aplicación tan pronto como sea posible
RST: reiniciar conexión debido a un error de cualquier tipo
SYN: petición de sincronismo de número de secuencia para iniciarconexión. La conexión se inicia cuando ambos extremos mandanun segmento SYN
FIN: indica �nal de envío de datos. Para un cierre de conexiónnormal ambos extremos mandan un segmento FIN
20 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Opciones de la cabecera
La encapsulación de opciones sigue un formatoType-Length-Value (TLV)
La longitud del segmento debe ser múltiplo de 4, sino se completacon NOPs
Algunas de las opciones deben ir acompañadas
21 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Servicio orientado a la conexión
Los protocolos orientados a la conexión requieren unprocedimiento explícito de establecimiento y terminación de lacomunicación
En TCP la gestión de la conexión se basa en un modelocliente/servidor• Cliente: inicia la conexión• Servidor: espera establecimiento de conexiones
La conexión puede terminarse tanto por iniciativa del clientecomo del servidor
22 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Máquina es estados de la conexión
24 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Establecimiento de la conexión
Durante la conexión puede haber segmentos duplicados ⇒conexiones duplicadas
El three-way-handsake evita problemas debidos a duplicación
Cada intento de conexión lleva asociado identi�cadores InitialSequence Number (ISN)aleatorio: uno del cliente y otro delservidor
Estos números permiten identi�car y diferenciar intentos deconexión
25 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Establecimiento de la conexión
En valor del ISN se incrementa cada 4us (32 bits ⇒ 4h46min)
Se realizan hasta 3 intentos de conexión• Si el primero no recibe contestación se espera 6 segundos• Si el segundo no recibe contestación se espera 24 segundos• Si el tercero no recibe contestación se abandona y se debe espera
al menos 2 minutos (TTL máximo)
Ambos extremos pueden indicar el tamaño de la ventana derecepción
Parámetros que se pueden enviar en las opciones• Maximum Segment Size (MSS) de cada extremo (536 por defecto)• Factor de escala de la ventana• Reconocimiento selectivo y métodos alternativos de checksum
Apertura activa/pasiva o apertura simultánea
26 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Cierre de la conexión
Nuevamente el cierre puede iniciarlo un extremo (activo/pasivo) olos dos a la vez (simultaneo)
Sin embargo puede darse el caso de que uno de los extremostodavía tenga datos para enviar: semi-cierre
Problemas de cierre de conexión• ACK �nal perdido: iniciar temporizador y liberar conexión• Respuesta perdida: iniciar temporizador y reiniciar cierre• Respuesta e intentos posteriores perdidos: iniciar temporizador y
liberar conexión
27 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Mantenimiento de la conexión (keep-alive)
Se busca evitar que las conexiones se queden �medio abiertas�(solo un extremo mantiene la conexión)
Se implementa reenviando el último byte transmitido en unsegmento. El receptor descarta el dato pero devuelve un ACK
Si se envían varios keepalive sin respuesta se considera que el otroextremo ha cerrado la conexión y se cierra también en este
Para declarar una conexión �medio abierta� se puede esperarhasta 2 horas
El keepalive no requiere modi�caciones en el receptor
28 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Identi�cación de las conexiones
Una vez establecida la conexión, esta queda identi�cada por ladupla de sockets origen y destino193.144.201.22:3054, 61.12.199.5:80193.144.201.23:3054, 61.12.199.5:80193.144.201.22:3055, 61.12.199.5:80193.144.201.22:3056, 61.12.199.5:80
las conexiones son full-duplex, por lo que la aplicación (origen ydestino) envía el �ujo de datos a través del socket local y confíaen TCP/IP para que llegue a su destino
29 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Tamaño máximo del segmento
Maximum segment size (MSS): cantidad máxima de datos aenviar por TCP al otro extremo
El valor no es negociado, cada extremo lo noti�ca (por defecto536 bytes)
Son preferibles valores elevados para evitar fragmentación
Al establecer la conexión el segmento SYN incluye el MSS
El valor máximo del MSS se calcula como
MSSmax = MTU − (IPheader + TCPheader )
30 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Segmentos de reinicio
Son aquellos segmentos con el �ag RST activado
Se envían siempre que llegan segmentos erróneos dentro delcontexto de la conexión• Para indicar que se ha realizado una petición de conexión a un
puerto no asignado (�connection refused�)• Para abortar conexiones: liberación de forma no ordenada• Cierre de conexiones �medio abiertas�• Indicar conexión cerrada ante la llegada de datos con mucho
retardo
31 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Comparativa TCP/UDPCaracterística UDP TCPComplejidad Simple ComplejoConexión Sin conexión Con conexiónTransmisión Basado en mensajes Basado en �ujoFiabilidad No �able FiableControl de �ujo No SiControl de congestión No SiVelocidad de transmisión Alta MenorTipo de aplicaciones Mensajes cortos y tiempo
realCasi todas
32 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Transferencia de datos
Uso de ventanas deslizantes (sliding windows) para la gestión deenvío y recepción
Ventana de recepción:• Bytes recibidos• Bytes no recibidos para los cuales hay espacio en el bu�er• Bytes no recibidos para los que no hay espacio en el bu�er
Ventana de transmisión• Bytes recibidos y reconocidos• Bytes recibidos y no reconocidos• Bytes no recibidos para los cuales hay espacio en el bu�er• Bytes no recibidos para los que no hay espacio en el bu�er
33 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Transferencia de datos
Uso de ventanas deslizantes (sliding windows) para la gestión deenvío y recepción
El tamaño de la ventana indica el número de bytes que se puedenenviar sin reconocer (envío) y recibir sin pasar a las capassuperiores (recepción)
Tipos de bytes en la ventana de recepción :• Bytes recibidos• Bytes no recibidos para los cuales hay espacio en el bu�er• Bytes no recibidos para los que no hay espacio en el bu�er
Tipos de bytes en la ventana de transmisión• Bytes enviados y reconocidos• Bytes enviados y no reconocidos• Bytes no enviados para los cuales hay espacio en el bu�er• Bytes no enviados para los que no hay espacio en el bu�er
34 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Ventana de envío
La ventana de recepción hace uso de 3 punteros que delimitan lostipos de bytes:• Send Unacknowledged (SND.UNA): secuencia del primer byte
enviado y no reconocido• Send Next (SND.NXT): secuencia del siguiente byte que se
enviará• Send Window (SND.WND): tamaño de la ventana de envío.
35 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Ventana de recepción
La ventana de recepción hace uso de 2 punteros que delimitan lostipos de bytes:• Receive Next (RCV.NXT): secuencia del siguiente byte que se
espera recibir• Receive Window (RCV.WND): tamaño de la ventana de recepción
36 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Gestión de punteros
A medida que se intercambian datos, los punteros de envío yrecepción se actualizan usando la información de la cabecera TCP
• Número de secuencia: identi�ca el número de secuencia del primerbyte transmitido. En muchos casos puede ser equivalente aSND.UNA
• Número de reconocimineto (ACK): indica el número de secuenciaque espera recibir en la siguiente transmisión. Típicamente, estevalor será igual al puntero RCV.NXT
• Tamaño de la ventana: el tamaño actual de la ventana derecepción que se usa como límite de la ventana de transmisión
La gestión de los punteros permite implementar:• Control de �ujo: gestiona el envío de los datos en el transmisor
para evitar congestionar al receptor• Control de congestión: gestiona el envío de datos en el transmisor
para evitar congestión en nodos intermedios
37 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Reenvío de segmentos
El reconocimiento de datos es acumulativo: mezcla de selectiverepeat y go-back-N
Al enviar cada segmento se inicia en temporizador (retransmissiontimer), si los datos del segmento no se reconocen en ese tiempo,este se reenvía
Si se alcanza un cierto número de retransmisiones se asumirá quehay un problema y se cerrará la conexión
39 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Ejemplo de reenvío
TCP Rel iabi l i ty and F low Cont ro l Features 797
Figure 49-1: TCP transaction example with retransmission This diagram illustrates a simple transaction and shows the server’s send pointers and client’s receive pointers. The server sends three segments to the client in rapid succession, setting a retransmission timer for each. Parts 1 and 2 are received, and the cli-ent sends an acknowledgment for them. Upon receipt of this ACK, Parts 1 and 2 are taken off the retrans-mission queue. However, Part 3 is lost in transit. When Part 4 is received, the client cannot acknowledge it; this would imply receipt of the missing Part 3. Eventually, the retransmission timer for Part 3 expires and it is retransmitted, at which time both Part 3 and Part 4 are acknowledged.
A final issue is what value we should use for the retransmission timer when we put a segment on the retransmission queue. If it is set too low, excessive retrans-missions occur; if set too high, performance is reduced due to extraneous delays in resending lost segments. In fact, TCP cannot use a single number for this value. It must determine the value dynamically using a process called adaptive retransmission, which we will examine later in the chapter.
TCPIP_02.book Page 797 Thursday, January 5, 2012 12:32 PM
40 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Gestión de segmentos sin reconocer
La espera de los temporizadores (Retransmittion Timeout - RTO)para el reenvío puede ser ine�ciente si se pierden varios segmentosconsecutivos
Se pueden usar implementaciones más agresivas que, de formaanticipada reenvíen desde el primer segmento no reconocido(Go-back-N)
Como mejora a RS/Go-Back-N se implementa el reconocimientoselectivo (selective ACK- SACK)• Se indica en un campo adicional (SACK) rangos de bytes
reconocidos fuera de orden• Ambos extremos de la conexión deben soportar SACK y su
utilización se indica durante la conexión en los segmentos SYN
41 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Ejemplo de reenvío con SACK
802 Chapter 49
Figure 49-3: TCP retransmission with selective acknowledgment (SACK) This is the example from Fig-ures 49-1 and 49-2, changed to use the optional selective acknowledge feature. After receiving Parts 1, 2, and 4 of the file, the client sends an acknowledgment for 1 and 2 that includes a SACK for Part 4. This tells the server not to resend Part 4 when Part 3’s timer expires.
TCPIP_02.book Page 802 Thursday, January 5, 2012 12:32 PM
42 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Cálculo del RTO
El round-trip time (RTT) puede ser muy variable, por lo que seintenta obtener un valor promediado que suavice las�uctuaciones. Inicialmente se propuso [RFC0793]:
SRTT = (αSRTT ) + (1− α)RTTsample
• α es el factor de suavizado y permite con�guraciones de TCP mássensibles a �uctuaciones. Toma valores entre 0.8 y 0.9
• Este tipo de medida se llama exponential weighted movingaverage o �ltro paso bajo
RTO = min(bupper ,max(blower , β(SRTT )))
• bupper en torno a 1 minuto, blower 1 segundo• β factor de varianza con valores recomendados entre 1.3 y 2
43 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Cálculo del RTO - Algoritmo de Jacobson
Se busca una mejor respuesta que el método de�nido en elRFC0793, que provoca retransmisiones innecesarias cuando elRTT es mayor de lo esperado.
Hace uso de la desviación media como aproximación a ladesviación estándar, pero más fácil de calcular:
SRTT = (1− g)SRTT + gRTTsample
RTTvar = (1− h)RTTvar + h(|RTTsample − SRTT |)RTO = SRTT + 4RTTvar
• Los parámetros g y h se �jan a 1/8 y 1/4 respectivamente
Este método es muy utilizado y muchas veces llamado métodoestándar
44 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Ambigüedad del cálculo del RTT
El RTT se mide como el tiempo entre el envío de un segmento yla recepción de su ACK• ¾Qué hacer cuando hay retransmisiones?
TCP dobla el valor (backo�) del RTO cada vez que este expira(expira el tiempo de reenvío de un segmento).
Algoritmo de Karn:When an acknowledgement arrives for a packet that has been sent more than once
(i.e., is retransmitted at least once), ignore any round-trip measurement based on
this packet, thus avoiding the retransmission ambiguity problem. In addition, the
backed-o� RTO for this packet is kept for the next packet. Only when it (or a
succeeding packet) is acknowledged without an intervening retransmission will the
RTO be recalculated from SRTT.
No se usan los segmentos retransmitidos para el cálculo del SRTT
45 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Control de �ujo
Se busca adecuar el envío de datos a la capacidad del receptor y asu tasa de lectura
Dado que estamos en una comunicación extremo a extremo, esposible mandar información explícita entre el receptor y eltransmisor que permita implementar el control de �ujo
Se hace uso de las ventanas deslizantes y se indica el tamaño dela ventana de recepción en la cabecera
El tamaño de ventana de recepción sirve de límite para la ventanade transmisión
Hoy en día, el control de �ujo no es un factor limitante:disponibilidad de memoria y dispositivos con alta capacidad deprocesado
46 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Síndrome de la ventana tonta (silly window
syndrome - SWS)
Se trata de una reducción ine�ciente de la ventana de recepción
Se da cuando el receptor no puede vaciar el bu�er de recepciónrápidamente (p.e. la aplicación lo lee despacio)
El resultado es el envío de segmentos cortos tan pronto como laventana libera espacio, lo cual es muy ine�ciente
Evitar SWS:• En el receptor (algoritmo de Clark): el receptor actualiza el valor
de la ventana de recepción anunciada solo si esta llega a un MSSo a la mitad del bu�er de recepción (el menor de los dos)
• En el transmisor (algoritmo de Nagle): si hay datos sin reconocer,no se envían nuevos datos hasta que se reconocen los anteriores ose puede enviar un segmento de tamaño igual a un MSS
47 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Control de congestión
Se busca adecuar el envío de datos a la capacidad de la red(nodos intermedios)
Dado que estamos en una comunicación extremo a extremo, porlo general, se debe estimar de forma indirecta la capacidad de lared y la presencia de congestión• En general se usa el round-trip time (RTT) para estimar la
congestión
El control de congestión se implementa mediante la gestióndinámica de la ventana de transmisión
Se han de�nido muchos algoritmos de control de congestión tantogenéricos como para escenarios concretos. Hoy en día sigue siendoun importante campo de estudio e investigación.
48 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Control de congestión
El transmisor estima que hay congestión por la pérdida de ACKs• Cuando hay congestión se reduce la ventana de transmisión
Cuando se con�rman segmentos se aumenta la ventana decongestión
¾Como hacer crecer y decrecer la ventana?• Additive increase/Multiplicative decrease (AIMD)
Para implementar el AIMD se usan como algoritmos básicos: SlowStart, Congestion Avoidance y Fast Recovery
49 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Slow Start
Inicialmente se asume una ventana de congestión (cwnd) deltamaño de un Maximum Segment Size (MSS)
Por cada segmento enviado con éxito la ventana se amplía en unMSS
En la práctica esto supone un crecimiento exponencial enpotencias de dos
Si la ventana de congestión supera a la de control de �ujo seaplicará esta, con lo cual la de congestión deja de crecer
Con MSS de 1 kB, en 7 iteraciones se llega a 64 kB, que es eltípico tamaño máximo de ventana
50 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Congestion Avoidance
Al detectar congestión:• Se �ja el umbral Slow Start Threshold (ssthresh) a la mitad de la
ventana cwnd siempre que sea mayor de 2 MSS ⇒ssthresh = max(cwnd/2, 2)
• Si la congestión se debe a la pérdida de un segmento, cwnd se �jaa 1 MSS
• La cwnd crece como antes hasta llegar a ssthresh, a partir de ahícrece un solo segmento cada vez
51 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Fast Retransmit
Se pueden hacer las retransmisiones no solo por expiración deltemporizador, sino por la recepción de 3 ACKs del mismosegmento
La recepción de ACKs duplicados también es indicativo decongestión
52 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Fast Recovery
Si se retransmite por 3 ACKs duplicados (Fast Retransmit), seinicia el procedimiento de Congestion Avoidance
No se usa Slow Start, puesto que los ACKs recibidos indican quelos siguientes segmentos han sido recibidos, y por lo tanto lacongestión ha cesado
En el mecanismo de Congestion Avoidance, la cwnd no se �ja a 1MSS como en el caso del Slow Start sino que se �ja a:
cwnd = ssthresh + 3MSS
Cuando se recibe el ACK del segmento retransmitido, cwnd pasaa ssthresh y se retoma el crecimiento lineal de la ventana
53 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
Congestión y errores en el canal
TCP fue diseñado para redes cableadas donde los errores en elcanal son muy poco probables
Ante la proliferación de las redes inalámbricas, los escenariosvarían• Errores en el canal asumidos como congestión ⇒ reducción de la
ventana y pérdida de e�ciencia
Aparecen mecanismos de controles de congestión más agresivos,como CUBIC o BBR
54 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
TCP: Ejercicio 1
Un cliente quiere descargarse un �chero de 6000 Bytes desde unservidor para lo cual emplea un servicio sobre TCP que funciona de lasiguiente manera:
• Para iniciar la descarga del �chero se envía el texto: �GET �ch.txt�.• Tras la descarga del �chero el servidor envía el texto �DOWNLOAD
COMPLETE� y se cierra la conexión.
Representar los segmentos TCP, indicando en cada uno de ellos las�ags activas, números de secuencia y reconocimiento, así como lalongitud del campo de datos. Se debe tener en cuenta que:
• Los dispositivos sólo transmiten segmentos al principio del tic de reloj ytardan medio tic en llegar a su destino.
• Ambos reconocerán en cuanto puedan los segmentos recibidos y cwnd es de 1MSS.
• El MSS para ambos dispositivos es 1440 bytes.• El servidor y el cliente publican ventanas de recepción de 4000 y 2700 Bytes
respectivamente.
Repetir el ejercicio asumiendo que ambos extremos implementancontrol de congestión.
55 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
TCP: Ejercicio 2
En la siguiente �gura se muestra el proceso de descarga de un �cheroen diferentes instantes de tiempo. Se pide:
• Completar los datos que faltan allí donde está indicado, donde NS indica elnúmero de secuencia y NR el número de reconocimiento.
• Completar los segmentos TCP que no se han incluido en los periodosmarcados por los recuadros punteados. Indicar tanto el tipo de segmento delque se trata, indicado por las �ags activas, como los campos de número desegmento y reconocimiento.
Se debe tener en cuenta lo siguiente:• Sólo se transmiten segmentos coincidiendo con el tic de reloj y los segmentos
tardan en llegar medio tic de reloj.• Las máquinas enviarán datos siempre que puedan y asentimientos cada vez
que reciban un segmento con datos. El MSS es de 1460 bytes y las ventanasde recepción de 65536 bytes.
• Se emplean los mecanismos de control de congestión y el la capturaúnicamente se ha perdido un segmento.
56 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
TCP: Ejercicio 3
En la �gura siguiente se muestra el proceso de descarga de un �cherodesde el servidor ftp.compania.es. Se pide completar tanto los datosque faltan, donde NS indica el número de secuencia y NR el número dereconocimiento, como los segmentos TCP no incluidos en el periodomarcado por el recuadro punteado.
Se debe tener en cuenta lo siguiente:• El �chero ocupa 7000 Bytes. Todos los datos en los segmentos de datos
enviados por el servidor corresponden con bytes del �chero.• Sólo se transmiten o re-transmiten segmentos coincidiendo con el tic de reloj
y los segmentos tardan en llegar medio tic de reloj.• Las máquinas enviarán datos siempre que puedan y enviarán asentimientos
cada vez que reciban un segmento con datos. El MSS es de 1460 bytes y lasventanas de recepción de 3920 bytes.
• El valor de RTO es de 13 tics de reloj.• Se emplean los mecanismos de Slow Start, Congestion Avoidance, Fast
Retransmit y Fast Recovery. El mecanismo de Fast Retransmit se inicia alrecibir 3 reconocimientos con mismo número de secuencia.
58 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
TCP: Ejercicio 4Se pide completar los datos que faltan allí donde está indicado, siendo NS elnúmero de secuencia y NR el de reconocimiento.
Completar los segmentos TCP que no se han incluido en los periodos marcados porlos recuadros punteados. Indicar tanto el tipo de segmento del que se trata, indicadopor las �ags activas, como los campos de número de segmento y reconocimiento.
Se debe tener en cuenta lo siguiente:• Sólo se transmiten segmentos coincidiendo con el tic de reloj y los segmentos
tardan en llegar medio tic de reloj.• Las máquinas enviarán datos siempre que puedan y asentimientos cada vez
que reciban un segmento con datos. El MSS es de 1000 bytes y las ventanasde recepción de 2500 bytes.
• Se emplean mecanismos de control de congestión y en la captura únicamentese ha perdido un segmento.
61 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
TCP: Ejercicio 450
55
60
65
Cliente Red Servidor
cwnd=10 MSS
62 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
TCP: Ejercicio 4
50
55
60
65
Cliente Red Servidor
cwnd=10 MSS
50
55
60
65
Cliente Red Servidor
cwnd=10 MSS
63 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
TCP: Ejercicio 5Se pide completar los datos que faltan allí donde está indicado e indicar lossegmentos TCP que no se han incluido en los periodos marcados por los recuadrospunteados.
Se debe tener en cuenta lo siguiente:• Sólo se transmiten segmentos coincidiendo con el tic de reloj y los segmentos
tardan en llegar medio tic de reloj.• Las máquinas enviarán datos siempre que puedan y asentimientos cada vez
que reciban un segmento con datos. El MSS es de 1000 bytes y las ventanasde recepción de su�cientemente grandes para no activar el control de �ujo.
• Se emplean los mecanismos de control de congestión asumiendo que no sesale de la fase slow-start y NO hay fast-recovery.
• Los re-envío únicamente se dan por espiración de RTO, que toma un valor de4 tics de reloj.
64 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
TCP: Ejercicio 550
55
60
Cliente Red Servidor
cwnd=1 MSS, SND_WND=0 B
cwnd=___, SND_WND=___ B
SND_WND=___ B
SND_WND=0 B
cwnd=3 MSS, SND_WND=2000 B
SND_WND=1000 B
cwnd=4 MSS, SND_WND=3000 B
Red Servidor
63
65
cwnd=___, SND_WND=___
6950
55
60
Cliente Red Servidor
cwnd=1 MSS, SND_WND=0 B
cwnd=___, SND_WND=___ B
SND_WND=___ B
SND_WND=0 B
cwnd=3 MSS, SND_WND=2000 B
SND_WND=1000 B
cwnd=4 MSS, SND_WND=3000 B
Red Servidor
63
65
cwnd=___, SND_WND=___
69
65 / 66
Redes y Servicios Telemáticos - Arquitectura TCP/IP
Luis Diez
TCP: Ejercicio 550
55
60
Cliente Red Servidor
cwnd=1 MSS, SND_WND=0 B
cwnd=2 MSS, SND_WND=2000 B
SND_WND=1000 B
SND_WND=0 B
cwnd=3 MSS, SND_WND=2000 B
SND_WND=1000 B
cwnd=4 MSS, SND_WND=3000 B
Red Servidor
cwnd=2 MSS, SND_WND=1000 B
63
65
cwnd=1 MSS, SND_WND=1000 B
cwnd=2 MSS, SND_WND=2000 B
SND_WND=0 B
cwnd=3 MSS, SND_WND=3000 B
69
cwnd=2 MSS, SND_WND=0 B
50
55
60
Cliente Red Servidor
cwnd=1 MSS, SND_WND=0 B
cwnd=2 MSS, SND_WND=2000 B
SND_WND=1000 B
SND_WND=0 B
cwnd=3 MSS, SND_WND=2000 B
SND_WND=1000 B
cwnd=4 MSS, SND_WND=3000 B
Red Servidor
cwnd=2 MSS, SND_WND=1000 B
63
65
cwnd=1 MSS, SND_WND=1000 B
cwnd=2 MSS, SND_WND=2000 B
SND_WND=0 B
cwnd=3 MSS, SND_WND=3000 B
69
cwnd=2 MSS, SND_WND=0 B
66 / 66