Entender de verdad el modelo OSI — diseccionar una única petición HTTP en sus siete capas

El modelo de referencia OSI es lo primero que aparece en cualquier libro introductorio de redes, y aun así es habitual escuchar: «puedo recitar el nombre de las siete capas, pero, sinceramente, no me hago una idea real de qué son». Aunque uno memorice capa física, capa de enlace de datos, capa de red… y así sucesivamente, es fácil quedarse sin saber cómo se relaciona ese diagrama de siete niveles con el código C# que uno mismo escribe o con el fallo de comunicación que está ocurriendo delante de sus ojos.

En este blog ya hemos tratado antes el comportamiento de L4 (la capa de transporte) en artículos como el error de pensar que se puede hacer Receive por cada unidad que se envía con Send en TCP o las causas y el diagnóstico de los cortes de comunicación de una cámara industrial por retransmisiones TCP, pero nunca habíamos escrito un artículo que recogiera la idea de fondo que sostiene todo eso: el propio concepto de «capa».

El enfoque de este artículo es sencillo. Vamos a construir de verdad una trama Ethernet que transporta una única petición HTTP GET y a diseccionarla de fuera hacia dentro. Las siete capas no son solo algo que existe en un diagrama conceptual: están físicamente anidadas dentro de los 171 bytes que circulan por la red. En cuanto lo veas con tus propios ojos, mediante un volcado hexadecimal y Wireshark, el modelo de referencia OSI dejará de ser algo que hay que memorizar.

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

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

1. Antes que nada, la conclusión

