Redes Multimedia

Redes multimedia
Xavier Vilajosana Guilln (coordinador)

Miquel Font Rossell
Silvia Llorente Viejo
Joan Manuel Marqus Puig
PID_00147720
Redes multimedia
FUOC PID_00147720
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.

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.

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
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.
Redes multimedia
FUOC PID_00147720
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.
Redes multimedia
FUOC PID_00147720
Contenidos
Mdulo didctico1
Conceptos de redes de computadores
1.
Conceptos de redes y comunicaciones en Internet
2.
Qu es Internet y qu es un protocolo
3.
Hardware de red
4.
Dispositivos de red
5.
Software de red
6.
Jerarqua de protocolos y cabecera
7.
Interfaces y servicios
8.
Modelos de referencia
9.
Breve historia de las comunicaciones
Mdulo didctico2
Las capas de la red de computadores
1.
El nivel de transporte
2.
El nivel de red
3.
El enlace de datos y el control de acceso al medio
4.
El nivel fsico
Mdulo didctico3
Seguridad en la red
1.
Cortafuegos
2.
Redes privadas virtuales
3.
Introduccin a la criptografa
4.
Certificados digitales
5.
Seguridad en la red
Mdulo didctico4
El nivel de aplicacin
Joan Manuel Marqus Puig y Silvia Llorente Viejo
1.
Arquitecturas de aplicaciones distribuidas
2.
DNS: Servicio de nombres en Internet
3.
La web y el HTTP
4.
Transferencia de ficheros
5.
Correo electrnico en Internet
6.
Aplicaciones de igual a igual para la comparticin de ficheros
7.
Mensajera instantnea
8.
Telnet y Secure Shell: acceso a ordenadores remotos
9.
Aplicaciones multimedia en red
10. Streaming de audio y vdeo almacenados
Redes multimedia
FUOC PID_00147720
11. Protocolos para aplicaciones interactivas en tiempo real

12. Anexos
Mdulo didctico5
Comunicaciones inalmbricas
Miquel Font Rossell
1.
Sistemas de comunicacin de la telefona mvil
2.
Redes inalmbricas
Redes multimedia
Conceptos
de redes de
computadores
PID_00147725
FUOC PID_00147725
FUOC PID_00147725
ndice
Introduccin...............................................................................................
Objetivos.......................................................................................................
1.
Conceptos de redes y comunicaciones en Internet....................
2.
Qu es Internet y qu es un protocolo.........................................
3.
Hardware de red................................................................................
3.1.
Topologas de red ........................................................................
3.2.
Tipo de conmutacin ..................................................................
10
3.2.1.
Conmutacin de circuitos .............................................
10
3.2.2.
Conmutacin de paquetes .............................................
11
3.2.3.
Conmutacin de paquetes con circuito virtual .............
14
Alcance de las redes ....................................................................
15
3.3.1.
Redes de gran alcance ...................................................
16
3.3.2.
Redes de rea local ........................................................
16
Tecnologas de red ......................................................................
16
3.4.1.
Tecnologas de red cableada ..........................................
17
3.4.2.
Tecnologas de red sin hilos ..........................................
17
4.
Dispositivos de red............................................................................
19
5.
Software de red..................................................................................
21
5.1.
Arquitectura de la red: diseo por capas ....................................
22
5.2.
Consideraciones de diseo .........................................................
25
6.
Jerarqua de protocolos y cabecera...............................................
27
7.
Interfaces y servicios.........................................................................
29
7.1.
Tipo de conexin de servicios ....................................................
33
Modelos de referencia.......................................................................
35
8.1.
Necesidad de estandarizacin .....................................................
35
8.2.
El modelo de referencia OSI .......................................................
36
8.2.1.
Proceso de encapsulacin y desencapsulacin ..............
38
Modelo TCP/IP ............................................................................
39
3.3.
3.4.
8.
8.3.
8.3.1.
8.4.
Encapsulacin de la informacin en el modelo

TCP/IP ............................................................................
41
Modelo OSI comparado con modelo TCP/IP ..............................
42
FUOC PID_00147725
9.
Breve historia de las comunicaciones..........................................
44
Resumen.......................................................................................................
56
Bibliografa.................................................................................................
59
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.
15
FUOC PID_00147725
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
2
redes de alcance local .

Antes de detallar qu son las LAN y las WAN es conveniente introducir en
primer lugar los conceptos de redes de difusin y redes punto-a-punto.
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).
(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.
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
(3)
En ingls, Wide Area Networks

(WAN).
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
(4)
En ingls, Local Area Networks

(LAN).
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.
17
FUOC PID_00147725
3.4.1. Tecnologas de red cableada

Dentro de las redes cableadas, la familia de tecnologas por excelencia es Et5
hernet (definido en el estndar IEEE 802.3) , que empez como una tecnologa
(5)
IEEE es la abreviatura del Institute of Electronic and Electrical Engineers.
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.
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.
19
FUOC PID_00147725
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 mo-
(6)
En ingls, router.
delo 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 dife-
(7)
OSI es la abreviatura de Open

Systems Interconnection (interconexin de sistemas abiertos).
rentes 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
Conmutador . Es un dispositivo digital de lgica de interconexin de re-
(8)
En ingls, hub.
des 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.
Concentrador
(9)
10
Puentedered . Es un dispositivo de interconexin de redes de ordena-
En ingls, switch.
dores que opera en la capa 2 (nivel de enlace de datos) del modelo OSI.
ste interconecta dos segmentos de red (o divide una red en segmentos)
Conmutador
permitiendo el paso de datos de una red a otra mediante el uso de la direccin fsica de destino de cada paquete. Un bridge conecta dos segmentos de
red como una sola red utilizando el mismo protocolo de establecimiento
(10)
En ingls, bridge.
de red.
Tarjetadeinterfazdered. Fsicamente es una tarjeta de expansin insertada dentro del ordenador con una o ms aberturas externas por donde se
11
conecta el cable de red. En el plano conceptual, la tarjeta de red , 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
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 Ether-

(11)
En ingls, network interface card

(NIC).
net, 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).
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
31
FUOC PID_00147725
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
Significado
Una entidad quiere que el servicio realice alguna cosa.
Indication
Una entidad es informada de algn evento.
Response
Una entidad quiere responder a algn evento.
Confirm
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
Protocolo orientado a
conexin
El ejemplo por excelencia de
un protocolo orientado a conexin es el TCP.
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.
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.
36
FUOC PID_00147725
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.
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.
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.
FUOC PID_00147725
37
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.
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.

(13)
SNA es la abreviatura de System

Network Architecture.
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.
39
FUOC PID_00147725
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)
14
En el modelo TCP/IP
se pueden distinguir cuatro capas:
La capa interfaz de red.
La capa de red o Internet.
La capa de transporte.
La capa de aplicacin.
TCP/IP es la abreviatura de
Transmission Control Protocol/Internet Protocol.
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
(15)
Recordad que la red telefnica

slo deja pasar sonidos entre unos
mrgenes de frecuencia.
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
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)
ARPA es la abreviatura en ingls de la Agencia de Proyectos de Investigacin Avanzada.
(17)
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
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).
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.
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.
1971. Ray Tomlison (BBN18) 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
backbone de Internet (NSFNET19), al lado de Argentina, Brasil, Chile, India, Suiza,
Austria, Irlanda y Corea del Sur.
1991. Tim Berners-Lee, investigador en el centro europeo CERN, en Suiza, elabor

su propuesta de un sistema de hipertexto compartido: era el primer esbozo de la
World Wide Web. Como el ARPANet veinte 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.
En la parte superior de la imagen se puede

