1.5. Introducción a los modelos de red OSI y TCP/IP
Proceso de encapsulación y desencapsulación
Práctica Wireshark modelos de red
Introducción a los Modelos de Red OSI y TCP/IP: Capas, Encapsulación y Práctica con Wireshark
Tabla de contenidos
- Qué es un modelo de red y por qué existe
- El modelo de red OSI y sus 7 capas
- Capas superiores del modelo OSI
- Diferencia entre capas superiores e inferiores
- Capas inferiores del modelo OSI
- Regla nemotécnica para memorizar las capas
- El modelo TCP/IP y su relación con OSI
- Proceso de encapsulación y desencapsulación
- Terminología de encapsulación: los PDUs
- Interacción de capas del mismo nivel (Same-Layer Interaction)
- Práctica: capturando tráfico con Wireshark
- Preguntas frecuentes
- Evaluación
¿Qué es un modelo de red y por qué existe?
Un modelo de red es un conjunto de reglas y funciones organizadas en capas, donde cada capa cumple una tarea específica para que dos dispositivos puedan comunicarse a través de una red. Cada capa trabaja con sus propios protocolos, y un protocolo no es más que un conjunto de reglas estandarizadas que definen cómo se realiza una tarea concreta dentro de esa capa.
En esta clase de Modelos de red OSI y TCP/IP, y en las siguientes seguimos con la teoría de las redes de computadoras. Tranquilos, que vamos a tener mucha práctica más adelante, pero antes de sentarnos a configurar dispositivos necesitamos dominar los conceptos fundamentales. Sin una base teórica sólida, la configuración se vuelve un ejercicio mecánico y cuando aparece un problema real en producción, no hay manera de resolverlo sin entender qué está pasando por debajo.
En el desarrollo de la clase vamos a analizar el funcionamiento lógico de una red estudiando los modelos de red y las funciones que cumple cada capa para que dos dispositivos logren comunicarse. Este es uno de los conceptos más importantes de todo el curso CCNA y uno de los que más peso tiene en el examen de certificación.
¿Por qué necesitamos un modelo de red?
Para que dos dispositivos finales se comuniquen con éxito, todos los dispositivos involucrados en el camino tienen que hablar el mismo idioma. Y para que eso sea posible, todos deben trabajar con el mismo modelo de red. Si cada uno hablara un idioma distinto, la situación sería como intentar que alguien que habla japonés se entienda con alguien que habla portugués sin ningún intermediario: simplemente no hay comunicación.
Trabajemos con la siguiente topología. Imaginen a la computadora PC intentando ver un video de YouTube alojado en el servidor SRV. Ese servidor puede estar en la misma oficina o al otro lado del planeta, y en el camino pueden existir desde un par de dispositivos intermedios hasta cientos de ellos, dependiendo de la distancia y la complejidad de la ruta.
Asumamos en el ejemplo que todos los dispositivos involucrados en la comunicación ya están utilizando el mismo modelo de red que lo vemos representado por 7 capas. Ahora, para que la computadora pueda comunicarse con el servidor, necesita la ayuda de todas las capas del modelo de red. Cada una de las capas que vemos, cumple una función específica para que el mensaje de la computadora sea generado, tenga un formato adecuado, pueda viajar por la red y sea entendido por el dispositivo de destino.
Cuando el servidor responde, ocurre exactamente lo mismo pero en sentido inverso. Los dispositivos intermedios que se encuentran entre ambos extremos, ya sean firewalls, routers, switches o cualquier otro tipo de dispositivo de red, también utilizan el mismo modelo de red que les permite cumplir sus funciones para el envío del mensaje desde un origen hasta un destino en particular.
El modelo de red OSI y sus 7 capas
El modelo OSI (Open System Interconnection) es un modelo de red compuesto por 7 capas, desarrollado por la ISO (International Organization for Standardization) como referencia para estandarizar la comunicación entre dispositivos de distintos fabricantes. Cada capa cumple una función específica y se comunica únicamente con la capa inmediatamente superior e inferior. El modelo que se emplea en la imagen anterior es OSI. Las 7 capas de este modelo, lastimosamente las deben memorizar para el examen de certificación.
Lista de las 7 capas del modelo OSI
De arriba hacia abajo, las 7 capas del modelo OSI son:
- Capa 7: Aplicación
- Capa 6: Presentación
- Capa 5: Sesión
- Capa 4: Transporte
- Capa 3: Red
- Capa 2: Enlace de datos
- Capa 1: Física
De nuevo, en cada una de estas capas tenemos protocolos que permiten que la comunicación se complete entre 2 dispositivos. Cada capa se comunica con la capa inmediatamente superior e inferior, y los datos van pasando por todas las capas cuando son generados o recibidos por un dispositivo.
Tabla resumen de capas, funciones y protocolos
Antes de ingresar a estudiar las diferentes capas a detalle, esta tabla sirve como mapa general de todo el modelo. Les ayuda tenerla presente durante las siguientes secciones y volver a ella cuando necesiten ubicar rápidamente qué hace cada capa y qué protocolos trabajan en ella.
| Capa | Nombre | Función principal | Ejemplos de Protocolos / estándares |
|---|---|---|---|
| 7 | Aplicación | Interfaz entre las aplicaciones del usuario y la red | HTTP, HTTPS, FTP, TFTP, SMTP, POP3, DNS, Telnet |
| 6 | Presentación | Formato, encriptación y compresión de los datos | ASCII, UNICODE, EBCDIC, JPEG, MPEG, MP3, SSL, MIME |
| 5 | Sesión | Establecer, mantener y terminar sesiones de comunicación | NetBIOS, RPC |
| 4 | Transporte | Entrega confiable o no confiable entre extremos, segmentación | TCP, UDP |
| 3 | Red | Direccionamiento lógico y enrutamiento de paquetes | IPv4, IPv6, OSPF, EIGRP, BGP |
| 2 | Enlace de datos | Acceso al medio y direccionamiento físico (MAC) | Ethernet, PPP, HDLC, Frame Relay |
| 1 | Física | Transmisión de bits a través del medio físico | Cable UTP, fibra óptica, señales eléctricas y ópticas |
Capas superiores del modelo OSI
Las capas superiores del modelo OSI son la 7, 6 y 5: Aplicación, Presentación y Sesión. Son las responsables de todo lo que ocurre con los datos antes de que viajen por la red: cómo los genera la aplicación, qué formato tienen y cómo se organiza el diálogo entre los dos extremos que se comunican.
Capa de Aplicación (capa 7)
Comencemos la descripción del modelo con la capa de Aplicación. Es la capa 7 del modelo OSI y la más cercana al usuario. Es donde trabajan los protocolos que dan servicio a las aplicaciones, como HTTP, HTTPS, FTP, SMTP, POP3, DNS o Telnet. En la práctica, esta capa funciona como la puerta de entrada a la red para cualquier programa que necesite comunicarse con otro dispositivo.
Acá tengan en cuenta un detalle muy importante que suele confundir a muchos estudiantes: no deben mezclar la aplicación/programa o software del usuario con los protocolos de la capa de Aplicación. Los protocolos de la capa de Aplicación son una parte de la aplicación del usuario, pero no son lo mismo. La aplicación es el software que el usuario ve y utiliza directamente; los protocolos de la capa de Aplicación son los mecanismos internos que esas aplicaciones utilizan para comunicarse a través de la red.
Para entender mejor estos conceptos, trabajemos nuevamente con un ejemplo: supongamos que queremos ver un video de YouTube. Todo el proceso descrito a continuación lo vemos en la siguiente imagen
Para ver un video de YouTube, o para ingresar a cualquier página web, necesitamos un navegador, no es cierto? Supongamos que abrimos en la computadora «PC» el navegador Firefox. Este navegador es la aplicación del usuario; podría ser cualquier otro navegador: Google Chrome, Microsoft Edge, Opera, Safari, el que deseen.
Una vez dentro escribimos la URL del video, y a continuación, el navegador no se comunica directamente con el servidor, sino que existe una comunicación interna donde le pide a un protocolo de capa de Aplicación que lo haga por él. En este caso, ese protocolo es HTTP (o HTTPS, que es HTTP con encriptación).
Es este protocolo HTTP el que sabe exactamente cómo hablarle a un servidor web: conoce las reglas, los mensajes válidos y las respuestas esperadas. Estos protocolos son los que generan los mensajes necesarios para comunicarse con el servidor, de manera que el servidor entienda la solicitud y nos devuelva el video de YouTube que estamos pidiendo.
Uno de los mensajes que tiene HTTP/HTTPS definido en su especificación es el método GET, que se utiliza para solicitar una página web. En términos sencillos, un GET traducido a lenguaje humano sería: «servidor, necesito que me envíes la página www.youtube.com». Para que el servidor entienda ese mensaje, tiene que hablar el mismo idioma. Es decir, en la capa de Aplicación del servidor también tiene que estar ejecutándose HTTP. Si el cliente habla HTTP y el servidor no, no hay conversación posible. Este principio se repite en todas las capas: ambos extremos deben entender el mismo protocolo para que la comunicación funcione.
Ejemplos de protocolos de capa de Aplicación
El mismo esquema que vimos con el navegador y HTTP se repite con cualquier otra aplicación de red. Cada aplicación que utilizamos internamente tiene asociado un protocolo de capa de Aplicación que le permite comunicarse en la red. Por ejemplo, ¿Qué pasa si ahora utilizamos una aplicación de correo electrónico?
Como vemos en la imagen anterior, ahora utilizamos una aplicación de correo electrónico como Outlook o Zimbra, y ya no un navegador web, estos son los softwares o aplicaciones del usuario, que se tienen que comunicar internamente con el protocolo de la capa de Aplicación correspondiente. En este caso, internamente se apoyan en protocolos como POP3 o IMAP para obtener correos desde un servidor, y en SMTP para enviarlos. Cada aplicación tiene detrás, un protocolo de capa de Aplicación que sabe exactamente cómo conversar con el servidor correspondiente. Nuevamente, si utilizamos en la capa de Aplicación al protocolo POP3, el servidor también tiene que conocer a este protocolo para poder procesar la solicitud.
Otros protocolos que podemos encontrar en esta capa son, por ejemplo:
- FTP y TFTP: para los programas de transferencia de archivos
- Telnet y SSH: para los programas que permiten conectarnos de manera remota a dispositivos de red
- DNS: para resolución de nombres de dominio a direcciones IP
- HTTP y HTTPS: para navegación web
Varios de estos los desarrollaremos a fondo en clases posteriores, así que no se preocupen si por ahora son solo nombres. Lo importante es ubicar en qué capa trabajan y para qué sirven.
Tengan en cuenta que la lista anterior es apenas una muestra. En la capa de Aplicación existen cientos de protocolos, cada uno pensado para un caso de uso específico. Skype, Zoom, Spotify, Teams: cada aplicación que necesita una red o Internet para funcionar tiene detrás un protocolo de capa de Aplicación, y no tiene por qué ser uno de los tradicionales. Muchos fabricantes desarrollan sus propios protocolos propietarios optimizados para lo que hace su producto.
Con esto queda claro el rol de la capa de Aplicación: generar mensajes o datos listos para viajar. En el ejemplo del navegador, el GET es el mensaje generado, y dentro de ese GET está la solicitud de la página web. Cuando el servidor responda, también lo hará con un mensaje generado en su propia capa de Aplicación, que en este caso tendrá el contenido de la página que pedimos.
Estos datos que se generan en la capa de Aplicación no van a llegar mágicamente a los dispositivos de destino. Para que estos datos o mensajes lleguen a su destino tienen que trabajar muchos otros protocolos, y es por eso que estos datos generados en la capa de Aplicación son entregados a la siguiente capa del modelo de red, la cual tendrá otras tareas y funciones para que se cumpla la comunicación. En este caso, la responsabilidad se pasa a la capa de Presentación.
Capa de Presentación (capa 6)
La capa de Presentación es la capa 6 del modelo OSI y se encarga de tres responsabilidades principales: darle formato a los datos para que ambos extremos los interpreten igual, encriptar la información cuando se necesita confidencialidad y comprimir los datos para que ocupen menos tamaño en el viaje por la red. En una frase: es la capa que garantiza que lo que envía un dispositivo sea exactamente lo que entiende el otro.
Formato y representación de datos (EBCDIC, ASCII, UNICODE)
La primera función de la capa de Presentación tiene que ver con un problema sutil pero real: dos computadoras pueden representar los mismos datos de forma diferente. La capa de Presentación se asegura de que eso no rompa la comunicación. ¿A qué se refiere esto?
Las computadoras se comunican en el lenguaje binario, es decir, con valores de unos y ceros. Si estamos enviando una imagen por la red, esa imagen es equivalente a ciertos valores binarios, supongamos 111100001111. Cada uno de estos valores binarios es conocido como bit. De igual forma, si enviamos un archivo de música por la red, ese archivo equivale a otros valores binarios diferentes, supongamos 101111110. Si enviamos textos por la red pasa lo mismo, una letra podría ser equivalente a 1010101 o algo similar. Sin embargo, el problema aparece cuando distintas arquitecturas o sistemas tienen convenciones diferentes para representar la misma información en valores binarios.
Por ejemplo, trabajemos con la siguiente imagen:
Veamos un caso concreto. Supongamos que un servidor envía la palabra «hola» como parte de una página web, y lo hace usando el código EBCDIC, una convención antigua de IBM para representar caracteres alfanuméricos en binario. El servidor convierte «hola» a una secuencia específica de bits según las reglas de EBCDIC.
La PC que recibe esos bits no conoce EBCDIC. Trabaja con ASCII, que es otra convención para mapear letras y números a binario. Si la PC interpreta los bits EBCDIC como si fueran ASCII, va a leer algo completamente diferente a «hola». La comunicación técnicamente ocurrió (llegaron los bits), pero el mensaje no se entendió.
Y acá es donde ingresa la capa de Presentación. Esta capa hace de traductor para que no importe qué tipo de representación de datos utilizan las diferentes computadoras. La capa de presentación traducirá entre las diferentes formas de representación de los datos. En el caso del ejemplo, la capa de Presentación de la PC diría algo así cuando recibe los bits: «Ok servidor, tus datos están en formato EBCDIC, por lo tanto yo voy a traducirlos al formato ASCII para que mi aplicación los pueda entender, y se pueda visualizar la palabra hola en la pantalla del usuario«.
En la práctica existen tres formas de resolver este problema de representación:
- Que el emisor envíe directamente en el formato que usa el receptor. Rápido pero obliga al emisor a conocer al receptor.
- Que el receptor detecte el formato del emisor y haga la conversión por su cuenta. Flexible pero carga todo el trabajo en el receptor.
- Que ambos extremos acuerden trabajar con un formato común estandarizado. Es la opción más aplicada hoy, y el estándar dominante es UNICODE, que cubre prácticamente todos los idiomas y sistemas de escritura del mundo.
❓ Preguntas Frecuentes
¿Cuál es la diferencia entre el modelo OSI y el modelo TCP/IP?
El modelo OSI tiene 7 capas y es un modelo de referencia conceptual creado para entender cómo debería funcionar la comunicación entre dispositivos. El modelo TCP/IP tiene 4 capas en su versión original (o 5 en algunas interpretaciones) y es el modelo que realmente se utiliza en Internet y en las redes actuales. TCP/IP combina las capas de aplicación, presentación y sesión del modelo OSI en una sola capa de aplicación, y combina las capas de enlace de datos y física en una sola capa de acceso a la red. Las capas de transporte y red son prácticamente equivalentes en ambos modelos. En el examen CCNA se evalúan ambos modelos, pero en la práctica real trabajamos con TCP/IP.
¿Qué nombre recibe el PDU en cada capa del modelo OSI y por qué es importante conocerlo?
El PDU (Protocol Data Unit) recibe un nombre específico en cada capa: en la capa de aplicación se denomina «datos» o «data», en la capa de transporte se denomina «segmento» (con TCP) o «datagrama» (con UDP), en la capa de red se denomina «paquete», en la capa de enlace de datos se denomina «trama» o «frame», y en la capa física se denomina simplemente «bits». Conocer esta terminología es importante tanto para el examen CCNA como para la vida profesional, ya que en la documentación técnica, en los comandos de diagnóstico, y en las conversaciones con otros ingenieros de redes se utilizan estos términos constantemente. Por ejemplo, cuando alguien pregunta «cuántos bytes tiene el header del paquete» está refiriéndose específicamente al header de capa 3 (IP), que tiene 20 bytes en su estructura básica.
📚 Recursos relacionados
🎓 Lección anterior
📖 Lección siguiente
🔗 Documentación complementaria
PREGUNTAS
Las preguntas que encontraras en esta sección, son similares a las que te encontraras en el examen de certificación.¡PARTICIPEMOS!
Si te quedaron dudas de la lección, escríbela a continuación y así todos podemos participar y ayudarte.- Este debate tiene 38 respuestas, 19 mensajes y ha sido actualizado por última vez el hace 1 año, 6 meses por
.
-
Hola Ever!
Esa es una pregunta muy interesante y que yo también me la hice cuando iniciaba mis estudios… ¿dónde están estos protocolos? ¿Están en el sistema operativo? ¿Cómo interactúan entre sí de manera real?
Tratar de entender donde encaja una tecnología dentro del modelo de red y tratar de entender específicamente que parte de una computadora corresponde a qué capa del modelo de red no es simple… lastimosamente muchas tecnologías en las redes de computadoras han sido diseñadas sin tener en mente a los modelos de red, algunas tecnologías abarcan 2 capas o más capas, algunas otras conceptualmente no encajan en ninguna capa.
De manera general, mientras estamos en las capas más inferiores, lidiamos con más hardware, ahí la cosa todavía tiene un sentido para nosotros, si vemos un cable… sabemos que en nuestras manos está la capa física, si vemos un adaptador de red, sabemos que ahí está la capa de enlace de datos/acceso-a-la-red, ya que a través de ese componente los bits son introducidos y sacados del medio de transmisión… pero a medida que vamos subiendo en las capas… todo se vuelve más abstracto, y ya no lidiamos con una pieza de hardware o con conceptos específicos y puntuales del sistema operativo, ahí ya interactuamos con varios componentes.
No existe un momento en que apagues o enciendas el modelo de red, el modelo de red no está concentrado en un punto de la computadora, diríamos que «comenzamos» a utilizar el modelo cuando hacemos uso de una aplicación de red (software de usuario), las aplicaciones de red son las que están programadas para utilizar un determinado protocolo de las diferentes capas (menos capa física y enlace de datos), entonces todo se da a nivel de programación para utilizar un protocolo de aplicación, transporte y red… cuando tu programas tu aplicación de red (código), ahí defines si utilizaras UDP o TCP para envíar tus datos, también defines con código el protocolo IP que vas a utilizar, y defines todo lo relevante a los protocolos de aplicación. El «cómo» utilizar esos protocolos (UDP/TCP/IP) en tu aplicación ya está definido, ya que la mayoría de los protocolos utilizados son estándares cuyas definiciones son públicas a través de los documentos RFC.
Un componente esencial en la programación de aplicaciones de red son los «sockets», los datos de las aplicaciones «salen» del «dominio» de las aplicaciones al enviar los datos por los «sockets», que también son creados en las aplicaciones al utilizar funciones que ya tienen los diferentes sistemas operativos… los sockets son las puertas de salida de los datos de la aplicación de red para llegar al mundo exterior (sistema operativo y red)…esos datos son almacenados en «lugares de memoria» del SO para que la NIC los agarre y los envíe por el medio físico.
De nuevo, para tener comunicación entre el sistema operativo y la aplicación de red, existen funciones (ya existentes en los SO) que se deben introducir al código de las aplicaciones de red, por ejemplo en Windows (es lo mismo para todos los sistemas operativos) se utiliza la función SOCK_DGRAM en tu programa… para decirle al sistema operativo que utilizaras UDP para el transporte de los datos de tu aplicación; también existe la función SOCK_STREAM para decirle que utilizaras TCP, y también existe (entre muchas otras) la función AF_INET para decirle que utilizaras IPv4, a esas funciones tú ya les das los datos que necesiten para funcionar. Esas funciones ya están programadas en el sistema operativo para realizar las diferentes tareas de los protocolos de transporte y red, y ahí ya tendrías que analizar como están implementadas esas funciones en cada sistema operativo.
En sintesis
Aplicación de red – Cuando ejecutas tu aplicación de red, primero se realiza la creación del socket -> definir IP destino y puerto de destino por la aplicación, y definir IP de origen y puerto de origen por el sistema operativo (Esto puede variar) al utilizar funciones en tu programa de aplicación (funciones definidas en el SO)… una vez se crea el socket recién vienen las líneas de código de la aplicación en sí… acá se generan tus datos que quieres enviar al dispositivo de destino.
Entonces con todo esto ¿qué puedes entender?… puedes ver que los limites no están definidos… no encontramos a todos los protocolos en 1 punto de la computadora. Cada componente de hardware/software es encargado de interactuar con otros componentes de hardware/software. Los protocolos de aplicación sí están presentes en la aplicación de red que tu programas… pero los conceptos de IP TCP UDP ya no queda tan claro, vemos que sí se utilizan dichos conceptos en las aplicaciones de red y también en el sistema operativo general, entonces esos protocolos donde encajan?…puedes ver que es algo abstracto, es una interacción entre el sistema operativo general, la aplicación de red y la NIC.
Si quieres ahondar más en este tema, tienes que introducirte en el concepto de programación de aplicaciones de red y programación de sockets.
Espero que mi respuesta te haya ayudado y no me haya enredado en la explicación.
Atento a tus comentarios.
Efectivamente Ever
La generación de datos se da al utilizar la aplicación de red que se programa, de acuerdo al tipo de aplicación creada se generan diferentes tipos de datos que van a utilizar otros protocolos de las diferentes capas de Transporte y Red para que puedan llegar a su destino. Esos protocolos de Transporte y Red que vas a utilizar también son definidos en el código de la aplicación de red, sin embargo ahí solo defines que vas utilizar cierto protocolo de Red y de Transporte, pero las tareas específicas de esos protocolos de Red y de Transporte ya las realiza el sistema operativo general y no así la aplicación de red que tu creaste.
Estoy atento si tuvieras más consultas sobre este tema. Te recomendaría ver los temas de UDP y TCP y volver a este tema para entenderlo a más detalle.
Atento a tus comentarios.
- Debes estar registrado para responder a este debate.