Tema 5
El Nivel de Transporte en
Internet
Rogelio Montañana
Departamento de Informática
Universidad de Valencia
[email protected]
http://www.uv.es/~montanan/
Universidad de Valencia
Redes 5-1
Rogelio Montañana
Sumario
• Aspectos generales del nivel de transporte
• Protocolo UDP
• 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
Redes LFN, factor de escala y opciones de TCP
Universidad de Valencia
Redes 5-2
Rogelio Montañana
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. El nivel de transporte (como el de red)
tiene una sola instancia en el host
• El servicio que ofrece puede ser de dos tipos:
– Orientado a conexión: garantiza la entrega de los datos, sin pérdidas
ni duplicados. Ej.: TCP (Internet), TP4 (OSI)
– No orientado a conexión: equivale al servicio que ofrece IP,pero a
nivel de transporte. Ej.: UDP (Internet), TP0 (OSI)
Universidad de Valencia
Redes 5-3
Rogelio Montañana
Sumario
• Aspectos generales del nivel de transporte
• Protocolo UDP
• 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
Redes LFN, factor de escala y opciones de TCP
Universidad de Valencia
Redes 5-4
Rogelio Montañana
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
confirmaciones. 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
congestión (LANs). Ej: NFS
– Se envía tráfico broadcast/multicast
Universidad de Valencia
Redes 5-5
Rogelio Montañana
Protocolo UDP
• Las TPDUs de UDP se denominan mensajes o
datagramas 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
Universidad de Valencia
Redes 5-6
Rogelio Montañana
La cabecera UDP
32 bits
Dirección IP de origen
Dirección IP de destino
Pseudocabecera
00000000
Cabecera
0001000132 bits
Long. Datagrama UDP
Puerto de origen
Puerto de destino
Longitud datagrama UDP
Checksum
La pseudocabecera se añade al principio del datagrama para el cálculo del
checksum, pero no se envía. Permite a UDP comprobar que IP no se ha
equivocado (ni le ha engañado) en la entrega del datagrama.
El valor 100012 = 1710 indica que el protocolo de transporte es UDP
Universidad de Valencia
Redes 5-7
Rogelio Montañana
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 una dirección IP y un puerto
identifica un ‘socket’ (origen o destino de los
datagramas UDP): 147.156.135.22.1038
Dirección IP
Puerto
Socket
Universidad de Valencia
Redes 5-8
Rogelio Montañana
Multiplexación
Nivel de aplicación
Múltiples instancias
(una o varias por
protocolo)
Daytime
DNS
NTP
(Puerto 13)
(Puerto 53)
(Puerto 123)
Nivel de transporte
Dos instancias
(TCP y UDP)
P. dest. 13
Cabecera UDP
Checksum
Checksum
Nivel de red
Una instancia IP
(puede haber otros
protocolos)
DATOS APLICACIÓN
Prot. 17
DATAGRAMA UDP
Cabecera IP
Nivel de enlace
Múltiples instancias
(una por interfaz)
Ethertype 0800
Cabecera MAC Ethernet
Universidad de Valencia
Redes 5-9
DATAGRAMA IP
CRC
CRC
Rogelio Montañana
Conexión UDP de un cliente contra un
servidor
Mensaje UDP
p.o. 1038, p.d. 13
Port
13
Port
1038
Mensaje UDP
p.o. 13, p.d. 1038
Servidor Daytime
IP 10.0.1.25
Cliente
IP 10.0.1.50
Socket: 10.0.1.50.1038
Socket: 10.0.1.25.13
Universidad de Valencia
Redes 5-10
Rogelio Montañana
Cabeceras IP y UDP en una petición/respuesta SNMP
IP: ----- IP Header ----IP:
IP: Version=4, header length=20 bytes
IP: DiffServ = 00
IP: Total length = 131 bytes
IP: Identification = 21066
IP: DF = 0, MF = 0
IP: Fragment offset = 0 bytes
IP: Time to live = 60 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header checksum = 2A13 (correct)
IP: Source address = [128.1.1.1]
IP: Destination address = [128.1.1.10]
IP: No options
IP:
UDP: ----- UDP Header ----UDP:
UDP: Source Port = 1227
UDP: Destination port = 161 (SNMP)
UDP: Length = 111
UDP: No checksum
UDP:
Universidad de Valencia
Redes 5-11
IP: ----- IP Header ----IP:
IP: Version=4, header length=20 bytes
IP: DiffServ = 00
IP: Total length = 160 bytes
IP: Identification = 2015
IP: DF = 0, MF = 0
IP: Fragment offset = 0 bytes
IP: Time to live = 64 seconds/hops
IP: Protocol = 17 (UDP)
IP: Header checksum = 7061 (correct)
IP: Source address = [128.1.1.10]
IP: Destination address = [128.1.1.1]
IP: No options
IP:
UDP: ----- UDP Header ----UDP:
UDP: Source Port = 161 (SNMP)
UDP: Destination port = 1227
UDP: Length = 140
UDP: Checksum = 4D4F (correct)
UDP:
Rogelio Montañana
Sumario
• Aspectos generales del nivel de transporte
• Protocolo UDP
• 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
Redes LFN, factor de escala y opciones de TCP
Universidad de Valencia
Redes 5-12
Rogelio Montañana
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 el RFC 793 en 1981
y sigue plenamente vigente.
Universidad de Valencia
Redes 5-13
Rogelio Montañana
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, espacio libre en buffers, 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 está a la espera de recibir peticiones de conexión
• Una conexión puede terminarse tanto por iniciativa del
cliente como del servidor.
• También hay aplicaciones que utilizan el modelo igual a
igual (peer-to-peer) como Emule, Edonkey, etc.
Universidad de Valencia
Redes 5-14
Rogelio Montañana
Funciones de TCP
• Multiplexar el nivel de aplicación (port)
• Controlar errores, retransmitiendo segmentos
perdidos o erróneos. Eliminar duplicados
• Establecer y terminar conexiones
• Gestionar los buffers y ejercer control de flujo de
forma eficiente
• Gestionar el intercambio de datos con las
aplicaciones
• Efectuar control de congestión
Universidad de Valencia
Redes 5-15
Rogelio Montañana
La cabecera TCP
32 bits
Puerto de origen
Puerto de destino
Número de secuencia
20
bytes
Número de acuse de recibo
L. Cab. Resv.
(4 bits) (4 bits)
Flags
(8 bits)
Checksum
Tamaño ventana
Puntero datos urgentes
Opciones
Flags:
Universidad de Valencia
CWR:
ECE:
URG:
ACK:
PSH:
RST:
SYN:
FIN:
Relleno
Congestion Window Reduced
ECN Echo (ECN=Explicit Congestion Notification)
el segmento contiene datos urgentes
el campo número de acuse de recibo tiene sentido
el segmento contiene datos ‘Pushed’
ha habido algún error y la conexión debe cerrarse
indica el inicio de una conexión
indica el final de una conexión
Redes 5-16
Rogelio Montañana
La pseudocabecera TCP
32 bits
Dirección IP de origen
Dirección IP de destino
00000000
00000110
Long. Segmento TCP
Se añade al principio del segmento solo para el cálculo del
Checksum, no se envía. Permite a TCP comprobar que IP no se
ha equivocado (ni le ha engañado) en la entrega del segmento.
El valor 1102 = 610 indica que el protocolo de transporte es TCP
Universidad de Valencia
Redes 5-17
Rogelio Montañana
Sumario
• Aspectos generales del nivel de transporte
• Protocolo UDP
• 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
Redes LFN, factor de escala y opciones de TCP
Universidad de Valencia
Redes 5-18
Rogelio Montañana
Multiplexación
• Se utiliza el número de puerto (origen o destino)
como en UDP. Puede valer de 0 a 65535.
• Como en UDP los puertos 0 a 1023 están
reservados para servidores ‘bien conocidos’
• Como en UDP 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 (IP origen-puerto
origen, IP destino-puerto destino)
Universidad de Valencia
Redes 5-19
Rogelio Montañana
Algunos servicios ‘bien conocidos’
Universidad de Valencia
Servicio
Puerto
TCP
UDP
DayTime
13
X
X
FTP
21
X
SSH
22
X
TelNet
23
X
SMTP
25
X
Domain (DNS)
53
X
BOOTP
67
X
TFTP
69
X
HTTP
80
X
POP3
110
X
NTP
123
X
SNMP
161
X
LDAP
389
X
HTTPS
443
X
Redes 5-20
X
Rogelio Montañana
Multiplexación
Nivel de aplicación
Múltiples instancias
(una o varias por
protocolo)
FTP
HTTP
HTTP
(Puerto 21)
(Puerto 80)
(Puerto 400)
Nivel de transporte
Dos instancias
(TCP y UDP)
Telnet
SMTP
(Puerto 23)
(Puerto 25)
Checksum
P. dest. (23)
DATOS APLICACIÓN
Cabecera TCP
Una instancia IP
(puede haber otros
protocolos)
Checksum
Nivel de red
Prot. (6)
SEGMENTO TCP
Cabecera IP
Nivel de enlace
Múltiples instancias
(una por interfaz)
Ethertype (0800)
DATAGRAMA IP
CRC
Cabecera MAC Ethernet
Universidad de Valencia
Redes 5-21
Rogelio Montañana
Dos conexiones TCP a un mismo socket desde
dos sockets con el mismo número de puerto
Este socket tiene dos
conexiones simultáneas
Port
1038
Cliente
IP 10.0.1.50
Port
23
Socket: 10.0.1.50.1038
Servidor telnet
IP 10.0.1.25
Port
1038
Socket: 10.0.1.25.23
Cliente
IP 10.0.2.47
Socket: 10.0.2.47.1038
Universidad de Valencia
Redes 5-22
Rogelio Montañana
Dos conexiones TCP a un mismo socket desde
dos sockets con la misma dirección IP
Socket: 10.0.1.80.1038
Port
1038
Port
23
Servidor
IP 10.0.1.25
Port
1039
Cliente
IP 10.0.1.80
Socket: 10.0.1.25.23
Socket: 10.0.1.80.1039
Universidad de Valencia
Redes 5-23
Rogelio Montañana
Conexiones TCP del host UNIX 147.156.1.25 (conectado por telnet desde 147.156.1.219)
Netstat -an
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address
Foreign Address
tcp
0
0 147.156.1.25.2480
147.156.1.1.143
tcp
0
0 147.156.1.25.23
147.156.96.8.1034
tcp
0
240 147.156.1.25.23
147.156.1.219.1036
tcp
0
0 147.156.1.25.513
147.156.1.3.1018
tcp
0
0 147.156.1.25.513
147.156.1.3.1019
tcp
0
0 147.156.1.25.2429
147.156.1.15.6000
tCP
0
0 147.156.1.25.2428
147.156.1.15.6000
tcp
0
0 147.156.1.25.1022
147.156.1.3.1002
tcp
0
0 147.156.1.25.514
147.156.1.3.1004
tcp
0
0 147.156.1.25.1023
147.156.1.3.1005
tcp
0
0 147.156.1.25.514
147.156.1.3.1007
tcp
0
0 147.156.1.25.139
147.156.1.219.1029
tcp
0
0 *.143
*.*
tcp
0
0 *.144
*.*
tcp
0
0 147.156.1.25.23
147.156.3.12.1945
tcp
0
0 *.139
*.*
tcp
0
0 *.5000
*.*
tcp
0
0 *.25
*.*
tcp
0
0 *.19
*.*
tcp
0
0 *.9
*.*
udp
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
*.*
Universidad de Valencia
Redes 5-24
(state)
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
CLOSE_WAIT
ESTABLISHED
CLOSE_WAIT
ESTABLISHED
LISTEN
LISTEN
ESTABLISHED
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
Rogelio Montañana
Sumario
• Aspectos generales del nivel de transporte
• Protocolo UDP
• 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
Redes LFN, factor de escala y opciones de TCP
Universidad de Valencia
Redes 5-25
Rogelio Montañana
Conexión por ‘Saludo a tres vías’
• Los segmentos pueden llegar duplicados (p. 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. Una sesión entera
podría duplicarse.
• Para evitar los problemas debidos a duplicados lo se utiliza
un procedimiento de conexión más elaborado denominado
saludo a tres vías.
• El saludo a tres vías se basa en la elección de un número
que identifica de forma única cada intento de conexión y
que actúa como PIN. De este modo se evita el riesgo de
aceptar como válidos segmentos retrasados que pudieran
aparecer fruto de conexiones anteriores.
Universidad de Valencia
Redes 5-26
Rogelio Montañana
Procedimiento del saludo a tres vías
1. 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.
Universidad de Valencia
Redes 5-27
Rogelio Montañana
Establecimiento de una conexión
TCP por saludo a tres vías
TCP A
TCP B
CLOSED
LISTEN
SYN-SENT
(ISN 100)
SYN-RECEIVED
 Tiempo
(ISN 300)
ESTABLISHED
Universidad de Valencia
ESTABLISHED
Redes 5-28
Rogelio Montañana
Saludo a tres vías, conexión simultánea
 Tiempo
TCP A
TCP B
CLOSED
CLOSED
SYN-SENT
SYN-SENT
(ISN 100)
(ISN 300)
SYN-RECEIVED
SYN-RECEIVED
ESTABLISHED
ESTABLISHED
Universidad de Valencia
Redes 5-29
Rogelio Montañana
Conexión con SYN duplicado
TCP A
TCP B
SYN-SENT
SYN
90
(ISN 90)
LISTEN
(timeout)
CLOSED
SYN-SENT
SYN
100
 Tiempo
(ISN 100)
SYN
90
SYN-RECEIVED
(ISN 300)
LISTEN
SYN
100
SYN-RECEIVED
(ISN 400)
ESTABLISHED
ESTABLISHED
Universidad de Valencia
Redes 5-30
Rogelio Montañana
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 Sequence
Number) 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.
Universidad de Valencia
Redes 5-31
Rogelio Montañana
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.
Universidad de Valencia
Redes 5-32
Rogelio Montañana
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.
Universidad de Valencia
Redes 5-33
Rogelio Montañana
Desconexión asimétrica
Host 1
Host 2
 Tiempo
Conectado
Conectado
Datos perdidos
No
Conectado
DR:
Universidad de Valencia
No
Conectado
Disconnect Request
Redes 5-34
Rogelio Montañana
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.
Universidad de Valencia
Redes 5-35
Rogelio Montañana
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.
Universidad de Valencia
Redes 5-36
Rogelio Montañana
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 iniciarla cualquiera de los
dos TCP (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
Universidad de Valencia
Redes 5-37
Rogelio Montañana
Desconexión a tres vías, caso normal
TCP A
TCP B
ESTABLISHED
ESTABLISHED
FIN-WAIT-1
CLOSE-WAIT
FIN-WAIT-2
LAST-ACK
TIME-WAIT
2
MSL
CLOSED
CLOSED
MSL: Maximum Segment Lifetime (normalmente 2 minutos)
Universidad de Valencia
Redes 5-38
Rogelio Montañana
Desconexión a tres vías, casos anormales
Host 1
Envía FIN y
arranca timer
Libera
conexión
Host 2
Envía FIN y
arranca timer
Envía ACK
(Timeout)
libera
conexión
Host 1
Host 2
Envía FIN y
arranca timer
Envía FIN y
arranca timer
(Timeout)
envía FIN y
arranca timer
Envía FIN y
arranca timer
Libera
conexión
Envía ACK
Pérdida de ACK final
Libera
conexión
Pérdida de respuesta FIN
Host 1
Host 2
Host 1
Host 2
Envía FIN y
arranca timer
Envía FIN y
arranca timer
Envía FIN y
arranca timer
Conectado
(timeout)
envía FIN y
arranca timer
(N timeouts)
Libera
conexión
(timeout)
envía FIN y
arranca timer
(Timeout)
libera
conexión
(N timeouts)
Libera
conexión
Pérdida de todo menos primer FIN
Universidad de Valencia
Redes 5-39
Conectado
Pérdida de todos los FIN de host 1
Rogelio Montañana
Universidad de Valencia
Redes 5-40
Rogelio Montañana
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
Universidad de Valencia
Redes 5-41
Rogelio Montañana
Sumario
• Aspectos generales del nivel de transporte
• Protocolo UDP
• 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
Redes LFN, factor de escala y opciones de TCP
Universidad de Valencia
Redes 5-42
Rogelio Montañana
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 continuo
de 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.
Universidad de Valencia
Redes 5-43
Rogelio Montañana
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í el
overhead 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.
Universidad de Valencia
Redes 5-44
Rogelio Montañana
Intercambio de datos
TCP  Aplicación y TCP  TCP
Aplicación
origen
Empuja
A criterio de la aplicación
(sujeto a disponibilidad
de buffer en TCP emisor)
TCP
emisor
Universidad de Valencia
Aplicación
destino
Buffer
Empuja
A criterio del TCP emisor
(sujeto a disponibilidad
de buffer en TCP receptor
y no congestión de la red)
Redes 5-45
Estira
A criterio de
la aplicación
Buffer
TCP
receptor
Rogelio Montañana
Intercambio de datos
TCP  Aplicación y TCP  TCP
Aplicación
origen
Aplicación
destino
1024 Bytes
Escribe
TCP
emisor
Lee
2048 Bytes
Buffer
1024 Bytes
Buffer
Envía
512 B
512 B
512 B
512 B
TCP
receptor
(MSS 512 Bytes)
Universidad de Valencia
Redes 5-46
Rogelio Montañana
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.
Universidad de Valencia
Redes 5-47
Rogelio Montañana
Gestión de buffers y Control de flujo
Emisor
Buffer
Receptor
0
La aplicación
escribe 2 KB
4K
Vacío
2 KB
La aplicación
escribe 3 KB
Lleno
Emisor
Bloqueado
La aplicación
lee 2 KB
2 KB
El emisor
puede enviar
hasta 2 KB
3 KB
Universidad de Valencia
Redes 5-48
Rogelio Montañana
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 Ley de Postel):
‘Sé estricto al enviar y tolerante al recibir’
Universidad de Valencia
Redes 5-49
Rogelio Montañana
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
Universidad de Valencia
Redes 5-50
Rogelio Montañana
Control de flujo y números de secuencia
Caso normal, sin pédidas
Host 1
SYN
Host 2
Seq=1000, Win=4000
Seq=1500, Ack=1001, Win=4000
1000 bytes
Seq=1001, Ack=1501, Win=4000
Seq=1501, Ack=2001, Win=3000
1000 bytes
Seq=2001, Ack=2501, Win=3000
1000 bytes
Seq=3001, Ack=2501, Win=3000
1000 bytes
Seq=4001, Ack=2501, Win=3000
Seq=2501, Ack=5001, Win=0
Bloqueado
Seq=2501, Ack=5001, Win=2000
1000 bytes
SYN
1000 bytes
Aplicación lee
2000 bytes
Seq=5001, Ack=2501, Win=3000
Seq=2501, Ack=6001, Win=3000
Universidad de Valencia
Redes 5-51
Rogelio Montañana
Pérdida de un paquete
Retransmisión con retroceso n
Host 1
Host 2
Seq=1000, Win=4000
SYN
Seq=1500, Ack=1001, Win=4000
1000 bytes
Seq=1001, Ack=1501, Win=4000
Seq=1501, Ack=2001, Win=3000
Timeout
Timeout
1000 bytes
Seq=2001, Ack=2501, Win=3000
1000 bytes
Seq=3001, Ack=2501, Win=3000
1000 bytes
Seq=4001, Ack=2501, Win=3000
Bloqueado
Seq=2501, Ack=3001, Win=2000
1000 bytes
1000 bytes
1000 bytes
Ignorado
Seq=3001, Ack=2501, Win=3000
Seq=4001, Ack=2501, Win=3000
Seq=2501, Ack=5001, Win=0
Seq=2501, Ack=5001, Win=2000
1000 bytes
SYN
Aplicación lee
2000 bytes
Seq=5001, Ack=2501, Win=3000
Seq=2501, Ack=6001, Win=3000
Universidad de Valencia
Redes 5-52
Rogelio Montañana
Pérdida de un paquete
Retransmisión con repetición selectiva
Host 1
SYN
Host 2
Seq=1000, Win=4000
Seq=1500, Ack=1001, Win=4000
1000 bytes
Seq=1001, Ack=1501, Win=4000
Seq=1501, Ack=2001, Win=3000
Timeout
1000 bytes
Seq=2001, Ack=2501, Win=3000
1000 bytes
Seq=3001, Ack=2501, Win=3000
1000 bytes
Bloqueado
1000 bytes
Seq=4001, Ack=2501,
Seq=2501, Ack=3001,
Seq=3001, Ack=2501,
Seq=2501, Ack=5001,
Win=3000
Win=1000
Win=3000
Win=0
Seq=2501, Ack=5001, Win=2000
1000 bytes
SYN
1000 bytes
Aplicación lee
2000 bytes
Seq=5001, Ack=2501, Win=3000
Seq=2501, Ack=6001, Win=3000
Universidad de Valencia
Redes 5-53
Rogelio Montañana
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
Universidad de Valencia
Redes 5-54
Rogelio Montañana
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’.
Universidad de Valencia
Redes 5-55
Rogelio Montañana
Timer de persistencia
 Tiempo
