Tema 5 El Nivel de Transporte en Internet

1
Tema 5El Nivel de Transporte en Internet
Rogelio Montañana Departamento de
Informática Universidad de Valencia rogelio.montan
ana_at_uv.es http//www.uv.es/montanan/
2
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

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. 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)

4
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

5
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

6
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

7
La cabecera UDP
32 bits
Dirección IP de origen Dirección IP de origen Dirección IP de origen
Dirección IP de destino Dirección IP de destino Dirección IP de destino
00000000 00010001 Long. Datagrama UDP
Pseudocabecera
32 bits
Puerto de origen Puerto de destino
Longitud datagrama UDP Checksum
Cabecera
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
8
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

Puerto
Dirección IP
Socket
9
Multiplexación
Nivel de aplicación
Múltiples instancias (una o varias por protocolo)
NTP (Puerto 123)
DNS (Puerto 53)
Daytime (Puerto 13)
Nivel de transporte
Dos instancias (TCP y UDP)
P. dest. 13 DATOS APLICACIÓN
Cabecera UDP
Checksum
Checksum
Nivel de red
Una instancia IP (puede haber otros protocolos)
Prot. 17 DATAGRAMA UDP
Cabecera IP
Nivel de enlace
Múltiples instancias (una por interfaz)
Ethertype 0800 DATAGRAMA IP CRC
Cabecera MAC Ethernet
CRC
10
Conexión UDP de un cliente contra un servidor
Mensaje UDP p.o. 1038, p.d. 13
Port 1038
Port 13
Mensaje UDP p.o. 13, p.d. 1038
Cliente IP 10.0.1.50
Servidor Daytime IP 10.0.1.25
Socket 10.0.1.50.1038
Socket 10.0.1.25.13
11
Cabeceras IP y UDP en una petición/respuesta SNMP
IP ----- IP Header ----- IP IP Version4, header length20 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 IP ----- IP Header ----- IP IP Version4, header length20 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
12
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

13
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.

14
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.

15
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

16
La cabecera TCP
32 bits
Puerto de destino
Puerto de origen
Número de secuencia
Número de acuse de recibo
20 bytes
L. Cab. (4 bits)
Resv. (4 bits)
Flags (8 bits)
Tamaño ventana
Puntero datos urgentes
Checksum
Relleno
Opciones
Flags CWR Congestion Window Reduced ECE ECN
Echo (ECNExplicit Congestion Notification)
URG el segmento contiene datos
urgentes ACK el campo número de acuse de recibo
tiene sentido PSH el segmento contiene datos
Pushed RST ha habido algún error y la
conexión debe cerrarse SYN indica el inicio de
una conexión FIN indica el final de una conexión
17
La pseudocabecera TCP
32 bits
Dirección IP de origen Dirección IP de origen Dirección IP de origen
Dirección IP de destino Dirección IP de destino 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
18
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

19
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)

