Full transcript
0:00Hoy vamos a hablar sobre TCP, UDP y Stop & Wait.
0:05Al principio del curso, hablamos de sockets "Orientados a conexión" y "No orientados a conexión".
0:10Ahora vamos a hablar de los protocolos que rigen a estos sockets a nivel de la capa de transporte.
0:16Primero hablemos un poco de la capa de transporte.
0:19La capa de transporte se encarga de enviar información punto a punto entre procesos.
0:24Para ello, utiliza direcciones que identifican cuáles procesos se están comunicando y dónde se están ejecutando.
0:31Aquí la IP indica dónde se está ejecutando un proceso y el puerto indica cuál es el proceso con el que me estoy comunicando.
0:38Dentro de la capa de transporte existen varios protocolos de comunicación,
0:42sin embargo, los más usados son TCP y UDP.
0:46UDP provee lo mínimo necesario para la comunicación en la capa de transporte.
0:50UDP nos permite enviar datagramas a una dirección (IP, puerto)
0:54y checkear si se alteró el contenido de los datos mediante un checksum. Nada más :/
0:58TCP, en cambio, establece un canal de comunicación
1:01a través del cual puede manejar pérdidas de segmentos y mantener el orden de los segmentos.
1:06Los sockets orientados a conexión se rigen por TCP, mientras que los sockets no orientados a conexión se rigen por UDP.
1:14Como vimos anteriormente, ambos tipos de comunicación tienen sus ventajas y desventajas, por lo que ambos son utilizados.
1:21Para proveer un servicio orientado a conexión TCP funciona de la siguiente manera:
1:26Primero establece el canal de comunicación con un saludo o handshake.
1:30Luego envía los datos y se asegura que lleguen a su destino.
1:34Y finalmente cierra el canal de comunicación.
1:37Para ello, utiliza mensajes de sincronización (SYN),
1:40mensajes de confirmación (ACK por acknowledge),
1:43mensajes de término (FIN) y números de secuencia.
1:47Veamos cómo funciona cada paso en TCP.
1:50Aquí vamos a ver una versión simplificada de TCP.
1:54Primero hacemos el saludo o handshake. Este saludo consta de 3 pasos:
1:58Desde el lado del cliente se solicita la conexión.
2:01Para ello se envía un mensaje SYN y un número aleatorio x, el cual corresponde al número de secuencia.
2:07Si el servidor acepta la conexión, entonces este envía un mensaje SYN-ACK y x incrementado en 1.
2:14Aquí la parte SYN del mensaje le señala al cliente que vamos a establecer comunicación bidireccional
2:20y el mensaje ACK junto con el número de secuencia incrementado indica que recibimos bien el mensaje SYN original del cliente.
2:27Finalmente, el cliente le confirma al servidor que recibió su mensaje SYN-ACK enviando un mensaje ACK
2:33junto al número de secuencia recibido incrementado en alguna cantidad.
2:37Como el saludo sigue 3 pasos, este proceso también es conocido como el Three way handshake.
2:43¿Y por qué no un handshake en dos pasos?
2:46Un handshake en dos pasos significaría que el cliente envíe un SYN, el servidor responda con un ACK, y listo!
2:52Este tipo de saludos no se usa, pues únicamente coordina la comunicación del cliente con el servidor,
2:59mientras que un handshake de 3 pasos coordina la comunicación del cliente con el servidor y del servidor con el cliente.
3:06Debemos notar que esto es menos evidente en nuestra versión simplificada,
3:11sin embargo, más adelante veremos la importancia de un handshake de 3 pasos en TCP de verdad.
3:16Luego del handshake debemos encargarnos de la comunicación.
3:20Existen varias maneras de asegurarnos que los mensajes lleguen desde el origen al destino y que lleguen en orden.
3:26La forma más simple corresponde a Stop & Wait.
3:30Stop & Wait funciona de la siguiente manera:
3:32Primero, el emisor envía un segmento junto a su número de secuencia y coloca un timeout para recibir la respuesta.
3:38Si el receptor recibe el segmento con éxito, entonces este envía un ACK con el número de segmento incrementado.
3:44En este caso vemos que lo incrementa de acuerdo al número de bytes recibidos.
3:48El receptor almacena el número de segmento que acaba de enviar
3:51para verificar que el siguiente segmento que le llegue sea en efecto la continuación de lo que acaba de recibir y no un duplicado.
3:59Si todo sale bien, entonces el emisor envía el siguiente segmento,
4:03utilizando como número de secuencia el número recibido desde el receptor.
4:06Si el emisor no recibe el ACK luego de cumplirse el timeout, este asume que el segmento no le llegó al receptor y vuelve a enviar el segmento.
4:15Esta acción se repite hasta que el emisor reciba un ACK antes de que se cumpla el timeout.
4:20Por su lado, si se pierde el ACK enviado por el receptor, una vez se cumpla el timeout del emisor, este va a reenviar el segmento.
4:27El cual, en este caso, ya fue recibido por el receptor.
4:31Aquí, el receptor checkea el número de segmento que tiene almacenado
4:35y al ver que el número de segmento recibido es menor que el que tenía almacenado, descarta el segmento y reenvía el ACK.
4:41De esta manera, Stop and Wait, como su nombre sugiere, luego de enviar cosas, se detiene y espera hasta recibir una confirmación.
4:49Finalmente, debemos cerrar la conexión.
4:52Para cerrar o terminar la comunicación:
4:54Enviamos un segmento FIN más el número de secuencia.
4:57Luego este mensaje se responde con un segmento FIN más un ACK con el número de secuencia incrementado.
5:02Y finalmente se envía el mensaje ACK para confirmar el cierre de conexión.
5:07Acá debemos notar si bien es ideal que se haga cierre de conexión,
5:10normalmente, TCP va a cerrar la conexión de todas maneras después de que se cumpla una cierta cantidad de tiempo sin recibir mensajes.
5:19En esta clase hemos visto:
5:20Capa de transporte.
5:22Qué es TCP y UDP.
5:24Cómo funciona TCP.
5:25Y Stop & Wait.
5:27Cualquier duda o consulta, ¡no duden en contactar al equipo docente!