23. A brief history of the Internet

El siguiente contenido se
proporciona bajo una licencia Creative Commons. Su apoyo ayudará a
MIT OpenCourseWare a seguir ofreciendo
recursos educativos de alta calidad de forma gratuita. Para hacer una donación o
ver materiales adicionales de cientos de cursos del MIT,
visite MIT OpenCourseWare en ocw.mit.edu. PROFESOR: Entonces esta es la
penúltima conferencia del semestre. Así que lo que voy a hacer
hoy es, en unos 45 minutos, darles una breve historia
de Internet desde… comenzaremos a fines de la década de
1950 y luego llegaremos a hoy. Y luego, el próximo
lunes, concluiré esta clase
haciendo primero un resumen de 6.02, y luego también les contaré
un poco sobre hacia dónde creo que podría ir el futuro de los
sistemas de comunicaciones.

Probablemente me equivoque. pero estaré seguro de ello. Y hoy la idea
es intentar conectar algunos de los temas que hemos
estudiado en clase hasta ahora con esta historia. Por supuesto, no
podremos hacerlo todo. Hasta ahora, en
términos de historia, hay que asumir que vamos a
comenzar en 1959 o 1957. Y para entonces, la historia
de los sistemas de comunicación ha tenido muchos éxitos. Y un tema común
es que existe la tecnología que
aparece, tiene éxito, intenta apoderarse del mundo. Y justo en ese
momento, y parece que no
va a pasar nada más, aparece otra tecnología nueva
que, con el tiempo, acaba con todo. Así, la primera
tecnología de red exitosa fue el telégrafo eléctrico. Y el telégrafo eléctrico
fue creado por varias personas diferentes: Wheatstone y Cooke construyeron
un telégrafo eléctrico en Inglaterra, Morse y
Vail construyeron uno en Estados Unidos.

El código Morse se desarrolló como
parte del telégrafo eléctrico. Y eso hizo un gran
trabajo en las décadas de 1830, 1840, 1850, etc. Y luego
aparecieron otras tecnologías. Ahora bien, este tipo de
historia se sigue repitiendo. Y así, en la década de 1950,
el actor dominante en el área de las comunicaciones
es la red telefónica. Tenemos la Bell Telephone
Company, que en Estados Unidos domina. Hay compañías telefónicas equivalentes
en otros países.

Y tienes esta enorme e
increíble red telefónica. Y cada vez más
gente tiene teléfonos. En el aspecto inalámbrico,
no existía un sistema telefónico inalámbrico en la década de 1950. Pero lo que tenemos es radio, radio y
televisión, y algunas empresas muy poderosas
que poseen espectro inalámbrico para ofrecer televisión y radio. Así pues, la historia comienza
a finales de los años cincuenta. Y en 1957 ocurrió algo importante:
se lanzó el Sputnik. Y eso hizo que Estados Unidos asumiera
que se estaban quedando atrás en ciencia y tecnología. Y eso llevó a la creación
de ARPA, la Agencia de Proyectos de Investigación Avanzada
que aún existe. Hoy se conoce como DARPA. Y es probablemente el
mayor financiador federal de investigación fundamental y de
mucha investigación y desarrollo aplicados. Paul Baran es, en muchos sentidos,
uno de los padres, o el padre de las
tecnologías de conmutación de paquetes.

Estaba trabajando en un
grupo de expertos llamado Rand Corporation, que era
una organización que realmente era un grupo de expertos. Permitió a la gente pensar
en direcciones fundamentales a largo plazo en
términos de tecnología y hacia dónde
se dirigía la tecnología. Y estaba analizando
el problema de intentar construir
lo que llamó una red de comunicación con capacidad de supervivencia
. Y la historia es
que está tratando de construir una red que
pueda seguir funcionando frente a una guerra nuclear. Pero eso no es realmente lo que
estaba tratando de lograr. Lo que estaba tratando de construir
era simplemente comprender cómo se diseñan
redes de comunicación que le permitan manejar fallas. Y gran parte de la
red telefónica de entonces era un
tipo de estructura muy centralizada en la que había una red
con muy poca redundancia incorporada. Y tendrías muchas de estas
topologías centrales tipo estrella. Y el problema, por supuesto,
cuando conectas estas estrellas entre sí, y estas
piezas en forma de estrella se conectan con otras piezas en forma de estrella,
es que será mejor que hagas que estos puntos aquí,
estos nodos o interruptores aquí, sean extremadamente,
extremadamente confiables, y aquellos vínculos que
los conectan con estas otras
estructuras centrales.

Porque de lo contrario, el
fallo de esas cosas acabaría con el sistema. Y la Bell Telephone
Company realmente entendió cómo construir
estos interruptores muy, muy, muy confiables, pero
eran muy, muy, extremadamente caros. El otro problema es, y
volveremos a esto más adelante hoy, que una
red telefónica es una gran red. Pero admite exactamente
una aplicación. La aplicación es que
coges el teléfono y hablas. A primera vista, es muy difícil
imaginar cómo una
red telefónica haría un gran trabajo respaldando
la web, por ejemplo. Nadie pensó siquiera en la web. Pero incluso algo
básico como poder ver una
transmisión de video cuya calidad puede variar con el tiempo, son cosas
que Internet hizo de manera diferente y mejor
que la red telefónica. Pero la red telefónica
tenía entonces fundamentalmente un
problema de tolerancia a fallos. Y la forma en que
lo abordaron fue construyendo
componentes extremadamente confiables.

La idea de Paul Baran, en
la que otras personas habían estado pensando
y jugando, fue que observó eso…
y en aquellos días, la red telefónica
era en gran medida analógica. La telefonía digital
realmente no existía. Y las computadoras digitales
apenas estaban comenzando a aparecer. Y Paul Baran fue probablemente
una de las primeras personas que se dio cuenta de que la informática
y las tecnologías digitales pueden cambiar la vida en términos de cómo
se construyen estos sistemas. Porque la abstracción digital
te permite saber con seguridad si un componente
está funcionando o no. Porque si funciona
te da una respuesta que luego puedes verificar. Y si no funciona,
simplemente deja de funcionar. No es como un
sistema analógico donde puede que funcione o no , y a medida que el ruido
aumenta o ocurre alguna falla, comienzas a
ver mucho ruido. Y está confuso,
no estás muy seguro. Con un sistema digital,
o funciona o no funciona.

