TCP Transmission Control Protocol

Transcripción

1 1 TCP Transmission Control Protocol TCP es un protocolo orientado a conexión que crea una conexión virtual entre dos TCPs para enviar datos. Además, TCP usa mecanismos de control de flujo y error en la capa de transporte. Aspectos a estudiar en este apartado: Servicios TCP Flujos Segmentos Conexión TCP Control de flujo Control de error

2 Puertos bien conocidos usados por TCP 2

3 3 Servicios TCP Comunicación Full Duplex Orientado a conexión Se establece una comunicación entre ellos Se intercambian datos en ambas direcciones Se cierra la conexión Conexión virtual (no física) Segmento TCP encapsulado en datagrama IP Cada segmento puede usar una ruta distinta En caso de perderse o corromperse, se reenvía Fiable, confirmación de que los datos han llegado bien y en orden

4 4 Transmisión de flujos Permite al proceso emisor enviar datos como si fuese un flujo de bytes, y permite al proceso receptor obtener los datos a partir de dicho flujo de bytes

5 5 Envío y recepción de buffers Las velocidades de emisor y receptor pueden ser distintas. Se necesita buffers para almacenamiento.

6 6 Segmentos TCP En realidad, IP manda los datos en paquetes y no en flujo de bytes. TCP agrupa un número de bytes en un paquete llamado segmento, que se encapsula en un datagrama IP

7 7 Conexión TCP: Numeración Nota TCP numera todos los bytes de datos que se transfieren en cada conexión La numeración empieza en un número aleatorio No existe campo número de segmento Hay número de secuencia y número de confirmación (referidos ambos al byte) Después de numerar los bytes, TCP asigna un número de secuencia a cada segmento que envía, que coincide con el número del primer byte

8 8 Ejemplo Suponer una conexión TCP para transferir un fichero de 5000 bytes. El primer byte tiene el número Obtener los números de secuencia para cada segmento si los datos se envían en 5 segmentos de 1000 bytes cada uno. El valor del campo número de secuencia de un segmento define el número del primer byte de datos contenido en dicho segmento

9 9 Número de confirmación Nota El valor del campo de confirmación de un segmento define el número del siguiente byte que espera recibir el receptor del segmento El número de confirmación es acumulativo: el receptor del segmento pone el número del último byte recibido correctamente, le suma 1 y envía dicha suma como número de confirmación Ejemplo, si usa 5643 como número de confirmación, significa que el último byte recibido fue el 5642 (no que haya recibido 5642 bytes, porque el primero no tiene por qué ser 1)

10 Formato segmento TCP 10

11 11 Algunas consideraciones sobre el segmento TCP La longitud de la cabecera, HLEN, se expresa en palabras de 32 bits (4 bytes). Como la cabecera oscila entre 20 bytes y 60 bytes, 5<=HLEN<=15. El tamaño de la ventana es el tamaño que debe tener en bytes la ventana en el receptor, también llamada ventana de recepción rwnd y la fija el receptor. Puntero urgente: si el flag correspondiente está activado, este campo de 16 bits se usa cuando hay datos urgentes. Se suma número de secuencia y puerto para obtener el número del último byte urgente y principio de datos no urgentes (normales). Opciones: hasta 40 bytes adicionales para la cabecera TCP.

12 Descripción de flags en el Campo de Control 12

13 Conexión TCP: establecimiento de conexión usando la negociación en tres pasos 13

14 Conexión TCP: establecimiento de conexión usando la negociación en tres pasos 1.- El cliente emite una petición de apertura activa enviando un segmento de control, SYN, con número de secuencia 8000, con el fin de iniciar el establecimiento de una comunicación con un servidor determinado que está preparado. No puede llevar datos. 2.- El servidor responde con el envío de un segmento de control, SYN+ACK, con número de secuencia 15000, y el número de confirmación 8001, que confirma la correcta recepción del segmento de control No puede llevar datos. 3.- El cliente envía un segmento de control, ACK, confirmando la recepción del mensaje SYN+ACK numerado como El número de secuencia es el mismo que el de ACK del mensaje anterior (8001). Este mensaje no tiene número si no lleva datos (como es el caso).

15 15 Nota Un segmento SYN no puede llevar datos, pero consume número de secuencia Un segmento SYN + ACK no puede llevar datos, pero consume número de secuencia Un segmento ACK (después de recibir SYN+ACK), si no lleva datos, no consume número de secuencia

16 Conexión TCP: transferencia de datos 16

17 Conexión TCP: transferencia de datos El cliente envía desde el byte 8001 hasta el 9000, y espera recibir del servidor el byte El cliente envía desde el byte 9001 hasta el 10000, y sigue esperando recibir del servidor el byte El servidor confirma que ha recibido correctamente hasta el byte enviando ACK 10001, y envía al cliente desde el byte hasta el El cliente confirma que ha recibido correctamente el byte y envía desde el byte con un tamaño de ventana de