ver el primer banner de Internet en HotWired
(1994).
FUOC PID_00147725
51
1995. Se empiezan a cobrar los dominios. Sun crea Java, y RealAudio incorpora sonido en la Red. Microsoft lanza con gran publicidad Windows 95 y anuncia un giro
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.
TCP/IP naci a partir de un encargo de la Defense Advanced Research Project

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

para la Defensa.
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.
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
(21)
ISO son las siglas de la International Organization for Standardization, en castellano, Organizacin
Internacional de Estandarizacin.
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.
Objetivos ......................................................................................
1.2.
Servicios ofrecidos por la capa de transporte .............................
1.3.
Relacin entre la capa de transporte y la capa de red .................
1.4.
Transporte no orientado a la conexin: UDP .............................
12
1.4.1.
Cabecera UDP ................................................................
12
1.4.2.
Cabecera UDP ................................................................
13
Transporte orientado a la conexin: TCP ...................................
14
1.5.1.
Funcionamiento bsico de TCP .....................................
15
1.5.2.
Cabecera TCP .................................................................
16
1.5.3.
Establecimiento de la conexin ....................................
19
El nivel de red....................................................................................
21
2.1.
Funcionalidades bsicas: direccionamiento ................................
21
2.2.
Servicios de red ...........................................................................
24
2.2.1.
Modelo de red en modo de circuitos virtuales ..............
25
2.2.2.
Modelo de red en modo datagrama ..............................
26
2.2.3.
Servicio de red orientado y no orientado a la
1.5.
2.
2.3.
4.
27
Direccionamiento en Internet: el protocolo IP ...........................
27
2.3.1.
IPv4 ................................................................................
28
2.3.2.
IPv6 ................................................................................
42
Protocolos de soporte a IP ..........................................................
49
2.4.1.
Internet Control Message Protocol ...............................
49
2.4.2.
Address Resolution Protocol ..........................................
51
2.4.3.
Network Discovery Protocol ..........................................
52
2.4.4.
Dynamic Host Configuration Protocol .........................
53
El enlace de datos y el control de acceso al medio....................
54
3.1.
Terminologa y definiciones .......................................................
55
3.2.
Tipo de enlaces ...........................................................................
56
3.3.
Tipo de servicios suministrado en la capa de red .......................
56
3.4.
Servicios proporcionados por la capa de enlace .........................
57
3.5.
Adaptadores y dispositivos de red ..............................................
58
El nivel fsico......................................................................................
60
4.1.
60
2.4.
3.
conexin ........................................................................
Medios de transmisin ................................................................
FUOC PID_00147723
4.1.1.
Par trenzado ...................................................................
60
4.1.2.
Cable coaxial de banda base .........................................
62
4.1.3.
Fibra ptica ....................................................................
62
Resumen.......................................................................................................
64
Bibliografa.................................................................................................
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.
10
FUOC PID_00147723
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)
Aplicaciones pblicas.
255-1.023(IANA)
Asignados a empresas con aplicaciones comerciales.
> 1.023
No estn registrados (efmeros).
Puerto de aplicaciones pblicas establecidas por IANA

Decimal
Palabra clave
Descripcin
Reservado
1-4
No asignado
RJE
ECHO
DISCARD
11
USERS
13
DAYTIME
De da
15
NETSTAT
Quin est conectado o NETSTAT
17
QUOTE
19
CHARGEN
Generador de caracteres
20
FTP-DATA
Protocolo de transferencia de archivos (datos)
21
FTP
23
TELNET
25
SMTP
Protocolo SMTP (simple mail transfer protocol)
37
TIME
Hora
39
RLP
42
NAMESERVER
43
NICNAME
Quin es
53
DOMAIN
Servidor de denominacin
67
BOOTPS
Servidor de protocolo de arranque
68
BOOTPC
Cliente del protocolo de arranque
69
TFTP
Entrada remota de tareas

Eco
Descartar
Usuarios activos
Cita del da
Protocolo de transferencia de archivos

Conexin de terminal
Protocolo de ubicacin de recursos

Servidor de nombre de anfitrin
Protocolo trivial de transferencia de archivos
11
FUOC PID_00147723
Decimal
Palabra clave
Descripcin
75
Cualquier servicio privado de conexin telefnica
77
Cualquier servicio RJE privado
79
FINGER
80
HTTP
95
SUPDUP
101
HOSTNAME
102
ISO-TSAP
113
AUTH
117
UUCP-PATH
123
NTP
137
NetBIOS
Servicio de nombres
139
NetBIOS
Servicio de datagramas
143
IMAP
150
NetBIOS
156
SQL
161
SNMP
179
BGP
190
GACP
194
IRC
Internet relay chat
197
DLS
Servicio de localizacin de directorios
224-241
No asignado
242-255
No asignado
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
Interim mail access protocol

Servicio de sesin
Servidor SQL
Simple network management protocol
Border gateway protocol
Gateway access control protocol
Puertos usados por algunos de los protocolos de nivel aplicacin
12
FUOC PID_00147723
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
Puertos
TFTP
69
SNMP
161
DHCP - BOOTP
67/68
DNS
53
1.4.1. Cabecera UDP

La unidad de cabecera de UDP es el datagrama UDP.
Cada escritura por parte de la aplicacin provoca la creacin de un datagrama UDP. No hay segmentacin.
13
FUOC PID_00147723
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

1
todas las API 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:
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.
Checksum
El checksum se calcula haciendo el complemento a 1 de la
suma de todas las palabras de
16 bits que conforman el datagrama UDP.
FUOC PID_00147723
15
El TCP da fiabilidad a la 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
Ved tambin
Se puede encontrar ms informacin sobre el direccionamiento en el subapartado "Direccionamiento IPv4".
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.
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.
32
FUOC PID_00147723
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

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

21
(256) direcciones, con un total de 2
(2.097.152) direcciones de tipo C a
repartir.
Con respecto a las 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.
Divisin de redes por clases

Clase
Bitsiniciales
BitsRed
RangoRed
7 (+1)
1.0.0.0-127.0.0.0
10
14 (+2)
128.0.0.0-191.255.0.0
110
21 (+3)
192.0.0.0-223.255.255.0
1110
224.0.0.0-239.0.0.0
11110
240.0.0.0-255.0.0.0
Carencia de direcciones IP
El reparto de clases A es uno
de los causantes de la fuerte
carencia de direcciones IP en la
actualidad.
FUOC PID_00147723
33
Direcciones de propsito especfico

Aparte de la divisin en redes tambin se destinaron una serie de direcciones
de propsito especfico para casos especiales:
Direccionesdehost. 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
34
FUOC PID_00147723
en la tabla siguiente. Como se observa en dicha tabla, se pueden configurar internamente diversos rangos de direcciones privadas, cuya utilidad es
evitar colisiones en asignaciones de direcciones en configuraciones internas con nodos de otras redes del exterior. Otra funcionalidad es permitir
asignar ms direcciones a nuestras redes que IP pblicas asignadas por los
operadores.
Lista de rangos de direcciones privadas
Clase
RangoRed
Nmerodesubredes
10.0.0.0-10.255.255.255
172.16.0.0-172.31.255.255
16
192.168.0.0-192.168.255.255
255
Network Address Translation

El problema principal de las direcciones privadas es que no pueden acceder a Internet
directamente, los encaminadores nunca 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.
36
FUOC PID_00147723
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
. 45
.1
. 23
255
. 255
. 255
.0
143
. 45
.1
.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.
37
FUOC PID_00147723
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
IPasignables
Explicacin
147.83.32.0/24
1.23.167.23/32
1.23.167.0/32
147.83.32.0/16
Solucin
Direccin
IPasignables
147.83.32.0/24
254
Explicacin
Es una direccin de red en la que tenemos 8 bits para los equipos; sabiendo que la
8
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
Direccin con una subred con slo un equipo. No es til en un caso real, pero es correcta.
38
FUOC PID_00147723
Direccin
IPasignables
Explicacin
1.23.167.0/32
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.
147.83.32.0/16
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.
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

