El siguiente contenido se
proporciona bajo una licencia Creative Commons. Su apoyo ayudará a que
MIT OpenCourseWare continúe 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: Así que esta es la
penúltima lección del trimestre. Entonces, lo que voy a hacer
hoy es en unos 45 minutos, darles una historia rápida
de Internet desde … Comenzaremos a fines de la década de
1950 y luego llegaremos a la actualidad. Y luego, la próxima vez,
el lunes, concluiré esta clase primero
haciendo 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 voy a estar seguro de ello. Y hoy, la idea
es tratar de conectar algunos de los temas que hemos
estudiado en clase hasta ahora con esta historia.
Por supuesto, no vamos
a ser capaces de hacerlo todo. Así que la historia hasta ahora en
términos de la historia , hay que suponer que vamos a
empezar en 1959 o 1957. Y en este momento, la historia
de los sistemas de comunicación ha tenido muchos éxitos. Y un tema común
es que está la tecnología que
surge, tiene éxito, trata de conquistar el 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 lo mata.
Entonces, la primera
tecnología de red exitosa fue el telégrafo eléctrico. Y el telégrafo eléctrico
fue hecho por varias personas diferentes: Wheatstone y Cooke construyeron
un telégrafo eléctrico en Inglaterra, Morse y
Vail construyeron uno en los EE. UU. 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 y así sucesivamente. Y luego
surgieron otras tecnologías. Ahora, este tipo de
historia sigue repitiéndose. Y así, en la década de 1950,
el actor dominante en el área de las comunicaciones
es la red telefónica. Así que tenemos Bell Telephone
Company, y en los EE. UU. , domina. Hay compañías telefónicas equivalentes
en otros países. Y tienes esta
red telefónica masiva y asombrosa.
Y cada vez más, muchas
personas tienen teléfonos. En el lado inalámbrico,
no hay un sistema telefónico inalámbrico en la década de 1950. Pero lo que tenemos es la radio, la transmisión de radio y la
transmisión de televisión, y algunas compañías muy poderosas
que poseen espectro inalámbrico para ofrecer televisión y radio. Entonces, la historia comienza
a fines de la década de 1950. Y en 1957
sucedió algo importante: se lanzó el Sputnik. Y eso hizo que Estados Unidos supusiera
que se estaba 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
una gran cantidad de investigación y desarrollo aplicados. Paul Baran, en muchos sentidos,
es 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 las personas 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 tratar de construir
lo que llamó una
red de comunicación sobreviviente. 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 perseguir. Lo que estaba tratando de construir
era simplemente comprender cómo se diseñan
las redes de comunicación que le permiten manejar las fallas. Y gran parte de la
red telefónica de entonces era un
tipo de estructura muy centralizada donde tendrías una red
que tenía muy poca redundancia incorporada. Y tendrías muchas de estas
topologías centrales en forma de estrella. Y el problema, por supuesto,
cuando conectas estas estrellas entre sí, y estas
piezas con forma de estrella se conectan con otras piezas con forma de estrella,
es que es mejor que hagas estos puntos aquí,
estos nodos o interruptores aquí, extremadamente,
extremadamente confiables, y aquellos enlaces que los
están conectando a estas otras
estructuras centrales.
Porque de lo contrario, la
falla de esas cosas mataría al sistema. Y Bell Telephone
Company realmente entendió cómo construir
estos conmutadores muy caros, muy, muy fiables,
pero eran muy, muy, extremadamente caros. El otro problema es, y
volveremos a esto más tarde hoy, es que una
red telefónica es una gran red. Pero es compatible con exactamente
una aplicación. La aplicación es que
levantas el teléfono y hablas. Es muy difícil,
a primera vista , imaginar cómo una
red telefónica haría un gran trabajo para soportar
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 fundamentalmente, en esos días, un
problema de tolerancia a fallas. Y la forma en que lo
manejaron fue construir
componentes extremadamente confiables. La idea de Paul Baran, en la
que otras personas habían estado
pensando y jugando, fue que observó que,
y en esos días, la red telefónica
era en gran parte analógica. La telefonía digital
no estaba realmente allí. Y las computadoras digitales
apenas comenzaban 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 certeza 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 en el que puede o no estar funcionando, ya medida que aumenta el ruido
o se produce alguna falla , comienza a
ver mucho ruido. Y está distorsionado,
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 este es el
tema rector fundamental para los sistemas informáticos a gran escala
de finales de la década de 1950. Quiero decir, esto va
todo el camino hasta cómo funcionan Google, Amazon, Facebook
o cualquiera de estos grandes centros de datos. Cualquiera de
esas computadoras es muy poco confiable en
relación con lo que podrías hacer si
invirtieras mucho dinero para construir una
computadora muy confiable.
Pero el conjunto
es altamente confiable. Y hacer eso 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 fines de la década de 1950
y principios de la de 1960 , dijo que con
la computadora digital ahora se podía comenzar a construir redes de
comunicación altamente confiables a partir de
componentes poco confiables. Y entonces articuló
esta idea de que puede conectar estos
conmutadores o nodos en estructuras altamente redundantes. Y si tiene un
flujo de datos para enviar , realmente no tiene que
elegir una ruta particular a través de la estructura.
Podrías tomar ese
mensaje y dividirlo en diferentes partes y
enviarlas en diferentes direcciones. E incluso si elige
enviarlos todos en una dirección, si ocurriera una falla,
estos interruptores podrían
comenzar a mover los datos en diferentes direcciones, lo que
significa que ya no pensará en una comunicación
como un gran flujo que debe
enviar. de una manera, pero puedes empezar a pensar
en dividirlo en estas diferentes piezas. Ahora, como con muchas de estas
ideas, es raro encontrar… a veces sucede, pero es
raro encontrar exactamente una persona en el mundo pensando en ello. No importa cuán
innovadora sea 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 envía a través de
la red que son unidades atómicas de entrega. Este término fue acuñado por
Donald Davies en la década de 1960. Ahora, todo esto fue
maravilloso y una especie de abstracciones teóricas. Pero, ¿cómo se empieza
a pensar en algunos principios de diseño para construir
redes de comunicación? En particular, ¿
cómo lidia con el problema de que estos enlaces
se junten en un conmutador y trate de compartir
los enlaces que salen de un conmutador de una manera
que permita el tráfico de diferentes conversaciones
al multiplex en el mismo enlace? En retrospectiva, la idea de tener una cola
en un interruptor 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
construir una cola y ahora comenzar a analizar es un
resultado bastante innovador. Una vez más, hubo
muchas personas involucradas. Pero probablemente las
principales contribuciones procedieron de una persona
llamada Len Kleinrock , 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 podría usar la
teoría de colas para analizar y modelar redes de comunicación. Ahora, más o menos al
mismo tiempo, de nuevo en el MIT, Licklider
y Clark escribieron un artículo realmente interesante. De hecho, vale la pena leerlo ahora. Quiero decir, es hace 50
años, pero es interesante. Tienes que volver y
pensar, esto fue en un momento en que la gente realmente no tenía
esta idea de que la gente podía sentarse frente a las computadoras. Se usaron computadoras
para tal vez contar votos. Sospecho que
se equivocan más hoy que en aquellos días. Pero las computadoras se
usaron para contar votos , se usaron para ayudar
con el Censo de los Estados Unidos.
Pero nadie pensó en las personas
sentadas frente a las computadoras. Y escribieron este maravilloso
artículo llamado "Comunicación hombre- computadora en línea". Supongo que en aquellos días, ya
sabes, hombre significaba gente. Así que de todos modos,
escribieron este artículo. Y, de hecho, Licklider
tuvo esta visión de lo que llamó una
red galáctica que se extendería por todo el mundo
y más allá, lo cual fue… a 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 las 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 por ahí. Y la gente simplemente tenía
terminales remotas, e iniciaba sesión y
tenía estas grandes computadoras que podía usar.
Pero entonces
tendrías buenas interacciones en tu propia terminal. De eso se trataba ese
papel. 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 compartir
computadoras remotas. Así que Internet…
ARPANET fue el precursor de Internet. Y comenzó no porque
quisiéramos construir una red de comunicación para prevenir, para que funcionara cuando
hubo una guerra nuclear o cualquiera de estos grandes desastres. De hecho, tenía un
objetivo muy concreto : permitir que las personas (las computadoras
eran muy, muy caras), permitir que las personas, sin
importar dónde estuvieran , pudieran aprovechar el
poder de la informática costosa lejos y hacer
que pareciera en la medida de lo posible como si las
computadoras estuvieran contigo. Esa fue la visión: bastante convincente, pero simple. Y decidieron,
por muy buenas razones , elegir la conmutación de paquetes. Las razones principalmente
tenían que ver con la economía. Esta era una red
que se proponía para una aplicación
cuya utilidad era cuestionable.
Y la idea de invertir
grandes 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. Así que dijeron, saben
qué, ARPANET va a ser una red de conmutación de paquetes. Volveré sobre esto
más tarde, pero, por supuesto, las
compañías telefónicas como AT& T pensaron que
era una idea terrible y aprovecharon todas las oportunidades
para ridiculizarla. Se creó ARPANET y
algunos equipos ofertaron por el contrato.
Y BBN… Bolt,
Beranek y Newman, eso 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, construir 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 que llamaron IMP, o el
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 necesitaba algo
para hacer el cálculo tanto de las tablas de enrutamiento
como de cada paquete. Aparecería cada
paquete, y tendrías que calcular algún
tipo de suma de verificación en él. Y tendría que hacer esta
tarea computacional de descubrir cómo reenviar ese paquete.
Y eso se
consideraba demasiado trabajo para tener en una
pequeña computadora real. Entonces, en realidad tuvieron que construir
una pieza de hardware separada que conectarías
a tu computadora, y probablemente
sería igual de grande. Y puedes ver
la imagen aquí. Estos IMP estaban conectados a
computadoras más grandes o computadoras del mismo tamaño. Y estos hicieron la creación de redes. Quiero decir, hoy, todas esas
cosas, un millón de veces más están pasando en este dispositivo. Pero en el
pasado, así era. Así que ganaron este contrato de
procesador de mensajes de interfaz llamado IMP. Y cuando gana un
gran contrato federal, a menudo, su congresista
o senador le escribe. De hecho, es divertido
porque muchos de nosotros recibimos… durante un período de tiempo antes de las
elecciones al Senado, algunos de nosotros recibimos correos electrónicos, cartas
de Scott Brown felicitándonos por haber ganado una
pequeña propuesta de la NSF.
No sé si otras
personas aquí lo entendieron, otros profesores aquí lo entendieron. Pero es como
en esos días, si ganabas un gran contrato,
recibías dinero, recibías una carta
de tu congresista. De hecho, Ted Kennedy, quien
era el 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 interreligioso. Supongo que
si realmente hubieran construido eso, podría haber sido
una contribución más útil a la paz mundial. Pero todo lo
que consiguieron fue el contrato para construir el
procesador de mensajes de la interfaz… sólo detalles. De todos modos, este equipo era
un equipo bastante notable. Construyeron el primero, no construyeron el
primer programa de correo electrónico. Eso se hizo
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 para usar, si usa el símbolo @.
Pero había 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. Así que 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 fue la
imagen de ARPANET en 1969. Esto se convirtió en Internet. Hay una evolución continua
desde esta imagen de cuatro nodos hasta Internet en la actualidad. Y en 1969, finalmente
conectaron inicialmente dos y luego cuatro nodos. Y tenían que hacer la
primera demostración. Y para escuchar a Len
Kleinrock contar la historia, esta fue su historia.
Él dice que su grupo en UCLA
trató de iniciar sesión en una computadora en SRI, que está en Palo Alto. Y él dijo, establecimos una
conexión telefónica entre nosotros y los muchachos de SRI. Escribimos la L y
preguntamos por teléfono, porque tenían que verificar
si funcionaba, así que tenían el teléfono para verificar. 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. Y escribimos
la G, y el sistema colapsó. Pero ya sabes,
tienen algo que funciona. Y, por supuesto, hay
una buena declaración aquí. Ya sabes, mucha gente se
preocupa por las optimizaciones de rendimiento. Pero la optimización más importante
en un sistema es pasar de no
funcionar a funcionar. Y el hecho de que algo
funcionó es extremadamente importante. Muy poco tiempo después,
conectaron la costa este, un grupo de computadoras y
organizaciones de la costa este con la costa oeste,
entre ellas el MIT. Así que había un equipo
en BBN, y muchos de ellos eran del MIT.
Entonces, MIT, BBN, Harvard y
Lincoln Labs de este lado, y MITRE se
conectó en Carnegie , hoy es la
Universidad Carnegie Mellon, creo que en ese momento se llamaba
Carnegie Tech, la Universidad de Illinois, y luego
largas filas. a través del país. Había un grupo de
Utah y en California. Ahora, ¿cuáles eran estos enlaces? Alguien quiere adivinar: estos
enlaces en todo el país, o entre Harvard y el
MIT, o allá, ¿crees que realmente
fueron y colocaron nuevos cables y colocaron estos cables? ¿Qué 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 gustaba… Quiero decir, en ese
momento, pensaron que esto era solo una broma académica.
Pero con el tiempo, quedó claro
que esta red subyacente se estaba utilizando para
hacer algo diferente. Y entonces hay
una red superpuesta que se construye, y las superposiciones
aparecen una y otra y otra vez. Es solo que no son
tan hostiles en estos días. Otro ejemplo de una
superposición es BitTorrent, o cualquier aplicación punto a punto:
Skype, todas estas cosas
son superposiciones que se construyen 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 ir a
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. Así que este único
enlace en ARPANET es en realidad muchos, muchos
enlaces con muchos conmutadores, y quién sabe lo caro que
es subyacente en la red telefónica. Pero todo lo que tienes que hacer
es pagar una cantidad de dinero a la red telefónica y
hacer una llamada o lo que sea, y puedes
verlo como un solo enlace.
Y puedes hacer lo mismo
en Internet. Ahora, este protocolo, el protocolo de
enrutamiento que usaron, era un
protocolo de enrutamiento de vector de distancia. En realidad, ni siquiera era tan
sofisticado como el que estudiamos. Pero era un
protocolo de vector de distancia. Y el vector de distancia fue
el primer protocolo de enrutamiento que se usó en una red de
conmutación de paquetes. Y continuó en
ARPANET durante muchos años. Continuaron
ejecutando este protocolo. OK, continuando, pasamos
de las redes de paquetes básicas a este problema de
interconexión de redes.
Y eso pasó por
una serie de demostraciones. Entonces, uno de ellos fue que tuvieron
una gran conferencia en 1972. Y estaban demostrando el
ARPANET de conmutación de paquetes simple. Y funcionó muy bien
excepto cuando se lo demostraron a un equipo de AT&T y
no funcionó en absoluto. Y de hecho, hubo
artículos de noticias que se escribieron. Y algunas personas escribieron que
esta era una buena red, algunas personas 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
muy buen equipo construyendo 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 sucede con
estas cosas, el ganador… ARPANET se convirtió en Internet,
y así todo el mundo se olvidó de todo lo demás. Pero CYCLADES en realidad
ideó 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, estaba en esta red francesa. Ellos originaron el
protocolo de la ventana deslizante. Parece obvio, pero no lo es. Puede ver que hay
muchas sutilezas en la forma en que construye
dicho protocolo y cómo argumenta que es correcto. El primer
protocolo de ventana deslizante fue en CYCLADES.
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 el
tiempo entre computadoras. Y tenían una serie
de ideas interesantes en esta red. El trabajo no solo se estaba
haciendo en el área amplia. En 1973, ethernet fue
inventado en Xerox PARC por un equipo que incluía a
Bob Metcalfe , otro alumno del MIT. Eso fue inspirado por 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 contención
es una idea nueva. De hecho, usaron el
método de probabilidad. El estándar de Ethernet evolucionó
a finales de los años 70 y 80 para usar la
ventana de contención que ahora conocemos. Y esa misma
idea de ventana de contención y sentido de operador se usa en Wi-Fi. Para que pueda dibujar
esta corriente de ideas a través de las 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 portadora. Debido a que Ethernet hoy 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 usa 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 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.
Usan el MAC 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 más antigua , aplicarla a un nuevo
contexto y luego modificarla es algo que
funciona bastante bien. Porque significa que
puede aprovechar algo que ya existe y
comenzar a realizar cambios en él. Y con el tiempo, se ve
completamente diferente. Ahora, el gobierno de EE. UU.
y DARPA… ARPA estaba financiando ARPANET. Pero había empresas
y otros grupos de investigación en la mezcla aquí.
Y en esos días
no estaba muy claro qué iba a ganar. Y todos estaban
investigando para encontrar diferentes formas de
conectar redes. Y Xerox tenía un
sistema llamado PUP. No sé lo que significa. Creo que significa PARC– Xerox PARC, Palo
Alto Research Center, PARC-algo de protocolo. No sé qué es la U. Y en cierto modo, había
muchas ideas técnicas en el sistema Xerox
que en realidad eran probablemente mejores
en términos técnicos de ARPANET y TCP/IP. Pero era propietario, mientras que
TCP/IP estaba completamente abierto. Y abierto significaba que
no tenías que pagarle a nadie, no tenías que obtener
el permiso de alguien 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í afuera,
abierto y libre. Hay mucho que
decir de ese modelo. Porque para que una
red tenga éxito , debe reducir
la barrera de entrada para que todos puedan participar
e implementarla.
Y si hace que los
protocolos de red sean propietarios, por lo general no
beneficia a nadie. Así que ahora, creo que las empresas
han comenzado a darse cuenta de eso. Entonces, todos
entienden que desea 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, puede obtener una
ventaja comercial de la implementación, pero no obtiene ninguna
ventaja comercial al mantener un protocolo cerrado. Hay excepciones
a esta regla. Como, Skype es una
excepción a esta regla. ¿ Pero quién sabe? En 5 o 10 años,
sospecho que 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, se arraigó esta idea de
que ahora realmente comienza a conectar muchos
tipos diferentes de redes, redes que se ejecutan
en diferentes organizaciones . Y este era el
problema de interconexión de 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 .
Así que estaba la
red Aloha en Hawái. Había gente construyendo
redes conmutadas de paquetes a partir de ethernet. En el MIT y 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 así, 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 había un
único protocolo para hacerlo. Entonces, ethernet tenía…
en el pasado, cuando comprabas una
tecnología ethernet de, por ejemplo, Digital
Equipment o Xerox o una de estas compañías
, no solo obtenías ethernet.
Obtendrías el protocolo ethernet MAC. Entonces obtendría algún tipo
de comunicación de red, capa de red entre los
diferentes dispositivos de Ethernet. Y obtendría
algo llamado EFTP, que era un
protocolo de transporte de archivos de Internet.
Entonces obtendrías
aplicaciones a su alrededor. Así que imagínese ahora, está
comprando una cosa de red. Y no puede ejecutar
sus propias aplicaciones , obtiene una pila de todo. Y obtienes una caja,
y solo puedes usar lo que
te haya dado el vendedor. 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 le gustaría
es tener una red donde la gente pueda venir e inventar
sus propias aplicaciones y ejecutar sus propias
aplicaciones en ella. Pero ahora necesitaba
una forma de comunicarse entre estas
diferentes redes. Entonces como haces esto? Así que este fue un gran
proyecto 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 conseguir
una comunidad de otros.
personas juntas en la construcción del 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 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 una comunicación de máximo esfuerzo. Porque no podemos asumir que
todas las redes garantizarán la entrega. Hay algunas redes que
pueden garantizar la entrega en orden, pero no puede exigir eso. Y lo que dijeron fue
, diseñaremos esta red con estas cajas que
llamaremos puertas de enlace. Y estas puertas de enlace
traducirán entre diferentes
protocolos de red. Y en un
alejamiento bastante radical de la
red de 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 red nacional .
Así que es una
idea bastante simple: tienes tu propia red interna. Esto podría ser un ethernet, esto
podría ser algún tipo de red Aloha o lo que sea. Pero tiene estas puertas de enlace
aquí que se sientan y traducen entre estos
diferentes protocolos. Y conocemos las cosas como … ahora sabemos que lo que hicieron
fue una muy buena decisión, que lo hicieron para
que todas estas puertas de enlace estén de acuerdo en un protocolo. Y el protocolo
que estandarizaron… inicialmente se equivocaron,
pero a finales de los 70, se dieron cuenta de que ese
protocolo se llamará 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 sobre
lo que sucede cuando reenvía un paquete. Tiene una
tabla de búsqueda y enrutamiento que busca la dirección IP
y luego decide el enlace. Y eso es todo lo que
tienes que aceptar. Entonces, para estar en Internet,
todo lo que tiene que hacer es: una red debe
admitir el direccionamiento 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 tiene que hacer, tanto que la gente
ha escrito estándares sobre cómo puede enviar el
protocolo 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 pedazos de papel, y
había algo buscándolos y enviándolos. Así que no se necesita mucho
para estar en Internet. Entonces Cerf y Kahn comenzaron a
diseñar la red. Y escribieron en
su documento original que necesitaba
identificar la red en la que se encuentra , y dentro de la red,
un host en el que se encontraba. Y dijeron que la elección
de identificación de red permite hasta 256
redes distintas. Como, ¿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 menos de 10 años,
y puede que no haya sido 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 , aún así cometieron un error. Decidieron que
las direcciones IP de paquetes de 32 bits son suficientes. Y nos hemos quedado sin. Literalmente nos quedamos
sin direcciones IP en este momento. Tenían estas puertas de enlace
que traducían, y tú ejecutabas el
protocolo de interconexión de redes o IP.
Entonces, en la década de 1970, esta
idea de interconexión 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á detenidamente en 6.033. Es uno de estos
documentos que estudiará dos o tres veces,
porque seguirá regresando, porque estos conceptos
son muy importantes. Se llama "Argumentos de extremo a extremo
en el diseño de sistemas" por Saltzer, Reed y Clark. Tienen muchos
ejemplos, pero la esencia de los argumentos de extremo a extremo
es que si tiene un sistema , digamos una
red, y quiere poder
diseñar una red, y tiene que tomar una
decisión de qué características pones en la red? Los argumentos de extremo a extremo
dicen que solo se incluyen funciones en
la red que son absolutamente esenciales para
el funcionamiento del sistema. Cualquier otra cosa que no sea crucial
para el funcionamiento del sistema, se la dejas a los puntos finales.
Entonces, si piensa en la
confiabilidad como un objetivo , como 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 necesaria, por ejemplo, si está
entregando un archivo, pero no si está entregando
una transmisión de video o hablando. Porque no todos los bytes
necesitan llegar allí, lo que significa que no
coloca esa funcionalidad dentro de la red.
Deja la función
de lograr la 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
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 concentrador de red. Como, eso es lo
que haría 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 tratamos de
diseñar nuestra red para que entre el
punto de acceso Wi-Fi y su computadora , produzcamos
una transmisión perfectamente confiable. Si hicieras eso
, entonces significaría que tendrías retrasos realmente largos. Y estaría proporcionando
esa función para aplicaciones que no la necesitan. Si quiero una
aplicación a través de la cual me gustaría enviar
los bytes, si funciona, genial,
si no lo hace, entonces haré otra cosa, ese es
un mal diseño de red. Desafortunadamente,
existen redes reales hoy en día que no obedecen este principio. las redes celulares a
veces son problemáticas, como Verizon o
AT&T o algo así. Encuentra allí en
datos reales que hay largas demoras en estas redes. Porque entre la
estación base celular y su teléfono , han decidido
proporcionar algo que parece un TCP altamente confiable.
Es una especie de mal
diseño de red, 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, la razón por la cual la
conmutación de paquetes y esta división de 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 una
aplicación para la cual el diseño de la infraestructura de la
red de Internet sea óptimo. Si quisiera construir una
red para admitir voz , construiría una
red telefónica. No construirías una red
que se vea así. Si quisiera construir una
red para distribuir datos de televisión a transmisiones de televisión
a un grupo de personas , no construiría Internet. Si quisiera
construir una red que quisiera apoyar a
Facebook y nada más , probablemente no
construiría Internet. Pero si desea una red
que admita todas esas aplicaciones razonablemente bien,
incluidas las aplicaciones que no puede imaginar hoy, este
diseño es una muy buena idea porque es muy minimalista. No hay casi nada
que la red haga. Lo deja todo
para el punto final. Así que, de hecho, diría que
la lección más útil, que aplicará una
y otra vez…
Quiero decir, digamos que
va a trabajar en una empresa o trabaja en algún tipo
de proyecto de investigación. Y en varias etapas
del proyecto, hay debates interminables
sobre lo que debe hacer, si vale la pena hacer
algo o no. Y la lección más importante
que 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
se equivoca en la aplicación de lo que
sea que esté creando, si es simple y
minimalista, probablemente podría girar
y usar lo mismo para esa otra aplicación. Así que hay un famoso
conjunto de citas aquí. Uno siempre debe diseñar
sistemas para la flexibilidad porque, naturalmente,
nunca, casi nunca se sabe cuándo su diseño, todos
tienen estos casos de uso en mente. Pero seamos realistas, cuando
estás en las primeras etapas de un proyecto, en
realidad nadie lo sabe. Y casi
siempre te equivocarás. Por lo tanto, es importante
diseñarlos para la flexibilidad, no para el rendimiento, no para una
gran cantidad de funciones, solo para ser flexibles
y lo mínimo necesario para hacer el trabajo en función de
lo que cree que es necesario.
Y por lo general significa
hacer eso incluso si eso significa sacrificar el rendimiento. Como dije, la
mejora más importante en el rendimiento del sistema
es hacer que funcione. Todo lo demás es secundario. Así que aquí hay una buena
cita, no sé si… ¿ Algún hablante o lector de francés? ¿Sí? PÚBLICO: [EN FRANCÉS] PROFESOR: Sí, lo sé. Sólo dímelo en inglés. [RISA] Lo suficientemente bueno, está bien. PÚBLICO: 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, muchachos,
cada uno de ustedes va a entrar en
el mundo real, ya sea en una nueva
empresa o en una gran empresa donde está 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é es útil
cuando diseñas algo. Y es muy
importante comprender que debe hacer lo
mínimo para que funcione.
Y es una muy,
muy buena idea: menos es más. Tengo una manera muy simple
de pensar en ello. Les digo esto a mis
alumnos repetidamente: en caso de duda, simplemente déjalo fuera. Si no está seguro de si lo
necesita o no, no lo haga. 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.
No puedo ayudarte allí. De acuerdo, en la década de 1980,
Internet comenzó a crecer. Y la forma en que
quería manejar el crecimiento era esta
idea simple pero brillante llamada direccionamiento topológico. Así que 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 red tenía
un identificador de red: una dirección IP o algún tipo
de nombre para ese nodo. Entonces, en la forma en
que 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, tendrías un
identificador de dos fases.
Tendría una especie de
identificador de red o un identificador de organización. Entonces, el MIT tendría
un conjunto de 8 bits, y luego tendrías
un conjunto de otros bits aquí que comunicarían dentro del
MIT lo que significaba ese número. Entonces, de manera abstracta,
estos números no significaban nada
en Internet global. Esto podría ser simplemente
110111 y algo. Y luego tendrías otra
secuencia de otra cosa. Esa era la idea básica. Ahora, en las redes
que estudiamos hasta ahora, ni siquiera tendríamos esto. Cada nodo de la red
solo tendría algún 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 en
la red, para reenviar paquetes
a usted oa 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.
Entonces, tendría
una tabla de enrutamiento que sería
esencialmente una entrada para cada host en la
red, que no se escala. Es 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. Lo 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. Así que aquí hay una vista muy simple y
abstracta de esto. Internet solía adoptar
esto de alguna manera aproximada. Pero esta es la idea conceptual. Usted diseña la
red en áreas. Entonces, 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 por ethernet , ethernet tiene una dirección IP.
Obtiene una dirección IP
en virtud de conectarse a un conmutador aguas arriba. La red Wi-Fi M
tiene una dirección IP. Si uso el 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, ¿de acuerdo? 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 como de costumbre y
reenvío como de costumbre. Así que todos estos nodos tienen… podrías
construir subáreas recursivamente. Pero si no lo hiciera,
cada uno de estos tipos tendría una entrada para
todos los otros nodos aquí. Y dentro de estas áreas,
tendría enrutadores fronterizos. Y estos
enrutadores fronterizos solo tendrían entradas para
las otras áreas. Entonces, si quisiera enviar
un paquete desde el área 1 al área 4, lo que
haría sería enviar un paquete a uno de sus enrutadores fronterizos.
Y ese enrutador de borde
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 tiene una buena jerarquía
donde dentro de la red , solo sabe cómo ingresar
su red y hasta la frontera. Las fronteras
saben entrar, y las fronteras
saben llegar a otras fronteras. Pero la frontera de
un área no sabe cómo entrar en
ninguna otra red. Ahora puede ver que puede
aplicar recursivamente esta idea y comenzar a escalar
el sistema de enrutamiento. Ahora, en Internet, lo que
terminó sucediendo fue que, bueno, tenían que aplicar
esta jerarquía de áreas.
Y muy pronto, las organizaciones
comenzaron a decir, bueno, tengo un área grande
y tengo un área pequeña. Entonces, ¿qué tan grande
haces esta cosa? En el Internet muy antiguo,
estos tenían 8 bits de largo y estos eran el
resto de la dirección. Si tiene 8 bits,
solo puede tener 256 organizaciones. Y aunque Kahn y Cerf
pensaron que eso era suficiente, claramente ese no fue el caso. 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? Así que lo que dijeron
fue, muy bien, tengamos tres
clases de áreas. Para los realmente grandes,
tendremos direcciones de clase A.
Luego, para los
chicos medianos, tendremos la clase B. Y para los
chicos pequeños, tendremos la clase C. Lo que eso significa es
que vamos a tener la clase A que permite que una
organización tenga hasta 2 a 24 direcciones. Porque la clase A se
identifica por 8 bits. Entonces obtienes 24,
que es 32 menos 8. Así que el MIT fue bastante inteligente.
Decidieron que irían y, ya sabes, estaban
allí, estaban investigando mucho sobre redes. Así que dijeron,
vamos a conseguirnos una de estas direcciones de clase A
porque somos una gran universidad y tenemos muchas computadoras. Y probablemente era el
caso de que en ese momento, el MIT probablemente tenía más computadoras
que la mayoría de los otros lugares.
Entonces, incluso hasta el día de hoy,
mantienen esta dirección, que era 18 puntos estrella,
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,
cualquiera que sea el 18, 000,
me equivocaré, pero hay un número de
8 bits para 18. De todos modos, fueron
y lograron esto. Ahora, nadie quería la clase
C porque las clases eran… se podía obtener de 2
a 8 direcciones porque la clase C se
definió como una base de 24. Así que tienes 24 bits para
definir la organización. Entonces, podría tener 2 a
24, o una gran cantidad de organizaciones,
no exactamente 2 a 24. Pero tendría una gran
cantidad de organizaciones, pero solo obtendría 256. Ahora, la organización
repartiendo estos números– hay una
organización en particular. En realidad, ni siquiera era
una organización en ese momento. 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 fue 16 y 16. Entonces obtendrías 2 a
las 16 direcciones, y obtienes 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 como, es demasiado
grande, y esto es demasiado pequeño. Esto es correcto. Y muy pronto, había de
2 a 16 organizaciones en Internet, y nos quedamos sin. Literalmente, se quedaron sin
direcciones de clase B.
Y en ese momento,
a principios de los 90, se dieron cuenta de que esta
descomposición rígida en direcciones en 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. Como, ¿qué pasa si necesito
2 a las 12 direcciones? Hoy
tendrías que darme 2 a los 16, que es ridículo.
Entonces, si necesito 2
a 12, bueno, ¿cómo se hace eso? Bueno, podría obtener cuatro 2 a
8, pero si esos 2 a 8 no fueran contiguos,
entonces esos enrutadores en el 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, anulando el propósito de, de
hecho, utilizar este tipo de enrutamiento basado en áreas. Así que todo
estaba un poco desordenado. Así que en realidad se dieron
cuenta de este problema. Y se les ocurrió una forma
más sensata y sensata de lidiar con este problema. Hablaré de eso
probablemente el lunes. Ahora, mientras tanto,
en la década de 1980, este crecimiento estaba
ocurriendo bastante rápido. Y
empezaron a organizarse. Vint Cerf, que
para entonces estaba en ARPA, nombró a Dave Clark, que era
un científico investigador sénior y profesor del 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 la gente hace este tipo de estandarización. Así que había una organización
llamada Grupo de Trabajo de Ingeniería de Internet, 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 muy importante. Esta idea de esta comunidad
con la comunidad de arquitectura de Internet recibió un verdadero impulso cuando
el Departamento de Defensa de los EE. UU. analizó varias formas y
formas competitivas de diseñar redes, y sorprendentemente
para un Departamento de Defensa decidió elegir el
estándar abierto en lugar de algunos patentados. estándar, en lugar
de un estándar cerrado que es potencialmente más seguro,
aunque en realidad no lo es. Sorprendentemente,
dijeron, vamos a estandarizar todos nuestros
sistemas en TCP/IP. Y el Departamento de Defensa … No sé si sigue siendo
el caso, probablemente lo sea. Pero en aquellos días,
era un gran consumidor de tecnología de la información.
Todavía lo es, es solo 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, toma Unix
y construye la pila TCP/IP.
Y Berkeley hizo muchas
cosas interesantes con él, incluida la creación de
la capa de sockets. Salieron con
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 para todo el 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
escribes 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 conviertes esto? Bueno, de nuevo, originalmente, esto
se mantuvo en un archivo. Este archivo se llamó host.txt. Y créalo o no, la
forma en que funcionaría este archivo era que todas las noches, creo que
en medio de la noche, todas las computadoras en
Internet iban y descargaban este archivo desde una computadora
que estaba ubicada en algún lugar de la costa oeste. Como, 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 estaba…
Me dijeron que
en los primeros días, todas las computadoras tenían una
contraseña raíz que estaba vacía, o estas computadoras en el MIT tenían
una contraseña raíz que estaba vacía. Todos podían iniciar sesión
en cualquier computadora. Y se
confiaba completamente en todos, lo que creo que ya no es
cierto. Pero descargaría este
archivo host.txt todos los días.
Y comenzó, a medida que
Internet creció muy rápido. Internet ha
estado creciendo entre un 80 % y un 90 % al año, no solo en los
últimos años, no solo en los años 90. Ya sabes, ha estado creciendo entre un
80 % y un 90 % al año desde 1980. Así que es solo en
esta increíble lágrima. Y de todos modos, esta idea de
descargar un archivo todas las noches no es una buena idea. Así que 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 red troncal de Internet. Y la columna vertebral, la idea es
que esta es una columna vertebral que conecta todas estas
diferentes redes entre sí, en particular, todas las
universidades juntas. Así que 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 aprovecharlo y mejorarlo.
y
no había tecnología propietaria que se tenía. Así que lo que haré aquí
es que voy a 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..