Full transcript
0:00Hola, en esta clase vamos a hablar de TCP sin simplificar.
0:04Hasta ahora hemos visto una versión *simplificada* de TCP.
0:08En esta clase vamos a ver lo básico de TCP sin simplificar de acuerdo a la RFC793.
0:15TCP establece un canal de conexión a través de un handshake para manejar pérdidas, esta es punto a punto.
0:21Esta conexión es full-duplex:
0:23esto quiere decir que solo se pueden conectar 2 hosts y que es posible mandar datos en ambas direcciones al mismo tiempo.
0:30Nuestra versión simplificada de TCP es half-duplex: es decir, que podemos enviar datos en ambas direcciones, pero no al mismo tiempo.
0:39Además de estos tipos de conexión, existen las conexiones simplex las cuales solo pueden establecer comunicaciones en una dirección.
0:46Veamos los headers TCP.
0:48Similar a los mensajes DNS, aquí los datos se colocan bit a bit.
0:52Si se fijan aquí solo hay puerto de origen y puerto de destino, pero no IP.
0:57Esto, pues IP se maneja en la capa de red, no en la de transporte.
1:01En el área de flags podemos indicar si el segmento es un ACK, SYN, FIN, entre otros.
1:07Data Offset nos indica dónde termina el header y comienzan los datos.
1:11El área de “window size” indica cuánto espacio queda en la ventana de recepción o reception window.
1:17Esta es la misma ventana de recepción que mencionamos en la clase de control de congestión y flujo.
1:23El área de options permite indicar datos complementarios, como por ejemplo, el Maximum Segment Size.
1:29Ahora, notemos que TCP, además del sequence number, tiene un acknowledgment number o ACK number.
1:35Mientras que nuestra versión simplificada solo tenía número de secuencia.
1:39Para entender mejor estos números veamos cómo funciona en TCP el 3-way handshake.
1:46En el handshake tanto A como B envían un número de secuencia.
1:51El número de secuencia de A se usa como número de ACK de B y el número de secuencia de B se usa como número de ACK de A.
1:58Gracias a este intercambio es posible aprovechar los ACKs para enviar datos y lograr que TCP sea full-duplex.
2:06Además, durante el handshake ambas partes se ponen de acuerdo respecto al valor del Maximum Segment Size
2:11a través del campo options del header,
2:13e indican los tamaños iniciales de su ventana de recepción a través del campo window size.
2:19Veamos cómo funciona el envío de datos.
2:22Puede que se pregunten si TCP usa Go-Back N o Selective Repeat.
2:26Y la respuesta es:
2:28Sí. Un poco de cada uno.
2:31TCP tiene una ventana tanto en el emisor como en el receptor, como Selective Repeat.
2:36En el emisor dividimos nuestros datos en trozos de tamaño MSS y manejamos una ventana de tamaño variable.
2:42Mientras que en el receptor tenemos una ventana con r_window(rwnd) bytes disponibles.
2:47Cuando enviamos un segmento, el número de secuencia indica en qué byte comienza el trozo de datos.
2:53Con esto, el receptor puede guardar los datos que le llegaron incluso si está desordenado, similar a Selective Repeat.
2:59O puede descartarlos como lo hace Go-Back N. La RFC lo especifica este comportamiento.
3:05En TCP los ACKs son acumulativos, similar a Go-Back N.
3:09Así, el ACK number indica el byte más grande tal que todo lo anterior fue recibido con éxito.
3:15O sea, si se pierde un segmento intermedio así, solo vamos a enviar ACKs con ACK number hasta aquí,
3:23pues el ACK number debe indicar el último byte tal que todos los bytes anteriores llegaron con éxito.
3:29Así, el ACK de este segmento va a tener el mismo ACK number que el ACK number de este otro segmento.
3:36Aquí al detectarse pérdida, el emisor reenvía el segmento perdido.
3:40Como los ACKs son acumulativos, no importa si se pierde un ACK intermedio,
3:44pues el emisor sabe que cada ACK number indica que todos los bytes previos llegaron con éxito y puede avanzar su ventana sin problemas.
3:52Veamos cómo se maneja el control de flujo con r_window (ahora sí vamos a ver control de flujo woo)
3:58Cuando el receptor manda un ACK, este anuncia el espacio disponible en la ventana de recepción con r_window
4:03para que el emisor no mande más datos que los que puede procesar el receptor,
4:07y así evitar pérdida de segmentos por velocidad de procesamiento de datos.
4:11Para lograrlo, el emisor debe cumplir que:
4:14El último byte enviado menos el último byte para el cual recibimos un ACK sea menor o igual al espacio disponible en la ventana de recepción.
4:23Por el lado del emisor vamos a manejar el control de congestión.
4:27Como vimos anteriormente, el tamaño de la ventana de congestión cambia conforme se reciben ACKs y se experimentan timeouts.
4:34El tamaño de la ventana de congestión va a guiar el tamaño de la ventana de envío.
4:39Al comenzar el envío vamos a tener una ventana de tamaño 1 MSS y su tamaño va a aumentar de acuerdo a slow start.
4:45Luego, según ocurran eventos, el tamaño de la ventana va a cambiar según Congestion Avoidance, Fast Recovery o Slow Start.
4:53Sin embargo, debemos seguir cumpliendo con control de flujo, por lo que el emisor cumple que:
4:58El último byte enviado menos el último byte para el cual recibí un ACK sea menor o igual
5:03al mínimo entre el espacio disponible en la ventana de recepción y el tamaño de la ventana de congestión.
5:09De esta forma, control de flujo y control de congestión trabajan juntos.
5:14Veamos cómo funcionan los timers en TCP.
5:18La verdad es que las especificaciones de timers en TCP son algo vagas y permiten cierta libertad de implementación.
5:25La forma más simple de implementar timeouts es establecer un timer como en Go-Back N.
5:30Lo que sí especifica la RFC es cómo manejar el valor de los timeouts cuando hay retransmisión.
5:35Cada vez que se retransmite un segmento, el timeout duplica su valor.
5:40El emisor esperará hasta 3 timeouts, luego de los cuales simplemente se rinde.
5:45De esta forma, si timeout = t, luego de t segundos va a retransmitir el segmento y va a setear su timer a timeout = 2t.
5:55Si se vuelve a cumplir el timeout, retransmite y actualiza su timeout a 4t.
6:01Si luego de 4t segundos no llega el ACK, el emisor da por terminada la conexión.
6:06Al establecer una conexión, TCP inicializa el timeout en un valor fijo.
6:11Conforme la comunicación progresa, este tiempo se va ajustando
6:14usando la función SRTT para predecir el Round Trip Time o RTT del siguiente segmento,
6:21El RTT es el tiempo que le toma a un segmento llegar de origen a destino, más el tiempo que le toma a su ACK llegar desde vuelta.
6:29Para predecir el RTT usamos la función SRTT como sigue:
6:34Primero, fijamos un valor para predicted_RTT e inicializamos el timeout tal como se muestra aquí.
6:40Luego enviamos un segmento y medimos su RTT real.
6:45Con esto, usamos la función SRTT como se muestra y usamos su resultado para actualizar el predicted_RTT
6:52Finalmente, actualizamos el timeout como lo hicimos anteriormente.
6:57Así SRTT nos permite aproximar el siguiente RTT usando datos de RTT anteriores,
7:05Finalmente, tenemos el cierre de conexión.
7:08Aquí la gran diferencia es que luego de que el emisor envía el último ACK se queda esperando por un tiempo en el estado TIME_WAIT
7:15por si tuviese que reenviar el último ACK.
7:18Luego de que ese tiempo pasa, libera los recursos, poniendo fin efectivo a la conexión.
7:25En esta clase hemos visto:
7:26Cómo funciona TCP sin simplificar, con todos sus pasos.
7:30Cualquier duda o consulta, ¡no duden en contactar al equipo docente!