4
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)
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.
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.
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).
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.
45
FUOC PID_00147723
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
Espaciodeasignacin
0000::/8
Reservado. Las direcciones de loopback y las direcciones con integracin de IPv4 salen de este prefijo
0100::/8
Reservado
0200::/7
Reservado
0400::/6
Reservado
0800::/5
Reservado
1000::/4
Reservado
2000::/3
Direccin unicast global. De aqu sale el rango de direcciones

125
que se repartirn a los usuarios. Hay 2 direcciones disponibles.
4000::/3
Reservado
6000::/3
Reservado
8000::/3
Reservado
A000::/3
Reservado
C000::/3
Reservado
E000::/4
Reservado
F000::/5
Reservado
F800::/6
Reservado
FC00::/7
Direccin unicast local nica
FE00::/9
Reservado
FE80::/10
Direccin de enlace local unicast (link-local)
FEC0::/10
Reservado
FF00::/8
Direcciones multicast
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).
50
FUOC PID_00147723
El ICMP es el encargado de enviar mensajes de control (y de error) entre

los diferentes equipos que forman la red.
La tabla siguiente muestra todos los tipos de mensajes existentes con ICMP.
Descripcin de los diferentes mensajes ICMP
Mensaje
Descripcin
Destinationunreachable
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.
Echorequest/Echoreply
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.
Sourcequench
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.
Routeradvertisement
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.
Routerdiscovery
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.
TTLexpired
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.
IPheaderbad
En el caso de que se detecte un error de checksum en la cabecera de un paquete IP, ste se descarta y se avisa al origen con este paquete ICMP.
Los mensajes ICMP tienen varias utilidades, desde reportar errores hasta depurar el estado de la red. Una de las herramientas 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
Bibliografa
Para una descripcin ms
completa de todos los tipos
de mensajes existentes con
ICMP se puede consultar el
documento RFC-792.
FUOC PID_00147723
51
paquete (IP origen) para saber de qu router se trata. Por descontado, con TTL
= 2 suceder lo mismo con el segundo encaminador, y 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
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
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.
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 encap5
sular/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.
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.
(5)
PDU son las siglas de Protocol

Data Unit.
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.
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.
(6)

Systems Interconnection; en castellano, interconexin de sistemas
abiertos.
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)
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)
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.
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
Fibra ptica
63
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
Seguridad en la red
FUOC PID_00147721
ndice
Introduccin...............................................................................................
Objetivos.......................................................................................................
1.
2.
3.
Cortafuegos..........................................................................................
1.1.
Sistemas cortafuegos ...................................................................
10
1.2.
Construccin de sistemas cortafuegos ........................................
11
1.2.1.
Encaminadores con filtrado de paquetes ......................
11
1.2.2.
Pasarela en el mbito de aplicacin ..............................
13
Redes privadas virtuales..................................................................
16
2.1.
Definicin y tipo de redes privadas virtuales .............................
16
2.2.
Configuraciones y protocolos utilizados en VPN .......................
17
Introduccin a la criptografa.......................................................
20
3.1.
Criptografa de clave simtrica ...................................................
22
3.1.1.
Algoritmos de cifrado de flujo ......................................
24
3.1.2.
Algoritmos de cifrado de bloque ...................................
26
3.1.3.
Uso de los algoritmos de clave simtrica .......................
29
3.1.4.
Funciones hash seguras ..................................................
32
Criptografa de clave pblica ......................................................
34
3.2.1.
Algoritmos de clave pblica ..........................................
34
3.2.2.
Uso de la criptografa de clave pblica ..........................
37
3.2.3.
Infraestructura de clave pblica ....................................
38
Certificados digitales........................................................................
39
4.1.
Cadenas de certificados y jerarquas de certificacin .................
40
4.2.
Listas de revocacin de certificados ............................................
40
Seguridad en la red...........................................................................
42
5.1.
Cookies ........................................................................................
42
5.2.
Contenidos activos ......................................................................
43
5.2.1.
Applets ...........................................................................
43
5.2.2.
Servlets/JSP .....................................................................
44
5.2.3.
CGI .................................................................................
44
5.2.4.
ASP/PHP .........................................................................
45
5.2.5.
RIA ..................................................................................
46
Protocolos de seguridad ..............................................................
46
5.3.1.
PGP .................................................................................
47
SSL ...............................................................................................
49
5.4.1.
50
3.2.
4.
5.
5.3.
5.4.
Caractersticas del protocolo SSL/TLS ............................
Seguridad en la red
FUOC PID_00147721
5.4.2.
El transporte seguro SSL/TLS .........................................
52
Transacciones seguras en red ......................................................
58
5.5.1.
Secure Electronic Transaction ........................................
58
5.5.2.
3D-Secure .......................................................................
59
Resumen.......................................................................................................
60
Bibliografa.................................................................................................
63
5.5.
FUOC PID_00147721
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
Seguridad en la red
FUOC PID_00147721
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.
Seguridad en la red
FUOC PID_00147721
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.
Seguridad en la red
FUOC PID_00147721
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.
Seguridad en la red
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.
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.
(1)
En ingls, firewall.
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
3
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)
En ingls, proxy.
FUOC PID_00147721
14
El servicio proxy se encargar de realizar las conexiones solicitadas con el exterior, y cuando reciba una respuesta se encargar de retransmitirla hacia el
equipo que 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.
Seguridad en la red
FUOC PID_00147721
15
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.
Seguridad en la red
FUOC PID_00147721
16
Seguridad en la red
2. Redes privadas virtuales
Los protocolos seguros que hemos visto hasta ahora permiten proteger las comunicaciones, por ejemplo, de una 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
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.
(4)
En ingls, Virtual Private Network (VPN).
FUOC PID_00147721
17
Seguridad en la red
2) Cuando un empleado de la empresa quiere acceder a la intranet desde un

ordenador remoto, puede establecer una VPN de este tipo entre este ordenador
y la intranet de la empresa. El ordenador remoto puede ser, por ejemplo, un
PC que el empleado tiene en su casa, o un ordenador 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.
18
FUOC PID_00147721
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 PPTP (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.
19
FUOC PID_00147721
El protocolo L2F (RFC 2637) es parecido al PPTP pero tambin puede trabajar con SLIP, adems de con PPP. Para la autenticacin puede utilizar
Seguridad en la red
(7)
L2F es la abreviatura de Layer

Two Forwarding.
protocolos auxiliares como Remote Authentication Dial-In User Service

(RADIUS).
El protocolo L2TP8 (RFC 2661) combina las funcionalidades que ofrecen

PPTP y L2F.
(8)
L2TP es la abreviatura de Layer

Two Tunneling Protocol.
(9)
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.
20
FUOC PID_00147721
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.
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.
Criptografa
Los trminos criptografa, criptologa, etc. provienen de la
raz griega krypts, que quiere
decir 'escondido'.
21
FUOC PID_00147721
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
Seguridad en la red
22
FUOC PID_00147721
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,probandounoaunotodoslosvaloresposiblesdelaclavededescifradox 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)
Seguridad en la red
23
FUOC PID_00147721
Seguridad en la red
M = d(k,C) = d(k,e(k,M))
La seguridad del sistema reside, pues, en mantener en secreto la clave k. Cuando los participantes en una 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
24
FUOC PID_00147721
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.
Seguridad en la red
FUOC PID_00147721
25
Esquema del cifrado y descifrado de flujo
Hay diferentes maneras de obtener el texto de cifrado S en 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.
Seguridad en la red
FUOC PID_00147721
26
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,
Seguridad en la red
FUOC PID_00147721
27
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
Seguridad en la red
FUOC PID_00147721
28
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
Seguridad en la red
29
FUOC PID_00147721
de paridad, de manera que la longitud efectiva de la clave es de 56 bits. Los bloques de

