Los modelos OSI y TCP/IP

Un intercambio por la red requiere varias tareas, desde crear un mensaje hasta enviar señales. Un modelo de capas separa esas tareas. Cada capa utiliza el servicio de la capa inmediatamente inferior y proporciona un servicio a la capa inmediatamente superior.

Separa las tareas

Un portátil puede pasar de Wi-Fi a Ethernet mientras su navegador sigue utilizando el mismo protocolo web. El método de entrega local cambia sin modificar el servicio de aplicación. Las normas publicadas también permiten que los sistemas de distintos fabricantes trabajen juntos (interoperabilidad) y dan a los técnicos un vocabulario compartido, como «fallo de capa 2». Diseñadores y estudiantes pueden examinar una tarea cada vez.

Un protocolo define los formatos de los mensajes, su orden y las respuestas. Un conjunto de protocolos agrupa protocolos que colaboran, como TCP/IP. Un modelo de referencia describe funciones de comunicación sin imponer una implementación concreta.

El modelo de interconexión de sistemas abiertos (OSI) procede de la Organización Internacional de Normalización (ISO). Su primera edición apareció como ISO 7498 en 1984; la referencia básica posterior es ISO/IEC 7498-1:1994, publicada también como UIT-T X.200. El tráfico de internet utiliza el conjunto TCP/IP; OSI proporciona el vocabulario de siete capas utilizado para describirlo.

Sigue la pila

Numera las capas desde el medio hacia arriba:

1. Física
2. Enlace de datos
3. Red
4. Transporte
5. Sesión
6. Presentación
7. Aplicación

«Fernando Estudia Redes, Teresa Siempre Prepara Apuntes» ayuda a recordar 1–7. «Ana Prepara Sus Tareas, Raúl Estudia Física» ayuda a recordar 7–1. Las capas 1–3 suelen llamarse capas del medio y las 4–7, capas del host.

Un emisor trabaja hacia abajo, desde aplicación hasta física. Las señales atraviesan el medio y el receptor trabaja hacia arriba. Las capas correspondientes son homólogas lógicas: las dos implementaciones de TCP siguen las reglas de TCP, aunque los datos reales viajen entre ellas mediante IP, enlaces locales y señales.

Imagina la entrega entre capas

Alguien escribe una carta, un sobre con una dirección permite entregarla y unos vehículos la transportan. Quien conduce puede transportar la carta cerrada sin entender su contenido. Del mismo modo, cada capa inferior transporta los datos de la capa superior como carga útil y añade información de control, normalmente una cabecera.

Los protocolos reales pueden combinar funciones. TLS realiza el cifrado asociado a presentación, mientras que ARP conecta la entrega MAC local con el direccionamiento IP. Su ubicación depende de su función y del modelo utilizado.

Las tres primeras capas OSI trasladan los datos por la red. Describen tres unidades de trabajo distintas: señales, tramas locales y paquetes que pueden atravesar redes.

Capa 1: envía bits como señales

La capa física representa bits mediante señales eléctricas en cobre, luz en fibra u ondas de radio por Wi-Fi. Define detalles como los conectores, la distribución de pines, los niveles de señal, las frecuencias y las tasas de bits. Una conexión Ethernet de par trenzado puede utilizar un conector RJ45 y funcionar a 1 Gbit/s.

La transmisión física no toma decisiones sobre direcciones MAC o IP. Una señal transporta un flujo de bits; las capas superiores deciden cómo forman mensajes esos bits y adónde deben ir esos mensajes.

Capa 2: entrega una trama en el enlace local

La capa de enlace de datos introduce los datos en tramas para entregarlos en un enlace local o segmento de red. Ethernet y Wi-Fi utilizan direcciones MAC para identificar interfaces. Una dirección MAC habitual tiene 48 bits, escritos como seis pares hexadecimales, como 00:1A:2B:3C:4D:5E.

El IEEE describe dos subcapas de la capa 2. El control de enlace lógico (LLC) proporciona la interfaz hacia la capa 3 y funciones de identificación de protocolos. El control de acceso al medio (MAC) gestiona el direccionamiento local y el acceso al medio. Ethernet es IEEE 802.3; Wi-Fi es IEEE 802.11. Ambos incluyen funciones de las capas física y de enlace de datos. PPP es otro protocolo de enlace de datos, utilizado en enlaces punto a punto.

Ethernet añade una secuencia de verificación de trama (FCS) al final de una trama. El receptor utiliza esta comprobación para detectar datos dañados. Si la comprobación falla, se descarta la trama. Ethernet estándar no reenvía la trama para recuperar esa pérdida; un protocolo de capa superior, como TCP, puede recuperar los datos que faltan cuando se requiere fiabilidad.

Capa 3: llega a un host a través de las redes

La capa de red agrupa los datos en paquetes. Utiliza direcciones lógicas: las direcciones IPv4 contienen 32 bits y las IPv6, 128 bits. El enrutamiento elige cómo viajan los paquetes entre redes. Un enrutador lee la dirección IP de destino y selecciona una ruta hacia ella.

IPv4 e IPv6 pertenecen a esta capa, junto con ICMP, que transporta mensajes de control y error utilizados por herramientas como ping. IPsec protege el tráfico IP. El tiempo de vida (TTL) de IPv4 y el límite de saltos de IPv6 evitan bucles de reenvío interminables: cada enrutador reduce el valor en uno y se descarta el paquete cuyo valor se agota.