18 Conexión TCP: fin de la conexión usando la negociación en tres pasos 18 +1

19 Conexión TCP: fin de la conexión usando la negociación en tres pasos 1.- El cliente envía un segmento de control, FIN, con número de secuencia x, y número de confirmación y (ha recibido hasta y-1) con el fin de finalizar una comunicación. No lleva datos, aunque podría llevarlos. 2.- El servidor responde con el envío de un segmento de control, FIN+ACK, con número de secuencia y, y el número de confirmación x+1, que confirma la correcta recepción del segmento de control x. No lleva datos, aunque podría llevarlos. 3.- El cliente envía un segmento de control, ACK, confirmando la recepción del mensaje FIN+ACK numerado como y+1 (ha recibido hasta y), y con número de secuencia x, el mismo que envió al principio del cierre. No puede llevar datos y no consume número de secuencia.

20 20 Nota El segmento FIN consume un número de secuencia si no lleva datos El segmento FIN + ACK consume un número de secuencia si no lleva datos El segmento ACK del cliente se incrementa en 1, no puede lleva datos y no consume número de secuencia

21 Conexión TCP: fin de la conexión usando la negociación en cuatro pasos: semicierre 21 Un extremo puede dejar de enviar datos, pero seguir recibiendo: semicierre En la Figura ocurre con el cliente. Aunque no envía datos, sí envía ACKs +1 El cliente envía un segmento FIN y el servidor lo acepta con un ACK. Cuando el servidor termina, envía un segmento FIN que es confirmado por el cliente

22 22 Control de flujo: ventana deslizante 1) rwnd es el tamaño de ventana que determina el receptor Número de bytes que puede aceptar antes de que se desborde su buffer 2) cwnd es la llamada ventana de congestión y lo determina la red

23 23 Control de flujo: ventana deslizante Distintos tipos de bytes (de izquierda a derecha): 1) Enviados y ya confirmados: no necesitan ser recordados. Están fuera de la ventana (por la izquierda). 2) Enviados y no confirmados: sí necesitan ser recordados. Están dentro de la ventana (pared izquierda). 3) No enviados pero dispuestos a ello: sí necesitan ser recordados. Están dentro de la ventana (pared derecha). 4) No enviados ni con posibilidad de hacerlo: no necesitan ser recordados. Están fuera de la ventana (por la derecha). Las ventanas se pueden: 1) Abrir: mover la pared derecha hacia la derecha. 2) Cerrar: mover la pared izquierda hacia la derecha. 3) Reducir: mover la pared derecha hacia la izquierda, que es desaconsejable, ya que supone revocar que algunos bytes se puedan enviar. Si ya se han enviado, es un problema.

24 24 Nota Se usa una ventana deslizante para hacer más eficiente la transmisión y para controlar el flujo de datos de manera que el destino no se desborde con datos. Las ventanas deslizantes de TCP son orientadas a byte.

25 25 Ejemplo 1 Cuál es el valor de la ventana de recepción (rwnd) para un host A si el receptor, host B, tiene una tamaño de buffer de 5000 bytes y 1000 bytes de datos recibidos sin procesar todavía? Solución El valor de rwnd = = El host B sólo puede recibir 4000 bytes antes de que su buffer se desborde. El host B anuncia este valor al host A en el siguiente segmento.

26 26 Ejemplo 2 Cuál es el tamaño de la ventana del host A si el valor de rwnd es 3000 bytes y el valor de cwnd es 3500 bytes? Solución El tamaño de la ventana es el menor de rwnd y cwnd, o sea, 3000 bytes.

27 27 Ejemplo 3 La figura muestra un ejemplo poco realista de una ventana deslizante. El emisor ha enviado hasta el byte 202 incluído. Supongamos que cwnd es 20 (en realidad este valor es en miles de bytes). El receptor ha enviado un número de confirmación de 200 con un rwnd de 9 bytes (en realidad son miles de bytes). El tamaño de la ventana del emisor es el menor de rwnd y cwnd, es decir, 9 bytes. Se recibieron los bytes 200 a 202, pero sin confirmación aún. Los bytes 203 a 208 se pueden enviar sin preocuparse de la confirmación. El byte 209 y los siguientes no se pueden enviar todavía.

28 Figura 28

29 29 Nota Algunas consideraciones sobre ventanas deslizantes en TCP: El tamaño de la ventana es el menor de rwnd y cwnd. El origen no necesita enviar una ventana entera llena de datos. La ventana se puede abrir o cerrar por el receptor, pero no debería reducirse. El destino puede enviar una confirmación en cualquier momento siempre que eso no provoque una reducción de la ventana. El receptor puede cerrar temporalmente la ventana; sin embargo, el emisor siempre puede enviar un segmento de un byte después de que se haya cerrado la ventana.