texto en los cuales se aplica el DES tienen que ser de 64 bits cada uno.
La parte central del algoritmo consiste en dividir la entrada en grupos de bits, hacer una
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
Seguridad en la red
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
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.
Seguridad en la red
32
FUOC PID_00147721
Seguridad en la red
3.1.4. Funciones hash seguras

Aparte de cifrar datos, hay algoritmos basados en tcnicas criptogrficas que
(10)
En ingls, message digest.
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.
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.
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.
FUOC PID_00147721
33
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.
Seguridad en la red
FUOC PID_00147721
34
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):
Seguridad en la red
35
FUOC PID_00147721
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:
Seguridad en la red
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).
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.
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.
37
FUOC PID_00147721
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
38
FUOC PID_00147721
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).
Seguridad en la red
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
(11)
En ingls, Certification Authority (CA).
ella. Quien firma el certificado puede ser una autoridad que se responsabilice
de verificar de manera fehaciente la autenticidad de las claves 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 co-
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.
mo 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 organizati-
(12)
En ingls, Distinguished Name

(DN).
vas), 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.
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
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.
Seguridad en la red
FUOC PID_00147721
42
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.
Seguridad en la red
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
(14)
En ingls, Web Application Archive.
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)
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
(16)
En ingls, Active Server Pages

(ASP).
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.
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)

Systems Interconnection, en castellano, interconexin de sistemas
abiertos.
FUOC PID_00147721
47
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
Seguridad en la red
FUOC PID_00147721
48
los ficheros y mensajes, con lo que se puede garantizar la integridad de los

mismos. Mediante este programa podemos llevar la 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.
Seguridad en la red
FUOC PID_00147721
49
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
Seguridad en la red
FUOC PID_00147721
50
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:
Seguridad en la red
FUOC PID_00147721
51
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.
Seguridad en la red
FUOC PID_00147721
52
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
Seguridad en la red
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).
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
Algoritmos de compresin
El nico algoritmo de compresin previsto en SSL TLS es el
algoritmo nulo, es decir, ninguna compresin.
FUOC PID_00147721
55
contendr el certificado X.509 del servidor, o una cadena de certificados. Si

el servidor no tiene certificado, o se ha acordado un 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).
Seguridad en la red
FUOC PID_00147721
56
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.
Seguridad en la red
FUOC PID_00147721
Negociacin de una sesin SSL/TLS nueva
Negociacin de una sesin SSL/TLS que se reanuda
57
Seguridad en la red
FUOC PID_00147721
58
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.
Seguridad en la red
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).
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.
(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
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.
Seguridad en la red
FUOC PID_00147721
60
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
Seguridad en la red
FUOC PID_00147721
61
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.
Seguridad en la red
FUOC PID_00147721
63
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.
Seguridad en la red
El nivel de
aplicacin
PID_00147724
FUOC PID_00147724
FUOC PID_00147724
ndice
Introduccin...............................................................................................
Objetivos.......................................................................................................
1.
Arquitecturas de aplicaciones distribuidas................................

1.1.
Cliente-servidor (client/server en ingls) ......................................
10
1.1.1.
Aplicaciones basadas en la web .....................................
12
De igual a igual (peer-to-peer, en ingls) ......................................
13
1.2.1.
Aplicaciones de igual a igual .........................................
15
1.3.
Ventajas y desventajas de cliente-servidor y de igual a igual ......
16
1.4.
Requerimientos de las aplicaciones ............................................
17
DNS: Servicio de nombres en Internet.........................................
19
2.1.
DNS: base de datos jerrquica y distribuida ...............................
21
2.2.
Caching de DNS ...........................................................................
23
2.3.
Peticiones recursivas frente a peticiones iterativas .....................
24
2.4.
Registros DNS ..............................................................................
25
2.5.
Consideraciones de seguridad .....................................................
26
La web y el HTTP..............................................................................
27
3.1.
HTTP: Hypertext Transfer Protocol..................................................
28
3.1.1.
Conexiones persistentes y no persistentes ....................
29
Formato de los mensajes HTTP ..................................................
30
3.2.1.
Mensaje HTTP de peticin ............................................
30
3.2.2.
Mensaje HTTP de respuesta ...........................................
31
3.3.
HTTPS (HTTP seguro) ..................................................................
33
3.4.
Cookies ........................................................................................
34
3.5.
Caractersticas de la demanda de pginas web ...........................
35
3.6.
Servidores intermediarios ............................................................
37
3.7.
El GET condicional .....................................................................
38
3.8.
Distribucin de contenidos .........................................................
39
3.8.1.
Redes de distribucin de contenidos .............................
41
Transferencia de ficheros................................................................
43
4.1.
Seguridad en la transferencia de ficheros ...................................
44
Correo electrnico en Internet.......................................................
45
5.1.
SMTP ............................................................................................
46
5.2.
Formato de los mensajes ............................................................
47
5.2.1.
Formato de mensajes MIME ..........................................
48
Protocolos para acceder a los buzones de correo ........................
50
1.2.
2.
3.
3.2.
4.
5.
5.3.
FUOC PID_00147724
6.
5.3.1.
POP3 ...............................................................................
51
5.3.2.
IMAP ...............................................................................
52
5.3.3.
Web ................................................................................
53
Aplicaciones de igual a igual para la comparticin de

ficheros..................................................................................................
54
6.1.
Redes superpuestas no estructuradas ..........................................
54
6.2.
Redes superpuestas estructuradas ................................................
57
Mensajera instantnea....................................................................
60
7.1.
XMPP ...........................................................................................
60
Telnet y Secure Shell: acceso a ordenadores remotos...............
63
8.1.
Seguridad del protocolo Telnet ...................................................
63
8.2.
Secure Shell .................................................................................
64
Aplicaciones multimedia en red....................................................
65
9.1.
Ejemplos de aplicaciones multimedia ........................................
65
9.1.1.
Streaming de audio y vdeo almacenados ......................
66
Streaming en directo de audio y vdeo ........................................
66
9.2.1.
Audio y vdeo en tiempo real interactivo .....................
67
Multimedia en Internet ..............................................................
67
9.3.1.
Compresin de audio y vdeo .......................................
69
9.3.2.
Formatos de audio y vdeo ............................................
71
10. Streaming de audio y vdeo almacenados...................................
74
10.1. Acceso va servidor de web .........................................................
75
10.2. Real Time Streaming Protocol (RTSP) .............................................
76
10.2.1. Los estados del RTSP .....................................................
78
10.2.2. Diagrama de estados del cliente ....................................
78
10.2.3. Diagrama de estados del servidor ..................................
79
10.2.4. Mtodos RTSP ................................................................
80
10.2.5. El protocolo RTSP ..........................................................
80
10.2.6. El mensaje de peticin RTSP .........................................
81
10.2.7. El mensaje de respuesta RTSP ........................................
82
10.2.8. Ejemplo de uso del protocolo RTSP ..............................
83
11. Protocolos para aplicaciones interactivas en tiempo real......
86
11.1. Real Time Transport Protocol (RTP) ...............................................
86
11.1.1. Descripcin del RTP .......................................................
86
7.
8.
9.
9.2.
9.3.
11.1.2. La cabecera del RTP .......................................................
87
11.2. Real Time Control Protocol (RTCP) ...............................................
88
11.2.1. Los paquetes RTCP ........................................................
89
11.2.2. Uso del ancho de banda en el protocolo RTCP .............
90
11.3. Session Initiation Protocol (SIP) .....................................................
91
11.3.1. Funcionalidad del SIP ....................................................
91
11.3.2. El protocolo SIP .............................................................
96
FUOC PID_00147724
11.3.3. El mensaje de peticin SIP ............................................
97
11.3.4. El mensaje de respuesta SIP ...........................................
98
11.4. H.323 ...........................................................................................
99
11.5. Skype ............................................................................................
101
12. Anexos...................................................................................................
103
12.1. Anexo 1. El protocolo RTSP ........................................................
103
12.1.1. rdenes ..........................................................................
103
12.1.2. Cdigos de estado ..........................................................
103
12.1.3. Cabeceras .......................................................................
104
12.2. Anexo 2. El formato de los paquetes RTCP ................................
105
12.2.1. Informe de emisor (SR) ..................................................
105
12.2.2. Informe de receptor (RR) ...............................................
107
12.2.3. Descripcin de elementos de la fuente (SDES) ..............
108
12.2.4. Paquete de cierre (BYE) .................................................
109
12.2.5. Paquete definido por la aplicacin (APP) ......................
109
12.3. Anexo 3. El protocolo SIP ...........................................................
110
12.3.1. Cdigos de estado ..........................................................
110
12.3.2. Cabeceras .......................................................................
112
Resumen.......................................................................................................
114
Bibliografa.................................................................................................
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.
10
FUOC PID_00147724
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
1
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)
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
(1)
De igual a igual en ingls se denomina peer-to-peer o p2p.
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
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.
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.
16
FUOC PID_00147724
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.
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.
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.
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.
Ventajas
Cliente-servidor
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.
17
FUOC PID_00147724
Ventajas
Deigualaigual
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 tra-
(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.
duccin 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.
(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
Direccin web
recomendada
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
En http://www.rootservers.org/ podis ver la ubicacin de los servidores DNS

raz.
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)
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.
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.
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.
FUOC PID_00147724
28
Los protocolos ms habituales son: http, ftp (File Transfer Protocol) y file (para
Ved tambin
el acceso y la localizacin de archivos dentro de sistemas de ficheros).
El protocolo ftp se trata en el

apartado 4 de este mdulo.
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.
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 paradig-
(7)
El HTTP est definido en los RFC

1.945 y 2.616.
ma cliente-servidor. Clientes y servidores se intercambian mensajes HTTP. El

HTTP define la estructura de estos mensajes y 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.
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.
Ejemplo
Una pgina que contiene texto en HTML y dos imgenes
en GIF contiene tres objetos:
la pgina HTML base y las dos
imgenes.
29
FUOC PID_00147724
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.
30
FUOC PID_00147724
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
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.
Ved tambin
Veris en el subapartado 3.6
que la cabecera Last-Modified es una cabecera crtica
para los servidores cach.
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.
(8)
Recordad que hay que pulsar dos veces la tecla de retorno despus de teclear la ltima
lnea.
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.
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.
(9)
Las cookies estn definidas en el

RFC 2.965.
FUOC PID_00147724
35
Las cookies, al ser texto, no son ejecutables. Por el hecho de no ser ejecutables,
no se pueden replicar por s mismas y, por lo tanto, no son virus. Debido al
mecanismo para guardar y leer las cookies, estas se pueden usar como spyware.
Los productos antispyware pueden avisar a los usuarios sobre algunas cookies
porque estas se pueden usar para hacer un seguimiento de las operaciones del
usuario o vulnerar la privacidad.
La 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)
La ley de Zipf debe su nombre a George Kingsley Zipf (19021950).
LeydeZipf
En muchos casos, la popularidad relativa entre diferentes sitios web o
10
entre distintas pginas de un cierto sitio web se rige por la ley de Zipf ,
que formulada de manera sencilla sera: muy pocos casos tienen mucha
popularidad y muchos casos tienen muy poca.
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.
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.
(11)
En ingls, web cache o proxy-cache.
38
FUOC PID_00147724
2) Si el proxy-cache tiene una copia del objeto, lo retorna dentro de un mensaje

