Formarse una imagen clara del modelo OSI — diseccionar una única petición HTTP en sus siete capas

El modelo de referencia OSI aparece siempre al principio de cualquier libro introductorio de redes, y aun así es habitual escuchar: «puedo recitar el nombre de las 7 capas, pero sinceramente no me hago una imagen clara». Aunque uno memorice capa física, capa de enlace de datos, capa de red… es fácil quedarse sin saber cómo se relaciona ese diagrama de 7 niveles con el código C# que está escribiendo o con el fallo de comunicación que tiene delante.

Este artículo está escrito para desarrolladores de aplicaciones Windows y para quienes se inician en redes. Aparecen fragmentos de código C# y comandos de Windows (ping, tracert, arp, etc.), pero no hace falta ningún conocimiento previo de paquetes ni de protocolos. Está estructurado para poder seguirse solo con la lectura, pero si quiere comprobarlo con sus propias manos, con un entorno donde funcionen el SDK de .NET (comando dotnet) y Wireshark podrá reproducir en su propia pantalla exactamente el contenido del artículo.

En este blog ya hemos escrito artículos sobre el comportamiento de L4 (la capa de transporte), como el malentendido de poder recibir en las mismas unidades en que se envió por TCP o las causas y el diagnóstico de los cortes de comunicación de cámaras industriales por retransmisión TCP, pero nos faltaba un artículo que resumiera la idea misma de «capa» que sirve de base a todo eso.

El enfoque de este artículo es simple. Construimos realmente una trama Ethernet que transporta una única petición HTTP GET, y la diseccionamos de fuera hacia adentro. Las 7 capas no son solo un diagrama conceptual: existen físicamente anidadas dentro de los 171 bytes que circulan por la red. En cuanto lo vea con sus propios ojos en un volcado hexadecimal y en Wireshark, el modelo OSI dejará de ser algo que memorizar.

El código que aparece en este artículo está publicado en GitHub como un conjunto de muestras que se puede compilar y ejecutar (una biblioteca para construir y diseccionar tramas, la exportación de un pcap que se puede abrir con Wireshark, y pruebas unitarias).

osi-model-packet-anatomy - komurasoft-blog-samples (GitHub)

1. Primero, la conclusión

• El modelo OSI es «vocabulario», no «implementación». Lo que funciona en la Internet real es la suite de protocolos TCP/IP (efectivamente 4 capas).¹ Los propios protocolos OSI de 7 capas perdieron la carrera de adopción y acabaron sin apenas uso.² Lo que sobrevivió es el modelo como lenguaje común: «aislemos esto en L2», «esto es un problema de L7».
• Las 7 capas están físicamente anidadas como una secuencia de bytes. En una trama que transporta un HTTP GET, los primeros 14 bytes son la cabecera Ethernet (L2), los siguientes 20 bytes son la cabecera IPv4 (L3), los siguientes 20 bytes son la cabecera TCP (L4) y el resto es el texto HTTP (L7). El hecho de que la cabecera de cada capa empiece justo después de la capa anterior se puede comprobar directamente en el volcado hexadecimal y en Wireshark que aparecen en el cuerpo del artículo.
• Lo único que su código C# escribe directamente es la secuencia de bytes de L7. A Socket.Send solo se le pasan los datos de la aplicación; las cabeceras TCP e IP las añade la pila de protocolos del sistema operativo, y la cabecera Ethernet y la señal eléctrica las añade la NIC. Por eso elegir entre HttpClient, SslStream o Socket es en realidad elegir «a partir de qué capa hacia abajo se lo delego al sistema operativo».³
• L5 (capa de sesión) y L6 (capa de presentación) no existen como capas independientes en la pila real. TLS y la codificación de caracteres asumen parte de ese papel, pero en el modelo TCP/IP todo eso se agrupa en la capa de aplicación. Si no logra entender «qué es L6», no es culpa suya: es que ahí es precisamente donde el modelo y la realidad se desalinean.¹
• Donde el modelo OSI resulta verdaderamente útil en la práctica es en la resolución de problemas y en la conversación entre equipos. Acotar el problema con el vocabulario de capas —por ejemplo, «si el ping funciona pero HTTP falla, L3 está vivo, así que sospechamos de L4 o superior»— se convierte en un lenguaje común entre los equipos de red, infraestructura y desarrollo de aplicaciones.