Sigue una solicitud inalámbrica

Un portátil solicita una página a un servidor de otra red. La señal de radio que sale del portátil corresponde a la capa 1. Su trama Wi-Fi llega al punto de acceso en la capa 2. El punto de acceso actúa como puente hacia Ethernet, donde una trama transporta el tráfico hacia el enrutador local. El paquete IP que contiene identifica al portátil y al servidor remoto como sus extremos.

La dirección IP de un servidor remoto puede permanecer en un paquete mientras cada enrutador construye una trama nueva para el siguiente enlace. Tratar la dirección MAC como un destino de extremo a extremo confunde la tarea de entrega local con el enrutamiento.

Las capas superiores de OSI describen la entrega a los programas y los servicios que estos utilizan. Una ruta IP que funciona permite llegar a un host; por sí sola no identifica el programa receptor ni explica el formato del mensaje.

Capa 4: llega al programa

La capa de transporte entrega datos entre procesos (programas en ejecución) mediante números de puerto. TCP proporciona una entrega fiable y ordenada de un flujo de bytes y divide los datos en segmentos. UDP transporta datagramas independientes.

La multiplexación de transporte permite que un navegador, un cliente de correo y un programa de llamadas compartan una interfaz manteniendo sus conversaciones diferenciadas. La dirección IP identifica un host; la información de transporte identifica el servicio o la conversación en ese host.

Capas 5 y 6: gestiona y representa

La capa de sesión, capa 5, establece, gestiona y finaliza los diálogos entre aplicaciones. El control del diálogo determina qué extremo envía en cada momento; los puntos de control permiten reanudar un intercambio interrumpido desde un punto registrado. RPC y el servicio de sesión de NetBIOS son ejemplos habituales de tareas de sesión.

La capa de presentación, capa 6, se encarga de la representación, la compresión y el cifrado. ASCII y UTF-8 representan texto; JPEG y PNG representan imágenes; MPEG representa vídeo. La compresión reduce la cantidad que se envía. El cifrado TLS suele relacionarse con presentación en las descripciones OSI.

Capa 7: proporciona un servicio de red

La capa de aplicación contiene los protocolos que los programas utilizan directamente. HTTP y HTTPS sirven para la web; SMTP envía correo; IMAP y POP3 lo recuperan. DNS resuelve nombres, DHCP proporciona ajustes de red automáticos, FTP y SFTP transfieren archivos y SSH proporciona acceso remoto seguro por línea de comandos.

Un navegador es el programa que utiliza HTTP. HTTP es su protocolo de red. Tratar todo el programa como si fuera la capa incluiría acciones locales del navegador que nunca se comunican por una red.

Interpreta un intercambio de correo

TCP 587 es un punto de conexión habitual para el envío de correo, que normalmente pasa a TLS mediante STARTTLS. En TCP/IP, las tareas de sesión y presentación pertenecen a aplicación. Estas filas OSI describen funciones, por lo que no tienen que corresponder a cuatro módulos de software separados.

OSI y TCP/IP agrupan de forma distinta las mismas tareas de comunicación. Relaciona las funciones para comparar sus diagramas.

Cuatro capas de internet

TCP/IP surgió de investigaciones financiadas por la Agencia de Proyectos de Investigación Avanzados de Defensa (DARPA) en la década de 1970. ARPANET lo adoptó el 1 de enero de 1983. Las especificaciones aparecen como solicitudes de comentarios (RFC), y el trabajo sobre los estándares de internet se realiza a través del Grupo de Trabajo de Ingeniería de Internet (IETF). TCP e IP dan nombre al conjunto, que también incluye UDP, ICMP, ARP, DNS y otros protocolos.

RFC 1122 describe cuatro capas:

Aplicación incluye HTTP, DNS y SMTP. Transporte incluye TCP y UDP; internet incluye IP e ICMP; enlace incluye Ethernet y Wi-Fi. Enlace también se llama acceso a la red o interfaz de red, y algunos libros llaman «red» a internet.

Relacionar la capa de aplicación de TCP/IP solo con OSI 7 dejaría fuera las funciones de sesión y presentación. Se siguen realizando, pero TCP/IP las agrupa con las aplicaciones que las necesitan.

Por qué aparece una quinta capa

El modelo didáctico de cinco capas divide enlace en enlace de datos y física. Su orden completo es aplicación, transporte, red, enlace de datos y física. Kurose y Ross y muchos cursos de redes lo utilizan para distinguir la formación de tramas locales de la señalización. Sus cuatro capas inferiores se corresponden individualmente con OSI 1–4.

OSI se diseñó como un marco de referencia general antes de que existiera la mayoría de sus protocolos asociados. El modelo TCP/IP describe un conjunto que ya se utilizaba. Esto ayuda a explicar por qué OSI distingue categorías en las capas superiores mientras que el software de internet suele combinar sus tareas.

Relaciona las capas en un intercambio HTTPS

Para HTTP/2 sobre HTTPS, HTTP y TLS pertenecen a la capa de aplicación de TCP/IP. TCP proporciona la entrega de transporte al puerto 443 del servidor. IP proporciona el direccionamiento de internet; Ethernet proporciona la formación de tramas y la señalización de enlace.