20
Algunos servicios bien conocidos
Servicio Puerto TCP UDP
DayTime 13 X X
FTP 21 X
SSH 22 X
TelNet 23 X
SMTP 25 X
Domain (DNS) 53 X 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
21
Multiplexación
Nivel de aplicación
HTTP (Puerto 80)
HTTP (Puerto 400)
Múltiples instancias (una o varias por protocolo)
SMTP (Puerto 25)
FTP (Puerto 21)
Telnet (Puerto 23)
Nivel de transporte
Checksum
Dos instancias (TCP y UDP)
P. dest. (23) DATOS APLICACIÓN
Cabecera TCP
Checksum
Nivel de red
Una instancia IP (puede haber otros protocolos)
Prot. (6) SEGMENTO TCP
Cabecera IP
Nivel de enlace
Múltiples instancias (una por interfaz)
Ethertype (0800) DATAGRAMA IP CRC
Cabecera MAC Ethernet
22
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
Conexión TCP 10.0.1.25.23-10.0.1.50.1038
Cliente IP 10.0.1.50
Port 23
Socket 10.0.1.50.1038
Conexión TCP 10.0.1.25.23-10.0.2.47.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
23
Dos conexiones TCP a un mismo socket desde dos
sockets con la misma dirección IP
Socket 10.0.1.80.1038
Conexión TCP 10.0.1.25.23-10.0.1.80.1038
Port 1038
Port 23
Port 1039
Conexión TCP 10.0.1.25.23-10.0.1.80.1039
Cliente IP 10.0.1.80
Servidor IP 10.0.1.25
Socket 10.0.1.25.23
Socket 10.0.1.80.1039
24
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
(state) tcp 0 0 147.156.1.25.2480
147.156.1.1.143 ESTABLISHED tcp
0 0 147.156.1.25.23
147.156.96.8.1034 ESTABLISHED tcp 0
240 147.156.1.25.23 147.156.1.219.1036
ESTABLISHED tcp 0 0
147.156.1.25.513 147.156.1.3.1018
ESTABLISHED tcp 0 0 147.156.1.25.513
147.156.1.3.1019 ESTABLISHED tcp
0 0 147.156.1.25.2429
147.156.1.15.6000 ESTABLISHED tCP 0
0 147.156.1.25.2428 147.156.1.15.6000
ESTABLISHED tcp 0 0
147.156.1.25.1022 147.156.1.3.1002
ESTABLISHED tcp 0 0 147.156.1.25.514
147.156.1.3.1004 CLOSE_WAIT tcp
0 0 147.156.1.25.1023
147.156.1.3.1005 ESTABLISHED tcp 0
0 147.156.1.25.514 147.156.1.3.1007
CLOSE_WAIT tcp 0 0
147.156.1.25.139 147.156.1.219.1029
ESTABLISHED tcp 0 0 .143
. LISTEN tcp
0 0 .144 .
LISTEN tcp 0 0
147.156.1.25.23 147.156.3.12.1945
ESTABLISHED tcp 0 0 .139
. LISTEN tcp
0 0 .5000 .
LISTEN tcp 0 0 .25
. LISTEN tcp
0 0 .19 .
LISTEN tcp 0 0 .9
. LISTEN 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 .
25
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

26
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.

27
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.

28
Establecimiento de una conexión TCP por saludo a
tres vías
TCP A
TCP B
CLOSED
LISTEN
seq100, SYN
SYN-SENT (ISN 100)
SYN-RECEIVED (ISN 300)
seq300, ack101, SYN, ACK
ESTABLISHED
? Tiempo
seq101, ack301, ACK
ESTABLISHED
29
Saludo a tres vías, conexión simultánea
TCP A
TCP B
CLOSED
CLOSED
seq100, SYN
seq300, SYN
SYN-SENT (ISN 100)
SYN-SENT (ISN 300)
SYN-RECEIVED
SYN-RECEIVED
seq300,ack101, SYN, ACK
seq100, ack301, SYN,ACK
? Tiempo
ESTABLISHED
ESTABLISHED
30
Conexión con SYN duplicado
TCP A
TCP B
seq90, SYN
SYN-SENT (ISN 90)
LISTEN
SYN 90
(timeout)
CLOSED
seq100, SYN
SYN-SENT (ISN 100)
SYN 100
SYN 90
seq90, SYN
SYN-RECEIVED (ISN 300)
? Tiempo
seq300, ack91, SYN, ACK
seq91, RST
LISTEN
SYN 100
seq100, SYN
SYN-RECEIVED (ISN 400)
seq400, ack101, SYN, ACK
ESTABLISHED
seq101, ack401, ACK
ESTABLISHED
31
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.

32
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.

33
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.

34
Desconexión asimétrica
Host 1
Host 2
DATOS
Conectado
DATOS
Conectado
? Tiempo
DR
DATOS
No Conectado
Datos perdidos
No Conectado
DR Disconnect Request
35
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.

36
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.

37
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

