alvaro.gonzalezsotillo@educa.madrid.org

TCP y UDP

Álvaro González Sotillo

Created: 2024-09-08 dom 17:53

1. Introducción

Figura 1: Esquema de niveles de red

  • TCP y UDP son de la capa de transporte
  • Es la primera que une dos entidades (procesos), en vez de dos hosts
  • Suele ser la primera capa visible para los programadores de aplicaciones
    • IP se puede considerar la frontera entre los administradores y los programadores

2. UDP

  • User Datagram Protocol
  • Funciones:
    • Entregar un datagrama entre el emisor y receptor (procesos)
    • Detección de errores

2.1. Formato de trama UDP

2.2. Características de UDP

  • Los datagramas pueden llegar en un orden diferente al enviado (si IP elige rutas distintas para ellos)
  • El emisor no tiene la seguridad de que los datagramas llegan al receptor
  • Por tanto, no se utilizan conexiones ni es confiable. Cada datagrama se envía de forma independiente.
  • ¿Cuántos puertos hay?
  • ¿Cuál es el tamaño máximo de un datagrama UDP?

3. TCP

  • Transmission Control Protocol
  • Asegura que la transmisión se realiza por un medio fiable
  • Garantiza la recepción de los mensajes en orden correcto
  • Garantiza al emisor que los mensajes llegan correctamente al receptor
  • Por tanto, es orientado a conexión y confiable.

3.1. Ventana y corrección de errores

  • TCP necesita confirmación de cada mensaje enviado
    • Para garantizar la confiabilidad
  • Opciones:
  • La parada y espera es más simple, pero desaprovecha ancho de banda

image/svg+xml 1 ACK 1 2 ACK 2 3 ACK 3

Figura 2: Ejemplo de parada y espera

image/svg+xml 1 2 3 ACK 3 4 5 6 ACK 4 5 6 7

Figura 3: Ejemplo de piggybacking con ventana 3

4. Sequence number y Acknowledgment number

  • TCP intenta que la comunicación se asemeje a un flujo de bytes
    • Todos los bytes que entran por un extremo
    • … deben salir por el otro lado
  • En cada paquete se envía
    • el número de secuencia del primer byte transmitido en el paquete
    • el número de secuencia del siguiente byte que se espera

4.1. Estado de la conexión

  • Cada extremo de la comunicación debe saber:
    • Cuál es su siguiente byte a enviar (sequence number)
    • Cuál es su siguiente byte a recibir (acknowledgment number)
  • Además, también lleva la cuenta de su opinión acerca del sequence number y del acknowledgment number del otro extremo

image/svg+xml Mi SN - AN | Su SN - AN Suponemos que todos los paquetes son de 10 bytes 0 - 0 10 - 0 0 - 0 0 - 0 0 - 10 0 - 10 10 - 10 10 - 10 20 - 10 10 - 10 30 - 10 20 - 10 10 - 30 0 - 0 10 - 10 0 - 0 10 - 10 10 - 10 Mi SN - AN | Su SN - AN 0 - 0 10 - 0 10 - 0 10 - 20 20 - 10 30 - 10 10 - 30 30 - 10 20 - 30 30 - 20 20 - 30

Figura 4: Sequence number y acknowledgment number

4.2. Corrección de errores

  • Si se recibe un sequence number posterior a nuestro acknowledgment number
    • Es un paquete posterior al que esperamos
      • Se puede guardar en la capa TCP hasta que lleguen los anteriores
      • O se puede ignorar, y reclamar los paquetes perdidos enviando un acknowledgment number menor que el que espera el otro
    • El otro lado reenviará los paquetes necesarios

image/svg+xml Mi SN - AN | Su SN - AN Suponemos que todos los paquetes son de 10 bytes 0 - 0 10 - 0 0 - 0 0 - 0 0 - 10 0 - 10 10 - 10 10 - 10 20 - 10 10 - 10 30 - 10 20 - 10 10 - 10 20 - 10 10 - 10 30 - 20 20 - 20 0 - 0 10 - 10 0 - 0 10 - 10 10 - 10 20 - ¿10? 20 - 10 10 - 20 30 - 20 20 - 10 20 - 20 Mi SN - AN | Su SN - AN 0 - 0 10 - 0 10 - 0 ¿30? - 10 10 - 10 20 - 20 20 - 30 20 - 20 30 - 20 20 - 30 30 - 30 30 - 20 30 - 30 30 - 30