El personal de redes sigue utilizando la numeración OSI para las descripciones con números: «enrutamiento de capa 3», «conmutador de capa 2» o «balanceador de carga de capa 7». Contar internet como el segundo bloque desde abajo en el modelo TCP/IP de cuatro capas llevaría a interpretar mal esa forma abreviada.

Para situar un protocolo, pregunta primero qué tarea realiza. Después examina qué transporta sus mensajes. Lo que lo transporta suele acotar la elección, pero la función decide cuando un protocolo combina tareas o se construye sobre otro protocolo de transporte.

Empieza por la tarea principal

HTTP, DNS, DHCP, FTP, SFTP, TFTP, SSH, Telnet, SMTP, IMAP, POP3, SNMP, NTP, LDAP, SMB, RDP, SIP y syslog proporcionan servicios a las aplicaciones. Pertenecen a la capa de aplicación de OSI y de TCP/IP. Las codificaciones de caracteres, como ASCII y UTF-8, los formatos multimedia, como JPEG y MPEG, y el cifrado describen funciones de presentación; RPC es un ejemplo habitual de sesión.

TCP y UDP realizan tareas de transporte. IPv4, IPv6, ICMP, ICMPv6, la tunelización GRE y los protocolos AH y ESP de IPsec realizan tareas de red/internet. OSPF intercambia información de enrutamiento directamente dentro de IP y también se sitúa en la capa 3.

La formación de tramas Ethernet, las funciones MAC de Wi-Fi, PPP, el etiquetado VLAN (802.1Q) y el protocolo de árbol de expansión (STP) son funciones de enlace de datos. La señalización por cobre o fibra, los conectores, 1000BASE-T y la transmisión de radio Wi-Fi son funciones físicas. Ethernet y Wi-Fi abarcan las dos capas inferiores.

Distingue un servicio de la información que maneja

DNS (sistema de nombres de dominio) consulta información sobre nombres, incluidas las direcciones IP, pero presta servicio a las aplicaciones y viaja por el puerto UDP o TCP 53. DHCP (protocolo de configuración dinámica de hosts) proporciona ajustes IP, pero sus mensajes utilizan el puerto UDP 67 del servidor y el puerto 68 del cliente. Manejar una dirección IP no convierte a ninguno de los dos servicios en un protocolo de capa de red.

ICMP (protocolo de mensajes de control de internet) informa sobre la entrega IP y transporta mensajes de eco para ping. IP lo transporta directamente y no tiene puertos TCP o UDP. Su ubicación en la capa de red se debe a su función de control, no a la presencia de una cabecera independiente dentro de IP.

Sitúa los protocolos que cruzan un límite entre capas

ARP (protocolo de resolución de direcciones) encuentra la dirección MAC asociada a una dirección IPv4 en el enlace local. Sus mensajes se transportan directamente en tramas Ethernet, sin cabecera IP. ARP permite la entrega IP mediante la entrega MAC local, por lo que convencionalmente se sitúa en la capa 2; la etiqueta informal «capa 2,5» describe esa función entre ambas capas.

TLS proporciona cifrado. Para HTTP/1.1 y HTTP/2, HTTPS transporta HTTP dentro de TLS sobre TCP. TLS pertenece a la capa de aplicación de TCP/IP y suele relacionarse con la capa de presentación de OSI. La palabra «transporte» de su nombre completo, seguridad de la capa de transporte, no sitúa a TLS en la misma capa que TCP o UDP.

QUIC se transporta dentro de UDP, pero proporciona funciones de transporte, como flujos fiables y gestión de conexiones. HTTP/3 utiliza QUIC, con una negociación TLS 1.3 integrada en el establecimiento de QUIC y cifrado de los paquetes QUIC. Por eso «dentro de UDP» es una pista útil, no un criterio universal para situar un protocolo en la capa de aplicación.

Por el mismo motivo, SSH sigue siendo de capa de aplicación aunque incluya cifrado. Lo que importa es el propósito completo del protocolo: el inicio de sesión remoto seguro es un servicio de aplicación, mientras que el cifrado por sí solo es una función de presentación.

Cuando los datos descienden por una pila, cada capa añade la información necesaria para su propia tarea. La encapsulación es este proceso de envoltura. La unidad completa de la capa superior se convierte en la carga útil de la siguiente capa, es decir, el contenido que se transporta.

Construye de dentro hacia fuera

Una cabecera va antes de la carga útil. Una cola de trama va después. En una pila Ethernet/IP/TCP, TCP e IP añaden cada uno una cabecera; Ethernet añade tanto una cabecera como una cola de trama FCS. La transmisión física representa la trama resultante como bits mediante señales.

La unidad de una capa determinada es su unidad de datos de protocolo (PDU). Utiliza estos nombres al seguir una solicitud:

Supón que un programa envía una solicitud HTTP por TCP. TCP añade su cabecera, incluidos los puertos y la información de secuencia. IPv4 añade su cabecera alrededor de ese segmento. Ethernet añade su cabecera alrededor del paquete y una FCS después. La solicitud permanece dentro de cada unidad mayor; las capas no la sustituyen por mensajes sin relación con ella.

Identifica el siguiente protocolo

