Saltar al contenido
0xrcosRyan Camargo — home
Todas las publicaciones
networking~7min readRyan Camargo

Notas de TCP/IP: Las Cuatro Capas, el Handshake y la Lectura de un Paquete

Notas de estudio sobre el modelo TCP/IP — las cuatro capas, el handshake de tres vías, los estados TCP y una visión práctica de la lectura de una captura de paquetes con tcpdump y tshark.

#networking#tcp#ip#osi

Nota: Este es un contenido de marcador de posición de muestra creado para demostrar el blog. Reemplázalo con tu propio escrito.

Estas son notas de trabajo a las que suelo volver cada vez que necesito explicar TCP/IP a alguien — incluyéndome a mí mismo. No son exhaustivas; son las partes que, en mi experiencia, explican realmente el 90% del comportamiento que se ve en la práctica.

Las Cuatro Capas

El modelo TCP/IP colapsa el modelo OSI de siete capas en cuatro. En la práctica, este es el modelo que realmente utiliza internet.

Capa Ejemplos A qué responde
Aplicación HTTP, SSH, DNS, SMTP, TLS "¿Qué nos estamos diciendo el uno al otro?"
Transporte TCP, UDP, QUIC "¿Cómo hacemos esto fiable/rápido?"
Internet IP (v4/v6), ICMP "¿Cómo llegamos de A a B?"
Acceso a red Ethernet, Wi-Fi, ARP "¿Cómo llegamos al siguiente salto?"

Un movimiento mental útil: cada capa envuelve a la de arriba. Una solicitud HTTP se convierte en un segmento TCP, que se convierte en un paquete IP, que se convierte en un trama Ethernet. En el extremo receptor, cada capa desenvuelve y pasa la carga útil hacia arriba.

El Handshake de Tres Vías

TCP es orientado a la conexión. Antes de que fluya cualquier dato de la aplicación, los dos extremos deben acordar una secuencia de números y un conjunto de capacidades. Este es el handshake de tres vías:

        Cliente                                 Servidor
          |                                       |
          |  ----- SYN, seq=x --------------->    |
          |                                       |
          |  <---- SYN+ACK, seq=y, ack=x+1 ----  |
          |                                       |
          |  ----- ACK, ack=y+1 -------------->    |
          |                                       |
          |  ===== datos de aplicación =========> |
          |                                       |

En palabras:

  1. El cliente envía SYN con un número de secuencia inicial x.
  2. El servidor responde con SYN+ACK, su propio número de secuencia inicial y, y un ack de x+1.
  3. El cliente responde con ACK y ack=y+1. La conexión ahora está ESTABLISHED (ESTABLECIDA).

Los números de secuencia existen para que cada lado pueda reconocer lo que ha recibido y detectar lagunas. No son "números de paquete" — son contadores de bytes, y se reinician.

Banderas TCP

La cabecera TCP lleva un pequeño conjunto de banderas. Conocerlas de memoria hace que la lectura de capturas sea mucho más rápida:

Banderas Significado Se establece cuando…
SYN Sincronizar números de secuencia Al abrir una conexión
ACK El campo de acuse de recibo es válido Después del primer SYN, casi siempre
FIN El remitente ha terminado de enviar Cierre ordenado, en una dirección
RST Restablecer la conexión Aborto, rechazo o error
PSH Empujar los datos hacia la aplicación inmediatamente Tráfico interactivo (a menudo se establece con ACK)
URG El puntero urgente es válido Raro; señal fuera de banda dentro del flujo
CWR Ventana de congestión reducida Retroalimentación ECN
ECE Eco ECN Notificación de Congestión Explícita

SYN, ACK, FIN y RST son las cuatro que verás constantemente. PSH+ACK es cómo se ven la mayoría de los segmentos de datos interactivos. Un RST solo suele ser el más interesante en un contexto de seguridad — puede significar "puerto cerrado", "esta conexión fue rechazada" o "algo en el medio me mató".

Estados TCP (la versión corta)

La máquina de estados completa es genuinamente útil, pero no cabe en una entrada de blog. Los estados que realmente me preocupo:

  • LISTEN — el servidor está esperando SYNs.
  • SYN_SENT — el cliente ha enviado SYN, esperando SYN+ACK.
  • SYN_RECEIVED — el servidor recibió SYN, envió SYN+ACK, esperando ACK.
  • ESTABLISHED — el handshake está hecho, fluyen los datos.
  • FIN_WAIT_1, FIN_WAIT_2, CLOSE_WAIT, LAST_ACK, CLOSING, TIME_WAIT — las diversas fases de la desconexión.