Figura 5: Llegada de un paquete posterior al esperado

  • Si se recibe un sequence number anterior a nuestro acknowledgment number
    • Es un paquete ya recibido (se habrá duplicado)
    • Por tanto, se ignora
  • Si me llega un acknowledgement number menor que los bytes que yo he enviado
    • Reenviaré a partir de dicho acknowledgement number

image/svg+xml Mi SN - AN | Su SN - AN Suponemos que todos los paquetes son de 10 bytes 0 - 0 10 - 0 0 - 0 0 - 0 0 - 10 0 - 10 10 - 10 10 - 10 20 - 10 10 - 10 20 - 10 10 - 10 20 - 20 0 - 0 10 - 10 0 - 0 10 - 10 20 - ¿10? 20 - 10 10 - 20 30 - 20 20 - 10 20 - 20 Mi SN - AN | Su SN - AN 0 - 0 10 - 0 10 - 0 20 - 20 20 - 30 20 - 20 30 - 20 20 - 30 30 - 30 30 - 20 30 - 30 30 - 30 10 - 0 20 - 10

Figura 6: El otro lado informa de la pérdida de algún paquete

  • Si no tengo confirmación de un paquete enviado tras un timeout
    • Reenviaré el paquete

image/svg+xml Mi SN - AN | Su SN - AN Suponemos que todos los paquetes son de 10 bytes 0 - 0 10 - 0 0 - 0 0 - 0 0 - 10 0 - 10 10 - 10 10 - 10 20 - 10 10 - 10 20 - 10 0 - 0 10 - 10 0 - 0 10 - 10 20 - 10 30 - 10 10 - 10 Mi SN - AN | Su SN - AN 0 - 0 10 - 0 10 - 0 10 - 20 10 - 30 20 - 10 30 - 10 10 - 30 20 - 30 30 - 10 30 - 20 20 - 30 Timeout } 10 - 10 10 - 10

Figura 7: Paquete no confirmado tras un timeout

5. Mensajes TCP

5.1. Establecimiento de conexión

  1. Un servidor escucha en un puerto
  2. Un cliente envía una solicitud de conexión
  3. El servidor responde con una aceptación de la conexión
  4. El cliente acepta la aceptación

image/svg+xml Client Server SYN seq=x SYN-ACK ack=x+1 seq=y ACK ack=y+1 seq=x+1 [data] Fuente: By Snubcube

5.2. Estados TCP

image/svg+xml CLOSED (Start) LISTEN/- CLOSE/- LISTEN SYNRECEIVED SYNSENT CONNECT/ (Step 1 of the 3-way-handshake) SYN SYN/SYN+ACK (Step 2 of the 3-way-handshake) unusual event client/receiver path server/sender path RST/- SYN/SYN+ACK (simultaneous open) SYN+ACK/ACK (Step 3 of the 3-way-handshake) Data exchange occurs ESTABLISHED FIN/ACK ACK/- CLOSE/- SEND/ SYN CLOSE/ FIN CLOSE/ FIN CLOSING TIME WAIT CLOSED FIN WAIT 1 FIN WAIT 2 CLOSE WAIT LAST ACK CLOSE/ FIN FIN/ACK FIN+ACK/ACK ACK/- FIN/ACK Timeout (Go back to start) Active CLOSE Passive CLOSE ACK/- ACK/- Fuente:By Scil100

6. Puertos

  • Se llama puerto a la dirección de nivel de transporte en
    • TCP
    • UDP
  • La asignación de puertos se realiza según el RFC 1700
Well-known ports 0 - 1023 Solo para el administrador
Registered ports 1024 - 49151 Generalmente, servicios menos críticos
Dynamic ports 49152 to 65535 Asignables a los clientes

6.1. Asignación de puertos

  • Servidor: El proceso escucha en un puerto conocido
    • Ejemplos: 80 para HTTP, 25 para SMTP…
    • Lista de well known ports en el fichero /etc/services
  • Cliente: El cliente inicia una conexión un servidor.
    • El sistema le asigna un puerto no utilizado cualquiera
    • Generalmente, un puerto dinámico
    • El cliente también puede solicitar un puerto, pero es poco frecuente