38
Desconexión a tres vías, caso normal
TCP A
TCP B
ESTABLISHED
ESTABLISHED
seq 100, ack300, FIN, ACK
FIN-WAIT-1
CLOSE-WAIT
seq300, ack101 ACK
FIN-WAIT-2
LAST-ACK
seq300, ack101, FIN, ACK
TIME-WAIT
2 MSL
seq101, ack301, ACK
CLOSED
CLOSED
MSL Maximum Segment Lifetime (normalmente 2
minutos)
39
Desconexión a tres vías, casos anormales
Host 1
Host 2
Host 1
Host 2
FIN
Envía FIN y arranca timer
FIN
Envía FIN y arranca timer
Envía FIN y arranca timer
FIN
Envía FIN y arranca timer
FIN
Libera conexión
(Timeout) envía FIN y arranca timer
FIN
Envía FIN y arranca timer
FIN
Envía ACK
ACK
(Timeout) libera conexión
Libera conexión
Libera conexión
ACK
Envía ACK
Pérdida de ACK final
Pérdida de respuesta FIN
Host 1
Host 2
Host 1
Host 2
FIN
FIN
Envía FIN y arranca timer
Envía FIN y arranca timer
Envía FIN y arranca timer
Conectado
FIN
(timeout) envía FIN y arranca timer
(timeout) envía FIN y arranca timer
FIN
FIN
(Timeout) libera conexión
(N timeouts) Libera conexión
(N timeouts) Libera conexión
Conectado
Pérdida de todos los FIN de host 1
Pérdida de todo menos primer FIN
40
(No Transcript)
41
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

42
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

43
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.

44
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.

45
Intercambio de datos TCP ? Aplicación y TCP ? TCP
Aplicación origen
Aplicación destino
A criterio de la aplicación (sujeto a
disponibilidad de buffer en TCP emisor)
A criterio de la aplicación
Estira
Empuja
TCP receptor
TCP emisor
Buffer
Buffer
Empuja
A criterio del TCP emisor (sujeto a
disponibilidad de buffer en TCP receptor y no
congestión de la red)
46
Intercambio de datos TCP ? Aplicación y TCP ? TCP
Aplicación origen
Aplicación destino
1024 Bytes
Lee
Escribe
2048 Bytes
1024 Bytes
Envía
TCP receptor
TCP emisor
Buffer
Buffer
512 B
512 B
512 B
512 B
(MSS 512 Bytes)
47
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.

48
Gestión de buffers y Control de flujo
Buffer
Emisor
Receptor
0
4K
La aplicación escribe 2 KB
Vacío
Seq 0
2 KB
Ack 2048, Win 2048
La aplicación escribe 3 KB
Seq 2048
Lleno
Emisor Bloqueado
Ack 4096, Win 0
La aplicación lee 2 KB
Ack 4096, Win 2048
El emisor puede enviar hasta 2 KB
Seq 4096
3 KB
49
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

50
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

51
Control de flujo y números de secuencia Caso
normal, sin pédidas
Host 1
Host 2
Seq1000, Win4000
SYN
Seq1500, Ack1001, Win4000
SYN
Seq1001, Ack1501, Win4000
1000 bytes
Seq1501, Ack2001, Win3000
1000 bytes
Seq2001, Ack2501, Win3000
1000 bytes
Seq3001, Ack2501, Win3000
1000 bytes
Seq4001, Ack2501, Win3000
1000 bytes
Seq2501, Ack5001, Win0
Aplicación lee 2000 bytes
Bloqueado
Seq2501, Ack5001, Win2000
Seq5001, Ack2501, Win3000
1000 bytes
Seq2501, Ack6001, Win3000
52
Pérdida de un paquete Retransmisión con retroceso
n
Host 1
Host 2
Seq1000, Win4000
SYN
Seq1500, Ack1001, Win4000
SYN
Seq1001, Ack1501, Win4000
1000 bytes
Seq1501, Ack2001, Win3000
1000 bytes
Seq2001, Ack2501, Win3000
1000 bytes
Seq3001, Ack2501, Win3000
1000 bytes
Seq4001, Ack2501, Win3000
1000 bytes
Ignorado
Timeout
Seq2501, Ack3001, Win2000
Bloqueado
Timeout
Seq3001, Ack2501, Win3000
1000 bytes
Seq4001, Ack2501, Win3000
1000 bytes
Aplicación lee 2000 bytes
Seq2501, Ack5001, Win0
Seq2501, Ack5001, Win2000
Seq5001, Ack2501, Win3000
1000 bytes
Seq2501, Ack6001, Win3000
53
Pérdida de un paquete Retransmisión con
repetición selectiva
Host 1
Host 2
Seq1000, Win4000
SYN
Seq1500, Ack1001, Win4000
SYN
Seq1001, Ack1501, Win4000
1000 bytes
Seq1501, Ack2001, Win3000
1000 bytes
Seq2001, Ack2501, Win3000
1000 bytes
Seq3001, Ack2501, Win3000
1000 bytes
Seq4001, Ack2501, Win3000
1000 bytes
Timeout
Seq2501, Ack3001, Win1000
Bloqueado
Seq3001, Ack2501, Win3000
1000 bytes
Seq2501, Ack5001, Win0
Aplicación lee 2000 bytes
Seq2501, Ack5001, Win2000
Seq5001, Ack2501, Win3000
1000 bytes
Seq2501, Ack6001, Win3000
54
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