Puedes construir sistemas como ese. Y se dio cuenta
de que ahora se podía empezar a pensar en construir
sistemas fiables a partir de muchos
componentes individuales poco fiables. Y éste es el
tema rector fundamental de los sistemas informáticos a gran escala
de finales de los años cincuenta. Quiero decir, esto se aplica
hasta el modo en que funcionan Google, Amazon, Facebook
o cualquiera de estos grandes centros de datos. Cualquiera de
esas computadoras es muy poco confiable en
comparación con lo que se podría hacer si se
invirtiera mucho dinero para construir una
computadora muy confiable. Pero el conjunto
es muy fiable. Y para lograrlo se requiere
mucha inteligencia y cuidado. Y el primer
ejemplo real de esto es una red de comunicación digital
construida a partir de esta idea de paquetes. En un par de
artículos que escribió a finales de los años 1950
y principios de los 1960, dijo que con
la computadora digital ahora se podía empezar a construir redes de
comunicación altamente confiables a partir de
componentes no confiables.

Y entonces articuló
esta idea de que se pueden conectar estos
conmutadores o nodos entre sí en estructuras altamente redundantes. Y si tiene un
flujo de datos para enviar, no tiene que
elegir una ruta particular a través de la estructura. Podrías tomar ese
mensaje, dividirlo en diferentes partes y enviarlas
en diferentes direcciones. E incluso si decide
enviarlos todos en una dirección, si se produce una falla,
estos conmutadores podrían
comenzar a mover los datos en diferentes direcciones, lo que
significa que ya no piensa en una comunicación
como un gran flujo que tiene que
enviar. de una manera, pero puedes empezar a pensar
en dividirlo en estas partes diferentes. Ahora, como ocurre con muchas de estas
ideas, es raro encontrar… a veces sucede, pero es
raro encontrar exactamente una persona en el mundo pensando en ello.

Por muy
innovadora que fuera la idea, había otras
personas trabajando en ella. Y Donald Davies en
el Reino Unido, a principios de los años 60, estaba analizando ideas similares. Y de hecho acuñó
el término paquete. Ahora usamos paquetes para
referirnos a estos pequeños mensajes que se envían a través de
la red y que son unidades atómicas de entrega. Este término fue acuñado por
Donald Davies en los años 1960. Ahora, todo esto fue
maravilloso y una especie de abstracciones teóricas.

Pero, ¿cómo se empieza a
idear algunos principios de diseño para construir
redes de comunicación? En particular, ¿cómo se
aborda el problema de que estos enlaces
se unan en un conmutador y se intente compartir
los enlaces que salen de un conmutador de manera
que permita que el tráfico de diferentes conversaciones se
multiplexe en el mismo enlace? En retrospectiva, la idea de tener una cola
en un conmutador parece completamente obvia. Pero si es la primera
vez que ve algo como esto y la
red telefónica realmente no tenía colas, la idea
de crear una cola y ahora comenzar a analizar es un
resultado bastante innovador. Nuevamente hubo
mucha gente involucrada.

Pero probablemente las
principales contribuciones provinieron de una persona
llamada Len Kleinrock, que era estudiante de doctorado en el MIT. Y en su tesis doctoral de 1961
, "Flujo de información en grandes
redes de comunicación", escribió sobre cómo se podría utilizar la
teoría de colas para analizar y modelar redes de comunicación. Ahora, aproximadamente al
mismo tiempo, nuevamente en el MIT, Licklider
y Clark escribieron un artículo realmente interesante.

De hecho, vale la pena leerlo ahora. Quiero decir, fue hace 50 años
, pero es interesante. Tienes que retroceder y
pensar, esto fue en un momento en que la gente realmente no tenía
la idea de que la gente podía sentarse frente a las computadoras. Se utilizaron computadoras
para tal vez contar los votos. Sospecho que
hoy se equivocan más que en aquellos días. Pero las computadoras se
usaron para contar votos y para ayudar
con el censo de Estados Unidos. Pero nadie pensó en la gente
sentada frente a las computadoras. Y escribieron este maravilloso
artículo llamado "Comunicación entre el hombre y la computadora en línea ". Supongo que en aquellos días
, hombre significaba gente. De todos modos, ellos
escribieron este artículo. Y de hecho, Licklider
tuvo esta visión de lo que llamó una
red galáctica que abarcaría todo el mundo
y más allá, lo cual fue…

Para principios de los años 60, fue
una visión bastante notable. Ahora, usando estas
ideas, y particularmente las ideas de Len Kleinrock
, y esta idea de interacciones hombre-computadora,
que por supuesto, la idea de que todos
tengan su propia computadora no era la visión de este artículo. La visión de este artículo era que hay
muchas computadoras disponibles. Y la gente simplemente tenía
terminales remotas, y tú iniciabas sesión y
tenías estas grandes computadoras que podías usar.

Pero entonces
tendrías buenas interacciones en tu propia terminal. De eso se
trataba ese artículo. Larry Roberts estuvo primero en el
MIT y luego se mudó a ARPA para ejecutar este programa, creó
algo llamado ARPANET y escribió un artículo
y escribió un programa que es una convocatoria de propuestas
para ARPANET, que era un plan para computadoras remotas de tiempo compartido
. Entonces Internet…
ARPANET fue el precursor de Internet. Y no comenzó porque
quisiéramos construir una red de comunicación para prevenir… que funcionara cuando
hubiera una guerra nuclear o cualquiera de estos grandes desastres. En realidad, tenía un
objetivo muy concreto: simplemente permitir que la gente…

Las computadoras
eran muy, muy caras… simplemente permitir que la gente, sin
importar dónde estuvieran, pudiera aprovechar el
poder de la informática costosa en lugares lejanos, y hacer que
pareciera en la medida de lo posible como si las
computadoras estuvieran con usted. Esa era la visión… bastante convincente, pero simple. Y decidieron,
por muy buenas razones, optar por la conmutación de paquetes. Las razones
tenían que ver principalmente con la economía. Se trataba de una red
que se estaba proponiendo para una aplicación
cuya utilidad era cuestionable.

Y la idea de invertir
enormes cantidades de dinero no era del todo aceptable. Y Larry Roberts
y otros quedaron muy cautivados por esta visión
de la conmutación de paquetes. Entonces dijeron: ¿sabes
qué? ARPANET será una red de conmutación de paquetes. Volveré a esto
más adelante, pero, por supuesto, las
compañías telefónicas como AT&T simplemente pensaron que
era una idea terrible y aprovecharon cada oportunidad
para ridiculizarla. Se creó ARPANET y
algunos equipos ofertaron por el contrato . Y BBN… Bolt,
Beranek y Newman, que está cerca de Alewife
en Cambridge. Todavía están allí,
ahora son parte de Raytheon. Y todavía continúan haciendo
investigaciones bastante interesantes.

Ganaron el contrato
para construir esta red, desarrollar la tecnología
para esta red. Y debido a que el
procesamiento involucrado en la red, los
protocolos involucrados se
consideraban complicados y computacionalmente
intensivos, tuvieron que construir una
pieza de hardware separada a la que llamaron IMP, o
Procesador de mensajes de interfaz. Y BBN ganó el
contrato para hacerlo. La idea de un
procesador de mensajes de interfaz es que cada
computadora, así como cada conmutador,
tenga algún hardware para reenviar cosas.

