Red

Redes multimedia
Xavier Vilajosana Guilln (coordinador) Miquel Font Rossell Silvia Llorente Viejo Joan Manuel Marqus Puig
PID_00147720
FUOC PID_00147720
Redes multimedia
Xavier Vilajosana Guilln Ingeniero en Informtica por la Universidad Politcnica de Catalua (UPC) y doctor en Sociedad de la Informacin por la Universitat Oberta de Catalunya (UOC). Actualmente, es profesor de los Estudios de Informtica, Multimedia y Telecomunicacin de la UOC.
Miquel Font Rossell Ingeniero y doctorando en Informtica, y consultor de los Estudios de Informtica, Multimedia y Telecomunicacin de la UOC.
Silvia Llorente Viejo Ingeniera en Informtica, diploma de estudios avanzados por la UPC y doctora por la Universidad Pompeu Fabra (UPF). Actualmente, es consultora de los Estudios de Informtica, Multimedia y Telecomunicacin en la UOC.
Joan Manuel Marqus Puig Doctor en Informtica, especializado en sistemas distribuidos descentralizados. Profesor de los Estudios de Informtica, Multimedia y Telecomunicacin de la UOC.
Primera edicin: septiembre 2010 Miquel Font Rossell, Silvia Llorente Viejo, Joan Manuel Marqus Puig, Xavier Vilajosana Guilln. Todos los derechos reservados de esta edicin, FUOC, 2010 Avda. Tibidabo, 39-43, 08035 Barcelona Diseo: Manel Andreu Realizacin editorial: Eureca Media, S. L. ISBN: 978-84-693-4288-6 Depsito legal: B-20.539-2010
Ninguna parte de esta publicacin, incluido el diseo general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningn medio, sea ste elctrico, qumico, mecnico, ptico, grabacin, fotocopia, o cualquier otro, sin la previa autorizacin escrita de los titulares del copyright.
FUOC PID_00147720
Redes multimedia
Introduccin
La asignatura Redes multimedia pretende dar una visin global e introductoria de las redes de computadores. Se toma una aproximacin de arriba abajo enfatizando los aspectos ms relacionados con la titulacin y dejando de lado aquellos relacionados con la comunicacin en el mbito fsico en la teora de la seal. Esta asignatura presenta las bases de las redes de comunicaciones, cmo se estructuran, qu dispositivos las integran, cules son las normas y protocolos que rigen la comunicacin, cules sus aplicaciones y servicios, y todo tomando como ejemplo la red de Internet. El mdulo "Conceptos de redes de computadores" introduce los principales conceptos que nos permiten entender qu es una red de computadores y cmo se estructura. Tambin sirve de breve revisin de la historia de las redes, lo cual nos permite contextualizar y entender Internet en la actualidad. El mdulo "Las capas de la red de computadores" describe los protocolos y servicios bsicos que ofrece cada una de las capas de una red de computadores. El mdulo empieza por los niveles ms altos y deja de lado el nivel de aplicacin que se ve en el mdulo "El nivel de aplicacin". El enfoque es, pues, de arriba abajo; se crea as un esbozo de los conceptos ms prximos al hardware y se pone el nfasis en los niveles de transporte y de red primordiales para el funcionamiento de Internet. El mdulo "Seguridad en la Red" complementa al resto y presenta los conceptos principales de la seguridad de las redes de computadores. El mdulo "El nivel de aplicacin" profundiza en el nivel de aplicacin; muestra protocolos tan importantes como HTTP o SMTP que rigen el funcionamiento del mundo hoy en da. Se destacan los protocolos orientados a la transmisin del contenido multimedia, y se presentan las arquitecturas ms comunes hoy en da en la Red. Por ltimo, el mdulo "Comunicaciones sin hilos" concluye el curso explicando los conceptos capitales de una tecnologa que permite superar las barreras impuestas por la necesidad de conectar fsicamente las redes. Cabe sealar que este curso pretende introducir el concepto de red y dar una visin general del funcionamiento de sta. Por lo tanto, quedan fuera muchos conceptos que son primordiales tambin 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 ms interesados en ampliar su conocimiento de las redes que consulten la bibliografa recomendada.
FUOC PID_00147720
Redes multimedia
Objetivos
El estudio de los materiales didcticos 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 aplicacin, entender su funcionamiento y saber relacionarlo con el funcionamiento actual de Internet. 3. Tener una visin general de los conceptos de seguridad en la Red que permiten asegurar las comunicaciones, as como evitar un uso indebido de la informacin. 4. Tener conocimiento de los conceptos principales que rigen la comunicacin sin hilos. Conocer las tecnologas de comunicacin sin hilos que existen hoy en da y rigen la mayora de las comunicaciones actuales.
FUOC PID_00147720
Redes multimedia
Contenidos
Mdulo didctico1 Conceptos de redes de computadores Xavier Vilajosana Guilln 1. 2. 3. 4. 5. 6. 7. 8. 9. Conceptos de redes y comunicaciones en Internet Qu es Internet y qu es un protocolo Hardware de red Dispositivos de red Software de red Jerarqua de protocolos y cabecera Interfaces y servicios Modelos de referencia Breve historia de las comunicaciones
Mdulo didctico2 Las capas de la red de computadores Xavier Vilajosana Guilln 1. 2. 3. 4. El nivel de transporte El nivel de red El enlace de datos y el control de acceso al medio El nivel fsico
Mdulo didctico3 Seguridad en la red Xavier Vilajosana Guilln 1. 2. 3. 4. 5. Cortafuegos Redes privadas virtuales Introduccin a la criptografa Certificados digitales Seguridad en la red
Mdulo didctico4 El nivel de aplicacin Joan Manuel Marqus Puig y Silvia Llorente Viejo 1. 2. 3. 4. 5. 6. 7. 8. 9. Arquitecturas de aplicaciones distribuidas DNS: Servicio de nombres en Internet La web y el HTTP Transferencia de ficheros Correo electrnico en Internet Aplicaciones de igual a igual para la comparticin de ficheros Mensajera instantnea Telnet y Secure Shell: acceso a ordenadores remotos Aplicaciones multimedia en red
10. Streaming de audio y vdeo almacenados
FUOC PID_00147720
Redes multimedia
11. Protocolos para aplicaciones interactivas en tiempo real 12. Anexos Mdulo didctico5 Comunicaciones inalmbricas Miquel Font Rossell 1. 2. Sistemas de comunicacin de la telefona mvil Redes inalmbricas
Conceptos de redes de computadores

Xavier Vilajosana Guilln
PID_00147725
FUOC PID_00147725
FUOC PID_00147725
ndice
Introduccin............................................................................................... Objetivos....................................................................................................... 1. 2. 3. Conceptos de redes y comunicaciones en Internet.................... Qu es Internet y qu es un protocolo......................................... Hardware de red................................................................................ 3.1. 3.2. Topologas de red ........................................................................ Tipo de conmutacin .................................................................. 3.2.1. 3.2.2. 3.2.3. 3.3. 3.3.1. 3.3.2. 3.4. 3.4.1. 3.4.2. 4. 5. Conmutacin de circuitos ............................................. Conmutacin de paquetes ............................................. Conmutacin de paquetes con circuito virtual ............. Redes de gran alcance ................................................... Redes de rea local ........................................................ Tecnologas de red cableada .......................................... Tecnologas de red sin hilos ..........................................
5 6 7 8 9 9 10 10 11 14 15 16 16 16 17 17 19 21 22 25 27 29 33 35 35 36 38 39 41 42
Alcance de las redes ....................................................................
Tecnologas de red ......................................................................
Dispositivos de red............................................................................ Software de red.................................................................................. 5.1. 5.2. Arquitectura de la red: diseo por capas .................................... Consideraciones de diseo .........................................................
6. 7.
Jerarqua de protocolos y cabecera............................................... Interfaces y servicios......................................................................... 7.1. Tipo de conexin de servicios ....................................................
8.
Modelos de referencia....................................................................... 8.1. 8.2. 8.3. Necesidad de estandarizacin ..................................................... El modelo de referencia OSI ....................................................... 8.2.1. 8.3.1. 8.4. Proceso de encapsulacin y desencapsulacin .............. Encapsulacin de la informacin en el modelo TCP/IP ............................................................................ Modelo OSI comparado con modelo TCP/IP .............................. Modelo TCP/IP ............................................................................
FUOC PID_00147725
9.
Breve historia de las comunicaciones..........................................
44 56 59
Resumen....................................................................................................... Bibliografa.................................................................................................
FUOC PID_00147725
Introduccin
Las redes de ordenadores actuales son una composicin de dispositivos, tcnicas y sistemas de comunicacin que han ido apareciendo desde el final del siglo XIX con la invencin del telfono. ste se desarroll exclusivamente para transmitir voz, aunque todava 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 transocenicos o por satlite, Internet, la telefona mvil, etc. Dedicaremos este mdulo a introducir las ideas y los conceptos bsicos de las redes de ordenadores que trataremos en profundidad a partir de ahora. En primer lugar, abordaremos los conceptos fundamentales de una red. Las topologas de red y los conceptos de conmutacin, el hardware y el software. Es importante tener una visin general de la tipologa de red, normalmente clasificada por su alcance. Seguidamente, el mdulo introduce las diferentes tecnologas de red ms relevantes en la actualidad, Ethernet u 802.3 es la ms usada en redes de rea local cableadas. Las tecnologas de redes sin hilos se han estandarizado en la ltima dcada y tienen su mayor exponente en el 802.11 o WiFi, que tambin es usado por la mayora de dispositivos de usuario en red. El mdulo profundiza en la definicin 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 transmisin de la informacin. 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 informacin, sta se transmite entre los diferentes niveles de la red a la vez que se encapsula la informacin de los niveles precedentes y se aade nueva informacin que le permite al receptor recuperar la informacin original. Veremos que en un principio se defini una jerarqua 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 da el funcionamiento de Internet. Finalmente, el mdulo hace un breve repaso de la historia de las comunicaciones. Conocer la historia nos permite tener una buena perspectiva de estas tecnologas y entender por qu se han creado, cmo han evolucionado y por qu tenemos el modelo de comunicacin actual.
FUOC PID_00147725
Objetivos
Al finalizar el estudio de este mdulo, tendris 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 separacin por capas o niveles y los modelos de referencia fundamentales. 4. Saber diferenciar las redes por su alcance. 5. Tener una visin general de la evolucin de las redes de computadores desde sus inicios.
FUOC PID_00147725
1. Conceptos de redes y comunicaciones en Internet
Durante las dos primeras dcadas de existencia de los computadores, stos eran sistemas hardware fuertemente centralizados, normalmente ubicados en un nico espacio fsico. Las empresas y centros que posean un computador hacan que ste cubriera todas las necesidades computacionales de la institucin. A medida que las capacidades de los computadores crecieron, la centralizacin se convirti en un problema tanto de gestin como de recursos. De esta manera, se fue sustituyendo el modelo centralizado por un modelo en el que mltiples computadores con menos capacidad pero interconectados entre s eran capaces de realizar las tareas de un computador centralizado. A esta nueva organizacin se la denomin reddecomputadores. El diseo y arquitectura de la red son los aspectos que trataremos durante este curso. La evolucin de las tecnologas ha llevado a un crecimiento progresivo del uso de los sistemas en red hasta llegar al modelo de hoy en da, en el que no se puede concebir un sistema informtico sin la presencia de los elementos de comunicacin. Internet ha sido la materializacin de la red de computadores y se ha convertido en el eje principal de las tecnologas de la informacin. Las comunicacin en Internet no deja de ser una jerarquizacin de la comunicacin en red. Internet es una gran red constituida por una infinidad de pequeas redes interconectadas entre s.
FUOC PID_00147725
2. Qu es Internet y qu es un protocolo
La idea de Internet apareci a mediados de los aos sesenta cuando la Agencia de Proyectos de Investigacin Avanzada (ARPA, por sus siglas en ingls), en el seno del Departamento de Defensa de Estados Unidos financi un proyecto denominado ARPANET que pretenda interconectar diferentes ordenadores distribuidos en sus sedes. Desde entonces, Internet ha evolucionado hasta el sistema de hoy en da, en el que millones de mquinas estn interconectadas y acceden a contenidos distribuidos por todas partes. La estructura de la red es compleja y no podemos pensar en una conexin de todos con todos, pues ello hara que el sistema fuera completamente inoperante e inviable tecnolgicamente. Internet sigue una estructura jerrquica en la que unos pocos nodos estn conectados con muchos otros, mientras que la mayora mantiene una conexin con su proveedor de servicio.
Para hacer posible toda la complejidad de Internet y permitir que la infinidad de aplicaciones de hoy en da se puedan comunicar mediante la red hace falta un conjunto de reglas que rijan las comunicaciones y regulen cmo y cundo 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
3. Hardware de red
Las redes de computadores se pueden clasificar de diferentes formas. Generalmente, estas clasificaciones se hacen basndose en la topologa, el tipo de conmutacin, el alcance y la tecnologa de la red, entre otros. Este apartado detalla estas diferentes clasificaciones que proporcionan la base necesaria para poder entender posteriormente el diseo de los protocolos existentes en la actualidad. 3.1. Topologas de red
Una topologa de red es la manera como estn distribuidos los nodos que la forman.
Las redes actuales estn 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 topologas ms conocidas son las de: Bus. Todos los equipos estn conectados a un nico medio de transmisin 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 ms de una estacin transmitiendo en el mismo instante de tiempo y se produzcan colisiones. Un ejemplo de una topologa en bus se puede ver en la figura siguiente. Anillo. Como muestra la figura, una topologa en anillo est formada por un enlace que forma un bucle, de manera que cada estacin est conectada al anillo a travs de dos enlaces, el de entrada y el de salida. Generalmente, cuando la estacin emisora recibe su propio paquete lo elimina de la red. Estrella. Esta topologa est formada por un nodo central, que acta como nodo intermedio de la red (conmutador o router) y es el que gestiona el envo y la recepcin de los datos; el resto de las estaciones se conectan a este nodo principal. rbol. La topologa en rbol se considera una topologa mixta de las topologas en bus y en estrella, y a veces tambin se la conoce como topologa jerrquica. 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 topologa es la ms utilizada actualmente. Enmalla. La topologa en malla es aquella en la que todos los equipos estn 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 topologa es la utilizada en el ncleo de las grandes redes como Internet, donde slo se conectan equipos intermedios, y no equipos finales.
Ejemplos tpicos de topologas de red
3.2. Tipo de conmutacin En el entorno de las redes, la conmutacin hace referencia al establecimiento de un circuito (real o lgico) entre dos puntos de la red que permite la interconexin y, por lo tanto, el traspaso de informacin entre los puntos. Esencialmente, esta conmutacin se puede dividir en dos clases diferentes: la conmutacin de circuitos y la conmutacin de paquetes. 3.2.1. Conmutacin de circuitos La conmutacin de circuitos se basa en establecer un circuito fsico entre los dos interlocutores de la red. Dicho circuito fsico se establece antes de que se pueda transmitir ningn tipo de informacin y est conformado por diferentes enlaces entre los nodos. En conmutacin de circuitos se distinguen tres fases para el envo de informacin: 1) Establecimiento del circuito. Esta fase se encarga de buscar un camino entre los nodos intermedios que lleven hacia el destino; as la estacin origen solicita la creacin del circuito al nodo al que est conectada, el cual enva la
FUOC PID_00147725
11
peticin 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 peticin de circuito. Por el contrario, en el caso de que el establecimiento sea viable, una vez llegado al destino, ste enviar una seal al origen para hacerle saber que ya puede enviar informacin. 2)Transferenciadedatos. Ahora, las estaciones ya pueden intercambiar la informacin deseada. 3)Desconexin. Una vez se ha acabado la comunicacin es obligatorio liberar recursos, a fin de que estn disponibles ms adelante para otras conexiones.
Ejemplo de creacin de circuitos Un ejemplo de creacin 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 evolucin temporal, donde cada bloque representa el envo de informacin hacia el siguiente nodo. Diagrama de tiempo del establecimiento de un circuito
Como se puede ver en la figura, las lneas tienen una cierta inclinacin, lo que indica el tiempo de propagacin de la seal, mientras que el grueso de cada bloque indica el tiempo de transmisin necesario para enviarla. Inicialmente, en el establecimiento del circuito cada equipo intermedio tiene que procesar la seal y enviarla al siguiente nodo; por eso, antes de enviarla se tiene que esperar a tener toda la informacin del circuito. Que una vez establecida, ya puede funcionar de extremo a extremo de forma transparente y sin ms retardos adicionales de los nodos intermedios. Red telefnica bsica El ejemplo ms clsico de la conmutacin de circuitos es la antigua red telefnica bsica (XTB), en la que, por medio de las centralitas situadas de forma jerrquica por medio de toda la red, se iban multiplexando los circuitos de voz y dirigindolos hacia su destinatario. Hoy da, con la era digital, este establecimiento del circuito se produce slo desde el telfono del usuario hacia la centralita ms prxima, donde se digitaliza la voz y se utilizan otras tcnicas como, por ejemplo, la conmutacin de paquetes, para enviar la informacin.
3.2.2. Conmutacin de paquetes Uno de los principales problemas que encontramos con la conmutacin 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 estn reserva-
FUOC PID_00147725
12
dos y no pueden ser utilizados por ninguna otra estacin. El problema se ve agravado ya que, para conexiones de datos como las que hay hoy da, el trfico, en vez de ser constante, llega en rfagas; por ejemplo, cuando el usuario carga una pgina web, la carga slo supone unos pocos centenares de milisegundos, mientras que su lectura puede comportar unos cuantos minutos. Otro problema impuesto por la conmutacin de circuitos es la necesidad de que todos los nodos de la comunicacin trabajen a la misma velocidad, ya que los nodos intermedios no realizan ningn procesado de la informacin, 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 conmutacin de circuitos de cara a estas nuevas necesidades se dise la conmutacin de paquetes con los siguientes objetivos: Optimizacin de la utilizacin de los canales de comunicacin. Interconexin de terminales con diferentes velocidades. Creacin de conexiones de forma simultnea sin reserva de recursos.
As, la conmutacin 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 cul es su destinatario y enviarlo hacia el nodo que corresponda. Como se ha dicho, la conmutacin de paquetes tiene que permitir diferentes velocidades de transmisin; por eso se utilizan las colas de recepcin y las colas de transmisin, tal como muestra la siguiente figura. Segn se puede comprobar, un nodo de conmutacin est compuesto por interfaces; estas interfaces estn 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 conmutacin, 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 conmutacin de paquetes
Las colas del nodo de conmutacin tendrn un tamao determinado, lo que implica que si una cola se llena antes de ser procesada, hay paquetes que tendrn que ser descartados. En mdulos posteriores veremos cmo la red gestiona y evita estas prdidas. Otro importante factor a considerar en este entorno es el tamao del paquete a transmitir; inicialmente se pens en hacer los paquetes tan grandes como el mensaje a enviar (conmutacin 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 tamao mximo fijado (generalmente 1.500 octetos). Un ejemplo de eso se puede encontrar en la figura siguiente; las dos subfiguras muestran el envo del mismo mensaje, primero con conmutacin de mensajes, y despus con conmutacin de paquetes. Como se puede ver en este ejemplo, el mensaje ha sido enviado con tres paquetes diferentes de un tamao inferior. A causa del almacenamiento en los nodos intermedios (denominado store and forward) la conmutacin de paquetes es generalmente ms rpida.
FUOC PID_00147725
14
Funcionamiento de la conmutacin de paquetes y de mensajes
3.2.3. Conmutacin de paquetes con circuito virtual Aunque la conmutacin de paquetes es mejor que la conmutacin de mensajes, ambas soluciones tienen el problema de que, dependiendo del tamao y el estado de las colas de los nodos intermedios, el retardo en la llegada de la informacin es variable. Ello implica que en comunicaciones crticas en tiempo (como una conversacin 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 pequeo corte en la conversacin. Para minimizar este problema aparecieron lo que se conoce como conmutacin 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 conexin, lo que hacen los circuitos virtuales es decidir el camino previamente (como con conmutacin de circuitos), pero manteniendo el envo de paquetes individuales, de manera que ahora todos los paquetes seguirn el mismo camino, por lo que podemos tener una reserva de recursos.
FUOC PID_00147725
15
3.3. Alcance de las redes Una clasificacin bastante clsica de las redes es la que se hace en funcin de su alcance, aunque, dependiendo del entorno, esta clasificacin puede cambiar. Generalmente se consideran dos categoras: las redes de gran alcance1 y las 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 difusin y redes punto-a-punto.
2 (1)
En ingls, Wide Area Networks (WAN).

(2)
En ingls, Local Area Networks (LAN).
Otras categoras de redes Hay otras categoras 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.
Una red de difusin (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 slo procesan los dirigidos hacia ellos.
Entre otras cosas, una red de difusin 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 contraposicin a las redes de difusin, 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 conexin ms utilizado actualmente, ya que se puede desplegar para formar topologas en estrella, en rbol o en malla de forma muy sencilla. Dependiendo del sentido de la comunicacin que permiten, los enlaces punto-a-punto pueden ser: Simplex. La comunicacin es unidireccional, uno de los dos puntos es siempre el origen, y el otro, el destino. Semidplex(Half-duplex). La comunicacin puede ser bidireccional, pero siempre y cuando los dos puntos de la comunicacin alternen la generacin de trfico, ya que si enviaran al mismo tiempo se provocara una colisin que invalidara ambas transmisiones. Dplex(Full-duplex). El caso ms comn actualmente es cuando el medio est preparado para poder enviar y recibir informacin de forma simultnea sin ningn problema. Hay que sealar que con las comunicaciones bidireccionales la velocidad puede ser igual (conexin simtrica) o diferente dependiendo del sentido de la comunicacin (conexin asimtrica).
FUOC PID_00147725
16
3.3.1. Redes de gran alcance Redes de gran alcance3 se consideran aquellas que se utilizan en espacios geogrficos extensos. Generalmente, las WAN se encargan de la interconexin de las LAN, facilitando as la conexin de los usuarios de diferentes localizaciones. La transmisin de datos se suele hacer mediante grandes operadoras de comunicaciones con lneas de comunicacin contratadas (leased lines), utilizando infraestructuras que se consideran pblicas (para evitar monopolios). Las conexiones WAN son prcticamente siempre punto-a-punto, exceptuando los enlaces va satlite, que, por el hecho de utilizar el aire como medio de transmisin, son inherentemente medios de difusin. Por su gran extensin, las redes WAN, en general, estn compuestas por topologas en rbol que estn conectadas con topologas 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 estn diseadas para tener un alcance ms reducido, que puede oscilar entre unos pocos kilmetros y algunos metros (incluso centmetros). Las tecnologas LAN estn pensadas para conectar usuarios con pocos equipos, edificios empresariales o incluso campus enteros. Normalmente, estas LAN se acaban conectando en WAN; actualmente, esta interconexin masiva de LAN y WAN a escala global se conoce como Internet. Clsicamente, las LAN han utilizado un medio de difusin para enviar la informacin, pero desde la aparicin de los conmutadores y otros equipamientos ms actuales han pasado, mediante topologas en rbol y en estrella, a ser un conjunto de conexiones punto-a-punto. La excepcin a esta regla vuelven a ser las redes que utilizan el aire como medio de transmisin, las redes sin hilos, que utilizan difusin para enviar la informacin. 3.4. Tecnologas de red La ltima clasificacin del hardware de red hace referencia a las diferentes tecnologas existentes para hacer una red, la lista de tecnologas de red existentes en la actualidad es demasiada extensa para poder listarla; aqu se introducen las tecnologas ms importantes en la actualidad, cuya lista comprende las tecnologas cableadas y las tecnologas 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 telefona mvil.
(4) (3)
En ingls, Wide Area Networks (WAN).
En ingls, Local Area Networks (LAN).
FUOC PID_00147725
17
3.4.1. Tecnologas de red cableada Dentro de las redes cableadas, la familia de tecnologas por excelencia es Ethernet (definido en el estndar IEEE 802.3) , que empez como una tecnologa a 10 Mbps con una topologa en bus y medio compartido, y que ha ido evolucionando a una topologa en estrella a 1 Gbps (Gigabit Ethernet) pasando por Fast Ethernet, todava muy utilizado en la actualidad a 100 Mbps. A pesar de empezar siendo una tecnologa limitada a LAN, Ethernet ha evolucionado tanto, gracias a su bajo coste y a su gran aceptacin, que actualmente hay enlaces WAN construidos con esta tecnologa. Por lo que respecta a las topologas basadas en anillo, como Token Ring (IEEE 802.5) y FDDI (definido en el estndar ANSI X3T12), han ido cayendo en desuso, en relacin con Ethernet, principalmente a causa de su coste ms alto y peor rendimiento. Actualmente, una topologa en anillo muy utilizada es Resilient Packet Ring (IEEE 802.17), una tecnologa para transportar otras tecnologas a travs de anillos de fibra ptica; normalmente se transporta directamente trfico Ethernet y servicios IP. 3.4.2. Tecnologas de red sin hilos Un punto en el que ha habido una gran expansin en los ltimos aos es el relativo a la aparicin de tecnologas de red sin hilos. De este tipo de redes se pueden extraer principalmente dos, las redes de telefona mvil y las redes sin hilos de ms corto alcance. Entre los muchos tipos de redes de telefona mvil que hay se puede mencionar el del Global System for Mobile Communications (GSM), que fue de los primeros sistemas que apareci y permite el envo de datos a 9,6 Kbps, para evolucionar al ms actual General Packet Radio Service (GPRS), con un ancho de banda mximo terico de 171,2 Kbps, pero cuyo canal de bajada es efectivamente de 64 Kbps y el de subida de 14 Kbps. La ltima implementacin en tecnologas de red mviles es la Universal Mobil Telecommunication Services (UMTS), tambin conocida como el sistema de tercera generacin (3 GR), que, con unos sistemas ms avanzados, es capaz de llegar a velocidades tericas 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 ms corto alcance, la tecnologa 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 estndar se ha diseado para soportar velocidades de 54 Mbps, con un alcance aproximado de 100 metros. En los ltimos aos, con el fin de reducir el consumo energtico de las comunicaciones sin hilos con equipos de baja potencia, ha aparecido el estndar de facto para la comunicacin de equipos
10 Gigabit Ethernet Tambin existen modelos de 10 Gigabit Ethernet, pero su implantacin todava est en sus inicios.
5 (5)
IEEE es la abreviatura del Institute of Electronic and Electrical Engineers.
FUOC PID_00147725
18
pequeos (mviles, PDA...), que es Bluetooth, con una velocidad de 1 Mbps y un alcance aproximado de 10 metros, pero con un consumo energtico muy bajo que lo hace muy atractivo para transferencias de datos cortas. Finalmente, una tecnologa que se queda entre el corto y el largo alcance es WiMAX (IEEE 802.16), una tecnologa sin hilos muy utilizada en la actualidad para dar conectividad a zonas aisladas y de difcil acceso, donde la comunicacin cableada es muy cara. WiMAX tiene una velocidad mxima aproximada de 150 Mbps de bajada y 35 Mbps de subida, con un alcance de unos 70 kilmetros.
FUOC PID_00147725
19
4. Dispositivos de red
Las redes de hoy en da funcionan porque hay una serie de dispositivos que son capaces de gestionar tanto la informacin de control y presencia de los nodos de una red como la informacin que dichos nodos se transmiten. Bsicamente, los dispositivos de red son los siguientes: Encaminadoroenrutador6. Es un dispositivo de red de nivel 3 del modelo OSI . Recoge la informacin del nivel de red (direccin IP) para tomar las decisiones de encaminamiento: escoger el camino o ruta ms adecuada por donde reenviar los datos recibidos. La sucesin de decisiones de diferentes routers posibilita la llegada de la informacin desde su origen hasta el sistema informtico de destino. Concentrador8. Es un dispositivo de red que permite agrupar un conjunto de dispositivos Ethernet en un mismo segmento de red. Acta en el primer nivel del modelo OSI o nivel fsico, 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 7 (6)
En ingls, router.
(7)
OSI es la abreviatura de Open Systems Interconnection (interconexin de sistemas abiertos).
Conmutador9. Es un dispositivo digital de lgica de interconexin de redes de computadores que opera en la capa 2 (nivel de enlace de datos) del modelo OSI. Su funcin es interconectar dos o ms segmentos de red, de manera similar a los puentes (bridges), pasando datos de un segmento a otro de acuerdo con la direccin MAC de destino de las tramas en la red. Los conmutadores se utilizan cuando se desea conectar mltiples 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.
(8)
En ingls, hub.
Concentrador (9)
Puentedered . Es un dispositivo de interconexin de redes de ordenadores 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) permitiendo el paso de datos de una red a otra mediante el uso de la direccin fsica de destino de cada paquete. Un bridge conecta dos segmentos de red como una sola red utilizando el mismo protocolo de establecimiento de red.
10
En ingls, switch.
Conmutador (10)
En ingls, bridge.
Tarjetadeinterfazdered. Fsicamente es una tarjeta de expansin insertada dentro del ordenador con una o ms aberturas externas por donde se conecta el cable de red. En el plano conceptual, la tarjeta de red11, tambin llamada adaptador de red, permite la comunicacin entre los diferentes dispositivos conectados entre s y, asimismo, la distribucin de recursos entre dos o ms equipos. Hay diversos tipos de adaptadores en funcin del
Puente de red
FUOC PID_00147725
20
(11)
tipo de cableado o arquitectura que se utilice en la red (coaxial fino, coaxial grueso, Token Ring, etc.), pero el ms comn actualmente es el Ethernet, que utiliza una interfaz o conector RJ-45. Cada tarjeta de red tiene un nmero de identificacin nico de 48 bits en hexadecimal, denominado direccin MAC. Estas direcciones de hardware son nicas y estn administradas por el Institute of Electronic and Electrical Engineers (IEEE).
En ingls, network interface card (NIC).
Tarjeta de red
FUOC PID_00147725
21
5. Software de red
Cuando aparecieron las redes de computadores, los fabricantes hacan el diseo pensando que todo el proceso de red se hara mediante hardware, y, adems, asuman que los protocolos y los mecanismos a utilizar seran propietarios, sin un sistema estndar, 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 algn tipo de estandarizacin, una va comn con el fin de interconectar tecnologas y utilizar mecanismos regulados, los esfuerzos de cada fabricante seran demasiados grandes y la lucha no beneficiara a nadie. Fue entonces cuando algunos fabricantes, como IBM, empezaron a ver que era ms viable pasar una buena parte de la carga de la red al software, mucho ms 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 ms 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: diseo por capas Histricamente, las primeras redes se disearon teniendo slo en cuenta el hardware de las comunicaciones. Esta estrategia no tuvo mucho futuro y las redes evolucionaron hacia una combinacin de software de red muy estructurado y hardware genrico. Para reducir la complejidad del diseo, las redes estn organizadas en una serie de capas, situadas unas encima de otras. El nmero 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, ocultndoles a stas los detalles de cmo estn implementados los servicios que se ofrecen. La capa de nivel N de un ordenador mantiene comunicacin con la capa de nivel N de otro ordenador. Las reglas y convenciones usadas en la capa de nivel N se denominan protocolos. Bsicamente, un protocolo es un acuerdo entre las partes de la comunicacin sobre cmo 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 informacin no se transfiere directamente de una capa N de una mquina a la capa N de otra mquina. Cada capa pasa la informacin 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 fsica, y es en ella
FUOC PID_00147725
23
donde se produce la comunicacin real. En la figura anterior, la comunicacin virtual (capa N con capa N) se muestra en lneas punteadas, y la comunicacin fsica o real en la capa fsica. 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 coleccin de funciones perfectamente definidas. Por ello, es muy sencillo reemplazar la implementacin de una capa por otra capa con diferente implementacin (si queremos cambiar el medio de transmisin de la informacin, slo hay que cambiar la capa de nivel 1, por ejemplo, las lneas telefnicas por canales por satlite, 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 filsofos (procesos pares (peer), capa 3). Un filsofo habla urdu e ingls, y el otro, chino y francs. Como no hablan ninguna lengua en comn necesitan un traductor (capa 2), y cada traductor se pone en contacto con su secretaria (capa 1) para enviar la informacin remotamente al otro filsofo. El filsofo 1 quiere enviar un mensaje al filsofo 2. As pues, pasa el mensaje en ingls a travs de la interfaz 2/3 a su traductor, que traduce el mensaje en una lengua neutral (neerlands). La eleccin de la lengua de la capa 2 es la misma en las dos entidades remotas. Despus, el traductor pasa el mensaje a la secretaria para que sta lo transmita va 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 francs para pasarlo finalmente al filsofo 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 podra optar por transmitir los mensajes por fax o enviarlos por correo postal, telfono o correo electrnico, slo cambiando la capa 1 sin cambiar la interfaz 2/1. Observemos la siguiente figura. Consideremos que se produce la comunicacin 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 enva 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 informacin, como los contadores de control de secuencia, para permitir que la capa 4 de la mquina destino reciba los mensajes en el orden correcto, ya que las capas inferiores no tienen ninguna obligacin de mantener la secuencia. En las otras capas, las cabeceras mantienen tamaos, tiempos y otros campos de control.
En muchas redes no existe lmite en el tamao 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
enva 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 lnea de salida transmitir los paquetes a la capa de nivel 2. La capa de nivel 2 aade una cabecera a cada trozo y ofrece el resultado a la capa de nivel 1 (fsica) para su transmisin. En el ordenador que recibe la informacin se enva 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 diseo El nivel por capas se da una forma estructurada de disear y abstraer las tareas necesarias con el fin de enviar informacin a travs de la red, pero cuando se disea una arquitectura de red hay muchos ms factores, aparte de las capas, que se tienen que considerar. Los siguientes son los ms relevantes: 1)Identificacin: 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 informacin a cualquier interlocutor de la misma red. 3)Controldeerrores: una de las partes ms importantes de cualquier comunicacin es garantizar que, cuando la informacin llegue al otro nodo, lo haga sin errores. Hay que sealar que los medios de transmisin no siempre son fiables, por lo que se tiene que decidir cul o cules capas verificarn errores y cmo lo harn.
FUOC PID_00147725
26
4)Modosdetransferencia: qu soporte tendr el protocolo para el envo de informacin, si se puede enviar informacin en modo full duplex, half duplex o simplex. Y, caso de que sea necesario, si habr algn tipo de priorizacin en el envo. 5)Controldecongestin: dado que las velocidades de transmisin de una red no siempre son homogneas y que a veces habr enlaces con ms carga que otros, cualquier protocolo tiene que considerar la posibilidad de que se tenga que disminuir la velocidad a la que se envan los datos, o bien, en el caso de que algn paquete no llegue al destino, de que se tenga que reenviar de forma transparente al usuario. 6)Tamaodelospaquetes: como ya hemos visto anteriormente, enviar mensajes muy grandes no siempre es posible, por lo que se tiene que decidir qu tamao mximo podrn tener los paquetes que se envan a la red.
FUOC PID_00147725
27
6. Jerarqua 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 mltiples procesos. Cada proceso tiene que saber con quin 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 especfico. Otra caracterstica del diseo de un protocolo es si los datos slo viajan en un solo sentido (comunicacin simplex) o lo hacen en las dos direcciones, pero no simultneamente (comunicacin half duplex), o viajan en las dos direcciones simultneamente (comunicacin full duplex). El protocolo tiene que determinar cuntos canales lgicos tiene que gestionar, y las prioridades de estos canales. Muchas redes permiten como mucho dos canales lgicos, 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 fsicos no son perfectos. Determinados cdigos de deteccin y correccin de errores se utilizan, y los ordenadores que se comunican se tienen que poner de acuerdo en la utilizacin de un cdigo corrector/detector concreto. Adems, el receptor de la informacin tiene que comunicar al emisor de los mensajes que se han recibido o no correctamente. No todos los canales de comunicacin preservan el orden de envo de los mensajes. Para solucionar la posible prdida de la secuencia de los mensajes, el protocolo tiene que gestionar los diferentes trozos de informacin en una memoria (buffer) para finalmente ordenarlos correctamente. Otro aspecto que se tiene en cuenta es el de cuando un emisor transmite informacin muy rpidamente hacia un receptor lento. Muchas soluciones utilizan una tcnica que consiste en que el receptor enve una seal al emisor indicndole su problemtica. 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 lmite. Por eso se utilizan mecanismos para desensamblar, transmitir y reensamblar mensajes. A veces, el canal fsico de transmisin es compartido por muchas conexiones que intentan transmitir a la vez sobre un mismo enlace. En este caso, la multiplexacin y desmultiplexacin de la capa fsica nos permite transmitir mucha informacin sobre pocos circuitos fsicos.
FUOC PID_00147725
28
Cuando existen mltiples caminos entre el origen y el destino se tiene que elegir una ruta. Esta decisin se toma muchas veces entre dos o ms capas.
FUOC PID_00147725
29
7. Interfaces y servicios
La funcin de cada capa es proporcionar servicios a la capa superior. En este apartado estudiaremos con ms 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 mquinas 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 mltiples clases de servicios, por ejemplo, comunicaciones caras y rpidas, o comunicaciones lentas y baratas. Los servicios estn 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 direccin nica que lo identifica. Para hacer este punto ms claro, el SAP en el sistema de telefona son los conectores a los que se conectan los aparatos de telfono, y la direccin SAP es el nmero de telfono de este conector. En el sistema postal, la direccin SAP es el nombre de la calle y el nmero de la vivienda. Para enviar una carta postal, tienes que conocer la direccin SAP. A fin de que dos capas se intercambien informacin, se tienen que definir una serie de normas sobre la interfaz. En una interfaz tpica, la entidad de la capa N + 1 pasa una Interface Data Unit (IDU) hacia la entidad de la capa N a travs del SAP tal como se muestra en la siguiente figura. La IDU consiste en un Service Data Unit (SDU) y determinada informacin de control (Interface Control Information). La SDU es la informacin pasada a travs de la red hacia la peer entity y subida despus hacia la capa remota N + 1. La informacin de control se necesita para ayudar a la capa inferior a realizar su trabajo (por ejemplo, indicar el nmero de bytes del SDU), pero no forma parte de la informacin 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 envan como un Protocol Data Unit (PDU) o paquete. A travs de las cabeceras de la PDU, la peer entity identifica qu PDU contienen datos y cules contienen informacin de control, proporcionando nmeros 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 conexin. Un servicio orientado a conexin se modela como un sistema de telefona: para hablar con alguien, primero tenemos que marcar el nmero de telfono, despus, hablar, y, finalmente, colgar el telfono. As, inicialmente se produce un establecimiento de conexin, despus se utiliza la conexin para hablar y transmitir informacin, y, finalmente, se cierra la conexin. Esta conexin acta como un tubo: el emisor enva 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 conexin se modela como un sistema postal. Cada mensaje o carta postal lleva la direccin completa del destinatario, y cada carta la enva el sistema independientemente de las otras cartas. Normalmente, de dos mensajes que se envan al mismo destino, el primero que se enve ser el primero que se recibir. Tambin es posible que el enviado en primer lugar sufra algn retardo y que el enviado en segundo lugar llegue antes que el que se envi primero. En una conexin orientada a conexin 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 informacin. Normalmente, un servicio fiable se implementa mediante el envo 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 (informacin de control redundante, no informacin til) y un cierto retardo, cosa que normalmente no es deseable en trminos de rendimiento de la red. La tpica situacin en la que se utiliza un servicio fiable orientado a conexin es la transmisin 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 trfico de voz digitalizada. Para los usuarios del telfono es preferible or por el auricular un poco de ruido de la lnea o una palabra mal entendida de vez en cuando, que soportar que se produzca
FUOC PID_00147725
31
un retardo en la espera del reconocimiento. Tambin cuando se transmite una pelcula de vdeo es preferible tener varios puntos (pxeles) incorrectos (que en la prctica casi no son ningn problema) que tener que ver la pelcula con paradas para corregir los errores (es muy irritante). Las conexiones no fiables (con la no utilizacin del mecanismo de reconocimiento) y las no orientadas a conexin se llaman servicio de datagrama (por ejemplo, el envo de e-mails). Tambin en algunas situaciones es conveniente no tener que establecer una conexin para enviar un mensaje corto, pero en el que la fiabilidad tiene que ser esencial. Por eso se utilizan los servicios no orientados a conexin con reconocimiento (ACK). Por ejemplo, cuando se enva un e-mail, el receptor del correo electrnico, 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 peticin. 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 accin o devolver el resultado de una accin de la entidad par (peer entity). La siguiente tabla nos muestra las maneras de clasificar las primitivas del servicio:
Primitiva Request Indication Response Confirm Significado Una entidad quiere que el servicio realice alguna cosa. Una entidad es informada de algn evento. Una entidad quiere responder a algn evento. La respuesta a la ltima peticin se confirma.
FUOC PID_00147725
32
Consideremos cmo se establece y se libera una conexin. La entidad que establece la conexin 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 conexin propuesta. La entidad que realiza la peticin de conectar recibe la aceptacin o el rechazo de su conexin a partir de la primitiva CONNECT.confirm. Cada primitiva puede llevar parmetros o no. Por ejemplo, la primitiva CONNECT.request tiene que especificar la direccin de la mquina a la que se quiere conectar, el tipo de servicio deseado y la longitud mxima del mensaje a utilizar durante la conexin. Los parmetros de la CONNECT.indication tienen que contener la identidad de quien realiza la llamada, el tipo de servicio deseado y la longitud mxima del mensaje propuesta. Si la entidad llamada no acepta la longitud mxima del mensaje propuesta, puede realizar con la primitiva response una nueva propuesta sobre la longitud del mensaje. Los detalles de cada negociacin forman parte de cada protocolo. Los servicios pueden ser confirmados o no ser confirmados. En un servicio confirmado estn las primitivas request, indication, response, confirm. En un servicio no confirmado slo estn las primitivas request e indication. El servicio CONNECT slo se utiliza en los servicios confirmados porque la entidad remota tiene que dar el visto bueno al establecimiento de la conexin. Las ocho primitivas de un servicio orientado a conexin son las siguientes: 1) CONNECT.request: pedir el establecimiento de la conexin. 2) CONNECT.indication: indicar a la parte solicitada un establecimiento de conexin. 3) CONNECT.response: utilizado por la parte solicitada para aceptar/rechazar la conexin o llamada. 4) CONNECT.confirm: indicar al que la ha solicitado si la conexin o la peticin ha sido aceptada. 5) DATA.request: indicar que se enva la informacin. 6) DATA.indication: indicar la llegada de la informacin. 7) DISCONNECT.request: indicar que la conexin se ha cerrado. 8) DISCONNECT.indication: indicar a la otra entidad el cierre de la conexin.
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 interaccin entre dos capas de una de las computadoras. Cada peticin o respuesta provoca una indicacin o confirmacin 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 cmo estn 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 sera como un tipo abstracto de datos o un objeto en los lenguajes de programacin. Define las operaciones que se pueden realizar sobre el objeto pero no especifica cmo se implementan las operaciones. Un protocolo relata cmo se implementa el servicio y, si es posible, cmo hacer que no sea visible para el usuario del servicio.
7.1. Tipo de conexin de servicios Cada servicio establece una conexin con el servicio anlogo del equipo de destino; dependiendo de cmo se gestione esta conexin entre servicios, un servicio puede ser orientado a conexin o no orientado a conexin.
FUOC PID_00147725
34
El servicio orientado a conexin previo al envo de informacin se establece una conexin, que se libera cuando la transferencia acaba. No hay que confundir un servicio orientado a conexin con la conmutacin de circuitos vista anteriormente; en el servicio orientado a conexin no se realiza ninguna reserva de recursos, sino una estructura de datos que mantiene el estado de la conexin. El hecho de que un protocolo sea orientado a conexin implica que la informacin tiene que llegar ordenada y sin errores. El hecho de mantener la conexin implica que ambos extremos son conocidos y, por lo tanto, no es necesario indicar qu destino tiene la comunicacin. Este paso se realiza durante el establecimiento de la conexin. Por su parte, los servicios no orientados a conexin no precisan ni asumen ninguna conexin previa entre los dos interlocutores; de esta manera, la informacin se separa en paquetes (denominados datagramas en este tipo de servicios) y se enva a la red sin conocer el camino que seguirn los paquetes, ni saber si llegarn a su destino, ni siquiera en qu orden lo harn, cada datagrama se enva de forma autnoma e independiente del resto. Por lo tanto, para poder enviar un datagrama con un protocolo no orientado a conexin, el datagrama tiene que tener la direccin destino, y los elementos intermedios de la red tienen que tener informacin de cmo hacer llegar la informacin dependiendo del destino de cada datagrama recibido.
Protocolo orientado a conexin El ejemplo por excelencia de un protocolo orientado a conexin es el TCP.
Servicios no orientados a conexin El ejemplo por excelencia de servicios no orientados a conexin es IP. Curiosamente, HTTP es tambin un protocolo no orientado a conexin.
FUOC PID_00147725
35
8. Modelos de referencia
Las dos arquitecturas de red ms conocidas hoy en da son la Open Systems Interconnection (OSI), utilizada como modelo terico, y la Transmission Control Protocol/Internet Protocol (TCP/IP), cuyo xito en el mundo de las redes ha sido enorme. 8.1. Necesidad de estandarizacin Los primeros ordenadores realizaban trabajos concretos, ubicados en lugares cerrados y aislados. Cada fabricante venda su sistema de comunicaciones integral a las empresas, encargndose de todos los aspectos relacionados con la red (equipos, software, cableado, etc.). Cuando una empresa necesitaba alguna ampliacin y/o modificacin, slo poda 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 elega un suministrador era para siempre. Con estas limitaciones, a partir de los aos ochenta empezaron a aparecer organizaciones que construan 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 estndar para redes de rea local para la red ETHERNET. En 1982, DIX distribuy la versin II de Ethernet, que es la versin estndar para TCP/IP. 2) El comit 802.3 de IEEE recogi la versin de DIX y empez a trabajar en una trama Ethernet mejorada. La red Ethernet tena un coste bajo y altas prestaciones, junto con una sencillez de operacin. 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 extensin de TCP/IP, dado que estaba incluido en su kernel.
FUOC PID_00147725
36
4) Creacin de un modelo de referencia OSI de ISO. Estos hechos provocaron que los sistemas que hasta este momento ofrecan 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 heterogneos. La informacin de los estndares se hace pblica, hecho que no pasaba con los sistemas propietarios. Se crean frums externos a los organismos que pueden llegar a forzar a stos a decidirse por uno u otro estndar (ATM Forum, Forum Gigabit Ethernet, Forum ADSL, etc.). La existencia de estndares 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 ms polticos y comerciales que tcnicos Los fabricantes son los que desarrollan ms I+D, lo cual provoca que los organismos tengan que definirse Muchos organismos pueden afectar a la estandarizacin, ya que se puede llegar a clasificar geogrficamente, por industria, etc. Perjuicios econmicos Hay importantes ganancias econmicas para las empresas que han desarrollado un sistema y ste se convierte en estndar. No obstante, ello puede provocar que otras empresas salgan perjudicadas.
8.2. El modelo de referencia OSI Entre los diferentes modelos propuestos por las diferentes organizaciones internacionales de normalizacin en la dcada de los ochenta, destaca una arquitectura de redes de ordenadores basada en niveles, el modelo OSI, definido por la Organizacin Internacional de Estndares (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 creacin de una serie de estndares que especificaran un conjunto de protocolos independientes de cualquier fabricante. Pretenda establecer las normas y estndares para que el software y los dispositivos de diferentes fabricantes pudieran funcionar juntos.
FUOC PID_00147725
37
(13)
Adems de facilitar las comunicaciones entre sistemas diferentes, la ISO pretenda con OSI impedir que ninguna de las arquitecturas de fabricante existentes adquiriera una posicin hegemnica, especialmente la SNA13 de IBM. Seguramente, la aportacin ms importante de la iniciativa OSI ha sido precisamente la definicin terica de su modelo arquitectnico. 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.
SNA es la abreviatura de System Network Architecture.
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 abstraccin. 2) Cada capa tendr que realizar una funcin 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 cmo se realizan los servicios. 6) La funcin que realizar cada capa se tendr que seleccionar con la intencin de definir protocolos normalizados internacionalmente. 7) Los lmites de las capas se habrn de seleccionar teniendo en cuenta la necesidad de minimizar la cantidad de informacin que se tiene que pasar entre capas. La frontera entre capas tiene que ser la ms sencilla posible. 8) El nmero de capas tiene que ser lo bastante grande para que funciones diferentes no tengan que ponerse juntas en la misma capa. Tambin tendr que ser lo bastante pequeo para que su arquitectura no sea difcil de manejar.
Las capas son las que se muestran en la figura siguiente.
FUOC PID_00147725
38
Las capas se pueden agrupar en dos subconjuntos convenientemente diferenciados: Capasinferiores. Son proveedoras de servicios de transporte de las capas superiores. Tratan problemas tales como errores del sistema de transmisin, bsqueda de rutas ptimas, etc. Capassuperiores. Su misin es dar servicios al usuario del sistema de comunicaciones. Confan 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 encapsulacin y desencapsulacin El modelo OSI describe cmo se desplaza la informacin desde los programas de aplicacin de diferentes ordenadores en un medio de la red. Cada capa realiza dos procesos de comunicacin: Comunicacinhorizontal. Comunicacin con su capa de igual nivel del otro sistema, que recibe el nombre de protocolo. Comunicacinvertical. Comunicacin con sus niveles inmediatamente superior e inferior, que recibe el nombre de primitivas de servicio.
Nota Hay que sealar la sospechosa coincidencia del nmero 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.
FUOC PID_00147725
39
Cuando un usuario necesita transmitir datos a un destino, el sistema de red va aadiendo informacin de control (cabeceras) para cada uno de los servicios que utilizar la red para ejecutar la orden de transmisin.
8.3. Modelo TCP/IP

(14)
En el modelo TCP/IP
14
se pueden distinguir cuatro capas:
TCP/IP es la abreviatura de Transmission Control Protocol/Internet Protocol.
La capa interfaz de red. La capa de red o Internet. La capa de transporte. La capa de aplicacin.
FUOC PID_00147725
40
Pasemos a describirlas brevemente.
La comparacin de los modelos arquitectnicos de OSI y TCP/IP es la siguiente.
FUOC PID_00147725
41
El modelo OSI tiene siete capas, mientras que el modelo TCP/IP slo tiene cuatro. Las capas de transporte y de Internet coinciden plenamente con los niveles 3 y 4 de la torre OSI. La capa de aplicacin engloba los niveles 5, 6 y 7 de OSI (sesin, representacin y aplicacin). La capa interfaz de red incluye los niveles fsico y enlace de la torre OSI. 8.3.1. Encapsulacin de la informacin en el modelo TCP/IP El funcionamiento del modelo OSI con la encapsulacin de los datos se puede observar en la siguiente figura.
Los datos de informacin del nivel aplicacin son encapsulados en la capa de transporte, donde se le aade la cabecera del protocolo TCP, conformando la unidad de informacin denominada segmento. Cuando se enva 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 informacin llamada paquete en este nivel. Este paquete es enviado a la tarjeta de red y all es encapsulado segn las normas del protocolo del nivel de enlace. Normalmente aade una cabecera del protocolo de enlace al principio del paquete. En muchos proto-
FUOC PID_00147725
42
colos tambin se aade una cola de datos que sirve para la deteccin de errores al final del paquete. La unidad de informacin aqu recibe el nombre de trama. Finalmente, los datos son enviados por el medio de transmisin en forma de impulsos electromagnticos o bits. 8.4. Modelo OSI comparado con modelo TCP/IP El modelo OSI, de orientacin ms acadmica, es ms 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 distincin 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 terico, aunque la mayora de los grandes fabricantes de ordenadores y compaas telefnicas impulsaron su utilizacin ofreciendo productos y servicios basados en l. Las razones principales que motivaron este fenmeno se resumen como sigue: OSI apareci tarde. Como todo estndar, se tardaron aos 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 despus se defini el modelo como una simple descripcin de los protocolos ya existentes. Por este motivo, el modelo TCP/IP es ms 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 costossimas inversiones. En contraste, TCP/IP fue rpidamente 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 Administracin para controlar las telecomunicaciones (un engendro poltico-burocrtico).
FUOC PID_00147725
43
Por todo eso, TCP/IP se convirti en el lder mundial absoluto en interconexin de redes. No obstante, TCP/IP tampoco se libr de la crtica. Por una parte, no distingue conceptos tan importantes como servicio, interfaz y protocolo. En segundo lugar, el modelo TCP/IP no es ningn modelo, es decir, su utilizacin como esquema de referencia resulta bastante intil en el estudio de otras arquitecturas. En tercer lugar, en el modelo TCP/IP la capa ordenador principal-red es ms 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.
Difusin de TCP/IP y del modelo OSI Hoy en da, la difusin de TCP/ IP por toda Europa es completa, mientras que los servicios basados en protocolos OSI han desaparecido prcticamente.
FUOC PID_00147725
44
9. Breve historia de las comunicaciones
La dcada de los sesenta vio la aparicin de los primeros ordenadores comerciales. Eran grandes, caros y poco potentes. Slo los podan comprar organismos oficiales, grandes empresas o universidades, y lo ms normal era que slo compraran uno (o algunos, pero no uno para cada usuario, como hoy estamos acostumbrados a ver). Por eso, estos ordenadores tenan sistemas operativos multitarea y multiusuario, para que diferentes usuarios, haciendo diferentes trabajos, los pudieran utilizar simultneamente. El acceso a estos ordenadores se haca 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 delegacin al ordenador principal. Para poder hacer este acceso remoto, la primera solucin que aportaron los ingenieros informticos de la poca fue utilizar la red telefnica que, por su ubicuidad, les evitaba tener que generar ninguna infraestructura nueva. Slo haca falta un aparato que adaptara los bits a la red15. Estos aparatos son los mdems. Los primeros mdems eran de 300 bps y generaban dos tonos diferentes: uno para el 1 lgico y otro para el 0. Actualmente, van a 56.000 bps, que es el mximo que permite la actual red telefnica convencional. Los mdems no slo servan para poder alejar los terminales pasivos de los ordenadores principales, tambin permitan interconectar ordenadores entre s, de manera que desde los terminales de uno se poda acceder a los de otro y viceversa.
Mdems de los aos ochenta (15)
Recordad que la red telefnica slo deja pasar sonidos entre unos mrgenes de frecuencia.
La tecnologa de conmutacin de circuitos se desarroll originalmente para las comunicaciones telefnicas, y una de sus caractersticas fundamentales era la ocupacin en exclusiva de los recursos mientras duraba la conexin, cosa que, como ya hemos visto, justificaba la tarificacin por tiempo. Pero las comunicaciones informticas no son cortas, intensas y espordicas como las de voz. Al conectar un terminal a un ordenador principal mediante dos mdems, no se pasan datos durante todo el rato que dura la conexin: puede haber largos perodos de tiempo en los que no pase ningn bit y ratos en los que haya un intercambio de datos intenso, aunque, desde luego, a una velocidad de transmisin mucho ms baja que la que se puede mantener entre el terminal y el ordenador conectados directamente. Las facturas telefnicas empezaron a ser astronmicas, y desproporcionadas, respecto del uso real de la red.
Perodos en la historia de Internet Internet es, como tantas otras tecnologas innovadoras, un invento militar. Naci del inters del ejrcito norteamericano en los aos 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 perodos clave en la historia de Internet: Primer perodo: 1957-1970. Nacimiento de Internet. Segundo perodo: 1970-1990. Del Ejrcito a la Universidad. Tercer perodo: 1990-1995. Expansin fuera de los mbitos militares y universitarios. Cuarto perodo: 1996-Actualidad. Multimedia y cientos de millones de usuarios.
Primer perodo: 1957-1970. Nacimiento de Internet Dentro del primer perodo de la historia de Internet podemos destacar los siguientes acontecimientos: 1945: Publicacin de la primera referencia a una red electrnica similar a Internet: "Memex", citado en el artculo "As We May Think", de Vannevar Bush (director de la Oficina de Investigacin Cientfica y Desarrollo norteamericana). 1957: Durante la guerra fra, la Unin Sovitica lanza el Sputnik, el primer satlite 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 artculo sobre la teora de conmutacin de paquetes. 1962: Licklider (MIT) lanza la idea de la "Galactic Network", una red interconectada globalmente a travs de la que cualquiera podra acceder desde cualquier lugar a datos y programas. Licklider fue el principal responsable del programa de investigacin en ordenadores en ARPA, la agencia de investigacin avanzada del Pentgono. 1964: Paul Baran (RAND Corporation) realiza sus estudios sobre "Redes de comunicacin distribuidas o descentralizadas". Tambin promueve el uso de redes de conmutacin de paquetes de datos (Packet Switching Networks). 1961-1965: La idea de red de paquetes descentralizada haba sido trabajada en paralelo por tres grupos de investigacin 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 interconexin de computadores, que se llam ARPANET y fue el antecesor de lo que despus se llamara Internet. 1966: Se desarrolla el concepto de red de ordenadores, que se llamara ARPANET. La red ARPANET poda 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 seal de salida. Un ao ms tarde se disean los primeros programas y el primer hardware especfico para redes. 1969: Hay cuatro centros interconectados a travs de sus IMP (Internet embrionaria). UCLA (Los ngeles) es seleccionada para ser el primer nodo de ARPANET. El centro de investigacin de Standford (SRI) proporciona un segundo nodo. El tercer nodo en la Universidad de California, Santa Brbara, y el cuarto nodo en la Universidad de Utah. Estos cuatro nodos constituyeron la red original de ARPANet.
(16) (17)
ARPA es la abreviatura en ingls de la Agencia de Proyectos de Investigacin Avanzada. NPL es la abreviatura de National Physical Laboratories (institucin del Reino Unido).
FUOC PID_00147725
46
Pronto, las grandes empresas presionaron a las compaas telefnicas del momento para que desarrollaran redes pensadas para transportar datos, con un sistema de tarificacin que se ajustara al trfico de datos real y permitiera ms velocidad que los escasos 300 o 1.200 bps que se alcanzaban en aquella poca utilizando la red telefnica. La respuesta fueron las redes de conmutacin de paquetes. El envo 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 transmisin y mantenerlo 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 ms prxima para que los enve 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 estn ocupados, no pasa nada, se le hace esperar ponindolo en una cola para enviarlo cuando haya un enlace disponible.
CCITT El CCITT es un organismo internacional patrocinado por las operadoras de telefona, dedicado a tareas de normalizacin en el mbito de las telecomunicaciones. El 1 de marzo de 1993 pas a llamarse International Telecommunication Union Standardization Sector (ITU-T).
Nodos en ARPANET en 1971
La transmisin por paquetes tiene la ventaja de que slo 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 comunicacin de datos, es hasta cierto punto tolerable. Con respecto a la cuestin econmica, no tiene sentido que se cobre por tiempo de conexin: 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 prdidas y regulen el flujo de informacin entre los nodos de conmutacin. Las compaas telefnicas desarrollaron redes de este tipo, y el CCITT emiti un estndar, 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 perodo: 1970-1990. Del Ejrcito a la Universidad Dentro del segundo perodo de la historia de Internet podemos destacar los siguientes acontecimientos: Aos1970. Durante este perodo, la red fue de acceso restringido a los investigadores y a las empresas privadas que participaban en proyectos financiados por la Administracin. 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 emoticn: :-). Vinton Cerf escribe por primera vez la palabra Internet. Est considerado el padre de la red. Ms tarde dise el protocolo TCP/IP, que actualmente rige las comunicaciones por Internet.
18 1971. Ray Tomlison (BBN ) crea los protocolos bsicos del correo (e-mail), incluida la convencin de la arroba para separar el nombre de la persona del identificador del ordenador.
1972. Se presenta pblicamente ARPANET en la International Computer Communication Conference. Investigadores del MIT dieron a luz el germen de lo que sera el sistema de transferencia de archivos FTP y telnet. El Sistema de Agencias de Informacin de Defensa crea la IANA o Autoridad de asignacin de nmeros de Internet, responsable de asignar una direccin nica a cada computador conectado a Internet. 1973. Vint Cerf y Bob Kahn especifican la primera versin del programa de control de transmisin (TCP), que se desarroll despus 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 versin 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 ao 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 estndar. Se crea la EuNet (European Unix Network). La European Unix Network (EuNet), conectada a ARPANet, se cre en 1982 para proporcionar servicios de correo electrnico y servicios Usenet a diversas organizaciones usuarias en los Pases Bajos, Dinamarca, Suecia e Inglaterra. 1983. Considerado como el ao 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 da, los ya miles de ordenadores conectados se cambiaron al nuevo sistema. Internet ya dispone de 562 servidores (ordenadores interconectados). El mismo ao se cre el sistema de nombres de dominios (.com, .edu, etc., ms las siglas de los pases), que prcticamente se ha mantenido hasta ahora. 1984. El ordenador pasa a estar al alcance de la gente, y su implantacin se acelera cuando se presenta el Macintosh. El nmero de servidores conectados a la red haba superado ya los 1.000. Al ao 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 localizacin de un computador, precursor del servicio DNS de Internet. 1985. Entra en funcionamiento el Domain Name Server (DNS), un mtodo para resolver nombres en direcciones numricas. 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 aadidos. En abril aparecen los primeros dominios con letra, que fueron acmu.edu, purdue.edu, rice.edu y ucla.edu, todos ellos todava en activo sin duda, y todos universitarios, tambin sin duda. En junio del mismo ao aparece el primer dominio gubernamental, css.gov, y en julio, mitre.org. El primer dominio de un pas se atribuy en julio de aquel mismo ao a Gran Bretaa: co.uk. En Espaa, los ordenadores de diferentes universidades se conectaban entre s y con el Centro Europeo de Fsica de Partculas (CERN). El Ministerio de Educacin y Ciencia, a travs de la Secretara de Universidades, elabor un plan para interconectar los centros de clculo de las universidades. Asimismo, un grupo de expertos de las universidades, centros de clculo, organismos pblicos de investigacin y Telefnica, bajo la coordinacin de Fundesco, realiz un informe que se llam Proyecto IRIS (Interconexin de Recursos Informticos). 1987. Nace la primera versin de Windows. Hay ms de 10.000 servidores en todo el mundo. 1988. Se produce el primer gran ataque vrico 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 raz del "gusano de Morris" se crea el Computer Emergency Response Team (CERT). Jarkko Oikarinen, un joven finlands, decide modificar el comando talk del Unix para permitir que diversas personas puedan charlar de forma simultnea. As nace el chat, el Internet Relay Chat (IRC), que permite que se pueda conversar en lnea en la red. En 1988 nace el programa IRIS dentro del Plan Nacional de Investigaciones y Desarrollo Tecnolgico para dar conectividad a cientficos e investigadores. La financiacin y supervisin de esta red correra a cargo de la Comisin Interministerial de Ciencia y Tecnologa, y de su gestin y direccin se encargara Fundesco. 1989. Nace RIPE para interconectar las redes europeas. El nmero de servidores conectados a Internet alcanza ya los 100.000. Este mismo ao, se inaugura tambin la primera conexin de un sistema de correo electrnico comercial en Internet (MCI y Compuserve). Nace Archie. Hasta aquel momento nadie se haba planteado nunca la hiptesis de que en Internet las cosas pudieran tener un orden, ni de crear un directorio. Las direcciones eran tan pocas que se supona que todo el mundo las conoca. Por este motivo, se crea el primer catlogo (un programa denominado Archie). Archie tuvo tal xito que colaps el trfico 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 despus 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 ms de un ordenador en la misma instalacin, 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 diseo 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 difcil de conseguir con las redes de conmutacin, pensadas para interconectar dos estaciones. Para este tipo de redes es ms adecuada la difusin con medio compartido, en la que los paquetes que salen de una estacin llegan a todo el resto simultneamente. En la recepcin, las estaciones los aceptan o ignoran segn que sean sus destinatarias o no. Se habla de difusin porque los paquetes se difunden por todas partes, y de medio compartido porque esta difusin se hace sobre un medio comn que las estaciones comparten. De la dcada de los sesenta son tambin los primeros estndares de arquitecturas de protocolos. Hay que tener presente que el intercambio de informacin entre ordenadores tiene toda una serie de implicaciones, entre las que se incluyen las siguientes: Aspectos elctricos: los cables, los conectores, las seales, etc. La manera de agrupar los bits para formar paquetes y la de controlar que no se produzcan errores de transmisin. La identificacin de los ordenadores dentro de la red y la manera de conseguir que la informacin 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 cooperacin de todos los niveles proporciona la conectividad querida por los usuarios. Hay que tener presente que, en la poca que nos ocupa, la informtica estaba en manos de muy pocos fabricantes e imperaba la filosofa del servicio integral: cada fabricante lo proporcionaba todo (ordenadores, cables, perifricos, sistema operativo y software). Por lo tanto, cuando una empresa se quera informatizar, escoga una marca y quedaba ligada a ella para toda vida.
FUOC PID_00147725
50
En la dcada de los setenta, el panorama cambi radicalmente, sobre todo a causa de tres acontecimientos: La propuesta del protocolo Ethernet para redes locales. La aparicin del sistema operativo Unix, no ligado a ninguna marca comercial, compatible con todas las plataformas de hardware que haba. La invencin de los protocolos TCP/IP, embrin de la actual Internet.
Se haba allanado el camino para la aparicin de los sistemas abiertos: no haba que atarse a ninguna marca para tenerlo todo. El hardware poda ser de un proveedor, el sistema operativo de otro, las aplicaciones de otro y los protocolos, pblicos.
Tercer perodo: 1990-1995. Expansin fuera de los mbitos militar y universitario Dentro del tercer perodo 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 ao tambin aparece Windows 3.0. En Espaa, Fundesco cambia el nombre del programa IRIS por REDIRIS y se conecta al
19 backbone de Internet (NSFNET ), al lado de Argentina, Brasil, Chile, India, Suiza, Austria, Irlanda y Corea del Sur. En la parte superior de la imagen se puede ver el primer banner de Internet en HotWired (1994).
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 aos atrs, su propsito era poner en comunicacin a los cientficos. La WWW es una creacin 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 travs de una red que permitiera intercomunicar a los fsicos de todo el mundo. Berners-Lee cre el HTML, el HTTP y las URL. 1992. Nace la Internet Society, la "autoridad" de la red. Surga como el lugar donde pactar los protocolos que haran posible la comunicacin. El Internet Activities Board (IAB) se integra en la Internet Society. En el IAB destac la Internet Engineering Task Force (IETF), que tena como funcin el desarrollo de Internet a corto plazo y la responsabilidad de la direccin tcnica. La mayor parte de los Request For Comments (RFC) se elaboran en el IETF, y stos iban aumentando cada ao. Internet ya tiene 1.136.000 servidores. En Espaa aparece Goya Servicios Telemticos, primer proveedor de acceso comercial. 1993. Aparece el primer visualizador grfico de pginas web: Mosaic, el antecesor de Netscape. Hasta aquel momento la red era slo texto: ahora sobre un fondo gris aparecen documentos con grficos 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 Castelln publica el primer servidor web de Espaa, donde ya haba 10 nodos y 15.000 mquinas bajo el dominio .es. 1994. Ao 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 abogaca). En octubre, ATT y Zima (una marca de refrescos) ponen los primeros banners comerciales de la historia en Hotwired. Pero no todo son desgracias: tambin se abren el primer centro comercial, la primera radio y el primer banco en la red. El nmero 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 versin comercial del navegador Netscape Navigator. En Espaa nace Servicom.
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 estratgico hacia Internet. El fabricante Digital (DEC) crea AltaVista, un buscador de Internet. Nacen la librera Amazon.com y el sitio de subastas eBay. Hay ms 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.

(20)
TCP/IP naci a partir de un encargo de la Defense Advanced Research Project Agency

20
(DARPA) a la comunidad cientfica americana para tener una red
En castellano, Agencia de Proyectos de Investigacin Avanzada para la Defensa.

(21)
mundial que fuera reconfigurable fcil y automticamente en caso de destruccin de algn nodo o algn enlace. La pila TCP/IP es una jerarqua de protocolos que ofreca conectividad y, a pesar de tener poco que ver con las que ya haba, era una opcin ms 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 haba propuesto y que pretenda ser completo, racional y muy bien estructurado (la TCP/IP tiene fama de ser una pila de protocolos anrquica), con la intencin, 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 dcada de los noventa, a medida que los que conocan la red la iban "enseando", y su popularizacin estall cuando salt al mundo de la empresa, en todas sus vertientes: como escaparate de productos o como canalizador de contactos comerciales.
ISO son las siglas de la International Organization for Standardization, en castellano, Organizacin Internacional de Estandarizacin.
Tim Berners Lee. Creador de la WWW
Su origen universitario, sin embargo, ha marcado esta evolucin 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 sesin remota, la transferencia de ficheros (FTP), el correo electrnico y, sobre todo, la WWW (World Wide Web) son ejemplos claros de aplicaciones que siguen
FUOC PID_00147725
52
este modelo. Las dos primeras han cado en desuso un poco, pero tanto el correo como la WWW son las estrellas hoy en da en Internet. Tmidamente, aparecen nuevas propuestas de aplicaciones, pero la WWW, que naci como un servicio de pginas estticas enlazadas con hiperenlaces, se est convirtiendo en la interfaz de usuario de toda la red, porque actualmente se utiliza para servir pginas dinmicas (se crean en el momento en que se sirven), e incluso, como cdigo 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 analgica, con conmutacin de circuitos, pensada para voz. Una red digital, con conmutacin de paquetes, pensada para datos.
La red telefnica, tal como la hemos descrito hasta ahora, es completamente analgica: la seal electromagntica que viaja desde un telfono hasta otro es analgica (vara continuamente y en cada momento puede tomar cualquier valor) y los circuitos electrnicos que componen la red tambin lo son. Los enlaces entre centrales de la red telefnica se hacan con seales analgicas con muchos canales multiplexados en frecuencia, y tenan que recorrer, a veces, grandes distancias. La atenuacin de la seal inherente a la distancia que haba que recorrer se tena que corregir mediante repetidores que la amplificaran, cosa que aumentaba el ruido presente en la lnea. Muy a menudo, la seal recibida era de una calidad muy baja porque la transmisin analgica no permite eliminar el ruido ni las interferencias en la recepcin. No hay ninguna manera de saber exactamente qu se ha enviado desde el origen y qu es ruido aadido. En 1972 se hicieron pblicos los primeros resultados del tratamiento digital de la seal aplicada a audio, bsicamente orientado a su almacenaje. El CD estaba viendo la luz. Convertir un sonido (una magnitud fsica que puede tomar cualquier valor en cualquier momento) en una serie de 0 y 1 (dos nicos valores conocidos) permita corregir fcilmente cualquier ruido aadido. El descubrimiento del procesamiento digital de la seal, y sus aplicaciones en los campos del sonido y la imagen, ha sido un hito primordial en el mundo de las comunicaciones. Bsicamente, ha permitido reducir drsticamente el efecto del ruido, lo cual ha permitido, por una parte, incrementar la calidad de recepcin de las seales y, por otra, aumentar la velocidad de transmisin con los mismos medios. Las compaas telefnicas empezaron a sustituir los enlaces internos (entre centrales) por seales digitales, pero manteniendo el bucle de abonado (lnea y terminal) analgico. La digitalizacin de la seal de sonido se hace dentro de la central local, despus del filtro de 4 kHz, y se vuelve a pasar a analgico en la central correspondiente en el otro extremo de la comunicacin. Eso ha
FUOC PID_00147725
53
hecho cambiar sustancialmente los procesos de conmutacin: ahora se tiene que trabajar con bits y, por lo tanto, las centrales electromecnicas se tienen que sustituir por ordenadores. Esta digitalizacin de la parte interna de la red de voz hizo que confluyeran de alguna manera las dos redes, la telefnica y la de datos: los enlaces digitales entre centrales se utilizaban indistintamente para paquetes de datos y para transmisiones de voz.
Cuarto perodo: 1996-Actualidad. Multimedia y cientos de millones de usuarios Dentro del cuarto perodo 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 ms de 9.400.000 servidores. En Espaa hay ms 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 creacin de siete nuevos dominios genricos; tv.com se vende a CNET por 15.000 dlares. Procter&Gamble, el mayor anunciante del mundo, impone el pago por clic, que dominar la publicidad en lnea. Inclusin de contenidos multimedia: tcnica de streaming para la transmisin fluida de vdeo. 1997. Business.com se vende por 150.000 dlares. En 1997 ya hay 17 millones de servidores en la red. En Espaa se crea ESPANIX para intercambiar trfico local; a finales de ao hay 500 proveedores y un milln de internautas, gracias a Infova. 1998. Microsoft, con su Explorer, tiene ms del 80% de los navegadores, y es demandado por abuso de posicin dominante. La red tiene 300 millones de pginas. 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 Espaa, Telefnica desactiva Infova 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 dlares por Business.com. A final de ao, el ndice NASDAQ alcanza cifras desmesuradas. Espaa 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 ftbol americano, a mediados de enero, se anuncian 17 compaas "puntocom", que pagan 2 millones de dlares por 30 segundos de anuncio cada una. En marzo, el ndice NASDAQ alcanza su pico histrico: 5.048 puntos; durante el verano se inicia una larga cada. Terra compra Lycos por 12.500 millones de dlares, y al lado de Telefnica empieza a ofrecer ADSL. Los operadores de cable empiezan a prestar servicio de banda ancha domstica en Espaa. La tienda de ropa Boo.com bate rcords, con una facturacin en seis meses de 160 millones de dlares. Microsoft es condenado por abusar de su cuasi-monopolio en sistemas operativos. Se calcula que la web supera los 1.000 millones de pginas. 2001. Arranca con el pleito abierto de nuevo por las discogrficas contra Napster por favorecer la piratera, pleito que acaba por provocar su cierre en julio por orden judicial (y su resurreccin como servicio de pago). En febrero, Napster haba batido su propio rcord, 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 meditico 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 rpida quiebra en abril. Su competidora Webvan sufre igual suerte. En mayo se lanza el programa SETI@Home, el primer gran proyecto de computacin distribuida; en menos de un mes proporciona ms potencia de clculo que el mayor superordenador disponible entonces.
FUOC PID_00147725
54
2002. La crisis de las puntocom contina profundizndose. Los dominios son noticia, con la apertura de tres nuevos dominios de mximo nivel (.name para personas, .coop para cooperativas y .aero para empresas aeronuticas) que no tendrn 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. Explosin en el uso de los weblog o blogger: pginas escritas por los cibernautas en las que stos explican ancdotas de sus propias vidas y dan a conocer sus opiniones. Lo que queda de Napster es adquirido por el conglomerado alemn Bertelsmann. 2003. Ao de la msica. La patronal musical de Estados Unidos (RIAA) denuncia por primera vez a usuarios finales por intercambiar msica en redes P2P. Apple lanza su tienda de msica iTunes, asociada al reproductor iPod. Despus de dos aos de continua cada 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 raz y afectando a bancos y el trfico areo, hasta SobigF y Blaster. Despus de una cierta parada entre 2001 y 2002, se recupera el vigoroso ritmo de crecimiento del nmero de servidores en la red. Este ao tambin empieza el ataque judicial de SCO contra Linux. 2004. Empieza la recuperacin. 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 msica de pago tambin 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 mdems y la campaa de las presidenciales demuestra el poder de los blogs llamados "Rathergate"; el precandidato Howard Dean usa la red para la movilizacin del electorado y la recaudacin de fondos. En Espaa Terra vende Lycos por 105 millones de dlares. El copyleft avanza con la extensin de las licencias Creative Commons. 2005. Existen ms servidores raz fuera de Estados Unidos que en su territorio. La red tiene ms de 300 millones de ordenadores principales, casi 60 millones de dominios activos, ms de 4.000 millones de pginas web indexadas por Google y ms de 900 millones de internautas. Suecia tiene la penetracin ms alta (74% de la poblacin), y Espaa ocupa el puesto 22 por accesos de banda ancha (casi 2,5 millones) y el 12 por nmero de internautas (14 millones), pero est por debajo de la media europea en penetracin. Diversos accidentes y ataques difunden informacin privada en la red. Microsoft responde a Firefox con el lanzamiento de una versin no prevista del Explorer. Apple presenta el iPod Shuffle, basado en memoria flash. El mercado de la publicidad en lnea se despierta, y diversos medios espaoles relanzan sus pginas web. A finales de este mismo ao nace Youtube. 2006. Aparecen los principales exponentes de la revolucin de la Web 2.0: Facebook y GoogleEarth. El fenmeno de la red interactiva y dinmica empieza a extenderse. Se empiezan a esbozar nuevas tendencias de computacin distribuida. Aparece el trmino cloud computing. 2007. Las plataformas de descarga de contenidos basados en tecnologas p2p aglutinan la mayora del trfico de la Red. XMPP se convierte en estndar de facto para las comunicaciones de mensajera instantnea. Gmail deja de ser beta y se convierte en accesible para todo el mundo. Writely, adquirido por Google el ao anterior, es llamado Google Docs. Nace Android como sistema operativo para dispositivos mviles. 2008. Auge en el acceso a Internet mediante dispositivos mviles. Amplia adopcin de la tecnologa 3G. Quincuagsimo 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 pas asitico. 2009. Se esboza la Internet de las cosas. Aparece 6LowPan como iniciativa para proveer de direccin 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 telefnica, el paso siguiente tena que ser llevar la transmisin de bits hasta las casas. Eso permita, por una parte, ofrecer a los usuarios en su casa la transmisin de datos adems de la tradicional de voz y, por otra, ofrecer a los abonados un abanico de nuevos servicios asociados a una comunicacin enteramente digital de punta a punta. Este servicio de transmisin digital mediante la red telefnica se conoce como red digital de servicios integrados (RDSI). Ofrece dos canales independientes de 64 kbps, que permiten hablar y conectarse a Internet simultneamente, o, con un hardware adecuado, aprovechar los dos canales juntos para navegar a 128 kbps. El uso de la red telefnica para transmitir datos tiene una limitacin importante por lo que respecta al mximo de bits por segundo permitidos, y las redes especficas de datos son muy caras para su uso domstico. Desde la dcada 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 mximo. 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: televisin, telfono y datos. Con respecto al segundo, las compaas telefnicas de toda la vida han querido sacar partido del cableado que ya tienen hecho y, por eso, han desarrollado las tecnologas ADSL, que permiten hacer convivir en el bucle de abonado la seal telefnica y una seal de datos que puede llegar a los 8 Mbps (o 20 Mbps con tecnologa ADSL+).
RDSI La red digital de servicios integrados (RDSI) corresponde a las siglas ISDN (integrated services digital network) en ingls.
FUOC PID_00147725
56
Resumen
El mdulo ha introducido los conceptos fundamentales de las redes de computadores. Hemos visto que stas son una composicin de sistemas hardware, software y protocolos que permiten la comunicacin entre dispositivos remotos. Hemos visto las topologas ms comunes de las redes de comunicacin y que stas tambin 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 ms bajos se ocupan de los aspectos fsicos de la comunicacin, desde la caracterizacin del medio a la codificacin de la informacin transmitida. Las capas superiores usan las interfaces de abstraccin de sus capas subyacentes construyendo as un sistema complejo que permite la transmisin estructurada de informacin entre dispositivos remotos. La divisin en capas y las interfaces permiten la abstraccin 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 estructuracin en capas de una red. No obstante, hemos visto tambin que el modelo OSI es complejo y no ha sido utilizado ms que como modelo de referencia. En realidad, Internet usa un modelo TCP/IP ms simple pero funcional. El mdulo ha presentado ambos modelos y los ha comparado. Finalmente, el mdulo 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 prximos mdulos profundizaremos en el conocimiento de los niveles de la red. En este curso hemos adoptado un enfoque top-down, es decir, desde los niveles ms prximos a la aplicacin hasta los niveles ms especficos del hardware. Esta aproximacin puede diferir de la de algunos otros documentos de referencia, en los que las redes se presentan a la inversa, primero, conociendo los niveles fsicos, y, finalmente, presentando los niveles de aplicacin. El mdulo "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 fsico, que, como veris, estn fuertemente interrelacionados. El mdulo "Seguridad en la red" adopta otro enfoque y nos presenta aspectos relacionados con la seguridad de las redes de computadores, hoy en da de primordial importancia. El mdulo 4 nos presenta el nivel de aplicacin donde se profundiza en los conceptos fundamentales que rigen las aplicaciones en Internet (el correo, la web, etc.). Finalmente, el mdulo "Co-
FUOC PID_00147725
57
municaciones inalmbricas" profundiza en el conocimiento de las comunicaciones sin hilos que se estn convirtiendo en el eje principal de las tecnologas de red actuales.
FUOC PID_00147725
59
Bibliografa
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

PID_00147723
FUOC PID_00147723
FUOC PID_00147723
ndice
Introduccin............................................................................................... Objetivos....................................................................................................... 1. El nivel de transporte....................................................................... 1.1. 1.2. 1.3. 1.4. Objetivos ...................................................................................... Servicios ofrecidos por la capa de transporte ............................. Relacin entre la capa de transporte y la capa de red ................. Transporte no orientado a la conexin: UDP ............................. 1.4.1. 1.4.2. 1.5. 1.5.1. 1.5.2. 1.5.3. 2. Cabecera UDP ................................................................ Cabecera UDP ................................................................ Funcionamiento bsico de TCP ..................................... Cabecera TCP ................................................................. Establecimiento de la conexin ....................................
5 6 7 7 8 9 12 12 13 14 15 16 19 21 21 24 25 26 27 27 28 42 49 49 51 52 53 54 55 56 56 57 58 60 60
Transporte orientado a la conexin: TCP ...................................
El nivel de red.................................................................................... 2.1. 2.2. Funcionalidades bsicas: direccionamiento ................................ Servicios de red ........................................................................... 2.2.1. 2.2.2. 2.2.3. 2.3. Modelo de red en modo de circuitos virtuales .............. Modelo de red en modo datagrama .............................. Servicio de red orientado y no orientado a la conexin ........................................................................ Direccionamiento en Internet: el protocolo IP ........................... 2.3.1. 2.3.2. 2.4. 2.4.1. 2.4.2. 2.4.3. 2.4.4. IPv4 ................................................................................ IPv6 ................................................................................ Internet Control Message Protocol ............................... Address Resolution Protocol .......................................... Network Discovery Protocol .......................................... Dynamic Host Configuration Protocol .........................
Protocolos de soporte a IP ..........................................................
3.
El enlace de datos y el control de acceso al medio.................... 3.1. 3.2. 3.3. 3.4. 3.5. Terminologa y definiciones ....................................................... Tipo de enlaces ........................................................................... Tipo de servicios suministrado en la capa de red ....................... Servicios proporcionados por la capa de enlace ......................... Adaptadores y dispositivos de red ..............................................
4.
El nivel fsico...................................................................................... 4.1. Medios de transmisin ................................................................
FUOC PID_00147723
4.1.1. 4.1.2. 4.1.3.
Par trenzado ................................................................... Cable coaxial de banda base ......................................... Fibra ptica ....................................................................
60 62 62 64 65
FUOC PID_00147723
Introduccin
En este mdulo veremos en detalle las caractersticas y funcionamiento de los diferentes niveles de la red. El objetivo del mdulo es dar una visin general del funcionamiento interno de una red de computadores, ya sea de rea local, ya a gran escala, como es Internet. La aproximacin a los niveles de la red ser desde los niveles ms prximos a las aplicaciones hasta los niveles ms especficos del hardware. Como hemos visto en el mdulo "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 aplicacin, sus servicios y protocolos los veremos en detalle en el mdulo "En el nivel de aplicacin". Antes, y para entender algunos de los conceptos del nivel aplicacin, pasaremos por el nivel de transporte, que ofrece fiabilidad a la red permitiendo el acceso de diferentes aplicaciones a un nico medio de transmisin, 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 mdulo conoceremos el funcionamiento actual de la red, as como las nuevas tecnologas de red que se convertirn en estndares en un futuro. La capa de enlace abstrae los nodos de la red del medio fsico sobre el que transmiten la informacin. Esta capa se encarga de dirigir la informacin entre nodos fsicos adyacentes y garantizar una transmisin fiable entre ellos. Hay que destacar la tarea de la subcapa de control de acceso al medio que permite transmitir informacin entre dos nodos independientemente de la tecnologa de red utilizada, ya sea inalmbrica, ya cableada. Finalmente, el nivel fsico se encarga de los aspectos de modulacin y codificacin de las seales fsicas que son dependientes directamente de la tecnologa y el medio de transmisin. El mdulo, en definitiva, os permitir haceros una idea general y amplia del funcionamiento de una red de computadores.
FUOC PID_00147723
Objetivos
El estudio de este mdulo 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 estndares de red actuales. 7. Tener una visin global del funcionamiento de la capa de enlace y fsica.
FUOC PID_00147723
1. El nivel de transporte
El nivel de transporte abstrae la complejidad de la red a las aplicaciones. En este mdulo, veremos su funcionamiento con detalle. 1.1. Objetivos La capa de transporte se encarga de proveer comunicacin extremo a extremo entre procesos de aplicaciones ubicadas en diferentes hosts. Desde el punto de vista de la aplicacin, es como si los hosts estuvieran directamente conectados, pero en realidad podran estar en lugares opuestos del planeta, conectados mediante mltiples routers y tipo de enlaces diferentes. La capa de transporte ofrece las funcionalidades bsicas para alcanzar este nivel de comunicacin lgica, 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 informacin transmitida por las aplicaciones es convertida en paquetes de la capa de transporte, conocidos como segmentosdelacapadetransporte. Los segmentos de la capa de transporte se construyen dividiendo la informacin que quiere transmitir la aplicacin en segmentos de un tamao determinado, a los que se aade una cabecera. Cada segmento se enva 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 examinarn la informacin correspondiente a la capa de red. Slo los receptores, al recibir el datagrama en la capa de red, extraern el segmento de transporte y lo pasarn a la capa de transporte del receptor. La capa de transporte procesar el segmento y lo pasar a la aplicacin correspondiente.
FUOC PID_00147723
En este mdulo 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 jerarqua TCP/IP
1.2. Servicios ofrecidos por la capa de transporte La capa de transporte ofrece las siguientes funcionalidades: Garantiza la transmisin sin errores, extremo a extremo, independientemente del tipo de red. Controla la transmisin extremo a extremo. Es responsable del control de flujo de los datos y del control de congestin 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 prdidas, sin errores y sin ser duplicadas. Ordena los paquetes que llegan.
FUOC PID_00147723
Se encarga de fragmentar los mensajes y recomponerlos en destino cuando es necesario.
Permite la multiplexacin de diversas conexiones de transporte sobre una misma conexin de red.
1.3. Relacin 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 comunicacin lgica entre procesos que se ejecutan en hosts diferentes, la capa de red provee comunicacin lgica entre hosts. Esta diferencia es sustancial, pues la capa de transporte tiene que permitir que mltiples procesos se comuniquen de forma lgica haciendo uso de una nica conexin lgica provista por la capa de red. Este concepto se llama multiplexacin y demultiplexacin de la capa de transporte.
Adems, la capa de red no da garantas de entrega de la informacin, no garantiza la entrega de los segmentos, ni tampoco garantiza la integridad de la informacin contenida en el segmento. Por esta razn, la capa de red noes confiable. La misin, pues, de la capa de transporte consiste por una parte en proveer la transmisin de datos fiable y permitir la comunicacin proceso a proceso en una red creada comunicando host a host. Para introducir los protocolos del nivel de transporte, nos centramos en la jerarqua de protocolos Transmission Control Protocol/Internet Protocol (TCP/ IP). En esta jerarqua se definen dos protocolos de transporte: el UDP y el TCP. El UDP no est orientado a la conexin, lo que quiere decir que no implementa fases de establecimiento de la conexin, envo de datos y fin de la conexin, mientras que el TCP est orientado a la conexin. En el caso de la jerarqua TCP/IP, se definen dos direcciones que relacionan el nivel de transporte con los niveles superior e inferior: La direccinIP es la direccin que identifica un subsistema dentro de una red. El puerto identifica la aplicacin que requiere la comunicacin.
Para identificar las diferentes aplicaciones, los protocolos TCP/IP marcan cada paquete (o unidad de informacin) con un identificador de 16 bits llamado puerto.
FUOC PID_00147723
10
Puertos conocidos. Estn 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.
Puertosefmeros. Son asignados de forma dinmica por los clientes dentro de un rango especfico por encima de 1.023. Identifican el proceso del cliente slo mientras dura la conexin.
0-255 (IANA) 255-1.023(IANA) > 1.023
Aplicaciones pblicas. Asignados a empresas con aplicaciones comerciales. No estn registrados (efmeros).
Puerto de aplicaciones pblicas establecidas por IANA Decimal 0 1-4 5 7 9 11 13 15 17 19 20 21 23 25 37 39 42 43 53 67 68 69 Palabra clave RJE ECHO DISCARD USERS DAYTIME NETSTAT QUOTE CHARGEN FTP-DATA FTP TELNET SMTP TIME RLP NAMESERVER NICNAME DOMAIN BOOTPS BOOTPC TFTP Reservado No asignado Entrada remota de tareas Eco Descartar Usuarios activos De da Quin est conectado o NETSTAT Cita del da Generador de caracteres Protocolo de transferencia de archivos (datos) Protocolo de transferencia de archivos Conexin de terminal Protocolo SMTP (simple mail transfer protocol) Hora Protocolo de ubicacin de recursos Servidor de nombre de anfitrin Quin es Servidor de denominacin Servidor de protocolo de arranque Cliente del protocolo de arranque Protocolo trivial de transferencia de archivos Descripcin
FUOC PID_00147723
11
Decimal 75 77 79 80 95 101 102 113 117 123 137 139 143 150 156 161 179 190 194 197 224-241 242-255
Palabra clave FINGER HTTP SUPDUP HOSTNAME ISO-TSAP AUTH UUCP-PATH NTP NetBIOS NetBIOS IMAP NetBIOS SQL SNMP BGP GACP IRC DLS
Descripcin Cualquier servicio privado de conexin telefnica Cualquier servicio RJE privado Finger Protocolo de transferencia de hipertexto Protocolo SUPDUP Servidor de nombre de anfitrin NIC ISO-TSAP Servicio de autenticacin Servicio de ruta UUCP Protocolo de tiempo de red Servicio de nombres Servicio de datagramas Interim mail access protocol Servicio de sesin Servidor SQL Simple network management protocol Border gateway protocol Gateway access control protocol Internet relay chat Servicio de localizacin de directorios No asignado No asignado
Puertos usados por algunos de los protocolos de nivel aplicacin
FUOC PID_00147723
12
Actividad
Conocis 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 conexin: UDP
El User Datagram Protocol (UDP) es un protocolo no orientado a la conexin, de manera que no proporciona ningn tipo de control de errores ni de flujo, aunque utiliza mecanismos de deteccin de errores. En caso de detectar un error, el UDP no entrega el datagrama a la aplicacin, sino que lo descarta.
Hay que recordar que, por debajo, el UDP est utilizando el IP, que tambin es un protocolo no orientado a la conexin, y que, bsicamente, lo que ofrece UDP, en comparacin con IP, es la posibilidad de multiplexar conexiones de procesos sobre una misma conexin 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 tambin 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 prdida de paquetes, como telefona o videoconferencia sobre TCP/IP, monitorizacin de seales, etc. Estas aplicaciones no toleran retardos muy variables. Si un datagrama llega ms tarde del instante en que tendra que ser recibido, entonces se descarta porque es inservible para la aplicacin. Eso se traduce en un ruido en el sonido o la imagen, que no impide la comunicacin. La tabla siguiente muestra algunas de las aplicaciones ms comunes que hacen uso de UDP.
Aplicaciones TFTP SNMP DHCP - BOOTP DNS Puertos 69 161 67/68 53
1.4.1. Cabecera UDP La unidad de cabecera de UDP es el datagrama UDP. Cada escritura por parte de la aplicacin provoca la creacin de un datagrama UDP. No hay segmentacin.
FUOC PID_00147723
13
Cada datagrama UDP creado es encapsulado dentro de un datagrama IP (nivel 3) para su transmisin.
1.4.2. Cabecera UDP La cabecera del datagrama UDP est formada por 8 bytes. Tiene cuatro campos.
Puertos(fuenteydestino): permiten identificar los procesos que se comunican.
UDPlength: longitud total del datagrama UDP (payload UDP + 8). Es un campo redundante, ya que IP lleva la longitud tambin. Como la longitud mxima de un datagrama IP es de 65.335 bytes (16 bits de longitud de datagrama): Longitud mxima de un datagrama UDP: 65.335 - 20 bytes = 65.315 bytes. Longitud mnima de un datagrama UDP: 8 bytes. Longitud de datos datagrama UDP: 65.315 - 8 bytes = 65.307 bytes. El tamao de un datagrama UDP depende del sistema operativo. Casi todas las API1 limitan la longitud de los datagramas UDP (lo mismo para TCP) a la longitud mxima 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 tamao mximo del datagrama UDP (FreeBSD). UDPchecksum: 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 errneo, se descarta el datagrama UDP y no se genera ningn tipo de mensaje hacia el origen. El checksum se aplica conjuntamente a una pseudocabecera ms la cabecera UDP ms el campo de datos. Esta pseudocabecera tiene 3 campos de la cabecera del paquete IP que se enva. Cabe mencionar que el checksum del datagrama IP slo 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: 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.
Aadiendo la tercera palabra obtenemos:
Ahora hacemos el complemento a 1 (cambiando 0 por 1) y obtenemos: 1011010100111101 Esta ltima palabra se aade tambin al datagrama UDP. En la recepcin se hace la suma de todas las palabras de 16 bits, que tiene que dar 1111111111111111.
1.5. Transporte orientado a la conexin: TCP El Transmission Control Protocol (TCP) es un protocolo de nivel de transporte que se usa en Internet para la transmisin fiable de informacin. Quizs sea el protocolo ms complejo e importante de la pila de protocolos de Internet. Como hemos visto, el UDP no garantiza la entrega de la informacin que le proporciona una aplicacin. Tampoco reordena la informacin 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.
FUOC PID_00147723
15
El TCP da fiabilidad a la aplicacin, es decir, garantiza la entrega de toda la informacin en el mismo orden en que ha sido transmitida por la aplicacin de origen. Para conseguir esta fiabilidad, el TCP proporciona un servicio orientado a la conexin con un control de flujo y errores.
TCP es un protocolo ARQ2, extremo a extremo, orientado a la conexin (fases de establecimiento de la conexin, envo de datos y cierre de la conexin) y bidireccional (full duplex). La unidad de datos TCP es el "segmento TCP". TCP, a diferencia de UDP, intenta generar segmentos de un tamao ptimo que se denomina Maximum Segment Size (MSS), generalmente el mayor posible para minimizar el sobrecoste (overhead en ingls) de las cabeceras, sin que produzca fragmentacin en el nivel IP. Al igual que UDP, TCP utiliza multiplexacin mediante el uso de puertos, tal como hemos visto con anterioridad. Proporciona fiabilidad mediante los siguientes controles: Controldeerrores. TCP es parecido al Go-Back-N pero no descarta segmentos posteriores cuando llegan fuera de secuencia. Permite las retransmisiones selectivas. Controldeflujo (ventana advertida). Sirve para adaptar la velocidad entre el emisor y el receptor. Vigila que el emisor no enve los segmentos a ms velocidad de la que puede emplear el receptor para procesarlos, de manera que se puedan perder paquetes por saturacin de la memoria intermedia de recepcin. Controldelacongestin (ventana de congestin). 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 transmisin, TCP se encarga de fragmentar los datos del nivel aplicacin, y les asigna un nmero de secuencia antes de enviar los fragmentos al nivel IP. En recepcin, como los segmentos pueden llegar fuera de orden, TCP los tiene que reordenar antes de pasarlos a los niveles superiores. 1.5.1. Funcionamiento bsico de TCP En cada extremo, TCP mantiene una memoria intermedia de transmisin y una de recepcin. La aplicacin utiliza los llamamientos al sistema operativo read() y write() para leer y escribir en estas memorias intermedias. Cuando la aplicacin escribe la informacin que se tiene que enviar al emisor, TCP la
(2)
ARQ es la abreviatura de Automatic Repeat-reQuest Protocol; en castellano, protocolo de repeticin de peticin automtica.
FUOC PID_00147723
16
guarda en una memoria intermedia de transmisin. 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 envan sus correspondientes confirmaciones. A medida que los datos van siendo confirmados por el receptor, se van borrando de la memoria intermedia de transmisin y queda espacio libre para que la aplicacin siga escribiendo.
1.5.2. Cabecera TCP
La cabecera TCP est formada por los siguientes elementos: SourcePort / DestinationPort: puertos origen y destino que identifican las aplicaciones.
FUOC PID_00147723
17
SequenceNumber: nmero de secuencia del segmento. Identifica el primer byte dentro de este segmento de la secuencia de bytes enviados hasta aquel momento.
InitialSeq.Number(ISN): primer nmero de secuencia escogido por el protocolo TCP.
Seq Number: ser un nmero a partir de ISN. Por lo tanto, para saber cuntos bytes llevamos enviados hay que hacer Seq. Number - ISN".
Acknowledgment Number: contiene el prximo nmero 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.
Headerlength: longitud total de la cabecera del segmento TCP en words de 32 bits (igual que el campo header length de la cabecera IP). Tamao mnimo de la cabecera TCP = 20 bytes (header length = 5). Tamao mximo 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 vlidos si estn 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. Vlido para todos menos para el SYN inicial.
Push(PSH): indica que el receptor tiene que pasar los datos de la memoria intermedia de recepcin a los niveles superiores tan rpidamente como sea posible. Operacin ms rpida sin llenar la memoria intermedia. La activacin de este flag depende de la implementacin. Las implementaciones derivadas de BSD lo activan cuando la memoria intermedia de Tx se queda vaca.
Reset(RST): se activa cuando se quiere abortar la conexin. Un ejemplo es cuando se recibe un segmento de un cliente dirigido a un puerto donde no hay ningn 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 conexin, durante la sincronizacin de los nmeros de secuencia al inicio de la conexin.
FUOC PID_00147723
18
Finalize(FINAL): se utiliza en la finalizacin de la conexin. AdvertisedWindowSize: tamao de la ventana advertida por el receptor al transmisor (Sliding Window) para el control de flujo. La ventana mxima es de 65.535 bytes.
TCPChecksum: 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 tamao del segmento TCP (cabecera + payload). La pseudocabecera slo es para calcular el checksum: no se transmite en el segmento TCP, ni se incluye en la longitud del paquete IP. El tamao del segmento TCP no se pone en la cabecera TCP, slo se tiene en cuenta en el clculo del checksum. A diferencia de UDP, en TCP el clculo del checksum es obligatorio.
UrgentPointer: Campo vlido si flag URG = 1. Implementa un mecanismo para indicar datos urgentes (es decir, que se tienen que atender lo ms pronto posible). Es un puntero en el Seq Number que indica la parte de datos urgentes dentro del campo de datos. Los datos urgentes irn 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 (interrupcin) desde la aplicacin telnet.
Options: TCP permite aadir opciones a la cabecera, pero, a diferencia de IP, las opciones de TCP suelen utilizarse. Podemos destacar: MaximumSegmentSize: se utiliza durante el establecimiento de la conexin 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. WindowScaleFactor: se utiliza durante el establecimiento de la conexin 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 clculo del RTT.
FUOC PID_00147723
19
SACK: permite que TCP haga retransmisin selectiva (selective ack). TCP utiliza el campo ACK para indicar hasta dnde se ha recibido correctamente. Con la opcin SACK, el receptor puede indicar bloques de segmentos que se han recibido correctamente ms 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 aadidos para que la cabecera tenga un mltiplo de 32 bits. Actividad
Asumimos que un extremo cliente TCP (emisor) ha escogido el 28.325 como nmero 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 nmero de secuencia 29.201, nmero ACK 12.655 y ventana 1.024? Solucin El nmero 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 nmero 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 slo puede aceptar 1.024 bytes antes de confirmarlos. Por lo tanto, el servidor TCP actualizar su ventana de transmisin en 1.024.
1.5.3. Establecimiento de la conexin TCP es un protocolo orientado a la conexin tal como hemos dicho con anterioridad. Eso implica que en todo proceso de comunicacin habr una fase de establecimiento de la conexin 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 (slo es la cabecera TCP): 1) El emisor enva un segmento SYN, con peticin de conexin. 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 conexin se pasa a la fase de envo de datos.
FUOC PID_00147723
20
De la misma manera que el establecimiento de la conexin, se hace necesario un proceso de finalizacin de la conexin. El cierre de la conexin puede deberse a diversas causas: El cliente o el servidor cierra la conexin (LLS close()). Por alguna razn se enva un reset de la conexin (flag activo RST). Cierre a causa de una interrupcin, un controlD o un controlC, etc.
La finalizacin tambin se hace por medio del envo 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 seleccin del mejor camino entre dos puntos separados de la red, permitiendo la interconexin de equipos que pueden estar ubicados en redes separadas geogrficamente unas de otras, garantizando la conectividad extremo a extremo, independientemente de la tecnologa de enlace de datos utilizada y del camino que siga la informacin en los puntos intermedios. Las principales ventajas que nos proporciona esta capa son, por una parte, independencia de la tecnologa de red (hacia capas inferiores), y, por otra, un sistema de abstraccin que permite utilizar una gran diversidad de aplicaciones y protocolos de transporte (hacia capas superiores) como, por ejemplo, TCP o UDP.
Bsicamente, la capa de red, especialmente en Internet, est compuesta por tres grandes bloques: 1) el protocolo que describe la manera de enviar informacin, 2) el protocolo de direccionamiento, que decide por dnde tienen que ir los datagramas para llegar a su destino, 3) la capa de red tambin identifica el mecanismo para informar de cualquier error que se haya producido en el envo de la informacin.
2.1. Funcionalidades bsicas: direccionamiento Una red est compuesta bsicamente por dos tipos de entidades, los clientes (tambin 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 comunicacin, son el origen y el final de la misma. Normalmente son servidores de informacin o equipos de usuarios finales que acceden a los servidores. Por su parte, los encaminadores, a pesar de que en determinados casos tambin pueden ser equipos finales, se limitan a enviar la informacin que reciben por una interfaz de entrada a la correspondiente de salida que lleve los datagramas hacia su destino. Para poder saber hacia dnde va la informacin, 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 informacin. 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 tambin se puede observar una simplificacin de cmo 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 nmero que los identifica, y por otra, los diferentes equipos finales con H (de hosts) y un nmero para identificarlos.
Los encaminadores estn compuestos por una serie de interfaces de entrada y salida, que son las encargadas de recibir los datagramas de los equipos vecinos; estas interfaces estn 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 lgica para decidir qu hacer con los datagramas que llegan. Esta decisin normalmente implica enviar el datagrama por otra interfaz que lo llevar ms 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 sealar 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 enva 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 sealar 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 enva el datagrama al encaminador de su red, lo cual implica que ha de conocer a priori cmo llegar a ese encaminador con el fin de poder enviarle el datagrama. La secuencia especfica de acciones que realiza el equipo se puede ver ms detalladamente en la figura siguiente: 1) Se crea el datagrama con las direcciones de red origen y destino apropiadas. 2) Se busca la direccin 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 direccin de red, salimos con error ya que no sabemos cul es el siguiente salto para enviar el datagrama. 4) Si hemos podido conseguir la direccin, 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 envo 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 funcin 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 caractersticas que tiene que tener el transporte punto a punto de los datos en la capa de red. As, se definen caractersticas como la fiabilidad en el envo de la informacin, orden de llegada de los paquetes, umbrales de retardo en hacer llegar la informacin a destino, informacin de congestin 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 modelodecircuitovirtual y el modelodedatagrama. A continuacin se describen los dos, aunque haremos ms nfasis en el modelo de datagrama, dado que es el utilizado por el nivel de red propuesto por Internet y, por lo tanto, el ms 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 direccin en la que se tiene que enviar la informacin perteneciente a cada circuito. Este paradigma permite acelerar enormemente el envo de paquetes entre dos puntos, ya que el procesamiento intermedio es mnimo; esta prerreserva encima permite garantizar una serie de recursos de red para el trfico 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)Establecimientodelcircuitovirtual: esta fase se inicia en la capa de red del emisor, utilizando la direccin del receptor. El emisor enva un datagrama de creacin 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 creacin en caso de que no queden ms recursos disponibles (normalmente, ancho de banda). Si el establecimiento del circuito puede llegar hasta el destinatario se avisa al emisor indicando que la conexin ha sido satisfactoria y se puede empezar a enviar informacin. 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)Desconexindelcircuitovirtual: esta desconexin puede iniciarla tanto el emisor como el receptor, y se avisa secuencialmente a travs de la capa de red a todos los nodos intermedios hasta llegar al otro extremo. Esta desconexin permite liberar los recursos ocupados por el circuito. Actividad
Qu diferencias creis que pueden existir entre el inicio de un circuito virtual en la capa de red y el establecimiento de una conexin en la capa de transporte? (por ejemplo, el three-way-handshaking). Solucin El establecimiento de la conexin de la capa de transporte involucra nicamente a dos sistemas finales. Los dos extremos acuerdan la comunicacin y determinan los parmetros de conexin, 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 utilizacin de circuitos virtuales es que los nodos intermedios tienen que mantener las reservas de recursos pedidas independientemente de que se estn utilizando, con el potencial problema de infrautilizar la red. 2.2.2. Modelo de red en modo datagrama Si enviar informacin a travs de un circuito virtual implica previamente establecer un camino y reservar recursos, en una red en modo datagrama (tambin llamado conmutacin de paquetes), el paquete se enva directamente a la red con una direccin origen y una direccin destino. Entonces, es trabajo de la red (a travs de las tablas de direccionamiento de cada encaminador) el hacer llegar el paquete a su destino. Como se puede comprobar, en este tipo de comunicacin no hay reserva de recursos ni camino preestablecido entre los extremos de la comunicacin. 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 nmero 2 llega antes que el nmero 1). Las redes en modo datagrama son las ms 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 utilizacin de los recursos ms eficiente, eso viene con un coste asociado. Con este tipo de redes se complica muchsimo la priorizacin del trfico, ya que nunca se sabe a priori cunto trfico se recibir, y lo que es ms 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 garanta de calidad y que "lo har lo mejor que pueda" para hacer llegar el datagrama en su destino. Actividad
Cul de los dos modelos de red vistos consideris que hace un uso de los recursos ms eficiente? Solucin 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 patrn de trfico que sigue la aplicacin, pero como eso, a priori, no es posible muchas veces, se acostumbra a hacer lo que se conoce como overprovisioning (reservar ms recursos de los que se consideran necesarios), lo que inequvocamente lleva a un sistema menos eficiente en trminos de recursos. Por su parte, utilizar el modo datagrama no implica ninguna prerreserva, con lo que la red siempre enviar tan rpidamente como pueda la informacin, siempre y cuando haya recursos disponibles.
FUOC PID_00147723
27
2.2.3. Servicio de red orientado y no orientado a la conexin Anlogamente a los protocolos de transporte que hemos visto anteriormente, en el nivel de red tambin podemos tener protocolos orientados a la conexin y otros que no lo sean. La principal diferencia entre las dos alternativas es que en el servicio orientado a conexin se guarda el estado de la conexin, o lo que es lo mismo, se tiene conocimiento de todas las conexiones establecidas, mientras que en el caso del servicio no orientado a conexin no se tiene constancia de las conexiones existentes. Un ejemplo claro de servicio de red orientado a la conexin es el modelo de circuitos virtuales visto anteriormente. Hay que sealar que el diseo de un protocolo de red no orientado a conexin no excluye que a niveles superiores (transporte) se pueda definir un protocolo orientado a conexin. El ejemplo ms indicativo de eso es la pila de protocolos TCP/IP, donde TCP es orientado a la conexin mientras que IP no lo es. Tanto es as que la arquitectura actual de Internet slo proporciona el modelo de servicio de datagrama, lo que no garantiza el orden de los paquetes, el retardo en el envo, 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 informacin en el modelo no orientado a conexin. IP es el protocolo utilizado en Internet para identificar los nodos de la red, as como tambin para enviar la informacin de una forma estndar e independiente de la tecnologa de red utilizada. Otra caracterstica muy importante de IP es que no implementa mecanismos que garanticen la integridad de los datos que se envan por la red (eso se hace en la capa de transporte), slo se comprueba que no haya errores de transmisin en la cabecera.
Todos los protocolos de red requieren algn mecanismo con el fin de identificar los nodos de la red; esta identificacin en el protocolo IP se realiza a travs de lo que se conoce como direccin IP; actualmente existen dos versiones diferentes del protocolo IP: IPv4 e IPv6. IPv4 es el protocolo ms utilizado en la actualidad en Internet, pero, dado el gran crecimiento que ha sufrido la red, se ha propuesto una extensin, IPv6, ms actual y que algn da se prev que sustituya al IPv4.
Ved tambin En el subapartado "Direccionamiento en Internet: el protocolo IP" se detalla cmo 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 todava es el protocolo de red por excelencia. IPv4 define el formato que se tiene que utilizar para enviar informacin entre dos puntos distantes de la red; el protocolo proporciona mecanismos que determinan cmo se divide el direccionamiento de una forma escalable en una red tan grande como Internet. La cabecera IP IPv4 define qu informacin de control y qu formato tienen que tener los paquetes que se envan 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: Versin(4bits): indica qu protocolo de red utiliza este datagrama. Para IPv4 est fijado en 0x04. Hdr.Len(4bits): la cabecera IP puede tener un tamao variable a causa del campo de opciones. Ese tamao indica en qu punto empiezan los datos del protocolo de transporte. En particular, dicho campo indica el valor en funcin 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 mayora de los casos por ser el tamao por defecto cuando no hay opciones. TypeofService(ToS)(8bits): este campo permite distinguir entre diferentes tipos de datagramas IP; inicialmente se definieron parmetros en funcin de: retardo bajo, tasa de transferencia alta o fiabilidad. As, dependiendo del tipo de trfico que contenga el paquete, por ejemplo trfico
FUOC PID_00147723
29
interactivo, puede quererse un retardo bajo, o en el caso de que el trfico sea de baja prioridad, se puede querer un coste mnimo. 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 tcnica best effort para encaminar los paquetes. TotalLength(16bits): indica el tamao total del datagrama en octetos, lo que incluye la cabecera as como el campo de datos. Los 16 bits indican un tamao mximo del datagrama de 65.535 octetos. Aunque en general el tamao mximo utilizado es de 1.500 octetos. Identifier(16bits),flags(3bits)yfragmentation(13bits): estos campos hacen referencia a lo que se conoce como fragmentacin IP. TTL(8bits): inicialmente, este campo haca referencia al tiempo de vida del datagrama en milisegundos. Pero en la prctica contiene el mximo nmero 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 tcnica se permite descartar datagramas en el caso de que haya algn bucle provocado por algn problema con el sistema de direccionamiento, y as evitar tener paquetes en la red ms tiempo del necesario. De este campo se puede derivar que el "dimetro" mximo posible de Internet es de 255 saltos. Aunque en la actualidad no acostumbra a superar los 30. Protocol(8bits): 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 fcilmente, pasando el control al que corresponda de forma eficiente. HeaderChecksum(16bits): permite detectar algunos tipos de error de transmisin a la cabecera. Es importante sealar que no se comprueba la integridad de la capa de transporte y superiores. Recordemos que IP no garantiza la recepcin de los datos. El checksum se calcula tratando cada dos octetos de la cabecera como enteros y sumndolos utilizando aritmtica 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 pequeo inconveniente de este checksum es que cada encaminador tiene que recalcularlo para cada paquete, dado que el campo TTL (y quizs algunas opciones) cambian a cada salto.
Ved tambin La fragmentacin ser explicada en el subapartado "Fragmentacin IP".
FUOC PID_00147723
30
DireccinOrigen(32bits): indica la direccin origen del paquete. DireccinDestino(32bits): adonde va dirigido el paquete. IPOptions: este campo es el que hace que la cabecera IP pueda ser variable en tamao. 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 diseo de la versin 6 del protocolo se cambi la forma de implementar estas opciones.
Ved tambin Se puede encontrar ms informacin sobre el direccionamiento en el subapartado "Direccionamiento IPv4".
Padding: por motivos de eficiencia, los datos tienen que empezar en una posicin mltiple de 4 octetos, por lo tanto, en el caso de que algunas opciones introduzcan una desalineacin, el padding, que normalmente es todo ceros, alinea a la palabra del siguiente campo.
Data(payload): los datos del datagrama que se pasarn al nivel de transporte, o sea, la informacin que realmente se quiere transmitir.
Fragmentacin IP Uno de los puntos ms crticos a la hora de disear el protocolo IP fue la necesidad de introducir la fragmentacin. La fragmentacin IP es necesaria porque no todas las redes, ni todos los protocolos de enlace de datos, pueden transportar paquetes de tamao arbitrario. En general, el tamao mximo vendr delimitado en funcin de la tecnologa de red utilizada. Por lo tanto, a causa de la diversidad de tecnologas que actualmente coexisten en Internet, podemos encontrar casos en los que el tamao mximo de trama permitido3 sea menor en algn encaminador dentro del camino a seguir por los datagramas, forzando a IP a dividir la trama en fragmentos ms pequeos que se puedan transmitir. Un ejemplo puede ser Ethernet, que permite tramas de un tamao mximo de 1.500 bytes, mientras que una tecnologa como Asynchronous Transfer Mode (ATM) en general tiene el mximo en 9.180 bytes. Hace falta sealar 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 supondra una prdida de rendimiento considerable), por lo que slo dividir el datagrama no es suficiente, es necesario hacer algn 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 tendrn el mismo identificador, cada fragmento contendr el desplazamiento y finalmente el flag, que ser 1 si hay ms paquetes, o 0 si es el ltimo. Por las restricciones en la implementacin, y para reducir el nmero de bits que se utilizan para almacenar este desplazamiento, se de(3)
En ingls, Maximum Transfer Unit (MTU).
FUOC PID_00147723
31
cidi hacerlo con mltiplos 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 fragmentacin En la figura siguiente se puede ver el caso en que un equipo enva un paquete de tamao MTU = 2.500 bytes. Lo que quiere decir que el paquete tendr 2.480 bytes de informacin 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 tamao 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 todava hay ms 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 direccin 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 mxima 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 adems, en vez de utilizar la representacin binaria, que es poco legible, en la prctica se escribe la direccin IP en notacin decimal separada por puntos; la direccin estar formada por 4 bloques de nmeros entre 0 y 28 - 1 (255).
Representacin binaria y decimal de una direccin IP
Adems, tener un nmero tan grande de direcciones supone un enorme problema de gestin, por lo que se propuso un sistema de asignacin de direcciones jerrquico. En Internet, las direcciones IP estn 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.
FUOC PID_00147723
32
La parte de red est formada por los bits superiores de la direccin IP e indica a qu red pertenece un conjunto de equipos, o lo que es lo mismo, cul es el encaminador de salida del conjunto de equipos. Por el contrario, la parte del equipo son los bits inferiores de la direccin IP e identifican el equipo dentro de su red.
Inicialmente, esta divisin con redes se hizo a travs de clases, concretamente se definieron 5 clases diferentes (A, B, C, D y E) tal como muestra la tabla siguiente: Las direccionesdeclaseA 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 estn 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 direccionesdeclaseB 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 direccionesdeclaseC, son las destinadas a medianas empresas con fuerte presencia en Internet; en este caso se dispone de 28 (256) direcciones, con un total de 221 (2.097.152) direcciones de tipo C a repartir. Con respecto a las direccionesdeclaseD, se consideran un tipo de clase especial, denominadas clases multicast, que sirven para enviar el trfico denominado punto multipunto. Finalmente, las direccionesdeclaseE estn reservadas para un uso futuro.
Carencia de direcciones IP El reparto de clases A es uno de los causantes de la fuerte carencia de direcciones IP en la actualidad.
Divisin de redes por clases Clase A B C D E Bitsiniciales 0 10 110 1110 11110 BitsRed 7 (+1) 14 (+2) 21 (+3) RangoRed 1.0.0.0-127.0.0.0 128.0.0.0-191.255.0.0 192.0.0.0-223.255.255.0 224.0.0.0-239.0.0.0 240.0.0.0-255.0.0.0
FUOC PID_00147723
33
Direcciones de propsito especfico Aparte de la divisin en redes tambin se destinaron una serie de direcciones de propsito especfico para casos especiales: Direccionesde 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 direccin de red es todo 0. Direccionesdered. 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 direccin del equipo de red est toda en 0. Hay un caso especial, que es la direccin 0.0.0.0, que indica "este host" de "esta red", aunque no siempre se implementa en los sistemas operativos actuales. Direccionesdebroadcast. Indican todos los equipos de una red concreta. La direccin se representa con red.255 para direcciones de clase C. Anlogamente al caso de las direcciones de red, las de clase B sern red.255.255, y las de clase A, red.255.255.255, o sea, que la direccin del equipo de red es todo 1. Siempre que se reciba un datagrama en la direccin de broadcast todos los equipos tienen que responder.
Las direcciones de broadcast, a su vez, tienen una direccin especial, que es la 255.255.255.255, que hace referencia a toda la red (Internet). Entonces, si alguien enviara un datagrama a la direccin 255.255.255.255 toda la Internet tendra que responder. Como eso provocara graves problemas de escalabilidad y exceso de trfico, no hay ningn encaminador que reenve trfico broadcast por sus interfaces. El trfico de broadcast siempre se quedar en la red que lo ha emitido.
Actividad
Dada la direccin IP 120.1.32.54, indicad cul es la direccin de red, la direccin del host y la direccin de broadcast de la red. Solucin La direccin 120.1.32.54 forma parte de las direcciones de clase A, por lo tanto, la direccin de red ser la 120.0.0.0, la del host la 0.1.32.54 y la de broadcast sera la 120.255.255.255.
Direccionesdeloopback. 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, automticamente crea una interfaz virtual (interfaz de loopback) para uso interno del sistema operativo, normalmente slo se utiliza la 127.0.0.1.
Direccionesprivadas. Son las utilizadas por redes locales internas que no salen a Internet. La lista con todos los rangos privados se puede encontrar
FUOC PID_00147723
34
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 ms direcciones a nuestras redes que IP pblicas asignadas por los operadores.
Lista de rangos de direcciones privadas Clase A B C RangoRed 10.0.0.0-10.255.255.255 172.16.0.0-172.31.255.255 192.168.0.0-192.168.255.255 Nmerodesubredes 1 16 255
Network Address Translation El problema principal de las direcciones privadas es que no pueden acceder a Internet directamente, los encaminadores nunca enviarn a Internet el trfico originado o con destino a direcciones privadas, ya que no saben cmo encaminar el salto siguiente. Con el fin de evitar esta limitacin y permitir la transferencia de datos entre direcciones privadas y pblicas, los encaminadores incluyen una tcnica 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 pblica 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 ms equipos que IP asignadas. Un ejemplo de eso es el del usuario con conexin ADSL, que recibe una sola IP por parte de la compaa telefnica, mientras que muchas veces el usuario dispone de diversos equipos, como el PC de sobremesa, el porttil, 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 ms IP (solucin difcil y cara) o utilizar direcciones IP privadas y configurar el encaminador para que haga la conversin desde la direccin IP privada a la IP pblica disponible. Eso se puede conseguir mediante lo que se conoce como NAT. NAT es una tabla de traduccin que se utiliza de la siguiente forma. Si, por ejemplo, un cliente con direccin privada quiere establecer una conexin con un equipo que tiene una direccin IP pblica (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 traduccin, donde transformar la IP origen del datagrama en una IP pblica que tenga reservada a tal efecto. Para completar la traduccin, 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 pblica del encaminador (123.26.1.12) y un puerto asignado dinmicamente (20.543 en el ejemplo). La estacin destino ve un
Referencia bibliogrfica 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 traduccin y deshace el cambio para enviar el paquete final a la estacin 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 pblicas, a pesar de que tiene una serie de inconvenientes que no permiten usarlo en determinados entornos. Primero, hay protocolos de aplicacin (por ejemplo, FTP) que incrustan la IP del cliente dentro del datagrama, esta IP es usada por el servidor para establecer una nueva conexin (por ejemplo, el caso del FTP activo), y como el cliente incrusta la IP privada, eso impide que se pueda establecer la conexin. 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 traduccin antes de poder enviar informacin 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 tcnica denominada Port Address Translation (PAT), en la que el encaminador tiene configurado de forma esttica un mapeado, por lo que cuando llega un datagrama a un puerto concreto, automticamente reenva el paquete hacia el equipo que est configurado con IP privada. En segn qu entornos, el PAT se conoce tambin como Destination NAT (DNAT) o incluso como puerto Forwarding, pero la idea de fondo es la misma.
FUOC PID_00147723
36
Classless inter Domain Routing Una vez definidas las diferentes clases de redes, se vio que esta solucin 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 nmero de direcciones demasiado grande, por lo que se propuso el Classless inter Domain Routing (CIDR).
CIDR propone un mecanismo ms flexible para poder subdividir nuestras redes. CIDR no sustituye la divisin por clases, que continan siendo las unidades bsicas de asignacin de direcciones; por el contrario, CIDR nos permite dividir las direcciones asignadas en subredes ms pequeas y manejables.
As, con CIDR, la separacin entre el equipo y la red se consigue gracias a una mscara. Esta mscara tiene la forma de una direccin IP, que enmascara los bits de una direccin normal para poder distinguir el equipo y la red de forma sencilla.
Ejemplo de mscara Una mscara de 255.255.255.0 permite separar la direccin de red de la del equipo final haciendo AND con la direccin IP, as: 143 255 143 . 45 . 255 . 45 .1 . 255 .1 . 23 .0 .0
De donde se puede extraer la direccin de la subred (los unos de la mscara - 143.45.1) y la direccin del equipo (los ceros de la mscara - 23). En este caso, la red constar de 28 IP vlidas como una clase C, de las que 28 - 2 sern 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 representacin 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 ms fino de divisin que simplificar mucho la gestin 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 direccin de red son correctos, sin que representen direcciones de broadcast y de red, respectivamente. Eso lo podemos saber gracias a la mscara. Una restriccin no escrita, pero generalmente adoptada a la hora de definir las mscaras, es que todos los unos de la mscara tienen que ser consecutivos.
FUOC PID_00147723
37
Mscaras correctas e incorrectas Mscaras como 255.145.0.0 se consideran invlidas, ya que, traducidas a formato binario, dara: 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 restriccin de los unos consecutivos nos permite simplificar la representacin de la mscara en un formato ms compacto; as, otra forma de indicar la separacin entre la red y el equipo es a travs de un formato que indica cuntos bits representan la red, por ejemplo, 143.45.1.23/24 indica que la mquina 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 direccin de red y 8 para la de los equipos. Por otra parte, gracias a la clasificacin por subredes, los encaminadores tienen el trabajo ms fcil, 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 direccin IP. La direccin IP entera, idealmente, slo 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 decisin de direccionamiento en una poltica llamada Longest Prefix Match, lo que significa que, de todas las rutas posibles, siempre se coge la que tiene ms bits coincidentes con el destino del paquete. Actividad
Dentro de las siguientes subredes e IP, indicad cuntas IP asignables puede contener la red y explicad el significado. Direccin 147.83.32.0/24 1.23.167.23/32 1.23.167.0/32 147.83.32.0/16 Solucin Direccin 147.83.32.0/24 IPasignables 254 Explicacin Es una direccin de red en la que tenemos 8 bits para los equipos; sabiendo que la direccin 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 Direccin con una subred con slo un equipo. No es til en un caso real, pero es correcta.
8
IPasignables
Explicacin
FUOC PID_00147723
38
Direccin 1.23.167.0/32
IPasignables 1
Explicacin 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 direccin de red genrica sino una especfica, como en el caso anterior. Hace referencia al equipo 32.0 de la red de clase B 147.83.0.0. Hay que sealar que no es una direccin de red, ya que no todos los bits de fuera de la mscara son 0; as, se trata como una direccin de equipo.
147.83.32.0/16
Actividad
En la direccin de clase B 143.45.0.0/16, indicad qu subredes /20 se pueden crear y cuntos equipos contienen cada una. Solucin
El CIDR se utiliza generalmente en conjuncin con la mscara de subred de tamao variable , tcnica que tiene por objetivo optimizar la utilizacin de las direcciones IP a travs de una asignacin inteligente de las mscaras de red. Esta asignacin se har ahora teniendo en cuenta el nmero de mquinas de cada subred y se asignarn mscaras de tamao ajustado a las necesidades particulares de cada una. VLSM se puede ver como la creacin 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
(4)
En ingls, Variable Length Subnet Mask (VLSM).
FUOC PID_00147723
39
2) Qu problema tiene la asignacin de direcciones hecha en el ejercicio anterior? Solucin 1) La asignacin de direcciones se puede hacer siguiendo la siguiente poltica: Los 20 equipos ms 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 ms. Finalmente, los enlaces punto a punto necesitarn 2 bits, ya que necesitamos espacio para las direcciones de broadcast y de red.
En resumidas cuentas, nos harn falta un prefijo /27, un /28, un /29 y tres prefijos /30 respectivamente. De esta manera, una posible asignacin sera: Los 20 equipos pueden usar la 147.83.85.0/27, donde el ltimo byte sera 000XXXXX. Con direccin de red 147.83.85.0 y direccin de broadcast 147.83.85.31. Los 10 equipos dispondrn de la 147.83.85.32/28 donde el ltimo byte ser 0010XXXX. Con direccin de red 147.83.85.32 y direccin 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 direccin de red 147.83.85.48 y direccin 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 asignacin viene dado por el hecho de que se ha ajustado demasiado el nmero de bits para cada subred, y en el caso de que crezca el nmero de equipos (especialmente en la subred de cinco equipos), nos tocara redimensionar la red de nuevo con el coste que eso supone.
FUOC PID_00147723
40
Tipo de datagramas IP
IPv4 especifica tres tipos de trfico claramente diferenciados dentro de la red: unicast, broadcast y multicast.
El trfico unicast es el ms comn, la comunicacin est formada por dos interlocutores que se intercambian informacin, a menudo estas conexiones son desde un cliente hacia un servidor, que a la vez puede tener conexiones unicast hacia otros clientes. El trficobroadcast se basa en enviar la informacin a todos los equipos presentes en una subred. Como ya hemos visto anteriormente, eso se puede conseguir enviando un paquete a una direccin que sea la direccin de red y todo 1 a la direccin del equipo final, por ejemplo, para la red 126.76.31.0/24, la direccin de broadcast sera 126.76.31.255. Finalmente, el caso del trficomulticast se basa en el paradigma de enviar informacin desde un solo origen hacia muchos destinos a la vez; la base del trfico multicast es que el emisor no tiene por qu tener conocimiento de quines sern sus receptores (al contrario de la poltica de unicast, que requiere conocer a los interlocutores). Eso se consigue a travs 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 estacin 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.
Requisitos del trfico broadcast Hay que sealar, sin embargo, que enviar trfico broadcast normalmente requiere algn privilegio en la red (ser administrador), adems, los encaminadores en general no propagan este tipo de trfico con el fin de evitar problemas de seguridad, como, por ejemplo, ataques del tipo Denial of Service (DoS).
La ventaja principal de multicast es que la informacin que se enva, en vez de replicarse desde el origen una vez por cada destino forma un rbol de manera que se minimiza el nmero de copias.
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 nmero y de qu tipo son las conexiones que tiene abiertas este servidor. Solucin 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 tpico 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 direccin de destino tendra el paquete, cuntos paquetes se generaran y a cuntas mquinas como mximo podra llegar. Solucin Dado que la subred a la que se quiere enviar el broadcast tiene 8 bits, eso implica que se generara un solo paquete con direccin destino 147.83.20.255 y que lo recibiran como mximo 255 - 2 = 253 estaciones. Ya que la direccin 147.83.20.0 y la 147.83.20.255 estn reservadas para la direccin de red y la de broadcast, respectivamente.
El futuro de Ipv4 Cuando se dise IPv4 se crea que su gran nmero de direcciones IP (232) sera 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 aos 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 pases, 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 poblacin mucho ms numerosa, slo dispone de 200 millones, aproximadamente. Para hacerse una idea, Espaa tiene asignadas en la actualidad en torno a 22 millones. Con este paradigma, muy pronto se ve que con la actual poltica para el reparto de direcciones, dentro de muy poco tiempo ya no quedarn direcciones IPv4 disponibles para asignar, lo que implicar inevitablemente que Internet no podr crecer ms. 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 pblica. En la actualidad, pases como China o la India estn haciendo un uso intensivo de la NAT por la falta de direcciones disponibles.
FUOC PID_00147723
42
Como esta solucin no es escalable y comporta una serie muy importante de problemas a los proveedores de servicios se lleg a la conclusin de que los 32 bits de direccionamiento del protocolo IPv4 eran insuficientes, por eso se dise el protocolo IPv6, como veremos a continuacin. 2.3.2. IPv6 La carencia de direcciones IPv4 incentiv el diseo de un nuevo protocolo de red, IPv6. En la actualidad, IPv6 est totalmente desarrollado, aunque todava no es posible utilizarlo dentro de la red comercial, ya que los operadores todava 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 versin y sustituir la anterior es lo que est retrasando su incorporacin en el mbito comercial. Este subapartado describe brevemente este protocolo y destaca sus diferencias con la versin anterior, as como las novedades que incorpora. Para acabar el subapartado, se describen los principales problemas que hay para la migracin de Ipv4 a IPv6. Motivacin Inicialmente, a la hora de disear el protocolo, se pens que no era necesario crear un protocolo entero y que sera suficiente con hacer una adaptacin de IPv. Pero enseguida se vio que, para poder disfrutar de buenas optimizaciones en comparacin con la versin anterior, haran falta bastantes ms cambios. As se opt por un diseo que tiene poco en comn con la versin anterior. El motivo principal que llev a plantearse una nueva versin del protocolo era el limitado rango de direcciones que permite IPv4, que, aunque pueda parecer muy elevado, se vio que sera claramente insuficiente para cubrir la demanda del mercado en un futuro. Sobre todo, la aparicin en los ltimos aos de una gran cantidad de dispositivos mviles que quieren formar parte de la gran red que es Internet ha provocado rpidamente que los 32 bits de direccionamiento IPv4 sea insuficiente, tanto es as que si todos estos dispositivos se quisieran conectar de forma simultnea en la red, los operadores probablemente tendran problemas por la falta de direcciones IPv4. Para ver este problema slo hay que pensar en cuntos telfonos mviles hay en la actualidad; slo en el Estado espaol hay alrededor de 44 millones, mientras que el nmero de IP que hay asignadas actualmente en el pas es de unos 22 millones. Eso, sin contar los usuarios que se conectan desde sus hogares. Cabra pensar que el problema se podra minimizar con la utilizacin de NAT, pero, a la larga, eso puede suponer un grave problema de rendimiento en los encaminadores por tener que mantener las tablas de traduccin de direcciones de millones de conexiones a la vez. Encima, cada vez hay ms pequeas y medianas empresas que quieren ofrecer a sus clientes una serie de servicios que precisan una
Implantacin del protocolo IPv6 Por motivos econmicos no est implantado todava 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 agotarn las que tienen pendientes de asignar en el 2012, lo que seguramente forzar a muchos pases a adoptar prematuramente IPv6. En este sentido, pases como Japn, China, la India y algunos de Amrica del Sur, ya han adoptado el protocolo y utilizan algunas tcnicas que permiten la interoperabilidad de los dos protocolos.
FUOC PID_00147723
43
conexin 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(4bits): indica la versin del protocolo que contiene el paquete. Este campo tiene el mismo significado que el de la versin IPv4, pero ahora con el valor0x06. TrafficClass(8bits): este campo clasifica un paquete dentro de un tipo de trfico determinado, conceptualmente es el equivalente del Type Of Service (TOS) de IPv4. FlowLabel(20bits): sirve para etiquetar un conjunto de paquetes que tengan las mismas caractersticas; servir para poder ofrecer calidad de servicio. PayloadLength(16bits): longitud del payload del paquete, o sea, el paquete sin la cabecera IP. El tamao viene representado en octetos. NextHeader(8bits): este campo es una gran innovacin de IPv6 respecto de IPv4, dado que permite tener una cabecera bsica de tamao fijo. Este campo indica la posicin en que se puede encontrar la siguiente cabecera, ahorrando as tiempo de proceso a los encaminadores intermedios al no haber opciones. HopLimit(8bits): este campo es equivalente del TTL de IPv4, pero cuenta directamente hops y no tiempo. SourceAddress(128bits): direccin del host que ha originado el paquete. DestinationAddress(128bits): direccin 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 ms 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 ms bits para la direccin, la forma de especificar direcciones IPv6 se hace con la notacin de los dos puntos. Donde una direccin IPv6 se representa con bloques de 16 bits representados en hexadecimal y separados por el smbolo ":". Por ejemplo, 2001:0DB8:0000:0000:0319:8A2E:0370:7348. Una simplificacin de esta notacin se puede aplicar en el caso de que una direccin tenga muchos 0 consecutivos; la forma abreviada de representarla es utilizando "::"; as, la forma compacta de representar la direccin anterior sera: 2001:0DB8::0319:8A2E:0370:7348. Otra diferencia notable entre IPv4 e IPv6 es la jerarquizacin de las direcciones. La asignacin de direcciones IPv4 se hizo, en su tiempo, de una forma muy anrquica, dado que no se esperaba que el crecimiento de Internet fuera tan espectacular. Actualmente, cada corporacin u operadora de telefona tiene rangos de direcciones muy dispersos y mal dimensionados, lo que hace extremadamente difcil la gestin de las direcciones disponibles, la asignacin de las nuevas y el direccionamiento global. Por eso, lo que ha hecho IPv6 ha sido jerarquizar de una forma ms inteligente el reparto de sus direcciones, de forma que cada pas, operador o ISP, dispone de un rango concreto con un nmero de direcciones proporcional a su posible utilizacin de la red. Independientemente de la mejora de esta jerarqua en cuanto a localizacin geogrfica, el hecho de separar de esta manera las direcciones permite asignar nuevas de una forma mucho ms sencilla que hasta ahora.
FUOC PID_00147723
45
De forma parecida a IPv4, se puede identificar qu tipo de direccin es slo con el prefijo de la direccin IPv6, como indica la siguiente tabla.
Asignacin de direcciones Prefijo 0000::/8 Espaciodeasignacin Reservado. Las direcciones de loopback y las direcciones con integracin de IPv4 salen de este prefijo Reservado Reservado Reservado Reservado Reservado Direccin unicast global. De aqu sale el rango de direcciones 125 que se repartirn a los usuarios. Hay 2 direcciones disponibles. Reservado Reservado Reservado Reservado Reservado Reservado Reservado Reservado Direccin unicast local nica Reservado Direccin de enlace local unicast (link-local) Reservado Direcciones multicast
0100::/8 0200::/7 0400::/6 0800::/5 1000::/4 2000::/3
4000::/3 6000::/3 8000::/3 A000::/3 C000::/3 E000::/4 F000::/5 F800::/6 FC00::/7 FE00::/9 FE80::/10 FEC0::/10 FF00::/8
Un hecho muy interesante que se consider para hacer esta asignacin de direcciones es que da la posibilidad de representar direcciones de diversas tecnologas incrustadas dentro de la nueva versin 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 direccin Ethernet de un equipo dentro de un IPv6 el prefijo LAN es FE80::/10. Por tanto, si la direccin de la tarjeta Ethernet es 00:90:F5:0C:0F:ED, entonces, la direccin IPv6 queda as: FE80::0090:F50C:0FED. Como se puede observar, el pro-
FUOC PID_00147723
46
ceso tambin 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 direccin local (link local) y se puede extraer la direccin hardware fcilmente. Adems, con este mecanismo, cualquier interfaz de red puede configurarse de forma automtica y autnoma.
Hay que sealar que IPv6, aparte de tener direcciones unicast, broadcast y multicast, como IPv4, aade soporte para un cuarto tipo, que son las direcciones anycast.
Las direcciones anycast son una gran innovacin de IPv6, sobre todo porque aprovechan las direcciones unicast ya existentes. As, una direccin unicast se vuelve anycast desde el momento en que se asigna una misma IPv6 a ms de una interfaz (incluyendo equipos diferentes). La idea que hay detrs de esta implementacin es que responda a las peticiones de un servicio concreto la estacin ms prxima.
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 ms cerca del equipo que hace la peticin. Actualmente, por complejidades en la implementacin de este tipo de direcciones, slo se utilizan para encaminadores. As, una subred puede tener ms de un encaminador para salir a Internet usando el mismo prefijo, y cada equipo utiliza el que est ms prximo a la estacin, que consigue de forma sencilla un sistema de balanceo de carga.
Otra innovacin relevante que incorpora IPv6 es la utilizacin mucho ms intensiva del trfico 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 generacin de trfico 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 gestin ms simple de las cabeceras por parte de los dispositivos que tienen que tratar el paquete hasta que llega a su destino, permitiendo un sistema ms simple y flexible. Direccionesdeautoconfiguracin: la asignacin dinmica 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 aadir la direccin hardware dentro de la direccin IPv6; as, slo con un prefijo dado por el dispositivo de direccionamiento ms prximo y con la direccin hardware se garantiza una direccin nica a escala mundial. Siempre
FUOC PID_00147723
47
que se utilice el prefijo asignado por el operador a la hora de generar la direccin. Facilidadparalaasignacinderecursos: lo que con IPv4 era el Type of Service ahora se llama Traffic Class, aunque tambin se tiene la posibilidad de marcar flujos individuales, lo que da mucha ms flexibilidad a la hora de marcar trfico prioritario. Capacidadesdeseguridad: como la seguridad, hoy da, es un tema tan importante, IPv6 incluye caractersticas de autenticacin y privacidad. Por defecto, IPv6 incluye funcionalidades nativas para la creacin de redes privadas virtuales (VPN, en la abreviatura en ingls) a travs 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 direccin link-local y la direccin de autoconfiguracin de este equipo. Solucin La direccin link-local vendr dada por el prefijo link-local, as la direccin ser: FE80::3427:A46F:AE53. Mientras que la direccin de autoconfiguracin sale del prefijo y del MAC, por lo tanto: 2001:0A54:0039::3427:A46F:AE53.
Problemas de la migracin en IPv6 Uno de los motivos principales por los que todava se trabaja con IPv4 es la dificultad que comporta la migracin al nuevo protocolo. La incompatibilidad de las direcciones y de las cabeceras de ambos protocolos hace que la actualizacin a la nueva versin no sea fcil. Tambin hay que tener en cuenta que las aplicaciones existentes slo soportan el sistema de direcciones de IPv4, que para aceptar las nuevas direcciones se tiene que cambiar el cdigo de la aplicacin, y tambin todos los llamamientos al sistema de acceso a la red. Aparte del nivel de aplicacin, 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 econmico y de tiempo que eso supone, cosa que muchas de las empresas no estn dispuestas a aceptar (especialmente las grandes corporaciones estadounidenses, que son las que tienen suficientes direcciones). Por ltimo, a causa de la gran utilizacin que se hace actualmente de Internet, es un gran problema tener que parar todas las redes para hacer la migracin. As, el problema que se encuentra es el enorme gasto econmico para las em-
FUOC PID_00147723
48
presas que controlan todas sus transacciones a travs de la red, lo que fuerza a hacer la migracin de forma progresiva, transparente para los usuarios y sin dejar de ofrecer los servicios disponibles en ningn momento. Mecanismos para asistir la transicin La migracin entre dos protocolos cuando uno se est utilizando masivamente es extremadamente compleja. Como hemos visto, las razones, normalmente, son econmicas, ya que la gran mayora de las aplicaciones actualmente slo soportan IPv4, y migrarlas a la nueva versin 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 configuracin correcta, ni la asignacin 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 disear un plan de migracin controlado. As, los diferentes mecanismos de transicin se pueden dividir en dos grandes grupos: mecanismos bsicos y mecanismos para la interconexin de islas. En cuanto a los mecanismos bsicos, se pueden distinguir dos, el conocido como Dual-Stack, en el que los equipos utilizan simultneamente los dos protocolos y se conectan con el que ms se ajuste a las necesidades del momento, y el de Tunneling, en el que dos equipos con Dual-Stack crean un tnel IPv4 entre ellos, y por dentro del tnel se comunican con IPv6. Hay que sealar que un tnel 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 tnel a travs 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 mquinas interconectadas a travs 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 tambin estn basados principalmente en tneles. Se pueden distinguir los siguientes tipos:
FUOC PID_00147723
49
Tnelesconfigurados: los extremos de los tneles entre las islas se configuran de forma manual entre las dos redes. Los extremos tienen que ser dual-stack.
Tneles automticos: 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 direccin 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.
TnelBroker: se utiliza un broker (gestor), que indica al cliente un script con el fin de hacer el tnel de forma automtica. El cliente tiene que ser dual-stack, ya que la peticin en el broker va con IPv4, que contesta con un script que permite conectar a un Tunnel-Server (que tambin es dual-stack) al que permite conectarse a la red IPv6.
6to4: se asigna una direccin IPv4 compatible con el prefijo IPv6 en los encaminadores, los cuales hacen un tnel. Por ejemplo, para la red 2001:d002:0507::/48 el encaminador tendra la direccin 208.2.5.7 (que sale de d002:0507). En el otro extremo se hara la operacin anloga y se establecera el tnel.
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 sera 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 comprensin, 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 conexin que tiene por objetivo el envo de informacin independientemente de la tecnologa de niveles inferiores utilizada. Eso proporciona un entorno ideal para poder comprobar el estado de la red, o enviar informacin 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 congestin en un enlace, o bien a un paquete se le ha expirado el TTL. Todas estas situaciones requieren de algn protocolo, que trabajando en la misma capa que IP permita avisar de forma automtica de cualquiera de estos eventos. Por eso se dise el Internet Control Message Protocol (ICMP).
FUOC PID_00147723
50
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.
Descripcin de los diferentes mensajes ICMP Mensaje Destinationunreachable Descripcin Indica que no se puede llegar al destino. Este mensaje tiene un campo de cdigo que indica si es culpa de la red, del equipo en particular o bien del puerto. Tambin distingue si no se puede llegar al destino o bien si el destino es desconocido. Estos dos mensajes son el de peticin y el de respuesta, cuando una estacin 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 aplicacin por excelencia que utiliza los echo request/reply es el ping. Este paquete sirve para regular, indica que aquel enlace est sufriendo congestin. Actualmente este tipo de paquete no se utiliza porque el control se hace mayoritariamente en la capa de transporte. Este paquete de ICMP se enva a una direccin multicast donde todos los encaminadores escuchan por defecto. Con este mensaje es posible descubrir automticamente la existencia de nuevos encaminadores en la red. 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. 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. 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.
Bibliografa Para una descripcin ms completa de todos los tipos de mensajes existentes con ICMP se puede consultar el documento RFC-792.
Echorequest/Echoreply
Sourcequench
Routeradvertisement
Routerdiscovery
TTLexpired
IPheaderbad
Los mensajes ICMP tienen varias utilidades, desde reportar errores hasta depurar el estado de la red. Una de las herramientas ms 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 depuracin 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 enva 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 enva de vuelta un paquete ICMP de TTL expired. Ahora slo hace falta que la aplicacin mire a quien ha enviado este
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 despus con el tercero, y as sucesivamente hasta el destino. 2.4.2. Address Resolution Protocol Para enviar un datagrama IP a una estacin de la misma red que el emisor es necesario descubrir qu direccin del nivel del enlace de datos tiene esta estacin, ya que las tecnologas de capas inferiores no entienden qu es una direccin IP. As pues, para que la IP funcione necesita interactuar con las capas inferiores y descubrir de forma automtica cul es la direccin de enlace de datos a la que responde un equipo para poder intercambiarse informacin. El protocolo Address Resolution Protocol (ARP) fue diseado especficamente para IPv4, y como veremos ms adelante, para IPv6 existe el Network Discovery Protocol. Para conseguir el descubrimiento de la direccin 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 direccin 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 envo de un paquete IP Direccin de nivel de enlace La direccin de nivel de enlace es conocida como direccin MAC y viene dada por los dispositivos de red. Cada dispositivo de red tiene una direccin MAC nica.
El proceso de ARP, ilustrado en la siguiente figura con un ejemplo, sigue una serie de pasos con el fin de descubrir la direccin. Lo primero que se tiene que conseguir es la direccin MAC del siguiente salto, por eso se enva un paquete ARP a la direccin de broadcast de nuestra red local. Este ARP buscar la IP del destino o bien la del encaminador dependiendo de si la estacin forma
FUOC PID_00147723
52
parte de la subred o no. Una vez se obtiene la direccin MAC, se construye un paquete que tiene como direccin MAC destino la obtenida por ARP y como IP destino la original (o sea, en el caso de que se enve el paquete al encaminador, esta IP ser la del destino final, no la del encaminador).
Ejemplo de peticin por ARP
RARP Hemos visto que ARP nos sirve para poder descubrir qu direccin MAC corresponde a una IP, tambin hemos visto la importancia de esta operacin. Por complecin, ARP tiene una variante denominada RARP, que nos permite realizar la operacin inversa, o sea, desde una direccin 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 relacin 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 ms funcionalidades como veremos a continuacin.
2.4.3. Network Discovery Protocol ARP es un protocolo que fue diseado especficamente para IPv4; con los avances de las redes hasta hoy ha probado que es insuficiente para segn qu servicios. Por eso, con la aparicin de IPv6, se decidi que haca falta un protocolo ms 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 utilizbamos con IPv4, ahora se envan neighbour solicitations y se reciben neighbour advertisements. Sin embargo, la gran diferencia con ARP es que se utiliza trfico multicast en vez de broadcast. Y que NDP forma parte de un protocolo mayor llamado ICMPv6, que es la extensin 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 direccin multicast Solicited-Node de una estacin se construye de la siguiente manera: se cogen los ltimos tres octetos de la direccin unicast y se aade al principio el prefijo multicast FF02::1:FF00:0000/104. Por ejemplo, la direccin multicast Solicited-Node para 2001:630:1310:FFE1:02C0:4EA5:2161:AB39 sera la FF02::1:FF61:AB39. Entonces, la estacin se pone a escuchar al grupo multicast para responder con la direccin hardware del equipo al que va dirigida la peticin. 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 reduccin 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 aplicacin. 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 informacin de la configuracin de los parmetros de red por un equipo IPv4 de forma automtica. El administrador de la red configura un prefijo de red, conjuntamente con un subrango de direcciones destinadas a autoconfiguracin (este rango de direcciones se llama pool). Cuando se recibe una peticin, 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 direccin hardware del equipo, o bien una al azar del pool si la direccin hardware no se encuentra. Esta cesin 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 informacin. Entrando en un poco ms 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 enva 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 duracin de la IP y la configuracin especfica 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 comunicacin entre dos mquinas, estableciendo diferentes rutas o caminos entre ellas. Cada ruta de comunicacin est formada por una serie de enlaces, que conectan la mquina origen con la de destino utilizando unos dispositivos encaminadores intermedios. Cuando un datagrama del nivel de red sale de la mquina origen hacia la mquina destino, va atravesando cada uno de estos enlaces individuales que conforman el recorrido extremo a extremo. Se hace necesaria una capa lgica adicional situada inmediatamente bajo la capa de red, que se ocupe de suministrar a sta un transporte de informacin fiable entre los diferentes enlaces que atraviesa a lo largo de un recorrido. Esta capa recibe el nombre de nivel de enlace, y se sita por encima de la capa fsica. La capa fsica no es capaz de aportar ninguno de los elementos necesarios para la transmisin efectiva de informacin en un enlace.
El niveldeenlace 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 informacin que se intercambian, y un conjunto de reglas de comportamiento o protocolos necesarios para la transmisin de datos.
El principal cometido de la capa de enlace es conseguir que la comunicacin de datos en un enlace se realice correctamente a travs de un medio fsico de transmisin. De una forma grfica, podemos decir que el nivel de enlace se encarga de establecer y mantener un puente de comunicacin entre dos nodos vecinos, para que por encima puedan circular los datagramas de nivel superior.
Ruta de comunicacin creada entre dos mquinas finales, formada por 5 enlaces: 2 enlaces comunican las mquinas finales con los routers de la red y 3 enlaces internos intercomunican slo routers de la red.
FUOC PID_00147723
55
De la observacin de la figura anterior, podemos destacar dos caractersticas muy importantes del nivel de enlace: Los enlaces, a lo largo de un recorrido de comunicacin, pueden utilizar diferentes protocolos de la capa de enlace y estar constituidos por tecnologas 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 cmo un datagrama enviado desde la mquina origen es manejado por Ethernet en el primer enlace, por el protocolo ATM en el segundo enlace, y va cambiando de tecnologa sucesivamente en cada nuevo enlace. Una de las funcionalidades bsicas del nivel de enlace consiste en encapsular/desencapsular los datagramas de la capa de red en PDU de informacin de la capa de enlace, tambin llamados tramas. Observemos las flechas de la figura que indican el flujo que sigue la informacin 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 enva al enlace. Aqu el datagrama es encapsulado segn las normas del protocolo de este enlace y preparado para ser enviado.
5 (5)
PDU son las siglas de Protocol Data Unit.
3.1. Terminologa y definiciones
El nodo es la mquina o encaminador. El enlace es el canal que conecta dos nodos adyacentes al recorrido de la comunicacin. El protocolo delacapadeenlace 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 envan 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.
FUOC PID_00147723
56
3.2. Tipo de enlaces Bsicamente podemos destacar dos tipos de enlaces: Enlacesdecomunicacinpuntoapunto. Slo 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 telefnico 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 adems extremo-a-extremo).
Enlacesbroadcastocanalesdemultidifusin. Son enlaces 1 a N, donde una serie de nodos estn conectados al mismo canal de comunicacin. La transmisin realizada por un nodo la reciben todos los nodos conectados al enlace. Se hacen necesarias unas polticas de coordinacin (o protocolos de acceso al medio) que permitan la comparticin del nico medio de forma eficiente, tratando de evitar al mximo 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 satlites. Las redes de acceso hbrido 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: Servicionoorientadoaconexinysinacusederecibo. El envo se hace sin esperar ninguna indicacin del receptor sobre el xito o fracaso de la operacin. Tampoco se establece o libera una conexin. Este tipo de servicio es apropiado cuando la tasa de error es muy baja (redes locales o fibra ptica) y se deja la misin de comprobar la correccin de la transmisin a las capas superiores (nivel de red o de transporte). Tambin se usa el servicio no confirmado cuando se quiere transmitir informacin en tiempo real (tpicamente voz o datos) y no se quiere sufrir el retardo que impondra un servicio ms sofisticado en la capa de enlace (se supone que este tipo de informacin puede sufrir una pequea tasa de error sin efecto apreciable).
FUOC PID_00147723
57
Servicionoorientadoaconexinconacusederecibo. Se produce un acuse de recibo para cada trama enviada, aunque todava no hay establecimiento d conexin. De esta manera el emisor puede estar seguro de que ha llegado.
Servicioorientadoaconexinconacusederecibo. Es el ms seguro y sofisticado. El emisor y el receptor establecen una conexin explcita 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 conexin se pueden distinguir tres fases: establecimiento de la conexin, envo de los datos, y finalizacin de la conexin. En la primera se disponen los contadores y memorias temporales necesarios para la transmisin, en la segunda se envan 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 bsico del nivel de enlace consiste en mover correctamente un datagrama de nivel de red, desde un nodo hasta otro adyacente sobre un enlace de comunicacin fijando en el recorrido. Los posibles servicios que puede ofrecer un protocolo de la capa de enlace son: Gestindelastramas. El nivel de enlace se encarga de la organizacin y gestin de las tramas. Entramado o composicin de la trama. Sincronizacin a nivel de trama. Transparencia de trama. Numeracin y secuenciacin (nmeros de secuencia). Direccionamiento: si existe ms de un posible destino de un mensaje es necesario identificarlo perfectamente. Gestin del enlace. Todo el proceso de inicio, mantenimiento y finalizacin de la transmisin requiere un considerable esfuerzo de gestin y coordinacin. Controldeflujo. La estacin emisora y la receptora se tienen que poner de acuerdo sobre el ritmo de transmisin de datos. Si la estacin receptora recibe las tramas ms rpidamente 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. Controldeerrores. Se trata de una de las funciones bsicas del nivel de enlace. Se asume que el medio de transmisin subyacente no es perfecto e introduce errores de transmisin. Es necesario destinar una parte de los bits que se intercambian a la deteccin y la posterior gestin de los errores,
FUOC PID_00147723
58
para controlar que no se produzcan errores de transmisin. En el control de errores se distinguen tres conjuntos de tcnicas: Deteccin de errores. Utilizacin de cdigos detectores de errores eficientes. Correccin de errores, si se utilizan cdigos correctores adecuados. Retransmisin de tramas errneas (entrega fiable).
Controldeaccesoalmedio. Esta funcionalidad cobra relevancia en los enlaces de acceso mltiple o broadcast, donde un nmero determinado de nodos comparten el mismo medio fsico. 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 transmisin 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 travs de un adaptador, conocido como tarjeta de interfaz de red o Network Interface Card (NIC). Fsicamente, un adaptador es una placa hardware (una tarjeta PCMCIA o un dispositivo conectado al puerto USB) que contiene todos los elementos de un pequeo computador: memoria RAM, chip DSP, una interfaz de bus con la mquina, y una interfaz de enlace. Normalmente se encuentra alojado en la misma capa fsica que el resto del nodo, comparte la alimentacin 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 autonoma: Enrecepcin: 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. Entransmisin: 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 comunicacin. 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 informacin de control entre el adaptador y el nodo padre. La interfaz del enlace es responsable de implementar el protocolo de la capa de enlace. Tambin incluye el hardware de transmisin y recepcin. El protocolo de la capa de enlace est, mayoritariamente, implementado en este adaptador. Si el protocolo de la capa de enlace proporciona deteccin de errores, entrega fiable (numeracin y reconocimientos) o acceso aleatorio (adems de enmarcar y quitar el marco de datagramas), entonces estas funcionalidades estn implementadas completamente en los adaptadores.
FUOC PID_00147723
60
4. El nivel fsico
Para acabar este mdulo, estudiaremos la ltima capa del modelo OSI6. El nivel fsico caracteriza la seal y su modulacin, as como describe los medios de transmisin fsicos. En este mdulo no entraremos en los fundamentos matemticos de la modulacin y de la seal. Simplemente tenemos que saber que la informacin binaria se puede transmitir por un medio a travs de las variaciones de alguna propiedad fsica, habitualmente, el voltaje o la intensidad. Podemos representar el valor de esta magnitud fsica como una funcin dependiente del tiempo. Dada esta funcin en forma de onda, podemos codificarla para transmitir la informacin que queremos. Este es el fundamento de la transmisin de informacin a travs de un medio y sobre el que se basa toda la teora de la comunicacin. 4.1. Medios de transmisin Existen varios medios de transmisin en funcin de su ancho de banda, retardo, coste, facilidad de uso, instalacin y mantenimiento. Los medios se pueden clasificar en medios guiados (par de hilos, fibra ptica) o no-guiados (ondas de radio, lser a travs del aire). Los siguientes factores de un medio de transmisin determinan la velocidad mxima de transmisin y la distancia mxima del medio: Anchodebanda. Al aumentar el ancho de banda se puede aumentar la velocidad de transmisin. Atenuacin. 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. Nmerodereceptores. Atenan y distorsionan la seal que supone una menor distancia.
(6)
OSI es la abreviatura de Open Systems Interconnection; en castellano, interconexin de sistemas abiertos.
4.1.1. Par trenzado Se trata del sistema ms antiguo y todava es muy utilizado en la actualidad. Consiste en dos pares de hilos de cobre o de acero cubierto con cobre, aproximadamente de un milmetro de dimetro cada uno, que estn envueltos entre s en forma de hlice, como una molcula de ADN.
FUOC PID_00147723
61
Se puedem utilizar tanto en las transmisiones digitales como en las analgicas. El ancho de banda que ofrecen depende del grueso del cable y de la distancia. Es un sistema muy utilizado en los sistemas de telefona. Generalmente, los telfonos de las viviendas estn conectadas con la centralita telefnica a travs de pares trenzados (su ancho de banda es de 4 KHz). Tambin 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 geogrfico 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 ms dentro de una proteccin de plstico. Este tipo de cable se llamaba de categora 3. Despus se introdujeron los cables de categora 5, agrupamientos con ms densidad por centmetro de vueltas en el cable, que ofrecan unas caractersticas de mayor calidad sobre largas distancias.
Par trenzado no apantallado (UTP)
Coste del par trenzado Debido a su bajo coste y su rendimiento, es un sistema muy popular. El coste es el ms econmico (ms que el coaxial o la fibra ptica) por metro, pero tiene unos costes de conectividad parecidos a los de otros medios.
Despus vino la evolucin al tipo de cableado Shielded Twisted Pair (STP), llamado par trenzado apantallado, donde cada par de hilos tiene una proteccin individual.
Par trenzado apantallado (STP)
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 ms largas pero con velocidades de transmisin ms bajas. Este tipo de cable se ha utilizado para interconectar los equipos de las centrales telefnicas, para alguna red de rea local o para la televisin por cable. Es ms econmico que la fibra ptica y ms 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 transmisin 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 transmisin es una fibra ptica muy fina. El detector genera un impulso elctrico 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 transmisin unidireccional que acepta seales elctricas, las convierte en impulsos de luz que se transmiten y se reconvierten en una seal elctrica 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 transmisin es muy elevada, llegando a varios Gbps en 30 km de distancia.
FUOC PID_00147723
63
Fibra ptica
FUOC PID_00147723
64
Resumen
En este mdulo se han visto en detalle las caractersticas y el funcionamiento de los diferentes niveles de la red. El objetivo del mdulo ha sido dar una visin general del funcionamiento interno de una red de computadores, ya de rea local, ya a gran escala, como es Internet. La aproximacin a los niveles de la red se ha hecho desde los niveles ms prximos a las aplicaciones hasta los niveles ms especficos 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 transmisin, la red. Se ha visto que el funcionamiento de la red se rige en gran medida por el protocolo TCP, que es orientado a conexin y ofrece garantas de fiabilidad en la red. Para aplicaciones que no requieren garantas 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 problemtica actual con el nmero de direcciones en la red. Se ha presentado la capa de enlace que abstrae los nodos de la red del medio fsico sobre el que transmiten la informacin. Se ha visto que esta capa se encarga de dirigir la informacin entre nodos fsicos adyacentes y garantizar transmisin fiable entre ellos. Hay que destacar la tarea de la subcapa de control de acceso al medio que permite transmitir informacin entre dos nodos independientemente de la tecnologa de red utilizada, ya sea inalmbrica o cableada. Finalmente, se ha hecho una breve introduccin al nivel fsico que se encarga de los aspectos de modulacin y codificacin de las seales fsicas que son dependientes directamente de la tecnologa y el medio de transmisin. Se han visto los principales medios de transmisin.
FUOC PID_00147723
65
Bibliografa
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 (nm. 1, pg. 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: <http://www.iana.org/assignments/multicast-addresses>. [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
PID_00147721
FUOC PID_00147721
Seguridad en la red
FUOC PID_00147721
Seguridad en la red
ndice
Introduccin............................................................................................... Objetivos....................................................................................................... 1. Cortafuegos.......................................................................................... 1.1. 1.2. Sistemas cortafuegos ................................................................... Construccin de sistemas cortafuegos ........................................ 1.2.1. 1.2.2. 2. Encaminadores con filtrado de paquetes ...................... Pasarela en el mbito de aplicacin ..............................
5 7 9 10 11 11 13 16 16 17 20 22 24 26 29 32 34 34 37 38 39 40 40 42 42 43 43 44 44 45 46 46 47 49 50
Redes privadas virtuales.................................................................. 2.1. 2.2. Definicin y tipo de redes privadas virtuales ............................. Configuraciones y protocolos utilizados en VPN .......................
3.
Introduccin a la criptografa....................................................... 3.1. Criptografa de clave simtrica ................................................... 3.1.1. 3.1.2. 3.1.3. 3.1.4. 3.2. 3.2.1. 3.2.2. 3.2.3. Algoritmos de cifrado de flujo ...................................... Algoritmos de cifrado de bloque ................................... Uso de los algoritmos de clave simtrica ....................... Funciones hash seguras .................................................. Algoritmos de clave pblica .......................................... Uso de la criptografa de clave pblica .......................... Infraestructura de clave pblica ....................................
Criptografa de clave pblica ......................................................
4.
Certificados digitales........................................................................ 4.1. 4.2. Cadenas de certificados y jerarquas de certificacin ................. Listas de revocacin de certificados ............................................
5.
Seguridad en la red........................................................................... 5.1. 5.2. Cookies ........................................................................................ Contenidos activos ...................................................................... 5.2.1. 5.2.2. 5.2.3. 5.2.4. 5.2.5. 5.3. 5.4. 5.3.1. 5.4.1. Applets ........................................................................... Servlets/JSP ..................................................................... CGI ................................................................................. ASP/PHP ......................................................................... RIA .................................................................................. PGP ................................................................................. Caractersticas del protocolo SSL/TLS ............................
Protocolos de seguridad .............................................................. SSL ...............................................................................................
FUOC PID_00147721
Seguridad en la red
5.4.2. 5.5. 5.5.1. 5.5.2.
El transporte seguro SSL/TLS ......................................... Secure Electronic Transaction ........................................ 3D-Secure .......................................................................
52 58 58 59 60 63
Transacciones seguras en red ......................................................
FUOC PID_00147721
Seguridad en la red
Introduccin
La seguridad en la red es un aspecto de primordial importancia. Cada da aparecen nuevas aplicaciones remotas o en red; estas aplicaciones almacenan la informacin en hardware remoto y requieren intercambios de datos constantes entre nuestros ordenadores personales y los servidores remotos. Todo este flujo de informacin hace necesaria la existencia de mecanismos para evitar el uso malicioso de la informacin y asegurar la privacidad y proteccin de los usuarios de la red. A la hora de proteger las redes de comunicaciones, la criptografa es la herramienta fundamental que nos permite evitar que alguien intercepte, manipule o falsifique los datos transmitidos. Dedicaremos una parte de este mdulo a introducir los conceptos de la criptografa necesarios para entender cmo se aplica a la proteccin de las comunicaciones. La finalidad bsica de la criptografa es el envo de informacin secreta. Si aplicamos una transformacin, conocida como cifrado, a la informacin que queremos mantener en privado, aunque un adversario consiga ver qu datos estamos enviando le sern completamente ininteligibles. Slo el destinatario legtimo ser capaz de hacer la transformacin inversa y recuperar los datos originales. En el mdulo tambin estudiaremos los sistemas cortafuegos que se encargarn de proteger el acceso a determinados puntos de la red. Veremos que un sistema cortafuegos acta 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 mquinas internas de una red denegando peticiones de conexin desde partes no autorizadas. Por otra parte veremos tambin que existen redesprivadasvirtuales que se construyen haciendo uso de los nodos de una red, pero que, mediante tcnicas criptogrficas y protocolos seguros, permiten aislar a los usuarios de esta red de los de la red de comunicacin. Finalmente haremos una pasada por los diferentes protocolos y aplicaciones ms relevantes para asegurar las redes de comunicaciones. Conoceremos las cookies, los contenidos dinmicos y cmo 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
FUOC PID_00147721
Seguridad en la red
en red y a sus protocolos. En este mdulo tambin conoceremos el funcionamiento de estos protocolos y, de paso, cmo se pueden hacer transacciones seguras en la red.
FUOC PID_00147721
Seguridad en la red
Objetivos
El estudio de este mdulo os permitir alcanzar los objetivos siguientes:
1. Conocer los principales mecanismos de seguridad en la red. 2. Conocer los fundamentos de la criptografa y los certificados digitales. 3. Tener una visin global de los elementos de la red que pueden precisar mecanismos de seguridad y conocer los posibles puntos dbiles de una red de computadores.
FUOC PID_00147721
Seguridad en la red
1. Cortafuegos
Cuando un equipo est conectado a una red de computadores se pueden identificar tres reas de riesgo: 1) El nmero 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 conexin), un requisito necesario para ser atacado es forzosamente la existencia de un acceso fsico al equipo. Pero en el caso de un sistema en red, cada uno de los equipos que pueda enviar informacin hacia la vctima podr ser utilizado por un posible atacante. Algunos servicios (como por ejemplo web y DNS) necesitan estar abiertos pblicamente, de forma que cualquier equipo conectado a Internet podra 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 expansin del permetro fsico del sistema telemtico al que acaba de ser conectado el equipo. Cuando la mquina 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 estn realmente bien protegidos contra actos de modificacin, eliminacin, observacin maliciosa, etc., ya que se transfieren entre diferentes componentes de confianza. Pero esta misma premisa no es cierta cuando los datos son transferidos a travs de una red. La informacin transmitida por el medio de comunicacin es reenviada por dispositivos que estn totalmente fuera del control del receptor. Esta informacin podra ser leda, almacenada, modificada y ms tarde retransmitida hacia el receptor legtimo. Especialmente en grandes redes como Internet, no es trivial la autenticacin del origen que se presenta como el emisor de un mensaje. 3) Finalmente, la tercera rea de riesgo se debe al aumento del nmero de servicios de autenticacin (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 programacin o de diseo) 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.
FUOC PID_00147721
10
Seguridad en la red
La prevencin 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 bsica es separar nuestra red (donde los equipos que intervienen son de confianza) de los equipos del exterior (potencialmente hostiles). Un sistema cortafuegos acta 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 mquinas internas de nuestra red denegando peticiones de conexin 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 mayora de los casos, los sistemas cortafuegos se utilizan para prevenir accesos ilcitos al interior de la red.
(1)
En ingls, firewall.
Un cortafuegos es aquel sistema de red expresamente encargado de separar redes de computadores y efectuar un control del trfico existente entre ellas. Este control consiste, en ltima instancia, en permitir o denegar el paso de la comunicacin 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 trfico 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 fsicamente todo el acceso al interior de la red a travs del sistema. 2) Slo el trfico autorizado, definido en las polticas 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 garantas de seguridad.
FUOC PID_00147721
11
Seguridad en la red
1.2. Construccin de sistemas cortafuegos En el sentido ms 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 tecnologas ms utilizadas a la hora de construir sistemas cortafuegos son las siguientes: Encaminadores con filtrado de paquetes. Pasarelas en el mbito de aplicacin.
1.2.1. Encaminadores con filtrado de paquetes
Un encaminador con filtrado de paquetes es un dispositivo que encamina el trfico TCP/IP (encaminador de TCP/IP) sobre la base de una serie de reglas de filtrado que deciden qu paquetes se encaminan a travs de l y cules 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 trfico de datos legtimo entre ambas partes. Los encaminadores con filtrado de paquetes, al trabajar a nivel de red, pueden aceptar o denegar paquetes fijndose 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 (segn el protocolo). Contenido de los paquetes. Tamao del paquete.
(2)
UDP es la abreviatura de User Datagram Protocol.
FUOC PID_00147721
12
Seguridad en la red
Las reglas estn organizadas en conjuntos de listas con una determinada poltica 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 accin indicada en la regla (denegar, aceptar, redirigir...). Por el contrario, si no es posible ninguna coincidencia, se consultar la poltica por defecto para saber qu accin tomar (dejar pasar el paquete, descartarlo, redireccionarlo, etc.). Si se trata, por ejemplo, de una poltica de denegacin por defecto, en el caso de no existir ninguna coincidencia con el paquete ser descartado ste. Una poltica de denegacin por defecto acostumbra a ser ms costosa de mantener, ya que ser necesario que el administrador indique explcitamente todos los servicios que tienen que permanecer abiertos (el resto, por defecto, sern todos denegados). En cambio, una poltica de aceptacin por defecto es ms sencilla de administrar, pero incrementa el riesgo de permitir ataques contra nuestra red, ya que requiere que el administrador indique explcitamente qu paquetes hay que descartar (el resto, por defecto, sern todos aceptados). Ventajas y desventajas de los encaminadores con filtrado de paquetes La construccin de un sistema cortafuegos mediante un encaminador con filtrado de paquetes es realmente econmica, ya que generalmente se suele hacer con hardware ya disponible. Adems, ofrece un alto rendimiento a redes con una carga de trfico elevada. Adicionalmente, esta tecnologa permite la implantacin de la mayor parte de las polticas de seguridad necesarias.
Iptables Un ejemplo de encaminador con filtro de paquetes podra ser la aplicaciniptables, implementada como una parte del software de direccionamiento del kernel Linux.
FUOC PID_00147721
13
Seguridad en la red
Las polticas 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 prctica las ideas o filosofas de la empresa en cuanto a seguridad) o de manera formal (utilizando un modelo matemtico 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 mayora 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 difcil saber si el propio encaminador est siendo atacado. Su capacidad de actuacin puede llegar a deteriorarse a causa de la utilizacin de un filtrado excesivamente estricto, dificultando tambin el proceso de gestin del dispositivo si este nmero 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 configuracin sean aprovechados por un atacante para realizar una violacin de la poltica de seguridad.
1.2.2. Pasarela en el mbito de aplicacin Una pasarela en el mbito de aplicacin, conocida tambin como servidor intermediario , no direcciona paquetes a nivel de red sino que acta como retransmisor en el mbito de aplicacin. Los usuarios de la red contactarn con el servidor intermediario, que a su vez estar ofreciendo un servicio proxy asociado a una o ms aplicaciones determinadas.
3 (3)
En ingls, proxy.
FUOC PID_00147721
14
Seguridad en la red
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 haba iniciado la conexin. As, el servicio proxy ejecutado en la pasarela aplicar las normas para decidir si se acepta o se rechaza una peticin de conexin. 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 aplicacin. Eso permite la autenticacin de los usuarios que realizan peticiones de conexin y el anlisis de conexiones en el mbito de aplicacin. Estas dos caractersticas 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 penalizacin introducida por estos dispositivos es mucho mayor. En el caso de una gran carga de trfico en la red, el rendimiento puede llegar a reducirse drsticamente. En la prctica, las pasarelas y los dispositivos de red con filtrado de paquetes son complementarios. As, estos dos sistemas se pueden combinar, lo que proporcionar ms seguridad y flexibilidad que si slo se utilizara uno, tal como se muestra en la figura siguiente.
Cuando la pasarela autentifica al cliente, abre una conexin al servidor proxy, siendo ste el responsable de transmitir los datos que el cliente recibe del servidor intermediario.
FUOC PID_00147721
15
Seguridad en la red
Este funcionamiento particular provoca que las pasarelas en el mbito de aplicacin 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 entregrselos a otro cuando ste los solicite. El uso de las pasarelas proporciona diversos beneficios. De entrada, las pasarelas permiten slo aquellos servicios para los cuales hay un servidor proxy habilitado. As, si una pasarela contiene servicios intermediarios tan slo para los servicios HTTP y DNS, entonces slo HTTP y DNS sern permitidos en la red interna. El resto de los servicios sern completamente rechazados. Otro beneficio del uso de pasarelas es que el protocolo tambin 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, sera posible prohibir nicamente el uso del comando PUT de FTP dejando habilitados el resto de comandos. Esta caracterstica no es posible obtenerla slo con el uso de filtros de paquetes. Adicionalmente, los servidores intermediarios tambin pueden implantar el filtro de conexiones por direccin IP de la misma manera que los filtros de paquetes, ya que la direccin IP est disponible en el mbito de aplicacin en el cual se har el filtrado. A pesar de obtener ms control global sobre los servicios vigilados, las pasarelas tambin presentan algunas problemticas. 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...). Adems, 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 comunicacin.
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 aplicacin 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 tambin necesitan una comunicacin 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 estn situados. 2.1. Definicin y tipo de redes privadas virtuales
(4)
En ingls, Virtual Private Network (VPN).
Una redprivadavirtual (VPN) es una configuracin que combina el uso de dos tipos de tecnologas: Las tecnologas de seguridad que permiten la definicin de una red privada, es decir, un medio de comunicacin confidencial que no puede ser interceptado por usuarios ajenos a la red. Las tecnologas de encabezamiento de protocolos que permiten que, en vez de una conexin fsica dedicada a la red privada, se pueda utilizar una infraestructura de red pblica, como es Internet, para definir por encima de ella una redvirtual.
Por lo tanto, una VPN es una red lgica o virtual creada sobre una infraestructura compartida, pero que proporciona los servicios de proteccin necesarios para una comunicacin segura. Dependiendo de la situacin 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, geogrficamente 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.
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 porttil 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 proteccin 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 configuracin especfica. En las VPN entre intranets, la situacin ms habitual es que en cada intranet haya una pasarelaVPN 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 travs de Internet. Cuando los paquetes llegan a la intranet de destino, la pasarela correspondiente los descifra y los reenva por la red local hasta el ordenador que los tenga que recibir. De esta manera se utiliza la infraestructura pblica como Internet, en lugar de establecer lneas privadas dedicadas, que supondran un coste ms elevado. Tambin 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 lnea dedicada la redundancia supone un coste todava mayor. En las VPN de acceso remoto, a veces llamadas VPDN5, un usuario se puede comunicar con una intranet a travs de un proveedor de acceso a Internet, utilizando tecnologa convencional, como, por ejemplo, a travs de un mdem ADSL. El ordenador del usuario tiene que disponer de software clienteVPN para comunicarse con la pasarela VPN de la intranet y llevar a cabo la autenticacin necesaria, el cifrado, etc. As, tambin se aprovecha la infraestructura de los proveedores de Internet para el acceso a la intranet, sin necesidad de llamadas a un mdem 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 comunicacin 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 ms restrictivo para permitir slo el acceso a los recursos autorizados.
(5)
VPDN son las siglas de Virtual Private Dial Network.
FUOC PID_00147721
18
Seguridad en la red
La definicin de una red virtual se lleva a cabo mediante el establecimiento de tneles, 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 comunicacin entre las diferentes intranets, o entre el ordenador que accede remotamente y la intranet, se pueden utilizar los protocolos que sean ms convenientes. Los paquetes de estos protocolos, para poder hacerlos llegar a su destino a travs de Internet, se pueden encapsular en datagramas IP, que contendrn 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 tneles en una VPN
Hay diversos protocolos que pueden ser utilizados para establecer los tneles, dependiendo del nivel de la comunicacin en el que se quiera hacer la proteccin. El protocolo utilizado en la gran mayora de configuraciones VPN es IPsec en modo tnel, 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: El protocolo PPTP6 (RFC 2637) especifica una tcnica para la encapsulacin de tramas PPP pero no aade servicios de autenticacin. 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.
FUOC PID_00147721
19
(7)
Seguridad en la red
El protocolo L2F7 (RFC 2637) es parecido al PPTP pero tambin puede trabajar con SLIP, adems de con PPP. Para la autenticacin puede utilizar protocolos auxiliares como Remote Authentication Dial-In User Service (RADIUS).
L2F es la abreviatura de Layer Two Forwarding.
El protocolo L2TP8 (RFC 2661) combina las funcionalidades que ofrecen PPTP y L2F.
(8)
L2TP es la abreviatura de Layer Two Tunneling Protocol.

(9)
El protocolo SSH ofrece la posibilidad de redirigir puertos TCP sobre un canal seguro, que podemos considerar como un tnel a nivel de transporte. Desde este punto de vista, tambin se podra considerar una conexin SSL TLS como un tnel en el mbito del transporte que proporciona confidencialidad y autenticacin. Habitualmente, sin embargo, este ltimo tipo de tnel no sirve para cualquier tipo de trfico sino slo para datos TCP, y por lo tanto no se considera parte integrante de una VPN.
SSH es la abreviatura de Secure Shell.
FUOC PID_00147721
20
Seguridad en la red
3. Introduccin a la criptografa
A lo largo de la historia se han diseado diferentes tcnicas para ocultar el significado de la informacin que no interesa que sea conocida por extraos. Algunas de ellas ya se utilizaban en tiempo de la antigua Grecia o del Imperio romano: por ejemplo, se atribuye a Julio Csar la invencin de un cdigo para enviar mensajes cifrados que no pudieran ser interpretados por el enemigo.
Criptografa Los trminos criptografa, criptologa, etc. provienen de la raz griega krypts, que quiere decir 'escondido'.
La criptografa estudia, desde un punto de vista matemtico, los mtodos para proteger la informacin. Por otra parte, el criptoanlisis estudia las posibles tcnicas para contrarrestar los mtodos criptogrficos, y es de gran utilidad para ayudar a hacerlos ms robustos y difciles de atacar. El conjunto formado por estas dos disciplinas, criptografa y criptoanlisis, se llama criptologa.
Uso del cifrado El hecho de usar el cifrado parte de la constatacin de que intentar evitar la interceptacin de la informacin por parte de un intruso (espa) es muy costoso. Enviar mensajes cifrados es ms fcil, y as, aunque un espa los pueda ver, no podr interpretar la informacin que contienen.
Cuando la proteccin que queremos obtener consiste en garantizar el secreto de la informacin, es decir, la confidencialidad, utilizamos el mtodo criptogrfico conocido como cifrado. Si M es el mensaje que queremos proteger o textoenclaro, cifrarlo consiste en aplicarle un algoritmo de cifrado f, que lo transforme en otro mensaje que llamaremos textocifrado, C. Eso lo podemos expresar como: C = f(M) A fin de que este cifrado sea til, tiene que existir otra transformacin o algoritmo de descifrado f-1, que permita recuperar el mensaje original a partir del texto cifrado: M - f-1 (C)
La cifra de Csar La cifradeCsar consiste en sustituir cada letra del mensaje por la que hay tres posiciones despus 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 Csar no haba letras como la "W"), obtenemos el texto cifrado "DOHD MDFWD HVW". El descifrado en este caso es bien sencillo: slo hay que sustituir cada letra por la que hay 3 posiciones despus en el alfabeto.
FUOC PID_00147721
21
Seguridad en la red
Un esquema como el de la cifra de Csar tiene el inconveniente de que si el enemigo descubre cul 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, habra que instruir a todos los "oficiales de comunicaciones" del ejrcito para que aprendieran un nuevo algoritmo, lo cual podra resultar complicado. En vez de eso, lo que se hace hoy es utilizar como algoritmo una funcin con un parmetro denominado clave.
Ejemplo de uso de una clave El algoritmo de Julio Csar se puede generalizar definiendo una clave k que indique cuntas posiciones se adelanta cada letra en el alfabeto. La cifra de Csar, 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 funcin de cifrado e con una clave de cifrado k, y una funcin de descifrado d con una clavededescifradox: C = e(k,M) M = d(x,C) = d(x,e(k,M)) As, una solucin al problema del espa que se entera de cmo descifrar los mensajes podra 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 proteccin en mantener los algoritmos en secreto (lo que se conoce como "seguridad por ocultismo"). Si el algoritmo es conocido por muchos, es ms fcil que se detecten las debilidades o vulnerabilidades y se puedan corregir rpidamente. Si no, un experto podra deducir el algoritmo por ingeniera inversa, y acabar descubriendo que tiene puntos dbiles por donde atacarlo, como pas con el algoritmo A5/1 de la telefona mvil GSM.
Una premisa fundamental en la criptografa moderna es la llamada suposicindeKerckhoffs, de acuerdo con la cual los algoritmos tienen que ser conocidos pblicamente y su seguridad slo tiene que depender de la clave. En lugar de intentar ocultar el funcionamiento de los algoritmos, es mucho ms seguro y efectivo mantener en secreto slo 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 cul es la clave de descifrado. La palabra "imposible", sin embargo, hay que considerarla con diferentes matices. Un algoritmo criptogrfico es computacionalmenteseguro si, aplicando el mejor mtodo conocido, la cantidad de recursos necesarios (tiempo de clculo, nmero de procesadores, etc.) para descifrar los mensajes sin conocer la clave es mucho mayor (unos cuantos rdenes de magnitud) que lo que est al
FUOC PID_00147721
22
Seguridad en la red
alcance de nadie. En el lmite, un algoritmo es incondicionalmenteseguro si no puede ser invertido ni con recursos infinitos. Los algoritmos que se hacen servir en la prctica son (o intentan ser) computacionalmente seguros. La accin 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 criptoanlisis, es decir, estudiando matemticamente la manera de deducir el texto en claro a partir del texto cifrado. Aplicando la fuerzabruta,esdecir,probandounoaunotodoslosvaloresposiblesdelaclavededescifrado x hasta encontrar uno que produzca un texto en claro con sentido.
Ataques a la cifra de Csar Continuando con el ejemplo del algoritmo de Csar generalizado (con clave), un ataque criptoanaltico podra consistir en analizar las propiedades estadsticas del texto cifrado. Las letras cifradas que ms se repiten probablemente corresponden a vocales o a las consonantes ms frecuentes, las combinaciones ms repetidas de dos (o tres) letras seguidas probablemente corresponden a los dgrafos (o trgrafos) que tpicamente aparecen ms veces en un texto, etc. Por otra parte, el ataque con fuerza bruta consistira 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 cul 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 sera un ejemplo de algoritmo inseguro o dbil.
A continuacin veremos las caractersticas de los principales sistemas criptogrficos utilizados en la proteccin de las comunicaciones. A partir de ahora, consideraremos los mensajes en claro, los mensajes cifrados y las claves como secuencias de bits. 3.1. Criptografa de clave simtrica
Los sistemas criptogrficos declavesimtrica se caracterizan por que la clave de descifrado x es idntica 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 tcnicas criptogrficas se llaman de clave simtrica, y, a veces, tambin de clavecompartida. As, tenemos: C = e(k,M)
FUOC PID_00147721
23
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 comunicacin 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 comunicacin, en la confianza de que, aunque el canal sea inseguro y susceptible de ser inspeccionado por terceros, ningn espa 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, cmo se pueden asegurar de que sea as? Est claro que no pueden enviar la clave escogida a travs del canal de comunicacin de que disponen, porque la hiptesis inicial es que este canal es inseguro y cualquiera podra descubrir la informacin que se transmite. Una posible solucin es utilizar un canal aparte, que pueda ser considerado suficientemente seguro:
Canales seguros Podran ser ejemplos de "canales seguros" el correo tradicional (no electrnico) o un servicio de mensajera "fsica", una conversacin telefnica o cara a cara, etc.
Esta solucin, 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, sera mucho mejor enviar todos los mensajes confidenciales sin cifrar por el canal seguro, y olvidarnos del canal inseguro). Por lo tanto, puede ser difcil ir cambiando la clave. Y por otra parte, este esquema no es bastante general: puede ser que tengamos que enviar informacin cifrada a alguien
FUOC PID_00147721
24
Seguridad en la red
con quien no podemos contactar de ninguna otra manera. Como veremos ms adelante, estos problemas relacionados con el intercambiodeclaves se solucionan con la criptografa asimtrica. A continuacin repasaremos las caractersticas bsicas de los principales algoritmos criptogrficos de clave simtrica, los cuales agruparemos en dos categoras: 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 simtrica k. Para descifrar slo hay que hacer la operacin inversa con el texto cifrado y el mismo texto de cifrado S.
La operacin de combinacin que se utiliza tpicamente es la suma, y la operacin inversa, por lo tanto, es la resta. Si el texto est formado por caracteres, este algoritmo sera como una cifra de Csar en la que la clave va cambiando de un carcter a otro. La clave que corresponde cada vez viene dada por el texto de cifrado S (llamado keystream en ingls).
Suma y resta de bits Cuando trabajamos con aritmtica binaria o aritmtica mdulo 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 idnticas a la operacin lgica "o exclusiva", denotada con el operador XOR ("eXclusive OR'') o el smbolo . 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 bsico de su implementacin.
FUOC PID_00147721
25
Seguridad en la red
Esquema del cifrado y descifrado de flujo
Hay diferentes maneras de obtener el texto de cifrado S en funcin de la clave k: Si se escoge una secuencia k ms corta que el mensaje M, una posibilidad sera repetirla cclicamente tantas veces como haga falta para ir sumndola al texto en claro. El inconveniente de este mtodo es que se puede romper fcilmente, sobre todo cuanto ms corta sea la clave (en el caso mnimo, el algoritmo sera equivalente a la cifra de Csar). En el otro extremo, se podra 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 cifradeVernam. Si k es una secuencia totalmente aleatoria que no se repite cclicamente, estamos ante un ejemplo de cifrado incondicionalmente seguro, tal como lo hemos definido al principio de este mdulo. Este cifrado se llama en ingls 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 travs 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 prctico 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 avin como el portaaviones estn 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 avin despega puede establecer una comunicacin segura con el portaaviones utilizando una cifra de Vernam con la clave aleatoria que ambas partes comparten.
Lo que se hace en la prctica es utilizar funciones que generan secuencias pseudoaleatorias a partir de una semilla (un nmero que acta como parmetro del generador), y lo que se intercambia como clave secreta k es slo 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 posicin 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 funcin del resto de bits.
FUOC PID_00147721
26
Seguridad en la red
Las secuencias pseudoaleatorias se llaman as porque intentan parecer aleatorias pero, claro est, son generadas algortmicamente. En cada paso, el algoritmo estar en un determinado estado, que vendr dado por sus variables internas. Como las variables sern finitas, habr un nmero mximo de posibles estados diferentes. Eso quiere decir que, al cabo de un cierto perodo, los datos generados se volvern a repetir. Para que el algoritmo sea seguro, interesa que el perodo de repeticin sea cuanto ms largo mejor (con relacin al mensaje a cifrar), con el fin de dificultar el criptoanlisis. Las secuencias pseudoaleatorias tambin han de tener otras propiedades estadsticas equivalentes a las de las secuencias aleatorias puras.
Cifrassncronasyasncronas Si el texto de cifrado S depende exclusivamente de la clave k, se dice que el cifrado es sncrono. Este cifrado tiene el problema de que, si por algn error de transmisin 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 asncrono (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 comunicacin, el error afectar como mximo 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 trminos de bits cifrados por segundo). Pero tambin las implementaciones en software pueden ser bastante eficientes. Las caractersticas del cifrado de flujo lo hacen apropiado para entornos en los que haga falta un rendimiento alto y los recursos (capacidad de clculo, consumo de energa) sean limitados. Por eso se suelen utilizar en comunicaciones mviles: redes locales sin hilos, telefona mvil, 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 mltiplo de b, se pueden aadir bits adicionales hasta llegar a un nmero entero de bloques,
FUOC PID_00147721
27
Seguridad en la red
pero entonces puede ser necesario indicar de alguna manera cuntos bits haba realmente en el mensaje original. El descifrado tambin se tiene que realizar bloque a bloque. La figura siguiente muestra el esquema bsico del cifrado de bloque.
Esquema del cifrado de bloque
Muchos de los algoritmos de cifrado de bloque se basan en la combinacin de dos operaciones bsicas: sustitucin y transposicin.
La sustitucin consiste en traducir cada grupo de bits de la entrada a otro, de acuerdo con una permutacin determinada.
La cifra de Csar sera un ejemplo simple de sustitucin, en el que cada grupo de bits correspondera a una letra. De hecho, se trata de un caso particular de sustitucinalfabtica. En el caso ms 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 sustitucin alfabtica
Clave de la sustitucin alfabtica Est claro que la clave tiene que ser una permutacin del alfabeto, es decir, no puede haber letras repetidas ni faltar ninguna. Si no, la transformacin no sera 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 sustitucin alfabtica 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 Textoenclaro: A L E A J A C T A E S T Textocifrado: Q S T Q P Q E Z Q T L Z
FUOC PID_00147721
28
Seguridad en la red
La transposicin consiste en reordenar la informacin del texto en claro segn un patrn determinado.
Ejemplo de transposicin Un ejemplo de transposicin podra 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): Textoenclaro: A L E A J A C T A E S T Textocifrado: E A A L C J A T A S T E
La transposicin por s sola no dificulta extraordinariamente el criptoanlisis, pero puede combinarse con otras operaciones para aadir complejidad a los algoritmos de cifrado. El productodecifras, o combinacin en cascada de diversas transformaciones criptogrficas, es una tcnica 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 sustitucintransposicin.
Confusinydifusin Dos propiedades deseables en un algoritmo criptogrfico son la "confusin", que consiste en esconder la relacin entre la clave y las propiedades estadsticas del texto cifrado, y la "difusin", que propaga la redundancia del texto en claro a lo largo del texto cifrado para que no sea fcilmente reconocible. La confusin hace que cambiando un solo bit de la clave cambien muchos bits del texto cifrado, y la difusin hace que el cambio de un solo bit del texto en claro afecte tambin a muchos bits del texto cifrado. En un bucle de productos de cifras bsicas, la sustitucin contribuye a la confusin, mientras que la transposicin contribuye a la difusin. La combinacin 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 aos el algoritmo de cifrado de bloque ha sido el algoritmo ms estudiado y, al mismo tiempo, el ms utilizado. Desarrollado por IBM durante los aos setenta, fue adoptado por el NBS norteamericano (nombre que tena entonces el actual NIST) como estndar para el cifrado de datos del ao 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 slo 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
FUOC PID_00147721
29
Seguridad en la red
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 sustitucin diferente sobre cada grupo y, a continuacin, una transposicin de todos los bits. Esta transformacin se repite 16 veces: a cada iteracin, la entrada es una transposicin diferente de los bits de la clave sumada bit a bit (XOR) con la salida de la iteracin anterior. Tal como est diseado 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 aos el algoritmo DES ha demostrado ser muy resistente al criptoanlisis, su principal problema actualmente es la vulnerabilidad a los ataques de fuerza bruta, a causa de la longitud de la clave, de slo 56 bits. Si en los aos setenta era muy costoso hacer una bsqueda entre las 256 combinaciones posibles, la tecnologa actual permite romper el algoritmo en un tiempo cada vez ms corto. Por eso, en 1999 el NIST cambi el algoritmo DES por el "Triple DES" como estndar oficial, mientras no estuviera disponible el nuevo estndar 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 slo dos diferentes (k1, k2, y otra vez k1). La longitud total de la clave en la segunda opcin es de 112 bits (dos claves de 56 bits), que hoy ya se considera bastante segura; la primera opcin proporciona ms seguridad, pero a costa de utilizar una clave total de 168 bits (3 claves de 56 bits), que puede costar un poco ms gestionar e intercambiar. Para hacer el sistema adaptable al estndar 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 estndar 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 criptolgica para que presentara propuestas sobre un nuevo estndar, 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 criptgrafos belgas Joan Daemen y Vincent Rijmen. El Rijndael puede trabajar con bloques de 128, 192 o 256 bits (aunque el estndar AES slo prev los de 128), y la longitud de la clave tambin puede ser 128, 192 o 256 bits. Dependiendo de esta ltima longitud, el nmero de iteraciones del algoritmo es 10, 12 o 14, respectivamente. Cada iteracin incluye una sustitucin fija byte a byte, una transposicin, una transformacin consistente en desplazamientos de bits y XOR, y una suma binaria (XOR) con bits obtenidos a partir de la clave. Repeticin del DES La operacin 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 repeticin del DES no sera ms segura que el DES simple.
3.1.3. Uso de los algoritmos de clave simtrica Cuando se usa el cifrado simtrico para proteger las comunicaciones, se puede escoger el algoritmo que sea ms apropiado a las necesidades de cada aplicacin: normalmente, a ms 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 informacin indirectamente. Por ejemplo, en un protocolo
FUOC PID_00147721
30
Seguridad en la red
que utilice mensajes con una cabecera fija, la aparicin de los mismos datos cifrados varias veces en una transmisin puede indicar dnde empiezan los mensajes. Eso no pasa con las cifras de flujo si su perodo 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 tambin sern iguales. Para contrarrestar esta propiedad, se pueden aplicar en diversos modosdeoperacin a las cifras de bloque: 1)ModoECB(ElectronicCodebook). Es el ms 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 operacin ECB Nombre del modo ECB Modo ECB (Electronic Codebook) da la idea de que se puede considerar como una simple sustitucin bloque a bloque, de acuerdo con un cdigo o diccionario (con muchas entradas, eso s) que viene dado por la clave.
2)ModoCBC(CipherBlockChaining). 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 inicializacin (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 sern 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 operacin CBC Modo CFB como cifra de flujo Es fcil ver que el modo CFB (y tambin el OFB) se puede considerar como una cifra de flujo que utiliza como funcin generadora una cifra de bloque.
3)ModoCFB(CipherFeedback). 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 nmero n de bits
FUOC PID_00147721
31
Seguridad en la red
generados en cada iteracin 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 operacin CFB
4)ModoOFB(OutputFeedback). 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 recepcin de un bit cifrado afecta slo al descifrado de este bit.
Modo de operacin OFB
5)Otrosmodos. 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 tcnica para evitar que en textos de entrada iguales se obtengan textos cifrados iguales, que es aplicable tambin a los cifrados que no usan vector de inicializacin (incluidas las cifras de flujo). Esta tcnica 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 bitsdesal. Igual que el vector de inicializacin, los bits de sal se envan en claro antes del texto cifrado.
FUOC PID_00147721
32
Seguridad en la red
3.1.4. Funciones hash seguras Aparte de cifrar datos, hay algoritmos basados en tcnicas criptogrficas que se usan para garantizar la autenticidad de los mensajes. Un tipo de algoritmos de estas caractersticas son las llamadas funcioneshashseguras, tambin conocidas como funciones de resumendemensaje10. En general, podemos decir que una funcin 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 funcin h tiene que dar resmenes H iguales. Pero si dos mensajes dan el mismo resumen H no necesariamente tienen que ser iguales. Eso es as porque slo hay un conjunto limitado de posibles valores H, ya que su longitud es fija, y en cambio puede haber muchos ms mensajes M (si la longitud puede ser cualquiera, habr infinitos). Para poder aplicarla en un sistema de autenticacin, la funcin h tiene que ser una funcin hash segura.
Secreto de los algoritmos Notad que las funciones hash son conocidas ya que todo el mundo tiene que poder calcular los resmenes de la misma manera.
(10)
En ingls, message digest.
Se entiende que una funcin 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 resistenteacolisiones, 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 enva 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 tendra que ser A), y tambin que nadie ha modificado el mensaje.
FUOC PID_00147721
33
Seguridad en la red
Otra tcnica consistira en calcular el resumen del mensaje M y cifrarlo utilizando s como clave de cifrado.
Autenticidad y confidencialidad Cifrar slo el resumen, en lugar del mensaje entero, es ms eficiente porque hay menos bits a cifrar. Eso, claro est, suponiendo que slo haga falta autenticidad, y no confidencialidad. Si tambin interesa que el mensaje sea confidencial, entonces s que hay que cifrarlo entero.
Para verificar la autenticidad hace falta recuperar el resumen enviado, descifrndolo con la clave secreta s, y compararlo con el resumen del mensaje M. Un atacante que quisiera modificar el mensaje sin conocer la clave podra intentar sustituirlo por otro que d el mismo resumen, con lo que B no detectara la falsificacin. Pero si la funcin de resumen es resistente a colisiones, eso le tendra 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 relacin 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 resmenes de 128 o 160 bits. Eso quiere decir que un atacante podra tener que probar del orden de 2128 o 2160 mensajes de entrada para encontrar una colisin (es decir, un mensaje diferente que diera el mismo resumen). Pero hay otro tipo de ataque ms ventajoso para el atacante, llamado ataque delcumpleaos. Un ataque de este tipo parte del supuesto de que el atacante puede escoger el mensaje que ser autenticado. La vctima 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 autntico es este otro. Y eso se puede conseguir haciendo una bsqueda 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 dbil", mientras que la propiedad de ser resistente a ataques del cumpleaos se llama " resistencia fuerte". Paradoja del cumpleaos El nombre de este tipo de ataque viene de un problema clsico de probabilidades conocido como la "paradoja del cumpleaos". El problema consiste en encontrar el nmero mnimo de personas que tiene que haber en un grupo para que la probabilidad de que al menos dos de ellas celebren su cumpleaos el mismo da sea superior al 50%. Una respuesta intuitiva puede ser que la solucin es del orden de 200, pero este resultado no es correcto. Podra serlo si se quisiera obtener el nmero 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 solucin es un nmero mucho menor: 23.
FUOC PID_00147721
34
Seguridad en la red
La conclusin es que si una funcin de resumen puede dar N valores diferentes, para que la probabilidad de encontrar dos mensajes con el mismo resumen sea del 50% el nmero de mensajes que hay que probar es del orden de N Ejemplos de funciones hash seguras El esquema de la mayora 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 despus 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 cmo la sucesin de transposiciones en los cifrados de bloque provoca un "efecto avalancha" que garantiza la difusin de los bits. Hasta hace poco, el algoritmo de hash ms usado era el MD5 (Message Digest 5). Pero como el resumen que da es de slo 128 bits, y aparte se han encontrado otras formas de generar colisiones parciales en el algoritmo, actualmente se recomienda utilizar algoritmos ms seguros, como el SHA-1 (Secure Hash Algorithm-1). El algoritmo SHA-1, publicado en 1995 en un estndar del NIST (como revisin de un algoritmo anterior llamado simplemente SHA), da resmenes de 160 bits. En el 2002 el NIST public variantes de este algoritmo que generan resmenes de 256, 384 y 512 bits.
3.2. Criptografa de clave pblica Trataremos ahora los conceptos fundamentales de la criptologa de clave pblica. 3.2.1. Algoritmos de clave pblica Como hemos visto en el subapartado anterior, uno de los problemas de la criptografa de clave simtrica es el de la distribucin de las claves. Este problema se puede solucionar si utilizamos algoritmosdeclavepblica, tambin llamados algoritmosdeclaveasimtrica.
En un algoritmo criptogrfico de clave pblica se utilizan claves diferentes para el cifrado y el descifrado. Una de ellas, la clavepblica, se puede obtener fcilmente a partir de la otra, la claveprivada, pero en cambio es computacionalmente muy difcil obtener la clave privada a partir de la clave pblica.
Los algoritmos de clave pblica tpicamente permiten cifrar con la clave pblica (kpub) y descifrar con la clave privada (kpr):
FUOC PID_00147721
35
Seguridad en la red
C = e(kpub,M) M = d(kpr,C) Pero tambin puede haber algoritmos que permitan cifrar con la clave privada y descifrar con la pblica (ms adelante veremos cmo se puede utilizar esta propiedad): C = e(kpr,M) M = d(kpub,C)
Adaptacin de los problemas difciles Si el avance de la tecnologa reduce el tiempo de resolucin, se puede aumentar la longitud n, con lo cual harn falta unas cuantas operaciones ms para el planteamiento, pero la complejidad de la solucin crecer exponencialmente.
Los algoritmos de clave pblica se basan en problemas matemticos "fciles" de plantear a partir de la solucin, pero "difciles" de resolver. En este contexto, se entiende que un problema es fcil si el tiempo para resolverlo, en funcin de la longitud n de los datos, se puede expresar en forma polinmica, como, por ejemplo, n2 + 2n (en teora de la complejidad, se dice que estos problemas son de la "clase P"). Si el tiempo de resolucin crece ms rpidamente, como por ejemplo con 2n, el problema se considera difcil. As, se puede escoger un valor de n tal que el planteamiento sea viable pero la resolucin sea computacionalmente intratable. Un ejemplo de problema fcil de plantear pero difcil de resolver es el de los logaritmos discretos. Si trabajamos con aritmtica mdulo m, es fcil calcular esta expresin: y = bx mod m El valor x se llama logaritmo discreto de y en base b mdulo m. Escogiendo convenientemente b y m, puede ser difcil calcular el logaritmo discreto de cualquier y. Una posibilidad es ir probando todos los valores de x: si m es un nmero de n bits, el tiempo para encontrar la solucin aumenta proporcionalmente a 2n. Hay otros mtodos ms eficientes para calcular logaritmos discretos, pero el mejor algoritmo conocido tambin necesita ms tiempo de lo que se puede expresar polinmicamente.
Ejemplo de operaciones mdulo m Para obtener 1411 mod 19 podemos multiplicar 11 veces el nmero 14, dividir el resultado entre 19 y tomar el residuo de la divisin, que es igual en 13. Pero tambin se puede aprovechar que el exponente 11 es 1011 en binario (11 = 123 + 022 + 121 + 120), y por lo tanto 1411 = 148 142 141, para obtener el resultado con menos multiplicaciones:
FUOC PID_00147721
36
Seguridad en la red
As, sabemos que log14 13 = 11 (mod 19). Pero si tuviramos que obtener el logaritmo de cualquier otro nmero y tendramos que ir probando uno a uno los exponentes hasta encontrar uno que d como resultado y. Y si en vez de tratarse de nmeros de 4 o 5 bits como stos fueran nmeros de ms de 1.000 bits, el problema sera intratable.
As pues, los algoritmos de clave pblica se tienen que disear de manera que sea inviable calcular la clave privada a partir de la pblica, y lgicamente tambin 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 prctica, los algoritmos utilizados permiten cifrar y descifrar fcilmente, pero todos ellos son considerablemente ms lentos. Por eso, la criptografa de clave pblica se suele utilizar slo en los problemas que la criptografa simtrica no puede resolver: el intercambio de claves y la autenticacin con no repudio (firmas digitales).
Velocidad de la criptografa de clave pblica El cifrado y descifrado con algoritmos de clave pblica puede llegar a ser dos o tres rdenes de magnitud ms lento que con criptografa simtrica. que los equivalentes con criptografa simtrica.
Los mecanismos de intercambiodeclaves permiten que dos partes se pongan de acuerdo en las claves simtricas que utilizarn para comunicarse, sin que un tercero que est escuchando el dilogo pueda deducir cules son estas claves.
Ejemplo de mecanismos de intercambio de claves A puede escoger una clave simtrica k, cifrarla con la clave pblica de B, y enviar el resultado a B. Entonces B descifrar con su clave privada el valor recibido, y sabr cul es la clave k que ha escogido A. El resto de la comunicacin ir cifrada con un algoritmo simtrico (mucho ms rpido), utilizando esta clave k. Los atacantes, como no conocern la clave privada de B, no podrn deducir el valor de k.
La autenticacin basada en clave pblica se puede llevar a cabo si el algoritmo permite utilizar las claves a la inversa: la clave privada para cifrar y la clave pblica para descifrar.
Si A enva un mensaje cifrado con su clave privada, todo el mundo podr descifrarlo con la clave pblica de A, y al mismo tiempo todo el mundo sabr que el mensaje slo lo puede haber generado quien conozca la clave privada asociada (que tendra que ser A). sta es la base de las firmasdigitales.
FUOC PID_00147721
37
Seguridad en la red
Ejemplos de algoritmos de clave pblica El RSA es el algoritmo ms utilizado en la historia de la criptografa de clave pblica. Su nombre viene de las iniciales de los que lo disearon en 1977: Ronald Rivest, Adi Shamir y Leonard Adleman. La clave pblica est formada por un nmero 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 pblica 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 factorizacin de nmeros grandes, que es otro de los problemas considerados difciles). Valores usados en el RSA Actualmente, el problema de factorizar nmeros de 512 bits es muy complejo, pero abordable si se dispone de bastantes recursos. Por lo tanto, se recomienda utilizar claves pblicas con un valor n a partir de 1.024 bits. Como exponente pblico e tpicamente se utilizan valores sencillos como 3 o 65.537 (1216 + 1) porque hacen ms rpido el cifrado.
3.2.2. Uso de la criptografa de clave pblica Hemos visto antes que las principales aplicaciones de la criptografa de clave pblica 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 slo disponen de un canal inseguro para comunicarse se resuelve con la criptografa de clave pblica. Cuando A quiere enviar un mensaje secreto M a B, no hay que cifrar todo el mensaje con un algoritmo de clave pblica (eso podra resultar muy lento), sino que se escoge una clave simtrica ks, llamada a veces clavedesesin o clavedetransporte, y se cifra el mensaje con un algoritmo simtrico utilizando esta clave. Lo nico que hay que cifrar con la clave pblica de B ( la clave de sesin. En recepcin, B utiliza su clave privada ( ) es
) para recuperar
la clave de sesin ks y, entonces, ya puede descifrar el mensaje cifrado.
Ya que la clave de sesin es un mensaje relativamente corto (por ejemplo, si es una clave DES slo tendr 56 bits), un atacante podra 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
FUOC PID_00147721
38
Seguridad en la red
clave de sesin ks con la clave pblica
. En el caso de una clave de sesin
DES, independientemente del nmero de bits de la clave pblica, el atacante slo necesitara un esfuerzo del orden de 256 operaciones. Para evitar este tipo de ataque, lo que se cifra realmente con la clave pblica no es directamente el valor secreto (en este caso ks), sino que a este valor se le aade una cadena ms o menos larga de bits aleatorios. El receptor slo tiene que descartar estos bits aleatorios del resultado que obtenga del descifrado.
Una firmadigital es bsicamente un mensaje cifrado con la clave privada del firmante. Sin embargo, por cuestin de eficiencia, lo que se cifra no es directamente el mensaje a firmar, sino slo su resumen calculado con una funcin hash segura.
Cuando A quiera enviar un mensaje firmado, tendr que obtener su resumen y cifrarlo con la clave privada descifrarla con la clave pblica . 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 funcin de resumen es resistente a colisiones, un atacante no podr modificar el mensaje sin que la firma deje de ser vlida.
3.2.3. Infraestructura de clave pblica Tal como hemos visto hasta ahora, la criptografa de clave pblica permite resolver el problema del intercambio de claves, haciendo uso de las claves pblicas de los participantes. Ahora, sin embargo, se plantea otro problema: si alguien nos dice que es A y su clave pblica es kpub, cmo poder saber que kpub es realmente la clave pblica 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 pblica es k'pub". Una posible solucin a este problema es que haya alguien de confianza que nos asegure que efectivamente las claves pblicas pertenecen a sus supuestos propietarios. Ese alguien puede firmar un documento que diga "la clave pblica de A es ", y publicarlo para que todo el mundo tenga conocimiento de ello. Este tipo de documento se llama certificadodeclavepblica y es la base de lo que se conoce como infraestructuradeclavepblica(PKI).
FUOC PID_00147721
39
Seguridad en la red
4. Certificados digitales
Un certificado de clave pblica consta de tres partes bsicas: 1) Una identificacin de usuario, como, por ejemplo, su nombre. 2) El valor de la clave pblica 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 garanta de que la clave pblica pertenece al usuario que figura en ella. Quien firma el certificado puede ser una autoridad que se responsabilice de verificar de manera fehaciente la autenticidad de las claves pblicas. En este caso, se dice que el certificado ha sido generado por una autoridadde certificacin11. Puede haber diferentes formatos de certificados, pero el ms usado es el de los certificadosX.509, especificado en la definicin del serviciodedirectorio X.500. El directorio X.500 permite almacenar y recuperar informacin, expresada como atributos, de un conjunto de objetos. Los objetos X.500 pueden representar, por ejemplo, pases, ciudades, o bien empresas, universidades (en general, organizaciones), departamentos, facultades (en general, unidades organizativas), personas, etc. Todos estos objetos estn organizados jerrquicamente 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 nombredistintivo12, que no es ms que la concatenacin de los atributos distintivos que hay entre la raz del rbol y el objeto en cuestin. 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 tambin operaciones de modificacin de la informacin de los objetos. Estas ltimas operaciones, sin embargo, normalmente slo estn permitidas a ciertos usuarios autorizados, y por lo tanto hacen falta mecanismos de autenticacin de los usuarios, y estos mecanismos estn definidos en la Recomendacin X.509. Hay un mecanismo bsico que utiliza contraseas, y un mecanismo ms avanzado que utiliza certificados.
(11)
En ingls, Certification Authority (CA).
El directorio X.500 La especificacin del directorio X.500 est publicada en la Serie de Recomendaciones ITU-T X.500, una de las cuales es la Recomendacin X.509.
(12)
En ingls, Distinguished Name (DN).
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 jerarquas de certificacin Un certificado nos soluciona el problema de la autenticidad de la clave pblica 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 pblica, 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 jerarqua de autoridades de certificacin, en la que las CA de nivel ms bajo emiten los certificados de usuario, y las CA de cada nivel son certificadas por una de nivel superior. En un mundo ideal, podra haber una CA raz que estuviera en la cima de la jerarqua y tuviera la mxima autoridad. En la prctica, esta CA raz global no existe, y seguramente no existir nunca (sera difcil 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 raz. Para que podamos verificar la autenticidad de su clave pblica, un usuario nos puede enviar su certificado, ms el certificado de la CA que lo ha emitido, ms el de la CA que ha emitido este otro certificado, etc., hasta llegar al certificado de una CA raz. Eso es lo que se denomina una cadenadecertificados. Los certificados de las CA raz tienen la propiedad de ser autofirmados, es decir, estn firmados por ellas mismas. Un posible tipo de extensin 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 nmero mximo de niveles de la jerarqua por debajo de esta CA. 4.2. Listas de revocacin de certificados La Recomendacin X.509, adems de definir el formato de los certificados, tambin define otra estructura denominada listaderevocacindecertificados13. Una lista de este tipo sirve para publicar los certificados que han dejado de ser vlidos 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 ingls, Certificate Revocation List (CRL).
FUOC PID_00147721
41
Seguridad en la red
As, si queremos asegurarnos completamente de la validez de un certificado, no basta con verificar su firma, sino que tendremos que obtener la versin 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 peridica, aadiendo 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.
FUOC PID_00147721
42
Seguridad en la red
5. Seguridad en la red
Hasta el momento hemos visto aspectos tericos y prcticos relacionados con la arquitectura de la red y los protocolos de comunicacin. En este apartado se presenta una visin de los conceptos de seguridad ms enfocada a los mbitos de aplicacin y transporte de la red. Trataremos los aspectos a considerar en el desarrollo de aplicaciones como los protocolos de seguridad ms usados hoy en da. 5.1. Cookies Las cookies (galletas) son un mecanismo para facilitar informacin sobre la navegacin realizada. En definitiva, son una herramienta utilizada por los servidores web para almacenar informacin sobre sus visitantes.
Una cookie es un fichero de texto que algunos servidores web graban en nuestro ordenador con informacin sobre la navegacin realizada en sus pginas. 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 dejarn de ser activas, la determina el diseador de la web del servidor, y puede variar entre el tiempo de la propia sesin y el de una fecha especificada. Las cookies no causan daos en el sistema, ya que slo permiten reconocer al usuario cuando se conecta a un sitio web, registrando las visitas. En concreto, pueden llegar a guardar la contrasea utilizada para acceder a aquella pgina, 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 tambin que existen virus que buscan esta informacin "sensible" dentro de las cookies. Por medio de las opciones de configuracin del navegador se puede habilitar o deshabilitar la aceptacin de cookies. Tambin 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 gestin de las cookies. Tcnicamente, 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 seran independientes de estado.
FUOC PID_00147721
43
Seguridad en la red
Sin las cookies, cada peticin de una pgina web o un componente de una pgina web sera un acontecimiento aislado, sin ninguna relacin con el resto de peticiones de otras pginas del mismo sitio. Al devolver una cookie al servidor web, el navegador le proporciona un medio para relacionar la solicitud de la pgina actual con solicitudes de pginas anteriores. Adems de ser definidas por un servidor web, las cookies tambin 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 podra querer ayudar a sus clientes potenciales recordndoles las cosas que haba en su cesta de la compra, incluso si cierran el navegador sin realizar la compra y vuelven ms tarde, para evitar que tengan que buscar los productos de nuevo. En este caso, el servidor creara una cookie con fecha de borrado segn el deseo del diseador 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 sesin y otra. Por esta razn, a las cookies con fecha de borrado se las llama persistentes. 5.2. Contenidos activos En los ltimos aos la web ha evolucionado desde el contenido esttico que nos permita crear HTML hasta contenidos completamente dinmicos, que constituyen ya hoy en da la mayora de las pginas web. Un contenido dinmico es creado en tiempo de ejecucin por un conjunto de procesos que se ejecutan tanto en el cliente como en el servidor, y eso depende de la tecnologa utilizada. En este sentido, la seguridad de la web requiere tcnicas cada vez ms especficas con el fin de asegurar los contenidos y proteger las maquinas de cdigos maliciosos. En este sentido introduciremos algunas de las tecnologas usadas para la creacin de contenido dinmico. 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 anfitrin mediante un plug-in, o en aplicaciones, como telfonos mviles, que soportan el modelo de programacin por applets. Los applets se ejecutan en el contexto del cliente y por lo tanto requieren de tcnicas que aseguren que la ejecucin no daar la mquina cliente.
Navegadores y cookies Las especificaciones de cookies sugieren que los navegadores tienen que soportar un nmero mnimo de cookies o una cantidad mnima 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 informacin grfica y a veces interacta con el usuario, tpicamente carece de sesin y tiene privilegios de seguridad restringidos. Un applet normalmente lleva a cabo una funcin muy especfica 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 polticas 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 pginas dinmicas cuyo contenido generalmente es un fichero HTML generado dinmicamente. Un servlet es capaz de recibir una invocacin y generar una respuesta en funcin de los datos de la invocacin, el estado del propio sistema y los datos a que pueda acceder. Los servlets pueden estar empaquetados dentro de un fichero de formato WAR14, como aplicacin web, dentro de un contenedor. La ejecucin de un servlet se hace dentro de uno o ms 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 ejecucin (o en otro momento despus del arranque del servidor de aplicaciones). Por otra parte, JavaServer Pages (JSP) es una tecnologa que permite a los desarrolladores de pginas web generar respuestas dinmicamente a peticiones HTTP. La tecnologa permite que cdigo Java y ciertas acciones predefinidas sean incrustadas en un contexto esttico, 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 comn15 es una importante tecnologa 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 estndar para transferir datos entre el cliente y el programa. Es un mecanismo de comunicacin entre el
(15) (14)
En ingls, Web Application Archive.
En ingls, Common Gateway Interface (CGI).
FUOC PID_00147721
45
Seguridad en la red
servidor web y una aplicacin externa cuyo resultado final de la ejecucin 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 prcticas de crear contenido dinmico para las pginas web. En una aplicacin 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 esttico tradicional. CGI ha hecho posible la implementacin de funciones nuevas y variadas en las pginas web, de tal manera que esta interfaz se ha convertido rpidamente en un estndar, que se implementa en todo tipo de servidores web. Las CGI son programas que podran introducir problemas de seguridad si han sido programados malintencionadamente. Por este motivo, muchos de los proveedores de hosting de pginas web no permiten la ejecucin de este tipo de servicios web. 5.2.4. ASP/PHP El servidor de pginas activas16 corresponde a la tecnologa introducida por Microsoft en el ao 1996, y permite el uso de diferentes scripts y componentes ActiveX al lado del tradicional HTML para mostrar pginas generadas dinmicamente. Se basa en el VBScript, pero existen diversos lenguajes de programacin que se pueden utilizar, como, por ejemplo, Perl, Javascript, etc. ASP es una tecnologa dinmica que funciona en el lado del servidor, lo que significa que, cuando el usuario solicita un documento ASP, las instrucciones de programacin dentro del script se ejecutan en el servidor para enviar al navegador nicamente el cdigo HTML resultante. Al usuario slo se le enva lo que solicita, y no puede acceder a ningn otro servicio del servidor. As, una de sus aplicaciones ms 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 programacin creado para desarrollar aplicaciones web, muy similar a los lenguajes de programacin C o C++. Su cdigo se inserta en las pginas HTML, y se ejecuta en el servidor. Hay que destacar la aparicin de muchos frameworks que facilitan el desarrollo de aplicaciones web, a la vez que integran las funcionalidades de generacin de contenido y su almacenaje. Por ejemplo, Cake, Rails, etc.
Direccin web recomendada Para saber ms sobre PHP podis consultar la siguiente direccin: http://www.php.net.
(16)
En ingls, Active Server Pages (ASP).
FUOC PID_00147721
46
Seguridad en la red
5.2.5. RIA RIA (Rich Internet Applications) es un acrnimo que engloba una gran multitud de trminos que definen una serie de aplicaciones cuyos contenidos son dinmicos y se cargan en el tiempo de inicializacin. La aplicacin slo hace consultas al servidor para obtener datos de las bases de datos mientras que las herramientas (reproductores de vdeo, procesamiento de imgenes) ya estn cargadas en el lado del cliente. Eso hace que se puedan ofrecer funcionalidades mucho ms ricas y entornos multimedia ms conseguidos. Se puede decir que las RIA son la nueva generacin de las aplicaciones y una tendencia ya impuesta por empresas como Macromedia, Magic Software, Sun o Microsoft, que estn desarrollando recursos para hacer de este tipo de aplicaciones una realidad. Estas aplicaciones estn 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 asncrona, 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 aplicacin alguna cosa muy sencillo, mejoras en la conectividad y despliegue instantneo de la aplicacin, agilizando su acceso, garantizan la desvinculacin de la capa de presentacin, es decir, el acceso a la aplicacin 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 informacin. 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 podra interceptar, leer, destruir o modificar la informacin enviada. Muchas veces, durante el proceso de diseo de una aplicacin la seguridad es un aspecto que se deja de lado y se acaba aadiendo con posterioridad. En muchos casos, estos aadidos no han contemplado todos los posibles problemas y, por lo tanto, hacen que la aplicacin 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 presentacin. De esta manera, se podra ofrecer este servicio a todas las aplicaciones. No obstante, el modelo OSI no tuvo xito y, por lo tanto, esta solucin no ha sido usada. Si analizamos el modelo Internet, basado en el protocolo TCP/IP, veremos que no existe ningn nivel de presentacin, pero podemos llegar a establecer una cierta equivalencia entre ambos modelos que nos ser til para sealar los
(17)
OSI es la abreviatura de Open Systems Interconnection, en castellano, interconexin de sistemas abiertos.
FUOC PID_00147721
47
Seguridad en la red
sistemas de seguridad que podemos establecer en cada uno de los niveles. En el nivel de aplicacin podemos implementar aquellos servicios de seguridad que sean especficos de cada aplicacin.
El servicio de seguridad pasa a travs de aplicaciones intermedias. Por ejemplo, Pretty Good Privacy (PGP), Secure Electronic Transactions (SET), S/MIME, etc. Por debajo del nivel de aplicacin, podemos llegar a intercalar servicios de seguridad como Secure Sockets Layer (SSL), Transporte Layer Secure (TLS), etc. Entre los niveles TCP y IP, podramos 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 llegarn a su destino. 5.3.1. PGP Existen herramientas basadas en algoritmos criptogrficos que permiten proteger la informacin que se intercambia a travs de la red. Pretty Good Privacy (PGP) es un protocolo que permite cifrar (encriptar) ficheros y mensajes de correo electrnico de manera que slo puedan acceder a ellos los usuarios que determinemos. De forma adicional, PGP permite realizar una firma digital de
FUOC PID_00147721
48
Seguridad en la red
los ficheros y mensajes, con lo que se puede garantizar la integridad de los mismos. Mediante este programa podemos llevar la gestin de claves, cifrar y firmar digitalmente mensajes y ficheros, borrado seguro de ficheros, etc. Resumiendo, sus dos usos ms comunes son los siguientes: Garantizar que un fichero informtico (mensaje de correo electrnico, fichero de texto, hoja de clculo, imagen, etc.) ha sido creado por quien dice ser su creador (firma digital). Impedir que personas sin autorizacin lean un fichero informtico (encriptacin). No obstante, aunque tiene otras funciones, nos centraremos en las dos formas ms comunes de uso de PGP, la firma digital y la encriptacin. Para usar cualquiera de estas funciones, el usuario de PGP tiene que crear una pareja de claves (una pblica y otra privada), que son la base sobre la que se sostiene la criptografa de claves pblicas, basada en los algoritmos de clave asimtrica. Crear la pareja de claves es muy sencillo, ya que es la aplicacin PGP la que se encarga prcticamente de todo. Para que se pueda utilizar PGP, los interlocutores tendrn 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 ms tenga acceso a ella. Para reducir su vulnerabilidad, la clave privada est protegida por una contrasea compleja en forma de frase que es mucho ms segura que una contrasea tpica de menos de diez caracteres. Su utilidad es desencriptar los mensajes que nos sean enviados de forma segura. Por el contrario, la clave pblica hay que distribuirla a todas las personas con las que queramos mantener comunicaciones seguras. Podra parecer que distribuir libremente nuestra clave pblica es una forma de bajar nuestras defensas, pero no es as: la clave pblica est encriptada y, adems, 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 sera preciso disponer de la clave privada. PGP se puede integrar en los programas de correo electrnico ms usuales para hacer que encriptar y firmar mensajes no consista ms que en pulsar un botn. Al encriptar un mensaje, se nos pedir que indiquemos a quin lo enviaremos, para as escoger la clave pblica correcta con que cifrarlo. Para firmar, en cambio, se nos pedir que tecleemos la contrasea de nuestra clave privada, con lo cual evitamos tambin que alguien que use nuestro ordenador en nuestra ausencia pueda hacerse pasar por nosotros.
FUOC PID_00147721
49
Seguridad en la red
Para cifrar los datos se utiliza un algoritmo de clave simtrica, cuya clave se cifra con un algoritmo de clave asimtrica. De esta manera se combinan las mejores propiedades de ambos: la seguridad de un algoritmo asimtrico (donde clave pblica y privada son diferentes) con la rapidez y robustez de un algoritmo simtrico (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 funcin 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 asimtrica, cifrado con clave simtrica y firma digital. Cuando se desea enviar un correo o fichero encriptado de B a A, PGP lo encripta usando un sistema simtrico (generalmente IDEA o DES), usando una clave aleatoria clave DES, que posteriormente se encripta (por ejemplo, con RSA con la clave pblica de A, KAp). Se envan 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 simtrica con su clave privada RSA (Kas), y despus descifra el documento usando la clave desencriptada clave DES. 5.4. SSL Secure Socket Layer es un sistema de protocolos de carcter general diseado en 1994 por la empresa Nestcape Communications Corporation, basado en la aplicacin conjunta de criptografa simtrica, criptografa asimtrica (de clave pblica), certificados digitales y firmas digitales, para ofrecer conexiones seguras a travs de Internet. Este grupo de protocolos comprende: El protocolo de transporte Secure Sockets Layer (SSL), desarrollado por Netscape Communications a principios de los aos noventa. La primera versin de este protocolo, sobradamente difundida e implementada, fue la 2.0. Poco despus, Netscape public la versin 3.0, con muchos cambios con respecto a la anterior, que hoy casi ya no se utiliza. La especificacin Transport Layer Security (TLS), elaborada por la Internet Engineering Task Force (IETF). La versin 1.0 del protocolo TLS est publicada en el documento RFC 2246. Es prcticamente equivalente a SSL 3.0 con algunas pequeas 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 mviles. La mayora de los protocolos WAP son adaptaciones de los ya existentes a las caractersticas 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
FUOC PID_00147721
50
Seguridad en la red
ancho de banda y de la capacidad de clculo de los dispositivos, que puede ser limitada.
5.4.1. Caractersticas del protocolo SSL/TLS El objetivo inicial del diseo del protocolo SSL fue proteger las conexiones entre clientes y servidores web con el protocolo HTTP. Esta proteccin tena que permitir al cliente asegurarse de que se haba conectado al servidor autntico, y enviarle datos confidenciales, como, por ejemplo, un nmero de tarjeta de crdito, con la certeza de que nadie ms que el servidor es capaz de ver estos datos. Las funciones de seguridad, sin embargo, no se implementaron directamente en la proteccin de aplicacin HTTP, sino que se opt por introducirlas en el nivel de transporte. As podra haber muchas ms 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 estndar 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 diseo se hizo de manera tal que cualquier aplicacin que utilizara TCP a travs de los llamamientos de los sockets poda hacer uso del protocolo SSL slo cambiando estos llamamientos. De aqu viene el nombre del protocolo.
Diseo del protocolo SSL
Datagramas en WTLS Una caracterstica distintiva del WTLS es que no solamente permite proteger conexiones TCP, como hacen SSL y TLS, sino que tambin define un mecanismo de proteccin para las comunicaciones en modo datagrama, usado en diversas aplicaciones mviles.
Los servicios de seguridad que proporcionan los protocolos SSL TLS son:
FUOC PID_00147721
51
Seguridad en la red
Confidencialidad. El flujo normal de informacin en una conexin SSL TLS consiste en intercambiar paquetes con datos cifrados mediante claves simtricas (por motivos de eficiencia y rapidez). Al inicio de cada sesin, cliente y servidor se ponen de acuerdo sobre las claves que utilizarn 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 dilogo inicial pueda saber cules son las claves acordadas, se sigue un mecanismo seguro de intercambio de claves, basado en criptografa de clave pblica. El algoritmo concreto para este intercambio tambin se negocia durante el establecimiento de la conexin.
Autenticacindeentidad. 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 pblica del servidor, y eso normalmente se hace a travs de certificados digitales. SSL/TLS tambin prev la autenticacin del cliente de cara al servidor. Esta posibilidad, sin embargo, no se usa tan a menudo porque muchas veces, en vez de autenticar automticamente al cliente a nivel de transporte, las mismas aplicaciones utilizan su propio mtodo de autenticacin.
Autenticacin de cliente Un ejemplo de autenticacin de cliente en el mbito de aplicacin son las contraseas que pueden introducir los usuarios en formularios HTML. Si la aplicacin utiliza este mtodo, al servidor ya no le hace falta autenticar al cliente a nivel de transporte.
Autenticacindemensaje. Cada paquete enviado en una conexin SSL TLS, adems de ir cifrado, puede incorporar un cdigo MAC para que el destinatario compruebe que nadie ha modificado el paquete. Las claves secretas para el clculo de los cdigos MAC (una para cada sentido) tambin se acuerdan de forma segura en el dilogo inicial.
Adems, los protocolos SSL TLS estn diseados con estos criterios adicionales: Eficiencia. Dos de las caractersticas de los SSL TLS, la definicin de sesiones y la compresin de los datos, permiten mejorar la eficiencia de la comunicacin. Si el cliente pide dos o ms conexiones simultneas o muy seguidas, en lugar de repetir la autenticacin y el intercambio de claves (operaciones computacionalmente costosas porque intervienen algoritmos de clave pblica), existe la opcin de reutilizar los parmetros previamente acordados. Si se hace uso de esta opcin, se considera que la nueva conexin pertenece a la misma sesin que la anterior. En el establecimiento de cada conexin se especifica un identificadordesesin, que permite saber si la conexin empieza una sesin nueva o es continuacin de otra.
FUOC PID_00147721
52
Seguridad en la red
SSL TLS prev la negociacin de algoritmos de compresin para los datos intercambiados, para compensar el trfico adicional que introduce la seguridad. Ni SSL 3.0 ni TLS 1.0, sin embargo, especifican ningn algoritmo concreto de compresin.
Conexiones consecutivas o simultneas Una situacin tpica en la que se usa SSL TLS es la de un navegador web que accede a una pgina HTML que contiene imgenes: con HTTP "no persistente" (el nico modo definido en HTTP 1.0), eso requiere una primera conexin para la pgina y, a continuacin, tantas conexiones como imgenes haya. Si las conexiones pertenecen a la misma sesin SSL TLS, slo hay que hacer la negociacin una vez.
Extensibilidad. Al principio de cada sesin, cliente y servidor negocian los algoritmos que utilizarn para el intercambio de claves, la autenticacin y el cifrado (adems del algoritmo de compresin). Las especificaciones de los protocolos incluyen unas combinaciones predefinidas de algoritmos criptogrficos, pero dejan abierta la posibilidad de aadir nuevos algoritmos si se descubren otros que sean ms eficientes o ms 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 bsicamente de negociar los parmetros de seguridad y transferir los datos de la aplicacin. Tanto los datos de negociacin como los de aplicacin se intercambian en mensajes. En la subcapa inferior, estos mensajes son estructurados en registros a los cuales se aplica, segn corresponda, la compresin, la autenticacin y el cifrado.
Estructura de la capa SSL/TLS
FUOC PID_00147721
53
Seguridad en la red
El protocoloderegistrosSSLTLS es el que permite que los datos protegidos sean convenientemente codificados por el emisor e interpretados por el receptor. Los parmetros necesarios para la proteccin, como los algoritmos y las claves, se establecen de forma segura al inicio de la conexin mediante el protocolodenegociacinSSL/TLS.
El protocolo de negociacin SSL/TLS El protocolo de negociacin SSL TLS, tambin llamado protocolodeapretn demanos (Handshake Protocol), tiene por finalidad autenticar el cliente y/o el servidor, y acordar los algoritmos y claves que utilizarn de una manera segura, es decir, garantizando la confidencialidad y la integridad de la negociacin. Como todos los mensajes SSL/TLS, los mensajes del protocolo de negociacin se incluyen dentro del campo de datos de los registros SSL/TLS para ser transmitido al destinatario. La estructura de un mensaje de negociacin es la que se muestra en la figura siguiente.
Formato de los mensajes de negociacin SSL/TLS
El contenido del mensaje tendr unos determinados campos dependiendo del tipo de mensaje de negociacin de que se trate. En total hay 10 tipos diferentes, que veremos a continuacin en el orden en que se tienen que enviar. 1) Peticin de saludo (Hello Request). Cuando se establece una conexin, el servidor normalmente espera que el cliente inicie la negociacin. Alternativamente, puede optar por enviar un mensaje Hello Request para indicar al cliente que est preparado para empezar. Si durante la sesin el servidor quiere iniciar una renegociacin, tambin lo puede indicar al cliente envindole un mensaje de este tipo. 2)Saludodecliente(ClientHello). El cliente enva un mensaje Client Hello al inicio de la conexin o como respuesta a un Hello Request. Este mensaje contiene la siguiente informacin: La versin del protocolo que el cliente quiere utilizar. Una cadena de 32 bytes aleatorios18. Opcionalmente, el identificador de una sesin anterior, si el cliente desea volver a utilizar los parmetros que se le concedieron.
(18)
De los 32 bytes aleatorios que se envan en los mensajes de saludo, los 4 primeros tienen que ser una marca de tiempo, con precisin de segundos.
FUOC PID_00147721
54
Seguridad en la red
La lista de las combinaciones de algoritmos criptogrficos que el cliente ofrece utilizar, por orden de preferencia. Cada combinacin incluye el algoritmo de cifrado, el algoritmo de MAC y el mtodo de intercambio de claves.
La lista de los algoritmos de compresin ofrecidos, por orden de preferencia (como mnimo tiene que haber uno, aunque sea el algoritmo nulo).
Algoritmos criptogrficos previstos en SSL/TLS SSL TLS contempla los algoritmos criptogrficos siguientes: Cifrado: RC4, DES, Triple DES, RC2, IDEA y FORTEZZA (este ltimo slo en SSL 3.0). MAC: MD5 y SHA-1. Intercambio de claves: RSA, Diffie-Hellman y FORTEZZA KEA (este ltimo slo en SSL 3.0).
Algoritmos de compresin El nico algoritmo de compresin previsto en SSL TLS es el algoritmo nulo, es decir, ninguna compresin.
Si slo interesa autenticar la conexin, sin confidencialidad, tambin se puede usar el algoritmo de cifrado nulo.
3)Saludodeservidor(ServerHello). Como respuesta, el servidor enva un mensaje Server Hello, que contiene esta informacin: La versin del protocolo que se utilizar en la conexin. La versin 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 sesin actual. Si el cliente envi uno y el servidor quiere reanudar la sesin correspondiente, tiene que responder con el mismo identificador. Si el servidor no quiere reanudar la sesin (o no puede porque ya no guarda la informacin necesaria), el identificador enviado ser diferente. Opcionalmente, el servidor puede no enviar ningn identificador para indicar que la sesin actual ya no podr ser reanudada. La combinacin de algoritmos criptogrficos escogida por el servidor en la lista de las enviadas por el cliente. Si se reanuda una sesin anterior, esta combinacin tiene que ser la misma que se utiliz entonces. El algoritmo de compresin escogido por el servidor, o el que se utiliz en la sesin que se reanuda. Si se ha decidido continuar una sesin anterior, cliente y servidor ya pueden empezar a utilizar los algoritmos y claves previamente acordados y se saltan los mensajes que vienen a continuacin, pasando directamente a los de finalizacin de la negociacin (mensajes finished). 4)Certificadodeservidor(certificate)ointercambiodeclavesdeservidor (serverkeyexchange). Si el servidor puede autenticarse delante del cliente, que es el caso ms habitual, enva el mensaje certificate. Este mensaje normalmente
FUOC PID_00147721
55
Seguridad en la red
contendr el certificado X.509 del servidor, o una cadena de certificados. Si el servidor no tiene certificado, o se ha acordado un mtodo de intercambio de claves que no utiliza, tiene que enviar un mensaje server key exchange, que contiene los parmetros necesarios para el mtodo a seguir. 5)Peticindecertificado(certificaterequest) Tipo de certificados: En SSL TLS estn contemplados los certificados de clave pblica RSA, DSA o FORTEZZA KEA (este ltimo tipo slo en SSL 3.0). En el caso de que se tenga que realizar tambin la autenticacin del cliente, el servidor le enva 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 certificacin que el servidor reconoce. 6)Findesaludodeservidor(ServerHelloDone). Para acabar esta primera fase del dilogo, el servidor enva un mensaje Server Hello Done. 7)Certificadodecliente(Certificate) Cliente sin certificado: Si el cliente recibe una peticin 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 vaco. 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 cmo continuar el protocolo de negociacin. En primer lugar, si el servidor le ha pedido un certificado y el cliente tiene alguno de las caractersticas solicitadas, lo enva en un mensaje Certificate. 8)Intercambiodeclavesdecliente(ClientKeyExchange). El cliente enva un mensaje Client Key Exchange, cuyo contenido depende del mtodo de intercambio de claves acordado. En el caso de seguir el mtodo RSA, en este mensaje hay una cadena de 48 bytes que se utilizar como secretopre-maestro, cifrada con la clave pblica del servidor. Un posible ataque contra la negociacin es modificar los mensajes para que las dos partes acuerden utilizar el protocolo SSL 2.0, que es ms vulnerable. Para evitar este ataque, en los dos primeros bytes del secreto pre-maestro tiene que estar el nmero de versin que se envi en el mensaje Client Hello. Entonces, cliente y servidor calculan el llamado secretomaestro, que es otra cadena de 48 bytes. Para hacer este clculo, 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 simtrico de los datos (una para cada sentido: de cliente a servidor y de servidor a cliente).
FUOC PID_00147721
56
Seguridad en la red
Las dos claves MAC (tambin una para cada sentido). Los dos vectores de inicializacin para el cifrado, si se utiliza un algoritmo de bloque.
9)Verificacindecertificado(CertificateVerify). 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 concatenacin de todos los mensajes de negociacin intercambiados hasta ahora, desde el Client Hello hasta el Client Key Exchange. 10)Finalizacin(Finished). A partir de este punto ya se pueden utilizar los algoritmos criptogrficos negociados. Cada parte enva a la otra una notificacin de cambio de cifrado seguida de un mensaje Finished. La notificacin 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 notificacin de cambio de cifrado. Su contenido se obtiene aplicando funciones hash al secreto maestro y a la concatenacin de todos los mensajes de negociacin 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 sesin anterior, ser el servidor quien lo enve primero, justo despus del Server Hello. Una de las principales diferencias entre SSL 3.0 y TLS 1.0 est en la tcnica usada para obtener los cdigos de verificacin de los mensajes Finished, y tambin 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 cdigos HMAC). El contenido del mensaje Finished sirve para verificar que la negociacin se ha llevado a cabo correctamente. Este mensaje tambin 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 utilizarn en la comunicacin. Una vez enviado el mensaje Finished, se da por acabada la negociacin, y cliente y servidor pueden empezar a enviar los datos de aplicacin utilizando los algoritmos y claves acordados. Los siguientes diagramas resumen los mensajes intercambiados durante la fase de negociacin SSL TLS.
FUOC PID_00147721
57
Seguridad en la red
Negociacin de una sesin SSL/TLS nueva
Negociacin de una sesin SSL/TLS que se reanuda
FUOC PID_00147721
58
Seguridad en la red
Adems de los mensajes de negociacin, notificaciones de cambio de cifrado y datos de aplicacin, tambin se pueden enviar mensajes de error. Estos mensajes contienen un cdigo de nivel de gravedad, que puede ser "mensaje de aviso" o " error fatal", y un cdigo de descripcin del error. Un error fatal provoca el fin de la conexin y la invalidacin del identificador de sesin correspondiente, es decir, la sesin no podr ser reanudada. Tambin se puede enviar un mensaje de aviso para indicar el fin normal de la conexin. Para evitar ataques de truncamiento, si una conexin acaba sin haber enviado este aviso se invalidar su identificador de sesin. 5.5. Transacciones seguras en red Conviene conocer tambin diferentes iniciativas para permitir las transacciones seguras en internet. Presentamos las ms importantes. 5.5.1. Secure Electronic Transaction A raz 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 electrnico. En 1996 un grupo de empresas del sector financiero, informtico y de seguridad (Visa International, MasterCard, Microsoft, Nestcape, IBM, RSA, etc.) anunci el desarrollo de esta nueva tecnologa. Secure Electronic Transaction19 (SET) es un protocolo que permite dar seguridad en las transacciones por Internet que utilizan tarjetas de crdito. Sus especificaciones se pueden encontrar en el sitio web oficial de SETco, organismo encargado de homologar los mdulos de programacin 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 criptogrficos. Los primeros, para asegurar la perfecta identificacin de todas aquellas parejas que intervienen en una transaccin en lnea basada en el uso de tarjetas de pago, y los segundos, para proteger el envo de los datos sensibles en su viaje entre los diferentes servidores que participan en el proceso. Una de sus caractersticas 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, slo 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 transaccin.
Ejemplos de errores fatales Son ejemplos de errores fatales: MAC incorrecto, tipo de mensaje inesperado, error de negociacin, etc. (TLS 1.0 prev ms cdigos de error que SSL 3.0).
(19)
En castellano, transacciones electrnicas seguras.
Direccin web recomendada Podis acceder al histrico de la pgina web de SETco en: http://web.archive.org/web/ */www.setco.org
FUOC PID_00147721
59
Seguridad en la red
5.5.2. 3D-Secure 3D-Secure es un sistema promovido por Visa/Mastercard con la finalidad de incentivar el comercio electrnico, que intenta evitar los fraudes cuando el pago se realiza con tarjetas de crdito. 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 legtimas para efectuar la transaccin, 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 eleccin del "procedimiento de autenticacin". De esta manera, tienen flexibilidad para seleccionar el mtodo de autenticacin ms apropiado para sus comercios y titulares, y sustituirlo por nuevas soluciones cuando lo consideren conveniente. La confidencialidad e integridad de la informacin de pago se consigue con la utilizacin del protocolo SSL. El proceso de compra con 3D Secure funciona como una compra normal en un comercio en lnea, con la particularidad de que, a la hora de introducir la informacin de pago, el comprador tendr que facilitar la contrasea 3D-Secure-Secure. De esta manera, se confirma que es el propio titular de la tarjeta, y no un tercero sin autorizacin, quien efecta la transaccin.
FUOC PID_00147721
60
Seguridad en la red
Resumen
El mdulo ha hecho una introduccin a los conceptos bsicos de la seguridad en las redes de comunicacin. 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 ms que una red lgica o virtual creada sobre una infraestructura compartida, pero que proporciona los servicios de proteccin necesarios para una comunicacin segura. Las redes privadas virtuales (VPN) permiten utilizar la red pblica Internet como si fuera una red privada dedicada, por ejemplo, entre diversas intranets de una misma organizacin. La tcnica bsica que utilizan las VPN son los tneles, en los que los paquetes protegidos se encapsulan dentro de datagramas IP que circulan de manera normal por la red Internet. En este mdulo tambin hemos visto que las tcnicascriptogrficas permiten cifrar un texto mediante una clavedecifrado, y que basta con conocer la clavededescifrado correspondiente para ser capaz de obtener el texto original. Segn la relacin que haya entre las dos claves, los algoritmos criptogrficos se clasifican en algoritmossimtricos si la clave de cifrado y la de descifrado son la misma, y algoritmosdeclavepblica si las claves son diferentes. Los algoritmos simtricos, a su vez, se pueden clasificar en algoritmosdeflujo, si el cifrado consiste en aadir al texto datos pseudoaleatorios calculados a partir de la clave, o algoritmosdebloque,sielcifradosehacesobrebloquesde tamaofijodeltextooriginal. La particularidad de la criptografa de clave pblica es que, a partir de una de las claves, la claveprivada, se puede deducir fcilmente la otra, la clavepblica, mientras que la deduccin inversa es prcticamente imposible. Eso permite que todo el mundo que conozca la clave pblica de un usuario pueda utilizarla para cifrar datos confidenciales, con la seguridad que slo quien tenga la clave privada podr descifrarlos, sin necesidad de acordar ninguna clave secreta a travs de un canal aparte. El uso de las claves al revs (la privada para cifrar y la pblica para descifrar) es la base de las firmasdigitales. Como la criptografa de clave pblica es computacionalmente ms costosa que la simtrica, no se utiliza nunca directamente para obtener confidencialidad, sino siempre a travs de una clave de sesin simtrica. De la misma manera, la
FUOC PID_00147721
61
Seguridad en la red
firma de un texto no se calcula directamente a partir del texto, sino aplicando una funcin hash segura. La propiedad de este tipo de funcin es que es muy difcil encontrar un mensaje que d el mismo hash que otro. Despus de esta aproximacin ms terica y para concluir el mdulo se han presentado diferentes conceptos de seguridad de la red en los niveles de aplicacin 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 tpico de los protocolos SSL TLS es para proteger de manera transparente un protocolo de aplicacin como es HTTP. El protocolo HTTPS es simplemente la combinacin de HTTP con el transporte seguro SSL/TLS.
FUOC PID_00147721
63
Seguridad en la red
Bibliografa
Menezes, A. J.; Oorschot, P. C. van; Vanstone, S. A. (1996). Handbook of Applied Cryptography. Boca Ratn: CRC Press. SETco. Disponible en web. <http://web.archive.org/web/*/www.setco.org>. [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.
El nivel de aplicacin
Joan Manuel Marqus Puig Silvia Llorente Viejo
PID_00147724
FUOC PID_00147724
FUOC PID_00147724
ndice
Introduccin............................................................................................... Objetivos....................................................................................................... 1. Arquitecturas de aplicaciones distribuidas................................ 1.1. 1.2. 1.3. 1.4. 2. Cliente-servidor (client/server en ingls) ...................................... 1.1.1. 1.2.1. Aplicaciones basadas en la web ..................................... Aplicaciones de igual a igual ......................................... De igual a igual (peer-to-peer, en ingls) ...................................... Ventajas y desventajas de cliente-servidor y de igual a igual ...... Requerimientos de las aplicaciones ............................................
7 8 9 10 12 13 15 16 17 19 21 23 24 25 26 27 28 29 30 30 31 33 34 35 37 38 39 41 43 44 45 46 47 48 50
DNS: Servicio de nombres en Internet......................................... 2.1. 2.2. 2.3. 2.4. 2.5. DNS: base de datos jerrquica y distribuida ............................... Caching de DNS ........................................................................... Peticiones recursivas frente a peticiones iterativas ..................... Registros DNS .............................................................................. Consideraciones de seguridad .....................................................
3.
La web y el HTTP.............................................................................. 3.1. 3.2. HTTP: Hypertext Transfer Protocol.................................................. 3.1.1. 3.2.1. 3.2.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. Conexiones persistentes y no persistentes .................... Mensaje HTTP de peticin ............................................ Mensaje HTTP de respuesta ........................................... Formato de los mensajes HTTP ..................................................
HTTPS (HTTP seguro) .................................................................. Cookies ........................................................................................ Caractersticas de la demanda de pginas web ........................... Servidores intermediarios ............................................................ El GET condicional ..................................................................... Distribucin de contenidos ......................................................... 3.8.1. Redes de distribucin de contenidos .............................
4.
Transferencia de ficheros................................................................ 4.1. Seguridad en la transferencia de ficheros ...................................
5.
Correo electrnico en Internet....................................................... 5.1. 5.2. 5.3. SMTP ............................................................................................ Formato de los mensajes ............................................................ 5.2.1. Formato de mensajes MIME .......................................... Protocolos para acceder a los buzones de correo ........................
FUOC PID_00147724
5.3.1. 5.3.2. 5.3.3. 6.
POP3 ............................................................................... IMAP ............................................................................... Web ................................................................................
51 52 53
Aplicaciones de igual a igual para la comparticin de ficheros.................................................................................................. 6.1. 6.2. Redes superpuestas no estructuradas .......................................... Redes superpuestas estructuradas ................................................ 54 54 57 60 60 63 63 64 65 65 66 66 67 67 69 71 74 75 76 78 78 79 80 80 81 82 83 86 86 86 87 88 89 90 91 91 96
7.
Mensajera instantnea.................................................................... 7.1. XMPP ...........................................................................................
8.
Telnet y Secure Shell: acceso a ordenadores remotos............... 8.1. 8.2. Seguridad del protocolo Telnet ................................................... Secure Shell .................................................................................
9.
Aplicaciones multimedia en red.................................................... 9.1. 9.2. 9.3. Ejemplos de aplicaciones multimedia ........................................ 9.1.1. 9.2.1. 9.3.1. 9.3.2. Streaming de audio y vdeo almacenados ...................... Audio y vdeo en tiempo real interactivo ..................... Compresin de audio y vdeo ....................................... Formatos de audio y vdeo ............................................ Streaming en directo de audio y vdeo ........................................ Multimedia en Internet ..............................................................
10. Streaming de audio y vdeo almacenados................................... 10.1. Acceso va servidor de web ......................................................... 10.2. Real Time Streaming Protocol (RTSP) ............................................. 10.2.1. Los estados del RTSP ..................................................... 10.2.2. Diagrama de estados del cliente .................................... 10.2.3. Diagrama de estados del servidor .................................. 10.2.4. Mtodos RTSP ................................................................ 10.2.5. El protocolo RTSP .......................................................... 10.2.6. El mensaje de peticin RTSP ......................................... 10.2.7. El mensaje de respuesta RTSP ........................................ 10.2.8. Ejemplo de uso del protocolo RTSP .............................. 11. Protocolos para aplicaciones interactivas en tiempo real...... 11.1. Real Time Transport Protocol (RTP) ............................................... 11.1.1. Descripcin del RTP ....................................................... 11.1.2. La cabecera del RTP ....................................................... 11.2. Real Time Control Protocol (RTCP) ............................................... 11.2.1. Los paquetes RTCP ........................................................ 11.2.2. Uso del ancho de banda en el protocolo RTCP ............. 11.3. Session Initiation Protocol (SIP) ..................................................... 11.3.1. Funcionalidad del SIP .................................................... 11.3.2. El protocolo SIP .............................................................
FUOC PID_00147724
11.3.3. El mensaje de peticin SIP ............................................ 11.3.4. El mensaje de respuesta SIP ........................................... 11.4. H.323 ........................................................................................... 11.5. Skype ............................................................................................ 12. Anexos................................................................................................... 12.1. Anexo 1. El protocolo RTSP ........................................................ 12.1.1. rdenes .......................................................................... 12.1.2. Cdigos de estado .......................................................... 12.1.3. Cabeceras ....................................................................... 12.2. Anexo 2. El formato de los paquetes RTCP ................................ 12.2.1. Informe de emisor (SR) .................................................. 12.2.2. Informe de receptor (RR) ............................................... 12.2.3. Descripcin de elementos de la fuente (SDES) .............. 12.2.4. Paquete de cierre (BYE) ................................................. 12.2.5. Paquete definido por la aplicacin (APP) ...................... 12.3. Anexo 3. El protocolo SIP ........................................................... 12.3.1. Cdigos de estado .......................................................... 12.3.2. Cabeceras ....................................................................... Resumen....................................................................................................... Bibliografa.................................................................................................
97 98 99 101 103 103 103 103 104 105 105 107 108 109 109 110 110 112 114 115
FUOC PID_00147724
Introduccin
En este mdulo didctico, se describe toda una serie de aplicaciones que utilizan Internet como medio de comunicacin y tambin los protocolos de comunicaciones que tienen asociados. Estas aplicaciones se conocen como aplicaciones distribuidas, ya que estn formadas por diferentes partes y cada una se encuentra en mquinas 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 ejecucin de algn tipo de operacin). En este mdulo, veremos en primer lugar algunos conceptos bsicos referentes a las aplicaciones distribuidas, y despus, una serie de aplicaciones distribuidas en Internet, cuyas caractersticas siguientes estudiaremos. Elmodelo: describimos los diferentes elementos que forman la aplicacin y sus caractersticas. Elprotocolo: exponemos las ideas principales del protocolo de comunicaciones de cada aplicacin. Elmodelodeinformacin: describimos el formato de informacin 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 comprensin.
FUOC PID_00147724
Objetivos
En este mdulo didctico, encontraris 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 implementacin de aplicaciones distribuidas. 2. Conocer las aplicaciones distribuidas ms utilizadas en Internet y entender los principios bsicos de funcionamiento de los protocolos de comunicacin que estas usan.
FUOC PID_00147724
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 mdulo:
Una aplicacin distribuida est formada por una coleccin de ordenadores autnomos enlazados por una red de ordenadores y soportados por un software que hace que la coleccin acte como un servicio integrado.
Una arquitectura de software determina cmo se identifican y se asignan los componentes del sistema; cmo interactan los componentes para formar el sistema; la cantidad y la granularidad de la comunicacin que se necesita para la interaccin, y los protocolos de la interfaz usada por la comunicacin. La arquitectura que hay que utilizar en cada caso depende de muchos factores. Ahora mencionaremos las caractersticas ms significativas que hay que considerar cuando se disea una aplicacin a escala Internet. La primera caracterstica es la grancantidadtantodeordenadorescomode usuarios que hay en Internet. Relacionado con esto, est la dispersin geogrfica de los mismos. La dispersingeogrfica afecta a la manera en la que los componentes del grupo perciben las acciones que pasan a la aplicacin. Por ejemplo, los usuarios de la aplicacin pueden percibir dos acciones que pasan en dos extremos opuestos del mundo en diferente orden, segn la proximidad de cada componente al componente generador de la accin. Segn la aplicacin, necesitaremos o no mecanismos para abordar estas situaciones. Una tercera caracterstica es laautonoma de los diferentes ordenadores que forman la aplicacin. Es muy habitual que diferentes partes de una aplicacin estn bajo dominios administrados por diferentes administradores. Relacionada con esta caracterstica est la seguridad. Cada organizacin tiene unas polticas de seguridad diferentes, como por ejemplo cortafuegos. Es preciso que las aplicaciones distribuidas que diseamos se puedan ejecutar teniendo en cuenta estas restricciones impuestas por los diferentes administradores. Una cuarta caracterstica es la calidaddeservicio. En una aplicacin distribuida a escala Internet, este es un aspecto fundamental que vendr muy condicionado por la latencia de la red, los cortes y otros fenmenos que le puedan afectar.
FUOC PID_00147724
10
Finalmente, estn 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 mdulo, trataremos las dos arquitecturas distribuidas ms utilizadas hoy da: cliente-servidor y de igual a igual . Hay otras arquitecturas distribuidas como el grid, la publicacin-suscripcin o el cdigo mvil, entre otras, que no trataremos en este material. 1.1. Cliente-servidor (client/server en ingls)
1 (1)
De igual a igual en ingls se denomina peer-to-peer o p2p.
En el modelo cliente-servidor hay dos tipos de componentes. Clientes: hacen peticiones de servicio. Normalmente, los clientes inician la comunicacin con el servidor. Servidores: proveen servicios. Normalmente, los servidores esperan recibir peticiones. Una vez han recibido una peticin, 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 pginas son los servidores. Los servidores pueden ser con estado o sin estado. Un servidor sin estado no mantiene ninguna informacin entre peticiones. Un servidor con estado puede recordar informacin entre peticiones. El alcance de esta informacin puede ser global o especfico de una sesin. Un servidor web con pginas web
FUOC PID_00147724
11
estticas es un ejemplo de servidor sin estado, mientras que un servidor que genere las pginas de manera dinmica (como la Intrauoc del Campus Virtual de la UOC) es un ejemplo de servidor con estado. Un servidor tambin puede ser cliente de otros servidores, tal y como se ve en la figura siguiente. Por ejemplo, una aplicacin de correo va web acta como servidor para el navegador y como cliente del servidor de correo que gestiona los mensajes del usuario en cuestin. Los servidores web y los otros servicios disponibles en Internet son clientes del servicio de resolucin de nombres (DNS). Un tercer ejemplo son los buscadores (search engines), que permiten a los usuarios acceder a sumarios de informacin de pginas 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 ingls, web crawlers), acceden a servidores de Internet buscando informacin. De hecho, un buscador incluir diferentes hilos de ejecucin, algunos sirviendo al cliente y otros ejecutando robots web.
Los servicios tambin se pueden implementar como diferentes procesos servidores que se ejecutan en diferentes ordenadores y que interactan 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 rplicas de los objetos en distintos ordenadores.
Ejemplo de particin de datos La web proporciona un ejemplo habitual de particin 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 reproduccin se usa para incrementar el rendimiento y la disponibilidad y para mejorar la tolerancia a fallos. Proporciona mltiples 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 pgina web que tiene en su navegador, se genera una peticin en el servidor que contiene la informacin. El servidor, al recibir la peticin, retorna la pgina pedida si la peticin era a una pgina, o retorna el resultado de ejecutar una aplicacin si el enlace corresponda a un cdigo para ejecutar (por ejemplo, CGI o Servlet). El navegador web proporciona a la aplicacin un entorno donde presentar la informacin. La comunicacin entre cliente y servidor se hace utilizando el protocolo HTTP. El resultado que retorna el servidor al cliente se enva en formato HTML, de manera que para el cliente web es totalmente transparente si accede a una pgina web o a una aplicacin 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 prctica totalidad de los ordenadores conectados hoy da a Internet), sin que sea preciso tener nada ms instalado en el ordenador local. El uso de estas arquitecturas tambin facilita el diseo de las aplicaciones, ya que no hay que implementar la comunicacin entre el cliente y el servidor (se utiliza el protocolo HTTP); y la parte de presentacin de la aplicacin se facilita mucho por el hecho de formatear el documento en HTML y aprovechar las funcionalidades que proporciona el navegador (como los intrpretes 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 ingls)
De una manera muy genrica, 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 comunicacin es simtrica.
En Internet, desde sus orgenes, ha habido sistemas y aplicaciones que se han comportado siguiendo la filosofa 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 paradigmtico son los mensajes Usenet.
Los mensajes Usenet Los mensajes Usenet (Usenet News en ingls) son un sistema global y descentralizado de grupos de discusin en Internet. Los usuarios leen y ponen mensajes que parecen correos electrnicos (se les denomina artculos) en un nmero determinado de grupos de noticias, que estn organizados formando jerarquas lgicas de temas (por ejemplo, informtica.linux.distribuciones o informtica.lenguajesProgramacin.tutoriales). Los mensajes se distribuyen entre un gran nmero de servidores, que almacenan y se reenvan 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 fenmeno de igual a igual empieza como tal a finales de los noventa, de la mano de Napster. En la poca de la explosin de Internet a partir de 1994, la vertiente de colaboracin que haba dominado Internet hasta aquel momento empez a perder protagonismo frente a la vertiente ms comercial, que impona la arquitectura cliente-servidor, liderada por la web como arquitectura estrella. Dentro de este contexto dominado por la centralizacin 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 haca pblica. De esta manera, el servicio de directorio saba, para cada igual, qu objetos tena disponibles para compartir. Cuando alguien buscaba una cancin, haca una peticin de la cancin al servidor, y este le contestaba la lista de nodos que tenan un ttulo similar. El usuario elega uno y se bajaba la cancin 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 (autonoma de los usuarios). La disponibilidad de un fichero depende de si los usuarios que lo tienen estn conectados al sistema (conectividad puntual o ad hoc en ingls). 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 (autoorganizacin).
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 cancin, 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 haca directamente entre el ordenador que buscaba la cancin y el que la ofreca. Esta manera de organizar grandes cantidades de informacin a escala Internet para facilitar la comparticin 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 discogrficas 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 raz del xito de la solucin, mucha gente se anim a hacer propuestas ms descentralizadas y que superasen las limitaciones de Napster. Gnutella es un ejemplo de esto: se basa en un algoritmo de inundacin 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 solucin 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 mano de las aplicaciones de comparticin de ficheros, pero hay otros tipos de aplicaciones. Skype es otro sistema tipo de igual a igual que es muy popular. Skype proporciona telefona en Internet. Utiliza un protocolo propietario de la implementacin del que se conocen pocas cosas. Funciona siguiendo una organizacin 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 estn detrs de un cortafuego o los problemas derivados del NAT (network address translation).
Ved tambin Las aplicaciones de igual a igual para la comparticin de ficheros como KazaA estn explicadas en el apartado "Aplicaciones de igual a igual para la comparticin de ficheros" de este mdulo didctico. Determinismo Por determinismo entendemos que diferentes ejecuciones de una misma operacin 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, segn el camino que haya seguido la consulta, nos diga que no lo ha encontrado, cuando s que est.
FUOC PID_00147724
16
Tambin hay otros sistemas de igual a igual para la comunicacin sncrona (como la mensajera instantnea), juegos, sistemas de procesamiento distribuido (como SETI@home) o software para la colaboracin (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 estn suscritos al proyecto y analiza datos de radiotelescopios, aprovechando las grandes cantidades de tiempo de procesamiento que los PC desperdician porque no hacen nada. Groove Groove es un sistema de igual a igual para facilitar la colaboracin y comunicacin en grupos pequeos. Proporciona herramientas para la comparticin de ficheros, la mensajera instantnea, el calendario, la gestin de proyectos, etc.
Bibliografa complementaria Encontraris ms informacin 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.
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 diseo de una aplicacin. Tambin se ha mencionado que hay otros paradigmas. Este esfuerzo de caracterizacin, 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 hbridos entre diferentes modelos. Cada aplicacin tiene sus necesidades y hay que utilizar las caractersticas que nos ofrece cada paradigma con el fin de construir una aplicacin 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. Adems, hablar de ventajas y desventajas es muy personal o depender de cada situacin. Lo que para alguien o en una situacin es una ventaja, para algn otro u otra situacin es una desventaja. Y al revs pasa lo mismo.
Cliente-servidor Ventajas Datos en los servidores, lo que facilita el control de la seguridad, control de acceso, consistencia de la informacin, etc. Hay muchas tecnologas 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 ms 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 centralizacin 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 slo ocurren de manera espordica o asumir que en ciertas situaciones puede haber congestin.
FUOC PID_00147724
17
Deigualaigual
Ventajas Descentralizacin: 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 hbrido) est repartido entre los usuarios. Escalable: dado que las operaciones se hacen directamente entre los iguales, el sistema puede soportar ms operaciones que si hubiera un nodo que centralizara las operaciones. Autoorganizacin: no hace falta que un componente del sistema supervise la evolucin 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. Tecnologa muy nueva. Aunque hay sistemas muy usados y que funcionan bien, las tcnicas utilizadas todava tienen que madurar. El dinamismo del sistema hace que el sistema sea utilizable slo si su disponibilidad satisface las necesidades de los usuarios. En la mayor parte de los casos, esto pasa por la reproduccin (tanto de informacin como de capacidad de procesamiento). Seguridad: a los problemas habituales de los sistemas distribuidos hay que aadir mecanismos para que la informacin que se aporte sea vlida, que no haya usuarios que obtengan informacin sin aportarla, etc. Estos aspectos todava no estn bien resueltos.
1.4. Requerimientos de las aplicaciones Las aplicaciones dialogan utilizando un protocolo de transporte. En terminologa de niveles, se dice que transporte ofrece unos servicios a aplicacin, o dicho al revs, la aplicacin requiere al nivel de transporte unas capacidades. En general, estas capacidades giran en torno a tres ejes. Transferencia fiable: algunas aplicaciones, como el correo electrnico o la transferencia de archivos, necesitan que la informacin 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 transmisin de voz o imagen en tiempo real que no necesita esta fiabilidad, porque si se pierde uno o varios paquetes, la reproduccin del sonido o la imagen original todava es posible, aunque con defectos aceptables. Ancho de banda: una transmisin de imagen en tiempo real necesita un ancho de banda concreto para que se pueda hacer de manera aceptable, pero el envo de un mensaje de correo electrnico se puede hacer con cualquier ancho de banda, por pequeo que sea. Temporizacin: las aplicaciones que permiten comunicaciones en tiempo real, ya sea con sonido, imagen o los dos, necesitan que el ritmo de recepcin de los paquetes sea constante, para que en recepcin se pueda reproducir el sonido o la imagen original de manera continua, tal y como se capt en origen. Por lo tanto, cada aplicacin 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 estn identificados de manera nica por su direccin IP. Las direcciones IP son difciles 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 traduccin 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 rpida. Para hacernos una idea del volumen de peticiones que debe ser capaz de gestionar el DNS, slo es necesario que nos fijemos en dos de las aplicaciones ms populares de Internet: la web y el correo electrnico. Cada vez que escribimos una direccin web en el navegador, este hace una consulta al DNS para saber a qu direccin IP corresponde. Y cada vez que enviamos un mensaje de correo electrnico, se hace una consulta al DNS para saber a qu servidor de correo hay que enviar el correo correspondiente al dominio de la direccin de correo electrnico. A continuacin, podemos ver los pasos que se siguen para que el ordenador del usuario pueda enviar una peticin de pgina web al URL www.uoc.edu/ eimt/index.html: 1) El ordenador del usuario es el que ejecuta la parte cliente de la aplicacin 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 aplicacin DNS. 3) El DNS cliente enva la peticin (que contiene el nombre del sitio web) a un servidor DNS. 4) En algn momento futuro el cliente DNS recibir la respuesta, que contiene la direccin IP correspondiente al sitio web. 5) Cuando el navegador recibe la direccin IP del DNS, puede iniciar la conexin TCP con el servidor HTTP ubicado en el puerto 80 de esta direccin IP. La figura siguiente muestra cmo el correo electrnico o el navegador interactan con el DNS.
(2)
En ingls, 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 notacin decimal.
(3)
El DNS est especificado en los RFC 1.034 y PFC 1.035 y actualizado en otros RFC.
FUOC PID_00147724
20
Os habris dado cuenta de que la pregunta al DNS introduce un retraso adicional a veces sustancial a la aplicacin Internet que lo invoca. Afortunadamente, como veremos ms adelante, la direccin IP est cacheada en algn DNS "cercano", lo que ayuda a reducir el trfico DNS en la red, as como el retraso medio del DNS. Otros servicios importantes que proporciona el DNS, aparte de los ya vistos de traduccin entre el nombre del ordenador y su direccin IP, son los siguientes. Alias: a veces interesa que un ordenador tenga ms de un nombre. En este caso, tiene un nombre que se denomina cannico, que es el nombre del ordenador, y despus tiene otros nombres que son sus alias. Estos alias normalmente son ms sencillos de recordar. En este caso, se puede invocar el DNS para obtener el nombre cannico del ordenador, as como su direccin IP. En el caso de la UOC, www.uoc.edu es un alias del nombre cannico www-org.uoc.edu. Aliasdelservidordecorreo: es importante que las direcciones de correo electrnico sean fciles de recordar. El nombre del servidor que gestiona el correo puede ser ms complicado de recordar y puede haber ms de un servidor que responda cuando se pide por un dominio determinado. De hecho, el campo MX permite que una institucin o empresa tenga el mismo nombre (un alias) para el dominio de correo electrnico y para el servidor web. Por ejemplo, en la UOC tanto el servidor web como el dominio de correo electrnico se denominan uoc.edu. Distribucindecarga: el DNS se usa tambin para hacer distribucin 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 direccin IP distinta. En este caso, una manera de repartir la carga entre los servidores es asociar un conjunto de direcciones IP a un nombre cannico. 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 enva la peticin a la primera direccin IP de la lista, se consigue una distribucin de carga entre los servidores.
Ved tambin Para saber ms sobre la distribucin de contenidos, podis ver el subapartado 3.8.
FUOC PID_00147724
21
Esta rotacin tambin se utiliza en el correo electrnico, y de este modo muchos servidores de correo pueden tener el mismo nombre. ltimamente, compaas de distribucin de contenidos como Akamai usan el DNS de maneras ms sofisticadas para proporcionar distribucin de contenidos web. Estas compaas utilizan el DNS para hacer que los usuarios se descarguen los contenidos de ubicaciones cercanas.
2.1. DNS: base de datos jerrquica y distribuida
El DNS es una base de datos jerrquica y distribuida organizada de manera autnoma, que proporciona un rendimiento a tiempo real a una audiencia global con contribuidores globales.
Un diseo sencillo para el DNS sera tener un servidor que contuviera todas las equivalencias entre nombres y direcciones IP. Los clientes enviaran las peticiones de resolucin al servidor DNS y este las contestara directamente. Esta solucin centralizada sera sencilla de implementar, pero tendra numerosos inconvenientes por el hecho de que actualmente en Internet hay millones de servidores. Sera necesario que tuviera una base de datos muy grande capaz de soportar un volumen de consultas muy grande, adems 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 (nmero de entradas y nmero de peticiones), el DNS usa muchos servidores organizados de manera jerrquica y distribuidos por todo el mundo. Ningn servidor DNS tiene todas las equivalencias entre nombres y direcciones IP. Estas equivalencias estn distribuidas en los diferentes servidores DNS. Hay tres tipos de servidores DNS. ServidoresDNSraz: hay trece servidores DNS raz (etiquetados de la A a la M). Cada uno de estos servidores raz en realidad es un clster de servidores reproducidos, por seguridad y fiabilidad. ServidoresDNSdeniveldedominiosuperior4: son los responsables de los dominios de primer nivel como org, com, net, edu o cat, as como de todos los dominios de pases (us, es, etc.). ServidoresDNSautorizados5: cada organizacin con ordenadores accesibles desde Internet tiene que proporcionar registros DNS accesibles pblicamente que permitan hacer la equivalencia entre los nombres de sus ordenadores y la direccin IP de estos. Un servidor DNS autorizado hospeda estos registros. Estos registros pueden estar en servidores DNS autoriza(4)
Direccin web recomendada En http://www.rootservers.org/ podis ver la ubicacin de los servidores DNS raz.
En ingls, top-level domain (TLD).
(5)
En ingls, authoritative DNS servers.
FUOC PID_00147724
22
dos de la propia organizacin o en servidores DNS autorizados de algn proveedor de servicios. En este caso, la organizacin tiene que pagar por este servicio. La mayora de las grandes empresas, universidades y centros de investigacin mantienen sus servidores DNS autorizados primario y secundario (backup).
Porcin de la jerarqua de servidores DNS
Hay otro tipo de servidores DNS, denominados servidoresDNSlocales, que aunque estrictamente no pertenecen a la jerarqua de servidores, son claves para la arquitectura del DNS. Cada empresa proveedora de acceso a Internet (PAI o ISP en ingls) como una universidad o una empresa de telecomunicaciones que proporciona acceso a Internet a usuarios domsticos tiene un servidor DNS local. Cuando un nodo se conecta a su PAI, este le proporciona la direccin IP de uno o ms servidores DNS locales (normalmente, esto se hace de manera automtica va DHCP). Cuando un ordenador hace una consulta al DNS, la consulta se enva al servidor DNS local, que acta como proxy, y este la enva a la jerarqua de servidores DNS para que resuelva la peticin.
DHCP Dynamic Host Configuration Protocol (DHCP) es un protocolo de red que permite a los nodos de una red IP obtener sus parmetros de configuracin de manera automtica. Se trata de un protocolo de tipo cliente-servidor. El cliente hace broadcast de una peticin para informacin de configuracin. El servidor DHCP recibe la peticin y responde con informacin de configuracin de su base de datos de configuracin. Generalmente, un servidor posee una lista de direcciones IP dinmicas y las va asignando a los clientes a medida que estas van estando libres, sabiendo en todo momento quin ha estado en posesin de aquella IP, cunto tiempo la ha tenido o a quin se le ha asignado despus. En el caso de no utilizar DHCP, cada ordenador de la red tiene que configurarse manualmente, tarea costosa y propensa a errores. Ejemplo de obtencin de direccin IP A continuacin, hay un ejemplo de los pasos que se seguiran para que el ordenador estudiante.pai.cat obtenga la direccin IP del ordenador sd.eimt.uoc.edu. 1)estudiante.pai.cat enva la peticin a su servidor DNS local. 2) El servidor DNS local reenva la peticin a un servidor DNS raz. 3) El servidor DNS raz retorna una lista de direcciones IP de servidores DNS responsables del dominio edu. 4) El servidor DNS local reenva la peticin a uno de estos servidores DNS TLD. 5) El servidor DNS TLD contesta la direccin 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 ingls, 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 tecnologas como DSL (normalmente ADSL), mdem de red telefnica conmutada, cable mdem, Wi-Fi, etc. Muchos PAI tambin ofrecen otros servicios relacionados con Internet como correo electrnico, hospedaje de pginas web, registro de dominios, etc.
FUOC PID_00147724
23
6) El servidor DNS local reenva la peticin al servidor DNS de la Universitat Oberta de Catalunya (dns.uoc.edu). 7) El servidor DNS de la Universitat Oberta de Catalunya responde la direccin IP del ordenador sd.eimt.uoc.edu. Peticiones DNS iterativas
Frecuentemente, sucede que el servidor TLD no conoce el nombre del servidor autorizado sino slo 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 peticin por un ordenador con el nombre acabado en eimt.uoc.edu, retorna a dns.pai.cat la direccin 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 preguntara, finalmente, a dns.eimt.uoc.edu la direccin IP de sd.eimt.uoc.edu. 2.2. Caching de DNS Como se puede ver, cada vez que se pide la resolucin de un nombre se envan 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 nmero de mensajes, el DNS hace caching. En el ejemplo de la ltima figura del subapartado 2.1, el servidor DNS local se guardara una copia de la direccin IP responsable del dominio uoc.edu. De esta manera, si al cabo de un rato recibe una peticin por un ordenador del dominio uoc.edu, ya preguntara directamente al servidor DNS autorizado por uoc.edu. El servidor DNS local tambin puede guardarse una copia de la direccin IP de los servidores TLD y ahorrarse preguntar a los servidores DNS raz. Dado que la equivalencia entre hosts y direcciones IP no es permanente, los servidores DNS descartan la informacin cacheada al cabo de un cierto tiempo (frecuentemente dos das). 2.3. Peticiones recursivas frente a peticiones iterativas El ejemplo de la ltima figura del subpartado 2.1 utiliza tanto peticionesrecursivas como peticionesiterativas. La peticin de estudiante.pai.cat a dns.pai.cat es recursiva, ya que pide a dns.pai.cat que no resuelva la equivalencia en ningn sitio suyo. Las otras tres consultas son iterativas, ya que las respuestas se retornan directamente a dns.pai.cat. En teora, las peticiones al DNS pueden ser recursivas o iterativas. La figura siguiente muestra la cadena de peticiones para el caso de una resolucin recursiva. En la prctica, la mayora de las peticiones siguen el esquema de la figura que hemos mencionado antes.
FUOC PID_00147724
25
Peticin DNS
2.4. Registros DNS Los servidores DNS almacenan registrosderecursos, que tienen los campos siguientes. Nombre. Valor. Tipo. Tiempo de vida6: el TTL es el tiempo mximo para que un recurso se borre de la cach. Los tipos ms usuales son los siguientes: A: Nombre es el nombre del ordenador y Valor es su direccin 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 cannico de un alias (nombre). Permite obtener el nombre cannico de un alias (por ejemplo, sd.uoc.edu, einfsun1.uoc.edu, CNAME).
(6)
En ingls, time to live (TTL).
FUOC PID_00147724
26
MX: Valor es el nombre cannico 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 ms sencillos. Tambin permite que una organizacin pueda tener el mismo alias para el dominio de correo que para el servidor web. Si se quiere obtener el nombre cannico 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 contaminacin de la memoria cach del DNS, que hace creer en un servidor DNS que ha recibido informacin autntica cuando en realidad no es as. Domain Name System Security Extensions (DNSSEC) modifica el DNS para aadir respuestas firmadas digitalmente, lo que proporciona a los clientes DNS (resolvedores) autenticacin del origen de los datos DNS, integridad de datos pero no disponibilidad ni confidencialidad y denegacin de existencia autenticada.
Contaminacin de la memoria cach del DNS La contaminacin de la memoria cach del DNS (DNS cache poisoning o DNS cache pollution en ingls) es una situacin 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 configuracin de los servidores DNS o por acciones malintencionadas que se aprovechan de la arquitectura abierta del DNS.
Extensin del DNSSEC A partir de julio del 2010, todos los servidores raz tendran 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 pginas escritas en hipertexto mediante el lenguaje de marcaje HTML y conectadas entre s mediante vnculos, de manera que formen un solo cuerpo de conocimiento por el cual se puede navegar fcilmente. Con un navegador web, se pueden visualizar pginas que pueden contener texto, imgenes, vdeos y otro multimedia y navegar de unas pginas a otras usando los hiperenlaces. La introduccin de la web a principios de los noventa supuso una revolucin en Internet. Internet dej de ser una red utilizada mayoritariamente por investigadores, acadmicos y alumnos de universidad para pasar a ser un medio de comunicacin, interaccin y publicacin de informacin que ha entrado a formar parte de nuestra cotidianidad.
HTML El Hyper Text Markup Language (HTML) es un lenguaje de marcaje diseado para estructurar textos y relacionarlos en forma de hipertexto. El World Wide Web Consortium (W3C) controla la evolucin del HTML: http:// www.w3.org.
La web se basa en tres estndares para funcionar: El Uniform Resource Locator (URL), que se encarga de dar una direccin 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 informacin entre el navegador y el servidor. El Hyper-text Markup Language (HTML), un mtodo para especificar cmo se tiene que ver esta informacin en el navegador.
En este mdulo nos centraremos en el HTTP. Antes, sin embargo, veremos los aspectos bsicos 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 cul es el recurso.
La sintaxis que se utiliza en el URL es: protocolo://[usuario:contrasea]@host[:puerto]/[camino], donde usuario:contrasea, el puerto y el camino son opcionales.
FUOC PID_00147724
28
Los protocolos ms habituales son: http, ftp (File Transfer Protocol) y file (para el acceso y la localizacin de archivos dentro de sistemas de ficheros). El host identifica la mquina donde est el recurso. Puede ser un nombre (www.wikipedia.org) o una direccin IP (192.12.34.11). El puerto es el nmero de puerto TCP del servidor, donde se conectar el navegador.
Ejemplo En la direccin http://www.empresa.com/producto/descipcion.html, http es el nombre del protocolo, www.empresa.com es la direccin del servidor de la empresa y /producto/descripcion.html es el camino hasta llegar al objeto en el servidor. En este caso no hay ningn puerto especificado, lo que quiere decir que se utiliza el puerto 80, que es el puerto por defecto de los servidores web.
Ved tambin El protocolo ftp se trata en el apartado 4 de este mdulo.
3.1. HTTP: Hypertext Transfer Protocol El HTTP7 es un protocolo a nivel de aplicacin para sistemas hipermedia colaborativos y distribuidos, que es la base de la web. El HTTP sigue el paradigma cliente-servidor. Clientes y servidores se intercambian mensajes HTTP. El HTTP define la estructura de estos mensajes y cmo el cliente y el servidor intercambian los mensajes. Se basa en un transporte fiable el ms habitual es TCP, aunque podra 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.
Ejemplo Una pgina que contiene texto en HTML y dos imgenes en GIF contiene tres objetos: la pgina HTML base y las dos imgenes.
(7)
El HTTP est definido en los RFC 1.945 y 2.616.
Una pginaweb 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 vdeo dirigible por un URL. La mayora de las pginas web consisten en un fichero base formateado en HTML que referencia a diferentes objetos.
La figura siguiente ilustra el funcionamiento de la interaccin entre un servidor web y unos clientes web: un cliente enva 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 tambin implementan otras partes, como el visualizador que formatea los documentos HTML y los presenta a los usuarios.
FUOC PID_00147724
29
Los servidores HTTP no mantienen ninguna informacin sobre los clientes, y por este motivo se dice que el HTTP es un protocolosinestado.
3.1.1. Conexiones persistentes y no persistentes El HTTP tiene dos modos de conexin. Conexionespersistentes: en el caso de las conexiones persistentes, se obra una conexin TCP diferente para enviar la peticin/respuesta para cada objeto que contiene la pgina que se quiere bajar (es decir, la peticin y respuesta de un mismo objeto viajan por la misma conexin). Conexionesnopersistentes: en el caso de las conexiones no persistentes, todas las peticiones y respuestas de los objetos de una pgina se envan por la misma conexin 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
Conexionespersistentes Despus de enviar una respuesta, el servidor deja Tarda ms en bajar los objetos de una pgina, ya abierta la conexin 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 pgina por separado. te y el servidor se pueden enviar por esta conexin TCP (ya se trate de objetos pertenecientes a la misma pgina o de diferentes pginas). Adems, no hace falta que esperen a que les toque el turno de ser servidas ya que la conexin ya est abierta. El servidor cierra la conexin TCP con el cliente cuando hace un rato que no se usa.
FUOC PID_00147724
30
Conexionesno persistentes
Ventajas Permite tener ms de una conexin en paralelo, lo que reduce el tiempo de respuesta.
Inconvenientes Hay que establecer ms conexiones: La bajada de cada objeto sufre un retraso, debido al tiempo de establecimiento de la conexin TCP y al tiempo de hacer la peticin del objeto. Para cada conexin hay que mantener informacin: 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 simultnea.
3.2. Formato de los mensajes HTTP A continuacin veremos los mensajes HTTP de peticin y respuesta. 3.2.1. Mensaje HTTP de peticin Seguidamente, presentamos el ejemplo de un mensaje de peticin HTTP.
GET /MiDirectorio/pagina.html HTTP/1.1 Host: www.servidor.edu
Como podis ver, el mensaje est escrito en ASCII. Cada lnea acaba con un carry return y un line feed. La ltima lnea est acabada con una lnea en blanco (una lnea que slo contiene un carry return y un line feed). Los mensajes pueden tener ms lneas. A la primera lnea se la denomina lneadepeticin. Las siguientes reciben el nombre de lneasdecabecera. La lnea de peticin tiene tres campos. El mtodo: puede tener diferentes valores GET, POST, HEAD, PUT, DELETE, etc. El mtodo ms usado es el GET. El mtodo GET se usa cuando el navegador pide un objeto. ElURL: identifica el objeto. En el ejemplo, se pide el objeto /MiDirectorio/pagina.html. Versin de HTTP: en el ejemplo, el navegador implementa la versin HTTP/1.1. La lnea de cabecera Host: www.servidor.edu indica en qu ordenador est el objeto. De entrada esta cabecera podra parecer superflua, pero es til para los proxy cache web. De manera ms general, en la figura siguiente encontraris el formato de los mensajes HTTP de peticin.
Ved tambin En el subapartado 3.6 se tratan los servidores proxy cache web.
FUOC PID_00147724
31
Es fcil ver que el formato de los mensajes de peticin sigue el ejemplo que hemos visto anteriormente, con una diferencia: el formato general contiene un "cuerpo". El cuerpo est vaco en el caso del mtodo GET, pero se utiliza con el mtodo POST. Los clientes HTTP acostumbran a utilizar el mtodo 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 pgina web a un servidor pero el contenido de la pgina web depende de lo que el usuario ha introducido en los campos del formulario. Si el valor del campo mtodo 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 envan usando el mtodo POST. Con frecuencia se usa el mtodo GET y los datos se incluyen en el URL. Por ejemplo, si un formulario que utiliza el mtodo 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 continuacin, 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. Unalneadeestado, que tiene, a su vez, tres partes: La versin del protocolo Un cdigo de estado El mensaje correspondiente al cdigo de estado
Ved tambin Veris en el subapartado 3.6 que la cabecera Last-Modified es una cabecera crtica para los servidores cach.
Unascabeceras. En el ejemplo anterior: Date: indica el da y la hora en los que se cre y envi la respuesta. No es el da 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 enva. Server: indica que el mensaje lo gener un servidor web Apache. Last-Modified: indica el da y la fecha en los que se cre o modific por ltima vez el objeto. Content-Length: indica el nmero de bytes del objeto que se enva. Content-Type: indica que el objeto que contiene el cuerpo es del tipo texto HTML.
Uncuerpo: contiene el objeto pedido.
En la figura siguiente, encontraris el formato general de los mensajes HTTP de respuesta.
Algunos cdigos de estado son los siguientes. 200 OK: la peticin ha tenido xito y la informacin se retorna incluida en la respuesta. 301 Moved Permanently: el objeto pedido se ha cambiado de ubicacin. El nuevo URL est especificado en la cabecera Location: del mensaje de respuesta. El cliente obtendr de manera automtica el nuevo URL.
FUOC PID_00147724
33
400 Bad Request: cdigo de error genrico que indica que el servidor no ha podido entender la peticin.
404 Not Found: el documento pedido no existe en el servidor. 505 HTTP Version Not Supported: el servidor no soporta la versin del protocolo HTTP pedido.
Mensaje HTTP de respuesta real Es muy fcil ver un mensaje HTTP de respuesta real. Slo hay que hacer un Telnet en un servidor web y despus teclear en lnea un mensaje pidiendo un objeto que est hospedado en el servidor. Podis 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 conexin TCP en el puerto 80 del servidor www.uoc.edu. A continuacin, se enva un mensaje HTTP de peticin (aunque no veis lo que estis escribiendo, se enviar una vez pulsis el retorno. Si os equivocis no sirve de nada borrar, ya que se enviarn todos los caracteres. Ser necesario que volvis a empezar). Recibiris un mensaje de respuesta que contendr el fichero HTML de la pgina que habis pedido. Recordad que hay que pulsar dos veces la tecla de retorno despus de teclear la ltima lnea.
(8)
3.3. HTTPS (HTTP seguro)
El Hypertext Transfer Protocol Secure (HTTPS) es una combinacin del HTTP con el protocolo SSL/TLS para proporcionar cifrado e identificacin segura del servidor. La idea principal tras el HTTPS es crear un canal seguro sobre una red insegura. Esto asegura una proteccin razonable frente a intrusos que quieran espiar la comunicacin 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 vctimas y hace pasar los mensajes entre estas a travs de l. Esto hace que las vctimas piensen que estn hablando directamente entre s a travs de una conexin privada cuando, en realidad, la conversacin est controlada por el atacante. Un ataque man-in-the-middle tiene xito slo cuando el atacante puede hacerse pasar por cada una de las vctimas. La mayora de los protocolos de cifrado incluyen alguna forma de autenticacin para evitar este tipo de ataques. Por ejemplo, el SSL autentica el servidor mediante una autoridad de certificacin en la que confan las dos partes.
El HTTPS confa en unas autoridades de certificacin que se venden preinstaladas en los navegadores web. A partir de aqu, las conexiones HTTPS son fiables si y slo si se cumple lo siguiente:
FUOC PID_00147724
34
El usuario confa en que la autoridad certificadora genera certificados para sitios web legtimos.
El sitio web proporciona un certificado vlido (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 confa en que el protocolo de cifrado usado (TLS o SSL) hace que no se pueda espiar la comunicacin.
3.4. Cookies El HTTP es un protocolo sin estado. Esto simplifica el diseo del servidor y hace que este tenga un rendimiento elevado, ya que es capaz de soportar miles de conexiones TCP simultneas. A veces, sin embargo, conviene que el servidor web pueda identificar a usuarios. Las cookies9 se usan para este propsito. Permiten a los servidores web tener informacin de los usuarios. Las cookies se pueden usar para autenticar, almacenar preferencias del cliente, identificar una sesin, 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 mayora de los sitios web comerciales usan cookies.
(9)
Las cookies estn definidas en el RFC 2.965.
Una cookie es una pequea porcin de texto almacenado en el ordenador del usuario por el navegador web, que consiste en una o ms parejas nombre-valor que contienen porciones de informacin.
El servidor web enva la cookie al navegador web como una cabecera de la respuesta. A partir de este momento, el navegador web enva 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 informacin 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 peticin 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 continuacin 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 conexin anterior a Youtube. El usuario contina navegando por el sitio web de la UOC. Cada vez que pide una pgina web, el navegador consulta el fichero de cookies y aade una lnea de cabecera a la peticin HTTP. Si el usuario vuelve al sitio web de la UOC unos das ms tarde, contina aadiendo la cabecera Cookie: en los mensajes de peticin.
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 mayora de los navegadores modernos permiten a los usuarios decidir si quieren aceptar o no las cookies de las pginas visitadas, pero la no aceptacin de estas puede hacer que algunas pginas web no funcionen correctamente. 3.5. Caractersticas de la demanda de pginas web Un servidor web puede tener miles de documentos y, sin embargo, recibir la mayora de las peticiones para un nico documento.
FUOC PID_00147724
36
(10)
LeydeZipf En muchos casos, la popularidad relativa entre diferentes sitios web o entre distintas pginas de un cierto sitio web se rige por la ley de Zipf10, que formulada de manera sencilla sera: muy pocos casos tienen mucha popularidad y muchos casos tienen muy poca.
La ley de Zipf debe su nombre a George Kingsley Zipf (19021950).
Distribucin 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 ms peticiones de las que puede servir: es un trfico en rfagas.
Evolucin del trfico entrante y saliente de un sitio web tpico durante una semana
Podis observar la gran variacin horaria y la reduccin de trfico durante el fin de semana.
Un servidor puede recibir avalanchas repentinas de trfico. Por ejemplo, por las estadsticas del servidor web que se ve en la figura siguiente sabemos que, despus de ser anunciado en la pgina de noticias Slashdot, sufri un exceso de visitas tan alto que el servidor se bloque.
Flash crowd Un cuento de ciencia ficcin de Larry Niven (1973) predijo que una consecuencia de un mecanismo de teletransporte barato sera que grandes multitudes se materializaran de manera instantnea en los lugares con noticias interesantes. Treinta aos despus, el trmino se usa en Internet para describir los picos de trfico web cuando un determinado sitio web se convierte repentinamente en popular y es visitado de manera masiva.
FUOC PID_00147724
37
Tambin 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 artculo del sitio web de noticias Slashdot (en castellano, Barrapunto). Peticiones web por hora, servidas por http://counter.li.org durante tres das
Se puede ver que mientras que el nmero habitual de operaciones (peticiones web) estaba por debajo de 500, subi rpidamente a unas 2.500, lo que provoc el fallo del sistema. Despus 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 direccin: 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 peticin. 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.
(11)
En ingls, web cache o proxy-cache.
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 peticin del usuario establecer una conexin TCP con el proxycache y le enviar la peticin HTTP.
FUOC PID_00147724
38
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 conexin TCP con el servidor origen de la peticin para pedirle el objeto. 4) Al recibir la peticin, el servidor origen enva el objeto en una respuesta HTTP al proxy-cache. 5) Finalmente, el proxy-cache almacena el objeto recibido en su disco local y enva una copia, en un mensaje HTTP de respuesta, al navegador cliente (en la conexin TCP establecida entre el cliente y el proxy-cache). El proxy-cache acta como servidor del cliente y como cliente del servidor. Los proveedores de acceso a Internet
12 (12)
son los que instalan los proxy-cache. Por
En ingls, Internet Service Providers (ISP)
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 trfico del enlace de la institucin con Internet. Los servidores intermediarios se usan tambin en otros protocolos adems del HTTP. En general, se sitan en una discontinuidad para hacer una funcin. Por ejemplo, para hacer un cambio de red: una mquina conectada a la red interna de una organizacin, que usa direcciones IPv4 privadas (por ejemplo, 10.*.*.*), y tambin a Internet, puede hacer de proxy-cache para la traduccin de direcciones IP entre las dos redes (NAT).
Network Address Translation (NAT) En los paquetes IP salientes: sustituir la direccin IP de las mquinas internas (no vlidas en Internet) por la suya propia; en los paquetes IP entrantes: sustituir su propia direccin IP por la de una mquina interna y reenviar el paquete hacia la red interna. Para saber a quin se tiene que entregar, el servidor intermediario debe asociar cada uno de sus puertos a las mquinas internas, ya que una direccin de transporte es una pareja (direccin 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
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 peticin GET, que se denomina GET condicional, indica al servidor que enve el objeto slo 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 lnea 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 slo hara malgastar ancho de banda y la percepcin del usuario sobre el tiempo de respuesta. 3.8. Distribucin de contenidos Los mecanismos de proxy-cache son tiles para que una comunidad de usuarios que comparten una conexin a Internet puedan ahorrar ancho de banda y reducir transferencias repetitivas de objetos. Sin embargo, esta slo 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 garanta de que sus clientes dispondrn de un buen servicio con cierta independencia de la demanda. Cliente: podra usar una memoria cach para economizar recursos de la red. Cuando un contenido se encuentra en ms de un lugar, debera elegir
FUOC PID_00147724
40
el mejor servidor en cada momento. El original o una rplica "rpida" (o llevar el objeto a trozos desde distintos lugares al mismo tiempo). Rplica: si un servidor guarda una rplica de algn contenido, probablemente es porque quiere ofrecerlo y reducir la carga del servidor original. Por lo tanto debe ser "conocido" por sus clientes, pero adems el contenido tiene que ser consistente con el contenido original. Proveedordered: debera elegir el mejor camino para una peticin, va direccionamiento IP, va resolucin DNS (resolver nombres en la direccin IP ms prxima al cliente que consulte, aunque no es lo ms habitual), va servidores proxy-cache HTTP y evitar zonas congestionadas (hot spots) o flash crowd (congestin en el servidor y en la red prxima debida a una avalancha de demandas). En este subapartado, nos centraremos en los sistemas de distribucin de documentos para ayudar a mejorar el rendimiento de la web. Ms 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 informacin debe poner tantos recursos como audiencia pueda tener. Una opcin muy utilizada es que el proveedor del contenido disponga de diferentes rplicas de la informacin. Hay varios trucos para repartir peticiones entre los diferentes servidores que contienen las rplicas: Mirrors con un programa que redirige la peticin HTTP a la mejor rplica. Hacer que el servicio de nombres DNS retorne distintas direcciones IP. Normalmente, se enva la peticin HTTP a la primera direccin de la lista de direcciones IP recibidas del DNS. Si esta lista est ordenada de manera diferente en cada peticin al DNS (mtodo round roben), cada vez se har la peticin a una direccin 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 mquina interna menos cargada. Redireccionamiento a un nivel de aplicacin (conmutador de nivel 7, L7 switch): un encaminador que mira las conexiones HTTP y puede decidir con qu rplica contactar en funcin 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 peticin a uno o varios servidores internos.
Rplica Una rplica (en ingls, mirror) es una copia exacta de otro lugar de Internet. Los mirrors proporcionan mltiples fuentes para una misma informacin y son especialmente tiles por la fiabilidad que esto comporta. Tambin para que el usuario acceda a la ubicacin ms prxima o para repartir la carga entre diferentes servidores.
3.8.1. Redes de distribucin de contenidos Han surgido empresas que se han dedicado a instalar mquinas en muchos lugares del mundo y algoritmos para decidir qu mquina es la ms adecuada para atender las peticiones, segn la ubicacin 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 puede responder a demandas de contenidos extraordinariamente altas. Estos sistemas se denominan redes de distribucin 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 situacin de la Red para hacer que cada cliente web obtenga el contenido solicitado desde el servidor ms eficiente de la CDN (habitualmente una combinacin del ms prximo, el menos cargado y el que tiene un camino con ms ancho de banda con el cliente). La CDN dispone de un gran nmero 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 segn la ubicacin de la direccin IP del cliente. El servidor web: cuando se pide una pgina web, se reescriben los URL internos segn la ubicacin de la direccin IP del cliente. Cuando se pide un objeto a la direccin IP de un servidor de la CDN, el conmutador (switch) de acceso a un conjunto de distintos servidores proxycache, o rplicas, puede redirigir la conexin al servidor menos cargado del grupo (todo el conjunto responde bajo una misma direccin 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 peticin de una pgina web con imgenes.
(13)
En ingls, Content Delivery Networks (CDN).
Akamai Se pueden encontrar diferentes empresas que ofrecen este servicio de redes de distribucin de contenidos. Akamai es la ms 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 pgina sobre msica. El servidor informa al navegador web que la pgina 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 peticin llega hasta el DNS autorizado por este dominio, que es un DNS de la empresa propietaria de la CDN. La CDN responde con la direccin IP del nodo de la CDN ms prximo a la ubicacin del navegador web (que es el que hace la peticin para los contenidos) al DNS de la CDN. Esta "proximidad" se calcula a partir de informacin 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 slo para distribuir contenidos web. Tambin se usan para streaming de audio y vdeo, 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 diseado. Las CDN utilizan el DNS para redirigir las peticiones de manera transparente, pero este mecanismo de redireccin 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 transmisin de ficheros FTP14 permite transferir ficheros de un ordenador a otro. Funciona siguiendo el modelo cliente servidor sobre una conexin TCP/IP. En la figura siguiente, se puede ver el funcionamiento del FTP a grandes rasgos.
(14)
Siglas en ingls de File Transfer Protocol
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 revs.
El FTP utiliza dos conexiones entre el cliente y el servidor, una para los datos y otra para el control. La conexindecontrol usa el puerto TCP nmero 21 y se utiliza para enviar informacin de control, como el usuario y el password, comandos para cambiar de directorio o comandos para pedir y enviar ficheros. Esta conexin se mantiene abierta durante toda la sesin. La conexindedatos se utiliza para enviar los ficheros y se hace por el puerto TCP nmero 20. Se establece una conexin de datos para cada fichero. Una vez enviado, la conexin se cierra. En el caso de que se quiera enviar otro fichero, se abre una nueva conexin de datos.
El servidor FTP mantiene informacin de estado durante una sesin. El servidor tiene que asociar la conexin 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 envan codificados en ASCII y finalizados con un carriage return y un line feed. Las respuestas tambin acaban con un carriage return y un line feed. Los comandos consisten en cuatro caracteres ASCII en maysculas,
FUOC PID_00147724
44
algunos con argumentos opcionales. Algunos de los comandos ms usuales (estos comandos son del protocolo, no los comandos que el usuario pone en el intrprete de comandos de la aplicacin 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 enve la lista de ficheros del directorio remoto actual. La lista de ficheros se enva por una conexin 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 nmeros de tres dgitos 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
Bibliografa Acerca de las peticiones y las respuestas, encontraris ms informacin sobre los comandos y respuestas en el RFC 959.
4.1. Seguridad en la transferencia de ficheros La especificacin original del FTP es inherentemente insegura porque no tiene ningn mtodo para transferir datos de manera cifrada. Esto quiere decir que en la mayora 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 solucin habitual a este problema es usar SFTP15 o FTPS16.
IETF El SFTP fue diseado por la Internet Engineering Task Force (IETF) como una ampliacin del Secure Shell Protocol (SSH) versin 2.0.
(15)
SFTP es la abreviatura de SSH File Transfer Protocol o Secure File Transfer Protocol.
(16)
FTPS es la abreviatura de FTP sobre SSL.
El SFTP es un protocolo que proporciona acceso, transferencia y gestin de ficheros sobre un canal fiable. Normalmente se utiliza con el SSH, y el SSH es el que proporciona el canal fiable, aunque se podra 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 propsito.
FUOC PID_00147724
45
5. Correo electrnico en Internet
El correo electrnico existe desde los principios de Internet. En los aos sesenta los sistemas mainframe ya tenan formas de comunicacin uno a uno tipo mensajera, y a lo largo de los aos estos sistemas han ido evolucionando hasta llegar al nivel de sofisticacin y potencia actuales. Hoy da, es una de las aplicaciones ms importantes y usadas de Internet. En la figura siguiente, se presenta una visin del sistema de correo en Internet. Cuando un usuario quiere enviar un mensaje, el agente usuario de mensajera que est utilizando enva el mensaje a un servidor de correo. Este el servidor de correo origen pregunta al DNS la direccin correspondiente al campo MX del dominio destino del mensaje y enva el mensaje al puerto 25 de este servidor de correo va SMTP. La transmisin del mensaje se hace utilizando el protocolo TCP porque proporciona una transmisin fiable de los datos. Una vez el servidor destino ha aceptado el mensaje, lo almacena en el buzn del usuario destinatario para que ms adelante el usuario destinatario previa autenticacin de este lo lea va un agente usuario de mensajera. Debemos destacar el hecho de que el protocolo SMTP normalmente no utiliza ningn servidor intermediario entre el servidor origen ni el destino. La comunicacin se hace directamente aunque cada uno est en una punta del mundo.
Visin de alto nivel del sistema de correo electrnico en Internet
FUOC PID_00147724
46
En el caso de que el servidor origen no pueda enviar el mensaje al servidor destino por algn fallo, el servidor origen encola el mensaje y reintenta enviarlo ms tarde. Los reintentos se hacen normalmente cada treinta minutos. Si despus de algunos das 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 SimpleMailTransferProtocol (SMTP) est definido en el RFC 2.821 y es el estndar actual de transmisin de correo electrnico 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 envo de un mensaje A continuacin, ponemos el ejemplo del envo de un mensaje uoc.edu a upc.cat utilizando SMTP. El ejemplo muestra los comandos que se intercambian una vez la conexin fiable (la conexin TCP) ha sido establecida. Con el objetivo de clarificar la comprensin del ejemplo, los comandos que enva el cliente (originador) se han prefijado con C: y los del servidor (receptor) con S:. Tambin hemos numerado las lneas para poder referirnos a estos ms fcilmente. RFC del SMTP El primer RFC que describe el SMTP data de 1982 (RFC 821), pero antes de esta fecha ya haba versiones de lo que ahora es el SMTP.
1 S: 220 upc.cat 2 C: HELO uoc.edu 3 S: 250 Hello uoc.edu please to meet you 4 C: MAIL FROM: <marques@uoc.edu> 5 S: 250 marques@uoc.edu ... Sender OK 6 C: RCPT TO: <puig@upc.cat> 7 S: 250 puig@upc.cat ... 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 enva 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 dilogo, el cliente enva los comandos: HELO, MAIL FROM, RCPT TO, DATA y QUIT. El cliente enva el mensaje (lneas 10 a 11) despus del comando DATA y lo acaba con una lnea que slo contiene un punto (lnea 12: CRLF.CFLR), y que indica el final del mensaje enviado al servidor. El servidor contesta cada comando con un cdigo de respuesta y un texto opcional explicativo (en ingls).
FUOC PID_00147724
47
El protocolo SMTP usa conexiones persistentes. En el caso de que el servidor origen tenga ms de un mensaje para enviar al mismo servidor destino, los mensajes se envan aprovechando la misma conexin TCP. El cliente empieza cada mensaje con un nuevo MAIL FROM: uoc.edu, acaba cada mensaje con un punto en una lnea que slo contiene un punto y enva 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 electrnico tienen dos partes. Cabecera: incluye la informacin general del mensaje. Sera equivalente al sobre de la carta postal y est formada por varios campos cabecera. Cuerpodelmensaje: 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 semntica. Cada campo de la cabecera consta de un nombredelcampo seguido del carcter ":/, opcionalmente acompaado por un cuerpodelcampo, y acaba con un CRLF. Ejemplo de cabecera de un mensaje El ejemplo del subapartado 5.1 no contiene ninguna cabecera. En la continuacin repetimos el mismo mensaje, incluyendo la cabecera del mensaje. De este modo, primero encontramos la cabecera (lneas 10 a 13), seguida del cuerpo del mensaje (lneas 14 y 15). Tal y como se puede ver en la lnea 13, el separador entre la cabecera y el cuerpo del mensaje es una lnea 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.
Dilogo con el servidor SMTP Si tenis acceso a un servidor SMTP que no requiera autenticacin, vosotros mismos podis intentar dialogar directamente con el servidor SMTP. Para hacerlo, slo tenis que hacer: telnet nombreServidor 25, siendo nombreServidor el del servidor SMTP al cual os conectis. Al hacer esto, estis estableciendo una conexin TCP con el servidor SMTP. Podis repetir los comandos del ejemplo prefijados con C: y veris que se enva un mensaje de correo electrnico. (Intentad poner como recipiente una direccin de correo electrnico vuestra y recibiris el mensaje.)
1 S: 220 upc.cat 2 C: HELO uoc.edu 3 S: 250 Hello uoc.edu please to meet you 4 C: MAIL FROM: <marques@uoc.edu> 5 S: 250 marques@uoc.edu ... Sender OK 6 C: RCPT TO: <puig@upc.cat> 7 S: 250 puig@upc.cat ... Recipient OK 8 C: DATA 9 S: 354 Enter mail, end with "." on a line by itself 10 C: From: marques@uoc.edu 11 C: To: puig@upc.cat 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
FUOC PID_00147724
48
5.2.1. Formato de mensajes MIME Tal y como hemos dicho anteriormente, una limitacin 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 haca falta algn mtodo 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 mltiples 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 mdulo, nos centraremos en Content-Type: y Content-TransferEncoding::. Content-Type
(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.
Content-Type: indica al agente de usuario de mensajera receptor del mensaje qu tipo de contenido contiene el cuerpo del mensaje, lo que permite que este tome la accin 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 mensajera 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

Algunostipos text image audio video application Algunossubtipos plain, html jpeg, gif basic, mp4, mpeg mpeg, quicktime msword, octet-stream, zip
FUOC PID_00147724
49
La Internet Assigned Numbers Authority (IANA) mantiene la lista de tipos y subtipos. Podis 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 codificacin utilizado.
Ejemplo Content-Transfer-Encoding: base64 indica que se ha utiliza la codificacin base64 para codificar el cuerpo del mensaje. La codificacin 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 tcnica popular para codificar que tambin 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 ests?", donde: = delimita la secuencia codificada con quoted-printable. En este caso, hay delimitadas dos secuencias: Qu y ests? ? separa las partes. Codificado en ISO-8859-1. Q: codificacin quoted-printable. E9 es el cdigo correspondiente a en la codificacin ISO-8859-1
Cuando volvis a recibir un mensaje (frecuentemente reenviado) con una secuencia como esta ya sabris de dnde sale :-)
A continuacin, pondremos un ejemplo que incluir los diferentes aspectos vistos sobre el formato MIME:
FUOC PID_00147724
50
From: marques@uoc.edu To: puig@upc.cat Subject: Foto del nio 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 versin de MIME que se est utilizando.
La cabecera Content-Type: tambin se utiliza para que un mensaje pueda contener texto y ficheros adjuntos. En este caso, a la cabecera Content-Type: se le aade un indicador de inicio y final de cada parte (boundary).
S/MIME (Secure/Multipurpose Internet Mail Extensions) es un estndar para cifrado de clave pblica y firma de correo electrnico encapsulado en MIME. S/MIME proporciona: Autenticacin, 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 conectndose al servidor SMTP y ejecutando un programa para leer el correo. La mayora de los usuarios, sin embargo, leen el correo electrnico 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 aplicacin para que un agente de usuario de correo electrnico (el cliente) pueda obtener el correo de un servidor de correo remoto. El funcionamiento es muy sencillo. El cliente abre una conexin TCP con el servidor en el puerto 110. Una vez establecida esta conexin, el POP3 pasa por tres fases. 1)Autorizacin: el usuario enva un usuario y una clave de acceso (en claro) para autenticar al usuario. 2) Transaccin: 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 informacin sobre el buzn del usuario. 3) Actualizacin: ocurre despus de que el cliente ha ejecutado el pedido QUIT, que finaliza la sesin POP3. En este momento, el servidor borra los mensajes que se haban marcado para ser borrados.
(18)
El protocolo POP3 (Post Office Protocol versin 3) est especificado en el RFC 1939.
Los comandos son palabras clave, que pueden estar seguidas de argumentos, y que acaban con un salto de lnea (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 informacin adicional. +OK: el servidor indica al cliente que el comando recibido era correcto -ERR: el servidor indica al cliente que haba algo errneo en el comando recibido.
Ejemplo de una sesin de autenticacin El siguiente es un ejemplo de una sesin de autenticacin (una vez establecida la conexin al puerto TCP 110 del servidor de correo).
+OK POP3 server ready USER marques +OK PASS uoc +OK user successfully logged on
Conexin a un servidor de correo Si tenis acceso a un servidor de correo que no requiera utilizar una conexin segura, os podis intentar conectar con telnet servidorCorreo 110. El usuario puede configurar su agente de usuario utilizando POP3 para que aplique la poltica "baja los mensajes y brralos" o la poltica "baja los mensajes y deja copia de los mismos en el servidor".
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 lneas 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 enva el mensaje 1> . DELE 1 +OK message 1 deleted RETR 2 +OK 200 octets < el servidor de POP3 enva el mensaje 2> . DELE 2 +OK message 2 deleted QUIT +OK POP3 server signing off
Un problema del modo "baja los mensajes y brralos" 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 problemtico para usuarios que acostumbran a leer el correo desde diferentes ordenadores, por ejemplo el ordenador de casa, un ordenador porttil, 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 ms funcionalidades. Tambin es ms complejo de implementar, 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. Tambin 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 tambin 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 informacin entre sesiones IMAP: los nombres de las carpetas, qu mensajes estn asociados a cada carpeta, etc.
(20) (19)
El IMAP est especificado en el RFC 3.501.
IMAP es la abreviatura de Internet Mail Access Protocol.
FUOC PID_00147724
53
Otra caracterstica interesante del IMAP es que tiene comandos que permiten al agente de usuario obtener partes de un mensaje: puede obtener slo las cabeceras del mensaje, o slo una parte de un mensaje multiparte (por ejemplo, el texto del mensaje sin el fichero adjunto). Esto es especialmente til cuando se utiliza una conexin 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 buzn va 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 enva al servidor de correo usando tambin el protocolo HTTP.
FUOC PID_00147724
54
6. Aplicaciones de igual a igual para la comparticin de ficheros
La arquitectura de igual a igual es una manera de construir aplicaciones que persigue la utilizacin de los recursos informticos y el ancho de banda que aportan los usuarios de la aplicacin aunque estos estn conectados de manera intermitente. Las aplicaciones de igual a igual se han popularizado de la mano de las aplicaciones de comparticin 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 cmo funcionan estos tipos de aplicaciones. Cada una de estas aplicaciones utiliza su propia organizacin interna y sus propios protocolos. Los nodos que forman el sistema o aplicacin de igual a igual se organizan formando una red superpuesta (overlay network, en ingls) que funciona sobre la red fsica que conecta los nodos. Hay diferentes maneras de organizar esta red superpuesta, las cuales se pueden dividir en dos categoras: 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 topologa. Estos sistemas usan mecanismos de inundacin para enviar consultas mediante la red superpuesta. Cuando un igual recibe la pregunta, enva al igual que la ha originado una lista de todo el contenido que encaja con la pregunta. Aunque las tcnicas basadas en la inundacin 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 tamao 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 prximo subapartado pueda localizar de manera eficiente objetos y, adems, sea escalable, sufre sobrecargas significativamente mayores que los sistemas no estructurados por contenidos populares. Por este motivo, los sistemas descentralizados no estructurados se usan ms.
Bibliografa recomendada En el artculo de Luayotros (2005). "A survey and comparison of peer-to-peer overlay network schemes". IEEE Communications Surveys & Tutorials (vol. 7, nm. 2) encontraris un resumen de cmo funcionan las redes superpuestas de igual a igual ms populares, as como una comparativa entre estas. Tambin encontraris ms 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 topologa de iguales totalmente plana. Ha sido (y todava 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 ingls) para hacer las buscas ms eficientes, tal y como se muestra en la figura siguiente. La comunicacin 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 metainformacin que har las buscas ms 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 volmenes de datos sin que el originador de la informacin 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 informacin sobre el fichero: longitud, nombre, informacin de resumen (hashing information, en ingls) y el URL del tracker. El tracker (podis 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 enva un mensaje al tracker, que le contesta con una lista aleatoria de nodos que estn 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 informacin sin proporcionarla. De esta manera, a la hora de subir informacin, un igual elegir otro igual del que haya recibido datos.
Bibliografa complementaria Para ms informacin sobre el funcionamiento de BitTorrent, podis consultar el artculo 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 hbrido organizado en dos niveles para el almacenamiento de informacin. Est formado por clientes y servidores. Los servidores actan 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 ingls) para la deteccin de ficheros corruptos, comparticin parcial de ficheros mientras se bajan y mtodos expresivos para hacer buscas de ficheros. Para que un nodo se pueda conectar al sistema, es necesario que conozca un igual que acte como servidor. En el proceso de conexin, el cliente proporciona al servidor la informacin 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 implementacin de Kademlia, una red superpuesta estructurada (en el prximo apartado se explica cmo funcionan estos tipos de sistemas). 6.2. Redes superpuestas estructuradas La topologa 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 ms eficientes. Estos sistemas utilizan tablas de hash distribuidas (distributed hash tables o DHT, en ingls) como sustratos, en los cuales la ubicacin 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 recuperacin 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 descentralizacin de Gnutella como la eficiencia y garanta de localizar los resultados de Napster. Por este motivo, cada igual mantiene una tabla de direccionamiento pequea. Los mensajes se direccionan de una manera progresiva hacia los iguales a travs de caminos de superposicin. Cada nodo enva el mensaje al nodo de su tabla de direccionamiento que tiene un identificador ms prximo a la clave en el espacio de identificadores. Los diferentes sistemas basados en DHT tienen distintos esquemas de organizacin para los objetos de datos y su espacio de claves y estrategias de direccionamiento. En teora, 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 nmero de iguales en el sistema. El camino entre dos nodos en la red fsica 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 aplicacin que funcione por encima.
Ejemplos de redes superpuestas estructuradas Can, Chord, Tapestry, Pastry, Kademlia, DKS o Viceroy son ejemplos de redes superpuestas estructuradas. Podis encontrar ms informacin de estos sistemas en: CAN S.Ratnasamyyotros (2001). "A Scalable Content Addressable Network". Proc. ACM SIGCOMM (pgs. 161-72). Chord I.Stoica;R.Morrisyotros (2003). "Chord: A Scalable Peer-to-Peer Lookup Protocol for Internet Applications". IEEE/ACM Trans. Net. (vol. 11, nm. 1, pgs. 17-32). Tapestry B.Y.Zhaoyotros (2004, enero). "Tapestry: A Resilient Global-Scale Overlay for Service Deployment". IEEE JSAC (vol. 22, nm. 1, pgs. 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 (pgs. 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 (pgs. 183-92). Monterey, CA: EE. UU.
FUOC PID_00147724
59
eMule tiene una versin que funciona sobre la red Kad, que es una implementacin de Kadmelia. Kad mejora la localizacin de ficheros en la Red y la hace ms resistente a ataques a los servidores centrales.
FUOC PID_00147724
60
7. Mensajera instantnea
La mensajera instantnea es una forma de comunicacin textual en tiempo real entre dos o ms personas a travs de Internet o algn otro tipo de red. La mensajera instantnea se diferencia del correo electrnico en que el usuario percibe sincronismo en la comunicacin, aunque muchos de los sistemas de mensajera instantnea tambin permiten enviar mensajes a personas que en aquel momento no estn conectadas. En este caso, el destinatario recibir el mensaje cuando se vuelva a conectar al sistema. La mensajera instantnea permite una comunicacin efectiva y eficiente y consigue una recepcin inmediata de la confirmacin o la respuesta. Normalmente, las respuestas se pueden guardar y consultar con posterioridad. Frecuentemente, combinado con la mensajera instantnea o en torno a la misma tambin encontramos otras funcionalidades que la hacen an ms completa y popular, como cmaras de vdeo o la posibilidad de hablar directamente mediante Internet. En este apartado, sin embargo, nos centraremos en la mensajera instantnea textual. 7.1. XMPP El XMPP21 es un protocolo libre de mensajera instantnea de especificaciones abiertas basado en el XML, y que ha sido estandarizado por la IETF. Como se puede ver en la siguiente figura, el XMPP22 utiliza una arquitectura cliente-servidor descentralizada: de manera similar a como lo hace el SMTP, no hay un servidor central que coordine la mensajera. Los clientes no se comunican directamente unos con otros, lo hacen mediante los servidores. De manera similar al correo electrnico, cada usuario tiene una direccin nica formada por dos campos: un nombre de usuario (nico para cada servidor) seguido de la direccin DNS del servidor que hospeda al usuario, separados por el smbolo @, como nombre@dominio.com. 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 enva el mensaje a su servidor (en este caso, el servidor 3). a) El servidor 3 pide al DNS la direccin IP correspondiente al servidor 1.
Arquitecturas centralizadas Otros sistemas de mensajera instantnea como Windows Live Messenger o AOL Instant Messenger utilizan arquitecturas centralizadas.
(21)
XMPP es la abreviatura de Extensible Messaging Presence Protocol. El XMPP antes se conoca como jabber.
(22)
El puerto estndar para el XMPP es el 5222.
FUOC PID_00147724
61
b) Si el servidor 3 bloquea la comunicacin hacia el servidor 1, el mensaje se descarta. 2) El servidor 3 obra una conexin 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 ms adelante. 3) El servidor 1 entrega el mensaje al cliente 3.
Los puntos fuertes del protocolo XMPP son los siguientes. Descentralizacin: cualquiera puede tener un servidor XMPP. No hay un servidor centralizado que coordine la mensajera. Estndareslibres: la Internet Engineering Task Force tiene el XMPP aprobado como un estndar de mensajera instantnea y presencia (RFC 3.920 y RFC 3.921). Seguridad: los servidores XMPP se pueden aislar de la red XMPP pblica (por ejemplo, en la intranet de una compaa), y el ncleo de XMPP incluye seguridad (va SASL y TLS).
FUOC PID_00147724
62
Flexibilidad: por encima del XMPP, se pueden aadir funcionalidades a medida.
Al ser un protocolo abierto, cada usuario puede utilizar un cliente XMPP diferente, siempre y cuando cumpla las especificaciones del XMPP.
SASL El Simple Authentication and Security Layer (SASL) es un framework para la autenticacin y la seguridad de los datos en protocolos de Internet. Separa los mecanismos de autenticacin de los protocolos de aplicacin haciendo posible en teora que cualquier mecanismo de autenticacin soportado por el SASL se pueda utilizar en cualquier protocolo de aplicacin. Est especificado en el RFC 4.422.
Los puntos dbiles del protocolo XMPP son los siguientes. Overheaddelainformacindepresencia: en torno al 70% del trfico entre servidores XMPP es informacin de presencia, cuyo 60% es redundante. La informacin de presencia permite saber qu amigos o contactos hay conectados y, por lo tanto, es posible enviar mensajes instantneos. Lainclusindedatosbinariosesineficiente: XMPP se codifica como un nico documento XML. Para incluir datos binarios, estos se deben codificar en base64. Cuando hay que enviar cantidades considerables de datos binarios (por ejemplo, envo de ficheros), lo mejor es hacer el envo de manera externa al XMPP y utilizar mensajes XMPP para coordinarse.
Jingle Jingle es una ampliacin del XMPP para iniciar y gestionar sesiones multimedia entre dos entidades XMPP, de manera que sean interoperables con estndares 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 comunicacin bidireccional interactiva en el acceso a ordenadores remotos. Est basado en el protocolo de transporte TCP. En una comunicacin Telnet, normalmente se sigue el modelo cliente-servidor, es decir, el sistema usuario establece una conexin con el sistema proveedor, que est esperando peticiones de conexin en un puerto determinado. Se puede utilizar cualquier nmero de puerto para las conexiones y, de hecho, hay muchas aplicaciones que utilizan el protocolo Telnet para la comunicacin, cada una con su propio nmero. La aplicacin bsica, sin embargo, es establecer una sesin de trabajo interactiva con el sistema servidor. En este caso, el nmero de puerto utilizado es el 23. Esta sesin de trabajo en el ordenador remoto se hace va un terminal virtual. Para resolver el problema del control del terminal en la aplicacin 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 bsica, definida en la misma especificacin del protocolo. Cuando se establece la conexin entre el cliente y el servidor, inicialmente se supone que la comunicacin se produce entre dos NVT. Esto quiere decir que tanto el sistema cliente como el sistema servidor deben mapear sus caractersticas en las de un NVT y suponer que en el otro extremo de la conexin hay otro NVT. En el modo de operacin normal, cada terminal acepta datos del usuario y los enva mediante la conexin establecida al otro terminal, y acepta tambin los datos que llegan por la conexin y los presenta al usuario. La comunicacin 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 ningn dato enviado a travs de la conexin (ni las claves de acceso), y esto permite espiar la comunicacin y poder utilizar la clave de acceso as como cualquier otra informacin enviada ms adelante para usos malintencionados. La mayora de las implementaciones de Telnet no proporcionan autenticacin que asegure que la comunicacin se lleva a cabo entre los dos ordenadores deseados y no est interceptada por el camino.
(23)
La especificacin de Telnet se public en el ao 1983 en el estndar RFC 854.
Terminal virtual de red Un terminal virtual de red, en ingls Network Virtual Terminal (NVT), es un dispositivo imaginario por el cual se definen unas funciones de control cannicas, 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 solucin a la falta de seguridad del protocolo Telnet ha sido el protocolo Secure Shell (SSH).
Puerto TCP 22 El puerto estndar para contactar a un servidor SSH es el puerto TCP 22.
El SSH proporciona la funcionalidad de Telnet con los aadidos siguientes: a) Permite el cifrado para evitar que sea posible interceptar los datos que se envan. b) Permite la autenticacin con clave pblica para asegurar que el ordenador remoto es quien dice ser. El SSH tiene la debilidad de que el usuario debe confiar en la primera sesin con un ordenador cuando todava no ha adquirido la clave pblica del servidor.
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 electrnico, transferencia de ficheros, etc.). Si tenemos en cuenta dos de los requerimientos ms relevantes que tienen las aplicaciones de red, como son la tolerancia a prdidas 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 prdida de datos, se tiene que decir que las aplicaciones multimedia son muy tolerantes: las prdidas ocasionales de datos lo nico que hacen es que haya un salto en la imagen o en el sonido; sin embargo, si se contina recibiendo informacin, se puede continuar normalmente la comunicacin. 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 ms de unos centenares de milisegundos no sirven para nada en una aplicacin 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 caractersticas de alta tolerancia a prdidas y mucha sensibilidad al retraso hacen que las aplicaciones multimedia sean muy diferentes a las aplicaciones tradicionales, en las que es mucho ms importante que lleguen todos los datos (si falta alguna parte, la informacin 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 prximos 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 / vdeo almacenados, streaming en directo de audio / vdeo y audio / vdeo en tiempo real interactivo. Ninguna de estas aplicaciones cubre el caso en el que nos bajamos un contenido y despus 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 tambin Para una descripcin completa de los requerimientos de las aplicaciones en red, podis ver en este mismo mdulo el subapartado 1.4, "Requerimientos de las aplicaciones".
FUOC PID_00147724
66
9.1.1. Streaming de audio y vdeo almacenados En este tipo de aplicaciones, los clientes piden contenidos de audio y vdeo comprimidos almacenados en servidores. Estos contenidos pueden ser, por ejemplo, programas de televisin, vdeos caseros, canciones, sinfonas o programas de radio. Esta clase de aplicaciones tienen tres caractersticas distintivas. Contenidosalmacenados: el contenido multimedia est ya grabado y se almacena en el servidor. Como resultado, el usuario puede detener la reproduccin, 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 tcnica del streaming, la reproduccin empieza poco despus de haber hecho la peticin 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 ms bajo. Con esta tcnica evitamos el retraso que podemos tener si debemos bajarnos todo el contenido. Reproduccincontinua: una vez la reproduccin 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 aplicacin. La aplicacin de usuario debe recibir a tiempo los datos del servidor para poder hacer la reproduccin de manera correcta. Aunque esta aplicacin 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 continuacin.
9.2. Streaming en directo de audio y vdeo Este tipo de aplicaciones funcionan como el broadcast tradicional de radio y televisin un emisor transmite a muchos receptores, slo que se hace por Internet. Con este tipo de streaming se pueden recibir emisiones de radio y televisin en directo desde cualquier punto del mundo. Puesto que en el streaming de audio y vdeo la informacin no est almacenada, el usuario no puede tirar adelante la reproduccin del contenido recibido. Lo que s permiten algunas aplicaciones es parar la reproduccin e incluso ir hacia atrs (aunque esto ltimo slo 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 podran utilizar conexiones multicast (un emisor transmite a diferentes receptores en una nica conexin), la verdad es que se hacen mltiples conexiones unicast (una conexin para cada receptor). Se requiere una reproduccin continuada, pero los requerimientos de interactividad no son tan crticos como las aplicaciones interactivas en tiempo real y pueden aceptarse retrasos en el inicio de la reproduccin de hasta diez segundos. 9.2.1. Audio y vdeo en tiempo real interactivo Este tipo de aplicaciones permiten que los usuarios interacten 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 vdeo. Algunas de estas aplicaciones tambin permiten llevar a cabo llamadas telefnicas a telfonos fijos o mviles (haciendo un pequeo pago), como es el caso de Skype. El retraso permitido en estas aplicaciones no debe ser mayor que unos centenares de milisegundos. As pues, retrasos de ms de 400 milisegundos haran que una comunicacin de voz fuera prcticamente 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 garanta. Los protocolos de transporte TCP/UDP funcionan sobre IP, y por lo tanto tampoco pueden dar garantas de cundo llegar un determinado paquete a su destino. Por este motivo, el envo de datos multimedia por Internet es una tarea difcil de que ha tenido hasta ahora un xito limitado. En las aplicaciones de streaming de audio y vdeo almacenados, retrasos de entre cinco y diez segundos pueden ser aceptables. As pues, si no se produce un pico de trfico 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 vdeo 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 vdeo se deben reproducir con la misma temporizacin con la cual se grabaron, el
Direcciones web recomendadas Aplicaciones de audio y vdeo interactivo: Windows Messenger: http:/ / www.microsoft.com/windows/messenger/features.asp Google Talk: http:// www.google.com/talk/ intl/ se/ Skype: http:// www.skype.com/intl/es/
FUOC PID_00147724
68
jitter se tiene que eliminar antes de hacer la reproduccin 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) Aadir un nmero de secuencia a cada paquete de datos enviado. El emisor incrementa este nmero en cada paquete enviado. 2) Aadir un timestamp a cada paquete. El emisor pone en cada paquete el momento en el que se gener. 3) Retrasar la reproduccin del paquete en el receptor. El retraso en la reproduccin tiene que ser lo bastante grande como para garantizar que los paquetes se han recibido antes del momento de su reproduccin. Este retraso puede ser fijo o adaptativo a lo largo de la sesin. Los paquetes que no llegan antes del momento de su reproduccin se consideran perdidos y se descartan. Con estos tres mecanismos, se pueden utilizar dos tcnicas de reproduccin dependientes del retraso: retrasofijo o retrasoadaptativo en el momento de la reproduccin de los datos. El retraso fijo consiste en reproducir el paquete de datos exactamente x milisegundos despus de la creacin del paquete de datos. As pues, si el timestamp del paquete era t, su reproduccin 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 aplicacin, pero para telefona 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 prdida de paquetes y retrasos que tengamos durante la comunicacin. La manera de hacer esto es calcular el retraso de la red y la variacin del retraso e ir ajustando el retraso en la reproduccin 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 pequeos. Las aplicaciones multimedia funcionaran mejor en la red Internet si existiera la posibilidad de reservar una parte del ancho de banda para el envo de este tipo de informacin. Sin embargo, esto no parece que tenga que suceder, al menos de momento. Por esto, es necesario utilizar algn otro tipo de tcnicas, como por ejemplo usar UDP en lugar de TCP para el envo de los datos, introducir retrasos en el envo de los datos o, si se trata de streaming de contenidos almacenados, enviar datos de antemano (utilizando tcnicas de buffering) cuando la conexin lo permite. Incluso se puede enviar informacin redundante para mitigar los efectos de la prdida 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 tcnicas de recuperacin 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 ms, entonces esto ya no es posible. De todos modos, si se envan muchos paquetes redundantes hay ms retraso. La otra tcnica para hacer FEC es enviar los datos redundantes en un stream con calidad ms 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 ningn paquete y la experiencia del usuario es bastante buena. El interleaving consiste en que el emisor enva los paquetes en un orden diferente del de su reproduccin, para minimizar las prdidas en un grupo de paquetes. De esta manera se reducen las prdidas, pero no es una tcnica adecuada para audio y vdeo interactivo, por el retraso en la recepcin de los datos; sin embargo, s funcionara bien para audio y vdeo almacenados. La ventaja de esta tcnica es que no se necesita ms ancho de banda, ya que el stream enviado es el mismo. 9.3.1. Compresin de audio y vdeo Para enviar datos multimedia (audio y vdeo) por Internet es necesario digitalizar y comprimir estos datos. La razn por la cual hay que digitalizar los datos es muy sencilla: las redes de ordenadores transmiten bits; as pues, toda la informacin que se transmite tiene que estar representada con bits. La compresin es importante porque el audio y el vdeo sin comprimir ocupan mucho espacio, con el consumo de ancho de banda que esto implica. Eliminar la redundancia en las seales de audio y vdeo reduce en varios rdenes de magnitud el ancho de banda que se necesita para transmitir la informacin.
Elanchodebandanecesarioylacompresin Una imagen de 1.024 pxeles en la que cada pxel se presenta con 24 bits, 8 para los colores rojo, azul y verde necesita 3 MB sin compresin. Si se aplica una tasa de compresin de 1:10, tendremos que esta misma imagen necesita 300 KB para ser representada. Suponiendo que tuviramos que enviar las dos imgenes por un canal de 64 kbps, en el primer caso tardara 7 minutos en enviarse, mientras que en el segundo el tiempo de transmisin se reduce en un factor de 10.
FUOC PID_00147724
70
Compresin de audio La compresin de tipo PCM(pulsecodemodulation) se basa en la recogida de muestras de audio a una frecuencia determinada. El valor de cada muestra es un nmero real arbitrario. El valor de cada muestra se redondea a un determinado valor finito (tenemos un nmero de valores finitos para las muestras). Cada uno de estos valores se representa con un nmero finito de bits, que depende del nmero de valores que pueden tomar las muestras. Por ejemplo, si se tienen 256 posibles valores de muestras, utilizaramos 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 seal digital con una tasa de 64.000 bits por segundo. La seal digital puede descodificarse y convertirse de nuevo en una seal analgica, pero esta seal ser diferente de la seal analgica original como consecuencia del muestreo. Si se recogen ms muestras y se toman ms valores posibles para estas muestras, la seal analgica descodificada ser mucho ms parecida a la seal original. Aunque la velocidad de las conexiones en Internet ha mejorado (recordemos que un mdem proporcionaba una velocidad mxima de 56 kbps), la compresin de audio y vdeo es todava muy importante. As pues, podemos encontrar algunos ejemplos de compresin de voz con tasas de bits ms bajas como GSM (13 kbps) o G.729 (8 kbps). Para la compresin de sonido con calidad casi de CD, la tcnica ms popular es el estndar de compresin MPEG 1 Layer 3, ms conocido como MP3. Las tasas de compresin de MP3 suelen ser 96 kbps, 128 kbps y 160 kbps, con poca degradacin del sonido. Compresin de vdeo El vdeo es una sucesin de imgenes, transmitidas a una tasa constante, como 24 o 30 imgenes por segundo. Una imagen sin comprimir es una sucesin de pxeles, en la que cada pxel se representa con un nmero de bits que indican color y luminosidad. Hay dos tipos de redundancia en los vdeos 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 imgenes consecutivas. Para vdeo, los estndares de compresin MPEG son tambin los ms populares. Estos incluyen MPEG 1 para la compresin con calidad de CD de vdeo (1,5 Mbps), MPEG 2 para calidad de DVD (3-6 Mbps) y MPEG 4 para compresin orientada a objetos. Las tcnicas de compresin MPEG se basan en el hecho de explotar la redundancia temporal entre imgenes adems de la compresin
Ejemplos en el uso de la PCM Algunos ejemplos en el uso de la PCM son la codificacin de voz con 8.000 muestras/ segundo y 8 bits/muestra, lo que da una tasa de 64 kbps. El CD de audio tambin 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 estreo.
FUOC PID_00147724
71
que tiene en cuenta la redundancia espacial que ya proporciona JPEG. Otros estndares de compresin de vdeo son H.261 o Quicktime (este ltimo es un formato propietario de Apple). 9.3.2. Formatos de audio y vdeo Existen muchos formatos diferentes de audio y vdeo, y aqu presentaremos los ms conocidos y utilizados. Los formatos de vdeo ms 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 continuacin, hacemos un resumen de sus caractersticas principales. QuicktimeMovie: originalmente estaba pensado como formato de vdeo, pero ahora se puede utilizar para contener cualquier tipo de medio (imgenes, audio, vdeo, Flash, etc.). Es un formato propietario de Apple. Es posible hacer streaming de este formato utilizando algn servidor de streaming dedicado. Se puede simular tambin el streaming sobre HTTP si se utiliza FastStart, que hace que el vdeo se empiece a reproducir al mismo tiempo que se est bajando. RealMedia: es uno de los formatos ms utilizados para hacer streaming. Se trata de un formato propietario de la compaa Real Networks y hay que tener un sistema Real Media para poder hacer el streaming. Tambin permite hacer seudostreaming va HTTP. WindowsMedia: se trata del formato de vdeo 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 vdeo en directo. Audio/Video Interleaved: es un formato de vdeo creado tambin 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 despus reproducirlo. MPEG: formato estndar definido por el Moving Picture Experts Group (MPEG). Soporta tres tipos de informacin: audio, vdeo y streaming (que significa que soporta audio y vdeo sincronizados). Este formato ofrece una alta compresin con pocas prdidas. FlashVideo: es un formato de vdeo creado por Flash (.flv) que permite hacer streaming. Funciona con la aplicacin Flash Player, lo cual hace que no se necesite un reproductor dedicado para poder ver los vdeos. Adems,
Bibliografa recomendada Ms informacin sobre los formatos de audio y vdeo: J.Niederst (2006). Web Design in a Nutshell (3. ed.). Sebastopol: O'Reilly.
FUOC PID_00147724
72
permite las mismas caractersticas de interactividad que ahora ofrecen las animaciones hechas con Flash (ficheros .swf). Los formatos de audio ms 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 continuacin hacemos un resumen de sus caractersticas principales. WAV/AIFF: estos dos formatos tienen caractersticas muy similares. El Waveform Audio Format (.wav) fue originalmente diseado para los sistemas operativos Windows, mientras que el Audio Interchange File Format (.aiff) fue diseado para sistemas Apple. Ahora ya no se utilizan tanto, ya que hay otros formatos que ofrecen ms compresin 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 ms popular en la red Internet. Ofrece una muy buena calidad de sonido, al mismo tiempo que permite hacer una alta compresin de datos. Sigue el estndar MPEG-1 Nivel-III y se basa en comprimir la informacin partiendo de la percepcin auditiva de las personas. Se puede hacer streaming de este formato y tambin se puede bajar con HTTP o FTP. QuicktimeAudio: aunque el formato Quicktime est pensado para vdeo, tambin permite incluir audio. Este formato permite hacer streaming y seudostreaming con HTTP, adems 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 estndar para que los instrumentos musicales electrnicos se pudieran comunicar entre los mismos. No contiene informacin de audio, sino rdenes de cmo se tendran 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. RealMediaAudio: fue uno de los primeros formatos que permitan hacer streaming de audio mediante la Red. Necesita un servidor dedicado, el RealServer, que permite negociar el ancho de banda y la transmisin RTSP. Se puede hacer seudostreaming de este formato con un servidor HTTP, si hay un trfico limitado. WindowsMediaAudio: 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 aadir sonidos de fondo a las pginas HTML y, adems, da caractersticas de interactividad y animacin. En este caso, no hay retrasos en la reproduccin y, una vez bajado el fichero Flash, la interactividad y el sonido estn permanentemente disponibles.
FUOC PID_00147724
74
10. Streaming de audio y vdeo almacenados
Las aplicaciones de streaming de audio y vdeo se han popularizado en los ltimos aos por diferentes motivos. Por una parte, los usuarios tienen cada vez ms capacidad de almacenamiento y tambin redes con mayor ancho de banda, que permiten recibir la informacin multimedia pedida en un corto espacio de tiempo. Sin embargo, para recibir los datos de streaming hay que tener una aplicacin dedicada (lo que se conoce como media player o reproductor), que sea capaz de ofrecer las caractersticas siguientes. Descompresin: los datos audio y vdeo estn casi siempre comprimidos para ahorrar espacio de disco y ancho de banda. El reproductor deber descomprimir el audio y el vdeo a medida que se reciben. Eliminacindel 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 vdeo se tienen que reproducir con la misma temporizacin con la cual se grabaron, el jitter se debe eliminar antes de hacer la reproduccin. El receptor almacenar los paquetes por un corto periodo de tiempo para que sea posible eliminar el jitter antes de reproducir el stream. Correccindeerrores: a causa de los errores imprevisibles en la red, una parte de los paquetes se podra perder. Si se pierden demasiados paquetes, entonces la calidad del stream recibido es inaceptable. Algunas tcnicas para recuperar los datos perdidos son las siguientes. Reconstruir los paquetes perdidos mediante el envo de paquetes redundantes. Hacer que el cliente pida de manera explcita 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 vdeo almacenados. La primera consiste en utilizar un servidor de web tradicional, en el que el audio y el vdeo estn almacenados en el sistema de ficheros. La otra manera de recibir un stream es el uso de un protocolo de streaming especfico, como es el Real Time Streaming Protocol (RTSP).
FUOC PID_00147724
75
10.1. Acceso va servidor de web Desde el punto de vista de un servidor de web, los ficheros de audio y vdeo son objetos accesibles desde el servidor como cualquier otro tipo de fichero, como una pgina HTML o una imagen. As pues, el usuario utilizara su navegador para acceder al fichero de audio o vdeo. Este acceso establecera una conexin TCP con el servidor y, una vez establecida esta conexin, pedira el recurso (fichero de audio o vdeo) con un mensaje de peticin HTTP con la correspondiente orden HTTP (podra ser una orden GET). El servidor genera un mensaje de respuesta, en el que estar encapsulado el fichero pedido. La recepcin 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 cmo se producira esta comunicacin.
1) El usuario pide con su navegador un archivo multimedia (por ejemplo, haciendo clic en un enlace web). Esta peticin genera un mensaje de peticin HTTP. 2) El servidor busca el recurso en su sistema de ficheros y lo enva 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 enve 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 contina 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 informacin de dnde se encuentra el recurso multimedia del que se tiene que hacer streaming e incluso del tipo de codificacin. De esta manera, el navegador recibe un fichero de metadatos, que pasa al reproductor y este se encarga de conectar con la direccin contenida en el fichero de metadatos. As pues, el inicio de la reproduccin 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 vdeo. No hace el envo de los datos, aunque el envo de informacin de control en medio de la transmisin de datos es posible. Lo que hace el RTSP es de control remoto a travs 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 sesin tiene su identificador. Una sesin RTSP no est vinculada a una conexin de nivel de transporte. Esto quiere decir que, durante una sesin RTSP, se pueden abrir y cerrar tantas sesiones de transporte como sea necesario. Tambin se puede utilizar UDP como protocolo de transporte, un protocolo sin conexin. 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 versin 1.1 del protocolo HTTP), lo cual hace que se puedan aadir mecanismos de extensin para el HTTP que tambin se pueden aplicar al RTSP. Sin embargo, el RTSP es diferente del HTTP en un buen nmero de aspectos importantes.
Ved tambin Sobre el RTP, podis ver ms adelante el subapartado 11.1 de este mdulo didctico.
(24)
El RFC que define el RTSP es el 2.326.
FUOC PID_00147724
77
El RTSP introduce mtodos nuevos y tiene un identificador de protocolo propio (rtsp://).
Un servidor RTSP tiene que mantener el estado en la mayora 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 peticin del RTSP siempre contiene el URI absoluto. En el HTTP, el URI de peticin slo lleva la ruta absoluta al fichero y el nombre del servidor va en una cabecera aparte.
El protocolo soporta las operaciones siguientes. a) Recuperacin de datos del servidor de contenidos multimedia: el cliente puede pedir una descripcin de una presentacin va HTTP o cualquier otro mtodo. Si la presentacin se est emitiendo en multicast, la descripcin de esta contiene su direccin multicast y los puertos que se utilizarn. Si la presentacin se enva en unicast slo a este cliente, el cliente da el destino por motivos de seguridad. b) Invitacin 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 presentacin o para grabar todos o una parte de los datos transmitidos en la presentacin. Este modo es muy til para aplicaciones de enseanza distribuida. Muchos participantes pueden tomar parte en las mismas, pulsando los botones de control remoto. c) Aadir contenido a una presentacin 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 descripcin de una presentacin sera un ejemplo de lo que en la distribucin de contenidos mediante un servidor de web hemos denominado un fichero de metadatos. Este fichero contiene una descripcin de los streams que forman parte de la presentacin, incluyendo el lenguaje de codificacin y otros parmetros que ayudan al usuario a elegir la mejor combinacin de datos. Cada contenido (por ejemplo, el audio y el vdeo se podran transmitir en streams separados) tiene su propia URL, que apunta a un determinado contenido dentro de un determinado servidor. El fichero tambin describe los mtodos de transporte que se soportan. Adems de los datos del contenido, la descripcin de la direccin destino de la red y el puerto se tiene que determinar. Hay diferentes modos de operacin.
FUOC PID_00147724
78
1) Unicast: los datos se transmiten al origen de la peticin RTSP, en el nmero de puerto seleccionado por el cliente. 2) Multicast (el servidor elige direccin): el servidor selecciona la direccin multicast y el puerto. Este caso es el tpico para transmisiones de datos multimedia en directo. 3) Multicast (el cliente elige direccin): si el servidor participa en una conferencia multicast existente, la direccin multicast, el puerto y la clave de cifrado vienen dados por la descripcin 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. Tambin puede pasar que el RTSP funcione sobre conexiones TCP, mientras que los datos se envan por UDP. As pues, la transmisin de datos contina ocurriendo aunque no se enven 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 sesin 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 confirmacin al envo de la orden PAUSE estando en Playing o Recording. Los estados Playing y Recording indican que se ha recibido una confirmacin 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 enva. Las transiciones se producen cuando el cliente recibe una confirmacin 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 confirmacin 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 estn 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 enva confirmacin al cliente). Las transiciones se producen cuando el servidor recibe una orden y ha enviado una confirmacin positiva (la orden se indica en la flecha correspondiente).
FUOC PID_00147724
80
10.2.4. Mtodos RTSP Los mtodos RTSP siguientes son los ms 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 sesin RTSP. PLAY y RECORD: se inicia la transmisin de datos de un stream inicializado con SETUP. PAUSE: detiene temporalmente la transmisin de datos, sin liberar los recursos del servidor. TEARDOWN: libera los recursos asociados al stream. La sesin RTSP se borra del servidor. Los mtodos RTSP que modifican el estado de la sesin utilizan el campo Sesin de la cabecera RTSP, que veremos en el subapartado siguiente. Para consultar la lista entera de mtodos, podis ver el RFC del RTSP. 10.2.5. El protocolo RTSP En este subapartado veremos el protocolo RTSP, incluyendo el formato del mensaje de peticin y respuesta y los campos de cabecera. Muchas de las caractersticas del protocolo se heredan del HTTP, pero aqu haremos una descripcin 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 tendran 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 implementacin y ampliacin (slo hay que definir un nuevo mtodo o una nueva cabecera). A continuacin, veremos el formato de los mensajes de peticin y respuesta de RTSP. 10.2.6. El mensaje de peticin RTSP La figura siguiente muestra el formato del mensaje de peticin. Este mensaje consta de tres partes bien diferenciadas: la lnea de peticin, la cabecera de peticin y el cuerpo del mensaje.
La lnea de peticin tiene la forma siguiente:
OrdenRTSP [Espacio] URI-peticin [Espacio] Versin-RTSP [Salto lnea]
La orden RTSP indica qu orden del protocolo estamos utilizando. El URI-peticin identifica el recurso al cual queremos acceder, y la versin RTSP indica la versin del protocolo que estamos utilizando. [Espacio] es un espacio en blanco y [Salto lnea] est representado por los caracteres Salto de lnea (ASCII 10) y Retorno de carro (ASCII 13). El resto de los espacios en blanco se han puesto por claridad.
Ved tambin Los valores de las rdenes RTSP, as como el formato de la versin RTSP, estn explicados con detalle en el anexo 1.
Nombre-campo: [Espacio] valor-campo [Salto lnea]
La cabecera de peticin tiene tres partes: la cabecera general, la cabecera propiamente de peticin y la cabecera de entidad. El formato de todos los campos de las cabeceras es el siguiente: La cabecera general representa informacin general que es independiente de si el mensaje es de peticin o de respuesta.
FUOC PID_00147724
82
La cabecera de peticin contiene campos que slo tienen sentido para un mensaje de peticin.
La cabecera de entidad contiene informacin sobre el cuerpo del mensaje (que tambin se conoce como entidad).
Ved tambin Los valores que pueden tomar las cabeceras de entidad estn explicados con detalle en el anexo 1.
El cuerpo del mensaje lleva la informacin, si la hay, asociada a la peticin. 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 lnea de estado de la respuesta, la cabecera y el cuerpo del mensaje.
La lnea de estado de la respuesta tiene la forma siguiente:
Versin-RTSP [Espacio] Cdigo-Estado [Espacio] por Descripcin-Estado [Salto lnea]
La versin RTSP define la versin del protocolo que se est utilizando, el cdigo de estado define el xito o error en la peticin y la descripcin del estado es una descripcin textual del cdigo de estado. [Espacio] es un espacio en blanco y [Salto lnea] est representado por los caracteres Salto de lnea (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 tambin Los valores de los cdigos y las descripciones de estado estn explicados con detalle en el anexo 1.
FUOC PID_00147724
83
La cabecera general representa informacin general que es independiente de si el mensaje es de peticin o de respuesta. La cabecera de respuesta contiene campos que slo tienen sentido para un mensaje de respuesta. La cabecera de entidad contiene informacin sobre el cuerpo del mensaje (que tambin se conoce como entidad). El cuerpo del mensaje lleva la informacin, 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 encontraramos en una comunicacin real. En este ejemplo, el cliente establece una conexin TCP en el puerto 554 del servidor y enva la orden OPTIONS, indicando la versin del protocolo RTSP que utilizar. El servidor confirma esta orden con un mensaje 200 OK (indicando que ha ido bien). Este cdigo de respuesta es igual al equivalente en HTTP. Peticin del cliente:
Ved tambin Los valores que pueden tomar estas tres cabeceras estn explicados con detalle en el anexo 1.
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 enva 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 descripcin completa del contenido, en algn formato estandarizado por ejemplo, Session Description Protocol (SDP) o Multimedia and Hypermedia Experts Group (MHEG). Peticin del cliente:
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.
DESCRIBE rtsp://servidor.multimedia.com:554/videos/ video.html RTSP/1.0 Cseq: 2
FUOC PID_00147724
84
Peticin 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, adems de las lneas de peticin y respuesta, los mensajes llevan cabeceras que indican el nmero de secuencia del mensaje (Cseq) o las caractersticas de la entidad enviada (Content-type o Content-length). En el siguiente paso de la negociacin, el cliente enva 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 aade el identificador de sesin y sus puertos de transferencia. Despus de establecer la conexin, el cliente est listo para empezar a recibir el stream y enva la orden PLAY. Esta orden slo contiene el URL del contenido y el identificador de la sesin 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 enva la confirmacin de que ha recibido la orden y se para el envo RTSP. Peticin 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 vdeo. Este protocolo es complementario a otros protocolos de tiempo real, como SIP o H.323. 11.1.1. Descripcin del RTP El RTP funciona sobre el protocolo de transporte UDP. El emisor encapsula un trozo de datos (chunk, en ingls) dentro del paquete RTP, que tambin 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 aplicacin incluye RTP, ser ms fcil que pueda interoperar con otras aplicaciones multimedia. Por ejemplo, si dos fabricantes ofrecen un software de telefona sobre IP e incorporan RTP en su producto, la interconexin entre sus productos ser ms factible. El RTP no ofrece ningn 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 slo 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 cmara, un micrfono, etc.) su propio stream de paquetes. As pues, si dos usuarios quieren hacer una videoconferencia, se pueden abrir dos streams de audio y vdeo, uno en cada sentido para cada tipo de datos. La realidad es que los streams de audio y vdeo estn entrelazados, se envan como un nico stream y se establece una nica conexin para enviar los dos streams (audio y vdeo). El RTP forma parte del nivel de aplicacin (estara por encima del UDP, que es el nivel de transporte), pero tambin se puede ver como un subnivel dentro del nivel de transporte. En la figura siguiente se puede ver esta distincin de forma grfica:
Ved tambin En este subapartado 11.1 hablaremos del RTP, y en el 11.2 hablaremos del protocolo de control del RTP, el RTCP.
(25)
El RFC que define el RTP y el RTCP es el 3.550.
Ved tambin Los protocolos SIP o H.323 se vern ms adelante dentro de este mismo apartado.
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 estn presentes en todos los paquetes RTP, mientras que la lista de identificadores CSRC (Contributing Source) slo est presente cuando hay un mezclador. Los campos tienen el significado siguiente. Versin (V): 2 bits. Este campo identifica la versin RTP. La versin actual es la 2. Relleno (P): 1 bit. Si este bit est activado, el paquete contiene unos o ms octetos de relleno adicional en los datos. El ltimo octeto de relleno indica cuntos octetos se tienen que descartar, incluyendo el mismo. Esta tcnica puede ser necesaria para algunos algoritmos de cifrado que necesitan un tamao de bloque fijo. Extensin (X): 1 bit. Si est activado, la cabecera fija slo puede llevar una extensin. Nmero de CSRC (CC): 4 bits. Este campo contiene el nmero de identificadores CSRC que hay en la cabecera fija. Marcador (M): 1 bit. La interpretacin 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 estn enviando con RTP.
Nmero de secuencia: 16 bits. Este nmero se incrementa en uno cada vez que se enva un paquete de datos RTP y puede utilizarse para detectar prdidas 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 sincronizacin. Tiene que ser aleatorio para que dos fuentes de sincronizacin de una sesin 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 transmisin peridica de paquetes de control a todos los participantes en una sesin, utilizando el mismo mecanismo de distribucin 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 nmeros de puerto UDP diferentes. El RTCP lleva a cabo cuatro funciones bsicas: 1) Da informacin 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 congestin ofrecidas por otros protocolos de transporte. 2) Mantiene un identificador persistente a nivel de transporte de una fuente RTP, que se denomina nombre cannico o CNAME, ya que, en el transcurso de la comunicacin, 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 sesin. 3) Las dos funcionalidades anteriores necesitan que todos los participantes enven paquetes RTCP, aunque se tiene que controlar la tasa de envo por si hay un nmero elevado de participantes. Si cada participante enva los paquetes de control a todos los otros, cada uno puede observar independientemente el nmero de participantes. Este nmero sirve para calcular la tasa a la cual se envan los paquetes.
FUOC PID_00147724
89
4) La ltima funcin es opcional, y consiste en comunicar un mnimo de informacin de control de la sesin, como que se muestre la identificacin de un participante en la interfaz de usuario. 11.2.1. Los paquetes RTCP Los paquetes RTCP pueden transportar diferentes tipos de informacin de control. SR: informe del emisor (Sender Report, en ingls), para transmitir y recibir estadsticas de los participantes que son emisores activos. RR: informe del receptor (Receiver Report, en ingls), para recibir estadsticas de los participantes que no son emisores activos. Tambin se puede combinar con el SR para los emisores activos que tienen que informar sobre ms de 31 fuentes de datos (el mximo que se puede indicar en un paquete de tipo SR). SDES: elementos de descripcin de la fuente, incluyendo el CNAME. BYE: indica que se ha dejado de participar. APP: funcionalidades especficas de la aplicacin.
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 mltiple de 32 bits. Se incluyen campos para indicar la alineacin 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 ningn 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 recepcin de estadsticas (en SR o RR) se tiene que enviar tan frecuentemente como lo permitan las restricciones de ancho de banda para maximizar la resolucin de las estadsticas. 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 nmero de tipos de paquetes que pueden aparecer inicialmente en el paquete compuesto se tiene que limitar para aumentar el nmero 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 direccin mal o que no estn 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 validacin 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 vaco. RR adicionales: si el nmero 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 envo 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 conexin 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 envo de los paquetes RTCP a medida que aumenta el nmero de participantes en la sesin. El RTCP intenta mantener su trfico en el 5% del ancho de banda de la sesin. Veamos esto con un ejemplo.
Ved tambin El formato especfico de cada paquete RTCP se define en el anexo 2 de este mdulo didctico.
FUOC PID_00147724
91
Ancho de banda RTSP Si un emisor transmite a una velocidad de 2 Mbps, el RTCP intenta limitar su trfico en el 5% de estos 2 Mbps, que seran 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 trfico RTCP a una tasa de 75 kbps/R y el emisor enva a una tasa de 25 kbps. Los participantes (emisores o receptores) determinan el periodo de transmisin de un paquete RTCP calculando dinmicamente el tamao medio de paquete RTCP (en toda la sesin) y dividindolo entre el tamao 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 creacin y gestin de sesiones, entendiendo sesin como un intercambio de datos entre distintos participantes. La implementacin de las sesiones se hace difcil por el comportamiento de los que participan en las mismas: los usuarios cambian de localizacin, pueden tener distintas maneras de identificarse e intercambian diferentes tipos de datos, a veces de manera simultnea. Hay muchos protocolos que permiten trabajar con sesiones multimedia en tiempo real con las que es posible transmitir texto, audio o vdeo. El Session Initiation Protocol (SIP)26 trabaja en cooperacin 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 sesin que quieren compartir. Para localizar a los participantes de una sesin y para otras funciones, el SIP permite la creacin de una infraestructura de hosts (denominados proxy servers), a la que las aplicaciones de usuario pueden enviar peticiones de registro, invitacin 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 sesin establecida. 11.3.1. Funcionalidad del SIP El SIP es un protocolo de control de nivel de aplicacin que puede establecer, modificar y finalizar sesiones multimedia (conferencias). Como ejemplo de sesin, tenemos las llamadas telefnicas mediante Internet. El SIP tambin permite invitar a participantes a sesiones existentes, como por ejemplo las conferencias multicast. Tambin se pueden aadir y quitar contenidos multimedia de una sesin existente. Con SIP, los usuarios pueden tener un nico identificador externo, independientemente de su localizacin 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 finalizacin de comunicaciones multimedia. Localizacin del usuario: hace referencia al sistema final que se har para la comunicacin. Disponibilidad del usuario: indica si el usuario quiere participar en las comunicaciones. Capacidad de los usuarios: indica el medio y los parmetros del medio que se utilizarn. Inicio de la sesin: llamada, establecimiento de la sesin y parmetros a los dos extremos de la comunicacin. Gestin de la sesin: incluye la transferencia y finalizacin de sesiones, modificando los parmetros de la sesin 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 aplicacin multimedia entera. Por ejemplo, se pueden utilizar los protocolos RTP y RTCP para el transporte y control del envo 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 localizacin. Si estos datos consisten en una descripcin de sesin definida, por ejemplo con SDP, los extremos de la comunicacin pueden ponerse de acuerdo con los parmetros de la sesin. El SIP tampoco ofrece servicios de control de las conferencias, ni define cmo 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 prevencin de la denegacin de servicio, la autenticacin de usuarios y proxies, la proteccin 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 sesin SIP. Cada intercambio tiene al lado un nmero entre parntesis (n), para hacer de referencia en la explicacin del mismo. Tambin se muestran los dos servidores proxy que actan en nombre de Amalia y Cristina para facilitar el establecimiento de la sesin. Amalia llama a Cristina utilizando su identidad SIP, una especie de URI, denominado URI SIP. Un URI SIP es semejante a una direccin de correo electrnico; lo definiremos ms adelante, pero contiene un host y un nombre de usuario. En este caso, este URI es sip:amalia@bcn.cat, en el que bcn.cat es el dominio del proveedor de servicio de Amalia. El URI SIP de Cristina es sip:cris@vic.cat. Amalia puede haber escrito la direccin de Cristina o puede haberla elegido de un enlace o una agenda. Tambin existen los URI SIP seguros, que se denominan SIPS, como por ejemplo sips:cris@vic.cat. En este caso, se utilizara el Transport Layer Security (TLS)27 para proveer de una conexin segura y cifrada para transportar los mensajes SIP. El SIP se basa en un mecanismo de peticin/respuesta muy similar al modelo de transacciones HTTP. Cada transaccin consiste en una peticin que invoca un mtodo del servidor y, como mnimo, una respuesta. En este ejemplo, la transaccin empieza cuando Amalia enva una orden INVITE dirigida al URI SIP de Cristina. A continuacin, se muestra la informacin que llevara asociada la orden INVITE:
(27)
El RFC del TLS es el 4.346.
INVITE sip:cris@vic.cat SIP/2.0
FUOC PID_00147724
94
Via: SIP/2.0/UDP pc01.bcn.cat;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Cristina <sip:cris@vic.cat> From: Amalia <sip:amalia@bcn.cat>;tag=1928301774 Call-ID: a84b4c76e66710@pc01.bcn.cat CSeq: 314159 INVITE Contact: <Sip:amalia@pc01.bcn.cat> Content-Type: application/sdp Content-Length: 142
... Resto de datos SDP ...
El contenido del mensaje es el siguiente: La primera lnea contiene el mtodo, con el URI SIP origen y la versin de SIP. Las lneas siguientes son cabeceras, que contienen informacin sobre el origen y el destino de la comunicacin (From, To), la direccin donde Amalia quiere recibir las respuestas, indicada en Via, y algunos identificadores nicos. Cseq es un nmero de secuencia que se incrementa con cada nueva peticin. Contact contiene el URI SIP que representa la ruta directa hacia Amalia, formada por un nombre de usuario y el nombre de dominio. El nmero Max-Forwards indica el nmero mximo de saltos que puede dar esta peticin y, finalmente, Content-Type y Content-Length contienen informacin sobre el cuerpo del mensaje. Los parmetros especficos de la sesin no se definen con SIP, sino con otro protocolo, como el SDP, que no veremos aqu. Puesto que el telfono de Amalia no sabe dnde encontrar a Cristina o el servidor SIP de bcn.cat, enva 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 funcin es redireccionar las peticiones SIP en nombre de quien las enva. En este ejemplo, el proxy server recibe la peticin INVITE (2) y responde con una respuesta 100 (Trying) (3). Esto indica que la peticin se ha recibido bien y que se est intentando enviar INVITE a su destino. La respuesta SIP tiene la forma de un cdigo de 3 cifras y una frase descriptiva (como HTTP). El proxy server bcn.cat encuentra la direccin SIP del dominio vic.cat. De esta manera, consigue la direccin del proxy server de vic.cat y le reenva la orden INVITE (2). Este contesta con un 100 (Trying) (5), para indicar que est trabajando en servir la peticin. El proxy server consulta una base de datos para encontrar la direccin de Cristina y le enva la peticin INVITE (4) a su telfono SIP. Cuando el telfono recibe la peticin, suena para informar a Cristina de que est recibiendo una llamada. El telfono SIP indica que se est haciendo la llamada enviando un mensaje de tipo 180 (Ringing) (6), (7), (8), que llega hasta el telfono de Amalia. Cuando la respuesta llega al telfono de Amalia,
Ved tambin Se puede encontrar una lista completa de las cabeceras SIP en el anexo 3 de este mdulo didctico.
FUOC PID_00147724
95
este hace alguna indicacin de que est sonando el telfono en el otro extremo. En este caso, Cristina responde a la llamada, lo cual hace que se enve una respuesta de tipo 200 OK (9), (10), (11). Amalia enva un ACK (12). En este momento, hay que negociar los parmetros de la sesin con el protocolo SDP. A continuacin, se muestra cmo sera el mensaje de respuesta enviado por el telfono SIP de Cristina:
SIP/2.0 200 OK Via: SIP/2.0/UDP proxy03.vic.cat ;branch=z9hG4bKnashds8;received=192.0.2.3 Va: 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 <sip:cris@vic.cat>;tag=a6c85cf From: Amalia <sip:amalia@bcn.cat>;tag=1928301774 Call-ID: a84b4c76e66710@pc01.bcn.cat CSeq: 314159 INVITE Contact: <Sip:cristina@192.0.2.4> Content-Type: application/sdp Content-Length: 131
... Resto de datos SDP ...
El contenido del mensaje es el siguiente: La primera lnea contiene la respuesta, con la versin de SIP, el cdigo de respuesta y la descripcin. Las lneas siguientes son cabeceras. Via, From, Call-ID y Cseq se copian de la peticin INVITE (ahora hay distintas cabeceras de tipo Via para indicar la comunicacin 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 informacin sobre el cuerpo del mensaje. La sesin multimedia entre Cristina y Amalia ha empezado y pueden enviar los datos multimedia en el formato acordado. En general, estos paquetes seguirn una ruta diferente de la de los mensajes SIP. Durante la comunicacin, se pueden cambiar las caractersticas de la sesin volviendo a enviar una orden INVITE. Para acabar la sesin, Cristina enva una orden BYE (cuelga) (13). Este BYE se enva directamente al telfono 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 peticin y respuesta y los campos de cabecera. Muchas de las caractersticas del protocolo se heredan de HTTP, pero no se trata de una extensin. 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:
URI SIP En SIP, los URI (direcciones) pueden empezar con SIP o SIPS. El uso de SIPS indica que se tiene que establecer una conexin segura (con TLS) para llevar a cabo la comunicacin.
sip:user:password@host:port;uri-parameters?headers Ejemplo: sip:amalia@bcn.cat
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 mquina (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 direccin IP numrica. Se recomienda utilizar el nombre de dominio. port: el nmero de puerto al que se tiene que enviar la peticin. uri parameters: parmetros que afectan a la peticin que lleva el URI. Los parmetros se representan como nom-param=valor-param. Estn separados de host:port con punto y coma y entre estos tambin se separan con punto y coma. headers: campos de cabecera que se pueden incluir en la peticin representada por el URI. SIP es un protocolo basado en mensajes de texto. Esto facilita su implementacin y ampliacin. A continuacin, veremos el formato de los mensajes de peticin y respuesta SIP.
FUOC PID_00147724
97
11.3.3. El mensaje de peticin SIP La figura siguiente muestra el formato del mensaje de peticin. Este mensaje consta de tres partes bien diferenciadas: la lnea de peticin, la cabecera de peticin y el cuerpo del mensaje.
La lnea de peticin tiene la forma siguiente:
OrdenSIP [Espacio] URI-peticin [Espacio] Versin-SIP [Salto lnea]
El orden SIP indica qu orden del protocolo estamos utilizando. El URI-peticin identifica el recurso al que queremos acceder, y la versin SIP indica la versin del protocolo que estamos utilizando. [Espacio] es un espacio en blanco y [Salto lnea] est bien representado por los caracteres Salto de lnea (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 mtodo es la siguiente. REGISTER: permite registrar un recurso, para que despus se puedan llevar a cabo comunicaciones SIP. INVITE: permite iniciar una sesin por parte de un usuario. ACK: indica que se ha aceptado la peticin enviada con INVITE y que la sesin se ha establecido. CANCEL: permite cancelar una peticin ya enviada. Se genera un mensaje de error y se tiene que dejar de procesar la peticin. Slo se tendra que utilizar para cancelar un INVITE. BYE: permite finalizar la sesin. OPTIONS: permite pedir las caractersticas de un programa cliente o de un proxy server.
FUOC PID_00147724
98
La cabecera de peticin tiene tres partes: la cabecera general, la cabecera propiamente de peticin y la cabecera de entidad. El formato de todos los campos de las cabeceras es el siguiente:
La cabecera general representa informacin general que es independiente de si el mensaje es de peticin o de respuesta. La cabecera de peticin contiene campos que slo tienen sentido para un mensaje de peticin. La cabecera de entidad contiene informacin sobre el cuerpo del mensaje (que tambin se conoce como entidad). El cuerpo del mensaje lleva la informacin, si la hay, asociada a la peticin. 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 lnea de estado de la respuesta, la cabecera y el cuerpo del mensaje.
La lnea de estado de la respuesta tiene la forma siguiente:
Versin-SIP [Espacio] Cdigo-Estado [Espacio] por Descripcin-Estado [Salto lnea]
La versin SIP define la versin del protocolo que se est utilizando, y el cdigo de estado define el xito o error en la peticin y la descripcin del estado, que es una descripcin textual del cdigo de estado. [Espacio] es un espacio en blanco y [Salto lnea] est representado por los caracteres Salto de lnea (ASCII 10) y Retorno de carro (ASCII 13). El resto de los espacios en blanco se han puesto por claridad.
Ved tambin Los valores de los cdigos y descripciones de estado estn 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 informacin general que es independiente de si el mensaje es de peticin o de respuesta. La cabecera de respuesta contiene campos que slo tienen sentido para un mensaje de respuesta. La cabecera de entidad contiene informacin sobre el cuerpo del mensaje (que tambin se conoce como entidad). El cuerpo del mensaje lleva la informacin, 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 vdeo en tiempo real. Est dedicado a la transmisin de voz sobre IP (voice over IP VOIP, en ingls). Con H.323, es posible comunicar un equipo conectado a Internet con un telfono conectado a la red telefnica. H.323 incluye distintas especificaciones: Negociacin de codificaciones de audio y vdeo entre los extremos de la comunicacin. Cmo se envan los trozos de datos de audio y vdeo. H.323 obliga a utilizar RTP. Cmo los equipos se comunican con sus gatekeepers. Cmo los equipos conectados a Internet se conectan con los telfonos conectados a la red telefnica. El requerimiento mnimo de H.323 es que se debe soportar el audio, pero las caractersticas de vdeo son opcionales. De esta manera, los fabricantes pueden ofrecer unos equipos sencillos con las caractersticas de audio y dejar para equipos ms sofisticados la parte de vdeo. Para transmitir los datos de audio, se tiene que utilizar un estndar que utiliza PCM (G.711) para generar voz digitalizada tanto en 56 kbps como 64 kbps. Aunque el vdeo es opcional, en caso de que el terminal lo tenga, debe soportar como mnimo el estndar 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 Vdeo 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 slo se necesita si queremos conectar equipos que estn en una red diferente, como la red telefnica. El gatekeeper es un elemento opcional en la comunicacin entre terminales H.323. Sin embargo, es el elemento ms 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 podra 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: sealizacin, registro, control de admisin, transporte y codecs. Por otra parte, SIP slo se encarga de iniciar y gestionar la sesin, sin hacer ninguna imposicin en el transporte o los formatos de audio o vdeo soportados. H.323 fue definido por ITU (telefona), 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 estndar complejo, formado por muchas partes, mientras que SIP es mucho ms simple y, por lo tanto, ms fcil de implementar.
FUOC PID_00147724
101
11.5. Skype
Skype es un sistema de telefona peer-to-peer (P2P) que funciona sobre la red Internet. Es la competencia de estndares de transmisin de voz sobre IP (VoIP) como SIP o H.323. Fue desarrollada por el equipo que hizo KaZaa en el ao 2003. Se trata de una aplicacin 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 tecnologas P2P (descentralizado) para no tener problemas con cortafuegos o con la traduccin de direcciones (en ingls, Network Address Translation, NAT) y las mltiples medidas para que no se pueda reconocer el protocolo o el software que la implementan. La identificacin del usuario que llama est enmascarada cuando se hace una llamada. La diferencia principal entre Skype y otros servicios es que utiliza tecnologa P2P, mientras que el resto utiliza arquitecturas cliente-servidor. La implementacin de P2P que utiliza es FastTrack, implementada en la aplicacin KaZaa. La arquitectura que implementa FastTrack es una red superpuesta (overlay network, en ingls) con dos tipos de nodos: los nodos normales y los supernodos. Un nodo normal es un ordenador en el que se ha instalado la aplicacin 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 pblica 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. Todava 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, envo de mensajes y llamadas, etc.) se hace de manera totalmente descentralizada.
KaZaa KaZaa es una aplicacin P2P de descarga de contenidos que tuvo mucho xito hace unos aos. 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 fcilmente escalable cuando se tiene un gran nmero de usuarios sin necesidad de una estructura compleja. Las llamadas se envan a travs de otros usuarios de Skype en la red para facilitar la comunicacin cuando hay cortafuegos o NAT. Esto hace que los usuarios que se conectan directamente a la red (sin NAT) tengan ms trfico 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 direccin IP y el nmero 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 cdigo es cerrado y el protocolo propietario, lo que dificulta su interoperabilidad con otros sistemas.
FUOC PID_00147724
103
12. Anexos
12.1. Anexo 1. El protocolo RTSP
12.1.1. rdenes La tabla siguiente describe las rdenes RTSP:

Orden OPTIONS DESCRIBE ANNOUNCE SETUP PLAY PAUSE TEARDOWN GET_PARAMETER SET_PARAMETER REDIRECT RECORD Descripcin Permite al cliente pedir informacin sobre las opciones de comunicacin con el servidor. Recupera la informacin del contenido multimedia identificado por el URL que se enva con la orden. Si lo enva el cliente, se est indicando la descripcin de una presentacin. Si lo enva el servidor, se actualiza la informacin de la descripcin de la sesin en tiempo real. Especifica los parmetros del mecanismo de transporte. Se puede enviar a media sesin, para cambiar estos parmetros. Se indica al servidor que se debe iniciar el envo de datos. Se indica al servidor que se quiere parar temporalmente la recepcin de datos de la sesin. Se cierra la recepcin de datos. Pide el valor de un parmetro de la descripcin de la sesin. Enva el valor de un parmetro de la descripcin de la sesin. Se indica al cliente que se tiene que conectar a otro servidor. Se inicia la grabacin de datos de acuerdo con la descripcin de la presentacin.
12.1.2. Cdigos de estado Los cdigos de estado son de cinco tipos: 1XX, informativos, 2XX, peticin lograda, 3XX, redireccionamiento, 4XX, error en la peticin del cliente y 5XX, error en el servidor. Slo se han puesto los cdigos especficos de RTSP, el resto estn definidos en el RFC de HTTP.
Tipo de cdigo Informativo xito Valor 100 250 Descripcin El cliente puede continuar con la peticin. Poco espacio de almacenamiento. Puede suceder con la orden RECORD.
FUOC PID_00147724
104
Tipo de cdigo Redireccin Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorparteservidor
Valor 3XX 405 451 452 453 454 455 456 457 458 459 460 461 462 551 Los mismos que HTTP.
Descripcin
El recurso no puede ejecutar el mtodo pedido. El servidor no soporta alguno de los parmetros indicados en la peticin. La conferencia no se ha encontrado. No hay suficiente ancho de banda para recibir el contenido. La sesin no se ha encontrado. El mtodo no es vlido en el estado actual del protocolo. Un parmetro indicado en la cabecera no se puede procesar. El rango pedido est fuera de los lmites. Un parmetro que se quera modificar con SET_PARAMETER es slo de lectura. El parmetro no se puede aplicar al recurso. Slo se puede aplicar a un stream El parmetro no se puede aplicar al recurso. Slo se puede aplicar a una presentacin. El tipo de transporte no est soportado. El cliente no es accesible. Una opcin enviada a la cabecera no es soportada.
12.1.3. Cabeceras En la tabla siguiente, se describen las cabeceras del protocolo RTSP que son especficas de este protocolo. El resto estn definidas en el RFC de HTTP:
Cabecera Accept Allow Bandwidth Blocksize Cache-Control Conference Content-Length CSeq Expires If-Modified-Since Descripcin Tipos de contenidos aceptados en la presentacin. Mtodos RTSP soportados por el servidor. Ancho de banda calculado del cliente. Tamao 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 conexin entre esta conferencia y un stream existente. Longitud del contenido enviado en el cuerpo del mensaje. Nmero de secuencia en la sesin RTSP de pares peticin/respuesta. Momento en el que el contenido estar obsoleto. Se utiliza con SETUP y DESCRIBE. Si la descripcin no se ha modificado desde el momento indicado en esta cabecera, se envan datos.
FUOC PID_00147724
105
Cabecera Last-Modified Proxy-Require Require RTP-Info Scale Session Speed Transporte Unsupported
Descripcin ltima vez en la que se modific la descripcin del recurso. Parmetros que debe soportar un proxy. Sirve para preguntar al servidor qu opciones soporta. Indica parmetros especficos de RTP en una orden PLAY. Permite indicar si el contenido se quiere ver a velocidad normal, ms rpida o ms lenta. Identificador de la sesin. Pide que la transferencia de datos se haga a una determinada velocidad. Protocolo de transporte utilizado. Caractersticas 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 estn definidas por los perfiles. La primera seccin es la cabecera y tiene ocho octetos. Los campos son los siguientes. Versin (V): 2 bits. Identifica la versin de RTP y es la misma que para los paquetes de datos. La versin 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 informacin de control, pero que estn incluidos en la longitud del paquete. El ltimo octeto de relleno indica cuntos octetos se tienen que ignorar, incluido el mismo. En un paquete compuesto, slo se debe aadir relleno a los paquetes individuales. Contador de recepcin de informes (RC): 5 bits. El nmero de bloques de recepcin de informes que hay en este paquete. 0 tambin es vlido. 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 sincronizacin del creador de este paquete SR. La segunda seccin, la seccin 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 propagacin de la informacin 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. Nmero de paquetes enviados por el emisor: 32 bits. El nmero de paquetes RTP de datos transmitidos por el emisor desde que se inici la transmisin hasta el envo de este paquete. Nmero de octetos enviados por el emisor: 32 bits. Nmero total de octetos de datos (sin incluir cabeceras ni relleno) transmitidos en paquetes de datos RTP por el emisor desde que se inici la transmisin hasta el envo de este paquete.
FUOC PID_00147724
107
La tercera seccin contiene 0 o ms bloques de informes de recepcin, dependiendo del nmero de fuentes recibidas por este emisor desde el ltimo informe. Cada bloque contiene las estadsticas siguientes. SSRC_n (identificador de la fuente): 32 bits. El identificador de la fuente SSRC a la cual pertenece la informacin enviada en este bloque. Fraccin de prdidas: 8 bits. La fraccin de paquetes RTP perdidos por la fuente SSRC_n desde que se envi el ltimo paquete de tipo SR o RR. Nmero acumulado de paquetes perdidos: 24 bits. El nmero total de paquetes perdidos desde el inicio de la recepcin. Nmero de secuencia ms alto recibido: 32 bits. Los 16 bits ms altos contienen el nmero de secuencia ms alto recibido y el resto son extensiones al nmero de secuencia. Jitter entre llegadas: 32 bits. Una estimacin estadstica 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 envo de este paquete de informacin.
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 informacin del emisor (timestamps NTP y RTP y nmero de paquetes y octetos enviados) no est. 12.2.3. Descripcin 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 ms porciones, cada una de estas formada por elementos que describen la fuente identificada por la porcin. La primera seccin es la cabecera y tiene ocho octetos. Los campos son los siguientes. Versin (V), relleno (P) y longitud tienen el mismo significado que los definidos por el paquete SR. Nmero de fuentes emisoras (SC): 5 bits. El nmero de porciones SSRC/ CRSC por las cuales son contenidas en un paquete SDES. Tipo de paquete (PT): 8 bits. Contiene la constante 202. Cada porcin 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 nmero 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 cmo 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 ms fondos ya no estn activos. Los campos son los siguientes. Versin (V), relleno (P) y longitud tienen el mismo significado que los definidos por el paquete SR. Nmero de fuentes emisoras (SC): 5 bits. El nmero de porciones SSRC/ CRSC por las cuales son contenidas en un paquete SDES. Tipo de paquete (PT): 8 bits. Contiene la constante 203.
12.2.5. Paquete definido por la aplicacin (APP) La figura siguiente muestra los campos del paquete de tipo APP:
El paquete APP est pensado para que las aplicaciones aadan funcionalidad. Los campos son: Versin (V), relleno (P) y longitud tienen el mismo significado que los definidos por el paquete SR. Subtipo: 5 bits. Puede utilizarse para definir un subtipo de aplicaciones.
FUOC PID_00147724
110
Tipo de paquete (PT): 8 bits. Contiene la constante 204. 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 aplicacin: longitud variable. Este campo puede aparecer o no. Es directamente interpretado por la aplicacin y no por RTP. Tiene que ser mltiplo de 32 bits.
12.3. Anexo 3. El protocolo SIP
12.3.1. Cdigos de estado Los cdigos de estado son de 5 tipos: 1XX, respuestas provisionales, 2XX, peticin lograda, 3XX, redireccionamiento, 4XX, error en la peticin del cliente, 5XX, error en el servidor y 6XX, errores globales (especficos del SIP). Muchos de los cdigos de estado estn heredados del protocolo HTTP, pero tambin hay cdigos especficos del SIP. Los cdigos HTTP que no tengan sentido en SIP no se deben utilizar.
Tipo de cdigo Respuestasprovisionales Respuestasprovisionales Respuestasprovisionales Respuestasprovisionales Respuestasprovisionales xito Redireccin Redireccin Redireccin Redireccin Redireccin Redireccin Redireccin Valor 100 180 181 182 Descripcin Indica que el siguiente host (salto, hop, en ingls) ha recibido la peticin. Indica que la peticin INVITE se ha recibido en el otro lado y se avisa al usuario. La llamada se est redirigiendo. La llamada se ha puesto en la cola, porque el receptor de la llamada no est disponible. Informacin sobre el progreso de la llamada. La peticin ha ido bien. Indica que hay mltiples opciones en la localizacin de la direccin del usuario al que se llama. El usuario ha cambiado de direccin y se le tiene que llamar a la nueva direccin indicada en la cabecera Contact. El usuario ha cambiado de direccin y se le tiene que llamar a la nueva direccin indicada en la cabecera Contact. Se tiene que utilizar un proxy. La llamada no ha sido posible, pero hay servicios alternativos disponibles. Formato de peticin errneo. El usuario necesita autenticarse.
183 200 300
301
302
305 380 400 401
FUOC PID_00147724
111
Tipo de cdigo Redireccin Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorpartecliente Errorparteservidor Errorparteservidor
Valor 402 403 Reservado para uso futuro.
Descripcin
El servidor no quiere servir la peticin del cliente, aunque tena un formato correcto. El usuario a quien se ha llamado no se encuentra en el servidor. El mtodo pedido no se puede ejecutar para la direccin indicada. El recurso no es aceptable segn los valores enviados en la cabecera Accept. El cliente se tiene que autorizar delante de un proxy. El servidor no ha podido producir una respuesta a tiempo. El recurso ya no est disponible en el servidor. El tamao de la entidad enviada por el cliente es demasiado grande para que el servidor la pueda tratar. El tamao del URI es demasiado grande para que el servidor lo pueda tratar. El tipo de datos del contenido no est soportado por el servidor. La peticin no se puede servir, porque el esquema indicado en el URI del recurso no se reconoce. El servidor no reconoce las extensiones indicadas en la cabecera. Proxy-Require Los programas necesitan una extensin especfica para poder servir la peticin. El servidor rechaza la peticin, porque expira demasiado pronto. Se ha podido llegar hasta el servidor, pero el usuario al que se ha llamado no est disponible temporalmente. La transaccin no existe. Se ha detectado un bucle en la llamada. Se ha pasado el mximo de hosts indicados en la cabecera MaxHops. La direccin del usuario al que se ha llamado es incompleta. La direccin es ambigua. El usuario no acepta la llamada. La peticin se ha acabado con un CANCEL o un BYE. La peticin no es aceptable, por algn parmetro indicado. a la sesin Hay otra peticin pendiente. El cuerpo del mensaje lleva un tipo MIME que el servidor no puede tratar. Error interno del servidor, que hace que no pueda servir la peticin. El servidor no tiene implementada la funcionalidad necesaria para servir la peticin.
404 405 406 407 408 410 413
414 415 416
420
421 423 480
481 482 483 484 485 486 487 488
491 493 500 501
FUOC PID_00147724
112
Tipo de cdigo Errorparteservidor Errorparteservidor Errorparteservidor Errorparteservidor Errorparteservidor Errorgeneral Errorgeneral Errorgeneral Errorgeneral
Valor 502 503 504 505 513 600 603 604 606
Descripcin El servidor recibe un error cuando hace de proxy o gateway. El servicio est temporalmente no disponible. El servidor no recibe una respuesta de un servidor externo a tiempo. El servidor no soporta la versin del protocolo indicada por el cliente. El mensaje es demasiado largo para que el servidor lo pueda procesar. El usuario llamado no est disponible. El usuario llamado no quiere aceptar la llamada. El usuario llamado no existe. La peticin no es aceptable, por algn parmetro indicado en la sesin.
12.3.2. Cabeceras En la tabla siguiente se describen las cabeceras del protocolo SIP que son especficas de este protocolo. El resto estn definidas en el RFC de HTTP:
Cabecera Alert-Info Allow Authentication-Info Authorization Call-ID Call-Info Contact Content-Disposition Content-Encoding Content-Length Cseq Date Error-Info Expires From In-Reply-To Max-Forwards Tono de llamada alternativo. Mtodos soportados. Informacin por autenticacin mutua Credenciales de autorizacin del cliente. Identificacin de una llamada o de una serie de los registros de un cliente. Informacin adicional sobre los participantes en la llamada. Contiene una URI que puede tener diferentes significados segn el contexto. Indicacin de la organizacin del cuerpo del mensaje, en trminos de las partes que pueda tener y los formatos MIME. Codificacin preferida por el contenido. Longitud del contenido enviado en el cuerpo del mensaje. Nmero de secuencia asociado a una peticin. Fecha y hora en los que se cre el mensaje. Informacin adicional sobre el error expresado en el cdigo de respuesta. Momento en el que el contenido estar obsoleto. Iniciador de la peticin. Referencia a los identificadores de la llamada asociados a la llamada actual. Lmite al nmero de proxies o gateways que pueden reenviar la peticin. Descripcin
FUOC PID_00147724
113
Cabecera Min-Expires Organization Priority Proxy-Authorization Proxy-Require Record-Route Reply-To Require Retry-After Route Server Subject Supported Timestamp To Unsupported Via WWW-Authenticate Intervalo de refresco mnimo.
Descripcin
Nombre de la organizacin a la cual pertenece quien genera la peticin. Prioridad de la llamada desde el punto de vista del cliente. Identificacin del cliente frente a un proxy que pide autenticacin. Requerimientos que debe tener el proxy. El proxy llena esta cabecera para indicar que las futuras peticiones tienen que pasar por el mismo. URI de retorno que no debe ser en absoluto el mismo que el de la cabecera From. Caractersticas esperadas del programa de usuario. Indicacin de cundo el servicio volver a estar disponible. Descripcin de los proxies por los cuales tendra que pasar la peticin. Descripcin del software que utiliza el servidor. Tema de la llamada. Extensiones soportadas por el programa de usuario. Indicacin de cundo el programa cliente efectu la llamada. Receptor de la llamada. Descripcin de las caractersticas no soportadas. Indicacin del camino que ha seguido la peticin y que se tiene que utilizar para las respuestas. Valor de respuesta de autenticacin.
FUOC PID_00147724
114
Resumen
En este mdulo, se ha empezado describiendo las arquitecturas de aplicaciones ms habituales en Internet: cliente servidor y de igual a igual, as como los requerimientos de las aplicaciones orientadas al envo de datos o de mensajes. A continuacin, se han descrito las aplicaciones distribuidas ms habituales en Internet y diferentes estndares que estn relacionados: Web y HTTP, DNS, SMTP, FTP, XMPP, Telnet y SSH, Gnutella, KaZaA, BitTorrent y eDonkey. Despus, se han introducido los requerimientos de las aplicaciones multimedia en red. Finalmente, se han visto una serie de tcnicas y protocolos para trabajar con contenidos multimedia en Internet, tanto por streaming de audio y vdeo: RTSP; como por aplicaciones interactivas en tiempo real: RTP, RTCP, SIP, H3.23 y Skype.
FUOC PID_00147724
115
Bibliografa
Kurose, J. F.; Ross, W. K. Computer Networking (5. edicin). Boston: Addison Wesley. ISBN 0-321-49770-8. Este libro proporciona una visin completa de los diferentes aspectos relacionados con las redes de ordenadores. En este mdulo interesa el captulo 2 ("Application Layer"), en el que se pueden encontrar los conceptos bsicos de la Web, el correo electrnico, la transferencia de ficheros y el servicio de directorio de Internet. Tambin hay un apartado de igual a igual que puede complementar la visin de los sistemas de igual a igual dada en este mdulo. 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 vdeo 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 implementacin de telefona sobre IP. Artculos Baset, S.; Schulzrinne, H. (2004). "An Analysis of the Skype Peer-To-Peer Internet Telephony Protocol". Este artculo 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, nm. 2). En este artculo encontraris un resumen de cmo funcionan las redes superpuestas de igual a igual ms populares, as como una comparativa entre las mismas. Tambin encontraris ms detalle de los sistemas explicados en este mdulo.
Comunicaciones inalmbricas
Miquel Font Rossell
PID_00147722
FUOC PID_00147722
FUOC PID_00147722
ndice
Introduccin............................................................................................... Objetivos....................................................................................................... 1. Sistemas de comunicacin de la telefona mvil....................... 1.1. 1.2. 1.3. 1.4. GSM (global system for mobile communication) ............................ GPRS ............................................................................................ EDGE ........................................................................................... UMTS ........................................................................................... 1.4.1. 2. Equipos mviles .............................................................
5 7 9 10 16 19 19 28 29 30 33 40 43 47 54 55
Redes inalmbricas............................................................................ 2.1. 2.2. 2.3. 2.4. 2.5. Infrarrojos .................................................................................... Bluetooth ..................................................................................... ZigBee .......................................................................................... WiFi ............................................................................................. WiMax .........................................................................................
FUOC PID_00147722
Introduccin
Las ondas infrarrojas, microondas y ondas hertzianas son las llamadas radiaciones electromagnticas que se utilizan en el campo de las telecomunicaciones inalmbricas (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 comunicacin 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 comunicacin de informacin. En los ltimos aos, el mercado de las comunicaciones inalmbricas se ha popularizado debido a las ventajas de las redes sin hilos: movilidad, flexibilidad, facilidad de instalacin, escalabilidad, dinamismo en los cambios de la topologa, 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 comunicacin con telefona mvil. Redes inalmbricas.
Actualmente, la gran mayora de la poblacin tiene un telfono mvil, y su uso ha experimentado un crecimiento exponencial en todo el mundo durante los ltimos aos. Inicialmente, la telefona mvil, que slo serva para mantener conversaciones telefnicas, evolucion con la posibilidad de realizar envos de pequeos mensajes de texto (SMS). Ms adelante se posibilit el acceso a Internet, primero a travs del protocolo WAP, despus el aumento de las velocidades de acceso a Interent con GPRS y finalmente, con las tecnologas UMTS, que permiten disponer de terminales mviles (telfonos, ordenadores de bolsillo...) multimedia con mltiples servicios y aplicaciones con conexiones a altas velocidades. A escala mundial se ha alcanzado la cifra de 4.000 millones de abonados mviles, con un ndice de penetracin en torno al 60%. En el 2009, China era el mercado ms importante, con ms de 600 millones de usuarios. El sistema GSM era el ms utilizado, con una cuota en turno al 80% y ms de 3.000 millones de usuarios. El nmero de usuarios de 3G en el mundo superaba los 900 millones (250 millones UMTS/HSPA).
FUOC PID_00147722
La evolucin de las redes inalmbricas de rea local WiFi, gracias a la popularizacin de los accesos domsticos a Internet, se ha extendido en multitud de hogares y empresas, as como la utilizacin del protocolo Bluetooth para interconectar diferentes accesorios y dispositivos en ordenadores, impresoras, ratones, teclados, etc.
FUOC PID_00147722
Objetivos
El estudio de los materiales didcticos de este mdulo tiene que permitiros alcanzar los objetivos siguientes:
1. Conocer las tecnologas ms habituales y actuales utilizadas en la telefona mvil comercial. 2. Tener una visin general de la rpida evolucin histrica de la tecnologa mvil en los ltimos treinta aos. 3. Entender bien las caractersticas y limitaciones de cada tecnologa de telefona mvil. 4. Saber cules son las funcionalidades actuales y futuras que se ofrecen a los usuarios de la telefona mvil. 5. Conocer los estndares y los nombres de las redes inalmbricas de uso ms comn en la actualidad. 6. Entender bien la diferencia de las funcionalidades de las redes inalmbricas segn su tipologa: consumo, prestaciones, velocidad de transmisin, distancia entre los equipos, etc. 7. Saber elegir una tecnologa inalmbrica concreta para una situacin particular.
FUOC PID_00147722
1. Sistemas de comunicacin de la telefona mvil
En 1985 surgi en Europa la primera generacin (1G) de telfonos mviles despus de adaptar el sistema advanced mobile phone system (AMPS) a los requisitos europeos denominados total access communications system (TACS). TACS engloba todas las tecnologas de comunicaciones mviles analgicas. Con ella se poda transmitir voz pero no datos. Actualmente, esta tecnologa est obsoleta y desaparecer en el futuro. Debido a la sencillez y las limitaciones de la primera generacin surgi el sistema global system for mobile communications (GSM), que marc el comienzo de la segunda generacin (2G) de la telefona mvil. Esta tecnologa puede transmitir datos, adems de las bien conocidas conversaciones de voz, a una velocidad de 9,6 kbit/s; la transmisin de datos se inici con el servicio de mensajera corta o mensajes SMS. Despus, surgi la tecnologa WAP, que consista en unas pginas web pensadas para verlas con las pantallas monocromas de los telfonos mviles. Las primeras conexiones se hacan con llamadas al proveedor telefnico, que transmita los datos como si fuera un mdem tradicional y los transmita a una velocidad de 9,6 kbits/s. En el 2001 surgi la denominada segunda generacin y media (2,5G), como paso previo a la tercera generacin (3G). En la 2,5G estn incluidas todas las tecnologas que permiten una mayor capacidad de transmisin de datos y que surgieron como paso previo a las tecnologas 3G. Dentro de esta generacin naci la tecnologa general packet radio service (GPRS), que permita acceder a Internet a travs del protocolo TCP/IP. La velocidad de comunicacin 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 conexin. Con la finalidad de facilitar las comunicaciones inalmbricas debido a su generalizacin en todo el mundo, la International Telecommunication Union (ITU) adopt diferentes interfaces de acceso radioelctrico llamadas international mobile telecommunications-2000 (IMT-2000) o comunicaciones mviles internacionales. Despus surgieron las tecnologas 3G, que se definen dentro del IMT-2000 (de la ITU) que marca el estndar 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
tecnologas que utilizan los mviles de tercera generacin (3G). Esta tecnologa permite descargar datos a una velocidad de hasta 2 Mbits/s, lo que fomenta la aparicin de nuevas aplicaciones y servicios. A pesar de todo, la tecnologa UMTS no est actualmente concebida para suplantar la tecnologa ADSL por cable de los hogares, empresas y oficinas, ya que todava slo se factura por descarga de datos. Tambin es necesario que en la zona donde se utiliza haya cobertura para esta tecnologa. Adems, tambin hace falta que en la zona donde se opera haya cobertura para esta tecnologa. Hoy da, la tecnologa UTMS se puede utilizar para conexiones a Internet, correo electrnico, FTP (transferencia de archivos), telnet (terminal remoto), videoconferencias, comercio electrnico, etc. La cuarta generacin (4G) ser el futuro de la tecnologa mvil, con velocidades de transmisin de 50 Mbps de subida y 100 Mbps de bajada, y utilizar diferentes tecnologas (MIMO, HSDPA, OFDM). 1.1. GSM (global system for mobile communication) El sistema global system for mobile communication1 (GSM) es un estndar aceptado por los telfono mviles o celulares. GSM es el nombre de un grupo de estandarizacin, ideado en 1982, pensado para crear un estndar de comunicacin para los telfonos mviles europeos.
(1)
En castellano, sistema global de comunicacin mvil.
El sistema GSM, por ser un sistema estndar, ofrece la ventaja de permitir al usuario disfrutar de los servicios contratados al mantenerlo conectado de manera automtica 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 estacin 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 transmisin se recuperan de manera automtica en la nueva estacin 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 comunicacin, puede ocurrir que, en algunos lugares y ciertas pocas del ao, el sistema quede congestionado cuando la demanda de servicio en una celda o zona geogrfica concreta supera su capacidad, como pasa en algunas zonas tursticas en temporadas de gran afluencia.
El estndar 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 razn de hacerlo
FUOC PID_00147722
11
as es limitar al mximo el nmero de diseadores 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 conmutacin (switching system, SS), 2) el sistema de estacin base (base station system, BSS), y 3) el sistema de operacin y soporte (operation and support system, OSS). Los elementos bsicos de una red GSM se describen en la siguiente figura.
El sistema de conmutacin (SS) es el responsable de gestionar el procesamiento de las llamadas y las funciones del suscriptor. Su estructura est constituida por los elementos siguientes: Registrodelocalizacin(HLR). Es una base de datos utilizada para guardar y gestionar las suscripciones. Se la considera la base de datos ms importante y guarda la informacin permanente sobre los suscriptores, los perfiles de servicios de los suscriptores, informacin de localizacin y estado de la actividad. Cuando una persona individual compra una suscripcin (se da de alta con un operador de telecomunicaciones) a uno de los
Suscriptor Es el cliente-usuario de un operador de telecomunicacin.
FUOC PID_00147722
12
operadores de telecomunicaciones (operador PC), la persona queda registrada en el HLR de este operador. Centrodeconmutacindelosserviciosmviles(MSC). El MSC proporciona las funciones de conmutacin de telefona en el sistema. Controla las llamadas a, y desde, otros telfonos y sistemas de datos. Registrodelocalizacindelosvisitantes(VLR). La VLR es una base de datos que contiene informacin temporal sobre los suscriptores que necesitan el MSC como suscriptores visitantes. El VLR se integra dentro del MSC. Cuando una estacin mvil permanece en una nueva rea MSC, el VLR conectado a este MSC pedir informacin sobre la estacin mvil a la HLR. Despus, la estacin mvil realiza una llamada, y el VLR tendr la informacin necesaria para realizar el establecimiento de llamada sin necesidad de tener que interrogar al HLR constantemente. Centrodeautoidentificacin(AUC). El AUC proporciona autoidentificacin y encriptacin para determinar la identidad y asegurar la confidencialidad de cada llamada. Protege las operaciones de red contra diferentes tipos de fraudes. Registrodelaidentidaddelosequipos(EIR). El EIR es una base de datos que contiene informacin sobre la identidad de los equipamientos mviles que realiza la prevencin que las llamadas sean escuchadas, no autorizadas o detectar estaciones mviles defectuosas. El sistema de estacin base (BSS) realiza todas las funciones relacionadas con la transmisin por radio, que consiste en controladores de estacin 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 fsicos entre el MSC y el BTS. Es un conmutador de alta capacidad que proporciona funciones como el control de la radiofrecuencia (RF), informacin de la configuracin 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 estacin mvil. 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 conmutacin y a los BSC. La implementacin 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 funcin importante del OSS es proporcionar una visin 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 geogrficas. La siguiente figura muestra las agrupaciones en celdas, reas de localizacin (LA), reas de servicio MSC/VLR y reas pblicas mviles de tierra (PLMN).
La celda es el rea de cobertura proporcionada por una estacin base de transmisin (BTS). La distribucin ms 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 travs de la identidad global de celda (CGI), que es un nmero asignado a cada celda. Un rea de localizacin es un conjunto de celdas. En esta rea es donde el suscriptor est situado. Cada rea de localizacin est servida por uno o ms controladores de estaciones base, para una sola MSC. A cada rea de localizacin se le asigna un nmero denominado identidad de localizacin 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 (telfono mvil y estacin base), y su velocidad de transmisin mxima puede ser de 270 Kbps. Hay dos tipos de servicios bsicos ofrecidos por GSM: telefona y datos. Los servicios de telefona son bsicamente los servicios de voz que proporcionan los suscriptores para comunicarse con otros suscriptores (telefona normal y llamadas de emergencia). Los servicios de datos son bsicamente los siguientes: Servicio de fax de grupo III: permite que un fax GSM se pueda comunicar con un fax analgico. Servicio de transmisin de mensajes cortos SMS: 160 caracteres alfanumricos entre estaciones mviles, garantizando que los mensajes se guardarn si la otra estacin no est conectada, y, por tanto, se recibirn con toda seguridad. Servicio de buzn de voz: una mquina del operador recibe y guarda las llamadas y mensajes del buzn de voz. Servicio de envo de mensajes broadcast entre los suscriptores de un rea. Servicio de correo de fax: el suscriptor puede recibir un mensaje de fax en cualquier mquina de fax.
Otros servicios que ofrece GSM Otros servicios suplementarios que ofrece GSM son: redireccionamiento de llamadas entrantes hacia otro nmero de telfono prevencin o filtrado de determinadas llamadas salientes de la estacin mvil prevencin o filtrado de recepcin de determinadas llamadas aviso del coste de una llamada o un mensaje conversaciones telefnicas mltiples etc.
El suscriptor, para comunicarse dentro de la red GSM, utiliza el telfono mvil, que internamente es un transmisor y receptor de seales. El telfono mvil est formado por diferentes circuitos de control; tiene unos dispositivos de
FUOC PID_00147722
16
amplificacin y modulacin/desmodulacin de la seal, circuitos de codificacin y descodificacin de seales A/D y D/A, un altavoz y un micrfono, una batera, una pantalla, un teclado y una antena.
El telfono mvil lleva una tarjeta inteligente, denominada mdulo de identificacin 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 telfono mvil, ste adquiere el nmero de telfono asociado a la tarjeta SIM. Dentro de cada tarjeta SIM se guarda la international mobile suscriber identity (IMSI), que es la identificacin internacional del suscriptor. 1.2. GPRS El general packet radio service (GPRS) o servicio general de paquetes va radio es una extensin del GSM, que permite la transmisin de datos por paquetes, con velocidades de transferencia de 56 a 144 Kbps. Servicios como el wireless application protocol (WAP), servicio de mensajera multimedia (MMS), acceso a Internet o SMS pueden utilizar el GPRS. La transferencia de datos de GPRS se cobra por volumen de informacin transmitida, no por tiempo, independientemente de si el usuario utiliza toda la capacidad del canal o est en estado de inactividad.
GPRS es una tecnologa de conmutacin de paquetes que surge como una evolucin de las redes GSM para proporcionar mayor velocidad y ms prestaciones en el acceso mvil a servicios de datos e Internet. Complementa las redes GSM, y no las sustituye. Es una buena alternativa a la migracin progresiva hacia la tercera generacin de redes mviles y permite una introduccin gradual de aplicaciones y servicios para evaluar la viabilidad y rentabilidad del acceso mvil a Internet.
GPRS se basa en una red de conmutacin superpuesta a la red GSM. Fue necesario instalar nuevos nodos y elementos de red sobre la red GSM para soportar servicios de conmutacin 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: ClaseA: soporta tanto servicios GSM como servicios GPRS de manera simultnea. ClaseB: soporta servicios GSM y servicios GPRS, pero de forma alternativa, no simultnea. ClaseC: soporta servicios GPRS de forma exclusiva, habitualmente en forma de tarjeta para insertar en un PC porttil.
Acceso a Internet Un acceso propio a Internet podra ser de la siguiente manera con APN: movistar.es. El perfil estara 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 sera: 1) MS solicita la activacin de un contexto con el APN movistar.es. 2) El MS proporciona un identificador y una contrasea genricos. Por ejemplo, usuario: MOVISTAR; clave: MOVISTAR. 3) El GGSN solicita la asignacin de una direccin IP. 4) El servidor Radius del TME asigna una direccin IP al MS. 5) El MS puede acceder a Internet a travs de la red de TME.
FUOC PID_00147722
18
Por ejemplo, se puede crear una conexin a Internet en un ordenador porttil de las siguientes maneras: Creando una conexin entre el porttil y un telfono mvil mediante el protocolo bluetooth (o un enlace de infrarrojos). El telfono mvil tiene la capacidad de crear una conexin a Internet a travs de la red GPRS. La comunicacin entre el ordenador y el telfono mvil se hace a travs de una aplicacin que gestiona la conexin 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 combinacin de dos tecnologas de comunicacin inalmbrica e Internet. Funciona sobre GSM, pero lo puede hacer sobre GPRS o UMTS, como veremos ms adelante. Se trata de un protocolo que permite la conexin de terminales mviles a fuentes externas de forma interactiva, ya sean servidores IP, bases de datos o multimedia. Por ejemplo, las estaciones mviles para navegar por Internet incorporan un micronavegador WAP, que es equivalente a un navegador web. El micronavegador es el visualizador que permite ver pginas WML, que es un lenguaje muy parecido al HTML. Las pasarelas WAP convierten pginas HTML en pginas WML, teniendo en cuenta el reducido tamao de las pantallas y las funcionalidades de los dispositivos mviles (telfonos mviles, PDA...).
Otros usos de WAP WAP tambin ofrece servicios para la transferencia asncrona de mensajes multimedia (MMS), y tambin permite enviar y recuperar los mensajes en un servidor e-mail de Internet a travs de las oportunas conversiones.
Difusin de EDGE ltimamente han aparecido tarjetas de red y telfonos mviles con tecnologa EDGE de diversos fabricantes, como el aumento de redes y operadores en diversos pases con esta tecnologa.
FUOC PID_00147722
19
1.3. EDGE
Enhanced data for global evolution (EDGE) y enhanced data rates for GSM evolution son tecnologas que permiten aumentar las velocidades de transmisin de datos y la eficiencia espectral, facilitando nuevas aplicaciones y el aumento de la capacidad para el uso en servicios de telefona mvil.
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 tecnologa de los sistemas de comunicacin y el acceso a todo tipo de informacin por parte de los usuarios son algunas de las causas que han potenciado el desarrollo de una nueva generacin de terminales de comunicacin capaz de facilitar la interconexin de las distintas redes mundiales. Los sistemas UMTS (o UTMS) o sistemas de tercera generacin (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 disposicin un sistema de interconexin global de todas las redes. UMTS equivale a la tercera generacin de comunicaciones mviles. Una generacin ms fiable y flexible que las dos anteriores. IMT-2000 define un estndar global para la tercera generacin, iniciativa de la ITU para proveer de acceso inalmbrico a la infraestructura global de telecomunicaciones a travs de sistemas por va satlite y sistemas terrestres. UMTS es la propuesta europea (ETSI) para promover la utilizacin de UMTS Terrestrial Radio Access (UTRA) en el IMT-2000. 3GPP (Third Generation Partnership Project) es un foro formado por organismos de diferentes pases (ETSI, TTA, TTC y CWTS) para la elaboracin de especificaciones tcnicas para UMTS.
FUOC PID_00147722
20
Los objetivos de IMT son: la convergencia de redes fijas y mviles, igualar la calidad de servicio, ofrecer servicios multimedia simtricos y asimtricos, roaming global, asignacin dinmica de ancho de banda hasta un mximo inicial de 2 Mbps, acceso personalizado concepto de virtual home environment (VHE) para definir un perfil de servicio constante y homogneo independiente de la red que le sirve el abonado, uso de la tecnologa de paquetes y protocolos IP, soporte de un amplia gama de terminales, y capacidad para un alta densidad de usuarios.
En la implantacin 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 compaas de 30 pases, pertenecientes a las industrias suministradoras de equipos, operadores de telecomunicaciones y organismos de regulacin. El foro est comprometido en la formacin del consenso necesario para introducir y desarrollar con xito el estndar UMTS y as poder satisfacer la demanda del mercado de unas comunicaciones mviles personales de bajo coste y alta calidad. Los pases europeos lo estn desarrollando en cooperacin con las organizaciones de estandarizacin en el 3G.
UMTS en Espaa Espaa fue uno de los pases pioneros en la tecnologa UMTS, y ha sido uno de los primeros pases en lanzar el servicio. En el 2000 se adjudicaron cuatro licencias UMTS disponibles a las operadoras Telefnica Mviles (Movistar), Airtel (actualmente Vodafone), Amena (actualmente Orange) y el consorcio Xfera (ms conocido como Yoigo).
Direccin web recomendada Podis acceder al foro UMTS a travs de la pgina web http://www.umts-forum.org.
Las fases del desarrollo de UMTS han sido: Primerafase. Elaboracin de las descripciones tcnicas y evaluacin de las soluciones para UTRAN. Concluir con una descripcin detallada de UTRAN en la que se incluyen los protocolos de interfaz de radio, los protocolos internos y los protocolos del subsistema de red. Segundafase. Elaboracin de las especificaciones del Release 99 para la integracin de UMTS con las redes GSM/GPRS existentes. Tercerafase. Correccin iterativa de las especificaciones prevista para finales del 2001. Cuarta fase. Incremento del bit rate para alcanzar tasas superiores a 2 Mbits/s.
FUOC PID_00147722
21
Arquitectura global GSM
UMTS es una tecnologa 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 rpido, transmisin de paquetes de datos y velocidad de transferencia de datos a demanda, entorno de servicios amigable y consistente.
Las caractersticas ms sobresalientes de UMTS son: roaming sin fisuras, acceso global rpido, multimedia, separacin de servicios y plataformas, un terminal puede estar conectado a varios nodos a la vez, velocidad de transmisin de hasta 2 Mbps, capacidad para determinar la posicin, mecanismos de seguridad, calidad de servicio (servicios de valor aadido o calidad) muy desarrollada, VHE (interfaz para cualquier red).
UMTS proporciona servicios de fcil uso y adaptables para abordar las necesidades y preferencias de los usuarios, una amplia gama de terminales para realizar un fcil acceso a distintos servicios y bajo coste de los servicios para hacerse con un mercado masivo. Tambin ofrece la capacidad de ofrecer diferentes formas de tarificacin y el servicio de roaming internacional. UMTS ha evolucionado para integrar todos los servicios ofrecidos por las distintas tecnologas y redes actuales (GSM, RDSI, Internet...) y se puede utilizar en determinados terminales (telfono fijo, inalmbrico, celular, terminal multimedia...), tanto en ambientes profesionales como domsticos, ofreciendo una mayor calidad de servicios y soportando la personalizacin del usuario y los servicios multimedia mviles en tiempo real. Los terminales son multimodo y multibanda, con cmara incorporada, pantalla de color y una gran memoria. Los servicios 3G combinan el acceso mvil de alta velocidad con los servicios basados en el protocolo IP. Pero la 3G no slo lleva una conexin rpida al World Wide Web (WWW), sino que, adems, implica nuevas formas de comu-
FUOC PID_00147722
22
nicacin, de acceder a la informacin, de hacer negocios, aprender y disfrutar del tiempo libre, que relegan al pasado las conexiones fijas y lentas. Como la 3G puede realizar mltiples conexiones simultneamente desde un mismo terminal mvil, un usuario se puede conectar a una base de datos remota para obtener informacin sin necesidad de interrumpir una sesin 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 fciles de utilizar. Por eso ofrecen: transmisin de alta fiabilidad, hasta 384 kbits/s en espacios abiertos y 2 Mbits/s con baja movilidad, uso del ancho de banda dinmico en funcin de la aplicacin, soporte tanto en conmutacin de paquetes como de circuitos, acceso a Internet (navegacin WWW), videojuegos, comercio electrnico, vdeo y audio en tiempo real, diferentes servicios simultneos en una sola conexin, calidad de voz con la red fija, mayor capacidad y uso eficiente del espectro, personalizacin de servicios segn el perfil de usuario, servicios dependientes de la posicin, incorporacin 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 satlite.
La estructura de las redes UMTS est compuesta por dos grandes subredes: la red de telecomunicaciones y la red de gestin. La primera es la encargada de sustentar el trasvase de informacin entre los extremos de una conexin. La segunda tiene como objetivo la provisin de medios para la facturacin y tarificacin de los abonados. Tiene los siguientes elementos: Ncleo de la red (core network). Red de acceso a radio (UTRAN). Terminal mviles.
La velocidad de transferencia de datos que la Unin Internacional de Telecomunicaciones (UIT) requiere en su solucin IMT-2000 va desde los 144 kbit/s sobre vehculos a gran velocidad, hasta los 2 Mbits/s sobre terminales en interiores de edificios (cifra al menos 60 veces superior a la que se tena cuando se utilizaba un mdem convencional para la red telefnica conmutada, la telefona de toda la vida), pasando por los 384 kbit/s en usuarios mviles en vehculos 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 tambin 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.
Despus de la implantacin del sistema UMTS, el concepto de telfono mvil ha cambiado radicalmente, pasando de ser un simple instrumento de comunicacin a convertirse en un terminal multimedia con mltiples capacidades para la comunicacin y el ocio, gracias a la gran cantidad de servicios ofrecidos y que crecen cada da. Adems, para zonas en las que la telefona mvil no llega o llega de manera deficiente, la tecnologa UMTS habilita la posibilidad de hacer llegar los servicios de telecomunicaciones avanzados.
Nuevos servicios a travs de UMTS Actualmente, algunos operadores ya ofrecen vdeollamadas, vdeo mensajera, descarga de juegos, msica de calidad MP3, clips de vdeo e imgenes en directo de temas de actualidad y la conexin a Internet para navegar desde el mvil. Algunos operadores ya prometen canal de televisin 24 horas en directo, cursos en lnea, etc.
Los modelos de mercado UMTS son: Modelos de interrelacin: B2B: Business-to-Business. B2E: Business-to-Employee. B2C: Business-to-Consumer.
FUOC PID_00147722
24
Clases de servicios bsicos: Intranet/extranet mvil. Servicios de localizacin. Servicios de voz. Servicios de mensajera multimedia. Acceso mvil a Internet. Ocio personalizado.
Grfico de la implantacin de UMTS
UMTS ofrece servicios bsicos de telecomunicacin: Servicios portadores: servicios de conmutacin de circuitos para transmisin de voz y audio, servicios de conmutacin de paquetes (llamadas virtuales, canales virtuales permanentes, conectividad RDSI interactiva: conversacin, mensajera a demanda, distribucin envo continuo a mltiples usuarios, sealizacin a los usuarios). En la transferencia de la informacin puede ofrecer una tasa binaria constante de informacin garantizada, una tasa binaria variable dinmicamente no garantizada, una tasa binaria variable dinmicamente en tiempo real con una tasa binaria mnima garantizada. El trfico puede ser punto a punto o unidireccional punto-multipunto (multicast, broadcast). Con respecto a la calidad de la
FUOC PID_00147722
25
informacin, puede tener un mximo retardo en la transferencia, una variacin en el retardo, una tasa de error de bit y una tasa de datos.
Tasas de transmisin en redes de acceso mvil. Tiempo de descarga de aplicaciones tpicas Aplicacin E-mail(10Kbytes) Pginaweb(20Kbytes) FicheroPowerPoint(2Mbytes) Videoclip(4Mbytes) RDSI 1s 2s 4 min 8 min GSM 8s 20 s 28 min 48 min GRPS 0,7 s 1,6 s 2 min 4 min UMTS 0,04 s 0,1 s 7s 14 s
Teleservicios: servicios de telecomunicacin que proporcionan la capacidad de comunicacin completa entre los usuarios, incluidas las funciones de los equipos terminales, en funciones de los protocolos acordados entre los operadores de red: telefona (voz, fax, transmisin de datos), teleconferencia (multiparte, llamadas mltiples, llamadas en grupo), servicios propios UMTS (audio, vdeo, multimedia, emergencia, mensajera, movilidad), servicios multimedia interactivos (IMN: datos, grficos, imgenes, audio y vdeo interactivo).
Teleservicios de UMTS Algunos ejemplos de teleservicios propios de UMTS son: peticin de bases de datos, servicio de listn telefnico, navegacin y localizacin, e-mail, llamadas de emergencia, llamadas de emergencia masiva, servicios de mensajera corta (fax, mensajes de voz, correo electrnico), control de equipos remotamente, telecompra, monitorizacin de vdeo, mensajes de voz, paginacin, transmisin de audio y vdeo... Servicio Duracin de la llamada 2 min. 1h Tasa de datos (kbit/s) 8-32 32-128 Error de bit 10 -4 10 10 10
-7 -4
Retardo (ms) 40 40
Telefona Voz Teleconferencia Videotelefona Videoconferencia Mensajera SMS Buzn de voz Videomensaje Correo electrnico Basesdedatos Telecompra Teleaccin/control
2 min. 1h Sin conexin 2 min. Sin definir Sin conexin
64-348 348-768 1,2-9,6 8-32 64 1,2-64
40-90 90 100 90 100 100
-7
10 -4 10 -7 10 -6 10 10 10 10
-6
-6
Sin definir Sin definir Sin definir
2,4-768 2,4-768 1,2-64
200+ 90 100-200
-6
-6
Serviciossuplementarios: servicios que modifican o complementan un servicio bsico de telecomunicacin, como, por ejemplo, la identificacin
FUOC PID_00147722
26
del nmero (marcacin abreviada, rechazo de llamadas, identificacin de grupos de llamadas), redireccionamiento de llamadas y finalizacin de las llamadas, comunicacin multiparte (llamadas entre grupos cerrados de usuarios), tarificacin (informacin adicional sobre la llamada), restriccin de llamadas (rechazo de llamadas entrantes). Serviciosdevaloraadido: servicios adicionales especficos de un usuario, como, por ejemplo, movilidad personal (transferencia de nmeros de telfono en cualquier terminal a travs de USIM, entorno virtual donde el usuario puede establecer su propia lista de servicios), ancho de banda a demanda, utilizacin eficiente de recursos por servicios que dependen crticamente de variaciones en la tasa de transmisin MMS y vdeo segn 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 caractersticas 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, mvil, inalmbrica...).
Las clases de calidad de servicio en UMTS son: Claseconversacional: permite la conversacin en directo (real time) entre los usuarios. El retardo mximo viene dado por la percepcin humana de audio y vdeo. Clasedetramas(streaming): recepcin audio y vdeo en un solo sentido. Conserva la relacin temporal entre las entidades (retardo limitado). Claseinteractiva: una mquina o un humano recibe datos bajo demanda. Depende del patrn de interaccin y de la carga de datos (por ejemplo, acceso a web o a una base de datos). Clasedefondo(background): el usuario enva y recibe datos en segundo plano y el destino no espera los datos en un perodo de tiempo preciso (correo electrnico, SMS, recepcin de registros de datos...). Los atributos del QoS pueden ser: Trfico unidireccional/bidireccional. Clase de trfico: conversacional, streaming, interactivo, background. Tasa binaria mxima (kbps) y tasa binaria garantizada (kbps).
(2)
Sigla de unidad de datos del servicio.
FUOC PID_00147722
27
Orden de envo (s/no). Tamao mximo de la SDU2 (bytes). Informacin de formato de la SDU (bits). Tasa de error de SDU y tasa de error de bit en la SDU. Reenvo de la SDU errnea (s/no). Retardo en la transferencia (ms). Prioridad de gestin de trfico. Prioridad en la asignacin / retencin de canal. Descriptor estadstico de la fuente. Indicacin de sealizacin (s/no).
Clase de trfico Conversacional Tcnica tramas <=16.000 Interactivo Trasfondo
Tasa de bits mxima (kbps)
<=16.000
<= 16.000 tiempo de sistema S/no <= 1.500 o 1.502
<= 16.000 tiempo de sistema S/no <= 1.500 o 1.502
Orden de entrega Medida mxima de SDU (unidad de datos de servicio) (octetos) Informacin en formato SDU Entrega de SDU errneas BER (probabilidad de error de bit) residual Porcentaje de errores de SDU Retraso de transferencia (ms)
S/no <= 1.500 o 1.502
S/no <=1.500 o 1.502 S S/no/
S S/no/
S/no/
S/no/
100 valor mnimo
300 valor mnimo <=16.000 1, 2, 3 Habla/desconocida
Tasa de bits garantizada (kbps) Prioridad de gestin del trfico Prioridad de asignacin/retencin Descriptor estadstico de origen
<=16.000 1, 2, 3 Habla/desconocida
1, 2, 3 1, 2, 3
1, 2, 3
Indicacin sealizadora
S/no
El valor aadido 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: telfono mvil, PDA, porttil. Cualquier situacin: negocios, ocio, educacin.
Las caractersticas clave sern su universalidad, que siempre estar encendido, su alcance, la personalizacin, la accesibilidad y la localizacin.
FUOC PID_00147722
28
La evolucin de UMTS ir hacia las tecnologas high speed downlink packet access (HSDPA) (3,5G y 3,75G) con terminales HSUPA y a los telfonos de cuarta generacin (4G) para mejorar el rendimiento por el uso simultneo de aplicaciones y aumentar la cobertura de tecnologas 3G, de forma que el rendimiento de la red se incremente hasta un 81% con respecto a GPRS y se produzca una evolucin en millones de usuarios los prximos aos.
UMTS
1.4.1. Equipos mviles Para que los usuarios utilicen los servicios 3G hacen falta nuevos telfonos y otros terminales capaces de proporcionar los servicios que aquellos desean, desde la telefona mvil hasta los multimedia (voz, datos y vdeo). Los telfonos mviles UMTS son muy tiles para el viajero y el cosmopolita. Estn diseados 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. Adems, casi todos los telfonos UMTS, a excepcin del Japn, son UMTS/GSM de modo dual; eso significa que durante una llamada, si salimos fuera de los lmites de la zona UMTS, la llamada ser transferida por una cobertura GSM.
Telfono mvil
Los telfonos UMTS soportan una gran variedad de frecuencias ya que tienen que poder utilizarse en todo el mundo. Muchos pases aportan diferentes frecuencias UMTS. Al igual que las tarjetas SIM para telfonos GSM, existe la tarjeta USIM para los telfonos 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 continuacin, un usuario mvil puede utilizar sus telfonos UMTS en otra red, aunque los precios pueden cambiar. Las tarjetas USIM tienen espacio para almacenar los contactos, mensajes y otra informacin. De la misma manera que las tarjetas SIM, las tarjetas USIM tambin se pueden cambiar de un telfono a otro, y el nuevo mantendr la identificacin de la tarjeta.
FUOC PID_00147722
29
2. Redes inalmbricas
Las diferentes tecnologas sin hilos (Wireless) se suelen agrupar basndose en el radio de accin (alcance) de cada una de ellas: Redespersonalessinhilos(WPAN,wirelesspersonalareanetwork). Este concepto se aplica cuando la distancia que se quiere cubrir es del orden de unos cuantos metros. La familia de estndares ms representativos son el 802.15.1 (Bluetooth), el 802.15.3a (UWB) y el 802.15.4 (Zigbee). Redeslocalessinhilos(WLAN, wirelesslocalareanetwork). 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 estndar ms destacado en este campo es el 802.11 (WiFi). Redesmetropolitanassinhilos(WMAN,wirelessmetropolitanareanetwork). Permiten dar servicios a distancias del orden de unos cuantos kilmetros (un barrio, un pueblo, una urbanizacin...). El estndar ms destacado en este campo es el 802.16 (WiMAX). Redesdegranalcancesinhilos(WWAN, wirelesswideareanetwork). Tienen una cobertura ms amplia. La familia de estndares ms representativos es la de GSM, GPRS y UMTS.
Clasificacin de las tecnologas sin hilos
FUOC PID_00147722
30
2.1. Infrarrojos En el ao 1800, Friedrich William Herschel descubri la radiacin infrarroja. Esta radiacin tiene longitudes de onda ms largas que la luz visible, pero ms 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 radiacin infrarroja es el calor o radiacin trmica. 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 comunicacin 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 comunicacin de informacin.
Dentro del mundo de las comunicaciones, se utiliza mucho porque hace falta relativamente poca energa para generarla. Los primeros en utilizarla fueron los ingenieros de una empresa que comunicaron una calculadora con una impresora para imprimir los clculos que haca. Otro ejemplo muy cotidiano al respecto es el mando a distancia del televisor o del reproductor de DVD.
De forma general, podemos definir la comunicacin 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 informacin y se enva de un transmisor a un receptor a una distancia relativamente corta.
En el ao 1993, 50 compaas se unificaron para crear el IrDA, estndares internacionales para el equipo y los programas utilizados en los enlaces de comunicacin por infrarrojos. La norma "IrDASerial Infrared Data Link Standard Version 1.1." establece tres niveles que deben cumplir los equipos en las secciones fsica, infrared link access protocol (IrLAP) e infrared link management protocol (IrLMP). Las caractersticas de la norma son: Bajo coste de implementacin. Bajos requerimientos de potencia. Conectividad direccional, punto a punto. Alta inmunidad al ruido. Optimizacin por transferencia de datos.
Ejemplo de un puerto IrDA de la placa madre de un ordenador
Los datos informticos se tratan con numeracin binaria, la cual, en la comunicacin infrarroja se codifica como un bit 0 si hay luz, o como un bit 1 si no hay luz. Podemos ver la comunicacin infrarroja como un cable virtual por
FUOC PID_00147722
32
el que pasan los datos de un elemento a otro. Este tipo de comunicacin que permite enviar los bits de informacin uno detrs de otro se llama comunicacin en serie. La capa fsica tiene un codificador y un descodificador que transforman los niveles 1 y 0 de la seal binaria en pulsos de duracin y formato especificados. Tiene un transductor (IrTxRx) consistente en un emisor (LED) y un detector (fotodode). Un valor binario "0" se representa por un pulso, con una duracin nominal mnima de 1,6 microsegundos y un mximo de 3/16 del perodo de bit. Un "1" se representa por la ausencia de pulso. Esta comunicacin exige que el receptor de la informacin est a la espera, lo que implica que el sensor receptor utilice energa para detectar cuando llega la luz. Por ello los elementos mviles con batera (telfonos mviles, PDA...) necesitan activar y desactivar la recepcin de datos. La capa de transporte se define como un flujo de datos serie asincrnica convencional compuesto por sucesivos caracteres, donde cada carcter 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 protocolo denominado IrLAP, que es una adaptacin del clsico HDLC . Transmite informacin para pedir una conexin a 9.600 baudios. Las velocidades de transmisin son: SIR (Serial IR - 115,2 kbps). MIR (velocidad media - 1,152 Mbps). FIR (alta velocidad - 4 Mbps). VFIR (muy alta velocidad - 16 Mbps).
3 (3)
High-Level Data Link Control es un protocolo de comunicaciones de propsito general punto a punto.
La comunicacin entre el emisor y el receptor que se establece puede ser: Una lnea recta directa entre el emisor y el receptor (comunicacin punto a punto). Si apuntamos a una pared para hacer una "carambola" entre el emisor y el receptor, establecemos una comunicacin cuasidifusa. Una comunicacin difusa, en la que no hace falta que haya una visin directa entre emisor y receptor, de manera que los equipos tienen que ser muy potentes.
FUOC PID_00147722
33
2.2. Bluetooth
Actualmente, la tecnologa Bluetooth es la tecnologa sin hilos ms popular. Se trata de un protocolo basado en el estndar de comunicaciones IEEE 802.15, pensado por la transmisin de datos y voz sin hilos entre dispositivos, mediante una radiofrecuencia. Al inicio del desarrollo de los productos Bluetooth de primera generacin, se tuvo en cuenta lo siguiente: El sistema tena que ser universal. El emisor haba de consumir poca energa, ya que se usaba en equipos que funcionan con batera. La conexin deba permitir la transmisin de datos y voz (aplicaciones multimedia). Tena que ser de bajo coste (el objetivo fue unos cuantos dlares para cada dispositivo). De acuerdo con estos requisitos, Ericsson desarroll en 1994 una tecnologa que utiliza un canal de comunicacin con un mximo 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 inters 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 ms de 9.000 miembros. Esta tecnologa es propietaria, es decir, que slo puede producirla quien tiene la patente. Por eso slo puede introducir esta tecnologa en sus productos quien pertenece al SIG de Bluetooth. Actualmente, la velocidad mxima de transmisin oscila entre 1 Mbps y 3 Mbps.
Difusin de la tecnologa Bluetooth Actualmente existen muchos dispositivos electrnicos que incorporan el protocolo Bluetooth: auriculares con micrfono, ordenadores, PDA, ratones, telfonos mviles, impresoras, gafas Oackley, cmaras fotogrficas, teclados, otros dispositivos de entrada de ordenadores, etc. Los sectores industriales en los que se utiliza son: automocin, aeronutica, naval, otros transportes, bienes de equipo mecnico, elctrico, electrodomsticos, ordenadores, equipos de oficina, hogar, telecomunicaciones y equipos electrnicos y otros segmentos industriales. En el sector servicios tenemos: los financieros, contenidos y ocio, administracin y servicios pblicos, servicios privados para empresas.
Origen del nombre Bluetooth El nombre Bluetooth tiene su origen en el rey dans Harald Blatand (Harold Bluetooth en ingls) que unific los pueblos de Dinamarca, Noruega y Suecia, que antes estaban en guerra.
Logotipo de Bluetooth
FUOC PID_00147722
34
Esta tecnologa representa una ventaja con respecto a la tecnologa de comunicacin 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 televisin por infrarrojos). Brevemente, los servicios de las conexiones Bluetooth que actualmente se suelen ofrecer en algunos sistemas operativos como Windows o Linux: TransferenciadeelementosdelPIM: 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. SincronizacindelPIM: permite que los dispositivos Bluetooth remotos sincronicen una base de datos PIM con las del PIM del equipo. Transferenciadearchivos: permite que los dispositivos Bluetooth remotos realicen operaciones de archivo en un directorio especfico en este equipo y en los subdirectorios y archivo de este directorio. Accesoalared: permite que los dispositivos Bluetooth remotos compartan la conexin a la red de este equipo, que puede ofrecer acceso a Internet. Accesotelefnicoaredes: en este caso se puede utilizar para acceder desde un ordenador a Internet a travs de un telfono mvil. El telfono mvil accede a Internet por GPRS, y la conexin mvil-ordenador se hace por Bluetooth. El ordenador ve el telfono mvil como si fuera un mdem
FUOC PID_00147722
35
clsico conectado directamente al ordenador (a pesar de que la comunicacin entre los dos dispositivos sea inalmbrica). El ordenador crea una conexin a Internet a travs del "mdem" mediante el protocolo PPP con el operador del servicio de Internet (operador de telefona mvil). PuertoserieBluetooth: permite que los dispositivos Bluetooth remotos se conecten al equipo a travs de un puerto serie inalmbrico. Fax: permite que los dispositivos Bluetooth remotos utilicen las opciones del equipo para enviar un fax. Pasareladeaudio: permite que los dispositivos Bluetooth remotos, como unos auriculares, reemplacen el micrfono y los altavoces del equipo. Auriculares: permite que los dispositivos Bluetooth remotos, como un telfono mvil, utilicen el micrfono 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 transmisin y una serie de protocolos de comunicaciones (fsico, enlace, lgico). En muchos casos se ha desarrollado un chip CMOS que gasta mucha menos energa que un telfono mvil (un 97% aproximadamente), controla la emisin de radio y una parte que controla digitalmente las seales recibidas. Los valores tpicos de consumo se muestran en la siguiente tabla.
Modo En espera Voz Datos
mA = miliamperio
Potencia Menos de 0,3 mA 8 a 30 mA 5 mA (media)
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 tcnica de modulacin en la que la seal se emite sobre una serie de frecuencias aparentemente aleatorias. De esta manera, los receptores no autorizados slo ven una seal ininteligible.
FUOC PID_00147722
36
Cuando tenemos diversos dispositivos sincronizados por un reloj y una secuencia de saltos de frecuencia, tambin comparte el mismo canal fsico de radio. Uno de ellos proporciona estos valores de referencia (sincronizacin y saltos de frecuencia) y se denomina dispositivomaestro, mientras que los otros se llaman dispositivosesclavos.
Pequea 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 slo puede pertenecer a una piconet, mientras que un dispositivo esclavo se puede conectar a varias piconets al mismo tiempo (red dispersa).
FUOC PID_00147722
37
Una red Piconet Bluetooth
FUOC PID_00147722
38
Una red scatternet Bluetooth
Dentro de una piconet, cada dispositivo esclavo se conecta al dispositivo master por un canal fsico. Cada uno de estos canales fsicos se divide en slots. Los paquetes que viajan entre el master y el esclavo estn colocados dentro de estos slots. Los canales fsicos 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 transmisin de la informacin. 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 accin y a proporcionar informacin con respecto al tipo de servicio que necesita. Los dispositivos que ofrecen uno o ms 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 accin, y, una vez descubiertos los dispositivos, stos son aadidos automticamente 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 comunicacin depende de la clase de potencia emitida. Actualmente existen tres clases de potencia segn 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: Nivel1:nohayseguridad. El dispositivo funciona en modo promiscuo, permitiendo que cualquier otro equipo Bluetooth se conecte al dispositivo. Nivel2:seguridadaniveldeservicio. Soporta autoidentificacin, encriptacin y autorizacin una vez se ha establecido el canal de comunicacin. Nivel 3: seguridad a nivel de enlace. Las medidas de seguridad se implantan antes de que el canal de comunicacin se haya establecido. Proporciona encriptacin y autoidentificacin. 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 cdigo. Este cdigo puede ser de cuatro cifras o una frase larga. El cdigo 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 informacin. Esta tecnologa tambin sufre ataques a la seguridad, y por eso tenemos que saber cules son y cmo 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 mvil. Este procedimiento no modifica ningn dato, pero quien recibe este ataque puede llegar a pensar que tiene un virus en su dispositivo. Bluebugging: permite ejecutar pedidos en un telfono mvil sin que el propietario reciba ningn 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 telfono, leerlos o modificarlos. Slo afecta equipos antiguos.
Carwhisperer: permite el acceso a un telfono de manos libres de coche, y por lo tanto, escuchar llamadas o el micrfono, o enviar sonido al dispositivo.
Cabirworm: programa gusano que, al instalarse en un telfono, se copia en otros telfonos. Slo 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 especificacin de un conjunto de protocolos de alto nivel de comunicacin inalmbrica para su utilizacin en radio digital de bajo consumo, basado en el estndar WPAN IEEE 802.15.4. Su objetivo son las aplicaciones que requieren comunicaciones seguras con baja tasa de envo de datos y maximizacin de la vida til de las bateras.
La tecnologa ZigBee se diferencia por su bajo consumo, su topologa de red en malla, y su integracin fcil (se pueden fabricar nodos con muy poca electrnica). La relacin entre IEEE 802.15.4-2003 y ZigBee es parecida a la existente entre IEEE 802.11 y WiFi Alliance. La especificacin 1.0 de ZigBee se aprob en el 2004 y est disponible en miembros del grupo de desarrollo (ZigBee Alliance). Un primer nivel de suscripcin, llamado adapter, permite la creacin de productos para su comercializacin adoptando la especificacin por un determinado precio. Esta especificacin est disponible al pblico para fines no comerciales. Con el tiempo, se han ido creando nuevas versiones de la especificacin original. En diciembre del ao 2006 se public la especificacin actual.
Comercializacin de productos ZigBee ZigBee tiene los mdulos transmisores inalmbricos ms baratos de la historia, y producidos de manera masiva. Tendrn un coste aproximado de 6 euros, y dispondrn de una antena integrada, control de frecuencia y una pequea batera.
ZigBee utiliza la banda de frecuencias ISM para usos industriales, cientficos y mdicos. En concreto, en Europa utiliza la banda de 868 MHz. Tambin muchas empresas optan por la banda de 2,4 GHz disponible en todo el mundo. El
FUOC PID_00147722
41
desarrollo de esta tecnologa se basa en su sencillez y bajo coste. Un nodo ZigBee ms completo requiere menos del 10% del hardware que necesita un nodo Bluetooth (requiere muchos menos circuitos analgicos de lo que es habitual). Los protocolos ZigBee estn definidos para su uso en aplicaciones encastadas con requerimientos muy bajos de transmisin de datos y consumo energtico. Se pueden utilizar para realizar un control industrial, albergar sensores empotrados, recolectar datos mdicos, detectar humo o intrusos y en domtica o teleasistencia. Una red en su conjunto utilizar una cantidad muy pequea de energa, de forma que cada dispositivo individual pueda tener una autonoma de hasta cinco aos antes de necesitar un recambio en su sistema de alimentacin.
Ejemplo de una aplicacin domtica con ZigBee
Las desventajas de ZigBee son: tasa de transferencia muy baja, slo manipula textos pequeos en comparacin con otras tecnologas, 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 mximo de 65.535 nodos distribuidos en subredes de 255 nodos (frente a los 8 nodos mximo 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 (artculos de juguetera, detectores...) frente al Bluetooth, que se suele utilizar en telfonos mviles o dispositivos de entrada/salida en equipos informticos en los que se requiere una velocidad de transmisin mayor. Provee conexiones seguras entre los dispositivos. Los dispositivos ZigBee son muy baratos y de construccin muy sencilla. En una red ZigBee existen tres tipos de dispositivos:
FUOC PID_00147722
42
1)CoordinadorZigBee(Coordinator,ZC). El tipo de dispositivo ms 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 computacin. 2)RouterZigBee(ZR). Interconecta dispositivos separados en una topologa de la red. Ofrece un nivel de aplicacin para ejecutar un cdigo de usuario. 3)Dispositivofinal(EndDevice,ZED). Tiene la funcionalidad necesaria de comunicarse al nodo padre (el coordinador o el router) pero no puede transmitir informacin destinada a otros dispositivos. De esta manera, este tipo de nodo puede estar dormido la gran mayora de tiempo, lo que aumenta la vida media de sus bateras. Un ZED tiene unos requerimientos mnimos de memoria y por eso es significativamente muy econmico.
Ejemplo de instalacin ZigBee En el caso de una aplicacin domtica, en una habitacin de la casa tendramos diversos dispositivos finales (un interruptor y una lmpara) y una red de interconexin realizada con routers ZigBee y gobernada por el coordinador.
Coordinador ZigBee
Routers ZigBee
Si nos basamos en la funcionalidad, se puede plantear una segunda clasificacin de los dispositivos ZigBee: Dispositivodefuncionalidadcompleta(FFD): tambin 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 acten de interfaz con los usuarios. Dispositivodefuncionalidadreducida(RFD): tambin conocido como nodo pasivo. Tiene unas capacidades y funcionalidades limitadas (especificadas en el estndar) con el objetivo de conseguir un bajo coste y una gran simplicidad. Bsicamente son los sensores y actuadores de la red.
Dispositivo final
Un nodo ZigBee, tanto activo como pasivo, reduce su consumo gracias a que puede estar dormido la mayor parte del tiempo (incluso muchos das 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 topologas de red: 1)Topologaenestrella: el coordinador se sita en el centro. 2)Topologaenrbol: el coordinador ser la raz del rbol.
FUOC PID_00147722
43
3)Topologaenmalla: al menos uno de los nodos tendr ms de dos conexiones. La topologa ms interesante es la topologa en malla. Permite que, si en un momento determinado un nodo del camino falla y se cae, se pueda realizar la comunicacin entre todos los otros nodos debido a que se rehacen todos los caminos. La gestin de los caminos la realiza el coordinador. La seguridad de las transmisiones y los datos son puntos clave en la tecnologa 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 encriptacin con un cdigo de 128 bits), 3) integracin 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 tecnologa inalmbrica 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, pequeos pueblos..., en los que se ofrece acceso a Internet. En Wi-Fi se utilizan las ondas portadoras de radio para transmitir la informacin. Los datos se superponen a la onda portadora de radio y se pueden extraer en el receptor final en un proceso conocido como modulacin/demodulacin.
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).
Un access point (AP) es el dispositivo que hace de puente entre una red cableada y una red inalmbrica. Podemos pensar que, de alguna manera, es la antena a la que nos conectamos.
Logotipo de Wifi
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 informacin, 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 ningn punto de acceso, sino entre ellos, crearemos una red llamada ad hoc.
Topologa simple ad hoc (sin punto de acceso) y topologa con un solo punto de acceso (BSS)
Topologa ms compleja: red cableada y puntos de acceso inalmbricos
FUOC PID_00147722
45
El IEEE 802 es un comit y grupo de estudio de estndares que pertenece al Instituto de Ingenieros Elctricos y Electrnicos (IEEE) que acta sobre redes de ordenadores. La especificacin concreta del sistema WiFi es la IEEE 802.11. Adems 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 ms largas. Los estndares 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 seal. Pero no se utilizan todos, porque se suplantan y producen interferencias. Los ms utilizados son los canales 1, 4, 9 y 13, ya que no son adyacentes y no reciben interferencias. Esta configuracin slo se hace habitualmente en el punto de acceso, ya que los dispositivos clientes detectan la seal. Para utilizar estas frecuencias no hace falta ninguna autorizacin (o licencia) de la administracin competente, y por lo tanto, es una tecnologa muy utilizada en entornos locales como edificios, oficinas, hospitales...
Red WiFi domstica 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, tambin 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 comunicacin con Internet.
Si conectamos muchos puntos de acceso entre s, el alcance de la red sin hilos aumentar. Esta accin se conoce como itinerancia, o en ingls, roaming.
Para establecer comunicacin 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 informacin. Actualmente muchos ordenadores ya llevan integrado el dispositivo WiFi dentro de la placa madre. En los modelos ms 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 ms alcance, pero slo en una sola direccin.
Una vez se ha establecido comunicacin 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 conexin entre un punto de acceso y un dispositivo WiFi hace falta configurar primero el punto de acceso. Cada punto de acceso tiene su propia configuracin, y actualmente se configuran con un entorno grfico al que se accede con el protocolo web. Cuando iniciamos por primera vez un punto de acceso, el dispositivo tiene unos parmetros de configuracin bsicos que pueden no satisfacer nuestros intereses. Muchos de estos parmetros se pueden cambiar. El ms importante es el serie set identifier (SSID): indica el identificador del servicio, y es el cdigo (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 funcin de buscar redes inalmbricas). Tambin se lo conoce como nombre de la red. El punto de acceso, para identificarse, emitir seales con este parmetro. Tambin con el entorno grfico se puede modificar el canal en el que emitimos la seal de onda portadora de radio. Habitualmente no cambiaremos este parmetro, pero si decidimos hacerlo, seguiremos las recomendaciones del ETSI.
FUOC PID_00147722
47
Una de las cosas ms importantes que se tiene que configurar es la seguridad de la comunicacin para poder dar acceso a nuestra red sin hilos a los equipos o personas que queramos. ElcifradoWEP (Wireless Encryption Protocol) codifica la informacin 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 ms seguridad que el WEP; adems, facilita la autoidentificacin del usuario (exige una clave y una contrasea para entrar dentro de la Red, y codifica la informacin transmitida por el aire). Para la mayora de redes pequeas, la encriptacin WAP es la manera ms sencilla de tener una seguridad efectiva. De las tres opciones, la PSK String es la mejor para implantar.
Estndar Ancho de banda Hasta 54 Mbps 1 Mbps Consumo de potencia Ventajas Aplicaciones
Wi-Fi
400 mA transmitiendo
Gran ancho de banda
Navegar por Internet, red de ordenadores, transferencia de ficheros
Bluetooth
40 mA transmitiendo
Interoperatividad, sustituto del USB sin hilos, mviles, informtica casera cable Batera de larga duracin, bajo coste Control remoto, productos dependientes de la batera, sensores, juegos
ZigBee
250 kbps
30 mA transmitiendo, 3 mA en reposo
1mA = 10 amperios
-3
2.5. WiMax Actualmente hay una gran demanda de servicios de acceso de banda ancha (altas velocidades de transmisin) en Internet y otras aplicaciones de voz y datos. De manera cableada actualmente se ofrecen servicio con las lneas ADSL, y de manera inalmbrica WiMax es la solucin que sirve tanto a los operadores de telecomunicaciones como a los usuarios. Con WiMax se est creando un mercado masivo de soluciones inalmbricas. Un nuevo estndar WMAN de banda ancha apareci promovido y desarrollado por el grupo WiMax (wireless interoperability for microwave access) acceso inalmbrico de banda ancha, que tiene dos miembros muy representativos, como Intel y Nokia. La etiqueta WiMax est asociada globalmente al propio nombre del estndar IEEE 802.16. La tecnologa WiMax supone una evolucin con respecto al WiFi. Permite la conectividad entre puntos fijos, nmadas y mviles, y eventualmente la conectividad mvil sin necesidad de tener una lnea punto a punto con una estacin base.
FUOC PID_00147722
48
Haciendo una analoga, WiMax es al estndar IEEE 802.16 lo que Wifi al estndar IEEE 802.11.
Wimax Forum El Wimax Forum es una agrupacin de ms de 350 compaas que se encarga de promover la interoperabilidad de dispositivos 802.16 y la unificacin de los estndares a nivel mundial. Incluye fabricantes de chips y de equipos y empresas que ofrecen servicios. Wimax Forum promueve la utilizacin del estndar IEEE 802.16, la certificacin de equipos, la interoperabilidad de Wimax entre diferentes marcas y la conformidad verificada en laboratorios autorizados.
FUOC PID_00147722
49
WiMax utiliza bandas de frecuencia con y sin licencia gubernamental. La banda que no necesita ninguna autorizacin 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 pases todava 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 visin directa (entre emisor y receptor). A principios del 2003, con la aparicin del 802.16a para ratificar el estndar inicial 802.16, se ampli el rango de frecuencias hacia las bandas de 2 a 11 GHz. En el ao 2004 aparece el estndar 802.16-2004 o IEEE 802.16d, tambin conocido como WiMAX, para cubrir las carencias del IEEE 802.16a.
En resumidas cuentas, existen dos estndares, IEEE 802.16d para WiMax fija, y IEEE 802.16e para WiMax mvil.
Espectro Funcionamiento Ancho debanda Modulacin Movilidad Anchodel espectro Distancia
802.16 10-66 GHz Slo con visin directa 32-134 Mbps
802.16a < 11 GHz Sin visin directa (NLOS)
802.16e < 6 GHz Sin visin directa (NLOS)
Hasta 75 Mbps con canales de 20 MHz OFDM con 256 subportadoras Sistema fijo Seleccin entre 1,25 y 20 MHz 5-50 km aprox.
Hasta 15 Mbps con canales de 5 MHz
QPSK, 16QAM y 64 QAM Sistema fijo 20, 25 y 28 MHz 2-5 km aprox.
Mismo que 802.16a
Movilidad pedestre El mismo que 802.16a con los canales de subida para ahorrar potencia 2-5 km aprox.
Hay que mencionar la aparicin del equipamiento denominado pre-WiMAX. Muchos fabricantes no esperaron a la aprobacin definitiva del estndar 802.16, y decidieron sacar al mercado (y todava lo siguen haciendo actualmente) equipos que implementan un protocolo propietario basado en los desarrollos realizados para la tecnologa 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 opcin (y muy utilizada) para despliegues en este tipo de entornos.
FUOC PID_00147722
50
Con respecto a velocidades, hay que diferenciar entre la velocidad de transmisin 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 Tecnologa pre-WiMAX WiMAX Velocidad mxima aire 54 Mbps 70 Mbps Velocidad mxima real ~30 Mbps ~40 Mbps
Sus principales caractersticas se resumen a continuacin: Modulacin adaptativa: se escogen dinmicamente en funcin de las condiciones del enlace, si ste tiene un buen comportamiento (pocas prdidas), se utiliza una modulacin que ms bits y, por lo tanto, la velocidad aumenta. En funcin de la distancia de la estacin a la estacin base se utiliza un tipo de modulacin u otra: 64QAM, 16QAM, QPSK... Bandafrecuencial: se puede trabajar en banda libre de 5,4 GHz, pero con poca potencia y con visin directa. Tambin hay banda licenciada (hace falta un permiso de la administracin para utilizar una determinada frecuencia) en 3,5 GHz, donde no es imprescindible la visin directa. Elementos: hay dos tipos de componentes, la estacin base (unidades de acceso, AU) y las unidades de abonado (SU). Perfiles: permiten enlaces punto a punto (con visin directa) y punto multipunto (sin necesidad de visin directa). Permitecalidaddeservicio(QoS): gracias al hecho de que WiMAX est orientado a la conexin. Tambin ofrece la especificacin antes de la transmisin de la calidad de servicio demandada (QoS): por ejemplo, la voz y el vdeo requieren una baja latencia (retraso), pero soportan bien la prdida de un poco de informacin, 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: Unsolicitedgrantservice(UGS): trfico de velocidad constante (constant bit rate), datos en tiempo real con paquetes de tamao fijo: VoIP sin supresin del silencio.
FUOC PID_00147722
51
Real-timepollingservice(rtPS): datos en tiempo real con paquetes de tamao variable generados en intervalos peridicos, como los paquetes de vdeo Moving Picture Expert Group (MPEG).
Extendedreal-timepollingservice(ertPS): es una optimizacin de UGS y rtPS: datos en tiempo real con paquetes de tamao variable generados en intervalos peridicos, tal como los VoIP con supresin de silencio.
Non-real-timepollingservice(nrtPS): soporta datos que toleran retardos como la transferencia de archivos (FTP: file transfer protocol).
Besteffort(BE): diseado para soportar trfico para el que no se ha definido ningn tipo de nivel de QoS, tal como la navegacin a travs 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 visin directa entre ellos. Las primeras versiones de WiMax fueron pensadas para comunicaciones punto a punto, o punto a multipunto tpicas de radioenlaces por microondas. Las futuras redes ofrecern total movilidad y podrn competir con las redes celulares. WiMax es adecuado para unir puntos con mucho trfico de informacin WiFi a las redes de los operadores de telecomunicaciones sin necesidad de establecer un enlace fijo. WiMax ampla la cobertura de una red WiFi y puede proveer una alternativa seria o complemento a las redes 3G.
Topologa 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 radiacin muy estrecho que se puede ir moviendo electrnicamente para enfocar siempre al receptor, con lo que evitan las interferencias entre canales adyacentes y se consume menos potencia para tener el haz ms concentrado. Otra aplicacin es la de ofrecer servicios a las zonas rurales de difcil acceso, a las que no llegan las redes cableadas. Es una tecnologa muy adecuada para establecer radioenlaces, debido a su gran cobertura y capacidad, y a un coste muy competitivo frente otras alternativas. La instalacin de estaciones base WiMax es sencilla y econmica, utilizando un hardware que llegar a ser estndar.
Diferentes fases de WiMax
A la izquierda, estacin de usuario acceso fijo. A la derecha, estacin base acceso fijo.
WiMax mvil y IEEE 802.16e, soportan varias tecnologas de antenas inteligentes: Beamforming. Space-time code (STC). Multiplexacin espacial.
En definitiva, WiMax nos ofrece un ancho de banda para equipos fijos y mviles, 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.
Ms de 250 operadores han realizado pruebas en ms de 65 pases, tal como se ve en la figura siguiente.
FUOC PID_00147722
53
Comparativa de WiMAX con otras tecnologas WiMAX 802.16 WiFi 802.11 MBWA 802.20 UMTS y CDMA2000 2 Mbit/s 10 km S Rango y movilidad Lento y caro
Velocidad Cobertura Licencia Ventajas Inconvenientes
124 Mbit/s 40-70 km S/No Velocidad y extensin geogrfica Interferencias
11-54 Mbit/s 300 m No Velocidad y precio Baja cobertura
16 Mbit/s 20 km S Velocidad y movilidad Precio alto
FUOC PID_00147722
54
Resumen
En este mdulo hemos visto la evolucin histrica de la telefona mvil, su crecimiento exponencial en nmero de usuarios a escala mundial, y cmo esta tecnologa y sus aplicaciones han evolucionado en muy pocos aos. Se ha pasado bsicamente de slo poder transmitir mensajes de texto con la tecnologa mvil GSM, a mejorar las conexiones a Internet con la tecnologa GPRS, para acabar en las ltimas aplicaciones totalmente multimedia sobre tecnologas EDGE y UMTS por el considerable aumento de las velocidades de transmisin y de sus coberturas. En el mbito de las redes inalmbricas se han visto las de uso ms cotidiano, las redes WiFi para aplicaciones de alcance local (vivienda, oficina), con distancias entre los equipos pequeas (varios centenares de metros). Para incrementar la distancia entre los equipos (varios kilmetros) se ha desarrollado la tecnologa inalmbrica WiMax. Adems, para interconectar dispositivos en muy poca distancia se utiliza la tecnologa infrarroja y la bluetooth. Finalmente, para instalar redes de sensores donde el consumo es el factor principal a tener en cuenta, existe la tecnologa ZigBee para que las bateras de estos sensores tengan una larga duracin.
FUOC PID_00147722
55
Bibliografa
Abad, F. J.; Canudas, J. M.; Martnez, R.; Nogueira, E. (2008). Informtica 4t. ESO. Barcelona: Teide. ISBN: 978-84-307-8685-5. Direcciones web Bluetooth. Disponible en web: <http://www.bluetooth.com/English/Pages/default.aspx>. [Fecha de consulta: 13 de abril del 2010.] International Engineering Consortium. Disponible en web: <http://www.iec.org>. [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: <http://articles.techrepublic.com.com/5100-10878_11-6139987.html> [Fecha de consulta: 13 de abril del 2010.] Umtsforum.net. Disponible en web: <http://www.umtsforum.net/default.asp>. [Fecha de consulta: 13 de abril del 2010.] Universidad Politcnica de Madrid. "Comunicaciones mviles con WAP, GPRS y UMTS" [plan docente del curso 2009-2010]. Disponible en web: <http://asignaturas.diatel.upm.es/ccmm/Documentacion.htm>. [Fecha de consulta: 13 de abril del 2010.] Zigbee Alliance. Disponible en web: <http://www.zigbee.org>. [Fecha de consulta: 13 de abril del 2010.] Zigbee Espaa. Disponible en web: <http://www.zigbee.es>. [Fecha de consulta: 13 de abril del 2010.]

Red

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Red

Cargado por

Copyright:

Formatos disponibles

Redes multimedia

10. Streaming de audio y vdeo almacenados

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

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

Tecnologas de red ......................................................................

Conceptos de redes de computadores

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

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

1. Conceptos de redes y comunicaciones en Internet

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Colas en la conmutacin de paquetes

Conceptos de redes de computadores

Funcionamiento de la conmutacin de paquetes y de mensajes

Conceptos de redes de computadores

En ingls, Wide Area Networks (WAN).

En ingls, Local Area Networks (LAN).

Conceptos de redes de computadores

En ingls, Wide Area Networks (WAN).

En ingls, Local Area Networks (LAN).

Conceptos de redes de computadores

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

Conceptos de redes de computadores

Conceptos de redes de computadores

OSI es la abreviatura de Open Systems Interconnection (interconexin de sistemas abiertos).

Conceptos de redes de computadores

En ingls, network interface card (NIC).

Conceptos de redes de computadores

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

Conceptos de redes de computadores

Conceptos de redes de computadores

Para explicar las comunicaciones multicapa, observemos la siguiente figura.

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

6. Jerarqua de protocolos y cabecera

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

Conceptos de redes de computadores

SNA es la abreviatura de System Network Architecture.

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

Conceptos de redes de computadores

Conceptos de redes de computadores

8.3. Modelo TCP/IP

se pueden distinguir cuatro capas:

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

Conceptos de redes de computadores

Pasemos a describirlas brevemente.