La estratificación de la web primitiva: cómo BBN y el Network Working Group crearon los protocolos de ARPANET

En 1969, Bolt, Beranek and Newman entregó minicomputadoras Honeywell personalizadas, conocidas como Procesadores de Mensajes de Interfaz (IMP, por sus siglas en inglés), para que funcionaran como pasarelas de red para un máximo de cuatro computadoras centrales en cada sitio a lo largo de Estados Unidos. Estas unidades reforzadas asumieron la tarea de enrutar paquetes de datos sin procesar entre distintas ubicaciones. Sin embargo, conectar computadoras centrales heterogéneas de diferentes fabricantes requería un conjunto completamente nuevo de reglas de software. BBN mantuvo el hardware y el software interno de las pasarelas, pero dejó la tarea de crear estándares de comunicación entre equipos a los científicos de la computación y estudiantes de posgrado que operaban las máquinas centrales en cada institución conectada.

La división del trabajo en el origen de la red

Para abordar esta división del trabajo, un grupo de jóvenes investigadores e ingenieros de equipos centrales formó el Network Working Group. Según la fuente, esta división organizativa forzó de manera natural una arquitectura de red estructurada por capas. BBN se concentró en el sistema subyacente de entrega de mensajes, mientras que el Network Working Group diseñó protocolos de nivel superior para traducir datos destinados a las aplicaciones. Al aislar el enrutamiento físico de las pasarelas de la lógica de aplicación a nivel de servidor, el equipo estableció un enfoque modular en el que las capas superiores del protocolo se ejecutaban directamente sobre las inferiores, sentando las bases estructurales de las pilas de red modernas.

El informe BBN 1822 y el límite de parada y espera

BBN documentó el nivel fundamental de la interfaz 1 entre servidores e IMP en una especificación técnica llamada informe BBN 1822. Bajo este protocolo, las computadoras centrales transmitían mensajes limitados a una longitud máxima de 8095 bits, precedidos por un encabezado que especificaba la dirección de destino y un número de enlace asignado. El flujo de tráfico se regulaba estrictamente en el nivel 1 mediante un mecanismo de parada y espera. Un equipo solo podía enviar un mensaje a la vez a través de un enlace, deteniendo posteriores transmisiones hasta que la pasarela receptora devolviera la señal de solicitud del siguiente mensaje (Request for Next Message).

Sockets de nivel 2 y control en el enlace 0

La comunicación de nivel superior exigía un control más preciso que el proporcionado por los simples números de enlace. Esbozado en el RFC 9 y formalizado en el RFC 54, el protocolo servidor-servidor de nivel 2 introdujo construcciones de software llamadas sockets. Los sockets se diferenciaban por género: los números pares representaban sockets de lectura para recibir datos, mientras que los números impares representaban sockets de escritura para enviar datos. Para gestionar estos canales unidireccionales, los equipos reservaron el enlace 0 exclusivamente para el envío de comandos de control. A través del enlace 0, los equipos conectados intercambiaban mensajes de control para abrir, ajustar velocidades de flujo y cerrar rutas de comunicación individuales sin interferir con los datos útiles.

La danza de las conexiones y el núcleo malinterpretado

Debido a que los sockets de nivel 2 creaban solo conexiones unidireccionales, las aplicaciones interactivas requerían un estándar de nivel 3 conocido como Protocolo de Conexión Inicial. Antes de iniciar una sesión de Telnet, el Protocolo de Conexión Inicial ejecutaba un intercambio de varios pasos: un cliente contactaba con el socket conocido de un servidor, recibía una nueva designación de socket, cerraba el enlace temporal y abría canales emparejados de lectura y escritura. En el núcleo de cada servidor residía el Network Control Program, una pila a nivel de sistema operativo que con frecuencia se recuerda erróneamente como un protocolo en lugar de como un software. Juntos, estos experimentos por capas demostraron que arquitecturas informáticas dispares podían negociar sesiones bidireccionales estables sobre una infraestructura de red compartida.

Basar los primeros experimentos de ARPANET en la estratificación de protocolos —separando el hardware de enrutamiento de nivel inferior del software del equipo de nivel superior— aportó las ideas prácticas necesarias para perfeccionar la conmutación de paquetes. Aunque las redes modernas reemplazaron los números de enlace de los IMP y las restricciones de parada y espera con abstracciones flexibles de TCP/IP, esta arquitectura inicial estableció el modelo de protocolos independientes y estructurados por capas que sustenta la comunicación global por Internet hoy en día.

Ilustración editorial generada con IA; no es una fotografía documental.

Fuente: 0b10 0b10 How the ARPANET Protocols Worked