[Introducción] Cuando se habla de Internet, muchas personas tienen en mente varios términos y servicios, pero ¿cómo se diseña y construye Internet? ¿Cuál es la naturaleza arquitectónica de Internet como red? El hermano Shitou y yo tradujimos juntos un libro enorme, "Problemas y soluciones de redes informáticas", pero no muchos amigos lo leyeron con atención y aprendieron algo de él. Recientemente, el hermano Stone recomendó otro artículo https://cacm.acm.org/magazines/2023/2/268956-extracting-the-essential-simplicity-of-the-internet/fulltext. El contenido es conciso y conciso. Me atrevo No guárdelo en privado, compílelo y compártalo con todos.
Hoy en día, Internet proporciona una conectividad ubicua de la que depende la gente. Mucha gente también sabe que el diseño básico de Internet se inventó en la década de 1970 para permitir que las computadoras intercambien datos. Desde su adopción sucesiva en 1983, se ha mantenido esencialmente sin cambios mientras se adapta elegantemente a cambios fundamentales en aplicaciones, tecnologías, escala, alcance y capacidad, convirtiéndose en una parte integral de nuestras vidas.
Siendo una infraestructura de TI tan excelente, ¿cómo es la arquitectura de su sistema?
1. Necesidades esenciales: modelo de servicio de Internet
Todo el software del host debe depender del modelo de servicio de la infraestructura al comunicarse. Por lo tanto, el diseño del modelo de servicio requiere un compromiso entre lo que es mejor para el software anfitrión y lo que la infraestructura puede soportar. Al diseñar un modelo de servicio de transferencia de datos, se deben seleccionar sus unidades de transferencia y garantizar su rendimiento. Dada la naturaleza en ráfagas de las comunicaciones informáticas, es necesaria una pequeña unidad de transmisión para lograr una utilización eficiente de los recursos. Internet utiliza paquetes de bits y los tamaños de paquetes actuales normalmente no superan los 1,5 kb.
Las aplicaciones de Internet tienen una amplia variedad de requisitos de rendimiento de red, que van desde baja latencia (vídeo interactivo o control de bucle cerrado) hasta gran ancho de banda (transmisión de grandes conjuntos de datos) y transmisión confiable (transferencia de archivos). El instinto de ingeniería es apoyar el acoplamiento de estos requisitos con la infraestructura de red para garantizar límites específicos de latencia, ancho de banda y confiabilidad. Sin embargo, Internet debe interconectarse con una variedad de redes de paquetes locales, como inalámbricas y alámbricas, de acceso compartido y punto a punto, muchas de las cuales no pueden garantizar el rendimiento. El mínimo común denominador que estas redes pueden soportar es la entrega de paquetes de "mejor esfuerzo", donde la red intenta entregar todos los paquetes pero no puede garantizar si se entregan los paquetes, cuándo o a qué velocidad.
Por lo tanto, la pregunta fundamental con respecto al modelo de servicio es si es mejor para la tecnología y la red soportar todos los requisitos de la aplicación o acomodar todos los paquetes de datos y solo proporcionar un modesto mínimo común denominador y un modelo de servicio de "mejor esfuerzo". El diseño de Internet ha elegido un enfoque simple, es decir, un modelo de servicio de mejor esfuerzo.
Ahora parece que esta es una mejor opción. En primer lugar, un modelo de servicio más flexible impuso requisitos mínimos a la infraestructura, lo que permitió que Internet creciera extremadamente rápido. En resumen, Internet se puede implementar con gran velocidad y alcance debido a los bajos requisitos de rendimiento. En segundo lugar, la aplicación tiene estrictos requisitos de red que son una continuación de la red telefónica. El sistema terminal inteligente de la red telefónica está conectado a la red inteligente y es totalmente responsable de cumplir con los estrictos requisitos de rendimiento del teléfono, es decir, tarifa fija. Transmisión y transmisión confiable. A medida que las computadoras se vuelven cada vez más poderosas como terminales, las demandas de las aplicaciones de Internet se relajan al diseñarse para adaptarse a diferentes niveles de rendimiento. En la mayoría de los casos, los operadores de red también pueden garantizar un rendimiento razonable proporcionando suficiente ancho de banda, es decir, implementando más enlaces y más rápidos para que la red rara vez se congestione.
2. Abstracción del sistema: la arquitectura de Internet
La arquitectura se trata de la organización de la funcionalidad, no de su implementación. La modularidad es un principio rector de la arquitectura que requiere dividir los objetivos de un sistema en tareas más pequeñas con interfaces limpias. El objetivo de Internet es permitir que las aplicaciones en dos computadoras diferentes se comuniquen, por lo que se puede dividir en dos componentes:
(i) El papel de la infraestructura de red (transmisión del mejor esfuerzo de paquetes de datos entre hosts)
(ii) El papel del software de soporte de red en el host (lo que facilita que las aplicaciones utilicen este transporte de mejor esfuerzo).
2.1 Infraestructura de red
Las tareas de entrega de host a host implementadas por la infraestructura se pueden descomponer en tres tareas diferentes, que están diseñadas jerárquicamente, donde las capas superiores tienen un alcance espacial más amplio y las capas inferiores manejan tareas más locales. Por lo tanto, el proceso de enviar un paquete desde un host emisor a un host receptor implica agregar estas tareas de envío locales. La tarea local y de bajo nivel de proporcionar una entrega óptima de paquetes es la transmisión a través de enlaces o transmisiones, lo que requiere conversión de digital a analógico y corrección de errores, ninguna de las cuales es exclusiva de Internet. Esta tarea de entrega local es manejada por la llamada capa física (L1).
Dado que L1 es capaz de enviar un flujo de bits a través del enlace, la siguiente tarea es habilitar la comunicación en una red de paquetes local (como Ethernet o inalámbrica). Esto implica dos pasos:
(i) Un paquete de datos está compuesto por un grupo de bits, precedido por un encabezado de paquete de datos que describe dónde deben enviarse estos bits;
(ii) Entregar estos paquetes al destino apropiado en la red local. Para limitar el segundo paso a la transmisión local (en lugar de global), puede utilizar técnicas no escalables como la transmisión (el propio medio garantiza que los paquetes de transmisión lleguen a todos los hosts (como los inalámbricos)) y la inundación (la red garantiza que los paquetes inundados lleguen a todos los hosts (como los inalámbricos)). todos los anfitriones). Esta tarea es manejada por lo que tradicionalmente se llama capa de enlace o L2. En redes que no son de transmisión, esta tarea la realizan conmutadores en la red local, que reenvían paquetes a sus destinos.
La tarea final es entregar los paquetes desde la red del remitente a la red de destino, aprovechando las capacidades de L2 para entregar paquetes en estas redes a varios hosts. La interconexión de dichas redes es manejada por la capa de interconexión de red (L3) y se implementa mediante enrutadores en L2 que se conectan a dos o más redes. Los paquetes se reenvían a través de una serie de enrutadores (la entrega de enrutador a enrutador es compatible con L2 en la red a la que están conectados los dos enrutadores) hasta que llegan a la red de destino. Esta capa de redes conectadas también define el modelo de servicio de Internet, con L3 entregando datos al software host de capa superior.
Así, la conectividad ubicua que ofrece Internet comenzó con un diseño conceptualmente simple pero audaz.
2.2 Soporte de red en software host
El modelo de servicio de host a host en la infraestructura de red no especifica a la aplicación a qué host se debe entregar el paquete, y es difícil para la aplicación lograr un rendimiento óptimo sin ayuda adicional. Para corregir estos problemas, el sistema operativo host proporciona una capa de transporte (L4) además de otro soporte de red. Según los metadatos en el encabezado del paquete llamado "puerto", L4 entrega el paquete a aplicaciones individuales en el host. Para facilitar que las aplicaciones utilicen los servicios de mejor esfuerzo, algunos protocolos de transporte público proporcionan tres funciones.
Bytestream API, las aplicaciones pueden utilizar una interfaz simple similar a un archivo para escribir y leer datos sin tener que enviar y recibir paquetes individuales explícitamente.
Controlar la velocidad de transmisión de paquetes de un host para evitar la sobrecarga de la red, este enfoque se llama transporte de control de congestión e implica un bucle de control en el que el protocolo de transporte detecta la congestión de la red si detecta congestión en la red (por ejemplo, por paquetes faltantes o aumento de la latencia). su tasa de envío disminuirá. Existen muchos algoritmos de control de congestión que difieren en cómo detectan y responden a la congestión.
El más básico es la entrega confiable de paquetes y la aplicación no necesita lidiar con la pérdida de paquetes. Esta pérdida es una parte natural del mejor modelo de servicio, pero es inaceptable para muchas aplicaciones. Aunque la confiabilidad se puede implementar en la propia aplicación u otras bibliotecas de soporte, para mayor claridad, esta confiabilidad se implementa en L4.
La arquitectura de Internet de cuatro capas es un resultado natural de la modularidad. Cada capa solo interactúa con la capa directamente encima y debajo de ella. Dado que los paquetes siempre llegan a través del medio físico de L1, los hosts deben implementar las cuatro capas; los enrutadores implementan las primeras tres capas y los conmutadores solo implementan las dos primeras capas. Así que aquí hay cuatro preguntas que responder.
Pregunta n.º 1: ¿Qué tipo de diversidad admite esta arquitectura en capas y cómo se gestiona?
Dos implementaciones de una capa son arquitectónicamente intercambiables siempre que proporcionen las mismas interfaces ascendentes y descendentes. Además, la modularidad de la arquitectura de Internet permite que coexistan múltiples protocolos de transporte en L4, múltiples diseños de redes locales en L2 y múltiples tecnologías físicas en L1, cada una de las cuales proporciona su propia interfaz única. Las tecnologías L1 y L2 son seleccionadas por el proveedor de red, quien puede garantizar que sus interfaces sean compatibles, es decir, el diseño de la red local puede utilizar un conjunto de tecnologías de enlace. Una aplicación selecciona el protocolo L4 que requiere al llamar a la API de red del sistema operativo. La aplicación y el proveedor de red hacen la selección de forma independiente, es decir, la aplicación no sabe en qué red se encuentra actualmente y el proveedor de red no sabe qué aplicaciones se utilizarán en su red. Este enfoque funciona perfectamente si y sólo si hay un conjunto de interfaces en L3 con las que todos los diseños L2 y protocolos L4 sean compatibles. Por lo tanto debemos tener un único protocolo en L3 que es el Protocolo de Internet (IP), actualmente IPv4 e IPv6. Como "cintura" de la arquitectura de Internet, la singularidad de la propiedad intelectual hace posible la innovación diversificada en todos los demás niveles.
Pregunta #2: ¿Qué identificadores utiliza Internet?
Internet debe permitir que los encabezados de paquetes L2 y L3 identifiquen el destino de una ruta y permitan a los usuarios y aplicaciones identificar los servicios a los que desean acceder. Esto da como resultado tres tipos de direcciones. Normalmente, cada interfaz de red de hardware conectable en el host (como Wi-Fi, tarjeta celular o tarjeta Ethernet) tiene una dirección única permanente llamada dirección MAC, que L2 utiliza para identificar la dirección. destino tierra. L3 usa direcciones IP, que designan una red única en Internet y la interfaz de host específica que actualmente usa la dirección en esa red (esta asignación de dirección puede cambiar con el tiempo). Los usuarios y las aplicaciones utilizan nombres a nivel de aplicación para referirse a servicios basados en host. Para darle a estos nombres cierto grado de persistencia, son independientes de las máquinas en las que se basan los servicios y en qué parte de la red se pueden ubicar esos hosts. De estos tres identificadores (nombre de nivel de aplicación, dirección IP y dirección MAC), los dos primeros deben resolverse en el identificador del siguiente nivel más bajo. Por lo tanto, cuando una aplicación en un host intenta enviar un paquete a una aplicación en otro host, debe resolver el nombre del nivel de aplicación en una dirección IP. Cuando un paquete llega a la red, se envía a través de L2 al host de destino o al enrutador del siguiente salto. En ambos casos, la dirección IP debe resolverse en una dirección MAC.
Pregunta 3: ¿Cómo organizar la infraestructura de Internet?
Internet es más que una colección no estructurada de redes L2 conectadas por enrutadores. En cambio, es una colección de sistemas autónomos (AS), también llamados dominios, cada uno de los cuales contiene un conjunto de redes L2 administradas por una única entidad. Ejemplos de AS incluyen empresas, universidades y proveedores de servicios de Internet (ISP) comerciales. Estos sistemas controlan su propio enrutamiento L3 interno y deben establecer protocolos de enrutamiento con otros sistemas para proporcionar transporte de host a host entre sistemas. Por tanto, L3 implica dos tareas de enrutamiento:
(i) El enrutamiento entre redes dentro de un AS (enrutamiento intradominio) lo maneja el enrutador en el AS;
(ii) El enrutamiento entre AS (enrutamiento entre dominios) se realiza mediante los denominados enrutadores fronterizos que conectan dos o más AS.
Estas dos tareas de enrutamiento tienen requisitos diferentes y, por lo tanto, requieren diferentes paradigmas y protocolos de enrutamiento.
Pregunta 4: ¿Cómo encajan estas piezas?
El proceso de entrega de un paquete a través de Internet comienza cuando la aplicación resuelve un nombre de nivel de aplicación en una dirección IP y luego llama al soporte de red del host para enviar los datos a esa dirección IP de destino. Esto da como resultado una llamada a L4 que empaqueta los datos y una llamada a L3 para entregar estos paquetes. En L3, un paquete se reenvía a través de una serie de enrutadores hasta que llega a su red de destino (identificada por la dirección IP de destino en el encabezado del paquete). Cada enrutador tiene una tabla de reenvío que asigna la dirección IP de destino a la dirección IP del enrutador del siguiente salto. Después de recibir el paquete, el enrutador busca un enrutador de siguiente salto adecuado en la tabla de reenvío y luego envía el paquete a ese nodo de siguiente salto llamando a L2. L2 primero debe resolver la dirección IP del enrutador del siguiente salto en una dirección MAC y luego entregar el paquete al enrutador del siguiente salto (ya sea mediante transmisión o reenviando el paquete a través de una serie de conmutadores, como se describe en la siguiente sección), y luego por el enrutador del siguiente salto, que devuelve el paquete a L3. El desafío técnico clave en este proceso es configurar la tabla de reenvío L3 para que el conjunto de siguientes saltos siempre resulte en que los paquetes lleguen al destino apropiado.
3. Tres mecanismos centrales de Internet
La arquitectura de Internet identifica tres mecanismos importantes necesarios para implementar la arquitectura de Internet: esquemas de enrutamiento, confiabilidad y resolución de nombres.
3.1 Enrutamiento
El término "enrutamiento" se refiere al problema general de reenviar paquetes a través de Internet a un host de destino, que ocurre en L3 y se implementa mediante enrutadores, o en L2 mediante conmutadores, y la implementación en L2 se denomina conmutación en lugar de enrutamiento. Comenzando por considerar el enrutamiento intradominio L3, supongamos:
Cada encabezado L3 contiene una dirección IP de destino,
Cada enrutador tiene un conjunto de enrutadores vecinos que conecta en L2
Cada enrutador tiene una tabla de reenvío que indica correctamente si el enrutador está conectado (en L2) a la red de destino del paquete y, en caso contrario, asigna de manera determinista el destino del paquete que llega al siguiente vecino al que se debe reenviar el paquete.
Para simplificar el problema, concéntrese primero en la situación en la que un conjunto de tablas de reenvío estáticas guía con éxito el paquete hasta su destino. El conjunto de interconexiones entre enrutadores se llama gráfico de topología de red, suponiendo que estén conectados; el conjunto de tablas de reenvío se llama estado de reenvío; la unión de estas tablas se llama estado de enrutamiento. Una instancia de estado de enrutamiento dada es válida si siempre dirige los paquetes a su destino; si existe un anillo (es decir, una ubicación de inicio y una dirección de destino), los paquetes pueden regresar a la ubicación que visitó el enrutador. Por lo tanto, una instancia de estado de enrutamiento es válida si y sólo si no hay bucles.
Supongamos que no hay bucles; debido a que la red está conectada y es finita, cualquier paquete debe eventualmente llegar a un enrutador conectado (en L2) a su destino. Supongamos que existe un bucle para un destino determinado; cualquier paquete dirigido a ese destino que entre en el bucle nunca llegará al destino.
¿Por qué preocuparse por este resultado obvio? Debido a que Internet utiliza varios algoritmos de enrutamiento para calcular los estados de reenvío, la diferencia conceptual clave entre estos algoritmos de enrutamiento es la forma en que evitan bucles en estado estable. El protocolo de enrutamiento es un sistema distribuido complejo que resuelve el problema de cómo recalcular rápida y automáticamente el estado de reenvío cuando la topología de la red cambia debido a una falla y recuperación del enlace de la red. Aquí evitamos la complejidad de estos protocolos distribuidos y nos centramos únicamente en el estado de reenvío producido cuando el algoritmo converge a un estado estable en una red estática. En estos algoritmos, el método para evitar bucles de estado estable depende principalmente del tipo de información que se comparte entre los enrutadores.
Por ejemplo, un enrutador conoce los enrutadores vecinos y puede compartir esta información local con otros enrutadores mediante un algoritmo de inundación. En estado estable, cada enrutador puede utilizar esta información para ensamblar todo el mapa de topología de la red. Si todos los enrutadores utilizan el mismo algoritmo de búsqueda de ruta sin bucles para calcular sus tablas de reenvío en este gráfico de topología de red compartida, el estado de enrutamiento resultante siempre es válido. Este enfoque se denomina enrutamiento de "estado de enlace".
Muchos en la comunidad informática creen que Internet es simplemente una colección de protocolos complejos en lugar de un diseño conceptualmente simple y audaz.
Otro escenario es que cada enrutador informe a sus enrutadores vecinos su distancia de todas las demás redes en función de alguna métrica (como la latencia). El enrutador α puede calcular su distancia a cada red de destino n como dα (n) = minβ [dβ (n) + d (α, β)], donde dβ (n) es la distancia desde cada enrutador vecino β a la red. de n,d(α,β) es la distancia α,β entre dos enrutadores. Este estado estable de computación distribuida produce una ruta más corta a cada destino, que no puede tener ciclos. Esto se denomina enrutamiento por "vector de distancia".
Cuando la topología de la red cambia, pueden ocurrir bucles temporales en el estado de enrutamiento durante el recálculo del enrutamiento por vector de distancia y el enrutamiento por estado de enlace (es decir, cuando el protocolo aún no ha convergido a un estado estable). Si no se controlan, los paquetes que circulan sin cesar en dicho bucle pueden provocar un control de congestión severo. Para evitar esto, el protocolo IP incluye sabiamente un campo en el encabezado del paquete que comienza con un número inicial establecido por el host emisor y luego disminuye ese número cada vez que el paquete llega a un nuevo enrutador. Si este campo llega a cero, el paquete se descarta, lo que limita el número de veces que un paquete puede atravesar el bucle temporal y garantiza que no se produzca una situación catastrófica con el bucle temporal. Sin un mecanismo tan simple, todos los protocolos de enrutamiento necesitarían solucionar problemas de bucles temporales, y este nivel de preocupación podría complicar los protocolos de enrutamiento.
Considere el enrutamiento entre dominios L3. Obviamente, los AS deben transportar todos los paquetes de los cuales son origen o destino; todos los demás paquetes se consideran tráfico de transporte, que pasa a través de otros AS en su camino desde el AS de origen al AS de destino. Los AS quieren poder elegir libremente el tráfico que transportan y las rutas que utilizan para desviar el tráfico a sus destinos. Para los ISP, estas dos opciones estratégicas dependen en gran medida de sus consideraciones económicas con los ISP autónomos vecinos, por lo que quieren mantener estas opciones en secreto para evitar divulgaciones que podrían ayudar a los competidores.
Aunque el enrutamiento entre dominios en realidad lo implementan los enrutadores fronterizos, lo que implica cierta coordinación intradominio compleja entre ellos, el modelo de enrutamiento entre dominios se puede establecer simplemente para formar un gráfico de AS interconectados y ser controlado por los propios AS. decisiones. El enrutamiento entre dominios debe:
A AS se le permite tomar decisiones políticas arbitrarias, por lo que no se pueden utilizar vectores de distancia
Mantenga estas opciones de políticas privadas, de modo que no se pueda utilizar el enrutamiento de estado de enlace
Esto requeriría que los AS hicieran explícitas sus políticas para que todos los demás AS puedan calcular rutas utilizando estas políticas. Otro enfoque es permitir que los sistemas AS anuncien sus rutas eligiendo a quién anunciar (enviando mensajes a los sistemas AS vecinos que digan: "Puedes usar mi ruta para llegar a este destino") y cuando varios vecinos ya los hayan enviado. a un destino determinado, estas rutas se eligen para implementar sus políticas. Estos son los mismos mensajes y opciones que se utilizan en el enrutamiento por vector de distancia, pero el vector de distancia no permite flexibilidad de políticas: la ruta se anuncia a todos los vecinos y solo se elige la ruta más corta. Esta libertad local proporciona flexibilidad política y privacidad, pero ¿cómo evitar bucles estacionarios en el cálculo de rutas? La solución para Internet es intercambiar información de rutas. Cuando el AS "A" anuncia una ruta al AS vecino "B" (para un destino específico), especifica la ruta completa a nivel de AS para ese tráfico hacia el destino. Si AS "B" ve que ya está en ese camino, no utilizará ese camino. Si todos los AS obedecen esta aparente restricción, entonces el estado estable de lo que llamamos enrutamiento de "ruta vectorial" estará libre de bucles, independientemente de las decisiones políticas tomadas por los AS. El enrutamiento por vector de ruta se utiliza en el actual protocolo de enrutamiento entre dominios BGP y, por lo tanto, BGP es el pegamento que mantiene unidos muchos sistemas automatizados en Internet.
Debido a los bajos requisitos de rendimiento, Internet se implementa a gran velocidad y escala.
Este enfoque de vector de ruta garantiza que no haya bucles en ningún estado estable. Sin embargo, esto no garantiza que el protocolo de enrutamiento converja a un estado estable; por ejemplo, la oscilación de política es el caso en el que el algoritmo de vector de ruta no converge. Tampoco garantiza que todos los estados estables resultantes proporcionen conectividad entre todos los puntos finales, ya que todos los AS pueden negar la conectividad de tránsito a un AS determinado. Es desconcertante por qué estas anomalías no se observan en Internet. El análisis teórico muestra que las prácticas operativas típicas (el enrutamiento maximiza los ingresos y minimiza los costos) producen estrategias de enrutamiento que siempre convergerán a un estado estable, proporcionando todos los puntos finales entre conexiones de extremo a extremo. .
La evitación de bucles también desempeña un papel en las redes que no son de transmisión, donde a menudo se utiliza la inundación para llegar al destino. El protocolo de árbol de expansión (STP) crea un árbol eligiendo no utilizar ciertos enlaces fuera de la red, es decir, eliminando todos los anillos del diagrama de topología de la red. Una vez que la red se convierte en un árbol de expansión, los paquetes pueden enviarse a todos los hosts haciendo que cada conmutador reenvíe el paquete a todos los enlaces adyacentes en el árbol de expansión, excepto el enlace al que llegó el paquete. Esta inundación permite a los hosts y enrutadores resolver direcciones IP en direcciones MAC a través de un mensaje de Protocolo de resolución de direcciones (ARP) que pregunta: "¿Qué host o enrutador tiene esta dirección IP?"; luego el propietario responde con su dirección MAC. Durante este intercambio ARP (en realidad, cada vez que un host envía un paquete), los conmutadores pueden aprender cómo llegar a un host específico sin inundarse al recordar el enlace desde el cual recibieron un paquete más recientemente de ese host. Sólo hay una ruta entre dos nodos cualesquiera en el árbol de expansión, por lo que se puede llegar a un host a través del enlace a través del cual llegan los paquetes enviados desde ese host. Por lo tanto, al utilizar dicho "interruptor de aprendizaje", el acto de resolver una dirección IP en una dirección MAC determina el estado de reenvío entre los hosts emisor y receptor. Al enviar un paquete a un host cuya dirección MAC se ha resuelto, la red no necesita utilizar inundación y, en su lugar, puede enviar el paquete directamente.
En resumen, todos los algoritmos de enrutamiento deben tener un mecanismo para evitar la formación de bucles en el estado estable (es decir, después de que el protocolo haya convergido), lo que a su vez depende de la información intercambiada. Para limitar el intercambio de información con enrutadores adyacentes en el AS, es necesario utilizar vectores de distancia para garantizar que no haya bucles y así generar la ruta más corta. Para aumentar la flexibilidad del enrutamiento dentro del dominio, una mejor opción es el estado del enlace, que requiere información inundada de vecinos pero permite el cálculo de rutas arbitrarias sin bucles. Para permitir que los AS apliquen controles de políticas individuales en el enrutamiento entre dominios, pueden intercambiar información de ruta explícita para evitar bucles. Para implementar inundaciones dinámicas y aprendizaje de rutas en L2, es necesario convertir los gráficos de topología de red en árboles de expansión, ya que son inherentemente acíclicos. Se podrían considerar otras cuestiones en el enrutamiento, como cómo recuperarse de fallas sin tener que volver a calcular las rutas y cómo usar el control centralizado para simplificar los protocolos de enrutamiento como SDN, pero el punto aquí es ilustrar cómo evitar bucles en el enrutamiento de uso común. paradigmas El papel de las carreteras.
3.2 Transmisión confiable
Cuando se habla de análisis de enrutamiento, incluso con un estado de enrutamiento válido, los paquetes aún pueden descartarse debido a enlaces sobrecargados o enrutadores defectuosos. La arquitectura de Internet no garantiza la confiabilidad de las tres primeras capas, pero deja sabiamente esta tarea a la capa de transporte o a la propia aplicación. Los paquetes perdidos sólo se transmiten cuando son retransmitidos por el host emisor.
La transmisión confiable está garantizada por el protocolo de transporte, que establece la conexión para obtener datos de una aplicación y transferirlos a una aplicación remota. Algunos protocolos de transporte importantes, como el ampliamente utilizado TCP, proporcionan una abstracción confiable del flujo de bytes, en la que los datos del flujo de bytes se dividen en paquetes y se transmiten secuencialmente, y el propio protocolo de transporte recupera todas las pérdidas de paquetes. Se puede implementar completamente una abstracción de flujo de bytes confiable mediante un software host que pueda distinguir los paquetes en un flujo de bytes de los paquetes en otro flujo de bytes al tener números de secuencia en los paquetes para que puedan usarse en cualquier entrega de datos a La aplicación receptora se reordena correctamente y retransmite paquetes hasta que se entregan exitosamente.
De manera informal, un protocolo de transporte confiable toma datos de una aplicación, los transmite al destino en forma de paquetes y finalmente notifica a la aplicación que la transferencia se completó exitosamente o terminó con falla, deteniendo en ambos casos futuras transferencias. Supongamos que la red subyacente finalmente entrega un paquete duplicado, por lo que el protocolo de persistencia siempre tiene éxito. Para este caso, ¿qué comunicación se requiere entre el remitente y el receptor para garantizar que el protocolo pueda notificar a la aplicación que ha tenido éxito si y sólo si se han recibido todos los paquetes? Hay dos enfoques comunes: el receptor puede enviar un acuse de recibo (ACK) al remitente cuando se recibe un paquete, o un no acuse de recibo (NACK) cuando se sospecha que un paquete se ha perdido.
ACK es necesario y suficiente para una transmisión confiable, mientras que NACK no es necesario ni suficiente. Un protocolo de transporte confiable solo puede declarar éxito cuando sabe que se han enviado todos los paquetes, lo que solo puede inferirse al recibir un ACK por cada paquete. La ausencia de un NACK (que a su vez se puede eliminar) no significa que se haya recibido el paquete. Sin embargo, los NACK pueden resultar útiles porque pueden proporcionar información oportuna sobre cuándo el remitente debe retransmitir. Por ejemplo, TCP utiliza ACK explícitos para mejorar la confiabilidad e inicia retransmisiones basadas en tiempos de espera y NACK implícitos (cuando no llega el ACK esperado).
3.3 Resolución de nombres
Además de resolver direcciones IP en direcciones MAC a través de ARP, Internet también debe resolver nombres a nivel de aplicación en una o más direcciones IP. Estos nombres se denominan informalmente nombres de host y formalmente se conocen como nombres de dominio completos. Puede utilizar terminología no estándar para nombres de nivel de aplicación que no se refieran a una máquina física específica (como lo hace una dirección MAC) ni estén directamente relacionados con el concepto de dominio utilizado en el enrutamiento entre dominios.
Cualquier sistema de nombres a nivel de aplicación debe:
Asigne el control administrativo de cada nombre a un permiso único que determine a qué dirección IP se resolverá el nombre;
Manejar solicitudes de alta resolución;
Ambas propiedades se proporcionan a escala de miles de millones de nombres a nivel de aplicación.
Para abordar estos desafíos, Internet adopta una estructura de nombres jerárquica llamada Sistema de nombres de dominio (DNS). El espacio de nombres se divide en áreas llamadas dominios, que se subdividen de forma recursiva en dominios más pequeños, y tanto la resolución como el control de gestión se realizan de forma jerárquica. Cada dominio con nombre tiene uno o más servidores de nombres que pueden crear nuevos subdominios y resolver nombres dentro de su dominio. El nombre se puede resolver completamente en una o más direcciones IP) o la resolución se puede dirigir a uno o más servidores de nombres de subdominio que pueden resolver aún más dichos nombres. Esta jerarquía comienza con un conjunto de dominios de nivel superior (TLD), y el registro comercial permite a los clientes registrar subdominios bajo estos TLD. La resolución de un TLD a sus servidores de nombres es manejada por un conjunto de servidores raíz DNS (cuyas direcciones son conocidas por todos los hosts), y la resolución continúa a lo largo de la jerarquía de nombres desde allí. Por ejemplo, www.myschool.edu primero se resuelve mediante un servidor raíz, que apunta al servidor de nombres edu, que luego apunta a un servidor de nombres para myschool.edu, que luego resuelve www.myschool.edu en una dirección IP. Esta jerarquía permite una resolución de nombres altamente paralela y un control administrativo totalmente distribuido, los cuales son críticos para manejar la escala de nombres de Internet.
4. El secreto del éxito en Internet
Este artículo intenta reducir la incomprensible complejidad de Internet a un pequeño conjunto de opciones de diseño:
modelo de servicio
Arquitectura de cuatro niveles
Tres mecanismos clave (enrutamiento, confiabilidad y resolución)
Comprender las razones detrás de estas decisiones no es suficiente para comprender la complejidad de la Internet actual, pero sí para diseñar una nueva Internet con aproximadamente las mismas propiedades. Desafortunadamente, esta simplicidad no es suficiente para explicar la longevidad de Internet. ¿Por qué el diseño de Internet ha tenido tanto éxito en manejar enormes cambios en velocidad, escala, alcance, tecnología y uso?
4.1 Rústico
En lugar de intentar satisfacer todos los requisitos posibles de las aplicaciones, Internet ha adoptado un modelo de servicio muy limitado pero muy común, que no tiene garantías. Entonces, para dispositivos inteligentes y redes no inteligentes:
Permite que florezcan nuevas aplicaciones porque Internet no está personalizado para satisfacer las necesidades de ninguna aplicación específica;
Aprovechar la capacidad del anfitrión para adaptarse a los caprichos del servicio óptimo de Internet de varias maneras (por ejemplo, mediante adaptación de tarifas, almacenamiento en búfer y retransmisión);
Capaz de aumentar rápidamente la velocidad de la red, el modelo de servicio es relativamente simple.
Si Internet adoptara un modelo de servicios más complejo, probablemente se limitaría a los requisitos de aplicación que existían en el momento de su creación y que podrían implementarse con las tecnologías disponibles en ese momento. Esto da como resultado una tecnología que está diseñada de manera compleja para un pequeño número de aplicaciones y rápidamente se vuelve obsoleta, lo que es una receta para el éxito a corto plazo pero el fracaso a largo plazo.
4.2 Modularización
La modularidad de la arquitectura de Internet de cuatro capas conduce a una clara división de responsabilidades: la infraestructura de red (L1/L2/L3) soporta una mejor entrega de paquetes (en términos de capacidad, cobertura y resiliencia), mientras que las aplicaciones (asistidas por L4) Cree una nueva funcionalidad para los usuarios basada en este modelo de servicio de entrega de paquetes. Por lo tanto, esta arquitectura permite que dos ecosistemas distintos, la infraestructura de red y las aplicaciones de Internet, florezcan de forma independiente.
Sin embargo, la modularidad de Internet trasciende su arquitectura formal para maximizar un enfoque más general de la autonomía dentro de su infraestructura basada en estándares, en contraste con la conformidad más rígida de la red telefónica. Por ejemplo, el único requisito para un AS es que sus enrutadores admitan IP y participen en el protocolo de enrutamiento entre dominios BGP. De lo contrario, cada sistema puede implementar cualquier tecnología L1 y L2 y cualquier protocolo de enrutamiento intradominio sin coordinación con otros sistemas. De manera similar, los dominios de nombres individuales deben admitir el protocolo DNS; de lo contrario, pueden emplear cualquier estrategia de gestión de nombres e infraestructura de resolución de nombres que elijan. La autonomía de esta infraestructura permite el surgimiento de diferentes prácticas operativas. Por ejemplo, una red de campus universitario, una red de centro de datos a hiperescala y una red troncal de ISP tienen necesidades operativas muy diferentes; la autonomía inherente de Internet les permite satisfacer sus propias necesidades a su manera y desarrollarse con el tiempo.
4.3 El fracaso es común
A medida que aumenta el tamaño de un sistema, existe una probabilidad cada vez mayor de que algún componente del sistema falle en un momento dado. Por lo tanto, a menudo se piensa en el escalamiento en términos de complejidad algorítmica o explosión de estado, mientras que el manejo eficiente de las fallas también es un requisito clave de escalabilidad. A diferencia de los sistemas que se espera que funcionen normalmente y entren en modos especiales para recuperarse de fallas, casi todos los mecanismos de Internet tratan las fallas como eventos comunes.
Por ejemplo, en los algoritmos de enrutamiento básicos, las rutas se calculan de la misma manera, ya sea debido a una falla del enlace o al recálculo de un bucle. De manera similar, cuando se pierde un paquete, se debe retransmitir, pero se espera que dichas retransmisiones ocurran con frecuencia y no sean casos especiales en el protocolo de transporte. Este estilo de diseño, que trata el fracaso como un caso común, es la base para construir una infraestructura de hiperescala en Google y otros, un estilo originalmente pionero en Internet.
4.4 Consenso aproximado y código ejecutable
En lugar de emplear los comités de diseño formales que eran populares en el mundo de las telecomunicaciones en ese momento, los inventores de Internet claramente eligieron otro camino: alentar a grupos más pequeños a construir diseños viables y luego dejar que una comunidad elija qué diseño adoptar. David Clark, uno de los líderes de la arquitectura de Internet, dijo en un discurso: "Rechazamos a los reyes, a los presidentes y a los votos. Creemos en el consenso aproximado y en el código de trabajo". Este espíritu igualitario se extiende a Internet como una conexión. Una visión compartida de una plataforma de comunicación unificada para todos los usuarios. Por lo tanto, el desarrollo de Internet estuvo determinado no sólo por decisiones puramente técnicas, sino también por la creencia de la primera comunidad de Internet en el valor de una plataforma compartida para conectar el mundo y su propiedad compartida para hacer realidad esta visión.
5. No existe la perfección
Hay muchas áreas donde el diseño de Internet es una solución subóptima, pero la mayoría son detalles de bajo nivel que no cambian la representación de alto nivel. Hay tres áreas en el diseño de Internet donde existen cuestiones más fundamentales.
5.1 Seguridad
Mucha gente culpa a la seguridad del mal estado de la seguridad en Internet, argumentando que la seguridad no fue una consideración principal en su diseño, aunque la capacidad de manejar fallas frente a fallas es de hecho una consideración importante. Esta crítica está fuera de lugar por dos razones:
(1) En un mundo interconectado, la seguridad es un objetivo más complejo y difícil de alcanzar que la ciberseguridad, e Internet sólo puede garantizar esta última;
(2) Aunque la arquitectura de Internet en sí misma no proporciona seguridad a la red, existen protocolos y tecnologías, algunos de los cuales son de uso generalizado, que pueden lograr dicha seguridad en gran medida.
Más precisamente, se puede decir que una red es segura si se pueden garantizar las siguientes propiedades al transmitir datos entre dos hosts:
La conexión entre hosts es razonablemente confiable (disponibilidad);
El destinatario puede indicar la fuente de los datos;
La integridad de los datos no ha sido alterada durante la transmisión);
Los datos no son leídos por ningún intermediario, nadie espía un enlace y sabe qué host está intercambiando paquetes (privacidad).
Los tres últimos generalmente pueden garantizarse mediante protocolos de cifrado. La disponibilidad de Internet es vulnerable a ataques distribuidos de denegación de servicio (DDoS), en los que muchos hosts se utilizan como robots para sobrecargar el objetivo con tráfico. Existen técnicas para filtrar este tráfico ofensivo, pero sólo son parcialmente efectivas. La disponibilidad también se ve amenazada por la vulnerabilidad de BGP porque el enrutamiento del AS es vulnerable; hay soluciones de cifrado disponibles, pero no están ampliamente implementadas. Por lo tanto, existen protocolos de cifrado y métodos de mitigación que permiten que Internet cumpla en gran medida con la definición de red segura.
Sin embargo, el hecho de no lograr que Internet sea una red intrínsecamente segura no es definitivamente la causa principal de los problemas de seguridad actuales: las redes seguras no pueden evitar las inseguridades del software del host. Por ejemplo, si una aplicación está diseñada para filtrar información sobre sus usuarios o hacerse pasar por sus usuarios para realizar transacciones financieras innecesarias, es poco lo que la red puede hacer para detener este comportamiento malicioso. Un host puede infectarse si un usuario descarga inadvertidamente una aplicación maliciosa o si algún ataque (como un desbordamiento del búfer) convierte una aplicación benigna en maliciosa. Las críticas a la seguridad en Internet a menudo apuntan a la facilidad para colocar malware en los hosts, pero esto no es principalmente una cuestión de ciberseguridad.
5.2 Procesamiento de paquetes dentro de la red
Los primeros diseñadores de Internet creían que la infraestructura de la red debería centrarse generalmente en la transmisión de paquetes y evitar funciones de nivel superior, pero casi todas las redes en funcionamiento hoy en día violan las reglas del llamado procesamiento de paquetes dentro de la red. Las redes modernas tienen muchos puntos intermedios que proporcionan algo más que transporte, como firewall (controlar qué paquetes pueden ingresar a la red), optimización de WAN (mejorar la eficiencia de la red al almacenar en caché los datos anteriores) y equilibrio de carga (dirigir solicitudes para subcargar el host).
Una encuesta de 2012 mostró que aproximadamente un tercio de los componentes de la red son middleware, un tercio enrutadores y un tercio conmutadores. Algunas de estas funciones de procesamiento en red se implementan dentro de empresas individuales para mejorar su eficiencia interna; este comportamiento sólo tiene un impacto dentro de la red empresarial y, por lo tanto, se considera ampliamente como una realidad aceptable. Además, como se analiza a continuación, algunos proveedores de contenido y nube han implementado grandes redes privadas, implementando capacidades dentro de la red (en particular, aceleración, almacenamiento en caché y equilibrio de carga) para reducir la latencia y mejorar la confiabilidad visible para el cliente.
5.3 Falta de capacidad evolutiva
Debido a que cada enrutador implementa el protocolo IP, es difícil cambiar el modelo de servicio de Internet. El mismo modelo de servicio también se mantuvo durante la reciente transición acelerada a IPv6 debido a la escasez de direcciones IPv4. Durante décadas, no ha habido cambios arquitectónicos importantes en Internet y no existe una alternativa viable a Internet. Sin embargo, las grandes redes privadas implementadas en centros de datos controlados centralmente brindan un servicio superior a los clientes a través de su procesamiento dentro de la red. Hoy en día, la mayor parte del tráfico de clientes almacena en caché su servicio AS original a través del centro de control local o lo usa directamente desde el AS de origen para tener una gran cantidad de datos. red privada de centros de procesamiento dentro de su red privada. Las grandes redes privadas de los centros de control centrales están integradas verticalmente con los servicios de contenido y de nube, que ahora son fuerzas económicas más dominantes que los ISP.
Por lo tanto, hemos comenzado a ver una transición hacia una nueva infraestructura global. Estas redes privadas han reemplazado la última milla de casi todo el tráfico en la Internet actual. Esto marcará el fin de una era de economía de Internet, cuando no tenía competidores reales. Si bien Internet enfrenta muchos desafíos, ninguno es más importante para su futuro que resolver las diferencias entre las dos visiones que animaron a las primeras comunidades de Internet: una Internet unificada que conecte a todos los usuarios, esencialmente desconectada de los servicios proporcionados por los puntos finales; una alternativa. Esta visión está representada por las redes privadas emergentes a gran escala donde el uso del procesamiento dentro de la red proporciona un mejor rendimiento.
6. Resumen de una frase
Internet es una maravilla de la ingeniería que incorpora decisiones de diseño muy audaces y proféticas. No permita que la complejidad de Internet eclipse la simplicidad de su diseño central y sus logros, y no olvide el coraje, el espíritu comunitario y la visión que llevaron a su creación. Este es quizás uno de los aspectos más valiosos de Internet. .
PD: Hasta ahora, entre los libros sobre redes informáticas que han leído los codificadores veteranos, este libro "Problemas y soluciones de redes informáticas" es el libro que explica con mayor claridad las redes informáticas y puede ser utilizado no solo como ingeniero de TI, sino especialmente como Un ingeniero de redes. El manual de escritorio de un ingeniero también es muy útil para que los arquitectos de sistemas e incluso los ingenieros de software comprendan el impacto de la arquitectura e infraestructura de red en los sistemas de software. Su valor no se depreciará dentro de 20 años, lo que nos permitirá comprender y aplicar claramente el Redes informáticas que nos rodean. .
[Lectura relacionada]