Pero necesitabas algo
para hacer el cálculo tanto de las tablas de enrutamiento
como de cada paquete. Cada paquete
aparecería y habría que calcular algún
tipo de suma de verificación. Y tendrías que hacer esta
tarea computacional de descubrir cómo reenviar ese paquete. Y eso se
consideraba demasiado trabajo para tenerlo en una
pequeña computadora real. Así que tuvieron que construir
una pieza separada de hardware que se conectaría
a la computadora y que probablemente
sería igual de grande. Y puedes ver
la imagen aquí. Estos IMP estaban conectados a
computadoras más grandes o del mismo tamaño. Y estos hicieron el networking. Quiero decir, hoy en día, todo
eso, un millón de veces más, está sucediendo en este dispositivo. Pero en el pasado,
así era. Entonces ganaron este contrato de
procesador de mensajes de interfaz llamado IMP.

Y cuando usted gana un
contrato federal importante, muchas veces su congresista
o senador le escribe. De hecho, es gracioso
porque muchos de nosotros recibimos… durante un período de tiempo antes de las
elecciones al Senado, muchos de nosotros recibimos correos electrónicos, cartas
de Scott Brown felicitándonos por ganar alguna
pequeña propuesta del NSF. No sé si otras
personas aquí lo entendieron, otros profesores aquí lo entendieron. Pero es como
en aquellos días, si ganabas un contrato importante,
obtenías dinero, recibías una carta
de tu congresista. De hecho, Ted Kennedy, quien
era senador en ese momento y lo fue durante muchos años,
felicitó al equipo por ganar esto. Excepto que se equivocó:
los felicitó por ganar el contrato para
construir el procesador de mensajes interreligiosos . Supongo que si
realmente lo hubieran construido, podría haber sido
una contribución más útil a la paz mundial. Pero lo único que
consiguieron fue el contrato para construir el
procesador de mensajes de interfaz… sólo detalles. De todos modos, este equipo era
un equipo bastante notable. Ellos construyeron el primero… no construyeron el
primer programa de correo electrónico. Esto se repitió
en el MIT en los años 60.

Pero lo que sí hicieron fue
el primer programa de correo electrónico que atravesó diferentes
organizaciones. Y, de hecho, el símbolo @
en sus direcciones de correo electrónico, que por supuesto, es
el símbolo correcto a usar, si usa el símbolo @. Pero hubo una persona en
BBN, Ray Tomlinson, que dijo: Voy a poner el
símbolo @ en las direcciones de correo electrónico. Y sucedieron muchas cosas tempranas
que continúan hasta el día de hoy. Entonces construyeron esta red. Y Kleinrock en UCLA
fue el investigador principal en esto: ahora construye sistemas a partir
de esta pieza de hardware que se construyó. Y esta era la
imagen de ARPANET en 1969.

Esto se convirtió en Internet. Hoy en día hay una evolución continua
desde esta imagen de cuatro nodos hasta Internet. Y en 1969 finalmente
conectaron primero dos y luego cuatro nodos. Y tuvieron que hacer la
primera demostración. Y al escuchar a Len
Kleinrock contar la historia, ésta era su historia. Dice que su grupo en UCLA
intentó iniciar sesión en una computadora en SRI, que está en Palo Alto. Y dijo, establecimos una
conexión telefónica entre nosotros y los chicos del SRI. Escribimos la L y
preguntamos por teléfono, porque tenían que comprobar
si funcionaba, así que tenían el teléfono para comprobarlo. Preguntamos por teléfono, ¿
ves la L? Sí, vemos la L,
fue la respuesta. Escribimos la O y
preguntamos: ¿ves la O? Sí, vemos la O. Escribimos
la G y el sistema falló.

Pero ya sabes,
tienen algo funcionando. Y, por supuesto,
aquí hay una bonita declaración. Ya sabes, mucha gente
se preocupa por las optimizaciones del rendimiento. Pero la optimización más importante
en un sistema es pasar de no
funcionar a funcionar. Y el hecho de que algo
haya funcionado es extremadamente importante. Muy poco después,
conectaron la costa este: un grupo de computadoras y
organizaciones de la costa este con la costa oeste,
entre ellas el MIT. Había un equipo
en BBN y muchos de ellos eran del MIT. Así que MIT, BBN, Harvard y los
laboratorios Lincoln de este lado, y MITRE se conectaron
en Carnegie…

Hoy es la
Universidad Carnegie Mellon, creo que se llamaba
Carnegie Tech en ese momento… Universidad de Illinois, y luego
largas colas. a campo traviesa. Había un grupo en
Utah y en California. Ahora bien, ¿cuáles eran estos vínculos? Alguien quiere adivinar: estos
vínculos en todo el país, o entre Harvard y el
MIT, o al otro lado de allí, ¿crees que realmente
pusieron cables nuevos y tendieron estos cables? ¿ Cuáles crees que eran? Eran líneas telefónicas. Y así esta idea
aparece una y otra vez. ARPANET era
esencialmente una superposición construida sobre la
red telefónica.

Y, de hecho, fue
una superposición hostil. Porque a la
red telefónica realmente no le gustó… quiero decir, en ese
momento, pensaron que esto era sólo una broma académica. Pero con el tiempo, quedó claro
que esta red subyacente se estaba utilizando para
hacer algo diferente. Y entonces se construye
una red superpuesta, y las superposiciones
aparecen una y otra y otra vez. Lo que pasa es que
hoy en día no son tan hostiles.

Otro ejemplo de
superposición es BitTorrent, o cualquier aplicación peer-to-peer:
Skype, todas estas cosas
son superposiciones que se crean sobre Internet. Y, de hecho, gran parte de la
razón de su existencia se debe a que
Internet no hace lo correcto en
términos del comportamiento correcto para ciertas aplicaciones. Entonces la gente dice, déjame
construir una superposición encima, en la que tomas
un camino que involucra múltiples enlaces en la
red subyacente y haces que parezca un enlace
en la red de nivel superior. Y cuando haces eso,
obtienes una red superpuesta. Entonces, este único
enlace en ARPANET es en realidad muchos, muchos
enlaces con muchos conmutadores, y ¿quién sabe lo caro que
es el subyacente en la red telefónica? Pero todo lo que tienes que hacer es
pagarle a la red telefónica una cierta cantidad de dinero y
hacer una llamada o lo que sea, y podrás
verlo como un enlace único. Y puedes hacer
lo mismo en Internet. Ahora, este protocolo, el
protocolo de enrutamiento que usaron, fue un
protocolo de enrutamiento por vector de distancia.