El receptor necesita una forma de elegir qué protocolo procesa la carga útil. El EtherType de Ethernet identifica IPv4 como 0x0800, IPv6 como 0x86DD y ARP como 0x0806. Por tanto, ARP pasa directamente de Ethernet al procesamiento ARP, sin pasar por IP.

El campo protocolo de IPv4 identifica TCP con 6, UDP con 17 e ICMP con 1. IPv6 llama a su campo correspondiente siguiente cabecera. Tras el procesamiento de transporte, un puerto de destino como TCP 443 identifica el servicio receptor.

Son tres selectores distintos. EtherType elige el protocolo dentro de una trama; el campo IP elige el protocolo dentro de un paquete; el puerto de destino selecciona el programa receptor. Los puertos TCP y UDP no aparecen en los mensajes ICMP.

Desenvuelve en el receptor

La desencapsulación elimina primero la capa más externa. La interfaz recibe señales y recupera los bits. Ethernet comprueba la FCS y utiliza EtherType para entregar la carga útil a IP. IP comprueba la información de entrega y pasa la carga útil al protocolo de transporte indicado. TCP procesa su cabecera y entrega los bytes de aplicación al programa receptor.

La FCS es un valor de comprobación de redundancia cíclica (CRC) de 32 bits para detectar tramas dañadas. Se elimina junto con la información de la trama local y no se entrega como parte del mensaje de la aplicación.

Antes de cada trama Ethernet, la capa física envía un preámbulo de 7 bytes y un delimitador de inicio de trama (SFD) de 1 byte para la sincronización. Estos ocho bytes quedan fuera del tamaño contabilizado de la trama Ethernet.

Un conmutador lee la información de la trama para reenviarla localmente. Un enrutador elimina la trama entrante, examina IP y crea otra trama para el siguiente enlace. Un host final procesa la pila hasta llegar a la aplicación. Describir la tarea normal de cada capa ayuda a explicar por qué un enrutador puede reenviar contenido cifrado sin leer el mensaje de la aplicación.

Las cabeceras ocupan espacio junto con los datos de aplicación. Para calcular un tamaño transmitido, identifica la pila, anota los tamaños de sus cabeceras y trabaja de dentro hacia fuera. Tanto el mayor paquete permitido como la menor trama Ethernet permitida afectan al resultado.

Identifica qué cuenta cada tamaño

Las cabeceras IPv4 y TCP pueden alcanzar 60 bytes cada una con opciones. La MTU, o unidad máxima de transmisión, cuenta el paquete de capa 3. Ethernet estándar tiene una MTU de 1500 bytes y produce una trama de 1518 bytes con sus 18 bytes de sobrecarga de enlace, o de 1522 bytes con una etiqueta VLAN. Las tramas jumbo suelen utilizar una MTU de 9000 bytes cuando están habilitadas.

El MSS, tamaño máximo de segmento, cuenta los datos de aplicación de TCP. Sin opciones IP ni TCP, la carga útil TCP disponible es:

Para IPv6 sin cabeceras de extensión ni opciones TCP, es:

Sumar la sobrecarga Ethernet a la MTU sobrestimaría el espacio disponible dentro del paquete.

Calcula una trama de dentro hacia fuera

Para 1000 bytes de datos HTTP sobre TCP, IPv4 y Ethernet sin etiqueta, sin opciones:

1. Segmento TCP: 1020 bytes, a partir de los datos más 20.
2. Paquete IP: 1040 bytes, tras añadir otros 20.
3. Trama Ethernet: 1058 bytes, tras añadir 18.

La sobrecarga es de 58 bytes. La proporción de datos útiles es:

Con la misma pila, una transferencia de aplicación de 4000 bytes con un MSS de 1460 necesita tres segmentos: 1460, 1460 y 1080 bytes de datos. Sus tramas tienen 1518, 1518 y 1138 bytes. El total es de 4174 bytes, incluidos 174 bytes de cabeceras y colas de trama. Cada segmento necesita su propio conjunto de cabeceras.

Mensajes pequeños y tramas mínimas

Una consulta DNS de 40 bytes sobre UDP e IPv4 se convierte en un datagrama de 48 bytes, un paquete de 68 bytes y una trama Ethernet sin etiqueta de 86 bytes. Su proporción de datos útiles es de aproximadamente el 46,5 %. Una carga útil TCP completa de 1460 bytes ocupa alrededor del 96,2 % de su trama de 1518 bytes.

Las tramas Ethernet deben tener al menos 64 bytes, con un mínimo de 46 bytes de carga útil. Una confirmación TCP sin datos de aplicación tiene un paquete IPv4 de 40 bytes con cabeceras mínimas. Ethernet añade 6 bytes de relleno antes de su FCS, lo que da una trama de 64 bytes.

Distingue bien los límites

La segmentación TCP divide los datos de aplicación en la capa 4. La fragmentación IP divide un paquete en la capa 3 cuando es demasiado grande para un enlace. Los enrutadores IPv4 pueden fragmentar cuando está permitido; los enrutadores IPv6 nunca fragmentan, por lo que el emisor debe adaptarse al límite de tamaño de la ruta.

Los tamaños de trama de aquí excluyen el preámbulo, el SFD y el tiempo entre tramas. Para convertir los bytes de una trama en bits, multiplica por ocho: una trama de 1518 bytes contiene 12 144 bits.

