Clase teorica 04: L4: Intro, UDP y entrega confiable Flashcards

1
Q

¿Cuál es la función de la capa de transporte?

A

Objetivo: Comunicar aplicaciones (procesos) corriendo en diferentes hosts

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Cual es el desafio central de la capa de transporte?

A
  • 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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Definicion de capa de transporte.

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Donde se implementa L4?

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Envío de información en L4

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Diferencias entre Transporte y Red

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Protocolos de la capa de transporte

A
  1. TCP: Transport Control Protocol
  2. UDP: User Datagram Protocol
  3. Google QUIC *
    * Google QUIC: Protocolo muy reciente, híbrido, que veremos más adelante
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Características de cada uno de los protocolos de la capa de transporte

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Defina CONFIABILIDAD

A

Para nosotros sera la capacidad de asegurar que el segmento fue satisfactoriamente entregado en destino.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Caraterísticas y limitaciones del protocolo IP y su impacto sobre L4.

A

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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Misión de la capa de transporte (Objetivo)

A

EXTENDER la transmisión de IP de nivel de host a nivel de proceso (aka MUX/DEMUX).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Servicios provistos por TCP y UDP

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Vimos que TCP convierte un envíos no confiable sobre IP en una transferencia confiable entre procesos. Como lo hace? Que efecto colateral tiene?

A
¿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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

¿Qué es MUX/DEMUX?

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

¿Qué es un socket?

A
  • 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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Sockets y MUX/DEMUX

A

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)

  1. Arriba un segmento
  2. Se leé el campo en el header
  3. Se lo redirige al SOCKET indicado

MUX (src)

  1. Se divide el mensaje de App en segmentos
  2. Se agrega el header con sus identificadores
  3. Se lo pasa a la capa de red
17
Q

Números de puerto: ¿Qué es?

A

+ 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)

18
Q

SOCKETS y Números de puerto:

  • ¿Cómo se vinculan?
  • ¿Por qué es necesaria esta vinculación?
A

> Cada socket tiene un port number asociado

> Para redirigir los segmentos al (socket del) proceso correspondiente

19
Q

TCP, UDP, puertos y sockets

A

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

20
Q

Servidores web y TCP. Que sucede con cada nueva conexion? Que sucede con que sea HTTP no persistente?

A

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
21
Q

Si UDP no provee transferencia confiable de datos y TCP sí, ¿por qué alguien lo elegiría?

A
  1. 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
  2. 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
  3. 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
  4. Bajo overhead
    Tamano header TCP: 20 bytes
    Tamano header UDP: 8 bytes
22
Q

¿Qué Apps usan UDP?

A

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

23
Q

Estructura del datagrama UDP

A
SÓLO 4 CAMPOS
• src port (MUX/DEMUX) [16 bits]
• dst port (MUX/DEMUX) [16 bits]
• Length [16 bits]
• Checksum [16 bits]
24
Q

Checksum UDP: Cálculo

A

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

25
Q

Checksum UDP: ¿Redundancia?

A
  • 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
26
Q

¿Dónde y por qué se producen los errores?

A
  • Ruido electromagnético en el canal

* Escritura en la memoria de routers y switches

27
Q

¿Qué debe cumplir un canal para ser confiable?

A
  • Toda los datos arribaron a destino
  • En orden
  • Sin bits corruptos
28
Q

Automatic Repeat reQuest (ARQ). Que son?

A

Protocolos de computadoras que basan sus retransmisiones en respuestas del tipo ACK/NAK.

29
Q

ARQ: requisitos.

A
  1. 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
  2. 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)
  3. Retransmisión (reTx)
    • Si un paquete arriba con errores a destino, el origen lo retransmitirá.
30
Q

STOP-&-WAIT

A
  • 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