En realidad, ni siquiera era tan
sofisticado como el que estudiamos. Pero era un
protocolo de vector distancia. Y el vector de distancia fue
el primer protocolo de enrutamiento jamás utilizado en una
red de conmutación de paquetes. Y continuó en
ARPANET durante muchos años. Continuaron
ejecutando este protocolo. Bien, continuando, pasamos
de las redes de paquetes básicas a este problema de
interconexión en red. Y eso pasó por
una serie de demostraciones. Uno de ellos fue que tuvieron
una gran conferencia en 1972. Y estaban demostrando el
simple ARPANET conmutado por paquetes.

Y funcionó muy bien,
excepto cuando se lo demostraron a un equipo de AT&T y
no funcionó en absoluto. Y de hecho, se
escribieron artículos de noticias. Y algunas personas escribieron que
esta era una buena red, otras escribieron
que nunca funcionó. Y AT&T simplemente pensó,
ah, grupo de académicos, en realidad nunca va a funcionar. Escribieron un
programa de correo electrónico modificado. Y Estados Unidos no era el único
lugar donde se estaba trabajando. En Francia, había un
equipo realmente bueno que creó una red llamada CYCLADES. Y Louis Pouzin fue el
investigador principal de ese sistema.

Creo que CYCLADES
no recibe suficiente crédito porque a menudo, como ocurre con
estas cosas, el ganador, ARPANET, se convirtió en Internet,
y así todos se olvidaron de todo lo demás. Pero a CYCLADES se le ocurrieron
algunas ideas bastante interesantes e innovadoras. La idea de articular
que esta red va a ser una red de mejor esfuerzo
con estos paquetes que llamaron
datagramas, que es una palabra que se sigue
usando hasta el día de hoy, estuvo en esta red francesa. Ellos originaron el
protocolo de ventana deslizante. Parece obvio, pero no lo es. Puede ver que hay
muchas sutilezas en cómo se construye dicho
protocolo y cómo se argumenta que es correcto. El primer protocolo de ventana deslizante
fue en CÍCLADES. Y TCP, que hoy
es el estándar mundial, utilizó una idea muy, muy similar. Y también utilizan el
enrutamiento por vector de distancia. Y también implementaron,
por primera vez, una forma de sincronizar la
hora entre ordenadores. Y tenían una serie
de ideas interesantes en esta red. El trabajo no se
hacía sólo en la zona amplia.

En 1973, Ethernet fue
inventado en Xerox PARC por un equipo que incluía a
Bob Metcalfe, otro alumno del MIT. Eso se inspiró en este
protocolo Aloha que estudiamos. Y Ethernet era
esencialmente Aloha con
acceso múltiple con detección de operador, muy similar a
lo que estudiamos. Esta idea de
ventanas de contienda es una idea nueva. De hecho, utilizaron el
método de probabilidad. El estándar Ethernet evolucionó
a finales de los años 70 y 80 para utilizar la
ventana de contención que conocemos ahora. Y esa misma
idea de ventana de contención y sentido de operador se utiliza en Wi-Fi. Para que pueda extraer
esta corriente de ideas que continúan
existiendo hasta el día de hoy. Es interesante que
Ethernet hoy en día no utilice acceso múltiple con detección de operador.

Porque hoy en día ethernet ya no es
una red de baja velocidad, es una red muy rápida. No es un bus compartido,
son enlaces punto a punto. Pero se llama
Ethernet y no utiliza el mismo
protocolo MAC excepto cuando tienes Ethernet de baja velocidad. Por otro lado, la tecnología inalámbrica
utiliza la idea de Ethernet. Y, de hecho,
mucha gente llama al 802.11 (solían
llamarlo ethernet inalámbrico). Y las ideas simplemente se
trasladaron a un dominio diferente, pero son las mismas ideas. Y, de hecho, muchos
de los primeros conjuntos de chips que ejecutaban el protocolo MAC
en redes 802.11 eran esencialmente los mismos
que el protocolo Ethernet.

Utilizan la MAC de Ethernet. Tenían esa pieza
de hardware, la comprarían y construirían
la caja a su alrededor. Entonces, esta idea de tomar
tecnología antigua, aplicarla a un nuevo
contexto y luego modificarla es algo que
funciona bastante bien. Porque significa que
puedes aprovechar algo que ya existe y
empezar a hacerle cambios. Y con el tiempo, parece
completamente diferente. Ahora, el
gobierno de EE.UU. y DARPA- ARPA estaban financiando ARPANET. Pero aquí también había empresas
y otros grupos de investigación . Y en aquellos días
no estaba muy claro quién iba a ganar. Y todo el mundo estaba
investigando cómo encontrar diferentes formas de
conectar redes. Y Xerox tenía un
sistema llamado PUP. No sé qué significa. Creo que significa PARC, Xerox PARC, Palo
Alto Research Center, PARC o algo así. No sé qué es la U. Y en cierto modo, había
muchas ideas técnicas en el sistema Xerox
que en realidad eran posiblemente mejores
en términos técnicos que ARPANET y TCP/IP. Pero era propietario, mientras que
TCP/IP era completamente abierto. Y abierto significaba que
no tenías que pagarle a nadie, no necesitabas obtener el
permiso de nadie para hacerlo.

El proceso mediante el cual
se estandarizaron las cosas fue mucho más abierto
y democrático. Y ganó no
porque fuera mejor, sino porque estaba ahí
fuera, abierto y gratuito. Hay mucho que
decir sobre ese modelo. Porque para que una
red tenga éxito, es necesario reducir
la barrera de entrada para que todos puedan participar
e implementarla. Y si
los protocolos de red son propietarios, normalmente no se
beneficia a nadie. Creo que ahora las empresas
han empezado a darse cuenta de ello. Entonces, todos
entienden que usted quiere hacer que los estándares sean
abiertos y luego mantener en secreto cualquier
estrategia de implementación particular sobre cómo implementarla. Por lo tanto, es posible obtener una
ventaja comercial con la implementación, pero no se obtiene ninguna
ventaja comercial al mantener cerrado un protocolo. Hay excepciones
a esta regla. Skype es una
excepción a esta regla. ¿ Pero quién sabe? Sospecho que dentro de cinco o diez años
no es probable que Skype siga siendo dominante. Habrá otras
cosas que sucederán. Y algunos de ellos podrían estar abiertos. A mediados de la década de 1970, echó raíces la idea
de que ahora realmente se empiezan a conectar muchos
tipos diferentes de redes, redes que se ejecutan
en diferentes organizaciones .

Y este era el
problema de las redes. Y este es el problema: la gente estaba trabajando en estas
tecnologías de conmutación de paquetes. Y aparecieron muchos
tipos diferentes de redes de conmutación de paquetes . Entonces estaba la
red Aloha en Hawaii. Había gente que construía
redes de conmutación de paquetes a partir de Ethernet.