Un paquete puede atravesar varias redes, pero una trama Ethernet sirve a un enlace local. Seguir ambas unidades a la vez explica por qué un host necesita la dirección IP remota y una dirección MAC cercana para el mismo intercambio.

Dirige la trama al siguiente receptor local

Considera un portátil con dirección 192.0.2.10 y etiqueta MAC AA. Un enrutador R1 une su red con la red de un servidor. R1 tiene la etiqueta MAC R1-A en el lado del portátil y R1-B en el del servidor. El servidor es 198.51.100.20, con etiqueta MAC SS. Estas etiquetas MAC abreviadas representan direcciones completas de interfaz.

El portátil reconoce que el servidor es remoto. Su puerta de enlace predeterminada, R1, es el siguiente receptor en el enlace local. ARP proporciona la dirección MAC de la puerta de enlace. Para una conexión TCP al puerto 443 del servidor, las direcciones anidadas son:

El portátil no utiliza SS como MAC de destino local. SS pertenece al host final de otra red; R1-A pertenece al dispositivo que puede recibir esta primera trama.

Atraviesa un conmutador y un enrutador

Un conmutador de capa 2 lee la MAC de destino, encuentra el puerto hacia R1-A y reenvía la trama. La conmutación ordinaria no sustituye las direcciones MAC de origen y destino.

R1 comprueba la FCS de la trama recibida y elimina su cabecera y su cola de trama. Lee la IP de destino, busca la ruta y reduce el TTL en uno. Después crea una trama nueva en el enlace del lado del servidor. Esa trama tiene origen R1-B y destino SS, aprendido mediante ARP. Su FCS cubre esta nueva trama.

Las direcciones IP de origen y destino y los puertos TCP permanecen iguales a lo largo de esta ruta enrutada ordinaria. La cabecera IP no permanece totalmente igual: el TTL disminuye y se actualiza la suma de comprobación de la cabecera IPv4. La traducción de direcciones de red (NAT) es una excepción a la conservación de las direcciones de los extremos porque modifica las direcciones IP y, a menudo, los puertos.

Cuenta los saltos de enrutador con el TTL

Un paquete enviado con TTL 64 llega al destino con TTL 61 después de tres pasos de reenvío en enrutadores. Si un enrutador reduce el TTL a cero, descarta el paquete y normalmente devuelve un mensaje ICMP de tiempo excedido. IPv6 utiliza un campo de límite de saltos con la misma finalidad de limitar los bucles.

traceroute en Linux o macOS y tracert en Windows utilizan sondas con distintos valores de TTL para descubrir los saltos que responden. Un * significa que no llegó ninguna respuesta para esa sonda. El enrutador puede seguir reenviando tráfico mientras filtra o limita las respuestas de diagnóstico, así que compara las respuestas posteriores y las pruebas del servicio antes de señalar un punto de fallo.

Regresa al cliente

El servidor elimina la trama local y procesa el paquete y el segmento TCP hasta llegar al servicio web. Una respuesta invierte las funciones de los extremos: la IP y el puerto del servidor pasan a ser el origen, y la IP y el puerto del cliente del portátil pasan a ser el destino. Los enrutadores vuelven a crear tramas para sus enlaces de salida. La ruta de retorno puede utilizar otros enrutadores, pero cada trama local sigue dirigida a su siguiente receptor.

TCP y UDP utilizan puertos para transportar datos entre programas en la capa 4. La elección depende de lo que necesita la aplicación cuando los paquetes se retrasan, se pierden o llegan fuera de orden.

Qué proporciona TCP

El protocolo de control de transmisión (TCP) está orientado a conexión. Un establecimiento de conexión en tres pasos (SYN, SYN-ACK, ACK) establece la conexión antes del intercambio normal de datos. Las confirmaciones indican al emisor qué ha llegado y la retransmisión recupera los datos que faltan. La información de secuencia permite a TCP presentar los bytes en orden.

El control de flujo protege al receptor de un emisor demasiado rápido. El control de congestión ajusta el envío a la carga de la red. Son problemas distintos: uno afecta a la capacidad del host receptor; el otro, a la red que transporta el tráfico. La cabecera TCP tiene 20 bytes sin opciones y puede alcanzar 60 bytes.

TCP proporciona un flujo de bytes fiable y ordenado, pero una conexión fallida puede dejar a una aplicación con un archivo incompleto. La aplicación debe gestionar el fallo o reanudar la operación; TCP no puede hacer que una ruta no disponible entregue datos.

Qué proporciona UDP

El protocolo de datagramas de usuario (UDP) es sin conexión. Envía datagramas independientes sin negociación de transporte, confirmaciones, retransmisión ni reordenación. Su cabecera de 8 bytes contiene el puerto de origen, el puerto de destino, la longitud y la suma de comprobación.

UDP admite tráfico de uno a uno, de difusión y de multidifusión. Una conexión TCP une dos extremos. La cabecera más pequeña de UDP y la ausencia de recuperación integrada reducen la sobrecarga de transporte, pero «no fiable» describe su falta de garantías de entrega, no la expectativa de que se pierda la mayor parte del tráfico.

Elige según el plazo de la aplicación