• El modelo de referencia OSI es un «vocabulario», no una «implementación». Lo que realmente funciona en Internet es la suite de protocolos TCP/IP (efectivamente cuatro capas); los propios protocolos OSI de 7 capas perdieron la carrera de adopción y nunca llegaron a usarse. Lo que sobrevivió es el modelo como lenguaje común: expresiones como «vamos a acotarlo en L2» o «esto es un problema de L7».¹²
• Las siete 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). Puedes comprobar directamente, en el volcado hexadecimal de este artículo y en Wireshark, cómo la cabecera de cada capa empieza justo después de la anterior.
• Lo único que tu código C# escribe directamente es la secuencia de bytes de L7. Lo que se pasa a Socket.Send son únicamente 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 y Socket es, en realidad, elegir «a partir de qué capa hacia abajo se lo delegas al sistema operativo».³
• L5 (la capa de sesión) y L6 (la 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 queda englobado en la capa de aplicación. Si «no entiendo qué es L6» te describe a ti, no es culpa tuya: es exactamente el punto donde el modelo y la realidad se separan.²
• Donde el modelo OSI realmente demuestra su valor en la práctica es en la resolución de problemas y en la conversación entre equipos. Acotar con el vocabulario de capas —«el ping funciona pero HTTP falla, así que L3 está vivo y hay que sospechar de L4 en adelante»— se convierte en un lenguaje común entre ingenieros de red, personal de infraestructura y desarrolladores de aplicaciones.

2. Por qué el modelo OSI termina siendo solo memorización

La mayoría de las explicaciones empiezan con una tabla como esta.

Esta tabla es correcta, pero todas las filas están escritas con un lenguaje tan abstracto que, por más que la leas, nunca llega a formarse una imagen mental. Si te dicen «transforma el formato de representación de los datos», nadie sabrá señalar a qué línea de su propio código se supone que se refiere eso.

Hay otro hecho histórico que conviene decir con claridad. El modelo de referencia OSI es un estándar definido por la ISO (Organización Internacional de Normalización) y la ITU-T (ISO/IEC 7498-1, ITU-T X.200), y en origen estaba pensado para ir acompañado de un ambicioso conjunto de protocolos OSI, uno por cada una de las siete capas.¹ Pero en la carrera de adopción de los años 90, TCP/IP —que ya tenía implementaciones funcionando— se convirtió en el estándar de facto, y los propios protocolos OSI acabaron apenas utilizándose. La RFC 1122, que sentó las bases de Internet, explica el mundo con efectivamente cuatro capas —la capa de enlace, la capa de Internet (IP), la capa de transporte y la capa de aplicación—, sin ninguna capa independiente equivalente a L5 o L6.²

En otras palabras, el motivo por el que hoy estudiamos el modelo de referencia OSI no es «porque así es como está implementado», sino para adquirir la herramienta de pensar por capas y el vocabulario compartido para la resolución de problemas. Partiendo de esta premisa, ya no hace falta preocuparse por «no encontrar dónde están realmente L5 y L6», y todo se aclara de golpe.

3. El tema principal: diseccionar una única petición HTTP

Basta de preámbulos: vamos a ver la cosa real. El siguiente volcado hexadecimal es una trama Ethernet (171 bytes en total) que transporta una única petición HTTP, GET /index.html HTTP/1.1. La ensambló el código de muestra presentado al principio del artículo, y como tanto la suma de comprobación de la cabecera IPv4 como la de TCP están calculadas correctamente, Wireshark la muestra como un paquete perfectamente normal al cargarla.

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 te fijas en la columna ASCII de la derecha, verás 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, esto es lo que informa.

[ 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 veas en todo el artículo. Hay tres puntos clave.

1. Cada capa empieza justo «donde termina la 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. Una capa no es una categoría conceptual: se puede señalar como un rango de bytes desde el principio de la trama.
2. Una capa interior no es más que la «carga útil» (el cargamento) de la capa exterior. Desde el punto de vista de Ethernet, todo lo que viene después —IPv4 en adelante— es simple cargamento; no le importa si el contenido resulta ser TCP o no. Desde el punto de vista de IP, todo lo que viene después de TCP es cargamento; desde el punto de vista de TCP, HTTP es cargamento. Cada capa lee únicamente su propia cabecera y pasa la carga hacia arriba sin tocarla. Esta estructura de «no importarle» es exactamente lo que es la encapsulación.
3. L1 (la capa física) y L5/L6 no aparecen en ningún lugar de este diagrama. El trabajo de L1 es convertir esta secuencia de bytes en una señal eléctrica, luz o ondas de radio, así que nunca aparece en un volcado; y, como vimos en el capítulo anterior, L5 y L6 no tienen una entidad independiente en HTTP/1.1 en texto plano. «De las siete capas, solo cuatro aparecen en el volcado»: esa es la realidad.

Insisto: no hay nada especial en HTTP aquí. Ya sea una conexión a una base de datos, gRPC o GigE Vision para una cámara industrial, todos los paquetes tienen exactamente esta misma estructura anidada mientras se trate de TCP/IP sobre Ethernet. Lo único que cambia es el contenido del cargamento de L7.

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

Vamos a repasar el resultado de la disección de fuera hacia dentro. 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 entregar hasta el nodo vecino dentro del mismo segmento de red. Para especificar el destino se usa una dirección MAC. Una dirección MAC es un identificador asignado a la NIC y, en principio, nunca llega hasta el otro extremo cruzando un router. Una trama enviada desde un PC de oficina 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 mucha gente, al menos una vez, le surge la duda: «si ya hay una dirección IP, ¿para qué hace falta también una dirección MAC?». La respuesta está en cómo las capas reparten la responsabilidad. La dirección IP es la dirección que apunta al «destino final», mientras que 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 sería la dirección de entrega de la etiqueta de envío, y la dirección MAC sería el nombre del «siguiente centro de distribución». La etiqueta de envío (L3) no cambia hasta el final, pero la etiqueta de destino (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 se puede consultar la tabla que recuerda el PC con el comando arp -a.

En cuanto a los dispositivos, el 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; no mira la dirección IP que viaja como cargamento.

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

Los siguientes 20 bytes son la cabecera IPv4. Extraemos 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 entregar hasta el host de destino final, sin importar cuántos routers haya que cruzar por el camino. Mientras que L2 solo transporta un tramo (un salto) cada vez, la dirección IP de destino de L3 no cambia desde el principio hasta el final de la comunicación. El router mira la IP de destino del paquete recibido, decide «a qué router le paso esto a continuación» y lo reenvía tras reescribir la cabecera de L2.

El TTL (Time To Live) es el campo que hace visible este movimiento de «cruzar routers». Se decrementa en uno cada vez que cruza un router, y cuando llega a cero, el paquete se descarta y se devuelve un error al remitente. tracert (el comando de trazado de rutas de Windows) funciona enviando paquetes con el TTL fijado deliberadamente en 1, 2, 3… de forma creciente, para ir sacando a la luz, uno a uno, los routers del camino. Es decir, cada línea que aparece en la salida de tracert es la manifestación real de «un salto de L3».

6. L4, la capa de transporte — decidir a qué proceso le llega

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 a la «máquina» (el host) de destino. Pero en esa máquina, el servidor web, la base de datos y muchos otros procesos podrían estar comunicándose al mismo tiempo. Uno de los trabajos de L4 es usar el número de puerto para decidir a qué proceso (a qué socket) se le entrega. El puerto de destino 80 es, por convención, «el número en el que escucha un servidor HTTP»; el sistema operativo mira ese número y apila los datos en el búfer de recepción del proceso correspondiente.

El otro gran trabajo de TCP es proporcionar un «flujo de bytes fiable» mediante números de secuencia, confirmaciones, retransmisión y control de flujo.⁴ Ese comportamiento, y cómo tratar con él, tienen la profundidad suficiente como para ser cada uno un artículo aparte, así que te remito a el artículo sobre los límites de mensaje en TCP y a el artículo sobre la retransmisión en TCP. Lo que quiero que te lleves aquí es esta sensación: «por encima de L4, la cosa ya no tiene forma de red; empieza a parecerse a una tubería que conecta un proceso con otro».

Hay un dato curioso que muestra la brecha 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: se define calculándose anteponiendo una «pseudocabecera» que enumera información de L3 (las direcciones IP de origen y destino).⁴ Si las capas fueran realmente independientes, no debería haber forma de que las direcciones de L3 se mezclaran en el cálculo de L4. Es un buen ejemplo de que el modelo de referencia OSI es solo un mapa para organizar las ideas, mientras que los protocolos reales cruzan los límites entre capas cuando les conviene.

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

Ahora bien, fíjate en que el diagrama de disección no tenía L5 (la capa de sesión) ni L6 (la capa de presentación). Este es el motivo número uno por el que la gente siente que «no entiende OSI», así que vamos a decirlo 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 hay por encima de TCP es simplemente «capa de aplicación».² Los roles que preveía el modelo OSI están, en la realidad, dispersos y absorbidos de la siguiente manera.

Por ejemplo, en el caso de HTTPS, TLS se intercala encima de TCP (L4), y HTTP fluye dentro de él. «¿En qué capa está TLS?» es el tipo de pregunta que tienta a convertirla en pregunta de examen, pero no tiene ningún valor práctico fijar una única respuesta correcta. Poder explicar que se sitúa por encima de L4, por debajo de L7, y que combina la gestión de sesión (un rol propio de L5) con el cifrado (un rol propio de L6), importa más que poder responder al instante «es L6».

En el código .NET, esta relación se manifiesta directamente en cómo se envuelven las clases unas a otras. Si envuelves el stream de L4 que obtienes con TcpClient.GetStream() con SslStream, el texto plano que escribas con Write se cifra en registros TLS antes de pasar a TCP.⁵

using var client = new TcpClient("example.com", 443);
// Envuelve el stream de bytes de L4 con TLS (equivalente a L5/L6)
using var ssl = new SslStream(client.GetStream());
await ssl.AuthenticateAsClientAsync("example.com");
// Lo que se escribe aquí es texto plano de L7 (HTTP). El cifrado es trabajo de SslStream
await ssl.WriteAsync(Encoding.ASCII.GetBytes("GET / HTTP/1.1\r\n..."));

Esta estructura de envolver un stream con otro stream es la versión en código de la encapsulación. Si observas en Wireshark el tráfico del puerto 443, verás que la carga útil de TCP solo aparece como un bloque opaco etiquetado Application Data, lo que te permite confirmar, en sentido inverso, que «L7 ha quedado envuelto en algo equivalente a L6».

8. ¿Qué capa está tocando realmente tu código C#?

Vamos a mapear todo lo anterior sobre las herramientas que realmente usa 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». Si usas HttpClient, puedes delegar incluso el ensamblado de L7; si usas Socket, acabas escribiendo tú mismo todo L7. A la inversa, una aplicación Windows normal casi nunca manipula L3 o capas inferiores directamente (los raw sockets exigen privilegios de administrador y vienen con fuertes restricciones).

Segundo, lo único que se le pasa a Socket.Send es la secuencia de bytes de L7, y nada más. La Parte 2 de la muestra es una demo que envía de verdad una petición HTTP por loopback, pero lo único que prepara la aplicación son los 60 bytes de texto HTTP; los 54 bytes de cabeceras que vimos en el capítulo 3 los añaden el sistema operativo y la NIC. El código de red de tu aplicación, en realidad, solo hace el trabajo de construir el cargamento más interior de las siete capas: esta es la relación exacta entre el modelo OSI y tu código.

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");

// Lo único que se pasa es la secuencia 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 — ensamblar una trama y abrirla en Wireshark

Para convertir el «lo he leído y lo he entendido» en un «lo he visto y lo he entendido», vamos a repasar cómo ejecutar el código de muestra.

El núcleo de la muestra es SampleFrameBuilder, que ensambla la trama del capítulo 3 exactamente en el orden en que se va envolviendo desde L7 hasta L2. Lo que ocurre en cada capa al enviar se corresponde directamente con el orden en que aparecen los métodos.

public static byte[] BuildHttpGetFrame()
{
    // L7: lo único que la aplicación pasa a Send es esta secuencia 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 driver 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, se exporta esta trama como un archivo pcap.

dotnet run --project samples/Demo

Prueba a abrir el sample-http-get.pcap generado con Wireshark.⁶ En el panel central verás cuatro líneas apiladas —Ethernet II / Internet Protocol Version 4 / Transmission Control Protocol / Hypertext Transfer Protocol— y al hacer clic en cualquiera de ellas se resalta únicamente el rango de bytes correspondiente en el volcado hexadecimal de abajo. Una herramienta estándar de la industria te está mostrando exactamente lo mismo que la vista anidada del capítulo 3. Una vez confirmado esto, el siguiente paso es tráfico real. Inicia una captura en Wireshark, pon un filtro como tcp.port == 443, abre algún sitio web en el navegador, y podrás comprobar que toda la comunicación real está construida con este mismo anidamiento.

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

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

Al principio dije que «OSI sobrevivió como vocabulario». Veamos dos situaciones en las que ese vocabulario realmente demuestra su valor.

Resolución de problemas. Un aviso del tipo «no puedo conectar con el servidor» se puede acotar sistemáticamente si lo traduces al vocabulario de capas. El método estándar es comprobar de abajo hacia arriba.

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

Un lenguaje común para la conversación. Frases como «parece un problema de L2, ¿puedes revisar el puerto del switch?» o «eso es cosa de L7, así que le corresponde al equipo de la aplicación» se entienden con precisión entre el personal de red, el de infraestructura y los desarrolladores de aplicaciones. El número de capa es una coordenada compartida en el sector para expresar de forma breve un punto de responsabilidad.

11. Corrigiendo errores comunes

Para terminar, vamos a recopilar y corregir los errores más comunes en torno al modelo de referencia OSI.

• «Internet funciona con las 7 capas de OSI». No funciona así. Lo que está implementado es TCP/IP (efectivamente cuatro capas); OSI es un modelo de referencia para explicar y conversar.²
• «Las cuatro capas de TCP/IP se corresponden perfectamente con las siete de OSI». La correspondencia de L5 a L7 es intrínsecamente ambigua. Es habitual ver una tabla que dice «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 la 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 precisa es que se sitúa por encima de L4, por debajo de L7, y combina roles equivalentes a L5 y L6.
• «Con solo mirar el número de puerto se sabe el protocolo». Que sea el puerto 80 no garantiza que sea HTTP. El número de puerto es una convención; no se sabe realmente qué está circulando hasta que se mira la carga útil. Por eso el disector de la muestra identifica HTTP fijándose en los caracteres iniciales del contenido, no en el número de puerto.
• «Los switches son dispositivos de L2, los routers son dispositivos de L3». Es correcto como punto de partida, pero en la realidad existen con toda normalidad dispositivos que abarcan varias capas: switches de L3, balanceadores de carga que reparten en L4, WAF que inspeccionan L7, etc. Es más preciso pensarlo en términos de «hasta qué capa lee este dispositivo».

12. Resumen

• El modelo de referencia OSI no es una implementación, sino un vocabulario para pensar por capas. Lo que funciona en la realidad es TCP/IP (efectivamente cuatro capas)
• Las siete capas no son un diagrama conceptual: están físicamente anidadas dentro de la secuencia de bytes de una única trama (L2: 0-13, L3: 14-33, L4: 34-53, L7: 54 en adelante)
• Cada capa lee solo su propia cabecera y no le importa el cargamento (las capas interiores): eso es la encapsulación
• L5 y L6 no existen de forma independiente en la pila real; TLS y la codificación han absorbido sus roles
• Lo único que escribe tu código C# es la secuencia de bytes de L7. Las cabeceras TCP/IP las añade el SO, y Ethernet lo añade la NIC
• Su utilidad práctica está en la resolución de problemas confirmando la vida capa por capa de abajo hacia arriba, y en el lenguaje común entre equipos
• Si ensamblas una trama con el código de muestra y la abres en Wireshark, puedes comprobar con tus propios ojos todo el contenido de este artículo

Artículos relacionados

• El error de pensar que se puede hacer Receive por cada unidad enviada con Send en TCP — diseño de la recepción tratándolo como un flujo de bytes
• Causas y diagnóstico de los cortes de comunicación de una cámara industrial por retransmisiones TCP
• Tabla práctica de decisiones para C# async/await - Task.Run y ConfigureAwait

Áreas de consultoría relacionadas

KomuraSoft LLC (合同会社小村ソフト) se encarga del diseño e implementación de aplicaciones Windows que se comunican por TCP/IP, de la investigación de la causa raíz de problemas de comunicación con equipos industriales (“a veces se corta”, “se ralentiza”), y del apoyo en la resolución de problemas mediante capturas de paquetes.

• Desarrollo de aplicaciones Windows
• Investigación de errores 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 Internet?

No, no se usan. Lo que realmente funciona en Internet es la suite de protocolos TCP/IP (efectivamente cuatro capas); los propios protocolos OSI de 7 capas perdieron la carrera de adopción en los años 90 y acabaron apenas utilizándose. La RFC 1122, que sentó las bases de Internet, explica el mundo en términos de cuatro capas: la capa de enlace, la capa IP, la capa de transporte y la capa de aplicación. Lo que sobrevivió es el modelo como vocabulario compartido para la resolución de problemas y la conversación — frases como «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, en realidad, dispersos y absorbidos en otros lugares: L5 (establecer y gestionar un diálogo) corresponde al handshake de TLS o a las cookies y tokens de HTTP, y L6 (transformar y cifrar la representación de los datos) corresponde al cifrado TLS, la codificación de caracteres y formatos de serialización como JSON. No tiene ningún valor práctico determinar a qué única capa pertenece TLS — lo que importa más es poder explicar que se sitúa por encima de L4 y por debajo de L7, combinando roles equivalentes a L5 y L6.

Si ya existe una dirección IP, ¿por qué también se necesita una dirección MAC?

Porque las capas reparten la responsabilidad de forma distinta. La dirección IP (L3) es la dirección que apunta al destino final, y no cambia desde el principio hasta el final de la comunicación. La dirección MAC (L2) es la etiqueta que indica quién transporta el siguiente salto, y se sustituye cada vez que cruza un router. Una trama enviada desde 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 se puede consultar la tabla de correspondencia 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: comprobación visual del indicador de enlace (L1-L2), ping a la puerta de enlace (L3), confirmación de una 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, como un servicio detenido o un cortafuegos. También funciona como un sistema de coordenadas compartido en el sector para expresar de forma concisa un punto de responsabilidad, como en «esto parece un problema de L2, ¿puedes revisar 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.