En el MIT y en la Universidad de Cambridge
había gente que estaba muy
enamorada de algo llamado Token Ring. No sé si Victor
estaba en el MIT en ese momento, o alguno de mis colegas
, pero la gente estaba construyendo estos
sistemas basados ​​en Token Ring que eran técnicamente bastante
superiores en algunos aspectos e interesantes. Y entonces, había muchos
tipos diferentes de redes que la gente estaba construyendo y
conectando sus propios campus internamente. Y había que comunicarse
entre sí. El problema era que no existía un
protocolo único para hacer esto. Entonces, Ethernet tenía…
en el pasado, cuando compraste una
tecnología Ethernet de, digamos, Digital
Equipment o Xerox o una de estas compañías,
no solo obtenías Ethernet. Obtendrías el
protocolo MAC de Ethernet. Luego obtendría algún tipo
de comunicación de red, capa de red entre los
diferentes dispositivos Ethernet. Y obtendrías
algo llamado EFTP, que era un
protocolo de transporte de archivos de Internet.

Entonces obtendrías
aplicaciones a su alrededor. Así que imagina ahora que estás
comprando algo de red. Y no puedes ejecutar
tus propias aplicaciones, obtienes una pila de todo. Y obtienes una caja
y solo puedes usar lo que
te dio el proveedor. Ese era el estado de
las redes en ese momento. Y la gente reconoció que
esto probablemente no era algo muy bueno. Porque lo que nos gustaría es
tener una red donde la gente pueda inventar
sus propias aplicaciones y ejecutar sus propias
aplicaciones en ella. Pero ahora necesitabas
una forma de comunicarte entre estas
diferentes redes. Entonces, ¿cómo se hace esto? Así que este fue un
proyecto enorme en el que participaron muchas organizaciones diferentes
. Pero una gran parte del crédito
se le da a dos personas: Vint Cerf y Bob
Kahn, quienes fueron en cierto sentido los líderes en la creación de
una comunidad de otras personas. unir a las personas para construir el sistema. Y articularon estas
visiones y estas ideas. Entonces las reglas de interconexión de Kahn
son las siguientes. Primero dijo que cada
red es independiente y no debe cambiar. Entonces, la idea de que se pueden
unir redes y comunicarse, si eso requería que
todas las redes cambiaran, no era una idea aceptable.

La segunda es que estuvo de acuerdo
con CYCLADES y dijo que
lo que necesitamos es la mejor comunicación. Porque no podemos asumir que
todas las redes garantizarán la entrega. Hay algunas redes que
pueden garantizar la entrega en orden, pero no puedes exigirlo. Y lo que dijeron fue que
diseñaremos esta red con estas cajas que
llamaremos puertas de enlace. Y estas puertas de enlace
se traducirán entre diferentes
protocolos de red. Y en un
alejamiento bastante radical de la
red Bell Telephone, dijeron que no habrá un control
central de gestión global .

No existe un
lugar central donde se vaya a gestionar el funcionamiento de esta red mundial
o de esta red nacional . Es una
idea bastante simple: tienes tu propia red interna. Esto podría ser una Ethernet,
podría ser algún tipo de red Aloha o lo que sea. Pero aquí tienes estas puertas de enlace
que se ubican y traducen entre estos
diferentes protocolos. Y sabemos las cosas como… ahora sabemos que lo que hicieron
fue una decisión bastante buena, es decir, lo hicieron para
que todas estas puertas de enlace estuvieran de acuerdo en un protocolo. Y el protocolo
que estandarizaron… se equivocaron al principio,
pero a finales de los años 70 se dieron cuenta de que ese
protocolo se llamaría IP o protocolo de Internet.

Entonces, un nodo está en
Internet si implementa el
protocolo de Internet, lo que significa que tiene un plan acordado sobre
cómo funciona el direccionamiento de los nodos y tiene un plan para
lo que sucede cuando se reenvía un paquete. Tiene una
tabla de enrutamiento y de búsqueda que busca la dirección IP
y luego decide el enlace. Y eso es todo en lo que
tienes que estar de acuerdo. Entonces, para estar en Internet,
todo lo que tienes que hacer es: una red debe
admitir direcciones IP y debe aceptar que
enviará paquetes de al menos 20 bytes de tamaño, porque esa es
la longitud del encabezado IP. Hay muy poco
más que tenga que hacer, tanto es así que la gente
ha escrito estándares sobre cómo enviar
protocolos de Internet a través de, ya sabes, paloma mensajera.

Y se puede… y de hecho,
alguien demostró algo como esto, donde
tenían estas cosas, y estas palomas
estaban entregando estos trozos de papel, y
había algo buscándolos y enviándolos. Así que no hace falta mucho
para estar en Internet. Entonces Cerf y Kahn comenzaron a
diseñar la red. Y escribieron en
su documento original que era necesario
identificar la red en la que se encuentra y, dentro de la red,
el host en el que se encontraba. Y dijeron que la elección
de la identificación de la red permite hasta 256
redes distintas. ¿ Cuántas redes
necesitas? ¿ Cuántas organizaciones
puedes tener? Y escribieron, ya sabes,
famosas últimas palabras: este tamaño parece suficiente para
el futuro previsible.

El problema es que
estaban un poco equivocados. El
futuro previsible en su caso era probablemente de menos de diez años,
y quizá no más de cinco o seis años. Pero ya sabes,
cometieron un error. Pero lo interesante fue que
la siguiente vez que la comunidad tuvo que hacer un cambio
en esa decisión, igualmente cometieron un error. Decidieron que las
direcciones IP de paquetes de 32 bits son suficientes. Y se nos acabó. Literalmente nos quedamos
sin direcciones IP en este momento. Entonces tenían estas puertas de enlace
que se traducirían y usted ejecutaría el
protocolo de interconexión de redes o IP. Entonces, en la década de 1970, esta
idea de interconexión en red estaba de moda. Y en 1978, se tomó
una muy buena decisión de separar TCP de IP. Y gran parte de esa motivación provino
de un grupo de personas del MIT. Aquí hay un artículo que
estudiarás detalladamente en 6.033. Es uno de esos
artículos que estudiarás dos o tres veces,
porque seguirá regresando, porque estos conceptos
son bastante importantes. Saltzer, Reed y Clark lo llaman "Argumentos de un extremo a otro
en el diseño de sistemas" .

Tienen muchos
ejemplos, pero la esencia de los argumentos de un extremo a otro
es que si tienes un sistema, como digamos una
red, y quieres poder
diseñar una red, y tienes que tomar una
decisión sobre qué ¿Qué funciones pones en la red? Los argumentos de un extremo a otro
dicen que solo se incluyen en
la red funciones que son absolutamente esenciales para
el funcionamiento del sistema. Cualquier otra cosa que no sea crucial
para el funcionamiento del sistema, se deja en manos de los puntos finales. Entonces, si piensa en la
confiabilidad como un objetivo (por ejemplo, si la red
necesita implementar un mecanismo para garantizar la entrega de
paquetes), la respuesta es no. La razón es que
esa propiedad es obligatoria, por ejemplo, si estás
entregando un archivo, pero no si estás entregando
una transmisión de video o hablando.

