Capa de Transporte

Juegos en Red - Grado en Diseño y Desarrollo de Videojuegos

Ruben Rodríguez
ruben.rodriguez@urjc.es

URJC

Natalia Madrueño
natalia.madrueno@urjc.es

URJC

Mario Manzano
mario.manzano@urjc.es

URJC

2026-09-09

URJC Logo DSLab Logo

Introducción

¿Qué es la Capa de Transporte?

La capa de transporte proporciona comunicación lógica entre procesos de aplicación que se ejecutan en diferentes hosts

Función principal:

  • Se ejecuta en hosts finales
  • No en el núcleo de la red
  • Divide mensajes en segmentos
  • Recompone segmentos en el receptor

Protocolos principales:

  • UDP: Protocolo minimalista
  • TCP: Protocolo complejo con garantías

block-beta
    columns 1
    
    A["<b>Capa de Aplicación</b><br/><br/>HTTP, HTTPS, FTP, SMTP<br/>DNS, DHCP, Telnet, SSH"]
    
    B["<b>Capa de Transporte</b><br/><br/>TCP, UDP<br/>Control de flujo y errores"]
    
    C["<b>Capa de Internet</b><br/><br/>IP, ICMP, ARP<br/>Enrutamiento, Direccionamiento"]
    
    D["<b>Capa de Acceso a la Red</b><br/><br/>Ethernet, WiFi, PPP<br/>Frames, MAC Address<br/>Control de acceso al medio"]
    
    classDef highlight fill:#ff9999,stroke:#cc0000,stroke-width:4px,color:#000
    classDef normal fill:#e1f5fe,stroke:#0277bd,stroke-width:2px,color:#000
    
    class B highlight
    class A,C,D normal

Ejemplo: Cliente-Servidor con UDP

sequenceDiagram
    participant A as Client A
    participant I as The Internet
    participant B as Server B
        
    A->>I: Paquete UDP 1 (IP destino: 8.8.8.8, puerto: 80)
    I->>B: Paquete 1 entregado
    
    A->>I: Paquete UDP 2 (IP destino: 8.8.8.8, puerto:80)
    I->>B: Paquete 2 entregado
    
    A->>I: Paquete UDP 3 (IP destino: 8.8.8.8, puerto:80)
    
    A->>I: Paquete UDP 4 (IP destino: 8.8.8.8, puerto:80)
    I->>B: Paquete 4 entregado (llega primero!)
    A->>I: Paquete UDP 5 (IP destino: 8.8.8.8, puerto:80)
    I->>B: Paquete 3 entregado (llega tarde!)

  • Paquete 5: perdido (~1% pérdida normal)
  • Paquete 4 llega antes que el 3
  • UDP no corrige orden ni pérdidas

Funciones Principales

1. Multiplexación y Demultiplexación

Multiplexación: Recoger información de diferentes sockets y enviarla por un único medio.

Demultiplexación: Recibir segmentos y enviarlos a los sockets correspondientes.

Identificación de sockets:

  • TCP: (IP y Puerto origen, IP y puerto destino)
  • UDP: (IP y puerto destino únicamente)

Puertos: Identificadores numéricos (1-65535)

  • Servidores: asignación manual y fija
  • Clientes: asignación aleatoria

graph LR
    subgraph "MULTIPLEXACIÓN"
        A1[Socket 1<br/>App A] --> M[Multiplexor<br/>Capa de Transporte]
        A2[Socket 2<br/>App B] --> M
        A3[Socket 3<br/>App C] --> M
        M --> N[Red<br/>Medio único]
    end
    
    subgraph "DEMULTIPLEXACIÓN"
        N2[Red<br/>Segmentos entrantes] --> D[Demultiplexor<br/>Capa de Transporte]
        D --> B1[Socket 1<br/>App A]
        D --> B2[Socket 2<br/>App B]
        D --> B3[Socket 3<br/>App C]
    end
    
    N -.->|Transmisión| N2
    
    classDef appClass fill:#e1f5fe,stroke:#0277bd,stroke-width:2px
    classDef muxClass fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef netClass fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    
    class A1,A2,A3,B1,B2,B3 appClass
    class M,D muxClass
    class N,N2 netClass

2. Transferencia Fiable

Características de una transferencia fiable:

  • No se corrompe ningún bit
  • No se pierde información (paquetes)
  • La información se entrega en orden correcto

Opciones de implementación:

  1. Usar protocolos fiables existentes (TCP)
  2. Implementar características propias sobre protocolo no fiable (UDP + lógica aplicación)

graph LR
    
    E[EMISOR] --> PC1[PROTOCOLO<br/>CONFIABILIDAD]
    PC1 --> MNF[MEDIO<br/>NO FIABLE<br/><br/>• Puede corromper bits<br/>• Puede perder paquetes<br/>• Puede desordenar]
    MNF --> PC2[PROTOCOLO<br/>CONFIABILIDAD]
    PC2 --> R[RECEPTOR]
    
    PC1 -.->|Implementa| MECH[• Detección de errores<br/>• Retransmisión<br/>• Control de flujo<br/>• Secuenciación<br/>• ACK/NACK<br/>• Timeouts]
    PC2 -.->|Implementa| MECH
    
    classDef endpointClass fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
    classDef protocolClass fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px
    classDef unreliableClass fill:#ffebee,stroke:#d32f2f,stroke-width:2px
    classDef reliableClass fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef mechClass fill:#fafafa,stroke:#616161,stroke-width:1px
    
    class E,R endpointClass
    class PC1,PC2 protocolClass
    class MNF unreliableClass
    class MECH mechClass

Otros conceptos

  • Control de flujo: Evita que el emisor sature al receptor limitando la velocidad de envío según la capacidad del destinatario
  • Control de congestión: Ajusta la velocidad de transmisión para evitar saturar la red cuando detecta congestión
  • Temporización: Garantiza un tiempo máximo de entrega de datos entre emisor y receptor a través de la red
  • Tasa de transferencia mínima: Garantiza una velocidad mínima de transmisión de datos para aplicaciones que requieren ancho de banda constante

UDP (User Datagram Protocol)

Características de UDP

Protocolo minimalista [RFC 768]:

  • Basado en best-effort (Fire-and-forget)
  • No orientado a conexión
  • Entrega no fiable y sin orden
  • Integridad básica (checksum)
  • Multiplexación y demultiplexación

Lo que NO proporciona:

  • Control de flujo
  • Control de congestión
  • Temporización
  • Tasa de transferencia mínima
  • Seguridad

sequenceDiagram
    participant A as Client A
    participant I as The Internet
    participant B as Server B
        
    A->>I: Paquete UDP 3 (IP destino: 8.8.8.8, puerto:80)
    Note over I: Paquete UDP 3 se pierde
    A->>I: Paquete UDP 4 (IP destino: 8.8.8.8, puerto:80)
    I->>B: Paquete 4 entregado (llega primero!)
    Note over B: No garantiza orden
    A->>I: Paquete UDP 5 (IP destino: 8.8.8.8, puerto:80)
    I->>B: Paquete 3 entregado (llega tarde!)

Estructura del Paquete UDP

packet-beta

    0-15: "Source Port"
    16-31: "Destination Port"
    32-47: "Length"
    48-63: "Checksum"

  • Longitud: Cabecera (8 bytes) + datos, hasta 65535 bytes
  • Checksum: Verificación de integridad
  • Estructura simple comparada con otros protocolos
  • 8 bytes de cabecera fijos.

Checksum UDP

Proceso de cálculo:

  1. Preparación: pseudo-cabecera IP + cabecera UDP + datos
  2. División en palabras de 16 bits
  3. Suma usando aritmética de complemento a uno
  4. Complemento del resultado → campo checksum

Verificación en receptor:

  • Mismo algoritmo incluyendo checksum recibido
  • Resultado esperado: 0xFFFF
  • Si difiere: datagrama descartado silenciosamente

Casos de Uso de UDP

Aplicaciones ideales para UDP:

  • Multimedia streaming: Tolerante a pérdidas, sensible a interrupciones
  • DNS: Respuestas rápidas necesarias
  • SNMP: Administración de red
  • Gaming online: Latencia baja crítica
  • QUIC/HTTP3: Base para protocolos modernos optimizados

Ejemplo: Implementar protocolo propio sobre UDP para juegos

  • Añadir número de paquete
  • Descartar paquetes fuera de orden
  • Ignorar duplicados
  • Sobrecarga mínima

TCP (Transmission Control Protocol)

Características de TCP

Protocolo confiable [RFC 9293]:

  • Orientado a conexión
  • Entrega fiable y ordenada (confiabilidad)
  • Control de flujo
  • Control de congestión
  • Multiplexación y demultiplexación

Lo que NO proporciona:

  • Temporización específica
  • Tasa mínima garantizada
  • Seguridad nativa (necesita TLS/SSL)

Trade-off: Confiabilidad y orden sobre velocidad pura

Estructura del Paquete TCP