Un paquete de voz en directo puede contener 20 ms de sonido. Si se pierde, una sustitución que llega 100 ms después es demasiado tardía para su momento de reproducción. Una llamada puede continuar con un pequeño silencio, por lo que UDP resulta adecuado. Un documento descargado necesita todos sus bytes en orden, así que la recuperación de TCP encaja con la tarea.

Las solicitudes breves, como DNS, DHCP, NTP y SNMP, también suelen utilizar UDP. DNS utiliza además el puerto TCP 53 para transferencias de zona y cuando una respuesta necesita TCP. El establecimiento de llamadas SIP puede utilizar UDP o TCP en el puerto 5060.

Las aplicaciones pueden añadir funciones sobre UDP. TFTP confirma sus bloques y QUIC proporciona conexiones fiables y cifradas sobre UDP. Por tanto, ver UDP en una captura no indica que la aplicación carezca de recuperación.

El vídeo bajo demanda suele almacenar datos por adelantado en un búfer y utilizar HTTPS sobre TCP o HTTP/3 sobre QUIC. «Vídeo significa UDP» pasa por alto la diferencia entre una conversación en directo con un plazo inmediato y un vídeo almacenado con tiempo para recuperar los datos que faltan.

Una dirección IP identifica un host, pero muchos programas pueden utilizar ese host a la vez. TCP y UDP añaden números de puerto de origen y destino para que los datos entrantes lleguen al servicio o a la conversación correctos.

Distingue los servicios y las conversaciones de los clientes

Un puerto es un número de 16 bits de 0 a 65 535. Un servidor escucha tráfico en un puerto conocido, como TCP 443 para HTTPS. Un cliente suele elegir un puerto de origen temporal, llamado puerto efímero, cuando abre una conexión.

RFC 6335 agrupa los números así:

IANA asigna los puertos de sistema y de usuario; los dinámicos no se asignan. El rango dinámico y el rango real de puertos temporales de un sistema operativo son conceptos distintos. Los puertos temporales predeterminados de Windows utilizan 49152–65535, mientras que Linux suele utilizar 32768–60999. Un administrador puede cambiar estos ajustes.

Identifica un extremo y una conexión

Un socket identifica un extremo de transporte mediante la dirección IP, el puerto y el protocolo de transporte. Por ejemplo, TCP 198.51.100.20:443 identifica un extremo de servidor HTTPS. TCP 53 y UDP 53 son puertos separados porque TCP y UDP tienen espacios de numeración independientes.

Una conexión se identifica mediante la quíntupla de 5 elementos: IP de origen, puerto de origen, IP de destino, puerto de destino y protocolo de transporte. Esos valores distinguen las conversaciones incluso cuando varios clientes utilizan un mismo puerto de servidor.

Supón que 192.0.2.10 abre dos conexiones TCP a 198.51.100.20:443. Una utiliza el puerto de cliente 51514 y la otra, el 51515. Su extremo de servidor es idéntico, pero sus puertos de origen difieren. Por eso el servidor puede devolver cada respuesta a la conexión correcta. Algunos navegadores reutilizan conexiones; el ejemplo describe dos conexiones distintas que se han abierto.

En una respuesta de la primera conversación, el origen pasa a ser 198.51.100.20:443 y el destino pasa a ser 192.0.2.10:51514. El puerto 443 no se convierte en el puerto del cliente solo porque se invierta el sentido.

Interpreta con cuidado la información de los puertos

Un servicio configurado puede utilizar un puerto no estándar. HTTP puede utilizar el 8080 y SSH, el 2222. El número sugiere un servicio convencional, pero no demuestra qué contenido se está enviando realmente. Un cortafuegos que solo examina los puertos realiza una clasificación limitada; la inspección de aplicaciones puede examinar el propio tráfico.

Un puerto físico de conmutador es una conexión de cable en una interfaz. Un puerto de transporte es un número en una cabecera TCP o UDP. Sustituir un cable afecta a la conectividad física, mientras que permitir TCP 443 cambia qué tráfico de transporte puede pasar. Compartir la palabra «puerto» no los convierte en el mismo tipo de objeto.

Aprende juntos el protocolo de transporte y el puerto de un servicio. TCP 53 y UDP 53 son extremos de transporte separados, aunque ambos puedan servir a DNS. Agrupar servicios relacionados también facilita distinguir nombres parecidos.

Web, acceso remoto y archivos

FTPS explícito comienza en el 21 y pasa a TLS. FTPS implícito comienza con TLS en el 990. TCP 989 está registrado para los datos de FTPS implícito; las transferencias pasivas negocian los puertos de datos. SFTP es un protocolo distinto dentro de SSH, así que cambiar FTP al puerto 22 no lo convierte en SFTP.

Correo electrónico y servicios de directorio

SMTP utiliza TCP 25 para la retransmisión entre servidores. Los clientes suelen enviar por TCP 587 con STARTTLS o por TCP 465 con TLS desde el principio. La recuperación mediante IMAP utiliza TCP 143, con TLS implícito en TCP 993. La recuperación mediante POP3 utiliza TCP 110, con TLS implícito en TCP 995.

Las consultas de directorio LDAP utilizan TCP 389; LDAP sobre TLS implícito, o LDAPS, utiliza TCP 636. Un servicio seguro también puede pasar una conexión existente a TLS si lo admite, por lo que un puerto distinto no es la única forma de añadir TLS a un protocolo.