Porque no es necesario que todos los bytes
lleguen allí, lo que significa que no se
coloca esa funcionalidad dentro de la red. Se deja la función
de lograr confiabilidad a los puntos finales, porque
no todos la necesitan. Y la única
excepción a la regla de que la única función que se
coloca dentro de la red son funciones que son absolutamente
esenciales para que el sistema funcione es si el
mecanismo conduce a mejoras significativas
en el rendimiento. Entonces, por ejemplo, si se ejecuta en una
red con una tasa de pérdida de paquetes del 20% , tiene sentido
tener cierto grado de confiabilidad y
retransmisión integrado en un centro de red. Eso es lo que
haría el Wi-Fi. Porque si
no lo hiciera, a veces tendría una
tasa de pérdida de paquetes del 20% o 30%. Y eso haría que
todo no funcionara. Pero no intentamos
diseñar nuestra red de manera que entre el punto de acceso Wi-Fi
y su computadora produzcamos una
transmisión perfectamente confiable. Si hiciera eso,
significaría que tendría retrasos realmente largos.

Y estarías proporcionando
esa función para aplicaciones que no la necesitan. Si quiero una
aplicación a través de la cual me gustaría simplemente enviar
los bytes, si pasa, genial,
si no, entonces haré otra cosa, ese es
un mal diseño de red. Desafortunadamente,
hoy en día existen redes reales que no obedecen este principio. Las redes celulares
a veces son problemáticas, como Verizon o
AT&T o algo así. Allí encontrará, con
datos reales, que hay grandes retrasos en estas redes.

Porque entre la
estación base celular y su teléfono, han decidido
proporcionar algo que parece TCP altamente confiable. Es un
diseño de red algo malo, pero así es como
lo hacen algunos de ellos. Este es un principio antiguo,
pero a veces no se sigue y
eso no es tan bueno. Ahora bien, la razón por la que la
conmutación de paquetes y esta división TCP/IP ganaron en Internet en comparación
con otras propuestas que flotaban
en ese momento es que esta arquitectura,
la arquitectura de Internet, es lo suficientemente buena para todo,
pero óptima para nada.

Realmente no existe ninguna
aplicación para la cual el diseño de la
infraestructura de la red de Internet sea óptimo. Si quisieras construir una
red que admitiera voz, construirías una
red telefónica. No construirías una red
como esta. Si quisieras construir una
red para distribuir datos de televisión en transmisiones de televisión
a un grupo de personas, no construirías Internet. Si quisieras
construir una red que apoyara
a Facebook y nada más, probablemente no
construirías Internet. Pero si desea una red que
admita todas esas aplicaciones razonablemente bien,
incluidas aplicaciones que no puede imaginar hoy en día, este
diseño es una muy buena idea porque es muy minimalista.
La red no hace casi nada. Deja todo
hasta el final. Entonces, diría que, de hecho,
la lección más útil, que aplicará una
y otra vez, es decir, digamos que
trabaja en una empresa o trabaja en algún tipo
de proyecto de investigación.

Y en varias etapas
del proyecto, hay discusiones interminables
sobre lo que hay que hacer: si vale la pena hacer
algo o no. Y la lección más importante
que se puede aprender en el diseño de sistemas es que
cuando se enfrente a una elección, trate de elegir la
opción más simple posible que haga el trabajo.

Porque lo más probable es que, si
te equivocas con la aplicación de lo que
sea que estés creando, si es simple y
minimalista, probablemente puedas cambiar
y usar lo mismo para esa otra aplicación. Aquí hay un
conjunto de citas famosas. Siempre se deben diseñar
sistemas para lograr flexibilidad porque, naturalmente,
nunca (casi nunca se sabe cuándo se diseña) todo el mundo
tiene estos casos de uso en mente. Pero seamos realistas: cuando
estás en las primeras etapas de un proyecto, nadie
lo sabe realmente.

Y casi
siempre te equivocarás. Por lo tanto, es importante diseñarlos
para que sean flexibles, no para el rendimiento, no para que tengan
mucha funcionalidad, solo para que sean flexibles
y lo mínimo indispensable para realizar el trabajo en función de
lo que usted cree que es necesario. Y normalmente significa
hacerlo incluso si eso significa sacrificar el rendimiento. Como dije, la
mejora más importante en el rendimiento del sistema
es lograr que funcione. Todo lo demás es secundario. Así que hay una buena cita
aquí, no sé si… ¿ algún hablante o lector de francés? ¿ Sí? AUDIENCIA: [HABLA FRANCÉS] PROFESOR: Sí, lo sé. Sólo dímelo en inglés. [RISAS] Bastante bien, está bien. AUDIENCIA: Parece que la
perfección no se alcanza cuando no hay nada
que agregar, pero no hay nada que…

PROFESOR: Sí, eso es genial. Sí, la perfección no se logra
cuando no hay nada más que agregar, sino cuando no
queda nada que quitar. Y esta es una muy,
muy buena lección. Quiero decir, chicos,
cada uno de ustedes irá
al mundo real, ya sea en una
empresa nueva o en una gran empresa donde están definiendo
un nuevo producto, o un proyecto de investigación,
van a la escuela de posgrado… en Al principio, no
sabrás las respuestas correctas. Tienes algunas
ideas vagas de para qué sirve cuando
diseñas algo. Y es muy
importante comprender que debes hacer lo
mínimo necesario para que funcione. Y es una
idea realmente buena: menos es más. Tengo una forma muy sencilla
de pensar en ello. Les digo esto a mis alumnos
repetidamente: en caso de duda, simplemente omítalo. Si no estás seguro de si
lo necesitas o no, no lo hagas. Hay suficientes cosas que hacer.

Y esa es probablemente la
lección más importante de muchas de las clases,
al menos en el lado del sistema que aprenderá. Por supuesto, se necesita mucho
buen gusto, perspicacia e intuición para descubrir
qué es realmente importante. Ahí no puedo ayudarte. Bien, en la década de 1980,
Internet comenzó a crecer. Y la forma en que se
quería manejar el crecimiento era esta
idea simple pero brillante llamada direccionamiento topológico. Entonces voy a explicar
lo que eso significa. En los primeros
días de Internet, e incluidas las pequeñas
redes simples que estudiamos, cada nodo de la red tenía
un identificador de red: una dirección IP o algún tipo
de nombre para ese nodo. Entonces, tal
como lo vimos, los nodos tendrían nombres
como A, B, C, D y E. Pero en realidad, A,
B, C, por supuesto, hay un conjunto de
bits que se comunican. Y en los viejos tiempos
de Internet, tenías un
identificador de dos fases.