2. Por qué el modelo OSI se queda en pura memorización

Muchas explicaciones empiezan con una tabla como esta.

Esta tabla es correcta, pero todas las filas están escritas con palabras abstractas, así que leerla no forma una imagen mental. Nadie sabría, al leer «transforma la representación de los datos», a qué línea de su propio código se refiere eso.

Hay otro hecho histórico que conviene explicar con franqueza. El modelo de referencia OSI es un estándar definido por ISO (la Organización Internacional de Normalización) y la ITU-T (ISO/IEC 7498-1, ITU-T X.200), y originalmente formaba parte de un proyecto ambicioso que incluía un conjunto de protocolos OSI para cada una de las 7 capas.² Pero en la carrera de adopción de los años 90, TCP/IP —que ya tenía algo funcionando— se convirtió en el estándar de facto, y los propios protocolos OSI acabaron sin apenas uso. La RFC 1122, que sentó las bases de Internet, explica el mundo con 4 capas efectivas: capa de enlace, capa de Internet (IP), capa de transporte y capa de aplicación, sin ninguna capa independiente equivalente a L5 o L6.¹

En otras palabras, el sentido de estudiar hoy el modelo OSI no es «porque así está implementado», sino adquirir la herramienta de «pensar en capas» y un vocabulario común para la resolución de problemas. Partiendo de esta premisa, ya no hace falta preocuparse por no encontrar dónde están «de verdad» L5 y L6, y todo se vuelve mucho más claro de golpe.

3. Al grano: disección de una única petición HTTP

Dejemos aquí la introducción y veamos algo real. El siguiente volcado hexadecimal es una trama Ethernet completa (171 bytes) que transporta una única petición HTTP GET /index.html HTTP/1.1. La construyó el código de muestra presentado al principio, con la suma de comprobación de la cabecera IPv4 y la suma de comprobación TCP calculadas correctamente, así que si se la damos a Wireshark se muestra como un paquete normal.

0000  02 00 00 00 00 01 02 00  00 00 00 02 08 00 45 00  ..............E.
0010  00 9d 12 34 40 00 40 06  3b 99 c0 00 02 0a c6 33  ...4@.@.;......3
0020  64 50 cb 84 00 50 00 00  03 e8 00 00 07 d0 50 18  dP...P........P.
0030  ff ff a3 05 00 00 47 45  54 20 2f 69 6e 64 65 78  ......GET /index
0040  2e 68 74 6d 6c 20 48 54  54 50 2f 31 2e 31 0d 0a  .html HTTP/1.1..
0050  48 6f 73 74 3a 20 65 78  61 6d 70 6c 65 2e 63 6f  Host: example.co
0060  6d 0d 0a 55 73 65 72 2d  41 67 65 6e 74 3a 20 4b  m..User-Agent: K
0070  6f 6d 75 72 61 53 6f 66  74 44 65 6d 6f 2f 31 2e  omuraSoftDemo/1.
0080  30 0d 0a 41 63 63 65 70  74 3a 20 74 65 78 74 2f  0..Accept: text/
0090  68 74 6d 6c 0d 0a 43 6f  6e 6e 65 63 74 69 6f 6e  html..Connection
00a0  3a 20 63 6c 6f 73 65 0d  0a 0d 0a                 : close....

Si mira la representación ASCII de la derecha, verá que a partir de cierto punto (offset 0x36) empieza un texto legible para humanos: GET /index.html HTTP/1.1. Entonces, ¿qué son los 54 bytes anteriores? Si se los pasamos al disector de la muestra, este es el informe que produce:

[ L2 Ethernet II | offset   0 |  14 bytes | dst=02:00:00:00:00:01 src=02:00:00:00:00:02 type=0x0800 (IPv4)
  [ L3 IPv4        | offset  14 |  20 bytes | 192.0.2.10 -> 198.51.100.80 TTL=64 proto=6 (TCP) checksum=OK
    [ L4 TCP         | offset  34 |  20 bytes | 52100 -> 80 [Psh, Ack] seq=1000 win=65535
      [ L7 HTTP        | offset  54 | 117 bytes | GET /index.html HTTP/1.1

Este es el diagrama que más quiero que vea en este artículo. Hay tres puntos clave.

1. Cada capa empieza «justo después de la capa anterior». La cabecera Ethernet ocupa los bytes 0-13, la cabecera IPv4 los bytes 14-33, la cabecera TCP los bytes 34-53, y HTTP empieza en el byte 54. Las capas no son una clasificación conceptual: se pueden señalar como rangos de bytes desde el principio de la trama.
2. La capa interior es la «carga (payload)» de la capa exterior. Desde el punto de vista de Ethernet, todo lo que sigue a IPv4 es simple carga, y le da igual si el contenido es TCP o no. Desde IP, todo lo que sigue a TCP es carga; desde TCP, HTTP es carga. Cada capa solo lee su propia cabecera y pasa la carga hacia arriba sin tocarla. Esta estructura de «no le importa» es precisamente la encapsulación.
3. L1 (capa física) y L5-L6 no aparecen en este diagrama. L1 es el trabajo de convertir esta secuencia de bytes en señal eléctrica, luz o radio, así que no aparece en el volcado; y L5-L6, como vimos en el capítulo anterior, no tienen una entidad independiente en un HTTP/1.1 en texto claro. «De las 7 capas, solo 4 aparecen en el volcado» — esta es la realidad.

Repitámoslo: esto no tiene nada de especial en HTTP. Ya sea una conexión a base de datos, gRPC, o GigE Vision de una cámara industrial, si es comunicación TCP/IP sobre Ethernet, todos los paquetes tienen esta misma estructura anidada. Lo único que cambia es el contenido de la carga en L7.

4. L2, la capa de enlace de datos — llegar hasta el «vecino»

Vamos a examinar el resultado de la disección de fuera hacia adentro. Los primeros 14 bytes son la cabecera Ethernet II.

02 00 00 00 00 01   Dirección MAC de destino (6 bytes)
02 00 00 00 00 02   Dirección MAC de origen (6 bytes)
08 00               EtherType = 0x0800 (la carga es IPv4)

El trabajo de L2 es «llegar hasta el nodo vecino dentro del mismo segmento de red». Para especificar el destino se usa la dirección MAC. La dirección MAC es un identificador asignado a la NIC y, en principio, nunca llega al destino cruzando un router. La trama que un PC de oficina envía a un servidor web tiene como MAC de destino no el servidor web, sino la MAC de la puerta de enlace predeterminada (el router).

Aquí es donde a muchas personas les surge la duda: «si ya hay una dirección IP, ¿por qué hace falta también una dirección MAC?». La respuesta está en el reparto de roles entre capas. La dirección IP es la dirección que apunta al «destino final»; la dirección MAC es la etiqueta que indica «quién transporta el siguiente tramo». Si lo comparamos con un envío de paquetería, la dirección IP es la dirección de entrega del albarán, y la MAC es el nombre del «siguiente centro de distribución». El albarán (L3) no cambia hasta el final, pero la etiqueta (L2) se sustituye en cada tramo. ARP es lo que permite averiguar la dirección MAC de un nodo vecino a partir de una dirección IP, y con el comando arp -a se puede consultar la tabla de correspondencias que recuerda el PC.

En términos de equipos, el dispositivo que reenvía basándose en L2 es el switch (concentrador conmutado). El switch elige el puerto de salida mirando únicamente la dirección MAC de destino, sin mirar la dirección IP de la carga.

5. L3, la capa de red — llegar hasta el otro extremo del mundo

Los siguientes 20 bytes son la cabecera IPv4. Extraigamos los campos principales.

45          Versión=4, longitud de cabecera=5 palabras (20 bytes)
00 9d       Longitud total 157 bytes (cabecera IP + TCP + HTTP; no incluye los 14 bytes de Ethernet)
40 06       TTL=64, protocolo=6 (la carga es TCP)
3b 99       Suma de comprobación de la cabecera
c0 00 02 0a IP de origen   192.0.2.10
c6 33 64 50 IP de destino  198.51.100.80

El trabajo de L3 es «llegar hasta el host de destino final, sin importar cuántos routers haya que cruzar». Mientras que L2 solo transporta un tramo (un salto), la dirección IP de destino de L3 no cambia del principio al fin de la comunicación. El router mira la IP de destino del paquete que recibe, decide «a qué router se lo paso a continuación» y lo envía después de sustituir la cabecera L2.

Si representamos en un diagrama este movimiento en el que «solo se sustituye L2», queda así. Lo único que cambia en cada tramo son las direcciones MAC de origen y destino (L2); la dirección IP de destino (L3) permanece con el mismo valor en los tres tramos.

flowchart LR
    accTitle: Cómo el destino MAC cambia en cada segmento mientras la IP de destino permanece igual
    accDescr: Diagrama que muestra un PC de origen enviando tramas a través de dos routers hasta un servidor web, donde la MAC de destino se sustituye en cada segmento (router 1, router 2, servidor web) mientras la IP de destino 198.51.100.80 permanece igual en los tres segmentos
    PC["PC de origen<br/>192.0.2.10"]
    R1["Router 1"]
    R2["Router 2"]
    SV["Servidor web<br/>198.51.100.80"]
    PC -->|"MAC destino: Router 1<br/>IP destino: 198.51.100.80"| R1
    R1 -->|"MAC destino: Router 2<br/>IP destino: 198.51.100.80"| R2
    R2 -->|"MAC destino: Servidor web<br/>IP destino: 198.51.100.80"| SV

Figura 1: La etiqueta L2 se sustituye en cada segmento, mientras que la IP de destino L3 no cambia hasta el final. El TTL disminuye en 1 cada vez que se cruza un router.

El TTL (Time To Live) es el campo que hace visible este movimiento de «cruzar un router». Disminuye en 1 cada vez que se cruza un router, y el paquete que llega a 0 se descarta y se devuelve un error al origen. tracert (el comando de investigación de rutas de Windows) va enviando paquetes aumentando deliberadamente el TTL a 1, 2, 3… para ir revelando uno a uno los routers intermedios. Es decir, cada línea que aparece en la salida de tracert es, físicamente, un «salto de L3».

6. L4, la capa de transporte — a qué proceso entregarlo

Los siguientes 20 bytes son la cabecera TCP.

cb 84       Puerto de origen 52100
00 50       Puerto de destino 80
00 00 03 e8 Número de secuencia
00 00 07 d0 Número de confirmación (ACK)
50 18       Longitud de cabecera=5 palabras, flags [PSH, ACK]
ff ff       Tamaño de ventana
a3 05       Suma de comprobación

Hasta L3, el paquete ha llegado al «host (la máquina)» de destino. Pero en esa máquina, el servidor web, la base de datos y muchos otros procesos se comunican al mismo tiempo. Uno de los trabajos de L4 es usar el número de puerto para repartir «a qué proceso (o mejor dicho, a qué socket) se entrega». El puerto de destino 80 es la convención de «el número en el que escucha un servidor HTTP»; el sistema operativo mira este número y coloca los datos en el búfer de recepción del proceso correspondiente.

Otro gran trabajo de TCP es ofrecer un «flujo de bytes fiable» mediante números de secuencia, confirmaciones, retransmisión y control de flujo.⁴ Este comportamiento y cómo tratarlo tiene la profundidad suficiente como para dar cada uno un artículo propio, así que lo dejamos para el artículo sobre los límites de mensaje en TCP y el artículo sobre la retransmisión TCP. Aquí, quédese con la sensación de que «a partir de L4 hacia arriba, ya no tiene forma de red: parece una tubería que conecta un proceso con otro».

Hay un dato curioso que muestra el desfase entre el ideal del modelo y la realidad. La suma de comprobación de TCP no se define calculándose solo sobre el segmento TCP, sino anteponiendo una «pseudocabecera» que reúne información de L3 (las direcciones IP de origen y destino).⁴ Si las capas estuvieran limpiamente separadas, la dirección de L3 no debería mezclarse en el cálculo de L4. Es un buen ejemplo de que el modelo OSI es, al fin y al cabo, un mapa para organizar ideas, y de que los protocolos reales cruzan capas cuando les resulta necesario.

7. L5 y L6 — donde el modelo y la realidad se desalinean

Como habrá notado, en el diagrama de disección no aparecían L5 (capa de sesión) ni L6 (capa de presentación). Esta es la principal razón por la que mucha gente siente que «no entiende OSI», así que lo diremos con claridad.

L5 y L6 no existen como capas independientes en la pila TCP/IP real. En el modelo de Internet de la RFC 1122, todo lo que está por encima de TCP es «capa de aplicación».¹ Los roles que preveía el modelo OSI se han dispersado y absorbido en la realidad de la siguiente manera.

En el caso de HTTPS, por ejemplo, TLS se intercala por encima de TCP (L4) y HTTP fluye dentro de él. «¿En qué capa está TLS?» es la típica pregunta de examen, pero decidir una única respuesta correcta no tiene ningún valor práctico. Es más importante poder explicar que se sitúa por encima de L4 y por debajo de L7, combinando la gestión de sesión (un rol equivalente a L5) y el cifrado (un rol equivalente a L6), que poder responder al instante «es L6».

En código .NET, esta relación se refleja directamente en cómo se apilan las clases. Si el flujo de L4 obtenido con TcpClient.GetStream() se envuelve con SslStream, el texto en claro que se escribe con Write se cifra en un registro TLS antes de pasar a TCP.⁵

using var client = new TcpClient("example.com", 443);
// Envolvemos el flujo de bytes de L4 con TLS (equivalente a L5/L6)
using var ssl = new SslStream(client.GetStream());
await ssl.AuthenticateAsClientAsync("example.com");
// Aquí se escribe el texto en claro de L7 (HTTP). El cifrado es tarea de SslStream
await ssl.WriteAsync(Encoding.ASCII.GetBytes("GET / HTTP/1.1\r\n..."));

Esta estructura de envolver un flujo con otro flujo es la versión en código de la encapsulación. Si observa en Wireshark el tráfico del puerto 443, la carga TCP se ve solo como un bloque opaco llamado Application Data, lo cual confirma, mirándolo desde el otro lado, que «L7 quedó envuelto en un paquete equivalente a L6».

8. Qué capa toca realmente su código C#

Relacionemos todo lo anterior con las herramientas de un desarrollador de aplicaciones Windows.

De esta tabla se pueden extraer dos conclusiones.

Primero, elegir una API es elegir «a partir de qué capa hacia abajo se delega el trabajo». Si usa HttpClient, se delega incluso la construcción de L7; si usa Socket, tendrá que escribir usted mismo todo L7. Por el contrario, una aplicación Windows normal casi nunca opera directamente por debajo de L3 (los raw sockets requieren privilegios de administrador y fuertes restricciones).

Segundo, lo único que se pasa a Socket.Send es la secuencia de bytes de L7. La Parte 2 de la muestra es una demostración que envía una petición HTTP real por loopback, pero la aplicación solo prepara los 60 bytes de texto HTTP; los 54 bytes de cabeceras que vimos en el capítulo 3 los añaden el SO y la NIC. El código de red de su aplicación, en realidad, solo se encarga de construir la carga más interna de las 7 capas — esta es la posición exacta de su código dentro del modelo OSI.

using var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
await socket.ConnectAsync(IPAddress.Loopback, port);

byte[] request = Encoding.ASCII.GetBytes(
    $"GET / HTTP/1.1\r\nHost: localhost:{port}\r\nConnection: close\r\n\r\n");

// Solo se pasa el flujo de bytes de L7. Las cabeceras TCP/IP/Ethernet
// se añaden al otro lado de esta llamada (el SO y la NIC)
int sent = await socket.SendAsync(request);

9. Manos a la obra — construir la trama y abrirla en Wireshark

Para pasar de «lo entendí leyendo» a «lo vi con mis propios ojos», veamos cómo ejecutar el código de muestra.

El núcleo de la muestra es SampleFrameBuilder, que construye la trama del capítulo 3 en el mismo orden en que se envuelve, de L7 hacia L2. Lo que ocurre en cada capa en el momento del envío se refleja directamente en el orden de los métodos.

public static byte[] BuildHttpGetFrame()
{
    // L7: lo único que la aplicación pasa a Send es este flujo de bytes
    byte[] http = Encoding.ASCII.GetBytes(HttpRequest);

    // L4: la pila de protocolos del SO antepone la cabecera TCP
    byte[] tcp = WrapInTcp(http);

    // L3: se antepone además la cabecera IPv4
    byte[] ip = WrapInIpv4(tcp);

    // L2: justo antes del controlador de la NIC se antepone la cabecera Ethernet
    return WrapInEthernet(ip);
}

Al ejecutar la demo, además de mostrar el volcado hexadecimal y la vista anidada, esta trama se exporta como un archivo pcap.

dotnet run --project samples/Demo

Abra el archivo sample-http-get.pcap generado con Wireshark.⁶ En el panel central (el panel de detalle del paquete) aparecen cuatro filas en vertical: Ethernet II, Internet Protocol Version 4, Transmission Control Protocol y Hypertext Transfer Protocol; al hacer clic en cualquiera de ellas, en el panel inferior (el panel de bytes) se resalta únicamente el rango de bytes correspondiente. Si representamos esta correspondencia en un diagrama, queda así: es exactamente la misma vista anidada del capítulo 3, mostrada ahora por una herramienta estándar del sector.

flowchart LR
    accTitle: Correspondencia entre el panel de detalle del paquete y el panel de bytes en Wireshark
    accDescr: Diagrama que muestra cómo, al hacer clic en cada una de las cuatro filas del panel de detalle del paquete (Ethernet II, Internet Protocol Version 4, Transmission Control Protocol, Hypertext Transfer Protocol), se resalta el rango de bytes correspondiente en el panel de bytes
    subgraph DETAIL["Panel de detalle del paquete ── 4 filas de arriba a abajo"]
        E["Ethernet II"]
        I["Internet Protocol Version 4"]
        T["Transmission Control Protocol"]
        H["Hypertext Transfer Protocol"]
    end
    subgraph BYTES["Panel de bytes ── rango que se resalta"]
        BE["bytes 0-13"]
        BI["bytes 14-33"]
        BT["bytes 34-53"]
        BH["bytes 54-170"]
    end
    E -->|"clic"| BE
    I -->|"clic"| BI
    T -->|"clic"| BT
    H -->|"clic"| BH

Figura 2: Correspondencia entre las filas del panel de detalle y el panel de bytes. Al seleccionar una fila, solo se resalta abajo el rango de bytes que ocupa la cabecera de esa capa.

Una vez comprobado esto, el siguiente paso es tráfico real. Inicie una captura en Wireshark, ponga un filtro como tcp.port == 443 y abra cualquier sitio web en el navegador: podrá confirmar que toda la comunicación real tiene esta misma estructura anidada.

Además, la implementación del disector (PacketDissector) también incluye una lección práctica interesante. Por ejemplo, al extraer la carga IPv4 no hay que tomar todo el resto del búfer de recepción, sino que hay que confiar en el campo TotalLength de la cabecera para recortarla. Esto se debe a que Ethernet tiene una longitud mínima de trama (60 bytes), y a los paquetes cortos se les añade al final un relleno (padding) sin significado. «Eliminar una conveniencia de la capa exterior (el padding) usando la información de longitud de la capa interior» es otro ejemplo de cómo el reparto de roles entre capas se refleja en la implementación, y está verificado con pruebas unitarias.

10. Usar el modelo OSI en la práctica — diagnosticar con el vocabulario de capas

Al principio dijimos que «OSI sobrevivió como vocabulario». Veamos dos situaciones en las que ese vocabulario resulta realmente útil.

Diagnóstico de fallos. Un aviso del tipo «no puedo conectar con el servidor», traducido al vocabulario de capas, se puede acotar sistemáticamente. Lo habitual es comprobar de abajo hacia arriba.

Por ejemplo, si «el ping funciona pero Test-NetConnection falla», L3 está sano y la sospecha se centra en algo que bloquea el puerto en L4 (un servicio detenido, un cortafuegos, un error de configuración del número de puerto). Si «la conexión TCP se establece pero HTTP devuelve un 400», el problema no es de red, sino de L7 (el contenido de la petición). En lugar de desenchufar cables a ciegas, ir confirmando capa por capa hasta dónde sigue vivo — así es como se usa el modelo OSI en la práctica.

Lenguaje común para la conversación. Frases como «parece un problema de L2, revisa el puerto del switch» o «eso es cosa de L7, pásaselo al equipo de aplicación» se entienden con precisión entre los responsables de red, de infraestructura y los desarrolladores de aplicaciones. El número de capa es un sistema de coordenadas común en el sector para expresar brevemente un punto de responsabilidad.

11. Corrigiendo malentendidos habituales

Por último, vamos a corregir de una vez los malentendidos habituales en torno al modelo OSI.

• «Internet funciona con las 7 capas de OSI» ── No es así. Lo que está implementado es TCP/IP (efectivamente 4 capas); OSI es un modelo de referencia para explicar y conversar.¹
• «Las 4 capas de TCP/IP se corresponden perfectamente con las 7 de OSI» ── La correspondencia de L5 a L7 es intrínsecamente ambigua. Es habitual ver la tabla «capa de aplicación de TCP/IP = L5+L6+L7 de OSI», pero, como vimos en el capítulo 7, los roles de L5 y L6 están en realidad dispersos entre TLS y los formatos de serialización.
• «TLS es un protocolo de la capa 6 (o de la capa 5)» ── No tiene sentido fijarlo en una única capa. La descripción exacta es que se sitúa por encima de L4 y por debajo de L7, combinando roles equivalentes a L5 y L6.
• «Con el número de puerto se sabe el protocolo» ── Que sea el puerto 80 no significa necesariamente que sea HTTP. El número de puerto es una convención, y no se sabe qué circula realmente hasta que se mira la carga. Por eso el disector de la muestra determina si algo es HTTP mirando la cadena inicial del contenido, no el número de puerto.
• «El switch es un dispositivo de L2, el router es de L3» ── Es correcto como punto de partida, pero en la realidad existen normalmente equipos que abarcan varias capas, como los switches de L3, los balanceadores de carga que reparten en L4 o los WAF que inspeccionan L7. Lo preciso es entenderlo como «hasta qué capa lee este dispositivo».

12. Resumen

• El modelo OSI no es una implementación, sino un vocabulario para pensar en capas. Lo que funciona en la realidad es TCP/IP (efectivamente 4 capas)
• Las 7 capas no son un diagrama conceptual: están físicamente anidadas dentro de la secuencia de bytes de una sola trama (L2: 0-13, L3: 14-33, L4: 34-53, L7: 54 en adelante)
• Cada capa solo lee su propia cabecera y no se ocupa de la carga (la capa interior) ── esto es la encapsulación
• L5 y L6 no existen de forma independiente en la pila real; TLS y la codificación absorben sus roles
• Su código C# solo escribe la secuencia de bytes de L7. Las cabeceras TCP/IP las añade el SO, y Ethernet la NIC
• Su utilidad práctica está en el diagnóstico de fallos, confirmando capa por capa desde abajo qué sigue vivo, y en el lenguaje común entre equipos
• Si construye la trama con el código de muestra y la abre en Wireshark, podrá comprobar con sus propios ojos todo el contenido de este artículo

Artículos relacionados

• El malentendido de poder recibir en las mismas unidades que se enviaron por TCP — diseño de recepción para tratarlo como flujo de bytes
• Causas y diagnóstico de cortes de comunicación con cámaras industriales por retransmisión TCP
• Tabla práctica de decisión C# async/await - Task.Run y ConfigureAwait

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa del diseño e implementación de aplicaciones Windows que realizan comunicación TCP/IP, de la investigación de las causas de fallos de comunicación con equipos industriales —del tipo «a veces se corta» o «se ralentiza»—, y del apoyo en la resolución de problemas mediante captura de paquetes.

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causas
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Se usan realmente las 7 capas del modelo OSI en la Internet actual?

No se usan. Lo que funciona en la Internet real es la suite de protocolos TCP/IP (efectivamente 4 capas); los propios protocolos OSI de 7 capas perdieron la carrera de adopción de los años 90 y acabaron sin apenas uso. La RFC 1122, que sienta las bases de Internet, explica el mundo con 4 capas: capa de enlace, capa IP, capa de transporte y capa de aplicación. Lo que sobrevivió es el modelo como vocabulario compartido para la resolución de problemas y la conversación, como en «aislemos esto en L2» o «esto es un problema de L7».

¿Dónde existen realmente la capa de sesión (L5) y la capa de presentación (L6)?

No existen como capas independientes en la pila TCP/IP real. Los roles que preveía el modelo OSI están dispersos y absorbidos en otros lugares: L5 (establecer y gestionar el diálogo) corresponde al handshake de TLS o a las cookies/tokens de HTTP, y L6 (transformar y cifrar la representación de los datos) corresponde al cifrado de TLS, la codificación de caracteres y formatos de serialización como JSON. Determinar a qué única capa pertenece TLS no tiene ningún valor práctico; lo importante es poder explicar que se sitúa por encima de L4 y por debajo de L7, combinando roles equivalentes a L5 y L6.

¿Por qué se necesita una dirección MAC si ya existe una dirección IP?

Porque el reparto de responsabilidades entre capas es distinto. La dirección IP (L3) es la dirección que apunta al destino final y no cambia del principio al fin de la comunicación. La dirección MAC (L2) es la etiqueta que indica «quién transporta el siguiente tramo» y se sustituye cada vez que se cruza un router. La trama que envía un PC de oficina a un servidor web tiene como MAC de destino no el servidor web, sino la puerta de enlace predeterminada (el router). ARP es lo que permite averiguar la dirección MAC de un nodo vecino a partir de una dirección IP, y la tabla de correspondencia se puede consultar con el comando arp -a.

¿Para qué sirve realmente el modelo OSI en la práctica?

Para la resolución de problemas y la conversación entre equipos. Un aviso del tipo «no puedo conectar con el servidor» se puede acotar sistemáticamente comprobando, capa por capa de abajo hacia arriba, qué sigue funcionando: inspección visual del indicador de enlace (L1-L2), ping a la puerta de enlace (L3), confirmación de la conexión TCP al puerto de destino (L4) y envío de una petición HTTP (L7). Por ejemplo, si el ping funciona pero la conexión TCP falla, la sospecha se centra en algo que bloquea el puerto en L4 (un servicio detenido, un cortafuegos). También funciona como un sistema de coordenadas compartido en el sector para señalar de forma breve un punto de responsabilidad, como en «esto parece un problema de L2, revisa el switch».

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.