55
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.

56
Timer de persistencia
TCP A
TCP B
100 bytes (501-600)
(seq501)(ack401)(ctlACK)(datos)
? Tiempo
Buffer lleno
(seq401)(ack601)(ctlACK)(W0)
Datos leídos por la aplicación
(seq401)(ack601)(ctlACK)(W400)
Timer de Persistencia
Bloqueado
(seq601)(ack401)(ctlACK)(datos)
1 byte (601)
Datos puestos en buffer para la aplicación
(seq401)(ack602)(ctlACK)(W(399)
57
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

58
Mensajes de keepalive
TCP Servidor
TCP Cliente
(seq501)(ack401)(ctlACK)(datos)
100 bytes (501-600)
Datos puestos en buffer para la aplicación
? Tiempo
(seq401)(ack601)(ctlACK)
Timer Keepalive
(seq600)(ack401)(ctlACK)(datos)
1 byte (600)
Datos duplicados descartados
(seq401)(ack601)(ctlACK)
59
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 Data offset 24 bytes TCP Flags 02 (SYN) TCP Window 2048 TCP Checksum F2DA (correct) TCP TCP Options follow TCP Max segment size 1460 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
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 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
60
Intercambio de segmentos del caso anterior
Cliente
Servidor
SEQ16421121, SYN
SEQ390272001, ACK16421122, SYN
TCP Conectado
SEQ16421122, ACK390272002
TCP Conectado
El servidor envía la secuencia UNIX Login
SEQ390272002, ACK16421122
61
Cliente
Servidor
El usuario teclea una C
SEQ92, ACK109, 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
SEQ109, ACK93, Datos C
El TCP envía un ACK del segmento recibido
SEQ93, ACK110
Funcionamiento de TCP en Telnet con eco
remoto cuando el host responde rápidamente a los
mensajes
62
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
SEQ92, ACK109, Datos C
SEQ109, ACK93
Cuando el servidor telnet ha procesado el
mensaje devuelve otro segmento con el carácter
C
SEQ109, ACK93, DatosC
El TCP envía un ACK del segmento recibido
SEQ93, ACK110
Funcionamiento de TCP en Telnet con eco
remoto cuando el host responde con lentitud a los
mensajes
63
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

64
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.

65
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

66
Síndrome de la ventana tonta

1. La aplicación que envía datos los genera
   rápidamente
2. La aplicación receptora los recupera lentamente,
   un byte cada vez
3. El buffer del TCP receptor se llena
4. El TCP receptor notifica al emisor que su ventana
   está cerrada
5. La aplicación receptora lee un byte
6. EL TCP receptor envía un ACK al emisor para
   anunciarle que dispone de un byte libre
7. El TCP emisor envía un segmento con un byte de
   datos
8. Volvemos al punto 3

67
Síndrome de la ventana tonta
Buffer receptor lleno
La aplicación lee un byte
Un byte libre
Se envía segmento de actualización de ventana
Cabecera IP-TCP
40 Bytes
Se recibe segmento con un byte de datos
Cabecera IP-TCP
40 Bytes
Buffer receptor lleno
1 Byte
68
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

69
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

70
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.

71
Control de flujo
Control de congestión
72
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.

73
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

74
Funcionamiento de slow start, fase 1
Emisor
Receptor
Ventana
1 MSS
Con MSS 1KB en 7 iteraciones se llega a 64 KB,
tamaño máximo de la ventana
2 MSS
4 MSS
8 MSS
75
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

76
Funcionamiento de slow start, fase 2
Emisor
Receptor
Ventana
1 MSS
ACK del segmento 15 perdido y retransmitido
SEG 15
ACK 15
2 MSS
SEG 16
ACK 16
SEG 17
ACK 17
SEG 18
4 MSS
ACK 18
SEG 19
ACK 19
SEG 20
ACK 20
SEG 21
ACK 21
SEG 22
ACK 22
5 MSS
SEG 23
ACK 23
SEG 24
ACK 24
SEG 25
ACK 25
SEG 26
ACK 26
SEG 27
6 MSS
ACK 27
SEG 28
ACK 28
SEG 29
ACK 29
SEG 30
ACK 30
SEG 31
ACK 31
SEG 32
ACK 32
77
Evolución de la ventana de congestión
44
Un segmento perdido (40 KB)
40
36
Umbral (32 KB)
32
28
24
Ventana de congestión (KiloBytes)
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
78
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.

79
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 4D

80
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

81
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
  BWRTT 1 Mb
• Enlace por fibra de larga distancia de 1 Gb/s y
  RTT 40 ms BWRTT 40 Mb

82
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 BWRTT gt 64 Kbytes el
  rendimiento se puede ver limitado por este
  motivo. La limitación es tanto mayor cuanto mayor
  es el BWRTT de la red

83
Funcionamiento de TCP en redes LFN
TCP A (emisor)
TCP B (receptor)
Enlace vía satélite con BW 2 Mb/s y RTT 500 ms
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)
84
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