Tendría una especie de identificador de red
o de organización . Entonces, el MIT tendría
un conjunto de 8 bits, y luego tendríamos
un conjunto de otros bits aquí que comunicarían dentro del
MIT lo que significa ese número. De manera abstracta,
estos números no significan nada en
Internet global. Esto podría ser simplemente
110111 y algo así. Y luego tendrías otra
secuencia de otra cosa. Esa era la idea básica. Ahora bien, en las redes que
estudiamos hasta ahora ni siquiera tendríamos esto. Cada nodo de la red
tendría simplemente un nombre. Entonces, lo que eso significa es que podrías
tener una dirección de red que fuera un conjunto de bits. Podría tener una
dirección de red que fuera algún otro conjunto de bits. Y los conmutadores de
la red, para reenviar paquetes
a usted o a mí, tendrían que tener entradas
en las tablas de enrutamiento que fueran uno a uno con todos
los diferentes nodos con los que querían
comunicarse.

Por lo tanto, tendría
una tabla de enrutamiento que sería
esencialmente una entrada para cada host de la
red, que no se escala. Es simplemente demasiada información. Entonces, el
direccionamiento topológico es la idea de que las entradas de enrutamiento por nodo
no escalan muy bien. Entonces lo que le gustaría
hacer es organizar la red jerárquicamente. Y es algo similar a la
forma en que funciona el sistema postal . Entonces, en la década de 1980, se les
ocurrió una forma de hacerlo utilizando tres
tipos de direcciones. La llamaré
dirección de clase A, B y C. Ya no los usamos
, pero permítanme describir lo que significa este tipo de
direccionamiento basado en áreas. He aquí una visión muy simple y
abstracta de esto. Internet solía adoptar
esto de forma aproximada. Pero esta es la idea conceptual. Diseñas la
red en áreas. Así que el MIT podría ser un área,
Stanford podría ser un área, Berkeley podría ser
un área… ya sabes, BBN, todas estas
personas diferentes son sus propias áreas, organizaciones.

Las áreas tienen números
que todos conocen. Esa es la primera parte, que
podría ser un identificador de área. Y luego esto es… dentro del área, es posible que
tenga un identificador de host o, más generalmente, un
identificador de interfaz. Lo que quiero decir con interfaz es
que realmente en Internet, mi computadora no
tiene una dirección IP. Si estoy conectado a
Internet mediante Ethernet, Ethernet tiene una dirección IP.

Obtiene una dirección IP
al conectarse a un conmutador aguas arriba de la misma. La red Wi-Fi M
tiene una dirección IP. Si uso Bluetooth, mi
Bluetooth tiene una dirección IP. De hecho, en general, a
veces mi computadora puede tener cuatro
direcciones IP: una si estoy conectado a Ethernet,
otra a Bluetooth y otra a Wi-Fi. Y si tengo uno de
esos módems celulares, si me conecto a través de
mi teléfono, cada vez que hago una de esas cosas,
obtengo una dirección IP, ¿vale? Entonces, las direcciones IP en Internet
nombran la interfaz de red. Entonces, la forma en que
funciona esta idea de enrutamiento de área es que dentro de
estas áreas, hay enrutamiento y
reenvío como de costumbre. Entonces, todos estos nodos tienen… se podrían
construir subáreas de forma recursiva.

Pero si no lo hiciera,
cada uno de estos tipos tendría una entrada para todos
los demás nodos aquí. Y dentro de estas áreas,
habría enrutadores fronterizos. Y estos
enrutadores fronterizos sólo tendrían entradas para
las otras áreas. Entonces, si quisiera enviar
un paquete desde el área 1 al área 4, lo que haría
es enviar un paquete a uno de sus enrutadores fronterizos. Y ese enrutador fronterizo
tendría una entrada en su tabla de enrutamiento
para llegar al área 4. No sabría nada sobre
los detalles dentro del área 4. Y entonces tienes una buena jerarquía en
la que dentro de la red, solo sabes cómo entrar.
su red y hasta la frontera.

Las fronteras saben
cómo entrar y las fronteras saben cómo
llegar a otras fronteras. Pero la frontera de
un área no sabe penetrar en
ninguna otra red. Como puede ver ahora, puede
aplicar esta idea de forma recursiva y comenzar a escalar
el sistema de enrutamiento. Ahora, en Internet, lo que
terminó sucediendo fue que tuvieron que aplicar
esta jerarquía de áreas. Y muy pronto, las organizaciones
empezaron a decir, bueno, tengo un área grande
y tengo un área pequeña. ¿ Qué tan grande
haces esta cosa? En la antigua Internet,
estos tenían 8 bits de largo y eran el
resto de la dirección. Si tienes 8 bits,
sólo podrás tener 256 organizaciones.

Y aunque Kahn y Cerf
pensaron que eso era suficiente, claramente no era así. Entonces, en ese momento, la gente estaba
comenzando a construir equipos con estas direcciones de 32 bits. Y todo este hardware estaba
ahí fuera, entonces, ¿qué haces? Entonces lo que dijeron
fue, muy bien, tengamos tres
clases de áreas. Para los realmente grandes,
tendremos direcciones de clase A. Luego, para los
medianos, tendremos la clase B. Y para los
pequeños, tendremos la clase C. Lo que eso significa es
que vamos a tener la clase A, lo que permite a una
organización tener hasta 2 de los 24. direcciones. Porque la clase A se
identifica con 8 bits. Entonces obtienes 24,
que es 32 menos 8. Entonces el MIT fue bastante inteligente. Decidieron que
irían y… ya sabes, estaban
allí arriba, estaban investigando mucho sobre redes. Entonces dijeron,
vamos a conseguir una de estas direcciones de clase A
porque somos una universidad grande y tenemos muchas computadoras.

Y probablemente se dio el
caso de que en ese momento, el MIT probablemente tenía más computadoras
que la mayoría de los otros lugares. Así que incluso hasta el día de hoy,
mantienen esta dirección, que era estrella de 18 puntos,
donde la estrella se refiere a… bueno, técnicamente,
estrella punto estrella punto estrella. Entonces, todas las direcciones de 2 a 24
que comienzan con el número 18, o en términos binarios,
lo que sea que sea 18, 000, voy
a entender esto mal, pero hay un
número de 8 bits para 18. De todos modos, Ellos fueron
y lograron hacer esto. Ahora, nadie quería la clase
C porque las clases eran… se podían obtener de 2
a 8 direcciones porque la clase C se
definió como una base de 24. Entonces tienes 24 bits para
definir la organización. Entonces podrías tener 2 entre
24, o un gran número de organizaciones,
no exactamente 2 entre 24. Pero tendrías un gran
número de organizaciones, pero entonces solo obtendrías 256. Ahora, la organización que
reparte Estos números… hay una organización en particular
.

