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.
Preguntas frecuentes
help ¿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.
help ¿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.
help ¿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.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →