Clase teorica 04: L4: Intro, UDP y entrega confiable Flashcards
¿Cuál es la función de la capa de transporte?
Objetivo: Comunicar aplicaciones (procesos) corriendo en diferentes hosts
Cual es el desafio central de la capa de transporte?
- La red puede perder paquetes o corromper datos
- Necesidad: Poder llevar a cabo la comunicación más allá de las limitaciones de la red
Desafío complementario
Evitar la congestion > Controlar el throughput
Definicion de capa de transporte.
Definición #1
La capa de transporte provee una comunicación lógica entre procesos corriendo en diferentes hosts
Definición #2: Comunicación lógica
Los procesos se comunican como si estuvieran directamente conectados (o incluso en le mismo host)
Definición #3: MUX/DEMUX
EXTENDER la transmisión de IP de nivel de host a nivel de proceso
Donde se implementa L4?
Solo en los end systems.
Routers, SW y su relación con L4
• No necesitan L4 para operar
• No implementan L4
• L4 es invisible para ellos
Envío de información en L4
- Recibe mensajes de capa de App
- Los transforma en segmentos (mensajes de capa transporte)
- A cada segmento se le agrega un header L4
- El segmento es encapsulado en un paquete de L3
Diferencias entre Transporte y Red
Capa de Transporte
• Comunicación lógica proceso a proceso
• L4 puede ofrecer diferentes servicios
• Servicios: puede proveerlos por más que no los brinde la red
Capa de red
• Comunicación lógica host a host
Protocolos de la capa de transporte
- TCP: Transport Control Protocol
- UDP: User Datagram Protocol
- Google QUIC *
* Google QUIC: Protocolo muy reciente, híbrido, que veremos más adelante
Características de cada uno de los protocolos de la capa de transporte
Características de UDP
> Sin garantía de entrega (no confiable)
> Sin conexión
>Datagramas (aunque Kurose también los llama segmentos)
Características de TCP
> Garantía de entrega (Confiable)
> Con conexión
> Segmentos
Defina CONFIABILIDAD
Para nosotros sera la capacidad de asegurar que el segmento fue satisfactoriamente entregado en destino.
Caraterísticas y limitaciones del protocolo IP y su impacto sobre L4.
Características
- Brinda comunicación entre hosts
- Envíos de máximo esfuerzo (sin garantía de entrega)
Impacto sobre L4
No garantiza que los segmentos arriben - A destino (máximo esfuerzo) - En orden - Integros > Sin comprobación de errores > bits pueden haber sido modificados (sin intención maliciosa)
Misión de la capa de transporte (Objetivo)
EXTENDER la transmisión de IP de nivel de host a nivel de proceso (aka MUX/DEMUX).
Servicios provistos por TCP y UDP
Ambos
> MUX/DEMUX
> Control de integridad presente en el header (Checksum)
UDP
> No es confiable
> Solo provee control integridad (opcional del SO)
TCP: Convierte un envíos no confiable sobre IP en una transferencia confiable entre procesos
Vimos que TCP convierte un envíos no confiable sobre IP en una transferencia confiable entre procesos. Como lo hace? Que efecto colateral tiene?
¿Cómo lo hace? > Entrega confiable por medio de - Control de flujo - Seq Numb. + ACKs - timers
> Además provee control de congestion
Obviamente: Más funcionalidades agregan mayor complejidad
¿Qué es MUX/DEMUX?
Misión L4
EXTENDER la transmisión de IP de nivel de host a nivel de proceso
Funcionamiento L4
Entregar los segmentos recibidos a la aplicación correspondiente
¿Qué es un socket?
- SOCKET: Interfaz entre las Apps y la red
- Las Apps envían y reciben mensajes a través de los SOCKETS
SOCKET
• Interfaz de programación App
• Integrada a programa de que usa la red
Sockets y MUX/DEMUX
App L4
- L4 no envía los mensajes directamente a la App
- Interacción vía SOCKET
Detalle SOCKETS
- Habrá un SOCKET por cada proceso
- Cada SOCKET tendrá un identificador único
Detalles L4
- El header L4 dispone de campos para MUX/DEMUX
DEMUX (dst)
- Arriba un segmento
- Se leé el campo en el header
- Se lo redirige al SOCKET indicado
MUX (src)
- Se divide el mensaje de App en segmentos
- Se agrega el header con sus identificadores
- Se lo pasa a la capa de red
Números de puerto: ¿Qué es?
+ Campo del header para llevar a cabo MUX/DEMUX
+ Existe un campo para indicar el SOCKET en cada extremo
> (src port, dst port)
+ Campo de 16-bit (0-65535)
SOCKETS y Números de puerto:
- ¿Cómo se vinculan?
- ¿Por qué es necesaria esta vinculación?
> Cada socket tiene un port number asociado
> Para redirigir los segmentos al (socket del) proceso correspondiente
TCP, UDP, puertos y sockets
UDP sin conexión
+ SOCKET completamente identificado por una 2-tupla
> (src_ip, src_port)
+ Entonces, ¿Para qué tienen campo origen?
> Para poder responder al remitente
TCP con conexión
+ SOCKET identificado por una 4-tupla
> (src_ip,dst_ip, src_port, dst_port)
+ DEMUX: Utiliza los 4 valores de la 4-tupla
Servidores web y TCP. Que sucede con cada nueva conexion? Que sucede con que sea HTTP no persistente?
Crean un nuevo proceso por cada nueva conexión (fork)
HTTP no persistentes
- Depende del CLI
- Nueva conexión TCP se crea y cierra por cada HTTP GET
- Impacto severo en la performance
Si UDP no provee transferencia confiable de datos y TCP sí, ¿por qué alguien lo elegiría?
- Control en el envío de datos
• El envío de los datos de la App a la red es casi inmediato
• Diferencias con TCP
> Control de congestión regula la tasa de Tx
> reTx la información hasta que llegue satisfactoriamente a destino (sin importar cuanto tiempo/reTx esto demore)
• Aplicaciones de tiempo real en general no necesitan tener reTx
• Conclusión: TCP no es un buen método para estas App - Sin establecimiento de la conexión
• TCP usa three-way handshake antes del envío de datos
• UDP envía datos sin ningún preámbulo
• Ahora los tiempo de establecimiento de conexión
• Ejemplo en DNS: Motivo por el cual utiliza UDP - Sin estados de conexión
• Mantener la conexión tiene un impacto en el SO (estados, buffers, mantener variables: Seq Numb., ACKs, Ctrl Cong)
• SVRs pueden manejar mayor cantidad de usuarios en UDP que en TCP (Ejemplo: DNS)
• También es útil en IoT donde las capacidades son limitadas - Bajo overhead
Tamano header TCP: 20 bytes
Tamano header UDP: 8 bytes
¿Qué Apps usan UDP?
Protocolos de ruteo (RIP, OSPF)
Si se pierde un mensaje no pasa nada, un tiempo después llegará una nueva actualización
Mensajes de control de red (SNMP)
Bajo impacto en los dispositivos de red por no mantener conexión
Estructura del datagrama UDP
SÓLO 4 CAMPOS • src port (MUX/DEMUX) [16 bits] • dst port (MUX/DEMUX) [16 bits] • Length [16 bits] • Checksum [16 bits]
Checksum UDP: Cálculo
Procedimiento
1. Fraccionamiento
> Se fracciona el datagrama en palabras de largo 16 bits
2. Suma mod16
> Suma mod16 de todas las palabras del mensaje
3. Complemento A1
> Complemento A1 del resultado de la suma
Checksum UDP: ¿Redundancia?
- Capas inferiores pueden proveer control de errores
- Por ejemplo, Ethernet (L2) provee comprobación de errores
- Pero no es ley para todas las tecnologías de enlace
- Entonces, no se puede asegurar comprobación de errores a lo largo de todo el path
- Por esto existe el Checksum UDP
¿Dónde y por qué se producen los errores?
- Ruido electromagnético en el canal
* Escritura en la memoria de routers y switches
¿Qué debe cumplir un canal para ser confiable?
- Toda los datos arribaron a destino
- En orden
- Sin bits corruptos
Automatic Repeat reQuest (ARQ). Que son?
Protocolos de computadoras que basan sus retransmisiones en respuestas del tipo ACK/NAK.
ARQ: requisitos.
- Detección de errores
• Es necesario detectar la existencia de bits cambiados
• ¿Cómo?
> Mediante técnicas que agregan bits al envío del mensaje - Notificación del receptor
– src y dst se encuentran en diferentes end systems
– Probablemente lejanos el uno del otro
– Única forma de que src conozca si dst recibió el mensaje es por medio de una notificación explícita (acuse de recibo)
– Acuses de recibo
> Positivos (Acknowledgement, ACKs)
> Negativos (Negative Acknowledgement, NAKs) - Retransmisión (reTx)
• Si un paquete arriba con errores a destino, el origen lo retransmitirá.
STOP-&-WAIT
- Cuando esta esperando por ACK/NAK, la FSM es bloqueante.
- No sale de ese estado hasta recibir ACK
- No se pueden enviar más datos desde la App en ese momento
