A las 22:30 del 29 de octubre de 1969, un estudiante llamado Charley Kline se sentó frente a un SDS Sigma 7 en un laboratorio de UCLA y trató de hacer login en una máquina que estaba a más de 500 kilómetros, un SDS-940 del Stanford Research Institute. Al otro lado, Bill Duvall esperaba con un teléfono en la oreja para confirmar letra por letra lo que llegaba. Kline tecleó la «l». «¿Te llegó la l?». Sí. Tecleó la «o». «¿Y la o?». También. Tecleó la «g» y el sistema se cayó.
El primer mensaje que viajó entre dos ordenadores por ARPANET fue, literalmente, «lo». Un login a medias. Una hora después, reiniciado el sistema, la sesión se completó sin incidentes. Pero ese fallo torpe quedó anotado en el IMP Log de UCLA y se convirtió en una de las anécdotas fundacionales de internet. No hubo épica esa noche: hubo dos programadores, un teléfono y un crash. La red que hoy sostiene la sociedad digital empezó con un error de transmisión.
Conviene mirar ese origen con calma, porque muchas de las decisiones que se tomaron entonces siguen guiando, sin que lo pensemos, a quien administra sistemas distribuidos hoy.
El problema que ARPA quería resolver
A finales de los sesenta, la Advanced Research Projects Agency (ARPA), del Departamento de Defensa estadounidense, financiaba investigación en varias universidades, cada una con ordenadores caros, incompatibles y subutilizados. La idea era simple y muy poco glamurosa: conectar esas máquinas para compartir recursos de cómputo y evitar comprar lo mismo diez veces. Resource sharing, lo llamaban. Colaboración científica.
Merece la pena desmontar aquí un mito muy extendido. ARPANET no se diseñó para sobrevivir a un ataque nuclear. Esa motivación pertenece al trabajo previo de Paul Baran en RAND sobre redes de comunicación supervivientes, un trabajo distinto que con los años se mezcló en la cultura popular con ARPANET. Los propios protagonistas, Kleinrock entre ellos, lo han aclarado muchas veces: el motor de ARPANET fue compartir recursos y conectar a una comunidad de investigadores, no resistir bombas. Lo que sí heredó de aquellas ideas fue la robustez frente a fallos parciales, una propiedad técnica, no una doctrina militar.
El encargo de construir la red se lo llevó BBN (Bolt, Beranek and Newman), una firma de Cambridge que venía del cálculo acústico y era casi una desconocida en redes. Su equipo, los autodenominados «IMP Guys» liderados por Frank Heart, construyó los Interface Message Processors: miniordenadores Honeywell DDP-516 endurecidos que hacían de nodo de conmutación. Eran, en esencia, los primeros routers. El primero llegó a UCLA, al Network Measurement Center de Kleinrock, a finales de agosto de 1969. Para diciembre, cuatro nodos estaban conectados por líneas de 50 kbps alquiladas a AT&T: UCLA, SRI, UC Santa Barbara y la Universidad de Utah.
La idea que lo cambió todo: conmutación de paquetes
El salto conceptual no fue el cable, fue el método. En lugar de reservar un circuito dedicado para cada comunicación, como hacía la red telefónica, los datos se troceaban en paquetes que viajaban por rutas variables y se reensamblaban al llegar. La conmutación de paquetes nació de varias cabezas en paralelo: Baran en RAND, Donald Davies en el National Physical Laboratory británico, y la teoría de colas que Leonard Kleinrock venía desarrollando desde principios de los sesenta.
La consecuencia práctica es la que cualquier SRE reconoce de inmediato: si un nodo cae, los paquetes buscan otro camino. No hay un punto único de control cuya caída tumbe la red entera. Esa descentralización, que hoy damos por sentada en cualquier arquitectura cloud, era en 1969 una apuesta arriesgada y contraintuitiva.
Decisiones con efecto a largo plazo
Tres decisiones de aquel periodo siguen vigentes, evolucionadas, en la infraestructura moderna.
La primera fue protocolos simples y modulares. El primer protocolo de host fue NCP (Network Control Program), suficiente para una red cerrada. Pero NCP tenía un límite de diseño fatal: era exclusivo de ARPANET, sin capacidad real de interconectar redes distintas. La solución llegó con TCP/IP, y con ella una de las migraciones más citadas de la historia de las redes.
El 1 de enero de 1983, ARPANET ejecutó un flag day: un corte coordinado en el que NCP se apagó y solo las máquinas que ya hablaban TCP/IP siguieron conectadas. No fue una transición gradual y suave; fue una fecha límite dura, planificada años antes en el RFC 801 que escribió Jon Postel en 1981. Quien no había migrado, se quedaba fuera. Eran unos 400 hosts, una cifra que hoy haría inviable cualquier corte así, como nos recuerda cada vez que se habla de la eterna transición a IPv6. La lección no es técnica, es organizativa: una migración masiva funciona cuando hay una fecha, un plan y la disciplina colectiva para cumplirlos.
La segunda decisión fue la apertura. El proceso de estándares se construyó sobre los Request for Comments, la serie de documentos que arrancó Steve Crocker con el RFC 1 en abril de 1969. El nombre no es casual: «petición de comentarios», no «especificación oficial». Era una declaración de humildad deliberada para que nadie se sintiera dueño del estándar y cualquiera pudiera proponer mejoras. Esa cultura abierta es la misma que late hoy en proyectos como Linux o Kubernetes.
La tercera fue asumir que la red había que medirla. No por casualidad el primer nodo fue a parar al Network Measurement Center de Kleinrock. Desde el primer día se entendió que una red que no se observa es una red que no se entiende, y que la complejidad crece más rápido que la intuición. Toda la disciplina moderna de observabilidad, de Prometheus a OpenTelemetry, es nieta de aquella obsesión por instrumentar y medir.
Qué se lleva a casa quien gestiona sistemas hoy
ARPANET no funcionó por ser perfecta, sino por iterar sobre sus propios errores con paciencia. El «lo» fallido no se ocultó: quedó anotado en un cuaderno y hoy se exhibe con orgullo. Hay algo sano en esa honestidad para quien convive con post-mortems y caídas en producción.
La resiliencia no fue un añadido, fue una premisa de diseño: rutas alternativas, ausencia de un punto único de fallo, tolerancia a la caída parcial. Lo mismo que perseguimos cuando repartimos réplicas entre zonas o diseñamos para que un nodo menos no derribe el servicio.
Y la coordinación importa tanto como la tecnología. El flag day de 1983 demostró que un estándar gana no cuando es técnicamente superior, sino cuando una comunidad decide moverse a la vez y construye las herramientas para que ese movimiento sea sobrevivible. Los protocolos son sociales antes que técnicos.
Aquel login a medias de una noche de octubre no fue el nacimiento glorioso de internet. Fue un experimento que se rompió a la tercera letra, lo anotaron, lo arreglaron y siguieron. Catorce años después, los mismos principios —medir, abrir, coordinar— hicieron posible apagar un protocolo entero en un solo día sin que el mundo se enterara. Esa es, probablemente, la herencia más útil de ARPANET: no la red en sí, sino la forma de construirla.
Para seguir aprendiendo
- A Brief History of the Internet — Leiner, Cerf, Clark, Kahn, Kleinrock, Lynch, Postel, Roberts y Wolff (Internet Society). El relato escrito por los propios protagonistas, con traducción al español disponible. https://www.internetsociety.org/internet/history-internet/brief-history-internet/
- RFC 801: NCP/TCP Transition Plan — Jon Postel, 1981. El documento original que fijó la fecha del flag day. https://datatracker.ietf.org/doc/html/rfc801
- Where Wizards Stay Up Late: The Origins of the Internet — Katie Hafner y Matthew Lyon (Simon & Schuster, 1996). Crónica detallada y muy legible de las personas que hicieron ARPANET.
- Computer Networks: A Systems Approach — Larry Peterson y Bruce Davie. Manual de referencia disponible libremente online bajo licencia CC BY 4.0. https://book.systemsapproach.org/
- The Innovators — Walter Isaacson (Simon & Schuster, 2014). Sitúa la creación de ARPANET dentro de un relato más amplio sobre la innovación digital.