Capítulo 3: La Capa de Transporte Flashcards
¿Qué provee la capa de transporte?
¿En dónde se implementan los protocolos de capa de transporte? ¿Cuál es su trabajo?
La capa de transporte provee comunicación lógica entre aplicaciones.
Comunicación lógica se refiere a que desde la perspectiva de la aplicación, es como si los hosts estuviesen directamente conectados, pero físicamente no es así porque en el medio hay routers y enlaces.
Los protocolos de capa de transporte se implementan en los hosts, no en los routers. Su trabajo es convertir los mensajes a enviar en paquetes que se conocen como segmentos. Los segmentos se le pasan a la capa de red, que los transforma en datagramas y luego se envía a destino.
¿Cuál es la relación entre la capa de transporte y la capa de red?
La capa de transporte provee comunicación lógica entre aplicaciones (procesos), y la capa de red provee comunicación lógica entre hosts.
¿Qué hace el protocolo de transporte?
¿Qué servicios ofrece? ¿Están limitados?
El protocolo de transporte mueve la información hasta el borde de la capa de red y viceversa, pero no tiene nada que ver en cómo esa información viaja dentro de la red.
Puede ofrecer los siguientes servicios:
- [TRA] Transferencia de datos confiable (RDT): garantiza la llegada y la integridad de los datos.
- [CA] Caudal (throughput): garantizar una tasa mínima a la que el proceso de origen puede entregarle datos al proceso receptor.
- [SIN] Sincronización: permite garantizar un umbral de demora en la transmisión de los datos (que ningún bit tarde más de x ms en llegar a destino).
- [SE] Seguridad: permite encriptar la información, chequear que la información no haya sido alterada en el camino, autenticar los extremos, etc.
Algunos de los servicios que ofrece un protocolo de transporte están limitados por los servicios de la capa de red. Si la capa de red no puede garantizar los tiempos de demora o el bandwidth, tampoco lo puede hacer la capa de transporte.
¿Cuál es el protocolo de red de Internet?
El protocolo de red de Internet es IP. El modelo de servicio de IP es best-effort delivery service. Esto quiere decir que hace todo lo posible para entregar los segmentos, pero no garantiza nada. Por eso se dice que IP es un servicio no confiable.
¿Cuál es la principal responsabilidad de los protocolos UDP y TCP?¿Ambos las garantizan? ¿Hay algún servicio adicional que se provea?
La principal responsabilidad de los protocolos UDP y TCP es la de extender el servicio de entrega entre dos hosts a un servicio de entrega entre dos procesos corriendo en dichos hosts.
Esta extensión se llama transport-layer mutiplexing and demultiplexing.
Además, proveen de un chequeo de errores en los headers de los segmentos.
UDP sólo garantiza esas dos cosas (por eso es unreliable).
TCP provee más servicios, tal como la transferencia confiable de datos y el control de congestión.
¿A dónde entrega los datos la capa de transporte? ¿Qué es multiplexing y qué es demultiplexing?
¿Qué información se necesita para demultiplexar?
La capa de transporte le entrega los datos directamente al socket, no al proceso.
Cada socket tiene un id (el puerto), y para saber a qué socket debe entregarle, cada segmento tiene un set de campos donde se especifica este id.
Esta acción de entregar datos de la capa de transporte al socket se llama demultiplexing.
La acción de juntar pedazos de diferentes sockets, encapsularlos con un header para crear segmentos y pasárselos a la capa de red se llama multiplexing.
Extremo receptor: [capa de transporte] -> demultiplexing -> [socket] Extremo de origen: [socket] -> multiplexing -> [capa de red]
Para demultiplexar, en el header deben estar seteados los campos de número de puerto para el origen y el destino, para que la capa de transporte pueda fijarse en el puerto de destino a qué socket mandar el paquete.
El puerto de origen sirve por si se quiere responder algo.
¿Cómo se identifica un socket TCP?
Un socket TCP se identifica por cuatro campos:
- dirección IP de origen
- puerto de origen
- dirección IP de destino
- puerto de destino
A diferencia de UDP, si llegan dos segmentos con distinto source IP o source port, van a ser dirigidos a distintos sockets.
De un ejemplo de uso de UDP.
Un ejemplo de una app que usa UDP es DNS.
DNS envía una query y si no obtiene respuesta puede intentar enviarla de nuevo, o enviarla a otro servidor, o informar que no se obtuvo respuesta.
UDP ofrece servicios mínimos y no le agrega nada al protocolo IP. Entonces, ¿por qué razones un developer elegiría usar UDP antes que TCP?
Hay 4 razones por las cuales un developer elegiría usar UDP antes que TCP.
- Más control sobre qué datos se envían y cuándo: UDP no tiene control de congestión, apenas recibe información la empaqueta y la manda. TCP dejará información esperando si están muy cargados los enlaces. Además, TCP garantiza que todos los paquetes lleguen y que además lleguen ordenados, y se tomará el tiempo que necesite para recibir las confirmaciones de envío; y para aplicaciones en tiempo real, es poco eficiente.
- No establece ninguna conexión: Establecer conexión introduce delays.
- No mantiene estados de conexión: Permite que se puedan mantener más clientes activos en una aplicación que corre con UDP.
- Headers con bajo overhead: TCP tiene 20 bytes de header overhead, mientras que UDP tiene 8.
Las aplicaciones que no requieren de servicio confiable y requieren de baja latencia como DNS, juegos multijugadores, etc. usan UDP.
¿Es posible hacer una aplicación que se comunica con UDP y transporta datos de manera confiable?
Es posible hacer una aplicación que se comunica con UDP y transporta datos de forma confiable. Sólo se debe construir esa seguridad desde la misma aplicación, implementando un RDT (reliable data transfer, tal y como se hizo en el TP de la materia).
¿Cómo se detectan errores en un segmento recibido?
Para la detección de errores en un segmento recibido, se usa el checksum.
El checksum se usa para saber si bits dentro del segmento fueron alterados durante el transporte.
Al hacer el envío, se hace el complemento a 1 de la suma de las 16-bits words del segmento y se guarda en el campo de checksum.
Al recibir el paquete, se suman todos los campos de nuevo pero incluyendo el checksum. Si no hubo errores, el resultado van a ser todos 1s. Si hay algún 0 es que hubo un error en el transporte.
¿Qué son y en qué se basan los ARQ Protocols?
¿Qué capacidades requieren?
- Los ARQ (Automatic Repeat reQuest) protocols son los protocolos de transferencia de datos fiables basados en las retransmisiones.
- Se basan en retransmitir mensajes cuando estos no fueron recibidos correctamente.
- Por cada mensaje, el receptor da el OK o pide que se le repita.
Esto requiere de 3 capacidades:
1. Detección de Errores
2. Feedback del Receptor
3. Retransmisión
¿Qué es el protocolo rdt1.0?
El protocolo rdt1.0 es el protocolo de transferencia de datos fiable sobre un canal totalmente fiable. Es el caso trivial, donde el lado emisor espera una llamada de arriba y el lado receptor espera una llamada de abajo.
Como se tiene algo totalmente fiable, no existe la necesidad de realimentación, confirmación o control de congestión.
El protocolo rdt1.0 no es un protocolo ARQ.
¿Qué es el protocolo rdt2.0?
Explique su funcionamiento y la posible falla del protocolo. ¿Cómo se puede solucionar la falla?
El protocolo rdt2.0 es el protocolo de transferencia de datos fiables sobre un canal con errores de bit.
Los errores se producen en los componentes físicos de una red cuando el paquete se transmite, se propaga o accede a un buffer.
El protocolo rdt2.0 es un protocolo ARQ, requiere de:
- detección de errores
- retroalimentación del receptor (con ACK o NAK)
- retransmisión
Funcionamiento:
1. El lado emisor, envía datos y espera un ACK o NAK.
2. Si recibe un NAK, vuelve a enviar los datos.
3. ACK, queda a la espera de una llamada de la capa superior para volver a enviar datos.
No se envía ningún otro mensaje hasta no recibir el OK del último enviado. Es por esto que al protocolo rdt2.0 se lo conoce como stop-and-wait.
Una falla del modelo es que no considera que el paquete ACK o NAK puede estar corrompido. En ese caso, podría reenviarse información pero podría llevar a tener paquetes duplicados, porque no se sabe si lo que se recibe es una retransmisión o información nueva.
Esta falla puede solucionarse agregando un número de secuencia a la data del paquete, para poder compararlo con el anterior. (RDT 2.1)
¿Cómo se implementa RDT 2.2?
En RDT 2.2 se hace una modificación sobre RDT 2.1 donde en vez de mandar señales NAK, se manda una señal ACK por el último paquete bien recibido.
Un sender que recibe dos ACKs por el mismo paquete va a saber que el receptor no recibió bien el paquete que le sigue al que fue recibido doble. Entonces, ahora el receptor tiene que incluir el número de secuencia del paquete reconocido por ACK y el emisor tiene que chequearlo.
