Redes Multimedia

Redes multimedia Xavier Vilajosana Guillén (coordinador) Miquel Font Rosselló Silvia Llorente Viejo Joan Manuel Marqués Puig PID_00147720

Redes multimedia

© FUOC • PID_00147720

Xavier Vilajosana Guillén Ingeniero en Informática por la Universidad Politécnica de Cataluña (UPC) y doctor en Sociedad de la Información por la Universitat Oberta de Catalunya (UOC). Actualmente, es profesor de los Estudios de Informática, Multimedia y Telecomunicación de la UOC.

Miquel Font Rosselló Ingeniero y doctorando en Informática, y consultor de los Estudios de Informática, Multimedia y Telecomunicación de la UOC.

Silvia Llorente Viejo Ingeniera en Informática, diploma de estudios avanzados por la UPC y doctora por la Universidad Pompeu Fabra (UPF). Actualmente, es consultora de los Estudios de Informática, Multimedia y Telecomunicación en la UOC.

Joan Manuel Marqués Puig Doctor en Informática, especializado en sistemas distribuidos descentralizados. Profesor de los Estudios de Informática, Multimedia y Telecomunicación de la UOC.

Primera edición: septiembre 2010 © Miquel Font Rosselló, Silvia Llorente Viejo, Joan Manuel Marqués Puig, Xavier Vilajosana Guillén. Todos los derechos reservados © de esta edición, FUOC, 2010 Avda. Tibidabo, 39-43, 08035 Barcelona Diseño: Manel Andreu Realización editorial: Eureca Media, S. L. ISBN: 978-84-693-4288-6 Depósito legal: B-20.539-2010 Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

© FUOC • PID_00147720

3

Introducción

La asignatura Redes multimedia pretende dar una visión global e introductoria de las redes de computadores. Se toma una aproximación de arriba abajo enfatizando los aspectos más relacionados con la titulación y dejando de lado aquellos relacionados con la comunicación en el ámbito físico en la teoría de la señal. Esta asignatura presenta las bases de las redes de comunicaciones, cómo se estructuran, qué dispositivos las integran, cuáles son las normas y protocolos que rigen la comunicación, cuáles sus aplicaciones y servicios, y todo tomando como ejemplo la red de Internet. El módulo "Conceptos de redes de computadores" introduce los principales conceptos que nos permiten entender qué es una red de computadores y cómo se estructura. También sirve de breve revisión de la historia de las redes, lo cual nos permite contextualizar y entender Internet en la actualidad. El módulo "Las capas de la red de computadores" describe los protocolos y servicios básicos que ofrece cada una de las capas de una red de computadores. El módulo empieza por los niveles más altos y deja de lado el nivel de aplicación que se ve en el módulo "El nivel de aplicación". El enfoque es, pues, de arriba abajo; se crea así un esbozo de los conceptos más próximos al hardware y se pone el énfasis en los niveles de transporte y de red primordiales para el funcionamiento de Internet. El módulo "Seguridad en la Red" complementa al resto y presenta los conceptos principales de la seguridad de las redes de computadores. El módulo "El nivel de aplicación" profundiza en el nivel de aplicación; muestra protocolos tan importantes como HTTP o SMTP que rigen el funcionamiento del mundo hoy en día. Se destacan los protocolos orientados a la transmisión del contenido multimedia, y se presentan las arquitecturas más comunes hoy en día en la Red. Por último, el módulo "Comunicaciones sin hilos" concluye el curso explicando los conceptos capitales de una tecnología que permite superar las barreras impuestas por la necesidad de conectar físicamente las redes. Cabe señalar que este curso pretende introducir el concepto de red y dar una visión general del funcionamiento de ésta. Por lo tanto, quedan fuera muchos conceptos que son primordiales también para entender el funcionamiento real de una red y que no han podido ser incluidos por limitaciones de espacio. De esta manera, se anima a los lectores más interesados en ampliar su conocimiento de las redes que consulten la bibliografía recomendada.

Redes multimedia

© FUOC • PID_00147720

4

Objetivos

El estudio de los materiales didácticos de esta asignatura os ha de permitir alcanzar los objetivos siguientes:

1. Conocer la arquitectura de una red. Saber diferenciar los niveles y conocer las principales funciones y servicios de cada uno de ellos. 2. Conocer los principales protocolos de nivel aplicación, entender su funcionamiento y saber relacionarlo con el funcionamiento actual de Internet. 3. Tener una visión general de los conceptos de seguridad en la Red que permiten asegurar las comunicaciones, así como evitar un uso indebido de la información. 4. Tener conocimiento de los conceptos principales que rigen la comunicación sin hilos. Conocer las tecnologías de comunicación sin hilos que existen hoy en día y rigen la mayoría de las comunicaciones actuales.

Redes multimedia

© FUOC • PID_00147720

5

Contenidos

Módulo didáctico 1 Conceptos de redes de computadores Xavier Vilajosana Guillén 1.

Conceptos de redes y comunicaciones en Internet

2.

Qué es Internet y qué es un protocolo

3.

Hardware de red

4.

Dispositivos de red

5.

Software de red

6.

Jerarquía de protocolos y cabecera

7.

Interfaces y servicios

8.

Modelos de referencia

9.

Breve historia de las comunicaciones

Módulo didáctico 2 Las capas de la red de computadores Xavier Vilajosana Guillén 1.

El nivel de transporte

2.

El nivel de red

3.

El enlace de datos y el control de acceso al medio

4.

El nivel físico

Módulo didáctico 3 Seguridad en la red Xavier Vilajosana Guillén 1.

Cortafuegos

2.

Redes privadas virtuales

3.

Introducción a la criptografía

4.

Certificados digitales

5.

Seguridad en la red

Módulo didáctico 4 El nivel de aplicación Joan Manuel Marqués Puig y Silvia Llorente Viejo 1.

Arquitecturas de aplicaciones distribuidas

2.

DNS: Servicio de nombres en Internet

3.

La web y el HTTP

4.

Transferencia de ficheros

5.

Correo electrónico en Internet

6.

Aplicaciones de igual a igual para la compartición de ficheros

7.

Mensajería instantánea

8.

Telnet y Secure Shell: acceso a ordenadores remotos

9.

Aplicaciones multimedia en red

10. Streaming de audio y vídeo almacenados

Redes multimedia

© FUOC • PID_00147720

6

11. Protocolos para aplicaciones interactivas en tiempo real 12. Anexos Módulo didáctico 5 Comunicaciones inalámbricas Miquel Font Rosselló 1.

Sistemas de comunicación de la telefonía móvil

2.

Redes inalámbricas

Redes multimedia

Conceptos de redes de computadores Xavier Vilajosana Guillén PID_00147725

© FUOC • PID_00147725

Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

Conceptos de redes de computadores


© FUOC • PID_00147725

Índice

Introducción...............................................................................................

5

Objetivos.......................................................................................................

6

1.

Conceptos de redes y comunicaciones en Internet....................

7

2.

Qué es Internet y qué es un protocolo.........................................

8

3.

Hardware de red................................................................................

9

3.1.

Topologías de red ........................................................................

9

3.2.

Tipo de conmutación ..................................................................

10

3.2.1.

Conmutación de circuitos .............................................

10

3.2.2.

Conmutación de paquetes .............................................

11

3.2.3.

Conmutación de paquetes con circuito virtual .............

14

Alcance de las redes ....................................................................

15

3.3.1.

Redes de gran alcance ...................................................

16

3.3.2.

Redes de área local ........................................................

16

Tecnologías de red ......................................................................

16

3.4.1.

Tecnologías de red cableada ..........................................

17

3.4.2.

Tecnologías de red sin hilos ..........................................

17

4.

Dispositivos de red............................................................................

19

5.

Software de red..................................................................................

21

5.1.

Arquitectura de la red: diseño por capas ....................................

22

5.2.

Consideraciones de diseño .........................................................

25

6.

Jerarquía de protocolos y cabecera...............................................

27

7.

Interfaces y servicios.........................................................................

29

7.1.

Tipo de conexión de servicios ....................................................

33

Modelos de referencia.......................................................................

35

8.1.

Necesidad de estandarización .....................................................

35

8.2.

El modelo de referencia OSI .......................................................

36

8.2.1.

Proceso de encapsulación y desencapsulación ..............

38

Modelo TCP/IP ............................................................................

39

3.3.

3.4.

8.

8.3.

8.3.1. 8.4.

Encapsulación de la información en el modelo TCP/IP ............................................................................

41

Modelo OSI comparado con modelo TCP/IP ..............................

42


© FUOC • PID_00147725

9.

Breve historia de las comunicaciones..........................................

44

Resumen.......................................................................................................

56

Bibliografía.................................................................................................

59

© FUOC • PID_00147725

5

Introducción

Las redes de ordenadores actuales son una composición de dispositivos, técnicas y sistemas de comunicación que han ido apareciendo desde el final del siglo XIX con la invención del teléfono. Éste se desarrolló exclusivamente para transmitir voz, aunque todavía hoy se utiliza, en muchos casos, para conectar ordenadores entre sí. Desde entonces han aparecido las redes locales, las conexiones de datos a larga distancia con enlaces transoceánicos o por satélite, Internet, la telefonía móvil, etc. Dedicaremos este módulo a introducir las ideas y los conceptos básicos de las redes de ordenadores que trataremos en profundidad a partir de ahora. En primer lugar, abordaremos los conceptos fundamentales de una red. Las topologías de red y los conceptos de conmutación, el hardware y el software. Es importante tener una visión general de la tipología de red, normalmente clasificada por su alcance. Seguidamente, el módulo introduce las diferentes tecnologías de red más relevantes en la actualidad, Ethernet u 802.3 es la más usada en redes de área local cableadas. Las tecnologías de redes sin hilos se han estandarizado en la última década y tienen su mayor exponente en el 802.11 o WiFi, que también es usado por la mayoría de dispositivos de usuario en red. El módulo profundiza en la definición de una red de computadores y nos presenta el modelo de referencia de una red, constituida por diferentes niveles que permiten abstraer las complejidades derivadas de la transmisión de la información. Como veremos, cada nivel de la red ofrece servicios a su nivel predecesor mientras que usa los servicios de su nivel antecesor. Cuando se quiere transmitir una información, ésta se transmite entre los diferentes niveles de la red a la vez que se encapsula la información de los niveles precedentes y se añade nueva información que le permite al receptor recuperar la información original. Veremos que en un principio se definió una jerarquía llamada Open Systems Interconnection (OSI) con siete niveles y que ésta evolucionó hacia el modelo de red actual, el modelo TCP/IP que rige hoy en día el funcionamiento de Internet. Finalmente, el módulo hace un breve repaso de la historia de las comunicaciones. Conocer la historia nos permite tener una buena perspectiva de estas tecnologías y entender por qué se han creado, cómo han evolucionado y por qué tenemos el modelo de comunicación actual.


© FUOC • PID_00147725

6

Objetivos

Al finalizar el estudio de este módulo, tendréis que haber alcanzado los objetivos siguientes:

1. Conocer el concepto de red de computadores, servicio y protocolo e Internet. 2. Conocer los componentes de una red de computadores, tanto los de hardware como los de software. 3. Conocer la arquitectura de una red de computadores, la separación por capas o niveles y los modelos de referencia fundamentales. 4. Saber diferenciar las redes por su alcance. 5. Tener una visión general de la evolución de las redes de computadores desde sus inicios.


© FUOC • PID_00147725

7

1. Conceptos de redes y comunicaciones en Internet

Durante las dos primeras décadas de existencia de los computadores, éstos eran sistemas hardware fuertemente centralizados, normalmente ubicados en un único espacio físico. Las empresas y centros que poseían un computador hacían que éste cubriera todas las necesidades computacionales de la institución. A medida que las capacidades de los computadores crecieron, la centralización se convirtió en un problema tanto de gestión como de recursos. De esta manera, se fue sustituyendo el modelo centralizado por un modelo en el que múltiples computadores con menos capacidad pero interconectados entre sí eran capaces de realizar las tareas de un computador centralizado. A esta nueva organización se la denominó red�de�computadores. El diseño y arquitectura de la red son los aspectos que trataremos durante este curso. La evolución de las tecnologías ha llevado a un crecimiento progresivo del uso de los sistemas en red hasta llegar al modelo de hoy en día, en el que no se puede concebir un sistema informático sin la presencia de los elementos de comunicación. Internet ha sido la materialización de la red de computadores y se ha convertido en el eje principal de las tecnologías de la información. Las comunicación en Internet no deja de ser una jerarquización de la comunicación en red. Internet es una gran red constituida por una infinidad de pequeñas redes interconectadas entre sí.


© FUOC • PID_00147725

8


2. Qué es Internet y qué es un protocolo

La idea de Internet apareció a mediados de los años sesenta cuando la Agencia de Proyectos de Investigación Avanzada (ARPA, por sus siglas en inglés), en el seno del Departamento de Defensa de Estados Unidos financió un proyecto denominado ARPANET que pretendía interconectar diferentes ordenadores distribuidos en sus sedes. Desde entonces, Internet ha evolucionado hasta el sistema de hoy en día, en el que millones de máquinas están interconectadas y acceden a contenidos distribuidos por todas partes. La estructura de la red es compleja y no podemos pensar en una conexión de todos con todos, pues ello haría que el sistema fuera completamente inoperante e inviable tecnológicamente. Internet sigue una estructura jerárquica en la que unos pocos nodos están conectados con muchos otros, mientras que la mayoría mantiene una conexión con su proveedor de servicio.

Para hacer posible toda la complejidad de Internet y permitir que la infinidad de aplicaciones de hoy en día se puedan comunicar mediante la red hace falta un conjunto de reglas que rijan las comunicaciones y regulen cómo y cuándo los nodos de la red se pueden comunicar. Las reglas y convenciones que permiten que eso sea posible se llaman protocolos.

Conectividad en Internet

© FUOC • PID_00147725

9

3. Hardware de red

Las redes de computadores se pueden clasificar de diferentes formas. Generalmente, estas clasificaciones se hacen basándose en la topología, el tipo de conmutación, el alcance y la tecnología de la red, entre otros. Este apartado detalla estas diferentes clasificaciones que proporcionan la base necesaria para poder entender posteriormente el diseño de los protocolos existentes en la actualidad. 3.1. Topologías de red

Una topología de red es la manera como están distribuidos los nodos que la forman.

Las redes actuales están formadas por tres tipos de entidades: los equipos finales (hosts), los equipos intermedios (conmutadores o routers) y los enlaces (links) que unen los equipos finales y los routers entre sí. Las topologías más conocidas son las de: •

Bus. Todos los equipos están conectados a un único medio de transmisión compartido por todas las estaciones de la red, por lo que resulta necesario establecer un sistema de acceso al medio con el fin de evitar que haya más de una estación transmitiendo en el mismo instante de tiempo y se produzcan colisiones. Un ejemplo de una topología en bus se puede ver en la figura siguiente.

•

Anillo. Como muestra la figura, una topología en anillo está formada por un enlace que forma un bucle, de manera que cada estación está conectada al anillo a través de dos enlaces, el de entrada y el de salida. Generalmente, cuando la estación emisora recibe su propio paquete lo elimina de la red.

•

Estrella. Esta topología está formada por un nodo central, que actúa como nodo intermedio de la red (conmutador o router) y es el que gestiona el envío y la recepción de los datos; el resto de las estaciones se conectan a este nodo principal.

•

Árbol. La topología en árbol se considera una topología mixta de las topologías en bus y en estrella, y a veces también se la conoce como topología jerárquica. Un ejemplo se puede ver en la figura, donde diversos nodos


© FUOC • PID_00147725

10

intermedios se conectan entre sí y, a su vez, tienen conectados equipos finales. Esta topología es la más utilizada actualmente. •

En�malla. La topología en malla es aquella en la que todos los equipos están conectados contra todo el resto. Hay casos de redes en malla no totales, en las que las estaciones no forman una malla completa. Generalmente, esta topología es la utilizada en el núcleo de las grandes redes como Internet, donde sólo se conectan equipos intermedios, y no equipos finales.

Ejemplos típicos de topologías de red

3.2. Tipo de conmutación En el entorno de las redes, la conmutación hace referencia al establecimiento de un circuito (real o lógico) entre dos puntos de la red que permite la interconexión y, por lo tanto, el traspaso de información entre los puntos. Esencialmente, esta conmutación se puede dividir en dos clases diferentes: la conmutación de circuitos y la conmutación de paquetes. 3.2.1. Conmutación de circuitos La conmutación de circuitos se basa en establecer un circuito físico entre los dos interlocutores de la red. Dicho circuito físico se establece antes de que se pueda transmitir ningún tipo de información y está conformado por diferentes enlaces entre los nodos. En conmutación de circuitos se distinguen tres fases para el envío de información: 1)� Establecimiento� del� circuito. Esta fase se encarga de buscar un camino entre los nodos intermedios que lleven hacia el destino; así la estación origen solicita la creación del circuito al nodo al que está conectada, el cual envía la


© FUOC • PID_00147725

11

petición al nodo siguiente. Este otro nodo hará lo mismo hacia el siguiente, y así hasta llegar al destino final. A medida que se va formando el circuito, cada nodo intermedio verifica que haya bastantes recursos para establecerlo, y, en el caso de que no sea así, se aborta la petición de circuito. Por el contrario, en el caso de que el establecimiento sea viable, una vez llegado al destino, éste enviará una señal al origen para hacerle saber que ya puede enviar información. 2)�Transferencia�de�datos. Ahora, las estaciones ya pueden intercambiar la información deseada. 3)�Desconexión. Una vez se ha acabado la comunicación es obligatorio liberar recursos, a fin de que estén disponibles más adelante para otras conexiones. Ejemplo de creación de circuitos Un ejemplo de creación de circuitos es el que se muestra en el diagrama de tiempo de la figura siguiente. Ésta muestra las tres fases en el caso de que haya dos nodos intermedios. El diagrama de tiempo se tiene que interpretar de izquierda a derecha con la evolución temporal, donde cada bloque representa el envío de información hacia el siguiente nodo. Diagrama de tiempo del establecimiento de un circuito

Como se puede ver en la figura, las líneas tienen una cierta inclinación, lo que indica el tiempo de propagación de la señal, mientras que el grueso de cada bloque indica el tiempo de transmisión necesario para enviarla. Inicialmente, en el establecimiento del circuito cada equipo intermedio tiene que procesar la señal y enviarla al siguiente nodo; por eso, antes de enviarla se tiene que esperar a tener toda la información del circuito. Que una vez establecida, ya puede funcionar de extremo a extremo de forma transparente y sin más retardos adicionales de los nodos intermedios. Red telefónica básica El ejemplo más clásico de la conmutación de circuitos es la antigua red telefónica básica (XTB), en la que, por medio de las centralitas situadas de forma jerárquica por medio de toda la red, se iban multiplexando los circuitos de voz y dirigiéndolos hacia su destinatario. Hoy día, con la era digital, este establecimiento del circuito se produce sólo desde el teléfono del usuario hacia la centralita más próxima, donde se digitaliza la voz y se utilizan otras técnicas como, por ejemplo, la conmutación de paquetes, para enviar la información.

3.2.2. Conmutación de paquetes Uno de los principales problemas que encontramos con la conmutación de circuitos es la exclusividad de los recursos, ya que cuando hay un circuito creado, aunque no haya datos pasando por el circuito, los recursos están reserva-


© FUOC • PID_00147725

12

dos y no pueden ser utilizados por ninguna otra estación. El problema se ve agravado ya que, para conexiones de datos como las que hay hoy día, el tráfico, en vez de ser constante, llega en ráfagas; por ejemplo, cuando el usuario carga una página web, la carga sólo supone unos pocos centenares de milisegundos, mientras que su lectura puede comportar unos cuantos minutos. Otro problema impuesto por la conmutación de circuitos es la necesidad de que todos los nodos de la comunicación trabajen a la misma velocidad, ya que los nodos intermedios no realizan ningún procesado de la información, cosa que en una red actual no es cierta; cada usuario tiene una velocidad diferente, que es a la vez diferente de la que utilizan los operadores. Así, con el fin de mejorar la conmutación de circuitos de cara a estas nuevas necesidades se diseñó la conmutación de paquetes con los siguientes objetivos: •

Optimización de la utilización de los canales de comunicación.

•

Interconexión de terminales con diferentes velocidades.

•

Creación de conexiones de forma simultánea sin reserva de recursos.

Así, la conmutación de paquetes, en vez de reservar recursos en un circuito, dota a los nodos intermedios de capacidad de proceso y de un sistema de colas que permite almacenar temporalmente un paquete, mirar cuál es su destinatario y enviarlo hacia el nodo que corresponda. Como se ha dicho, la conmutación de paquetes tiene que permitir diferentes velocidades de transmisión; por eso se utilizan las colas de recepción y las colas de transmisión, tal como muestra la siguiente figura. Según se puede comprobar, un nodo de conmutación está compuesto por interfaces; estas interfaces están compuestas, entre otras cosas, por una cola de entrada y otra cola de salida al sistema, y se utilizan con el fin de controlar el acceso al nodo de conmutación, que, ahora, en vez de ser pasivo, procesará todos los paquetes que llegan por las colas de entrada y los colocará en la cola de salida de la interfaz correspondiente para ser enviados.


© FUOC • PID_00147725

13

Colas en la conmutación de paquetes

Las colas del nodo de conmutación tendrán un tamaño determinado, lo que implica que si una cola se llena antes de ser procesada, hay paquetes que tendrán que ser descartados. En módulos posteriores veremos cómo la red gestiona y evita estas pérdidas. Otro importante factor a considerar en este entorno es el tamaño del paquete a transmitir; inicialmente se pensó en hacer los paquetes tan grandes como el mensaje a enviar (conmutación de mensajes), pero enseguida se vio que, para mensajes grandes, los nodos intermedios necesitaban demasiada memoria –ya que almacenan el paquete en su totalidad antes de enviarlo–, y demasiado tiempo para procesarlo. Así, lo que se hace actualmente es dividir los mensajes en fragmentos de un tamaño máximo fijado (generalmente 1.500 octetos). Un ejemplo de eso se puede encontrar en la figura siguiente; las dos subfiguras muestran el envío del mismo mensaje, primero con conmutación de mensajes, y después con conmutación de paquetes. Como se puede ver en este ejemplo, el mensaje ha sido enviado con tres paquetes diferentes de un tamaño inferior. A causa del almacenamiento en los nodos intermedios (denominado store and forward) la conmutación de paquetes es generalmente más rápida.


© FUOC • PID_00147725

14

Funcionamiento de la conmutación de paquetes y de mensajes

3.2.3. Conmutación de paquetes con circuito virtual Aunque la conmutación de paquetes es mejor que la conmutación de mensajes, ambas soluciones tienen el problema de que, dependiendo del tamaño y el estado de las colas de los nodos intermedios, el retardo en la llegada de la información es variable. Ello implica que en comunicaciones críticas en tiempo (como una conversación de voz) se pueda llegar a crear un problema; por ejemplo, si un paquete de voz llega demasiado tarde, no podrá ser descodificado y el otro interlocutor notará un pequeño corte en la conversación. Para minimizar este problema aparecieron lo que se conoce como conmutación de paquetes con circuito virtual, que tiene por objetivo reunir las ventajas de los dos paradigmas. Así, en vez de enviar de forma independiente todos los paquetes de una conexión, lo que hacen los circuitos virtuales es decidir el camino previamente (como con conmutación de circuitos), pero manteniendo el envío de paquetes individuales, de manera que ahora todos los paquetes seguirán el mismo camino, por lo que podemos tener una reserva de recursos.


15

© FUOC • PID_00147725


3.3. Alcance de las redes Una clasificación bastante clásica de las redes es la que se hace en función de su alcance, aunque, dependiendo del entorno, esta clasificación puede cambiar. Generalmente se consideran dos categorías: las redes de gran alcance1 y las 2

redes de alcance local . Antes de detallar qué son las LAN y las WAN es conveniente introducir en primer lugar los conceptos de redes de difusión y redes punto-a-punto.

Una red de difusión (o broadcast) es aquella en la que el medio es compartido por todas las estaciones que forman la red; así, todos los equipos reciben todos los paquetes, pero sólo procesan los dirigidos hacia ellos.

Entre otras cosas, una red de difusión comporta serios problemas de privacidad; por eso, en este tipo de redes es recomendable utilizar mecanismos de cifrado en las conexiones, como, por ejemplo, en las redes sin hilos.

Las redes punto-a-punto, en contraposición a las redes de difusión, son aquellas en las que las conexiones son dedicadas entre dos puntos determinados de la red.

A pesar de que un enlace punto-a-punto puede parecer poco flexible, en la realidad es el tipo de conexión más utilizado actualmente, ya que se puede desplegar para formar topologías en estrella, en árbol o en malla de forma muy sencilla. Dependiendo del sentido de la comunicación que permiten, los enlaces punto-a-punto pueden ser: •

Simplex. La comunicación es unidireccional, uno de los dos puntos es siempre el origen, y el otro, el destino.

•

Semidúplex�(Half-duplex). La comunicación puede ser bidireccional, pero siempre y cuando los dos puntos de la comunicación alternen la generación de tráfico, ya que si enviaran al mismo tiempo se provocaría una colisión que invalidaría ambas transmisiones.

•

Dúplex�(Full-duplex). El caso más común actualmente es cuando el medio está preparado para poder enviar y recibir información de forma simultánea sin ningún problema.

Hay que señalar que con las comunicaciones bidireccionales la velocidad puede ser igual (conexión simétrica) o diferente dependiendo del sentido de la comunicación (conexión asimétrica).

(1)

En inglés, Wide Area Networks (WAN). (2)

En inglés, Local Area Networks (LAN).

Otras categorías de redes Hay otras categorías de redes, como las redes metropolitanas (Metropolitan Area Network, MAN) o las redes personales (Personal Area Network, PAN), aunque normalmente se las puede incluir dentro de las redes LAN.

© FUOC • PID_00147725

16


3.3.1. Redes de gran alcance Redes de gran alcance3 se consideran aquellas que se utilizan en espacios geográficos extensos. Generalmente, las WAN se encargan de la interconexión de

(3)

En inglés, Wide Area Networks (WAN).

las LAN, facilitando así la conexión de los usuarios de diferentes localizaciones. La transmisión de datos se suele hacer mediante grandes operadoras de comunicaciones con líneas de comunicación contratadas (leased lines), utilizando infraestructuras que se consideran públicas (para evitar monopolios). Las conexiones WAN son prácticamente siempre punto-a-punto, exceptuando los enlaces vía satélite, que, por el hecho de utilizar el aire como medio de transmisión, son inherentemente medios de difusión. Por su gran extensión, las redes WAN, en general, están compuestas por topologías en árbol que están conectadas con topologías en malla, formadas por miles de nodos. 3.3.2. Redes de área local Por el contrario, en las WAN, las redes de alcance local4 están diseñadas para tener un alcance más reducido, que puede oscilar entre unos pocos kilómetros

(4)

En inglés, Local Area Networks (LAN).

y algunos metros (incluso centímetros). Las tecnologías LAN están pensadas para conectar usuarios con pocos equipos, edificios empresariales o incluso campus enteros. Normalmente, estas LAN se acaban conectando en WAN; actualmente, esta interconexión masiva de LAN y WAN a escala global se conoce como Internet. Clásicamente, las LAN han utilizado un medio de difusión para enviar la información, pero desde la aparición de los conmutadores y otros equipamientos más actuales han pasado, mediante topologías en árbol y en estrella, a ser un conjunto de conexiones punto-a-punto. La excepción a esta regla vuelven a ser las redes que utilizan el aire como medio de transmisión, las redes sin hilos, que utilizan difusión para enviar la información. 3.4. Tecnologías de red La última clasificación del hardware de red hace referencia a las diferentes tecnologías existentes para hacer una red, la lista de tecnologías de red existentes en la actualidad es demasiada extensa para poder listarla; aquí se introducen las tecnologías más importantes en la actualidad, cuya lista comprende las tecnologías cableadas y las tecnologías sin hilos.

Redes sin hilos Hay muchos tipos de redes sin hilos, y no todos pueden ser clasificados como LAN, por ejemplo, el de las redes de telefonía móvil.

17

© FUOC • PID_00147725


3.4.1. Tecnologías de red cableada Dentro de las redes cableadas, la familia de tecnologías por excelencia es Et5

hernet (definido en el estándar IEEE 802.3) , que empezó como una tecnología

(5)

IEEE es la abreviatura del Institute of Electronic and Electrical Engineers.

a 10 Mbps con una topología en bus y medio compartido, y que ha ido evolucionando a una topología en estrella a 1 Gbps (Gigabit Ethernet) pasando por Fast Ethernet, todavía muy utilizado en la actualidad a 100 Mbps. A pesar de empezar siendo una tecnología limitada a LAN, Ethernet ha evolucionado tanto, gracias a su bajo coste y a su gran aceptación, que actualmente hay enlaces WAN construidos con esta tecnología. Por lo que respecta a las topologías basadas en anillo, como Token Ring (IEEE 802.5) y FDDI (definido en el estándar ANSI X3T12), han ido cayendo en desuso, en relación con Ethernet, principalmente a causa de su coste más alto y peor rendimiento. Actualmente, una topología en anillo muy utilizada es Resilient Packet Ring (IEEE 802.17), una tecnología para transportar otras tecnologías a través de anillos de fibra óptica; normalmente se transporta directamente tráfico Ethernet y servicios IP. 3.4.2. Tecnologías de red sin hilos Un punto en el que ha habido una gran expansión en los últimos años es el relativo a la aparición de tecnologías de red sin hilos. De este tipo de redes se pueden extraer principalmente dos, las redes de telefonía móvil y las redes sin hilos de más corto alcance. Entre los muchos tipos de redes de telefonía móvil que hay se puede mencionar el del Global System for Mobile Communications (GSM), que fue de los primeros sistemas que apareció y permite el envío de datos a 9,6 Kbps, para evolucionar al más actual General Packet Radio Service (GPRS), con un ancho de banda máximo teórico de 171,2 Kbps, pero cuyo canal de bajada es efectivamente de 64 Kbps y el de subida de 14 Kbps. La última implementación en tecnologías de red móviles es la Universal Mobil Telecommunication Services (UMTS), también conocida como el sistema de tercera generación (3 GR), que, con unos sistemas más avanzados, es capaz de llegar a velocidades teóricas de 21 Mbps, pero con velocidades efectivas de 7,2 Mbps de bajada y 384 Kbps de subida. Con respecto a las redes sin hilos de más corto alcance, la tecnología por excelencia usada es la Wireless LAN (WiFi - IEEE 802.11), que inicialmente fue definida con una velocidad de 11 Mbps, pero que con posteriores revisiones del estándar se ha diseñado para soportar velocidades de 54 Mbps, con un alcance aproximado de 100 metros. En los últimos años, con el fin de reducir el consumo energético de las comunicaciones sin hilos con equipos de baja potencia, ha aparecido el estándar de facto para la comunicación de equipos

10 Gigabit Ethernet También existen modelos de 10 Gigabit Ethernet, pero su implantación todavía está en sus inicios.

© FUOC • PID_00147725

18

pequeños (móviles, PDA...), que es Bluetooth, con una velocidad de 1 Mbps y un alcance aproximado de 10 metros, pero con un consumo energético muy bajo que lo hace muy atractivo para transferencias de datos cortas. Finalmente, una tecnología que se queda entre el corto y el largo alcance es WiMAX (IEEE 802.16), una tecnología sin hilos muy utilizada en la actualidad para dar conectividad a zonas aisladas y de difícil acceso, donde la comunicación cableada es muy cara. WiMAX tiene una velocidad máxima aproximada de 150 Mbps de bajada y 35 Mbps de subida, con un alcance de unos 70 kilómetros.


19

© FUOC • PID_00147725


4. Dispositivos de red

Las redes de hoy en día funcionan porque hay una serie de dispositivos que son capaces de gestionar tanto la información de control y presencia de los nodos de una red como la información que dichos nodos se transmiten. Básicamente, los dispositivos de red son los siguientes: •

Encaminador�o�enrutador6. Es un dispositivo de red de nivel 3 del mo-

(6)

En inglés, router.

7

delo OSI . Recoge la información del nivel de red (dirección IP) para tomar las decisiones de encaminamiento: escoger el camino o ruta más adecuada por donde reenviar los datos recibidos. La sucesión de decisiones de dife-

(7)

OSI es la abreviatura de Open Systems Interconnection (interconexión de sistemas abiertos).

rentes routers posibilita la llegada de la información desde su origen hasta el sistema informático de destino. •

Concentrador8. Es un dispositivo de red que permite agrupar un conjunto de dispositivos Ethernet en un mismo segmento de red. Actúa en el primer nivel del modelo OSI o nivel físico, sin entrar por lo tanto a analizar las direcciones MAC de destino. Por ello, todo lo que llega es reenviado indiscriminadamente a todos los ordenadores conectados. Router

•

9

Conmutador . Es un dispositivo digital de lógica de interconexión de re-

(8)

En inglés, hub.

des de computadores que opera en la capa 2 (nivel de enlace de datos) del modelo OSI. Su función es interconectar dos o más segmentos de red, de manera similar a los puentes (bridges), pasando datos de un segmento a otro de acuerdo con la dirección MAC de destino de las tramas en la red. Los conmutadores se utilizan cuando se desea conectar múltiples redes que se fusionan en una sola. Igual que los puentes, ya que funcionan como un filtro en la red, mejoran el rendimiento y la seguridad de las LAN.

Concentrador (9)

•

10

Puente�de�red . Es un dispositivo de interconexión de redes de ordena-

En inglés, switch.

dores que opera en la capa 2 (nivel de enlace de datos) del modelo OSI. Éste interconecta dos segmentos de red (o divide una red en segmentos) Conmutador

permitiendo el paso de datos de una red a otra mediante el uso de la dirección física de destino de cada paquete. Un bridge conecta dos segmentos de red como una sola red utilizando el mismo protocolo de establecimiento

(10)

En inglés, bridge.

de red. •

Tarjeta�de�interfaz�de�red. Físicamente es una tarjeta de expansión insertada dentro del ordenador con una o más aberturas externas por donde se 11

conecta el cable de red. En el plano conceptual, la tarjeta de red , también llamada adaptador de red, permite la comunicación entre los diferentes dispositivos conectados entre sí y, asimismo, la distribución de recursos entre dos o más equipos. Hay diversos tipos de adaptadores en función del

Puente de red

© FUOC • PID_00147725

20

tipo de cableado o arquitectura que se utilice en la red (coaxial fino, coaxial grueso, Token Ring, etc.), pero el más común actualmente es el Ether-

Conceptos de redes de computadores (11)

En inglés, network interface card (NIC).

net, que utiliza una interfaz o conector RJ-45. Cada tarjeta de red tiene un número de identificación único de 48 bits en hexadecimal, denominado dirección MAC. Estas direcciones de hardware son únicas y están administradas por el Institute of Electronic and Electrical Engineers (IEEE). Tarjeta de red

© FUOC • PID_00147725

21


5. Software de red

Cuando aparecieron las redes de computadores, los fabricantes hacían el diseño pensando que todo el proceso de red se haría mediante hardware, y, además, asumían que los protocolos y los mecanismos a utilizar serían propietarios, sin un sistema estándar, y sin que hubiera un acuerdo conjunto entre los fabricantes para interactuar. De todas formas, a medida que fueron evolucionando las redes, se vio que si no se planteaba algún tipo de estandarización, una vía común con el fin de interconectar tecnologías y utilizar mecanismos regulados, los esfuerzos de cada fabricante serían demasiados grandes y la lucha no beneficiaría a nadie. Fue entonces cuando algunos fabricantes, como IBM, empezaron a ver que era más viable pasar una buena parte de la carga de la red al software, mucho más flexible y barato de producir que el hardware. Por eso apareció lo que se conoce como las arquitecturas de red organizadas por capas, cuyos ejemplos más importantes son OSI y TCP/IP12. Ejemplo de arquitectura de red con cuatro capas

(12)

TCP/IP es la abreviatura de Transmission Control Protocol/Internet Protocol.

© FUOC • PID_00147725

22

5.1. Arquitectura de la red: diseño por capas Históricamente, las primeras redes se diseñaron teniendo sólo en cuenta el hardware de las comunicaciones. Esta estrategia no tuvo mucho futuro y las redes evolucionaron hacia una combinación de software de red muy estructurado y hardware genérico. Para reducir la complejidad del diseño, las redes están organizadas en una serie de capas, situadas unas encima de otras. El número de capas, el nombre de cada una de ellas, su contenido y sus funciones difieren de un tipo de red a otro. En todas las redes, el objetivo de cada capa es ofrecer determinados servicios a las capas superiores, ocultándoles a éstas los detalles de cómo están implementados los servicios que se ofrecen. La capa de nivel N de un ordenador mantiene comunicación con la capa de nivel N de otro ordenador. Las reglas y convenciones usadas en la capa de nivel N se denominan protocolos. Básicamente, un protocolo es un acuerdo entre las partes de la comunicación sobre cómo se realiza ésta. En la siguiente figura se muestra una pila de protocolos: las entidades que utilizan las correspondientes capas en los diferentes ordenadores se llaman pares (peers). En otras palabras, los pares se comunican usando un protocolo.

En la realidad, la información no se transfiere directamente de una capa N de una máquina a la capa N de otra máquina. Cada capa pasa la información y el control de ésta a la capa inmediatamente inferior, y así sucesivamente hasta llegar a la última capa. Esta última capa se denomina capa física, y es en ella


© FUOC • PID_00147725

23

donde se produce la comunicación real. En la figura anterior, la comunicación virtual (capa N con capa N) se muestra en líneas punteadas, y la comunicación física o real en la capa física. Entre cada par de capas adyacentes existe una interfaz. La interfaz define las operaciones primitivas y los servicios que la capa inferior ofrece a la capa superior. Cada capa ofrece una colección de funciones perfectamente definidas. Por ello, es muy sencillo reemplazar la implementación de una capa por otra capa con diferente implementación (si queremos cambiar el medio de transmisión de la información, sólo hay que cambiar la capa de nivel 1, por ejemplo, las líneas telefónicas por canales por satélite, manteniendo el resto intacto).

El conjunto de capas y protocolos se denomina arquitectura de la red. La lista de protocolos, un protocolo por capa, se llama la pila de protocolos.

Para explicar las comunicaciones multicapa, observemos la siguiente figura.


© FUOC • PID_00147725

24

Imaginemos que tenemos dos filósofos (procesos pares (peer), capa 3). Un filósofo habla urdu e inglés, y el otro, chino y francés. Como no hablan ninguna lengua en común necesitan un traductor (capa 2), y cada traductor se pone en contacto con su secretaria (capa 1) para enviar la información remotamente al otro filósofo. El filósofo 1 quiere enviar un mensaje al filósofo 2. Así pues, pasa el mensaje en inglés a través de la interfaz 2/3 a su traductor, que traduce el mensaje en una lengua neutral (neerlandés). La elección de la lengua de la capa 2 es la misma en las dos entidades remotas. Después, el traductor pasa el mensaje a la secretaria para que ésta lo transmita vía fax (capa 1) a la otra secretaria. Cuando el mensaje llega a la secretaria remota, ésta lo pasa al traductor remoto (capa 2), y traduce el mensaje al francés para pasarlo finalmente al filósofo remoto. Hay que tener en cuenta que cada protocolo es independiente de los otros en la pila de protocolos, y que podemos cambiar un protocolo por otro mientras las interfaces no cambien. Por ejemplo, la secretaria podría optar por transmitir los mensajes por fax o enviarlos por correo postal, teléfono o correo electrónico, sólo cambiando la capa 1 sin cambiar la interfaz 2/1. Observemos la siguiente figura. Consideremos que se produce la comunicación de la capa superior. Un mensaje M es producido por un programa (o proceso) que funciona en la capa de nivel 5. La capa 5 envía el mensaje M a la capa 4. La capa 4 pone la cabecera antes del mensaje para identificar el mensaje y le pasa el resultado a la capa 3. La cabecera incluye el control de la información, como los contadores de control de secuencia, para permitir que la capa 4 de la máquina destino reciba los mensajes en el orden correcto, ya que las capas inferiores no tienen ninguna obligación de mantener la secuencia. En las otras capas, las cabeceras mantienen tamaños, tiempos y otros campos de control.

En muchas redes no existe límite en el tamaño de los mensajes transmitidos en la capa de nivel 4, pero muchas veces el protocolo de nivel 3 sí que impone restricciones. Consecuentemente, la capa 3 tiene que partir el mensaje que le


© FUOC • PID_00147725

25

envía la capa superior en varias unidades menores, denominadas paquetes; la capa de nivel 3 introduce una cabecera de nivel 3 en cada paquete. En este ejemplo, M queda dividido en dos partes, M1 y M2. La capa de nivel 3 decide qué línea de salida transmitirá los paquetes a la capa de nivel 2. La capa de nivel 2 añade una cabecera a cada trozo y ofrece el resultado a la capa de nivel 1 (física) para su transmisión. En el ordenador que recibe la información se envía el mensaje a la capa superior, capa por capa, con las cabeceras que se van eliminando a medida que se progresa de forma ascendente de capa en capa.

5.2. Consideraciones de diseño El nivel por capas se da una forma estructurada de diseñar y abstraer las tareas necesarias con el fin de enviar información a través de la red, pero cuando se diseña una arquitectura de red hay muchos más factores, aparte de las capas, que se tienen que considerar. Los siguientes son los más relevantes: 1)�Identificación: cada nodo de la red se tiene que poder identificar de forma única con el fin de identificar a sus interlocutores. 2)�Encaminamiento: los nodos de la red han de tener mecanismos que permitan enviar la información a cualquier interlocutor de la misma red. 3)�Control�de�errores: una de las partes más importantes de cualquier comunicación es garantizar que, cuando la información llegue al otro nodo, lo haga sin errores. Hay que señalar que los medios de transmisión no siempre son fiables, por lo que se tiene que decidir cuál o cuáles capas verificarán errores y cómo lo harán.


© FUOC • PID_00147725

26

4)�Modos�de�transferencia: qué soporte tendrá el protocolo para el envío de información, si se puede enviar información en modo full duplex, half duplex o simplex. Y, caso de que sea necesario, si habrá algún tipo de priorización en el envío. 5)�Control�de�congestión: dado que las velocidades de transmisión de una red no siempre son homogéneas y que a veces habrá enlaces con más carga que otros, cualquier protocolo tiene que considerar la posibilidad de que se tenga que disminuir la velocidad a la que se envían los datos, o bien, en el caso de que algún paquete no llegue al destino, de que se tenga que reenviar de forma transparente al usuario. 6)�Tamaño�de�los�paquetes: como ya hemos visto anteriormente, enviar mensajes muy grandes no siempre es posible, por lo que se tiene que decidir qué tamaño máximo podrán tener los paquetes que se envían a la red.


© FUOC • PID_00147725

27

6. Jerarquía de protocolos y cabecera

Cada capa necesita un mecanismo para identificar al emisor y el receptor. Una red tiene diversos nodos y en cada uno de ellos se ejecutan múltiples procesos. Cada proceso tiene que saber con quién se quiere comunicar, teniendo en cuenta que los destinos pueden ser diversos. De esta manera se hace necesaria una forma de direccionamiento que nos permita determinar un destino específico. Otra característica del diseño de un protocolo es si los datos sólo viajan en un solo sentido (comunicación simplex) o lo hacen en las dos direcciones, pero no simultáneamente (comunicación half duplex), o viajan en las dos direcciones simultáneamente (comunicación full duplex). El protocolo tiene que determinar cuántos canales lógicos tiene que gestionar, y las prioridades de estos canales. Muchas redes permiten como mucho dos canales lógicos, un canal para datos normales y un canal para datos urgentes. El control de los errores es otro aspecto importante, ya que los enlaces de comunicaciones físicos no son perfectos. Determinados códigos de detección y corrección de errores se utilizan, y los ordenadores que se comunican se tienen que poner de acuerdo en la utilización de un código corrector/detector concreto. Además, el receptor de la información tiene que comunicar al emisor de los mensajes que se han recibido o no correctamente. No todos los canales de comunicación preservan el orden de envío de los mensajes. Para solucionar la posible pérdida de la secuencia de los mensajes, el protocolo tiene que gestionar los diferentes trozos de información en una memoria (buffer) para finalmente ordenarlos correctamente. Otro aspecto que se tiene en cuenta es el de cuando un emisor transmite información muy rápidamente hacia un receptor lento. Muchas soluciones utilizan una técnica que consiste en que el receptor envíe una señal al emisor indicándole su problemática. Otras soluciones limitan la velocidad del emisor cuando supera un cierto umbral. Otro problema es que determinados niveles acepten mensajes de una longitud que supere un cierto límite. Por eso se utilizan mecanismos para desensamblar, transmitir y reensamblar mensajes. A veces, el canal físico de transmisión es compartido por muchas conexiones que intentan transmitir a la vez sobre un mismo enlace. En este caso, la multiplexación y desmultiplexación de la capa física nos permite transmitir mucha información sobre pocos circuitos físicos.


© FUOC • PID_00147725

28

Cuando existen múltiples caminos entre el origen y el destino se tiene que elegir una ruta. Esta decisión se toma muchas veces entre dos o más capas.


© FUOC • PID_00147725

29

7. Interfaces y servicios

La función de cada capa es proporcionar servicios a la capa superior. En este apartado estudiaremos con más detalle lo que se denominan servicios. Los elementos activos de cada capa se llaman entidades (entities). Cada entidad puede ser una entidad de software (como un proceso) o de hardware (como un dispositivo inteligente de entrada-salida). Las entidades de la misma capa de diferentes máquinas se llaman peer entities. La capa N puede usar los servicios de la capa N - 1 para proporcionar su propio servicio. Una capa puede ofrecer múltiples clases de servicios, por ejemplo, comunicaciones caras y rápidas, o comunicaciones lentas y baratas. Los servicios están disponibles en los Service Access Point (SAP). El SAP de la capa N son los lugares en los que la capa N + 1 puede acceder a los servicios ofrecidos. Cada SAP tiene una dirección única que lo identifica. Para hacer este punto más claro, el SAP en el sistema de telefonía son los conectores a los que se conectan los aparatos de teléfono, y la dirección SAP es el número de teléfono de este conector. En el sistema postal, la dirección SAP es el nombre de la calle y el número de la vivienda. Para enviar una carta postal, tienes que conocer la dirección SAP. A fin de que dos capas se intercambien información, se tienen que definir una serie de normas sobre la interfaz. En una interfaz típica, la entidad de la capa N + 1 pasa una Interface Data Unit (IDU) hacia la entidad de la capa N a través del SAP tal como se muestra en la siguiente figura. La IDU consiste en un Service Data Unit (SDU) y determinada información de control (Interface Control Information). La SDU es la información pasada a través de la red hacia la peer entity y subida después hacia la capa remota N + 1. La información de control se necesita para ayudar a la capa inferior a realizar su trabajo (por ejemplo, indicar el número de bytes del SDU), pero no forma parte de la información pura. Para transmitir la SDU, la entidad de la capa N tiene que fragmentar ésta en varios trozos, a cada uno de los cuales se asigna una cabecera, que se envían como un Protocol Data Unit (PDU) o paquete. A través de las cabeceras de la PDU, la peer entity identifica qué PDU contienen datos y cuáles contienen información de control, proporcionando números de secuencia y contadores.


© FUOC • PID_00147725

30

Las capas pueden ofrecer dos tipos diferentes de servicios a las capas superiores: conexiones orientadas y no orientadas a conexión. Un servicio orientado a conexión se modela como un sistema de telefonía: para hablar con alguien, primero tenemos que marcar el número de teléfono, después, hablar, y, finalmente, colgar el teléfono. Así, inicialmente se produce un establecimiento de conexión, después se utiliza la conexión para hablar y transmitir información, y, finalmente, se cierra la conexión. Esta conexión actúa como un tubo: el emisor envía objetos o bits hacia el receptor, y el receptor los coge en el mismo orden en que le son enviados. Un servicio no orientado a conexión se modela como un sistema postal. Cada mensaje o carta postal lleva la dirección completa del destinatario, y cada carta la envía el sistema independientemente de las otras cartas. Normalmente, de dos mensajes que se envían al mismo destino, el primero que se envíe será el primero que se recibirá. También es posible que el enviado en primer lugar sufra algún retardo y que el enviado en segundo lugar llegue antes que el que se envió primero. En una conexión orientada a conexión eso es imposible. Cada servicio está caracterizado por lo que se denomina calidad de servicio. Muchos servicios son fiables en el sentido de que nunca pierden información. Normalmente, un servicio fiable se implementa mediante el envío de reconocimientos por parte del receptor de cada mensaje, y así el emisor sabe que el mensaje se ha recibido correctamente. El proceso de reconocimientos (ACK) introduce overhead (información de control redundante, no información útil) y un cierto retardo, cosa que normalmente no es deseable en términos de rendimiento de la red. La típica situación en la que se utiliza un servicio fiable orientado a conexión es la transmisión de ficheros. El usuario del servicio desea que los bits del fichero lleguen en el orden en que fueron emitidos, y que lleguen todos los bits del fichero. Para muchas aplicaciones, los retardos de los reconocimientos son inaceptables. Por ejemplo, en el caso del tráfico de voz digitalizada. Para los usuarios del teléfono es preferible oír por el auricular un poco de ruido de la línea o una palabra mal entendida de vez en cuando, que soportar que se produzca


31

© FUOC • PID_00147725

un retardo en la espera del reconocimiento. También cuando se transmite una película de vídeo es preferible tener varios puntos (píxeles) incorrectos (que en la práctica casi no son ningún problema) que tener que ver la película con paradas para corregir los errores (es muy irritante). Las conexiones no fiables (con la no utilización del mecanismo de reconocimiento) y las no orientadas a conexión se llaman servicio de datagrama (por ejemplo, el envío de e-mails). También en algunas situaciones es conveniente no tener que establecer una conexión para enviar un mensaje corto, pero en el que la fiabilidad tiene que ser esencial. Por eso se utilizan los servicios no orientados a conexión con reconocimiento (ACK). Por ejemplo, cuando se envía un e-mail, el receptor del correo electrónico, cuando lo ha recibido, le devuelve un e-mail al emisor para indicarle que lo ha recibido. Otro tipo de servicio es el request-reply-service: el emisor transmite un datagrama simple que contiene la petición. La respuesta contiene tanto la pregunta como la respuesta.

Un servicio se especifica formalmente con un conjunto de primitivas (operaciones) de las que el usuario u otra entidad puede disponer para acceder al servicio. Esas primitivas mandan realizar al servicio alguna acción o devolver el resultado de una acción de la entidad par (peer entity). La siguiente tabla nos muestra las maneras de clasificar las primitivas del servicio: Primitiva Request

Significado Una entidad quiere que el servicio realice alguna cosa.

Indication

Una entidad es informada de algún evento.

Response

Una entidad quiere responder a algún evento.

Confirm

La respuesta a la última petición se confirma.


© FUOC • PID_00147725

32

Consideremos cómo se establece y se libera una conexión. La entidad que establece la conexión realiza una CONNECT.request y el receptor recibe la CONNECT.indication anunciando que una entidad se quiere conectar al receptor. La entidad que recibe la CONNECT.indication utiliza la CONNECT.response para comunicar que acepta o rechaza la conexión propuesta. La entidad que realiza la petición de conectar recibe la aceptación o el rechazo de su conexión a partir de la primitiva CONNECT.confirm. Cada primitiva puede llevar parámetros o no. Por ejemplo, la primitiva CONNECT.request tiene que especificar la dirección de la máquina a la que se quiere conectar, el tipo de servicio deseado y la longitud máxima del mensaje a utilizar durante la conexión. Los parámetros de la CONNECT.indication tienen que contener la identidad de quien realiza la llamada, el tipo de servicio deseado y la longitud máxima del mensaje propuesta. Si la entidad llamada no acepta la longitud máxima del mensaje propuesta, puede realizar con la primitiva response una nueva propuesta sobre la longitud del mensaje. Los detalles de cada negociación forman parte de cada protocolo. Los servicios pueden ser confirmados o no ser confirmados. En un servicio confirmado están las primitivas request, indication, response, confirm. En un servicio no confirmado sólo están las primitivas request e indication. El servicio CONNECT sólo se utiliza en los servicios confirmados porque la entidad remota tiene que dar el visto bueno al establecimiento de la conexión. Las ocho primitivas de un servicio orientado a conexión son las siguientes: 1) CONNECT.request: pedir el establecimiento de la conexión. 2) CONNECT.indication: indicar a la parte solicitada un establecimiento de conexión. 3) CONNECT.response: utilizado por la parte solicitada para aceptar/rechazar la conexión o llamada. 4) CONNECT.confirm: indicar al que la ha solicitado si la conexión o la petición ha sido aceptada. 5) DATA.request: indicar que se envía la información. 6) DATA.indication: indicar la llegada de la información. 7) DISCONNECT.request: indicar que la conexión se ha cerrado. 8) DISCONNECT.indication: indicar a la otra entidad el cierre de la conexión.


© FUOC • PID_00147725

33

En este ejemplo, el servicio CONNECT es confirmado, mientras que el servicio DISCONNECT es no confirmado. La siguiente figura muestra la misma secuencia antes descrita. Cada paso incluye una interacción entre dos capas de una de las computadoras. Cada petición o respuesta provoca una indicación o confirmación en la otra parte. El usuario del servicio está en la capa N + 1, y la capa N es la capa que ofrece el servicio.

Los protocolos y los servicios son dos conceptos distintos, aunque en general se suelen confundir. Un servicio es un conjunto de primitivas (operaciones) que una capa proporciona a la capa superior. El servicio define qué operaciones es capaz de ofrecer la capa, pero no dice nada de cómo están implementadas estas operaciones. Un servicio es una interfaz entre dos capas, siendo la capa de nivel inferior la que proporciona el servicio, y la capa de nivel superior la que lo utiliza. Un protocolo es un conjunto de normas que gobiernan el formato y el significado de las tramas, paquetes o mensajes que se intercambian las entidades dentro de una misma capa. Las entidades utilizan los protocolos para implementar las definiciones del servicio.

Un servicio sería como un tipo abstracto de datos o un objeto en los lenguajes de programación. Define las operaciones que se pueden realizar sobre el objeto pero no especifica cómo se implementan las operaciones. Un protocolo relata cómo se implementa el servicio y, si es posible, cómo hacer que no sea visible para el usuario del servicio.

7.1. Tipo de conexión de servicios Cada servicio establece una conexión con el servicio análogo del equipo de destino; dependiendo de cómo se gestione esta conexión entre servicios, un servicio puede ser orientado a conexión o no orientado a conexión.


© FUOC • PID_00147725

34

El servicio orientado a conexión previo al envío de información se establece una conexión, que se libera cuando la transferencia acaba. No hay que confundir un servicio orientado a conexión con la conmutación de circuitos vista anteriormente; en el servicio orientado a conexión no se realiza ninguna reserva de recursos, sino una estructura de datos que mantiene el estado de la


Protocolo orientado a conexión El ejemplo por excelencia de un protocolo orientado a conexión es el TCP.

conexión. El hecho de que un protocolo sea orientado a conexión implica que la información tiene que llegar ordenada y sin errores. El hecho de mantener la conexión implica que ambos extremos son conocidos y, por lo tanto, no es necesario indicar qué destino tiene la comunicación. Este paso se realiza durante el establecimiento de la conexión. Por su parte, los servicios no orientados a conexión no precisan ni asumen ninguna conexión previa entre los dos interlocutores; de esta manera, la información se separa en paquetes (denominados datagramas en este tipo de servicios) y se envía a la red sin conocer el camino que seguirán los paquetes, ni saber si llegarán a su destino, ni siquiera en qué orden lo harán, cada datagrama se envía de forma autónoma e independiente del resto. Por lo tanto, para poder enviar un datagrama con un protocolo no orientado a conexión, el datagrama tiene que tener la dirección destino, y los elementos intermedios de la red tienen que tener información de cómo hacer llegar la información dependiendo del destino de cada datagrama recibido.

Servicios no orientados a conexión El ejemplo por excelencia de servicios no orientados a conexión es IP. Curiosamente, HTTP es también un protocolo no orientado a conexión.

© FUOC • PID_00147725

35

8. Modelos de referencia

Las dos arquitecturas de red más conocidas hoy en día son la Open Systems Interconnection (OSI), utilizada como modelo teórico, y la Transmission Control Protocol/Internet Protocol (TCP/IP), cuyo éxito en el mundo de las redes ha sido enorme. 8.1. Necesidad de estandarización Los primeros ordenadores realizaban trabajos concretos, ubicados en lugares cerrados y aislados. Cada fabricante vendía su sistema de comunicaciones integral a las empresas, encargándose de todos los aspectos relacionados con la red (equipos, software, cableado, etc.). Cuando una empresa necesitaba alguna ampliación y/o modificación, sólo podía contar con un único interlocutor para proporcionarle los servicios necesarios. Eso acarreaba varios problemas, tales como: •

Los costes eran elevados, ya que los adaptadores eran a medida.

•

Nula interoperabilidad, ya que resultaba imposible interconectar unos sistemas con otros, a causa de la falta de compatibilidad entre dispositivos. Cuando se elegía un suministrador era para siempre.

Con estas limitaciones, a partir de los años ochenta empezaron a aparecer organizaciones que construían equipos para interconectar redes y pasarelas entre ordenadores de diferentes fabricantes. Podemos destacar los siguientes hitos: 1) Tres empresas, DEC, INTEL y XEROX (Consorcio DIX), se pusieron de acuerdo para crear un primer estándar para redes de área local para la red ETHERNET. En 1982, DIX distribuyó la versión II de Ethernet, que es la versión estándar para TCP/IP. 2) El comité 802.3 de IEEE recogió la versión de DIX y empezó a trabajar en una trama Ethernet mejorada. La red Ethernet tenía un coste bajo y altas prestaciones, junto con una sencillez de operación. 3) El sistema operativo UNIX, creado por BELL Laboratories, empezó a popularizarse, y diversas organizaciones (empresas y universidades) lo implementaron en sus sistemas (BSD-UNIX de Berkeley, Xenix, SUNOS, HP-UX, etc.). Ésta fue la principal causa de la extensión de TCP/IP, dado que estaba incluido en su kernel.


36

© FUOC • PID_00147725


4) Creación de un modelo de referencia OSI de ISO. Estos hechos provocaron que los sistemas que hasta este momento ofrecían una arquitectura cerrada pasaran a una arquitectura abierta y que las redes empezaran a ser compatibles. Se empezaron a estandarizar componentes y funcionalidades de cada nivel arquitectural para poder intercomunicar los sistemas heterogéneos. La información de los estándares se hace pública, hecho que no pasaba con los sistemas propietarios. Se crean fórums externos a los organismos que pueden llegar a forzar a éstos a decidirse por uno u otro estándar (ATM Forum, Forum Gigabit Ethernet, Forum ADSL, etc.). La existencia de estándares tiene las siguientes ventajas y desventajas, que se muestran en la tabla siguiente. Ventajas • • • • •

Estimula la competitividad entre los fabricantes Evita monopolios Baja los precios Flexibilidad de instalar equipos Heterogeneidad de fabricantes

Desventajas • • • • • •

Tardanza al aprobarse Los fabricantes crean equipos en condiciones propietarias Los intereses de los fabricantes y los organismos no siempre son los mismos Posibilidad de acuerdos más políticos y comerciales que técnicos Los fabricantes son los que desarrollan más I+D, lo cual provoca que los organismos tengan que definirse Muchos organismos pueden afectar a la estandarización, ya que se puede llegar a clasificar geográficamente, por industria, etc.

8.2. El modelo de referencia OSI Entre los diferentes modelos propuestos por las diferentes organizaciones internacionales de normalización en la década de los ochenta, destaca una arquitectura de redes de ordenadores basada en niveles, el modelo OSI, definido por la Organización Internacional de Estándares (ISO, International Organization for Standardization). A finales de los setenta, la ISO fue definiendo la arquitectura de redes OSI con el fin de promover la creación de una serie de estándares que especificaran un conjunto de protocolos independientes de cualquier fabricante. Pretendía establecer las normas y estándares para que el software y los dispositivos de diferentes fabricantes pudieran funcionar juntos.

Perjuicios económicos Hay importantes ganancias económicas para las empresas que han desarrollado un sistema y éste se convierte en estándar. No obstante, ello puede provocar que otras empresas salgan perjudicadas.

© FUOC • PID_00147725

37

Además de facilitar las comunicaciones entre sistemas diferentes, la ISO pretendía con OSI impedir que ninguna de las arquitecturas de fabricante existentes adquiriera una posición hegemónica, especialmente la SNA13 de IBM. Seguramente, la aportación más importante de la iniciativa OSI ha sido precisamente la definición teórica de su modelo arquitectónico. Ésta ha servido como marco de referencia para describir y estudiar redes "reales". Por este motivo, a la arquitectura OSI se la denomina generalmente modelo de referencia OSI.

El modelo OSI está compuesto por niveles o capas, y en cada nivel se agrupan una serie de funciones o protocolos necesarios para comunicar sistemas. Los principios que se aplicaron para establecer estos siete niveles fueron los siguientes: 1) Una capa se creará en situaciones donde se necesite un nivel diferente de abstracción. 2) Cada capa tendrá que realizar una función bien definida. 3) Los problemas se resuelven en una capa concreta sin afectar al resto de las capas. 4) Cada capa se basa en los servicios de la capa inmediatamente inferior. 5) Cada capa ofrecerá servicios a las capas superiores sin que éstas sepan cómo se realizan los servicios. 6) La función que realizará cada capa se tendrá que seleccionar con la intención de definir protocolos normalizados internacionalmente. 7) Los límites de las capas se habrán de seleccionar teniendo en cuenta la necesidad de minimizar la cantidad de información que se tiene que pasar entre capas. La frontera entre capas tiene que ser la más sencilla posible. 8) El número de capas tiene que ser lo bastante grande para que funciones diferentes no tengan que ponerse juntas en la misma capa. También tendrá que ser lo bastante pequeño para que su arquitectura no sea difícil de manejar.

Las capas son las que se muestran en la figura siguiente.

Conceptos de redes de computadores (13)

SNA es la abreviatura de System Network Architecture.

© FUOC • PID_00147725

38


Las capas se pueden agrupar en dos subconjuntos convenientemente diferenciados: •

Capas�inferiores. Son proveedoras de servicios de transporte de las capas superiores. Tratan problemas tales como errores del sistema de transmisión, búsqueda de rutas óptimas, etc.

•

Capas�superiores. Su misión es dar servicios al usuario del sistema de comunicaciones. Confían en las prestaciones de los niveles inferiores.

El objetivo del modelo es el desarrollo de protocolos para desarrollar redes internacionales. Algunos protocolos se desarrollaron, pero otros, en cambio, se dejaron de lado en favor de Internet (TCP/IP). 8.2.1. Proceso de encapsulación y desencapsulación El modelo OSI describe cómo se desplaza la información desde los programas de aplicación de diferentes ordenadores en un medio de la red. Cada capa realiza dos procesos de comunicación: •

Comunicación�horizontal. Comunicación con su capa de igual nivel del otro sistema, que recibe el nombre de protocolo.

•

Comunicación�vertical. Comunicación con sus niveles inmediatamente superior e inferior, que recibe el nombre de primitivas de servicio.

Nota Hay que señalar la sospechosa coincidencia del número de capas de OSI con el de SNA, la arquitectura de red para grandes sistemas de IBM, que estaba en pleno apogeo en el momento en que se definió OSI.

39

© FUOC • PID_00147725


Cuando un usuario necesita transmitir datos a un destino, el sistema de red va añadiendo información de control (cabeceras) para cada uno de los servicios que utilizará la red para ejecutar la orden de transmisión.

8.3. Modelo TCP/IP (14) 14

En el modelo TCP/IP

se pueden distinguir cuatro capas:

•

La capa interfaz de red.

•

La capa de red o Internet.

•

La capa de transporte.

•

La capa de aplicación.

TCP/IP es la abreviatura de Transmission Control Protocol/Internet Protocol.

© FUOC • PID_00147725

40

Pasemos a describirlas brevemente.

La comparación de los modelos arquitectónicos de OSI y TCP/IP es la siguiente.


© FUOC • PID_00147725

41

El modelo OSI tiene siete capas, mientras que el modelo TCP/IP sólo tiene cuatro. Las capas de transporte y de Internet coinciden plenamente con los niveles 3 y 4 de la torre OSI. La capa de aplicación engloba los niveles 5, 6 y 7 de OSI (sesión, representación y aplicación). La capa interfaz de red incluye los niveles físico y enlace de la torre OSI. 8.3.1. Encapsulación de la información en el modelo TCP/IP El funcionamiento del modelo OSI con la encapsulación de los datos se puede observar en la siguiente figura.

Los datos de información del nivel aplicación son encapsulados en la capa de transporte, donde se le añade la cabecera del protocolo TCP, conformando la unidad de información denominada segmento. Cuando se envía el segmento al nivel de red, queda encapsulado dentro de la cabecera del protocolo IP donde se indican las direcciones IP de la unidad de información llamada paquete en este nivel. Este paquete es enviado a la tarjeta de red y allí es encapsulado según las normas del protocolo del nivel de enlace. Normalmente añade una cabecera del protocolo de enlace al principio del paquete. En muchos proto-


© FUOC • PID_00147725

42

colos también se añade una cola de datos que sirve para la detección de errores al final del paquete. La unidad de información aquí recibe el nombre de trama. Finalmente, los datos son enviados por el medio de transmisión en forma de impulsos electromagnéticos o bits. 8.4. Modelo OSI comparado con modelo TCP/IP El modelo OSI, de orientación más académica, es más coherente y modular y está menos condicionado por cualquier protocolo en particular. Por ello se utiliza principalmente como modelo de referencia para describir otros tipos de arquitecturas, como la TCP/IP (el modelo TCP/IP nunca se utiliza para describir otras arquitecturas que no sean la suya propia). El modelo OSI hace una distinción muy clara entre servicios, interfaces y protocolos, conceptos que a menudo se confunden en el modelo TCP/IP. El modelo OSI nunca ha pasado de ser un bonito desarrollo teórico, aunque la mayoría de los grandes fabricantes de ordenadores y compañías telefónicas impulsaron su utilización ofreciendo productos y servicios basados en él. Las razones principales que motivaron este fenómeno se resumen como sigue: •

OSI apareció tarde. Como todo estándar, se tardaron años en definir una arquitectura de capas con funcionalidades y servicios perfectamente definidos. Este retraso motivó que OSI fuera adelantado por TCP/IP, que en aquella época ya se utilizaba profusamente.

•

OSI, al inspirarse en SNA de I retraso BM, que es una arquitectura compleja, es muy complicado y muchas veces repite en diferentes capas las mismas funciones. El nacimiento de TCP/IP fue a la inversa: primero se especificaron los protocolos, y después se definió el modelo como una simple descripción de los protocolos ya existentes. Por este motivo, el modelo TCP/IP es más simple que el OSI.

•

Los productos comerciales que se basaron en OSI eran malos y caros. La poca demanda obligaba a las empresas desarrolladoras a fijar altos precios con el fin de recuperar sus costosísimas inversiones. En contraste, TCP/IP fue rápidamente incorporado al UNIX de Berkeley donde funcionaba bastante bien, y todo eso a un precio sensiblemente menor: ¡era gratuito!

•

Mientras que TCP/IP era visto como parte de UNIX, es decir, una cosa que realmente funcionaba y estaba al margen de toda sospecha de parcialidad, OSI era considerado un invento de la Administración para controlar las telecomunicaciones (un engendro político-burocrático).


© FUOC • PID_00147725

43

Por todo eso, TCP/IP se convirtió en el líder mundial absoluto en interconexión de redes. No obstante, TCP/IP tampoco se libró de la crítica. Por una parte, no distingue conceptos tan importantes como servicio, interfaz y protocolo. En segundo lugar, el modelo TCP/IP no es ningún modelo, es decir, su utilización como esquema de referencia resulta bastante inútil en el estudio de otras arquitecturas. En tercer lugar, en el modelo TCP/IP la capa ordenador principal-red es más bien una interfaz que una capa, ya que la única cosa que se especifica de ella es que tiene que ser capaz de transmitir paquetes IP.


Difusión de TCP/IP y del modelo OSI Hoy en día, la difusión de TCP/ IP por toda Europa es completa, mientras que los servicios basados en protocolos OSI han desaparecido prácticamente.

© FUOC • PID_00147725

44


9. Breve historia de las comunicaciones

La década de los sesenta vio la aparición de los primeros ordenadores comerciales. Eran grandes, caros y poco potentes. Sólo los podían comprar organismos oficiales, grandes empresas o universidades, y lo más normal era que sólo compraran uno (o algunos, pero no uno para cada usuario, como hoy estamos acostumbrados a ver). Por eso, estos ordenadores tenían sistemas operativos multitarea y multiusuario, para que diferentes usuarios, haciendo diferentes trabajos, los pudieran utilizar simultáneamente. El acceso a estos ordenadores se hacía mediante terminales sin ninguna capacidad de proceso, pasivos. No tardó mucho en aparecer la necesidad de poder alejar los terminales de la unidad central para conectarse, por ejemplo, desde casa o desde una delegación al ordenador principal. Para poder hacer este acceso remoto, la primera solución que aportaron los ingenieros informáticos de la época fue utilizar la red telefónica que, por su ubicuidad, les evitaba tener que generar ninguna infraestructura nueva. Sólo

(15)

Recordad que la red telefónica sólo deja pasar sonidos entre unos márgenes de frecuencia.

hacía falta un aparato que adaptara los bits a la red15. Estos aparatos son los módems. Los primeros módems eran de 300 bps y generaban dos tonos diferentes: uno para el 1 lógico y otro para el 0. Actualmente, van a 56.000 bps, que es el máximo que permite la actual red telefónica convencional. Los módems no sólo servían para poder alejar los terminales pasivos de los ordenadores principales, también permitían interconectar ordenadores entre sí, de manera que desde los terminales de uno se podía acceder a los de otro y viceversa. Módems de los años ochenta

La tecnología de conmutación de circuitos se desarrolló originalmente para las comunicaciones telefónicas, y una de sus características fundamentales era la ocupación en exclusiva de los recursos mientras duraba la conexión, cosa que, como ya hemos visto, justificaba la tarificación por tiempo. Pero las comunicaciones informáticas no son cortas, intensas y esporádicas como las de voz. Al conectar un terminal a un ordenador principal mediante dos módems, no se pasan datos durante todo el rato que dura la conexión: puede haber largos períodos de tiempo en los que no pase ningún bit y ratos en los que haya un intercambio de datos intenso, aunque, desde luego, a una velocidad de transmisión mucho más baja que la que se puede mantener entre el terminal y el ordenador conectados directamente. Las facturas telefónicas empezaron a ser astronómicas, y desproporcionadas, respecto del uso real de la red. Períodos en la historia de Internet Internet es, como tantas otras tecnologías innovadoras, un invento militar. Nació del interés del ejército norteamericano en los años sesenta por conseguir comunicaciones

© FUOC • PID_00147725

45

fiables y descentralizadas. Es decir, para evitar que un misil bien dirigido pudiera hacer saltar por los aires un centro vital de comunicaciones. Se pueden establecer cuatro períodos clave en la historia de Internet: • • • •

Primer período: 1957-1970. Nacimiento de Internet. Segundo período: 1970-1990. Del Ejército a la Universidad. Tercer período: 1990-1995. Expansión fuera de los ámbitos militares y universitarios. Cuarto período: 1996-Actualidad. Multimedia y cientos de millones de usuarios.

Primer período: 1957-1970. Nacimiento de Internet Dentro del primer período de la historia de Internet podemos destacar los siguientes acontecimientos: •

1945: Publicación de la primera referencia a una red electrónica similar a Internet: "Memex", citado en el artículo "As We May Think", de Vannevar Bush (director de la Oficina de Investigación Científica y Desarrollo norteamericana).

•

1957: Durante la guerra fría, la Unión Soviética lanza el Sputnik, el primer satélite artificial de comunicaciones. En respuesta a este hecho, Estados Unidos crea el ARPA16, en el seno del Departamento de Defensa estadounidense.

•

1961: Leonard Kleinrock (MIT) publica el primer artículo sobre la teoría de conmutación de paquetes.

•

1962: Licklider (MIT) lanza la idea de la "Galactic Network", una red interconectada globalmente a través de la que cualquiera podría acceder desde cualquier lugar a datos y programas. Licklider fue el principal responsable del programa de investigación en ordenadores en ARPA, la agencia de investigación avanzada del Pentágono.

•

1964: Paul Baran (RAND Corporation) realiza sus estudios sobre "Redes de comunicación distribuidas o descentralizadas". También promueve el uso de redes de conmutación de paquetes de datos (Packet Switching Networks).

•

1961-1965: La idea de red de paquetes descentralizada había sido trabajada en paralelo por tres grupos de investigación americanos, sin que los investigadores conocieran el trabajo de los otros. – MIT (1961-67): Licklider, Roberts, Kleinrock. –

RAND (1962-65): Paul Baran.

–

NPL (1964-67): Donald Davies y Roger Scantlebury. La palabra packet (paquete) fue adoptada a partir del trabajo del NPL17.

•

1965: El Ministerio de Defensa norteamericano (ARPA) inicia un proyecto de interconexión de computadores, que se llamó ARPANET y fue el antecesor de lo que después se llamaría Internet.

•

1966: Se desarrolla el concepto de red de ordenadores, que se llamaría ARPANET. La red ARPANET podía interconectar los diferentes ordenadores de los investigadores que se fueran conectando a esta red, naciendo así el Backbone Network.

•

1967: La nueva red, denominada ARPANet, recibe la señal de salida. Un año más tarde se diseñan los primeros programas y el primer hardware específico para redes.

•

1969: Hay cuatro centros interconectados a través de sus IMP (Internet embrionaria). UCLA (Los Ángeles) es seleccionada para ser el primer nodo de ARPANET. El centro de investigación de Standford (SRI) proporciona un segundo nodo. El tercer nodo en la Universidad de California, Santa Bárbara, y el cuarto nodo en la Universidad de Utah. Estos cuatro nodos constituyeron la red original de ARPANet.

(16)

ARPA es la abreviatura en inglés de la Agencia de Proyectos de Investigación Avanzada.

(17)

NPL es la abreviatura de National Physical Laboratories (institución del Reino Unido).


© FUOC • PID_00147725

46

Pronto, las grandes empresas presionaron a las compañías telefónicas del momento para que desarrollaran redes pensadas para transportar datos, con un sistema de tarificación que se ajustara al tráfico de datos real y permitiera más velocidad que los escasos 300 o 1.200 bps que se alcanzaban en aquella época utilizando la red telefónica. La respuesta fueron las redes de conmutación de paquetes. El envío de datos no se tiene que hacer necesariamente en tiempo real (las transmisiones de voz, sí). Por lo tanto, no hace falta establecer el camino entre los dos puntos antes de empezar la transmisión y mantenerlo


CCITT El CCITT es un organismo internacional patrocinado por las operadoras de telefonía, dedicado a tareas de normalización en el ámbito de las telecomunicaciones. El 1 de marzo de 1993 pasó a llamarse International Telecommunication Union Standardization Sector (ITU-T).

mientras dura el intercambio de datos. En lugar de eso, se empaquetan los bits que se tienen que transmitir y se dan a la central más próxima para que los envíe cuando pueda a la siguiente, y así sucesivamente, hasta que lleguen a su destino. Si cuando llega un paquete a una central todos los enlaces con la siguiente están ocupados, no pasa nada, se le hace esperar poniéndolo en una cola para enviarlo cuando haya un enlace disponible.

Nodos en ARPANET en 1971

La transmisión por paquetes tiene la ventaja de que sólo ocupa los recursos cuando realmente se utilizan, no todo el tiempo. Pero, como contrapartida, se tiene que soportar el retardo que pueda haber desde que los paquetes salen del origen hasta que llegan a su destino, y que es variable, porque las esperas en las colas son aleatorias, dependen del estado de la red. Pero, como hemos dicho, eso, en comunicación de datos, es hasta cierto punto tolerable. Con respecto a la cuestión económica, no tiene sentido que se cobre por tiempo de conexión: en las redes de datos se paga por bits transmitidos. Hay otro peligro: los paquetes se pueden perder. Hay que tener presente que las colas son limitadas y, si una cola ya está llena cuando llega un paquete, éste no se podrá guardar y se perderá. Hay que prever mecanismos que eviten estas pérdidas y regulen el flujo de información entre los nodos de conmutación. Las compañías telefónicas desarrollaron redes de este tipo, y el CCITT emitió un estándar, el X.25, que ha sido en definitiva el que ha adoptado todo el mundo hasta hace poco.

CERT El Computer Emergency Response Team (CERT) es un equipo de respuesta de emergencia de ordenadores que mantiene datos sobre todas las incidencias en red y sobre las principales amenazas.

© FUOC • PID_00147725

47

Segundo período: 1970-1990. Del Ejército a la Universidad Dentro del segundo período de la historia de Internet podemos destacar los siguientes acontecimientos: •

Años�1970. Durante este período, la red fue de acceso restringido a los investigadores y a las empresas privadas que participaban en proyectos financiados por la Administración.

•

1970. El Network Working Group (NWG), liderado por S. Crocker, acabó el protocolo ordenador principal a ordenador principal inicial para ARPANET, denominado Network Control Protocol (NCP, protocolo de control de red). Kevin MacKenzie inventa el primer emoticón: :-). Vinton Cerf escribe por primera vez la palabra Internet. Está considerado el padre de la red. Más tarde diseñó el protocolo TCP/IP, que actualmente rige las comunicaciones por Internet.

•

1971. Ray Tomlison (BBN18) crea los protocolos básicos del correo (e-mail), incluida la convención de la arroba para separar el nombre de la persona del identificador del ordenador.

•

1972. Se presenta públicamente ARPANET en la International Computer Communication Conference. Investigadores del MIT dieron a luz el germen de lo que sería el sistema de transferencia de archivos FTP y telnet. El Sistema de Agencias de Información de Defensa crea la IANA o Autoridad de asignación de números de Internet, responsable de asignar una dirección única a cada computador conectado a Internet.

•

1973. Vint Cerf y Bob Kahn especifican la primera versión del programa de control de transmisión (TCP), que se desarrolló después hasta convertirlo en el Transmission Control Protocol/Internet Protocol (TCP/IP), los protocolos que actualmente permiten el funcionamiento de Internet. Berkeley desarrolló el BSD UNIX. ARPA dio una copia de TCP/IP a Berkeley y se incorporó este software a la versión UNIX. Nace la posibilidad de realizar un FTP.

•

1979. Nace Usenet. Creada por tres estudiantes, Tom Truscott, Jim Ellis y Steve Bellovin. Usenet es un servicio de grupos de noticias, las populares "news".

•

1980. Aparecen las primeras aplicaciones TCP/IP. Internet ya tiene 212 servidores.

•

1981. El año 1981, IBM lanza el primer PC, con el sistema operativo de una pyme denominada Microsoft.


© FUOC • PID_00147725

48

•

1982. ARPANet adopta el protocolo TCP/IP como estándar. Se crea la EuNet (European Unix Network). La European Unix Network (EuNet), conectada a ARPANet, se creó en 1982 para proporcionar servicios de correo electrónico y servicios Usenet a diversas organizaciones usuarias en los Países Bajos, Dinamarca, Suecia e Inglaterra.

•

1983. Considerado como el año en que nació realmente Internet al separarse la parte militar y la civil de la red. Hasta el 1 de enero de 1983, la incipiente Internet estuvo funcionando con un antecesor de los protocolos TCP/IP; aquel día, los ya miles de ordenadores conectados se cambiaron al nuevo sistema. Internet ya dispone de 562 servidores (ordenadores interconectados). El mismo año se creó el sistema de nombres de dominios (.com, .edu, etc., más las siglas de los países), que prácticamente se ha mantenido hasta ahora.

•

1984. El ordenador pasa a estar al alcance de la gente, y su implantación se acelera cuando se presenta el Macintosh. El número de servidores conectados a la red había superado ya los 1.000. Al año siguiente se forjaba Well, la primera comunidad comercial de usuarios. Se crea en Wisconsin el primer name server, con lo que ya no se necesita conocer el path de localización de un computador, precursor del servicio DNS de Internet.

•

1985. Entra en funcionamiento el Domain Name Server (DNS), un método para resolver nombres en direcciones numéricas. El primer dominio se otorga el 15 de marzo a Symbolics.com. Internet ya tiene 1.961 servidores y los sufijos .com, .net y .org añadidos. En abril aparecen los primeros dominios con letra, que fueron acmu.edu, purdue.edu, rice.edu y ucla.edu, todos ellos todavía en activo sin duda, y todos universitarios, también sin duda. En junio del mismo año aparece el primer dominio gubernamental, css.gov, y en julio, mitre.org. El primer dominio de un país se atribuyó en julio de aquel mismo año a Gran Bretaña: co.uk. En España, los ordenadores de diferentes universidades se conectaban entre sí y con el Centro Europeo de Física de Partículas (CERN). El Ministerio de Educación y Ciencia, a través de la Secretaría de Universidades, elaboró un plan para interconectar los centros de cálculo de las universidades. Asimismo, un grupo de expertos de las universidades, centros de cálculo, organismos públicos de investigación y Telefónica, bajo la coordinación de Fundesco, realizó un informe que se llamó Proyecto IRIS (Interconexión de Recursos Informáticos).

•

1987. Nace la primera versión de Windows. Hay más de 10.000 servidores en todo el mundo.

•

1988. Se produce el primer gran ataque vírico de Internet, cuando el "gusano de Morris" hace caerse 6.000 de los 60.000 ordenadores que entonces la formaban. Creado por el estudiante de doctorado Robert T. Morris como un experimento, el gusano usaba un defecto del sistema operativo Unix para reproducirse hasta bloquear el ordenador. A raíz del "gusano de Morris" se crea el Computer Emergency Response Team (CERT). Jarkko Oikarinen, un joven finlandés, decide modificar el comando talk del Unix para permitir que diversas personas puedan charlar de forma simultánea. Así nace el chat, el Internet Relay Chat (IRC), que permite que se pueda conversar en línea en la red. En 1988 nace el programa IRIS dentro del Plan Nacional de Investigaciones y Desarrollo Tecnológico para dar conectividad a científicos e investigadores. La financiación y supervisión de esta red correría a cargo de la Comisión Interministerial de Ciencia y Tecnología, y de su gestión y dirección se encargaría Fundesco.

•

1989. Nace RIPE para interconectar las redes europeas. El número de servidores conectados a Internet alcanza ya los 100.000. Este mismo año, se inaugura también la primera conexión de un sistema de correo electrónico comercial en Internet (MCI y Compuserve). Nace Archie. Hasta aquel momento nadie se había planteado nunca la hipótesis de que en Internet las cosas pudieran tener un orden, ni de crear un directorio. Las direcciones eran tan pocas que se suponía que todo el mundo las conocía. Por este motivo, se crea el primer catálogo (un programa denominado Archie). Archie tuvo tal éxito que colapsó el tráfico en Estados Unidos y Canadá en cuanto se tuvo noticia de su existencia. Por este motivo, la Universidad MacGill de Montreal obligó a su autor a cerrarlo. Por suerte, lo hizo después de que Archie ya estuviera replicado en otros ordenadores. Archie fue el precedente de Gopher y Veronica y, de alguna remota manera, el primer intento de directorio de recursos de Internet.

(18)

BBN es la abreviatura de la empresa Bolt, Beranek and Newman.


© FUOC • PID_00147725

49

Cuando empezó a ser habitual disponer de más de un ordenador en la misma instalación, apareció la necesidad de interconectarlos para poder compartir los diferentes recursos: dispositivos caros, como impresoras de calidad, un disco duro que almacenara los datos de la empresa, un equipo de cinta para hacer copias de seguridad, etc. El diseño de las redes de área local siguió caminos completamente diferentes de los que se utilizaron para las redes de gran alcance. En las redes de área local se necesita, habitualmente, establecer comunicaciones "de muchos a uno" y "de uno a muchos", cosa difícil de conseguir con las redes de conmutación, pensadas para interconectar dos estaciones. Para este tipo de redes es más adecuada la difusión con medio compartido, en la que los paquetes que salen de una estación llegan a todo el resto simultáneamente. En la recepción, las estaciones los aceptan o ignoran según que sean sus destinatarias o no. Se habla de difusión porque los paquetes se difunden por todas partes, y de medio compartido porque esta difusión se hace sobre un medio común que las estaciones comparten. De la década de los sesenta son también los primeros estándares de arquitecturas de protocolos. Hay que tener presente que el intercambio de información entre ordenadores tiene toda una serie de implicaciones, entre las que se incluyen las siguientes: •

Aspectos eléctricos: los cables, los conectores, las señales, etc.

•

La manera de agrupar los bits para formar paquetes y la de controlar que no se produzcan errores de transmisión.

•

La identificación de los ordenadores dentro de la red y la manera de conseguir que la información que cualquier ordenador genera llegue a quien se pretende que la reciba.

Abordar todos estos aspectos de una manera global resulta inviable: demasiadas cosas demasiado diferentes entre sí. Por eso, ya desde el principio, se desarrollaron modelos estructurados en niveles: en cada nivel se lleva a cabo una tarea, y la cooperación de todos los niveles proporciona la conectividad querida por los usuarios. Hay que tener presente que, en la época que nos ocupa, la informática estaba en manos de muy pocos fabricantes e imperaba la filosofía del servicio integral: cada fabricante lo proporcionaba todo (ordenadores, cables, periféricos, sistema operativo y software). Por lo tanto, cuando una empresa se quería informatizar, escogía una marca y quedaba ligada a ella para toda vida.


© FUOC • PID_00147725

50


En la década de los setenta, el panorama cambió radicalmente, sobre todo a causa de tres acontecimientos: •

La propuesta del protocolo Ethernet para redes locales.

•

La aparición del sistema operativo Unix, no ligado a ninguna marca comercial, compatible con todas las plataformas de hardware que había.

•

La invención de los protocolos TCP/IP, embrión de la actual Internet.

Se había allanado el camino para la aparición de los sistemas abiertos: no había que atarse a ninguna marca para tenerlo todo. El hardware podía ser de un proveedor, el sistema operativo de otro, las aplicaciones de otro y los protocolos, públicos. Tercer período: 1990-1995. Expansión fuera de los ámbitos militar y universitario Dentro del tercer período de la historia de Internet podemos destacar los siguientes acontecimientos: •

1990. Nacen el primer proveedor de acceso a Internet comercial y el Electronic Frontiers Foundation (EFF), una ONG de defensa de ciberderechos. La red tiene ya centenares de miles de servidores (313.000). Este año también aparece Windows 3.0. En España, Fundesco cambia el nombre del programa IRIS por REDIRIS y se conecta al backbone de Internet (NSFNET19), al lado de Argentina, Brasil, Chile, India, Suiza, Austria, Irlanda y Corea del Sur.

•

1991. Tim Berners-Lee, investigador en el centro europeo CERN, en Suiza, elaboró su propuesta de un sistema de hipertexto compartido: era el primer esbozo de la World Wide Web. Como el ARPANet veinte años atrás, su propósito era poner en comunicación a los científicos. La WWW es una creación europea fruto del trabajo de Tim Berners-Lee y Robert Cailauu. Su objetivo era buscar una herramienta de trabajo para crear y leer textos a través de una red que permitiera intercomunicar a los físicos de todo el mundo. Berners-Lee creó el HTML, el HTTP y las URL.

•

1992. Nace la Internet Society, la "autoridad" de la red. Surgía como el lugar donde pactar los protocolos que harían posible la comunicación. El Internet Activities Board (IAB) se integra en la Internet Society. En el IAB destacó la Internet Engineering Task Force (IETF), que tenía como función el desarrollo de Internet a corto plazo y la responsabilidad de la dirección técnica. La mayor parte de los Request For Comments (RFC) se elaboran en el IETF, y éstos iban aumentando cada año. Internet ya tiene 1.136.000 servidores. En España aparece Goya Servicios Telemáticos, primer proveedor de acceso comercial.

•

1993. Aparece el primer visualizador gráfico de páginas web: Mosaic, el antecesor de Netscape. Hasta aquel momento la red era sólo texto: ahora sobre un fondo gris aparecen documentos con gráficos y enlaces en azul. El crecimiento de Internet supera el 350.000% (casi dos millones de ordenadores). Marc Andreeseen, cocreador de Mosaic, funda Netscape junto con el veterano ejecutivo de Silicon Valley Jim Clarke. En septiembre, la Universidad Juan Carlos I de Castellón publica el primer servidor web de España, donde ya había 10 nodos y 15.000 máquinas bajo el dominio .es.

•

1994. Año del primer spam: los abogados de Arizona Canter & Siegel lanzan el 5 de marzo de 1994 un anuncio en 6.000 grupos de noticias, y son perseguidos por los furiosos internautas, que consiguen que los expulsen de su ISP (y de la abogacía). En octubre, ATT y Zima (una marca de refrescos) ponen los primeros banners comerciales de la historia en Hotwired. Pero no todo son desgracias: también se abren el primer centro comercial, la primera radio y el primer banco en la red. El número de servidores de Internet alcanza los 3.800.000. En la Universidad de Stanford dos estudiantes crean un directorio de cosas interesantes de la red, al que bautizan Yahoo! Lycos. Se difunde la versión comercial del navegador Netscape Navigator. En España nace Servicom.

En la parte superior de la imagen se puede ver el primer banner de Internet en HotWired (1994).

© FUOC • PID_00147725

•

51


1995. Se empiezan a cobrar los dominios. Sun crea Java, y RealAudio incorpora sonido en la Red. Microsoft lanza con gran publicidad Windows 95 y anuncia un giro estratégico hacia Internet. El fabricante Digital (DEC) crea AltaVista, un buscador de Internet. Nacen la librería Amazon.com y el sitio de subastas eBay. Hay más de 5 millones de servidores conectados a Internet. La espina dorsal de NSFNET empieza a ser sustituida por proveedores comerciales interconectados. Salida a bolsa de Netscape, la tercera major hasta entonces, que marca el comienzo del boom de Internet.

(19)

Las siglas NSFNET corresponden a National Science Foundation Network.

TCP/IP nació a partir de un encargo de la Defense Advanced Research Project 20

Agency

(DARPA) a la comunidad científica americana para tener una red

(20)

En castellano, Agencia de Proyectos de Investigación Avanzada para la Defensa.

mundial que fuera reconfigurable fácil y automáticamente en caso de destrucción de algún nodo o algún enlace. La pila TCP/IP es una jerarquía de protocolos que ofrecía conectividad y, a pesar de tener poco que ver con las que ya había, era una opción más en el mercado. Ante una oferta tan grande, y dispar, de protocolos, la ISO21 y el CCITT propusieron un modelo nuevo que intentaba reunir de alguna manera todo lo que ya se había propuesto y que pretendía ser completo, racional y muy bien estructurado (la TCP/IP tiene fama de ser una pila de protocolos anárquica), con la intención, por lo tanto, de que se convirtiera en un modelo de referencia. Es la llamada pila de protocolos OSI (open systems interconnection). Internet, que nació y creció en las universidades, se empezó a hacer popular en la década de los noventa, a medida que los que conocían la red la iban "enseñando", y su popularización estalló cuando saltó al mundo de la empresa, en todas sus vertientes: como escaparate de productos o como canalizador de contactos comerciales.

Tim Berners Lee. Creador de la WWW

Su origen universitario, sin embargo, ha marcado esta evolución en muchos sentidos. Por ejemplo, el modelo cliente/servidor de aplicaciones distribuidas. Es un modelo sencillo y al mismo tiempo potente, y casi todas las aplicaciones que se hacen servir en Internet lo siguen. El Telnet, o apertura de sesión remota, la transferencia de ficheros (FTP), el correo electrónico y, sobre todo, la WWW (World Wide Web) son ejemplos claros de aplicaciones que siguen

(21)

ISO son las siglas de la International Organization for Standardization, en castellano, Organización Internacional de Estandarización.

© FUOC • PID_00147725

52

este modelo. Las dos primeras han caído en desuso un poco, pero tanto el correo como la WWW son las estrellas hoy en día en Internet. Tímidamente, aparecen nuevas propuestas de aplicaciones, pero la WWW, que nació como un servicio de páginas estáticas enlazadas con hiperenlaces, se está convirtiendo en la interfaz de usuario de toda la red, porque actualmente se utiliza para servir páginas dinámicas (se crean en el momento en que se sirven), e incluso, como código que se ejecuta en el ordenador cliente (applets). En este momento tenemos dos redes completamente independientes entre sí, pero de alguna manera superpuestas: •

Una red analógica, con conmutación de circuitos, pensada para voz.

•

Una red digital, con conmutación de paquetes, pensada para datos.

La red telefónica, tal como la hemos descrito hasta ahora, es completamente analógica: la señal electromagnética que viaja desde un teléfono hasta otro es analógica (varía continuamente y en cada momento puede tomar cualquier valor) y los circuitos electrónicos que componen la red también lo son. Los enlaces entre centrales de la red telefónica se hacían con señales analógicas con muchos canales multiplexados en frecuencia, y tenían que recorrer, a veces, grandes distancias. La atenuación de la señal inherente a la distancia que había que recorrer se tenía que corregir mediante repetidores que la amplificaran, cosa que aumentaba el ruido presente en la línea. Muy a menudo, la señal recibida era de una calidad muy baja porque la transmisión analógica no permite eliminar el ruido ni las interferencias en la recepción. No hay ninguna manera de saber exactamente qué se ha enviado desde el origen y qué es ruido añadido. En 1972 se hicieron públicos los primeros resultados del tratamiento digital de la señal aplicada a audio, básicamente orientado a su almacenaje. El CD estaba viendo la luz. Convertir un sonido (una magnitud física que puede tomar cualquier valor en cualquier momento) en una serie de 0 y 1 (dos únicos valores conocidos) permitía corregir fácilmente cualquier ruido añadido. El descubrimiento del procesamiento digital de la señal, y sus aplicaciones en los campos del sonido y la imagen, ha sido un hito primordial en el mundo de las comunicaciones. Básicamente, ha permitido reducir drásticamente el efecto del ruido, lo cual ha permitido, por una parte, incrementar la calidad de recepción de las señales y, por otra, aumentar la velocidad de transmisión con los mismos medios. Las compañías telefónicas empezaron a sustituir los enlaces internos (entre centrales) por señales digitales, pero manteniendo el bucle de abonado (línea y terminal) analógico. La digitalización de la señal de sonido se hace dentro de la central local, después del filtro de 4 kHz, y se vuelve a pasar a analógico en la central correspondiente en el otro extremo de la comunicación. Eso ha


© FUOC • PID_00147725

53

hecho cambiar sustancialmente los procesos de conmutación: ahora se tiene que trabajar con bits y, por lo tanto, las centrales electromecánicas se tienen que sustituir por ordenadores. Esta digitalización de la parte interna de la red de voz hizo que confluyeran de alguna manera las dos redes, la telefónica y la de datos: los enlaces digitales entre centrales se utilizaban indistintamente para paquetes de datos y para transmisiones de voz. Cuarto período: 1996-Actualidad. Multimedia y cientos de millones de usuarios Dentro del cuarto período de la historia de Internet podemos destacar los siguientes acontecimientos: •

1996. El 98% de los navegadores son Netscape, y se piensa que la red puede acabar con el sistema operativo. Microsoft responde lanzando el Explorer, lo cual da inicio a la guerra de los navegadores. Internet ya tiene más de 9.400.000 servidores. En España hay más de 100.000 ordenadores bajo el dominio .es. Salen a bolsa Yahoo! y Excite con grandes beneficios. Estados Unidos lanza la Communications Decency Act, que será anulada en 1997. Se propone la creación de siete nuevos dominios genéricos; tv.com se vende a CNET por 15.000 dólares. Procter&Gamble, el mayor anunciante del mundo, impone el pago por clic, que dominará la publicidad en línea. Inclusión de contenidos multimedia: técnica de streaming para la transmisión fluida de vídeo.

•

1997. Business.com se vende por 150.000 dólares. En 1997 ya hay 17 millones de servidores en la red. En España se crea ESPANIX para intercambiar tráfico local; a finales de año hay 500 proveedores y un millón de internautas, gracias a Infovía.

•

1998. Microsoft, con su Explorer, tiene más del 80% de los navegadores, y es demandado por abuso de posición dominante. La red tiene 300 millones de páginas. Nace Google y AOL compra Netscape. Se registra el dominio comercial dos millones. El Gobierno estadounidense anuncia un plan para privatizar Internet que es rechazado; un segundo plan es mejor recibido.

•

1999. Nace Napster, el primer programa de intercambio de ficheros (P2P). En España, Telefónica desactiva Infovía y funda Terra (que saldrá a bolsa con gran éxito) a la que dota de cifras con la compra del buscador Olé. Parte del equipo fundacional abandona para fundar Ya.com. Terra sale a bolsa con gran éxito. Se pagan 7,5 millones de dólares por Business.com. A final de año, el índice NASDAQ alcanza cifras desmesuradas. España tiene 300.000 ordenadores bajo .es y 2 millones de internautas. El formato de sonido MP3 desestabiliza a las multinacionales del disco.

•

2000. El temido efecto 2000 apenas provoca problemas. En el intermedio de la Super Bowl de fútbol americano, a mediados de enero, se anuncian 17 compañías "puntocom", que pagan 2 millones de dólares por 30 segundos de anuncio cada una. En marzo, el índice NASDAQ alcanza su pico histórico: 5.048 puntos; durante el verano se inicia una larga caída. Terra compra Lycos por 12.500 millones de dólares, y al lado de Telefónica empieza a ofrecer ADSL. Los operadores de cable empiezan a prestar servicio de banda ancha doméstica en España. La tienda de ropa Boo.com bate récords, con una facturación en seis meses de 160 millones de dólares. Microsoft es condenado por abusar de su cuasi-monopolio en sistemas operativos. Se calcula que la web supera los 1.000 millones de páginas.

•

2001. Arranca con el pleito abierto de nuevo por las discográficas contra Napster por favorecer la piratería, pleito que acaba por provocar su cierre en julio por orden judicial (y su resurrección como servicio de pago). En febrero, Napster había batido su propio récord, con 13,6 millones de usuarios. Napster cierra en julio por orden judicial (volverá a salir como servicio de pago). America Online compra en enero Time Warner, el mayor grupo mediático del mundo, en lo que se considera el definitivo triunfo de los nuevos medios sobre los viejos. La empresa Kozmo de venta por Internet con entrega rápida quiebra en abril. Su competidora Webvan sufre igual suerte. En mayo se lanza el programa SETI@Home, el primer gran proyecto de computación distribuida; en menos de un mes proporciona más potencia de cálculo que el mayor superordenador disponible entonces.


© FUOC • PID_00147725

54

•

2002. La crisis de las puntocom continúa profundizándose. Los dominios son noticia, con la apertura de tres nuevos dominios de máximo nivel (.name para personas, .coop para cooperativas y .aero para empresas aeronáuticas) que no tendrán mucho éxito. En octubre, un ataque concertado consigue desconectar a 8 de los 13 ordenadores de los que depende todo el sistema de dominios, lo cual acelera los planes para reforzarlo. Explosión en el uso de los weblog o blogger: páginas escritas por los cibernautas en las que éstos explican anécdotas de sus propias vidas y dan a conocer sus opiniones. Lo que queda de Napster es adquirido por el conglomerado alemán Bertelsmann.

•

2003. Año de la música. La patronal musical de Estados Unidos (RIAA) denuncia por primera vez a usuarios finales por intercambiar música en redes P2P. Apple lanza su tienda de música iTunes, asociada al reproductor iPod. Después de dos años de continua caída del valor AOL Time, Warner elimina el "AOL" de su nombre. WiFi se consolida como alternativa de acceso sin hilo. Diversas plagas ensucian Internet; desde Slammer, que se extendió en 10 minutos echando abajo a 8 servidores raíz y afectando a bancos y el tráfico aéreo, hasta SobigF y Blaster. Después de una cierta parada entre 2001 y 2002, se recupera el vigoroso ritmo de crecimiento del número de servidores en la red. Este año también empieza el ataque judicial de SCO contra Linux.

•

2004. Empieza la recuperación. Sale a bolsa Google, que lanza su correo web de 1 Gb Gmail. Guerra de buscadores: Yahoo! abandona a Google y compra diversas empresas, Microsoft potencia MSN Search y Amazon lanza A9. La música de pago también se caldea, con la entrada de Wal-Mart, Sony, Virgin, eBay y Microsoft; iTunes tiene el 70% del mercado. El navegador Firefox v1.0 hace mella en el dominio del Explorer de Microsoft, al que arranca un 5%. En Estados Unidos, la banda ancha supera a los módems y la campaña de las presidenciales demuestra el poder de los blogs llamados "Rathergate"; el precandidato Howard Dean usa la red para la movilización del electorado y la recaudación de fondos. En España Terra vende Lycos por 105 millones de dólares. El copyleft avanza con la extensión de las licencias Creative Commons.

•

2005. Existen más servidores raíz fuera de Estados Unidos que en su territorio. La red tiene más de 300 millones de ordenadores principales, casi 60 millones de dominios activos, más de 4.000 millones de páginas web indexadas por Google y más de 900 millones de internautas. Suecia tiene la penetración más alta (74% de la población), y España ocupa el puesto 22 por accesos de banda ancha (casi 2,5 millones) y el 12 por número de internautas (14 millones), pero está por debajo de la media europea en penetración. Diversos accidentes y ataques difunden información privada en la red. Microsoft responde a Firefox con el lanzamiento de una versión no prevista del Explorer. Apple presenta el iPod Shuffle, basado en memoria flash. El mercado de la publicidad en línea se despierta, y diversos medios españoles relanzan sus páginas web. A finales de este mismo año nace Youtube.

•

2006. Aparecen los principales exponentes de la revolución de la Web 2.0: Facebook y GoogleEarth. El fenómeno de la red interactiva y dinámica empieza a extenderse. Se empiezan a esbozar nuevas tendencias de computación distribuida. Aparece el término cloud computing.

•

2007. Las plataformas de descarga de contenidos basados en tecnologías p2p aglutinan la mayoría del tráfico de la Red. XMPP se convierte en estándar de facto para las comunicaciones de mensajería instantánea. Gmail deja de ser beta y se convierte en accesible para todo el mundo. Writely, adquirido por Google el año anterior, es llamado Google Docs. Nace Android como sistema operativo para dispositivos móviles.

•

2008. Auge en el acceso a Internet mediante dispositivos móviles. Amplia adopción de la tecnología 3G. Quincuagésimo aniversario del nacimiento de la red. El Gobierno chino construye un sistema de filtraje y censura en la red para controlar los contenidos que llegan a los usuarios del país asiático.

•

2009. Se esboza la Internet de las cosas. Aparece 6LowPan como iniciativa para proveer de dirección IPv6 a las redes de sensores. Se extiende la oferta de servicios a la Red. Auge del cloud computing.

•

2010. Facebook llega a los 400 millones de usuarios. Google es boicoteado en China. Amazon EC2 y Google Application Engine se disputan el mercado del cloud. IBM se desmarca de la competencia por el mercado cloud ofreciendo soluciones basadas en escritorios remotos (eyeOS). Se empieza a hablar de redes cognitivas.


© FUOC • PID_00147725

55


Una vez digitalizada la red telefónica, el paso siguiente tenía que ser llevar la transmisión de bits hasta las casas. Eso permitía, por una parte, ofrecer a los usuarios en su casa la transmisión de datos además de la tradicional de voz y, por otra, ofrecer a los abonados un abanico de nuevos servicios asociados a una comunicación enteramente digital de punta a punta. Este servicio de transmisión digital mediante la red telefónica se conoce como red digital de servicios integrados (RDSI). Ofrece dos canales independientes de 64 kbps, que permiten hablar y conectarse a Internet simultáneamente, o, con un hardware adecuado, aprovechar los dos canales juntos para navegar a 128 kbps. El uso de la red telefónica para transmitir datos tiene una limitación importante por lo que respecta al máximo de bits por segundo permitidos, y las redes específicas de datos son muy caras para su uso doméstico. Desde la década de los noventa se han estudiado maneras de conseguir llevar hasta las casas o las empresas un buen caudal de bits por segundo (banda ancha) a un precio razonable, de manera que las nuevas aplicaciones multimedia se puedan explotar al máximo. Para conseguir esta banda ancha, se han seguido dos caminos completamente diferentes. Con respecto al primero, se han promovido cableados nuevos con fibra óptica que permiten ese gran caudal, a menudo llevados a cabo por empresas que pretenden competir con los monopolios dominantes. Estas redes se aprovechan para dar un servicio integral: televisión, teléfono y datos. Con respecto al segundo, las compañías telefónicas de toda la vida han querido sacar partido del cableado que ya tienen hecho y, por eso, han desarrollado las tecnologías ADSL, que permiten hacer convivir en el bucle de abonado la señal telefónica y una señal de datos que puede llegar a los 8 Mbps (o 20 Mbps con tecnología ADSL+).

RDSI La red digital de servicios integrados (RDSI) corresponde a las siglas ISDN (integrated services digital network) en inglés.

© FUOC • PID_00147725

56

Resumen

El módulo ha introducido los conceptos fundamentales de las redes de computadores. Hemos visto que éstas son una composición de sistemas hardware, software y protocolos que permiten la comunicación entre dispositivos remotos. Hemos visto las topologías más comunes de las redes de comunicación y que éstas también se pueden clasificar por su alcance. La arquitectura de las redes de computadores está estructurada en diferentes niveles. Hemos visto que existe un modelo de referencia denominado OSI, que define siete niveles de red. Los niveles más bajos se ocupan de los aspectos físicos de la comunicación, desde la caracterización del medio a la codificación de la información transmitida. Las capas superiores usan las interfaces de abstracción de sus capas subyacentes construyendo así un sistema complejo que permite la transmisión estructurada de información entre dispositivos remotos. La división en capas y las interfaces permiten la abstracción de las funcionalidades de las capas subyacentes en las capas superiores permitiendo así que las capas se puedan modificar y/o cambiar sin que ello afecte al comportamiento de la red. Los conceptos de interfaz y cabecera son clave para entender la estructuración en capas de una red. No obstante, hemos visto también que el modelo OSI es complejo y no ha sido utilizado más que como modelo de referencia. En realidad, Internet usa un modelo TCP/IP más simple pero funcional. El módulo ha presentado ambos modelos y los ha comparado. Finalmente, el módulo repasa la historia de las comunicaciones. Conocer la historia nos ayuda a entender el porqué de determinadas particularidades de las redes de comunicaciones actuales. En los próximos módulos profundizaremos en el conocimiento de los niveles de la red. En este curso hemos adoptado un enfoque top-down, es decir, desde los niveles más próximos a la aplicación hasta los niveles más específicos del hardware. Esta aproximación puede diferir de la de algunos otros documentos de referencia, en los que las redes se presentan a la inversa, primero, conociendo los niveles físicos, y, finalmente, presentando los niveles de aplicación. El módulo "Las capas de la red de computadores" presenta en detalle los niveles de transporte, el nivel de red que es primordial, los principales conceptos de los niveles de enlace de datos y físico, que, como veréis, están fuertemente interrelacionados. El módulo "Seguridad en la red" adopta otro enfoque y nos presenta aspectos relacionados con la seguridad de las redes de computadores, hoy en día de primordial importancia. El módulo 4 nos presenta el nivel de aplicación donde se profundiza en los conceptos fundamentales que rigen las aplicaciones en Internet (el correo, la web, etc.). Finalmente, el módulo "Co-


© FUOC • PID_00147725

57

municaciones inalámbricas" profundiza en el conocimiento de las comunicaciones sin hilos que se están convirtiendo en el eje principal de las tecnologías de red actuales.


© FUOC • PID_00147725

59

Bibliografía Kurose, J.; Ross, K. (2005). Computer Networking: a top-down approach featuring the Internet (5.ª ed.). Boston: Addison-Wesley Publishing Company. Tanenbaum, A. S. (2003). Redes de computadores (4.ª ed.). Nueva York: Prentice-Hall Professional Technical Reference.


Las capas de la red de computadores Xavier Vilajosana Guillén PID_00147723

© FUOC • PID_00147723


Las capas de la red de computadores


© FUOC • PID_00147723

Índice

Introducción...............................................................................................

5

Objetivos.......................................................................................................

6

1.

El nivel de transporte.......................................................................

7

1.1.

Objetivos ......................................................................................

7

1.2.

Servicios ofrecidos por la capa de transporte .............................

8

1.3.

Relación entre la capa de transporte y la capa de red .................

9

1.4.

Transporte no orientado a la conexión: UDP .............................

12

1.4.1.

Cabecera UDP ................................................................

12

1.4.2.

Cabecera UDP ................................................................

13

Transporte orientado a la conexión: TCP ...................................

14

1.5.1.

Funcionamiento básico de TCP .....................................

15

1.5.2.

Cabecera TCP .................................................................

16

1.5.3.

Establecimiento de la conexión ....................................

19

El nivel de red....................................................................................

21

2.1.

Funcionalidades básicas: direccionamiento ................................

21

2.2.

Servicios de red ...........................................................................

24

2.2.1.

Modelo de red en modo de circuitos virtuales ..............

25

2.2.2.

Modelo de red en modo datagrama ..............................

26

2.2.3.

Servicio de red orientado y no orientado a la

1.5.

2.

2.3.

4.

27

Direccionamiento en Internet: el protocolo IP ...........................

27

2.3.1.

IPv4 ................................................................................

28

2.3.2.

IPv6 ................................................................................

42

Protocolos de soporte a IP ..........................................................

49

2.4.1.

Internet Control Message Protocol ...............................

49

2.4.2.

Address Resolution Protocol ..........................................

51

2.4.3.

Network Discovery Protocol ..........................................

52

2.4.4.

Dynamic Host Configuration Protocol .........................

53

El enlace de datos y el control de acceso al medio....................

54

3.1.

Terminología y definiciones .......................................................

55

3.2.

Tipo de enlaces ...........................................................................

56

3.3.

Tipo de servicios suministrado en la capa de red .......................

56

3.4.

Servicios proporcionados por la capa de enlace .........................

57

3.5.

Adaptadores y dispositivos de red ..............................................

58

El nivel físico......................................................................................

60

4.1.

60

2.4.

3.

conexión ........................................................................

Medios de transmisión ................................................................


© FUOC • PID_00147723

4.1.1.

Par trenzado ...................................................................

60

4.1.2.

Cable coaxial de banda base .........................................

62

4.1.3.

Fibra óptica ....................................................................

62

Resumen.......................................................................................................

64

Bibliografía.................................................................................................

65

© FUOC • PID_00147723

5

Introducción

En este módulo veremos en detalle las características y funcionamiento de los diferentes niveles de la red. El objetivo del módulo es dar una visión general del funcionamiento interno de una red de computadores, ya sea de área local, ya a gran escala, como es Internet. La aproximación a los niveles de la red será desde los niveles más próximos a las aplicaciones hasta los niveles más específicos del hardware. Como hemos visto en el módulo "Conceptos de redes de computadores", las redes de computadores han sido estructuradas en diferentes niveles que abstraen en los niveles superiores las complejidades de los niveles inferiores. El funcionamiento del nivel aplicación, sus servicios y protocolos los veremos en detalle en el módulo "En el nivel de aplicación". Antes, y para entender algunos de los conceptos del nivel aplicación, pasaremos por el nivel de transporte, que ofrece fiabilidad a la red permitiendo el acceso de diferentes aplicaciones a un único medio de transmisión, la red. Seguidamente profundizaremos en el conocimiento de la capa de red. El nivel de red es primordial para el funcionamiento de Internet pues nos permite dirigir e identificar los nodos de una red. En este módulo conoceremos el funcionamiento actual de la red, así como las nuevas tecnologías de red que se convertirán en estándares en un futuro. La capa de enlace abstrae los nodos de la red del medio físico sobre el que transmiten la información. Esta capa se encarga de dirigir la información entre nodos físicos adyacentes y garantizar una transmisión fiable entre ellos. Hay que destacar la tarea de la subcapa de control de acceso al medio que permite transmitir información entre dos nodos independientemente de la tecnología de red utilizada, ya sea inalámbrica, ya cableada. Finalmente, el nivel físico se encarga de los aspectos de modulación y codificación de las señales físicas que son dependientes directamente de la tecnología y el medio de transmisión. El módulo, en definitiva, os permitirá haceros una idea general y amplia del funcionamiento de una red de computadores.


© FUOC • PID_00147723

6

Objetivos

El estudio de este módulo os tiene que permitir alcanzar los objetivos siguientes:

1. Profundizar en el conocimiento de cada una de las capas de las redes de computadores. 2. Conocer las funciones principales de la capa de transporte. 3. Conocer el funcionamiento de los protocolos TCP y UDP. 4. Conocer los servicios ofrecidos por la capa de red. 5. Entender el direccionamiento en las redes de computadores. 6. Conocer los estándares de red actuales. 7. Tener una visión global del funcionamiento de la capa de enlace y física.


© FUOC • PID_00147723

7

1. El nivel de transporte

El nivel de transporte abstrae la complejidad de la red a las aplicaciones. En este módulo, veremos su funcionamiento con detalle. 1.1. Objetivos La capa de transporte se encarga de proveer comunicación extremo a extremo entre procesos de aplicaciones ubicadas en diferentes hosts. Desde el punto de vista de la aplicación, es como si los hosts estuvieran directamente conectados, pero en realidad podrían estar en lugares opuestos del planeta, conectados mediante múltiples routers y tipo de enlaces diferentes. La capa de transporte ofrece las funcionalidades básicas para alcanzar este nivel de comunicación lógica, sin que las aplicaciones se tengan que preocupar de la infraestructura de red subyacente. Mensajes extremo a extremo

Los protocolos de la capa de transporte se implementan en los dispositivos extremos de la red y no en los routers ni en los dispositivos intermedios. La información transmitida por las aplicaciones es convertida en paquetes de la capa de transporte, conocidos como segmentos�de�la�capa�de�transporte. Los segmentos de la capa de transporte se construyen dividiendo la información que quiere transmitir la aplicación en segmentos de un tamaño determinado, a los que se añade una cabecera. Cada segmento se envía a la capa de red donde será incluido en los paquetes del nivel de red conocidos como datagramas. A partir de la capa de red, los datagramas son enviados a los destinatarios pasando por diferentes dispositivos que únicamente examinarán la información correspondiente a la capa de red. Sólo los receptores, al recibir el datagrama en la capa de red, extraerán el segmento de transporte y lo pasarán a la capa de transporte del receptor. La capa de transporte procesará el segmento y lo pasará a la aplicación correspondiente.


© FUOC • PID_00147723

8

En este módulo estudiaremos con detalle los protocolos y funcionalidades de la capa de transporte de datos, haciendo énfasis en los protocolos de transporte de datos de Internet, User Datagram Protocol (UDP) y Transmission Control Protocol (TCP), que ofrecen servicios diferentes a las aplicaciones que los invocan. La jerarquía TCP/IP

1.2. Servicios ofrecidos por la capa de transporte La capa de transporte ofrece las siguientes funcionalidades: •

Garantiza la transmisión sin errores, extremo a extremo, independientemente del tipo de red.

•

Controla la transmisión extremo a extremo.

•

Es responsable del control de flujo de los datos y del control de congestión de la red.

•

Es responsable de establecer, mantener y finalizar las conexiones entre dos hosts o un host y un servidor en una red.

•

Asegura que los datos lleguen sin pérdidas, sin errores y sin ser duplicadas.

•

Ordena los paquetes que llegan.


© FUOC • PID_00147723

•

9

Se encarga de fragmentar los mensajes y recomponerlos en destino cuando es necesario.

•

Permite la multiplexación de diversas conexiones de transporte sobre una misma conexión de red.

1.3. Relación entre la capa de transporte y la capa de red

La capa de transporte se ubica justo por encima de la capa de red en la pila de protocolos. Mientras que la capa de transporte se encarga de proveer comunicación lógica entre procesos que se ejecutan en hosts diferentes, la capa de red provee comunicación lógica entre hosts. Esta diferencia es sustancial, pues la capa de transporte tiene que permitir que múltiples procesos se comuniquen de forma lógica haciendo uso de una única conexión lógica provista por la capa de red. Este concepto se llama multiplexación y demultiplexación de la capa de transporte.

Además, la capa de red no da garantías de entrega de la información, no garantiza la entrega de los segmentos, ni tampoco garantiza la integridad de la información contenida en el segmento. Por esta razón, la capa de red no�es confiable. La misión, pues, de la capa de transporte consiste por una parte en proveer la transmisión de datos fiable y permitir la comunicación proceso a proceso en una red creada comunicando host a host. Para introducir los protocolos del nivel de transporte, nos centramos en la jerarquía de protocolos Transmission Control Protocol/Internet Protocol (TCP/ IP). En esta jerarquía se definen dos protocolos de transporte: el UDP y el TCP. El UDP no está orientado a la conexión, lo que quiere decir que no implementa fases de establecimiento de la conexión, envío de datos y fin de la conexión, mientras que el TCP está orientado a la conexión. En el caso de la jerarquía TCP/IP, se definen dos direcciones que relacionan el nivel de transporte con los niveles superior e inferior: •

La dirección�IP es la dirección que identifica un subsistema dentro de una red.

•

El puerto identifica la aplicación que requiere la comunicación.

Para identificar las diferentes aplicaciones, los protocolos TCP/IP marcan cada paquete (o unidad de información) con un identificador de 16 bits llamado puerto.


10

© FUOC • PID_00147723

•


Puertos� conocidos. Están regulados por la Internet Assigned Numbers Authority (IANA). Ocupan el rango inferior a 1.024 y son utilizados para acceder a servicios ofrecidos por servidores.

•

Puertos�efímeros. Son asignados de forma dinámica por los clientes dentro de un rango específico por encima de 1.023. Identifican el proceso del cliente sólo mientras dura la conexión.

0-255 (IANA)

Aplicaciones públicas.

255-1.023(IANA)

Asignados a empresas con aplicaciones comerciales.

> 1.023

No están registrados (efímeros).

Puerto de aplicaciones públicas establecidas por IANA Decimal

Palabra clave

Descripción

0

Reservado

1-4

No asignado

5

RJE

7

ECHO

9

DISCARD

11

USERS

13

DAYTIME

De día

15

NETSTAT

Quién está conectado o NETSTAT

17

QUOTE

19

CHARGEN

Generador de caracteres

20

FTP-DATA

Protocolo de transferencia de archivos (datos)

21

FTP

23

TELNET

25

SMTP

Protocolo SMTP (simple mail transfer protocol)

37

TIME

Hora

39

RLP

42

NAMESERVER

43

NICNAME

Quién es

53

DOMAIN

Servidor de denominación

67

BOOTPS

Servidor de protocolo de arranque

68

BOOTPC

Cliente del protocolo de arranque

69

TFTP

Entrada remota de tareas Eco Descartar Usuarios activos

Cita del día

Protocolo de transferencia de archivos Conexión de terminal

Protocolo de ubicación de recursos Servidor de nombre de anfitrión

Protocolo trivial de transferencia de archivos

11

© FUOC • PID_00147723


Decimal

Palabra clave

Descripción

75

Cualquier servicio privado de conexión telefónica

77

Cualquier servicio RJE privado

79

FINGER

80

HTTP

95

SUPDUP

101

HOSTNAME

102

ISO-TSAP

113

AUTH

117

UUCP-PATH

123

NTP

137

NetBIOS

Servicio de nombres

139

NetBIOS

Servicio de datagramas

143

IMAP

150

NetBIOS

156

SQL

161

SNMP

179

BGP

190

GACP

194

IRC

Internet relay chat

197

DLS

Servicio de localización de directorios

224-241

No asignado

242-255

No asignado

Finger Protocolo de transferencia de hipertexto Protocolo SUPDUP Servidor de nombre de anfitrión NIC ISO-TSAP Servicio de autenticación Servicio de ruta UUCP Protocolo de tiempo de red

Interim mail access protocol Servicio de sesión Servidor SQL Simple network management protocol Border gateway protocol Gateway access control protocol

Puertos usados por algunos de los protocolos de nivel aplicación

12

© FUOC • PID_00147723

Actividad ¿Conocéis aplicaciones comerciales o de software libre que utilicen un puerto determinado? ¿Qué puertos utilizan Skype, Emule, BitTorrent, MSN?

1.4. Transporte no orientado a la conexión: UDP

El User Datagram Protocol (UDP) es un protocolo no orientado a la conexión, de manera que no proporciona ningún tipo de control de errores ni de flujo, aunque utiliza mecanismos de detección de errores. En caso de detectar un error, el UDP no entrega el datagrama a la aplicación, sino que lo descarta.

Hay que recordar que, por debajo, el UDP está utilizando el IP, que también es un protocolo no orientado a la conexión, y que, básicamente, lo que ofrece UDP, en comparación con IP, es la posibilidad de multiplexar conexiones de procesos sobre una misma conexión de red. La simplicidad del UDP hace que sea ideal para aplicaciones que requieren pocos retardos (por ejemplo, aplicaciones en tiempo real o el DNS). El UDP también es ideal para los sistemas que no pueden implementar un sistema tan complejo como el TCP. UDP es útil en aplicaciones donde no importe la pérdida de paquetes, como telefonía o videoconferencia sobre TCP/IP, monitorización de señales, etc. Estas aplicaciones no toleran retardos muy variables. Si un datagrama llega más tarde del instante en que tendría que ser recibido, entonces se descarta porque es inservible para la aplicación. Eso se traduce en un ruido en el sonido o la imagen, que no impide la comunicación. La tabla siguiente muestra algunas de las aplicaciones más comunes que hacen uso de UDP. Aplicaciones

Puertos

TFTP

69

SNMP

161

DHCP - BOOTP

67/68

DNS

53

1.4.1. Cabecera UDP La unidad de cabecera de UDP es el datagrama UDP. •

Cada escritura por parte de la aplicación provoca la creación de un datagrama UDP. No hay segmentación.


13

© FUOC • PID_00147723

•


Cada datagrama UDP creado es encapsulado dentro de un datagrama IP (nivel 3) para su transmisión.

1.4.2. Cabecera UDP La cabecera del datagrama UDP está formada por 8 bytes. Tiene cuatro campos.

•

Puertos�(fuente�y�destino): permiten identificar los procesos que se comunican.

•

UDP�length: longitud total del datagrama UDP (payload UDP + 8). Es un campo redundante, ya que IP lleva la longitud también. Como la longitud máxima de un datagrama IP es de 65.335 bytes (16 bits de longitud de datagrama): –

Longitud máxima de un datagrama UDP: 65.335 - 20 bytes = 65.315 bytes.

–

Longitud mínima de un datagrama UDP: 8 bytes.

–

Longitud de datos datagrama UDP: 65.315 - 8 bytes = 65.307 bytes.

–

El tamaño de un datagrama UDP depende del sistema operativo. Casi 1

todas las API limitan la longitud de los datagramas UDP (lo mismo para TCP) a la longitud máxima de los buffers de lectura y escritura definidos por el sistema operativo (llamadas al sistema "read" y "write").

(1)

Abreviatura de application programming interface.

© FUOC • PID_00147723

14


Se suele usar 8.192 bytes como tamaño máximo del datagrama UDP (FreeBSD). •

UDP�checksum: detector de errores, cuyo objetivo consiste en comprobar que nadie ha modificado el datagrama UDP y que éste llega a su destino correctamente. Si el checksum UDP es erróneo, se descarta el datagrama UDP y no se genera ningún tipo de mensaje hacia el origen. El checksum se aplica conjuntamente a una pseudocabecera más la cabecera UDP más el campo de datos. Esta pseudocabecera tiene 3 campos de la cabecera del paquete IP que se envía. Cabe mencionar que el checksum del datagrama IP sólo cubre la cabecera IP. Ejemplo Supongamos que tenemos el datagrama (descompuesto en 3 palabras de 16 bits): 0110011001100000 0101010101010101 1000111100001100 La suma de las dos primeras palabras de 16 bits es:

Añadiendo la tercera palabra obtenemos:

Ahora hacemos el complemento a 1 (cambiando 0 por 1) y obtenemos: 1011010100111101 Esta última palabra se añade también al datagrama UDP. En la recepción se hace la suma de todas las palabras de 16 bits, que tiene que dar 1111111111111111.

1.5. Transporte orientado a la conexión: TCP El Transmission Control Protocol (TCP) es un protocolo de nivel de transporte que se usa en Internet para la transmisión fiable de información. Quizás sea el protocolo más complejo e importante de la pila de protocolos de Internet. Como hemos visto, el UDP no garantiza la entrega de la información que le proporciona una aplicación. Tampoco reordena la información en el caso de que llegue en un orden diferente del utilizado para transmitirla. Hay aplicaciones que no pueden tolerar estas limitaciones. Para superarlas, el nivel de transporte proporciona TCP.

Checksum El checksum se calcula haciendo el complemento a 1 de la suma de todas las palabras de 16 bits que conforman el datagrama UDP.

© FUOC • PID_00147723

15


El TCP da fiabilidad a la aplicación, es decir, garantiza la entrega de toda la información en el mismo orden en que ha sido transmitida por la aplicación de origen. Para conseguir esta fiabilidad, el TCP proporciona un servicio orientado a la conexión con un control de flujo y errores.

TCP es un protocolo ARQ2, extremo a extremo, orientado a la conexión (fases de establecimiento de la conexión, envío de datos y cierre de la conexión) y bidireccional (full duplex). La unidad de datos TCP es el "segmento TCP". TCP, a diferencia de UDP, intenta generar segmentos de un tamaño óptimo que se denomina Maximum Segment Size (MSS), generalmente el mayor posible para minimizar el sobrecoste (overhead en inglés) de las cabeceras, sin que produzca fragmentación en el nivel IP. Al igual que UDP, TCP utiliza multiplexación mediante el uso de puertos, tal como hemos visto con anterioridad. Proporciona fiabilidad mediante los siguientes controles: •

Control�de�errores. TCP es parecido al Go-Back-N pero no descarta segmentos posteriores cuando llegan fuera de secuencia. Permite las retransmisiones selectivas.

•

Control�de�flujo (ventana advertida). Sirve para adaptar la velocidad entre el emisor y el receptor. Vigila que el emisor no envíe los segmentos a más velocidad de la que puede emplear el receptor para procesarlos, de manera que se puedan perder paquetes por saturación de la memoria intermedia de recepción.

•

Control�de�la�congestión (ventana de congestión). Para adaptar la velocidad del emisor a los encaminadores intermedios de la red y evitar así que se colapsen sus memorias intermedias y se puedan perder paquetes.

En transmisión, TCP se encarga de fragmentar los datos del nivel aplicación, y les asigna un número de secuencia antes de enviar los fragmentos al nivel IP. En recepción, como los segmentos pueden llegar fuera de orden, TCP los tiene que reordenar antes de pasarlos a los niveles superiores. 1.5.1. Funcionamiento básico de TCP En cada extremo, TCP mantiene una memoria intermedia de transmisión y una de recepción. La aplicación utiliza los llamamientos al sistema operativo read() y write() para leer y escribir en estas memorias intermedias. Cuando la aplicación escribe la información que se tiene que enviar al emisor, TCP la

(2)

ARQ es la abreviatura de Automatic Repeat-reQuest Protocol; en castellano, protocolo de repetición de petición automática.

© FUOC • PID_00147723

16

guarda en una memoria intermedia de transmisión. Cuando la memoria intermedia de Tx está llena, el llamamiento write() queda bloqueado hasta que vuelva a haber espacio. Cada vez que llegan segmentos de datos al receptor, el API read() los pasa al nivel superior y se envían sus correspondientes confirmaciones. A medida que los datos van siendo confirmados por el receptor, se van borrando de la memoria intermedia de transmisión y queda espacio libre para que la aplicación siga escribiendo.

1.5.2. Cabecera TCP

La cabecera TCP está formada por los siguientes elementos: •

Source�Port / Destination�Port: puertos origen y destino que identifican las aplicaciones.


© FUOC • PID_00147723

•

17

Sequence�Number: número de secuencia del segmento. Identifica el primer byte dentro de este segmento de la secuencia de bytes enviados hasta aquel momento.

•

Initial�Seq.�Number�(ISN): primer número de secuencia escogido por el protocolo TCP.

•

Seq� Number: será un número a partir de ISN. Por lo tanto, para saber cuántos bytes llevamos enviados hay que hacer Seq. Number - ISN".

•

Acknowledgment� Number: contiene el próximo número de secuencia que el transmisor del ACK espera recibir, es decir, es "Seq. Number + 1" del último byte recibido correctamente. –

TCP es FULL-DUPLEX: cada extremo mantiene un Seq. Number y un Ack Number.

•

Header�length: longitud total de la cabecera del segmento TCP en words de 32 bits (igual que el campo header length de la cabecera IP).

•

–

Tamaño mínimo de la cabecera TCP = 20 bytes (header length = 5).

–

Tamaño máximo de la cabecera TCP = 60 bytes (header length = 15).

Reserved: bits reservados para posibles ampliaciones del protocolo. Se ponen 0.

•

Flags: hay 6 flags (bits) en la cabecera. Son válidos si están en 1.

•

Urgente�(URG): indica que se utiliza el campo Urgent Pointer de la cabecera TCP.

•

Acknowledgement�(ACK): indica que se utiliza el campo Acknowledgement Number. Válido para todos menos para el SYN inicial.

•

Push�(PSH): indica que el receptor tiene que pasar los datos de la memoria intermedia de recepción a los niveles superiores tan rápidamente como sea posible. Operación más rápida sin llenar la memoria intermedia. La activación de este flag depende de la implementación. Las implementaciones derivadas de BSD lo activan cuando la memoria intermedia de Tx se queda vacía.

•

Reset�(RST): se activa cuando se quiere abortar la conexión. Un ejemplo es cuando se recibe un segmento de un cliente dirigido a un puerto donde no hay ningún servidor escuchando. En este caso, TCP contesta con un segmento con el flag de reset activado.

•

Synchronize�(SYN): se utiliza en el establecimiento de la conexión, durante la sincronización de los números de secuencia al inicio de la conexión.


© FUOC • PID_00147723

18

•

Finalize�(FINAL): se utiliza en la finalización de la conexión.

•

Advertised�Window�Size: tamaño de la ventana advertida por el receptor al transmisor (Sliding Window) para el control de flujo. La ventana máxima es de 65.535 bytes.

•

TCP�Checksum: se utiliza para detectar errores en el segmento TCP, y para tener una mayor certeza de que el segmento no ha llegado a un destino equivocado.

•

Igual que en UDP, el checksum TCP se aplica conjuntamente a una pseudocabecera + la cabecera TCP + el campo de datos TCP. Esta pseudocabecera tiene 3 campos de la cabecera IP y el tamaño del segmento TCP (cabecera + payload). –

La pseudocabecera sólo es para calcular el checksum: no se transmite en el segmento TCP, ni se incluye en la longitud del paquete IP.

–

El tamaño del segmento TCP no se pone en la cabecera TCP, sólo se tiene en cuenta en el cálculo del checksum.

–

•

A diferencia de UDP, en TCP el cálculo del checksum es obligatorio.

Urgent�Pointer: Campo válido si flag URG = 1. Implementa un mecanismo para indicar datos urgentes (es decir, que se tienen que atender lo más pronto posible). Es un puntero en el Seq Number que indica la parte de datos urgentes dentro del campo de datos. Los datos urgentes irán desde el primer byte del segmento hasta el byte indicado por el Urgent Pointer. Este flag se utiliza rara vez. Un ejemplo es cuando se teclea un control-C (interrupción) desde la aplicación telnet.

•

Options: TCP permite añadir opciones a la cabecera, pero, a diferencia de IP, las opciones de TCP suelen utilizarse. Podemos destacar: –

Maximum�Segment�Size: se utiliza durante el establecimiento de la conexión para sugerir el valor del MSS en el otro extremo MSS = MTU red directamente conectada - IP Header - TCP Header (sin opciones). Si la red es ethernet (MTU 1500), entonces MSS = 1460.

–

Window�Scale�Factor: se utiliza durante el establecimiento de la conexión para indicar que el valor de la ventana advertida se tiene que multiplicar por este factor de escala. Eso permite advertir ventanas mayores de 216.

–

Timestamp: se utiliza en el cálculo del RTT.


© FUOC • PID_00147723

–

19

SACK: permite que TCP haga retransmisión selectiva (selective ack). TCP utiliza el campo ACK para indicar hasta dónde se ha recibido correctamente. Con la opción SACK, el receptor puede indicar bloques de segmentos que se han recibido correctamente más allá del segmento confirmado por el ACK. De esta manera, el emisor puede escoger mejor los segmentos que se tienen que retransmitir.

•

Padding: bytes de relleno añadidos para que la cabecera tenga un múltiplo de 32 bits. Actividad Asumimos que un extremo cliente TCP (emisor) ha escogido el 28.325 como número de secuencia inicial (ISN), mientras que el extremo receptor TCP (servidor) ha escogido como ISN el 12.555. ¿Qué indica un segmento cliente (emisor) TCP con número de secuencia 29.201, número ACK 12.655 y ventana 1.024? Solución El número de secuencia indica que el cliente ya ha transmitido desde el byte 28.325 hasta el byte 29.200 (875 bytes en total) y que en este segmento transmitirá a partir del byte 29.201. El número ACK indicará al receptor que el emisor ha recibido correctamente hasta el byte 12.654 y que espera recibir a partir del 12.655. La ventana indica al receptor que el cliente sólo puede aceptar 1.024 bytes antes de confirmarlos. Por lo tanto, el servidor TCP actualizará su ventana de transmisión en 1.024.

1.5.3. Establecimiento de la conexión TCP es un protocolo orientado a la conexión tal como hemos dicho con anterioridad. Eso implica que en todo proceso de comunicación habrá una fase de establecimiento de la conexión donde emisor y receptor se sincronizan con el fin de poder intercambiar datos. EN TCP se usa el algoritmo 3-Way Handshake, que consiste en el intercambio de tres segmentos que no llevan datos (sólo es la cabecera TCP): 1) El emisor envía un segmento SYN, con petición de conexión. 2) El receptor (servidor) devuelve un segmento SYN + ACK como respuesta. 3) El cliente responde con un segmento ACK que reconoce el SYN + ACK. Una vez establecida la conexión se pasa a la fase de envío de datos.


© FUOC • PID_00147723

20

De la misma manera que el establecimiento de la conexión, se hace necesario un proceso de finalización de la conexión. El cierre de la conexión puede deberse a diversas causas: •

El cliente o el servidor cierra la conexión (LLS close()).

•

Por alguna razón se envía un reset de la conexión (flag activo RST).

•

Cierre a causa de una interrupción, un control∧D o un control∧C, etc.

La finalización también se hace por medio del envío de segmentos TCP. El primer segmento de final puede enviarlo tanto el cliente como el servidor. El cierre normal se produce a causa de un close() del cliente, lo que provoca el intercambio de 3 o 4 segmentos TCP.


© FUOC • PID_00147723

21

2. El nivel de red

La capa de red se encarga de proporcionar conectividad y ofrecer mecanismos para la selección del mejor camino entre dos puntos separados de la red, permitiendo la interconexión de equipos que pueden estar ubicados en redes separadas geográficamente unas de otras, garantizando la conectividad extremo a extremo, independientemente de la tecnología de enlace de datos utilizada y del camino que siga la información en los puntos intermedios. Las principales ventajas que nos proporciona esta capa son, por una parte, independencia de la tecnología de red (hacia capas inferiores), y, por otra, un sistema de abstracción que permite utilizar una gran diversidad de aplicaciones y protocolos de transporte (hacia capas superiores) como, por ejemplo, TCP o UDP.

Básicamente, la capa de red, especialmente en Internet, está compuesta por tres grandes bloques: 1) el protocolo que describe la manera de enviar información, 2) el protocolo de direccionamiento, que decide por dónde tienen que ir los datagramas para llegar a su destino, 3) la capa de red también identifica el mecanismo para informar de cualquier error que se haya producido en el envío de la información.

2.1. Funcionalidades básicas: direccionamiento Una red está compuesta básicamente por dos tipos de entidades, los clientes (también conocidos por el nombre de hosts o el de equipos finales) y los encaminadores (o routers). Los clientes son los equipos de red encargados de la comunicación, son el origen y el final de la misma. Normalmente son servidores de información o equipos de usuarios finales que acceden a los servidores. Por su parte, los encaminadores, a pesar de que en determinados casos también pueden ser equipos finales, se limitan a enviar la información que reciben por una interfaz de entrada a la correspondiente de salida que lleve los datagramas hacia su destino. Para poder saber hacia dónde va la información, los encaminadores se sirven de lo que se conoce como tablas de direccionamiento.


© FUOC • PID_00147723

22

La capa de red necesita que tanto los encaminadores como los equipos finales tengan un identificador único. Este identificador permite que cualquier otro equipo de la red lo pueda localizar y enviarle información. En particular, en una red como Internet estos identificadores se conocen como direcciones (direcciones IP). Ejemplo de red con encaminadores y equipos finales La figura siguiente muestra una red con ocho encaminadores y dos equipos finales. En la figura también se puede observar una simplificación de cómo funciona un encaminador internamente. Para simplificar, en vez de indicar las direcciones de los diversos equipos hemos identificado, por una parte, los diferentes encaminadores con R (de routers) y un número que los identifica, y por otra, los diferentes equipos finales con H (de hosts) y un número para identificarlos.

Los encaminadores están compuestos por una serie de interfaces de entrada y salida, que son las encargadas de recibir los datagramas de los equipos vecinos; estas interfaces están controladas por unas colas (o buffers) que almacenan los paquetes (de entrada o de salida) para poder enviarlos cuando sea posible, o lo que es lo mismo, cuando el encaminador tenga recursos para atender las colas de entrada, o bien cuando la red tenga recursos (ancho de banda disponible) para las colas de salida. Internamente, el encaminador dispone de una lógica para decidir qué hacer con los datagramas que llegan. Esta decisión normalmente implica enviar el datagrama por otra interfaz que lo llevará más cerca de su destino. Así, el datagrama va saltando por los encaminadores hasta llegar al destino. Cada equipo de red por el que pasa el datagrama se conoce como salto o hop. Hay que señalar que los encaminadores trabajan a nivel de red, lo que quiere decir que no interpretan los campos presentes en los niveles superiores, tal como muestra la figura siguiente.


© FUOC • PID_00147723

23

Capas usadas por el direccionamiento en protocolos de red

Cuando un equipo envía un datagrama hacia un destino, dicho datagrama va dirigido inicialmente al encaminador asociado a la red del equipo. Este encaminador mirará el destino del datagrama, y lo enviará por la interfaz que lo lleve hacia su destino dependiendo de una tabla de direccionamiento. El siguiente encaminador hará lo mismo hasta que el datagrama llegue a su destino final. La lista de encaminadores que sigue un datagrama se conoce como el camino o path del datagrama. Hay que señalar que este path será diferente dependiendo del origen y el destino del datagrama. Como muestra, se puede ver en la figura del ejemplo anterior que el camino que siguen los datagramas para ir desde H1 hasta H2 es H1-R1-R4-R7-R8-H2, haciendo un total de 5 saltos para llegar al destino.

Hemos dicho que el equipo envía el datagrama al encaminador de su red, lo cual implica que ha de conocer a priori cómo llegar a ese encaminador con el fin de poder enviarle el datagrama. La secuencia específica de acciones que realiza el equipo se puede ver más detalladamente en la figura siguiente: 1) Se crea el datagrama con las direcciones de red origen y destino apropiadas. 2) Se busca la dirección de red del encaminador - next hop (o del equipo final si está directamente conectado al encaminador - last hop). 3) Si no se dispone de la dirección de red, salimos con error ya que no sabemos cuál es el siguiente salto para enviar el datagrama. 4) Si hemos podido conseguir la dirección, enviamos el datagrama (con las direcciones de red origen y destino originales) al siguiente salto del path o al equipo final si estamos en el last hop.


© FUOC • PID_00147723

24

5) Repetir desde el paso 2 hasta que el datagrama llegue a su destino. Diagrama de bloques simplificado del envío de un datagrama a un equipo de red

El datagrama no sigue cualquier path, sino que los encaminadores disponen de una tabla de direccionamiento (forwarding table o routing table) que indica por qué interfaz se tienen que enviar los datagramas en función de su destino. Para llenar estas tablas es necesario utilizar unos algoritmos de direccionamiento.

2.2. Servicios de red El servicio de red define las características que tiene que tener el transporte punto a punto de los datos en la capa de red. Así, se definen características como la fiabilidad en el envío de la información, orden de llegada de los paquetes, umbrales de retardo en hacer llegar la información a destino, información de congestión en la red, etc., entre los diferentes emisores y receptores dentro de la red. Actualmente existen dos modelos de servicios de red claramente diferenciados, el modelo�de�circuito�virtual y el modelo�de�datagrama. A continuación se describen los dos, aunque haremos más énfasis en el modelo de datagrama, dado que es el utilizado por el nivel de red propuesto por Internet y, por lo tanto, el más relevante en la actualidad.


© FUOC • PID_00147723

25

2.2.1. Modelo de red en modo de circuitos virtuales

Un circuito virtual es un camino que se preconfigura entre dos puntos de la red, de forma que los nodos intermedios sepan a priori la dirección en la que se tiene que enviar la información perteneciente a cada circuito. Este paradigma permite acelerar enormemente el envío de paquetes entre dos puntos, ya que el procesamiento intermedio es mínimo; esta prerreserva encima permite garantizar una serie de recursos de red para el tráfico que pasa por el circuito. Por eso, este modelo de red se pensó para servicios en tiempo real (multimedia).

En cualquier circuito virtual se pueden distinguir tres fases claramente separadas: 1)�Establecimiento�del�circuito�virtual: esta fase se inicia en la capa de red del emisor, utilizando la dirección del receptor. El emisor envía un datagrama de creación de circuito que provoca que cada nodo intermedio reserve los recursos pedidos de forma iterativa hasta llegar al destino. Cada uno de los nodos intermedios tendrá que actualizar su estado para acomodar el nuevo circuito, o denegar la creación en caso de que no queden más recursos disponibles (normalmente, ancho de banda). Si el establecimiento del circuito puede llegar hasta el destinatario se avisa al emisor indicando que la conexión ha sido satisfactoria y se puede empezar a enviar información. 2)� Transferencia� de� datos: en el caso de que se haya podido establecer el circuito virtual se puede empezar a enviar datos entre los dos puntos. 3)�Desconexión�del�circuito�virtual: esta desconexión puede iniciarla tanto el emisor como el receptor, y se avisa secuencialmente a través de la capa de red a todos los nodos intermedios hasta llegar al otro extremo. Esta desconexión permite liberar los recursos ocupados por el circuito. Actividad ¿Qué diferencias creéis que pueden existir entre el inicio de un circuito virtual en la capa de red y el establecimiento de una conexión en la capa de transporte? (por ejemplo, el three-way-handshaking). Solución El establecimiento de la conexión de la capa de transporte involucra únicamente a dos sistemas finales. Los dos extremos acuerdan la comunicación y determinan los parámetros de conexión, mientras que los nodos intermedios de la red no intervienen. Por el contrario, el establecimiento de un circuito virtual en la capa de red obliga a involucrar a todos los nodos intermedios.


© FUOC • PID_00147723

26

El principal inconveniente que tiene la utilización de circuitos virtuales es que los nodos intermedios tienen que mantener las reservas de recursos pedidas independientemente de que se estén utilizando, con el potencial problema de infrautilizar la red. 2.2.2. Modelo de red en modo datagrama Si enviar información a través de un circuito virtual implica previamente establecer un camino y reservar recursos, en una red en modo datagrama (también llamado conmutación de paquetes), el paquete se envía directamente a la red con una dirección origen y una dirección destino. Entonces, es trabajo de la red (a través de las tablas de direccionamiento de cada encaminador) el hacer llegar el paquete a su destino. Como se puede comprobar, en este tipo de comunicación no hay reserva de recursos ni camino preestablecido entre los extremos de la comunicación. Por lo tanto, a un encaminador le pueden llegar datagramas de diferentes destinos a la vez, y los datagramas pueden seguir caminos diferentes para llegar al destino (dependiendo de los algoritmos de direccionamiento), lo que provoca el efecto lateral de que los paquetes pueden llegar fuera de orden (el paquete número 2 llega antes que el número 1). Las redes en modo datagrama son las más usadas actualmente, debido principalmente a que el protocolo de red de Internet (IP) lo utiliza. A pesar de que hemos visto que el modelo de datagrama hace una utilización de los recursos más eficiente, eso viene con un coste asociado. Con este tipo de redes se complica muchísimo la priorización del tráfico, ya que nunca se sabe a priori cuánto tráfico se recibirá, y lo que es más grave, no se sabe qué prioridad se tiene que dar a cada uno de los flujos de datos presentes en la red, tanto es así que Internet se basa en el paradigma conocido como best effort, que implica que la red no nos da ninguna garantía de calidad y que "lo hará lo mejor que pueda" para hacer llegar el datagrama en su destino. Actividad ¿Cuál de los dos modelos de red vistos consideráis que hace un uso de los recursos más eficiente? Solución El hecho de que un circuito virtual obligue a hacer una prerreserva de recursos implica que se tiene que conocer previamente el modelo y el patrón de tráfico que sigue la aplicación, pero como eso, a priori, no es posible muchas veces, se acostumbra a hacer lo que se conoce como overprovisioning (reservar más recursos de los que se consideran necesarios), lo que inequívocamente lleva a un sistema menos eficiente en términos de recursos. Por su parte, utilizar el modo datagrama no implica ninguna prerreserva, con lo que la red siempre enviará tan rápidamente como pueda la información, siempre y cuando haya recursos disponibles.


© FUOC • PID_00147723

27


2.2.3. Servicio de red orientado y no orientado a la conexión Análogamente a los protocolos de transporte que hemos visto anteriormente, en el nivel de red también podemos tener protocolos orientados a la conexión y otros que no lo sean. La principal diferencia entre las dos alternativas es que en el servicio orientado a conexión se guarda el estado de la conexión, o lo que es lo mismo, se tiene conocimiento de todas las conexiones establecidas, mientras que en el caso del servicio no orientado a conexión no se tiene constancia de las conexiones existentes. Un ejemplo claro de servicio de red orientado a la conexión es el modelo de circuitos virtuales visto anteriormente. Hay que señalar que el diseño de un protocolo de red no orientado a conexión no excluye que a niveles superiores (transporte) se pueda definir un protocolo orientado a conexión. El ejemplo más indicativo de eso es la pila de protocolos TCP/IP, donde TCP es orientado a la conexión mientras que IP no lo es. Tanto es así que la arquitectura actual de Internet sólo proporciona el modelo de servicio de datagrama, lo que no garantiza el orden de los paquetes, el retardo en el envío, ni la llegada del datagrama. 2.3. Direccionamiento en Internet: el protocolo IP

El protocolo de capa de red por excelencia es Internet Protocol (IP). IP es un protocolo que basa el intercambio de información en el modelo no orientado a conexión. IP es el protocolo utilizado en Internet para identificar los nodos de la red, así como también para enviar la información de una forma estándar e independiente de la tecnología de red utilizada. Otra característica muy importante de IP es que no implementa mecanismos que garanticen la integridad de los datos que se envían por la red (eso se hace en la capa de transporte), sólo se comprueba que no haya errores de transmisión en la cabecera.

Todos los protocolos de red requieren algún mecanismo con el fin de identificar los nodos de la red; esta identificación en el protocolo IP se realiza a través de lo que se conoce como dirección IP; actualmente existen dos versiones diferentes del protocolo IP: IPv4 e IPv6. IPv4 es el protocolo más utilizado en la actualidad en Internet, pero, dado el gran crecimiento que ha sufrido la red, se ha propuesto una extensión, IPv6, más actual y que algún día se prevé que sustituya al IPv4.

Ved también En el subapartado "Direccionamiento en Internet: el protocolo IP" se detalla cómo funcionan los protocolos IPv4 e IPv6 y qué ventajas e inconvenientes tienen.

© FUOC • PID_00147723

28

2.3.1. IPv4 IPv4 fue propuesto en 1981 (documento RFC-791) y en la actualidad todavía es el protocolo de red por excelencia. IPv4 define el formato que se tiene que utilizar para enviar información entre dos puntos distantes de la red; el protocolo proporciona mecanismos que determinan cómo se divide el direccionamiento de una forma escalable en una red tan grande como Internet. La cabecera IP IPv4 define qué información de control y qué formato tienen que tener los paquetes que se envían a la red. Por eso, y al igual que con los protocolos de transporte vistos anteriormente, es necesario definir una cabecera que sirva para poder identificar los paquetes. La cabecera de Ipv4 se puede ver en la figura siguiente.

En esta figura podemos ver los siguientes elementos: Versión�(4�bits): indica qué protocolo de red utiliza este datagrama. Para IPv4 está fijado en 0x04. •

Hdr.�Len�(4�bits): la cabecera IP puede tener un tamaño variable a causa del campo de opciones. Ese tamaño indica en qué punto empiezan los datos del protocolo de transporte. En particular, dicho campo indica el valor en función de la cantidad de palabras de 4 octetos que tiene la cabecera; así, un valor de 0x05 quiere decir una cabecera de 20 octetos, el valor usado en la mayoría de los casos por ser el tamaño por defecto cuando no hay opciones.

•

Type�of�Service�(ToS)�(8�bits): este campo permite distinguir entre diferentes tipos de datagramas IP; inicialmente se definieron parámetros en función de: retardo bajo, tasa de transferencia alta o fiabilidad. Así, dependiendo del tipo de tráfico que contenga el paquete, por ejemplo tráfico


© FUOC • PID_00147723

29


interactivo, puede quererse un retardo bajo, o en el caso de que el tráfico sea de baja prioridad, se puede querer un coste mínimo. La lista de los diferentes tipos de servicio se puede encontrar en el documento RFC-1349. En realidad, los encaminadores normalmente ignoran este campo y utilizan la técnica best effort para encaminar los paquetes. •

Total�Length�(16�bits): indica el tamaño total del datagrama en octetos, lo que incluye la cabecera así como el campo de datos. Los 16 bits indican un tamaño máximo del datagrama de 65.535 octetos. Aunque en general el tamaño máximo utilizado es de 1.500 octetos.

•

Identifier�(16�bits),�flags�(3�bits)�y�fragmentation�(13�bits): estos campos hacen referencia a lo que se conoce como fragmentación IP.

•

TTL�(8�bits): inicialmente, este campo hacía referencia al tiempo de vida del datagrama en milisegundos. Pero en la práctica contiene el máximo número de routers que puede atravesar el paquete hasta que llegue al destino. A cada salto, un encaminador decrementa en 1 el valor de este campo, cuando el TTL llega a 0, el paquete es descartado. Con esta técnica se permite descartar datagramas en el caso de que haya algún bucle provocado por algún problema con el sistema de direccionamiento, y así evitar tener paquetes en la red más tiempo del necesario. De este campo se puede derivar que el "diámetro" máximo posible de Internet es de 255 saltos. Aunque en la actualidad no acostumbra a superar los 30.

•

Protocol�(8�bits): este campo indica el protocolo presente en la capa de transporte, que será capaz de interpretarlo. Normalmente, este campo puede ser 0x06 para TCP o 0x11 para UDP. La lista completa se puede encontrar en los documentos RFC-1700 y RFC-3232. Con este enlace entre la capa de red y la de transporte, se puede tener diversos protocolos de transporte y distinguirlos fácilmente, pasando el control al que corresponda de forma eficiente.

•

Header�Checksum�(16�bits): permite detectar algunos tipos de error de transmisión a la cabecera. Es importante señalar que no se comprueba la integridad de la capa de transporte y superiores. Recordemos que IP no garantiza la recepción de los datos. El checksum se calcula tratando cada dos octetos de la cabecera como enteros y sumándolos utilizando aritmética de complemento a 1, ignorando para la suma el mismo campo que contiene el checksum. La integridad se comprueba comparando la suma con la almacenada en la cabecera. En caso de error, el paquete se descarta. Un pequeño inconveniente de este checksum es que cada encaminador tiene que recalcularlo para cada paquete, dado que el campo TTL (y quizás algunas opciones) cambian a cada salto.

Ved también La fragmentación será explicada en el subapartado "Fragmentación IP".

© FUOC • PID_00147723

30

•

Dirección�Origen�(32�bits): indica la dirección origen del paquete.

•

Dirección�Destino�(32�bits): adonde va dirigido el paquete.

•

IP�Options: este campo es el que hace que la cabecera IP pueda ser variable


Ved también Se puede encontrar más información sobre el direccionamiento en el subapartado "Direccionamiento IPv4".

en tamaño. Las opciones, que normalmente no se utilizan, permiten ampliar las funcionalidades de la cabecera IP. A pesar de no hacerse servir casi nunca, el hecho de comprobar su existencia en cada encaminador reduce mucho el rendimiento del protocolo IPv4. Por eso, durante el diseño de la versión 6 del protocolo se cambió la forma de implementar estas opciones. •

Padding: por motivos de eficiencia, los datos tienen que empezar en una posición múltiple de 4 octetos, por lo tanto, en el caso de que algunas opciones introduzcan una desalineación, el padding, que normalmente es todo ceros, alinea a la palabra del siguiente campo.

•

Data�(payload): los datos del datagrama que se pasarán al nivel de transporte, o sea, la información que realmente se quiere transmitir.

Fragmentación IP Uno de los puntos más críticos a la hora de diseñar el protocolo IP fue la necesidad de introducir la fragmentación. La fragmentación IP es necesaria porque no todas las redes, ni todos los protocolos de enlace de datos, pueden transportar paquetes de tamaño arbitrario. En general, el tamaño máximo vendrá delimitado en función de la tecnología de red utilizada. Por lo tanto, a causa de la diversidad de tecnologías que actualmente coexisten en Internet, podemos encontrar casos en los que el tamaño máximo de trama permitido3 sea menor en algún encaminador dentro del camino a seguir por los datagramas, forzando a IP a dividir la trama en fragmentos más pequeños que se puedan transmitir. Un ejemplo puede ser Ethernet, que permite tramas de un tamaño máximo de 1.500 bytes, mientras que una tecnología como Asynchronous Transfer Mode (ATM) en general tiene el máximo en 9.180 bytes. Hace falta señalar que cuando se fragmenta un datagrama IP, cada fragmento tiene que ser autocontenido, y tiene que poder ser ensamblado en el destino final (hacerlo en los encaminadores intermedios supondría una pérdida de rendimiento considerable), por lo que sólo dividir el datagrama no es suficiente, es necesario hacer algún tipo de proceso. Cuando se tiene que dividir un datagrama IP, primero se replica la cabecera IP para cada fragmento, y acto seguido se actualizan los campos de la cabecera: identification, flag y fragmentation offset. Así, todos los fragmentos pertenecientes al mismo datagrama tendrán el mismo identificador, cada fragmento contendrá el desplazamiento y finalmente el flag, que será 1 si hay más paquetes, o 0 si es el último. Por las restricciones en la implementación, y para reducir el número de bits que se utilizan para almacenar este desplazamiento, se de-

(3)

En inglés, Maximum Transfer Unit (MTU).

© FUOC • PID_00147723

31

cidió hacerlo con múltiplos de 8 bytes; así, un desplazamiento de 64 bytes –o sea, que el fragmento IP contenga desde el byte 65 del datagrama original– se representará con un 8 en el campo fragmentation offset (ya que 8 x 8 = 64). Ejemplo de fragmentación En la figura siguiente se puede ver el caso en que un equipo envía un paquete de tamaño MTU = 2.500 bytes. Lo que quiere decir que el paquete tendrá 2.480 bytes de información útil y 20 de cabecera. A la hora de fragmentar se generan dos paquetes diferentes, uno de 1.480 + 20 y otro de 1.000 + 20. Como se puede ver, el tamaño útil no cambia, pero, por el hecho de tener dos paquetes diferentes, estamos replicando la cabecera. El valor del identificador viene dado por un contador interno en el encaminador que fragmenta, el desplazamiento (offset) para el primer fragmento es 0, y el flag 1, lo que indica que todavía hay más fragmentos, para el segundo fragmento el offset contiene un 185, ya que se especifica con grupos de 8 bytes, y un 0 en el flag, que indica que se trata del último fragmento del datagrama original. Cuando el datagrama llegue a su destino final será reensamblado y pasado a los niveles superiores de forma transparente.

Direccionamiento IPv4 Los protocolos de red necesitan disponer de una dirección única que permita identificar todos los nodos de la red. En el caso de Ipv4, tal como se puede deducir de la cabecera IPv4, la máxima cantidad de direcciones disponibles es muy grande: 232 (4.294.967.296). Para simplificar su escritura, se dividen los 32 bit en 4 bloques de 8 bits cada uno, y además, en vez de utilizar la representación binaria, que es poco legible, en la práctica se escribe la dirección IP en notación decimal separada por puntos; la dirección estará formada por 4 bloques de números entre 0 y 28 - 1 (255). Representación binaria y decimal de una dirección IP

Además, tener un número tan grande de direcciones supone un enorme problema de gestión, por lo que se propuso un sistema de asignación de direcciones jerárquico. En Internet, las direcciones IP están compuestas por dos partes, la parte de red y la parte del equipo, lo que se utiliza para poder estructurar las direcciones y organizarlas por zonas administrativas.


32

© FUOC • PID_00147723


La parte de red está formada por los bits superiores de la dirección IP e indica a qué red pertenece un conjunto de equipos, o lo que es lo mismo, cuál es el encaminador de salida del conjunto de equipos. Por el contrario, la parte del equipo son los bits inferiores de la dirección IP e identifican el equipo dentro de su red.

Inicialmente, esta división con redes se hizo a través de clases, concretamente se definieron 5 clases diferentes (A, B, C, D y E) tal como muestra la tabla siguiente: •

Las direcciones�de�clase�A son las destinadas a empresas muy grandes, como por ejemplo IBM, o grandes operadoras americanas, como AT&T WorldNet Services, y proporcionan acceso a 224 (16.777.216) equipos por red, donde 8 bits están destinados a identificar la red y el resto hasta los 32 se utilizan para los equipos finales. De direcciones de clase A hay un total de 27 (255).

•

Las direcciones�de�clase�B son las que se dan a grandes entidades, universidades y determinados proveedores de Internet. Permiten repartir 216 (65.536) equipos por red, y hay un total de 214 (16.384) direcciones de clase B.

•

En el caso de las direcciones�de�clase�C, son las destinadas a medianas 8

empresas con fuerte presencia en Internet; en este caso se dispone de 2 21

(256) direcciones, con un total de 2

(2.097.152) direcciones de tipo C a

repartir. •

Con respecto a las direcciones�de�clase�D, se consideran un tipo de clase especial, denominadas clases multicast, que sirven para enviar el tráfico denominado punto multipunto.

•

Finalmente, las direcciones�de�clase�E están reservadas para un uso futuro.

División de redes por clases Clase

Bits�iniciales

Bits�Red

Rango�Red

A

0

7 (+1)

1.0.0.0-127.0.0.0

B

10

14 (+2)

128.0.0.0-191.255.0.0

C

110

21 (+3)

192.0.0.0-223.255.255.0

D

1110

-

224.0.0.0-239.0.0.0

E

11110

-

240.0.0.0-255.0.0.0

Carencia de direcciones IP El reparto de clases A es uno de los causantes de la fuerte carencia de direcciones IP en la actualidad.

© FUOC • PID_00147723

33

Direcciones de propósito específico Aparte de la división en redes también se destinaron una serie de direcciones de propósito específico para casos especiales: •

Direcciones�de�host. Indican un equipo dentro de la red actual y tienen la forma 0.host, donde host es la parte del equipo de la red actual, o sea, que la parte de la dirección de red es todo 0.

•

Direcciones�de�red. Hacen referencia a la red, pero no a los equipos dentro de ella; las direcciones de red son de la forma red.0 para direcciones de clase C, red.0.0 para la clase B y red.0.0.0 para la clase A, o, lo que es lo mismo, que la dirección del equipo de red está toda en 0. Hay un caso especial, que es la dirección 0.0.0.0, que indica "este host" de "esta red", aunque no siempre se implementa en los sistemas operativos actuales.

•

Direcciones�de�broadcast. Indican todos los equipos de una red concreta. La dirección se representa con red.255 para direcciones de clase C. Análogamente al caso de las direcciones de red, las de clase B serán red.255.255, y las de clase A, red.255.255.255, o sea, que la dirección del equipo de red es todo 1. Siempre que se reciba un datagrama en la dirección de broadcast todos los equipos tienen que responder.

Las direcciones de broadcast, a su vez, tienen una dirección especial, que es la 255.255.255.255, que hace referencia a toda la red (Internet). Entonces, si alguien enviara un datagrama a la dirección 255.255.255.255 toda la Internet tendría que responder. Como eso provocaría graves problemas de escalabilidad y exceso de tráfico, no hay ningún encaminador que reenvíe tráfico broadcast por sus interfaces. El tráfico de broadcast siempre se quedará en la red que lo ha emitido.

Actividad Dada la dirección IP 120.1.32.54, indicad cuál es la dirección de red, la dirección del host y la dirección de broadcast de la red. Solución La dirección 120.1.32.54 forma parte de las direcciones de clase A, por lo tanto, la dirección de red será la 120.0.0.0, la del host la 0.1.32.54 y la de broadcast sería la 120.255.255.255.

•

Direcciones�de�loopback. Son desde la 127.0.0.0 hasta la 127.0.0.255 y son las que se utilizan internamente por los equipos. Cuando un equipo arranca, automáticamente crea una interfaz virtual (interfaz de loopback) para uso interno del sistema operativo, normalmente sólo se utiliza la 127.0.0.1.

•

Direcciones�privadas. Son las utilizadas por redes locales internas que no salen a Internet. La lista con todos los rangos privados se puede encontrar


34

© FUOC • PID_00147723


en la tabla siguiente. Como se observa en dicha tabla, se pueden configurar internamente diversos rangos de direcciones privadas, cuya utilidad es evitar colisiones en asignaciones de direcciones en configuraciones internas con nodos de otras redes del exterior. Otra funcionalidad es permitir asignar más direcciones a nuestras redes que IP públicas asignadas por los operadores. Lista de rangos de direcciones privadas Clase

Rango�Red

Número�de�subredes

A

10.0.0.0-10.255.255.255

1

B

172.16.0.0-172.31.255.255

16

C

192.168.0.0-192.168.255.255

255

Network Address Translation El problema principal de las direcciones privadas es que no pueden acceder a Internet directamente, los encaminadores nunca enviarán a Internet el tráfico originado o con destino a direcciones privadas, ya que no saben cómo encaminar el salto siguiente. Con el fin de evitar esta limitación y permitir la transferencia de datos entre direcciones privadas y públicas, los encaminadores incluyen una técnica denominada Network Address Translation (NAT).

Network Address Translation (NAT) Por lo que se puede deducir de lo que se ha visto hasta ahora, cada equipo de una red IPv4 tiene que disponer de una IP pública para poder acceder a la red. Uno de los problemas principales que se encuentran cuando se piden IP a las operadoras es, generalmente, que el usuario (o la empresa) tiene más equipos que IP asignadas. Un ejemplo de eso es el del usuario con conexión ADSL, que recibe una sola IP por parte de la compañía telefónica, mientras que muchas veces el usuario dispone de diversos equipos, como el PC de sobremesa, el portátil, la PDA, etc. Con el fin de permitir que todos los equipos se puedan conectar a la red al mismo tiempo hay dos opciones, pedir más IP (solución difícil y cara) o utilizar direcciones IP privadas y configurar el encaminador para que haga la conversión desde la dirección IP privada a la IP pública disponible. Eso se puede conseguir mediante lo que se conoce como NAT. NAT es una tabla de traducción que se utiliza de la siguiente forma. Si, por ejemplo, un cliente con dirección privada quiere establecer una conexión con un equipo que tiene una dirección IP pública (punto 1 de la figura siguiente) –por ejemplo, un servidor–, el cliente enviará el paquete hacia el encaminador de su red. El mencionado encaminador tendrá configurada una tabla de traducción, donde transformará la IP origen del datagrama en una IP pública que tenga reservada a tal efecto. Para completar la traducción, el encaminador mapeará el puerto origen (de la capa de transporte) en un nuevo puerto origen asignado por el encaminador. El punto 2 de la figura muestra un ejemplo, en el que el encaminador transforma la IP origen (192.168.1.4) y el puerto origen (5.674) del equipo en la IP pública del encaminador (123.26.1.12) y un puerto asignado dinámicamente (20.543 en el ejemplo). La estación destino ve un

Referencia bibliográfica La NAT está definida en detalle en los documentos RFC2663 y RFC-3022.

© FUOC • PID_00147723

35

datagrama como si hubiera sido enviado por el encaminador, al que responde de la forma habitual usando TCP/IP. Finalmente, el encaminador, al recibir la respuesta, mira la tabla de traducción y deshace el cambio para enviar el paquete final a la estación origen. Si la entrada no hubiera estado en la tabla, el encaminador hubiera asumido que el paquete iba realmente dirigido a él. Ejemplo de red con NAT

Este mecanismo es muy útil cuando se quiere evitar el uso de direcciones públicas, a pesar de que tiene una serie de inconvenientes que no permiten usarlo en determinados entornos. Primero, hay protocolos de aplicación (por ejemplo, FTP) que incrustan la IP del cliente dentro del datagrama, esta IP es usada por el servidor para establecer una nueva conexión (por ejemplo, el caso del FTP activo), y como el cliente incrusta la IP privada, eso impide que se pueda establecer la conexión. Otro problema importante es que todas las conexiones se tienen que iniciar desde el equipo con IP privada, ya que el encaminador tiene que establecer la entrada en la tabla de traducción antes de poder enviar información hacia el equipo con IP privada, lo que normalmente implica que no se puedan tener servidores con IP privadas. Hay que decir, sin embargo, que eso se puede solucionar con una técnica denominada Port Address Translation (PAT), en la que el encaminador tiene configurado de forma estática un mapeado, por lo que cuando llega un datagrama a un puerto concreto, automáticamente reenvía el paquete hacia el equipo que esté configurado con IP privada. En según qué entornos, el PAT se conoce también como Destination NAT (DNAT) o incluso como puerto Forwarding, pero la idea de fondo es la misma.


36

© FUOC • PID_00147723

Classless inter Domain Routing Una vez definidas las diferentes clases de redes, se vio que esta solución era claramente insuficiente, ya que forzaba igualmente a las grandes y medianas operadoras (con clases A y B) a gestionar desde un solo equipo un número de direcciones demasiado grande, por lo que se propuso el Classless inter Domain Routing (CIDR).

CIDR propone un mecanismo más flexible para poder subdividir nuestras redes. CIDR no sustituye la división por clases, que continúan siendo las unidades básicas de asignación de direcciones; por el contrario, CIDR nos permite dividir las direcciones asignadas en subredes más pequeñas y manejables.

Así, con CIDR, la separación entre el equipo y la red se consigue gracias a una máscara. Esta máscara tiene la forma de una dirección IP, que enmascara los bits de una dirección normal para poder distinguir el equipo y la red de forma sencilla. Ejemplo de máscara Una máscara de 255.255.255.0 permite separar la dirección de red de la del equipo final haciendo AND con la dirección IP, así: 143

. 45

.1

. 23

255

. 255

. 255

.0

143

. 45

.1

.0

De donde se puede extraer la dirección de la subred (los unos de la máscara - 143.45.1) y la dirección del equipo (los ceros de la máscara - 23). En este caso, la red constará de 28 IP válidas como una clase C, de las que 28 - 2 serán asignables a equipos; hay que recordar que las direcciones especiales de red y de broadcast (143.45.1.0 y 143.45.1.255, respectivamente) no son asignables. La representación de esta subred se hace con la siguiente nomenclatura: 143.45.1.23/255.255.255.0.

Como se puede observar, eso nos da un nivel más fino de división que simplificará mucho la gestión interna de redes; si una entidad dispone de una clase B (146.43.0.0), internamente la entidad puede decidir subdividir las 65.536 direcciones en varias subredes, por ejemplo, con 256 subredes de 256 IP cada una: desde la 146.43.0.0/255.255.255.0 a la 146.43.255.0/255.255.255.0. Observad que los valores de 255 y 0 para la dirección de red son correctos, sin que representen direcciones de broadcast y de red, respectivamente. Eso lo podemos saber gracias a la máscara. Una restricción no escrita, pero generalmente adoptada a la hora de definir las máscaras, es que todos los unos de la máscara tienen que ser consecutivos.


37

© FUOC • PID_00147723


Máscaras correctas e incorrectas Máscaras como 255.145.0.0 se consideran inválidas, ya que, traducidas a formato binario, daría: 11111111 10010001 00000000 00000000 Mientras que otras, como 255.255.128.0, son totalmente correctas ya que, en formato binario, resulta: 11111111 11111111 11111110 00000000 Donde todos los unos son consecutivos, a pesar de no estar alineados en el octeto.

Esta restricción de los unos consecutivos nos permite simplificar la representación de la máscara en un formato más compacto; así, otra forma de indicar la separación entre la red y el equipo es a través de un formato que indica cuántos bits representan la red, por ejemplo, 143.45.1.23/24 indica que la máquina 143.45.1.23 pertenece a la red 143.45.1.0/255.255.255.0, o, lo que es lo mismo, que tiene 24 bits para la dirección de red y 8 para la de los equipos. Por otra parte, gracias a la clasificación por subredes, los encaminadores tienen el trabajo más fácil, ya que para poder decidir la ruta que tiene que tomar cualquier datagrama, es suficiente mirar la red de destino, y no es necesario comprobar toda la dirección IP. La dirección IP entera, idealmente, sólo la mirará el último router de la cadena, o sea, el que esté dentro de la misma subred a la que pertenezca aquel destino. Para implementar este mecanismo, los encaminadores basan la decisión de direccionamiento en una política llamada Longest Prefix Match, lo que significa que, de todas las rutas posibles, siempre se coge la que tiene más bits coincidentes con el destino del paquete. Actividad Dentro de las siguientes subredes e IP, indicad cuántas IP asignables puede contener la red y explicad el significado. Dirección

IP�asignables

Explicación

147.83.32.0/24

1.23.167.23/32

1.23.167.0/32

147.83.32.0/16

Solución Dirección

IP�asignables

147.83.32.0/24

254

Explicación Es una dirección de red en la que tenemos 8 bits para los equipos; sabiendo que la 8

dirección de broadcast y la de red no son asignables, acabamos con el total de 2 - 2 direcciones para asignar. 1.23.167.23/32

1

Dirección con una subred con sólo un equipo. No es útil en un caso real, pero es correcta.

38

© FUOC • PID_00147723


Dirección

IP�asignables

Explicación

1.23.167.0/32

1

Como no hay parte de equipo, todo es de red, el hecho de que el último octeto sea 0 hace que la IP no sea una dirección de red genérica sino una específica, como en el caso anterior.

147.83.32.0/16

1

Hace referencia al equipo 32.0 de la red de clase B 147.83.0.0. Hay que señalar que no es una dirección de red, ya que no todos los bits de fuera de la máscara son 0; así, se trata como una dirección de equipo.

Actividad En la dirección de clase B 143.45.0.0/16, indicad qué subredes /20 se pueden crear y cuántos equipos contienen cada una. Solución

El CIDR se utiliza generalmente en conjunción con la máscara de subred de 4

tamaño variable , técnica que tiene por objetivo optimizar la utilización de las direcciones IP a través de una asignación inteligente de las máscaras de red. Esta asignación se hará ahora teniendo en cuenta el número de máquinas de cada subred y se asignarán máscaras de tamaño ajustado a las necesidades particulares de cada una. VLSM se puede ver como la creación de subredes de las subredes. Actividad 1) Dada la red de la figura, se nos proporciona el rango de direcciones 147.83.85.0/24. Se pide que se asignen rangos de direcciones a todas las subredes y a los enlaces entre los encaminadores.

(4)

En inglés, Variable Length Subnet Mask (VLSM).

© FUOC • PID_00147723

39

2) ¿Qué problema tiene la asignación de direcciones hecha en el ejercicio anterior? Solución 1) La asignación de direcciones se puede hacer siguiendo la siguiente política: •

Los 20 equipos más el router necesitan un total de 5 bits (25 = 32).

•

Los 10 + 1 equipos tienen suficiente con 4 bits (24 = 16).

•

Los 5 + 1 equipos necesitan 3 (23 = 8), con lo que esta subred no podrá crecer más.

•

Finalmente, los enlaces punto a punto necesitarán 2 bits, ya que necesitamos espacio para las direcciones de broadcast y de red.

En resumidas cuentas, nos harán falta un prefijo /27, un /28, un /29 y tres prefijos /30 respectivamente. De esta manera, una posible asignación sería: •

Los 20 equipos pueden usar la 147.83.85.0/27, donde el último byte sería 000XXXXX. Con dirección de red 147.83.85.0 y dirección de broadcast 147.83.85.31.

•

Los 10 equipos dispondrán de la 147.83.85.32/28 donde el último byte será 0010XXXX. Con dirección de red 147.83.85.32 y dirección de broadcast, 147.83.85.47.

•

En el caso de los 5 equipos utilizaremos la subred 147.83.85.48/29 donde el último byte será 00110XXX. Con dirección de red 147.83.85.48 y dirección de broadcast, 147.83.85.55.

•

Finalmente, los tres prefijos /30 (de los enlaces entre los encaminadores) se pueden dividir con el último byte 001110XX, 001111XX y 010000XX, respectivamente. O sea, 147.83.85.56/30, 147.83.85.60/30 y 147.83.85.64/30. Con direcciones de red 147.83.85.56, 147.83.85.60 y 147.83.85.64. Con direcciones de broadcast 147.83.85.59, 147.83.85.63 y 147.83.85.67.

2) El problema de esta asignación viene dado por el hecho de que se ha ajustado demasiado el número de bits para cada subred, y en el caso de que crezca el número de equipos (especialmente en la subred de cinco equipos), nos tocaría redimensionar la red de nuevo con el coste que eso supone.


© FUOC • PID_00147723

40


Tipo de datagramas IP

IPv4 especifica tres tipos de tráfico claramente diferenciados dentro de la red: unicast, broadcast y multicast.

El tráfico� unicast es el más común, la comunicación está formada por dos interlocutores que se intercambian información, a menudo estas conexiones son desde un cliente hacia un servidor, que a la vez puede tener conexiones unicast hacia otros clientes. El tráfico�broadcast se basa en enviar la información a todos los equipos presentes en una subred. Como ya hemos visto anteriormente, eso se puede conseguir enviando un paquete a una dirección que sea la dirección de red y todo 1 a la dirección del equipo final, por ejemplo, para la red 126.76.31.0/24, la dirección de broadcast sería 126.76.31.255. Finalmente, el caso del tráfico�multicast se basa en el paradigma de enviar información desde un solo origen hacia muchos destinos a la vez; la base del tráfico multicast es que el emisor no tiene por qué tener conocimiento de quiénes serán sus receptores (al contrario de la política de unicast, que requiere conocer a los interlocutores). Eso se consigue a través de lo que se conoce como grupos de multicast. Como se ha visto anteriormente, la Internet Assigned Numbers Authority (IANA) ha reservado las direcciones de tipo D a multicast, éstas son las que van del rango 224.0.0.0 hasta el 239.0.0.0. Dentro de este grupo de direcciones hay unas cuantas reservadas a grupos multicast conocidos como permanentes. Así, si una estación concreta está interesada en recibir un contenido multicast, lo que hará será suscribirse al servicio mediante el protocolo Internet Group Management Protocol (IGMP), que especifica el formato del paquete que se tiene que generar con el fin de poder registrarse en un grupo y poder recibir el contenido. IGMP soporta dos tipos de paquetes, los de pregunta y los de respuesta. Normalmente, los de pregunta son paquetes dirigidos a todos los equipos donde los que tienen sesiones multicast activas responden, así los encaminadores (que tienen que tener soporte para multicast) pueden construir lo que se conoce como el árbol multicast, para encaminar los paquetes hacia sus destinos.

La ventaja principal de multicast es que la información que se envía, en vez de replicarse desde el origen una vez por cada destino forma un árbol de manera que se minimiza el número de copias.

Requisitos del tráfico broadcast Hay que señalar, sin embargo, que enviar tráfico broadcast normalmente requiere algún privilegio en la red (ser administrador), además, los encaminadores en general no propagan este tipo de tráfico con el fin de evitar problemas de seguridad, como, por ejemplo, ataques del tipo Denial of Service (DoS).

© FUOC • PID_00147723

41

Actividad Un servidor de chat tiene en un momento dado un total de 80 clientes conectados por todo el mundo. Indicad qué número y de qué tipo son las conexiones que tiene abiertas este servidor. Solución Dado que el chat es un protocolo que utiliza TCP/IP, y que los clientes, a pesar de hablar entre ellos, pasan siempre por el servidor, se trata del típico escenario con 80 conexiones unicast entre los 80 clientes y el servidor.

Actividad Un administrador de la red 147.83.0.0/16 quiere enviar un paquete de broadcast a la subred 147.83.20.0/24. Indicad qué dirección de destino tendría el paquete, cuántos paquetes se generarían y a cuántas máquinas como máximo podría llegar. Solución Dado que la subred a la que se quiere enviar el broadcast tiene 8 bits, eso implica que se generaría un solo paquete con dirección destino 147.83.20.255 y que lo recibirían como máximo 255 - 2 = 253 estaciones. Ya que la dirección 147.83.20.0 y la 147.83.20.255 están reservadas para la dirección de red y la de broadcast, respectivamente.

El futuro de Ipv4 Cuando se diseñó IPv4 se creía que su gran número de direcciones IP (232) sería suficiente para poder aguantar el gran crecimiento que se esperaba de una red como Internet. Hay que recordar que Internet entró en funcionamiento en 1969 con el nombre de ARPANet, un proyecto subvencionado por el Departamento de Defensa de Estados Unidos. Eso provocó que, cuando Internet se desplegó al cabo de unos años en la red comercial, el reparto de direcciones no se hiciera de forma equitativa, y las grandes empresas estadounidenses pudieron adjudicarse una gran cantidad de direcciones de clase A, dejando a países, como China y otros que se han desarrollo posteriormente, con muchas menos direcciones de las necesarias. Como referencia, Estados Unidos tiene sobre 1.500 millones de direcciones asignadas, mientras que China, con una población mucho más numerosa, sólo dispone de 200 millones, aproximadamente. Para hacerse una idea, España tiene asignadas en la actualidad en torno a 22 millones. Con este paradigma, muy pronto se ve que con la actual política para el reparto de direcciones, dentro de muy poco tiempo ya no quedarán direcciones IPv4 disponibles para asignar, lo que implicará inevitablemente que Internet no podrá crecer más. Con el fin de minimizar este problema, se diseñó la NAT, como ya hemos visto, que permite utilizar direcciones privadas para acceder a la red con una sola IP pública. En la actualidad, países como China o la India están haciendo un uso intensivo de la NAT por la falta de direcciones disponibles.


© FUOC • PID_00147723

42

Como esta solución no es escalable y comporta una serie muy importante de problemas a los proveedores de servicios se llegó a la conclusión de que los 32 bits de direccionamiento del protocolo IPv4 eran insuficientes, por eso se diseñó el protocolo IPv6, como veremos a continuación. 2.3.2. IPv6 La carencia de direcciones IPv4 incentivó el diseño de un nuevo protocolo de red, IPv6. En la actualidad, IPv6 está totalmente desarrollado, aunque todavía no es posible utilizarlo dentro de la red comercial, ya que los operadores todavía no han preparado sus equipos ni tampoco han hecho el reparto de direcciones a sus usuarios. Eso, y la dificultad de implantar progresivamente esta nueva versión y sustituir la anterior es lo que está retrasando su incorporación en el ámbito comercial. Este subapartado describe brevemente este protocolo y destaca sus diferencias con la versión anterior, así como las novedades que incorpora. Para acabar el subapartado, se describen los principales problemas que hay para la migración de Ipv4 a IPv6. Motivación Inicialmente, a la hora de diseñar el protocolo, se pensó que no era necesario crear un protocolo entero y que sería suficiente con hacer una adaptación de IPv. Pero enseguida se vio que, para poder disfrutar de buenas optimizaciones en comparación con la versión anterior, harían falta bastantes más cambios. Así se optó por un diseño que tiene poco en común con la versión anterior. El motivo principal que llevó a plantearse una nueva versión del protocolo era el limitado rango de direcciones que permite IPv4, que, aunque pueda parecer muy elevado, se vio que sería claramente insuficiente para cubrir la demanda del mercado en un futuro. Sobre todo, la aparición en los últimos años de una gran cantidad de dispositivos móviles que quieren formar parte de la gran red que es Internet ha provocado rápidamente que los 32 bits de direccionamiento IPv4 sea insuficiente, tanto es así que si todos estos dispositivos se quisieran conectar de forma simultánea en la red, los operadores probablemente tendrían problemas por la falta de direcciones IPv4. Para ver este problema sólo hay que pensar en cuántos teléfonos móviles hay en la actualidad; sólo en el Estado español hay alrededor de 44 millones, mientras que el número de IP que hay asignadas actualmente en el país es de unos 22 millones. Eso, sin contar los usuarios que se conectan desde sus hogares. Cabría pensar que el problema se podría minimizar con la utilización de NAT, pero, a la larga, eso puede suponer un grave problema de rendimiento en los encaminadores por tener que mantener las tablas de traducción de direcciones de millones de conexiones a la vez. Encima, cada vez hay más pequeñas y medianas empresas que quieren ofrecer a sus clientes una serie de servicios que precisan una


Implantación del protocolo IPv6 Por motivos económicos no está implantado todavía IPv6, y si la demanda de direcciones IPv4 sigue al ritmo actual, se prevé que la IANA asignará el último rango de direcciones IPv4 a mediados del 2011 y que las autoridades regionales agotarán las que tienen pendientes de asignar en el 2012, lo que seguramente forzará a muchos países a adoptar prematuramente IPv6. En este sentido, países como Japón, China, la India y algunos de América del Sur, ya han adoptado el protocolo y utilizan algunas técnicas que permiten la interoperabilidad de los dos protocolos.

© FUOC • PID_00147723

43

conexión permanente a la red, con el consecuente gasto de direcciones y la imposibilidad de utilizar la NAT masivamente. IPv6 soluciona este problema proponiendo un campo de direcciones de 128 bits. Cabecera IPv6 La cabecera IPv6 tiene una longitud fija de 40 octetos (tal como se puede ver en la figura siguiente), y consta de los campos siguientes: •

Version�(4�bits): indica la versión del protocolo que contiene el paquete. Este campo tiene el mismo significado que el de la versión IPv4, pero ahora con el valor0x06.

•

Traffic�Class�(8�bits): este campo clasifica un paquete dentro de un tipo de tráfico determinado, conceptualmente es el equivalente del Type Of Service (TOS) de IPv4.

•

Flow�Label�(20�bits): sirve para etiquetar un conjunto de paquetes que tengan las mismas características; servirá para poder ofrecer calidad de servicio.

•

Payload�Length�(16�bits): longitud del payload del paquete, o sea, el paquete sin la cabecera IP. El tamaño viene representado en octetos.

•

Next�Header�(8�bits): este campo es una gran innovación de IPv6 respecto de IPv4, dado que permite tener una cabecera básica de tamaño fijo. Este campo indica la posición en que se puede encontrar la siguiente cabecera, ahorrando así tiempo de proceso a los encaminadores intermedios al no haber opciones.

•

Hop�Limit�(8�bits): este campo es equivalente del TTL de IPv4, pero cuenta directamente hops y no tiempo.

•

Source�Address�(128�bits): dirección del host que ha originado el paquete.

•

Destination�Address�(128�bits): dirección del host al que va destinado el paquete.


© FUOC • PID_00147723

44

Cabecera IPv6

A partir de los datos de la cabecera se puede observar que la diferencia más directa que hay entre ambos protocolos es la longitud de las direcciones IP, donde IPv4 tiene 32 bits, IPv6 pasa a tener 128. Este aumento en el espacio de direccionamiento permite que el rango de direcciones de la red pase de 232 a 2128 direcciones posibles.

Como ahora tenemos muchos más bits para la dirección, la forma de especificar direcciones IPv6 se hace con la notación� de� los� dos� puntos. Donde una dirección IPv6 se representa con bloques de 16 bits representados en hexadecimal y separados por el símbolo ":". Por ejemplo, 2001:0DB8:0000:0000:0319:8A2E:0370:7348. Una simplificación de esta notación se puede aplicar en el caso de que una dirección tenga muchos 0 consecutivos; la forma abreviada de representarla es utilizando "::"; así, la forma compacta de representar la dirección anterior sería: 2001:0DB8::0319:8A2E:0370:7348. Otra diferencia notable entre IPv4 e IPv6 es la jerarquización de las direcciones. La asignación de direcciones IPv4 se hizo, en su tiempo, de una forma muy anárquica, dado que no se esperaba que el crecimiento de Internet fuera tan espectacular. Actualmente, cada corporación u operadora de telefonía tiene rangos de direcciones muy dispersos y mal dimensionados, lo que hace extremadamente difícil la gestión de las direcciones disponibles, la asignación de las nuevas y el direccionamiento global. Por eso, lo que ha hecho IPv6 ha sido jerarquizar de una forma más inteligente el reparto de sus direcciones, de forma que cada país, operador o ISP, dispone de un rango concreto con un número de direcciones proporcional a su posible utilización de la red. Independientemente de la mejora de esta jerarquía en cuanto a localización geográfica, el hecho de separar de esta manera las direcciones permite asignar nuevas de una forma mucho más sencilla que hasta ahora.


45

© FUOC • PID_00147723

De forma parecida a IPv4, se puede identificar qué tipo de dirección es sólo con el prefijo de la dirección IPv6, como indica la siguiente tabla. Asignación de direcciones Prefijo

Espacio�de�asignación

0000::/8

Reservado. Las direcciones de loopback y las direcciones con integración de IPv4 salen de este prefijo

0100::/8

Reservado

0200::/7

Reservado

0400::/6

Reservado

0800::/5

Reservado

1000::/4

Reservado

2000::/3

Dirección unicast global. De aquí sale el rango de direcciones 125 que se repartirán a los usuarios. Hay 2 direcciones disponibles.

4000::/3

Reservado

6000::/3

Reservado

8000::/3

Reservado

A000::/3

Reservado

C000::/3

Reservado

E000::/4

Reservado

F000::/5

Reservado

F800::/6

Reservado

FC00::/7

Dirección unicast local única

FE00::/9

Reservado

FE80::/10

Dirección de enlace local unicast (link-local)

FEC0::/10

Reservado

FF00::/8

Direcciones multicast

Un hecho muy interesante que se consideró para hacer esta asignación de direcciones es que da la posibilidad de representar direcciones de diversas tecnologías incrustadas dentro de la nueva versión del protocolo. De esta manera, se pueden representar direcciones IPv4, e incluso direcciones hardware del enlace de datos (como, por ejemplo, Ethernet). La gran ventaja de insertar otros tipos de direcciones directamente en IPv6 es que tienen un prefijo asignado; así, por ejemplo, para tener una dirección Ethernet de un equipo dentro de un IPv6 el prefijo LAN es FE80::/10. Por tanto, si la dirección de la tarjeta Ethernet es 00:90:F5:0C:0F:ED, entonces, la dirección IPv6 queda así: FE80::0090:F50C:0FED. Como se puede observar, el pro-


© FUOC • PID_00147723

46

ceso también se puede realizar a la inversa, cuando llega un paquete con el prefijo de red FE80 ya se puede suponer que se trata de una dirección local (link local) y se puede extraer la dirección hardware fácilmente. Además, con este mecanismo, cualquier interfaz de red puede configurarse de forma automática y autónoma.

Hay que señalar que IPv6, aparte de tener direcciones unicast, broadcast y multicast, como IPv4, añade soporte para un cuarto tipo, que son las direcciones anycast.

Las direcciones anycast son una gran innovación de IPv6, sobre todo porque aprovechan las direcciones unicast ya existentes. Así, una dirección unicast se vuelve anycast desde el momento en que se asigna una misma IPv6 a más de una interfaz (incluyendo equipos diferentes). La idea que hay detrás de esta implementación es que responda a las peticiones de un servicio concreto la estación más próxima. Imaginemos dos servidores web con la misma IPv6, por ejemplo, 2001:0DB8::0319:8A2E:0370:7348, cuando la red reciba un paquete dirigido hacia esta IPv6, lo enviará a las dos estaciones, la primera que responda será la que esté más cerca del equipo que hace la petición. Actualmente, por complejidades en la implementación de este tipo de direcciones, sólo se utilizan para encaminadores. Así, una subred puede tener más de un encaminador para salir a Internet usando el mismo prefijo, y cada equipo utiliza el que esté más próximo a la estación, que consigue de forma sencilla un sistema de balanceo de carga.

Otra innovación relevante que incorpora IPv6 es la utilización mucho más intensiva del tráfico multicast dentro de las redes locales, tanto es así que los equipos, por defecto, escuchan a direcciones multicast con el prefijo FF02::1:FF00:0000/104, con el fin de evitar la generación de tráfico broadcast que afecta a todos los equipos de la subred y no siempre es deseable. Otras mejoras menores que introduce este protocolo son: •

Mecanismo� de� opciones� ampliado: las opciones forman parte de una cabecera colocado entre la cabecera IP propiamente dicho y la cabecera de la capa de transporte. Esta forma de poner las opciones permite una gestión más simple de las cabeceras por parte de los dispositivos que tienen que tratar el paquete hasta que llega a su destino, permitiendo un sistema más simple y flexible.

•

Direcciones�de�autoconfiguración: la asignación dinámica de direcciones ha sido sustancialmente mejorada con respecto a su predecesor. Uno de los motivos principales de eso es el hecho de que se puede añadir la dirección hardware dentro de la dirección IPv6; así, sólo con un prefijo dado por el dispositivo de direccionamiento más próximo y con la dirección hardware se garantiza una dirección única a escala mundial. Siempre


© FUOC • PID_00147723

47

que se utilice el prefijo asignado por el operador a la hora de generar la dirección. •

Facilidad�para�la�asignación�de�recursos: lo que con IPv4 era el Type of Service ahora se llama Traffic Class, aunque también se tiene la posibilidad de marcar flujos individuales, lo que da mucha más flexibilidad a la hora de marcar tráfico prioritario.

•

Capacidades�de�seguridad: como la seguridad, hoy día, es un tema tan importante, IPv6 incluye características de autenticación y privacidad. Por defecto, IPv6 incluye funcionalidades nativas para la creación de redes privadas virtuales (VPN, en la abreviatura en inglés) a través de IPsec (RFC4301), protocolo de cifrado de los datos en tiempo real que con IPv4 era opcional. Actividad Un PC con una tarjeta Ethernet con MAC 34:27:A4:6F:AE:53. El operador le proporciona el prefijo 2001:0A54:0039::/48. Indicad la dirección link-local y la dirección de autoconfiguración de este equipo. Solución La dirección link-local vendrá dada por el prefijo link-local, así la dirección será: FE80::3427:A46F:AE53. Mientras que la dirección de autoconfiguración sale del prefijo y del MAC, por lo tanto: 2001:0A54:0039::3427:A46F:AE53.

Problemas de la migración en IPv6 Uno de los motivos principales por los que todavía se trabaja con IPv4 es la dificultad que comporta la migración al nuevo protocolo. La incompatibilidad de las direcciones y de las cabeceras de ambos protocolos hace que la actualización a la nueva versión no sea fácil. También hay que tener en cuenta que las aplicaciones existentes sólo soportan el sistema de direcciones de IPv4, que para aceptar las nuevas direcciones se tiene que cambiar el código de la aplicación, y también todos los llamamientos al sistema de acceso a la red. Aparte del nivel de aplicación, hay otro problema muy grave. Dada la gran diversidad de redes que forman Internet, hay funcionando equipos muy diversos, y no todos esos equipos de comunicaciones tienen soporte para el nuevo protocolo, por lo que se tiene que actualizar el sistema operativo de los encaminadores de la red, con el consecuente gasto económico y de tiempo que eso supone, cosa que muchas de las empresas no están dispuestas a aceptar (especialmente las grandes corporaciones estadounidenses, que son las que tienen suficientes direcciones). Por último, a causa de la gran utilización que se hace actualmente de Internet, es un gran problema tener que parar todas las redes para hacer la migración. Así, el problema que se encuentra es el enorme gasto económico para las em-


© FUOC • PID_00147723

48

presas que controlan todas sus transacciones a través de la red, lo que fuerza a hacer la migración de forma progresiva, transparente para los usuarios y sin dejar de ofrecer los servicios disponibles en ningún momento. Mecanismos para asistir la transición La migración entre dos protocolos cuando uno se está utilizando masivamente es extremadamente compleja. Como hemos visto, las razones, normalmente, son económicas, ya que la gran mayoría de las aplicaciones actualmente sólo soportan IPv4, y migrarlas a la nueva versión no siempre es sencillo (por ejemplo, aplicaciones bancarias). Por otra parte, todo el equipamiento hardware que forma el backbone de la red, si bien está preparado para soportar IPv6, no siempre tiene la configuración correcta, ni la asignación de direcciones hecha. En cualquier caso, se espera que haya una fase de coexistencia de los dos protocolos. De todas formas, a pesar de la coexistencia, hay escenarios que obligan a diseñar un plan de migración controlado. Así, los diferentes mecanismos de transición se pueden dividir en dos grandes grupos: mecanismos básicos y mecanismos para la interconexión de islas. En cuanto a los mecanismos básicos, se pueden distinguir dos, el conocido como Dual-Stack, en el que los equipos utilizan simultáneamente los dos protocolos y se conectan con el que más se ajuste a las necesidades del momento, y el de Tunneling, en el que dos equipos con Dual-Stack crean un túnel IPv4 entre ellos, y por dentro del túnel se comunican con IPv6. Hay que señalar que un túnel es el mecanismo por el que se encapsulan dos protocolos de red dentro de un mismo datagrama, así hay dos cabeceras de red consecutivas del nivel de red. IPv4 soporta el mecanismo de túnel a través de un valor especial en el campo Protocolo que se encuentra en la cabecera. Por lo que respecta a los mecanismos para conectar islas, pretenden resolver el caso en el que diversas máquinas interconectadas a través de IPv6 (isla IPv6) se quieren conectar con otra isla IPv6, pero por el camino hay una isla IPv4, tal como muestra la figura siguiente. Redes IPv4 y redes IPv6

Estos mecanismos también están basados principalmente en túneles. Se pueden distinguir los siguientes tipos:


© FUOC • PID_00147723

•

49

Túneles�configurados: los extremos de los túneles entre las islas se configuran de forma manual entre las dos redes. Los extremos tienen que ser dual-stack.

•

Túneles� automáticos: se utilizan direcciones IPv4 mapeadas dentro de IPv6 con el prefijo reservado, que es el ::/96, por ejemplo, ::195.123.57.93, que el encaminador convierte a la dirección IPv4, y en el otro extremo se vuelve a convertir a la IPv6. Los extremos no se dan cuenta del cambio y se pueden comunicar con IPv6 sin problemas.

•

Túnel�Broker: se utiliza un broker (gestor), que indica al cliente un script con el fin de hacer el túnel de forma automática. El cliente tiene que ser dual-stack, ya que la petición en el broker va con IPv4, que contesta con un script que permite conectar a un Tunnel-Server (que también es dual-stack) al que permite conectarse a la red IPv6.

•

6to4: se asigna una dirección IPv4 compatible con el prefijo IPv6 en los encaminadores, los cuales hacen un túnel. Por ejemplo, para la red 2001:d002:0507::/48 el encaminador tendría la dirección 208.2.5.7 (que sale de d002:0507). En el otro extremo se haría la operación análoga y se establecería el túnel.

2.4. Protocolos de soporte a IP Tanto IPv4 como IPv6 son protocolos de red, pero ambos necesitan soporte de otros protocolos de la misma capa para poder llevar a cabo ciertas funcionalidades que sería complejo conseguir de otra manera. A pesar de que, dadas las diferencias estructurales entre los dos protocolos, muchos de los servicios son diferentes, todos se engloban en este subapartado para simplificar la comprensión, ya que, si bien los protocolos divergen, su funcionalidad a menudo es muy similar. 2.4.1. Internet Control Message Protocol IP es un protocolo no orientado a conexión que tiene por objetivo el envío de información independientemente de la tecnología de niveles inferiores utilizada. Eso proporciona un entorno ideal para poder comprobar el estado de la red, o enviar información de control en el caso de que haya problemas en la red. Por ejemplo, cuando un datagrama no puede llegar a su destino, o bien hay congestión en un enlace, o bien a un paquete se le ha expirado el TTL. Todas estas situaciones requieren de algún protocolo, que trabajando en la misma capa que IP permita avisar de forma automática de cualquiera de estos eventos. Por eso se diseñó el Internet Control Message Protocol (ICMP).


50

© FUOC • PID_00147723


El ICMP es el encargado de enviar mensajes de control (y de error) entre los diferentes equipos que forman la red.

La tabla siguiente muestra todos los tipos de mensajes existentes con ICMP. Descripción de los diferentes mensajes ICMP Mensaje

Descripción

Destination�unreachable

Indica que no se puede llegar al destino. Este mensaje tiene un campo de código que indica si es culpa de la red, del equipo en particular o bien del puerto. También distingue si no se puede llegar al destino o bien si el destino es desconocido.

Echo�request/�Echo�reply

Estos dos mensajes son el de petición y el de respuesta, cuando una estación recibe un echo request, tiene que responder con un echo reply si está activa. En general es aconsejable que todos los equipos respondan estas peticiones, aunque por seguridad muchas veces se filtran los mensajes. La aplicación por excelencia que utiliza los echo request/reply es el ping.

Source�quench

Este paquete sirve para regular, indica que aquel enlace está sufriendo congestión. Actualmente este tipo de paquete no se utiliza porque el control se hace mayoritariamente en la capa de transporte.

Router�advertisement

Este paquete de ICMP se envía a una dirección multicast donde todos los encaminadores escuchan por defecto. Con este mensaje es posible descubrir automáticamente la existencia de nuevos encaminadores en la red.

Router�discovery

Es un paquete complementario del de router advertisement. Pero en este caso es un encaminador que acaba de entrar en una red que pregunta qué otros encaminadores hay en la red.

TTL�expired

Cuando el TTL de un paquete llega a 0 éste se descarta, y el encaminador que lo ha descartado genera un paquete TTL expired en el origen del paquete descartado.

IP�header�bad

En el caso de que se detecte un error de checksum en la cabecera de un paquete IP, éste se descarta y se avisa al origen con este paquete ICMP.

Los mensajes ICMP tienen varias utilidades, desde reportar errores hasta depurar el estado de la red. Una de las herramientas más utilizadas para poder ver si un equipo está conectado a la red es el ping. Otra funcionalidad es posible gracias al campo TTL de la cabecera IP, que ayuda a realizar otra tarea de depuración mediante una herramienta llamada traceroute; esta herramienta nos permite descubrir los encaminadores intermedios entre el origen y el destino de los datagramas. Para conseguir saber qué encaminadores cruza un datagrama, el traceroute envía paquetes IP consecutivos con un TTL de 1, otro de 2, otro de 3, y así sucesivamente hasta llegar al destino. El efecto de eso es que el primer encaminador, al recibir un paquete con TTL = 1, lo decrementa, y al ser 0, lo descarta y envía de vuelta un paquete ICMP de TTL expired. Ahora sólo hace falta que la aplicación mire a quien ha enviado este

Bibliografía Para una descripción más completa de todos los tipos de mensajes existentes con ICMP se puede consultar el documento RFC-792.

© FUOC • PID_00147723

51


paquete (IP origen) para saber de qué router se trata. Por descontado, con TTL = 2 sucederá lo mismo con el segundo encaminador, y después con el tercero, y así sucesivamente hasta el destino. 2.4.2. Address Resolution Protocol Para enviar un datagrama IP a una estación de la misma red que el emisor es necesario descubrir qué dirección del nivel del enlace de datos tiene esta estación, ya que las tecnologías de capas inferiores no entienden qué es una dirección IP. Así pues, para que la IP funcione necesita interactuar con las capas inferiores y descubrir de forma automática cuál es la dirección de enlace de datos a la que responde un equipo para poder intercambiarse información. El protocolo Address Resolution Protocol (ARP) fue diseñado específicamente para IPv4, y como veremos más adelante, para IPv6 existe el Network Discovery Protocol. Para conseguir el descubrimiento de la dirección hardware de un equipo a partir de su IP, ARP se sirve de la funcionalidad que nos proporciona la capa de enlace de datos para enviar paquetes de broadcast. Entonces la procesa con el fin de conseguir la dirección hardware (llamada MAC) y poder enviar el paquete, tal como se puede ver en el diagrama de la figura siguiente. Diagrama de secuencia para el envío de un paquete IP

El proceso de ARP, ilustrado en la siguiente figura con un ejemplo, sigue una serie de pasos con el fin de descubrir la dirección. Lo primero que se tiene que conseguir es la dirección MAC del siguiente salto, por eso se envía un paquete ARP a la dirección de broadcast de nuestra red local. Este ARP buscará la IP del destino o bien la del encaminador dependiendo de si la estación forma

Dirección de nivel de enlace La dirección de nivel de enlace es conocida como dirección MAC y viene dada por los dispositivos de red. Cada dispositivo de red tiene una dirección MAC única.

© FUOC • PID_00147723

52

parte de la subred o no. Una vez se obtiene la dirección MAC, se construye un paquete que tiene como dirección MAC destino la obtenida por ARP y como IP destino la original (o sea, en el caso de que se envíe el paquete al encaminador, esta IP será la del destino final, no la del encaminador). Ejemplo de petición por ARP

RARP Hemos visto que ARP nos sirve para poder descubrir qué dirección MAC corresponde a una IP, también hemos visto la importancia de esta operación. Por compleción, ARP tiene una variante denominada RARP, que nos permite realizar la operación inversa, o sea, desde una dirección MAC poder averiguar a qué IP corresponde. RARP no es exactamente un protocolo de la capa de red, ya que incluye muchas funcionalidades de la capa de enlace de datos, pero, dada la estrecha relación con ARP, se acostumbran a considerar conjuntamente. RARP ya no se utiliza, ya que hay protocolos como BOOTP y DHCP que nos ofrecen esta y más funcionalidades como veremos a continuación.

2.4.3. Network Discovery Protocol ARP es un protocolo que fue diseñado específicamente para IPv4; con los avances de las redes hasta hoy ha probado que es insuficiente para según qué servicios. Por eso, con la aparición de IPv6, se decidió que hacía falta un protocolo más completo. Así apareció el Network Discovery Protocol (NDP). NDP es un protocolo que permite descubrir a los vecinos existentes en una red local. El modo de operar es muy similar al que utilizábamos con IPv4, ahora se envían neighbour solicitations y se reciben neighbour advertisements. Sin embargo, la gran diferencia con ARP es que se utiliza tráfico multicast en vez de broadcast. Y que NDP forma parte de un protocolo mayor llamado ICMPv6, que es la extensión en IPv6 del protocolo ICMP.


© FUOC • PID_00147723

53

Cuando un nodo IPv6 se da de alta se pone a escuchar a un conjunto de direcciones multicast, una de ellas es la de Solicited-Node. Para automatizar este procedimiento, la dirección multicast Solicited-Node de una estación se construye de la siguiente manera: se cogen los últimos tres octetos de la dirección unicast y se añade al principio el prefijo multicast FF02::1:FF00:0000/104. Por ejemplo, la dirección multicast Solicited-Node para 2001:630:1310:FFE1:02C0:4EA5:2161:AB39 sería la FF02::1:FF61:AB39. Entonces, la estación se pone a escuchar al grupo multicast para responder con la dirección hardware del equipo al que va dirigida la petición. Eso nos da la versatilidad que no todos los nodos reciben los anuncios, así en el caso de que no vayan dirigidos hacia ellos ya ni los llegan a ver, con la reducción en el uso de recursos que eso supone. 2.4.4. Dynamic Host Configuration Protocol El siguiente protocolo de red que veremos no es realmente un protocolo de red, sino un protocolo de aplicación. De todas formas, dado que se utiliza para configurar la red, se explica en este subapartado. El Dynamic Host Configuration Protocol (DHCP) fue inicialmente definido en el documento RFC-1531. Es un protocolo que utilizan los dispositivos con el fin de obtener información de la configuración de los parámetros de red por un equipo IPv4 de forma automática. El administrador de la red configura un prefijo de red, conjuntamente con un subrango de direcciones destinadas a autoconfiguración (este rango de direcciones se llama pool). Cuando se recibe una petición, el protocolo comprueba si el cliente está autorizado; si lo está se le asigna una IP preconfigurada, que se obtiene de una base de datos a partir de la dirección hardware del equipo, o bien una al azar del pool si la dirección hardware no se encuentra. Esta cesión de IP va controlada por un temporizador; cuando este temporizador expira y no se ha recibido ninguna noticia del cliente se devuelve la IP al pool de direcciones libres. Para evitar eso, el protocolo implementa un sistema de Keep-Alive, que va enviando renovaciones de uso de la IP al servidor para evitar que caduquen. Para hacer todas estas tareas DHCP utiliza UDP para enviar la información. Entrando en un poco más de detalle, un cliente, cuando dé de alta una interfaz, enviará un DHCP discovery, que es un paquete broadcast con el fin de descubrir servidores DHCP. El servidor, cuando ve el paquete, comprueba la validez del cliente (base de datos de MAC) y envía un DHCP Offer con su IP. Al que el cliente responde directamente con un DHCP request, que finalmente el servidor acepta con un DHCP acknowledgement, que contiene la duración de la IP y la configuración específica que el cliente haya pedido al DHCP request. Por ejemplo, encaminador por defecto, servidor de DNS, etc.


© FUOC • PID_00147723

54

3. El enlace de datos y el control de acceso al medio

Hemos visto que la capa de red proporciona un servicio de comunicación entre dos máquinas, estableciendo diferentes rutas o caminos entre ellas. Cada ruta de comunicación está formada por una serie de enlaces, que conectan la máquina origen con la de destino utilizando unos dispositivos encaminadores intermedios. Cuando un datagrama del nivel de red sale de la máquina origen hacia la máquina destino, va atravesando cada uno de estos enlaces individuales que conforman el recorrido extremo a extremo. Se hace necesaria una capa lógica adicional situada inmediatamente bajo la capa de red, que se ocupe de suministrar a ésta un transporte de información fiable entre los diferentes enlaces que atraviesa a lo largo de un recorrido. Esta capa recibe el nombre de nivel de enlace, y se sitúa por encima de la capa física. La capa física no es capaz de aportar ninguno de los elementos necesarios para la transmisión efectiva de información en un enlace.

El nivel�de�enlace consiste en dos programas o procesos que se ejecutan a ambos lados de un enlace y se comunican entre sí. Para que estos dos procesos se puedan comunicar es necesario establecer: •

un formato para la información que se intercambian, y

•

un conjunto de reglas de comportamiento o protocolos necesarios para la transmisión de datos.

El principal cometido de la capa de enlace es conseguir que la comunicación de datos en un enlace se realice correctamente a través de un medio físico de transmisión. De una forma gráfica, podemos decir que el nivel de enlace se encarga de establecer y mantener un puente de comunicación entre dos nodos vecinos, para que por encima puedan circular los datagramas de nivel superior.

Ruta de comunicación creada entre dos máquinas finales, formada por 5 enlaces: 2 enlaces comunican las máquinas finales con los routers de la red y 3 enlaces internos intercomunican sólo routers de la red.


© FUOC • PID_00147723

55


De la observación de la figura anterior, podemos destacar dos características muy importantes del nivel de enlace: •

Los enlaces, a lo largo de un recorrido de comunicación, pueden utilizar diferentes protocolos de la capa de enlace y estar constituidos por tecnologías de base totalmente diferentes. Un encaminador puede disponer de diferentes enlaces y cada uno de ellos puede utilizar un protocolo de nivel de enlace diferente. En la figura podemos observar cómo un datagrama enviado desde la máquina origen es manejado por Ethernet en el primer enlace, por el protocolo ATM en el segundo enlace, y va cambiando de tecnología sucesivamente en cada nuevo enlace.

•

Una de las funcionalidades básicas del nivel de enlace consiste en encap5

sular/desencapsular los datagramas de la capa de red en PDU de información de la capa de enlace, también llamados tramas. Observemos las flechas de la figura que indican el flujo que sigue la información a lo largo del recorrido. Cuando una trama llega al encaminador desde un enlace entrante, la capa de enlace desencapsula/extrae el datagrama de la trama recibida y lo entrega a la capa de red. Una vez la capa de red ha determinado el enlace de salida por donde debe encaminar el datagrama, lo envía al enlace. Aquí el datagrama es encapsulado según las normas del protocolo de este enlace y preparado para ser enviado.

3.1. Terminología y definiciones

El nodo es la máquina o encaminador. El enlace es el canal que conecta dos nodos adyacentes al recorrido de la comunicación. El protocolo de�la�capa�de�enlace es la forma de comunicarse entre los nodos, para mover un datagrama sobre un enlace individual. Define el formato de los paquetes (PDU) intercambiados entre los nodos en los extremos del enlace, así como las acciones adoptadas por estos nodos cuando envían y reciben estos paquetes. La trama son las unidades de datos intercambiadas por un protocolo de la capa de enlace. El nodo transmisor encapsula el datagrama de la capa en una trama de la capa de enlace y transmite la trama al enlace, y un nodo receptor recibe la trama y extrae el datagrama.

(5)

PDU son las siglas de Protocol Data Unit.

© FUOC • PID_00147723

56

3.2. Tipo de enlaces Básicamente podemos destacar dos tipos de enlaces: •

Enlaces�de�comunicación�punto�a�punto. Sólo participan dos entidades o puntos. Son enlaces 1 a 1: compuestos por un único nodo emisor en un extremo del enlace y un único nodo receptor en el otro. Ambos nodos utilizan en exclusiva el enlace, sin compartir el canal. Ejemplos de enlaces punto a punto Son enlaces punto a punto: • • • •

•

Bucle de abonado local, cable de dos hilos telefónico para acceso a Internet. Las redes de área local FastEthernet. Las redes de área local GigabitEthernet. PPP, HDLC (a nivel de enlace), X.25 a nivel de red y TCP a nivel de transporte (en este caso es además extremo-a-extremo).

Enlaces�broadcast�o�canales�de�multidifusión. Son enlaces 1 a N, donde una serie de nodos están conectados al mismo canal de comunicación. La transmisión realizada por un nodo la reciben todos los nodos conectados al enlace. Se hacen necesarias unas políticas de coordinación (o protocolos de acceso al medio) que permitan la compartición del único medio de forma eficiente, tratando de evitar al máximo las colisiones entre tramas. Ejemplos de enlaces broadcast Son enlaces broadcast: • • • • • •

Las redes de área local Ethernet (half duplex). Las redes de área local sin cable Wifi. Los enlaces con satélites. Las redes de acceso híbrido fibra-cable (HFC). Las redes de área local Token Ring. Las redes de área local FDDI.

3.3. Tipo de servicios suministrado en la capa de red El tipo de servicio que la capa de enlace suministra a la capa de red suele ser alguno de los siguientes: •

Servicio�no�orientado�a�conexión�y�sin�acuse�de�recibo. El envío se hace sin esperar ninguna indicación del receptor sobre el éxito o fracaso de la operación. Tampoco se establece o libera una conexión. Este tipo de servicio es apropiado cuando la tasa de error es muy baja (redes locales o fibra óptica) y se deja la misión de comprobar la corrección de la transmisión a las capas superiores (nivel de red o de transporte). También se usa el servicio no confirmado cuando se quiere transmitir información en tiempo real (típicamente voz o datos) y no se quiere sufrir el retardo que impondría un servicio más sofisticado en la capa de enlace (se supone que este tipo de información puede sufrir una pequeña tasa de error sin efecto apreciable).


© FUOC • PID_00147723

•

57

Servicio�no�orientado�a�conexión�con�acuse�de�recibo. Se produce un acuse de recibo para cada trama enviada, aunque todavía no hay establecimiento dé conexión. De esta manera el emisor puede estar seguro de que ha llegado.

•

Servicio�orientado�a�conexión�con�acuse�de�recibo. Es el más seguro y sofisticado. El emisor y el receptor establecen una conexión explícita de antemano, se enumeran las tramas a enviar y se asegura que todas sean recibidas correctamente en el destino, y se transmiten seguidamente a la capa de red. En el servicio orientado a conexión se pueden distinguir tres fases: establecimiento de la conexión, envío de los datos, y finalización de la conexión. En la primera se disponen los contadores y memorias temporales necesarios para la transmisión, en la segunda se envían los datos, y en la tercera se libera la memoria ocupada con datos temporales y variables.

3.4. Servicios proporcionados por la capa de enlace El servicio básico del nivel de enlace consiste en mover correctamente un datagrama de nivel de red, desde un nodo hasta otro adyacente sobre un enlace de comunicación fijando en el recorrido. Los posibles servicios que puede ofrecer un protocolo de la capa de enlace son: •

Gestión�de�las�tramas. El nivel de enlace se encarga de la organización y gestión de las tramas. –

Entramado o composición de la trama.

–

Sincronización a nivel de trama.

–

Transparencia de trama.

–

Numeración y secuenciación (números de secuencia).

–

Direccionamiento: si existe más de un posible destino de un mensaje es necesario identificarlo perfectamente.

•

Gestión� del� enlace. Todo el proceso de inicio, mantenimiento y finalización de la transmisión requiere un considerable esfuerzo de gestión y coordinación.

•

Control�de�flujo. La estación emisora y la receptora se tienen que poner de acuerdo sobre el ritmo de transmisión de datos. Si la estación receptora recibe las tramas más rápidamente de lo que es capaz de procesarlas, el nivel de enlace remoto ha de "frenarlas" para evitar que se sature la memoria intermedia o memoria temporal que almacena las tramas pendientes.

•

Control�de�errores. Se trata de una de las funciones básicas del nivel de enlace. Se asume que el medio de transmisión subyacente no es perfecto e introduce errores de transmisión. Es necesario destinar una parte de los bits que se intercambian a la detección y la posterior gestión de los errores,


© FUOC • PID_00147723

58

para controlar que no se produzcan errores de transmisión. En el control de errores se distinguen tres conjuntos de técnicas: –

Detección de errores. Utilización de códigos detectores de errores eficientes.

•

–

Corrección de errores, si se utilizan códigos correctores adecuados.

–

Retransmisión de tramas erróneas (entrega fiable).

Control�de�acceso�al�medio. Esta funcionalidad cobra relevancia en los enlaces de acceso múltiple o broadcast, donde un número determinado de nodos comparten el mismo medio físico. El modelo OSI divide la capa de enlace en dos subcapas: la LLC (Logical Link Layer) y la MAC (Medium Access Control). La subcapa MAC es la encargada de especificar las reglas con que se transmite una trama sobre el enlace. Los protocolos MAC coordinan la transmisión de las tramas de los nodos, con el objetivo de evitar las colisiones de tramas. En los enlaces punto a punto los protocolos de acceso al medio dejan de tener sentido.

3.5. Adaptadores y dispositivos de red Los nodos o encaminadores se conectan a los enlaces a través de un adaptador, conocido como tarjeta de interfaz de red o Network Interface Card (NIC). Físicamente, un adaptador es una placa hardware (una tarjeta PCMCIA o un dispositivo conectado al puerto USB) que contiene todos los elementos de un pequeño computador: memoria RAM, chip DSP, una interfaz de bus con la máquina, y una interfaz de enlace. Normalmente se encuentra alojado en la misma capa física que el resto del nodo, comparte la alimentación y los buses con el resto del nodo, y está en el fondo bajo el control del nodo.

Un adaptador tiene un cierto grado de autonomía: •

En�recepción: cuando recibe una trama, determina si ésta tiene errores. Si es así, la rechaza sin notificarlo a su nodo padre. Si es correcta, desencap-


© FUOC • PID_00147723

59

sulará el datagrama de la capa de red e interrumpirá a su nodo padre para pasarlo hacia arriba de la pila de protocolos. •

En�transmisión: cuando un nodo pasa un datagrama hacia abajo en la pila de protocolos a un adaptador, delega totalmente en éste la tarea de transmitir el datagrama sobre el enlace. El adaptador encapsula el datagrama en una trama y transmite la trama en el enlace de comunicación.

Los componentes principales de un adaptador son la interfaz del bus y la del enlace. La interfaz del bus es responsable de comunicar con el nodo padre del adaptador. Transfiere datos e información de control entre el adaptador y el nodo padre. La interfaz del enlace es responsable de implementar el protocolo de la capa de enlace. También incluye el hardware de transmisión y recepción. El protocolo de la capa de enlace está, mayoritariamente, implementado en este adaptador. Si el protocolo de la capa de enlace proporciona detección de errores, entrega fiable (numeración y reconocimientos) o acceso aleatorio (además de enmarcar y quitar el marco de datagramas), entonces estas funcionalidades están implementadas completamente en los adaptadores.


© FUOC • PID_00147723

60


4. El nivel físico

Para acabar este módulo, estudiaremos la última capa del modelo OSI6. El nivel físico caracteriza la señal y su modulación, así como describe los medios de transmisión físicos. En este módulo no entraremos en los fundamentos matemáticos de la modulación y de la señal. Simplemente tenemos que saber que la información binaria se puede transmitir por un medio a través de las variaciones de alguna propiedad física, habitualmente, el voltaje o la intensidad. Podemos representar el valor de esta magnitud física como una función dependiente del tiempo. Dada esta función en forma de onda, podemos codificarla para transmitir la información que queremos. Este es el fundamento de la transmisión de información a través de un medio y sobre el que se basa toda la teoría de la comunicación. 4.1. Medios de transmisión Existen varios medios de transmisión en función de su ancho de banda, retardo, coste, facilidad de uso, instalación y mantenimiento. Los medios se pueden clasificar en medios guiados (par de hilos, fibra óptica) o no-guiados (ondas de radio, láser a través del aire). Los siguientes factores de un medio de transmisión determinan la velocidad máxima de transmisión y la distancia máxima del medio: •

Ancho�de�banda. Al aumentar el ancho de banda se puede aumentar la velocidad de transmisión.

•

Atenuación. En orden decreciente van el par trenzado, el cable coaxial y la fibra óptica.

•

Interferencias. En orden decreciente van el par trenzado y el cable coaxial.

•

Número�de�receptores. Atenúan y distorsionan la señal que supone una menor distancia.

4.1.1. Par trenzado Se trata del sistema más antiguo y todavía es muy utilizado en la actualidad. Consiste en dos pares de hilos de cobre o de acero cubierto con cobre, aproximadamente de un milímetro de diámetro cada uno, que están envueltos entre sí en forma de hélice, como una molécula de ADN.

(6)

OSI es la abreviatura de Open Systems Interconnection; en castellano, interconexión de sistemas abiertos.

© FUOC • PID_00147723

61

Se puedem utilizar tanto en las transmisiones digitales como en las analógicas. El ancho de banda que ofrecen depende del grueso del cable y de la distancia. Es un sistema muy utilizado en los sistemas de telefonía. Generalmente, los teléfonos de las viviendas están conectadas con la centralita telefónica a través de pares trenzados (su ancho de banda es de 4 KHz). También se utiliza en las LAN a velocidades de 10, 100 y 1.000 Mbps. Es muy utilizado en las conexiones punto a punto, y su ámbito geográfico suele ser de unos 100 metros (en redes Ethernet). Los primeros pares trenzados no apantallados se llamaban Unshielded Twisted Pair (UTP). El par trenzado habitualmente se agrupaba en cuatro pares trenzados más dentro de una protección de plástico. Este tipo de cable se llamaba de categoría 3. Después se introdujeron los cables de categoría 5, agrupamientos con más densidad por centímetro de vueltas en el cable, que ofrecían unas características de mayor calidad sobre largas distancias. Par trenzado no apantallado (UTP)

Después vino la evolución al tipo de cableado Shielded Twisted Pair (STP), llamado par trenzado apantallado, donde cada par de hilos tiene una protección individual. Par trenzado apantallado (STP)


Coste del par trenzado Debido a su bajo coste y su rendimiento, es un sistema muy popular. El coste es el más económico (más que el coaxial o la fibra óptica) por metro, pero tiene unos costes de conectividad parecidos a los de otros medios.

© FUOC • PID_00147723

62

4.1.2. Cable coaxial de banda base El cable coaxial tiene un recubrimiento superior a los pares trenzados, y funciona a largas distancias y altas velocidades. Este cable consiste en un hilo de cobre, rodeado por un material aislante. Para cables de 1 km de longitud, soporta velocidades de 1 a 2 Gbps. Se pueden utilizar distancias más largas pero con velocidades de transmisión más bajas. Este tipo de cable se ha utilizado para interconectar los equipos de las centrales telefónicas, para alguna red de área local o para la televisión por cable. Es más económico que la fibra óptica y más caro que el par trenzado.

4.1.3. Fibra óptica Un sistema de comunicaciones ópticas está formado por tres componentes: una fuente de luz, el medio de transmisión y el detector de luz. Convencionalmente, un impulso de luz indica un bit con valor 1, y la ausencia de luz indica un bit de valor 0. El medio de transmisión es una fibra óptica muy fina. El detector genera un impulso eléctrico cuando la luz incide sobre él. Así pues, instalando una fuente de luz al inicio de la fibra óptica y un detector de luz al final de la fibra, tenemos un sistema de transmisión unidireccional que acepta señales eléctricas, las convierte en impulsos de luz que se transmiten y se reconvierten en una señal eléctrica al final de la fibra. La materia prima de la fibra óptica es el vidrio, un material no excesivamente caro y existente en grandes cantidades en nuestro planeta. El vidrio utilizado en las fibras ópticas es un vidrio transparente. La velocidad de transmisión es muy elevada, llegando a varios Gbps en 30 km de distancia.


© FUOC • PID_00147723

Fibra óptica

63


© FUOC • PID_00147723

64

Resumen

En este módulo se han visto en detalle las características y el funcionamiento de los diferentes niveles de la red. El objetivo del módulo ha sido dar una visión general del funcionamiento interno de una red de computadores, ya de área local, ya a gran escala, como es Internet. La aproximación a los niveles de la red se ha hecho desde los niveles más próximos a las aplicaciones hasta los niveles más específicos del hardware. En primer lugar se ha introducido el nivel de transporte que ofrece fiabilidad a la red permitiendo el acceso de diferentes aplicaciones a un único medio de transmisión, la red. Se ha visto que el funcionamiento de la red se rige en gran medida por el protocolo TCP, que es orientado a conexión y ofrece garantías de fiabilidad en la red. Para aplicaciones que no requieren garantías existe el protocolo UDP que es usado mayoritariamente por aplicaciones en tiempo real. Seguidamente se ha presentado la capa de red. El nivel de red es primordial para el funcionamiento de Internet pues nos permite dirigir e identificar los nodos de una red. En este apartado hemos visto IPv4 e IPv6. Se ha presentado el modelo de direccionamiento y la problemática actual con el número de direcciones en la red. Se ha presentado la capa de enlace que abstrae los nodos de la red del medio físico sobre el que transmiten la información. Se ha visto que esta capa se encarga de dirigir la información entre nodos físicos adyacentes y garantizar transmisión fiable entre ellos. Hay que destacar la tarea de la subcapa de control de acceso al medio que permite transmitir información entre dos nodos independientemente de la tecnología de red utilizada, ya sea inalámbrica o cableada. Finalmente, se ha hecho una breve introducción al nivel físico que se encarga de los aspectos de modulación y codificación de las señales físicas que son dependientes directamente de la tecnología y el medio de transmisión. Se han visto los principales medios de transmisión.


© FUOC • PID_00147723

65

Bibliografía Almquist, P. (1992, julio). "RFC-1349: Type of Service in the Internet Protocol Suite". Consultant. Bing, B. (2000). High-Speed Wireless ATM and LAN. Londres: Artech House. ISBN 1-58053092-3. Bing, B. (2000). Broadband Wireless Access. Dordrecht: Kluwer Academic Publishers. ISBN 0-7923-7955-1. Croft, B.; Gilmore, J. (1985, septiembre). "RFC-951: Bootstrap Protocol (BOOTP)". Stanford University & Sun Microsystems, Dijkstra, E. W. (1959). "A note on two problems in connexion with graphs". Numerische Mathematik (núm. 1, pág. 269-271). Droms, R. (1993, octubre). "RFC-1531: Dynamic Host Configuration Protocol". Lewisburg: Bucknell University. Gartner, F. C. (2003). A Survey of Self-Stabilizing Spanning-Tree Construction Algorithms. Lausana: Swiss Federal Institute of Technology Tech. Rep. IC/2003/38, School of Computer and Communication Sciences. Hedrick, C. (1988, junio). "RFC-1058: Routing Information Protocol". Piscataway: Rutgers University. IANA Reserved Multicast Address List. Disponible en web: . [Fecha de consulta: 12 abril de 2010.] Information Sciences Institute (1981, septiembre). "RFC-791: Internet Protocol Specification". Marina del Rey: Information Sciences Institute, University of Southern California. Intel Corporation (1999, 20 septiembre). "Preboot Execution Environment (PXE) Specification". Kent, S.; Seo, K. (2005, diciembre). "RFC-4301: Security Architecture for the Internet Protocol". BBN Technologies. Kurose, J.; Ross, K. (2005). Computer Networking: a Top-Down Approach Featuring the Internet. Amherst: Department of Computer Science, University of Massachusetts. Malkin, G. (1998, noviembre). "RFC-2453: RIP Version 2". Bay Networks. Moy, J. (1994, marzo). "RFC-1584: "Multicast Extensions to OSPF". Moy, J. (1998, abril). "RFC-2328: OSPF Version 2". Ascend Communications. Postel, J. (1981, septiembre). "RFC-792: Internet Control Message Protocol (ICMP)". ISI, Rekhter, Y.; Li T.; Hares, S. (2006, enero). "RFC-4271: A Border Gateway Protocol 4 (BGP4)". Reynolds, J. (2002, enero). "RFC-3232: Assigned Numbers: RFC 1700 is Replaced by an On-line Database". Reynolds, J.; Postel; J. (1994, octubre). "RFC-1700: Assigned Numbers". Srisuresh, P.; Egevang, K. (2001, enero). "RFC-3022: Traditional IP Network Address Translator (Traditional NAT)". Intel Corporation, Srisuresh, P.; Holdrege, M. (1999, agosto). "RFC-2663: IP Network Address Translator (NAT) Terminology and Considerations". Murray Hill: Lucent Technologies, Tanenbaum, A. S. (2003). Redes de computadores (4.ª ed.). Nueva York: Prentice-Hall Professional Technical Reference.


Seguridad en la red Xavier Vilajosana Guillén PID_00147721

© FUOC • PID_00147721


Seguridad en la red

Seguridad en la red

© FUOC • PID_00147721

Índice

Introducción...............................................................................................

5

Objetivos.......................................................................................................

7

1.

9

2.

3.

Cortafuegos.......................................................................................... 1.1.

Sistemas cortafuegos ...................................................................

10

1.2.

Construcción de sistemas cortafuegos ........................................

11

1.2.1.

Encaminadores con filtrado de paquetes ......................

11

1.2.2.

Pasarela en el ámbito de aplicación ..............................

13

Redes privadas virtuales..................................................................

16

2.1.

Definición y tipo de redes privadas virtuales .............................

16

2.2.

Configuraciones y protocolos utilizados en VPN .......................

17

Introducción a la criptografía.......................................................

20

3.1.

Criptografía de clave simétrica ...................................................

22

3.1.1.

Algoritmos de cifrado de flujo ......................................

24

3.1.2.

Algoritmos de cifrado de bloque ...................................

26

3.1.3.

Uso de los algoritmos de clave simétrica .......................

29

3.1.4.

Funciones hash seguras ..................................................

32

Criptografía de clave pública ......................................................

34

3.2.1.

Algoritmos de clave pública ..........................................

34

3.2.2.

Uso de la criptografía de clave pública ..........................

37

3.2.3.

Infraestructura de clave pública ....................................

38

Certificados digitales........................................................................

39

4.1.

Cadenas de certificados y jerarquías de certificación .................

40

4.2.

Listas de revocación de certificados ............................................

40

Seguridad en la red...........................................................................

42

5.1.

Cookies ........................................................................................

42

5.2.

Contenidos activos ......................................................................

43

5.2.1.

Applets ...........................................................................

43

5.2.2.

Servlets/JSP .....................................................................

44

5.2.3.

CGI .................................................................................

44

5.2.4.

ASP/PHP .........................................................................

45

5.2.5.

RIA ..................................................................................

46

Protocolos de seguridad ..............................................................

46

5.3.1.

PGP .................................................................................

47

SSL ...............................................................................................

49

5.4.1.

50

3.2.

4.

5.

5.3. 5.4.

Características del protocolo SSL/TLS ............................

Seguridad en la red

© FUOC • PID_00147721

5.4.2.

El transporte seguro SSL/TLS .........................................

52

Transacciones seguras en red ......................................................

58

5.5.1.

Secure Electronic Transaction ........................................

58

5.5.2.

3D-Secure .......................................................................

59

Resumen.......................................................................................................

60

Bibliografía.................................................................................................

63

5.5.

© FUOC • PID_00147721

5

Introducción

La seguridad en la red es un aspecto de primordial importancia. Cada día aparecen nuevas aplicaciones remotas o en red; estas aplicaciones almacenan la información en hardware remoto y requieren intercambios de datos constantes entre nuestros ordenadores personales y los servidores remotos. Todo este flujo de información hace necesaria la existencia de mecanismos para evitar el uso malicioso de la información y asegurar la privacidad y protección de los usuarios de la red. A la hora de proteger las redes de comunicaciones, la criptografía es la herramienta fundamental que nos permite evitar que alguien intercepte, manipule o falsifique los datos transmitidos. Dedicaremos una parte de este módulo a introducir los conceptos de la criptografía necesarios para entender cómo se aplica a la protección de las comunicaciones. La finalidad básica de la criptografía es el envío de información secreta. Si aplicamos una transformación, conocida como cifrado, a la información que queremos mantener en privado, aunque un adversario consiga ver qué datos estamos enviando le serán completamente ininteligibles. Sólo el destinatario legítimo será capaz de hacer la transformación inversa y recuperar los datos originales. En el módulo también estudiaremos los sistemas cortafuegos que se encargarán de proteger el acceso a determinados puntos de la red. Veremos que un sistema cortafuegos actúa como una barrera central para reforzar el control de acceso a los servicios que se ejecutan tanto en el interior como el exterior de la red. El cortafuegos intenta prevenir los ataques del exterior contra las máquinas internas de una red denegando peticiones de conexión desde partes no autorizadas. Por otra parte veremos también que existen redes�privadas�virtuales que se construyen haciendo uso de los nodos de una red, pero que, mediante técnicas criptográficas y protocolos seguros, permiten aislar a los usuarios de esta red de los de la red de comunicación. Finalmente haremos una pasada por los diferentes protocolos y aplicaciones más relevantes para asegurar las redes de comunicaciones. Conoceremos las cookies, los contenidos dinámicos y cómo éstos pueden afectar a la seguridad de una sitio web. La existencia de protocolos como SSL/TLS en el nivel de transporte ha permitido que se pueda dotar de seguridad a las aplicaciones

Seguridad en la red

© FUOC • PID_00147721

6

en red y a sus protocolos. En este módulo también conoceremos el funcionamiento de estos protocolos y, de paso, cómo se pueden hacer transacciones seguras en la red.

Seguridad en la red

© FUOC • PID_00147721

7

Objetivos

El estudio de este módulo os permitirá alcanzar los objetivos siguientes:

1. Conocer los principales mecanismos de seguridad en la red. 2. Conocer los fundamentos de la criptografía y los certificados digitales. 3. Tener una visión global de los elementos de la red que pueden precisar mecanismos de seguridad y conocer los posibles puntos débiles de una red de computadores.

Seguridad en la red

© FUOC • PID_00147721

9

1. Cortafuegos

Cuando un equipo está conectado a una red de computadores se pueden identificar tres áreas de riesgo: 1) El número de puntos que se pueden utilizar como origen para realizar un ataque contra cualquier componente de la red se incrementa. En un sistema aislado (sin conexión), un requisito necesario para ser atacado es forzosamente la existencia de un acceso físico al equipo. Pero en el caso de un sistema en red, cada uno de los equipos que pueda enviar información hacia la víctima podrá ser utilizado por un posible atacante. Algunos servicios (como por ejemplo web y DNS) necesitan estar abiertos públicamente, de forma que cualquier equipo conectado a Internet podría ser el origen de una posible actividad maliciosa contra ellos. Eso hace que sea muy probable la existencia de ataques regulares contra estos sistemas. 2) La segunda área de riesgo incluye la expansión del perímetro físico del sistema telemático al que acaba de ser conectado el equipo. Cuando la máquina está aislada, cualquier actividad puede ser considerada como interna del equipo (y por lo tanto, de confianza). El procesador trabaja con los datos que encuentra en la memoria, que al mismo tiempo han sido cargados desde un medio de almacenamiento secundario. Estos datos están realmente bien protegidos contra actos de modificación, eliminación, observación maliciosa, etc., ya que se transfieren entre diferentes componentes de confianza. Pero esta misma premisa no es cierta cuando los datos son transferidos a través de una red. La información transmitida por el medio de comunicación es reenviada por dispositivos que están totalmente fuera del control del receptor. Esta información podría ser leída, almacenada, modificada y más tarde retransmitida hacia el receptor legítimo. Especialmente en grandes redes como Internet, no es trivial la autenticación del origen que se presenta como el emisor de un mensaje. 3) Finalmente, la tercera área de riesgo se debe al aumento del número de servicios de autenticación (generalmente un servicio de login-password) que un sistema conectado a la red tiene que ofrecer, con respecto a un sistema aislado. Estos servicios no dejan de ser simples aplicaciones (con posibles errores de programación o de diseño) que protegen el acceso a los recursos de los equipos del sistema. Un error o vulnerabilidad en alguno de estos servicios puede poner en apuros a todo el sistema.

Seguridad en la red

© FUOC • PID_00147721

10

Seguridad en la red

La prevención de ataques es la suma de una serie de mecanismos de seguridad que proporcionan un primer nivel de defensa contra cierto tipo de ataques antes de que éstos lleguen a su objetivo.

1.1. Sistemas cortafuegos Los sistemas cortafuegos1 son un mecanismo de control de acceso sobre la capa de red. La idea básica es separar nuestra red (donde los equipos que intervienen son de confianza) de los equipos del exterior (potencialmente hostiles). Un sistema cortafuegos actúa como una barrera central para reforzar el control de acceso a los servicios que se ejecutan tanto en el interior como en el exterior de la red. El cortafuegos intentará prevenir los ataques del exterior contra las máquinas internas de nuestra red denegando peticiones de conexión desde partes no autorizadas. Un cortafuegos puede ser cualquier dispositivo utilizado como mecanismo de control de acceso a nivel de red para proteger una red en particular o un conjunto de redes. En la mayoría de los casos, los sistemas cortafuegos se utilizan para prevenir accesos ilícitos al interior de la red.

Un cortafuegos es aquel sistema de red expresamente encargado de separar redes de computadores y efectuar un control del tráfico existente entre ellas. Este control consiste, en última instancia, en permitir o denegar el paso de la comunicación de una red a otra mediante el control de los protocolos Transmission Control Protocol/Internet Protocol (TCP/IP).

A la hora de instalar y configurar un sistema cortafuegos en nuestra red, se tiene que tener presente lo siguiente: 1) Todo el tráfico que sale del interior hacia el exterior de la red a proteger, y viceversa, tiene que pasar por el cortafuegos. Eso se puede conseguir bloqueando físicamente todo el acceso al interior de la red a través del sistema. 2) Sólo el tráfico autorizado, definido en las políticas de seguridad local del sistema, podrá traspasar el bloqueo. 3) El propio cortafuegos tiene que estar protegido contra posibles intrusiones. Eso implica el uso de un sistema operativo de confianza con suficientes garantías de seguridad.

(1)

En inglés, firewall.

© FUOC • PID_00147721

11

Seguridad en la red

1.2. Construcción de sistemas cortafuegos En el sentido más general, un sistema cortafuegos consta de software y hardware. El software puede ser propietario, shareware, o freeware. Por otra parte, el hardware podrá ser cualquiera que pueda soportar este software. Actualmente, dos de las tecnologías más utilizadas a la hora de construir sistemas cortafuegos son las siguientes: •

Encaminadores con filtrado de paquetes.

•

Pasarelas en el ámbito de aplicación.

1.2.1. Encaminadores con filtrado de paquetes

Un encaminador con filtrado de paquetes es un dispositivo que encamina el tráfico TCP/IP (encaminador de TCP/IP) sobre la base de una serie de reglas de filtrado que deciden qué paquetes se encaminan a través de él y cuáles son descartados.

Las reglas de filtrado se encargan de determinar si a un paquete le está permitido pasar de la parte interna de la red a la parte externa, y viceversa, verificando el tráfico de datos legítimo entre ambas partes. Los encaminadores con filtrado de paquetes, al trabajar a nivel de red, pueden aceptar o denegar paquetes fijándose en las cabeceras del protocolo (tanto IP como UDP2, TCP...), en las que se incluyen: •

Direcciones de origen y de destino.

•

Tipos de protocolo e indicadores especiales.

•

Puertos de origen y de destino o tipo de mensaje (según el protocolo).

•

Contenido de los paquetes.

•

Tamaño del paquete.

(2)

UDP es la abreviatura de User Datagram Protocol.

© FUOC • PID_00147721

12

Seguridad en la red

Las reglas están organizadas en conjuntos de listas con una determinada política por defecto (denegarlo todo, aceptarlo todo...). Cada paquete que llegue al dispositivo será comparado con las reglas, empezando por el principio de la lista hasta que se encuentre la primera coincidencia. Si existe alguna coincidencia, se activará la acción indicada en la regla (denegar, aceptar, redirigir...). Por el contrario, si no es posible ninguna coincidencia, se consultará la política por defecto para saber qué acción tomar (dejar pasar el paquete, descartarlo, redireccionarlo, etc.). Si se trata, por ejemplo, de una política de denegación por defecto, en el caso de no existir ninguna coincidencia con el paquete será descartado éste. Una política de denegación por defecto acostumbra a ser más costosa de mantener, ya que será necesario que el administrador indique explícitamente todos los servicios que tienen que permanecer abiertos (el resto, por defecto, serán todos denegados). En cambio, una política de aceptación por defecto es más sencilla de administrar, pero incrementa el riesgo de permitir ataques contra nuestra red, ya que requiere que el administrador indique explícitamente qué paquetes hay que descartar (el resto, por defecto, serán todos aceptados). Ventajas y desventajas de los encaminadores con filtrado de paquetes La construcción de un sistema cortafuegos mediante un encaminador con filtrado de paquetes es realmente económica, ya que generalmente se suele hacer con hardware ya disponible. Además, ofrece un alto rendimiento a redes con una carga de tráfico elevada. Adicionalmente, esta tecnología permite la implantación de la mayor parte de las políticas de seguridad necesarias.

Iptables Un ejemplo de encaminador con filtro de paquetes podría ser la aplicación�iptables, implementada como una parte del software de direccionamiento del kernel Linux.

© FUOC • PID_00147721

13

Seguridad en la red

Las políticas de seguridad son el resultado de documentar las expectativas de seguridad, intentando plasmar en el mundo real los conceptos abstractos de seguridad. Pueden definirse de manera procesal (plasmando de forma práctica las ideas o filosofías de la empresa en cuanto a seguridad) o de manera formal (utilizando un modelo matemático que intente abarcar todos los posibles estados y operaciones). A pesar de estas ventajas, los encaminadores de red con filtrado de paquetes pueden presentar algunas deficiencias, como, por ejemplo: •

Muchos de los encaminadores utilizados pueden ser vulnerables a ataques existentes (aunque la mayoría de los distribuidores tienen los correspondientes paquetes de actualizaciones para solucionarlo). Por otra parte, no suelen tener capacidades de registro. Eso provoca que al administrador le sea difícil saber si el propio encaminador está siendo atacado.

•

Su capacidad de actuación puede llegar a deteriorarse a causa de la utilización de un filtrado excesivamente estricto, dificultando también el proceso de gestión del dispositivo si este número de reglas llega a ser muy elevado.

•

Las reglas de filtrado pueden llegar a ser muy complicadas, lo que provoca en ocasiones que los posibles descuidos en su configuración sean aprovechados por un atacante para realizar una violación de la política de seguridad.

1.2.2. Pasarela en el ámbito de aplicación Una pasarela en el ámbito de aplicación, conocida también como servidor 3

intermediario , no direcciona paquetes a nivel de red sino que actúa como retransmisor en el ámbito de aplicación. Los usuarios de la red contactarán con el servidor intermediario, que a su vez estará ofreciendo un servicio proxy asociado a una o más aplicaciones determinadas.

(3)

En inglés, proxy.

© FUOC • PID_00147721

14

El servicio proxy se encargará de realizar las conexiones solicitadas con el exterior, y cuando reciba una respuesta se encargará de retransmitirla hacia el equipo que había iniciado la conexión. Así, el servicio proxy ejecutado en la pasarela aplicará las normas para decidir si se acepta o se rechaza una petición de conexión. Una pasarela separa completamente el interior del exterior de la red en la capa de enlace, ofreciendo únicamente un conjunto de servicios en el ámbito de aplicación. Eso permite la autenticación de los usuarios que realizan peticiones de conexión y el análisis de conexiones en el ámbito de aplicación. Estas dos características hacen que las pasarelas ofrezcan una mayor seguridad con respecto a los filtros de paquetes, presentando un rango de posibilidades muy elevado. Por el contrario, la penalización introducida por estos dispositivos es mucho mayor. En el caso de una gran carga de tráfico en la red, el rendimiento puede llegar a reducirse drásticamente. En la práctica, las pasarelas y los dispositivos de red con filtrado de paquetes son complementarios. Así, estos dos sistemas se pueden combinar, lo que proporcionará más seguridad y flexibilidad que si sólo se utilizara uno, tal como se muestra en la figura siguiente.

Cuando la pasarela autentifica al cliente, abre una conexión al servidor proxy, siendo éste el responsable de transmitir los datos que el cliente recibe del servidor intermediario.

Seguridad en la red

© FUOC • PID_00147721

15

Este funcionamiento particular provoca que las pasarelas en el ámbito de aplicación presenten un rendimiento inferior al de los filtros de paquetes. Con el fin de evitarlo, los servidores intermediarios hacen una copia de los datos transmitidos para entregárselos a otro cuando éste los solicite. El uso de las pasarelas proporciona diversos beneficios. De entrada, las pasarelas permiten sólo aquellos servicios para los cuales hay un servidor proxy habilitado. Así, si una pasarela contiene servicios intermediarios tan sólo para los servicios HTTP y DNS, entonces sólo HTTP y DNS serán permitidos en la red interna. El resto de los servicios serán completamente rechazados. Otro beneficio del uso de pasarelas es que el protocolo también puede ser filtrado, prohibiendo así el uso de diferentes subservicios dentro de un mismo servicio permitido. Por ejemplo, mediante una pasarela que filtrara conexiones FTP, sería posible prohibir únicamente el uso del comando PUT de FTP dejando habilitados el resto de comandos. Esta característica no es posible obtenerla sólo con el uso de filtros de paquetes. Adicionalmente, los servidores intermediarios también pueden implantar el filtro de conexiones por dirección IP de la misma manera que los filtros de paquetes, ya que la dirección IP está disponible en el ámbito de aplicación en el cual se hará el filtrado. A pesar de obtener más control global sobre los servicios vigilados, las pasarelas también presentan algunas problemáticas. Uno de los primeros inconvenientes a destacar es la necesidad de tener que configurar un servidor proxy para cada servicio de la red que se ha de vigilar (HTTP, DNS, Telnet, FTP...). Además, en el caso de protocolos cliente-servidor, como, por ejemplo, Telnet, pueden llegar a ser necesarios algunos pasos adicionales para conectar el punto final de la comunicación.

Seguridad en la red

© FUOC • PID_00147721

16

Seguridad en la red

2. Redes privadas virtuales

Los protocolos seguros que hemos visto hasta ahora permiten proteger las comunicaciones, por ejemplo, de una aplicación implementada como un proceso cliente que se ejecuta en un ordenador y un proceso servidor que se ejecuta en otro ordenador. Si hay otras aplicaciones que también necesitan una comunicación segura entre estos dos ordenadores, o entre ordenadores situados en las mismas redes locales, pueden hacer uso de otras instancias de los protocolos seguros: nuevas asociaciones de seguridad IPsec, nuevas conexiones SSL TLS, etc. Una posibilidad alternativa es establecer una red privada virtual4 entre estos ordenadores o las redes locales en las que están situados. 2.1. Definición y tipo de redes privadas virtuales

Una red�privada�virtual (VPN) es una configuración que combina el uso de dos tipos de tecnologías: •

Las tecnologías de seguridad que permiten la definición de una red privada, es decir, un medio de comunicación confidencial que no puede ser interceptado por usuarios ajenos a la red.

•

Las tecnologías de encabezamiento de protocolos que permiten que, en vez de una conexión física dedicada a la red privada, se pueda utilizar una infraestructura de red pública, como es Internet, para definir por encima de ella una red�virtual.

Por lo tanto, una VPN es una red lógica o virtual creada sobre una infraestructura compartida, pero que proporciona los servicios de protección necesarios para una comunicación segura. Dependiendo de la situación de los nodos que hacen uso de esta red, podemos considerar tres tipos de VPN: 1) Éste es el caso habitual en que una empresa dispone de redes locales en diferentes sedes, geográficamente separadas, en cada una de las cuales hay una red privada o intranet, de acceso restringido a sus empleados. Si interesa que desde una de las sedes se pueda acceder a las intranets de las otras sedes, se puede usar una VPN para interconectar estas redes privadas y formar una intranet única.

(4)

En inglés, Virtual Private Network (VPN).

© FUOC • PID_00147721

17

Seguridad en la red

2) Cuando un empleado de la empresa quiere acceder a la intranet desde un ordenador remoto, puede establecer una VPN de este tipo entre este ordenador y la intranet de la empresa. El ordenador remoto puede ser, por ejemplo, un PC que el empleado tiene en su casa, o un ordenador portátil desde el que se conecta a la red de la empresa cuando está de viaje. 3) A veces, a una empresa le interesa compartir una parte de los recursos de su intranet con determinados usuarios externos, como, por ejemplo, proveedores o clientes de la empresa. La red que permite estos accesos externos a una intranet se llama extranet, y su protección se alcanza mediante una VPN extranet. 2.2. Configuraciones y protocolos utilizados en VPN A cada uno de los tipos de VPN le suele corresponder una configuración específica. •

En las VPN entre intranets, la situación más habitual es que en cada intranet haya una pasarela�VPN que conecta la red local con Internet. Esta pasarela se comunica con la de las otras intranets, aplicando el cifrado y las protecciones que sean necesarias para las comunicaciones de pasarela a pasarela a través de Internet. Cuando los paquetes llegan a la intranet de destino, la pasarela correspondiente los descifra y los reenvía por la red local hasta el ordenador que los tenga que recibir. De esta manera se utiliza la infraestructura pública como Internet, en lugar de establecer líneas privadas dedicadas, que supondrían un coste más elevado. También se aprovecha la fiabilidad y redundancia que proporciona Internet, ya que si una ruta no está disponible siempre se pueden encaminar los paquetes por otro lugar, mientras que con una línea dedicada la redundancia supone un coste todavía mayor.

•

En las VPN de acceso remoto, a veces llamadas VPDN5, un usuario se puede comunicar con una intranet a través de un proveedor de acceso a Internet, utilizando tecnología convencional, como, por ejemplo, a través de un módem ADSL. El ordenador del usuario tiene que disponer de software cliente�VPN para comunicarse con la pasarela VPN de la intranet y llevar a cabo la autenticación necesaria, el cifrado, etc. Así, también se aprovecha la infraestructura de los proveedores de Internet para el acceso a la intranet, sin necesidad de llamadas a un módem de la empresa, que pueden llegar a tener un coste considerable.

•

El caso de las VPN extranet puede ser como el de las VPN entre intranets, en las que la comunicación segura se establece entre pasarelas VPN, o bien como el de las VPN de acceso remoto, en las que un cliente VPN se comunica con la pasarela de la intranet. La diferencia, sin embargo, es que, en este caso, normalmente el control de acceso es más restrictivo para permitir sólo el acceso a los recursos autorizados.

(5)

VPDN son las siglas de Virtual Private Dial Network.

18

© FUOC • PID_00147721

Seguridad en la red

La definición de una red virtual se lleva a cabo mediante el establecimiento de túneles, que permiten encapsular paquetes de la red virtual, con sus protocolos, dentro de paquetes de otra red, que normalmente es Internet, con su protocolo, es decir IP. Para la comunicación entre las diferentes intranets, o entre el ordenador que accede remotamente y la intranet, se pueden utilizar los protocolos que sean más convenientes. Los paquetes de estos protocolos, para poder hacerlos llegar a su destino a través de Internet, se pueden encapsular en datagramas IP, que contendrán en su interior los paquetes originales. Cuando llegan a su destino, estos datagramas se desencapsulan para recuperar los paquetes con el formato "nativo" del protocolo correspondiente. Uso de túneles en una VPN

Hay diversos protocolos que pueden ser utilizados para establecer los túneles, dependiendo del nivel de la comunicación en el que se quiera hacer la protección. El protocolo utilizado en la gran mayoría de configuraciones VPN es IPsec en modo túnel, generalmente con ESP para cifrar los datos, y opcionalmente con AH para autenticar los paquetes encapsulados. Las pasarelas VPN, en este caso, son pasarelas seguras Ipsec. En el caso de las VPN de acceso remoto o VPDN, existe la posibilidad de encapsular tramas PPP, que son las que transmite normalmente un cliente VPN de este tipo, sobre datagramas IP. Hay diversas opciones para encapsular PPP (que, a su vez, puede encapsular otros protocolos de red, como IPX, etc., y posiblemente IP) sobre IP: •

6

El protocolo PPTP (RFC 2637) especifica una técnica para la encapsulación de tramas PPP pero no añade servicios de autenticación. Estos servicios se pueden realizar con los mismos protocolos que utiliza PPP, como Password Authentication Protocol (BUCHE) o Challenge Handshake Authentication Protocol (CHAP).

(6)

PPTP es la abreviatura de Pointto-Point Tunneling Protocol.

19

© FUOC • PID_00147721

•

7

El protocolo L2F (RFC 2637) es parecido al PPTP pero también puede trabajar con SLIP, además de con PPP. Para la autenticación puede utilizar

Seguridad en la red (7)

L2F es la abreviatura de Layer Two Forwarding.

protocolos auxiliares como Remote Authentication Dial-In User Service (RADIUS). •

El protocolo L2TP8 (RFC 2661) combina las funcionalidades que ofrecen PPTP y L2F.

(8)

L2TP es la abreviatura de Layer Two Tunneling Protocol. (9)

•

9

El protocolo SSH ofrece la posibilidad de redirigir puertos TCP sobre un canal seguro, que podemos considerar como un túnel a nivel de transporte. Desde este punto de vista, también se podría considerar una conexión SSL TLS como un túnel en el ámbito del transporte que proporciona confidencialidad y autenticación. Habitualmente, sin embargo, este último tipo de túnel no sirve para cualquier tipo de tráfico sino sólo para datos TCP, y por lo tanto no se considera parte integrante de una VPN.

SSH es la abreviatura de Secure Shell.

20

© FUOC • PID_00147721

Seguridad en la red

3. Introducción a la criptografía

A lo largo de la historia se han diseñado diferentes técnicas para ocultar el significado de la información que no interesa que sea conocida por extraños. Algunas de ellas ya se utilizaban en tiempo de la antigua Grecia o del Imperio romano: por ejemplo, se atribuye a Julio César la invención de un código para enviar mensajes cifrados que no pudieran ser interpretados por el enemigo.

La criptografía estudia, desde un punto de vista matemático, los métodos para proteger la información. Por otra parte, el criptoanálisis estudia las posibles técnicas para contrarrestar los métodos criptográficos, y es de gran utilidad para ayudar a hacerlos más robustos y difíciles de atacar. El conjunto formado por estas dos disciplinas, criptografía y criptoanálisis, se llama criptología.

Uso del cifrado El hecho de usar el cifrado parte de la constatación de que intentar evitar la interceptación de la información por parte de un intruso (espía) es muy costoso. Enviar mensajes cifrados es más fácil, y así, aunque un espía los pueda ver, no podrá interpretar la información que contienen.

Cuando la protección que queremos obtener consiste en garantizar el secreto de la información, es decir, la confidencialidad, utilizamos el método criptográfico conocido como cifrado. Si M es el mensaje que queremos proteger o texto�en�claro, cifrarlo consiste en aplicarle un algoritmo de cifrado f, que lo transforme en otro mensaje que llamaremos texto�cifrado, C. Eso lo podemos expresar como: C = f(M) A fin de que este cifrado sea útil, tiene que existir otra transformación o algoritmo de descifrado f-1, que permita recuperar el mensaje original a partir del texto cifrado: M - f-1 (C) La cifra de César La cifra�de�César consiste en sustituir cada letra del mensaje por la que hay tres posiciones después en el alfabeto (volviendo a empezar por la letra A si llegamos a la Z). Así, si aplicamos este algoritmo de cifrado al texto en claro "ALEA JACTA EST" (y utilizamos el alfabeto latino actual, porque en tiempos de César no había letras como la "W"), obtenemos el texto cifrado "DOHD MDFWD HVW". El descifrado en este caso es bien sencillo: sólo hay que sustituir cada letra por la que hay 3 posiciones después en el alfabeto.

Criptografía Los términos criptografía, criptología, etc. provienen de la raíz griega kryptós, que quiere decir 'escondido'.

21

© FUOC • PID_00147721

Un esquema como el de la cifra de César tiene el inconveniente de que si el enemigo descubre cuál es el algoritmo de cifrado (y a partir de aquí deduce el algoritmo inverso), será capaz de interpretar todos los mensajes cifrados que capture. Entonces, habría que instruir a todos los "oficiales de comunicaciones" del ejército para que aprendieran un nuevo algoritmo, lo cual podría resultar complicado. En vez de eso, lo que se hace hoy es utilizar como algoritmo una función con un parámetro denominado clave. Ejemplo de uso de una clave El algoritmo de Julio César se puede generalizar definiendo una clave k que indique cuántas posiciones se adelanta cada letra en el alfabeto. La cifra de César, pues, utiliza k = 3. Para el descifrado se puede utilizar el mismo algoritmo, pero con la clave invertida (de º e, x = -k).

Entonces, podemos hablar de una función de cifrado e con una clave de cifrado k, y una función de descifrado d con una clave�de�descifrado x: C = e(k,M) M = d(x,C) = d(x,e(k,M)) Así, una solución al problema del espía que se entera de cómo descifrar los mensajes podría ser continuar utilizando el mismo algoritmo, pero con una clave diferente. Seguridad por ocultismo A lo largo de la historia ha habido casos que han demostrado la peligrosidad de basar la protección en mantener los algoritmos en secreto (lo que se conoce como "seguridad por ocultismo"). Si el algoritmo es conocido por muchos, es más fácil que se detecten las debilidades o vulnerabilidades y se puedan corregir rápidamente. Si no, un experto podría deducir el algoritmo por ingeniería inversa, y acabar descubriendo que tiene puntos débiles por donde atacarlo, como pasó con el algoritmo A5/1 de la telefonía móvil GSM.

Una premisa fundamental en la criptografía moderna es la llamada suposición�de�Kerckhoffs, de acuerdo con la cual los algoritmos tienen que ser conocidos públicamente y su seguridad sólo tiene que depender de la clave. En lugar de intentar ocultar el funcionamiento de los algoritmos, es mucho más seguro y efectivo mantener en secreto sólo las claves.

Un algoritmo se considera seguro si a un adversario le es imposible obtener el texto en claro M aunque conozca el algoritmo e y el texto cifrado C. Es decir, es imposible descifrar el mensaje sin saber cuál es la clave de descifrado. La palabra "imposible", sin embargo, hay que considerarla con diferentes matices. Un algoritmo criptográfico es computacionalmente�seguro si, aplicando el mejor método conocido, la cantidad de recursos necesarios (tiempo de cálculo, número de procesadores, etc.) para descifrar los mensajes sin conocer la clave es mucho mayor (unos cuantos órdenes de magnitud) que lo que está al

Seguridad en la red

22

© FUOC • PID_00147721

alcance de nadie. En el límite, un algoritmo es incondicionalmente�seguro si no puede ser invertido ni con recursos infinitos. Los algoritmos que se hacen servir en la práctica son (o intentan ser) computacionalmente seguros. La acción de intentar descifrar mensajes sin conocer la clave de descifrado se llama "ataque". Si el ataque tiene éxito, se suele decir coloquialmente que se ha conseguido "romper" el algoritmo. Hay dos maneras de llevar a cabo un ataque: •

Mediante el criptoanálisis, es decir, estudiando matemáticamente la manera de deducir el texto en claro a partir del texto cifrado.

•

Aplicando la fuerza�bruta,�es�decir,�probando�uno�a�uno�todos�los�valores�posibles�de�la�clave�de�descifrado x hasta encontrar uno que produzca un texto en claro con sentido. Ataques a la cifra de César Continuando con el ejemplo del algoritmo de César generalizado (con clave), un ataque criptoanalítico podría consistir en analizar las propiedades estadísticas del texto cifrado. Las letras cifradas que más se repiten probablemente corresponden a vocales o a las consonantes más frecuentes, las combinaciones más repetidas de dos (o tres) letras seguidas probablemente corresponden a los dígrafos (o trígrafos) que típicamente aparecen más veces en un texto, etc. Por otra parte, el ataque con fuerza bruta consistiría en intentar el descifrado con cada uno de los 25 posibles valores de la clave (1£ x£ 25, si el alfabeto tiene 26 letras) y mirar cuál da un resultado inteligible. En este caso, la cantidad de recursos necesarios es tan modesta que incluso se puede hacer el ataque a mano. Por lo tanto, este cifrado sería un ejemplo de algoritmo inseguro o débil.

A continuación veremos las características de los principales sistemas criptográficos utilizados en la protección de las comunicaciones. A partir de ahora, consideraremos los mensajes en claro, los mensajes cifrados y las claves como secuencias de bits. 3.1. Criptografía de clave simétrica

Los sistemas criptográficos de�clave�simétrica se caracterizan por que la clave de descifrado x es idéntica a la clave de cifrado k, o bien se puede deducir directamente a partir de ésta.

Para simplificar, supondremos que en este tipo de sistemas la clave de descifrado es igual a la de cifrado: x = k (si no, siempre podemos considerar que en el algoritmo de descifrado el primer paso es calcular la clave x a partir de la k). Por eso, estas técnicas criptográficas se llaman de clave simétrica, y, a veces, también de clave�compartida. Así, tenemos: C = e(k,M)

Seguridad en la red

23

© FUOC • PID_00147721

Seguridad en la red

M = d(k,C) = d(k,e(k,M)) La seguridad del sistema reside, pues, en mantener en secreto la clave k. Cuando los participantes en una comunicación quieren intercambiarse mensajes confidenciales, tienen que escoger una clave secreta y utilizarla para cifrar los mensajes. Entonces pueden enviar estos mensajes por cualquier canal de comunicación, en la confianza de que, aunque el canal sea inseguro y susceptible de ser inspeccionado por terceros, ningún espía Z será capaz de interpretarlos.

Si el sistema es de clave compartida, es necesario que el valor de la clave secreta k que utilizan A y B sea el mismo. Ahora bien, ¿cómo se pueden asegurar de que sea así? Está claro que no pueden enviar la clave escogida a través del canal de comunicación de que disponen, porque la hipótesis inicial es que este canal es inseguro y cualquiera podría descubrir la información que se transmite. Una posible solución es utilizar un canal aparte, que pueda ser considerado suficientemente seguro: Canales seguros Podrían ser ejemplos de "canales seguros" el correo tradicional (no electrónico) o un servicio de mensajería "física", una conversación telefónica o cara a cara, etc.

Esta solución, sin embargo, tiene algunos inconvenientes. Por una parte, se supone que el canal seguro no será de uso tan ágil como el canal inseguro (si lo fuera, sería mucho mejor enviar todos los mensajes confidenciales sin cifrar por el canal seguro, y olvidarnos del canal inseguro). Por lo tanto, puede ser difícil ir cambiando la clave. Y por otra parte, este esquema no es bastante general: puede ser que tengamos que enviar información cifrada a alguien

24

© FUOC • PID_00147721

con quien no podemos contactar de ninguna otra manera. Como veremos más adelante, estos problemas relacionados con el intercambio�de�claves se solucionan con la criptografía asimétrica. A continuación repasaremos las características básicas de los principales algoritmos criptográficos de clave simétrica, los cuales agruparemos en dos categorías: algoritmos de flujo y algoritmos de bloque. 3.1.1. Algoritmos de cifrado de flujo

El funcionamiento de una cifra de flujo consiste en combinar el texto en claro M con un texto de cifrado S que se obtiene a partir de la clave simétrica k. Para descifrar sólo hay que hacer la operación inversa con el texto cifrado y el mismo texto de cifrado S.

La operación de combinación que se utiliza típicamente es la suma, y la operación inversa, por lo tanto, es la resta. Si el texto está formado por caracteres, este algoritmo sería como una cifra de César en la que la clave va cambiando de un carácter a otro. La clave que corresponde cada vez viene dada por el texto de cifrado S (llamado keystream en inglés). Suma y resta de bits Cuando trabajamos con aritmética binaria o aritmética módulo 2, se cumple:

Si consideramos el texto formado por bits, la suma y la resta son equivalentes. En efecto, cuando se aplican bit a bit, las dos son idénticas a la operación lógica "o exclusiva", denotada con el operador XOR ("eXclusive OR'') o el símbolo ⊕. Así, pues: C = M⊕ S(k) M = C⊕ S(k) En los esquemas de cifrado de flujo, el texto en claro M puede ser de cualquier longitud, y el texto de cifrado S tiene que ser al menos igual de largo. De hecho, no hay que disponer del mensaje entero antes de empezar a cifrarlo o descifrarlo, ya que se puede implementar el algoritmo para que trabaje con un "flujo de datos" que va llegando (el texto en claro o el texto cifrado) y otro "flujo de datos" que se va generando a partir de la clave (el texto de cifrado). De aquí procede el nombre de este tipo de algoritmos. La figura siguiente ilustra el mecanismo básico de su implementación.

Seguridad en la red

© FUOC • PID_00147721

25

Esquema del cifrado y descifrado de flujo

Hay diferentes maneras de obtener el texto de cifrado S en función de la clave k: •

Si se escoge una secuencia k más corta que el mensaje M, una posibilidad sería repetirla cíclicamente tantas veces como haga falta para ir sumándola al texto en claro. El inconveniente de este método es que se puede romper fácilmente, sobre todo cuanto más corta sea la clave (en el caso mínimo, el algoritmo sería equivalente a la cifra de César).

•

En el otro extremo, se podría hacer directamente S(k) = k. Eso quiere decir que la propia clave tiene que ser tan larga como el mensaje a cifrar. Éste es el principio de la llamada cifra�de�Vernam. Si k es una secuencia totalmente aleatoria que no se repite cíclicamente, estamos ante un ejemplo de cifrado incondicionalmente seguro, tal como lo hemos definido al principio de este módulo. Este cifrado se llama en inglés one-time pad (cuaderno de un solo uso). El problema en este caso es que el receptor tiene que disponer de la misma secuencia aleatoria para poder hacer el descifrado, y si le tiene que llegar a través de un canal seguro, la pregunta es inmediata: ¿por qué no enviar el mensaje confidencial M, que es igual de largo que la clave k, directamente por el mismo canal seguro? Es evidente, pues, que este algoritmo es muy seguro, pero no es muy práctico en general. Uso del cifrado de Vernam A menudo, las comunicaciones entre los portaaviones y los aviones utilizan el cifrado de Vernam. En este caso, se utiliza el hecho de que en un momento dado (antes de elevarse) tanto el avión como el portaaviones están en el mismo lugar, e intercambiarse, por ejemplo, un disco duro de 20 GB con una secuencia aleatoria no es un problema. Posteriormente, cuando el avión despega puede establecer una comunicación segura con el portaaviones utilizando una cifra de Vernam con la clave aleatoria que ambas partes comparten.

•

Lo que se hace en la práctica es utilizar funciones que generan secuencias pseudoaleatorias a partir de una semilla (un número que actúa como parámetro del generador), y lo que se intercambia como clave secreta k es sólo esta semilla. Ejemplo de funciones pseudoaleatorias Son ejemplos de funciones pseudoaleatorias las basadas en registros de desplazamiento realimentados (feedback shift registers o FSR). El valor inicial del registro es la semilla. Para ir obteniendo cada bit pseudoaleatorio se desplazan todos los bits del registro una posición y se coge el que sale fuera del registro. El bit que queda libre en el otro extremo se llena con un valor que es función del resto de bits.

Seguridad en la red

© FUOC • PID_00147721

26

Las secuencias pseudoaleatorias se llaman así porque intentan parecer aleatorias pero, claro está, son generadas algorítmicamente. En cada paso, el algoritmo estará en un determinado estado, que vendrá dado por sus variables internas. Como las variables serán finitas, habrá un número máximo de posibles estados diferentes. Eso quiere decir que, al cabo de un cierto período, los datos generados se volverán a repetir. Para que el algoritmo sea seguro, interesa que el período de repetición sea cuanto más largo mejor (con relación al mensaje a cifrar), con el fin de dificultar el criptoanálisis. Las secuencias pseudoaleatorias también han de tener otras propiedades estadísticas equivalentes a las de las secuencias aleatorias puras.

Cifras�síncronas�y�asíncronas Si el texto de cifrado S depende exclusivamente de la clave k, se dice que el cifrado es síncrono. Este cifrado tiene el problema de que, si por algún error de transmisión se pierden bits (o llegan repetidos), el receptor se desincronizará y sumará bits del texto S con bits del texto cifrado C que no tocan, con lo cual el texto descifrado a partir de entonces será incorrecto. Eso se puede evitar con el cifrado asíncrono (o "autosincronizante"), en el cual el texto S se calcula a partir de la clave k y el mismo texto cifrado C. Es decir, en vez de realimentarse con sus propios bits de estado, el generador se realimenta con los n últimos bits cifrados transmitidos. De esta manera, si se pierden m bits consecutivos en la comunicación, el error afectará como máximo al descifrado de m + n bits del mensaje original.

Ejemplos de algoritmos de cifrado de flujo Los algoritmos de cifrado de flujo actualmente en uso tienen la propiedad de ser poco costosos de implementar. Las implementaciones en hardware son relativamente simples y, por lo tanto, tienen un rendimiento eficiente (en términos de bits cifrados por segundo). Pero también las implementaciones en software pueden ser bastante eficientes. Las características del cifrado de flujo lo hacen apropiado para entornos en los que haga falta un rendimiento alto y los recursos (capacidad de cálculo, consumo de energía) sean limitados. Por eso se suelen utilizar en comunicaciones móviles: redes locales sin hilos, telefonía móvil, etc.

3.1.2. Algoritmos de cifrado de bloque

En una cifra de bloque, el algoritmo de cifrado o descifrado se aplica separadamente a bloques de entrada de longitud fija b, y para cada uno de ellos el resultado es un bloque de la misma longitud.

Para cifrar un texto en claro de L bits hace falta dividirlo en bloques de b bits cada uno y cifrar estos bloques uno a uno. Si L no es múltiplo de b, se pueden añadir bits adicionales hasta llegar a un número entero de bloques,

Seguridad en la red

© FUOC • PID_00147721

27

pero entonces puede ser necesario indicar de alguna manera cuántos bits había realmente en el mensaje original. El descifrado también se tiene que realizar bloque a bloque. La figura siguiente muestra el esquema básico del cifrado de bloque. Esquema del cifrado de bloque

Muchos de los algoritmos de cifrado de bloque se basan en la combinación de dos operaciones básicas: sustitución y transposición.

La sustitución consiste en traducir cada grupo de bits de la entrada a otro, de acuerdo con una permutación determinada.

La cifra de César sería un ejemplo simple de sustitución, en el que cada grupo de bits correspondería a una letra. De hecho, se trata de un caso particular de sustitución�alfabética. En el caso más general, las letras del texto cifrado no tienen por qué estar a una distancia constante (la k del algoritmo, tal como lo hemos definido) de las letras del texto en claro. Clave de la sustitución alfabética Clave de la sustitución alfabética Está claro que la clave tiene que ser una permutación del alfabeto, es decir, no puede haber letras repetidas ni faltar ninguna. Si no, la transformación no sería invertible en general. La clave se puede expresar entonces como la secuencia correlativa de letras que corresponden a la A, la B, la C, etc. Ejemplo de sustitución alfabética Alfabeto: A B C D E F G H Y J K L M N O P Q R S T U V W X Y Z Clave: Q W E R T Y U Y O P A S D F G H J K L Z X C V B N M Texto�en�claro: A L E A J A C T A E S T Texto�cifrado: Q S T Q P Q E Z Q T L Z

Seguridad en la red

© FUOC • PID_00147721

28

La transposición consiste en reordenar la información del texto en claro según un patrón determinado.

Ejemplo de transposición Un ejemplo de transposición podría ser formar grupos de cinco letras, incluidos los espacios en blanco, y reescribir cada grupo (1,2,3,4,5) en el orden (3,1,5,4,2): Texto�en�claro: A L E A J A C T A E S T Texto�cifrado: E A A L C J A T A S T E

La transposición por sí sola no dificulta extraordinariamente el criptoanálisis, pero puede combinarse con otras operaciones para añadir complejidad a los algoritmos de cifrado. El producto�de�cifras, o combinación en cascada de diversas transformaciones criptográficas, es una técnica muy efectiva para implementar algoritmos bastante seguros de manera sencilla. Por ejemplo, muchos algoritmos de cifrado de bloque se basan en una serie de iteraciones de productos sustitucióntransposición.

Confusión�y�difusión Dos propiedades deseables en un algoritmo criptográfico son la "confusión", que consiste en esconder la relación entre la clave y las propiedades estadísticas del texto cifrado, y la "difusión", que propaga la redundancia del texto en claro a lo largo del texto cifrado para que no sea fácilmente reconocible. La confusión hace que cambiando un solo bit de la clave cambien muchos bits del texto cifrado, y la difusión hace que el cambio de un solo bit del texto en claro afecte también a muchos bits del texto cifrado. En un bucle de productos de cifras básicas, la sustitución contribuye a la confusión, mientras que la transposición contribuye a la difusión. La combinación de estas transformaciones simples, repetidas diversas veces, hace que los cambios en la entrada se propaguen por toda la salida por un "efecto avalancha".

Ejemplos de algoritmos de cifrado de bloque Durante muchos años el algoritmo de cifrado de bloque ha sido el algoritmo más estudiado y, al mismo tiempo, el más utilizado. Desarrollado por IBM durante los años setenta, fue adoptado por el NBS norteamericano (nombre que tenía entonces el actual NIST) como estándar para el cifrado de datos del año 1977. NBS y NISTNBS eran las siglas de National Bureau of Standards, y NIST son las siglas de National Institute of Standards and Technology. El algoritmo admite una clave de 64 bits, pero sólo 7 de cada 8 intervienen en el cifrado. Un posible uso de los bits de la clave DES que no influyen en el algoritmo es como bits

Seguridad en la red

29

© FUOC • PID_00147721

de paridad, de manera que la longitud efectiva de la clave es de 56 bits. Los bloques de texto en los cuales se aplica el DES tienen que ser de 64 bits cada uno. La parte central del algoritmo consiste en dividir la entrada en grupos de bits, hacer una sustitución diferente sobre cada grupo y, a continuación, una transposición de todos los bits. Esta transformación se repite 16 veces: a cada iteración, la entrada es una transposición diferente de los bits de la clave sumada bit a bit (XOR) con la salida de la iteración anterior. Tal como está diseñado el algoritmo, el descifrado se realiza igual que el cifrado, pero haciendo las transposiciones de la clave en el orden inverso (empezando por la última). A pesar de que a lo largo de los años el algoritmo DES ha demostrado ser muy resistente al criptoanálisis, su principal problema actualmente es la vulnerabilidad a los ataques de fuerza bruta, a causa de la longitud de la clave, de sólo 56 bits. Si en los años setenta era muy costoso hacer una búsqueda entre las 256 combinaciones posibles, la tecnología actual permite romper el algoritmo en un tiempo cada vez más corto. Por eso, en 1999 el NIST cambió el algoritmo DES por el "Triple DES" como estándar oficial, mientras no estuviera disponible el nuevo estándar AES. El Triple DES, como su nombre indica, consiste en aplicar el DES tres veces consecutivas. Eso se puede hacer con tres claves (k1, k2, k3), o bien con sólo dos diferentes (k1, k2, y otra vez k1). La longitud total de la clave en la segunda opción es de 112 bits (dos claves de 56 bits), que hoy ya se considera bastante segura; la primera opción proporciona más seguridad, pero a costa de utilizar una clave total de 168 bits (3 claves de 56 bits), que puede costar un poco más gestionar e intercambiar. Para hacer el sistema adaptable al estándar antiguo, en el Triple DES se aplica una secuencia cifrado-descifrado-cifrado (E-D-E) en lugar de tres cifrados: C = e(k3, d(k2, e(k1,M))) o bien: mod 1 emC = e(k1, d(k2, e(k1,M))) Así, haciendo k2 = k1 tenemos un sistema equivalente al DES simple. Como el estándar DES empezaba a quedarse anticuado, a causa sobre todo de la longitud tan corta de las claves, y el Triple DES no es muy eficiente cuando se implementa con software, en 1997 el NIST convocó a la comunidad criptológica para que presentara propuestas sobre un nuevo estándar, el AES, que sustituyera al DES. De los quince algoritmos candidatos que se aceptaron, se escogieron cinco como finalistas, y en octubre del 2000 se dio a conocer al ganador, el algoritmo Rijndael, propuesto por los criptógrafos belgas Joan Daemen y Vincent Rijmen. El Rijndael puede trabajar con bloques de 128, 192 o 256 bits (aunque el estándar AES sólo prevé los de 128), y la longitud de la clave también puede ser 128, 192 o 256 bits. Dependiendo de esta última longitud, el número de iteraciones del algoritmo es 10, 12 o 14, respectivamente. Cada iteración incluye una sustitución fija byte a byte, una transposición, una transformación consistente en desplazamientos de bits y XOR, y una suma binaria (XOR) con bits obtenidos a partir de la clave. Repetición del DES La operación de aplicar el cifrado DES con una clave y volver a cifrar el resultado con otra no es equivalente a un solo cifrado DES (no hay ninguna clave única que dé el mismo resultado que dan las otras dos juntas). Si no fuera así, la repetición del DES no sería más segura que el DES simple.

3.1.3. Uso de los algoritmos de clave simétrica Cuando se usa el cifrado simétrico para proteger las comunicaciones, se puede escoger el algoritmo que sea más apropiado a las necesidades de cada aplicación: normalmente, a más seguridad menos velocidad de cifrado, y viceversa. Un aspecto a tener en cuenta es que si bien el cifrado puede hacer que un atacante no descubra directamente los datos transmitidos, a veces es posible que se pueda deducir información indirectamente. Por ejemplo, en un protocolo

Seguridad en la red

© FUOC • PID_00147721

30

Seguridad en la red

que utilice mensajes con una cabecera fija, la aparición de los mismos datos cifrados varias veces en una transmisión puede indicar dónde empiezan los mensajes. Eso no pasa con las cifras de flujo si su período es lo bastante largo, pero en una cifra de bloque, si dos bloques de texto en claro son iguales y se utiliza la misma clave, los bloques cifrados también serán iguales. Para contrarrestar esta propiedad, se pueden aplicar en diversos modos�de�operación a las cifras de bloque: 1)�Modo�ECB�(Electronic�Codebook). Es el más sencillo, y consiste simplemente en dividir el texto en bloques y cifrar cada uno de manera independiente. Este modo presenta el problema de dar bloques iguales cuando en la entrada hay bloques iguales. Modo de operación ECB

Nombre del modo ECB Modo ECB (Electronic Codebook) da la idea de que se puede considerar como una simple sustitución bloque a bloque, de acuerdo con un código o diccionario (con muchas entradas, eso sí) que viene dado por la clave.

2)�Modo�CBC�(Cipher�Block�Chaining). En el modo CBC, antes de cifrar cada bloque de texto en claro se le suma (bit a bit, con XOR) el bloque cifrado anterior. En el primer bloque se le suma un vector� de� inicialización (VI), que es un conjunto de bits aleatorios de la misma longitud que un bloque. Escogiendo vectores diferentes cada vez, aunque el texto en claro sea el mismo, los datos cifrados serán diferentes. El receptor tiene que conocer el valor del vector antes de empezar a descifrar, pero no hay que guardar este valor en secreto, sino que normalmente se transmite como cabecera del texto cifrado. Modo de operación CBC

Modo CFB como cifra de flujo Es fácil ver que el modo CFB (y también el OFB) se puede considerar como una cifra de flujo que utiliza como función generadora una cifra de bloque.

3)�Modo�CFB�(Cipher�Feedback). En el modo CFB, el algoritmo de cifrado no se aplica directamente al texto en claro sino a un vector auxiliar (inicialmente igual al VI). Del resultado del cifrado se toman n bits que se suman a n bits del texto en claro para obtener n bits de texto cifrado. Estos bits cifrados se usan al mismo tiempo para actualizar el vector auxiliar. El número n de bits

© FUOC • PID_00147721

31

generados en cada iteración puede ser menor o igual que la longitud de bloque b. Tomando por ejemplo n = 8, tenemos una cifra que genera un byte cada vez sin tener que esperar a tener un bloque entero para poder cifrarlo. Modo de operación CFB

4)�Modo�OFB�(Output�Feedback). El modo OFB es como el CFB, pero en lugar de actualizar el vector auxiliar con el texto cifrado, se actualiza con el resultado obtenido del algoritmo de cifrado. La propiedad que diferencia este modo de los otros es que un error en la recepción de un bit cifrado afecta sólo al descifrado de este bit. Modo de operación OFB

5)�Otros�modos. A partir de los modos anteriores se pueden definir diversas variantes. Por ejemplo, el modo CTR (Counter) es como el OFB, pero el vector auxiliar no se realimenta con el cifrado anterior sino que es simplemente un contador que se va incrementando. Hay otra técnica para evitar que en textos de entrada iguales se obtengan textos cifrados iguales, que es aplicable también a los cifrados que no usan vector de inicialización (incluidas las cifras de flujo). Esta técnica consiste en modificar la clave secreta con bits aleatorios antes de usarla en el algoritmo de cifrado (o en el de descifrado). Como estos bits aleatorios sirven para dar un "sabor" diferente a la clave, se les suele llamar bits�de�sal. Igual que el vector de inicialización, los bits de sal se envían en claro antes del texto cifrado.

Seguridad en la red

32

© FUOC • PID_00147721

Seguridad en la red

3.1.4. Funciones hash seguras Aparte de cifrar datos, hay algoritmos basados en técnicas criptográficas que

(10)

En inglés, message digest.

se usan para garantizar la autenticidad de los mensajes. Un tipo de algoritmos de estas características son las llamadas funciones�hash�seguras, también conocidas como funciones de resumen�de�mensaje10. En general, podemos decir que una función hash nos permite obtener una cadena de bits de longitud fija, relativamente corta, a partir de un mensaje de longitud arbitraria: H = h(M) Para mensajes M iguales, la función h tiene que dar resúmenes H iguales. Pero si dos mensajes dan el mismo resumen H no necesariamente tienen que ser iguales. Eso es así porque sólo hay un conjunto limitado de posibles valores H, ya que su longitud es fija, y en cambio puede haber muchos más mensajes M (si la longitud puede ser cualquiera, habrá infinitos). Para poder aplicarla en un sistema de autenticación, la función h tiene que ser una función hash segura.

Se entiende que una función hash o de resumen es segura si cumple estas condiciones: 1) Es unidireccional, es decir, si tenemos H = h(M), es computacionalmente inviable encontrar M a partir del resumen H. 2) Es resistente�a�colisiones, es decir, dado un mensaje M cualquiera, es computacionalmente inviable encontrar un mensaje M'¹ M tal que h(M') = h(M).

Estas propiedades permiten el uso de las funciones hash seguras para dar un servicio de autenticidad basado en una clave secreta S compartida entre dos partes A y B. Aprovechando la unidireccionalidad, cuando A quiere enviar un mensaje M a B puede preparar otro mensaje Ms, por ejemplo, concatenando el original con la clave: Ms = (M,s). Entonces envía a B el mensaje M y el resumen del mensaje Ms. Para comprobar la autenticidad del mensaje recibido, B verifica que el resumen corresponde efectivamente a Ms. Si es así, quiere decir que lo ha generado alguien que conoce la clave secreta s (que tendría que ser A), y también que nadie ha modificado el mensaje.

Secreto de los algoritmos Notad que las funciones hash son conocidas ya que todo el mundo tiene que poder calcular los resúmenes de la misma manera.

© FUOC • PID_00147721

33

Otra técnica consistiría en calcular el resumen del mensaje M y cifrarlo utilizando s como clave de cifrado. Autenticidad y confidencialidad Cifrar sólo el resumen, en lugar del mensaje entero, es más eficiente porque hay menos bits a cifrar. Eso, claro está, suponiendo que sólo haga falta autenticidad, y no confidencialidad. Si también interesa que el mensaje sea confidencial, entonces sí que hay que cifrarlo entero.

Para verificar la autenticidad hace falta recuperar el resumen enviado, descifrándolo con la clave secreta s, y compararlo con el resumen del mensaje M. Un atacante que quisiera modificar el mensaje sin conocer la clave podría intentar sustituirlo por otro que dé el mismo resumen, con lo que B no detectaría la falsificación. Pero si la función de resumen es resistente a colisiones, eso le tendría que ser imposible al atacante. Con el fin de dificultar los ataques contra las funciones de resumen, por una parte los algoritmos tienen que definir una relación compleja entre los bits de la entrada y cada bit de la salida. Por otra parte, los ataques de fuerza bruta se contrarrestan haciendo bastante larga la longitud del resumen. Por ejemplo, los algoritmos usados actualmente generan resúmenes de 128 o 160 bits. Eso quiere decir que un atacante podría tener que probar del orden de 2128 o 2160 mensajes de entrada para encontrar una colisión (es decir, un mensaje diferente que diera el mismo resumen). Pero hay otro tipo de ataque más ventajoso para el atacante, llamado ataque del�cumpleaños. Un ataque de este tipo parte del supuesto de que el atacante puede escoger el mensaje que será autenticado. La víctima lee el mensaje y, si está de acuerdo, lo autentica con su clave secreta. Pero el atacante ha presentado este mensaje porque ha encontrado otro que da el mismo resumen, y por lo tanto puede hacer creer al destinatario que el mensaje auténtico es este otro. Y eso se puede conseguir haciendo una búsqueda de fuerza bruta con muchas menos operaciones: del orden de 264 o 280, si el resumen es de 128 o 160 bits, respectivamente. Resistencia fuerte a las colisiones La resistencia de los algoritmos de resumen a las colisiones, tal como la hemos definido, a veces se llama "resistencia débil", mientras que la propiedad de ser resistente a ataques del cumpleaños se llama " resistencia fuerte". Paradoja del cumpleaños El nombre de este tipo de ataque viene de un problema clásico de probabilidades conocido como la "paradoja del cumpleaños". El problema consiste en encontrar el número mínimo de personas que tiene que haber en un grupo para que la probabilidad de que al menos dos de ellas celebren su cumpleaños el mismo día sea superior al 50%. Una respuesta intuitiva puede ser que la solución es del orden de 200, pero este resultado no es correcto. Podría serlo si se quisiera obtener el número de personas necesarias para que hubiera un 50% de probabilidad de coincidencia con una persona determinada. Si aceptamos que la coincidencia sea entre cualquier pareja de personas, la solución es un número mucho menor: 23.

Seguridad en la red

© FUOC • PID_00147721

34

La conclusión es que si una función de resumen puede dar N valores diferentes, para que la probabilidad de encontrar dos mensajes con el mismo resumen sea del 50% el número de mensajes que hay que probar es del orden de √N Ejemplos de funciones hash seguras El esquema de la mayoría de funciones hash usadas actualmente es parecido al de los algoritmos de cifrado de bloque: el mensaje de entrada se divide en bloques de la misma longitud, y a cada uno se le aplica una serie de operaciones junto con el resultado obtenido del bloque anterior. El resultado que queda después de procesar el último bloque es el resumen del mensaje. Esquema de las funciones de resumen

El objetivo de estos algoritmos es que cada bit de la salida dependa de todos los bits de la entrada. Eso se consigue con diversas iteraciones de operaciones que "mezclen" los bits entre sí, de manera parecida a cómo la sucesión de transposiciones en los cifrados de bloque provoca un "efecto avalancha" que garantiza la difusión de los bits. Hasta hace poco, el algoritmo de hash más usado era el MD5 (Message Digest 5). Pero como el resumen que da es de sólo 128 bits, y aparte se han encontrado otras formas de generar colisiones parciales en el algoritmo, actualmente se recomienda utilizar algoritmos más seguros, como el SHA-1 (Secure Hash Algorithm-1). El algoritmo SHA-1, publicado en 1995 en un estándar del NIST (como revisión de un algoritmo anterior llamado simplemente SHA), da resúmenes de 160 bits. En el 2002 el NIST publicó variantes de este algoritmo que generan resúmenes de 256, 384 y 512 bits.

3.2. Criptografía de clave pública Trataremos ahora los conceptos fundamentales de la criptología de clave pública. 3.2.1. Algoritmos de clave pública Como hemos visto en el subapartado anterior, uno de los problemas de la criptografía de clave simétrica es el de la distribución de las claves. Este problema se puede solucionar si utilizamos algoritmos�de�clave�pública, también llamados algoritmos�de�clave�asimétrica.

En un algoritmo criptográfico de clave pública se utilizan claves diferentes para el cifrado y el descifrado. Una de ellas, la clave�pública, se puede obtener fácilmente a partir de la otra, la clave�privada, pero en cambio es computacionalmente muy difícil obtener la clave privada a partir de la clave pública.

Los algoritmos de clave pública típicamente permiten cifrar con la clave pública (kpub) y descifrar con la clave privada (kpr):

Seguridad en la red

35

© FUOC • PID_00147721

C = e(kpub,M) M = d(kpr,C) Pero también puede haber algoritmos que permitan cifrar con la clave privada y descifrar con la pública (más adelante veremos cómo se puede utilizar esta propiedad): C = e(kpr,M) M = d(kpub,C) Adaptación de los problemas difíciles Si el avance de la tecnología reduce el tiempo de resolución, se puede aumentar la longitud n, con lo cual harán falta unas cuantas operaciones más para el planteamiento, pero la complejidad de la solución crecerá exponencialmente.

Los algoritmos de clave pública se basan en problemas matemáticos "fáciles" de plantear a partir de la solución, pero "difíciles" de resolver. En este contexto, se entiende que un problema es fácil si el tiempo para resolverlo, en función de la longitud n de los datos, se puede expresar en forma polinómica, como, por ejemplo, n2 + 2n (en teoría de la complejidad, se dice que estos problemas son de la "clase P"). Si el tiempo de resolución crece más rápidamente, como por ejemplo con 2n, el problema se considera difícil. Así, se puede escoger un valor de n tal que el planteamiento sea viable pero la resolución sea computacionalmente intratable. Un ejemplo de problema fácil de plantear pero difícil de resolver es el de los logaritmos discretos. Si trabajamos con aritmética módulo m, es fácil calcular esta expresión: y = bx mod m El valor x se llama logaritmo discreto de y en base b módulo m. Escogiendo convenientemente b y m, puede ser difícil calcular el logaritmo discreto de cualquier y. Una posibilidad es ir probando todos los valores de x: si m es un número de n bits, el tiempo para encontrar la solución aumenta proporcionalmente a 2n. Hay otros métodos más eficientes para calcular logaritmos discretos, pero el mejor algoritmo conocido también necesita más tiempo de lo que se puede expresar polinómicamente. Ejemplo de operaciones módulo m Para obtener 1411 mod 19 podemos multiplicar 11 veces el número 14, dividir el resultado entre 19 y tomar el residuo de la división, que es igual en 13. Pero también se puede aprovechar que el exponente 11 es 1011 en binario (11 = 1·23 + 0·22 + 1·21 + 1·20), y por lo tanto 1411 = 148 · 142 · 141, para obtener el resultado con menos multiplicaciones:

Seguridad en la red

© FUOC • PID_00147721

36

Seguridad en la red

Así, sabemos que log14 13 = 11 (mod 19). Pero si tuviéramos que obtener el logaritmo de cualquier otro número y tendríamos que ir probando uno a uno los exponentes hasta encontrar uno que dé como resultado y. Y si en vez de tratarse de números de 4 o 5 bits como éstos fueran números de más de 1.000 bits, el problema sería intratable.

Así pues, los algoritmos de clave pública se tienen que diseñar de manera que sea inviable calcular la clave privada a partir de la pública, y lógicamente también tiene que ser inviable invertirlos sin saber la clave privada, pero el cifrado y el descifrado se tienen que poder realizar en un tiempo relativamente corto. En la práctica, los algoritmos utilizados permiten cifrar y descifrar fácilmente, pero todos ellos son considerablemente más lentos. Por eso, la criptografía de clave pública se suele utilizar sólo en los problemas que la criptografía simétrica no puede resolver: el intercambio de claves y la autenticación con no repudio (firmas digitales).

Los mecanismos de intercambio�de�claves permiten que dos partes se pongan de acuerdo en las claves simétricas que utilizarán para comunicarse, sin que un tercero que esté escuchando el diálogo pueda deducir cuáles son estas claves.

Ejemplo de mecanismos de intercambio de claves A puede escoger una clave simétrica k, cifrarla con la clave pública de B, y enviar el resultado a B. Entonces B descifrará con su clave privada el valor recibido, y sabrá cuál es la clave k que ha escogido A. El resto de la comunicación irá cifrada con un algoritmo simétrico (mucho más rápido), utilizando esta clave k. Los atacantes, como no conocerán la clave privada de B, no podrán deducir el valor de k.

La autenticación basada en clave pública se puede llevar a cabo si el algoritmo permite utilizar las claves a la inversa: la clave privada para cifrar y la clave pública para descifrar.

Si A envía un mensaje cifrado con su clave privada, todo el mundo podrá descifrarlo con la clave pública de A, y al mismo tiempo todo el mundo sabrá que el mensaje sólo lo puede haber generado quien conozca la clave privada asociada (que tendría que ser A). Ésta es la base de las firmas�digitales.

Velocidad de la criptografía de clave pública El cifrado y descifrado con algoritmos de clave pública puede llegar a ser dos o tres órdenes de magnitud más lento que con criptografía simétrica. que los equivalentes con criptografía simétrica.

37

© FUOC • PID_00147721

Seguridad en la red

Ejemplos de algoritmos de clave pública El RSA es el algoritmo más utilizado en la historia de la criptografía de clave pública. Su nombre viene de las iniciales de los que lo diseñaron en 1977: Ronald Rivest, Adi Shamir y Leonard Adleman. La clave pública está formada por un número n, calculado como producto de dos factores primeros muy grandes (n = p · q)), y un exponente e. La clave privada es otro exponente d calculado a partir de p, q y e, de tal forma que el cifrado y el descifrado se pueden realizar así: Cifrado: C = Me mod n Descifrado: M = Cd mod n Como se puede ver, la clave pública y la privada son intercambiables: si se usa cualquiera de ellas para cifrar, habrá que usar la otra para descifrar. La fortaleza del algoritmo RSA se basa, por una parte, en la dificultad de obtener M a partir de C sin conocer d (problema del logaritmo discreto), y por otra parte, en la dificultad de obtener p y q (y por lo tanto d) a partir de n (problema de la factorización de números grandes, que es otro de los problemas considerados difíciles). Valores usados en el RSA Actualmente, el problema de factorizar números de 512 bits es muy complejo, pero abordable si se dispone de bastantes recursos. Por lo tanto, se recomienda utilizar claves públicas con un valor n a partir de 1.024 bits. Como exponente público e típicamente se utilizan valores sencillos como 3 o 65.537 (1216 + 1) porque hacen más rápido el cifrado.

3.2.2. Uso de la criptografía de clave pública Hemos visto antes que las principales aplicaciones de la criptografía de clave pública son el intercambio de claves para proporcionar confidencialidad, y la firma digital para proporcionar autenticidad y no repudio. El problema de la confidencialidad entre dos partes que sólo disponen de un canal inseguro para comunicarse se resuelve con la criptografía de clave pública. Cuando A quiere enviar un mensaje secreto M a B, no hay que cifrar todo el mensaje con un algoritmo de clave pública (eso podría resultar muy lento), sino que se escoge una clave simétrica ks, llamada a veces clave�de�sesión o clave�de�transporte, y se cifra el mensaje con un algoritmo simétrico utilizando esta clave. Lo único que hay que cifrar con la clave pública de B ( la clave de sesión. En recepción, B utiliza su clave privada (

) es

) para recuperar

la clave de sesión ks y, entonces, ya puede descifrar el mensaje cifrado.

Ya que la clave de sesión es un mensaje relativamente corto (por ejemplo, si es una clave DES sólo tendrá 56 bits), un atacante podría intentar romper el cifrado a la fuerza bruta, pero no intentando descifrar el mensaje con los posibles valores de la clave privada

, sino cifrando los posibles valores de la

38

© FUOC • PID_00147721

clave de sesión ks con la clave pública

. En el caso de una clave de sesión

DES, independientemente del número de bits de la clave pública, el atacante sólo necesitaría un esfuerzo del orden de 256 operaciones. Para evitar este tipo de ataque, lo que se cifra realmente con la clave pública no es directamente el valor secreto (en este caso ks), sino que a este valor se le añade una cadena más o menos larga de bits aleatorios. El receptor sólo tiene que descartar estos bits aleatorios del resultado que obtenga del descifrado.

Una firma�digital es básicamente un mensaje cifrado con la clave privada del firmante. Sin embargo, por cuestión de eficiencia, lo que se cifra no es directamente el mensaje a firmar, sino sólo su resumen calculado con una función hash segura.

Cuando A quiera enviar un mensaje firmado, tendrá que obtener su resumen y cifrarlo con la clave privada descifrarla con la clave pública

. Para verificar la firma, el receptor tiene que y comparar el resultado con el resumen del

mensaje: si son iguales, quiere decir que el mensaje lo ha generado A y nadie lo ha modificado. Como se supone que la función de resumen es resistente a colisiones, un atacante no podrá modificar el mensaje sin que la firma deje de ser válida.

3.2.3. Infraestructura de clave pública Tal como hemos visto hasta ahora, la criptografía de clave pública permite resolver el problema del intercambio de claves, haciendo uso de las claves públicas de los participantes. Ahora, sin embargo, se plantea otro problema: si alguien nos dice que es A y su clave pública es kpub, ¿cómo poder saber que kpub es realmente la clave pública de A? Porque es perfectamente posible que un atacante Z genere su par de claves (k'pr,k'pub) y nos diga "yo soy A, y mi clave pública es k'pub". Una posible solución a este problema es que haya alguien de confianza que nos asegure que efectivamente las claves públicas pertenecen a sus supuestos propietarios. Ese alguien puede firmar un documento que diga "la clave pública de A es

", y publicarlo para que todo el mundo tenga conocimiento de

ello. Este tipo de documento se llama certificado�de�clave�pública y es la base de lo que se conoce como infraestructura�de�clave�pública�(PKI).

Seguridad en la red

© FUOC • PID_00147721

39

Seguridad en la red

4. Certificados digitales

Un certificado de clave pública consta de tres partes básicas: 1) Una identificación de usuario, como, por ejemplo, su nombre. 2) El valor de la clave pública de este usuario. 3) La signatura de las dos partes anteriores.

Si el autor de la signatura es alguien en quien confiamos, el certificado nos sirve como garantía de que la clave pública pertenece al usuario que figura en

(11)

En inglés, Certification Authority (CA).

ella. Quien firma el certificado puede ser una autoridad que se responsabilice de verificar de manera fehaciente la autenticidad de las claves públicas. En este caso, se dice que el certificado ha sido generado por una autoridad�de certificación11. Puede haber diferentes formatos de certificados, pero el más usado es el de los certificados�X.509, especificado en la definición del servicio�de�directorio X.500. El directorio X.500 permite almacenar y recuperar información, expresada co-

El directorio X.500 La especificación del directorio X.500 está publicada en la Serie de Recomendaciones ITU-T X.500, una de las cuales es la Recomendación X.509.

mo atributos, de un conjunto de objetos. Los objetos X.500 pueden representar, por ejemplo, países, ciudades, o bien empresas, universidades (en general, organizaciones), departamentos, facultades (en general, unidades organizati-

(12)

En inglés, Distinguished Name (DN).

vas), personas, etc. Todos estos objetos están organizados jerárquicamente en forma de árbol (en cada nodo del árbol hay un objeto) y, dentro de cada nivel, los objetos se identifican mediante un atributo� distintivo. A escala global, cada objeto se identifica con un nombre�distintivo12, que no es más que la concatenación de los atributos distintivos que hay entre la raíz del árbol y el objeto en cuestión. El sistema de nombres es, pues, parecido al DNS de Internet, con la diferencia de que los componentes de un nombre DNS son simples cadenas de caracteres, y los de un DN X.500 son atributos, cada uno con un tipo y un valor. X.500 define un protocolo de acceso al servicio que permite realizar operaciones de consulta, y también operaciones de modificación de la información de los objetos. Estas últimas operaciones, sin embargo, normalmente sólo están permitidas a ciertos usuarios autorizados, y por lo tanto hacen falta mecanismos de autenticación de los usuarios, y estos mecanismos están definidos en la Recomendación X.509. Hay un mecanismo básico que utiliza contraseñas, y un mecanismo más avanzado que utiliza certificados.

Ejemplos de nombre distintivo Algunos ejemplos de tipos de atributos que se pueden usar como atributos distintivos en un DN son: countryName (habitualmente denotado con la abreviatura "c"), stateOrProvinceName ("st"), localityName ("l"), organizationName ("o"), organizationalUnitName ("ou"), commonName ("cn"), surname ("sn"), etc. Un ejemplo de DN es "c=ES, st=Barcelona, l=Barcelona, o=Universitat Oberta de Catalunya, ou=SI, cn=cv.uoc.edu".

© FUOC • PID_00147721

40

Seguridad en la red

4.1. Cadenas de certificados y jerarquías de certificación Un certificado nos soluciona el problema de la autenticidad de la clave pública si está firmado por una CA en la que confiamos. Pero ¿qué pasa si nos comunicamos con un usuario que tiene un certificado emitido por una CA que no conocemos? Existe la posibilidad que una CA tenga un certificado que garantice la autenticidad de su clave pública, firmado por otra CA. Esta otra CA quizá sí la conocemos, o quizá tiene a su vez un certificado firmado por una tercera CASA, y así sucesivamente. De esta manera, se puede establecer una jerarquía de autoridades de certificación, en la que las CA de nivel más bajo emiten los certificados de usuario, y las CA de cada nivel son certificadas por una de nivel superior. En un mundo ideal, podría haber una CA raíz que estuviera en la cima de la jerarquía y tuviera la máxima autoridad. En la práctica, esta CA raíz global no existe, y seguramente no existirá nunca (sería difícil que la aceptara todo el mundo). En lugar de haber un solo árbol que comprenda todas las CA del mundo, lo que hay en realidad son árboles independientes (algunos posiblemente con una sola CA), cada uno con su CA raíz. Para que podamos verificar la autenticidad de su clave pública, un usuario nos puede enviar su certificado, más el certificado de la CA que lo ha emitido, más el de la CA que ha emitido este otro certificado, etc., hasta llegar al certificado de una CA raíz. Eso es lo que se denomina una cadena�de�certificados. Los certificados de las CA raíz tienen la propiedad de ser autofirmados, es decir, están firmados por ellas mismas. Un posible tipo de extensión de los certificados X.509 es basicConstraints, y un campo de su valor indica si el certificado es de CA (se puede usar su clave para emitir otros certificados) o no. En el caso de que lo sea, otro subcampo (pathLenConstraint) permite indicar el número máximo de niveles de la jerarquía por debajo de esta CA. 4.2. Listas de revocación de certificados La Recomendación X.509, además de definir el formato de los certificados, también define otra estructura denominada lista�de�revocación�de�certificados13. Una lista de este tipo sirve para publicar los certificados que han dejado de ser válidos antes de su fecha de caducidad. Los motivos pueden ser diversos: se ha emitido otro certificado que sustituye al revocado, ha cambiado el DN del titular (por ejemplo, ha dejado de trabajar en la empresa donde estaba), le han robado su clave privada, etc.

(13)

En inglés, Certificate Revocation List (CRL).

© FUOC • PID_00147721

41

Así, si queremos asegurarnos completamente de la validez de un certificado, no basta con verificar su firma, sino que tendremos que obtener la versión actual de la CRL (publicada por la CA que emitió el certificado) y comprobar que el certificado no aparezca en esta lista. Una CA normalmente actualizará su CRL de forma periódica, añadiendo cada vez los certificados que hayan sido revocados. Cuando llegue la fecha de caducidad que constaba en el certificado, ya no habrá que volver a incluirlo en la CRL. Eso permite que las CRL no crezcan indefinidamente.

Seguridad en la red

© FUOC • PID_00147721

42

5. Seguridad en la red

Hasta el momento hemos visto aspectos teóricos y prácticos relacionados con la arquitectura de la red y los protocolos de comunicación. En este apartado se presenta una visión de los conceptos de seguridad más enfocada a los ámbitos de aplicación y transporte de la red. Trataremos los aspectos a considerar en el desarrollo de aplicaciones como los protocolos de seguridad más usados hoy en día. 5.1. Cookies Las cookies (galletas) son un mecanismo para facilitar información sobre la navegación realizada. En definitiva, son una herramienta utilizada por los servidores web para almacenar información sobre sus visitantes.

Una cookie es un fichero de texto que algunos servidores web graban en nuestro ordenador con información sobre la navegación realizada en sus páginas. Este fichero se guarda en nuestro propio disco duro, y será devuelto posteriormente al servidor cuando éste lo solicite.

La caducidad de estas cookies, momento en el cual dejarán de ser activas, la determina el diseñador de la web del servidor, y puede variar entre el tiempo de la propia sesión y el de una fecha especificada. Las cookies no causan daños en el sistema, ya que sólo permiten reconocer al usuario cuando se conecta a un sitio web, registrando las visitas. En concreto, pueden llegar a guardar la contraseña utilizada para acceder a aquella página, datos personales del usuario, etc.; incluso así, muchos usuarios no desean este tipo de control no autorizado y prefieren el anonimato, siendo éste casi el único problema real de las cookies. Destaquemos también que existen virus que buscan esta información "sensible" dentro de las cookies. Por medio de las opciones de configuración del navegador se puede habilitar o deshabilitar la aceptación de cookies. También podemos configurarlo para que nos avise de la llegada de alguna cookie. Con las últimas versiones de los navegadores se ha ido mejorando el sistema de gestión de las cookies. Técnicamente, las cookies son trozos de datos arbitrarios definidos por el servidor web y enviados al navegador. El navegador las devuelve sin modificar al servidor, reflejando así un estado (memoria de acontecimientos anteriores) en las transacciones HTTP, que de otra manera serían independientes de estado.

Seguridad en la red

© FUOC • PID_00147721

43

Seguridad en la red

Sin las cookies, cada petición de una página web o un componente de una página web sería un acontecimiento aislado, sin ninguna relación con el resto de peticiones de otras páginas del mismo sitio. Al devolver una cookie al servidor web, el navegador le proporciona un medio para relacionar la solicitud de la página actual con solicitudes de páginas anteriores. Además de ser definidas por un servidor web, las cookies también pueden ser definidas por un script en un lenguaje como JavaScript, si éste está soportado y habilitado en el navegador web. El servidor que establece la cookie puede especificar una fecha de borrado, en cuyo caso la cookie será borrada en dicha fecha. Un sitio de compras podría querer ayudar a sus clientes potenciales recordándoles las cosas que había en su cesta de la compra, incluso si cierran el navegador sin realizar la compra y vuelven más tarde, para evitar que tengan que buscar los productos de nuevo. En este caso, el servidor crearía una cookie con fecha de borrado según el deseo del diseñador del sitio web. Si no se define una fecha de borrado, la cookie es borrada cuando el usuario cierra su navegador. Por lo tanto, definir una fecha de borrado es una manera de hacer que la cookie sobreviva entre una sesión y otra. Por esta razón, a las cookies con fecha de borrado se las llama persistentes. 5.2. Contenidos activos En los últimos años la web ha evolucionado desde el contenido estático que nos permitía crear HTML hasta contenidos completamente dinámicos, que constituyen ya hoy en día la mayoría de las páginas web. Un contenido dinámico es creado en tiempo de ejecución por un conjunto de procesos que se ejecutan tanto en el cliente como en el servidor, y eso depende de la tecnología utilizada. En este sentido, la seguridad de la web requiere técnicas cada vez más específicas con el fin de asegurar los contenidos y proteger las maquinas de códigos maliciosos. En este sentido introduciremos algunas de las tecnologías usadas para la creación de contenido dinámico. 5.2.1. Applets Un applet es un componente de software que corre en el contexto de otro programa, por ejemplo, un navegador web. El applet tiene que correr en un contenedor, que lo proporciona un programa anfitrión mediante un plug-in, o en aplicaciones, como teléfonos móviles, que soportan el modelo de programación por applets. Los applets se ejecutan en el contexto del cliente y por lo tanto requieren de técnicas que aseguren que la ejecución no dañará la máquina cliente.

Navegadores y cookies Las especificaciones de cookies sugieren que los navegadores tienen que soportar un número mínimo de cookies o una cantidad mínima de memoria por almacenarlas. En concreto, se espera que un navegador sea capaz de almacenar al menos 300 cookies de 4 kilobytes cada una y al menos 20 cookies por servidor o dominio.

© FUOC • PID_00147721

44

Seguridad en la red

A diferencia de un programa, un applet no puede correr de manera independiente, ofrece información gráfica y a veces interactúa con el usuario, típicamente carece de sesión y tiene privilegios de seguridad restringidos. Un applet normalmente lleva a cabo una función muy específica que carece de uso independiente. Los applets tienen restricciones de seguridad fuertes en lo que respecta a su acceso al ordenador cliente que los está ejecutando. Las políticas de seguridad son, pues, un factor muy importante a tener en cuenta cuando se desarrolla este tipo de software. 5.2.2. Servlets/JSP Los servlets son objetos Java ejecutados por un servidor de aplicaciones y responden a invocaciones HTTP, sirviendo páginas dinámicas cuyo contenido generalmente es un fichero HTML generado dinámicamente. Un servlet es capaz de recibir una invocación y generar una respuesta en función de los datos de la invocación, el estado del propio sistema y los datos

(14)

En inglés, Web Application Archive.

a que pueda acceder. Los servlets pueden estar empaquetados dentro de un fichero de formato WAR14, como aplicación web, dentro de un contenedor. La ejecución de un servlet se hace dentro de uno o más procesos del servidor de aplicaciones, de manera que se genera un nuevo flujo. No generar un nuevo proceso (como acostumbran a hacer los CGI) implica un ahorro de recursos que se traduce en un mejor rendimiento del sistema, pero comporta otros problemas de concurrencia. Los servlets pueden ser objetos java precompilados o JSP compilados en tiempo de ejecución (o en otro momento después del arranque del servidor de aplicaciones). Por otra parte, JavaServer Pages (JSP) es una tecnología que permite a los desarrolladores de páginas web generar respuestas dinámicamente a peticiones HTTP. La tecnología permite que código Java y ciertas acciones predefinidas sean incrustadas en un contexto estático, es decir, dentro del propio HTML. La sintaxis de JSP incorpora tags XML adicionales, llamados acciones de JSP por ser usados para invocar otras funciones. 5.2.3. CGI La interfaz de entrada común15 es una importante tecnología de la World Wide Web que permite a un cliente (navegador web) solicitar datos de un programa ejecutado en un servidor web. CGI especifica un estándar para transferir datos entre el cliente y el programa. Es un mecanismo de comunicación entre el

(15)

En inglés, Common Gateway Interface (CGI).

© FUOC • PID_00147721

45

Seguridad en la red

servidor web y una aplicación externa cuyo resultado final de la ejecución son objetos MIME. Las aplicaciones que se ejecutan en el servidor reciben el nombre de CGI. Las aplicaciones CGI fueron una de las primeras maneras prácticas de crear contenido dinámico para las páginas web. En una aplicación CGI, el servidor web pasa las solicitudes del cliente a un programa externo. Este programa puede estar escrito en cualquier lenguaje que soporte el servidor, aunque por razones de portabilidad se suelen usar lenguajes de script. La salida de este programa es enviada al cliente en lugar del archivo estático tradicional. CGI ha hecho posible la implementación de funciones nuevas y variadas en las páginas web, de tal manera que esta interfaz se ha convertido rápidamente en un estándar, que se implementa en todo tipo de servidores web. Las CGI son programas que podrían introducir problemas de seguridad si han sido programados malintencionadamente. Por este motivo, muchos de los proveedores de hosting de páginas web no permiten la ejecución de este tipo de servicios web. 5.2.4. ASP/PHP El servidor de páginas activas16 corresponde a la tecnología introducida por Microsoft en el año 1996, y permite el uso de diferentes scripts y componentes

(16)

En inglés, Active Server Pages (ASP).

ActiveX al lado del tradicional HTML para mostrar páginas generadas dinámicamente. Se basa en el VBScript, pero existen diversos lenguajes de programación que se pueden utilizar, como, por ejemplo, Perl, Javascript, etc. ASP es una tecnología dinámica que funciona en el lado del servidor, lo que significa que, cuando el usuario solicita un documento ASP, las instrucciones de programación dentro del script se ejecutan en el servidor para enviar al navegador únicamente el código HTML resultante. Al usuario sólo se le envía lo que solicita, y no puede acceder a ningún otro servicio del servidor. Así, una de sus aplicaciones más importantes es la del acceso a bases de datos. Existen otros lenguajes con funcionalidades parecidas. Entre ellos destacaremos el PHP (Hypertext Preprocessor), que es un lenguaje de programación creado para desarrollar aplicaciones web, muy similar a los lenguajes de programación C o C++. Su código se inserta en las páginas HTML, y se ejecuta en el servidor. Hay que destacar la aparición de muchos frameworks que facilitan el desarrollo de aplicaciones web, a la vez que integran las funcionalidades de generación de contenido y su almacenaje. Por ejemplo, Cake, Rails, etc.

Dirección web recomendada Para saber más sobre PHP podéis consultar la siguiente dirección: http://www.php.net.

© FUOC • PID_00147721

46

Seguridad en la red

5.2.5. RIA RIA (Rich Internet Applications) es un acrónimo que engloba una gran multitud de términos que definen una serie de aplicaciones cuyos contenidos son dinámicos y se cargan en el tiempo de inicialización. La aplicación sólo hace consultas al servidor para obtener datos de las bases de datos mientras que las herramientas (reproductores de vídeo, procesamiento de imágenes) ya están cargadas en el lado del cliente. Eso hace que se puedan ofrecer funcionalidades mucho más ricas y entornos multimedia más conseguidos. Se puede decir que las RIA son la nueva generación de las aplicaciones y una tendencia ya impuesta por empresas como Macromedia, Magic Software, Sun o Microsoft, que están desarrollando recursos para hacer de este tipo de aplicaciones una realidad. Estas aplicaciones están basadas en plataformas J2EE o.NET, con un front-end Flash, Java Swing, Java FX o Google Web Toolkit, y utilizan una arquitectura cliente/servidor asíncrona, segura y escalable, junto con una interfaz de usuario web. Entre los beneficios principales de las aplicaciones RIA tenemos una mejora importante en la experiencia visual, que hacen del uso de la aplicación alguna cosa muy sencillo, mejoras en la conectividad y despliegue instantáneo de la aplicación, agilizando su acceso, garantizan la desvinculación de la capa de presentación, es decir, el acceso a la aplicación desde cualquier computador en cualquier lugar del mundo. Un framework que permite desarrollar de forma sencilla este tipo de aplicaciones es Google Web Toolkit. 5.3. Protocolos de seguridad Los protocolos definen las reglas y las normas que utilizan los ordenadores para comunicarse con la red. Internet es un canal inseguro para enviar información. Cuando se tiene que enviar un mensaje por Internet, se le hace pasar por numerosos nodos intermedios antes de llegar a su destino. Alguno de estos nodos intermedios podría interceptar, leer, destruir o modificar la información enviada. Muchas veces, durante el proceso de diseño de una aplicación la seguridad es un aspecto que se deja de lado y se acaba añadiendo con posterioridad. En muchos casos, estos añadidos no han contemplado todos los posibles problemas y, por lo tanto, hacen que la aplicación pueda ser vulnerable. En un principio, en el modelo OSI17 de comunicaciones, se decidió poner todo lo que se refiere a seguridad en el nivel de presentación. De esta manera, se podría ofrecer este servicio a todas las aplicaciones. No obstante, el modelo OSI no tuvo éxito y, por lo tanto, esta solución no ha sido usada. Si analizamos el modelo Internet, basado en el protocolo TCP/IP, veremos que no existe ningún nivel de presentación, pero podemos llegar a establecer una cierta equivalencia entre ambos modelos que nos será útil para señalar los

(17)

OSI es la abreviatura de Open Systems Interconnection, en castellano, interconexión de sistemas abiertos.

© FUOC • PID_00147721

47

sistemas de seguridad que podemos establecer en cada uno de los niveles. En el nivel de aplicación podemos implementar aquellos servicios de seguridad que sean específicos de cada aplicación.

El servicio de seguridad pasa a través de aplicaciones intermedias. Por ejemplo, Pretty Good Privacy (PGP), Secure Electronic Transactions (SET), S/MIME, etc. Por debajo del nivel de aplicación, podemos llegar a intercalar servicios de seguridad como Secure Sockets Layer (SSL), Transporte Layer Secure (TLS), etc. Entre los niveles TCP y IP, podríamos establecer medidas de seguridad transparentes en las aplicaciones. Ejemplo: IPSEC. Incluso por debajo del nivel IP, podemos llegar a cifrar las cabeceras IP, pero ello tiene el inconveniente de que, si no se realiza correctamente el descifrado, los datos no llegarán a su destino. 5.3.1. PGP Existen herramientas basadas en algoritmos criptográficos que permiten proteger la información que se intercambia a través de la red. Pretty Good Privacy (PGP) es un protocolo que permite cifrar (encriptar) ficheros y mensajes de correo electrónico de manera que sólo puedan acceder a ellos los usuarios que determinemos. De forma adicional, PGP permite realizar una firma digital de

Seguridad en la red

© FUOC • PID_00147721

48

los ficheros y mensajes, con lo que se puede garantizar la integridad de los mismos. Mediante este programa podemos llevar la gestión de claves, cifrar y firmar digitalmente mensajes y ficheros, borrado seguro de ficheros, etc. Resumiendo, sus dos usos más comunes son los siguientes: •

Garantizar que un fichero informático (mensaje de correo electrónico, fichero de texto, hoja de cálculo, imagen, etc.) ha sido creado por quien dice ser su creador (firma digital).

•

Impedir que personas sin autorización lean un fichero informático (encriptación).

No obstante, aunque tiene otras funciones, nos centraremos en las dos formas más comunes de uso de PGP, la firma digital y la encriptación. Para usar cualquiera de estas funciones, el usuario de PGP tiene que crear una pareja de claves (una pública y otra privada), que son la base sobre la que se sostiene la criptografía de claves públicas, basada en los algoritmos de clave asimétrica. Crear la pareja de claves es muy sencillo, ya que es la aplicación PGP la que se encarga prácticamente de todo. Para que se pueda utilizar PGP, los interlocutores tendrán que tener instalado el programa. Al instalarse el programa se generan unas claves. Una de las claves que forman la pareja es la clave privada, a la que siempre hay que proteger contra los accesos no autorizados, ya que toda nuestra seguridad se basa en que nadie más tenga acceso a ella. Para reducir su vulnerabilidad, la clave privada está protegida por una contraseña compleja en forma de frase que es mucho más segura que una contraseña típica de menos de diez caracteres. Su utilidad es desencriptar los mensajes que nos sean enviados de forma segura. Por el contrario, la clave pública hay que distribuirla a todas las personas con las que queramos mantener comunicaciones seguras. Podría parecer que distribuir libremente nuestra clave pública es una forma de bajar nuestras defensas, pero no es así: la clave pública está encriptada y, además, su única utilidad es cifrar (encriptar) los mensajes y ficheros que los otros nos quieran enviar. Con ella es imposible desencriptar los mensajes o ficheros que alguien nos haya enviado; tampoco es posible hacerse pasar por nosotros firmando un fichero. Para eso sería preciso disponer de la clave privada. PGP se puede integrar en los programas de correo electrónico más usuales para hacer que encriptar y firmar mensajes no consista más que en pulsar un botón. Al encriptar un mensaje, se nos pedirá que indiquemos a quién lo enviaremos, para así escoger la clave pública correcta con que cifrarlo. Para firmar, en cambio, se nos pedirá que tecleemos la contraseña de nuestra clave privada, con lo cual evitamos también que alguien que use nuestro ordenador en nuestra ausencia pueda hacerse pasar por nosotros.

Seguridad en la red

© FUOC • PID_00147721

49

Para cifrar los datos se utiliza un algoritmo de clave simétrica, cuya clave se cifra con un algoritmo de clave asimétrica. De esta manera se combinan las mejores propiedades de ambos: la seguridad de un algoritmo asimétrico (donde clave pública y privada son diferentes) con la rapidez y robustez de un algoritmo simétrico (cuya clave es única y, por lo tanto, vulnerable). Un tercer algoritmo se utiliza para firmar documentos: se extrae un conjunto de bits del mensaje (resumen) con una función hash y se cifra con la clave privada del emisor. Así, por su modo de funcionamiento, PGP (y programas similares), consta de los tres subsistemas: cifrado del documento con clave asimétrica, cifrado con clave simétrica y firma digital. Cuando se desea enviar un correo o fichero encriptado de B a A, PGP lo encripta usando un sistema simétrico (generalmente IDEA o DES), usando una clave aleatoria –clave DES–, que posteriormente se encripta (por ejemplo, con RSA con la clave pública de A, KAp). Se envían el documento cifrado con la clave aleatoria y ésta encriptada con la clave RSA privada del destinatario. Cuando A recibe el correo y desea desencriptarlo, su programa PGP descifra primero la clave simétrica con su clave privada RSA (Kas), y después descifra el documento usando la clave desencriptada –clave DES–. 5.4. SSL Secure Socket Layer es un sistema de protocolos de carácter general diseñado en 1994 por la empresa Nestcape Communications Corporation, basado en la aplicación conjunta de criptografía simétrica, criptografía asimétrica (de clave pública), certificados digitales y firmas digitales, para ofrecer conexiones seguras a través de Internet. Este grupo de protocolos comprende: •

El protocolo de transporte Secure Sockets Layer (SSL), desarrollado por Netscape Communications a principios de los años noventa. La primera versión de este protocolo, sobradamente difundida e implementada, fue la 2.0. Poco después, Netscape publicó la versión 3.0, con muchos cambios con respecto a la anterior, que hoy casi ya no se utiliza.

•

La especificación Transport Layer Security (TLS), elaborada por la Internet Engineering Task Force (IETF). La versión 1.0 del protocolo TLS está publicada en el documento RFC 2246. Es prácticamente equivalente a SSL 3.0 con algunas pequeñas diferencias, por lo cual en ciertos contextos se considera el TLS 1.0 como si fuera el protocolo SSL 3.1.

•

El protocolo Wireless Transport Layer Security (WTLS), perteneciente a la familia de protocolos Wireless Application Protocol (WAP) para el acceso a la red desde dispositivos móviles. La mayoría de los protocolos WAP son adaptaciones de los ya existentes a las características de las comunicaciones sin hilos, y en particular el WTLS está basado en el TLS 1.0. Las diferencias se centran principalmente en aspectos relativos al uso eficiente del

Seguridad en la red

© FUOC • PID_00147721

50

ancho de banda y de la capacidad de cálculo de los dispositivos, que puede ser limitada.

5.4.1. Características del protocolo SSL/TLS El objetivo inicial del diseño del protocolo SSL fue proteger las conexiones entre clientes y servidores web con el protocolo HTTP. Esta protección tenía que permitir al cliente asegurarse de que se había conectado al servidor auténtico, y enviarle datos confidenciales, como, por ejemplo, un número de tarjeta de crédito, con la certeza de que nadie más que el servidor es capaz de ver estos datos. Las funciones de seguridad, sin embargo, no se implementaron directamente en la protección de aplicación HTTP, sino que se optó por introducirlas en el nivel de transporte. Así podría haber muchas más aplicaciones que hicieran uso de esta funcionalidad. A tal fin se desarrolló una interfaz de acceso a los servicios del nivel de transporte basada en la interfaz estándar de los sockets. En esta nueva interfaz, funciones como connect, accept, send o recv fueron sustituidas por otras equivalentes pero que utilizaban un protocolo de transporte seguro: SSL_connect, SSL_accept, SSL_send, SSL_recv, etc. El diseño se hizo de manera tal que cualquier aplicación que utilizara TCP a través de los llamamientos de los sockets podía hacer uso del protocolo SSL sólo cambiando estos llamamientos. De aquí viene el nombre del protocolo. Diseño del protocolo SSL

Datagramas en WTLS Una característica distintiva del WTLS es que no solamente permite proteger conexiones TCP, como hacen SSL y TLS, sino que también define un mecanismo de protección para las comunicaciones en modo datagrama, usado en diversas aplicaciones móviles.

Los servicios de seguridad que proporcionan los protocolos SSL TLS son:

Seguridad en la red

© FUOC • PID_00147721

•

51

Confidencialidad. El flujo normal de información en una conexión SSL TLS consiste en intercambiar paquetes con datos cifrados mediante claves simétricas (por motivos de eficiencia y rapidez). Al inicio de cada sesión, cliente y servidor se ponen de acuerdo sobre las claves que utilizarán para cifrar los datos. Siempre se utilizan dos claves diferentes: una para los paquetes enviados por el cliente al servidor, y la otra para los paquetes enviados en sentido contrario. Para evitar que un intruso que esté escuchando el diálogo inicial pueda saber cuáles son las claves acordadas, se sigue un mecanismo seguro de intercambio de claves, basado en criptografía de clave pública. El algoritmo concreto para este intercambio también se negocia durante el establecimiento de la conexión.

•

Autenticación�de�entidad. Con un protocolo basado en firmas digitales, el cliente puede confirmar la identidad del servidor al que se ha conectado. Para validar las firmas, el cliente necesita conocer la clave pública del servidor, y eso normalmente se hace a través de certificados digitales. SSL/TLS también prevé la autenticación del cliente de cara al servidor. Esta posibilidad, sin embargo, no se usa tan a menudo porque muchas veces, en vez de autenticar automáticamente al cliente a nivel de transporte, las mismas aplicaciones utilizan su propio método de autenticación. Autenticación de cliente Un ejemplo de autenticación de cliente en el ámbito de aplicación son las contraseñas que pueden introducir los usuarios en formularios HTML. Si la aplicación utiliza este método, al servidor ya no le hace falta autenticar al cliente a nivel de transporte.

•

Autenticación�de�mensaje. Cada paquete enviado en una conexión SSL TLS, además de ir cifrado, puede incorporar un código MAC para que el destinatario compruebe que nadie ha modificado el paquete. Las claves secretas para el cálculo de los códigos MAC (una para cada sentido) también se acuerdan de forma segura en el diálogo inicial.

Además, los protocolos SSL TLS están diseñados con estos criterios adicionales: •

Eficiencia. Dos de las características de los SSL TLS, la definición de sesiones y la compresión de los datos, permiten mejorar la eficiencia de la comunicación. –

Si el cliente pide dos o más conexiones simultáneas o muy seguidas, en lugar de repetir la autenticación y el intercambio de claves (operaciones computacionalmente costosas porque intervienen algoritmos de clave pública), existe la opción de reutilizar los parámetros previamente acordados. Si se hace uso de esta opción, se considera que la nueva conexión pertenece a la misma sesión que la anterior. En el establecimiento de cada conexión se especifica un identificador�de�sesión, que permite saber si la conexión empieza una sesión nueva o es continuación de otra.

Seguridad en la red

© FUOC • PID_00147721

–

52

SSL TLS prevé la negociación de algoritmos de compresión para los datos intercambiados, para compensar el tráfico adicional que introduce la seguridad. Ni SSL 3.0 ni TLS 1.0, sin embargo, especifican ningún algoritmo concreto de compresión.

Conexiones consecutivas o simultáneas Una situación típica en la que se usa SSL TLS es la de un navegador web que accede a una página HTML que contiene imágenes: con HTTP "no persistente" (el único modo definido en HTTP 1.0), eso requiere una primera conexión para la página y, a continuación, tantas conexiones como imágenes haya. Si las conexiones pertenecen a la misma sesión SSL TLS, sólo hay que hacer la negociación una vez.

•

Extensibilidad. Al principio de cada sesión, cliente y servidor negocian los algoritmos que utilizarán para el intercambio de claves, la autenticación y el cifrado (además del algoritmo de compresión). Las especificaciones de los protocolos incluyen unas combinaciones predefinidas de algoritmos criptográficos, pero dejan abierta la posibilidad de añadir nuevos algoritmos si se descubren otros que sean más eficientes o más seguros.

5.4.2. El transporte seguro SSL/TLS La capa de transporte seguro que proporciona SSL/TLS se puede considerar dividida en dos subcapas. •

La subcapa superior se encarga básicamente de negociar los parámetros de seguridad y transferir los datos de la aplicación. Tanto los datos de negociación como los de aplicación se intercambian en mensajes.

•

En la subcapa inferior, estos mensajes son estructurados en registros a los cuales se aplica, según corresponda, la compresión, la autenticación y el cifrado.

Estructura de la capa SSL/TLS

Seguridad en la red

© FUOC • PID_00147721

53

Seguridad en la red

El protocolo�de�registros�SSL�TLS es el que permite que los datos protegidos sean convenientemente codificados por el emisor e interpretados por el receptor. Los parámetros necesarios para la protección, como los algoritmos y las claves, se establecen de forma segura al inicio de la conexión mediante el protocolo�de�negociación�SSL/TLS.

El protocolo de negociación SSL/TLS El protocolo de negociación SSL TLS, también llamado protocolo�de�apretón de�manos (Handshake Protocol), tiene por finalidad autenticar el cliente y/o el servidor, y acordar los algoritmos y claves que utilizarán de una manera segura, es decir, garantizando la confidencialidad y la integridad de la negociación. Como todos los mensajes SSL/TLS, los mensajes del protocolo de negociación se incluyen dentro del campo de datos de los registros SSL/TLS para ser transmitido al destinatario. La estructura de un mensaje de negociación es la que se muestra en la figura siguiente. Formato de los mensajes de negociación SSL/TLS

El contenido del mensaje tendrá unos determinados campos dependiendo del tipo de mensaje de negociación de que se trate. En total hay 10 tipos diferentes, que veremos a continuación en el orden en que se tienen que enviar. 1)� Petición� de� saludo� (Hello� Request). Cuando se establece una conexión, el servidor normalmente espera que el cliente inicie la negociación. Alternativamente, puede optar por enviar un mensaje Hello Request para indicar al cliente que está preparado para empezar. Si durante la sesión el servidor quiere iniciar una renegociación, también lo puede indicar al cliente enviándole un mensaje de este tipo. 2)�Saludo�de�cliente�(Client�Hello). El cliente envía un mensaje Client Hello al inicio de la conexión o como respuesta a un Hello Request. Este mensaje contiene la siguiente información: •

La versión del protocolo que el cliente quiere utilizar.

•

Una cadena de 32 bytes aleatorios18.

•

Opcionalmente, el identificador de una sesión anterior, si el cliente desea volver a utilizar los parámetros que se le concedieron.

(18)

De los 32 bytes aleatorios que se envían en los mensajes de saludo, los 4 primeros tienen que ser una marca de tiempo, con precisión de segundos.

© FUOC • PID_00147721

•

54

Seguridad en la red

La lista de las combinaciones de algoritmos criptográficos que el cliente ofrece utilizar, por orden de preferencia. Cada combinación incluye el algoritmo de cifrado, el algoritmo de MAC y el método de intercambio de claves.

•

La lista de los algoritmos de compresión ofrecidos, por orden de preferencia (como mínimo tiene que haber uno, aunque sea el algoritmo nulo). Algoritmos criptográficos previstos en SSL/TLS SSL TLS contempla los algoritmos criptográficos siguientes: •

Cifrado: RC4, DES, Triple DES, RC2, IDEA y FORTEZZA (este último sólo en SSL 3.0).

•

MAC: MD5 y SHA-1.

•

Intercambio de claves: RSA, Diffie-Hellman y FORTEZZA KEA (este último sólo en SSL 3.0).

Si sólo interesa autenticar la conexión, sin confidencialidad, también se puede usar el algoritmo de cifrado nulo.

3)�Saludo�de�servidor�(Server�Hello). Como respuesta, el servidor envía un mensaje Server Hello, que contiene esta información: •

La versión del protocolo que se utilizará en la conexión. La versión será igual a la que envió el cliente, o inferior si ésta no es soportada por el servidor.

•

Otra cadena de 32 bytes aleatorios.

•

El identificador de la sesión actual. Si el cliente envió uno y el servidor quiere reanudar la sesión correspondiente, tiene que responder con el mismo identificador. Si el servidor no quiere reanudar la sesión (o no puede porque ya no guarda la información necesaria), el identificador enviado será diferente. Opcionalmente, el servidor puede no enviar ningún identificador para indicar que la sesión actual ya no podrá ser reanudada.

•

La combinación de algoritmos criptográficos escogida por el servidor en la lista de las enviadas por el cliente. Si se reanuda una sesión anterior, esta combinación tiene que ser la misma que se utilizó entonces. El algoritmo de compresión escogido por el servidor, o el que se utilizó en la sesión que se reanuda.

Si se ha decidido continuar una sesión anterior, cliente y servidor ya pueden empezar a utilizar los algoritmos y claves previamente acordados y se saltan los mensajes que vienen a continuación, pasando directamente a los de finalización de la negociación (mensajes finished). 4)�Certificado�de�servidor�(certificate)�o�intercambio�de�claves�de�servidor (server�key�exchange). Si el servidor puede autenticarse delante del cliente, que es el caso más habitual, envía el mensaje certificate. Este mensaje normalmente

Algoritmos de compresión El único algoritmo de compresión previsto en SSL TLS es el algoritmo nulo, es decir, ninguna compresión.

© FUOC • PID_00147721

55

contendrá el certificado X.509 del servidor, o una cadena de certificados. Si el servidor no tiene certificado, o se ha acordado un método de intercambio de claves que no utiliza, tiene que enviar un mensaje server key exchange, que contiene los parámetros necesarios para el método a seguir. 5)�Petición�de�certificado�(certificate�request) •

Tipo de certificados: En SSL TLS están contemplados los certificados de clave pública RSA, DSA o FORTEZZA KEA (este último tipo sólo en SSL 3.0). En el caso de que se tenga que realizar también la autenticación del cliente, el servidor le envía un mensaje Certificate Request. Este mensaje contiene una lista de los posibles tipos de certificado que el servidor puede admitir, por orden de preferencia, y una lista de los DN de las autoridades de certificación que el servidor reconoce.

6)�Fin�de�saludo�de�servidor�(Server�Hello�Done). Para acabar esta primera fase del diálogo, el servidor envía un mensaje Server Hello Done. 7)�Certificado�de�cliente�(Certificate) •

Cliente sin certificado: Si el cliente recibe una petición de certificado pero no tiene ninguno apropiado, en SSL 3.0 tiene que enviar un mensaje de aviso, pero en TLS 1.0 tiene que enviar un mensaje Certificate vacío. En cualquier caso, el servidor puede responder con un error fatal, o bien continuar sin autenticar al cliente. Una vez el servidor ha enviado sus mensajes iniciales, el cliente ya sabe cómo continuar el protocolo de negociación. En primer lugar, si el servidor le ha pedido un certificado y el cliente tiene alguno de las características solicitadas, lo envía en un mensaje Certificate.

8)�Intercambio�de�claves�de�cliente�(Client�Key�Exchange). El cliente envía un mensaje Client Key Exchange, cuyo contenido depende del método de intercambio de claves acordado. En el caso de seguir el método RSA, en este mensaje hay una cadena de 48 bytes que se utilizará como secreto�pre-maestro, cifrada con la clave pública del servidor. Un posible ataque contra la negociación es modificar los mensajes para que las dos partes acuerden utilizar el protocolo SSL 2.0, que es más vulnerable. Para evitar este ataque, en los dos primeros bytes del secreto pre-maestro tiene que estar el número de versión que se envió en el mensaje Client Hello. Entonces, cliente y servidor calculan el llamado secreto�maestro, que es otra cadena de 48 bytes. Para hacer este cálculo, se aplican funciones hash al secreto premaestro y a las cadenas aleatorias que se enviaron en los mensajes de saludo. A partir del secreto maestro y las cadenas aleatorias, se obtienen: •

Las dos claves para el cifrado simétrico de los datos (una para cada sentido: de cliente a servidor y de servidor a cliente).

Seguridad en la red

© FUOC • PID_00147721

56

•

Las dos claves MAC (también una para cada sentido).

•

Los dos vectores de inicialización para el cifrado, si se utiliza un algoritmo de bloque.

9)�Verificación�de�certificado�(Certificate�Verify). Si el cliente ha enviado un certificado en respuesta a un mensaje Certificate Request, ya puede autenticarse demostrando que posee la clave privada correspondiente mediante un mensaje Certificate Verify. Este mensaje contiene una firma, generada con la clave privada del cliente, de una cadena de bytes obtenida a partir de la concatenación de todos los mensajes de negociación intercambiados hasta ahora, desde el Client Hello hasta el Client Key Exchange. 10)�Finalización�(Finished). A partir de este punto ya se pueden utilizar los algoritmos criptográficos negociados. Cada parte envía a la otra una notificación de cambio de cifrado seguida de un mensaje Finished. La notificación de cambio de cifrado sirve para indicar que el siguiente mensaje será el primero enviado con los nuevos algoritmos y clavos. El mensaje Finished sigue inmediatamente a la notificación de cambio de cifrado. Su contenido se obtiene aplicando funciones hash al secreto maestro y a la concatenación de todos los mensajes de negociación intercambiados, desde el Client Hello hasta el anterior a éste (incluido el mensaje Finished de la otra parte, si ya lo ha enviado). Normalmente será el cliente el primero en enviar el mensaje Finished, pero en el caso de reanudar una sesión anterior, será el servidor quien lo envíe primero, justo después del Server Hello. Una de las principales diferencias entre SSL 3.0 y TLS 1.0 está en la técnica usada para obtener los códigos de verificación de los mensajes Finished, y también para calcular el secreto maestro y obtener las claves a partir de este secreto (en SSL se utilizan funciones hash directamente, y en TLS se utilizan códigos HMAC). El contenido del mensaje Finished sirve para verificar que la negociación se ha llevado a cabo correctamente. Este mensaje también permite autenticar al servidor delante del cliente, ya que el primero necesita su clave privada para descifrar el mensaje Client Key Exchange y obtener las claves que se utilizarán en la comunicación. Una vez enviado el mensaje Finished, se da por acabada la negociación, y cliente y servidor pueden empezar a enviar los datos de aplicación utilizando los algoritmos y claves acordados. Los siguientes diagramas resumen los mensajes intercambiados durante la fase de negociación SSL TLS.

Seguridad en la red

© FUOC • PID_00147721

Negociación de una sesión SSL/TLS nueva

Negociación de una sesión SSL/TLS que se reanuda

57

Seguridad en la red

© FUOC • PID_00147721

58

Además de los mensajes de negociación, notificaciones de cambio de cifrado y datos de aplicación, también se pueden enviar mensajes de error. Estos mensajes contienen un código de nivel de gravedad, que puede ser "mensaje de aviso" o " error fatal", y un código de descripción del error. Un error fatal provoca el fin de la conexión y la invalidación del identificador de sesión correspondiente, es decir, la sesión no podrá ser reanudada.

Seguridad en la red

Ejemplos de errores fatales Son ejemplos de errores fatales: MAC incorrecto, tipo de mensaje inesperado, error de negociación, etc. (TLS 1.0 prevé más códigos de error que SSL 3.0).

También se puede enviar un mensaje de aviso para indicar el fin normal de la conexión. Para evitar ataques de truncamiento, si una conexión acaba sin haber enviado este aviso se invalidará su identificador de sesión. 5.5. Transacciones seguras en red Conviene conocer también diferentes iniciativas para permitir las transacciones seguras en internet. Presentamos las más importantes. 5.5.1. Secure Electronic Transaction A raíz de las faltas del protocolo SSL, diferentes empresas y organismos buscaron un sistema que permitiera realizar operaciones sensibles por Internet de forma segura, como los pagos, con el fin de estimular la confianza de los consumidores en el comercio electrónico. En 1996 un grupo de empresas del sector financiero, informático y de seguridad (Visa International, MasterCard, Microsoft, Nestcape, IBM, RSA, etc.) anunció el desarrollo de esta nueva tecnología. Secure Electronic Transaction19 (SET) es un protocolo que permite dar seguridad en las transacciones por Internet que utilizan tarjetas de crédito. Sus especificaciones se pueden encontrar en el sitio web oficial de SETco, organismo encargado de homologar los módulos de programación y los certificados desarrollados por empresas privadas que se usan en implementaciones del protocolo SET. Su funcionamiento se basa en el uso de certificados digitales y sistemas criptográficos. Los primeros, para asegurar la perfecta identificación de todas aquellas parejas que intervienen en una transacción en línea basada en el uso de tarjetas de pago, y los segundos, para proteger el envío de los datos sensibles en su viaje entre los diferentes servidores que participan en el proceso. Una de sus características es la de separar el proceso de compra del de pago. Como inconvenientes de la SET mencionaremos su complejidad y lentitud. Normalmente, con SSL no se necesita certificado ni software adicional, sólo seleccionar los productos que hay que comprar y aceptar el pago. La lentitud de la SET se debe a que se han de realizar diferentes verificaciones de identidad e integridad por parte de diversas entidades a lo largo de una transacción.

(19)

En castellano, transacciones electrónicas seguras.

Dirección web recomendada Podéis acceder al histórico de la página web de SETco en: http://web.archive.org/web/ */www.setco.org

© FUOC • PID_00147721

59

5.5.2. 3D-Secure 3D-Secure es un sistema promovido por Visa/Mastercard con la finalidad de incentivar el comercio electrónico, que intenta evitar los fraudes cuando el pago se realiza con tarjetas de crédito. Está basado en el modelo de los "tres dominios", en el cual se requiere: 1) Que la entidad emisora de la tarjeta autentique al cliente o titular de la tarjeta (comprador): dominio del emisor. 2) Que la entidad adquirente autentique al comercio (vendedor): dominio del adquirente. 3) Que ambas partes (entidad emisora y entidad adquirente) sean reconocidas mutuamente como legítimas para efectuar la transacción, y que ésta se complete de forma segura: dominio de intercambio. En este modelo se deja al arbitrio de cada una de las entidades la elección del "procedimiento de autenticación". De esta manera, tienen flexibilidad para seleccionar el método de autenticación más apropiado para sus comercios y titulares, y sustituirlo por nuevas soluciones cuando lo consideren conveniente. La confidencialidad e integridad de la información de pago se consigue con la utilización del protocolo SSL. El proceso de compra con 3D Secure funciona como una compra normal en un comercio en línea, con la particularidad de que, a la hora de introducir la información de pago, el comprador tendrá que facilitar la contraseña 3D-Secure-Secure. De esta manera, se confirma que es el propio titular de la tarjeta, y no un tercero sin autorización, quien efectúa la transacción.

Seguridad en la red

© FUOC • PID_00147721

60

Resumen

El módulo ha hecho una introducción a los conceptos básicos de la seguridad en las redes de comunicación. Los cortafuegos se han presentado como medidas pasivas de seguridad en los sistemas en red. Hemos visto que un cortafuegos puede ser tanto hardware como software y que incluso se pueden combinar diferentes sistemas para asegurar una red. Se ha presentado el concepto de red privada virtual (VPN), que no es más que una red lógica o virtual creada sobre una infraestructura compartida, pero que proporciona los servicios de protección necesarios para una comunicación segura. Las redes� privadas� virtuales (VPN) permiten utilizar la red pública Internet como si fuera una red privada dedicada, por ejemplo, entre diversas intranets de una misma organización. La técnica básica que utilizan las VPN son los túneles, en los que los paquetes protegidos se encapsulan dentro de datagramas IP que circulan de manera normal por la red Internet. En este módulo también hemos visto que las técnicas�criptográficas permiten cifrar un texto mediante una clave�de�cifrado, y que basta con conocer la clave�de�descifrado correspondiente para ser capaz de obtener el texto original. Según la relación que haya entre las dos claves, los algoritmos criptográficos se clasifican en algoritmos�simétricos si la clave de cifrado y la de descifrado son la misma, y algoritmos�de�clave�pública si las claves son diferentes. Los algoritmos simétricos, a su vez, se pueden clasificar en algoritmos�de�flujo, si el cifrado consiste en añadir al texto datos pseudoaleatorios calculados a partir de la clave, o algoritmos�de�bloque,�si�el�cifrado�se�hace�sobre�bloques�de tamaño�fijo�del�texto�original. La particularidad de la criptografía de clave pública es que, a partir de una de las claves, la clave�privada, se puede deducir fácilmente la otra, la clave�pública, mientras que la deducción inversa es prácticamente imposible. Eso permite que todo el mundo que conozca la clave pública de un usuario pueda utilizarla para cifrar datos confidenciales, con la seguridad que sólo quien tenga la clave privada podrá descifrarlos, sin necesidad de acordar ninguna clave secreta a través de un canal aparte. El uso de las claves al revés (la privada para cifrar y la pública para descifrar) es la base de las firmas�digitales. Como la criptografía de clave pública es computacionalmente más costosa que la simétrica, no se utiliza nunca directamente para obtener confidencialidad, sino siempre a través de una clave de sesión simétrica. De la misma manera, la

Seguridad en la red

© FUOC • PID_00147721

61

firma de un texto no se calcula directamente a partir del texto, sino aplicando una función hash segura. La propiedad de este tipo de función es que es muy difícil encontrar un mensaje que dé el mismo hash que otro. Después de esta aproximación más teórica y para concluir el módulo se han presentado diferentes conceptos de seguridad de la red en los niveles de aplicación y transporte. Hemos profundizado en el conocimiento de un protocolo, el SSL/TLS, de la capa de transporte que sirve para dotar de seguridad a las comunicaciones de las aplicaciones en red. El uso típico de los protocolos SSL TLS es para proteger de manera transparente un protocolo de aplicación como es HTTP. El protocolo HTTPS es simplemente la combinación de HTTP con el transporte seguro SSL/TLS.

Seguridad en la red

© FUOC • PID_00147721

63

Bibliografía Menezes, A. J.; Oorschot, P. C. van; Vanstone, S. A. (1996). Handbook of Applied Cryptography. Boca Ratón: CRC Press. SETco. Disponible en web. . [Fecha de consulta: 12 de abril del 2010.] Stallings, W. (2003). Cryptography and Network Security, Principles and Practice (3.ª ed.). Upper Saddle River: Prentice-Hall. Yuan, R.; Strayer, W. T. (2001). Virtual Private Networks, Technologies and Solutions. Boston: Addison-Wesley.

Seguridad en la red

El nivel de aplicación Joan Manuel Marqués Puig Silvia Llorente Viejo PID_00147724

© FUOC • PID_00147724


El nivel de aplicación


© FUOC • PID_00147724

Índice

Introducción...............................................................................................

7

Objetivos.......................................................................................................

8

1.

9

Arquitecturas de aplicaciones distribuidas................................ 1.1.

Cliente-servidor (client/server en inglés) ......................................

10

1.1.1.

Aplicaciones basadas en la web .....................................

12

De igual a igual (peer-to-peer, en inglés) ......................................

13

1.2.1.

Aplicaciones de igual a igual .........................................

15

1.3.

Ventajas y desventajas de cliente-servidor y de igual a igual ......

16

1.4.

Requerimientos de las aplicaciones ............................................

17

DNS: Servicio de nombres en Internet.........................................

19

2.1.

DNS: base de datos jerárquica y distribuida ...............................

21

2.2.

Caching de DNS ...........................................................................

23

2.3.

Peticiones recursivas frente a peticiones iterativas .....................

24

2.4.

Registros DNS ..............................................................................

25

2.5.

Consideraciones de seguridad .....................................................

26

La web y el HTTP..............................................................................

27

3.1.

HTTP: Hypertext Transfer Protocol..................................................

28

3.1.1.

Conexiones persistentes y no persistentes ....................

29

Formato de los mensajes HTTP ..................................................

30

3.2.1.

Mensaje HTTP de petición ............................................

30

3.2.2.

Mensaje HTTP de respuesta ...........................................

31

3.3.

HTTPS (HTTP seguro) ..................................................................

33

3.4.

Cookies ........................................................................................

34

3.5.

Características de la demanda de páginas web ...........................

35

3.6.

Servidores intermediarios ............................................................

37

3.7.

El GET condicional .....................................................................

38

3.8.

Distribución de contenidos .........................................................

39

3.8.1.

Redes de distribución de contenidos .............................

41

Transferencia de ficheros................................................................

43

4.1.

Seguridad en la transferencia de ficheros ...................................

44

Correo electrónico en Internet.......................................................

45

5.1.

SMTP ............................................................................................

46

5.2.

Formato de los mensajes ............................................................

47

5.2.1.

Formato de mensajes MIME ..........................................

48

Protocolos para acceder a los buzones de correo ........................

50

1.2.

2.

3.

3.2.

4.

5.

5.3.


© FUOC • PID_00147724

6.

5.3.1.

POP3 ...............................................................................

51

5.3.2.

IMAP ...............................................................................

52

5.3.3.

Web ................................................................................

53

Aplicaciones de igual a igual para la compartición de ficheros..................................................................................................

54

6.1.

Redes superpuestas no estructuradas ..........................................

54

6.2.

Redes superpuestas estructuradas ................................................

57

Mensajería instantánea....................................................................

60

7.1.

XMPP ...........................................................................................

60

Telnet y Secure Shell: acceso a ordenadores remotos...............

63

8.1.

Seguridad del protocolo Telnet ...................................................

63

8.2.

Secure Shell .................................................................................

64

Aplicaciones multimedia en red....................................................

65

9.1.

Ejemplos de aplicaciones multimedia ........................................

65

9.1.1.

Streaming de audio y vídeo almacenados ......................

66

Streaming en directo de audio y vídeo ........................................

66

9.2.1.

Audio y vídeo en tiempo real interactivo .....................

67

Multimedia en Internet ..............................................................

67

9.3.1.

Compresión de audio y vídeo .......................................

69

9.3.2.

Formatos de audio y vídeo ............................................

71

10. Streaming de audio y vídeo almacenados...................................

74

10.1. Acceso vía servidor de web .........................................................

75

10.2. Real Time Streaming Protocol (RTSP) .............................................

76

10.2.1. Los estados del RTSP .....................................................

78

10.2.2. Diagrama de estados del cliente ....................................

78

10.2.3. Diagrama de estados del servidor ..................................

79

10.2.4. Métodos RTSP ................................................................

80

10.2.5. El protocolo RTSP ..........................................................

80

10.2.6. El mensaje de petición RTSP .........................................

81

10.2.7. El mensaje de respuesta RTSP ........................................

82

10.2.8. Ejemplo de uso del protocolo RTSP ..............................

83

11. Protocolos para aplicaciones interactivas en tiempo real......

86

11.1. Real Time Transport Protocol (RTP) ...............................................

86

11.1.1. Descripción del RTP .......................................................

86

7.

8.

9.

9.2. 9.3.

11.1.2. La cabecera del RTP .......................................................

87

11.2. Real Time Control Protocol (RTCP) ...............................................

88

11.2.1. Los paquetes RTCP ........................................................

89

11.2.2. Uso del ancho de banda en el protocolo RTCP .............

90

11.3. Session Initiation Protocol (SIP) .....................................................

91

11.3.1. Funcionalidad del SIP ....................................................

91

11.3.2. El protocolo SIP .............................................................

96


© FUOC • PID_00147724

11.3.3. El mensaje de petición SIP ............................................

97

11.3.4. El mensaje de respuesta SIP ...........................................

98

11.4. H.323 ...........................................................................................

99

11.5. Skype ............................................................................................

101

12. Anexos...................................................................................................

103

12.1. Anexo 1. El protocolo RTSP ........................................................

103

12.1.1. Órdenes ..........................................................................

103

12.1.2. Códigos de estado ..........................................................

103

12.1.3. Cabeceras .......................................................................

104

12.2. Anexo 2. El formato de los paquetes RTCP ................................

105

12.2.1. Informe de emisor (SR) ..................................................

105

12.2.2. Informe de receptor (RR) ...............................................

107

12.2.3. Descripción de elementos de la fuente (SDES) ..............

108

12.2.4. Paquete de cierre (BYE) .................................................

109

12.2.5. Paquete definido por la aplicación (APP) ......................

109

12.3. Anexo 3. El protocolo SIP ...........................................................

110

12.3.1. Códigos de estado ..........................................................

110

12.3.2. Cabeceras .......................................................................

112

Resumen.......................................................................................................

114

Bibliografía.................................................................................................

115

© FUOC • PID_00147724

7

Introducción

En este módulo didáctico, se describe toda una serie de aplicaciones que utilizan Internet como medio de comunicación y también los protocolos de comunicaciones que tienen asociados. Estas aplicaciones se conocen como aplicaciones distribuidas, ya que están formadas por diferentes partes y cada una se encuentra en máquinas diferentes. Normalmente, hay una parte denominada servidor que se ejecuta en un ordenador, a la cual se conectan los diferentes clientes (que se encuentran en otros ordenadores remotos) con el fin de pedir los servicios (generalmente, solicitan la ejecución de algún tipo de operación). En este módulo, veremos en primer lugar algunos conceptos básicos referentes a las aplicaciones distribuidas, y después, una serie de aplicaciones distribuidas en Internet, cuyas características siguientes estudiaremos. •

El�modelo: describimos los diferentes elementos que forman la aplicación y sus características.

•

El�protocolo: exponemos las ideas principales del protocolo de comunicaciones de cada aplicación.

•

El�modelo�de�información: describimos el formato de información de los protocolos que tienen uno concreto.

•

La� funcionalidad: explicamos la funcionalidad y los comandos que la proporcionan.

Incluimos ejemplos breves del intercambio de comandos para facilitar su comprensión.


© FUOC • PID_00147724

8

Objetivos

En este módulo didáctico, encontraréis las herramientas necesarias para alcanzar los objetivos siguientes:

1. Comprender el modelo cliente-servidor y el modelo peer-to-peer, que sirven como base de la implementación de aplicaciones distribuidas. 2. Conocer las aplicaciones distribuidas más utilizadas en Internet y entender los principios básicos de funcionamiento de los protocolos de comunicación que estas usan.


© FUOC • PID_00147724

9

1. Arquitecturas de aplicaciones distribuidas

Hay muchas definiciones de aplicaciones distribuidas. Aquí os ponemos una que creemos que encaja muy bien con el enfoque de este módulo:

Una aplicación distribuida está formada por una colección de ordenadores autónomos enlazados por una red de ordenadores y soportados por un software que hace que la colección actúe como un servicio integrado.

Una arquitectura de software determina cómo se identifican y se asignan los componentes del sistema; cómo interactúan los componentes para formar el sistema; la cantidad y la granularidad de la comunicación que se necesita para la interacción, y los protocolos de la interfaz usada por la comunicación. La arquitectura que hay que utilizar en cada caso depende de muchos factores. Ahora mencionaremos las características más significativas que hay que considerar cuando se diseña una aplicación a escala Internet. La primera característica es la gran�cantidad�tanto�de�ordenadores�como�de usuarios que hay en Internet. Relacionado con esto, está la dispersión geográfica de los mismos. La dispersión�geográfica afecta a la manera en la que los componentes del grupo perciben las acciones que pasan a la aplicación. Por ejemplo, los usuarios de la aplicación pueden percibir dos acciones que pasan en dos extremos opuestos del mundo en diferente orden, según la proximidad de cada componente al componente generador de la acción. Según la aplicación, necesitaremos o no mecanismos para abordar estas situaciones. Una tercera característica es la�autonomía de los diferentes ordenadores que forman la aplicación. Es muy habitual que diferentes partes de una aplicación estén bajo dominios administrados por diferentes administradores. Relacionada con esta característica está la seguridad. Cada organización tiene unas políticas de seguridad diferentes, como por ejemplo cortafuegos. Es preciso que las aplicaciones distribuidas que diseñamos se puedan ejecutar teniendo en cuenta estas restricciones impuestas por los diferentes administradores. Una cuarta característica es la calidad�de�servicio. En una aplicación distribuida a escala Internet, este es un aspecto fundamental que vendrá muy condicionado por la latencia de la red, los cortes y otros fenómenos que le puedan afectar.


10

© FUOC • PID_00147724


Finalmente, están los aspectos relacionados con la movilidad: dispositivos que se conectan y desconectan; acceso desde diferentes ubicaciones; trabajo en modo desconectado; calidad de acceso menor (ancho de banda, fiabilidad, etc.). Este último aspecto, sin embargo, mejorará mucho a medida que estos servicios se generalicen. En este módulo, trataremos las dos arquitecturas distribuidas más utilizadas 1

hoy día: cliente-servidor y de igual a igual . Hay otras arquitecturas distribuidas como el grid, la publicación-suscripción o el código móvil, entre otras, que no trataremos en este material. 1.1. Cliente-servidor (client/server en inglés)

En el modelo cliente-servidor hay dos tipos de componentes. •

Clientes: hacen peticiones de servicio. Normalmente, los clientes inician la comunicación con el servidor.

•

Servidores: proveen servicios. Normalmente, los servidores esperan recibir peticiones. Una vez han recibido una petición, la resuelven y devuelven el resultado al cliente.

Esta idea se puede aplicar de manera muy variada a muchos tipos diferentes de aplicaciones. Un ejemplo que ayudará a entenderlo es la web. El navegador es el cliente y los ordenadores a los cuales nos conectamos y de los que obtenemos las páginas son los servidores. Los servidores pueden ser con estado o sin estado. Un servidor sin estado no mantiene ninguna información entre peticiones. Un servidor con estado puede recordar información entre peticiones. El alcance de esta información puede ser global o específico de una sesión. Un servidor web con páginas web

(1)

De igual a igual en inglés se denomina peer-to-peer o p2p.

© FUOC • PID_00147724

11

estáticas es un ejemplo de servidor sin estado, mientras que un servidor que genere las páginas de manera dinámica (como la Intrauoc del Campus Virtual de la UOC) es un ejemplo de servidor con estado. Un servidor también puede ser cliente de otros servidores, tal y como se ve en la figura siguiente. Por ejemplo, una aplicación de correo vía web actúa como servidor para el navegador y como cliente del servidor de correo que gestiona los mensajes del usuario en cuestión. Los servidores web y los otros servicios disponibles en Internet son clientes del servicio de resolución de nombres (DNS). Un tercer ejemplo son los buscadores (search engines), que permiten a los usuarios acceder a sumarios de información de páginas web extendidas por muchos sitios web de toda Internet. Un buscador es al mismo tiempo servidor y cliente: responde a peticiones provenientes de los navegadores clientes y ejecuta programas que, actuando como clientes (robots web; en inglés, web crawlers), acceden a servidores de Internet buscando información. De hecho, un buscador incluirá diferentes hilos de ejecución, algunos sirviendo al cliente y otros ejecutando robots web.

Los servicios también se pueden implementar como diferentes procesos servidores que se ejecutan en diferentes ordenadores y que interactúan para proporcionar un servicio a procesos clientes siguientes. Los servidores se pueden repartir los diferentes objetos que componen el servicio que proporcionan o pueden mantener réplicas de los objetos en distintos ordenadores. Ejemplo de partición de datos La web proporciona un ejemplo habitual de partición de los datos, en el que cada servidor gestiona su conjunto de recursos. Un usuario utiliza un navegador para acceder a un recurso situado en cualquiera de los servidores. La reproducción se usa para incrementar el rendimiento y la disponibilidad y para mejorar la tolerancia a fallos. Proporciona múltiples copias consistentes de los datos en procesos que se ejecutan en diferentes ordenadores. Por ejemplo, la web proporcionada en


© FUOC • PID_00147724

12

www.google.com (o www.uoc.edu) está registrada en diferentes servidores que tienen datos reproducidos.

1.1.1. Aplicaciones basadas en la web Un caso particular de aplicaciones cliente-servidor son las aplicaciones que se ejecutan aprovechando la arquitectura de la web. Estas aplicaciones se basan en el hecho de tener toda la capacidad de procesamiento en un servidor web (o conjunto de servidores) al que se accede desde un navegador web. Cuando el usuario hace clic sobre un enlace de la página web que tiene en su navegador, se genera una petición en el servidor que contiene la información. El servidor, al recibir la petición, retorna la página pedida si la petición era a una página, o retorna el resultado de ejecutar una aplicación si el enlace correspondía a un código para ejecutar (por ejemplo, CGI o Servlet). El navegador web proporciona a la aplicación un entorno donde presentar la información. La comunicación entre cliente y servidor se hace utilizando el protocolo HTTP. El resultado que retorna el servidor al cliente se envía en formato HTML, de manera que para el cliente web es totalmente transparente si accede a una página web o a una aplicación que genera un resultado formateado en HTML. Las aplicaciones basadas en la web tienen la ventaja de que son accesibles desde cualquier ordenador que disponga de un navegador (la práctica totalidad de los ordenadores conectados hoy día a Internet), sin que sea preciso tener nada más instalado en el ordenador local. El uso de estas arquitecturas también facilita el diseño de las aplicaciones, ya que no hay que implementar la comunicación entre el cliente y el servidor (se utiliza el protocolo HTTP); y la parte de presentación de la aplicación se facilita mucho por el hecho de formatear el documento en HTML y aprovechar las funcionalidades que proporciona el navegador (como los intérpretes de Javascript y Java).


© FUOC • PID_00147724

13

La facilidad y universalidad en el acceso a las aplicaciones que proporciona esta arquitectura es la base de los servicios ofrecidos en Internet. Algunos ejemplos son el Campus Virtual de la UOC; los servidores de correo web tipo Yahoo o Google, y los bancos por Internet.

1.2. De igual a igual (peer-to-peer, en inglés)

De una manera muy genérica, podemos decir que un sistema de igual a igual se caracteriza por ser un sistema distribuido, en el que todos los nodos tienen las mismas capacidades y responsabilidades, y en el que toda la comunicación es simétrica.

En Internet, desde sus orígenes, ha habido sistemas y aplicaciones que se han comportado siguiendo la filosofía de igual a igual. Estos sistemas se han caracterizado por el hecho de ser totalmente descentralizados, de gran escala y con capacidad para autoorganizarse. El ejemplo paradigmático son los mensajes Usenet. Los mensajes Usenet Los mensajes Usenet (Usenet News en inglés) son un sistema global y descentralizado de grupos de discusión en Internet. Los usuarios leen y ponen mensajes que parecen correos electrónicos (se les denomina artículos) en un número determinado de grupos de noticias, que están organizados formando jerarquías lógicas de temas (por ejemplo, informática.linux.distribuciones o informática.lenguajesProgramación.tutoriales). Los mensajes se distribuyen entre un gran número de servidores, que almacenan y se reenvían mensajes unos a otros. Los usuarios se bajan los mensajes y ponen otros nuevos en uno de los servidores. El intercambio de mensajes entre los servidores hace que, a la larga, los mensajes lleguen a todos los servidores.

Sin embargo, el fenómeno de igual a igual empieza como tal a finales de los noventa, de la mano de Napster. En la época de la explosión de Internet –a partir de 1994–, la vertiente de colaboración que había dominado Internet hasta aquel momento empezó a perder protagonismo frente a la vertiente más comercial, que imponía la arquitectura cliente-servidor, liderada por la web como arquitectura estrella. Dentro de este contexto dominado por la centralización de la arquitectura cliente-servidor, los usuarios de Napster descubrieron que el efecto agregado de que cada individuo pusiera canciones al servicio de una comunidad era que los participantes de la comunidad encontraban con facilidad las canciones que les interesaban.


© FUOC • PID_00147724

14

El funcionamiento de Naspter era muy sencillo. Usaba un servidor (o índice) para proporcionar un servicio de directorio. Cuando un usuario arrancaba un nodo de Naster, este se conectaba al servidor y publicaba la lista de canciones que el nodo local hacía pública. De esta manera, el servicio de directorio sabía, para cada igual, qué objetos tenía disponibles para compartir. Cuando alguien buscaba una canción, hacía una petición de la canción al servidor, y este le contestaba la lista de nodos que tenían un título similar. El usuario elegía uno y se bajaba la canción directamente de este nodo.

Los grandes cambios que aporta Napster, tanto desde el punto de vista de la arquitectura como del funcionamiento del sistema, con respecto a las soluciones centralizadas (cliente-servidor) que predominaban en aquel momento son: •

Los ficheros que hay disponibles son los que los usuarios, de manera individual, deciden aportar al sistema (autonomía de los usuarios).

•

La disponibilidad de un fichero depende de si los usuarios que lo tienen están conectados al sistema (conectividad puntual o ad hoc en inglés).

•

Hay muchos usuarios que proporcionan un mismo fichero (tolerancia a fallos).

•

Los recursos necesarios para almacenar los ficheros los aportan los mismos usuarios (coste del sistema).

•

El sistema evoluciona y se adapta a medida que los usuarios se conectan o desconectan (autoorganización).


© FUOC • PID_00147724

•

15


El sistema soporta a muchos usuarios (escalabilidad). De hecho, llegó a haber millones de usuarios conectados a Napster.

•

Al haber muchas reproducciones de una canción, la carga está repartida (mejora de rendimiento).

Aunque hubiera un servidor o índice, se considera que Napster era un sistema de igual a igual, porque los ficheros se encontraban en los ordenadores de los usuarios y la bajada se hacía directamente entre el ordenador que buscaba la canción y el que la ofrecía. Esta manera de organizar grandes cantidades de información a escala Internet para facilitar la compartición resultó muy eficaz. La prueba de esto la encontramos tanto en el hecho de que el sistema llegó a tener millones de usuarios, como en el hecho de que muchas empresas discográficas lo vieron como una amenaza. Precisamente, el motivo de que Napster dejara de funcionar fue que denunciaron a los propietarios del servicio de directorio por infringir las leyes del copyright. El caso Napster acabó con una sentencia judicial que forzó el cierre del servidor índice. A raíz del éxito de la solución, mucha gente se animó a hacer propuestas más descentralizadas y que superasen las limitaciones de Napster. Gnutella es un ejemplo de esto: se basa en un algoritmo de inundación para localizar el fichero que se busca y, de esta manera, elimina el punto único de fallo que supone tener un servicio centralizado de directorio. Una vez localizado el fichero, la bajada se hace directamente entre quien quiere el fichero y quien lo proporciona. Esta solución tiene el inconveniente de que no es determinista. 1.2.1. Aplicaciones de igual a igual Los sistemas y las aplicaciones de igual a igual se han hecho populares de la

Determinismo Por determinismo entendemos que diferentes ejecuciones de una misma operación den el mismo resultado. Sistemas como el de tipo Gnutella no son deterministas. El algoritmo que utilizan para localizar ficheros dentro del sistema no garantiza que si un fichero está en alguno de los iguales lo encuentre. Puede que, según el camino que haya seguido la consulta, nos diga que no lo ha encontrado, cuando sí que está.

mano de las aplicaciones de compartición de ficheros, pero hay otros tipos de aplicaciones. Skype es otro sistema tipo de igual a igual que es muy popular. Skype proporciona telefonía en Internet. Utiliza un protocolo propietario de la implementación del que se conocen pocas cosas. Funciona siguiendo una organización con superiguales tal y como lo hace KaZaA. De hecho, Skype fue fundada por los fundadores de KaZaA. Un aspecto que hay que destacar es que consigue superar los problemas que tienen los iguales cuando están detrás de un cortafuego o los problemas derivados del NAT (network address translation).

Ved también Las aplicaciones de igual a igual para la compartición de ficheros como KazaA están explicadas en el apartado "Aplicaciones de igual a igual para la compartición de ficheros" de este módulo didáctico.

16

© FUOC • PID_00147724


También hay otros sistemas de igual a igual para la comunicación síncrona (como la mensajería instantánea), juegos, sistemas de procesamiento distribuido (como SETI@home) o software para la colaboración (como Groove). SETI@home SETI@home es un proyecto que tiene como objetivo detectar vida inteligente fuera de la Tierra. Distribuye procesamiento entre muchos ordenadores personales que están suscritos al proyecto y analiza datos de radiotelescopios, aprovechando las grandes cantidades de tiempo de procesamiento que los PC desperdician porque no hacen nada.

Bibliografía complementaria Encontraréis más información sobre el funcionamiento interno de Skype en: S.�A.�Baset;�H.�Schulzrinne (2006, abril). "An analysis of the Skype peer-to-peer internet telephony protocol". Proceedings of IEEE INFOCOM 2006. Barcelona.

Groove Groove es un sistema de igual a igual para facilitar la colaboración y comunicación en grupos pequeños. Proporciona herramientas para la compartición de ficheros, la mensajería instantánea, el calendario, la gestión de proyectos, etc.

1.3. Ventajas y desventajas de cliente-servidor y de igual a igual Como se ha visto, cliente-servidor y de igual a igual son dos maneras de plantear el diseño de una aplicación. También se ha mencionado que hay otros paradigmas. Este esfuerzo de caracterización, sin embargo, no nos tiene que confundir. A la hora de la verdad, las aplicaciones no implementan nunca una arquitectura pura y muchas veces son híbridos entre diferentes modelos. Cada aplicación tiene sus necesidades y hay que utilizar las características que nos ofrece cada paradigma con el fin de construir una aplicación que satisfaga las necesidades de sus usuarios. La tabla siguiente pretende resumir las ventajas y desventajas tanto del cliente-servidor como del igual a igual. No pretende ser exhaustiva. Además, hablar de ventajas y desventajas es muy personal o dependerá de cada situación. Lo que para alguien o en una situación es una ventaja, para algún otro u otra situación es una desventaja. Y al revés pasa lo mismo.

Ventajas

Cliente-servidor • •

• • •

Datos en los servidores, lo que facilita el control de la • seguridad, control de acceso, consistencia de la información, etc. Hay muchas tecnologías maduras para los sistemas • cliente-servidor. Esto hace que haya soluciones muy probadas y que garantizan la seguridad, facilidad de uso y amigabilidad de la interfaz. Relativa facilidad para actualizar los elementos de un sistema cliente-servidor. • El desarrollo de aplicaciones centralizadas es más sencillo que el de las descentralizadas. Hay unos responsables de garantizar el servicio, que son los proveedores del servicio (o de cada una de las partes de estos).

Desventajas La centralización del modelo: punto único de fallo, dependencia de la autoridad administrativa que provee el servicio, vulnerabilidad a ataques. Escalabilidad condicionada a la capacidad de hacer crecer el servidor o conjunto de servidores que proporcionan el servicio. Relacionado con esto, es muy costoso construir un sistema que soporte cargas altas de contenidos pesados. Cuando hay muchos clientes que hacen peticiones, el servidor se puede congestionar. En entornos en los que la demanda puede ser muy variable o incierta, es necesario sobredimensionar el servicio para atender cargas que quizá sólo ocurren de manera esporádica o asumir que en ciertas situaciones puede haber congestión.

17

© FUOC • PID_00147724


Ventajas

De�igual�a�igual • • •

•

Descentralización: los diferentes miembros (iguales) del sistema son los propietarios y tienen el control de los datos y recursos de su ordenador. El coste de la propiedad (o la mayor parte de esta si es un sistema de igual a igual híbrido) está repartido entre los usuarios. Escalable: dado que las operaciones se hacen directamente entre los iguales, el sistema puede soportar más operaciones que si hubiera un nodo que centralizara las operaciones. Autoorganización: no hace falta que un componente del sistema supervise la evolución del sistema cuando cambia su escala (aumentan los usuarios o la carga); hay fallos, o los iguales se conectan o desconectan.

Desventajas • • • •

•

El comportamiento descentralizado es complejo de implementar. La responsabilidad del sistema está difundida entre los usuarios: si los usuarios no aportan recursos suficientes, el sistema no puede funcionar. Tecnología muy nueva. Aunque hay sistemas muy usados y que funcionan bien, las técnicas utilizadas todavía tienen que madurar. El dinamismo del sistema hace que el sistema sea utilizable sólo si su disponibilidad satisface las necesidades de los usuarios. En la mayor parte de los casos, esto pasa por la reproducción (tanto de información como de capacidad de procesamiento). Seguridad: a los problemas habituales de los sistemas distribuidos hay que añadir mecanismos para que la información que se aporte sea válida, que no haya usuarios que obtengan información sin aportarla, etc. Estos aspectos todavía no están bien resueltos.

1.4. Requerimientos de las aplicaciones Las aplicaciones dialogan utilizando un protocolo de transporte. En terminología de niveles, se dice que transporte ofrece unos servicios a aplicación, o dicho al revés, la aplicación requiere al nivel de transporte unas capacidades. En general, estas capacidades giran en torno a tres ejes. •

Transferencia fiable: algunas aplicaciones, como el correo electrónico o la transferencia de archivos, necesitan que la información que viaja llegue y llegue bien. La fiabilidad de la transferencia es entonces un requisito crucial. En cambio, hay aplicaciones que se basan en la transmisión de voz o imagen en tiempo real que no necesita esta fiabilidad, porque si se pierde uno o varios paquetes, la reproducción del sonido o la imagen original todavía es posible, aunque con defectos aceptables.

•

Ancho de banda: una transmisión de imagen en tiempo real necesita un ancho de banda concreto para que se pueda hacer de manera aceptable, pero el envío de un mensaje de correo electrónico se puede hacer con cualquier ancho de banda, por pequeño que sea.

•

Temporización: las aplicaciones que permiten comunicaciones en tiempo real, ya sea con sonido, imagen o los dos, necesitan que el ritmo de recepción de los paquetes sea constante, para que en recepción se pueda reproducir el sonido o la imagen original de manera continua, tal y como se captó en origen.

Por lo tanto, cada aplicación tiene unos requerimientos diferentes, y por esto en el nivel de transporte hay diferentes opciones para satisfacer estos requerimientos. Los protocolos originales de Internet (TCP y UDP) se concentraban en el primer requerimiento, porque las primeras aplicaciones que se especifi-

© FUOC • PID_00147724

18

caron no eran de tiempo real. A medida que se han desarrollado este tipo de aplicaciones, se han especificado nuevos protocolos de transporte que ofrecen los servicios adecuados.


© FUOC • PID_00147724

19


2. DNS: Servicio de nombres en Internet

Los ordenadores conectados a Internet están identificados de manera única por su dirección IP. Las direcciones IP son difíciles de recordar y por este motivo se utilizan nombres del estilo de www.uoc.edu o smtp.uoc.edu para identificar los diferentes recursos u ordenadores de Internet. El sistema de nombres de dominio2 es un servicio desplegado en Internet que permite hacer la tra-

(2)

En inglés, Domain Name System (DNS).

Formato de las direcciones IP Las direcciones IP tienen el aspecto siguiente: 213.73.40.99, donde cada punto separa un byte del 0 al 255 expresado en notación decimal.

ducción entre nombres y direcciones IP. El DNS3 es un servicio que recibe millones de peticiones y tiene que ser capaz de resolverlas de manera muy rápida. Para hacernos una idea del volumen de peticiones que debe ser capaz de gestionar el DNS, sólo es necesario que nos fijemos en dos de las aplicaciones más populares de Internet: la web y el correo electrónico. Cada vez que escribimos una dirección web en el navegador, este hace una consulta al DNS para saber a qué dirección IP corresponde. Y cada vez que enviamos un mensaje de correo electrónico, se hace una consulta al DNS para saber a qué servidor de correo hay que enviar el correo correspondiente al dominio de la dirección de correo electrónico. A continuación, podemos ver los pasos que se siguen para que el ordenador del usuario pueda enviar una petición de página web al URL www.uoc.edu/ eimt/index.html: 1) El ordenador del usuario es el que ejecuta la parte cliente de la aplicación DNS. 2) El navegador extrae el nombre del sitio web –www.uoc.edu en este caso– del URL y lo pasa a la parte cliente de la aplicación DNS. 3) El DNS cliente envía la petición (que contiene el nombre del sitio web) a un servidor DNS. 4) En algún momento futuro el cliente DNS recibirá la respuesta, que contiene la dirección IP correspondiente al sitio web. 5) Cuando el navegador recibe la dirección IP del DNS, puede iniciar la conexión TCP con el servidor HTTP ubicado en el puerto 80 de esta dirección IP. La figura siguiente muestra cómo el correo electrónico o el navegador interactúan con el DNS.

(3)

El DNS está especificado en los RFC 1.034 y PFC 1.035 y actualizado en otros RFC.

© FUOC • PID_00147724

20


Os habréis dado cuenta de que la pregunta al DNS introduce un retraso adicional –a veces sustancial– a la aplicación Internet que lo invoca. Afortunadamente, como veremos más adelante, la dirección IP está cacheada en algún DNS "cercano", lo que ayuda a reducir el tráfico DNS en la red, así como el retraso medio del DNS. Otros servicios importantes que proporciona el DNS, aparte de los ya vistos de traducción entre el nombre del ordenador y su dirección IP, son los siguientes. •

Alias: a veces interesa que un ordenador tenga más de un nombre. En este caso, tiene un nombre que se denomina canónico, que es el nombre del ordenador, y después tiene otros nombres que son sus alias. Estos alias normalmente son más sencillos de recordar. En este caso, se puede invocar el DNS para obtener el nombre canónico del ordenador, así como su dirección IP. En el caso de la UOC, www.uoc.edu es un alias del nombre canónico www-org.uoc.edu.

•

Alias�del�servidor�de�correo: es importante que las direcciones de correo electrónico sean fáciles de recordar. El nombre del servidor que gestiona el correo puede ser más complicado de recordar y puede haber más de un servidor que responda cuando se pide por un dominio determinado. De hecho, el campo MX permite que una institución o empresa tenga el mismo nombre (un alias) para el dominio de correo electrónico y para el servidor web. Por ejemplo, en la UOC tanto el servidor web como el dominio de correo electrónico se denominan uoc.edu.

•

Distribución�de�carga: el DNS se usa también para hacer distribución de carga entre servidores replicados, como servidores web. Sitios web muy accedidos pueden estar replicados en muchos servidores, cada uno corriendo en un ordenador diferente y con una dirección IP distinta. En este caso, una manera de repartir la carga entre los servidores es asociar un conjunto de direcciones IP a un nombre canónico. El DNS contiene este conjunto de direcciones. Cuando un cliente hace una consulta al DNS por un nombre al que le corresponde un conjunto de direcciones contesta todas las direcciones IP, pero en cada respuesta rota el orden de estas. Puesto que normalmente el servidor HTTP envía la petición a la primera dirección IP de la lista, se consigue una distribución de carga entre los servidores.

Ved también Para saber más sobre la distribución de contenidos, podéis ver el subapartado 3.8.

© FUOC • PID_00147724

21


Esta rotación también se utiliza en el correo electrónico, y de este modo muchos servidores de correo pueden tener el mismo nombre. Últimamente, compañías de distribución de contenidos como Akamai usan el DNS de maneras más sofisticadas para proporcionar distribución de contenidos web. Estas compañías utilizan el DNS para hacer que los usuarios se descarguen los contenidos de ubicaciones cercanas.

2.1. DNS: base de datos jerárquica y distribuida

El DNS es una base de datos jerárquica y distribuida organizada de manera autónoma, que proporciona un rendimiento a tiempo real a una audiencia global con contribuidores globales.

Un diseño sencillo para el DNS sería tener un servidor que contuviera todas las equivalencias entre nombres y direcciones IP. Los clientes enviarían las peticiones de resolución al servidor DNS y este las contestaría directamente. Esta solución centralizada sería sencilla de implementar, pero tendría numerosos inconvenientes por el hecho de que actualmente en Internet hay millones de servidores. Sería necesario que tuviera una base de datos muy grande capaz de soportar un volumen de consultas muy grande, además de ser capaz de gestionar una frecuencia alta de actualizaciones de las entradas, como nuevos hosts o cambios en los hosts. Con el fin de poder atender estos requerimientos de escala (número de entradas y número de peticiones), el DNS usa muchos servidores organizados de manera jerárquica y distribuidos por todo el mundo. Ningún servidor DNS tiene todas las equivalencias entre nombres y direcciones IP. Estas equivalencias están distribuidas en los diferentes servidores DNS. Hay tres tipos de servidores DNS. •

Servidores�DNS�raíz: hay trece servidores DNS raíz (etiquetados de la A

Dirección web recomendada

a la M). Cada uno de estos servidores raíz en realidad es un clúster de servidores reproducidos, por seguridad y fiabilidad. •

Servidores�DNS�de�nivel�de�dominio�superior4: son los responsables de

En http://www.rootservers.org/ podéis ver la ubicación de los servidores DNS raíz.

los dominios de primer nivel como org, com, net, edu o cat, así como de todos los dominios de países (us, es, etc.). •

Servidores�DNS�autorizados5: cada organización con ordenadores accesibles desde Internet tiene que proporcionar registros DNS accesibles públicamente que permitan hacer la equivalencia entre los nombres de sus ordenadores y la dirección IP de estos. Un servidor DNS autorizado hospeda estos registros. Estos registros pueden estar en servidores DNS autoriza-

(4)

En inglés, top-level domain (TLD).

(5)

En inglés, authoritative DNS servers.

© FUOC • PID_00147724

22


dos de la propia organización o en servidores DNS autorizados de algún proveedor de servicios. En este caso, la organización tiene que pagar por este servicio. La mayoría de las grandes empresas, universidades y centros de investigación mantienen sus servidores DNS autorizados primario y secundario (backup). Porción de la jerarquía de servidores DNS

Hay otro tipo de servidores DNS, denominados servidores�DNS�locales, que aunque estrictamente no pertenecen a la jerarquía de servidores, son claves para la arquitectura del DNS. Cada empresa proveedora de acceso a Internet (PAI o ISP en inglés) –como una universidad o una empresa de telecomunicaciones que proporciona acceso a Internet a usuarios domésticos– tiene un servidor DNS local. Cuando un nodo se conecta a su PAI, este le proporciona la dirección IP de uno o más servidores DNS locales (normalmente, esto se hace de manera automática vía DHCP). Cuando un ordenador hace una consulta al DNS, la consulta se envía al servidor DNS local, que actúa como proxy, y este la envía a la jerarquía de servidores DNS para que resuelva la petición. DHCP Dynamic Host Configuration Protocol (DHCP) es un protocolo de red que permite a los nodos de una red IP obtener sus parámetros de configuración de manera automática. Se trata de un protocolo de tipo cliente-servidor. El cliente hace broadcast de una petición para información de configuración. El servidor DHCP recibe la petición y responde con información de configuración de su base de datos de configuración. Generalmente, un servidor posee una lista de direcciones IP dinámicas y las va asignando a los clientes a medida que estas van estando libres, sabiendo en todo momento quién ha estado en posesión de aquella IP, cuánto tiempo la ha tenido o a quién se le ha asignado después. En el caso de no utilizar DHCP, cada ordenador de la red tiene que configurarse manualmente, tarea costosa y propensa a errores. Ejemplo de obtención de dirección IP A continuación, hay un ejemplo de los pasos que se seguirían para que el ordenador estudiante.pai.cat obtenga la dirección IP del ordenador sd.eimt.uoc.edu. 1)estudiante.pai.cat envía la petición a su servidor DNS local. 2) El servidor DNS local reenvía la petición a un servidor DNS raíz. 3) El servidor DNS raíz retorna una lista de direcciones IP de servidores DNS responsables del dominio edu. 4) El servidor DNS local reenvía la petición a uno de estos servidores DNS TLD. 5) El servidor DNS TLD contesta la dirección IP del servidor autorizado por el dominio uoc.edu.

Proveedor de acceso a Internet Proveedor de acceso a Internet (PAI) o proveedor de servicios de Internet (en inglés, Internet Servide Provider, ISP) es una empresa que ofrece a sus clientes acceso a Internet. Un PAI conecta a sus usuarios a Internet mediante diferentes tecnologías como DSL (normalmente ADSL), módem de red telefónica conmutada, cable módem, Wi-Fi, etc. Muchos PAI también ofrecen otros servicios relacionados con Internet como correo electrónico, hospedaje de páginas web, registro de dominios, etc.

© FUOC • PID_00147724

23

6) El servidor DNS local reenvía la petición al servidor DNS de la Universitat Oberta de Catalunya (dns.uoc.edu). 7) El servidor DNS de la Universitat Oberta de Catalunya responde la dirección IP del ordenador sd.eimt.uoc.edu. Peticiones DNS iterativas

Frecuentemente, sucede que el servidor TLD no conoce el nombre del servidor autorizado sino sólo de un servidor DNS intermedio, el cual sí conoce el servidor DNS autorizado del ordenador. Supongamos que en el ejemplo que acabamos de ver, la UOC tenga un servidor DNS para toda la universidad –dns.uoc.edu–, y que el servidor DNS de cada departamento sea el autorizado para todos los ordenadores del departamento. En este caso, cuando el servidor DNS intermediario, dns.uoc.edu, recibe una petición por un ordenador con el nombre acabado en eimt.uoc.edu, retorna a dns.pai.cat la dirección IP de dns.eimt.uoc.edu, que es el servidor DNS autorizado para todos los ordenadores acabados en eimt.uoc.edu. El servidor DNS local preguntaría, finalmente, a dns.eimt.uoc.edu la dirección IP de sd.eimt.uoc.edu. 2.2. Caching de DNS Como se puede ver, cada vez que se pide la resolución de un nombre se envían muchos mensajes, lo que hace incrementar el tiempo para obtener la respuesta y que haya muchos mensajes DNS circulando por Internet. Con el objetivo


© FUOC • PID_00147724

24

de reducir este número de mensajes, el DNS hace caching. En el ejemplo de la última figura del subapartado 2.1, el servidor DNS local se guardaría una copia de la dirección IP responsable del dominio uoc.edu. De esta manera, si al cabo de un rato recibe una petición por un ordenador del dominio uoc.edu, ya preguntaría directamente al servidor DNS autorizado por uoc.edu. El servidor DNS local también puede guardarse una copia de la dirección IP de los servidores TLD y ahorrarse preguntar a los servidores DNS raíz. Dado que la equivalencia entre hosts y direcciones IP no es permanente, los servidores DNS descartan la información cacheada al cabo de un cierto tiempo (frecuentemente dos días). 2.3. Peticiones recursivas frente a peticiones iterativas El ejemplo de la última figura del subpartado 2.1 utiliza tanto peticiones�recursivas como peticiones�iterativas. La petición de estudiante.pai.cat a dns.pai.cat es recursiva, ya que pide a dns.pai.cat que no resuelva la equivalencia en ningún sitio suyo. Las otras tres consultas son iterativas, ya que las respuestas se retornan directamente a dns.pai.cat. En teoría, las peticiones al DNS pueden ser recursivas o iterativas. La figura siguiente muestra la cadena de peticiones para el caso de una resolución recursiva. En la práctica, la mayoría de las peticiones siguen el esquema de la figura que hemos mencionado antes.


© FUOC • PID_00147724

25


Petición DNS

2.4. Registros DNS Los servidores DNS almacenan registros�de�recursos, que tienen los campos siguientes. •

Nombre.

•

Valor.

•

Tipo.

•

Tiempo de vida6: el TTL es el tiempo máximo para que un recurso se borre de la caché.

Los tipos más usuales son los siguientes: •

A: Nombre es el nombre del ordenador y Valor es su dirección IP.

•

NOS: Nombre es un dominio (por ejemplo, uoc.edu) y Valor es el nombre de un servidor autorizado para este dominio (por ejemplo, dns.uoc.edu).

•

CNAME: Valor es el nombre canónico de un alias (nombre). Permite obtener el nombre canónico de un alias (por ejemplo, sd.uoc.edu, einfsun1.uoc.edu, CNAME).

(6)

En inglés, time to live (TTL).

© FUOC • PID_00147724

•

26


MX: Valor es el nombre canónico de un servidor de correo que tiene Name como alias (por ejemplo, uoc.edu, correu2.uoc.edu, MX). MX permite que los servidores de correo tengan nombres más sencillos. También permite que una organización pueda tener el mismo alias para el dominio de correo que para el servidor web. Si se quiere obtener el nombre canónico del servidor de correo, se preguntará por el campo MX y si se quiere obtener el del otro servidor, se preguntará por el campo CNAME.

2.5. Consideraciones de seguridad El DNS se diseñó sin considerar la seguridad. Un tipo de vulnerabilidad es la contaminación de la memoria caché del DNS, que hace creer en un servidor DNS que ha recibido información auténtica cuando en realidad no es así. Domain Name System Security Extensions (DNSSEC) modifica el DNS para añadir respuestas firmadas digitalmente, lo que proporciona a los clientes DNS (resolvedores) autenticación del origen de los datos DNS, integridad de datos –pero no disponibilidad ni confidencialidad– y denegación de existencia autenticada.

Contaminación de la memoria caché del DNS La contaminación de la memoria caché del DNS (DNS cache poisoning o DNS cache pollution en inglés) es una situación creada maliciosamente o de manera intencionada que proporciona datos a una caché de DNS que no está originada por el servidor DNS autorizado. Este hecho puede ocurrir por un error en el software, por mala configuración de los servidores DNS o por acciones malintencionadas que se aprovechan de la arquitectura abierta del DNS.

Extensión del DNSSEC A partir de julio del 2010, todos los servidores raíz tendrían que utilizar DNSSEC (http:// www.root-servers.org/).

© FUOC • PID_00147724

27


3. La web y el HTTP

La web es un sistema formado por millones de páginas escritas en hipertexto mediante el lenguaje de marcaje HTML y conectadas entre sí mediante vínculos, de manera que formen un solo cuerpo de conocimiento por el cual se puede navegar fácilmente. Con un navegador web, se pueden visualizar páginas que pueden contener texto, imágenes, vídeos y otro multimedia y navegar de unas páginas a otras usando los hiperenlaces. La introducción de la web a principios de los noventa supuso una revolución en Internet. Internet dejó de ser una red utilizada mayoritariamente por investigadores, académicos y alumnos de universidad para pasar a ser un medio de comunicación, interacción y publicación de información que ha entrado a formar parte de nuestra cotidianidad.

La web se basa en tres estándares para funcionar: •

El Uniform Resource Locator (URL), que se encarga de dar una dirección única con el fin de localizar cada objeto.

•

El Hyper Text Transfer Protocol (HTTP), que especifica la manera en la que se enviará y se recibirá la información entre el navegador y el servidor.

•

El Hyper-text Markup Language (HTML), un método para especificar cómo se tiene que ver esta información en el navegador.

En este módulo nos centraremos en el HTTP. Antes, sin embargo, veremos los aspectos básicos de los URL. El URL es una cadena de caracteres que informa al navegador de: •

El ordenador donde está el recurso al que hace referencia.

•

El protocolo que tiene que utilizar para obtener este recurso.

•

La manera en la que el servidor web encontrará cuál es el recurso.

La sintaxis que se utiliza en el URL es: protocolo://[usuario:contraseña]@host[:puerto]/[camino], donde usuario:contraseña, el puerto y el camino son opcionales.

HTML El Hyper Text Markup Language (HTML) es un lenguaje de marcaje diseñado para estructurar textos y relacionarlos en forma de hipertexto. El World Wide Web Consortium (W3C) controla la evolución del HTML: http:// www.w3.org.

© FUOC • PID_00147724

28

Los protocolos más habituales son: http, ftp (File Transfer Protocol) y file (para


Ved también

el acceso y la localización de archivos dentro de sistemas de ficheros).

El protocolo ftp se trata en el apartado 4 de este módulo.

El host identifica la máquina donde está el recurso. Puede ser un nombre (www.wikipedia.org) o una dirección IP (192.12.34.11). El puerto es el número de puerto TCP del servidor, donde se conectará el navegador. Ejemplo En la dirección http://www.empresa.com/producto/descipcion.html, http es el nombre del protocolo, www.empresa.com es la dirección del servidor de la empresa y /producto/descripcion.html es el camino hasta llegar al objeto en el servidor. En este caso no hay ningún puerto especificado, lo que quiere decir que se utiliza el puerto 80, que es el puerto por defecto de los servidores web.

3.1. HTTP: Hypertext Transfer Protocol El HTTP7 es un protocolo a nivel de aplicación para sistemas hipermedia colaborativos y distribuidos, que es la base de la web. El HTTP sigue el paradig-

(7)

El HTTP está definido en los RFC 1.945 y 2.616.

ma cliente-servidor. Clientes y servidores se intercambian mensajes HTTP. El HTTP define la estructura de estos mensajes y cómo el cliente y el servidor intercambian los mensajes. Se basa en un transporte fiable –el más habitual es TCP–, aunque podría funcionar en otros transportes fiables. El puerto por defecto para establecer las conexiones es el puerto asignado oficialmente al servicio www, que es el puerto 80.

Una página�web está formada por diferentes objetos. Un objeto es un fichero –que puede ser de diferentes tipos: un fichero HTML, una imagen, un applet Java o un vídeo– dirigible por un URL. La mayoría de las páginas web consisten en un fichero base formateado en HTML que referencia a diferentes objetos.

La figura siguiente ilustra el funcionamiento de la interacción entre un servidor web y unos clientes web: un cliente envía un mensaje HTTP al servidor y este lo procesa y contesta con otro mensaje HTTP. Dado que los navegadores web implementan la parte cliente HTTP, a menudo nos referiremos a clientes HTTP como navegadores. Los navegadores también implementan otras partes, como el visualizador que formatea los documentos HTML y los presenta a los usuarios.

Ejemplo Una página que contiene texto en HTML y dos imágenes en GIF contiene tres objetos: la página HTML base y las dos imágenes.

29

© FUOC • PID_00147724


Los servidores HTTP no mantienen ninguna información sobre los clientes, y por este motivo se dice que el HTTP es un protocolo�sin�estado.

3.1.1. Conexiones persistentes y no persistentes El HTTP tiene dos modos de conexión. •

Conexiones�persistentes: en el caso de las conexiones persistentes, se obra una conexión TCP diferente para enviar la petición/respuesta para cada objeto que contiene la página que se quiere bajar (es decir, la petición y respuesta de un mismo objeto viajan por la misma conexión).

•

Conexiones�no�persistentes: en el caso de las conexiones no persistentes, todas las peticiones y respuestas de los objetos de una página se envían por la misma conexión TCP. Por defecto, el HTTP usa conexiones persistentes, aunque tanto los clientes como los servidores HTTP se pueden configurar para usar conexiones no persistentes.

Ventajas

Inconvenientes

Conexiones�persistentes Después de enviar una respuesta, el servidor deja Tarda más en bajar los objetos de una página, ya abierta la conexión TCP con el cliente. Esto permique no aprovecha el paralelismo que se puede obtete que futuras peticiones y respuestas entre el clien- ner bajando cada objeto de la página por separado. te y el servidor se pueden enviar por esta conexión TCP (ya se trate de objetos pertenecientes a la misma página o de diferentes páginas). Además, no hace falta que esperen a que les toque el turno de ser servidas ya que la conexión ya está abierta. El servidor cierra la conexión TCP con el cliente cuando hace un rato que no se usa.

30

© FUOC • PID_00147724

Conexiones�no persistentes


Ventajas Permite tener más de una conexión en paralelo, lo que reduce el tiempo de respuesta.

Inconvenientes Hay que establecer más conexiones: • La bajada de cada objeto sufre un retraso, debido al tiempo de establecimiento de la conexión TCP y al tiempo de hacer la petición del objeto. • Para cada conexión hay que mantener información: buffers y otras variables del TCP, lo que puede ser una molestia para el servidor web, ya que puede estar atendiendo muchas peticiones de manera simultánea.

3.2. Formato de los mensajes HTTP A continuación veremos los mensajes HTTP de petición y respuesta. 3.2.1. Mensaje HTTP de petición Seguidamente, presentamos el ejemplo de un mensaje de petición HTTP.

GET /MiDirectorio/pagina.html HTTP/1.1 Host: www.servidor.edu

Como podéis ver, el mensaje está escrito en ASCII. Cada línea acaba con un carry return y un line feed. La última línea está acabada con una línea en blanco (una línea que sólo contiene un carry return y un line feed). Los mensajes pueden tener más líneas. A la primera línea se la denomina línea�de�petición. Las siguientes reciben el nombre de líneas�de�cabecera. La línea de petición tiene tres campos. •

El� método: puede tener diferentes valores GET, POST, HEAD, PUT, DELETE, etc. El método más usado es el GET. El método GET se usa cuando el navegador pide un objeto.

•

El�URL: identifica el objeto. En el ejemplo, se pide el objeto /MiDirectorio/pagina.html.

•

Versión� de� HTTP: en el ejemplo, el navegador implementa la versión HTTP/1.1.

La línea de cabecera Host: www.servidor.edu indica en qué ordenador está el objeto. De entrada esta cabecera podría parecer superflua, pero es útil para los proxy cache web. De manera más general, en la figura siguiente encontraréis el formato de los mensajes HTTP de petición.

Ved también En el subapartado 3.6 se tratan los servidores proxy cache web.

© FUOC • PID_00147724

31

Es fácil ver que el formato de los mensajes de petición sigue el ejemplo que hemos visto anteriormente, con una diferencia: el formato general contiene un "cuerpo". El cuerpo está vacío en el caso del método GET, pero se utiliza con el método POST. Los clientes HTTP acostumbran a utilizar el método POST para enviar datos de un formulario (por ejemplo, cuando un usuario proporciona palabras para hacer una busca en un buscador). Con un mensaje POST, el usuario está pidiendo una página web a un servidor pero el contenido de la página web depende de lo que el usuario ha introducido en los campos del formulario. Si el valor del campo método es POST, el cuerpo contiene lo que el usuario ha introducido en los campos de formulario. Merece la pena mencionar que no siempre que se utiliza un formulario los datos se envían usando el método POST. Con frecuencia se usa el método GET y los datos se incluyen en el URL. Por ejemplo, si un formulario que utiliza el método GET tiene dos campos (modelo y cantidad) y los valores de los dos campos son AT y 23, entonces el URL tendrá la estructura siguiente: www.negocio.com/compra?modelo=TA&cantidad=23 3.2.2. Mensaje HTTP de respuesta A continuación, se muestra un ejemplo de posible mensaje HTTP de respuesta.

HTTP/1.1 200 Ok Date: Wed, 24 Feb 2010 19:05:40 GMT Server: Apache/1.3.3 (Unix) Last-Modified: Wed, 18 Feb 2009 21:11:55 GMT Content-Length: 3245 Content-Type: text/html

(datos datos datos...)


© FUOC • PID_00147724

32


La respuesta tiene tres partes. •

•

Una�línea�de�estado, que tiene, a su vez, tres partes: –

La versión del protocolo

–

Un código de estado

–

El mensaje correspondiente al código de estado

Unas�cabeceras. En el ejemplo anterior: –

Date: indica el día y la hora en los que se creó y envió la respuesta. No es el día y la hora en los que se creó o modificó por última vez el objeto, sino el momento en el que el servidor obtiene el objeto del sistema de ficheros, lo incluye en el mensaje de respuesta y lo envía.

–

Server: indica que el mensaje lo generó un servidor web Apache.

–

Last-Modified: indica el día y la fecha en los que se creó o modificó por última vez el objeto.

–

Content-Length: indica el número de bytes del objeto que se envía.

–

Content-Type: indica que el objeto que contiene el cuerpo es del tipo texto HTML.

•

Un�cuerpo: contiene el objeto pedido.

En la figura siguiente, encontraréis el formato general de los mensajes HTTP de respuesta.

Algunos códigos de estado son los siguientes. •

200 OK: la petición ha tenido éxito y la información se retorna incluida en la respuesta.

•

301 Moved Permanently: el objeto pedido se ha cambiado de ubicación. El nuevo URL está especificado en la cabecera Location: del mensaje de respuesta. El cliente obtendrá de manera automática el nuevo URL.

Ved también Veréis en el subapartado 3.6 que la cabecera Last-Modified es una cabecera crítica para los servidores caché.

© FUOC • PID_00147724

•

33

400 Bad Request: código de error genérico que indica que el servidor no ha podido entender la petición.

•

404 Not Found: el documento pedido no existe en el servidor.

•

505 HTTP Version Not Supported: el servidor no soporta la versión del protocolo HTTP pedido. Mensaje HTTP de respuesta real Es muy fácil ver un mensaje HTTP de respuesta real. Sólo hay que hacer un Telnet en un servidor web y después teclear en línea un mensaje pidiendo un objeto que esté hospedado en el servidor. Podéis probar con el ejemplo siguiente8:

telnet www.uoc.edu 80 GET /index.html HTTP/1.1 Host: www.uoc.edu

Con Telnet se obra una conexión TCP en el puerto 80 del servidor www.uoc.edu. A continuación, se envía un mensaje HTTP de petición (aunque no veáis lo que estáis escribiendo, se enviará una vez pulséis el retorno. Si os equivocáis no sirve de nada borrar, ya que se enviarán todos los caracteres. Será necesario que volváis a empezar). Recibiréis un mensaje de respuesta que contendrá el fichero HTML de la página que habéis pedido. (8)

Recordad que hay que pulsar dos veces la tecla de retorno después de teclear la última línea.

3.3. HTTPS (HTTP seguro)

El Hypertext Transfer Protocol Secure (HTTPS) es una combinación del HTTP con el protocolo SSL/TLS para proporcionar cifrado e identificación segura del servidor. La idea principal tras el HTTPS es crear un canal seguro sobre una red insegura. Esto asegura una protección razonable frente a intrusos que quieran espiar la comunicación y ataques man-inthe-middle, siempre y cuando el certificado del servidor esté verificado y se pueda confiar en el mismo.

Ataque man-in-the-middle El ataque man-in-the-middle es una forma de espiar en la que el atacante crea conexiones independientes con las víctimas y hace pasar los mensajes entre estas a través de él. Esto hace que las víctimas piensen que están hablando directamente entre sí a través de una conexión privada cuando, en realidad, la conversación está controlada por el atacante. Un ataque man-in-the-middle tiene éxito sólo cuando el atacante puede hacerse pasar por cada una de las víctimas. La mayoría de los protocolos de cifrado incluyen alguna forma de autenticación para evitar este tipo de ataques. Por ejemplo, el SSL autentica el servidor mediante una autoridad de certificación en la que confían las dos partes.

El HTTPS confía en unas autoridades de certificación que se venden preinstaladas en los navegadores web. A partir de aquí, las conexiones HTTPS son fiables si y sólo si se cumple lo siguiente:


© FUOC • PID_00147724

•

34


El usuario confía en que la autoridad certificadora genera certificados para sitios web legítimos.

•

El sitio web proporciona un certificado válido (un certificado firmado por una autoridad en la que se puede confiar).

•

El certificado identifica de manera clara el sitio web.

•

O bien los nodos de Internet que intervienen son fiables, o bien el usuario confía en que el protocolo de cifrado usado (TLS o SSL) hace que no se pueda espiar la comunicación.

3.4. Cookies El HTTP es un protocolo sin estado. Esto simplifica el diseño del servidor y hace que este tenga un rendimiento elevado, ya que es capaz de soportar miles de conexiones TCP simultáneas. A veces, sin embargo, conviene que el servidor web pueda identificar a usuarios. Las cookies9 se usan para este propósito. Permiten a los servidores web tener información de los usuarios. Las cookies se pueden usar para autenticar, almacenar preferencias del cliente, identificar una sesión, mantener un seguimiento de las compras en una tienda virtual o cualquier otro cosa que se pueda hacer a partir de almacenar datos textuales. La mayoría de los sitios web comerciales usan cookies.

Una cookie es una pequeña porción de texto almacenado en el ordenador del usuario por el navegador web, que consiste en una o más parejas nombre-valor que contienen porciones de información.

El servidor web envía la cookie al navegador web como una cabecera de la respuesta. A partir de este momento, el navegador web envía la cookie cada vez que accede al servidor. El navegador web almacena las cookies en un fichero local gestionado por el navegador. El servidor web puede tener una base de datos con la información relacionada con las cookies. Ejemplo de uso de una cookie Supongamos que hay un cliente que se quiere conectar al servidor web de la UOC. Cuando la petición llega al servidor de la UOC, el servidor crea un identificador único y una entrada a una base de datos que este identificador indexa. A continuación contesta al navegador del cliente incluyendo la cabecera Set-cookie: en la respuesta HTTP, que contiene el identificador. El navegador recibe la respuesta HTTP y almacena la cookie recibida en un fichero en el que almacena las cookies. En el ejemplo de la figura siguiente, el fichero de cookies ya contiene una de una conexión anterior a Youtube. El usuario continúa navegando por el sitio web de la UOC. Cada vez que pide una página web, el navegador consulta el fichero de cookies y añade una línea de cabecera a la petición HTTP. Si el usuario vuelve al sitio web de la UOC unos días más tarde, continúa añadiendo la cabecera Cookie: en los mensajes de petición.

(9)

Las cookies están definidas en el RFC 2.965.

© FUOC • PID_00147724

35

Las cookies, al ser texto, no son ejecutables. Por el hecho de no ser ejecutables, no se pueden replicar por sí mismas y, por lo tanto, no son virus. Debido al mecanismo para guardar y leer las cookies, estas se pueden usar como spyware. Los productos antispyware pueden avisar a los usuarios sobre algunas cookies porque estas se pueden usar para hacer un seguimiento de las operaciones del usuario o vulnerar la privacidad. La mayoría de los navegadores modernos permiten a los usuarios decidir si quieren aceptar o no las cookies de las páginas visitadas, pero la no aceptación de estas puede hacer que algunas páginas web no funcionen correctamente. 3.5. Características de la demanda de páginas web Un servidor web puede tener miles de documentos y, sin embargo, recibir la mayoría de las peticiones para un único documento.


© FUOC • PID_00147724

36

El nivel de aplicación (10)

La ley de Zipf debe su nombre a George Kingsley Zipf (19021950).

Ley�de�Zipf En muchos casos, la popularidad relativa entre diferentes sitios web o 10

entre distintas páginas de un cierto sitio web se rige por la ley de Zipf , que formulada de manera sencilla sería: muy pocos casos tienen mucha popularidad y muchos casos tienen muy poca.

Distribución de popularidad que sigue la ley de Zipf

Casos ordenados por popularidad en el eje x, valor de popularidad en el eje y

La popularidad de un sitio web puede ser muy variable. Puede recibir muy pocas visitas durante mucho tiempo y, de repente, recibir varias veces más peticiones de las que puede servir: es un tráfico en ráfagas. Evolución del tráfico entrante y saliente de un sitio web típico durante una semana

Podéis observar la gran variación horaria y la reducción de tráfico durante el fin de semana.

Un servidor puede recibir avalanchas repentinas de tráfico. Por ejemplo, por las estadísticas del servidor web que se ve en la figura siguiente sabemos que, después de ser anunciado en la página de noticias Slashdot, sufrió un exceso de visitas tan alto que el servidor se bloqueó. Flash crowd Un cuento de ciencia ficción de Larry Niven (1973) predijo que una consecuencia de un mecanismo de teletransporte barato sería que grandes multitudes se materializarían de manera instantánea en los lugares con noticias interesantes. Treinta años después, el término se usa en Internet para describir los picos de tráfico web cuando un determinado sitio web se convierte repentinamente en popular y es visitado de manera masiva.

© FUOC • PID_00147724

37


También se conoce como efecto slashdot o efecto /., que se da cuando un sitio web resulta inaccesible a causa de las numerosas visitas que recibe cuando aparece en un artículo del sitio web de noticias Slashdot (en castellano, Barrapunto). Peticiones web por hora, servidas por http://counter.li.org durante tres días

Se puede ver que mientras que el número habitual de operaciones (peticiones web) estaba por debajo de 500, subió rápidamente a unas 2.500, lo que provocó el fallo del sistema. Después de reconfigurarlo, estuvo soportando durante unas doce horas en torno a 3.000 peticiones por hora para bajar posteriormente a valores normales. La historia completa está en la dirección: http://counter.li.org/slashdot.

3.6. Servidores intermediarios Un servidor intermediario11 es una entidad de la Red que satisface las peticiones HTTP en lugar del servidor web al que iba dirigida la petición. Los servidores intermediarios mantienen una copia de los objetos accedidos recientemente en un disco del servidor. La figura siguiente muestra el funcionamiento general de un servidor intermediario.

El navegador del usuario se puede configurar para que todas las peticiones HTTP del usuario vayan primero al servidor web intermediario. A partir de este momento: 1) Cada nueva petición del usuario establecerá una conexión TCP con el proxycache y le enviará la petición HTTP.

(11)

En inglés, web cache o proxy-cache.

38

© FUOC • PID_00147724


2) Si el proxy-cache tiene una copia del objeto, lo retorna dentro de un mensaje HTTP de respuesta al navegador cliente. 3) En caso de que el proxy-cache no tenga el objeto pedido, este abre una nueva conexión TCP con el servidor origen de la petición para pedirle el objeto. 4) Al recibir la petición, el servidor origen envía el objeto en una respuesta HTTP al proxy-cache. 5) Finalmente, el proxy-cache almacena el objeto recibido en su disco local y envía una copia, en un mensaje HTTP de respuesta, al navegador cliente (en la conexión TCP establecida entre el cliente y el proxy-cache). El proxy-cache actúa como servidor del cliente y como cliente del servidor. Los 12

proveedores de acceso a Internet

son los que instalan los proxy-cache. Por

ejemplo, una universidad puede instalar un proxy-cache en la red del campus y configurar todos los navegadores para que apunten al proxy-cache. Hay dos razones principales para desplegar proxy-cache en Internet: •

Se puede reducir de manera significativa el tiempo de respuesta de las peticiones.

•

Puede reducir de manera significativa el tráfico del enlace de la institución con Internet.

Los servidores intermediarios se usan también en otros protocolos además del HTTP. En general, se sitúan en una discontinuidad para hacer una función. Por ejemplo, para hacer un cambio de red: una máquina conectada a la red interna de una organización, que usa direcciones IPv4 privadas (por ejemplo, 10.*.*.*), y también a Internet, puede hacer de proxy-cache para la traducción de direcciones IP entre las dos redes (NAT). Network Address Translation (NAT) En los paquetes IP salientes: sustituir la dirección IP de las máquinas internas (no válidas en Internet) por la suya propia; en los paquetes IP entrantes: sustituir su propia dirección IP por la de una máquina interna y reenviar el paquete hacia la red interna. Para saber a quién se tiene que entregar, el servidor intermediario debe asociar cada uno de sus puertos a las máquinas internas, ya que una dirección de transporte es una pareja (dirección IP, puerto).

3.7. El GET condicional Hemos visto que el caching puede reducir el tiempo de respuesta percibido por el usuario, pero la copia que tenga la caché puede ser obsoleta. Es decir, el objeto hospedado en el servidor web puede haberse modificado de manera

(12)

En inglés, Internet Service Providers (ISP)

© FUOC • PID_00147724

39

posterior a que al cliente lo copiara en su caché. Para solucionarlo, el protocolo HTTP incluye un mecanismo que permite a la caché verificar que su copia del objeto está actualizada.

GET /MiDirectorio/pagina.html HTTP/1.1 Host: www.servidor.edu If-modified-since: Wed, 18 Feb 2009 21:11:55 GMT

La cabecera If-modified-since: contiene el valor de la cabecera Last-Modified: de cuando el servidor envió el objeto. Esta petición GET, que se denomina GET condicional, indica al servidor que envíe el objeto sólo si el objeto se ha modificado desde la fecha especificada.

En el caso de que el objeto no se haya modificado desde la fecha indicada, el servidor web contesta un mensaje a la caché como el siguiente:

HTTP/1.1 304 Not Modified Date: Tue, 24 Mar 2009 18:23:40 GMT (sin cuerpo)

304 Not Modified en la línea de estado del mensaje de respuesta indica a la caché que puede pasar su copia del objeto al navegador que ha hecho la solicitud. Hay que destacar que el mensaje de respuesta del servidor no incluye el objeto, ya que esto sólo haría malgastar ancho de banda y la percepción del usuario sobre el tiempo de respuesta. 3.8. Distribución de contenidos Los mecanismos de proxy-cache son útiles para que una comunidad de usuarios que comparten una conexión a Internet puedan ahorrar ancho de banda y reducir transferencias repetitivas de objetos. Sin embargo, esta sólo es una parte del problema. Diferentes agentes participan en el rendimiento de una transferencia web. •

Proveedor� de� contenidos� (servidor� web): debe planificar su capacidad para dar servicio en horas punta y aguantar posibles avalanchas de peticiones, y de esta manera tener una cierta garantía de que sus clientes dispondrán de un buen servicio con cierta independencia de la demanda.

•

Cliente: podría usar una memoria caché para economizar recursos de la red. Cuando un contenido se encuentra en más de un lugar, debería elegir


© FUOC • PID_00147724

40

el mejor servidor en cada momento. El original o una réplica "rápida" (o llevar el objeto a trozos desde distintos lugares al mismo tiempo). •

Réplica: si un servidor guarda una réplica de algún contenido, probablemente es porque quiere ofrecerlo y reducir la carga del servidor original. Por lo tanto debe ser "conocido" por sus clientes, pero además el contenido tiene que ser consistente con el contenido original.

•

Proveedor�de�red: debería elegir el mejor camino para una petición, vía direccionamiento IP, vía resolución DNS (resolver nombres en la dirección IP más próxima al cliente que consulte, aunque no es lo más habitual), vía servidores proxy-cache HTTP y evitar zonas congestionadas (hot spots) o flash crowd (congestión en el servidor y en la red próxima debida a una avalancha de demandas).

En este subapartado, nos centraremos en los sistemas de distribución de documentos para ayudar a mejorar el rendimiento de la web. Más concretamente, nos centraremos en qué puede hacer el proveedor de los contenidos. Las aplicaciones que ofrecen contenidos en Internet se enfrentan al reto de la escala: un único servidor frente a millones de personas que de manera eventual pueden pedir sus servicios todos al mismo tiempo: el proveedor de información debe poner tantos recursos como audiencia pueda tener. Una opción muy utilizada es que el proveedor del contenido disponga de diferentes réplicas de la información. Hay varios trucos para repartir peticiones entre los diferentes servidores que contienen las réplicas: •

Mirrors con un programa que redirige la petición HTTP a la mejor réplica.

•

Hacer que el servicio de nombres DNS retorne distintas direcciones IP. Normalmente, se envía la petición HTTP a la primera dirección de la lista de direcciones IP recibidas del DNS. Si esta lista está ordenada de manera diferente en cada petición al DNS (método round roben), cada vez se hará la petición a una dirección IP diferente.

•

Redireccionamiento a nivel de transporte (conmutador de nivel 4, L4 switch): un encaminador mira los paquetes IP de conexiones TCP hacia un servidor web (puerto 80) y las redirige a la máquina interna menos cargada.

•

Redireccionamiento a un nivel de aplicación (conmutador de nivel 7, L7 switch): un encaminador que mira las conexiones HTTP y puede decidir con qué réplica contactar en función del URL solicitado. Muy complejo.


© FUOC • PID_00147724

•

41

Enviar todas las peticiones a un servidor intermediario inverso que responda con contenido guardado en la memoria o que pase la petición a uno o varios servidores internos.

3.8.1. Redes de distribución de contenidos Han surgido empresas que se han dedicado a instalar máquinas en muchos lugares del mundo y algoritmos para decidir qué máquina es la más adecuada


Réplica Una réplica (en inglés, mirror) es una copia exacta de otro lugar de Internet. Los mirrors proporcionan múltiples fuentes para una misma información y son especialmente útiles por la fiabilidad que esto comporta. También para que el usuario acceda a la ubicación más próxima o para repartir la carga entre diferentes servidores.

para atender las peticiones, según la ubicación del cliente y la carga de la red. Estas empresas venden este "servidor web distribuido" a distintos clientes que pagan por disponer de un sistema de servicio web de gran capacidad y que

(13)

En inglés, Content Delivery Networks (CDN).

puede responder a demandas de contenidos extraordinariamente altas. Estos sistemas se denominan redes de distribución de contenidos13. Una CDN es un software intermediario (middleware) entre proveedores de contenidos y clientes web. La CDN sirve contenidos desde distintos servidores repartidos por todo el planeta. La infraestructura de la CDN está compartida por distintos clientes de la CDN y las peticiones tienen en cuenta la situación de la Red para hacer que cada cliente web obtenga el contenido solicitado desde el servidor más eficiente de la CDN (habitualmente una combinación del más próximo, el menos cargado y el que tiene un camino con más ancho de banda con el cliente). La CDN dispone de un gran número de puntos de servicio en multitud de proveedores de Internet y puede actuar sobre lo siguiente. •

El DNS: cuando se resuelve un nombre, el servidor DNS responde según la ubicación de la dirección IP del cliente.

•

El servidor web: cuando se pide una página web, se reescriben los URL internos según la ubicación de la dirección IP del cliente.

•

Cuando se pide un objeto a la dirección IP de un servidor de la CDN, el conmutador (switch) de acceso a un conjunto de distintos servidores proxycache, o réplicas, puede redirigir la conexión al servidor menos cargado del grupo (todo el conjunto responde bajo una misma dirección IP). Ejemplo de funcionamiento de una CDN La figura siguiente muestra el ejemplo de los posibles pasos que se pueden dar cuando se hace la petición de una página web con imágenes.

Akamai Se pueden encontrar diferentes empresas que ofrecen este servicio de redes de distribución de contenidos. Akamai es la más importante. A fecha de febrero del 2010, la UOC utilizaba Akamai para proporcionar el contenido de su portal.

© FUOC • PID_00147724

42

1) El cliente pide al servidor origen (www.foo.com) una página sobre música. El servidor informa al navegador web que la página pedida contiene varios objetos. El URL de estos objetos se modifica para que hagan referencia a la CDN. Por ejemplo, en lugar de contestar http://www.foo.com/musica/Beethoven.gif contesta http://www.cdn.com/ www.foo.com/musica/Beethoven.gif. 2) El navegador pide al DNS que resuelva www.cdn.com. La petición llega hasta el DNS autorizado por este dominio, que es un DNS de la empresa propietaria de la CDN. La CDN responde con la dirección IP del nodo de la CDN más próximo a la ubicación del navegador web (que es el que hace la petición para los contenidos) al DNS de la CDN. Esta "proximidad" se calcula a partir de información que va recogiendo sobre las distancias de los nodos de la CDN al ISP. 3) Finalmente, el navegador web pide los objetos al nodo de la CDN que le han asignado.

Las CDN no se utilizan sólo para distribuir contenidos web. También se usan para streaming de audio y vídeo, tanto almacenado como en directo. Finalmente hay que decir que, para proporcionar su servicio, las CDN usan el DNS para unas funciones para las que no está diseñado. Las CDN utilizan el DNS para redirigir las peticiones de manera transparente, pero este mecanismo de redirección sobrecarga el DNS ya que hace que las peticiones dirigidas a la CDN no se puedan cachear.


© FUOC • PID_00147724

43


4. Transferencia de ficheros

El protocolo de transmisión de ficheros FTP14 permite transferir ficheros de un ordenador a otro. Funciona siguiendo el modelo cliente servidor sobre una conexión TCP/IP. En la figura siguiente, se puede ver el funcionamiento del FTP a grandes rasgos.

Para hacer la transferencia, el usuario debe conectarse al ordenador remoto proporcionando un usuario y un password. La transferencia se puede hacer tanto del ordenador del usuario al ordenador remoto como al revés.

El FTP utiliza dos conexiones entre el cliente y el servidor, una para los datos y otra para el control. La conexión�de�control usa el puerto TCP número 21 y se utiliza para enviar información de control, como el usuario y el password, comandos para cambiar de directorio o comandos para pedir y enviar ficheros. Esta conexión se mantiene abierta durante toda la sesión. La conexión�de�datos se utiliza para enviar los ficheros y se hace por el puerto TCP número 20. Se establece una conexión de datos para cada fichero. Una vez enviado, la conexión se cierra. En el caso de que se quiera enviar otro fichero, se abre una nueva conexión de datos.

El servidor FTP mantiene información de estado durante una sesión. El servidor tiene que asociar la conexión de control con una cuenta de usuario y debe saber en todo momento en qué directorio se encuentra el usuario, ya que este puede ir cambiando de directorio en el servidor remoto. Los comandos se envían codificados en ASCII y finalizados con un carriage return y un line feed. Las respuestas también acaban con un carriage return y un line feed. Los comandos consisten en cuatro caracteres ASCII en mayúsculas,

(14)

Siglas en inglés de File Transfer Protocol

© FUOC • PID_00147724

44


algunos con argumentos opcionales. Algunos de los comandos más usuales (estos comandos son del protocolo, no los comandos que el usuario pone en el intérprete de comandos de la aplicación FTP cliente) son los siguientes. •

USER nombreUsuario: para enviar el nombre de usuario al servidor.

•

PASS clave: para enviar la clave de acceso al servidor.

•

LIST: para pedir al servidor que envíe la lista de ficheros del directorio remoto actual. La lista de ficheros se envía por una conexión de datos.

•

RETR fichero: para obtener un fichero del directorio actual del ordenador remoto.

•

STOR fichero: para enviar un fichero al directorio actual del ordenador remoto.

Cada comando enviado al ordenador remoto genera una respuesta de este. Las respuestas son números de tres dígitos seguidos de un mensaje opcional. Algunas respuestas habituales son: •

331 Username Ok, password required

•

125 Data connection already open; transfer starting

•

425 Can't open data connection

•

452 Error writing file

Bibliografía Acerca de las peticiones y las respuestas, encontraréis más información sobre los comandos y respuestas en el RFC 959.

4.1. Seguridad en la transferencia de ficheros La especificación original del FTP es inherentemente insegura porque no tiene ningún método para transferir datos de manera cifrada. Esto quiere decir que en la mayoría de las configuraciones de red, el nombre de usuario, la clave de acceso, los comandos FTP y los ficheros transferidos se pueden capturar desde la misma red utilizando un sniffer. La solución habitual a este problema es usar

(15)

SFTP es la abreviatura de SSH File Transfer Protocol o Secure File Transfer Protocol. (16)

FTPS es la abreviatura de FTP sobre SSL.

SFTP15 o FTPS16.

El SFTP es un protocolo que proporciona acceso, transferencia y gestión de ficheros sobre un canal fiable. Normalmente se utiliza con el SSH, y el SSH es el que proporciona el canal fiable, aunque se podría utilizar con otros protocolos de seguridad. Por lo tanto, la seguridad no la proporciona directamente el protocolo SFTP, sino el SSH o el protocolo que se utilice para este propósito.

IETF El SFTP fue diseñado por la Internet Engineering Task Force (IETF) como una ampliación del Secure Shell Protocol (SSH) versión 2.0.

© FUOC • PID_00147724

45

5. Correo electrónico en Internet

El correo electrónico existe desde los principios de Internet. En los años sesenta los sistemas mainframe ya tenían formas de comunicación uno a uno tipo mensajería, y a lo largo de los años estos sistemas han ido evolucionando hasta llegar al nivel de sofisticación y potencia actuales. Hoy día, es una de las aplicaciones más importantes y usadas de Internet. En la figura siguiente, se presenta una visión del sistema de correo en Internet. Cuando un usuario quiere enviar un mensaje, el agente usuario de mensajería que está utilizando envía el mensaje a un servidor de correo. Este –el servidor de correo origen– pregunta al DNS la dirección correspondiente al campo MX del dominio destino del mensaje y envía el mensaje al puerto 25 de este servidor de correo vía SMTP. La transmisión del mensaje se hace utilizando el protocolo TCP porque proporciona una transmisión fiable de los datos. Una vez el servidor destino ha aceptado el mensaje, lo almacena en el buzón del usuario destinatario para que más adelante el usuario destinatario –previa autenticación de este– lo lea vía un agente usuario de mensajería. Debemos destacar el hecho de que el protocolo SMTP normalmente no utiliza ningún servidor intermediario entre el servidor origen ni el destino. La comunicación se hace directamente aunque cada uno esté en una punta del mundo. Visión de alto nivel del sistema de correo electrónico en Internet


© FUOC • PID_00147724

46


En el caso de que el servidor origen no pueda enviar el mensaje al servidor destino por algún fallo, el servidor origen encola el mensaje y reintenta enviarlo más tarde. Los reintentos se hacen normalmente cada treinta minutos. Si después de algunos días no se puede entregar el mensaje, el servidor origen elimina el mensaje y notifica al remitente que no lo ha podido entregar. 5.1. SMTP El protocolo Simple�Mail�Transfer�Protocol (SMTP) está definido en el RFC 2.821 y es el estándar actual de transmisión de correo electrónico en Internet. El protocolo SMTP tiene muy buenas cualidades, como se puede deducir por el éxito que ha conseguido, pero arrastra algunos inconvenientes heredados del pasado. Por ejemplo, tanto el cuerpo de los mensajes como las cabeceras van codificados en caracteres ASCII de 7 bits. Esto hace que cualquier dato que no esté codificado en este formato deba codificarse en ASCII de 7 bits antes de enviarlo y volverse a descodificar una vez recibido. Ejemplo de envío de un mensaje A continuación, ponemos el ejemplo del envío de un mensaje uoc.edu a upc.cat utilizando SMTP. El ejemplo muestra los comandos que se intercambian una vez la conexión fiable (la conexión TCP) ha sido establecida. Con el objetivo de clarificar la comprensión del ejemplo, los comandos que envía el cliente (originador) se han prefijado con C: y los del servidor (receptor) con S:. También hemos numerado las líneas para poder referirnos a estos más fácilmente.

1 S: 220 upc.cat 2 C: HELO uoc.edu 3 S: 250 Hello uoc.edu please to meet you 4 C: MAIL FROM: 5 S: 250 [email protected] ... Sender OK 6 C: RCPT TO: 7 S: 250 [email protected] ... Recipient OK 8 C: DATA 9 S: 354 Enter mail, end with "." on a line by itself 10 C: Este es un mensaje de correo de ejemplo. 11 C: ¿Verdad que es sencillo? 12 C: . 13 S: 250 Message accepted for delivery 14 C: QUIT 15 S: 221 upc.cat closing connection

En este ejemplo, el cliente envía el mensaje Este es un mensaje de correo de ejemplo. ¿Verdad que es sencillo? desde el servidor de correo uoc.edu a upc.cat. Como parte del diálogo, el cliente envía los comandos: HELO, MAIL FROM, RCPT TO, DATA y QUIT. El cliente envía el mensaje (líneas 10 a 11) después del comando DATA y lo acaba con una línea que sólo contiene un punto (línea 12: CRLF.CFLR), y que indica el final del mensaje enviado al servidor. El servidor contesta cada comando con un código de respuesta y un texto opcional explicativo (en inglés).

RFC del SMTP El primer RFC que describe el SMTP data de 1982 (RFC 821), pero antes de esta fecha ya había versiones de lo que ahora es el SMTP.

© FUOC • PID_00147724

47

El protocolo SMTP usa conexiones persistentes. En el caso de que el servidor origen tenga más de un mensaje para enviar al mismo servidor destino, los mensajes se envían aprovechando la misma conexión TCP. El cliente empieza cada mensaje con un nuevo MAIL FROM: uoc.edu, acaba cada mensaje con un punto en una línea que sólo contiene un punto y envía el comando QUIT una vez ha acabado de enviar todos los mensajes. 5.2. Formato de los mensajes Tal y como sucede en las cartas postal que tienen un sobre y una carta, los mensajes de correo electrónico tienen dos partes. •

Cabecera: incluye la información general del mensaje. Sería equivalente al sobre de la carta postal y está formada por varios campos cabecera.

•

Cuerpo�del�mensaje: contiene el mensaje en sí. Corresponde al contenido de la carta postal. Esta parte es opcional. Formato de las cabeceras El RFC 822 especifica el formato de las cabeceras, así como su semántica. Cada campo de la cabecera consta de un nombre�del�campo seguido del carácter ":/, opcionalmente acompañado por un cuerpo�del�campo, y acaba con un CRLF. Ejemplo de cabecera de un mensaje El ejemplo del subapartado 5.1 no contiene ninguna cabecera. En la continuación repetimos el mismo mensaje, incluyendo la cabecera del mensaje. De este modo, primero encontramos la cabecera (líneas 10 a 13), seguida del cuerpo del mensaje (líneas 14 y 15). Tal y como se puede ver en la línea 13, el separador entre la cabecera y el cuerpo del mensaje es una línea en blanco (o sea, CRLF). Estos campos de la cabecera son diferentes de los comandos del SMTP ((HELO, MAIL FROM, RCPT TO, DATA y QUIT)), aunque puedan parecer similares.

1 S: 220 upc.cat 2 C: HELO uoc.edu 3 S: 250 Hello uoc.edu please to meet you 4 C: MAIL FROM: 5 S: 250 [email protected] ... Sender OK 6 C: RCPT TO: 7 S: 250 [email protected] ... Recipient OK 8 C: DATA 9 S: 354 Enter mail, end with "." on a line by itself 10 C: From: [email protected] 11 C: To: [email protected] 12 C: Subject: Mensaje de ejemplo 13 C: 14 C: Este es un mensaje de correo de ejemplo. 15 C: ¿Verdad que es sencillo? 16 C: . 17 S: 250 Message accepted for delivery 18 C: QUIT 19 S: 221 upc.cat closing connection


Diálogo con el servidor SMTP Si tenéis acceso a un servidor SMTP que no requiera autenticación, vosotros mismos podéis intentar dialogar directamente con el servidor SMTP. Para hacerlo, sólo tenéis que hacer: telnet nombreServidor 25, siendo nombreServidor el del servidor SMTP al cual os conectáis. Al hacer esto, estáis estableciendo una conexión TCP con el servidor SMTP. Podéis repetir los comandos del ejemplo prefijados con C: y veréis que se envía un mensaje de correo electrónico. (Intentad poner como recipiente una dirección de correo electrónico vuestra y recibiréis el mensaje.)

48

© FUOC • PID_00147724


5.2.1. Formato de mensajes MIME Tal y como hemos dicho anteriormente, una limitación de la norma RFC 822 es que define un formato de mensaje y un contenido con una única parte de texto en ASCII de 7 bits. Se vio que este formato era muy pobre y que hacía falta algún método para superar sus limitaciones. El formato MIME17 redefine el formato del mensaje para permitir, sin perder la compatibilidad con el formato definido por el RFC 822, dar apoyo a: •

Texto codificado con un juego de caracteres diferente del ASCII de 7 bits.

•

Adjunciones que no sean texto.

•

Cuerpos del mensaje con múltiples partes.

•

Cabeceras codificadas con un juego de caracteres diferente del ASCII de 7 bits.

Para hacerlo, MIME define un conjunto de nuevos campos de cabecera MIME-version, Content-ID, Content-Type, Content-Disposition y Content-Transfer-Encoding. En este módulo, nos centraremos en Content-Type: y Content-TransferEncoding::. Content-Type

Content-Type: indica al agente de usuario de mensajería receptor del mensaje qué tipo de contenido contiene el cuerpo del mensaje, lo que permite que este tome la acción apropiada para cada contenido de mensaje. El tipo de contenido se especifica con un tipo y un subtipo.

Ejemplo Content-Type: image/JPEG indica que el cuerpo del mensaje contiene una imagen formateada en JPEG. De esta manera, el agente usuario de mensajería que reciba el mensaje puede hacer las acciones necesarias, como enviar el cuerpo del mensaje a un descompresor JPEG.

Formato: Content-Type: type/subtype; parameters Algunos�tipos text

Algunos�subtipos plain, html

image

jpeg, gif

audio

basic, mp4, mpeg

video

mpeg, quicktime

application

msword, octet-stream, zip

(17)

MIME es la abreviatura de Multipurpose Internet Mail Extensions.

RFC del formato MIME El formato de mensajes MIME está especificado en los RFC 2.045, 2.046, 2.047, 4.288, 4.289 y 2.049.

49

© FUOC • PID_00147724

La Internet Assigned Numbers Authority (IANA) mantiene la lista de tipos y subtipos. Podéis encontrarla en http://www.iana.org/assignments/media-types. Content-Transfer-Encoding Recordad que hemos dicho que los mensajes SMTP tienen que ir codificados en ASCII de 7 bits. La cabecera Content-Transfer-Encoding: indica que el cuerpo del mensaje ha sido codificado en ASCII y el tipo de codificación utilizado. Ejemplo Content-Transfer-Encoding: base64 indica que se ha utiliza la codificación base64 para codificar el cuerpo del mensaje. La codificación base64 codifica una secuencia arbitraria de bytes en una forma que satisface las reglas del ASCII de 7 bits, y por lo tanto, no confundirá el SMTP.

Otra técnica popular para codificar que también satisface el ASCII de 7 bits es la quoted-printable, que se acostumbra a utilizar para convertir texto codificado en ASCII de 8 bits (que puede contener caracteres no ingleses) en ASCII de 7 bits. Ejemplo de quoted-printable El siguiente es un ejemplo de quoted-printable: Subject:

=?iso-8859-1?Q?Qu=E9?=

tal

=?iso-8859-1?Q?est=E1s=3F?=

que corresponde a "Subject: ¿Qué tal estás?", donde: •

= delimita la secuencia codificada con quoted-printable. En este caso, hay delimitadas dos secuencias: ¿Qué y estás?

•

? separa las partes.

•

Codificado en ISO-8859-1.

•

Q: codificación quoted-printable.

•

E9 es el código correspondiente a é en la codificación ISO-8859-1

Cuando volváis a recibir un mensaje (frecuentemente reenviado) con una secuencia como esta ya sabréis de dónde sale :-)

A continuación, pondremos un ejemplo que incluirá los diferentes aspectos vistos sobre el formato MIME:


© FUOC • PID_00147724

50

From: [email protected] To: [email protected] Subject: Foto del niño MIME-version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg (datos codificados en base64 ............................................................datos codificados en base64)

La cabecera MIME-version indica la versión de MIME que se está utilizando.

La cabecera Content-Type: también se utiliza para que un mensaje pueda contener texto y ficheros adjuntos. En este caso, a la cabecera Content-Type: se le añade un indicador de inicio y final de cada parte (boundary).

S/MIME (Secure/Multipurpose Internet Mail Extensions) es un estándar para cifrado de clave pública y firma de correo electrónico encapsulado en MIME. S/MIME proporciona: •

Autenticación, integridad y no repudio (usando firma digital).

•

Privacidad y seguridad de los datos (usando cifrado).

5.3. Protocolos para acceder a los buzones de correo Los servidores SMTP guardan los mensajes recibidos en los buzones de correo de los destinatarios de los mensajes. Es posible acceder a estos mensajes conectándose al servidor SMTP y ejecutando un programa para leer el correo. La mayoría de los usuarios, sin embargo, leen el correo electrónico desde un ordenador personal, mediante un cliente de correo que les ofrece un conjunto amplio de funcionalidades y que incluye la posibilidad de ver mensajes multimedia y adjunciones.


© FUOC • PID_00147724

51


5.3.1. POP3 POP318 es un protocolo del ámbito aplicación para que un agente de usuario de correo electrónico (el cliente) pueda obtener el correo de un servidor de correo remoto. El funcionamiento es muy sencillo. El cliente abre una conexión TCP con el servidor en el puerto 110. Una vez establecida esta conexión, el POP3 pasa por tres fases. 1)�Autorización: el usuario envía un usuario y una clave de acceso (en claro) para autenticar al usuario. 2)� Transacción: el agente de usuario baja mensajes. En esta fase, el agente de usuario puede marcar los mensajes para que se borren, eliminar marcas de borrar y obtener información sobre el buzón del usuario. 3)� Actualización: ocurre después de que el cliente ha ejecutado el pedido QUIT, que finaliza la sesión POP3. En este momento, el servidor borra los mensajes que se habían marcado para ser borrados.

Los comandos son palabras clave, que pueden estar seguidas de argumentos, y que acaban con un salto de línea (CRLF). Tanto las palabras clave como los argumentos son caracteres ASCII imprimibles.

Las respuestas consisten en un indicador de estado (+OK) o (-ERR) que puede estar seguido por una información adicional. •

+OK: el servidor indica al cliente que el comando recibido era correcto

•

-ERR: el servidor indica al cliente que había algo erróneo en el comando recibido. Ejemplo de una sesión de autenticación El siguiente es un ejemplo de una sesión de autenticación (una vez establecida la conexión al puerto TCP 110 del servidor de correo).

+OK POP3 server ready USER marques +OK PASS uoc +OK user successfully logged on

Conexión a un servidor de correo Si tenéis acceso a un servidor de correo que no requiera utilizar una conexión segura, os podéis intentar conectar con telnet servidorCorreo 110. El usuario puede configurar su agente de usuario –utilizando POP3– para que aplique la política "baja los mensajes y bórralos" o la política "baja los mensajes y deja copia de los mismos en el servidor".

(18)

El protocolo POP3 (Post Office Protocol versión 3) está especificado en el RFC 1939.

© FUOC • PID_00147724

52


Ejemplo de bajar y borrar los mensajes El agente de usuario obtiene una lista de los mensajes (LIST), y los va bajando (RETR) y borrando (DELE) uno a uno. Por claridad, identificamos las líneas emitidas por el agente de usuario con C: y por el servidor de correo con S:

C: S: S: S: S: C: S: S: S: C: S: C: S: S: S: C: S: C: S:

LIST +OK 2 messages (320 octets) 1 120 2 200 . RETR 1 +OK 120 octets < el servidor de POP3 envía el mensaje 1> . DELE 1 +OK message 1 deleted RETR 2 +OK 200 octets < el servidor de POP3 envía el mensaje 2> . DELE 2 +OK message 2 deleted QUIT +OK POP3 server signing off

Un problema del modo "baja los mensajes y bórralos" es que el correo se baja en un ordenador. Si el usuario posteriormente quiere acceder al correo desde otro ordenador no lo podrá hacer, ya que el servidor ya no contendrá los mensajes. Esto es problemático para usuarios que acostumbran a leer el correo desde diferentes ordenadores, por ejemplo el ordenador de casa, un ordenador portátil, el trabajo, etc. El servidor POP3 no guarda estado entre sesiones. 5.3.2. IMAP El protocolo IMAP19 es un protocolo de acceso a correo como el POP3, pero tiene muchas más funcionalidades. También es más complejo de implementar,

(19)

El IMAP está especificado en el RFC 3.501.

tanto en la parte cliente como en la parte del servidor. Los servidores IMAP20 asocian cada mensaje a una carpeta. Cuando un mensaje llega al servidor, este se asocia a la carpeta INBOX. Posteriormente, el receptor puede mover este mensaje a otra carpeta creada por el mismo usuario. También puede leerlo, borrarlo, etc. El protocolo IMAP proporciona comandos para permitir a los usuarios crear carpetas y para mover mensajes de una carpeta a otra. El IMAP también proporciona comandos que permiten a los usuarios hacer buscas de mensajes que satisfagan ciertos criterios en las carpetas remotas. De todo esto, ya se ve que los servidores IMAP deben mantener información entre sesiones IMAP: los nombres de las carpetas, qué mensajes están asociados a cada carpeta, etc.

(20)

IMAP es la abreviatura de Internet Mail Access Protocol.

© FUOC • PID_00147724

53

Otra característica interesante del IMAP es que tiene comandos que permiten al agente de usuario obtener partes de un mensaje: puede obtener sólo las cabeceras del mensaje, o sólo una parte de un mensaje multiparte (por ejemplo, el texto del mensaje sin el fichero adjunto). Esto es especialmente útil cuando se utiliza una conexión con poco ancho de banda. 5.3.3. Web Una manera muy popular de acceder al correo es mediante un navegador web. En este caso, el agente de usuario es el navegador web y el usuario se comunica con su buzón vía HTTP. De esta manera, cuando se quiere leer un mensaje el navegador lo obtiene del servidor de correo usando el protocolo HTTP, y cuando se quiere enviar un mensaje, el navegador lo envía al servidor de correo usando también el protocolo HTTP.


© FUOC • PID_00147724

54


6. Aplicaciones de igual a igual para la compartición de ficheros

La arquitectura de igual a igual es una manera de construir aplicaciones que persigue la utilización de los recursos informáticos y el ancho de banda que aportan los usuarios de la aplicación aunque estos estén conectados de manera intermitente. Las aplicaciones de igual a igual se han popularizado de la mano de las aplicaciones de compartición de ficheros. La primera fue Napster, pero la han ido siguiendo otras aplicaciones. En este material presentaremos varias, que nos tienen que ayudar a entender cómo funcionan estos tipos de aplicaciones. Cada una de estas aplicaciones utiliza su propia organización interna y sus propios protocolos. Los nodos que forman el sistema o aplicación de igual a igual se organizan formando una red superpuesta (overlay network, en inglés) que funciona sobre la red física que conecta los nodos. Hay diferentes maneras de organizar esta red superpuesta, las cuales se pueden dividir en dos categorías: estructuradas y no estructuradas. 6.1. Redes superpuestas no estructuradas Un sistema de igual a igual que utilice una red superpuesta del tipo no estructurado es un sistema que está compuesto de iguales que se conectan a la red sin conocer su topología. Estos sistemas usan mecanismos de inundación para enviar consultas mediante la red superpuesta. Cuando un igual recibe la pregunta, envía al igual que la ha originado una lista de todo el contenido que encaja con la pregunta. Aunque las técnicas basadas en la inundación van bien para localizar objetos altamente reproducidos y son resistentes ante las conexiones y desconexiones de los nodos, no tienen un comportamiento muy bueno cuando se hacen buscas de objetos poco reproducidos. De esta manera, las redes superpuestas no estructuradas tienen fundamentalmente un problema: cuando deben gestionar un ritmo elevado de consultas o cuando hay crecimientos repentinos del tamaño del sistema, se sobrecargan y tienen problemas de escalabilidad. A pesar de que el sistema de direccionamiento basado en claves que utilizan los sistemas de igual a igual estructurados –veremos este tipo de sistemas en el próximo subapartado– pueda localizar de manera eficiente objetos y, además, sea escalable, sufre sobrecargas significativamente mayores que los sistemas no estructurados por contenidos populares. Por este motivo, los sistemas descentralizados no estructurados se usan más.

Bibliografía recomendada En el artículo de Lua�y�otros (2005). "A survey and comparison of peer-to-peer overlay network schemes". IEEE Communications Surveys & Tutorials (vol. 7, núm. 2) encontraréis un resumen de cómo funcionan las redes superpuestas de igual a igual más populares, así como una comparativa entre estas. También encontraréis más detalle de los sistemas explicados en este apartado.

© FUOC • PID_00147724

55

Algunos ejemplos de sistemas no estructurados son Gnutella, FastTrack/KaZaA, BitTorrent y Overnet/eDonkey2000. Gnutella: protocolo totalmente descentralizado para hacer buscas sobre una topología de iguales totalmente plana. Ha sido (y todavía lo es) muy usado. Para localizar un objeto, un igual pregunta a sus vecinos. Estos inundan a sus vecinos y así hasta un cierto radio. Este mecanismo es extremadamente resistente ante entradas y salidas de nodos, pero los mecanismos actuales de busca no son escalables y generan cargas no esperadas en el sistema. La figura siguiente muestra un ejemplo de busca.

KaZaA: es un sistema de ficheros descentralizado en el que los nodos se agrupan en torno a superiguales (super-peers en inglés) para hacer las buscas más eficientes, tal y como se muestra en la figura siguiente. La comunicación entre los iguales en KaZaA se hace utilizando el protocolo Fast Track, que es un protocolo propietario. Los superiguales son iguales del sistema que se han elegido para que mantengan metainformación que hará las buscas más eficientes. En el momento de una busca, el igual pregunta al superigual al que está conectado. Este, de manera similar a lo que hace Gnutella, hace un broadcast a los otros superiguales.


© FUOC • PID_00147724

56


Los iguales se conectan a un superigual. Las consultas se encaminan hacia los superiguales. Las bajadas se hacen entre iguales. BitTorrent: es un sistema de igual a igual para distribuir grandes volúmenes de datos sin que el originador de la información tenga que soportar todo el coste de los recursos necesarios para servir el contenido. Este tipo de soluciones son útiles para distribuir contenidos que son muy populares. BitTorrent utiliza servidores para gestionar las bajadas. Estos servidores almacenan un fichero que contiene información sobre el fichero: longitud, nombre, información de resumen (hashing information, en inglés) y el URL del tracker. El tracker (podéis ver la figura siguiente) conoce todos los iguales que tienen el fichero (tanto de manera total como parcial) y hace que los iguales se conecten unos con otros para bajar o subir los ficheros. Cuando un nodo quiere bajar un fichero envía un mensaje al tracker, que le contesta con una lista aleatoria de nodos que están bajando el mismo fichero. BitTorrent parte los ficheros en trozos (de 256 kB) para saber qué tiene cada uno de los iguales. Cada igual que está bajando el fichero anuncia a sus iguales los trozos que tiene. El protocolo proporciona mecanismos para penalizar a los usuarios que obtienen información sin proporcionarla. De esta manera, a la hora de subir información, un igual elegirá otro igual del que haya recibido datos.

Bibliografía complementaria Para más información sobre el funcionamiento de BitTorrent, podéis consultar el artículo siguiente: B.�Cohen (2003, junio). "Incentives Build Robustness in BitTorrent". Proc. First Workshop the Economics of Peer-toPeer Systems. Berkeley, CA: University of Berkeley.

© FUOC • PID_00147724

57

eDonkey: es un sistema de igual a igual híbrido organizado en dos niveles para el almacenamiento de información. Está formado por clientes y servidores. Los servidores actúan como concentradores para los clientes y permiten a los usuarios localizar los ficheros que hay en la Red. Esta arquitectura proporciona bajada concurrente de un fichero desde distintas ubicaciones, uso de funciones resumen (hash, en inglés) para la detección de ficheros corruptos, compartición parcial de ficheros mientras se bajan y métodos expresivos para hacer buscas de ficheros. Para que un nodo se pueda conectar al sistema, es necesario que conozca un igual que actúe como servidor. En el proceso de conexión, el cliente proporciona al servidor la información sobre los ficheros que comparte. Cuando un cliente busca un fichero, los servidores proporcionan las ubicaciones de los ficheros. De esta manera, los clientes pueden bajar los ficheros directamente de las ubicaciones indicadas. eMule puede funcionar tanto sobre la red eDonkey como sobre Kad. Kad es una implementación de Kademlia, una red superpuesta estructurada (en el próximo apartado se explica cómo funcionan estos tipos de sistemas). 6.2. Redes superpuestas estructuradas La topología de la red superpuesta sobre la cual se construyen estos sistemas está fuertemente controlada y el contenido no va a cualquier lugar, sino a uno determinado que hace que las consultas sean más eficientes. Estos sistemas utilizan tablas de hash distribuidas (distributed hash tables o DHT, en inglés) como sustratos, en los cuales la ubicación de los objetos (o valores) se hace de manera determinista. Los sistemas que se basan en DHT tienen la propiedad de que asignan los identificadores de nodos de una manera consistente a los iguales dentro de un espacio con muchos identificadores. A los objetos de datos se les asigna un identificador, que se denomina clave, elegido dentro del mismo espacio de nombres. El protocolo de la red superpuesta mapea las claves en un único nodo entre los conectados. Estas redes superpuestas soportan el almacenamiento y la recuperación de pares {clave,valor} en la red superpuesta.


© FUOC • PID_00147724

58

Este tipo de sistemas usan un sistema de direccionamiento estructurado, manteniendo tanto la descentralización de Gnutella como la eficiencia y garantía de localizar los resultados de Napster. Por este motivo, cada igual mantiene una tabla de direccionamiento pequeña. Los mensajes se direccionan de una manera progresiva hacia los iguales a través de caminos de superposición. Cada nodo envía el mensaje al nodo de su tabla de direccionamiento que tiene un identificador más próximo a la clave en el espacio de identificadores. Los diferentes sistemas basados en DHT tienen distintos esquemas de organización para los objetos de datos y su espacio de claves y estrategias de direccionamiento. En teoría, los sistemas basados en DHT garantizan que, como media, se puede localizar cualquier objeto en O(log N) saltos en la red superpuesta, donde N es el número de iguales en el sistema. El camino entre dos nodos en la red física puede ser muy diferente del camino en la red superpuesta DHT. Esto puede provocar que la latencia en las buscas en un sistema de igual a igual basado en una red DHT sea bastante grande y pueda afectar negativamente al rendimiento de la aplicación que funcione por encima. Ejemplos de redes superpuestas estructuradas Can, Chord, Tapestry, Pastry, Kademlia, DKS o Viceroy son ejemplos de redes superpuestas estructuradas. Podéis encontrar más información de estos sistemas en: CAN S.�Ratnasamy�y�otros (2001). "A Scalable Content Addressable Network". Proc. ACM SIGCOMM (págs. 161-72). Chord I.�Stoica;�R.�Morris�y�otros (2003). "Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications". IEEE/ACM Trans. Net. (vol. 11, núm. 1, págs. 17-32). Tapestry B.�Y.�Zhao�y�otros (2004, enero). "Tapestry: A Resilient Global-Scale Overlay for Service Deployment". IEEE JSAC (vol. 22, núm. 1, págs. 41-53). Pastry A.�Rowstron;�P.�Druschel (2001). "Pastry: Scalable, Distributed Object Location and Routing for Large-scale Peer-to-peer Systems". Proc. Middleware. Kademlia P.� Maymounkov;� D.� Mazieres (2002, febrero). "Kademlia: A Peer-to-Peer Information System Based on the XOR Metric". Proc. IPTPS (págs. 53-65). Cambridge, MA: EE. UU. DKS DKS(N,k,f). A Familiy of Low Communication, Scalable and Fault-Tolerant Infrastructures for P2P Applications. Viceroy D.�Malkhi;�M.�Naor;�D.�Ratajczak (2002, julio). "Viceroy: A Scalable and Dynamic Emulation of the Butterfly". Proc. ACM PODC 2002 (págs. 183-92). Monterey, CA: EE. UU.


© FUOC • PID_00147724

59

eMule tiene una versión que funciona sobre la red Kad, que es una implementación de Kadmelia. Kad mejora la localización de ficheros en la Red y la hace más resistente a ataques a los servidores centrales.


60

© FUOC • PID_00147724


7. Mensajería instantánea

La mensajería instantánea es una forma de comunicación textual en tiempo real entre dos o más personas a través de Internet o algún otro tipo de red. La mensajería instantánea se diferencia del correo electrónico en que el usuario percibe sincronismo en la comunicación, aunque muchos de los sistemas de mensajería instantánea también permiten enviar mensajes a personas que en aquel momento no están conectadas. En este caso, el destinatario recibirá el mensaje cuando se vuelva a conectar al sistema. La mensajería instantánea permite una comunicación efectiva y eficiente y consigue una recepción inmediata de la confirmación o la respuesta. Normalmente, las respuestas se pueden guardar y consultar con posterioridad. Frecuentemente, combinado con la mensajería instantánea o en torno a la misma también encontramos otras funcionalidades que la hacen aún más completa y popular, como cámaras de vídeo o la posibilidad de hablar directamente mediante Internet. En este apartado, sin embargo, nos centraremos en la mensajería instantánea textual. 7.1. XMPP El XMPP21 es un protocolo libre de mensajería instantánea de especificaciones abiertas basado en el XML, y que ha sido estandarizado por la IETF. 22

Como se puede ver en la siguiente figura, el XMPP

utiliza una arquitectura

cliente-servidor descentralizada: de manera similar a como lo hace el SMTP,

(21)

XMPP es la abreviatura de Extensible Messaging Presence Protocol. El XMPP antes se conocía como jabber. (22)

El puerto estándar para el XMPP es el 5222.

no hay un servidor central que coordine la mensajería. Los clientes no se comunican directamente unos con otros, lo hacen mediante los servidores. De manera similar al correo electrónico, cada usuario tiene una dirección única formada por dos campos: un nombre de usuario (único para cada servidor) seguido de la dirección DNS del servidor que hospeda al usuario, separados por el símbolo @, como [email protected]. Los pasos para que un mensaje enviado por el cliente 7 (cliente7@server3) de la figura anterior llegue al cliente 3 (cliente3@server1) son los siguientes: 1) El cliente 7 envía el mensaje a su servidor (en este caso, el servidor 3). a) El servidor 3 pide al DNS la dirección IP correspondiente al servidor 1.

Arquitecturas centralizadas Otros sistemas de mensajería instantánea como Windows Live Messenger o AOL Instant Messenger utilizan arquitecturas centralizadas.

© FUOC • PID_00147724

61

b) Si el servidor 3 bloquea la comunicación hacia el servidor 1, el mensaje se descarta. 2) El servidor 3 obra una conexión con el servidor 1. a) Si el servidor 1 bloquea los mensajes procedentes del servidor 3, el mensaje se descarta. b) Si el cliente 3 no está conectado en estos momentos, el servidor 1 almacena el mensaje para entregarlo más adelante. 3) El servidor 1 entrega el mensaje al cliente 3.

Los puntos fuertes del protocolo XMPP son los siguientes. •

Descentralización: cualquiera puede tener un servidor XMPP. No hay un servidor centralizado que coordine la mensajería.

•

Estándares�libres: la Internet Engineering Task Force tiene el XMPP aprobado como un estándar de mensajería instantánea y presencia (RFC 3.920 y RFC 3.921).

•

Seguridad: los servidores XMPP se pueden aislar de la red XMPP pública (por ejemplo, en la intranet de una compañía), y el núcleo de XMPP incluye seguridad (vía SASL y TLS).


© FUOC • PID_00147724

•

62


Flexibilidad: por encima del XMPP, se pueden añadir funcionalidades a medida.

•

Al ser un protocolo abierto, cada usuario puede utilizar un cliente XMPP diferente, siempre y cuando cumpla las especificaciones del XMPP.

Los puntos débiles del protocolo XMPP son los siguientes. •

Overhead�de�la�información�de�presencia: en torno al 70% del tráfico entre servidores XMPP es información de presencia, cuyo 60% es redundante. La información de presencia permite saber qué amigos o contactos hay conectados y, por lo tanto, es posible enviar mensajes instantáneos.

•

La�inclusión�de�datos�binarios�es�ineficiente: XMPP se codifica como un

SASL El Simple Authentication and Security Layer (SASL) es un framework para la autenticación y la seguridad de los datos en protocolos de Internet. Separa los mecanismos de autenticación de los protocolos de aplicación haciendo posible –en teoría– que cualquier mecanismo de autenticación soportado por el SASL se pueda utilizar en cualquier protocolo de aplicación. Está especificado en el RFC 4.422.

único documento XML. Para incluir datos binarios, estos se deben codificar en base64. Cuando hay que enviar cantidades considerables de datos binarios (por ejemplo, envío de ficheros), lo mejor es hacer el envío de manera externa al XMPP y utilizar mensajes XMPP para coordinarse.

Jingle Jingle es una ampliación del XMPP para iniciar y gestionar sesiones multimedia entre dos entidades XMPP, de manera que sean interoperables con estándares existentes de Internet.

© FUOC • PID_00147724

63


8. Telnet y Secure Shell: acceso a ordenadores remotos

El protocolo Telnet23 se usa en Internet o en redes de área local para proporcionar una comunicación bidireccional interactiva en el acceso a ordenadores

(23)

La especificación de Telnet se publicó en el año 1983 en el estándar RFC 854.

remotos. Está basado en el protocolo de transporte TCP. En una comunicación Telnet, normalmente se sigue el modelo cliente-servidor, es decir, el sistema usuario establece una conexión con el sistema proveedor, que está esperando peticiones de conexión en un puerto determinado. Se puede utilizar cualquier número de puerto para las conexiones y, de hecho, hay muchas aplicaciones que utilizan el protocolo Telnet para la comunicación, cada una con su propio número. La aplicación básica, sin embargo, es establecer una sesión de trabajo interactiva con el sistema servidor. En este caso, el número de puerto utilizado es el 23. Esta sesión de trabajo en el ordenador remoto se hace vía un terminal virtual. Para resolver el problema del control del terminal en la aplicación de sesiones interactivas, en el protocolo Telnet se utiliza el concepto de terminal virtual de red o NVT. Un NVT es un terminal virtual con una funcionalidad muy básica, definida en la misma especificación del protocolo. Cuando se establece la conexión entre el cliente y el servidor, inicialmente se supone que la comunicación se produce entre dos NVT. Esto quiere decir que tanto el sistema cliente como el sistema servidor deben mapear sus características en las de un NVT y suponer que en el otro extremo de la conexión hay otro NVT. En el modo de operación normal, cada terminal acepta datos del usuario y los envía mediante la conexión establecida al otro terminal, y acepta también los datos que llegan por la conexión y los presenta al usuario. La comunicación se hace en bytes de 8 bits. 8.1. Seguridad del protocolo Telnet Telnet no es un protocolo seguro, por las razones siguientes: •

No cifra ningún dato enviado a través de la conexión (ni las claves de acceso), y esto permite espiar la comunicación y poder utilizar la clave de acceso –así como cualquier otra información enviada– más adelante para usos malintencionados.

•

La mayoría de las implementaciones de Telnet no proporcionan autenticación que asegure que la comunicación se lleva a cabo entre los dos ordenadores deseados y no está interceptada por el camino.

Terminal virtual de red Un terminal virtual de red, en inglés Network Virtual Terminal (NVT), es un dispositivo imaginario por el cual se definen unas funciones de control canónicas, de manera que se puede establecer una correspondencia entre estas funciones y las de cada tipo de terminal real.

© FUOC • PID_00147724

64


8.2. Secure Shell

La solución a la falta de seguridad del protocolo Telnet ha sido el protocolo Secure Shell (SSH).

El SSH proporciona la funcionalidad de Telnet con los añadidos siguientes: a) Permite el cifrado para evitar que sea posible interceptar los datos que se envían. b) Permite la autenticación con clave pública para asegurar que el ordenador remoto es quien dice ser. El SSH tiene la debilidad de que el usuario debe confiar en la primera sesión con un ordenador cuando todavía no ha adquirido la clave pública del servidor.

Puerto TCP 22 El puerto estándar para contactar a un servidor SSH es el puerto TCP 22.

© FUOC • PID_00147724

65


9. Aplicaciones multimedia en red

Las aplicaciones multimedia en red tienen unos requerimientos muy diferentes a los de las aplicaciones tradicionales en la red Internet (correo electrónico, transferencia de ficheros, etc.). Si tenemos en cuenta dos de los requerimientos más relevantes que tienen las aplicaciones de red, como son la tolerancia a pérdidas de datos y las consideraciones temporales, nos damos cuenta de que estos son especialmente importantes para las aplicaciones multimedia en red. Con respecto a la pérdida de datos, se tiene que decir que las aplicaciones multimedia son muy tolerantes: las pérdidas ocasionales de datos lo único que hacen es que haya un salto en la imagen o en el sonido; sin embargo, si se continúa recibiendo información, se puede continuar normalmente la comunicación. Por el contrario, se trata de aplicaciones muy sensibles al retraso, lo cual hace que las consideraciones temporales se deban tener muy en cuenta. Así pues, a lo largo de los subapartados siguientes veremos que los paquetes que llegan con un retraso de más de unos centenares de milisegundos no sirven para nada en una aplicación multimedia y se pueden descartar (un sonido que se ha emitido hace dos segundos con respecto a lo que se está escuchando o una imagen que ya ha pasado no hay que mostrarlos al usuario). Estas características de alta tolerancia a pérdidas y mucha sensibilidad al retraso hacen que las aplicaciones multimedia sean muy diferentes a las aplicaciones tradicionales, en las que es mucho más importante que lleguen todos los datos (si falta alguna parte, la información recibida será inservible) que el tiempo que estos datos tarden en llegar al destinatario (que puede hacer que la experiencia de usuario no sea muy buena, pero si al final recibe todos los datos, habrá cumplido los requerimientos). En los próximos subapartados veremos algunos ejemplos de aplicaciones multimedia y qué nos podemos encontrar actualmente en Internet para el soporte de estas aplicaciones. 9.1. Ejemplos de aplicaciones multimedia Hay muchos tipos de aplicaciones multimedia actualmente en la red Internet. En este subapartado describiremos brevemente tres de los grandes tipos de aplicaciones multimedia que nos podemos encontrar: streaming de audio / vídeo almacenados, streaming en directo de audio / vídeo y audio / vídeo en tiempo real interactivo. Ninguna de estas aplicaciones cubre el caso en el que nos bajamos un contenido y después lo vemos. Este caso tiene que ver con la transferencia de ficheros que se puede hacer con protocolos como HTTP (Hypertext Transfer Protocol) y FTP (File Transfer Protocol).

Ved también Para una descripción completa de los requerimientos de las aplicaciones en red, podéis ver en este mismo módulo el subapartado 1.4, "Requerimientos de las aplicaciones".

© FUOC • PID_00147724

66

9.1.1. Streaming de audio y vídeo almacenados En este tipo de aplicaciones, los clientes piden contenidos de audio y vídeo comprimidos almacenados en servidores. Estos contenidos pueden ser, por ejemplo, programas de televisión, vídeos caseros, canciones, sinfonías o programas de radio. Esta clase de aplicaciones tienen tres características distintivas. •

Contenidos�almacenados: el contenido multimedia está ya grabado y se almacena en el servidor. Como resultado, el usuario puede detener la reproducción, rebobinar o indexar el contenido. El tiempo de respuesta de un contenido de este tipo puede ir de uno a diez segundos para ser aceptable.

•

Streaming: cuando un usuario recibe un contenido con la técnica del streaming, la reproducción empieza poco después de haber hecho la petición del contenido. De esta manera, el usuario ve una parte del contenido, mientras que el resto se va recibiendo a medida que se reproduce. En este caso, el tiempo de respuesta es más bajo. Con esta técnica evitamos el retraso que podemos tener si debemos bajarnos todo el contenido.

•

Reproducción�continua: una vez la reproducción del contenido multimedia empieza, tiene que transcurrir tal y como se grabó originalmente. Esto hace que haya unos fuertes requerimientos de retraso en la entrega de los datos en este tipo de aplicación. La aplicación de usuario debe recibir a tiempo los datos del servidor para poder hacer la reproducción de manera correcta. Aunque esta aplicación tiene unos requerimientos de retraso importantes, no son tan fuertes como para el streaming en directo o las aplicaciones de tiempo real, que veremos a continuación.

9.2. Streaming en directo de audio y vídeo Este tipo de aplicaciones funcionan como el broadcast tradicional de radio y televisión –un emisor transmite a muchos receptores–, sólo que se hace por Internet. Con este tipo de streaming se pueden recibir emisiones de radio y televisión en directo desde cualquier punto del mundo. Puesto que en el streaming de audio y vídeo la información no está almacenada, el usuario no puede tirar adelante la reproducción del contenido recibido. Lo que sí permiten algunas aplicaciones es parar la reproducción e incluso ir hacia atrás (aunque esto último sólo es posible si se ha almacenado el contenido en el disco del usuario mientras se iba reproduciendo).


© FUOC • PID_00147724

67


Aunque para enviar este tipo de streams se podrían utilizar conexiones multicast (un emisor transmite a diferentes receptores en una única conexión), la verdad es que se hacen múltiples conexiones unicast (una conexión para cada receptor). Se requiere una reproducción continuada, pero los requerimientos de interactividad no son tan críticos como las aplicaciones interactivas en tiempo real y pueden aceptarse retrasos en el inicio de la reproducción de hasta diez segundos. 9.2.1. Audio y vídeo en tiempo real interactivo Este tipo de aplicaciones permiten que los usuarios interactúen en tiempo real. Actualmente, hay bastantes aplicaciones de este tipo que permiten que los usuarios hagan audio o videoconferencias mediante Internet. Windows Messenger, Google Talk o Skype son algunos ejemplos de aplicaciones que permiten establecer conexiones de audio y/o vídeo. Algunas de estas aplicaciones también permiten llevar a cabo llamadas telefónicas a teléfonos fijos o móviles

Direcciones web recomendadas Aplicaciones de audio y vídeo interactivo: Windows Messenger: http:/ / www.microsoft.com/windows/messenger/features.asp

(haciendo un pequeño pago), como es el caso de Skype.

Google Talk: http:// www.google.com/talk/ intl/ se/

El retraso permitido en estas aplicaciones no debe ser mayor que unos cente-

Skype: http:// www.skype.com/intl/es/

nares de milisegundos. Así pues, retrasos de más de 400 milisegundos harían que una comunicación de voz fuera prácticamente imposible. 9.3. Multimedia en Internet IP es un protocolo de tipo best effort, es decir, que intenta entregar los paquetes tan pronto como puede, pero sin dar ninguna garantía. Los protocolos de transporte TCP/UDP funcionan sobre IP, y por lo tanto tampoco pueden dar garantías de cuándo llegará un determinado paquete a su destino. Por este motivo, el envío de datos multimedia por Internet es una tarea difícil de que ha tenido hasta ahora un éxito limitado. En las aplicaciones de streaming de audio y vídeo almacenados, retrasos de entre cinco y diez segundos pueden ser aceptables. Así pues, si no se produce un pico de tráfico o los paquetes no deben pasar por enlaces congestionados, podremos disfrutar del streaming de manera satisfactoria. Por otra parte, el uso de las aplicaciones de streaming interactivo de audio y vídeo hasta ahora no ha sido tan satisfactorio a causa de las restricciones en el retraso de los paquetes y en el denominado paquet jitter. El paquet jitter es la variabilidad que pueden tener los retrasos de paquetes enviados entre un origen y un destino dentro del mismo stream. Puesto que el audio y el vídeo se deben reproducir con la misma temporización con la cual se grabaron, el

© FUOC • PID_00147724

68

jitter se tiene que eliminar antes de hacer la reproducción de los datos. El reproductor debe almacenar los paquetes por un corto periodo de tiempo para eliminar el jitter antes de reproducir el stream. Con el fin de eliminar el jitter, habitualmente se combinan tres mecanismos: 1) Añadir un número de secuencia a cada paquete de datos enviado. El emisor incrementa este número en cada paquete enviado. 2) Añadir un timestamp a cada paquete. El emisor pone en cada paquete el momento en el que se generó. 3) Retrasar la reproducción del paquete en el receptor. El retraso en la reproducción tiene que ser lo bastante grande como para garantizar que los paquetes se han recibido antes del momento de su reproducción. Este retraso puede ser fijo o adaptativo a lo largo de la sesión. Los paquetes que no llegan antes del momento de su reproducción se consideran perdidos y se descartan. Con estos tres mecanismos, se pueden utilizar dos técnicas de reproducción dependientes del retraso: retraso�fijo o retraso�adaptativo en el momento de la reproducción de los datos. El retraso fijo consiste en reproducir el paquete de datos exactamente x milisegundos después de la creación del paquete de datos. Así pues, si el timestamp del paquete era t, su reproducción se tiene que hacer en el instante t + x, siempre que el paquete haya llegado antes de este momento. El valor de x depende de la aplicación, pero para telefonía por Internet es posible soportar hasta 400 milisegundos. Si es menos, se produce el riesgo de que no lleguen. El retraso adaptativo consiste en adaptarse a las condiciones de pérdida de paquetes y retrasos que tengamos durante la comunicación. La manera de hacer esto es calcular el retraso de la red y la variación del retraso e ir ajustando el retraso en la reproducción de acuerdo con estos datos. El streaming interactivo funciona bien si se dispone de un buen ancho de banda, en el que el retraso y el jitter son pequeños. Las aplicaciones multimedia funcionarían mejor en la red Internet si existiera la posibilidad de reservar una parte del ancho de banda para el envío de este tipo de información. Sin embargo, esto no parece que tenga que suceder, al menos de momento. Por esto, es necesario utilizar algún otro tipo de técnicas, como por ejemplo usar UDP en lugar de TCP para el envío de los datos, introducir retrasos en el envío de los datos o, si se trata de streaming de contenidos almacenados, enviar datos de antemano (utilizando técnicas de buffering) cuando la conexión lo permite. Incluso se puede enviar información redundante para mitigar los efectos de la pérdida de paquetes.


© FUOC • PID_00147724

69

Puesto que para este tipo de datos no es muy adecuado reenviar los paquetes, lo que se hace es utilizar otras técnicas de recuperación de errores, como son forward error correction (FEC) e interleaving. El FEC consiste en enviar datos redundantes al stream original. De esta manera, se pueden reconstruir versiones aproximadas de los paquetes originales perdidos. Una manera de hacer FEC es enviar un paquete redundante cada n paquetes. Esto hace que si se pierde un paquete de estos n, se pueda recuperar. Si se pierden más, entonces esto ya no es posible. De todos modos, si se envían muchos paquetes redundantes hay más retraso. La otra técnica para hacer FEC es enviar los datos redundantes en un stream con calidad más baja. Si se pierde un paquete del stream original, entonces se toma el paquete del stream de baja calidad y se reproduce en el momento que le toca. De esta manera, aunque se mezclen paquetes de alta y baja calidad, no se pierde ningún paquete y la experiencia del usuario es bastante buena. El interleaving consiste en que el emisor envía los paquetes en un orden diferente del de su reproducción, para minimizar las pérdidas en un grupo de paquetes. De esta manera se reducen las pérdidas, pero no es una técnica adecuada para audio y vídeo interactivo, por el retraso en la recepción de los datos; sin embargo, sí funcionaría bien para audio y vídeo almacenados. La ventaja de esta técnica es que no se necesita más ancho de banda, ya que el stream enviado es el mismo. 9.3.1. Compresión de audio y vídeo Para enviar datos multimedia (audio y vídeo) por Internet es necesario digitalizar y comprimir estos datos. La razón por la cual hay que digitalizar los datos es muy sencilla: las redes de ordenadores transmiten bits; así pues, toda la información que se transmite tiene que estar representada con bits. La compresión es importante porque el audio y el vídeo sin comprimir ocupan mucho espacio, con el consumo de ancho de banda que esto implica. Eliminar la redundancia en las señales de audio y vídeo reduce en varios órdenes de magnitud el ancho de banda que se necesita para transmitir la información.

El�ancho�de�banda�necesario�y�la�compresión Una imagen de 1.024 píxeles –en la que cada píxel se presenta con 24 bits, 8 para los colores rojo, azul y verde– necesita 3 MB sin compresión. Si se aplica una tasa de compresión de 1:10, tendremos que esta misma imagen necesita 300 KB para ser representada. Suponiendo que tuviéramos que enviar las dos imágenes por un canal de 64 kbps, en el primer caso tardaría 7 minutos en enviarse, mientras que en el segundo el tiempo de transmisión se reduce en un factor de 10.


© FUOC • PID_00147724

70


Compresión de audio La compresión de tipo PCM�(pulse�code�modulation) se basa en la recogida de muestras de audio a una frecuencia determinada. El valor de cada muestra es un número real arbitrario. El valor de cada muestra se redondea a un determinado valor finito (tenemos un número de valores finitos para las muestras). Cada uno de estos valores se representa con un número finito de bits, que depende del número de valores que pueden tomar las muestras. Por ejemplo, si se tienen 256 posibles valores de muestras, utilizaríamos un byte para representarlas. Para el caso de la PCM, se toman 8.000 muestras por segundo y cada muestra se representa con 8 bits. Esto nos da una señal digital con una tasa de 64.000 bits por segundo. La señal digital puede descodificarse y convertirse de nuevo en una señal analógica, pero esta señal será diferente de la señal analógica original como consecuencia del muestreo. Si se recogen más muestras y se toman más valores posibles para estas muestras, la señal analógica descodificada será mucho más parecida a la señal original. Aunque la velocidad de las conexiones en Internet ha mejorado (recordemos que un módem proporcionaba una velocidad máxima de 56 kbps), la compresión de audio y vídeo es todavía muy importante. Así pues, podemos encontrar algunos ejemplos de compresión de voz con tasas de bits más bajas como GSM (13 kbps) o G.729 (8 kbps). Para la compresión de sonido con calidad casi de CD, la técnica más popular es el estándar de compresión MPEG 1 Layer 3, más conocido como MP3. Las tasas de compresión de MP3 suelen ser 96 kbps, 128 kbps y 160 kbps, con poca degradación del sonido. Compresión de vídeo El vídeo es una sucesión de imágenes, transmitidas a una tasa constante, como 24 o 30 imágenes por segundo. Una imagen sin comprimir es una sucesión de píxeles, en la que cada píxel se representa con un número de bits que indican color y luminosidad. Hay dos tipos de redundancia en los vídeos que se pueden aprovechar para comprimir: redundancia espacial y redundancia temporal. La redundancia espacial consiste en tener repeticiones dentro de la misma imagen y la temporal, en redundancia entre imágenes consecutivas. Para vídeo, los estándares de compresión MPEG son también los más populares. Estos incluyen MPEG 1 para la compresión con calidad de CD de vídeo (1,5 Mbps), MPEG 2 para calidad de DVD (3-6 Mbps) y MPEG 4 para compresión orientada a objetos. Las técnicas de compresión MPEG se basan en el hecho de explotar la redundancia temporal entre imágenes además de la compresión

Ejemplos en el uso de la PCM Algunos ejemplos en el uso de la PCM son la codificación de voz con 8.000 muestras/ segundo y 8 bits/muestra, lo que da una tasa de 64 kbps. El CD de audio también utiliza la PCM, con 44.100 muestras/segundo y 16 bits/muestra. Esto da una tasa de 705,6 kbps para canales mono y 1,411 Mbps para estéreo.

© FUOC • PID_00147724

71


que tiene en cuenta la redundancia espacial que ya proporciona JPEG. Otros estándares de compresión de vídeo son H.261 o Quicktime (este último es un formato propietario de Apple). 9.3.2. Formatos de audio y vídeo Existen muchos formatos diferentes de audio y vídeo, y aquí presentaremos los más conocidos y utilizados. Los formatos de vídeo más conocidos para trabajar en la red Internet son Quicktime Movie (Apple), Real Media (Real Networks), Windows Media (Microsoft), Audio/Video Interleaved (Microsoft), MPEG (mpg) y Flash Video (Adobe). A continuación, hacemos un resumen de sus características principales. •

Quicktime�Movie: originalmente estaba pensado como formato de vídeo, pero ahora se puede utilizar para contener cualquier tipo de medio (imágenes, audio, vídeo, Flash, etc.). Es un formato propietario de Apple. Es posible hacer streaming de este formato utilizando algún servidor de streaming dedicado. Se puede simular también el streaming sobre HTTP si se utiliza FastStart, que hace que el vídeo se empiece a reproducir al mismo tiempo que se está bajando.

•

Real�Media: es uno de los formatos más utilizados para hacer streaming. Se trata de un formato propietario de la compañía Real Networks y hay que tener un sistema Real Media para poder hacer el streaming. También permite hacer seudostreaming vía HTTP.

•

Windows�Media: se trata del formato de vídeo creado por Microsoft. Hay dos formatos, Windows Media Video (.wmv) y Advanced Streaming Format (.asf). Se necesita un servidor de tipo Windows Media Server para crear este tipo de ficheros. Permite hacer streaming y transmisiones de vídeo en directo.

•

Audio/Video� Interleaved: es un formato de vídeo creado también por Microsoft para su Video For Windows (VFW), la arquitectura multimedia de Windows 95. Ha sido sustituido por el formato Windows Media. Con este formato no se puede hacer streaming, hay que bajar el contenido y después reproducirlo.

•

MPEG: formato estándar definido por el Moving Picture Experts Group (MPEG). Soporta tres tipos de información: audio, vídeo y streaming (que significa que soporta audio y vídeo sincronizados). Este formato ofrece una alta compresión con pocas pérdidas.

•

Flash�Video: es un formato de vídeo creado por Flash (.flv) que permite hacer streaming. Funciona con la aplicación Flash Player, lo cual hace que no se necesite un reproductor dedicado para poder ver los vídeos. Además,

Bibliografía recomendada Más información sobre los formatos de audio y vídeo: J.�Niederst (2006). Web Design in a Nutshell (3.ª ed.). Sebastopol: O'Reilly.

© FUOC • PID_00147724

72

permite las mismas características de interactividad que ahora ofrecen las animaciones hechas con Flash (ficheros .swf). Los formatos de audio más conocidos para trabajar en la red Internet son WAV/ AIFF, MP3, Quicktime Audio (Apple), MIDI, Real Media Audio (Real Networks), Windows Media Audio (Microsoft) y Flash (Adobe). A continuación hacemos un resumen de sus características principales. •

WAV/AIFF: estos dos formatos tienen características muy similares. El Waveform Audio Format (.wav) fue originalmente diseñado para los sistemas operativos Windows, mientras que el Audio Interchange File Format (.aiff) fue diseñado para sistemas Apple. Ahora ya no se utilizan tanto, ya que hay otros formatos que ofrecen más compresión con una calidad parecida, como por ejemplo el MP3. No permiten hacer streaming, pero son los formatos que se utilizan como base para otros formatos (como RealAudio). Si se comprimen, pierden mucha calidad de sonido.

•

MP3: se trata del formato más popular en la red Internet. Ofrece una muy buena calidad de sonido, al mismo tiempo que permite hacer una alta compresión de datos. Sigue el estándar MPEG-1 Nivel-III y se basa en comprimir la información partiendo de la percepción auditiva de las personas. Se puede hacer streaming de este formato y también se puede bajar con HTTP o FTP.

•

Quicktime�Audio: aunque el formato Quicktime está pensado para vídeo, también permite incluir audio. Este formato permite hacer streaming y seudostreaming con HTTP, además de poder bajarse.

•

MIDI: quiere decir Musical Instrument Digital Interface y se trata de un tipo diferente de formato de audio de los vistos hasta ahora. Se diseñó inicialmente como estándar para que los instrumentos musicales electrónicos se pudieran comunicar entre los mismos. No contiene información de audio, sino órdenes de cómo se tendrían que tocar las diferentes notas, con instrucciones sobre longitud y volumen. Los ficheros MIDI ocupan muy poco y son ideales para conexiones con un ancho de banda bajo. No se puede hacer streaming de este formato.

•

Real�Media�Audio: fue uno de los primeros formatos que permitían hacer streaming de audio mediante la Red. Necesita un servidor dedicado, el RealServer, que permite negociar el ancho de banda y la transmisión RTSP. Se puede hacer seudostreaming de este formato con un servidor HTTP, si hay un tráfico limitado.

•

Windows�Media�Audio: es el formato de audio para streaming creado por Microsoft. Hay dos opciones: Windows Media Audio (.wma), que no permite streaming, y Active Streaming File (.asf) para streaming. El codec para


© FUOC • PID_00147724

73

este formato es propietario y se necesita un servidor dedicado para hacer streaming. •

Flash: se trata de un formato que permite añadir sonidos de fondo a las páginas HTML y, además, da características de interactividad y animación. En este caso, no hay retrasos en la reproducción y, una vez bajado el fichero Flash, la interactividad y el sonido están permanentemente disponibles.


© FUOC • PID_00147724

74

10. Streaming de audio y vídeo almacenados

Las aplicaciones de streaming de audio y vídeo se han popularizado en los últimos años por diferentes motivos. Por una parte, los usuarios tienen cada vez más capacidad de almacenamiento y también redes con mayor ancho de banda, que permiten recibir la información multimedia pedida en un corto espacio de tiempo. Sin embargo, para recibir los datos de streaming hay que tener una aplicación dedicada (lo que se conoce como media player o reproductor), que sea capaz de ofrecer las características siguientes. •

Descompresión: los datos audio y vídeo están casi siempre comprimidos para ahorrar espacio de disco y ancho de banda. El reproductor deberá descomprimir el audio y el vídeo a medida que se reciben.

•

Eliminación�del�jitter: el paquete jitter es la variabilidad del retraso que hay entre origen y destino dentro de un mismo stream. Puesto que el audio y el vídeo se tienen que reproducir con la misma temporización con la cual se grabaron, el jitter se debe eliminar antes de hacer la reproducción. El receptor almacenará los paquetes por un corto periodo de tiempo para que sea posible eliminar el jitter antes de reproducir el stream.

•

Corrección�de�errores: a causa de los errores imprevisibles en la red, una parte de los paquetes se podría perder. Si se pierden demasiados paquetes, entonces la calidad del stream recibido es inaceptable. Algunas técnicas para recuperar los datos perdidos son las siguientes. –

Reconstruir los paquetes perdidos mediante el envío de paquetes redundantes.

–

Hacer que el cliente pida de manera explícita los paquetes perdidos.

–

Interpolar los datos perdidos a partir de los datos recibidos.

En los siguientes subapartados veremos dos maneras de hacer streaming de audio y vídeo almacenados. La primera consiste en utilizar un servidor de web tradicional, en el que el audio y el vídeo están almacenados en el sistema de ficheros. La otra manera de recibir un stream es el uso de un protocolo de streaming específico, como es el Real Time Streaming Protocol (RTSP).


© FUOC • PID_00147724

75

10.1. Acceso vía servidor de web Desde el punto de vista de un servidor de web, los ficheros de audio y vídeo son objetos accesibles desde el servidor como cualquier otro tipo de fichero, como una página HTML o una imagen. Así pues, el usuario utilizaría su navegador para acceder al fichero de audio o vídeo. Este acceso establecería una conexión TCP con el servidor y, una vez establecida esta conexión, pediría el recurso (fichero de audio o vídeo) con un mensaje de petición HTTP con la correspondiente orden HTTP (podría ser una orden GET). El servidor genera un mensaje de respuesta, en el que estará encapsulado el fichero pedido. La recepción de este fichero hará que se abra el programa reproductor y, cuando este tenga bastantes datos, empezará a reproducir el fichero recibido. La figura siguiente muestra de manera muy simple cómo se produciría esta comunicación.

1) El usuario pide con su navegador un archivo multimedia (por ejemplo, haciendo clic en un enlace web). Esta petición genera un mensaje de petición HTTP. 2) El servidor busca el recurso en su sistema de ficheros y lo envía al navegador del cliente. Esta respuesta viaja en un mensaje de respuesta HTTP.


© FUOC • PID_00147724

76


3) El navegador guarda los datos en el disco y estos datos son reproducidos por un reproductor de archivos multimedia, que deberá descomprimir los datos, eliminar los retrasos y solucionar los errores de datos que se hayan podido producir. En este caso, encontramos el problema de que hasta que el navegador no recibe el objeto multimedia entero, no lo puede pasar al reproductor. Si el archivo es muy grande, el retraso será inaceptable. Por este motivo, lo que se hace normalmente es que el servidor de web se comunique directamente con el reproductor y le envíe los datos. De esta manera, el reproductor recibe los datos y cuando tiene suficientes para reproducir el contenido, empieza a hacerlo, al mismo tiempo que continúa recibiendo datos. La manera de hacer que el servidor web se conecte directamente con el reproductor es sustituyendo el recurso multimedia por un fichero de metadatos, que contiene la información de dónde se encuentra el recurso multimedia del que se tiene que hacer streaming e incluso del tipo de codificación. De esta manera, el navegador recibe un fichero de metadatos, que pasa al reproductor y este se encarga de conectar con la dirección contenida en el fichero de metadatos. Así pues, el inicio de la reproducción puede empezar mucho antes de haber recibido todo el fichero multimedia. 10.2. Real Time Streaming Protocol (RTSP) El protocolo RTSP24 establece y controla tanto uno como varios streams sincronizados de datos multimedia, como pueden ser el audio y el vídeo. No hace

(24)

El RFC que define el RTSP es el 2.326.

el envío de los datos, aunque el envío de información de control en medio de la transmisión de datos es posible. Lo que hace el RTSP es de control remoto a través de la Red para los servidores de datos multimedia. En el RTSP no hay conexiones, lo que tenemos son sesiones mantenidas por el servidor. Cada sesión tiene su identificador. Una sesión RTSP no está vinculada a una conexión de nivel de transporte. Esto quiere decir que, durante una sesión RTSP, se pueden abrir y cerrar tantas sesiones de transporte como sea necesario. También se puede utilizar UDP como protocolo de transporte, un protocolo sin conexión. Los streams controlados por el RTSP pueden utilizar RTP, pero el funcionamiento del RTSP no depende del mecanismo de control utilizado para enviar los datos multimedia. El protocolo RTSP es muy parecido al protocolo HTTP/1.1 (la versión 1.1 del protocolo HTTP), lo cual hace que se puedan añadir mecanismos de extensión para el HTTP que también se pueden aplicar al RTSP. Sin embargo, el RTSP es diferente del HTTP en un buen número de aspectos importantes.

Ved también Sobre el RTP, podéis ver más adelante el subapartado 11.1 de este módulo didáctico.

© FUOC • PID_00147724

•

77

El RTSP introduce métodos nuevos y tiene un identificador de protocolo propio (rtsp://).

•

Un servidor RTSP tiene que mantener el estado en la mayoría de los casos, justo al contrario de lo que hace el HTTP.

•

Tanto el cliente como el servidor RTSP pueden hacer peticiones.

•

Los datos los transporta un protocolo diferente del RTSP.

•

El URI de petición del RTSP siempre contiene el URI absoluto. En el HTTP, el URI de petición sólo lleva la ruta absoluta al fichero y el nombre del servidor va en una cabecera aparte.

El protocolo soporta las operaciones siguientes. a) Recuperación de datos del servidor de contenidos multimedia: el cliente puede pedir una descripción de una presentación vía HTTP o cualquier otro método. Si la presentación se está emitiendo en multicast, la descripción de esta contiene su dirección multicast y los puertos que se utilizarán. Si la presentación se envía en unicast sólo a este cliente, el cliente da el destino por motivos de seguridad. b) Invitación de un servidor de datos a una conferencia: un servidor de datos puede ser invitado a unirse a una conferencia existente, tanto para reproducir datos en la presentación o para grabar todos o una parte de los datos transmitidos en la presentación. Este modo es muy útil para aplicaciones de enseñanza distribuida. Muchos participantes pueden tomar parte en las mismas, pulsando los botones de control remoto. c) Añadir contenido a una presentación existente: es muy útil especialmente para el caso de presentaciones en directo, ya que el servidor le puede decir al cliente que hay nuevos datos disponibles. Un fichero de descripción de una presentación sería un ejemplo de lo que en la distribución de contenidos mediante un servidor de web hemos denominado un fichero de metadatos. Este fichero contiene una descripción de los streams que forman parte de la presentación, incluyendo el lenguaje de codificación y otros parámetros que ayudan al usuario a elegir la mejor combinación de datos. Cada contenido (por ejemplo, el audio y el vídeo se podrían transmitir en streams separados) tiene su propia URL, que apunta a un determinado contenido dentro de un determinado servidor. El fichero también describe los métodos de transporte que se soportan. Además de los datos del contenido, la descripción de la dirección destino de la red y el puerto se tiene que determinar. Hay diferentes modos de operación.


© FUOC • PID_00147724

78

1) Unicast: los datos se transmiten al origen de la petición RTSP, en el número de puerto seleccionado por el cliente. 2) Multicast (el servidor elige dirección): el servidor selecciona la dirección multicast y el puerto. Este caso es el típico para transmisiones de datos multimedia en directo. 3) Multicast (el cliente elige dirección): si el servidor participa en una conferencia multicast existente, la dirección multicast, el puerto y la clave de cifrado vienen dados por la descripción de la conferencia. 10.2.1. Los estados del RTSP El RTSP controla streams que se pueden enviar por un protocolo separado, independiente del protocolo de control. También puede pasar que el RTSP funcione sobre conexiones TCP, mientras que los datos se envían por UDP. Así pues, la transmisión de datos continúa ocurriendo aunque no se envíen datos de control RTSP. Otra posibilidad es que un stream de datos esté controlado por peticiones RTSP y que estas peticiones viajen en diferentes conexiones TCP. Por todas estas razones, es necesario mantener el estado de la sesión RTSP, con el objetivo de correlacionar las peticiones que se refieren al mismo stream. 10.2.2. Diagrama de estados del cliente El cliente puede estar en cuatro estados posibles: Init, Ready, Playing y Recording. El estado Init indica que el cliente ha enviado una orden SETUP y espera respuesta. El estado Ready indica que, o se ha recibido una respuesta afirmativa a SETUP, o se ha recibido una confirmación al envío de la orden PAUSE estando en Playing o Recording. Los estados Playing y Recording indican que se ha recibido una confirmación afirmativa a las órdenes PLAY y RECORD, de manera respectiva. La figura siguiente muestra los estados por los cuales ha pasado el cliente, como respuesta a las órdenes que envía. Las transiciones se producen cuando el cliente recibe una confirmación positiva a la orden enviada (la orden se indica en la flecha correspondiente).


© FUOC • PID_00147724

79

10.2.3. Diagrama de estados del servidor El servidor puede estar en cuatro estados posibles: Init, Ready, Playing y Recording. El estado Init indica que el servidor está a la espera de recibir una orden SETUP correcta. Es el estado inicial. El estado Ready indica que el último SETUP recibido fue correcto y se envió la confirmación correspondiente, o que en los estados Playing y Recording la orden PAUSE se recibió y se confirmó. El estado Playing indica que se ha recibido la orden PLAY y se confirmó y que se están enviando los datos al cliente. El estado Recording indica que el servidor está grabando los datos. La figura siguiente muestra los estados por los cuales ha pasado el servidor, como respuesta a las órdenes que recibe (y de las cuales envía confirmación al cliente). Las transiciones se producen cuando el servidor recibe una orden y ha enviado una confirmación positiva (la orden se indica en la flecha correspondiente).


© FUOC • PID_00147724

80

10.2.4. Métodos RTSP Los métodos RTSP siguientes son los más relevantes a la hora de cambiar de estado y de hacer la reserva de recursos para el stream en el lado servidor. •

SETUP: el servidor reserva recursos para un stream e inicia una sesión RTSP.

•

PLAY y RECORD: se inicia la transmisión de datos de un stream inicializado con SETUP.

•

PAUSE: detiene temporalmente la transmisión de datos, sin liberar los recursos del servidor.

•

TEARDOWN: libera los recursos asociados al stream. La sesión RTSP se borra del servidor.

Los métodos RTSP que modifican el estado de la sesión utilizan el campo Sesión de la cabecera RTSP, que veremos en el subapartado siguiente. Para consultar la lista entera de métodos, podéis ver el RFC del RTSP. 10.2.5. El protocolo RTSP En este subapartado veremos el protocolo RTSP, incluyendo el formato del mensaje de petición y respuesta y los campos de cabecera. Muchas de las características del protocolo se heredan del HTTP, pero aquí haremos una descripción completa. El URL del protocolo RTSP tiene la forma siguiente: Esquemas RTSP En RTSP, los URL pueden empezar con RTSP o RTSPU. El uso de RTSP indica que funciona sobre un nivel de transporte fiable (TCP), mientras que RTSPU indica que el protocolo funciona sobre un nivel de transporte no fiable (UDP).

rtsp://host:port/cami/al/recurso

Ejemplo:

rtsp://servidor.multimedia.com:554/programa_tv.html

Los URL tendrían que evitar utilizar direcciones IP en lugar del nombre del host, y pueden referirse a un único stream o a una serie de streams agregados.


© FUOC • PID_00147724

81


El RTSP es un protocolo basado en mensajes de texto. Esto facilita su implementación y ampliación (sólo hay que definir un nuevo método o una nueva cabecera). A continuación, veremos el formato de los mensajes de petición y respuesta de RTSP. 10.2.6. El mensaje de petición RTSP La figura siguiente muestra el formato del mensaje de petición. Este mensaje consta de tres partes bien diferenciadas: la línea de petición, la cabecera de petición y el cuerpo del mensaje.

La línea de petición tiene la forma siguiente:

OrdenRTSP [Espacio] URI-petición [Espacio] Versión-RTSP [Salto línea]

La orden RTSP indica qué orden del protocolo estamos utilizando. El URI-petición identifica el recurso al cual queremos acceder, y la versión RTSP indica la versión del protocolo que estamos utilizando. [Espacio] es un espacio en blanco y [Salto línea] está representado por los caracteres Salto de línea (ASCII 10) y Retorno de carro (ASCII 13). El resto de los espacios en blanco se han puesto por claridad.

Nombre-campo: [Espacio] valor-campo [Salto línea]

La cabecera de petición tiene tres partes: la cabecera general, la cabecera propiamente de petición y la cabecera de entidad. El formato de todos los campos de las cabeceras es el siguiente: •

La cabecera general representa información general que es independiente de si el mensaje es de petición o de respuesta.

Ved también Los valores de las órdenes RTSP, así como el formato de la versión RTSP, están explicados con detalle en el anexo 1.

© FUOC • PID_00147724

•

82


La cabecera de petición contiene campos que sólo tienen sentido para un mensaje de petición.

•

La cabecera de entidad contiene información sobre el cuerpo del mensaje (que también se conoce como entidad).

El cuerpo del mensaje lleva la información, si la hay, asociada a la petición.

Ved también Los valores que pueden tomar las cabeceras de entidad están explicados con detalle en el anexo 1.

10.2.7. El mensaje de respuesta RTSP La figura siguiente muestra el formato del mensaje de respuesta. Este mensaje consta de tres partes bien diferenciadas: la línea de estado de la respuesta, la cabecera y el cuerpo del mensaje.

La línea de estado de la respuesta tiene la forma siguiente:

Versión-RTSP [Espacio] Código-Estado [Espacio] por Descripción-Estado [Salto línea]

La versión RTSP define la versión del protocolo que se está utilizando, el código de estado define el éxito o error en la petición y la descripción del estado es una descripción textual del código de estado. [Espacio] es un espacio en blanco y [Salto línea] está representado por los caracteres Salto de línea (ASCII 10) y Retorno de carro (ASCII 13). El resto de los espacios en blanco se han puesto por claridad. La cabecera de respuesta tiene tres partes: la cabecera general, la cabecera propiamente de respuesta y la cabecera de entidad. El formato de todos los campos de las cabeceras es el siguiente:


Ved también Los valores de los códigos y las descripciones de estado están explicados con detalle en el anexo 1.

© FUOC • PID_00147724

83

La cabecera general representa información general que es independiente de si el mensaje es de petición o de respuesta. La cabecera de respuesta contiene campos que sólo tienen sentido para un mensaje de respuesta. La cabecera de entidad contiene información sobre el cuerpo del mensaje (que también se conoce como entidad).


Ved también Los valores que pueden tomar estas tres cabeceras están explicados con detalle en el anexo 1.

El cuerpo del mensaje lleva la información, si la hay, asociada a la respuesta. 10.2.8. Ejemplo de uso del protocolo RTSP En este subapartado veremos un ejemplo de uso del protocolo RTSP, con las peticiones y respuestas que nos encontraríamos en una comunicación real. En este ejemplo, el cliente establece una conexión TCP en el puerto 554 del servidor y envía la orden OPTIONS, indicando la versión del protocolo RTSP que utilizará. El servidor confirma esta orden con un mensaje 200 OK (indicando que ha ido bien). Este código de respuesta es igual al equivalente en HTTP. Petición del cliente:

OPTIONS rtsp://servidor.multimedia.com:554 RTSP/1.0 Cseq: 1

Respuesta del servidor:

RTSP/1.0 200 OK Cseq: 1

En un segundo paso, el cliente envía una orden de tipo DESCRIBE, que indica al servidor el contenido concreto que queremos. El servidor vuelve a responder con un 200 OK, incluyendo una descripción completa del contenido, en algún formato estandarizado –por ejemplo, Session Description Protocol (SDP) o Multimedia and Hypermedia Experts Group (MHEG). Petición del cliente:

DESCRIBE rtsp://servidor.multimedia.com:554/videos/ video.html RTSP/1.0 Cseq: 2

SDP y MHEG El Session Description Protocol (SDP) está definido en el RFC 4.566. Multimedia and Hypermedia Experts Group (MHEG): http:// www.mheg.org.

© FUOC • PID_00147724

84

Petición del cliente:

SETUP rtsp:// servidor.multimedia.com:554/videos/ video.html RTSP/1.0 Cseq: 3 Transport: rtp/udp;unicast;client_port=5067-5068


RTSP/1.0 200 OK Cseq: 3 Session: 12345678 Transport: rtp/udp;client_port=5067-5068;server_port=60236024

Como se puede ver, además de las líneas de petición y respuesta, los mensajes llevan cabeceras que indican el número de secuencia del mensaje (Cseq) o las características de la entidad enviada (Content-type o Content-length). En el siguiente paso de la negociación, el cliente envía una orden SETUP en la que le dice al servidor los mecanismos de transporte que quiere utilizar y el orden de preferencia. El cliente indica que quiere utilizar UDP como protocolo de transporte y los puertos 5067 y 5068 para la transferencia de datos. El servidor confirma los datos de transporte y puertos del cliente y añade el identificador de sesión y sus puertos de transferencia. Después de establecer la conexión, el cliente está listo para empezar a recibir el stream y envía la orden PLAY. Esta orden sólo contiene el URL del contenido y el identificador de la sesión enviado previamente por el servidor. El servidor confirma la orden y se empieza a enviar el stream. Si el cliente decide parar el stream, lo puede hacer con la orden TEARDOWN. El servidor envía la confirmación de que ha recibido la orden y se para el envío RTSP. Petición del cliente:

PLAY rtsp:// servidor.multimedia.com:554/videos/ video.mpg RTSP/1.0 Cseq: 4 Session: 12345678


© FUOC • PID_00147724

85


RTSP/1.0 200 OK Cseq: 4

La figura siguiente resume los intercambios anteriores:


© FUOC • PID_00147724

86


11. Protocolos para aplicaciones interactivas en tiempo real

11.1. Real Time Transport Protocol (RTP) El Real Time Transport Protocol (RTP)25 es un protocolo definido por la Internet Engineering Task Force (IETF). Este protocolo se puede utilizar para enviar cualquier tipo de formato: PCM, GSM o MP3 para audio y MPEG o H.263 para vídeo. Este protocolo es complementario a otros protocolos de tiempo real, como SIP o H.323.

(25)

El RFC que define el RTP y el RTCP es el 3.550.

Ved también Los protocolos SIP o H.323 se verán más adelante dentro de este mismo apartado.

11.1.1. Descripción del RTP El RTP funciona sobre el protocolo de transporte UDP. El emisor encapsula un trozo de datos (chunk, en inglés) dentro del paquete RTP, que también se encapsula dentro de un datagrama UDP, el cual viaja en un paquete IP. El receptor extrae los datos RTP del datagrama UDP y pasa los datos al reproductor para que este descodifique el contenido y lo reproduzca. Si una aplicación incluye RTP, será más fácil que pueda interoperar con otras aplicaciones multimedia. Por ejemplo, si dos fabricantes ofrecen un software de telefonía sobre IP e incorporan RTP en su producto, la interconexión entre sus productos será más factible. El RTP no ofrece ningún mecanismo que permita asegurar que los datos llegan a su destino a tiempo o con la calidad de servicio adecuada. Tampoco garantiza que los paquetes lleguen en orden, ya que el protocolo RTP sólo se reconoce en los extremos y los direccionadores toman los paquetes IP que contienen RTP como si fueran cualquier otro paquete IP y no los diferencian del resto. El RTP permite asociar a cualquier dispositivo (una cámara, un micrófono, etc.) su propio stream de paquetes. Así pues, si dos usuarios quieren hacer una videoconferencia, se pueden abrir dos streams de audio y vídeo, uno en cada sentido para cada tipo de datos. La realidad es que los streams de audio y vídeo están entrelazados, se envían como un único stream y se establece una única conexión para enviar los dos streams (audio y vídeo). El RTP forma parte del nivel de aplicación (estaría por encima del UDP, que es el nivel de transporte), pero también se puede ver como un subnivel dentro del nivel de transporte. En la figura siguiente se puede ver esta distinción de forma gráfica:

Ved también En este subapartado 11.1 hablaremos del RTP, y en el 11.2 hablaremos del protocolo de control del RTP, el RTCP.

© FUOC • PID_00147724

87


11.1.2. La cabecera del RTP El formato de la cabecera RTP se puede ver en la figura siguiente.

Los primeros 12 octetos están presentes en todos los paquetes RTP, mientras que la lista de identificadores CSRC (Contributing Source) sólo está presente cuando hay un mezclador. Los campos tienen el significado siguiente. •

Versión (V): 2 bits. Este campo identifica la versión RTP. La versión actual es la 2.

•

Relleno (P): 1 bit. Si este bit está activado, el paquete contiene unos o más octetos de relleno adicional en los datos. El último octeto de relleno indica cuántos octetos se tienen que descartar, incluyendo el mismo. Esta técnica puede ser necesaria para algunos algoritmos de cifrado que necesitan un tamaño de bloque fijo.

•

Extensión (X): 1 bit. Si está activado, la cabecera fija sólo puede llevar una extensión.

•

Número de CSRC (CC): 4 bits. Este campo contiene el número de identificadores CSRC que hay en la cabecera fija.

•

Marcador (M): 1 bit. La interpretación de este campo está definida por un perfil, que indica por qué se debe utilizar en un determinado contexto.

Mezclador RTP Un mezclador RTP se encarga de cambiar el formato del stream con el fin de adecuarlo al ancho de banda del receptor.

© FUOC • PID_00147724

•

88

Tipo de contenido (PT): 7 bits. Este campo identifica el formato de los datos que se están enviando con RTP.

•

Número de secuencia: 16 bits. Este número se incrementa en uno cada vez que se envía un paquete de datos RTP y puede utilizarse para detectar pérdidas de datos y restaurar la secuencia del paquete. El valor inicial debe ser aleatorio.

•

Timestamp: 32 bits. Indica el momento de tiempo del primer octeto enviado en este paquete de datos RTP.

•

SSRC: 32 bits. Este campo identifica la fuente de sincronización. Tiene que ser aleatorio para que dos fuentes de sincronización de una sesión RTP no tengan el mismo identificador.

•

Lista CSRC: de 0 a 15 elementos, 32 bits por elemento. Identifica las fuentes que contribuyen a los datos contenidos en este paquete RTP.

11.2. Real Time Control Protocol (RTCP) El protocolo de control del RTP (RTCP) se basa en la transmisión periódica de paquetes de control a todos los participantes en una sesión, utilizando el mismo mecanismo de distribución que los paquetes de datos enviados con RTP. El protocolo que haya por debajo tiene que ofrecer la posibilidad de multiplexar paquetes de datos y de control, por ejemplo, por medio de números de puerto UDP diferentes. El RTCP lleva a cabo cuatro funciones básicas: 1) Da información sobre la calidad de los datos distribuidos. Esto forma parte del rol del RTP como protocolo de transporte y está muy relacionado con las funcionalidades de control de congestión ofrecidas por otros protocolos de transporte. 2) Mantiene un identificador persistente a nivel de transporte de una fuente RTP, que se denomina nombre canónico o CNAME, ya que, en el transcurso de la comunicación, el identificador SSRC puede cambiar si se detecta un conflicto o se reinicia un programa. Con el CNAME, si el identificador SSRC cambia, se pueden recuperar los participantes de la sesión. 3) Las dos funcionalidades anteriores necesitan que todos los participantes envíen paquetes RTCP, aunque se tiene que controlar la tasa de envío por si hay un número elevado de participantes. Si cada participante envía los paquetes de control a todos los otros, cada uno puede observar independientemente el número de participantes. Este número sirve para calcular la tasa a la cual se envían los paquetes.


© FUOC • PID_00147724

89

4) La última función es opcional, y consiste en comunicar un mínimo de información de control de la sesión, como que se muestre la identificación de un participante en la interfaz de usuario. 11.2.1. Los paquetes RTCP Los paquetes RTCP pueden transportar diferentes tipos de información de control. •

SR: informe del emisor (Sender Report, en inglés), para transmitir y recibir estadísticas de los participantes que son emisores activos.

•

RR: informe del receptor (Receiver Report, en inglés), para recibir estadísticas de los participantes que no son emisores activos. También se puede combinar con el SR para los emisores activos que tienen que informar sobre más de 31 fuentes de datos (el máximo que se puede indicar en un paquete de tipo SR).

•

SDES: elementos de descripción de la fuente, incluyendo el CNAME.

•

BYE: indica que se ha dejado de participar.

•

APP: funcionalidades específicas de la aplicación.

Cada paquete RTCP empieza con una parte fija similar a la que tienen los paquetes de datos RTP, seguida de una serie de elementos estructurados que pueden tener una estructura variable de acuerdo con el tipo de paquete, pero que deben tener una longitud múltiple de 32 bits. Se incluyen campos para indicar la alineación y un campo de longitud para hacer que los paquetes RTCP sean apilables. Los paquetes RTCP pueden enviarse de manera consecutiva, sin tener que ponerles ningún separador, y formar de este modo un paquete RTCP compuesto, que se puede enviar en un único paquete del nivel inferior (por ejemplo, UDP). Cada paquete RTCP dentro del paquete compuesto se tiene que procesar de manera independiente del resto de los paquetes. Sin embargo, para llevar a cabo las funciones del protocolo, se imponen las restricciones siguientes: a) La recepción de estadísticas (en SR o RR) se tiene que enviar tan frecuentemente como lo permitan las restricciones de ancho de banda para maximizar la resolución de las estadísticas. Por este motivo, cada paquete RTCP compuesto tiene que llevar obligatoriamente un paquete de tipo informe. b) Los nuevos receptores deben recibir el CNAME tan pronto como sea posible para identificar la fuente y poder asociar el contenido multimedia.


© FUOC • PID_00147724

90


c) El número de tipos de paquetes que pueden aparecer inicialmente en el paquete compuesto se tiene que limitar para aumentar el número de bits constantes en la primera palabra del paquete y la probabilidad de validar con éxito los paquetes RTCP contra paquetes de datos RTP que tengan la dirección mal o que no estén relacionados. Todos los paquetes RTCP se deben enviar obligatoriamente en paquetes compuestos de al menos dos paquetes individuales, con el formato siguiente. •

Prefijo de cifrado: si el paquete RCTP se tiene que cifrar, entonces se debe poner ante un prefijo aleatorio de 32 bits, que debe recalcularse para cada paquete compuesto. Si es preciso relleno, se tiene que poner en el último paquete del paquete compuesto.

•

SR o RR: el primer paquete del paquete compuesto debe ser de tipo informe, para facilitar la validación de la cabecera. Esto se tiene que hacer siempre, aunque no se hayan enviado o no se hayan recibido datos. En este caso, se tiene que enviar un paquete RR vacío.

•

RR adicionales: si el número de fuentes de las que se debe reportar es mayor que 31, entonces se tienen que enviar paquetes RR adicionales hasta completar los datos del primer paquete SR o RR enviado.

•

SDES: un paquete de tipo SDES que contenga un CNAME se tiene que incluir siempre en el paquete compuesto.

•

BYE o APP: el resto de los paquetes pueden aparecer en cualquier orden e incluso repetidos, excepto los de tipos BYE, que tienen que ir al final para un SSRC/ CSRC dado.

Un participante RTP tiene que enviar un único paquete compuesto por intervalo de envío de informes para calcular correctamente el ancho de banda de RTCP por participante. 11.2.2. Uso del ancho de banda en el protocolo RTCP Para el funcionamiento del RTCP, se puede ver que, en una conexión con un emisor y muchos receptores (que pueden comunicarse con multicast), los datos enviados con RTCP pueden exceder en gran manera los datos enviados con RTP por el emisor. Por este motivo, el RTCP modifica la tasa de envío de los paquetes RTCP a medida que aumenta el número de participantes en la sesión. El RTCP intenta mantener su tráfico en el 5% del ancho de banda de la sesión. Veamos esto con un ejemplo.

Ved también El formato específico de cada paquete RTCP se define en el anexo 2 de este módulo didáctico.

© FUOC • PID_00147724

91


Ancho de banda RTSP Si un emisor transmite a una velocidad de 2 Mbps, el RTCP intenta limitar su tráfico en el 5% de estos 2 Mbps, que serían 100 kbps. El protocolo da el 75% de esta tasa, 75 kbps, a los receptores, y el resto, los 25 kbps restantes, al emisor. Los 75 Kbps de los receptores se reparten entre los mismos de manera igualitaria. De este modo, si hay R receptores, cada receptor puede enviar tráfico RTCP a una tasa de 75 kbps/R y el emisor envía a una tasa de 25 kbps. Los participantes (emisores o receptores) determinan el periodo de transmisión de un paquete RTCP calculando dinámicamente el tamaño medio de paquete RTCP (en toda la sesión) y dividiéndolo entre el tamaño medio de paquete RTCP que puede enviar a su tasa asignada. Para resumir, el periodo en el que un emisor puede enviar un paquete RTCP es: Y en resumen, el periodo en el que un receptor puede enviar un paquete RTCP es:

11.3. Session Initiation Protocol (SIP) Hay muchas aplicaciones en Internet que necesitan la creación y gestión de sesiones, entendiendo sesión como un intercambio de datos entre distintos participantes. La implementación de las sesiones se hace difícil por el comportamiento de los que participan en las mismas: los usuarios cambian de localización, pueden tener distintas maneras de identificarse e intercambian diferentes tipos de datos, a veces de manera simultánea. Hay muchos protocolos que permiten trabajar con sesiones multimedia en tiempo real con las que es posible transmitir texto, audio o vídeo. El Session Initiation Protocol (SIP)26 trabaja en cooperación con estos protocolos, y permite que los diferentes agentes de usuario (aplicaciones que utilizan a los usuarios para comunicarse) puedan encontrarse y ponerse de acuerdo con el tipo de sesión que quieren compartir. Para localizar a los participantes de una sesión y para otras funciones, el SIP permite la creación de una infraestructura de hosts (denominados proxy servers), a la que las aplicaciones de usuario pueden enviar peticiones de registro, invitación a las sesiones y otras peticiones. El SIP es una herramienta que permite gestionar sesiones independientemente de los protocolos de transporte que haya por debajo y sin ninguna dependencia del tipo de sesión establecida. 11.3.1. Funcionalidad del SIP El SIP es un protocolo de control de nivel de aplicación que puede establecer, modificar y finalizar sesiones multimedia (conferencias). Como ejemplo de sesión, tenemos las llamadas telefónicas mediante Internet. El SIP también permite invitar a participantes a sesiones existentes, como por ejemplo las conferencias multicast. También se pueden añadir y quitar contenidos multimedia de una sesión existente. Con SIP, los usuarios pueden tener un único identificador externo, independientemente de su localización de red.

(26)

El RFC donde se define el SIP es el 3.261.

Aplicaciones que utilizan el SIP Windows Live Messenger y Yahoo Messenger son dos aplicaciones que utilizan SIP.

© FUOC • PID_00147724

92

El SIP considera cinco aspectos diferentes para el establecimiento y la finalización de comunicaciones multimedia. •

Localización del usuario: hace referencia al sistema final que se hará para la comunicación.

•

Disponibilidad del usuario: indica si el usuario quiere participar en las comunicaciones.

•

Capacidad de los usuarios: indica el medio y los parámetros del medio que se utilizarán.

•

Inicio de la sesión: llamada, establecimiento de la sesión y parámetros a los dos extremos de la comunicación.

•

Gestión de la sesión: incluye la transferencia y finalización de sesiones, modificando los parámetros de la sesión y llamando a los servicios.

El SIP no es un sistema completo de comunicaciones, sino que se trata de un componente que se puede complementar con otros protocolos de Internet con el fin de implementar una aplicación multimedia entera. Por ejemplo, se pueden utilizar los protocolos RTP y RTCP para el transporte y control del envío de datos o el protocolo RTSP para el control del streaming de datos multimedia. El SIP no ofrece servicios, sino primitivas que se pueden utilizar para ofrecer diferentes tipos de servicio. Por ejemplo, el SIP tiene una primitiva que permite encontrar a un usuario y enviarle datos opacos a su localización. Si estos datos consisten en una descripción de sesión definida, por ejemplo con SDP, los extremos de la comunicación pueden ponerse de acuerdo con los parámetros de la sesión. El SIP tampoco ofrece servicios de control de las conferencias, ni define cómo se tiene que gestionar una conferencia. Sin embargo, se puede utilizar para iniciar una conferencia que utiliza otro protocolo para el control de conferencias. La naturaleza de los servicios que se pueden ofrecer con SIP hace que la seguridad sea muy importante. Por este motivo, el SIP ofrece toda una serie de mecanismos de seguridad que incluyen la prevención de la denegación de servicio, la autenticación de usuarios y proxies, la protección de la integridad y los servicios de cifrado y privacidad. La figura siguiente muestra un ejemplo de funcionamiento del SIP:


© FUOC • PID_00147724

93


En este ejemplo, Amalia y Cristina quieren establecer una sesión SIP. Cada intercambio tiene al lado un número entre paréntesis (n), para hacer de referencia en la explicación del mismo. También se muestran los dos servidores proxy que actúan en nombre de Amalia y Cristina para facilitar el establecimiento de la sesión. Amalia llama a Cristina utilizando su identidad SIP, una especie de URI, denominado URI SIP. Un URI SIP es semejante a una dirección de correo electrónico; lo definiremos más adelante, pero contiene un host y un nombre de usuario. En este caso, este URI es sip:[email protected], en el que bcn.cat es el dominio del proveedor de servicio de Amalia. El URI SIP de Cristina es sip:[email protected]. Amalia puede haber escrito la dirección de Cristina o puede haberla elegido de un enlace o una agenda. También existen los URI SIP seguros, que se denominan SIPS, como por ejemplo sips:[email protected]. En este caso, se utilizaría el Transport Layer Security (TLS)27 para proveer de una conexión segura y cifrada para transportar los mensajes SIP. El SIP se basa en un mecanismo de petición/respuesta muy similar al modelo de transacciones HTTP. Cada transacción consiste en una petición que invoca un método del servidor y, como mínimo, una respuesta. En este ejemplo, la transacción empieza cuando Amalia envía una orden INVITE dirigida al URI SIP de Cristina. A continuación, se muestra la información que llevaría asociada la orden INVITE:

INVITE sip:[email protected] SIP/2.0

(27)

El RFC del TLS es el 4.346.

© FUOC • PID_00147724

94


Via: SIP/2.0/UDP pc01.bcn.cat;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Cristina From: Amalia ;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142

... Resto de datos SDP ...

El contenido del mensaje es el siguiente: •

La primera línea contiene el método, con el URI SIP origen y la versión de SIP.

•

Las líneas siguientes son cabeceras, que contienen información sobre el origen y el destino de la comunicación (From, To), la dirección donde Amalia quiere recibir las respuestas, indicada en Via, y algunos identificadores únicos. Cseq es un número de secuencia que se incrementa con cada nueva petición. Contact contiene el URI SIP que representa la ruta directa hacia Amalia, formada por un nombre de usuario y el nombre de dominio. El número Max-Forwards indica el número máximo de saltos que puede dar esta petición y, finalmente, Content-Type y Content-Length contienen información sobre el cuerpo del mensaje.

Los parámetros específicos de la sesión no se definen con SIP, sino con otro protocolo, como el SDP, que no veremos aquí. Puesto que el teléfono de Amalia no sabe dónde encontrar a Cristina o el servidor SIP de bcn.cat, envía la orden INVITE a su servidor de dominio, bcn.cat (1). El servidor bcn.cat es un tipo de servidor SIP conocido como proxy server. Su función es redireccionar las peticiones SIP en nombre de quien las envía. En este ejemplo, el proxy server recibe la petición INVITE (2) y responde con una respuesta 100 (Trying) (3). Esto indica que la petición se ha recibido bien y que se está intentando enviar INVITE a su destino. La respuesta SIP tiene la forma de un código de 3 cifras y una frase descriptiva (como HTTP). El proxy server bcn.cat encuentra la dirección SIP del dominio vic.cat. De esta manera, consigue la dirección del proxy server de vic.cat y le reenvía la orden INVITE (2). Este contesta con un 100 (Trying) (5), para indicar que está trabajando en servir la petición. El proxy server consulta una base de datos para encontrar la dirección de Cristina y le envía la petición INVITE (4) a su teléfono SIP. Cuando el teléfono recibe la petición, suena para informar a Cristina de que está recibiendo una llamada. El teléfono SIP indica que se está haciendo la llamada enviando un mensaje de tipo 180 (Ringing) (6), (7), (8), que llega hasta el teléfono de Amalia. Cuando la respuesta llega al teléfono de Amalia,

Ved también Se puede encontrar una lista completa de las cabeceras SIP en el anexo 3 de este módulo didáctico.

© FUOC • PID_00147724

95

este hace alguna indicación de que está sonando el teléfono en el otro extremo. En este caso, Cristina responde a la llamada, lo cual hace que se envíe una respuesta de tipo 200 OK (9), (10), (11). Amalia envía un ACK (12). En este momento, hay que negociar los parámetros de la sesión con el protocolo SDP. A continuación, se muestra cómo sería el mensaje de respuesta enviado por el teléfono SIP de Cristina:

SIP/2.0 200 OK Via: SIP/2.0/UDP proxy03.vic.cat ;branch=z9hG4bKnashds8;received=192.0.2.3 Vía: SIP/2.0/UDP proxy01.bcn.cat ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc01.bcn.cat ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Cristina ;tag=a6c85cf From: Amalia ;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131

... Resto de datos SDP ...

El contenido del mensaje es el siguiente: •

La primera línea contiene la respuesta, con la versión de SIP, el código de respuesta y la descripción.

•

Las líneas siguientes son cabeceras. Via, From, Call-ID y Cseq se copian de la petición INVITE (ahora hay distintas cabeceras de tipo Via para indicar la comunicación mediante los proxy servers). Contact contiene el URI SIP que representa la ruta directa hacia Cristina, formada por un nombre de usuario y nombre de dominio. Content-Type y Content-Length contienen información sobre el cuerpo del mensaje.

La sesión multimedia entre Cristina y Amalia ha empezado y pueden enviar los datos multimedia en el formato acordado. En general, estos paquetes seguirán una ruta diferente de la de los mensajes SIP. Durante la comunicación, se pueden cambiar las características de la sesión volviendo a enviar una orden INVITE. Para acabar la sesión, Cristina envía una orden BYE (cuelga) (13). Este BYE se envía directamente al teléfono de Amalia, sin pasar por los proxies. Amalia responde con un 200 OK (14). En este caso, no hay ACK.


© FUOC • PID_00147724

96


11.3.2. El protocolo SIP En este subapartado veremos el protocolo SIP, incluyendo el formato de los mensajes de petición y respuesta y los campos de cabecera. Muchas de las características del protocolo se heredan de HTTP, pero no se trata de una extensión. Por ejemplo, el SIP puede utilizar UDP para enviar sus peticiones y respuestas. Las direcciones (URI SIP) de los usuarios que utilizan este protocolo tienen la forma:

sip:user:password@host:port;uri-parameters?headers Ejemplo: sip:[email protected]

Los URI para SIPS siguen el mismo formato, cambiando SIP por SIPS al inicio del URI. El resto de los campos del URI son los siguientes. •

user: el identificador de un recurso en la máquina (host) a la que se está dirigiendo. En este contexto, host se refiere a un dominio.

•

password: el password asociado al usuario. Aunque se puede poner, su uso no está recomendado, porque significa enviarlo "en claro" y es un riesgo de seguridad.

•

host: el ordenador que ofrece el recurso SIP. Este campo puede contener un nombre de dominio o una dirección IP numérica. Se recomienda utilizar el nombre de dominio.

•

port: el número de puerto al que se tiene que enviar la petición.

•

uri parameters: parámetros que afectan a la petición que lleva el URI. Los parámetros se representan como nom-param=valor-param. Están separados de host:port con punto y coma y entre estos también se separan con punto y coma.

•

headers: campos de cabecera que se pueden incluir en la petición representada por el URI.

SIP es un protocolo basado en mensajes de texto. Esto facilita su implementación y ampliación. A continuación, veremos el formato de los mensajes de petición y respuesta SIP.

URI SIP En SIP, los URI (direcciones) pueden empezar con SIP o SIPS. El uso de SIPS indica que se tiene que establecer una conexión segura (con TLS) para llevar a cabo la comunicación.

© FUOC • PID_00147724

97

11.3.3. El mensaje de petición SIP La figura siguiente muestra el formato del mensaje de petición. Este mensaje consta de tres partes bien diferenciadas: la línea de petición, la cabecera de petición y el cuerpo del mensaje.

La línea de petición tiene la forma siguiente:

OrdenSIP [Espacio] URI-petición [Espacio] Versión-SIP [Salto línea]

El orden SIP indica qué orden del protocolo estamos utilizando. El URI-petición identifica el recurso al que queremos acceder, y la versión SIP indica la versión del protocolo que estamos utilizando. [Espacio] es un espacio en blanco y [Salto línea] está bien representado por los caracteres Salto de línea (ASCII 10) y Retorno de carro (ASCII 13). El resto de los espacios en blanco se han puesto por claridad. Las órdenes SIP son: REGISTER, INVITE, ACK, CANCEL, BYE y OPTIONS. La funcionalidad de cada método es la siguiente. •

REGISTER: permite registrar un recurso, para que después se puedan llevar a cabo comunicaciones SIP.

•

INVITE: permite iniciar una sesión por parte de un usuario.

•

ACK: indica que se ha aceptado la petición enviada con INVITE y que la sesión se ha establecido.

•

CANCEL: permite cancelar una petición ya enviada. Se genera un mensaje de error y se tiene que dejar de procesar la petición. Sólo se tendría que utilizar para cancelar un INVITE.

•

BYE: permite finalizar la sesión.

•

OPTIONS: permite pedir las características de un programa cliente o de un proxy server.


© FUOC • PID_00147724

98


La cabecera de petición tiene tres partes: la cabecera general, la cabecera propiamente de petición y la cabecera de entidad. El formato de todos los campos de las cabeceras es el siguiente:


La cabecera general representa información general que es independiente de si el mensaje es de petición o de respuesta. La cabecera de petición contiene campos que sólo tienen sentido para un mensaje de petición. La cabecera de entidad contiene información sobre el cuerpo del mensaje (que también se conoce como entidad).


El cuerpo del mensaje lleva la información, si la hay, asociada a la petición. 11.3.4. El mensaje de respuesta SIP La figura siguiente muestra el formato del mensaje de respuesta. Este mensaje consta de tres partes bien diferenciadas: la línea de estado de la respuesta, la cabecera y el cuerpo del mensaje.

La línea de estado de la respuesta tiene la forma siguiente:

Versión-SIP [Espacio] Código-Estado [Espacio] por Descripción-Estado [Salto línea]

La versión SIP define la versión del protocolo que se está utilizando, y el código de estado define el éxito o error en la petición y la descripción del estado, que es una descripción textual del código de estado. [Espacio] es un espacio en blanco y [Salto línea] está representado por los caracteres Salto de línea (ASCII 10) y Retorno de carro (ASCII 13). El resto de los espacios en blanco se han puesto por claridad.

Ved también Los valores de los códigos y descripciones de estado están explicados con detalle en el anexo 3.

© FUOC • PID_00147724

99


La cabecera de respuesta tiene tres partes: la cabecera general, la cabecera propiamente de respuesta y la cabecera de entidad. El formato de todos los campos de las cabeceras es:


La cabecera general representa información general que es independiente de si el mensaje es de petición o de respuesta. La cabecera de respuesta contiene campos que sólo tienen sentido para un mensaje de respuesta. La cabecera de entidad contiene información sobre el cuerpo del mensaje (que también se conoce como entidad).


El cuerpo del mensaje lleva la información, si la hay, asociada a la respuesta. 11.4. H.323 Este protocolo está considerado como una alternativa al SIP y es muy popular a la hora de transmitir audio y vídeo en tiempo real. Está dedicado a la transmisión de voz sobre IP (voice over IP –VOIP–, en inglés). Con H.323, es posible comunicar un equipo conectado a Internet con un teléfono conectado a la red telefónica. H.323 incluye distintas especificaciones: •

Negociación de codificaciones de audio y vídeo entre los extremos de la comunicación.

•

Cómo se envían los trozos de datos de audio y vídeo. H.323 obliga a utilizar RTP.

•

Cómo los equipos se comunican con sus gatekeepers.

•

Cómo los equipos conectados a Internet se conectan con los teléfonos conectados a la red telefónica.

El requerimiento mínimo de H.323 es que se debe soportar el audio, pero las características de vídeo son opcionales. De esta manera, los fabricantes pueden ofrecer unos equipos sencillos con las características de audio y dejar para equipos más sofisticados la parte de vídeo. Para transmitir los datos de audio, se tiene que utilizar un estándar que utiliza PCM (G.711) para generar voz digitalizada tanto en 56 kbps como 64 kbps. Aunque el vídeo es opcional, en caso de que el terminal lo tenga, debe soportar como mínimo el estándar QCIF H.261.

Formatos de datos utilizados en H.323 G.711 – Audio http:// www.itu.int/rec/T-REC-G.711/ en. QCIF H.261 – Vídeo http:// www.itu.int/rec/T-REC-H.261/ en.

© FUOC • PID_00147724

100

La figura siguiente muestra un ejemplo de arquitectura de un sistema H.323:

El gateway es un elemento opcional que sólo se necesita si queremos conectar equipos que están en una red diferente, como la red telefónica. El gatekeeper es un elemento opcional en la comunicación entre terminales H.323. Sin embargo, es el elemento más importante de una red H.323, ya que hace de punto central de todas las llamadas que hay dentro de una zona y proporciona servicios a los terminales registrados y control de las llamadas. Se podría decir que el gatekeeper hace de conmutador virtual. Para acabar este subapartado, se describen las diferencias principales entre SIP y H.323. •

H.323 es un conjunto integrado de protocolos para hacer conferencias multimedia que incluye: señalización, registro, control de admisión, transporte y codecs. Por otra parte, SIP sólo se encarga de iniciar y gestionar la sesión, sin hacer ninguna imposición en el transporte o los formatos de audio o vídeo soportados.

•

H.323 fue definido por ITU (telefonía), mientras que SIP fue definido por IETF (Internet). Esto hace que el punto de vista de los dos sea muy diferente.

•

H.323 es un estándar complejo, formado por muchas partes, mientras que SIP es mucho más simple y, por lo tanto, más fácil de implementar.


© FUOC • PID_00147724

101


11.5. Skype

Skype es un sistema de telefonía peer-to-peer (P2P) que funciona sobre la red Internet. Es la competencia de estándares de transmisión de voz sobre IP (VoIP) como SIP o H.323. Fue desarrollada por el equipo que hizo KaZaa en el año 2003. Se trata de una aplicación muy utilizada desde que se creó, tanto en sus servicios gratuitos como de pago. Ofrece muchas funcionalidades, incluyendo audio y videoconferencias gratuitas, el uso de tecnologías P2P (descentralizado) para no tener problemas con cortafuegos o con la traducción de direcciones (en inglés, Network Address Translation, NAT) y las múltiples medidas para que no se pueda reconocer el protocolo o el software que la implementan. La identificación del usuario que llama está enmascarada cuando se hace una llamada. La diferencia principal entre Skype y otros servicios es que utiliza tecnología P2P, mientras que el resto utiliza arquitecturas cliente-servidor. La implementación de P2P que utiliza es FastTrack, implementada en la aplicación KaZaa. La arquitectura que implementa FastTrack es una red superpuesta (overlay network, en inglés) con dos tipos de nodos: los nodos normales y los supernodos. Un nodo normal es un ordenador en el que se ha instalado la aplicación Skype y que permite hacer llamadas y enviar mensajes de texto. Los supernodos son end-points de la red Skype. Cualquier nodo que tenga una IP pública y bastantes recursos (memoria, ancho de banda, etc.) puede convertirse en un supernodo. Un nodo normal tiene que hacer login en la red Skype con su usuario y palabra de paso y, de esta manera, estará conectado a un supernodo. Todavía tenemos otro elemento en la red, el servidor de login, que es el que almacena los usuarios y las palabras de paso en toda la red Skype (los nombres de usuario son únicos). Aparte de este servidor, el resto de las operaciones en la red (busca de usuarios, envío de mensajes y llamadas, etc.) se hace de manera totalmente descentralizada.

KaZaa KaZaa es una aplicación P2P de descarga de contenidos que tuvo mucho éxito hace unos años. Utiliza el mismo protocolo P2P que Skype, FastTrack.

© FUOC • PID_00147724

102

El directorio de Skype está completamente descentralizado y distribuido entre los nodos de la red, lo que significa que es fácilmente escalable cuando se tiene un gran número de usuarios sin necesidad de una estructura compleja. Las llamadas se envían a través de otros usuarios de Skype en la red para facilitar la comunicación cuando hay cortafuegos o NAT. Esto hace que los usuarios que se conectan directamente a la red (sin NAT) tengan más tráfico para direccionar las llamadas de otros usuarios. Puesto que se trata de una red superpuesta, cada cliente Skype tiene que mantener una lista de nodos accesibles. Esta lista es la lista de hosts y contiene la dirección IP y el número de puerto de los supernodos. En sistemas Windows, se guarda en el registro. Es posible desarrollar programas que utilicen la API de Skype para acceder a su red. Sin embargo, el código es cerrado y el protocolo propietario, lo que dificulta su interoperabilidad con otros sistemas.


103

© FUOC • PID_00147724


12. Anexos

12.1. Anexo 1. El protocolo RTSP

12.1.1. Órdenes La tabla siguiente describe las órdenes RTSP: Orden

Descripción

OPTIONS

Permite al cliente pedir información sobre las opciones de comunicación con el servidor.

DESCRIBE

Recupera la información del contenido multimedia identificado por el URL que se envía con la orden.

ANNOUNCE

Si lo envía el cliente, se está indicando la descripción de una presentación. Si lo envía el servidor, se actualiza la información de la descripción de la sesión en tiempo real.

SETUP

Especifica los parámetros del mecanismo de transporte. Se puede enviar a media sesión, para cambiar estos parámetros.

PLAY

Se indica al servidor que se debe iniciar el envío de datos.

PAUSE TEARDOWN

Se indica al servidor que se quiere parar temporalmente la recepción de datos de la sesión. Se cierra la recepción de datos.

GET_PARAMETER

Pide el valor de un parámetro de la descripción de la sesión.

SET_PARAMETER

Envía el valor de un parámetro de la descripción de la sesión.

REDIRECT

Se indica al cliente que se tiene que conectar a otro servidor.

RECORD

Se inicia la grabación de datos de acuerdo con la descripción de la presentación.

12.1.2. Códigos de estado Los códigos de estado son de cinco tipos: 1XX, informativos, 2XX, petición lograda, 3XX, redireccionamiento, 4XX, error en la petición del cliente y 5XX, error en el servidor. Sólo se han puesto los códigos específicos de RTSP, el resto están definidos en el RFC de HTTP. Tipo de código

Valor

Descripción

Informativo

100

El cliente puede continuar con la petición.

Éxito

250

Poco espacio de almacenamiento. Puede suceder con la orden RECORD.

104

© FUOC • PID_00147724


Tipo de código

Valor

Descripción

Redirección

3XX

Los mismos que HTTP.

Error�parte�cliente

405

El recurso no puede ejecutar el método pedido.


451

El servidor no soporta alguno de los parámetros indicados en la petición.


452

La conferencia no se ha encontrado.


453

No hay suficiente ancho de banda para recibir el contenido.


454

La sesión no se ha encontrado.


455

El método no es válido en el estado actual del protocolo.


456

Un parámetro indicado en la cabecera no se puede procesar.


457

El rango pedido está fuera de los límites.


458

Un parámetro que se quería modificar con SET_PARAMETER es sólo de lectura.


459

El parámetro no se puede aplicar al recurso. Sólo se puede aplicar a un stream


460

El parámetro no se puede aplicar al recurso. Sólo se puede aplicar a una presentación.


461

El tipo de transporte no está soportado.


462

El cliente no es accesible.

Error�parte�servidor

551

Una opción enviada a la cabecera no es soportada.

12.1.3. Cabeceras En la tabla siguiente, se describen las cabeceras del protocolo RTSP que son específicas de este protocolo. El resto están definidas en el RFC de HTTP: Cabecera

Descripción

Accept

Tipos de contenidos aceptados en la presentación.

Allow

Métodos RTSP soportados por el servidor.

Bandwidth Blocksize Cache-Control Conference Content-Length CSeq Expires If-Modified-Since

Ancho de banda calculado del cliente. Tamaño de datos preferido por el cliente. No incluye las cabeceras de protocolos de niveles inferiores (IP, UDP, RTSP). Control del mecanismo de caché de los contenidos. Establece una conexión entre esta conferencia y un stream existente. Longitud del contenido enviado en el cuerpo del mensaje. Número de secuencia en la sesión RTSP de pares petición/respuesta. Momento en el que el contenido estará obsoleto. Se utiliza con SETUP y DESCRIBE. Si la descripción no se ha modificado desde el momento indicado en esta cabecera, se envían datos.

105

© FUOC • PID_00147724

Cabecera


Descripción

Last-Modified

Última vez en la que se modificó la descripción del recurso.

Proxy-Require

Parámetros que debe soportar un proxy.

Require

Sirve para preguntar al servidor qué opciones soporta.

RTP-Info

Indica parámetros específicos de RTP en una orden PLAY.

Scale

Permite indicar si el contenido se quiere ver a velocidad normal, más rápida o más lenta.

Session

Identificador de la sesión.

Speed

Pide que la transferencia de datos se haga a una determinada velocidad.

Transporte Unsupported

Protocolo de transporte utilizado. Características no soportadas por el servidor.

12.2. Anexo 2. El formato de los paquetes RTCP En este anexo, se describen los datos que contiene cada uno de los paquetes del protocolo RTCP. 12.2.1. Informe de emisor (SR) La figura siguiente muestra los campos del paquete de tipo SR:

© FUOC • PID_00147724

106

Este tipo de paquete tiene tres secciones y una cuarta, opcional, que son las extensiones y que están definidas por los perfiles. La primera sección es la cabecera y tiene ocho octetos. Los campos son los siguientes. •

Versión (V): 2 bits. Identifica la versión de RTP y es la misma que para los paquetes de datos. La versión actual es la 2.

•

Relleno (P): 1 bit. Si el bit de relleno está activado, este paquete RTCP tiene octetos de relleno que no forman parte de la información de control, pero que están incluidos en la longitud del paquete. El último octeto de relleno indica cuántos octetos se tienen que ignorar, incluido el mismo. En un paquete compuesto, sólo se debe añadir relleno a los paquetes individuales.

•

Contador de recepción de informes (RC): 5 bits. El número de bloques de recepción de informes que hay en este paquete. 0 también es válido.

•

Tipo de paquete (PT): 8 bits. Contiene una constante con valor 200 para identificar que se trata de un paquete de tipo SR.

•

Longitud: 16 bits. Longitud del paquete en palabras de 32 bits menos 1, incluyendo cabecera y relleno.

•

SSRC: 32 bits. Identificador de la fuente de sincronización del creador de este paquete SR.

La segunda sección, la sección del emisor, tiene 20 octetos de longitud y está presente en cualquier paquete de tipo SR. Hace un resumen de los datos transmitidos por este emisor. Los campos son los siguientes. •

NTP timestamp: 64 bits. Indica el tiempo en el que este informe se envió. Se puede utilizar para calcular el tiempo de propagación de la información si se combina con timestamps como paquetes de tipo RR.

•

RTP timestamp: 32 bits. Tiene el mismo valor que el campo anterior, pero con las mismas unidades que los timestamps de los paquetes RTP.

•

Número de paquetes enviados por el emisor: 32 bits. El número de paquetes RTP de datos transmitidos por el emisor desde que se inició la transmisión hasta el envío de este paquete.

•

Número de octetos enviados por el emisor: 32 bits. Número total de octetos de datos (sin incluir cabeceras ni relleno) transmitidos en paquetes de datos RTP por el emisor desde que se inició la transmisión hasta el envío de este paquete.


© FUOC • PID_00147724

107

La tercera sección contiene 0 o más bloques de informes de recepción, dependiendo del número de fuentes recibidas por este emisor desde el último informe. Cada bloque contiene las estadísticas siguientes. •

SSRC_n (identificador de la fuente): 32 bits. El identificador de la fuente SSRC a la cual pertenece la información enviada en este bloque.

•

Fracción de pérdidas: 8 bits. La fracción de paquetes RTP perdidos por la fuente SSRC_n desde que se envió el último paquete de tipo SR o RR.

•

Número acumulado de paquetes perdidos: 24 bits. El número total de paquetes perdidos desde el inicio de la recepción.

•

Número de secuencia más alto recibido: 32 bits. Los 16 bits más altos contienen el número de secuencia más alto recibido y el resto son extensiones al número de secuencia.

•

Jitter entre llegadas: 32 bits. Una estimación estadística de la variancia del tiempo entre llegadas de los paquetes de datos RTP, medido en unidades de timestamp y expresado como un entero sin signo.

•

Último SR (LSR): 32 bits. La mitad de los 64 bits recibidos en el NTP timestamp del último paquete de tipo SR recibido desde la fuente SSRC_n.

•

Retraso desde el último SR (DLSR): 32 bits. El retraso entre el último SR recibido desde SSRC_n y el envío de este paquete de información.

12.2.2. Informe de receptor (RR) La figura siguiente muestra los campos del paquete de tipo RR:


© FUOC • PID_00147724

108

El formato de este tipo de paquete es igual al del paquete SR, excepto por el hecho de que el tipo de paquete tiene la constante 201 y la información del emisor (timestamps NTP y RTP y número de paquetes y octetos enviados) no está. 12.2.3. Descripción de elementos de la fuente (SDES) La figura siguiente muestra los campos del paquete de tipo SDES:

Este tipo de paquete tiene una estructura en tres niveles compuesta por una cabecera y cero o más porciones, cada una de estas formada por elementos que describen la fuente identificada por la porción. La primera sección es la cabecera y tiene ocho octetos. Los campos son los siguientes. •

Versión (V), relleno (P) y longitud tienen el mismo significado que los definidos por el paquete SR.

•

Número de fuentes emisoras (SC): 5 bits. El número de porciones SSRC/ CRSC por las cuales son contenidas en un paquete SDES.

•

Tipo de paquete (PT): 8 bits. Contiene la constante 202.

•

Cada porción contiene un identificador de SSRC/CSRC, seguido de una lista de elementos SDES. Cada elemento consiste en un campo de 8 bits que indica el tipo, un campo de 8 bits que es un contador del número de octetos que indica la longitud del campo (sin la cabecera) y el texto del elemento, que no puede pasar de 255 octetos.

Como ejemplo de elemento SDES, veremos cómo se representa el campo CNAME.


© FUOC • PID_00147724

109

El campo CNAME tiene que ser único y hace enlace entre un identificador SSRC (que puede cambiar) y el identificador de la fuente, que debe ser constante. 12.2.4. Paquete de cierre (BYE) La figura siguiente muestra los campos del paquete de tipo BYE:

El paquete BYE indica que uno o más fondos ya no están activos. Los campos son los siguientes. •


•

Número de fuentes emisoras (SC): 5 bits. El número de porciones SSRC/ CRSC por las cuales son contenidas en un paquete SDES.

•


12.2.5. Paquete definido por la aplicación (APP) La figura siguiente muestra los campos del paquete de tipo APP:

El paquete APP está pensado para que las aplicaciones añadan funcionalidad. Los campos son: •


•

Subtipo: 5 bits. Puede utilizarse para definir un subtipo de aplicaciones.


110

© FUOC • PID_00147724


•


•

Nombre: 8 octetos. Nombre escogido por la persona que ha definido los paquetes de tipo APP, para diferenciarlos de otros paquetes de tipo APP.

•

Datos dependientes de la aplicación: longitud variable. Este campo puede aparecer o no. Es directamente interpretado por la aplicación y no por RTP. Tiene que ser múltiplo de 32 bits.

12.3. Anexo 3. El protocolo SIP

12.3.1. Códigos de estado Los códigos de estado son de 5 tipos: 1XX, respuestas provisionales, 2XX, petición lograda, 3XX, redireccionamiento, 4XX, error en la petición del cliente, 5XX, error en el servidor y 6XX, errores globales (específicos del SIP). Muchos de los códigos de estado están heredados del protocolo HTTP, pero también hay códigos específicos del SIP. Los códigos HTTP que no tengan sentido en SIP no se deben utilizar. Tipo de código

Valor

Descripción

Respuestas�provisionales

100

Indica que el siguiente host (salto, hop, en inglés) ha recibido la petición.


180

Indica que la petición INVITE se ha recibido en el otro lado y se avisa al usuario.


181

La llamada se está redirigiendo.


182

La llamada se ha puesto en la cola, porque el receptor de la llamada no está disponible.


183

Información sobre el progreso de la llamada.

Éxito

200

La petición ha ido bien.

Redirección

300

Indica que hay múltiples opciones en la localización de la dirección del usuario al que se llama.

Redirección

301

El usuario ha cambiado de dirección y se le tiene que llamar a la nueva dirección indicada en la cabecera Contact.

Redirección

302

El usuario ha cambiado de dirección y se le tiene que llamar a la nueva dirección indicada en la cabecera Contact.

Redirección

305

Se tiene que utilizar un proxy.

Redirección

380

La llamada no ha sido posible, pero hay servicios alternativos disponibles.

Redirección

400

Formato de petición erróneo.

Redirección

401

El usuario necesita autenticarse.

111

© FUOC • PID_00147724


Tipo de código

Valor

Descripción

Redirección

402

Reservado para uso futuro.


403

El servidor no quiere servir la petición del cliente, aunque tenía un formato correcto.


404

El usuario a quien se ha llamado no se encuentra en el servidor.


405

El método pedido no se puede ejecutar para la dirección indicada.


406

El recurso no es aceptable según los valores enviados en la cabecera Accept.


407

El cliente se tiene que autorizar delante de un proxy.


408

El servidor no ha podido producir una respuesta a tiempo.


410

El recurso ya no está disponible en el servidor.


413

El tamaño de la entidad enviada por el cliente es demasiado grande para que el servidor la pueda tratar.


414

El tamaño del URI es demasiado grande para que el servidor lo pueda tratar.


415

El tipo de datos del contenido no está soportado por el servidor.


416

La petición no se puede servir, porque el esquema indicado en el URI del recurso no se reconoce.


420

El servidor no reconoce las extensiones indicadas en la cabecera. Proxy-Require


421

Los programas necesitan una extensión específica para poder servir la petición.


423

El servidor rechaza la petición, porque expira demasiado pronto.


480

Se ha podido llegar hasta el servidor, pero el usuario al que se ha llamado no está disponible temporalmente.


481

La transacción no existe.


482

Se ha detectado un bucle en la llamada.


483

Se ha pasado el máximo de hosts indicados en la cabecera MaxHops.


484

La dirección del usuario al que se ha llamado es incompleta.


485

La dirección es ambigua.


486

El usuario no acepta la llamada.


487

La petición se ha acabado con un CANCEL o un BYE.


488

La petición no es aceptable, por algún parámetro indicado. a la sesión


491

Hay otra petición pendiente.


493

El cuerpo del mensaje lleva un tipo MIME que el servidor no puede tratar.


500

Error interno del servidor, que hace que no pueda servir la petición.


501

El servidor no tiene implementada la funcionalidad necesaria para servir la petición.

112

© FUOC • PID_00147724


Tipo de código

Valor

Descripción


502

El servidor recibe un error cuando hace de proxy o gateway.


503

El servicio está temporalmente no disponible.


504

El servidor no recibe una respuesta de un servidor externo a tiempo.


505

El servidor no soporta la versión del protocolo indicada por el cliente.


513

El mensaje es demasiado largo para que el servidor lo pueda procesar.

Error�general

600

El usuario llamado no está disponible.

Error�general

603

El usuario llamado no quiere aceptar la llamada.

Error�general

604

El usuario llamado no existe.

Error�general

606

La petición no es aceptable, por algún parámetro indicado en la sesión.

12.3.2. Cabeceras En la tabla siguiente se describen las cabeceras del protocolo SIP que son específicas de este protocolo. El resto están definidas en el RFC de HTTP: Cabecera Alert-Info Allow Authentication-Info Authorization Call-ID

Descripción Tono de llamada alternativo. Métodos soportados. Información por autenticación mutua Credenciales de autorización del cliente. Identificación de una llamada o de una serie de los registros de un cliente.

Call-Info

Información adicional sobre los participantes en la llamada.

Contact

Contiene una URI que puede tener diferentes significados según el contexto.

Content-Disposition Content-Encoding Content-Length

Indicación de la organización del cuerpo del mensaje, en términos de las partes que pueda tener y los formatos MIME. Codificación preferida por el contenido. Longitud del contenido enviado en el cuerpo del mensaje.

Cseq

Número de secuencia asociado a una petición.

Date

Fecha y hora en los que se creó el mensaje.

Error-Info Expires From In-Reply-To Max-Forwards

Información adicional sobre el error expresado en el código de respuesta. Momento en el que el contenido estará obsoleto. Iniciador de la petición. Referencia a los identificadores de la llamada asociados a la llamada actual. Límite al número de proxies o gateways que pueden reenviar la petición.

113

© FUOC • PID_00147724

Cabecera Min-Expires Organization Priority Proxy-Authorization


Descripción Intervalo de refresco mínimo. Nombre de la organización a la cual pertenece quien genera la petición. Prioridad de la llamada desde el punto de vista del cliente. Identificación del cliente frente a un proxy que pide autenticación.

Proxy-Require

Requerimientos que debe tener el proxy.

Record-Route

El proxy llena esta cabecera para indicar que las futuras peticiones tienen que pasar por el mismo.

Reply-To

URI de retorno que no debe ser en absoluto el mismo que el de la cabecera From.

Require

Características esperadas del programa de usuario.

Retry-After

Indicación de cuándo el servicio volverá a estar disponible.

Route

Descripción de los proxies por los cuales tendría que pasar la petición.

Server

Descripción del software que utiliza el servidor.

Subject

Tema de la llamada.

Supported

Extensiones soportadas por el programa de usuario.

Timestamp

Indicación de cuándo el programa cliente efectuó la llamada.

To Unsupported Via WWW-Authenticate

Receptor de la llamada. Descripción de las características no soportadas. Indicación del camino que ha seguido la petición y que se tiene que utilizar para las respuestas. Valor de respuesta de autenticación.

© FUOC • PID_00147724

114

Resumen

En este módulo, se ha empezado describiendo las arquitecturas de aplicaciones más habituales en Internet: cliente servidor y de igual a igual, así como los requerimientos de las aplicaciones orientadas al envío de datos o de mensajes. A continuación, se han descrito las aplicaciones distribuidas más habituales en Internet y diferentes estándares que están relacionados: Web y HTTP, DNS, SMTP, FTP, XMPP, Telnet y SSH, Gnutella, KaZaA, BitTorrent y eDonkey. Después, se han introducido los requerimientos de las aplicaciones multimedia en red. Finalmente, se han visto una serie de técnicas y protocolos para trabajar con contenidos multimedia en Internet, tanto por streaming de audio y vídeo: RTSP; como por aplicaciones interactivas en tiempo real: RTP, RTCP, SIP, H3.23 y Skype.


© FUOC • PID_00147724

115

Bibliografía Kurose, J. F.; Ross, W. K. Computer Networking (5.ª edición). Boston: Addison Wesley. ISBN 0-321-49770-8. Este libro proporciona una visión completa de los diferentes aspectos relacionados con las redes de ordenadores. En este módulo interesa el capítulo 2 ("Application Layer"), en el que se pueden encontrar los conceptos básicos de la Web, el correo electrónico, la transferencia de ficheros y el servicio de directorio de Internet. También hay un apartado de igual a igual que puede complementar la visión de los sistemas de igual a igual dada en este módulo. Keagy, S. (2000). Integrating Voice and Data Networks. Indianapolis: Cisco Press. En este libro se describe el protocolo SIP. Niederst, J. (2006). Web Design in a Nutshell (3.ª ed.). Sebastopol: O'Reilly. En este libro hay dos secciones dedicadas a los formatos de audio y vídeo que se transmiten por Internet. Hersent, O.; Gurle, D.; Petit, J. P. (1999). IP Telephony: Packet-Based Multimedia Communications Systems. Indianapolis: Addison Wesley Professional. En este libro, se describen los protocolos SIP y H.323 para la implementación de telefonía sobre IP. Artículos Baset, S.; Schulzrinne, H. (2004). "An Analysis of the Skype Peer-To-Peer Internet Telephony Protocol". Este artículo describe la arquitectura y el protocolo de Skype basados en la captura de los datos enviados por la red que han hecho los autores. Lua y otros (2005). "A survey and comparison of peer-to-peer overlay network schemes". IEEE Communications Surveys&Tutorials (vol. 7, núm. 2). En este artículo encontraréis un resumen de cómo funcionan las redes superpuestas de igual a igual más populares, así como una comparativa entre las mismas. También encontraréis más detalle de los sistemas explicados en este módulo.


Comunicaciones inalámbricas Miquel Font Rosselló PID_00147722

© FUOC • PID_00147722


Comunicaciones inalámbricas


© FUOC • PID_00147722

Índice

Introducción...............................................................................................

5

Objetivos.......................................................................................................

7

1.

9

Sistemas de comunicación de la telefonía móvil....................... 1.1.

GSM (global system for mobile communication) ............................

10

1.2.

GPRS ............................................................................................

16

1.3.

EDGE ...........................................................................................

19

1.4.

UMTS ...........................................................................................

19

1.4.1.

Equipos móviles .............................................................

28

Redes inalámbricas............................................................................

29

2.1.

Infrarrojos ....................................................................................

30

2.2.

Bluetooth .....................................................................................

33

2.3.

ZigBee ..........................................................................................

40

2.4.

WiFi .............................................................................................

43

2.5.

WiMax .........................................................................................

47

Resumen.......................................................................................................

54

Bibliografía.................................................................................................

55

2.

© FUOC • PID_00147722

5

Introducción

Las ondas infrarrojas, microondas y ondas hertzianas son las llamadas radiaciones electromagnéticas que se utilizan en el campo de las telecomunicaciones inalámbricas (sin cable). En las primeras comunicaciones a larga distancia que se realizaron, se utilizaban columnas de humo o luz creada con antorchas de fuego. La luz se ha usado como medio de comunicación por su facilidad de producirse y porque recorre distancias largas a gran velocidad. La ventaja de las ondas infrarrojas, microondas y hertzianas es que no son visibles para el ojo humano, a pesar de que pueden servir para la comunicación de información. En los últimos años, el mercado de las comunicaciones inalámbricas se ha popularizado debido a las ventajas de las redes sin hilos: movilidad, flexibilidad, facilidad de instalación, escalabilidad, dinamismo en los cambios de la topología, y la posibilidad de llegar donde no llega el cable. Como principales inconvenientes podemos destacar su elevado coste inicial y su seguridad. Dentro del mundo de las comunicaciones sin hilos, podemos distinguir dos grandes grupos: •

Sistemas de comunicación con telefonía móvil.

•

Redes inalámbricas.

Actualmente, la gran mayoría de la población tiene un teléfono móvil, y su uso ha experimentado un crecimiento exponencial en todo el mundo durante los últimos años. Inicialmente, la telefonía móvil, que sólo servía para mantener conversaciones telefónicas, evolucionó con la posibilidad de realizar envíos de pequeños mensajes de texto (SMS). Más adelante se posibilitó el acceso a Internet, primero a través del protocolo WAP, después el aumento de las velocidades de acceso a Interent con GPRS y finalmente, con las tecnologías UMTS, que permiten disponer de terminales móviles (teléfonos, ordenadores de bolsillo...) multimedia con múltiples servicios y aplicaciones con conexiones a altas velocidades. A escala mundial se ha alcanzado la cifra de 4.000 millones de abonados móviles, con un índice de penetración en torno al 60%. En el 2009, China era el mercado más importante, con más de 600 millones de usuarios. El sistema GSM era el más utilizado, con una cuota en turno al 80% y más de 3.000 millones de usuarios. El número de usuarios de 3G en el mundo superaba los 900 millones (250 millones UMTS/HSPA).


© FUOC • PID_00147722

6

La evolución de las redes inalámbricas de área local WiFi, gracias a la popularización de los accesos domésticos a Internet, se ha extendido en multitud de hogares y empresas, así como la utilización del protocolo Bluetooth para interconectar diferentes accesorios y dispositivos en ordenadores, impresoras, ratones, teclados, etc.


© FUOC • PID_00147722

7

Objetivos

El estudio de los materiales didácticos de este módulo tiene que permitiros alcanzar los objetivos siguientes:

1. Conocer las tecnologías más habituales y actuales utilizadas en la telefonía móvil comercial. 2. Tener una visión general de la rápida evolución histórica de la tecnología móvil en los últimos treinta años. 3. Entender bien las características y limitaciones de cada tecnología de telefonía móvil. 4. Saber cuáles son las funcionalidades actuales y futuras que se ofrecen a los usuarios de la telefonía móvil. 5. Conocer los estándares y los nombres de las redes inalámbricas de uso más común en la actualidad. 6. Entender bien la diferencia de las funcionalidades de las redes inalámbricas según su tipología: consumo, prestaciones, velocidad de transmisión, distancia entre los equipos, etc. 7. Saber elegir una tecnología inalámbrica concreta para una situación particular.


© FUOC • PID_00147722

9

1. Sistemas de comunicación de la telefonía móvil

En 1985 surgió en Europa la primera generación (1G) de teléfonos móviles después de adaptar el sistema advanced mobile phone system (AMPS) a los requisitos europeos denominados total access communications system (TACS). TACS engloba todas las tecnologías de comunicaciones móviles analógicas. Con ella se podía transmitir voz pero no datos. Actualmente, esta tecnología está obsoleta y desaparecerá en el futuro. Debido a la sencillez y las limitaciones de la primera generación surgió el sistema global system for mobile communications (GSM), que marcó el comienzo de la segunda generación (2G) de la telefonía móvil. Esta tecnología puede transmitir datos, además de las bien conocidas conversaciones de voz, a una velocidad de 9,6 kbit/s; la transmisión de datos se inició con el servicio de mensajería corta o mensajes SMS. Después, surgió la tecnología WAP, que consistía en unas páginas web pensadas para verlas con las pantallas monocromas de los teléfonos móviles. Las primeras conexiones se hacían con llamadas al proveedor telefónico, que transmitía los datos como si fuera un módem tradicional y los transmitía a una velocidad de 9,6 kbits/s. En el 2001 surgió la denominada segunda generación y media (2,5G), como paso previo a la tercera generación (3G). En la 2,5G están incluidas todas las tecnologías que permiten una mayor capacidad de transmisión de datos y que surgieron como paso previo a las tecnologías 3G. Dentro de esta generación nació la tecnología general packet radio service (GPRS), que permitía acceder a Internet a través del protocolo TCP/IP. La velocidad de comunicación era de 54 kbits/s de bajada y 9,6 kbits/s de subida, y el servicio se pagaba por los datos descargados, no por el tiempo de conexión. Con la finalidad de facilitar las comunicaciones inalámbricas debido a su generalización en todo el mundo, la International Telecommunication Union (ITU) adoptó diferentes interfaces de acceso radioeléctrico llamadas international mobile telecommunications-2000 (IMT-2000) o comunicaciones móviles internacionales. Después surgieron las tecnologías 3G, que se definen dentro del IMT-2000 (de la ITU) que marca el estándar para que todas las redes 3G sean compatibles unas con otras. Actualmente, el 3GPP (3er generation partnership project) está trabajando con el universal mobile telecommunications system (UMTS), una de las


© FUOC • PID_00147722

10


tecnologías que utilizan los móviles de tercera generación (3G). Esta tecnología permite descargar datos a una velocidad de hasta 2 Mbits/s, lo que fomenta la aparición de nuevas aplicaciones y servicios. A pesar de todo, la tecnología UMTS no está actualmente concebida para suplantar la tecnología ADSL por cable de los hogares, empresas y oficinas, ya que todavía sólo se factura por descarga de datos. También es necesario que en la zona donde se utiliza haya cobertura para esta tecnología. Además, también hace falta que en la zona donde se opera haya cobertura para esta tecnología. Hoy día, la tecnología UTMS se puede utilizar para conexiones a Internet, correo electrónico, FTP (transferencia de archivos), telnet (terminal remoto), videoconferencias, comercio electrónico, etc. La cuarta generación (4G) será el futuro de la tecnología móvil, con velocidades de transmisión de 50 Mbps de subida y 100 Mbps de bajada, y utilizará diferentes tecnologías (MIMO, HSDPA, OFDM). 1.1. GSM (global system for mobile communication) El sistema global system for mobile communication1 (GSM) es un estándar aceptado por los teléfono móviles o celulares. GSM es el nombre de un grupo de estandarización, ideado en 1982, pensado para crear un estándar de comunicación para los teléfonos móviles europeos.

El sistema GSM, por ser un sistema estándar, ofrece la ventaja de permitir al usuario disfrutar de los servicios contratados al mantenerlo conectado de manera automática independientemente de la parte del mundo donde se encuentre. Eso es posible gracias al hecho de que, al ser un sistema celular global, el espacio está dividido en celdas, de modo que cada una de ellas dispone de una estación de radio que le da cobertura. De esta manera, a medida que un usuario se desplaza de una celda a otra, la cobertura y la transmisión se recuperan de manera automática en la nueva estación de radio gracias al hecho de que todas ellas se encuentran interconectadas (proceso denominado handover). Por este motivo, y a causa del auge de este sistema de comunicación, puede ocurrir que, en algunos lugares y ciertas épocas del año, el sistema quede congestionado cuando la demanda de servicio en una celda o zona geográfica concreta supera su capacidad, como pasa en algunas zonas turísticas en temporadas de gran afluencia.

El estándar GSM proporciona recomendaciones pero no requerimientos. Las especificaciones definen en detalle las funciones y los requerimientos de las interfaces, pero no describen el hardware de los equipos. La razón de hacerlo

(1)

En castellano, sistema global de comunicación móvil.

© FUOC • PID_00147722

11


así es limitar al máximo el número de diseñadores para hacer posible que un mismo operador de telecomunicaciones pueda adquirir los equipos de varios fabricantes diferentes. La red GSM se divide en tres sistemas: 1) el sistema de conmutación (switching system, SS), 2) el sistema de estación base (base station system, BSS), y 3) el sistema de operación y soporte (operation and support system, OSS). Los elementos básicos de una red GSM se describen en la siguiente figura.

El sistema de conmutación (SS) es el responsable de gestionar el procesamiento de las llamadas y las funciones del suscriptor. Su estructura está constituida por los elementos siguientes: •

Registro�de�localización�(HLR). Es una base de datos utilizada para guardar y gestionar las suscripciones. Se la considera la base de datos más importante y guarda la información permanente sobre los suscriptores, los perfiles de servicios de los suscriptores, información de localización y estado de la actividad. Cuando una persona individual compra una suscripción (se da de alta con un operador de telecomunicaciones) a uno de los

Suscriptor Es el cliente-usuario de un operador de telecomunicación.

© FUOC • PID_00147722

12

operadores de telecomunicaciones (operador PC), la persona queda registrada en el HLR de este operador. •

Centro�de�conmutación�de�los�servicios�móviles�(MSC). El MSC proporciona las funciones de conmutación de telefonía en el sistema. Controla las llamadas a, y desde, otros teléfonos y sistemas de datos.

•

Registro�de�localización�de�los�visitantes�(VLR). La VLR es una base de datos que contiene información temporal sobre los suscriptores que necesitan el MSC como suscriptores visitantes. El VLR se integra dentro del MSC. Cuando una estación móvil permanece en una nueva área MSC, el VLR conectado a este MSC pedirá información sobre la estación móvil a la HLR. Después, la estación móvil realiza una llamada, y el VLR tendrá la información necesaria para realizar el establecimiento de llamada sin necesidad de tener que interrogar al HLR constantemente.

•

Centro�de�autoidentificación�(AUC). El AUC proporciona autoidentificación y encriptación para determinar la identidad y asegurar la confidencialidad de cada llamada. Protege las operaciones de red contra diferentes tipos de fraudes.

•

Registro�de�la�identidad�de�los�equipos�(EIR). El EIR es una base de datos que contiene información sobre la identidad de los equipamientos móviles que realiza la prevención que las llamadas sean escuchadas, no autorizadas o detectar estaciones móviles defectuosas.

El sistema de estación base (BSS) realiza todas las funciones relacionadas con la transmisión por radio, que consiste en controladores de estación base (BSC) y las estaciones transmisoras base (BTS). Sus funciones son las siguientes: •

El BSC proporciona todo el control de las funciones de los enlaces físicos entre el MSC y el BTS. Es un conmutador de alta capacidad que proporciona funciones como el control de la radiofrecuencia (RF), información de la configuración de celda, niveles de potencia en las BTS. Varios BSC son servidos por un mismo MSC.

•

El BTS proporciona la interfaz de radio hacia la estación móvil. El BTS es el equipamiento de radio (transmisores y receptores y antenas) que se necesita para proporcionar servicio a cada celda. Un grupo de BTS es controlado por un BSC.

El centro de mantenimiento y operaciones (OMC) se conecta a todos los equipos en el sistema de conmutación y a los BSC. La implementación del OMC se llama el sistema de soporte y operaciones (OSS). El OSS es la entidad funcional a partir de la cual el operador de la red controla y monitoriza el sistema. El OSS ofrece al cliente soporte para las operaciones de mantenimiento centrali-


© FUOC • PID_00147722

13

zadas, regionales y locales. Una función importante del OSS es proporcionar una visión global de la red y dar soporte a las actividades de mantenimiento de las diferentes organizaciones. Otros elementos son el message center (MXE), que guarda los mensajes de datos, de voz, y de fax; el mobile service node (MSN), que proporciona servicios de red inteligentes, el gateway mobile services switching center (GMSC), que sirve para inteconectar dos redes, y la GSM interworking unit (GIWU), que consiste en el hardware y software de la interfaz de varios redes. La red GSM se construye a partir de áreas geográficas. La siguiente figura muestra las agrupaciones en celdas, áreas de localización (LA), áreas de servicio MSC/VLR y áreas públicas móviles de tierra (PLMN).

La celda es el área de cobertura proporcionada por una estación base de transmisión (BTS). La distribución más habitual de posicionar las celdas es crearlas hexagonales para aumentar la cobertura de la red y minimizar los efectos de los transmisores de las celdas contiguas.


© FUOC • PID_00147722

14

La red GSM identifica cada celda a través de la identidad global de celda (CGI), que es un número asignado a cada celda. Un área de localización es un conjunto de celdas. En esta área es donde el suscriptor está situado. Cada área de localización está servida por uno o más controladores de estaciones base, para una sola MSC. A cada área de localización se le asigna un número denominado identidad de localización de área.

Cada área de servicio MSC/VLR representa la parte de la red GSM que es cubierta por una MSC, y se registra en el VLR de la MSC.

El área de servicio PLMN es un área servida por un operador de red:


© FUOC • PID_00147722

15

GSM transmite entre las frecuencias de 1,850-1,9990 MHz (teléfono móvil y estación base), y su velocidad de transmisión máxima puede ser de 270 Kbps. Hay dos tipos de servicios básicos ofrecidos por GSM: telefonía y datos. Los servicios de telefonía son básicamente los servicios de voz que proporcionan los suscriptores para comunicarse con otros suscriptores (telefonía normal y llamadas de emergencia). Los servicios de datos son básicamente los siguientes: •

Servicio de fax de grupo III: permite que un fax GSM se pueda comunicar con un fax analógico.

•

Servicio de transmisión de mensajes cortos SMS: 160 caracteres alfanuméricos entre estaciones móviles, garantizando que los mensajes se guardarán si la otra estación no está conectada, y, por tanto, se recibirán con toda seguridad.

•

Servicio de buzón de voz: una máquina del operador recibe y guarda las llamadas y mensajes del buzón de voz.

•

Servicio de envío de mensajes broadcast entre los suscriptores de un área.

•

Servicio de correo de fax: el suscriptor puede recibir un mensaje de fax en cualquier máquina de fax. Otros servicios que ofrece GSM Otros servicios suplementarios que ofrece GSM son: • • • • • •

redireccionamiento de llamadas entrantes hacia otro número de teléfono prevención o filtrado de determinadas llamadas salientes de la estación móvil prevención o filtrado de recepción de determinadas llamadas aviso del coste de una llamada o un mensaje conversaciones telefónicas múltiples etc.

El suscriptor, para comunicarse dentro de la red GSM, utiliza el teléfono móvil, que internamente es un transmisor y receptor de señales. El teléfono móvil está formado por diferentes circuitos de control; tiene unos dispositivos de


© FUOC • PID_00147722

16

amplificación y modulación/desmodulación de la señal, circuitos de codificación y descodificación de señales A/D y D/A, un altavoz y un micrófono, una batería, una pantalla, un teclado y una antena.

El teléfono móvil lleva una tarjeta inteligente, denominada módulo de identificación de suscriptor (SIM). Es un elemento exclusivo del suscriptor del servicio y constituye la base del sistema de abonado ofrecido por el operador de la red. Cuando se introduce dentro de un teléfono móvil, éste adquiere el número de teléfono asociado a la tarjeta SIM. Dentro de cada tarjeta SIM se guarda la international mobile suscriber identity (IMSI), que es la identificación internacional del suscriptor. 1.2. GPRS El general packet radio service (GPRS) o servicio general de paquetes vía radio es una extensión del GSM, que permite la transmisión de datos por paquetes, con velocidades de transferencia de 56 a 144 Kbps. Servicios como el wireless application protocol (WAP), servicio de mensajería multimedia (MMS), acceso a Internet o SMS pueden utilizar el GPRS. La transferencia de datos de GPRS se cobra por volumen de información transmitida, no por tiempo, independientemente de si el usuario utiliza toda la capacidad del canal o está en estado de inactividad.

GPRS es una tecnología de conmutación de paquetes que surge como una evolución de las redes GSM para proporcionar mayor velocidad y más prestaciones en el acceso móvil a servicios de datos e Internet. Complementa las redes GSM, y no las sustituye. Es una buena alternativa a la migración progresiva hacia la tercera generación de redes móviles y permite una introducción gradual de aplicaciones y servicios para evaluar la viabilidad y rentabilidad del acceso móvil a Internet.

GPRS se basa en una red de conmutación superpuesta a la red GSM. Fue necesario instalar nuevos nodos y elementos de red sobre la red GSM para soportar servicios de conmutación de paquetes pero se utiliza la misma infraestructura GSM en el subsistema de radio. Las estaciones base son las mismas en GSM que en GPRS.


© FUOC • PID_00147722

17

Los tipos de terminales GPRS pueden ser de: •

Clase�A: soporta tanto servicios GSM como servicios GPRS de manera simultánea.

•

Clase�B: soporta servicios GSM y servicios GPRS, pero de forma alternativa, no simultánea.

•

Clase�C: soporta servicios GPRS de forma exclusiva, habitualmente en forma de tarjeta para insertar en un PC portátil.

Acceso a Internet Un acceso propio a Internet podría ser de la siguiente manera con APN: movistar.es. El perfil estaría configurado por defecto para navegar por Internet con el TME como proveedor del servicio y acceso a los diferentes servicios ubicados en la red de TME. La secuencia de acciones sería: 1) MS solicita la activación de un contexto con el APN movistar.es. 2) El MS proporciona un identificador y una contraseña genéricos. Por ejemplo, usuario: MOVISTAR; clave: MOVISTAR. 3) El GGSN solicita la asignación de una dirección IP. 4) El servidor Radius del TME asigna una dirección IP al MS. 5) El MS puede acceder a Internet a través de la red de TME.


© FUOC • PID_00147722

18


Por ejemplo, se puede crear una conexión a Internet en un ordenador portátil de las siguientes maneras: •

Creando una conexión entre el portátil y un teléfono móvil mediante el protocolo bluetooth (o un enlace de infrarrojos). El teléfono móvil tiene la capacidad de crear una conexión a Internet a través de la red GPRS. La comunicación entre el ordenador y el teléfono móvil se hace a través de una aplicación que gestiona la conexión entre los dos equipos.

•

Conectando al ordenador directamente con una tarjeta PC Card con un SIM GSM

El wireless application protocol (WAP) es un protocolo con el objetivo de la combinación de dos tecnologías de comunicación inalámbrica e Internet. Funciona sobre GSM, pero lo puede hacer sobre GPRS o UMTS, como veremos más adelante. Se trata de un protocolo que permite la conexión de terminales móviles a fuentes externas de forma interactiva, ya sean servidores IP, bases de datos o multimedia. Por ejemplo, las estaciones móviles para navegar por Internet incorporan un micronavegador WAP, que es equivalente a un navegador web. El micronavegador es el visualizador que permite ver páginas WML, que es un lenguaje muy parecido al HTML. Las pasarelas WAP convierten páginas HTML en páginas WML, teniendo en cuenta el reducido tamaño de las pantallas y las funcionalidades de los dispositivos móviles (teléfonos móviles, PDA...). Otros usos de WAP WAP también ofrece servicios para la transferencia asíncrona de mensajes multimedia (MMS), y también permite enviar y recuperar los mensajes en un servidor e-mail de Internet a través de las oportunas conversiones.

Difusión de EDGE Últimamente han aparecido tarjetas de red y teléfonos móviles con tecnología EDGE de diversos fabricantes, como el aumento de redes y operadores en diversos países con esta tecnología.

© FUOC • PID_00147722

19

1.3. EDGE

Enhanced data for global evolution (EDGE) y enhanced data rates for GSM evolution son tecnologías que permiten aumentar las velocidades de transmisión de datos y la eficiencia espectral, facilitando nuevas aplicaciones y el aumento de la capacidad para el uso en servicios de telefonía móvil.

Suponen un paso adelante en los servicios de datos de GSM y GPRS y distingue: •

Enhanced circuit-switched data (ECSD).

•

Enhanced general packet radio service (EGPRS).

1.4. UMTS El espectacular desarrollo que ha experimentado la tecnología de los sistemas de comunicación y el acceso a todo tipo de información por parte de los usuarios son algunas de las causas que han potenciado el desarrollo de una nueva generación de terminales de comunicación capaz de facilitar la interconexión de las distintas redes mundiales. Los sistemas UMTS (o UTMS) o sistemas de tercera generación (3G o W-CDMA) han ido desplazando gradualmente los sistemas GSM actuales a causa de las grandes ventajas que supone para los usuarios tener a su disposición un sistema de interconexión global de todas las redes. UMTS equivale a la tercera generación de comunicaciones móviles. Una generación más fiable y flexible que las dos anteriores. IMT-2000 define un estándar global para la tercera generación, iniciativa de la ITU para proveer de acceso inalámbrico a la infraestructura global de telecomunicaciones a través de sistemas por vía satélite y sistemas terrestres. UMTS es la propuesta europea (ETSI) para promover la utilización de UMTS Terrestrial Radio Access (UTRA) en el IMT-2000. 3GPP (Third Generation Partnership Project) es un foro formado por organismos de diferentes países (ETSI, TTA, TTC y CWTS) para la elaboración de especificaciones técnicas para UMTS.


© FUOC • PID_00147722

20


Los objetivos de IMT son: la convergencia de redes fijas y móviles, igualar la calidad de servicio, ofrecer servicios multimedia simétricos y asimétricos, roaming global, asignación dinámica de ancho de banda hasta un máximo inicial de 2 Mbps, acceso personalizado –concepto de virtual home environment (VHE) para definir un perfil de servicio constante y homogéneo independiente de la red que le sirve el abonado–, uso de la tecnología de paquetes y protocolos IP, soporte de un amplia gama de terminales, y capacidad para un alta densidad de usuarios.

En la implantación de los sistemas 3G juega un papel muy importante el foro UMTS, un organismo independiente, creado en 1996, en el que participan cerca de 170 compañías de 30 países, pertenecientes a las industrias suministradoras de equipos, operadores de telecomunicaciones y organismos de regulación. El foro está comprometido en la formación del consenso necesario para introducir y desarrollar con éxito el estándar UMTS y así poder satisfacer la demanda del mercado de unas comunicaciones móviles personales de bajo coste y alta calidad. Los países europeos lo están desarrollando en cooperación con las organizaciones de estandarización en el 3G. UMTS en España España fue uno de los países pioneros en la tecnología UMTS, y ha sido uno de los primeros países en lanzar el servicio. En el 2000 se adjudicaron cuatro licencias UMTS disponibles a las operadoras Telefónica Móviles (Movistar), Airtel (actualmente Vodafone), Amena (actualmente Orange) y el consorcio Xfera (más conocido como Yoigo).

Las fases del desarrollo de UMTS han sido: •

Primera�fase. Elaboración de las descripciones técnicas y evaluación de las soluciones para UTRAN. Concluir con una descripción detallada de UTRAN en la que se incluyen los protocolos de interfaz de radio, los protocolos internos y los protocolos del subsistema de red.

•

Segunda�fase. Elaboración de las especificaciones del Release 99 para la integración de UMTS con las redes GSM/GPRS existentes.

•

Tercera�fase. Corrección iterativa de las especificaciones prevista para finales del 2001.

•

Cuarta� fase. Incremento del bit rate para alcanzar tasas superiores a 2 Mbits/s.

Dirección web recomendada Podéis acceder al foro UMTS a través de la página web http://www.umts-forum.org.

© FUOC • PID_00147722

21

Arquitectura global GSM

UMTS es una tecnología apropiada para una gran variedad de usuarios y de tipos de servicios, y no únicamente para usuarios avanzados. UMTS ofrece facilidad de uso y costes bajos, servicios modernos y mejorados, acceso rápido, transmisión de paquetes de datos y velocidad de transferencia de datos a demanda, entorno de servicios amigable y consistente.

Las características más sobresalientes de UMTS son: roaming sin fisuras, acceso global rápido, multimedia, separación de servicios y plataformas, un terminal puede estar conectado a varios nodos a la vez, velocidad de transmisión de hasta 2 Mbps, capacidad para determinar la posición, mecanismos de seguridad, calidad de servicio (servicios de valor añadido o calidad) muy desarrollada, VHE (interfaz para cualquier red).

UMTS proporciona servicios de fácil uso y adaptables para abordar las necesidades y preferencias de los usuarios, una amplia gama de terminales para realizar un fácil acceso a distintos servicios y bajo coste de los servicios para hacerse con un mercado masivo. También ofrece la capacidad de ofrecer diferentes formas de tarificación y el servicio de roaming internacional. UMTS ha evolucionado para integrar todos los servicios ofrecidos por las distintas tecnologías y redes actuales (GSM, RDSI, Internet...) y se puede utilizar en determinados terminales (teléfono fijo, inalámbrico, celular, terminal multimedia...), tanto en ambientes profesionales como domésticos, ofreciendo una mayor calidad de servicios y soportando la personalización del usuario y los servicios multimedia móviles en tiempo real. Los terminales son multimodo y multibanda, con cámara incorporada, pantalla de color y una gran memoria. Los servicios 3G combinan el acceso móvil de alta velocidad con los servicios basados en el protocolo IP. Pero la 3G no sólo lleva una conexión rápida al World Wide Web (WWW), sino que, además, implica nuevas formas de comu-


© FUOC • PID_00147722

22

nicación, de acceder a la información, de hacer negocios, aprender y disfrutar del tiempo libre, que relegan al pasado las conexiones fijas y lentas. Como la 3G puede realizar múltiples conexiones simultáneamente desde un mismo terminal móvil, un usuario se puede conectar a una base de datos remota para obtener información sin necesidad de interrumpir una sesión de videoconferencia. Para asegurar el éxito de los servicios 3G, se proporciona a los usuarios unas comunicaciones muy eficientes, con una alta velocidad y calidad, y fáciles de utilizar. Por eso ofrecen: transmisión de alta fiabilidad, hasta 384 kbits/s en espacios abiertos y 2 Mbits/s con baja movilidad, uso del ancho de banda dinámico en función de la aplicación, soporte tanto en conmutación de paquetes como de circuitos, acceso a Internet (navegación WWW), videojuegos, comercio electrónico, vídeo y audio en tiempo real, diferentes servicios simultáneos en una sola conexión, calidad de voz con la red fija, mayor capacidad y uso eficiente del espectro, personalización de servicios según el perfil de usuario, servicios dependientes de la posición, incorporación gradual en coexistencia con los sistemas actuales de 2 GR, itinerancia o roaming (incluido el internacional) entre diferentes operadores y cobertura mundial con servicios terrestres y por satélite.

La estructura de las redes UMTS está compuesta por dos grandes subredes: la red de telecomunicaciones y la red de gestión. La primera es la encargada de sustentar el trasvase de información entre los extremos de una conexión. La segunda tiene como objetivo la provisión de medios para la facturación y tarificación de los abonados. Tiene los siguientes elementos: •

Núcleo de la red (core network).

•

Red de acceso a radio (UTRAN).

•

Terminal móviles.

La velocidad de transferencia de datos que la Unión Internacional de Telecomunicaciones (UIT) requiere en su solución IMT-2000 va desde los 144 kbit/s sobre vehículos a gran velocidad, hasta los 2 Mbits/s sobre terminales en interiores de edificios (cifra al menos 60 veces superior a la que se tenía cuando se utilizaba un módem convencional para la red telefónica conmutada, la telefonía de toda la vida), pasando por los 384 kbit/s en usuarios móviles en vehículos de baja velocidad. Los tipos de celdas en UMTS son:


© FUOC • PID_00147722

•

23

Macroceldas (radio entre 1 y 40 Km). Cobertura celular en grandes áreas abiertas y las celdas sirven de paraguas para cubrir agujeros entre zonas con microceldas.

•

Microceldas (radio entre 50 y 1.000 metros). Son la cobertura celular en áreas urbanas y autopistas. Usan antenas direccionales, y sirven también para cubrir las zonas oscuras en macroceldas.

•

Picoceldas (radio inferior a 50 metros). Se usan en entornos residenciales e interiores de oficinas. La zona cubierta depende de la estructura del edificio y los materiales utilizados.

Después de la implantación del sistema UMTS, el concepto de teléfono móvil ha cambiado radicalmente, pasando de ser un simple instrumento de comunicación a convertirse en un terminal multimedia con múltiples capacidades para la comunicación y el ocio, gracias a la gran cantidad de servicios ofrecidos y que crecen cada día. Además, para zonas en las que la telefonía móvil no llega o llega de manera deficiente, la tecnología UMTS habilita la posibilidad de hacer llegar los servicios de telecomunicaciones avanzados. Nuevos servicios a través de UMTS Actualmente, algunos operadores ya ofrecen vídeollamadas, vídeo mensajería, descarga de juegos, música de calidad MP3, clips de vídeo e imágenes en directo de temas de actualidad y la conexión a Internet para navegar desde el móvil. Algunos operadores ya prometen canal de televisión 24 horas en directo, cursos en línea, etc.

Los modelos de mercado UMTS son: •

Modelos de interrelación: –

B2B: Business-to-Business.

–

B2E: Business-to-Employee.

–

B2C: Business-to-Consumer.


© FUOC • PID_00147722

•

24

Clases de servicios básicos: –

Intranet/extranet móvil.

–

Servicios de localización.

–

Servicios de voz.

–

Servicios de mensajería multimedia.

–

Acceso móvil a Internet.

–

Ocio personalizado.

Gráfico de la implantación de UMTS

UMTS ofrece servicios básicos de telecomunicación: •

Servicios� portadores: servicios de conmutación de circuitos para transmisión de voz y audio, servicios de conmutación de paquetes (llamadas virtuales, canales virtuales permanentes, conectividad RDSI –interactiva: conversación, mensajería a demanda–, distribución –envío continuo a múltiples usuarios–, señalización a los usuarios). En la transferencia de la información puede ofrecer una tasa binaria constante de información garantizada, una tasa binaria variable dinámicamente no garantizada, una tasa binaria variable dinámicamente en tiempo real con una tasa binaria mínima garantizada. El tráfico puede ser punto a punto o unidireccional punto-multipunto (multicast, broadcast). Con respecto a la calidad de la


25

© FUOC • PID_00147722


información, puede tener un máximo retardo en la transferencia, una variación en el retardo, una tasa de error de bit y una tasa de datos. Tasas de transmisión en redes de acceso móvil. Tiempo de descarga de aplicaciones típicas

•

Aplicación

RDSI

GSM

GRPS

UMTS

E-mail�(10�Kbytes)

1s

8s

0,7 s

0,04 s

Página�web�(20�Kbytes)

2s

20 s

1,6 s

0,1 s

Fichero�PowerPoint�(2�Mbytes)

4 min

28 min

2 min

7s

Videoclip�(4�Mbytes)

8 min

48 min

4 min

14 s

Teleservicios: servicios de telecomunicación que proporcionan la capacidad de comunicación completa entre los usuarios, incluidas las funciones de los equipos terminales, en funciones de los protocolos acordados entre los operadores de red: telefonía (voz, fax, transmisión de datos), teleconferencia (multiparte, llamadas múltiples, llamadas en grupo), servicios propios UMTS (audio, vídeo, multimedia, emergencia, mensajería, movilidad), servicios multimedia interactivos (IMN: datos, gráficos, imágenes, audio y vídeo interactivo). Teleservicios de UMTS Algunos ejemplos de teleservicios propios de UMTS son: petición de bases de datos, servicio de listín telefónico, navegación y localización, e-mail, llamadas de emergencia, llamadas de emergencia masiva, servicios de mensajería corta (fax, mensajes de voz, correo electrónico), control de equipos remotamente, telecompra, monitorización de vídeo, mensajes de voz, paginación, transmisión de audio y vídeo... Servicio

Duración de la llamada

Tasa de datos (kbit/s)

Error de bit

Telefonía • Voz • Teleconferencia

2 min. 1h

8-32 32-128

10 -4 10

Videotelefonía

2 min.

64-348

10

1h

348-768

10

Sin conexión 2 min. Sin definir Sin conexión

1,2-9,6 8-32 64 1,2-64

10 -4 10 -7 10 -6 10

Bases�de�datos

Sin definir

2,4-768

10

Telecompra

Sin definir

2,4-768

10

Teleacción/control

Sin definir

1,2-64

10

Videoconferencia Mensajería • SMS • Buzón de voz • Videomensaje • Correo electrónico

•

Servicios�suplementarios: servicios que modifican o complementan un servicio básico de telecomunicación, como, por ejemplo, la identificación

Retardo (ms)

-4

40 40

-7

40-90

-7

90

-6

100 90 100 100

-6

200+

-6

90

-6

100-200

© FUOC • PID_00147722

26


del número (marcación abreviada, rechazo de llamadas, identificación de grupos de llamadas), redireccionamiento de llamadas y finalización de las llamadas, comunicación multiparte (llamadas entre grupos cerrados de usuarios), tarificación (información adicional sobre la llamada), restricción de llamadas (rechazo de llamadas entrantes). •

Servicios�de�valor�añadido: servicios adicionales específicos de un usuario, como, por ejemplo, movilidad personal (transferencia de números de teléfono en cualquier terminal a través de USIM, entorno virtual donde el usuario puede establecer su propia lista de servicios), ancho de banda a demanda, utilización eficiente de recursos por servicios que dependen críticamente de variaciones en la tasa de transmisión MMS y vídeo según la calidad-precio que desee el usuario...

El virtual home environment (VHE) es el entorno portable de servicios personales disponibles para el usuario en las diferentes redes y terminales. Los usuarios acceden a las mismas características personalizadas, interfaz de usuario y servicios particulares con independencia de la red y el terminal, en cualquier lugar donde esté localizado. Así, los servicios personalizados incluyen los datos de usuario personalizados, el conjunto de servicios integrados desde la perspectiva del usuario independientemente de la red de acceso (fija, móvil, inalámbrica...).

Las clases de calidad de servicio en UMTS son: •

Clase�conversacional: permite la conversación en directo (real time) entre los usuarios. El retardo máximo viene dado por la percepción humana de audio y vídeo.

•

Clase�de�tramas�(streaming): recepción audio y vídeo en un solo sentido. Conserva la relación temporal entre las entidades (retardo limitado).

•

Clase�interactiva: una máquina o un humano recibe datos bajo demanda. Depende del patrón de interacción y de la carga de datos (por ejemplo, acceso a web o a una base de datos).

•

Clase�de�fondo�(background): el usuario envía y recibe datos en segundo plano y el destino no espera los datos en un período de tiempo preciso (correo electrónico, SMS, recepción de registros de datos...).

Los atributos del QoS pueden ser: •

Tráfico unidireccional/bidireccional.

•

Clase de tráfico: conversacional, streaming, interactivo, background.

•

Tasa binaria máxima (kbps) y tasa binaria garantizada (kbps).

(2)

Sigla de unidad de datos del servicio.

27

© FUOC • PID_00147722

•

Orden de envío (sí/no).

•

Tamaño máximo de la SDU2 (bytes).

•

Información de formato de la SDU (bits).

•

Tasa de error de SDU y tasa de error de bit en la SDU.

•

Reenvío de la SDU errónea (sí/no).

•

Retardo en la transferencia (ms).

•

Prioridad de gestión de tráfico.

•

Prioridad en la asignación / retención de canal.

•

Descriptor estadístico de la fuente.

•

Indicación de señalización (sí/no). Clase de tráfico


Conversacional

Técnica tramas

Interactivo

Trasfondo

<=16.000

<=16.000

<= 16.000 – tiempo de sistema

<= 16.000 – tiempo de sistema

Sí/no

Sí/no

Sí/no

Sí/no

<= 1.500 o 1.502

<=1.500 o 1.502

<= 1.500 o 1.502

<= 1.500 o 1.502

Sí

Sí

Sí/no/–

Sí/no/–

Sí/no/–

Sí/no/–

BER (probabilidad de error de bit) residual

Porcentaje de errores de SDU

Retraso de transferencia (ms)

100 – valor mínimo

300 – valor mínimo

Tasa de bits garantizada (kbps)

<=16.000

<=16.000

Prioridad de gestión del tráfico

1, 2, 3

Prioridad de asignación/retención

1, 2, 3

1, 2, 3

1, 2, 3

1, 2, 3

Habla/desconocida

Habla/desconocida

Sí/no

Tasa de bits máxima (kbps)

Orden de entrega Medida máxima de SDU (unidad de datos de servicio) (octetos) Información en formato SDU Entrega de SDU erróneas

Descriptor estadístico de origen

Indicación señalizadora

El valor añadido de las aplicaciones y servicios sigue las normas de las 4 Qs: •

Cualquier lugar: oficina, casa, carretera y medio de transporte.

•

Cualquier red: GSM/GPRS, EDGE, UMTS.

•

Cualquier dispositivo: teléfono móvil, PDA, portátil.

•

Cualquier situación: negocios, ocio, educación.

Las características clave serán su universalidad, que siempre estará encendido, su alcance, la personalización, la accesibilidad y la localización.

28

© FUOC • PID_00147722

La evolución de UMTS irá hacia las tecnologías high speed downlink packet access (HSDPA) (3,5G y 3,75G) con terminales HSUPA y a los teléfonos de cuarta generación (4G) para mejorar el rendimiento por el uso simultáneo de aplicaciones y aumentar la cobertura de tecnologías 3G, de forma que el rendimiento de la red se incremente hasta un 81% con respecto a GPRS y se produzca una evolución en millones de usuarios los próximos años.

UMTS

1.4.1. Equipos móviles Para que los usuarios utilicen los servicios 3G hacen falta nuevos teléfonos y otros terminales capaces de proporcionar los servicios que aquellos desean, desde la telefonía móvil hasta los multimedia (voz, datos y vídeo). Los teléfonos móviles UMTS son muy útiles para el viajero y el cosmopolita. Están diseñados de manera tal que puedan realizar el roaming en otras redes UMTS (en el supuesto de que su proveedor UMTS se asocie con el proveedor local UMTS) en diversas zonas del mundo. Además, casi todos los teléfonos UMTS, a excepción del Japón, son UMTS/GSM de modo dual; eso significa que durante una llamada, si salimos fuera de los límites de la zona UMTS, la llamada será transferida por una cobertura GSM.

Teléfono móvil

Los teléfonos UMTS soportan una gran variedad de frecuencias ya que tienen que poder utilizarse en todo el mundo. Muchos países aportan diferentes frecuencias UMTS. Al igual que las tarjetas SIM para teléfonos GSM, existe la tarjeta USIM para los teléfonos UMTS. Parecidas a las tarjetas SIM, las tarjetas USIM son una forma de identificar y autentificar a nivel local a los clientes itinerantes. Si las redes UMTS tienen un acuerdo entre ellas, a continuación, un usuario móvil puede utilizar sus teléfonos UMTS en otra red, aunque los precios pueden cambiar. Las tarjetas USIM tienen espacio para almacenar los contactos, mensajes y otra información. De la misma manera que las tarjetas SIM, las tarjetas USIM también se pueden cambiar de un teléfono a otro, y el nuevo mantendrá la identificación de la tarjeta.


© FUOC • PID_00147722

29

2. Redes inalámbricas

Las diferentes tecnologías sin hilos (Wireless) se suelen agrupar basándose en el radio de acción (alcance) de cada una de ellas: •

Redes�personales�sin�hilos�(WPAN,�wireless�personal�area�network). Este concepto se aplica cuando la distancia que se quiere cubrir es del orden de unos cuantos metros. La familia de estándares más representativos son el 802.15.1 (Bluetooth), el 802.15.3a (UWB) y el 802.15.4 (Zigbee).

•

Redes�locales�sin�hilos�(WLAN,�wireless�local�area�network). Permiten dar servicios a distancias del orden de un centenar de metros (un piso, una planta de un edificio, una nave industrial, unas cuantas calles, etc.). El estándar más destacado en este campo es el 802.11 (WiFi).

•

Redes�metropolitanas�sin�hilos�(WMAN,�wireless�metropolitan�area�network). Permiten dar servicios a distancias del orden de unos cuantos kilómetros (un barrio, un pueblo, una urbanización...). El estándar más destacado en este campo es el 802.16 (WiMAX).

•

Redes�de�gran�alcance�sin�hilos�(WWAN,�wireless�wide�area�network). Tienen una cobertura más amplia. La familia de estándares más representativos es la de GSM, GPRS y UMTS.

Clasificación de las tecnologías sin hilos


© FUOC • PID_00147722

30

2.1. Infrarrojos En el año 1800, Friedrich William Herschel descubrió la radiación infrarroja. Esta radiación tiene longitudes de onda más largas que la luz visible, pero más cortas que las microondas. Sus frecuencias son menores que las de la luz visible y mayores que las de las microondas. La fuente primaria de una radiación infrarroja es el calor o radiación térmica. Cualquier objeto que tenga una temperatura superior al cero absoluto (-273,15 °C o 0° Kelvin) irradia ondas en la banda infrarroja.


© FUOC • PID_00147722

31


Ventaja de la luz infrarroja La luz se ha utilizado como medio de comunicación por su facilidad de producirse y porque recorre distancias largas a gran velocidad. La ventaja de las ondas infrarrojas, microondas y hertzianas es que no son visibles para el ojo humano, a pesar de que pueden servir para la comunicación de información.

Dentro del mundo de las comunicaciones, se utiliza mucho porque hace falta relativamente poca energía para generarla. Los primeros en utilizarla fueron los ingenieros de una empresa que comunicaron una calculadora con una impresora para imprimir los cálculos que hacía. Otro ejemplo muy cotidiano al respecto es el mando a distancia del televisor o del reproductor de DVD.

De forma general, podemos definir la comunicación infrarroja como un haz enfocado de luz en el espectro de frecuencia infrarroja, medido en terahertz o billones de hercios (ciclos por segundo), donde se modula la información y se envía de un transmisor a un receptor a una distancia relativamente corta.

En el año 1993, 50 compañías se unificaron para crear el IrDA, estándares internacionales para el equipo y los programas utilizados en los enlaces de comunicación por infrarrojos. La norma "IrDASerial Infrared Data Link Standard Version 1.1." establece tres niveles que deben cumplir los equipos en las secciones física, infrared link access protocol (IrLAP) e infrared link management protocol (IrLMP). Las características de la norma son: •

Bajo coste de implementación.

•

Bajos requerimientos de potencia.

•

Conectividad direccional, punto a punto.

•

Alta inmunidad al ruido.

•

Optimización por transferencia de datos.

Los datos informáticos se tratan con numeración binaria, la cual, en la comunicación infrarroja se codifica como un bit 0 si hay luz, o como un bit 1 si no hay luz. Podemos ver la comunicación infrarroja como un cable virtual por

Ejemplo de un puerto IrDA de la placa madre de un ordenador

© FUOC • PID_00147722

32


el que pasan los datos de un elemento a otro. Este tipo de comunicación que permite enviar los bits de información uno detrás de otro se llama comunicación en serie. La capa física tiene un codificador y un descodificador que transforman los niveles 1 y 0 de la señal binaria en pulsos de duración y formato especificados. Tiene un transductor (IrTxRx) consistente en un emisor (LED) y un detector (fotodíode). Un valor binario "0" se representa por un pulso, con una duración nominal mínima de 1,6 microsegundos y un máximo de 3/16 del período de bit. Un "1" se representa por la ausencia de pulso. Esta comunicación exige que el receptor de la información esté a la espera, lo que implica que el sensor receptor utilice energía para detectar cuando llega la luz. Por ello los elementos móviles con batería (teléfonos móviles, PDA...) necesitan activar y desactivar la recepción de datos. La capa de transporte se define como un flujo de datos serie asincrónica convencional compuesto por sucesivos caracteres, donde cada carácter está compuesto por un bit de arranque, 8 bits de datos, sin paridad, y un bit de parada. Con respecto al protocolo de enlace, IrDA ha definido y adoptado un proto3

colo denominado IrLAP, que es una adaptación del clásico HDLC . Transmite información para pedir una conexión a 9.600 baudios. Las velocidades de transmisión son: •

SIR (Serial IR - 115,2 kbps).

•

MIR (velocidad media - 1,152 Mbps).

•

FIR (alta velocidad - 4 Mbps).

•

VFIR (muy alta velocidad - 16 Mbps).

La comunicación entre el emisor y el receptor que se establece puede ser: •

Una línea recta directa entre el emisor y el receptor (comunicación punto a punto).

•

Si apuntamos a una pared para hacer una "carambola" entre el emisor y el receptor, establecemos una comunicación cuasidifusa.

•

Una comunicación difusa, en la que no hace falta que haya una visión directa entre emisor y receptor, de manera que los equipos tienen que ser muy potentes.

(3)

High-Level Data Link Control es un protocolo de comunicaciones de propósito general punto a punto.

© FUOC • PID_00147722

33


2.2. Bluetooth

Actualmente, la tecnología Bluetooth es la tecnología sin hilos más popular. Se trata de un protocolo basado en el estándar de comunicaciones IEEE 802.15, pensado por la transmisión de datos y voz sin hilos entre dispositivos, mediante una radiofrecuencia. Al inicio del desarrollo de los productos Bluetooth de primera generación, se tuvo en cuenta lo siguiente: •

El sistema tenía que ser universal.

•

El emisor había de consumir poca energía, ya que se usaba en equipos que

Origen del nombre Bluetooth El nombre Bluetooth tiene su origen en el rey danés Harald Blatand (Harold Bluetooth en inglés) que unificó los pueblos de Dinamarca, Noruega y Suecia, que antes estaban en guerra.

funcionan con batería. •

La conexión debía permitir la transmisión de datos y voz (aplicaciones multimedia).

•

Tenía que ser de bajo coste (el objetivo fue unos cuantos dólares para cada dispositivo).

De acuerdo con estos requisitos, Ericsson desarrolló en 1994 una tecnología que utiliza un canal de comunicación con un máximo de 720 Kb/s (1 Mbps de velocidad bruta), con un rango óptimo (opcionalmente de 100 metros con repetidores). En 1999 se creó el SIG (grupo de interés especial) de Bluetooth, formado por las empresas Ericsson, Intel, IBM, Toshiba y Nokia. Este SIG trabaja para definir, desarrollar, promover y publicar el protocolo Bluetooth. Actualmente, este SIG tiene más de 9.000 miembros. Esta tecnología es propietaria, es decir, que sólo puede producirla quien tiene la patente. Por eso sólo puede introducir esta tecnología en sus productos quien pertenece al SIG de Bluetooth. Actualmente, la velocidad máxima de transmisión oscila entre 1 Mbps y 3 Mbps. Difusión de la tecnología Bluetooth Actualmente existen muchos dispositivos electrónicos que incorporan el protocolo Bluetooth: auriculares con micrófono, ordenadores, PDA, ratones, teléfonos móviles, impresoras, gafas Oackley, cámaras fotográficas, teclados, otros dispositivos de entrada de ordenadores, etc. Los sectores industriales en los que se utiliza son: automoción, aeronáutica, naval, otros transportes, bienes de equipo mecánico, eléctrico, electrodomésticos, ordenadores, equipos de oficina, hogar, telecomunicaciones y equipos electrónicos y otros segmentos industriales. En el sector servicios tenemos: los financieros, contenidos y ocio, administración y servicios públicos, servicios privados para empresas.

Logotipo de Bluetooth

© FUOC • PID_00147722

34

Esta tecnología representa una ventaja con respecto a la tecnología de comunicación por infrarrojos ya que no hace falta que los dispositivos tengan que verse directamente para comunicarse (como ocurre con un mando a distancia y un aparato de televisión por infrarrojos). Brevemente, los servicios de las conexiones Bluetooth que actualmente se suelen ofrecer en algunos sistemas operativos como Windows o Linux: •

Transferencia�de�elementos�del�PIM: permite que los dispositivos Bluetooth remotos intercambien tarjetas de visita con este equipo, para aceptar elementos del personal information manager (PIM) con elementos de calendario, contactos, notas y mensajes de los Bluetooth remotos.

•

Sincronización�del�PIM: permite que los dispositivos Bluetooth remotos sincronicen una base de datos PIM con las del PIM del equipo.

•

Transferencia�de�archivos: permite que los dispositivos Bluetooth remotos realicen operaciones de archivo en un directorio específico en este equipo y en los subdirectorios y archivo de este directorio.

•

Acceso�a�la�red: permite que los dispositivos Bluetooth remotos compartan la conexión a la red de este equipo, que puede ofrecer acceso a Internet.

•

Acceso�telefónico�a�redes: en este caso se puede utilizar para acceder desde un ordenador a Internet a través de un teléfono móvil. El teléfono móvil accede a Internet por GPRS, y la conexión móvil-ordenador se hace por Bluetooth. El ordenador ve el teléfono móvil como si fuera un módem


35

© FUOC • PID_00147722

clásico conectado directamente al ordenador (a pesar de que la comunicación entre los dos dispositivos sea inalámbrica). El ordenador crea una conexión a Internet a través del "módem" mediante el protocolo PPP con el operador del servicio de Internet (operador de telefonía móvil). •

Puerto�serie�Bluetooth: permite que los dispositivos Bluetooth remotos se conecten al equipo a través de un puerto serie inalámbrico.

•

Fax: permite que los dispositivos Bluetooth remotos utilicen las opciones del equipo para enviar un fax.

•

Pasarela�de�audio: permite que los dispositivos Bluetooth remotos, como unos auriculares, reemplacen el micrófono y los altavoces del equipo.

•

Auriculares: permite que los dispositivos Bluetooth remotos, como un teléfono móvil, utilicen el micrófono y los altavoces de este equipo con dispositivos propios de entrada y salida. De hecho, cuando este servicio está conectado, el equipo se convierte en los auriculares del dispositivo remoto.

El sistema Bluetooth consiste en un transmisor de radio, una banda frecuencial de transmisión y una serie de protocolos de comunicaciones (físico, enlace, lógico). En muchos casos se ha desarrollado un chip CMOS que gasta mucha menos energía que un teléfono móvil (un 97% aproximadamente), controla la emisión de radio y una parte que controla digitalmente las señales recibidas. Los valores típicos de consumo se muestran en la siguiente tabla. Modo

Potencia

En espera

Menos de 0,3 mA

Voz

8 a 30 mA

Datos

5 mA (media)

mA = miliamperio

Bluetooth emite a la frecuencia de 2,4 GHz, que es una banda base, es decir, que no interfiere las frecuencias utilizadas para la industria, la ciencia y la medicina. Como se verá posteriormente, en este aspecto es bastante parecido a un sistema WiFi. El sistema tiene un transmisor de saltos de frecuencia, que consiste en una técnica de modulación en la que la señal se emite sobre una serie de frecuencias aparentemente aleatorias. De esta manera, los receptores no autorizados sólo ven una señal ininteligible.


© FUOC • PID_00147722

36

Cuando tenemos diversos dispositivos sincronizados por un reloj y una secuencia de saltos de frecuencia, también comparte el mismo canal físico de radio. Uno de ellos proporciona estos valores de referencia (sincronización y saltos de frecuencia) y se denomina dispositivo�maestro, mientras que los otros se llaman dispositivos�esclavos.

Pequeña red Bluetooth

Bluetooth permite conexiones punto a punto, y punto a multipunto. Cuando tenemos un maestro y uno o varios esclavos, creamos un piconet. Un dispositivo maestro sólo puede pertenecer a una piconet, mientras que un dispositivo esclavo se puede conectar a varias piconets al mismo tiempo (red dispersa).


© FUOC • PID_00147722

Una red Piconet Bluetooth

37


© FUOC • PID_00147722

38

Una red scatternet Bluetooth

Dentro de una piconet, cada dispositivo esclavo se conecta al dispositivo master por un canal físico. Cada uno de estos canales físicos se divide en slots. Los paquetes que viajan entre el master y el esclavo están colocados dentro de estos slots. Los canales físicos no se crean entre los esclavos. Todas las transmisiones de paquetes son gestionadas y controladas por el dispositivo master. El master, de manera secuencial, autoriza cada dispositivo para ver si requiere su servicio. El dispositivo master es el responsable de sincronizar todos los dispositivos para asegurar un cierto ritmo de transmisión de la información. Un dispositivo que se une a una piconet lo puede hacer de dos maneras. En la primera, el dispositivo empieza a descubrir todos los otros dispositivos bluetooth dentro de su radio de acción y a proporcionar información con respecto al tipo de servicio que necesita. Los dispositivos que ofrecen uno o más de los


© FUOC • PID_00147722

39


servicios demandados responden al dispositivo que demanda el servicio. En la segunda manera, el master busca dentro de su radio de acción, y, una vez descubiertos los dispositivos, éstos son añadidos automáticamente a la piconet de acuerdo con las medidas de seguridad que tienen tanto el master como el esclavo. Distancia entre dispositivos La distancia entre dos dispositivos para establecer un canal de comunicación depende de la clase de potencia emitida. Actualmente existen tres clases de potencia según que la distancia sea de: 1) Menos de 10 metros. 2) Aproximadamente 10 metros. 3) Aproximadamente 100 metros.

El protocolo Bluetooth establece tres niveles de seguridad: •

Nivel�1:�no�hay�seguridad. El dispositivo funciona en modo promiscuo, permitiendo que cualquier otro equipo Bluetooth se conecte al dispositivo.

•

Nivel�2:�seguridad�a�nivel�de�servicio. Soporta autoidentificación, encriptación y autorización una vez se ha establecido el canal de comunicación.

•

Nivel� 3:� seguridad� a� nivel� de� enlace. Las medidas de seguridad se implantan antes de que el canal de comunicación se haya establecido. Proporciona encriptación y autoidentificación.

Para configurar los dispositivos, en primer lugar hay que establecer un SSID (identificador) del dispositivo. Al encontrar los dispositivos, se establece un protocolo de seguridad basado en un código. Este código puede ser de cuatro cifras o una frase larga. El código se comprueba en el dispositivo maestro y en el dispositivo esclavo. Si es el mismo, entonces se establece el acoplamiento y empieza el intercambio de información. Esta tecnología también sufre ataques a la seguridad, y por eso tenemos que saber cuáles son y cómo se pueden detectar. Las empresas sacan mejoras (actualizaciones) para evitar estos ataques a sus productos: •

Bluejacking: permite enviar datos en forma de texto a un móvil. Este procedimiento no modifica ningún dato, pero quien recibe este ataque puede llegar a pensar que tiene un virus en su dispositivo.

•

Bluebugging: permite ejecutar pedidos en un teléfono móvil sin que el propietario reciba ningún aviso. El atacante puede hacer llamadas, enviar mensajes y otras acciones.

Bluetooth y red local Los dispositivos Bluetooth permiten integrarse dentro de una red de área local y acceder a la memoria de éstos como si fuera un recurso de red local.

© FUOC • PID_00147722

•

40

Bluesnarfing: permite acceder a datos internos del teléfono, leerlos o modificarlos. Sólo afecta equipos antiguos.

•

Car�whisperer: permite el acceso a un teléfono de manos libres de coche, y por lo tanto, escuchar llamadas o el micrófono, o enviar sonido al dispositivo.

•

Cabir�worm: programa gusano que, al instalarse en un teléfono, se copia en otros teléfonos. Sólo afecta al sistema operativo Symbian OS.

•

Denial� of� service� (DoS): consiste en denegar el servicio de Bluetooth al usuario, cosa que obliga el aparato a apagar el servicio.

2.3. ZigBee

ZigBee es el nombre de la especificación de un conjunto de protocolos de alto nivel de comunicación inalámbrica para su utilización en radio digital de bajo consumo, basado en el estándar WPAN IEEE 802.15.4. Su objetivo son las aplicaciones que requieren comunicaciones seguras con baja tasa de envío de datos y maximización de la vida útil de las baterías.

La tecnología ZigBee se diferencia por su bajo consumo, su topología de red en malla, y su integración fácil (se pueden fabricar nodos con muy poca electrónica). La relación entre IEEE 802.15.4-2003 y ZigBee es parecida a la existente entre IEEE 802.11 y WiFi Alliance. La especificación 1.0 de ZigBee se aprobó en el 2004 y está disponible en miembros del grupo de desarrollo (ZigBee Alliance). Un primer nivel de suscripción, llamado adapter, permite la creación de productos para su comercialización adoptando la especificación por un determinado precio. Esta especificación está disponible al público para fines no comerciales. Con el tiempo, se han ido creando nuevas versiones de la especificación original. En diciembre del año 2006 se publicó la especificación actual. Comercialización de productos ZigBee ZigBee tiene los módulos transmisores inalámbricos más baratos de la historia, y producidos de manera masiva. Tendrán un coste aproximado de 6 euros, y dispondrán de una antena integrada, control de frecuencia y una pequeña batería.

ZigBee utiliza la banda de frecuencias ISM para usos industriales, científicos y médicos. En concreto, en Europa utiliza la banda de 868 MHz. También muchas empresas optan por la banda de 2,4 GHz disponible en todo el mundo. El


© FUOC • PID_00147722

41

desarrollo de esta tecnología se basa en su sencillez y bajo coste. Un nodo ZigBee más completo requiere menos del 10% del hardware que necesita un nodo Bluetooth (requiere muchos menos circuitos analógicos de lo que es habitual). Los protocolos ZigBee están definidos para su uso en aplicaciones encastadas con requerimientos muy bajos de transmisión de datos y consumo energético. Se pueden utilizar para realizar un control industrial, albergar sensores empotrados, recolectar datos médicos, detectar humo o intrusos y en domótica o teleasistencia. Una red en su conjunto utilizará una cantidad muy pequeña de energía, de forma que cada dispositivo individual pueda tener una autonomía de hasta cinco años antes de necesitar un recambio en su sistema de alimentación.

Ejemplo de una aplicación domótica con ZigBee

Las desventajas de ZigBee son: tasa de transferencia muy baja, sólo manipula textos pequeños en comparación con otras tecnologías, trabaja de manera que no es compatible con Bluetooth porque no llega a tener las mismas tasas de transferencia, ni la misma capacidad de soporte para nodos, tiene una menor cobertura porque pertenece a redes sin hilos del tipo WPAN. Una red ZigBee puede constar de un máximo de 65.535 nodos distribuidos en subredes de 255 nodos (frente a los 8 nodos máximo de una subred Piconet Bluetooth). Puede alcanzar una velocidad de 250 Kbps y se utiliza en aquellas aplicaciones donde la transferencia de datos es baja (artículos de juguetería, detectores...) frente al Bluetooth, que se suele utilizar en teléfonos móviles o dispositivos de entrada/salida en equipos informáticos en los que se requiere una velocidad de transmisión mayor. Provee conexiones seguras entre los dispositivos. Los dispositivos ZigBee son muy baratos y de construcción muy sencilla. En una red ZigBee existen tres tipos de dispositivos:


© FUOC • PID_00147722

42


1)�Coordinador�ZigBee�(Coordinator,�ZC). El tipo de dispositivo más completo. Tiene que existir uno por cada red. Sus funciones son las de encargarse de controlar la red y los caminos que tienen que seguir los dispositivos para conectarse entre ellos. Requiere de memoria y capacidad de computación. 2)�Router�ZigBee�(ZR). Interconecta dispositivos separados en una topología de la red. Ofrece un nivel de aplicación para ejecutar un código de usuario. 3)�Dispositivo�final�(End�Device,�ZED). Tiene la funcionalidad necesaria de comunicarse al nodo padre (el coordinador o el router) pero no puede transmitir información destinada a otros dispositivos. De esta manera, este tipo de

Coordinador ZigBee

nodo puede estar dormido la gran mayoría de tiempo, lo que aumenta la vida media de sus baterías. Un ZED tiene unos requerimientos mínimos de memoria y por eso es significativamente muy económico. Ejemplo de instalación ZigBee En el caso de una aplicación domótica, en una habitación de la casa tendríamos diversos dispositivos finales (un interruptor y una lámpara) y una red de interconexión realizada con routers ZigBee y gobernada por el coordinador.

Routers ZigBee

Si nos basamos en la funcionalidad, se puede plantear una segunda clasificación de los dispositivos ZigBee: •

Dispositivo�de�funcionalidad�completa�(FFD): también conocido como nodo activo. Puede recibir mensajes en formato 802.15.4. Puede funcionar como router o como coordinador, o se puede utilizar en dispositivos de red que actúen de interfaz con los usuarios.

•

Dispositivo�de�funcionalidad�reducida�(RFD): también conocido como nodo pasivo. Tiene unas capacidades y funcionalidades limitadas (especificadas en el estándar) con el objetivo de conseguir un bajo coste y una gran simplicidad. Básicamente son los sensores y actuadores de la red.

Un nodo ZigBee, tanto activo como pasivo, reduce su consumo gracias a que puede estar dormido la mayor parte del tiempo (incluso muchos días seguidos). Cuando se requiere su uso, el nodo ZigBee es capaz de despertar en un tiempo muy reducido y dormir otra vez cuando no lo necesiten. Un nodo cualquiera despierta aproximadamente en 15 milisegundos.

ZigBee permite tres topologías de red: 1)�Topología�en�estrella: el coordinador se sitúa en el centro. 2)�Topología�en�árbol: el coordinador será la raíz del árbol.

Dispositivo final

© FUOC • PID_00147722

43


3)�Topología�en�malla: al menos uno de los nodos tendrá más de dos conexiones. La topología más interesante es la topología en malla. Permite que, si en un momento determinado un nodo del camino falla y se cae, se pueda realizar la comunicación entre todos los otros nodos debido a que se rehacen todos los caminos. La gestión de los caminos la realiza el coordinador. La seguridad de las transmisiones y los datos son puntos clave en la tecnología ZigBee. Ésta utiliza el modelo de seguridad de la subcapa MAC IEEE 802.15.4, la cual especifica cuatro servicios de seguridad: 1) control de accesos (el dispositivo mantiene una lista de los dispositivos comprobados por la red), 2) datos encriptados (se usa la encriptación con un código de 128 bits), 3) integración de tramas (los datos se protegen para que no sean modificadas por otros), y 4) secuencia de refresco (se comprueba que las tramas no han sido reemplazadas por otras). El controlador de red comprueba estas tramas de refresco y su valor, para ver si son las esperadas. 2.4. WiFi Últimamente se habla mucho del WiFi, una tecnología inalámbrica que en sus distintas versiones (802.11a, b y g) puede ofrecer desde 11 Mbits/s hasta 54 Mbits/s, y tiene distintas aplicaciones, especialmente en entornos locales (de corta distancia) como aeropuertos, hoteles, estaciones de servicio, centros comerciales, convenciones, pequeños pueblos..., en los que se ofrece acceso a Internet.

Nombre "Wifi" El nombre Wifi corresponde a las siglas de Wireless Fidelity, y se refiere a los procedimientos utilizados para las comunicaciones de redes locales (distancias cortas) sin hilos (wireless local area network o WLAN).

En Wi-Fi se utilizan las ondas portadoras de radio para transmitir la información. Los datos se superponen a la onda portadora de radio y se pueden extraer en el receptor final en un proceso conocido como modulación/demodulación.

Un access point (AP) es el dispositivo que hace de puente entre una red cableada y una red inalámbrica. Podemos pensar que, de alguna mane-

Logotipo de Wifi

ra, es la antena a la que nos conectamos.

Si las ondas se transmiten a diversas frecuencias, puede haber varias ondas portadoras de radio al mismo tiempo, sin que se interfieren unas con otras. Los puntos de acceso (access point) reciben la información, la guardan, y la

acces points

© FUOC • PID_00147722

44

retransmiten entre la red sin hilos y la red cableada. Si los dispositivos WiFi se comunican sin ningún punto de acceso, sino entre ellos, crearemos una red llamada ad hoc. Topología simple ad hoc (sin punto de acceso) y topología con un solo punto de acceso (BSS)

Topología más compleja: red cableada y puntos de acceso inalámbricos


© FUOC • PID_00147722

45

El IEEE 802 es un comité y grupo de estudio de estándares que pertenece al Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) que actúa sobre redes de ordenadores. La especificación concreta del sistema WiFi es la IEEE 802.11. Además de estas velocidades, el alcance de las comunicaciones puede llegar a varios centenares de metros en espacios abiertos. Continuamente aparecen equipos que pueden llegar a distancias cada vez más largas. Los estándares IEEE 802.11b y 802.11g utilizan la banda de frecuencias de 2,4 a 2,5 GHz. En Europa, el ETSI (Instituto Europeo de Normas de Telecomunicaciones) ha definido trece canales dentro de esta banda de señal. Pero no se utilizan todos, porque se suplantan y producen interferencias. Los más utilizados son los canales 1, 4, 9 y 13, ya que no son adyacentes y no reciben interferencias. Esta configuración sólo se hace habitualmente en el punto de acceso, ya que los dispositivos clientes detectan la señal. Para utilizar estas frecuencias no hace falta ninguna autorización (o licencia) de la administración competente, y por lo tanto, es una tecnología muy utilizada en entornos locales como edificios, oficinas, hospitales... Red WiFi doméstica Los elementos que se necesitan para crear una red en casa sin cable son un punto de acceso, para conectar al encaminador (router), y un dispositivo WiFi, para conectar a nuestro ordenador. Un punto de acceso es un dispositivo encargado de conectar dispositivos WiFi para crear una red sin hilos. Habitualmente, también disponemos de un conector para red con cable y podemos conectar la red sin cable con la red cableada. Muchos de los encaminadores actuales ya llevan incorporado el punto de acceso, y ofrecen tres servicios en un solo equipo: red sin hilos, red con hilos y encaminador a Internet. En el equipo encaminador encontramos la antena, que sirve para las comunicaciones sin cable; los cuatro puertos para la red Ethernet (de color amarillo habitualmente) y finalmente, el puerto de comunicación con Internet.

Si conectamos muchos puntos de acceso entre sí, el alcance de la red sin hilos aumentará. Esta acción se conoce como itinerancia, o en inglés, roaming.

Para establecer comunicación con el punto de acceso nuestro ordenador necesita un dispositivo WiFi. Este dispositivo sirve para recibir y enviar las ondas de radio donde está la información. Actualmente muchos ordenadores ya llevan integrado el dispositivo WiFi dentro de la placa madre. En los modelos más antiguos que no lo llevan incorporado se puede conectar al ordenador con tres elementos: tarjetas PCI, tarjetas PCMCIA y tarjetas USB.


© FUOC • PID_00147722

46

Existe una amplia variedad de antenas: •

Omnidireccionales. Tienen poco alcance, pero permiten un radio de cobertura de 360°, unos 300 metros en el exterior.

•

Unidireccionales. Tienen más alcance, pero sólo en una sola dirección.

Una vez se ha establecido comunicación entre una tarjeta sin cable y otro dispositivo, la tarjeta se comporta como cualquier tarjeta Ethernet cableada y se tiene que configurar como tal. Para poder establecer la conexión entre un punto de acceso y un dispositivo WiFi hace falta configurar primero el punto de acceso. Cada punto de acceso tiene su propia configuración, y actualmente se configuran con un entorno gráfico al que se accede con el protocolo web. Cuando iniciamos por primera vez un punto de acceso, el dispositivo tiene unos parámetros de configuración básicos que pueden no satisfacer nuestros intereses. Muchos de estos parámetros se pueden cambiar. El más importante es el serie set identifier (SSID): indica el identificador del servicio, y es el código (o nombre) que se incorpora a todas las comunicaciones sin cable para identificarlas como parte de la red (es el nombre que aparece cuando desde un ordenador se realiza la función de buscar redes inalámbricas). También se lo conoce como nombre de la red. El punto de acceso, para identificarse, emitirá señales con este parámetro. También con el entorno gráfico se puede modificar el canal en el que emitimos la señal de onda portadora de radio. Habitualmente no cambiaremos este parámetro, pero si decidimos hacerlo, seguiremos las recomendaciones del ETSI.


47

© FUOC • PID_00147722


Una de las cosas más importantes que se tiene que configurar es la seguridad de la comunicación para poder dar acceso a nuestra red sin hilos a los equipos o personas que queramos. El�cifrado�WEP (Wireless Encryption Protocol) codifica la información que viaja por el aire de cada trama de datos enviados por el adaptador mediante unas claves (64, 128 y 256 bits). Existe otro tipo de cifrado, el WPA (WiFi Protected Access), que proporciona más seguridad que el WEP; además, facilita la autoidentificación del usuario (exige una clave y una contraseña para entrar dentro de la Red, y codifica la información transmitida por el aire). Para la mayoría de redes pequeñas, la encriptación WAP es la manera más sencilla de tener una seguridad efectiva. De las tres opciones, la PSK String es la mejor para implantar. Estándar

Ancho de banda

Consumo de potencia

Ventajas

Aplicaciones

Wi-Fi

Hasta 54 Mbps

400 mA transmitiendo

Gran ancho de banda

Navegar por Internet, red de ordenadores, transferencia de ficheros

Bluetooth

1 Mbps

40 mA transmitiendo

Interoperatividad, sustituto del USB sin hilos, móviles, informática casera cable

ZigBee

250 kbps

30 mA transmitiendo, 3 mA en reposo

Batería de larga duración, bajo coste

Control remoto, productos dependientes de la batería, sensores, juegos

-3

1mA = 10 amperios

2.5. WiMax Actualmente hay una gran demanda de servicios de acceso de banda ancha (altas velocidades de transmisión) en Internet y otras aplicaciones de voz y datos. De manera cableada actualmente se ofrecen servicio con las líneas ADSL, y de manera inalámbrica WiMax es la solución que sirve tanto a los operadores de telecomunicaciones como a los usuarios. Con WiMax se está creando un mercado masivo de soluciones inalámbricas. Un nuevo estándar WMAN de banda ancha apareció promovido y desarrollado por el grupo WiMax (wireless interoperability for microwave access) –acceso inalámbrico de banda ancha–, que tiene dos miembros muy representativos, como Intel y Nokia. La etiqueta WiMax está asociada globalmente al propio nombre del estándar IEEE 802.16. La tecnología WiMax supone una evolución con respecto al WiFi. Permite la conectividad entre puntos fijos, nómadas y móviles, y eventualmente la conectividad móvil sin necesidad de tener una línea punto a punto con una estación base.

© FUOC • PID_00147722

48

Haciendo una analogía, WiMax es al estándar IEEE 802.16 lo que Wifi al estándar IEEE 802.11.

Wimax Forum El Wimax Forum es una agrupación de más de 350 compañías que se encarga de promover la interoperabilidad de dispositivos 802.16 y la unificación de los estándares a nivel mundial. Incluye fabricantes de chips y de equipos y empresas que ofrecen servicios. Wimax Forum promueve la utilización del estándar IEEE 802.16, la certificación de equipos, la interoperabilidad de Wimax entre diferentes marcas y la conformidad verificada en laboratorios autorizados.


49

© FUOC • PID_00147722


WiMax utiliza bandas de frecuencia con y sin licencia gubernamental. La banda que no necesita ninguna autorización administrativa está entre 2,4 y 5 GHz. Estas bandas se tienen que utilizar con mucha cautela, ya que existe la posibilidad de una gran interferencia. En algunos países todavía no se han asignado las bandas WiMax. La norma inicial IEEE 802.16, publicada en diciembre del 2001, sirvió para fomentar la operatividad entre los sistemas local multipoint distribution system (LMDS). Inicialmente, el rango de frecuencias era entre 10 y 66 GHz con necesidad de visión directa (entre emisor y receptor). A principios del 2003, con la aparición del 802.16a para ratificar el estándar inicial 802.16, se amplió el rango de frecuencias hacia las bandas de 2 a 11 GHz. En el año 2004 aparece el estándar 802.16-2004 o IEEE 802.16d, también conocido como WiMAX, para cubrir las carencias del IEEE 802.16a.

En resumidas cuentas, existen dos estándares, IEEE 802.16d para WiMax fija, y IEEE 802.16e para WiMax móvil.

802.16

802.16a

802.16e

Espectro

10-66 GHz

< 11 GHz

< 6 GHz

Funcionamiento

Sólo con visión directa

Sin visión directa (NLOS)

Sin visión directa (NLOS)

Ancho de�banda

32-134 Mbps

Hasta 75 Mbps con canales de 20 MHz

Hasta 15 Mbps con canales de 5 MHz

Modulación

QPSK, 16QAM y 64 QAM

OFDM con 256 subportadoras

Mismo que 802.16a

Movilidad

Sistema fijo

Sistema fijo

Movilidad pedestre

Ancho�del espectro

20, 25 y 28 MHz

Selección entre 1,25 y 20 MHz

El mismo que 802.16a con los canales de subida para ahorrar potencia

Distancia

2-5 km aprox.

5-50 km aprox.

2-5 km aprox.

Hay que mencionar la aparición del equipamiento denominado pre-WiMAX. Muchos fabricantes no esperaron a la aprobación definitiva del estándar 802.16, y decidieron sacar al mercado (y todavía lo siguen haciendo actualmente) equipos que implementan un protocolo propietario basado en los desarrollos realizados para la tecnología WiMAX. Estos dispositivos, a pesar de proporcionar altas prestaciones, no permiten interoperabilidad con los otros fabricantes. Pero, en cambio, trabajan en bandas de frecuencia libre (sin licencia), de manera que han acabado siendo una buena opción (y muy utilizada) para despliegues en este tipo de entornos.

50

© FUOC • PID_00147722

Con respecto a velocidades, hay que diferenciar entre la velocidad de transmisión en el aire y la velocidad real (conocida como throughput). En el caso concreto de WiMAX y pre-WiMAX, la velocidad de los equipos es ligeramente diferente: Velocidades pre-WiMAX / WiMAX Tecnología

Velocidad máxima aire

Velocidad máxima real

pre-WiMAX

54 Mbps

~30 Mbps

WiMAX

70 Mbps

~40 Mbps

Sus principales características se resumen a continuación: •

Modulación� adaptativa: se escogen dinámicamente en función de las condiciones del enlace, si éste tiene un buen comportamiento (pocas pérdidas), se utiliza una modulación que más bits y, por lo tanto, la velocidad aumenta. En función de la distancia de la estación a la estación base se utiliza un tipo de modulación u otra: 64QAM, 16QAM, QPSK...

•

Banda�frecuencial: se puede trabajar en banda libre de 5,4 GHz, pero con poca potencia y con visión directa. También hay banda licenciada (hace falta un permiso de la administración para utilizar una determinada frecuencia) en 3,5 GHz, donde no es imprescindible la visión directa.

•

Elementos: hay dos tipos de componentes, la estación base (unidades de acceso, AU) y las unidades de abonado (SU).

•

Perfiles: permiten enlaces punto a punto (con visión directa) y punto multipunto (sin necesidad de visión directa).

•

Permite�calidad�de�servicio�(QoS): gracias al hecho de que WiMAX está orientado a la conexión. También ofrece la especificación antes de la transmisión de la calidad de servicio demandada (QoS): por ejemplo, la voz y el vídeo requieren una baja latencia (retraso), pero soportan bien la pérdida de un poco de información, mientras que las aplicaciones de datos tienen que estar libres de errores pero toleran bien el retraso.

•

Usuarios: soporta varios centenares de usuarios por canal.

WiMax ofrece varios cualidades de servicio: •

Unsolicited�grant�service�(UGS): tráfico de velocidad constante (constant bit rate), datos en tiempo real con paquetes de tamaño fijo: VoIP sin supresión del silencio.


© FUOC • PID_00147722

•

51

Real-time�polling�service�(rtPS): datos en tiempo real con paquetes de tamaño variable generados en intervalos periódicos, como los paquetes de vídeo Moving Picture Expert Group (MPEG).

•

Extended�real-time�polling�service�(ertPS): es una optimización de UGS y rtPS: datos en tiempo real con paquetes de tamaño variable generados en intervalos periódicos, tal como los VoIP con supresión de silencio.

•

Non-real-time�polling�service�(nrtPS): soporta datos que toleran retardos como la transferencia de archivos (FTP: file transfer protocol).

•

Best�effort�(BE): diseñado para soportar tráfico para el que no se ha definido ningún tipo de nivel de QoS, tal como la navegación a través de Internet.

Ofrece la posibilidad de formar redes en malla (mesh networks) para que los distintos usuarios se puedan comunicar entre sí, sin necesidad de tener una visión directa entre ellos. Las primeras versiones de WiMax fueron pensadas para comunicaciones punto a punto, o punto a multipunto típicas de radioenlaces por microondas. Las futuras redes ofrecerán total movilidad y podrán competir con las redes celulares. WiMax es adecuado para unir puntos con mucho tráfico de información WiFi a las redes de los operadores de telecomunicaciones sin necesidad de establecer un enlace fijo. WiMax amplía la cobertura de una red WiFi y puede proveer una alternativa seria o complemento a las redes 3G. Topología red WiMAX


© FUOC • PID_00147722

52


WiMax soporta las llamadas antenas inteligentes (smart antennas) propias de las redes celulares en 3G. Estas antenas inteligentes emiten un haz de radiación muy estrecho que se puede ir moviendo electrónicamente para enfocar siempre al receptor, con lo que evitan las interferencias entre canales adyacentes y se consume menos potencia para tener el haz más concentrado. Otra aplicación es la de ofrecer servicios a las zonas rurales de difícil acceso, a las que no llegan las redes cableadas. Es una tecnología muy adecuada para establecer radioenlaces, debido a su gran cobertura y capacidad, y a un coste muy competitivo frente otras alternativas. La instalación de estaciones base WiMax es sencilla y económica, utilizando un hardware que llegará a ser estándar. Diferentes fases de WiMax

A la izquierda, estación de usuario acceso fijo. A la derecha, estación base acceso fijo.

WiMax móvil y IEEE 802.16e, soportan varias tecnologías de antenas inteligentes: •

Beamforming.

•

Space-time code (STC).

•

Multiplexación espacial.

En definitiva, WiMax nos ofrece un ancho de banda para equipos fijos y móviles, puede coexistir junto con WiFi y 3G, soporta aplicaciones basadas en IP (datos, Internet, VoIP, etc.), garantiza la seguridad y la calidad del servicio, y tiene diferentes sectores en el mercado.

Más de 250 operadores han realizado pruebas en más de 65 países, tal como se ve en la figura siguiente.

53

© FUOC • PID_00147722


Comparativa de WiMAX con otras tecnologías

WiMAX 802.16

WiFi 802.11

MBWA 802.20

UMTS y CDMA2000

Velocidad

124 Mbit/s

11-54 Mbit/s

16 Mbit/s

2 Mbit/s

Cobertura

40-70 km

300 m

20 km

10 km

Licencia

Sí/No

No

Sí

Sí

Ventajas

Velocidad y extensión geográfica

Velocidad y precio

Velocidad y movilidad

Rango y movilidad

Inconvenientes

Interferencias

Baja cobertura

Precio alto

Lento y caro

© FUOC • PID_00147722

54

Resumen

En este módulo hemos visto la evolución histórica de la telefonía móvil, su crecimiento exponencial en número de usuarios a escala mundial, y cómo esta tecnología y sus aplicaciones han evolucionado en muy pocos años. Se ha pasado básicamente de sólo poder transmitir mensajes de texto con la tecnología móvil GSM, a mejorar las conexiones a Internet con la tecnología GPRS, para acabar en las últimas aplicaciones totalmente multimedia sobre tecnologías EDGE y UMTS por el considerable aumento de las velocidades de transmisión y de sus coberturas. En el ámbito de las redes inalámbricas se han visto las de uso más cotidiano, las redes WiFi para aplicaciones de alcance local (vivienda, oficina), con distancias entre los equipos pequeñas (varios centenares de metros). Para incrementar la distancia entre los equipos (varios kilómetros) se ha desarrollado la tecnología inalámbrica WiMax. Además, para interconectar dispositivos en muy poca distancia se utiliza la tecnología infrarroja y la bluetooth. Finalmente, para instalar redes de sensores donde el consumo es el factor principal a tener en cuenta, existe la tecnología ZigBee para que las baterías de estos sensores tengan una larga duración.


© FUOC • PID_00147722

55

Bibliografía Abad, F. J.; Canudas, J. M.; Martínez, R.; Nogueira, E. (2008). Informàtica 4t. ESO. Barcelona: Teide. ISBN: 978-84-307-8685-5. Direcciones web Bluetooth. Disponible en web: . [Fecha de consulta: 13 de abril del 2010.] International Engineering Consortium. Disponible en web: . [Fecha de consulta: 13 de abril del 2010.] Olzac, T. (1 de diciembre del 2006). "Secure your Bluetooth wireless networks and protect your data". Tech Republic. Disponible en web: [Fecha de consulta: 13 de abril del 2010.] Umtsforum.net. Disponible en web: . [Fecha de consulta: 13 de abril del 2010.] Universidad Politécnica de Madrid. "Comunicaciones móviles con WAP, GPRS y UMTS" [plan docente del curso 2009-2010]. Disponible en web: . [Fecha de consulta: 13 de abril del 2010.] Zigbee Alliance. Disponible en web: . [Fecha de consulta: 13 de abril del 2010.] Zigbee España. Disponible en web: . [Fecha de consulta: 13 de abril del 2010.]


Redes Multimedia

Recommend Documents