HTTP de respuesta al navegador cliente.
3) En caso de que el proxy-cache no tenga el objeto pedido, este abre una nueva
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
12
proveedores de acceso a Internet
son los que instalan los proxy-cache. Por
ejemplo, una universidad puede instalar un proxy-cache en la red del campus

y configurar todos los navegadores para que apunten al proxy-cache.
Hay dos razones principales para desplegar proxy-cache en Internet:
Se puede reducir de manera significativa el tiempo de respuesta de las peticiones.
Puede reducir de manera significativa el 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
(12)
En ingls, Internet Service Providers (ISP)
FUOC PID_00147724
39
posterior a que al cliente lo copiara en su cach. Para solucionarlo, el protocolo

HTTP incluye un mecanismo que permite a la cach verificar que su copia del
objeto est actualizada.
GET /MiDirectorio/pagina.html HTTP/1.1

Host: www.servidor.edu
If-modified-since: Wed, 18 Feb 2009 21:11:55 GMT
La cabecera If-modified-since: contiene el valor de la cabecera

Last-Modified: de cuando el servidor envi el objeto. Esta 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.
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
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.
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
(13)
En ingls, Content Delivery Networks (CDN).
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.
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.
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,
(14)
Siglas en ingls de File Transfer

Protocol
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
(15)
SFTP es la abreviatura de SSH

File Transfer Protocol o Secure File
Transfer Protocol.
(16)
FTPS es la abreviatura de FTP

sobre SSL.
SFTP15 o FTPS16.
El SFTP es un protocolo que proporciona acceso, transferencia y 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.
IETF
El SFTP fue diseado por la Internet Engineering Task Force
(IETF) como una ampliacin
del Secure Shell Protocol (SSH)
versin 2.0.
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.
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).
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.
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.
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
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.)
48
FUOC PID_00147724
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
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
Algunossubtipos
plain, html
image
jpeg, gif
audio
basic, mp4, mpeg
video
mpeg, quicktime
application
msword, octet-stream, zip
(17)
MIME es la abreviatura de Multipurpose Internet Mail Extensions.
RFC del formato MIME

El formato de mensajes MIME
est especificado en los RFC
2.045, 2.046, 2.047, 4.288,
4.289 y 2.049.
49
FUOC PID_00147724
La Internet Assigned Numbers Authority (IANA) mantiene la lista de tipos

y subtipos. 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.
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".
(18)
El protocolo POP3 (Post Office

Protocol versin 3) est especificado en el RFC 1939.
FUOC PID_00147724
52
Ejemplo de bajar y borrar los mensajes

El agente de usuario obtiene una lista de los mensajes (LIST), y los va bajando (RETR) y
borrando (DELE) uno a uno. Por claridad, identificamos las 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,
(19)
El IMAP est especificado en el

RFC 3.501.
tanto en la parte cliente como en la parte del servidor.

Los servidores IMAP20 asocian cada mensaje a una carpeta. Cuando un mensaje llega al servidor, este se asocia a la carpeta INBOX. Posteriormente, el receptor puede mover este mensaje a otra carpeta creada por el mismo usuario.
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)
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.
60
FUOC PID_00147724
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.
22
Como se puede ver en la siguiente figura, el XMPP
utiliza una arquitectura
cliente-servidor descentralizada: de manera similar a como lo hace el SMTP,
(21)
XMPP es la abreviatura de Extensible Messaging Presence Protocol. El XMPP antes se conoca como jabber.
(22)
El puerto estndar para el