TCP A
TCP B
100 bytes
(501-600)
Buffer lleno
Datos leídos por
la aplicación
Timer de
Persistencia
Bloqueado
1 byte
(601)
Universidad de Valencia
Datos puestos
en buffer para la
aplicación
Redes 5-56
Rogelio Montañana
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 timer
de keepalive.
• El keepalive no requiere modificaciones en el TCP
receptor
Universidad de Valencia
Redes 5-57
Rogelio Montañana
Mensajes de keepalive
 Tiempo
TCP Servidor
TCP Cliente
100 bytes
(501-600)
Datos puestos
en buffer para la
aplicación
Timer
Keepalive
1 byte
(600)
Universidad de Valencia
Datos duplicados
descartados
Redes 5-58
Rogelio Montañana
Cabeceras TCP del inicio de una conexión Telnet
1. SYN
TCP: --- TCP header --TCP:
TCP: Source port = 2345
TCP: Dest port = 23 (Telnet)
TCP: Initial seq. Number = 16421121
TCP:
TCP:
TCP:
TCP:
TCP:
TCP:
TCP:
Data offset = 24 bytes
Flags = 02 (SYN)
Window = 2048
Checksum = F2DA (correct)
Options follow
Max segment size = 1460
3. ACK
TCP: --- TCP header --TCP:
TCP: Source port = 2345
TCP: Dest port = 23 (Telnet)
TCP: Seq. Number = 16421122
TCP: Acknowledgment Number =
390272002
TCP: Data offset = 20 bytes
TCP: Flags = 10 (ACK)
TCP: Window = 2048
TCP: Checksum = DF43 (correct)
TCP: No TCP options
Universidad de Valencia
2. SYN
TCP: --- TCP header -TCP:
TCP: Source port = 23 (Telnet)
TCP: Dest port = 2345
TCP: Initial seq. Number = 390272001
TCP: Acknowledgment Number = 16421122
TCP: Data offset = 24 bytes
TCP: Flags = 12 (ACK,SYN)
TCP: Window = 4096
TCP: Checksum = C13A (correct)
TCP:
TCP: Options follow
TCP: Max segment size = 1024
4. DATA
TCP: --- TCP header --TCP:
TCP: Source port = 23 (Telnet)
TCP: Dest port = 2345
TCP: Seq. Number = 390272002
TCP: Acknowledgment Number = 16421122
TCP: Data offset = 20 bytes
TCP: Flags = 18 (ACK,PSH)
TCP: Window = 4096
TCP: Checksum = 9FEF (correct)
TCP: No TCP options
TCP: [12 byte(s) of data]
Redes 5-59
Rogelio Montañana
Intercambio de segmentos del caso anterior
Cliente
Servidor
TCP Conectado
TCP Conectado
El servidor envía la
secuencia:
UNIX
Login:
Universidad de Valencia
Redes 5-60
Rogelio Montañana
Cliente
Servidor
El usuario
teclea una ‘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
Funcionamiento de TCP en Telnet con eco remoto
cuando el host responde rápidamente a los mensajes
Universidad de Valencia
Redes 5-61
Rogelio Montañana
Cliente
Servidor
El TCP receptor, al ver
que no se produce
respuesta en un tiempo
razonable, genera un
mensaje de ACK
El usuario
teclea una ‘C’
Cuando el servidor
telnet ha procesado
el mensaje devuelve
otro segmento con
el carácter ‘C’
El TCP envía
un ACK del
segmento recibido
Funcionamiento de TCP en Telnet con eco remoto
cuando el host responde con lentitud a los mensajes
Universidad de Valencia
Redes 5-62
Rogelio Montañana
Sumario
• Aspectos generales del nivel de transporte
• Protocolo UDP
• 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
Redes LFN, factor de escala y opciones de TCP
Universidad de Valencia
Redes 5-63
Rogelio Montañana
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 byte
tambié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.
Universidad de Valencia
Redes 5-64
Rogelio Montañana
Algoritmo de Nagle
Cuando 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
Universidad de Valencia
Redes 5-65
Rogelio Montañana
Síndrome de la ventana tonta
1.
2.
3.
4.
5.
6.
7.
8.
La aplicación que envía datos los genera rápidamente
La aplicación receptora los recupera lentamente, un byte
cada vez
El buffer del TCP receptor se llena
El TCP receptor notifica al emisor que su ventana está
cerrada
La aplicación receptora lee un byte
EL TCP receptor envía un ACK al emisor para anunciarle
que dispone de un byte libre
El TCP emisor envía un segmento con un byte de datos
Volvemos al punto 3
Universidad de Valencia
Redes 5-66
Rogelio Montañana
Síndrome de la ventana tonta
Buffer receptor lleno
La aplicación lee un byte
Un byte libre
Cabecera IP-TCP
Se envía segmento de
actualización de ventana
40 Bytes
Se recibe segmento
con un byte de datos
Cabecera IP-TCP
40 Bytes
1 Byte
Universidad de Valencia
Buffer receptor lleno
Redes 5-67
Rogelio Montañana
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
Universidad de Valencia
Redes 5-68
Rogelio Montañana
Sumario
• Aspectos generales del nivel de transporte
• Protocolo UDP
• 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
Redes LFN, factor de escala y opciones de TCP
Universidad de Valencia
Redes 5-69
Rogelio Montañana
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.
Universidad de Valencia
Redes 5-70
Rogelio Montañana
Control de flujo
Universidad de Valencia
Control de congestión
Redes 5-71
Rogelio Montañana
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.
Universidad de Valencia
Redes 5-72
Rogelio Montañana
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
Universidad de Valencia
Redes 5-73
Rogelio Montañana
Funcionamiento de slow start, fase 1
Ventana
Emisor
1 MSS
SEG 1
Receptor
ACK 1
2 MSS
4 MSS
8 MSS
Universidad de Valencia
SEG 2
SEG 3
ACK 2
ACK 3
SEG 4
SEG 5
SEG 6
SEG 7
Con MSS = 1KB en
7 iteraciones se
llega a 64 KB,
tamaño máximo de
la ventana
ACK 4
ACK 5
ACK 6
ACK 7
SEG 8
SEG 9
SEG 10
SEG 11
SEG 12
SEG 13
SEG 14
SEG 15
Redes 5-74
ACK 8
ACK 9
ACK 10
ACK 11
ACK 12
ACK 13
ACK 14
ACK 15
Rogelio Montañana
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
Universidad de Valencia
Redes 5-75
Rogelio Montañana
Funcionamiento de slow start, fase 2
Ventana
Emisor
Receptor
1 MSS
SEG 15
ACK 15
2 MSS
SEG 16
SEG 17
ACK 16
ACK 17
4 MSS
SEG 18
SEG 19
SEG 20
SEG 21
ACK 18
ACK 19
ACK 20
ACK 21
5 MSS
SEG 22
SEG 23
SEG 24
SEG 25
SEG 26
ACK 22
ACK 23
ACK 24
ACK 25
ACK 26
SEG 27
SEG 28
SEG 29
SEG 30
SEG 31
SEG 32
Universidad de Valencia
Redes 5-76
6 MSS
ACK del
segmento 15
perdido y
retransmitido
ACK 27
ACK 28
ACK 29
ACK 30
ACK 31
ACK 32
Rogelio Montañana
Evolución de la ventana de congestión
44
Un segmento perdido (40 KB)
Ventana de congestión (KiloBytes)
40
36
Umbral (32 KB)
32
28
24
Umbral (20 KB)
20
16
12
8
4
0
0
2
4
6
8
10
12
14
16
18
20
22
24
Número del envío
Universidad de Valencia
Redes 5-77
Rogelio Montañana
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’.
Universidad de Valencia
Redes 5-78
Rogelio Montañana
Timer de retransmisión
• El valor medio de RTT (MRTT) se calcula por la fórmula:
MRTTn =  MRTTn-1 + (1 - ) RTT
donde:
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
Universidad de Valencia
Redes 5-79
Rogelio Montañana
Sumario
• Aspectos generales del nivel de transporte
• Protocolo UDP
• 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
Redes LFN, factor de escala y opciones de TCP
Universidad de Valencia
Redes 5-80
Rogelio Montañana
Redes LFN ¿Qué son?
• Las redes LFN (Long, Fat pipe Networks)
son las que tienen un elevado ancho de
banda y un elevado RTT (retardo). El
producto de ambos da una idea comparativa
de dichas redes. Ej.:
– Enlace vía satélite de 2 Mb/s y retardo 500 ms:
BW*RTT = 1 Mb
– Enlace por fibra de larga distancia de 1 Gb/s y
RTT = 40 ms: BW*RTT = 40 Mb
Universidad de Valencia
Redes 5-81
Rogelio Montañana
Problema de TCP con las redes LFN
• La ventana de TCP es un campo de 16 bits.
Su valor máximo es 65535, y cuenta bytes.
• En TCP no es posible enviar más de 65535
bytes seguidos sin haber recibido un ACK
• En una red LFN con BW*RTT > 64 Kbytes
el rendimiento se puede ver limitado por
este motivo. La limitación es tanto mayor
cuanto mayor es el BW*RTT de la red
Universidad de Valencia
Redes 5-82
Rogelio Montañana
Funcionamiento de TCP en redes LFN
TCP A
(emisor)
Enlace vía satélite con BW 2 Mb/s y RTT 500 ms
TCP B
(receptor)
0 ms: TCP A empieza a enviar datos a 2 Mb/s
262 ms: TCP A ha enviado 64 KB y tiene que parar
500 ms: TCP A empieza a recibir los ACK y transmite los siguientes 64 KB
762 ms: TCP A ha enviado el segundo grupo de 64 KB y tiene que parar
1000 ms: TCP A empieza a recibir los ACK del segundo grupo y transmite
1262 ms: TCP A tiene que parar
…
Eficiencia: 262/500 = 52,4 % = 1,048 Mb/s (64 KB/ RTT)
Universidad de Valencia
Redes 5-83
Rogelio Montañana
Solución al problema de TCP con las
redes LFN
• Es preciso tener ventanas mayores que 64 KB. Pero el
campo es de 16 bytes y no se puede ampliar
• La solución es aplicar un factor de escala al tamaño de
ventana. Así los bytes no se cuentan de uno en uno sino de
dos en dos, de cuatro en cuatro, etc. Siempre se agrupan en
potencias de dos (equivale a añadir ceros por la derecha al
tamaño de ventana)
• Para poder utilizar el factor de escala lo han de soportar los
dos TCP que establecen la conexión; lo acuerdan al
principio de esta y lo mantienen durante toda la conexión
Universidad de Valencia
Redes 5-84
Rogelio Montañana
Ejemplo de uso del factor de escala
• El IFIC (Instituto de Física Corpuscular) en
Valencia realiza transferencias de datos masivas
con el CERN en Ginebra, Suiza
• En pruebas hechas con máquinas conectadas a 100
Mb/s se obtenía un caudal de 9 Mb/s, considerado
insuficiente.
• Lanzando ocho transferencias en paralelo se
obtenían caudales seis veces superiores
Universidad de Valencia
Redes 5-85
Rogelio Montañana
C:\Documents and Settings\montanan>ping www.cern.ch
Haciendo ping a webr2.cern.ch [137.138.28.230] con 32 bytes de datos:
Respuesta
Respuesta
Respuesta
Respuesta
desde
desde
desde
desde
137.138.28.230:
137.138.28.230:
137.138.28.230:
137.138.28.230:
bytes=32
bytes=32
bytes=32
bytes=32
tiempo=43ms
tiempo=43ms
tiempo=43ms
tiempo=43ms
TTL=114
TTL=114
TTL=114
TTL=114
Estadísticas de ping para 137.138.28.230:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0 (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 43ms, Máximo = 43ms, Media = 43ms
C:\Documents and Settings\montanan >tracert www.cern.ch
Traza a la dirección webr2.cern.ch [137.138.28.230] sobre un máximo de 30 saltos:
1
<1 ms
<1 ms
<1 ms burl3ci.red.uv.es [147.156.2.50]
2
<1 ms
<1 ms
<1 ms burladerol3.red.uv.es [147.156.200.184]
3
<1 ms
<1 ms
<1 ms neveraout.red.uv.es [147.156.7.1]
4
<1 ms
<1 ms
<1 ms AT0-2-0-0.EB-Valencia0.red.rediris.es [130.206.211.181]
5 ms
5
6 ms
6 ms
6 ms VAL.SO3-0-0.EB-IRIS4.red.rediris.es [130.206.240.13]
6
7 ms
7 ms
7 ms rediris.es1.es.geant.net [62.40.103.61]
22 ms
7
29 ms
29 ms
29 ms es.it1.it.geant.net [62.40.96.186]
13 ms 8
42 ms
42 ms
42 ms it.ch1.ch.geant.net [62.40.96.33]
9
43 ms
42 ms
42 ms swiCE2-P6-1.switch.ch [62.40.103.18]
10
43 ms
43 ms
42 ms cernh7-gb1-1.cern.ch [192.65.184.222]
11
42 ms
43 ms
42 ms cernh2-vlan2.cern.ch [192.65.192.2]
C:\Documents and Settings\montanan>
Universidad de Valencia
Redes 5-86
Rogelio Montañana
Dist. línea
recta
Universidad de Valencia
RTT
Dist. f.o.
Valencia-Madrid
300 Km
5 ms
500 Km
Madrid-Milán
1200 Km
22 ms
2200 Km
Milán-Ginebra
250 Km
13 ms
1300 Km
Redes 5-87
Rogelio Montañana
Rendimiento con factor de escala
• Caudal max. = ventana / RTT
• Con RTT = 43 ms y ventana 524280 bits:
Caudal max. = 524280 / 0,043 = 12,2 Mb/s
• Para mejorar el rendimiento se utilizaron
implementaciones de TCP que soportan la opción de factor
de escala, obteniendo así un mayor tamaño de ventana.
Factor de escala Tam. Ventana (bits) Caudal max. (Mb/s)
Universidad de Valencia
1
524280
12,2
2
1048560
24,4
4
2097120
48,8
8
4194240
97,6
16
8388480
195,2
Redes 5-88
Rogelio Montañana
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 puesto)
Universidad de Valencia
Redes 5-89
Rogelio Montañana
Netstat -p tcp
tcp:
978740 packets sent
949215 data packets (1306073886 bytes)
544 data packets (329353 bytes) retransmitted
10186 ack-only packets (8786 delayed)
0 URG only packets
188 window probe packets
17669 window update packets
938 control packets
432947 packets received
251266 acks (for 863756680 bytes)
1294 duplicate acks
0 acks for unsent data
76150 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 window
0 window probes
23158 window update packets
1 packet received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
397 connection requests
414 connection accepts
629 connections established (including accepts)
848 connections closed (including 38 drops)
179 embryonic connections dropped
313267 segments updated rtt (of 314002 attempts)
347 retransmit timeouts
2 connections dropped by rexmit timeout
190 persist timeouts
54 keepalive timeouts
53 keepalive probes sent
1 connection dropped by keepalive
Universidad de Valencia
Redes 5-90
Rogelio Montañana
Comparación TCP - UDP
Función
TCP UDP
Transporte
Multiplexación
Detección de errores
Corrección de errores
Sí
Sí
Sí
Sí
Control de flujo
Sí
Control de congestión
Sí
Establecimiento/
Sí
terminación de conexión
Sí
Sí
Opcional(*)
No
No
No
No
(*) Obligatorio en IPv6
Universidad de Valencia
Redes 5-91
Rogelio Montañana
Proceso de una trama Ethernet TCP/IP recibida por un host
Depositar contenido en buffer para proceso en puerto destino y devolver ACK (TCP)
No
Sí
Descartar y
devolver ACK
Sí
¿Puerto destino reconocido?
No
Sí
¿Checksum TCP/UDP correcto?
Descartar y
devolver ICMP
destino inacc.
No
¿Datos duplicados (TCP)?
Proceso TCP/UDP
Sí
¿Protocolo reconocido?
Proceso IP
Driver Tarjeta
Tarjeta de red
Universidad de Valencia
Descartar
No
Sí
¿IP destino reconocida?
No
Sí
¿Checksum IP correcto?
No
Sí
¿MAC destino reconocida?
No
Sí
¿CRC correcto?
No
Sí
¿Trama long. entera  64  1518?
No
Trama recibida
Redes 5-92
CPU
Descartar y
devolver ICMP
destino inacc.
Descartar
Descartar
Descartar
Descartar
Tarjeta
red
Descartar
Rogelio Montañana
Ejercicios
Universidad de Valencia
Redes 5-93
Rogelio Montañana
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 20
bytes son la cabecera IP, con lo que quedan
65515 bytes para el segmento TCP.
Universidad de Valencia
Redes 5-94
Rogelio Montañana
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, fragment offset y
MF (More Fragments). TCP no podría reordenar los
fragmentos aunque quisiera, puesto que
normalmente solo el primero tiene cabecera TCP.
Universidad de Valencia
Redes 5-95
Rogelio Montañana
Ejercicio 7
Función básica de un cortafuegos
Internet
Router filtro
Red interna
Universidad de Valencia
Se quiere poner en el router una
regla que impida el establecimiento
de conexiones TCP desde fuera
Redes 5-96
Rogelio Montañana
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) de la cabecera IP
– Tener a 1 el bit SYN y a 0 el ACK en la
cabecera TCP.
Universidad de Valencia
Redes 5-97
Rogelio Montañana
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
Universidad de Valencia
Redes 5-98
Rogelio Montañana
Ejercicio 8: solución
•
•
•
•
Aplicación: 1540 bytes
TCP: 1540 + 20 = 1560
IP: 1560 + 20 = 1580
MTU = 800 bytes
Múltiplo de 8 bytes
20
20
756
IP
TCP
Datos
20
776
IP
Datos
20
8
IP
Datos
Universidad de Valencia
Redes 5-99
Rogelio Montañana
Ejercicio 9
P: Sesión TCP con 100 Mb/s de BW y 20 ms
de 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
Universidad de Valencia
Redes 5-100
Rogelio Montañana
Ejercicio 9
Cálculo detallado suponiendo segmentos de 1 Kbyte:
0 ms
TCP emisor empieza a enviar 1er segmento
0,08 ms
TCP emisor empieza a enviar 2º segmento
0,16 ms
TCP emisor empieza a enviar 3er segmento
...
...
5,16 ms
TCP emisor empieza a enviar segmento 64
5,24 ms
TCP emisor queda a la espera
10 ms
TCP receptor empieza a recibir 1er segmento
10,08 ms
TCP receptor devuelve primer ACK
20,08 ms
TCP emisor recibe primer ACK y empieza a
transmitir segmento 65
Eficiencia: 5,24/20,08 = 0,261 = 26,1 Mb/s
Universidad de Valencia
Redes 5-101
Rogelio Montañana
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)
– Qué merma cualitativa cabe esperar por la tasa de
error:
A. Menor del 10%
B. Alrededor del 10%
C. Mayor del 10%
–
Como influiría el RTT en el rendimiento
Universidad de Valencia
Redes 5-102
Rogelio Montañana
Evolución ventana de congestión Ej. 12
Ventana cong. (KB)
Trama
Segmento
Umbral peligro (KB)
1
1
1
64
2
2,3
2,3
64
4
4,5,6,7
4,5,6,7
64
8
8,9,10,11,12,13,14,15
8,9,10,11,12,13,14,15
64
1
16
10
4
2
17,18
16,17
4
4
19,20,21,22
18,19,20,21
4
1
23
19
2
2
24,25
22,23
2
3
26,27,28
24,25,26
2
4
29,30,31,32
27,28,29,30
2
1
33
28
2
2
34,35
31,32
2
3
36,37,38
33,34,35
2
4
39,40,41,42
36,37,38,39
2
1
43
37
2
2
44,45
40,41
2
3
46,47,48
42,43,44
2
4
49,50,51,52
45,46,47,48
2
1
53
46
2
2
54,55
49,50
2
Universidad de Valencia
Redes 5-103
Rogelio Montañana
Ejercicio 12
• La merma del rendimeinto será siempre
superior al 10%, ya que además del 10% de
paquetes perdidos tenemos el inconveniente
de estar continuamente reduciendo la
ventana de congestión.
• Cuanto mayor sea el RTT mayor será la
pérdida (con un RTT cero la pérdida sería
del 10%)
Universidad de Valencia
Redes 5-104
Rogelio Montañana
Descargar

El Nivel de Transporte en Internet