30 30 Control de error Sumas de comprobación: ya visto. Confirmación: los segmentos de control que no llevan datos pero consumen número de secuencia también se confirman. Sin embargo los segmentos ACK no consumen número de secuencia y nunca se confirman. Retransmisión: cuando un segmento se corrompe, se pierde o se retrasa, se retransmite.

31 31 Retransmisión Nota En implementaciones modernas, hay una retransmisión: - si expira un temporización de retransmisión o - si llegan tres segmentos repetidos de ACK (retransmisión rápida). No se activa un temporizador de retransmisión para un segmento ACK.

32 32 Segmentos fuera de orden Nota Los datos pueden llegar desordenados y almacenarse temporalmente por el receptor, pero TCP garantiza que segmentos fueran de orden no se entregan al proceso.

33 Funcionamiento normal 33

34 34 Funcionamiento normal 1.- El cliente envía el número de segmento 1201 correspondiente al bloque de bytes 1201 a 1400 ambos incluídos. Además, espera recibir el byte 4001, con lo que confirma haber recibido correctamente hasta el byte El servidor responde confirmando que ha recibido el byte 1400, enviando 1401 como número de confirmación, y envía el bloque de bytes de 4001 a 5000 ambos incluídos, indicando en su campo número de segmento el valor Pasados 500 ms y esperando por si llegan más segmentos, se dispara un temporizador. El cliente, que no tiene datos que enviar, confirma la correcta recepción del byte 5000 enviando un mensaje ACK con el campo de confirmación puesto a 5001.

35 35 Funcionamiento normal 4.- El servidor envía el número de segmento 5001 correspondiente al bloque de bytes 5001 a 6000 ambos incluídos. Además, sigue esperando recibir el byte El último byte correcto que recibió fue el El cliente no ha enviado más bytes con números superiores a 4000, por eso no los ha recibido. 5.- El servidor envía el número de segmento 6001 correspondiente al bloque de bytes 6001 a 7000 ambos incluídos y sigue esperando recibir el byte Aunque no ha llegado a expirar el temporizador cuando llega el bloque de bytes , el cliente confirma la correcta recepción del bloque en cuanto lo recibe, e indirectamente del bloque , enviando un ACK con número de confirmación 7001, sin añadir nuevos datos.

36 36 Segmento perdido Suponer comunicación unidireccional

37 37 Segmento perdido 1.- El emisor envía el número de segmento 501 correspondiente al bloque de bytes 501 a 600 ambos incluídos. Además, espera recibir el byte x (confirmada la correcta recepción hasta el byte x-1). Se recibe correctamente en el receptor y se almacena en el buffer. 2.- El emisor envía el número de segmento 601 correspondiente al bloque de bytes 601 a 700, ambos incluídos. Además, sigue esperando recibir el byte x. Se recibe correctamente en el receptor y se almacena en el buffer a continuación del anterior. 3.- El receptor confirma la correcta recepción hasta el byte 700 e indirectamente también el bloque anterior ( ) enviando un mensaje de ACK sin datos con el campo de confirmación a 701.

38 38 Segmento perdido 4.- El emisor envía el número de segmento 701 correspondiente al bloque de bytes 701 a 800 ambos incluídos. Este segmento se pierde y no llega al receptor. Poco después, el emisor envía el número de segmento 801 correspondiente al bloque de bytes 801 a 900 ambos incluídos, que sí llega al receptor. 5.- El receptor confirma la correcta recepción hasta el byte 700, igual que en el punto anterior y almacena en el buffer el bloque de bytes 801 a 900, dejando un hueco para el bloque perdido Cuando el emisor recibe una confirmación que no corresponde al último byte que envió y expira el temporizador (timeout), vuelve a enviar el segmento del que todavía no tiene constancia de que haya llegado.

39 39 Segmento perdido 7.- El emisor envía el número de segmento 701 correspondiente al bloque de bytes 701 a 800 ambos incluídos. Esta vez no se pierde y sí llega al servidor. 8.- Por un lado, el receptor confirma la correcta llegada del último byte del que tiene constancia, el 900, enviando un ACK con número de confirmación Coloca el segmento con los bytes 701 a 800 perdido y reenviado en el hueco que le había reservado en el buffer, de manera que queda subsanada la pérdida del segmento con bytes 701 a 800.

40 40 Nota El receptor TCP (en nuestro caso el servidor) sólo entrega datos ordenados al proceso

41 Retransmisión rápida 41

42 42 Retransmisión rápida Cuando se confirman tres veces consecutivas un número de byte que no es el esperado, se reenvía el bloque de bytes perdido y cuando llega, se confirman todos los bytes recibidos con un mensaje de ACK cuyo número es confirmación es una unidad más que el último byte recibido. Además, se colocan los segmentos en orden para enviarlos ordenadamente al proceso.