Modelos OSI y TCP/IP — teoría con capas, sobres dentro de sobres y un switch que no sabe tu IP (y la práctica que subí a las 23:57)
Domingo, 23:57. Tres minutos para que cerrara la entrega de la práctica de IC2 y la barra del campus virtual se quedó clavada en «Subiendo…». En el grupo de clase empezaron los diagnósticos: «será el Wi-Fi», «será el switch del aula», «será el router de la facultad», «será el servidor del campus, que está caído». Todos opinábamos y ninguno sabía de verdad qué hace cada aparato ni qué mira cada uno de lo que mandamos. (Llegó a las 23:59, por si te lo preguntas.)
Esa noche entendí para qué sirve este tema. Cuando subes un archivo, tu portátil no lanza los bytes al aire sin más: los mete en un sobre, ese sobre en otro y ese en otro más, y cada aparato del camino abre solo los sobres que le tocan. Hoy vas a ver qué es un protocolo, qué es una arquitectura de protocolos, el modelo de tres capas, las PDU y el encapsulado, la arquitectura TCP/IP, el modelo OSI y, lo que más cae en el examen, en qué capa trabajan el switch y el router en cada modelo. Si vienes de la Introducción a las redes, ya sabes qué es un switch, un router y la conmutación de paquetes; hoy les ponemos capas. Y cuando acabes, tienes los ejercicios tipo examen de este tema.
El ejemplo que nos acompaña todo el artículo: subes tu práctica de IC2 al campus virtual desde el portátil, conectado al Wi-Fi de la facultad. El portátil tiene la IP 10.110.7.24, el servidor del campus la 10.200.1.80 y entre medias hay un switch y el router de la facultad.
Tabla de Contenidos
Qué es un protocolo
Antes de las capas, la palabra que lo sostiene todo. Dos programas en equipos distintos (tu navegador y el servidor del campus) solo se entienden si siguen las mismas reglas. Es igual que una conversación entre personas: si yo digo «hola» y tú me contestas con un número de teléfono, algo ha fallado.
Un protocolo es el conjunto de reglas que definen cómo se comunican dos entidades: el formato, el significado y la temporización de los mensajes que se intercambian.
Fíjate en el dibujo: a la izquierda, una conversación humana (saludo, pregunta, respuesta); a la derecha, lo que hace tu portátil al subir la práctica: pide una conexión TCP, el servidor responde, el portátil envía POST /entrega con el archivo y el servidor contesta 200 OK. Las dos siguen un guion. Si el portátil enviara el archivo sin pedir antes la conexión, el servidor no sabría qué hacer con él.
Entidades y sistemas
Los apuntes distinguen dos palabras que suenan parecido y caen en el test:
| Concepto | Qué es | Ejemplos |
|---|---|---|
| Entidad | Lo que se comunica: el software que envía y recibe | El navegador, el programa de correo, una terminal, una aplicación de transferencia de ficheros |
| Sistema | Dónde vive esa entidad: el aparato | Tu portátil, el servidor, un terminal, un sensor remoto |
Dicho de otra forma: el navegador (entidad) vive en tu portátil (sistema). Un protocolo se usa para comunicar entidades de sistemas diferentes.
Marcar «el portátil» o «el sensor remoto» como entidades. Son sistemas. Las entidades son siempre programas: aplicaciones de usuario, correo, terminales…
Los tres puntos clave de un protocolo
Cualquier protocolo se describe con tres preguntas, y esto es carne de pregunta de huecos:
| Punto clave | Responde a… | Qué incluye | En nuestro ejemplo |
|---|---|---|---|
| Sintaxis | ¿Cómo es el mensaje? | Formato de los datos y niveles de señal | La cabecera TCP mide 20 bytes y empieza por los puertos |
| Semántica | ¿Qué significa? | Información de control y manejo de errores | Un código que significa «este trozo llegó mal, reenvíalo» |
| Temporización | ¿Cuándo y en qué orden? | Sintonía de velocidades y secuenciación | El servidor no recibe más rápido de lo que procesa y los trozos se recolocan en orden |
Sintaxis = forma, semántica = significado, temporización = tiempo. Si en la pregunta sale «niveles de señal», es sintaxis aunque suene a física; si sale «manejo de errores», semántica.
Arquitectura de protocolos: dividir para entenderse
Subir un archivo implica muchísimas cosas a la vez: entender qué es un archivo, trocearlo, numerar los trozos, saber a qué equipo va, convertirlo en señales… Meter todo eso en un único protocolo gigante sería inmanejable. La solución es la de siempre en informática: dividir el problema en módulos.
Una arquitectura de protocolos es la organización en capas de varios protocolos: indica qué hace cada capa, cómo interactúan entre sí y qué información añade cada una al mensaje para que pueda transmitirse correctamente.
El ejemplo clásico de los apuntes es una transferencia de archivos dividida en tres módulos:
- Aplicación para la transferencia de archivos: sabe de archivos y órdenes («sube este fichero»).
- Módulo del servicio de comunicaciones: se asegura de que los datos lleguen bien a la aplicación correcta del otro lado.
- Módulo de acceso a la red: habla con la red concreta a la que está conectado el equipo.
Ninguno necesita saber cómo trabajan los otros: solo qué le pide el de arriba y qué le ofrece el de abajo. Esos tres módulos son, precisamente, el modelo de tres capas.
Protocolo y arquitectura no son lo mismo. Un protocolo es un conjunto de reglas; una arquitectura organiza varios protocolos en capas. TCP/IP y OSI son arquitecturas (o modelos), no protocolos sueltos.
El modelo de tres capas
Es la versión simplificada que usan los apuntes para entender la idea antes de TCP/IP. Tu portátil (computador X) y el servidor del campus (computador Y) tienen las mismas tres capas.
Mira las flechas discontinuas del dibujo: cada capa «habla» con su igual del otro equipo usando su protocolo (aplicación con aplicación, transporte con transporte). Pero los datos de verdad no viajan en horizontal: bajan por tu portátil, cruzan la red y suben por el servidor.
| Capa | Qué hace | Detalle que cae en el examen |
|---|---|---|
| Aplicación | Permite que los programas usen la red sin saber cómo funciona por debajo | Admite varias aplicaciones a la vez (correo, transferencia de ficheros) |
| Transporte | Entrega los datos a la aplicación correcta: comunicación extremo a extremo entre aplicaciones de equipos distintos | Identifica la aplicación destino (puertos o SAP), segmenta y reensambla, controla errores y orden. Es independiente de la aplicación y de la red |
| Acceso a la red | Intercambio de datos entre el computador y la red a la que está conectado | El emisor da a la red la dirección de destino y puede pedir servicios (prioridad). Depende del tipo de red (LAN, conmutación de paquetes…) |
¿Por qué transporte es independiente y acceso a la red no? Imagina que cambias el Wi-Fi por un cable Ethernet a mitad de la entrega. Transporte sigue troceando y numerando exactamente igual: no sabe ni le importa por dónde salen los datos. Acceso a la red, en cambio, es la que habla con el Wi-Fi o con el cable, así que es la que cambia.
Decir que la capa de aplicación «entrega los datos a la aplicación correcta». Suena lógico por el nombre, pero eso lo hace transporte, con los puertos. Aplicación es el programa en sí.
PDU y encapsulado: sobres dentro de sobres
Aquí está el corazón del tema. En cada capa se usa un protocolo, y cada protocolo añade información de control (una cabecera) a los datos que recibe de la capa de arriba.
Una PDU (unidad de datos de protocolo) es el bloque que forma una capa: los datos que recibe de arriba más la información de control que añade ella.
En el modelo de tres capas, el proceso al enviar es este:
- La aplicación entrega los datos (tu práctica).
- Transporte puede trocearlos. A cada trozo le pone una cabecera de transporte con tres cosas: el SAP o puerto de destino, el número de secuencia y un código de detección de errores. El resultado es la PDU de transporte.
- Acceso a la red añade su cabecera, con la dirección del computador de destino y la solicitud de recursos a la red. El resultado es lo que viaja: un paquete de red.
Cada cabecera responde a una pregunta distinta, y esto es lo que más ayuda a no liarse:
| Cabecera | Pregunta que responde | Dato que lleva |
|---|---|---|
| Transporte | ¿A qué servicio o aplicación dentro del equipo va? | Puerto o SAP de destino (DSAP) |
| Acceso a la red | ¿A qué dispositivo (siguiente salto) entrego esto? | Dirección del host de destino (DHost) |
En TCP/IP el sobre tiene una capa más: la capa Internet añade la dirección IP entre medias. Así se ve con los datos reales del simulador de este artículo, que trocea la práctica en fragmentos de como mucho 1460 bytes:
Fíjate en que la caja de datos no cambia nunca (1460 B en todas las filas): lo único que crece son los sobres de la izquierda. Las cuentas cuadran: 1460 + 20 (TCP) = 1480 B de segmento; 1480 + 20 (IP) = 1500 B de datagrama; 1500 + 14 + 4 (Ethernet y su FCS, un código de comprobación al final) = 1518 B de trama; y 1518 × 8 = 12 144 bits por el aire.
| Capa (TCP/IP) | Nombre de su PDU | Lo que añade |
|---|---|---|
| Aplicación | Datos (mensaje) | — |
| Transporte | Segmento | Puertos, número de secuencia, detección de errores |
| Internet | Datagrama (paquete IP) | Direcciones IP de origen y destino |
| Acceso a la red | Trama | Direcciones MAC de origen y del siguiente salto (y el FCS) |
| Física | Bits | Nada: convierte la trama en señales |
Al recibir se hace el camino inverso (desencapsulado): cada capa quita su cabecera, comprueba lo suyo y pasa el resto hacia arriba, hasta que el servidor del campus tiene tu práctica entera.
Si te preguntan qué añade la cabecera de transporte, piensa en lo que necesitas para recomponer un archivo troceado: a quién va (puerto), en qué orden (secuencia) y si llegó bien (detección de errores).
La arquitectura TCP/IP
Ahora el modelo de verdad, el que usa Internet. La arquitectura TCP/IP salió de ARPANET, una red experimental de conmutación de paquetes financiada por la DARPA (la Agencia de Proyectos de Investigación Avanzada para la Defensa de EE. UU.), y se ha erigido como el estándar de Internet. Un detalle que preguntan: no existe un modelo oficial de TCP/IP, pero sí uno funcional. En la asignatura ese modelo tiene cinco capas.
El dibujo resume lo que hace cada capa y qué dirección añade. Vamos una por una, de arriba abajo, con nuestra entrega:
- Aplicación: posibilita las aplicaciones de usuario. Tu navegador habla HTTPS con el servidor del campus (otros ejemplos: HTTP, SMTP para el correo).
- Transporte (origen-destino): comunicación extremo a extremo entre las dos aplicaciones. Con TCP, el intercambio es seguro y los datos llegan en el mismo orden en que se enviaron. Aquí van los puertos: el navegador usa el
51234y el servidor escucha en el443. - Internet (IP): permite que los equipos estén en redes diferentes: se encarga del encaminamiento a través de varias redes. Se implementa tanto en los equipos finales como en los routers intermedios. Aquí se añade la dirección IP (
10.110.7.24→10.200.1.80). Existen dos versiones, IPv4 e IPv6. - Acceso a la red: el intercambio de datos entre el equipo y la red a la que está conectado. Debe dar a la red la dirección del destino e implica servicios como pedir una prioridad. Aquí se añade la dirección MAC.
- Física: la interfaz física entre el equipo y el medio de transmisión. Especifica las características del medio, la naturaleza de las señales y la velocidad de datos.
Verás libros que dicen que TCP/IP tiene cuatro capas porque juntan física y acceso a la red. En IC2 son cinco: si te piden el número, escribe 5.
TCP y UDP, los dos de transporte
En la capa de transporte hay dos protocolos y suelen preguntar en qué se diferencian:
| TCP | UDP | |
|---|---|---|
| Conexión | Orientado a conexión (primero se pide y se acepta, como en el dibujo del protocolo) | No orientado a conexión |
| Garantías | Entrega fiable, ordenada y sin duplicados; confirma con ACK (acuse de recibo) | No garantiza ni la entrega ni el orden |
| Coste | Más sobrecarga y más latencia | Poca sobrecarga, menos latencia |
| Cuándo | Subir la práctica, una web, el correo | Videollamadas, juegos, tiempo real |
Tu entrega va por TCP: no puede faltar ni un byte del archivo. Una videollamada de tutoría prefiere UDP: si se pierde un trozo de imagen, mejor seguir que congelarse esperando el reenvío.
El modelo OSI
OSI (Open Systems Interconnection, interconexión de sistemas abiertos) es el modelo de referencia que desarrolló la ISO (la Organización Internacional de Normalización). Tiene siete capas:
| Nº | Capa | Qué hace |
|---|---|---|
| 7 | Aplicación | La interacción con el usuario: las aplicaciones acceden a los servicios de red |
| 6 | Presentación | Garantiza que los datos tengan un formato utilizable; aquí se cifran |
| 5 | Sesión | Mantiene las conexiones; controla las sesiones |
| 4 | Transporte | Transmite con protocolos de transporte y garantiza que lo recibido sea idéntico a lo enviado |
| 3 | Red | Administra las direcciones de los datos y su paso entre redes |
| 2 | Enlace de datos | Define el formato de los datos en la red, observa errores de formato y controla el flujo |
| 1 | Física | Define el hardware de red y transmite el flujo de bits en bruto |
Para recordar el orden de arriba abajo (7 → 1): «Antes Pensaba Ser Todo Rico En Fama» → Aplicación, Presentación, Sesión, Transporte, Red, Enlace, Física. Si te piden ordenarlas de la 1 a la 7, léela al revés.
Y el dato histórico que cae en los V/F: el modelo de siete capas en su conjunto no ha prosperado como pila de protocolos real; la arquitectura TCP/IP se ha erigido como dominante. OSI se sigue usando muchísimo, pero como vocabulario: cuando un técnico dice «es un problema de capa 2», habla en OSI.
OSI frente a TCP/IP
Esta comparación es una de las preguntas de desarrollo que más se repiten, así que conviene tenerla dibujada en la cabeza:
Las cuatro capas de abajo van una a una (física con física, enlace de datos con acceso a la red, red con Internet y transporte con transporte). Las tres de arriba de OSI, en coral, se juntan en la capa de aplicación de TCP/IP: lo que OSI reparte en sesión, presentación y aplicación, TCP/IP lo deja en manos de la propia aplicación (por ejemplo, el cifrado de HTTPS lo hace el navegador).
| OSI | TCP/IP | |
|---|---|---|
| Origen | ISO, como modelo de referencia | ARPANET, financiada por DARPA |
| Capas | 7 | 5 (en la asignatura) |
| Arriba | Sesión, presentación y aplicación separadas | Una sola capa de aplicación |
| Abajo | Física, enlace de datos, red, transporte | Física, acceso a la red, Internet, transporte |
| En la práctica | Modelo teórico, vocabulario de referencia | El estándar real de Internet |
| Se parecen en… | Los dos se organizan en capas y cada capa añade su cabecera |
Mezclar los nombres de los dos modelos en la misma respuesta. Si la pregunta dice «en el modelo TCP/IP», la respuesta es Internet o acceso a la red; si dice «en OSI», es red o enlace de datos. «Capa de red» en una pregunta de TCP/IP suele contar como fallo.
Switch y router en cada modelo
Y llegamos a las preguntas cortas que más se repiten. Vuelve a la entrega de las 23:57: tu trama pasa primero por el switch del aula y después por el router de la facultad. ¿Qué abre cada uno?
El dibujo enseña hasta qué capa «sube» cada aparato. El switch solo tiene física y acceso a la red: recibe la trama, mira la dirección MAC de destino y la reenvía por el puerto donde está ese equipo. No abre el datagrama, así que no sabe nada de tu IP. El router sube una capa más: abre la trama, lee la dirección IP de destino del datagrama y decide por dónde seguir.
| Switch | Router | |
|---|---|---|
| Qué dirección usa | MAC (física) | IP |
| Qué une | Equipos de una misma red | Redes diferentes |
| Capa en TCP/IP | Acceso a la red | Internet |
| Capa en OSI | Enlace de datos (capa 2) | Red (capa 3) |
| PDU que maneja | Trama | Datagrama |
| Extra | — | En casa suele hacer también NAT y DHCP |
Y el datagrama, que también lo preguntan por separado, vive en la capa Internet de TCP/IP, que es la capa de red en OSI.
La MAC cambia en cada salto; la IP no
Hay un detalle que explica por qué el router «ve el siguiente salto». La dirección MAC solo sirve para un tramo: de un equipo al siguiente dentro de una misma red. Cuando tu trama llega al router, este la desmonta, lee la IP, y construye una trama nueva para el siguiente tramo, con MAC nuevas.
Compara las dos tarjetas: en el tramo 1, la MAC de destino es la del router (00:1b:21:aa:10:01), no la del servidor, porque el router es el siguiente salto. En el tramo 2 las dos MAC han cambiado. En cambio, las IP (10.110.7.24 → 10.200.1.80) y los puertos (51234 → 443) viajan intactos de punta a punta. Si entre medias hubiera cinco routers, la MAC se reescribiría cinco veces y la IP ninguna.
El router ve el siguiente salto; el switch ve la dirección final dentro de la LAN.
Errores típicos
Confundir protocolo con arquitectura de protocolos. Uno es un conjunto de reglas; la otra organiza varios protocolos en capas y dice qué añade cada una.
Colocar el switch en la capa de red «porque también reenvía». Reenvía tramas por MAC dentro de la misma red: capa 2 de OSI, acceso a la red en TCP/IP.
Pensar que la dirección MAC de destino de tu trama es la del servidor. Es la del siguiente salto (normalmente, tu router).
Decir que UDP es «TCP pero más rápido y también fiable». UDP es más rápido precisamente porque no garantiza la entrega ni el orden.
Contestar «4» cuando preguntan cuántas capas tiene TCP/IP en IC2. En los apuntes son 5.
Compruébalo con Python
Para ver el encapsulado con números, aquí tienes un simulador que hace lo que hace tu portátil con la práctica: trocea 3000 bytes de datos en segmentos de como mucho 1460 bytes (lo máximo que cabe en una trama Ethernet normal) y le añade a cada trozo las tres cabeceras, contando cuántos bytes y bits salen al final. Los datos son fijos, así que no hace falta teclear nada.
# Simulador de encapsulado: entregar la práctica de IC2 en el campus virtual
# Cada capa de TCP/IP envuelve lo que le da la de arriba con su propia cabecera.
DATOS = 3000 # bytes que la aplicación (HTTPS) quiere enviar
MSS = 1460 # máximo de datos por segmento TCP sobre Ethernet
CAB_TCP, CAB_IP, CAB_ETH = 20, 20, 18 # cabeceras mínimas; Ethernet = 14 + 4 de FCS
origen = {"puerto": 51234, "ip": "10.110.7.24", "mac": "3c:52:82:1a:7e:04"}
destino = {"puerto": 443, "ip": "10.200.1.80"}
mac_salto = "00:1b:21:aa:10:01" # la MAC del router de la facultad, NO la del servidor
# Transporte: trocea los datos en fragmentos de como mucho MSS bytes
trozos, resto = [], DATOS
while resto > 0:
trozos.append(min(MSS, resto)) # el último trozo se lleva lo que sobre
resto -= trozos[-1]
print(f"Datos de aplicación: {DATOS} B -> {len(trozos)} segmentos")
print(f"{'Nº':>2} {'sec':>5} {'datos':>6} {'segmento':>9} {'datagrama':>10} {'trama':>6} {'bits':>6}")
total, sec = 0, 1 # sec = número de secuencia (primer byte del trozo)
for n, datos in enumerate(trozos, start=1):
segmento = datos + CAB_TCP # + puertos, nº de secuencia y código de error
datagrama = segmento + CAB_IP # + IP de origen y de destino
trama = datagrama + CAB_ETH # + MAC de origen y del siguiente salto
print(f"{n:>2} {sec:>5} {datos:>6} {segmento:>9} {datagrama:>10} {trama:>6} {trama * 8:>6}")
total += trama
sec += datos # el siguiente trozo empieza donde acabó este
extra = total - DATOS
print(f"Bytes en el cable: {total} (cabeceras: {extra} B, {100 * extra / total:.1f} %)")
print(f"Puerto: {origen['puerto']} -> {destino['puerto']} (lo mira el servidor: ¿qué servicio?)")
print(f"IP: {origen['ip']} -> {destino['ip']} (lo mira el router: ¿qué red?)")
print(f"MAC: {origen['mac']} -> {mac_salto} (lo mira el switch: ¿qué puerto de la LAN?)")
La salida real de su única ejecución:
Datos de aplicación: 3000 B -> 3 segmentos Nº sec datos segmento datagrama trama bits 1 1 1460 1480 1500 1518 12144 2 1461 1460 1480 1500 1518 12144 3 2921 80 100 120 138 1104 Bytes en el cable: 3174 (cabeceras: 174 B, 5.5 %) Puerto: 51234 -> 443 (lo mira el servidor: ¿qué servicio?) IP: 10.110.7.24 -> 10.200.1.80 (lo mira el router: ¿qué red?) MAC: 3c:52:82:1a:7e:04 -> 00:1b:21:aa:10:01 (lo mira el switch: ¿qué puerto de la LAN?)
Tres segmentos, dos llenos y uno pequeño, y al final las tres direcciones que acompañan a cada trozo. Vamos por partes.
El troceo, vuelta a vuelta
El bucle while es la capa de transporte segmentando:
# Transporte: trocea los datos en fragmentos de como mucho MSS bytes
trozos, resto = [], DATOS
while resto > 0:
trozos.append(min(MSS, resto)) # el último trozo se lleva lo que sobre
resto -= trozos[-1]
Cada vuelta se lleva min(MSS, resto): 1460 bytes mientras quede de sobra y lo que sobre en la última. ¿Por qué min y no restar siempre 1460? Porque en la tercera vuelta solo quedan 80 bytes, y restar 1460 dejaría resto en negativo y un trozo inventado.
| Vuelta | resto antes | Trozo | resto después |
|---|---|---|---|
| 1 | 3000 | 1460 | 1540 |
| 2 | 1540 | 1460 | 80 |
| 3 | 80 | 80 | 0 → sale del bucle |
Comprobación: 1460 + 1460 + 80 = 3000. No se pierde ni se inventa un byte.
Los sobres
El for hace el encapsulado de cada trozo, de dentro afuera:
for n, datos in enumerate(trozos, start=1):
segmento = datos + CAB_TCP # + puertos, nº de secuencia y código de error
datagrama = segmento + CAB_IP # + IP de origen y de destino
trama = datagrama + CAB_ETH # + MAC de origen y del siguiente salto
print(f"{n:>2} {sec:>5} {datos:>6} {segmento:>9} {datagrama:>10} {trama:>6} {trama * 8:>6}")
total += trama
sec += datos # el siguiente trozo empieza donde acabó este
Cada línea es una capa: el segmento suma la cabecera TCP, el datagrama suma la IP sobre el segmento (no sobre los datos) y la trama suma Ethernet sobre el datagrama. Por eso se encadenan: si sumaras las tres cabeceras siempre a datos, el código haría lo mismo con los números, pero perderías la idea de «sobre dentro de sobre». La variable sec es el número de secuencia: el primer byte de cada trozo (1, 1461, 2921), lo que usa TCP para recolocarlos en el destino aunque lleguen desordenados.
Qué observar:
- Los datos no cambian, las cabeceras se suman. En la fila 1: 1460 → 1480 → 1500 → 1518. Son exactamente los números del diagrama del encapsulado.
- El último segmento es pequeño. Solo lleva 80 bytes de datos, pero paga las mismas 58 de cabeceras: 80 + 58 = 138 B. Con trozos pequeños, el porcentaje de cabeceras se dispara.
- La sobrecarga total. 1518 + 1518 + 138 = 3174 bytes en el cable para 3000 de datos: 174 de cabeceras (3 × 58), el 5,5 % de la trama.
- Tres direcciones, tres lectores. El puerto lo usa el servidor para saber a qué servicio va; la IP, el router; la MAC, el switch. Y la MAC de destino es la del router, no la del servidor.
- Pruébalo tú: cambia
DATOS = 3000porDATOS = 100y fíjate en cuánto pesan ahora las cabeceras (58 de 158 bytes, más de un tercio).
Pruébalo en el simulador El viaje de un paquete: mandas tu práctica al campus y ves cómo cada capa le pone su cabecera, qué abre el switch del aula, qué abre el router y cuántos bytes acaban en el cable. Funciona en el navegador, también en el móvil.
Resumen
| Concepto | Lo que tienes que saber |
|---|---|
| Protocolo | Reglas entre entidades: formato, significado y temporización (sintaxis, semántica, temporización) |
| Arquitectura de protocolos | Varios protocolos en capas: qué hace cada una, cómo interactúan y qué añade |
| Modelo de tres capas | Aplicación, transporte (independiente, puertos) y acceso a la red (depende de la red) |
| PDU | Datos + información de control de una capa: segmento, datagrama, trama, bits |
| TCP/IP | ARPANET y DARPA; 5 capas: aplicación, transporte, Internet (IP), acceso a la red (MAC), física |
| OSI | ISO; 7 capas: física, enlace, red, transporte, sesión, presentación, aplicación; no prosperó como pila real |
| Switch | MAC, misma red; acceso a la red (TCP/IP), enlace de datos, capa 2 (OSI) |
| Router | IP, redes diferentes; Internet (TCP/IP), red, capa 3 (OSI) |
Tres ideas para llevarte:
- Cada capa mete lo de arriba en un sobre nuevo, y cada aparato abre solo los sobres que le tocan.
- El puerto dice a qué servicio va, la IP a qué red y equipo, y la MAC a qué aparato de la LAN en este tramo.
- OSI tiene siete capas y TCP/IP cinco: las cuatro de abajo coinciden y las tres de arriba de OSI caben en la aplicación de TCP/IP.
Ahora toca demostrarlo: en los ejercicios tipo examen de los modelos OSI y TCP/IP tienes un cuestionario interactivo con todos los formatos del examen y las cuatro preguntas de desarrollo con su respuesta modelo. Y en el siguiente tema nos metemos dentro de la capa Internet: IP, direccionamiento, subredes y encaminamiento.
Siguiente paso: ejerciciosModelos OSI y TCP/IP — ejercicios tipo examen con capas, PDU, switch y router (y la «capa de red» que me costó medio punto)¿Te ha servido este artículo? Así puedes apoyar SergioLearns →
El hardware que sostiene al sistema operativo — teoría con la práctica de IC2 en la impresora, una interrupción que lo para todo y una caché que acierta (y el bucle infinito que no colgó mi portátil)