Infraestructura y gestión

La mayoría de las consultas DNS ordinarias utilizan UDP; las transferencias de zona utilizan TCP y los clientes también necesitan TCP para las respuestas que lo requieren. SNMPv3 puede añadir autenticación y cifrado manteniendo los puertos 161 y 162. Syslog puede utilizar otros protocolos de transporte en sistemas en funcionamiento; UDP 514 es la referencia habitual que se presenta aquí.

No confundas los números de protocolo IP con los puertos

El campo protocolo de la cabecera IP identifica qué transporta IP: ICMP 1, TCP 6, UDP 17, GRE 47, ESP 50 y AH 51. TCP y UDP proporcionan después sus propios campos de puerto. ICMP, GRE, ESP y AH no tienen puertos TCP o UDP. Por tanto, una regla que permite el puerto TCP 1 no permite el tráfico de eco ICMP.

Para un servidor web que utiliza HTTP/2 sobre TLS, permite TCP 443 entrante. Si el mismo servidor ofrece HTTP/3, su tráfico QUIC necesita UDP 443. Una regla DNS que solo permite UDP 53 puede dejar pasar consultas pequeñas y bloquear intercambios TCP necesarios. Ajusta la regla al protocolo de transporte real y al puerto de destino del servidor.

Sitúa un dispositivo según la información que lee para decidir cómo gestionar el tráfico. La etiqueta describe una función de reenvío o inspección. Un equipo físico puede contener varias funciones en distintas capas.

Señales, tramas y paquetes

Los dispositivos de capa 1 gestionan señales. Un repetidor regenera una señal; un concentrador repite las señales entrantes por todos los demás puertos. Un conversor de medios conecta medios como cobre y fibra. Un módem convierte entre datos digitales y la señalización utilizada en la línea de un proveedor. La alimentación a través de Ethernet (PoE) suministra energía por cableado de par trenzado a dispositivos como teléfonos y puntos de acceso, por lo que es una función de la capa física.

Un conmutador de capa 2 aprende las direcciones MAC de origen y sus puertos de entrada. Utiliza la MAC de destino para seleccionar un puerto de salida. Las tramas de difusión y las tramas con destinos desconocidos se envían mediante inundación a otros puertos de la misma red local. Un puente realiza la misma tarea básica con menos puertos. Un punto de acceso inalámbrico actúa como puente entre tramas Wi-Fi y cableadas. Una tarjeta de interfaz de red (NIC) gestiona las capas 1 y 2, incluida la dirección MAC de la interfaz.

Un enrutador lee las direcciones IP de destino y reenvía paquetes entre redes mediante una tabla de enrutamiento. Separa los dominios de difusión locales. Un conmutador de capa 3 combina la conmutación de tramas locales con el enrutamiento, a menudo entre VLAN. La palabra «conmutador» por sí sola no permite saber si el dispositivo puede enrutar.

Inspecciona información de transporte o aplicación

Un host, como un portátil, un servidor o un teléfono, gestiona las siete funciones OSI. Un «enrutador» doméstico suele combinar un enrutador, un conmutador, un punto de acceso, un cortafuegos y, a veces, un módem. Su función de puente Wi-Fi y el enrutamiento de paquetes son tareas separadas dentro de la misma carcasa.

Cuenta los dominios compartidos

Un dominio de colisión es una zona en la que las transmisiones simultáneas pueden interferir. Un concentrador comparte un dominio entre sus puertos. Un conmutador separa los enlaces conectados a él. Los enlaces conmutados modernos con dúplex completo no tienen colisiones; el recuento tradicional de dominios sigue mostrando las diferencias entre concentradores y conmutadores.

Un dominio de difusión contiene dispositivos que reciben las tramas de difusión de los demás. Los concentradores y los conmutadores ordinarios dejan pasar esas tramas. Los enrutadores separan los dominios de difusión y las VLAN pueden dividir un conmutador en varios de ellos.

En un enrutador que une dos conmutadores, el conmutador A con cinco ordenadores tiene seis enlaces ocupados, incluido su enlace al enrutador. El conmutador B con tres ordenadores y un concentrador tiene cinco enlaces ocupados: tres ordenadores, un concentrador y un enlace al enrutador. Los cuatro ordenadores del concentrador comparten el único dominio de colisión de su enlace al conmutador. El recuento tradicional da 11 dominios de colisión y dos dominios de difusión, sin divisiones mediante VLAN.

Empieza por preguntar a quién afecta el problema, qué servicios fallan y qué ha cambiado. Ese patrón ayuda a elegir un punto de partida para el diagnóstico y la resolución.

Elige una dirección

El enfoque de abajo arriba verifica el servicio físico, después las tramas locales, el enrutamiento y los servicios superiores. Es exhaustivo cuando se desconoce la causa, pero puede hacer perder tiempo si las evidencias ya aíslan un fallo de aplicación. El enfoque de arriba abajo empieza por el servicio y avanza hacia las capas inferiores de las que depende según sea necesario.

Interpreta la prueba intermedia

Divide y vencerás suele utilizar ping. Una respuesta de la puerta de enlace respalda el funcionamiento del trayecto IP/ICMP local hasta ella. Una respuesta de un servidor remoto respalda el funcionamiento de la ruta probada hasta ese servidor. Esos resultados justifican avanzar hacia los nombres, los puertos de transporte y la aplicación.