packet-beta
  0-15: "Source Port"
  16-31: "Destination Port"
  32-63: "Sequence Number"
  64-95: "Acknowledgment Number"
  96-99: "Data Offset"
  100-105: "Reserved"
  106: "URG"
  107: "ACK"
  108: "PSH"
  109: "RST"
  110: "SYN"
  111: "FIN"
  112-127: "Window"
  128-143: "Checksum"
  144-159: "Urgent Pointer"
  160-191: "Options (variable)"

  • Sequence number: Número que identifica la posición del primer byte de datos en el segmento dentro del flujo de datos.
  • Ack number: Indica el próximo número de secuencia que el receptor espera recibir. Confirma la recepción correcta de datos anteriores.
  • Window: Implementa control de flujo (bytes que receptor acepta)
  • checksum: Muy similar a UDP.
  • Tamaño variable de 20 a 60 bytes.

Mecanismos de Confiabilidad

Los mecanismos de confiabilidad en TCP garantizan que los datos lleguen correctamente y en orden.

Números de secuencia y ACKs:

  • Cada byte tiene número único
  • Cuando enviamos información, está identificada por un número de secuencia (SEQ)
  • Además, esperamos confirmación de que se ha recibido correctamente (ACK)
  • ACKs acumulativos (ACK para byte N confirma hasta N-1)
  • Los ACKs y SEQs permiten detectar datos perdidos, duplicados o desordenados

sequenceDiagram
    participant E as Emisor
    participant R as Receptor
    
    Note over E,R: Conexión ya establecida, seq inicial=100
    
    E->>R: seq=100, data="Hola" (4 bytes)
    Note over R: Recibe
    R->>E: ACK=104 ("Espero byte 104")
    Note over R: Confirma
    
    E->>R: seq=104, data=" mundo!" (7 bytes)  
    R->>E: ACK=111 ("Espero byte 111")
    
    E->>R: seq=111, data=" TCP" (4 bytes)
    E->>R: seq=115, data=" rocks" (6 bytes)
    Note over R: Recibe ambos correctamente
    Note over R: ACK acumulativo confirma todo
    R->>E: ACK=121 ("Recibí todo hasta byte 120")

Detección de pérdidas

Pérdidas por timeout

sequenceDiagram
    participant E as Emisor
    participant R as Receptor
    E ->> X: seq=100, data="A", Paquete perdido
    Note over E: Timeout de seq:100, reenvío
    E ->> R: seq=100, data="A",

  • Si no recibe ACK en tiempo determinado → asume pérdida y retransmite

Pérdidas por ACKs duplicados

sequenceDiagram
    participant E as Emisor
    participant R as Receptor
    E ->> X: seq=100, data="A", Paquete perdido
    E ->> R: seq=101, data="B"
    E ->> R: seq=102, data="C"
    E ->> R: seq=103, data="D"
    R ->> E: ACK=100
    R ->> E: ACK=100
    R ->> E: ACK=100
    Note over E,R: Retransmisión rápida
    E ->> R: seq=100, data="A"

  • 3 ACKs duplicados → Fast Retransmit inmediato

Control de Flujo

El control de flujo en TCP es un mecanismo que evita que el emisor envíe más datos de los que el receptor puede procesar.

sequenceDiagram
    participant E as Emisor
    participant R as Receptor
    
    Note over R: Buffer: 4KB libres
    R->>E: ACK=1000, Window=4096
    E->>R: seq=1000, data=2KB
    Note over R: Buffer: 2KB libres
    R->>E: ACK=3000, Window=2048
    E->>R: seq=3000, data=2KB
    Note over R: Buffer: 0KB libres (lleno)
    R->>E: ACK=5000, Window=0
    Note over E: Detiene envío, inicia probe timer

  • Receptor informa de su capacidad disponible, y se define:
  • VentanaRecepcion = BufferRecepcion - (UltimoByteRecibido - UltimoByteLeido)
  • El emisor se limita a esta ventana
  • Si la capacidad es 0, se espera un tiempo y se vuelve a probar.

Control de Congestión

El control de congestión en TCP es un mecanismo que ajusta automáticamente la velocidad de envío (ventana de congestión) para evitar saturar la red cuando detecta pérdida de paquetes o retardos.

Ventana de congestión

  • Variable del emisor
  • Bytes máximos en “el aire” (enviados sin ACK)
  • Tasa efectiva = min(VentanaCongestion, VentanaRecepcion)

Eventos de Congestión (Pérdidas)

  • Timeout -> Modo slow start

    • Pérdida severa
    • Ventana → 1 MSS

  • 3 ACKs duplicados -> Modo congestion avoidance

    • Pérdida moderada
    • Ventana → mitad

Mecanismos de control de congestión

Slow start

sequenceDiagram
    participant E as Emisor
    participant R as Receptor
    
    Note over E: Slow Start: cwnd=1 MSS
    E->>R: seq=1000, MSS=1KB
    R->>E: ACK=2000
    Note over E: cwnd=2 MSS
    E->>R: seq=2000, MSS=1KB
    E->>R: seq=3000, MSS=1KB
    R->>E: ACK=4000
    Note over E: cwnd=4 MSS (crecimiento exponencial)
    Note over E: ... continúa hasta threshold o detectar pérdida ...

