Redes 6-1
Tema 6
El Nivel de Transporte en Internet
Redes 6-2
Sumario
• Aspectos generales del nivel de transporte• Protocolo TCP
– Multiplexación– Conexión/Desconexión– Intercambio de datos y control de flujo– Casos de baja eficiencia en TCP– Control de congestión
• Protocolo UDP
Redes 6-3
Funciones del Nivel de Transporte• Se encarga del transporte de los datos extremo a extremo
(host a host). • Realiza la comunicación de forma transparente al medio
físico. Usa los servicios del nivel de red• Multiplexa tráfico de diversas instancias (procesos) del
nivel de aplicación• La unidad de transferencia de información a nivel de
transporte es la TPDU (Transport Protocol Data Unit)• Generalmente las aplicaciones requieren un servicio fiable,
sin pérdidas ni datos duplicados. Para ello se utiliza un servicio orientado a conexión (CONS). Ej.: TCP, TP4 (OSI)
• A otras aplicaciones les basta con un servicio no fiable, no orientado a conexión (CLNS). Ej.: UDP, TP0 (OSI)
Redes 6-4
Equivalencia Internet – OSI
Tipo de protocolo Internet OSI
Nivel de red IP (Internet Protocol) CLNP (ConnectionlessNetwork Protocol
Routing interno OSPF (Open Shortest Path First)
IS-IS (Intermediate System –Intermediate System
Routing externo BGP (BorderGateway Protocol)
IDRP (Inter Domain RoutingProtocol)
Nivel de transporte orientado a conex.
TCP (TransmissionControl Protocol)
TP4 (Transport Protocolclase 4)
Nivel de transporte no orientado a conex.
UDP (User Datagram Protocol)
TP0 (Transport Protocolclase 0)
Redes 6-5
TSAP• El TSAP (Transport Service Access Point) es el punto
donde el nivel de aplicación accede al servicio del nivel de transporte.
• Por ejemplo en Internet el TSAP se especifica por:– Dirección IP– Campo Protocolo en cabecera IP (6 para TCP, 17 para
UDP)– Puerto en la cabecera TCP/UDP
• El puerto permite multiplexar en una sola instancia del nivel de transporte múltiples instancias del nivel de aplicación
• Normalmente los servidores utilizan puertos ‘bien conocidos’
Redes 6-6
Aplicación
Transporte
Red
Enlace
Física
Host 1 Host 2
NSAP NSAP
Cliente Servidor
TSAP TSAP
TSAP y NSAP de una conexión
147.156.135.22 147.156.1.11
147.156.1.11:80 (TCP)
147.156.135.22:8000 (TCP)
Redes 6-7
Sumario
• Aspectos generales del nivel de transporte• Protocolo TCP
– Multiplexación– Conexión/Desconexión– Intercambio de datos y control de flujo– Casos de baja eficiencia en TCP– Control de congestión
• Protocolo UDP
Redes 6-8
TCP (Transmission Control Protocol)
• El protocolo TCP ofrece el servicio de transporte orientado a conexión (CONS) en Internet.
• Está diseñado para ofrecer un transporte fiable sobre un servicio no fiable del nivel de red (el que le suministra IP).
• Las TPDUs de TCP se llaman segmentos.• El TCP actual se especificó en 1981 en el RFC 793
y sigue plenamente vigente.
Redes 6-9
Servicio orientado a conexión• Los servicios orientados a conexión requieren un
procedimiento explícito de establecimiento y terminación de la comunicación.
• Durante la conexión las entidades participantes mantienen en memoria una información relativa a dicha conexión (contadores de bytes, etc.). Dicha información se conoce como información de estado.
• Para describir los servicios orientados a conexión se suele utilizar un modelo basado en dos protagonistas:– Cliente: el que inicia la conexión– Servidor: el que es invitado a conectar
• Una conexión puede terminarse tanto por iniciativa del cliente como del servidor.
Redes 6-10
Funciones de TCP
• Establecer y terminar conexiones• Gestionar los buffers y ejercer control de
flujo de forma eficiente• Multiplexar el nivel de aplicación (port) e
intercambiar datos con las aplicaciones• Controlar errores, retransmitir segmentos
perdidos o erróneos y eliminar duplicados• Efectuar control de congestión
Redes 6-11
Relleno
Flags8 bits
Reserv.4 bits
Puntero datos urgentes
Tamaño ventana
Puerto de destino
Opciones
Checksum
Lon. Cab
Número de acuse de recibo
Número de secuencia
Puerto de origen
Flags: CWR: Congestion Window ReducedECE: ECN Echo (ECN=Explicit Congestion Notification) URG: el segmento contiene datos urgentesACK: el campo número de acuse de recibo tiene sentidoPSH: el segmento contiene datos ‘Pushed’RST: ha habido algún error y la conexión debe cerrarseSYN: indica el inicio de una conexiónFIN: indica el final de una conexión
La cabecera TCP32 bits
20bytes
Redes 6-12
Dirección IP de origenDirección IP de destino
00000000 00000110 Long. Segmento TCP
La pseudocabecera TCP
32 bits
Se añade al principio del segmento para el cálculo del checksum. Permite a TCP comprobar que IP no se ha equivocado en la entrega del datagrama.
El valor 1102 = 610 indica que el protocolo de transporte es TCP
Redes 6-13
Sumario
• Aspectos generales del nivel de transporte• Protocolo TCP
– Multiplexación– Conexión/Desconexión– Intercambio de datos y control de flujo– Casos de baja eficiencia en TCP– Control de congestión
• Protocolo UDP
Redes 6-14
Multiplexación
• La multiplexación se realiza mediante el puerto (origen o destino) que puede valer de 0 a 65535.
• Los puertos 0 a 1023 están reservados para servidores ‘bien conocidos’ (‘well known ports’)
• La combinación de dirección IP y puerto identifica el ‘socket’
• Una conexión TCP queda especificada por los dos sockets que se comunican
Redes 6-15
Nivel de enlace
Nivel de red
Nivel de transporte
Nivel de aplicación
Ethertype 0800 DATAGRAMA IP CRC
Protocolo 6 SEGMENTO TCP
Puerto dest. 23 DATOS APLICACIÓN
SMTP(Puerto 25)
Telnet(Puerto 23)
FTP(Puerto 21)
Cabecera MAC Ethernet
Cabecera IP
Cabecera TCP
Multiplexación
Redes 6-16
Cliente IP 147.156.1.202
Servidor IP 147.156.1.25
Port23
Port 1038
Conexión TCPPort 1038
Cliente IP 158.42.3.47
Conexión TCP
Socket: 147.156.1.25.23
Socket: 147.156.1.202.1038
Socket: 158.42.3.47.1038
Dos conexiones TCP de clientes con diferentes direcciones IP
Redes 6-17
Cliente IP 147.156.1.202
Servidor IP 147.156.1.25
Port23
Socket: 147.156.1.25.23
Socket: 147.156.1.202.1038
Port1039
Port1038
Socket: 147.156.1.202.1039
Dos conexiones TCP de clientes con la misma IP
Redes 6-18
Netstat -anActive Internet connections (including servers)Proto Recv-Q Send-Q Local Address Foreign Address (state)tcp 0 0 147.156.1.25.2480 147.156.1.1.143 ESTABLISHEDtcp 0 0 147.156.1.25.23 147.156.96.8.1034 ESTABLISHEDtcp 0 240 147.156.1.25.23 147.156.1.219.1036 ESTABLISHEDtcp 0 0 147.156.1.25.513 147.156.1.3.1018 ESTABLISHEDtcp 0 0 147.156.1.25.513 147.156.1.3.1019 ESTABLISHEDtcp 0 0 147.156.1.25.2429 147.156.1.15.6000 ESTABLISHEDtCP 0 0 147.156.1.25.2428 147.156.1.15.6000 ESTABLISHEDtcp 0 0 147.156.1.25.1022 147.156.1.3.1002 ESTABLISHEDtcp 0 0 147.156.1.25.514 147.156.1.3.1004 CLOSE_WAITtcp 0 0 147.156.1.25.1023 147.156.1.3.1005 ESTABLISHEDtcp 0 0 147.156.1.25.514 147.156.1.3.1007 CLOSE_WAITtcp 0 0 147.156.1.25.139 147.156.1.219.1029 ESTABLISHEDtcp 0 0 *.143 *.* LISTENtcp 0 0 *.144 *.* LISTENtcp 0 0 147.156.1.25.23 147.156.3.12.1945 ESTABLISHEDtcp 0 0 *.139 *.* LISTENtcp 0 0 *.5000 *.* LISTENtcp 0 0 *.25 *.* LISTENtcp 0 0 *.19 *.* LISTENtcp 0 0 *.9 *.* LISTENudp 0 0 *.16522 *.*udp 0 0 *.16520 *.*udp 0 0 147.156.1.25.123 *.*udp 0 0 127.0.0.1.123 *.*udp 0 0 *.123 *.*
Conexiones TCP del host UNIX 147.156.1.25 (conectado por telnet desde 147.156.1.219)
Redes 6-19
Sumario
• Aspectos generales del nivel de transporte• Protocolo TCP
– Multiplexación– Conexión/Desconexión– Intercambio de datos y control de flujo– Casos de baja eficiencia en TCP– Control de congestión
• Protocolo UDP
Redes 6-20
Primitivas básicas de conexión/desconexión
Cliente Servidor
Connect(bloqueado)
ReceiveSend
(bloqueado)
Receive...Disconnect
(libera conexión)
Listen (bloqueado)
ReceiveSend
(bloqueado)
ReceiveSend
(bloqueado)...
ReceiveDisconnect
(libera conexión)Listen
(bloqueado)
Petición conexión
Conexión
aceptada
Datos
Datos
Petición desconexión
Petición
desconexión
Redes 6-21
INACTIVO
PENDIENTE CONEXIÓN
PASIVA
PENDIENTE CONEXIÓN
ACTIVA
CONEXIÓN ESTABLECIDA
INACTIVO
PENDIENTE DESCONEXIÓN
PASIVA
PENDIENTE DESCONEXIÓN
ACTIVA
SERVIDORCLIENTE
Primitiva Connectejecutada
TPDU de conexión recibida
Primitiva Connectejecutada
TPDU de conexión recibida
TPDU de desconexión
recibida
Primitiva Disconnectejecutada
Primitiva Disconnectejecutada
TPDU de desconexión recibida
Evolución de estados en una conexión/desconexión
Redes 6-22
Conexión por ‘Saludo a tres vías’• En TCP pueden llegar segmentos duplicados (ej. Se pierde la
confirmación de un segmento con lo que el emisor lo reenvía)• Con un procedimiento de conexión simple los segmentos
duplicados podrían causar problemas, como que una sesión entera se duplique.
• Para evitarlo se utiliza el saludo a tres vías, un procedimiento de conexión más elaborado que evita los problemas debidos a duplicados
• Para ello se identifica cada intento de conexión mediante un número diferente. El cliente elige un número a modo de clave para la comunicación en sentido de ida y el servidor otro para el sentido de vuelta.
• Estos dos números actúan como PINs que identifican cada intento de conexión y lo protegen de segmentos retrasados que pudieran aparecer fruto de conexiones anteriores.
Redes 6-23
Procedimiento del saludo a tres vías1. El cliente elige para cada intento de conexión un
número único. El número elegido lo incluye en la petición de conexión que envía al servidor.
2. El servidor, cuando recibe la petición, elige otro número único y envía una respuesta al cliente indicándoselo.
3. El cliente al recibir la respuesta considera establecida la conexión. A continuación envía un tercer mensaje en el que acusa recibo del anterior. El servidor considera establecida la conexión cuando el recibe este tercer mensaje.
Redes 6-24
TCP A TCP B
←Ti
empo
seq=100, SYN
seq=300, ack=101, SYN, ACK
seq=101, ack=301, ACK
Establecimiento de una conexión TCP por saludo a tres vías
CLOSED
SYN-SENT(ISN 100)
LISTEN
SYN-RECEIVED
(ISN 300)
ESTABLISHED
ESTABLISHED
Redes 6-25
TCP A TCP B
←Ti
empo
seq=100, SYN
seq=300,ack=101,
SYN, ACKseq=100, ack=301,SYN,ACK
Conexión saludo a tres vías, conexión simultánea
CLOSED
SYN-SENT(ISN 100)
CLOSED
SYN-RECEIVED
ESTABLISHED ESTABLISHED
seq=300, SYN SYN-SENT(ISN 300)
SYN-RECEIVED
Redes 6-26
TCP A TCP B←
Tiem
po
seq=100, SYN
seq=300, ack=91, SYN, ACK
seq=91, RST
Conexión con SYN duplicado
CLOSED
SYN-SENT(ISN 100)
LISTEN
SYN-RECEIVED(ISN 300)
LISTEN
seq=90, SYN
seq=100, SYNSYN-RECEIVED(ISN 400)
seq=400, ack=101, SYN, ACK
ESTABLISHED seq=101, ack=401, ACKESTABLISHED
SYN90
SYN-SENT(ISN 90)
seq=90, SYN
(timeout)
SYN90
SYN100
SYN100
Redes 6-27
Conexión en TCP• Los dos primeros segmentos de la conexión se identifican
con el flag SYN.• El número de secuencia es un campo de 32 bits que cuenta
bytes en módulo 232 (el contador se da la vuelta cuando llega al valor máximo).
• El número de secuencia no empieza normalmente en 0, sino en un valor denominado ISN (Initial SequenceNumber) elegido al azar; el ISN sirve de ‘PIN’ en el saludo a tres vías para asegurar la autenticidad de la comunicación.
• Una vez establecida la comunicación el ‘seq’ y el ‘ack’sirven para contar los bytes transmitidos y recibidos.
Redes 6-28
Conexión en TCP• El ISN es elegido por el sistema (cliente o servidor). El
estándar sugiere utilizar un contador entero incrementado en 1 cada 4 µs aproximadamente. En este caso el contador se da la vuelta (y el ISN reaparece) al cabo de 4 horas 46 min.
• El MSL (Maximum Segment Lifetime) típico es de unos 2 minutos, con lo que la probabilidad de que dos ISN coincidan es despreciable.
• El mecanismo de selección de los ISN es suficientemente fiable para proteger de coincidencias debidas al azar, pero no es un mecanismo de protección frente a sabotajes. Es muy fácil averiguar el ISN de una conexión e interceptarla suplantando a alguno de los dos participantes.
Redes 6-29
Desconexión
• Puede ser de dos tipos:– Simétrica: la conexión se considera formada por dos
circuitos simplex y cada host solo puede cortar uno (aquel en el que él emite datos). El cierre de un sentido se interpreta como una ‘invitación’ a cerrar el otro.
– Asimétrica: desconexión unilateral (un host la termina en ambos sentidos sin esperar a recibir confirmación del otro). Puede provocar pérdida de información.
Redes 6-30
Host 1 Host 2←
Tiem
po
DATOS
DATOS
DATOS
DR: Disconnect Request
Desconexión asimétrica
ConectadoConectado
NoConectado
NoConectado
DR
Datos perdidos
Redes 6-31
Mensaje de Desconexión
• EL mensaje solicitando la desconexión se puede perder. Por eso se pide una confirmación (ACK).
• Pero la confirmación también podría perderse, por lo que habría que enviar una reconfirmacion, y así sucesivamente.
• Este problema no tiene solución infalible, pues estamos usando un canal no fiable para asegurar un envío de información. Es lo que se conoce como el problema de los dos ejércitos.
Redes 6-32
El problema de los dos ejércitos
Redes 6-33
Desconexión por saludo a tres vías
• Se trata de una desconexión simétrica en la que se tiene una seguridad razonable de que no se pierden datos.
• Supone el intercambio de tres mensajes, de forma análoga a la conexión, de ahí su nombre.
• En caso de que alguno de los mensajes de desconexión se pierda una vez iniciado el proceso la conexión se termina por timeout.
Redes 6-34
Desconexión en TCP
• Se utiliza el ‘saludo a tres vías’ invitando a la otra parte a cerrar.
• Para indicar el cierre se utiliza el flag FIN• La desconexión puede inciarla el cliente o el
servidor.• Una vez efectuada la desconexión el host que
inició el proceso está un cierto tiempo a la espera por si aparecen segmentos retrasados
Redes 6-35
TCP A TCP B
seq = 100, ack=300, FIN, ACK
seq=300, ack=101 ACK
seq=101, ack=301, ACK
Desconexión a tres vías, caso normal
ESTABLISHED
FIN-WAIT-1
ESTABLISHED
CLOSE-WAIT
FIN-WAIT-2LAST-ACKseq=300, ack=101, FIN, ACK
TIME-WAIT
CLOSED
CLOSED
2MSL
MSL: Maximum Segment Lifetime (normalmente 2 minutos)
Redes 6-36
Libera conexión
Envía ACK
Host 1
(Timeout)libera
conexión
Host 2
FIN
FIN
ACK
Host 1
Libera conexión
Host 2FIN
FIN
ACK
FIN
FINEnvía FIN y
arranca timer
(Timeout)envía FIN y
arranca timer
Envía FIN y arranca timer
Envía FIN y arranca timer
Envía FIN y arranca timer
Envía FIN y arranca timer
Libera conexión
Envía ACK
Host 1 Host 2
FIN(timeout)envía FIN y
arranca timer
Envía FIN y arranca timer
(N timeouts)Libera
conexión Conectado
Pérdida de ACK final Pérdida de respuesta FIN
Pérdida de todos los FIN de host 1
Otras formas de terminar una conexión TCP
FINHost 1 Host 2
FIN
FIN
FIN(timeout)envía FIN y
arranca timer
Envía FIN y arranca timer
Envía FIN y arranca timer
(N timeouts)Libera
conexión
(Timeout)libera
conexión
Pérdida de todo menos primer FIN
Conectado
Redes 6-37
Redes 6-38
Números de secuencia y flags• El número de secuencia es el que corresponde al primer
byte enviado en ese segmento. • TCP incrementa el número de secuencia de cada segmento
según los bytes que tenía el segmento anterior, con una sola excepción:Los flags SYN y FIN, cuando están puestos, incrementan
en 1 el número de secuencia. • Esto permite que se pueda acusar recibo de un segmento
SYN o FIN sin ambigüedad.• Podemos considerar que los segmentos que tienen puesto
el flag SYN o FIN lleva un byte de datos ‘virtual’• La presencia del flag ACK no incrementa el número de
secuencia
Redes 6-39
Sumario
• Aspectos generales del nivel de transporte• Protocolo TCP
– Multiplexación– Conexión/Desconexión– Intercambio de datos y control de flujo– Casos de baja eficiencia en TCP– Control de congestión
• Protocolo UDP
Redes 6-40
Intercambio de datos TCP ↔ aplicación• Aplicación → TCP: la aplicación envía los datos a TCP
cuando quiere (siempre y cuando TCP tenga espacio libre en el buffer de emisión)
• TCP → Aplicación: la aplicación lee del buffer de recepción de TCP cuando quiere y cuanto quiere. Excepción: datos urgentes
• Para TCP los datos de la aplicación son un flujo continuode bytes, independientemente de la separación que pueda tener la aplicación (registros, etc.). Es responsabilidad de la aplicación asegurarse que esa separación (si existe) se mantendrá después de transmitir los datos.
Redes 6-41
Intercambio de datos TCP ↔ TCP• El TCP emisor manda los datos cuando quiere. Excepción:
datos ‘Pushed’• El TCP emisor decide el tamaño de segmento según sus
preferencias. Al inicio de la conexión se negocia el MSS (Maximum Segment Size)
• Cada segmento ha de viajar en un datagrama• Normalmente TCP intenta agrupar los datos para que los
segmentos tengan la longitud máxima, reduciendo así eloverhead debido a cabeceras y proceso de segmentos.
• El TCP emisor puede aplicar la técnica de descubrimiento de la MTU del trayecto (‘Path MTU Discovery’, MTU =Maximum Transfer Unit) para ajustar el MSS al tamaño óptimo para esa comunicación.
Redes 6-42
Aplicaciónorigen
TCPreceptor
TCPemisor
Aplicacióndestino
A criterio de la aplicación(sujeto a disponibilidad de buffer en TCP emisor)
A criterio dela aplicación
A criterio del TCP emisor(sujeto a disponibilidadde buffer en TCP receptory no congestión de la red)
Empuja
Empuja
Estira
Buffer Buffer
Intercambio de datos TCP ↔ Aplicación y TCP ↔ TCP
Redes 6-43
Aplicaciónorigen
TCPreceptor
TCPemisor
Aplicacióndestino
Buffer Buffer
Intercambio de datos TCP ↔ Aplicación y TCP ↔ TCP
Escribe
Envía
Lee2048 Bytes1024 Bytes
1024 Bytes
512 B 512 B512 B 512 B
(MSS 512 Bytes)
Redes 6-44
Gestión de buffers y Control de Flujo
• El TCP receptor informa en cada segmento al emisor del espacio que le queda libre en el buffer para esa comunicación. Para ello usa el campo tamaño de ventana.
• Anunciando una ventana cero el receptor puede bloquear al emisor, y ejercer así control de flujo.
• La ventana anunciada es un espacio que el TCP receptor reserva para esa comunicación en su buffer.
• Tanto los números de secuencia como los tamaños de ventana cuentan bytes.
Redes 6-45
Emisor Receptor
Gestión de buffers y Control de flujo
EmisorBloqueado
Buffer
La aplicaciónescribe 2 KB Seq = 0
Seq = 2048
Seq = 4096
Ack = 2048, Win = 2048
Ack = 4096, Win = 0
Ack = 4096, Win = 2048
La aplicaciónescribe 3 KB
El emisorpuede enviar
hasta 2 KB
Vacío
Lleno
2 KB
2 KB
0 4K
La aplicaciónlee 2 KB
3 KB
2 KB
2 KB
1 K
Redes 6-46
Gestión de buffers y Control de Flujo
• El TCP receptor nunca debería retirar el espacio en buffer que ya ha anunciado al emisor.
• Sin embargo TCP debe estar preparado por si el del otro lado lo hace (esto se denomina ‘contraer la ventana’).
Recordemos la norma básica de Internet:
‘Sé estricto al enviar y tolerante al recibir’
Redes 6-47
Reenvío de segmentos
• En caso de pérdida de un paquete en la red el segmento TCP no llegará a su destino
• Cada TCP cuando envía un segmento espera recibir el ACK; si este no llega dentro de un tiempo razonable reenvía el segmento.
• Si se enviaron varios segmentos y se pierde uno se puede hacer dos cosas:– Enviar solo ese segmento (repetición selectiva)– Enviar todos los segmentos a partir de ese (retroceso n)
• Lo normal es utilizar retroceso n
Redes 6-48
Host 1 Host 2Seq=1000, Win=4000
Seq=1500, Ack=1001, Win=4000
Control de flujo y números de secuenciaCaso normal, sin pédidas
Seq=1001, Ack=1501, Win=40001000 bytes
Seq=1501, Ack=2001, Win=3000 1000 bytes
Seq=2001, Ack=2501, Win=3000Seq=3001, Ack=2501, Win=3000
Seq=4001, Ack=2501, Win=3000
1000 bytes
1000 bytes
1000 bytes
BloqueadoSeq=2501, Ack=5001, Win=2000
Seq=5001, Ack=2501, Win=3000
Seq=2501, Ack=6001, Win=30001000 bytes
Seq=2501, Ack=5001, Win=0Aplicación lee2000 bytes
SYN
SYN
Redes 6-49
Host 1 Host 2Seq=1000, Win=4000
Seq=1500, Ack=1001, Win=4000
Pérdida de un paqueteRetransmisión con retroceso n
Seq=1001, Ack=1501, Win=40001000 bytes
Seq=1501, Ack=2001, Win=30001000 bytes
Seq=2001, Ack=2501, Win=3000Seq=3001, Ack=2501, Win=3000
Seq=4001, Ack=2501, Win=3000
1000 bytes
1000 bytes
1000 bytes
Bloqueado
Seq=2501, Ack=5001, Win=2000
Seq=5001, Ack=2501, Win=3000
Seq=2501, Ack=6001, Win=3000
1000 bytes
Seq=2501, Ack=3001, Win=2000
Seq=3001, Ack=2501, Win=3000
Timeout
Seq=4001, Ack=2501, Win=3000
Ignorado
Aplicación lee2000 bytes
Timeout
SYN
SYN
1000 bytes
1000 bytesSeq=2501, Ack=5001, Win=0
Redes 6-50
Host 1 Host 2Seq=1000, Win=4000
Seq=1500, Ack=1001, Win=4000
Seq=1001, Ack=1501, Win=40001000 bytes
Seq=1501, Ack=2001, Win=30001000 bytes
Seq=2001, Ack=2501, Win=3000Seq=3001, Ack=2501, Win=3000
Seq=4001, Ack=2501, Win=3000
1000 bytes
1000 bytes
1000 bytes
Bloqueado
Seq=2501, Ack=5001, Win=2000
Seq=5001, Ack=2501, Win=3000
Seq=2501, Ack=6001, Win=30001000 bytes
Seq=2501, Ack=3001, Win=2000Seq=3001, Ack=2501, Win=3000
Timeout
1000 bytesAplicación lee2000 bytes
SYN
SYN
Pérdida de un paqueteRetransmisión con repetición selectiva
Seq=2501, Ack=5001, Win=0
Redes 6-51
Intercambio de datos: casos excepcionales
• Datos ‘Pushed’ (bit PSH)– La aplicación pide al TCP emisor que envíe esos datos
lo antes posible. El TCP receptor los pondrá a disposición de la aplicación de inmediato, para cuando ésta le pida datos. Ejemplo: telnet.
• Datos Urgentes (bit URG y Urgent Offset)– Los datos se quieren entregar a la aplicación remota sin
esperar a que esta los pida. Ejemplo: abortar un programa con CTRL-C en una sesión telnet
Redes 6-52
Timer de Persistencia
• Mientras la ventana está cerrada el TCP emisor puede enviar de vez en cuando un segmento con un byte de datos; esto provoca el envío de un ACK por parte del receptor y evita el bloqueo que se podría producir en caso de pérdida de un segmento anunciando una ventana mayor que cero
• La frecuencia con que el TCP emisor envía los reintentos se fija en el ‘Timer de Persistencia’.
Redes 6-53
TCP A TCP B←
Tiem
po
(seq=401)(ack=601)(ctl=ACK)(W=0)
(seq=601)(ack=401)(ctl=ACK)(datos)
Timer de persistencia
(seq=501)(ack=401)(ctl=ACK)(datos)
Timer de Persistencia
100 bytes(501-600)
Buffer lleno
(seq=401)(ack=601)(ctl=ACK)(W=400) Datos leídos por la aplicación
Datos puestos en buffer para la aplicación
(seq=401)(ack=602)(ctl=ACK)(W=(399)
1 byte(601)
Bloqueado
Redes 6-54
Mensaje y timer de keepalive
• Evita que se queden conexiones ‘medio abiertas’• Se implementa reenviando el último byte transmitido en un
segmento; el receptor descarta el dato pero devuelve un ACK
• Si se envían varios mensajes de keepalive sin respuesta se considera que se trata de una conexión medio abierta y se cierra.
• Para declarar una conexión medio abierta se espera a veces hasta 2 horas.
• El tiempo de envío de los mensajes se regula con el timerde keepalive.
• El keepalive no requiere modificaciones en el TCP receptor
Redes 6-55
TCP Servidor TCP Cliente←
Tiem
po
(seq=401)(ack=601)(ctl=ACK)
(seq=600)(ack=401)(ctl=ACK)(datos)
Mensajes de keepalive
(seq=501)(ack=401)(ctl=ACK)(datos)
TimerKeepalive
(seq=401)(ack=601)(ctl=ACK)
100 bytes(501-600)
1 byte(600)
Datos puestos en buffer para la aplicación
Datos duplicados descartados
Redes 6-56
1. SYNTCP: --- TCP header ---TCP:TCP: Source port = 2345TCP: Dest port = 23 (Telnet)TCP: Initial seq. Number = 16421121
TCP: Data offset = 24 bytesTCP: Flags = 02 (SYN)TCP: Window = 2048TCP: Checksum = F2DA (correct)TCP:TCP: Options followTCP: Max segment size = 1460
2. SYNTCP: --- TCP header --TCP:TCP: Source port = 23 (Telnet)TCP: Dest port = 2345TCP: Initial seq. Number = 390272001TCP: Acknowledgment Number = 16421122TCP: Data offset = 24 bytesTCP: Flags = 12 (ACK,SYN)TCP: Window = 4096TCP: Checksum = C13A (correct)TCP:TCP: Options followTCP: Max segment size = 1024
3. ACKTCP: --- TCP header ---TCP:TCP: Source port = 2345TCP: Dest port = 23 (Telnet)TCP: Seq. Number = 16421122TCP: Acknowledgment Number =
390272002TCP: Data offset = 20 bytesTCP: Flags = 10 (ACK)TCP: Window = 2048TCP: Checksum = DF43 (correct)TCP: No TCP options
4. DATATCP: --- TCP header ---TCP:TCP: Source port = 23 (Telnet)TCP: Dest port = 2345TCP: Seq. Number = 390272002TCP: Acknowledgment Number = 16421122TCP: Data offset = 20 bytesTCP: Flags = 18 (ACK,PSH)TCP: Window = 4096TCP: Checksum = 9FEF (correct)TCP: No TCP optionsTCP: [12 byte(s) of data]
Cabeceras TCP del inicio de una conexión Telnet
Redes 6-57
Cliente Servidor
SEQ=16421121, SYN
SEQ=390272001, ACK=16421122, SYN
El servidor envía la secuencia:
UNIXLogin:
TCP Conectado
Intercambio de segmentos del caso anterior
SEQ=16421122, ACK=390272002
SEQ=390272002, ACK=16421122
TCP Conectado
Redes 6-58
Cliente Servidor
SEQ=92, ACK=109, Datos =C
SEQ=109, ACK=93, Datos =C
El servidor telnet procesa el mensaje
y devuelve una ‘C’; como la respuesta llega con rapidez en el mismo
segmento se envían los datos de vuelta y el ACK El TCP envía
un ACK del segmento recibido
SEQ=93, ACK=110
Funcionamiento de TCP en Telnet con eco remotocuando el host responde rápidamente a los mensajes
El usuario teclea una ‘C’
Redes 6-59
Cliente Servidor
El usuario teclea una ‘C’
SEQ=92, ACK=109, Datos =C
SEQ=109, ACK=93
Cuando el servidortelnet ha procesado el mensaje devuelveotro segmento con
el carácter ‘C’
El TCP envía un ACK del
segmento recibidoSEQ=93, ACK=110
Funcionamiento de TCP en Telnet con eco remotocuando el host responde con lentitud a los mensajes
El TCP receptor, al ver que no se produce
respuesta en un tiemporazonable, genera un
mensaje de ACK
SEQ=109, ACK=93, Datos=C
Redes 6-60
Sumario
• Aspectos generales del nivel de transporte• Protocolo TCP
– Multiplexación– Conexión/Desconexión– Intercambio de datos y control de flujo– Casos de baja eficiencia en TCP– Control de congestión
• Protocolo UDP
Redes 6-61
Baja eficiencia en TCP• El funcionamiento eficiente de TCP aconseja
enviar segmentos del tamaño máximo permitido• Cuando la aplicación emisora genera los datos en
pequeñas dosis (telnet con eco remoto por ejemplo) se da un problema de eficiencia que se resuelve con el algoritmo de Nagle.
• Si la aplicación receptora los recoge byte a bytetambién se puede dar una baja eficiencia; esto se conoce como síndrome de la ventana tonta y se resuelve con la Solución de Clark.
Redes 6-62
Algoritmo de NagleCuando la aplicación envía datos en pequeños grupos TCP
envía el primero y retiene los demás hasta recibir el ACK; por cada ACK recibido envía un segmento con los bytes que hubiera pendientes, y así sucesivamente.También se envía un segmento cuando los datos
acumulados igualan o superan el MSS (tamaño máximo de un segmento), o la mitad de la ventana.El mecanismo es autoadaptativo, pues cuanto más cargada
esté la red mas tardarán los ACK y mas agrupados irán los datos•Se puede aplicar a datos pushed en caso necesario
Redes 6-63
Síndrome de la ventana tonta
1. La aplicación que envía datos los genera rápidamente2. La aplicación receptora los recupera lentamente, un byte
cada vez3. El buffer del TCP receptor se llena4. El TCP receptor notifica al emisor que su ventana está
cerrada 5. La aplicación receptora lee un byte6. EL TCP receptor envía un ACK al emisor para
anunciarle que dispone de un byte libre7. El TCP emisor envía un segmento con un byte de datos8. Volvemos al punto 3
Redes 6-64
La aplicación lee un byte
Buffer receptor lleno
Un byte libre
Buffer receptor lleno
Cabecera IP-TCPSe envía segmento deactualización de ventana
Cabecera IP-TCP Se recibe segmentocon un byte de datos
1 Byte
Síndrome de la ventana tonta
40 Bytes
40 Bytes
Redes 6-65
Solución de Clark (RFC 813)
• El TCP receptor solo debe notificar una nueva ventana cuando tenga una cantidad razonable de espacio libre. Razonable significa:– Un MSS (segmento del tamaño máximo), o– La mitad del espacio disponible en el buffer
Redes 6-66
Sumario
• Aspectos generales del nivel de transporte• Protocolo TCP
– Multiplexación– Conexión/Desconexión– Intercambio de datos y control de flujo– Casos de baja eficiencia en TCP– Control de congestión
• Protocolo UDP
Redes 6-67
Control de congestión
• Por medio del tamaño de ventana el receptor puede dosificar al emisor en función del buffer disponible. Esto es control de flujo.
• Pero puede que el receptor tenga espacio de sobra pero la red esté congestionada. En este caso el TCP debe regularse para no inyectar demasiado tráfico, a pesar de que la ventana disponible sea muy grande. Esto es control de congestión.
• Normalmente en TCP se utiliza control de congestión implícito. Ahora se está empezando a experimentar en Internet con el control de congestión explícito.
Redes 6-68
Control de flujo Control de congestión
Redes 6-69
Control de congestión en TCP
• Cuando hay congestión TCP ha de reducir el flujo• El mecanismo para detectarla es implícito, por la pérdida de
segmentos. Cuando ocurre TCP baja el ritmo.• Se presupone que la red es altamente fiable a nivel físico y que
las pérdidas se deben a congestión únicamente. Cuando no es así (redes con errores) bajar el ritmo es contraproducente.
• Además de la ventana de control de flujo (dictada por el receptor y transmitida en la cabecera TCP) el emisor tiene una ventana de control de congestión, que ajusta a partir de los segmentos perdidos. En cada momento se usa la más pequeña de ambas.
• El mecanismo de control de congestión de TCP se denomina slow-start (arranque lento) y fue diseñado por Van Jacobson en los años 80.
Redes 6-70
Slow Start (primera fase)
• Inicialmente la ventana de congestión tiene el tamaño de un MSS (Maximum Segment Size)
• Por cada segmento enviado con éxito la ventana se amplía en un MSS
• En la práctica esto supone un crecimiento exponencial (en potencias de dos)
• Si la ventana de congestión supera a la de control de flujo se aplica ésta con lo cual aquella deja de crecer
Redes 6-71
ACK 2
Emisor Receptor
SEG 1
ACK 1
SEG 2
ACK 3
SEG 4ACK 4
Con MSS = 1KB en 7 iteraciones se llega a 64 KB,
tamaño máximo de la ventana
Ventana
1 MSS
4 MSS
2 MSS
SEG 8ACK 8
8 MSS
SEG 3
SEG 5SEG 6
SEG 7ACK 5
ACK 6ACK 7
SEG 9SEG 10
SEG 11SEG 12
SEG 13SEG 14
SEG 15
ACK 9ACK 10
ACK 11ACK 12
ACK 13ACK 14
ACK 15
Funcionamiento de slow start, fase 1
Redes 6-72
Slow start (segunda fase)
• Cuando se pierde un segmento:– La ventana de congestión vuelve a su valor
inicial– Se fija un ‘umbral de peligro’ en un valor igual
a la mitad de la ventana que había cuando se produjo la pérdida.
– La ventana de congestión crece como antes hasta el umbral de peligro; a partir de ahí crece en sólo un segmento cada vez
Redes 6-73
Emisor Receptor
SEG 15 ACK 15
Ventana
1 MSS
SEG 162 MSS ACK 16
SEG 184 MSS ACK 18
SEG 22 ACK 22
SEG 27 ACK 27
5 MSS
6 MSS
ACK del segmento 15
perdido y retransmitidoSEG 17 ACK 17
SEG 19SEG 20
SEG 21
ACK 19ACK 20
ACK 21
SEG 23SEG 24
SEG 25SEG 26
ACK 23ACK 24
ACK 25ACK 26
SEG 28SEG 29
SEG 30SEG 31
SEG 32
ACK 28ACK 29
ACK 30ACK 31
ACK 32
Funcionamiento de slow start, fase 2
Redes 6-74
4
8
12
16
20
24
28
32
36
40
44
00 2 4 6 8 10 12 14 16 18 20 22 24
Un segmento perdido (40 KB)
Umbral (32 KB)
Umbral (20 KB)
Número del envío
Vent
ana
de c
onge
stió
n (K
iloB
ytes
)Evolución de la ventana de congestión
Redes 6-75
Timer de retransmisión
• Debe ser adecuado para la comunicación:– Si es excesivo se esperará innecesariamente– Si es muy corto se harán reenvíos innecesarios
• Como la fluctuación es muy grande se utilizan mecanismos autoadaptativos. A partir de los ACK se mide el tiempo de ida y vuelta o Round Trip Time (RTT)
• La estimación de este timer es crucial para el correcto funcionamiento del ‘slow-start’.
Redes 6-76
Timer de retransmisión
• El valor medio de RTT (MRTT) se calcula por la fórmula:MRTTn = α MRTTn-1 + (1 - α) RTTdonde: RTT: Valor más reciente medido de RTT
α: Factor de amortiguación. Normalmente 7/8• Para deducir el timeout a partir de MRTT tenemos que
tener una idea de la dispersión de los valores. Para eso calculamos la desviación estándar como:Dn = β Dn-1 + (1 - β) | MRTTn-1 – RTT|donde β suele valer 3/4.
• El timeout se calcula normalmente como MRTT + 4*D
Redes 6-77
Dispersión del timer de retransmisión
Redes 6-78
Redes 6-79
N MRTTn-1 RTTn MRTTn Dn-1 Dn Timeout
494
459,25
515.83
456.92
451.27
505.36
459,36
467,18
434,81
412,45
419,16
424,49
426,36
453,14
64
54,5
65,56
51,07
51,21
61,86
49,92
50,27
41,68
36,78
37,25
37,40
39,27
44,13
64
54,5
65,56
51,07
51,21
61,86
49,92
50,27
41,68
36,78
37,25
37,40
39,27
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
230 230,00
230,00 294 238,00
238,00 264 241,25
241,25 340 253,59
253,59 246 252,64
252,64 201 246,19
246,19 340 257,92
257,92 272 259,68
259,68 311 266,10
266,10 282 268,09
268,09 246 265,33
265,33 304 270,16
270,16 308 274,89
274,89 230 269,28
269,28 328 276,62
Evolución de MRTT, D y timeout de retransmisión en función del valor de RTT
Redes 6-80
Netstat -p tcptcp:978740 packets sent949215 data packets (1306073886 bytes)544 data packets (329353 bytes) retransmitted10186 ack-only packets (8786 delayed)0 URG only packets188 window probe packets17669 window update packets938 control packets
432947 packets received251266 acks (for 863756680 bytes)1294 duplicate acks0 acks for unsent data76150 packets (68148251 bytes) received in-sequence)174 completely duplicated packets (57347 bytes)15 packets with some dup. data (34 bytes duped)341 out-of-order packets (4224 bytes)23 packets (0 bytes) of data after window0 window probes23158 window update packets1 packet received after close0 discarded for bad checksums0 discarded for bad header offset fields0 discarded because packet too short
397 connection requests414 connection accepts629 connections established (including accepts)848 connections closed (including 38 drops)179 embryonic connections dropped313267 segments updated rtt (of 314002 attempts)347 retransmit timeouts2 connections dropped by rexmit timeout
190 persist timeouts54 keepalive timeouts53 keepalive probes sent1 connection dropped by keepalive
Redes 6-81
Opciones y extensiones de TCP
• Intercambio de valores de MSS entre los dos comunicantes. Es la más habitual
• Otras opciones son:– Factor de escala, para ventanas de hasta 1 GB
(RFC 1323). Mejora la eficiencia en redes ‘LFN’ (Long, Fat pipe Network) con elevado valor de BW*RTT
– Repetición selectiva y acuse de recibo negativo (NAK) (RFC 1106). También especialmente útil en LFNs.
• Se suelen negociar en el segmento de inicio de la conexión (el que lleva el bit SYN
Redes 6-82
Sumario
• Aspectos generales del nivel de transporte• Protocolo TCP
– Multiplexación– Conexión/Desconexión– Intercambio de datos y control de flujo– Casos de baja eficiencia en TCP– Control de congestión
• Protocolo UDP
Redes 6-83
Protocolo UDP
• Servicio sencillo, CLNS, no fiable• Se utiliza en los siguientes entornos:
– El intercambio de mensajes es muy escaso, ej.:consultas al DNS (servidor de nombres)
– La aplicación es en tiempo real y no puede esperar los ACKs. Ej.: videoconferencia, voz sobre IP.
– Los mensajes se producen regularmente y no importa si se pierde alguno. Ej: NTP, SNMP
– El medio de transmisión es altamente fiable y sin congestion (LANs). Ej: NFS
– Se envía tráfico broadcast/multicast
Redes 6-84
Protocolo UDP
• Las TPDUs de UDP se denominan mensajes odatagramas UDP
• UDP multiplexa los datos de las aplicaciones y efectúa opcionalmente una comprobación de errores, pero no realiza:– Control de flujo– Control de congestión– Retransmisión de datos perdidos– Conexión/desconexión
Redes 6-85
Puerto de origen Puerto de destinoLongitud datagrama UDP Checksum
La cabecera de UDP con la pseudocabecera
32 bits
Dirección IP de origenDirección IP de destino
00000000 00010001 Long. Datagrama UDPPseudocabecera
Cabecera
La pseudocabecera se añade al principio del datagrama para el cálculo del checksum. Permite a UDP comprobar que IP no se ha equivocado en la entrega del datagrama.
El valor 100012 = 1710 indica que el protocolo de transporte es UDP
Redes 6-86
IP: ----- IP Header -----IP:IP: Version=4, header length=20 bytesIP: DiffServ = 00 IP: Total length = 131 bytesIP: Identification = 21066IP: DF = 0, MF = 0IP: Fragment offset = 0 bytesIP: Time to live = 60 seconds/hopsIP: Protocol = 17 (UDP)IP: Header checksum = 2A13 (correct)IP: Source address = [128.1.1.1]IP: Destination address = [128.1.1.10]IP: No optionsIP:UDP: ----- UDP Header -----UDP:UDP: Source Port = 1227 (SNMP)UDP: Destination port = 161UDP: Length = 111UDP: No checksumUDP:
IP: ----- IP Header -----IP:IP: Version=4, header length=20 bytesIP: DiffServ = 00 IP: Total length = 160 bytesIP: Identification = 2015IP: DF = 0, MF = 0IP: Fragment offset = 0 bytesIP: Time to live = 64 seconds/hopsIP: Protocol = 17 (UDP)IP: Header checksum = 7061 (correct)IP: Source address = [128.1.1.10]IP: Destination address = [128.1.1.1]IP: No optionsIP:UDP: ----- UDP Header -----UDP:UDP: Source Port = 161 (SNMP)UDP: Destination port = 1227UDP: Length = 140UDP: Checksum = 4D4F (correct)UDP:
Cabeceras IP y UDP en una petición/respuesta SNMP
Redes 6-87
Función TCP UDPTransporte Sí SíMultiplexación Sí SíDetección de errores Sí Opcional(*)
Corrección de errores Sí NoControl de flujo Sí NoControl de congestión Sí NoEstablecimiento/ terminación de conexión
Sí No
(*) Obligatorio en IPv6
Comparación Protocolos de transporte de Internet
Redes 6-88
Ejercicios
Redes 6-89
Ejercicio 4
P: El tamaño máximo de un segmento TCP es 65.515 bytes. ¿Podría explicar de donde viene ese valor?
R: La longitud máxima de un datagrama se especifica en un campo de 16 bits, por lo que es 65535 bytes. De estos al menos 20bytes son la cabecera IP, con lo que quedan 65515 bytes para el segmento TCP.
Redes 6-90
Ejercicio 6
• ¿Debe TCP preocuparse de reordenar los fragmentos de un datagrama?
• NO. El nivel IP reconstruye el datagrama original en orden antes de entregar el segmento a TCP; para ello usa los campos identificación, fragmentoffset y MF. TCP no puede reordenar los fragmentos puesto que normalmente solo el primero tiene cabecera TCP.
Redes 6-91
Internet
Se quiere poner en el router una regla que impida el establecimiento de conexiones TCP desde fuera
Red interna
Ejercicio 7
Router filtro
Redes 6-92
Ejercicio 7
Solución:Filtrar los datagramas que entren por la interfaz serie y que cumplan simultáneamente:– Tener el valor 6 en el campo protocolo
(TCP)– Tener a 1 el bit SYN y a 0 el ACK en la
cabecera TCP.
Redes 6-93
Ejercicio 8
• Aplicación genera mensaje de 1540 bytes. • MTU del trayecto: 800 bytes• Indique cuantos datagramas y bytes recibe
el nivel de red en el host de destino
Redes 6-94
IP Datos
Ejercicio 8: solución• Aplicación: 1540 bytes• TCP: 1540 + 20 = 1560• IP: 1560 + 20 = 1580• MTU = 800 bytes
IP TCP Datos
IP Datos
20 20
20
20
776
8
756
Múltiplo de 8 bytes
Redes 6-95
Ejercicio 9
P: Sesión TCP con 100 Mb/s de BW y 20 msde RTT. Calcular caudal máximo aprovechable.
R: De la fórmula: Ventana = BW * RTT obtenemos BW = Ventana / RTT
Sustituyendo:BW = 65535*8 / 0,02 = 26,2 Mb/s
Redes 6-96
Ejercicio 9Cálculo detallado (con segmentos de 1 Kbyte por ejemplo):0 ms TCP emisor empieza a enviar 1er segmento0,08 ms TCP emisor empieza a enviar 2º segmento0,16 ms TCP emisor empieza a enviar 3er segmento... ...5,16 ms TCP emisor empieza a enviar segmento 645,24 ms TCP emisor queda a la espera10 ms TCP receptor empieza a recibir 1er segmento10,08 ms TCP receptor devuelve primer ACK20,08 ms TCP emisor recibe primer ACK y empieza a
transmitir segmento 65
Eficiencia: 5,24/20,08 = 0,261 = 26,1 Mb/s
Redes 6-97
Ejercicio 12
• Una conexión TCP sobre medio físico poco fiable pierde una trama de cada 10. El nivel de enlace (PPP) descarta las tramas erróneas sin pedir reenvío. Preguntas:– Como evolucionará la ventana de congestión en el TCP
emisor (retransmisión selectiva)– Que merma cualitativa cabe esperar por la tasa de error:
• Menor del 10%• Alrededor del 10%• Mayor del 10%
– Como influiría el RTT en el rendimiento
Redes 6-98
Ventana cong. (KB) Trama Segmento Umbral peligro (KB)1 1 1
2,34,5,6,7
8,9,10,11,12,13,14,1510
16,1718,19,20,21
1 23 19 22 24,25 22,23 23 26,27,28 24,25,26 24 29,30,31,32 27,28,29,30 21 33 28 22 34,35 31,32 23 36,37,38 33,34,35 24 39,40,41,42 36,37,38,39 21 43 37 22 44,45 40,41 23 46,47,48 42,43,44 24 49,50,51,52 45,46,47,48 21 53 46 22 54,55 49,50 2
642 2,3 644 4,5,6,7 648 8,9,10,11,12,13,14,15 641 16 42 17,18 44 19,20,21,22 4
Evolución de la ventana de congestión de TCP
Redes 6-99
Descartar¿Trama long. entera ≥ 64 ≤ 1518?
Trama recibida
¿CRC correcto?
NoSíDescartarNo
Sí¿MAC destino reconocida? Descartar
NoSí
¿Checksum IP correcto? DescartarNoSí
Tarjeta de red
Driver Tarjeta
Proceso IP
Proceso TCP/UDP
Depositar contenido en buffer para proceso en puerto destino y devolver ACK (TCP)
¿IP destino reconocida? DescartarNoSí
¿Checksum TCP/UDP correcto? DescartarNoSí
¿Puerto destino reconocido? Descartar y
devolver ICMPdestino inacc.
NoSí
¿Datos duplicados (TCP)? Descartar ydevolver ACK
SíNo
Tarjetared
CPU
¿Protocolo reconocido? No
Sí Descartar ydevolver ICMPdestino inacc.
Proceso de una trama Ethernet TCP/IP recibida por un host
Redes 6-100
Internet
Broadcast en IP
147.156.1.2/24
147.156.1.3/24
147.156.1.200/24
………
147.156.255.2/24
ping 147.156.1.255
A recibe 199ICMP echo reply
ping 147.156.1.255
B recibe un ICMPecho reply (de X)
147.156.1.1/24
no ip directed-broadcast
ping 147.156.255.255
A
B
D
D recibe un ICMP echo reply (de X)
X
Y
147.156.2.2/24
C
ping 147.156.1.255
C recibe un ICMPecho reply (de X)
ping 147.156.2.255
D recibe un ICMP echo reply (de Y)
Top Related