6.2. Comando netstat

  • Informa de
    • Las conexiones TCP y UDP activas
    • Los programas escuchando en puertos TCP y UDP
  Linux Windows
Conexiones TCP -t -p tcp
Conexiones UDP -u -p udp
Proceso -p -o
No traducir direcciones -n -n
Escuchando -l  
Escuchando y establecidas -a -a
  • Si no está netstat, se puede usar ss
    • ss --process --numeric --tcp --all

6.2.1. Ejercicio

  • Comprueba qué conexiones están establecidas en tu ordenador
  • Comprueba a qué direcciones está conectado tu ordenador
  • Comprueba qué puertos admiten conexiones
  • Comprueba qué procesos admiten conexiones

6.3. Comando nc

6.3.1. Ejercicio

  • Pon a netcat a escuchar en un puerto
  • Haz que un compañero se conecte a ese puerto
  • Utiliza netcat como chat.

6.3.2. Youtube, 1990

nc towel.blinkenlights.nl 23

6.3.3. Gmail, 1990

telnet bbs.fozztexx.com

7. Direcciones de escucha

  • Cuando un proceso escucha en un puerto, también elige en qué dirección de red escucha

  • La dirección IP se puede utilizar como un firewall rudimentario

    Dirección Efecto
    0.0.0.0 Escucha en todas las direcciones IP accesibles
    127.X.X.X Escucha en una dirección local
    X.X.X.X Escucha en una interfaz de red concreta
  • No todas las combinaciones son posibles
    • Es posible escuchar en el mismo puerto en 127.X.X.X y en X.X.X.X
    • 0.0.0.0 no es compatible con ningún otro

7.1. Posibilidades

  • El servidor está accesible a todo el mundo
  • El servidor solo está disponible desde la máquina local (por ejemplo email local)
  • El servidor solo está disponible por una de las interfaces de red
  • Diferentes servidores en diferentes interfaces de red

7.2. ¿Más de un proceso escuchando en el mismo puerto?

  • Dependiendo de la versión de Linux/Windows, más de un proceso puede escuchar en el mismo puerto
  • Se hace para repartir mejor múltiples conexiones de clientes entre las CPU del servidor
SO_REUSEPORT (since Linux 3.9)

Permits multiple AF_INET or AF_INET6 sockets to be
bound to an identical socket address. This option
must be set on each socket (including the first
socket) prior to calling bind(2) on the socket. To
prevent port hijacking, all of the processes
binding to the same address must have the same
effective UID. This option can be employed with
both TCP and UDP sockets.

8. TCP vs UDP

  • TCP es un medio de transmisión asegurado
    • Las aplicaciones que usan TCP no envían paquetes, sino bytes.
    • TCP decide cuando enviar un paquete (las aplicaciones pueden opinar)
    • Consume más CPU y memoria, por la ventana de emisión y los reenvíos
    • Reduce la transferencia útil
  • UDP es más eficiente
    • No necesita mantener conexión, ni reordenar paquetes, ni retransmitir paquetes
    • Las aplicaciones son conscientes de que se envían paquetes, no bytes.
    • En redes con pocos errores, puede ser más adecuado
    • Interesante cuando se necesita mucha transferencia útil pero no importa perder algún paquete (voz, vídeo)

8.1. TCP Joke

  1. Hello, would you like to hear a TCP joke?
  2. Yes, I'd like to hear a TCP joke.
  3. OK, I'll tell you a TCP joke.
  4. OK, I'll hear a TCP joke.
  5. Are you ready to hear a TCP joke?
  6. Yes, I am ready to hear a TCP joke.
  7. OK, I'm about to send the TCP joke. It will last 10 seconds, it has two characters, it does not have a setting, it ends with a punchline.
  8. OK, I'm ready to hear the TCP joke that will last 10 seconds, has two characters, does not have a setting and will end with a punchline.
  9. I'm sorry, your connection has timed out… …Hello, would you like to hear a TCP joke?

8.2. UDP Joke

  • Lo anterior era una broma de TCP. No me importa si la pillas o no.

9. Referencias