TIME_WAIT es el que pica a la gente. Después de que el lado que inicia el cierre envía su ACK final, se queda en TIME_WAIT durante aproximadamente dos máximos tiempos de vida de segmento (típicamente 60–120 segundos). Esto es para que un duplicado retrasado del ACK final no confunda una nueva conexión que reutilice el mismo par de puertos. En un servidor ocupado con conexiones de corta duración, los sockets TIME_WAIT se acumulan; esto es normal, no una fuga.

Puedes ver el estado actual de cada conexión en una máquina Linux con:

ss -tan | awk 'NR==1 || $1=="ESTAB" || $1=="TIME-WAIT"' | head

El comando ss ha reemplazado a netstat para la mayoría de los casos de uso. Es más rápido y lee desde netlink en lugar de analizar /proc.

Una Inspección Práctica de Paquetes

El material de texto solo encaja realmente cuando lo ves en una captura. tcpdump y tshark son las dos herramientas que uso, en ese orden. tcpdump es más rápido y está en cada máquina Linux; tshark es lo que quiero cuando necesito ver campos decodificados.

Una captura simple de una sola conexión SSH:

# Captura los primeros 20 paquetes de tráfico TCP al puerto 22, sin resolución DNS.
sudo tcpdump -n -c 20 'tcp port 22' -i any

Una línea típica de tcpdump para un SYN se ve así:

10.0.0.5.54321 > 10.0.0.10.22: Flags [S], seq 1234567890, win 64240, options [mss 1460,sackOK,TS val 123 ecr 0,nop,wscale 7], length 0

Leyéndola:

  • 10.0.0.5.54321 > 10.0.0.10.22 — IP.origen.puerto a IP.destino.puerto.
  • Flags [S] — SYN. [S.] significaría SYN+ACK (el punto es ACK).
  • seq 1234567890 — número de secuencia inicial.
  • win 64240 — ventana de recepción que ofrece el remitente.
  • length 0 — no hay carga útil, lo cual tiene sentido para un SYN.

Para una mirada más profunda — campos decodificados, bien estructurados — tshark con salida JSON es excelente para scripting y para compartir capturas con personas que no quieren instalar Wireshark:

# Decodifica el mismo tráfico y emite JSON, un objeto por paquete.
sudo tshark -i any -f 'tcp port 22' -c 3 -T json > handshake.json

Una versión recortada de lo que obtienes se ve así:

{
  "_index": "packets-2026-07-18",
  "_source": {
    "layers": {
      "ip": {
        "ip.src": "10.0.0.5",
        "ip.dst": "10.0.0.10",
        "ip.proto": "6"
      },
      "tcp": {
        "tcp.srcport": "54321",
        "tcp.dstport": "22",
        "tcp.flags": "0x00000002",
        "tcp.flags.syn": "1",
        "tcp.seq": "1234567890",
        "tcp.window_size": "64240"
      }
    }
  }
}

Esta es la misma información que tcpdump te mostró, solo estructurada. Útil para diferenciar capturas, para construir dashboards, o para canalizar hacia jq cuando buscas un patrón específico.

Una Nota sobre MTU y Fragmentación

La capa Internet (IP) es responsable de hacer que un paquete cruce múltiples saltos. Cada salto tiene una unidad de transmisión máxima (MTU) — el marco más grande que transportará. El MTU de Ethernet es típicamente 1500 bytes. Cuando un paquete es más grande que el MTU del siguiente salto, IP lo fragmenta (IPv4) o lo descarta y le señala al remitente (IPv6, con Packet Too Big ICMP).

Dos consecuencias prácticas:

  1. El descubrimiento de MTU de ruta importa. La mayoría de las pilas modernas lo hacen; los firewalls mal configurados que bloquean ICMP pueden romperlo silenciosamente, produciendo el modo de fallo clásico "los paquetes pequeños funcionan, los grandes se cuelgan".
  2. Los segmentos TCP deben caber. TCP usa MSS (tamaño máximo de segmento) para negociar un tamaño de carga útil que quepa en el MTU de la ruta, típicamente 1460 bytes sobre Ethernet estándar (1500 − 20 IP − 20 TCP). Este es el número que verás en las opciones del SYN.

Notas Finales

El modelo TCP/IP es lo suficientemente pequeño como para caber en una entrada de blog y lo suficientemente profundo como para dedicarle una carrera. Las cuatro capas explican la estructura; el handshake explica cómo comienzan las conexiones; las banderas y la máquina de estados explican cómo se comportan (y se comportan mal); y tcpdump / tshark son cómo realmente ves cualquiera de esas cosas. Una vez que puedes leer con confianza una sola línea de tcpdump, tienes la mayor parte de lo que necesitas para depurar los problemas de red que no tienen un mensaje de error agradable.

Para las referencias canónicas, RFC 793 define TCP (con muchas actualizaciones desde entonces), RFC 1122 es el documento de requisitos de host que codifica lo que las pilas realmente hacen, y la página man de tcpdump es una de las mejor documentadas del mundo Unix.

En esta página