En realidad,
en aquel momento ni siquiera era una organización. Fue así: Jon Postel en UCLA, un tipo
estaba repartiendo estas cosas, y luego se convirtió en
una organización. Jon Postel es genial. Quiero decir, él era realmente… los aspectos sociales de cómo
manejó esto fueron notables. Así que no
los repartió al azar. Y nadie quería esto,
todos querían esto. Quiero decir, todos querían
eso, pero consiguieron esto. Y esto era 16 y 16. Entonces obtendrías 2 de
las 16 direcciones y obtendrías tus identificadores de 16 bits
para estas áreas. Y con el tiempo, a medida que
Internet creció, sucedió lo obvio. Porque la cosa es que esto es
como la historia de Ricitos de Oro, ¿no? Esto es demasiado
grande y esto es demasiado pequeño. Esto es perfecto. Y muy pronto, había entre
2 y 16 organizaciones en Internet y se nos acabó.

Literalmente, se quedaron sin
direcciones de clase B. Y en ese momento,
a principios de los años 90, se dieron cuenta de que esta
rígida descomposición en direcciones de esta forma
simplemente no era del todo correcta. Porque lo que
realmente querías era un sistema en el que permitieras… quiero decir, esta idea de
una identificación de organización no tenía sentido. ¿ Qué pasa si necesito de
2 a 12 direcciones? Hoy
tendrías que darme 2 elevado a 16, lo cual es ridículo. Entonces, si necesitara 2
entre 12, bueno, ¿ cómo se hace eso? Bueno, podría obtener cuatro 2 entre
8, pero si esos 2 entre 8 no fueran contiguos,
entonces esos enrutadores en medio de
Internet no podrían tratarlos como
uno solo y tener el mismo prefijo para definir toda la red. . Tendrían que tener cuatro
entradas diferentes, lo que frustraría el propósito de
utilizar este tipo de enrutamiento basado en áreas. Así que todo
fue un desastre.

Entonces se dieron
cuenta de este problema. Y se les ocurrió una
forma más sensata y sensata de abordar este problema. Hablaré de eso
probablemente el lunes. Mientras tanto,
en la década de 1980, este crecimiento se estaba
produciendo con bastante rapidez. Y empezaron
a organizarse. Vint Cerf, que
entonces estaba en ARPA, nombró a Dave Clark, que era
investigador científico senior y profesor en el MIT, para
el puesto de arquitecto jefe de Internet. Y jugó un papel decisivo al
escribir y reunir a mucha gente para
organizar cómo se lleva a cabo este tipo de estandarización. Entonces surgió una organización
llamada Internet Engineering Task Force, o IETF. Esa es la organización
que determina y establece los estándares para los protocolos
que se ejecutan en Internet. En 1982
sucedió algo realmente importante. Esta idea de esta comunidad
con la comunidad de arquitectura de Internet recibió un verdadero impulso cuando
el Departamento de Defensa de EE.

UU. examinó varias formas y
formas competitivas de diseñar redes, y algo sorprendente es que
el Departamento de Defensa decidió elegir el
estándar abierto en lugar de algún estándar propietario. estándar, en
lugar de algún estándar cerrado que sea potencialmente más seguro,
aunque en realidad no lo sea. Sorprendentemente,
dijeron, vamos a estandarizar
todos nuestros sistemas en TCP/IP. Y el Departamento de Defensa… No sé si todavía es
así, probablemente lo sea. Pero en aquella época
era un gran consumidor de tecnología de la información.

Todavía lo es, sólo que
otras personas también lo consumen. Pero en aquellos días
probablemente era el consumidor dominante de tecnología de la información. Y lo estandarizaron
y otorgaron un contrato al
grupo de sistemas informáticos de Berkeley para construir TCP/IP, que para
entonces se había convertido en estándar. Y hubo muchas
implementaciones, pero dijeron: tomen Unix y
construyan la pila TCP/IP. Y Berkeley hizo muchas
cosas interesantes con él, incluida
la creación de Sockets Layer.

Surgieron
lo que hoy se conoce como implementaciones de código abierto
de la pila TCP. En 1983, el MIT creó
el Proyecto Athena, que fue el
primer sistema de red de área de campus del mundo. Y trabajaron mucho
en cosas como sistemas de archivos, sistemas de archivos distribuidos y
el esquema de autenticación Kerberos , y muchas
ideas importantes de esta red. Y también ejecutaron
la pila TCP/IP. No ejecutaron
nada propietario. En 1984
se introdujo el sistema de nombres de dominio. Para aquellos que
no lo saben, cuando escriben
www.mit.edu, algo lo convierte en una dirección IP. Y luego su pila de red
se comunica y envía paquetes a través de TCP o UDP o
estos protocolos a esa dirección. ¿ Cómo se convierte esto? Bueno, de nuevo, originalmente esto
se mantenía en un archivo.

Este archivo se llamó host.txt. Y lo creas o no, la
forma en que funcionaría este archivo era que todas las noches, creo que
en medio de la noche, cada computadora en
Internet descargaría este archivo desde una computadora
que estaba ubicada en algún lugar de la costa oeste. Literalmente,
obtendrías un archivo host.txt. Y, por supuesto,
podrías hackearlo. Podrías hacer lo que quieras. Y la suposición, por
supuesto, era que nadie lo estaba… Me dijeron que
en los primeros días, cada computadora tenía una
contraseña de root que estaba vacía, o estas computadoras en el MIT tenían
una contraseña de root que estaba vacía.

Todos podrían iniciar
sesión en cualquier computadora. Y se
confiaba plenamente en todos, lo cual creo que
ya no es cierto. Pero descargarías este
archivo host.txt todos los días. Y comenzó… a medida que
Internet crecía muy rápido… Sabes, Internet ha
estado creciendo entre un 80% y un 90% al año, no sólo en los últimos
años, no sólo en los años 90. Ya sabes, ha estado creciendo entre un
80% y un 90% anual desde 1980. Así que se trata de
esta increíble lágrima. Y de todos modos, esta idea de
descargar un archivo todas las noches simplemente no es una buena idea.

Entonces crearon el
sistema de nombres de dominio. Tuvieron que crear… la NSF, que era la
Fundación Nacional de Ciencias, entró en acción. Y se convirtieron en la
primera columna vertebral de Internet. Y la columna vertebral… la idea es
que esta es una columna vertebral que conecta todas estas
redes diferentes, en particular, todas las
universidades juntas. Por eso también eligieron
TCP/IP como estándar. Y nuevamente, la
lección importante aquí es que lo eligieron como
estándar porque era abierto, porque estaba muy claro que
estas implementaciones estaban disponibles,
eran gratuitas, todos podían contribuir y
todos podían superarlas y mejorarlas.

y
no se poseía ninguna tecnología patentada . Así que lo que haré aquí
es parar. Lo retomaré en
este punto el lunes, hablaré sobre el control de la congestión
, cómo secuestrar rutas y cómo enviar spam
sin ser detectado, y luego hablaré sobre el
futuro de las redes y las comunicaciones..

As found on YouTube