Un ping fallido requiere más investigación: la ruta puede estar interrumpida o ICMP puede estar filtrado mientras el servicio web sigue siendo accesible. Confirma con una prueba del servicio real.

El seguimiento de la ruta examina los dispositivos a lo largo de ella, a menudo con traceroute o tracert. Un salto que no responde puede seguir reenviando tráfico. Compara las respuestas posteriores y, si es posible, las pruebas desde dispositivos a ambos lados antes de atribuir un fallo de reenvío a ese salto.

Deja que los síntomas orienten la primera comprobación

Supón que todos los puestos de una sala pierden toda la conectividad mientras las salas cercanas funcionan. Empieza de abajo arriba en los equipos compartidos: alimentación del conmutador, su enlace ascendente (uplink) e indicadores de enlace. Sustituir un cable sospechoso por otro que sabes que funciona permite comprobar esa dependencia.

Si una cuenta no puede enviar correo mientras la navegación y otros servicios funcionan, empieza de arriba abajo con su nombre de servidor, su puerto de envío y su mensaje de error. El patrón más limitado apunta a una comprobación específica del servicio.

Compara un dispositivo que falla con otro que funciona cuando sea posible. Cambia un elemento, repite la misma prueba y registra el resultado. Revierte un cambio que no haya funcionado antes de probar otro. Cambiar a la vez el cable, la puerta de enlace y los ajustes DNS puede restaurar el acceso sin mostrar qué cambio fue decisivo.

Un síntoma sugiere dónde investigar; una prueba proporciona evidencias. Elige la herramienta según la tarea que quieras verificar y ten en cuenta su destino, protocolo y resultado al interpretar la respuesta.

Comprueba las señales y la entrega local

En la capa 1, la ausencia de indicadores de enlace, un cable desconectado, un dispositivo apagado, una longitud excesiva de cable o las interferencias pueden impedir la comunicación. Inspecciona la alimentación y los conectores, comprueba el cable o sustitúyelo por otro que sabes que funciona.

En la capa 2, el enlace físico puede existir mientras las tramas locales fallan. Una pertenencia a VLAN incorrecta puede separar dispositivos que deberían compartir una red local. Una discrepancia de dúplex puede causar bajo rendimiento y errores; un aumento de errores CRC también puede apuntar a problemas de señal o cableado. Consulta las estadísticas de las interfaces del conmutador y compara ambos extremos. arp -a muestra las correspondencias de IPv4 a MAC aprendidas en un host.

En los dispositivos Cisco, show interfaces informa del estado de la interfaz y del protocolo de línea. «up/up» indica que los estados físico y de enlace de datos están activos. «down/down» suele dirigir la atención hacia la alimentación, el cableado u otro problema físico. «up/down» significa que existe un enlace físico mientras el protocolo de línea está inactivo; una discrepancia de encapsulación es una posible causa.

Verifica la accesibilidad IP y el acceso de transporte

En la capa 3, comprueba las direcciones de las interfaces y los ajustes de la puerta de enlace con ipconfig en Windows, ip address en Linux o ifconfig en macOS. Una configuración incorrecta o la falta de rutas puede impedir que los paquetes lleguen a otra red. Utiliza ping para comprobar la accesibilidad IP y tracert en Windows o traceroute en Linux/macOS para ver los saltos que responden.

En la capa 4, comprueba el puerto real del servicio. Un servidor puede responder a ping mientras un cortafuegos bloquea TCP 443 o no hay ningún servicio web en escucha. En Windows PowerShell, utiliza Test-NetConnection 203.0.113.25 -Port 443; en Linux o macOS, utiliza nc -zv 203.0.113.25 443. En el servidor, ss en Linux o netstat pueden mostrar los puertos en escucha y las conexiones. Una conexión fallida por sí sola no distingue un bloqueo de cortafuegos de un servicio que ha dejado de escuchar.

Inspecciona los nombres y el comportamiento de la aplicación

En las capas superiores, una consulta de nombres fallida, un error de certificado, un nombre de servidor incorrecto o un inicio de sesión fallido requieren evidencias de la aplicación. Utiliza nslookup o dig para inspeccionar las respuestas DNS. Utiliza un navegador o curl para comprobar HTTP/HTTPS y consulta los registros de la aplicación en busca de errores del servicio.

Investiga el fallo de una página

Un portátil no puede abrir https://intranet.example.com. Primero, el ping a su puerta de enlace tiene éxito. Después, el ping a la IP del servidor 203.0.113.25 tiene éxito. Estos resultados respaldan el funcionamiento de los trayectos local y enrutado utilizados por esas pruebas. Si nslookup intranet.example.com no puede obtener una respuesta, investiga la consulta DNS y la configuración en la capa de aplicación.

En otro resultado, el nombre se resuelve correctamente y el servidor responde a ping, pero TCP 443 falla. Comprueba el servicio en escucha del servidor y la regla de cortafuegos pertinente. Si TCP 443 conecta y HTTPS informa de un error de certificado, avanza hacia el certificado y la configuración del nombre del servidor. Cada prueba acota la siguiente pregunta; no certifica todos los tipos de tráfico de la red.