Duplicar ventana por cada RTT

Congestion Avoidance

sequenceDiagram
    participant E as Emisor
    participant R as Receptor
    
    Note over E: Congestion Avoidance: cwnd=1 MSS

    E->>R: seq=1000, MSS=1KB
    R->>E: ACK=2000

    Note over E: cwnd=2 MSS

    E->>R: seq=2000, MSS=1KB
    E->>R: seq=3000, MSS=1KB
    R->>E: ACK=4000

    Note over E: cwnd=3 MSS (crecimiento lineal)
    Note over E: ... continúa hasta detectar pérdida ...

Incrementar en 1 la ventana en cada RTT

Handshake de Tres Fases

sequenceDiagram
    participant CS as Cliente Socket
    participant SS as Server Socket (listen)
    participant NS as Nuevo Socket
    
    Note over CS: Estado: CLOSED
    Note over SS: Estado: LISTEN
    CS->>SS: SYN=1, seq=x
    Note over CS: Estado: SYN_SENT
    Note over SS: accept() crea nuevo socket
    SS->>NS: Deriva conexión
    Note over NS: Estado: SYN_RCVD
    NS->>CS: SYN=1, ACK=1, seq=y, ack=x+1
    Note over CS: Estado: ESTABLISHED
    CS->>NS: ACK=1, seq=x+1, ack=y+1

  • Se negocian: MSS, opciones de ventana, extensiones TCP
  • Los flags de las cabeceras también consumen bits.
  • El serverSocket está en el servidor,
  • una vez se establece la comunicación ambos sockets son iguales.

Terminación de Conexión

sequenceDiagram
    participant C as Cliente
    participant S as Servidor
    
    Note over C,S: Conexión establecida
    C->>S: FIN=1, seq=x
    Note over C: Estado: FIN_WAIT_1
    S->>C: ACK=1, ack=x+1
    Note over C: Estado: FIN_WAIT_2
    S->>C: FIN=1, ACK=1, seq=y
    Note over S: Estado: LAST_ACK
    C->>S: ACK=1, ack=y+1
    Note over C: Estado: TIME_WAIT
    Note over C: Espera 2*MSL
    Note over C,S: CLOSED

  • Cada extremo debe enviar su propio FIN y recibir confirmación,
  • permitiendo cierre unidireccional (half-close).
  • El cliente espera 2*MSL para asegurar que su último ACK llegó,
  • manejando retransmisiones tardías antes del cierre definitivo.

Equidad y Coexistencia

TCP es “fair”:

  • N conexiones TCP comparten enlace equitativamente
  • Cada una obtiene ~R/N del ancho de banda R
  • Ver ejemplos en jergames (Bandwidth distribution)

Limitaciones:

  • UDP no implementa control → puede monopolizar
  • Aplicaciones con múltiples conexiones TCP
  • Conexiones con menor RTT tienen ventaja

Comparativa TCP vs UDP para Videojuegos

Cuándo usar…

UDP

Requisitos para UDP:

  • Latencias < 50ms
  • Actualizaciones frecuentes
  • Información nueva más valiosa que la vieja

Ventajas:

  • Cabeceras pequeñas
  • Sin tráfico de control
  • Servidor necesita menos recursos
  • No mantiene estado

Ejemplos: Shooters (Counter-Strike), juegos de lucha

TCP

Requisitos para TCP:

  • Tolerancia 100-200ms latencia
  • Entrega ordenada garantizada
  • Detección y corrección de errores


Consideraciones:

  • Bloqueo cabeza de línea
  • Latencias variables por retransmisiones
  • Mayor tráfico de red


Ejemplos: MMORPGs (World of Warcraft), juegos por turnos

Ejemplos Concretos

World of Warcraft (TCP):

  • Hechizos necesitan entrega garantizada
  • Actualizaciones de inventario críticas
  • Estado de misiones consistente
  • MMORPGs toleran 100-200ms

Counter-Strike (UDP):

  • Retroalimentación inmediata crítica
  • Actualizaciones posición/disparos
  • Técnicas de interpolación en cliente
  • Mitiga efecto paquetes perdidos

Resumen

Puntos Clave

  • La capa de transporte proporciona comunicación lógica entre procesos
  • UDP: Minimalista, best-effort, no orientado a conexión
  • TCP: Confiable, ordenado, orientado a conexión
  • Multiplexación: Múltiples sockets por un medio
  • Control de flujo: Evita saturar al receptor
  • Control de congestión: Responde a condiciones de red
  • Trade-off fundamental: Confiabilidad vs velocidad
  • Elección protocolo depende de requisitos aplicación