IT Experts de México
Centro de Operaciones Consultoría y Soporte Hardware y Licenciamiento Cloud Operations Ciberseguridad Herramientas Blog Contáctanos
Networking

Redes desde los cimientos II: puertos, protocolos y NAT (lo que pasa cuando el paquete ya llegó)

14/07/2026 3 min de lectura Rubén Espinoza

En la primera parte de esta serie seguimos un paquete desde "enviar" hasta "llegó". Pero hay una trampa en esa palabra: que un paquete llegue a tu máquina no es que llegue al programa correcto. Tu laptop, ahora mismo, mantiene decenas de conversaciones a la vez —el correo, tres pestañas del navegador, Teams, un respaldo en la nube— todas por la misma dirección IP. ¿Cómo sabe el sistema qué paquete pertenece a cuál? Esa pregunta abre una capa entera que Vol I no tocó.

Esta segunda parte sube justo un piso: de "cómo llega el paquete a la máquina" a cómo llega a la aplicación, cómo conversan dos programas, y cómo todo eso cruza la frontera entre tu red y el internet público.

Tres preguntas nuevas (y una del futuro)

Sobre los cimientos de direccionamiento y el viaje del paquete viven cuatro temas que casi todo ingeniero usa a diario sin haberlos mirado de frente:

  • ¿A qué aplicación va el paquete? El concepto de puerto y de socket. → Qué son los puertos.
  • ¿Cómo conversan dos programas: rápido o confiable? Los dos protocolos de transporte. → TCP vs UDP.
  • ¿Qué esconde una dirección web? Una URL es DNS, puerto y protocolo en una sola línea. → Anatomía de un URL.
  • ¿Cómo publico un servicio hacia afuera sin abrir un boquete? NAT en serio. → NAT a fondo.

Y como todo esto se apoya en las direcciones, cerramos con el direccionamiento del futuro (y por qué no termina de llegar): IPv6 desmitificado, por qué IPv4 sigue dominando, y un término muy mexicano que confunde a todos: las IPs homologadas.

Por qué vale la pena subir esta capa

Cuando entiendes puertos, transporte y NAT, cosas que parecían magia se vuelven mecánica: por qué "hay que abrir el puerto 443", por qué una videollamada se ve pixelada pero no se congela, por qué tu servidor interno no es visible desde internet, y qué pasa exactamente cuando tecleas una dirección. Es la diferencia entre configurar por receta y configurar entendiendo.

Un modelo mental: la red por capas

Todo esto encaja mejor con una imagen: la red funciona por capas, cada una apoyándose en la de abajo. En el piso está el cable o el WiFi que mueve bits. Encima, la capa de direcciones que lleva un paquete de una máquina a otra —el territorio de la primera parte—. Sobre esa, la capa de transporte que decide cómo conversan (TCP o UDP) y a qué aplicación entregar (los puertos). Y arriba del todo, las aplicaciones que hablan sus propios idiomas (HTTP, correo, DNS). No necesitas memorizar el modelo formal; basta la idea de que cada capa hace su trabajo y confía en la de abajo. Vol I te dio las capas inferiores; Vol II sube a las de transporte y aplicación, que es donde vive casi todo lo que configuras a diario.

La idea que se queda

Vol I te llevó el paquete hasta la puerta de la máquina. Vol II lo mete a la aplicación correcta, lo hace conversar y lo saca al mundo. Son los cimientos que convierten "sé usar la red" en "entiendo la red" —la continuación natural de Redes desde los cimientos.

#redes #puertos #tcp #udp #nat #fundamentos

Preguntas frecuentes

¿De qué trata la segunda parte de "Redes desde los cimientos"?

De la capa que vive sobre el direccionamiento y el viaje del paquete: cómo un paquete llega no solo a la máquina sino a la aplicación correcta (puertos y sockets), cómo conversan dos programas eligiendo entre confiabilidad y velocidad (TCP vs UDP), qué esconde una dirección web (anatomía de un URL), cómo se publica un servicio hacia afuera sin abrir un boquete (NAT a fondo), y el direccionamiento del futuro con IPv6 y por qué IPv4 sigue dominando.

¿Necesito haber leído la primera parte?

Ayuda, pero no es obligatorio. La primera parte cubre los cimientos de direccionamiento IP, subnetting, DNS y el viaje del paquete de un extremo a otro. La segunda parte asume esos conceptos y sube una capa hacia los puertos, los protocolos de transporte y el NAT. Si algún término base te queda flojo, cada artículo enlaza de vuelta a donde se explica.

¿Por qué vale la pena entender puertos, TCP/UDP y NAT?

Porque convierten en mecánica lo que parecía magia: por qué hay que abrir el puerto 443, por qué una videollamada se pixela pero no se congela, por qué tu servidor interno no es visible desde internet y qué pasa exactamente cuando tecleas una dirección. Es la diferencia entre configurar la red por receta y configurarla entendiendo lo que haces.

¿Necesitas ayuda con este tema?

El equipo de IT Experts puede evaluar tu infraestructura sin costo.

Hablar con un especialista

Más de Networking

IAX, Asterisk y la leyenda de Digium
Troncales SIP a fondo: DIDs, concurrencias, inbound y outbound
Códecs, RTP, jitter y por qué la voz va por UDP