XMPP es el 5222.
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.
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.
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
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.
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
(23)
La especificacin de Telnet se
public en el ao 1983 en el estndar RFC 854.
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.
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).
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.
Puerto TCP 22
El puerto estndar para contactar a un servidor SSH es el
puerto TCP 22.
FUOC PID_00147724
65
9. Aplicaciones multimedia en red
Las aplicaciones multimedia en red tienen unos requerimientos muy diferentes a los de las aplicaciones tradicionales en la red Internet (correo 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
Direcciones web
recomendadas
Aplicaciones de audio y vdeo interactivo:
Windows Messenger: http:/
/ www.microsoft.com/windows/messenger/features.asp
(haciendo un pequeo pago), como es el caso de Skype.
Google Talk: http://

www.google.com/talk/ intl/
se/
El retraso permitido en estas aplicaciones no debe ser mayor que unos cente-
Skype: http://
www.skype.com/intl/es/
nares de milisegundos. As pues, retrasos de 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
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.
Eliminacindeljitter: 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
(24)
El RFC que define el RTSP es el

2.326.
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.
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.
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.
Ved tambin
Los valores de las rdenes
RTSP, as como el formato de
la versin RTSP, estn explicados con detalle en el anexo 1.
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).
El cuerpo del mensaje lleva la informacin, si la hay, asociada a la peticin.
Ved tambin
Los valores que pueden tomar
las cabeceras de entidad estn
explicados con detalle en el
anexo 1.
10.2.7. El mensaje de respuesta RTSP

La figura siguiente muestra el formato del mensaje de respuesta. Este mensaje
consta de tres partes bien diferenciadas: la 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
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).
Ved tambin
estas tres cabeceras estn explicados con detalle en el anexo 1.
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:
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).
DESCRIBE rtsp://servidor.multimedia.com:554/videos/
video.html RTSP/1.0
Cseq: 2
SDP y MHEG
El Session Description Protocol
(SDP) est definido en el RFC
4.566.
Multimedia and Hypermedia Experts Group (MHEG): http://
www.mheg.org.
FUOC PID_00147724
84
SETUP rtsp:// servidor.multimedia.com:554/videos/

video.html RTSP/1.0
Cseq: 3
Transport: rtp/udp;unicast;client_port=5067-5068

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.
PLAY rtsp:// servidor.multimedia.com:554/videos/