85
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

86
C\Documents and Settings\montanangtping
www.cern.ch Haciendo ping a webr2.cern.ch
137.138.28.230 con 32 bytes de
datos Respuesta desde 137.138.28.230 bytes32
tiempo43ms TTL114 Respuesta desde
137.138.28.230 bytes32 tiempo43ms
TTL114 Respuesta desde 137.138.28.230 bytes32
tiempo43ms TTL114 Respuesta desde
137.138.28.230 bytes32 tiempo43ms
TTL114 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 gttracert
www.cern.ch Traza a la dirección webr2.cern.ch
137.138.28.230 sobre un máximo de 30 saltos
1 lt1 ms lt1 ms lt1 ms burl3ci.red.uv.es
147.156.2.50 2 lt1 ms lt1 ms lt1 ms
burladerol3.red.uv.es 147.156.200.184 3 lt1
ms lt1 ms lt1 ms neveraout.red.uv.es
147.156.7.1 4 lt1 ms lt1 ms lt1 ms
AT0-2-0-0.EB-Valencia0.red.rediris.es
130.206.211.181 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 7 29
ms 29 ms 29 ms es.it1.it.geant.net
62.40.96.186 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\montanangt
5 ms
22 ms
13 ms
87
Dist. línea recta 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
88
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)
1 524280 12,2
2 1048560 24,4
4 2097120 48,8
8 4194240 97,6
16 8388480 195,2
89
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
  BWRTT
• 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)

90
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
91
Comparación TCP - UDP
Función TCP UDP
Transporte Sí Sí
Multiplexación Sí Sí
Detección de errores Sí Opcional()
Corrección de errores Sí No
Control de flujo Sí No
Control de congestión Sí No
Establecimiento/ terminación de conexión Sí No
() Obligatorio en IPv6
92
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
Datos duplicados (TCP)?
Sí
Descartar y devolver ICMP destino inacc.
No
Proceso TCP/UDP
Puerto destino reconocido?
Sí
No
CPU
Descartar
Checksum TCP/UDP correcto?
Sí
Descartar y devolver ICMP destino inacc.
No
Protocolo reconocido?
Sí
No
Proceso IP
Descartar
IP destino reconocida?
Sí
No
Descartar
Checksum IP correcto?
Sí
No
Descartar
MAC destino reconocida?
Driver Tarjeta
Sí
No
Descartar
CRC correcto?
Tarjeta red
Sí
No
Tarjeta de red
Descartar
Trama long. entera ? 64 ? 1518?
Trama recibida
93
Ejercicios
94
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.
95
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.

96
Ejercicio 7
Función básica de un cortafuegos
Internet
Router filtro
Se quiere poner en el router una regla que impida
el establecimiento de conexiones TCP desde fuera
Red interna
97
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.

98
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

99
Ejercicio 8 solución

• Aplicación 1540 bytes
• TCP 1540 20 1560
• IP 1560 20 1580
• MTU 800 bytes

Múltiplo de 8 bytes
756
20
20
IP TCP Datos
776
20
IP Datos
20
8
IP Datos
100
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 SustituyendoBW 655358 / 0,02
26,2 Mb/s
101
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
102
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
• Menor del 10
• Alrededor del 10
• Mayor del 10
• Como influiría el RTT en el rendimiento

103
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
104
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)