video.mpg RTSP/1.0
Cseq: 4
Session: 12345678
FUOC PID_00147724
85
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.
(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.
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.
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:
INVITE sip:cris@vic.cat SIP/2.0
(27)
El RFC del TLS es el 4.346.
FUOC PID_00147724
94
Via: SIP/2.0/UDP pc01.bcn.cat;branch=z9hG4bK776asdhds

Max-Forwards: 70
To: Cristina <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:
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.
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.
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
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:

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
Ved tambin
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
puesto por claridad.
Ved tambin
Los valores de los cdigos y
descripciones de estado estn
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:

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
Ved tambin
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.
103
FUOC PID_00147724
12. Anexos
12.1. Anexo 1. El protocolo RTSP
12.1.1. rdenes
La tabla siguiente describe las rdenes RTSP:
Orden
Descripcin
OPTIONS
Permite al cliente pedir informacin sobre las opciones de comunicacin con el servidor.
DESCRIBE
Recupera la informacin del contenido multimedia identificado por el URL que se enva con la orden.
ANNOUNCE
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.
SETUP
Especifica los parmetros del mecanismo de transporte. Se puede enviar a media sesin, para cambiar estos parmetros.
PLAY
Se indica al servidor que se debe iniciar el envo de datos.
PAUSE
TEARDOWN
Se indica al servidor que se quiere parar temporalmente la recepcin de datos de la sesin.

Se cierra la recepcin de datos.
GET_PARAMETER
Pide el valor de un parmetro de la descripcin de la sesin.
SET_PARAMETER
Enva el valor de un parmetro de la descripcin de la sesin.
REDIRECT
Se indica al cliente que se tiene que conectar a otro servidor.
RECORD
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
Valor
Descripcin
Informativo
100
El cliente puede continuar con la peticin.
xito
250
Poco espacio de almacenamiento. Puede suceder con la orden RECORD.
104
FUOC PID_00147724
Tipo de cdigo
Valor
Descripcin
Redireccin
3XX
Los mismos que HTTP.
Errorpartecliente
405
El recurso no puede ejecutar el mtodo pedido.
Errorpartecliente
451
El servidor no soporta alguno de los parmetros indicados en la peticin.
Errorpartecliente
452
La conferencia no se ha encontrado.
Errorpartecliente
453
No hay suficiente ancho de banda para recibir el contenido.
Errorpartecliente
454
La sesin no se ha encontrado.
Errorpartecliente
455
El mtodo no es vlido en el estado actual del protocolo.
Errorpartecliente
456
Un parmetro indicado en la cabecera no se puede procesar.
Errorpartecliente
457
El rango pedido est fuera de los lmites.
Errorpartecliente
458
Un parmetro que se quera modificar con SET_PARAMETER es slo de lectura.
Errorpartecliente
459
El parmetro no se puede aplicar al recurso. Slo se puede aplicar a un stream
Errorpartecliente
460
El parmetro no se puede aplicar al recurso. Slo se puede aplicar a una presentacin.
Errorpartecliente
461
El tipo de transporte no est soportado.
Errorpartecliente
462
El cliente no es accesible.
Errorparteservidor
551
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
Descripcin
Accept
Tipos de contenidos aceptados en la presentacin.
Allow
Mtodos RTSP soportados por el servidor.
Bandwidth
Blocksize
Cache-Control
Conference
Content-Length
CSeq
Expires
If-Modified-Since
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.
105
FUOC PID_00147724
Cabecera
Descripcin
Last-Modified
ltima vez en la que se modific la descripcin del recurso.
Proxy-Require
Parmetros que debe soportar un proxy.
Require
Sirve para preguntar al servidor qu opciones soporta.
RTP-Info
Indica parmetros especficos de RTP en una orden PLAY.
Scale
Permite indicar si el contenido se quiere ver a velocidad normal, ms rpida o ms lenta.
Session
Identificador de la sesin.
Speed
Pide que la transferencia de datos se haga a una determinada velocidad.
Transporte
Unsupported
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.
Nmero de fuentes emisoras (SC): 5 bits. El nmero de porciones SSRC/

CRSC por las cuales son contenidas en un paquete SDES.
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:
Subtipo: 5 bits. Puede utilizarse para definir un subtipo de aplicaciones.
110
FUOC PID_00147724
Nombre: 8 octetos. Nombre escogido por la persona que ha definido los

paquetes de tipo APP, para diferenciarlos de otros paquetes de tipo APP.
Datos dependientes de la 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
Valor
Descripcin
Respuestasprovisionales
100
Indica que el siguiente host (salto, hop, en ingls) ha recibido la peticin.
180
Indica que la peticin INVITE se ha recibido en el otro lado y se avisa al usuario.
181
La llamada se est redirigiendo.
182
La llamada se ha puesto en la cola, porque el receptor de la llamada no est disponible.
183
Informacin sobre el progreso de la llamada.
xito
200
La peticin ha ido bien.
Redireccin
300
Indica que hay mltiples opciones en la localizacin de la direccin del usuario al

que se llama.
Redireccin
301
El usuario ha cambiado de direccin y se le tiene que llamar a la nueva direccin

indicada en la cabecera Contact.
Redireccin
302
El usuario ha cambiado de direccin y se le tiene que llamar a la nueva direccin

indicada en la cabecera Contact.
Redireccin
305
Se tiene que utilizar un proxy.
Redireccin
380
La llamada no ha sido posible, pero hay servicios alternativos disponibles.
Redireccin
400
Formato de peticin errneo.
Redireccin
401
El usuario necesita autenticarse.
111
FUOC PID_00147724
Tipo de cdigo
Valor
Descripcin
Redireccin
402
Reservado para uso futuro.
Errorpartecliente
403
El servidor no quiere servir la peticin del cliente, aunque tena un formato correcto.
Errorpartecliente
404
El usuario a quien se ha llamado no se encuentra en el servidor.
Errorpartecliente
405
El mtodo pedido no se puede ejecutar para la direccin indicada.
Errorpartecliente
406
El recurso no es aceptable segn los valores enviados en la cabecera Accept.
Errorpartecliente
407
El cliente se tiene que autorizar delante de un proxy.
Errorpartecliente
408
El servidor no ha podido producir una respuesta a tiempo.
Errorpartecliente
410
El recurso ya no est disponible en el servidor.
Errorpartecliente
413
El tamao de la entidad enviada por el cliente es demasiado grande para que el

servidor la pueda tratar.
Errorpartecliente
414
El tamao del URI es demasiado grande para que el servidor lo pueda tratar.
Errorpartecliente
415
El tipo de datos del contenido no est soportado por el servidor.
Errorpartecliente
416
La peticin no se puede servir, porque el esquema indicado en el URI del recurso

no se reconoce.
Errorpartecliente
420
El servidor no reconoce las extensiones indicadas en la cabecera.

Proxy-Require
Errorpartecliente
421
Los programas necesitan una extensin especfica para poder servir la peticin.
Errorpartecliente
423
El servidor rechaza la peticin, porque expira demasiado pronto.
Errorpartecliente
480
Se ha podido llegar hasta el servidor, pero el usuario al que se ha llamado no est

disponible temporalmente.
Errorpartecliente
481
La transaccin no existe.
Errorpartecliente
482
Se ha detectado un bucle en la llamada.
Errorpartecliente
483
Se ha pasado el mximo de hosts indicados en la cabecera MaxHops.
Errorpartecliente
484
La direccin del usuario al que se ha llamado es incompleta.
Errorpartecliente
485
La direccin es ambigua.
Errorpartecliente
486
El usuario no acepta la llamada.
Errorpartecliente
487
La peticin se ha acabado con un CANCEL o un BYE.
Errorpartecliente
488
La peticin no es aceptable, por algn parmetro indicado.

a la sesin
Errorpartecliente
491
Hay otra peticin pendiente.
Errorpartecliente
493
El cuerpo del mensaje lleva un tipo MIME que el servidor no puede tratar.
Errorparteservidor
500
Error interno del servidor, que hace que no pueda servir la peticin.
Errorparteservidor
501
El servidor no tiene implementada la funcionalidad necesaria para servir la peticin.
112
FUOC PID_00147724
Tipo de cdigo
Valor
Descripcin
Errorparteservidor
502
El servidor recibe un error cuando hace de proxy o gateway.
Errorparteservidor
503
El servicio est temporalmente no disponible.
Errorparteservidor
504
El servidor no recibe una respuesta de un servidor externo a tiempo.
Errorparteservidor
505
El servidor no soporta la versin del protocolo indicada por el cliente.
Errorparteservidor
513
El mensaje es demasiado largo para que el servidor lo pueda procesar.
Errorgeneral
600
El usuario llamado no est disponible.
Errorgeneral
603
El usuario llamado no quiere aceptar la llamada.
Errorgeneral
604
El usuario llamado no existe.
Errorgeneral
606
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
Descripcin
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.
Call-Info
Informacin adicional sobre los participantes en la llamada.
Contact
Contiene una URI que puede tener diferentes significados segn el contexto.
Content-Disposition
Content-Encoding
Content-Length
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.
Cseq
Nmero de secuencia asociado a una peticin.
Date
Fecha y hora en los que se cre el mensaje.
Error-Info
Expires
From
In-Reply-To
Max-Forwards
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.
113
FUOC PID_00147724
Cabecera
Min-Expires
Organization
Priority
Proxy-Authorization
Descripcin
Intervalo de refresco mnimo.
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.
Proxy-Require
Requerimientos que debe tener el proxy.
Record-Route
El proxy llena esta cabecera para indicar que las futuras peticiones tienen que pasar por el mismo.
Reply-To
URI de retorno que no debe ser en absoluto el mismo que el de la cabecera From.
Require
Caractersticas esperadas del programa de usuario.
Retry-After
Indicacin de cundo el servicio volver a estar disponible.
Route
Descripcin de los proxies por los cuales tendra que pasar la peticin.
Server
Descripcin del software que utiliza el servidor.
Subject
Tema de la llamada.
Supported
Extensiones soportadas por el programa de usuario.
Timestamp
Indicacin de cundo el programa cliente efectu la llamada.
To
Unsupported
Via
WWW-Authenticate
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.
GSM (global system for mobile communication) ............................
10
1.2.
GPRS ............................................................................................
16
1.3.
EDGE ...........................................................................................
19
1.4.
UMTS ...........................................................................................
19
1.4.1.
Equipos mviles .............................................................
28
Redes inalmbricas............................................................................
29
2.1.
Infrarrojos ....................................................................................
30
2.2.
Bluetooth .....................................................................................
33
2.3.
ZigBee ..........................................................................................
40
2.4.
WiFi .............................................................................................
43
2.5.
WiMax .........................................................................................
47
Resumen.......................................................................................................
54
Bibliografa.................................................................................................
55
2.
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.
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
(1)
En castellano, sistema global de

comunicacin mvil.
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).
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.
Direccin web
recomendada
Podis acceder al foro UMTS
a travs de la pgina web
http://www.umts-forum.org.
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
25
FUOC PID_00147722
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
RDSI
GSM
GRPS
UMTS
E-mail(10Kbytes)
1s
8s
0,7 s
0,04 s
Pginaweb(20Kbytes)
2s
20 s
1,6 s
0,1 s
FicheroPowerPoint(2Mbytes)
4 min
28 min
2 min
7s
Videoclip(4Mbytes)
8 min
48 min
4 min
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
Tasa de datos (kbit/s)
Error de bit
Telefona
Voz
Teleconferencia
2 min.
1h
8-32
32-128
10
-4
10
Videotelefona
2 min.
64-348
10
1h
348-768
10
Sin conexin
2 min.
Sin definir
Sin conexin
1,2-9,6
8-32
64
1,2-64
10
-4
10
-7
10
-6
10
Basesdedatos
Sin definir
2,4-768
10
Telecompra
Sin definir
2,4-768
10
Teleaccin/control
Sin definir
1,2-64
10
Videoconferencia
Mensajera
SMS
Buzn de voz
Videomensaje
Correo electrnico
Serviciossuplementarios: servicios que modifican o complementan un

servicio bsico de telecomunicacin, como, por ejemplo, la identificacin
Retardo (ms)
-4
40
40
-7
40-90
-7
90
-6
100
90
100
100
-6
200+
-6
90
-6
100-200
FUOC PID_00147722
26
del 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.
27
FUOC PID_00147722
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
Interactivo
Trasfondo
<=16.000
<=16.000
<= 16.000 tiempo de sistema
<= 16.000 tiempo de sistema
S/no
S/no
S/no
S/no
<= 1.500 o 1.502
<=1.500
o 1.502
<= 1.500 o 1.502
<= 1.500 o 1.502
S/no/
S/no/
S/no/
S/no/
BER (probabilidad de error de bit) residual
Porcentaje de errores de SDU
Retraso de transferencia (ms)
100 valor mnimo
300 valor
mnimo
Tasa de bits garantizada (kbps)
<=16.000
<=16.000
Prioridad de gestin del trfico
1, 2, 3
Prioridad de asignacin/retencin
1, 2, 3
1, 2, 3
1, 2, 3
1, 2, 3
Habla/desconocida
Habla/desconocida
S/no
Tasa de bits mxima (kbps)
Orden de entrega
Medida mxima de SDU (unidad de datos de servicio) (octetos)
Informacin en formato SDU
Entrega de SDU errneas
Descriptor estadstico de origen
Indicacin sealizadora
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.
28
FUOC PID_00147722
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.
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
Ejemplo de un puerto IrDA de la placa madre

de un ordenador
FUOC PID_00147722
32
el que pasan los datos de un elemento a otro. Este tipo de 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 proto3
colo 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).
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.
(3)
High-Level Data Link Control es

un protocolo de comunicaciones
de propsito general punto a punto.
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
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.
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.
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
35
FUOC PID_00147722
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
Potencia
En espera
Menos de 0,3 mA
Voz
8 a 30 mA
Datos
5 mA (media)
mA = miliamperio
Bluetooth emite a la frecuencia de 2,4 GHz, que es una banda base, es decir,
que no interfiere las frecuencias utilizadas para la industria, la ciencia y la
medicina. Como se ver posteriormente, en este aspecto es bastante parecido
a un sistema WiFi.
El sistema tiene un transmisor de saltos de frecuencia, que consiste en una
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
Una red Piconet Bluetooth
37
FUOC PID_00147722
38
Una red scatternet Bluetooth
Dentro de una piconet, cada dispositivo esclavo se conecta al dispositivo master por un canal 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
Coordinador ZigBee
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.
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.
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.
Dispositivo final
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.
Nombre "Wifi"
El nombre Wifi corresponde a
las siglas de Wireless Fidelity, y
se refiere a los procedimientos
utilizados para las comunicaciones de redes locales (distancias cortas) sin hilos (wireless
local area network o WLAN).
En Wi-Fi se utilizan las ondas portadoras de radio para transmitir la 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.
Un access point (AP) es el dispositivo que hace de puente entre una red
cableada y una red inalmbrica. Podemos pensar que, de alguna mane-
Logotipo de Wifi
ra, es la antena a la que nos conectamos.
Si las ondas se transmiten a diversas frecuencias, puede haber varias ondas

portadoras de radio al mismo tiempo, sin que se interfieren unas con otras.
Los puntos de acceso (access point) reciben la 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.
47
FUOC PID_00147722
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
Consumo de potencia
Ventajas
Aplicaciones
Wi-Fi
Hasta 54
Mbps
400 mA transmitiendo
Gran ancho de banda
Navegar por Internet, red de ordenadores,

transferencia de ficheros
Bluetooth
1 Mbps
40 mA transmitiendo
Interoperatividad, sustituto del USB sin hilos, mviles, informtica casera

cable
ZigBee
250 kbps
30 mA transmitiendo, 3 mA
en reposo
Batera de larga duracin, bajo

coste
Control remoto, productos dependientes

de la batera, sensores, juegos
-3
1mA = 10 amperios
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.
49
FUOC PID_00147722
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.
802.16
802.16a
802.16e
Espectro
10-66 GHz
< 11 GHz
< 6 GHz
Funcionamiento
Slo con visin directa
Sin visin directa (NLOS)
Sin visin directa (NLOS)
Ancho
debanda
32-134 Mbps
Hasta 75 Mbps con

canales de 20 MHz
Hasta 15 Mbps con canales de 5 MHz
Modulacin
QPSK, 16QAM
y 64 QAM
OFDM con 256

subportadoras
Mismo que 802.16a
Movilidad
Sistema fijo
Sistema fijo
Movilidad pedestre
Anchodel
espectro
20, 25 y
28 MHz
Seleccin entre
1,25 y 20 MHz
El mismo que 802.16a con los canales de subida para ahorrar potencia
Distancia
2-5 km aprox.
5-50 km aprox.
2-5 km aprox.
Hay que mencionar la 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.
50
FUOC PID_00147722
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
Velocidad mxima aire
Velocidad mxima real
pre-WiMAX
54 Mbps
~30 Mbps
WiMAX
70 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.
53
FUOC PID_00147722
Comparativa de WiMAX con otras tecnologas
WiMAX 802.16
WiFi 802.11
MBWA 802.20
UMTS y CDMA2000
Velocidad
124 Mbit/s
11-54 Mbit/s
16 Mbit/s
2 Mbit/s
Cobertura
40-70 km
300 m
20 km
10 km
Licencia
S/No
No
Ventajas
Velocidad y extensin geogrfica
Velocidad
y precio
Velocidad y
movilidad
Rango y
movilidad
Inconvenientes
Interferencias
Baja cobertura
Precio alto
Lento y caro
FUOC PID_00147722
54
Resumen
En este 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.]

Redes Multimedia

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

Redes Multimedia

Cargado por

Copyright:

Formatos disponibles

Redes multimedia

Xavier Vilajosana Guilln (coordinador)

Xavier Vilajosana Guilln

Miquel Font Rossell

Silvia Llorente Viejo

Joan Manuel Marqus Puig

Primera edicin: septiembre 2010

La asignatura Redes multimedia pretende dar una visin global e introductoria

El estudio de los materiales didcticos de esta asignatura os ha de permitir

1. Conocer la arquitectura de una red. Saber diferenciar los niveles y conocer

Conceptos de redes y comunicaciones en Internet

Jerarqua de protocolos y cabecera

Breve historia de las comunicaciones

El enlace de datos y el control de acceso al medio

Redes privadas virtuales

Arquitecturas de aplicaciones distribuidas

DNS: Servicio de nombres en Internet

Correo electrnico en Internet

Aplicaciones de igual a igual para la comparticin de ficheros

Telnet y Secure Shell: acceso a ordenadores remotos

Aplicaciones multimedia en red

10. Streaming de audio y vdeo almacenados

11. Protocolos para aplicaciones interactivas en tiempo real

Sistemas de comunicacin de la telefona mvil

Conceptos de redes de computadores

Conceptos de redes de computadores

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

Topologas de red ........................................................................

Tipo de conmutacin ..................................................................

Conmutacin de circuitos .............................................

Conmutacin de paquetes .............................................

Conmutacin de paquetes con circuito virtual .............

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

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

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

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

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

Tecnologas de red sin hilos ..........................................

Arquitectura de la red: diseo por capas ....................................

Consideraciones de diseo .........................................................

Jerarqua de protocolos y cabecera...............................................

Tipo de conexin de servicios ....................................................

Necesidad de estandarizacin .....................................................

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

Proceso de encapsulacin y desencapsulacin ..............

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

Encapsulacin de la informacin en el modelo

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

Conceptos de redes de computadores

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

Conceptos de redes de computadores

1. Conocer el concepto de red de computadores, servicio y protocolo e Internet.

Conceptos de redes de computadores

1. Conceptos de redes y comunicaciones en Internet

Durante las dos primeras dcadas de existencia de los computadores, stos

Conceptos de redes de computadores

Conceptos de redes de computadores

La idea de Internet apareci a mediados de los aos sesenta cuando la Agencia

Para hacer posible toda la complejidad de Internet y permitir que la

Una topologa de red es la manera como estn distribuidos los nodos

Bus. Todos los equipos estn conectados a un nico medio de transmisin

Conceptos de redes de computadores

intermedios se conectan entre s y, a su vez, tienen conectados equipos

Ejemplos tpicos de topologas de red