Redes Multimedia PDF

Redes multimedia
Xavier Vilajosana Guillén (coordinador)

Miquel Font Rosselló
Silvia Llorente Viejo
Joan Manuel Marqués Puig
PID_00147720
© FUOC • PID_00147720 Redes multimedia
Xavier Vilajosana Guillén Miquel Font Rosselló Silvia Llorente Viejo
Ingeniero en Informática por la Uni- Ingeniero y doctorando en Informá- Ingeniera en Informática, diploma
versidad Politécnica de Cataluña tica, y consultor de los Estudios de de estudios avanzados por la UPC y
(UPC) y doctor en Sociedad de la In- Informática, Multimedia y Teleco- doctora por la Universidad Pompeu
formación por la Universitat Oberta municación de la UOC. Fabra (UPF). Actualmente, es con-
de Catalunya (UOC). Actualmente, sultora de los Estudios de Informáti-
es profesor de los Estudios de Infor- ca, Multimedia y Telecomunicación
mática, Multimedia y Telecomunica- en la UOC.
ción de la UOC.
Doctor en Informática, especializa-

do en sistemas distribuidos descen-
tralizados. Profesor de los Estudios
de Informática, Multimedia y Tele-
comunicación de la UOC.
Primera edición: septiembre 2010

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

de las redes de computadores. Se toma una aproximación de arriba abajo en-
fatizando los aspectos más relacionados con la titulación y dejando de lado
aquellos relacionados con la comunicación en el ámbito físico en la teoría de
la señal. Esta asignatura presenta las bases de las redes de comunicaciones, có-
mo se estructuran, qué dispositivos las integran, cuáles son las normas y pro-
tocolos que rigen la comunicación, cuáles sus aplicaciones y servicios, y todo
tomando como ejemplo la red de Internet.
El módulo "Conceptos de redes de computadores" introduce los principales

conceptos que nos permiten entender qué es una red de computadores y cómo
se estructura. También sirve de breve revisión de la historia de las redes, lo cual
nos permite contextualizar y entender Internet en la actualidad. El módulo
"Las capas de la red de computadores" describe los protocolos y servicios bási-
cos que ofrece cada una de las capas de una red de computadores. El módulo
empieza por los niveles más altos y deja de lado el nivel de aplicación que se
ve en el módulo "El nivel de aplicación".
El enfoque es, pues, de arriba abajo; se crea así un esbozo de los conceptos más
próximos al hardware y se pone el énfasis en los niveles de transporte y de red
primordiales para el funcionamiento de Internet.
El módulo "Seguridad en la Red" complementa al resto y presenta los conceptos

principales de la seguridad de las redes de computadores. El módulo "El nivel
de aplicación" profundiza en el nivel de aplicación; muestra protocolos tan
importantes como HTTP o SMTP que rigen el funcionamiento del mundo hoy
en día. Se destacan los protocolos orientados a la transmisión del contenido
multimedia, y se presentan las arquitecturas más comunes hoy en día en la
Red.
Por último, el módulo "Comunicaciones sin hilos" concluye el curso explican-

do los conceptos capitales de una tecnología que permite superar las barreras
impuestas por la necesidad de conectar físicamente las redes.
Cabe señalar que este curso pretende introducir el concepto de red y dar una
visión general del funcionamiento de ésta. Por lo tanto, quedan fuera muchos
conceptos que son primordiales también para entender el funcionamiento real
de una red y que no han podido ser incluidos por limitaciones de espacio.
De esta manera, se anima a los lectores más interesados en ampliar su conoci-
miento de las redes que consulten la bibliografía recomendada.
Objetivos
El estudio de los materiales didácticos de esta asignatura os ha de permitir

alcanzar los objetivos siguientes:
1. Conocer la arquitectura de una red. Saber diferenciar los niveles y conocer

las principales funciones y servicios de cada uno de ellos.
2. Conocer los principales protocolos de nivel aplicación, entender su fun-

cionamiento y saber relacionarlo con el funcionamiento actual de Inter-
net.
3. Tener una visión general de los conceptos de seguridad en la Red que per-
miten asegurar las comunicaciones, así como evitar un uso indebido de
la información.
4. Tener conocimiento de los conceptos principales que rigen la comunica-

ción sin hilos. Conocer las tecnologías de comunicación sin hilos que exis-
ten hoy en día y rigen la mayoría de las comunicaciones actuales.
Contenidos
Módulo didáctico 1
Conceptos de redes de computadores
Xavier Vilajosana Guillén
1. Conceptos de redes y comunicaciones en Internet
2. Qué es Internet y qué es un protocolo
3. Hardware de red
4. Dispositivos de red
5. Software de red
6. Jerarquía de protocolos y cabecera
7. Interfaces y servicios
8. Modelos de referencia
9. Breve historia de las comunicaciones
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 físico
Seguridad en la red
1. Cortafuegos
2. Redes privadas virtuales
3. Introducción a la criptografía
4. Certificados digitales
5. Seguridad en la red
El nivel de aplicación
Joan Manuel Marqués Puig y Silvia Llorente Viejo
1. Arquitecturas de aplicaciones distribuidas
2. DNS: Servicio de nombres en Internet
3. La web y el HTTP
4. Transferencia de ficheros
5. Correo electrónico en Internet
6. Aplicaciones de igual a igual para la compartición de ficheros
7. Mensajería instantánea
8. Telnet y Secure Shell: acceso a ordenadores remotos
9. Aplicaciones multimedia en red
10. Streaming de audio y vídeo almacenados
11. Protocolos para aplicaciones interactivas en tiempo real

12. Anexos
Comunicaciones inalámbricas
1. Sistemas de comunicación de la telefonía móvil
2. Redes inalámbricas
Conceptos
de redes de
computadores
PID_00147725
© FUOC • PID_00147725 Conceptos de redes de computadores
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. Conceptos de redes y comunicaciones en Internet.................... 7
2. Qué es Internet y qué es un protocolo......................................... 8
3. Hardware de red................................................................................ 9
3.1. Topologías de red ........................................................................ 9
3.2. Tipo de conmutación .................................................................. 10
3.2.1. Conmutación de circuitos ............................................. 10
3.2.2. Conmutación de paquetes ............................................. 11
3.2.3. Conmutación de paquetes con circuito virtual ............. 14
3.3. Alcance de las redes .................................................................... 15
3.3.1. Redes de gran alcance ................................................... 16
3.3.2. Redes de área local ........................................................ 16
3.4. Tecnologías de red ...................................................................... 16
3.4.1. Tecnologías de red cableada .......................................... 17
3.4.2. Tecnologías de red sin hilos .......................................... 17
4. Dispositivos de red............................................................................ 19
5. Software de red.................................................................................. 21
5.1. Arquitectura de la red: diseño por capas .................................... 22
5.2. Consideraciones de diseño ......................................................... 25
6. Jerarquía de protocolos y cabecera............................................... 27
7. Interfaces y servicios......................................................................... 29
7.1. Tipo de conexión de servicios .................................................... 33
8. Modelos de referencia....................................................................... 35
8.1. Necesidad de estandarización ..................................................... 35
8.2. El modelo de referencia OSI ....................................................... 36
8.2.1. Proceso de encapsulación y desencapsulación .............. 38
8.3. Modelo TCP/IP ............................................................................ 39
8.3.1. Encapsulación de la información en el modelo
TCP/IP ............................................................................ 41
8.4. Modelo OSI comparado con modelo TCP/IP .............................. 42
9. Breve historia de las comunicaciones.......................................... 44
Resumen....................................................................................................... 56
Bibliografía................................................................................................. 59
© FUOC • PID_00147725 5 Conceptos de redes de computadores
Introducción
Las redes de ordenadores actuales son una composición de dispositivos, téc-

nicas y sistemas de comunicación que han ido apareciendo desde el final del
siglo XIX con la invención del teléfono. Éste se desarrolló exclusivamente para
transmitir voz, aunque todavía hoy se utiliza, en muchos casos, para conectar
ordenadores entre sí. Desde entonces han aparecido las redes locales, las co-
nexiones de datos a larga distancia con enlaces transoceánicos o por satélite,
Internet, la telefonía móvil, etc.
Dedicaremos este módulo a introducir las ideas y los conceptos básicos de

las redes de ordenadores que trataremos en profundidad a partir de ahora.
En primer lugar, abordaremos los conceptos fundamentales de una red. Las
topologías de red y los conceptos de conmutación, el hardware y el software.
Es importante tener una visión general de la tipología de red, normalmente
clasificada por su alcance. Seguidamente, el módulo introduce las diferentes
tecnologías de red más relevantes en la actualidad, Ethernet u 802.3 es la más
usada en redes de área local cableadas. Las tecnologías de redes sin hilos se han
estandarizado en la última década y tienen su mayor exponente en el 802.11
o WiFi, que también es usado por la mayoría de dispositivos de usuario en red.
El módulo profundiza en la definición de una red de computadores y nos pre-

senta el modelo de referencia de una red, constituida por diferentes niveles
que permiten abstraer las complejidades derivadas de la transmisión de la in-
formación. Como veremos, cada nivel de la red ofrece servicios a su nivel pre-
decesor mientras que usa los servicios de su nivel antecesor. Cuando se quiere
transmitir una información, ésta se transmite entre los diferentes niveles de
la red a la vez que se encapsula la información de los niveles precedentes y se
añade nueva información que le permite al receptor recuperar la información
original.
Veremos que en un principio se definió una jerarquía llamada Open Systems

Interconnection (OSI) con siete niveles y que ésta evolucionó hacia el modelo
de red actual, el modelo TCP/IP que rige hoy en día el funcionamiento de
Internet. Finalmente, el módulo hace un breve repaso de la historia de las
comunicaciones. Conocer la historia nos permite tener una buena perspectiva
de estas tecnologías y entender por qué se han creado, cómo han evolucionado
y por qué tenemos el modelo de comunicación actual.
Objetivos
Al finalizar el estudio de este módulo, tendréis que haber alcanzado los obje-
tivos siguientes:
1. Conocer el concepto de red de computadores, servicio y protocolo e In-

ternet.
2. Conocer los componentes de una red de computadores, tanto los de hard-

ware como los de software.
3. Conocer la arquitectura de una red de computadores, la separación por

capas o niveles y los modelos de referencia fundamentales.
4. Saber diferenciar las redes por su alcance.
5. Tener una visión general de la evolución de las redes de computadores

desde sus inicios.
1. Conceptos de redes y comunicaciones en Internet
Durante las dos primeras décadas de existencia de los computadores, éstos

eran sistemas hardware fuertemente centralizados, normalmente ubicados en
un único espacio físico. Las empresas y centros que poseían un computador
hacían que éste cubriera todas las necesidades computacionales de la institu-
ción. A medida que las capacidades de los computadores crecieron, la centrali-
zación se convirtió en un problema tanto de gestión como de recursos. De esta
manera, se fue sustituyendo el modelo centralizado por un modelo en el que
múltiples computadores con menos capacidad pero interconectados entre sí
eran capaces de realizar las tareas de un computador centralizado. A esta nueva
organización se la denominó red�de�computadores. El diseño y arquitectura
de la red son los aspectos que trataremos durante este curso.
La evolución de las tecnologías ha llevado a un crecimiento progresivo del uso

de los sistemas en red hasta llegar al modelo de hoy en día, en el que no se
puede concebir un sistema informático sin la presencia de los elementos de
comunicación. Internet ha sido la materialización de la red de computadores
y se ha convertido en el eje principal de las tecnologías de la información. Las
comunicación en Internet no deja de ser una jerarquización de la comunica-
ción en red. Internet es una gran red constituida por una infinidad de peque-
ñas redes interconectadas entre sí.
2. Qué es Internet y qué es un protocolo
La idea de Internet apareció a mediados de los años sesenta cuando la Agencia

de Proyectos de Investigación Avanzada (ARPA, por sus siglas en inglés), en
el seno del Departamento de Defensa de Estados Unidos financió un proyec-
to denominado ARPANET que pretendía interconectar diferentes ordenadores
distribuidos en sus sedes.
Desde entonces, Internet ha evolucionado hasta el sistema de hoy en día, en

el que millones de máquinas están interconectadas y acceden a contenidos
distribuidos por todas partes. La estructura de la red es compleja y no podemos
pensar en una conexión de todos con todos, pues ello haría que el sistema
fuera completamente inoperante e inviable tecnológicamente. Internet sigue
una estructura jerárquica en la que unos pocos nodos están conectados con
muchos otros, mientras que la mayoría mantiene una conexión con su pro-
veedor de servicio.
Para hacer posible toda la complejidad de Internet y permitir que la

infinidad de aplicaciones de hoy en día se puedan comunicar mediante
la red hace falta un conjunto de reglas que rijan las comunicaciones
y regulen cómo y cuándo los nodos de la red se pueden comunicar.
Las reglas y convenciones que permiten que eso sea posible se llaman
protocolos.
Conectividad en Internet
3. Hardware de red
Las redes de computadores se pueden clasificar de diferentes formas. Gene-

ralmente, estas clasificaciones se hacen basándose en la topología, el tipo de
conmutación, el alcance y la tecnología de la red, entre otros. Este apartado
detalla estas diferentes clasificaciones que proporcionan la base necesaria pa-
ra poder entender posteriormente el diseño de los protocolos existentes en la
actualidad.
3.1. Topologías de red
Una topología de red es la manera como están distribuidos los nodos

que la forman.
Las redes actuales están formadas por tres tipos de entidades: los equipos fi-
nales (hosts), los equipos intermedios (conmutadores o routers) y los enlaces
(links) que unen los equipos finales y los routers entre sí.
Las topologías más conocidas son las de:
• Bus. Todos los equipos están conectados a un único medio de transmisión

compartido por todas las estaciones de la red, por lo que resulta necesario
establecer un sistema de acceso al medio con el fin de evitar que haya
más de una estación transmitiendo en el mismo instante de tiempo y se
produzcan colisiones. Un ejemplo de una topología en bus se puede ver
en la figura siguiente.
• Anillo. Como muestra la figura, una topología en anillo está formada por
un enlace que forma un bucle, de manera que cada estación está conectada
al anillo a través de dos enlaces, el de entrada y el de salida. Generalmente,
cuando la estación emisora recibe su propio paquete lo elimina de la red.
• Estrella. Esta topología está formada por un nodo central, que actúa como
nodo intermedio de la red (conmutador o router) y es el que gestiona el
envío y la recepción de los datos; el resto de las estaciones se conectan a
este nodo principal.
• Árbol. La topología en árbol se considera una topología mixta de las topo-

logías en bus y en estrella, y a veces también se la conoce como topología
jerárquica. Un ejemplo se puede ver en la figura, donde diversos nodos
intermedios se conectan entre sí y, a su vez, tienen conectados equipos

finales. Esta topología es la más utilizada actualmente.
• En�malla. La topología en malla es aquella en la que todos los equipos es-

tán conectados contra todo el resto. Hay casos de redes en malla no totales,
en las que las estaciones no forman una malla completa. Generalmente,
esta topología es la utilizada en el núcleo de las grandes redes como Inter-
net, donde sólo se conectan equipos intermedios, y no equipos finales.
Ejemplos típicos de topologías de red
3.2. Tipo de conmutación
En el entorno de las redes, la conmutación hace referencia al establecimiento

de un circuito (real o lógico) entre dos puntos de la red que permite la interco-
nexión y, por lo tanto, el traspaso de información entre los puntos. Esencial-
mente, esta conmutación se puede dividir en dos clases diferentes: la conmu-
tación de circuitos y la conmutación de paquetes.
3.2.1. Conmutación de circuitos
La conmutación de circuitos se basa en establecer un circuito físico entre los

dos interlocutores de la red. Dicho circuito físico se establece antes de que se
pueda transmitir ningún tipo de información y está conformado por diferentes
enlaces entre los nodos. En conmutación de circuitos se distinguen tres fases
para el envío de información:
1)� Establecimiento� del� circuito. Esta fase se encarga de buscar un camino

entre los nodos intermedios que lleven hacia el destino; así la estación origen
solicita la creación del circuito al nodo al que está conectada, el cual envía la
petición al nodo siguiente. Este otro nodo hará lo mismo hacia el siguiente, y
así hasta llegar al destino final. A medida que se va formando el circuito, cada
nodo intermedio verifica que haya bastantes recursos para establecerlo, y, en
el caso de que no sea así, se aborta la petición de circuito. Por el contrario, en el
caso de que el establecimiento sea viable, una vez llegado al destino, éste en-
viará una señal al origen para hacerle saber que ya puede enviar información.
2)�Transferencia�de�datos. Ahora, las estaciones ya pueden intercambiar la

información deseada.
3)�Desconexión. Una vez se ha acabado la comunicación es obligatorio liberar

recursos, a fin de que estén disponibles más adelante para otras conexiones.
Ejemplo de creación de circuitos
Un ejemplo de creación de circuitos es el que se muestra en el diagrama de tiempo de la

figura siguiente. Ésta muestra las tres fases en el caso de que haya dos nodos intermedios.
El diagrama de tiempo se tiene que interpretar de izquierda a derecha con la evolución
temporal, donde cada bloque representa el envío de información hacia el siguiente nodo.
Diagrama de tiempo del establecimiento de un circuito
Como se puede ver en la figura, las líneas tienen una cierta inclinación, lo que indica
el tiempo de propagación de la señal, mientras que el grueso de cada bloque indica el
tiempo de transmisión necesario para enviarla. Inicialmente, en el establecimiento del
circuito cada equipo intermedio tiene que procesar la señal y enviarla al siguiente nodo;
por eso, antes de enviarla se tiene que esperar a tener toda la información del circuito.
Que una vez establecida, ya puede funcionar de extremo a extremo de forma transparente
y sin más retardos adicionales de los nodos intermedios.
Red telefónica básica
El ejemplo más clásico de la conmutación de circuitos es la antigua red telefónica básica

(XTB), en la que, por medio de las centralitas situadas de forma jerárquica por medio de
toda la red, se iban multiplexando los circuitos de voz y dirigiéndolos hacia su destina-
tario. Hoy día, con la era digital, este establecimiento del circuito se produce sólo desde
el teléfono del usuario hacia la centralita más próxima, donde se digitaliza la voz y se
utilizan otras técnicas como, por ejemplo, la conmutación de paquetes, para enviar la
información.
3.2.2. Conmutación de paquetes
Uno de los principales problemas que encontramos con la conmutación de

circuitos es la exclusividad de los recursos, ya que cuando hay un circuito crea-
do, aunque no haya datos pasando por el circuito, los recursos están reserva-
dos y no pueden ser utilizados por ninguna otra estación. El problema se ve

agravado ya que, para conexiones de datos como las que hay hoy día, el tráfi-
co, en vez de ser constante, llega en ráfagas; por ejemplo, cuando el usuario
carga una página web, la carga sólo supone unos pocos centenares de milise-
gundos, mientras que su lectura puede comportar unos cuantos minutos. Otro
problema impuesto por la conmutación de circuitos es la necesidad de que
todos los nodos de la comunicación trabajen a la misma velocidad, ya que los
nodos intermedios no realizan ningún procesado de la información, cosa que
en una red actual no es cierta; cada usuario tiene una velocidad diferente, que
es a la vez diferente de la que utilizan los operadores.
Así, con el fin de mejorar la conmutación de circuitos de cara a estas nuevas

necesidades se diseñó la conmutación de paquetes con los siguientes objetivos:
• Optimización de la utilización de los canales de comunicación.

• Interconexión de terminales con diferentes velocidades.
• Creación de conexiones de forma simultánea sin reserva de recursos.
Así, la conmutación de paquetes, en vez de reservar recursos en un circuito,

dota a los nodos intermedios de capacidad de proceso y de un sistema de colas
que permite almacenar temporalmente un paquete, mirar cuál es su destina-
tario y enviarlo hacia el nodo que corresponda.
Como se ha dicho, la conmutación de paquetes tiene que permitir diferentes

velocidades de transmisión; por eso se utilizan las colas de recepción y las colas
de transmisión, tal como muestra la siguiente figura. Según se puede compro-
bar, un nodo de conmutación está compuesto por interfaces; estas interfaces
están compuestas, entre otras cosas, por una cola de entrada y otra cola de
salida al sistema, y se utilizan con el fin de controlar el acceso al nodo de con-
mutación, que, ahora, en vez de ser pasivo, procesará todos los paquetes que
llegan por las colas de entrada y los colocará en la cola de salida de la interfaz
correspondiente para ser enviados.
Colas en la conmutación de paquetes
Las colas del nodo de conmutación tendrán un tamaño determinado, lo que

implica que si una cola se llena antes de ser procesada, hay paquetes que ten-
drán que ser descartados. En módulos posteriores veremos cómo la red gestio-
na y evita estas pérdidas.
Otro importante factor a considerar en este entorno es el tamaño del paquete

a transmitir; inicialmente se pensó en hacer los paquetes tan grandes como el
mensaje a enviar (conmutación de mensajes), pero enseguida se vio que, para
mensajes grandes, los nodos intermedios necesitaban demasiada memoria –ya
que almacenan el paquete en su totalidad antes de enviarlo–, y demasiado
tiempo para procesarlo. Así, lo que se hace actualmente es dividir los mensajes
en fragmentos de un tamaño máximo fijado (generalmente 1.500 octetos).
Un ejemplo de eso se puede encontrar en la figura siguiente; las dos subfiguras

muestran el envío del mismo mensaje, primero con conmutación de mensajes,
y después con conmutación de paquetes. Como se puede ver en este ejemplo,
el mensaje ha sido enviado con tres paquetes diferentes de un tamaño inferior.
A causa del almacenamiento en los nodos intermedios (denominado store and
forward) la conmutación de paquetes es generalmente más rápida.
Funcionamiento de la conmutación de paquetes y de mensajes
3.2.3. Conmutación de paquetes con circuito virtual
Aunque la conmutación de paquetes es mejor que la conmutación de mensa-

jes, ambas soluciones tienen el problema de que, dependiendo del tamaño y
el estado de las colas de los nodos intermedios, el retardo en la llegada de la
información es variable. Ello implica que en comunicaciones críticas en tiem-
po (como una conversación de voz) se pueda llegar a crear un problema; por
ejemplo, si un paquete de voz llega demasiado tarde, no podrá ser descodifi-
cado y el otro interlocutor notará un pequeño corte en la conversación.
Para minimizar este problema aparecieron lo que se conoce como conmuta-

ción de paquetes con circuito virtual, que tiene por objetivo reunir las ventajas
de los dos paradigmas. Así, en vez de enviar de forma independiente todos
los paquetes de una conexión, lo que hacen los circuitos virtuales es decidir el
camino previamente (como con conmutación de circuitos), pero mantenien-
do el envío de paquetes individuales, de manera que ahora todos los paquetes
seguirán el mismo camino, por lo que podemos tener una reserva de recursos.
3.3. Alcance de las redes
(1)
Una clasificación bastante clásica de las redes es la que se hace en función de su En inglés, Wide Area Networks
(WAN).
alcance, aunque, dependiendo del entorno, esta clasificación puede cambiar.
Generalmente se consideran dos categorías: las redes de gran alcance1 y las (2)
En inglés, Local Area Networks
2 (LAN).
redes de alcance local .
Antes de detallar qué son las LAN y las WAN es conveniente introducir en Otras categorías de redes
primer lugar los conceptos de redes de difusión y redes punto-a-punto.

Hay otras categorías de redes,
como las redes metropolitanas
(Metropolitan Area Network,
MAN) o las redes personales
Una red de difusión (o broadcast) es aquella en la que el medio es com- (Personal Area Network, PAN),
aunque normalmente se las
partido por todas las estaciones que forman la red; así, todos los equipos puede incluir dentro de las re-
des LAN.
reciben todos los paquetes, pero sólo procesan los dirigidos hacia ellos.
Entre otras cosas, una red de difusión comporta serios problemas de privaci-
dad; por eso, en este tipo de redes es recomendable utilizar mecanismos de
cifrado en las conexiones, como, por ejemplo, en las redes sin hilos.
Las redes punto-a-punto, en contraposición a las redes de difusión, son

aquellas en las que las conexiones son dedicadas entre dos puntos de-
terminados de la red.
A pesar de que un enlace punto-a-punto puede parecer poco flexible, en la

realidad es el tipo de conexión más utilizado actualmente, ya que se puede
desplegar para formar topologías en estrella, en árbol o en malla de forma
muy sencilla. Dependiendo del sentido de la comunicación que permiten, los
enlaces punto-a-punto pueden ser:
• Simplex. La comunicación es unidireccional, uno de los dos puntos es

siempre el origen, y el otro, el destino.
• Semidúplex�(Half-duplex). La comunicación puede ser bidireccional, pe-

ro siempre y cuando los dos puntos de la comunicación alternen la gene-
ración de tráfico, ya que si enviaran al mismo tiempo se provocaría una
colisión que invalidaría ambas transmisiones.
• Dúplex�(Full-duplex). El caso más común actualmente es cuando el me-

dio está preparado para poder enviar y recibir información de forma si-
multánea sin ningún problema.
Hay que señalar que con las comunicaciones bidireccionales la velocidad pue-
de ser igual (conexión simétrica) o diferente dependiendo del sentido de la
comunicación (conexión asimétrica).
3.3.1. Redes de gran alcance
(3)
Redes de gran alcance3 se consideran aquellas que se utilizan en espacios geo- En inglés, Wide Area Networks
(WAN).
gráficos extensos. Generalmente, las WAN se encargan de la interconexión de
las LAN, facilitando así la conexión de los usuarios de diferentes localizacio-
nes. La transmisión de datos se suele hacer mediante grandes operadoras de
comunicaciones con líneas de comunicación contratadas (leased lines), utili-
zando infraestructuras que se consideran públicas (para evitar monopolios).
Las conexiones WAN son prácticamente siempre punto-a-punto, exceptuando

los enlaces vía satélite, que, por el hecho de utilizar el aire como medio de
transmisión, son inherentemente medios de difusión. Por su gran extensión,
las redes WAN, en general, están compuestas por topologías en árbol que están
conectadas con topologías en malla, formadas por miles de nodos.
3.3.2. Redes de área local
(4)
Por el contrario, en las WAN, las redes de alcance local4 están diseñadas para En inglés, Local Area Networks
(LAN).
tener un alcance más reducido, que puede oscilar entre unos pocos kilómetros
y algunos metros (incluso centímetros). Las tecnologías LAN están pensadas
para conectar usuarios con pocos equipos, edificios empresariales o incluso
campus enteros. Normalmente, estas LAN se acaban conectando en WAN; ac-
tualmente, esta interconexión masiva de LAN y WAN a escala global se conoce
como Internet.
Clásicamente, las LAN han utilizado un medio de difusión para enviar la in- Redes sin hilos
formación, pero desde la aparición de los conmutadores y otros equipamien-
Hay muchos tipos de redes sin
tos más actuales han pasado, mediante topologías en árbol y en estrella, a ser hilos, y no todos pueden ser
un conjunto de conexiones punto-a-punto. La excepción a esta regla vuelven clasificados como LAN, por
ejemplo, el de las redes de te-
a ser las redes que utilizan el aire como medio de transmisión, las redes sin lefonía móvil.
hilos, que utilizan difusión para enviar la información.
3.4. Tecnologías de red
La última clasificación del hardware de red hace referencia a las diferentes tec-
nologías existentes para hacer una red, la lista de tecnologías de red existentes
en la actualidad es demasiada extensa para poder listarla; aquí se introducen
las tecnologías más importantes en la actualidad, cuya lista comprende las
tecnologías cableadas y las tecnologías sin hilos.
3.4.1. Tecnologías de red cableada
(5)
Dentro de las redes cableadas, la familia de tecnologías por excelencia es Et- IEEE es la abreviatura del Institu-
5 te of Electronic and Electrical Engi-
hernet (definido en el estándar IEEE 802.3) , que empezó como una tecnología neers.
a 10 Mbps con una topología en bus y medio compartido, y que ha ido evo-
lucionando a una topología en estrella a 1 Gbps (Gigabit Ethernet) pasando 10 Gigabit Ethernet
por Fast Ethernet, todavía muy utilizado en la actualidad a 100 Mbps.
También existen modelos de
10 Gigabit Ethernet, pero su
A pesar de empezar siendo una tecnología limitada a LAN, Ethernet ha evolu- implantación todavía está en
sus inicios.
cionado tanto, gracias a su bajo coste y a su gran aceptación, que actualmente
hay enlaces WAN construidos con esta tecnología.
Por lo que respecta a las topologías basadas en anillo, como Token Ring (IEEE
802.5) y FDDI (definido en el estándar ANSI X3T12), han ido cayendo en de-
suso, en relación con Ethernet, principalmente a causa de su coste más alto
y peor rendimiento. Actualmente, una topología en anillo muy utilizada es
Resilient Packet Ring (IEEE 802.17), una tecnología para transportar otras tec-
nologías a través de anillos de fibra óptica; normalmente se transporta direc-
tamente tráfico Ethernet y servicios IP.
3.4.2. Tecnologías de red sin hilos
Un punto en el que ha habido una gran expansión en los últimos años es el

relativo a la aparición de tecnologías de red sin hilos. De este tipo de redes se
pueden extraer principalmente dos, las redes de telefonía móvil y las redes sin
hilos de más corto alcance.
Entre los muchos tipos de redes de telefonía móvil que hay se puede mencio-
nar el del Global System for Mobile Communications (GSM), que fue de los
primeros sistemas que apareció y permite el envío de datos a 9,6 Kbps, para
evolucionar al más actual General Packet Radio Service (GPRS), con un ancho
de banda máximo teórico de 171,2 Kbps, pero cuyo canal de bajada es efecti-
vamente de 64 Kbps y el de subida de 14 Kbps. La última implementación en
tecnologías de red móviles es la Universal Mobil Telecommunication Services
(UMTS), también conocida como el sistema de tercera generación (3 GR), que,
con unos sistemas más avanzados, es capaz de llegar a velocidades teóricas de
21 Mbps, pero con velocidades efectivas de 7,2 Mbps de bajada y 384 Kbps
de subida.
Con respecto a las redes sin hilos de más corto alcance, la tecnología por ex-
celencia usada es la Wireless LAN (WiFi - IEEE 802.11), que inicialmente fue
definida con una velocidad de 11 Mbps, pero que con posteriores revisiones
del estándar se ha diseñado para soportar velocidades de 54 Mbps, con un al-
cance aproximado de 100 metros. En los últimos años, con el fin de reducir
el consumo energético de las comunicaciones sin hilos con equipos de baja
potencia, ha aparecido el estándar de facto para la comunicación de equipos
pequeños (móviles, PDA...), que es Bluetooth, con una velocidad de 1 Mbps y

un alcance aproximado de 10 metros, pero con un consumo energético muy
bajo que lo hace muy atractivo para transferencias de datos cortas.
Finalmente, una tecnología que se queda entre el corto y el largo alcance es

WiMAX (IEEE 802.16), una tecnología sin hilos muy utilizada en la actualidad
para dar conectividad a zonas aisladas y de difícil acceso, donde la comunica-
ción cableada es muy cara. WiMAX tiene una velocidad máxima aproximada
de 150 Mbps de bajada y 35 Mbps de subida, con un alcance de unos 70 ki-
lómetros.
4. Dispositivos de red
Las redes de hoy en día funcionan porque hay una serie de dispositivos que son
capaces de gestionar tanto la información de control y presencia de los nodos
de una red como la información que dichos nodos se transmiten. Básicamente,
los dispositivos de red son los siguientes:
(6)
• Encaminador�o�enrutador6. Es un dispositivo de red de nivel 3 del mo- En inglés, router.
7
delo OSI . Recoge la información del nivel de red (dirección IP) para tomar
(7)
OSI es la abreviatura de Open
las decisiones de encaminamiento: escoger el camino o ruta más adecuada Systems Interconnection (interco-
por donde reenviar los datos recibidos. La sucesión de decisiones de dife- nexión de sistemas abiertos).
rentes routers posibilita la llegada de la información desde su origen hasta

el sistema informático de destino.
• Concentrador8. Es un dispositivo de red que permite agrupar un conjunto

de dispositivos Ethernet en un mismo segmento de red. Actúa en el pri-
mer nivel del modelo OSI o nivel físico, sin entrar por lo tanto a analizar
las direcciones MAC de destino. Por ello, todo lo que llega es reenviado
indiscriminadamente a todos los ordenadores conectados.
Router
• 9
Conmutador . Es un dispositivo digital de lógica de interconexión de re- (8)
En inglés, hub.
des de computadores que opera en la capa 2 (nivel de enlace de datos) del
modelo OSI. Su función es interconectar dos o más segmentos de red, de
manera similar a los puentes (bridges), pasando datos de un segmento a
otro de acuerdo con la dirección MAC de destino de las tramas en la red.
Los conmutadores se utilizan cuando se desea conectar múltiples redes que
se fusionan en una sola. Igual que los puentes, ya que funcionan como un
filtro en la red, mejoran el rendimiento y la seguridad de las LAN. Concentrador
(9)
En inglés, switch.
• 10
Puente�de�red . Es un dispositivo de interconexión de redes de ordena-
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 direc-
ción física de destino de cada paquete. Un bridge conecta dos segmentos de (10)
En inglés, bridge.
red como una sola red utilizando el mismo protocolo de establecimiento
de red.
• Tarjeta�de�interfaz�de�red. Físicamente es una tarjeta de expansión inser-

tada dentro del ordenador con una o más aberturas externas por donde se
11
conecta el cable de red. En el plano conceptual, la tarjeta de red , también
Puente de red
llamada adaptador de red, permite la comunicación entre los diferentes
dispositivos conectados entre sí y, asimismo, la distribución de recursos
entre dos o más equipos. Hay diversos tipos de adaptadores en función del
(11)
tipo de cableado o arquitectura que se utilice en la red (coaxial fino, coa- En inglés, network interface card
(NIC).
xial grueso, Token Ring, etc.), pero el más común actualmente es el Ether-
net, que utiliza una interfaz o conector RJ-45. Cada tarjeta de red tiene un
número de identificación único de 48 bits en hexadecimal, denominado
dirección MAC. Estas direcciones de hardware son únicas y están adminis-
tradas por el Institute of Electronic and Electrical Engineers (IEEE).
Tarjeta de red
5. Software de red
Cuando aparecieron las redes de computadores, los fabricantes hacían el dise-

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

5.1. Arquitectura de la red: diseño por capas
Históricamente, las primeras redes se diseñaron teniendo sólo en cuenta el

hardware de las comunicaciones. Esta estrategia no tuvo mucho futuro y las
redes evolucionaron hacia una combinación de software de red muy estructu-
rado y hardware genérico.
Para reducir la complejidad del diseño, las redes están organizadas en una serie
de capas, situadas unas encima de otras. El número de capas, el nombre de
cada una de ellas, su contenido y sus funciones difieren de un tipo de red
a otro. En todas las redes, el objetivo de cada capa es ofrecer determinados
servicios a las capas superiores, ocultándoles a éstas los detalles de cómo están
implementados los servicios que se ofrecen.
La capa de nivel N de un ordenador mantiene comunicación con la capa de

nivel N de otro ordenador. Las reglas y convenciones usadas en la capa de nivel
N se denominan protocolos. Básicamente, un protocolo es un acuerdo entre
las partes de la comunicación sobre cómo se realiza ésta.
En la siguiente figura se muestra una pila de protocolos: las entidades que

utilizan las correspondientes capas en los diferentes ordenadores se llaman
pares (peers). En otras palabras, los pares se comunican usando un protocolo.
En la realidad, la información no se transfiere directamente de una capa N de

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

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

lista de protocolos, un protocolo por capa, se llama la pila de protocolos.
Para explicar las comunicaciones multicapa, observemos la siguiente figura.

Imaginemos que tenemos dos filósofos (procesos pares (peer), capa 3). Un filó-
sofo habla urdu e inglés, y el otro, chino y francés. Como no hablan ninguna
lengua en común necesitan un traductor (capa 2), y cada traductor se pone en
contacto con su secretaria (capa 1) para enviar la información remotamente
al otro filósofo. El filósofo 1 quiere enviar un mensaje al filósofo 2. Así pues,
pasa el mensaje en inglés a través de la interfaz 2/3 a su traductor, que traduce
el mensaje en una lengua neutral (neerlandés). La elección de la lengua de la
capa 2 es la misma en las dos entidades remotas. Después, el traductor pasa el
mensaje a la secretaria para que ésta lo transmita vía fax (capa 1) a la otra se-
cretaria. Cuando el mensaje llega a la secretaria remota, ésta lo pasa al traduc-
tor remoto (capa 2), y traduce el mensaje al francés para pasarlo finalmente al
filósofo remoto. Hay que tener en cuenta que cada protocolo es independiente
de los otros en la pila de protocolos, y que podemos cambiar un protocolo por
otro mientras las interfaces no cambien. Por ejemplo, la secretaria podría optar
por transmitir los mensajes por fax o enviarlos por correo postal, teléfono o
correo electrónico, sólo cambiando la capa 1 sin cambiar la interfaz 2/1.
Observemos la siguiente figura. Consideremos que se produce la comunica-

ción de la capa superior. Un mensaje M es producido por un programa (o pro-
ceso) que funciona en la capa de nivel 5. La capa 5 envía el mensaje M a la capa
4. La capa 4 pone la cabecera antes del mensaje para identificar el mensaje y le
pasa el resultado a la capa 3. La cabecera incluye el control de la información,
como los contadores de control de secuencia, para permitir que la capa 4 de
la máquina destino reciba los mensajes en el orden correcto, ya que las capas
inferiores no tienen ninguna obligación de mantener la secuencia. En las otras
capas, las cabeceras mantienen tamaños, tiempos y otros campos de control.
En muchas redes no existe límite en el tamaño de los mensajes transmitidos

en la capa de nivel 4, pero muchas veces el protocolo de nivel 3 sí que impone
restricciones. Consecuentemente, la capa 3 tiene que partir el mensaje que le
envía la capa superior en varias unidades menores, denominadas paquetes; la

capa de nivel 3 introduce una cabecera de nivel 3 en cada paquete. En este
ejemplo, M queda dividido en dos partes, M1 y M2.
La capa de nivel 3 decide qué línea de salida transmitirá los paquetes a la capa
de nivel 2. La capa de nivel 2 añade una cabecera a cada trozo y ofrece el
resultado a la capa de nivel 1 (física) para su transmisión. En el ordenador que
recibe la información se envía el mensaje a la capa superior, capa por capa,
con las cabeceras que se van eliminando a medida que se progresa de forma
ascendente de capa en capa.
5.2. Consideraciones de diseño
El nivel por capas se da una forma estructurada de diseñar y abstraer las tareas
necesarias con el fin de enviar información a través de la red, pero cuando se
diseña una arquitectura de red hay muchos más factores, aparte de las capas,
que se tienen que considerar. Los siguientes son los más relevantes:
1)�Identificación: cada nodo de la red se tiene que poder identificar de forma

única con el fin de identificar a sus interlocutores.
2)�Encaminamiento: los nodos de la red han de tener mecanismos que per-

mitan enviar la información a cualquier interlocutor de la misma red.
3)�Control�de�errores: una de las partes más importantes de cualquier comu-

nicación es garantizar que, cuando la información llegue al otro nodo, lo haga
sin errores. Hay que señalar que los medios de transmisión no siempre son
fiables, por lo que se tiene que decidir cuál o cuáles capas verificarán errores
y cómo lo harán.
4)�Modos�de�transferencia: qué soporte tendrá el protocolo para el envío de

información, si se puede enviar información en modo full duplex, half duplex
o simplex. Y, caso de que sea necesario, si habrá algún tipo de priorización en
el envío.
5)�Control�de�congestión: dado que las velocidades de transmisión de una

red no siempre son homogéneas y que a veces habrá enlaces con más carga
que otros, cualquier protocolo tiene que considerar la posibilidad de que se
tenga que disminuir la velocidad a la que se envían los datos, o bien, en el
caso de que algún paquete no llegue al destino, de que se tenga que reenviar
de forma transparente al usuario.
6)�Tamaño�de�los�paquetes: como ya hemos visto anteriormente, enviar men-

sajes muy grandes no siempre es posible, por lo que se tiene que decidir qué
tamaño máximo podrán tener los paquetes que se envían a la red.
6. Jerarquía de protocolos y cabecera
Cada capa necesita un mecanismo para identificar al emisor y el receptor. Una

red tiene diversos nodos y en cada uno de ellos se ejecutan múltiples proce-
sos. Cada proceso tiene que saber con quién se quiere comunicar, teniendo
en cuenta que los destinos pueden ser diversos. De esta manera se hace nece-
saria una forma de direccionamiento que nos permita determinar un destino
específico.
Otra característica del diseño de un protocolo es si los datos sólo viajan en un

solo sentido (comunicación simplex) o lo hacen en las dos direcciones, pero no
simultáneamente (comunicación half duplex), o viajan en las dos direcciones
simultáneamente (comunicación full duplex). El protocolo tiene que determi-
nar cuántos canales lógicos tiene que gestionar, y las prioridades de estos ca-
nales. Muchas redes permiten como mucho dos canales lógicos, un canal para
datos normales y un canal para datos urgentes.
El control de los errores es otro aspecto importante, ya que los enlaces de co-
municaciones físicos no son perfectos. Determinados códigos de detección y
corrección de errores se utilizan, y los ordenadores que se comunican se tienen
que poner de acuerdo en la utilización de un código corrector/detector con-
creto. Además, el receptor de la información tiene que comunicar al emisor
de los mensajes que se han recibido o no correctamente.
No todos los canales de comunicación preservan el orden de envío de los men-

sajes. Para solucionar la posible pérdida de la secuencia de los mensajes, el
protocolo tiene que gestionar los diferentes trozos de información en una me-
moria (buffer) para finalmente ordenarlos correctamente.
Otro aspecto que se tiene en cuenta es el de cuando un emisor transmite in-

formación muy rápidamente hacia un receptor lento. Muchas soluciones uti-
lizan una técnica que consiste en que el receptor envíe una señal al emisor
indicándole su problemática. Otras soluciones limitan la velocidad del emisor
cuando supera un cierto umbral.
Otro problema es que determinados niveles acepten mensajes de una longitud

que supere un cierto límite. Por eso se utilizan mecanismos para desensamblar,
transmitir y reensamblar mensajes.
A veces, el canal físico de transmisión es compartido por muchas conexiones

que intentan transmitir a la vez sobre un mismo enlace. En este caso, la multi-
plexación y desmultiplexación de la capa física nos permite transmitir mucha
información sobre pocos circuitos físicos.
Cuando existen múltiples caminos entre el origen y el destino se tiene que

elegir una ruta. Esta decisión se toma muchas veces entre dos o más capas.
7. Interfaces y servicios
La función de cada capa es proporcionar servicios a la capa superior. En este

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

varios trozos, a cada uno de los cuales se asigna una cabecera, que se envían
como un Protocol Data Unit (PDU) o paquete. A través de las cabeceras de la
PDU, la peer entity identifica qué PDU contienen datos y cuáles contienen in-
formación de control, proporcionando números de secuencia y contadores.
Las capas pueden ofrecer dos tipos diferentes de servicios a las capas superio-
res: conexiones orientadas y no orientadas a conexión. Un servicio orientado
a conexión se modela como un sistema de telefonía: para hablar con alguien,
primero tenemos que marcar el número de teléfono, después, hablar, y, final-
mente, colgar el teléfono. Así, inicialmente se produce un establecimiento de
conexión, después se utiliza la conexión para hablar y transmitir información,
y, finalmente, se cierra la conexión. Esta conexión actúa como un tubo: el
emisor envía objetos o bits hacia el receptor, y el receptor los coge en el mismo
orden en que le son enviados.
Un servicio no orientado a conexión se modela como un sistema postal. Cada

mensaje o carta postal lleva la dirección completa del destinatario, y cada carta
la envía el sistema independientemente de las otras cartas. Normalmente, de
dos mensajes que se envían al mismo destino, el primero que se envíe será el
primero que se recibirá. También es posible que el enviado en primer lugar
sufra algún retardo y que el enviado en segundo lugar llegue antes que el que
se envió primero. En una conexión orientada a conexión eso es imposible.
Cada servicio está caracterizado por lo que se denomina calidad de servicio.

Muchos servicios son fiables en el sentido de que nunca pierden información.
Normalmente, un servicio fiable se implementa mediante el envío de recono-
cimientos por parte del receptor de cada mensaje, y así el emisor sabe que el
mensaje se ha recibido correctamente. El proceso de reconocimientos (ACK)
introduce overhead (información de control redundante, no información útil)
y un cierto retardo, cosa que normalmente no es deseable en términos de ren-
dimiento de la red.
La típica situación en la que se utiliza un servicio fiable orientado a conexión

es la transmisión de ficheros. El usuario del servicio desea que los bits del
fichero lleguen en el orden en que fueron emitidos, y que lleguen todos los
bits del fichero.
Para muchas aplicaciones, los retardos de los reconocimientos son inacepta-

bles. Por ejemplo, en el caso del tráfico de voz digitalizada. Para los usuarios
del teléfono es preferible oír por el auricular un poco de ruido de la línea o
una palabra mal entendida de vez en cuando, que soportar que se produzca
un retardo en la espera del reconocimiento. También cuando se transmite una

película de vídeo es preferible tener varios puntos (píxeles) incorrectos (que
en la práctica casi no son ningún problema) que tener que ver la película con
paradas para corregir los errores (es muy irritante).
Las conexiones no fiables (con la no utilización del mecanismo de reconoci-

miento) y las no orientadas a conexión se llaman servicio de datagrama (por
ejemplo, el envío de e-mails).
También en algunas situaciones es conveniente no tener que establecer una

conexión para enviar un mensaje corto, pero en el que la fiabilidad tiene que
ser esencial. Por eso se utilizan los servicios no orientados a conexión con
reconocimiento (ACK). Por ejemplo, cuando se envía un e-mail, el receptor del
correo electrónico, cuando lo ha recibido, le devuelve un e-mail al emisor para
indicarle que lo ha recibido.
Otro tipo de servicio es el request-reply-service: el emisor transmite un datagra-

ma simple que contiene la petición. La respuesta contiene tanto la pregunta
como la respuesta.
Un servicio se especifica formalmente con un conjunto de primitivas (opera-

ciones) de las que el usuario u otra entidad puede disponer para acceder al
servicio. Esas primitivas mandan realizar al servicio alguna acción o devolver
el resultado de una acción de la entidad par (peer entity). La siguiente tabla nos
muestra las maneras de clasificar las primitivas del servicio:
Primitiva Significado
Request Una entidad quiere que el servicio realice alguna cosa.
Indication Una entidad es informada de algún evento.
Response Una entidad quiere responder a algún evento.
Confirm La respuesta a la última petición se confirma.

Consideremos cómo se establece y se libera una conexión. La entidad que

establece la conexión realiza una CONNECT.request y el receptor recibe la
CONNECT.indication anunciando que una entidad se quiere conectar al recep-
tor. La entidad que recibe la CONNECT.indication utiliza la CONNECT.response
para comunicar que acepta o rechaza la conexión propuesta. La entidad que
realiza la petición de conectar recibe la aceptación o el rechazo de su conexión
a partir de la primitiva CONNECT.confirm.
Cada primitiva puede llevar parámetros o no. Por ejemplo, la primitiva

CONNECT.request tiene que especificar la dirección de la máquina a la que se
quiere conectar, el tipo de servicio deseado y la longitud máxima del mensaje
a utilizar durante la conexión. Los parámetros de la CONNECT.indication tie-
nen que contener la identidad de quien realiza la llamada, el tipo de servicio
deseado y la longitud máxima del mensaje propuesta. Si la entidad llamada
no acepta la longitud máxima del mensaje propuesta, puede realizar con la
primitiva response una nueva propuesta sobre la longitud del mensaje. Los de-
talles de cada negociación forman parte de cada protocolo.
Los servicios pueden ser confirmados o no ser confirmados. En un servicio

confirmado están las primitivas request, indication, response, confirm. En un ser-
vicio no confirmado sólo están las primitivas request e indication. El servicio
CONNECT sólo se utiliza en los servicios confirmados porque la entidad remo-
ta tiene que dar el visto bueno al establecimiento de la conexión.
Las ocho primitivas de un servicio orientado a conexión son las siguientes:
1) CONNECT.request: pedir el establecimiento de la conexión.
2) CONNECT.indication: indicar a la parte solicitada un establecimiento de

conexión.
3) CONNECT.response: utilizado por la parte solicitada para aceptar/rechazar

la conexión o llamada.
4) CONNECT.confirm: indicar al que la ha solicitado si la conexión o la petición

ha sido aceptada.
5) DATA.request: indicar que se envía la información.
6) DATA.indication: indicar la llegada de la información.
7) DISCONNECT.request: indicar que la conexión se ha cerrado.
8) DISCONNECT.indication: indicar a la otra entidad el cierre de la conexión.

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 in-
cluye una interacción entre dos capas de una de las computadoras. Cada pe-
tición o respuesta provoca una indicación o confirmación en la otra parte. El
usuario del servicio está en la capa N + 1, y la capa N es la capa que ofrece el
servicio.
Los protocolos y los servicios son dos conceptos distintos, aunque en general
se suelen confundir. Un servicio es un conjunto de primitivas (operaciones)
que una capa proporciona a la capa superior. El servicio define qué operaciones
es capaz de ofrecer la capa, pero no dice nada de cómo están implementadas
estas operaciones. Un servicio es una interfaz entre dos capas, siendo la capa
de nivel inferior la que proporciona el servicio, y la capa de nivel superior la
que lo utiliza.
Un protocolo es un conjunto de normas que gobiernan el formato y el signi-

ficado de las tramas, paquetes o mensajes que se intercambian las entidades
dentro de una misma capa. Las entidades utilizan los protocolos para imple-
mentar las definiciones del servicio.
Un servicio sería como un tipo abstracto de datos o un objeto en los

lenguajes de programación. Define las operaciones que se pueden rea-
lizar sobre el objeto pero no especifica cómo se implementan las ope-
raciones. Un protocolo relata cómo se implementa el servicio y, si es
posible, cómo hacer que no sea visible para el usuario del servicio.
7.1. Tipo de conexión de servicios
Cada servicio establece una conexión con el servicio análogo del equipo de
destino; dependiendo de cómo se gestione esta conexión entre servicios, un
servicio puede ser orientado a conexión o no orientado a conexión.
El servicio orientado a conexión previo al envío de información se establece Protocolo orientado a

una conexión, que se libera cuando la transferencia acaba. No hay que con- conexión
fundir un servicio orientado a conexión con la conmutación de circuitos vis- El ejemplo por excelencia de
ta anteriormente; en el servicio orientado a conexión no se realiza ninguna un protocolo orientado a co-
nexión es el TCP.
reserva de recursos, sino una estructura de datos que mantiene el estado de la
conexión. El hecho de que un protocolo sea orientado a conexión implica que
la información tiene que llegar ordenada y sin errores. El hecho de mantener
la conexión implica que ambos extremos son conocidos y, por lo tanto, no
es necesario indicar qué destino tiene la comunicación. Este paso se realiza
durante el establecimiento de la conexión.
Por su parte, los servicios no orientados a conexión no precisan ni asumen Servicios no orientados a
ninguna conexión previa entre los dos interlocutores; de esta manera, la in- conexión
formación se separa en paquetes (denominados datagramas en este tipo de El ejemplo por excelencia de
servicios) y se envía a la red sin conocer el camino que seguirán los paquetes, servicios no orientados a co-
nexión es IP. Curiosamente,
ni saber si llegarán a su destino, ni siquiera en qué orden lo harán, cada data- HTTP es también un protocolo
no orientado a conexión.
grama se envía de forma autónoma e independiente del resto. Por lo tanto,
para poder enviar un datagrama con un protocolo no orientado a conexión,
el datagrama tiene que tener la dirección destino, y los elementos intermedios
de la red tienen que tener información de cómo hacer llegar la información
dependiendo del destino de cada datagrama recibido.
8. Modelos de referencia
Las dos arquitecturas de red más conocidas hoy en día son la Open Systems
Interconnection (OSI), utilizada como modelo teórico, y la Transmission Con-
trol Protocol/Internet Protocol (TCP/IP), cuyo éxito en el mundo de las redes
ha sido enorme.
8.1. Necesidad de estandarización
Los primeros ordenadores realizaban trabajos concretos, ubicados en lugares

cerrados y aislados. Cada fabricante vendía su sistema de comunicaciones in-
tegral a las empresas, encargándose de todos los aspectos relacionados con la
red (equipos, software, cableado, etc.). Cuando una empresa necesitaba algu-
na ampliación y/o modificación, sólo podía contar con un único interlocutor
para proporcionarle los servicios necesarios. Eso acarreaba varios problemas,
tales como:
• Los costes eran elevados, ya que los adaptadores eran a medida.
• Nula interoperabilidad, ya que resultaba imposible interconectar unos sis-

temas con otros, a causa de la falta de compatibilidad entre dispositivos.
Cuando se elegía un suministrador era para siempre.
Con estas limitaciones, a partir de los años ochenta empezaron a aparecer

organizaciones que construían equipos para interconectar redes y pasarelas
entre ordenadores de diferentes fabricantes. Podemos destacar los siguientes
hitos:
1) Tres empresas, DEC, INTEL y XEROX (Consorcio DIX), se pusieron de acuer-

do para crear un primer estándar para redes de área local para la red ETHER-
NET. En 1982, DIX distribuyó la versión II de Ethernet, que es la versión es-
tándar para TCP/IP.
2) El comité 802.3 de IEEE recogió la versión de DIX y empezó a trabajar en

una trama Ethernet mejorada. La red Ethernet tenía un coste bajo y altas pres-
taciones, junto con una sencillez de operación.
3) El sistema operativo UNIX, creado por BELL Laboratories, empezó a popu-

larizarse, y diversas organizaciones (empresas y universidades) lo implemen-
taron en sus sistemas (BSD-UNIX de Berkeley, Xenix, SUNOS, HP-UX, etc.).
Ésta fue la principal causa de la extensión de TCP/IP, dado que estaba incluido
en su kernel.
4) Creación de un modelo de referencia OSI de ISO.
Estos hechos provocaron que los sistemas que hasta este momento ofrecían
una arquitectura cerrada pasaran a una arquitectura abierta y que las redes
empezaran a ser compatibles.
Se empezaron a estandarizar componentes y funcionalidades de cada nivel ar-

quitectural para poder intercomunicar los sistemas heterogéneos. La informa-
ción de los estándares se hace pública, hecho que no pasaba con los sistemas
propietarios.
Se crean fórums externos a los organismos que pueden llegar a forzar a éstos
a decidirse por uno u otro estándar (ATM Forum, Forum Gigabit Ethernet,
Forum ADSL, etc.).
La existencia de estándares tiene las siguientes ventajas y desventajas, que se

muestran en la tabla siguiente.
Ventajas Desventajas Perjuicios económicos
• Estimula la competitividad entre los fabri- • Tardanza al aprobarse Hay importantes ganancias
cantes • Los fabricantes crean equipos en condiciones económicas para las empresas
• Evita monopolios propietarias que han desarrollado un siste-
• Baja los precios • Los intereses de los fabricantes y los organis- ma y éste se convierte en es-
• Flexibilidad de instalar equipos mos no siempre son los mismos tándar. No obstante, ello pue-
de provocar que otras empre-
• Heterogeneidad de fabricantes • Posibilidad de acuerdos más políticos y co-
sas salgan perjudicadas.
merciales que técnicos
• Los fabricantes son los que desarrollan más
I+D, lo cual provoca que los organismos ten-
gan que definirse
• Muchos organismos pueden afectar a la es-
tandarización, ya que se puede llegar a clasi-
ficar geográficamente, por industria, etc.
8.2. El modelo de referencia OSI
Entre los diferentes modelos propuestos por las diferentes organizaciones in-
ternacionales de normalización en la década de los ochenta, destaca una ar-
quitectura de redes de ordenadores basada en niveles, el modelo OSI, definido
por la Organización Internacional de Estándares (ISO, International Organi-
zation for Standardization).
A finales de los setenta, la ISO fue definiendo la arquitectura de redes OSI con
el fin de promover la creación de una serie de estándares que especificaran
un conjunto de protocolos independientes de cualquier fabricante. Pretendía
establecer las normas y estándares para que el software y los dispositivos de
diferentes fabricantes pudieran funcionar juntos.
(13)
Además de facilitar las comunicaciones entre sistemas diferentes, la ISO pre- SNA es la abreviatura de System
Network Architecture.
tendía con OSI impedir que ninguna de las arquitecturas de fabricante exis-
tentes adquiriera una posición hegemónica, especialmente la SNA13 de IBM.
Seguramente, la aportación más importante de la iniciativa OSI ha sido preci-

samente la definición teórica de su modelo arquitectónico. Ésta ha servido co-
mo 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 ni-
veles fueron los siguientes:
1) Una capa se creará en situaciones donde se necesite un nivel diferente

de abstracción.
2) Cada capa tendrá que realizar una función bien definida.
3) Los problemas se resuelven en una capa concreta sin afectar al resto

de las capas.
4) Cada capa se basa en los servicios de la capa inmediatamente inferior.
5) Cada capa ofrecerá servicios a las capas superiores sin que éstas sepan
cómo se realizan los servicios.
6) La función que realizará cada capa se tendrá que seleccionar con la

intención de definir protocolos normalizados internacionalmente.
7) Los límites de las capas se habrán de seleccionar teniendo en cuenta

la necesidad de minimizar la cantidad de información que se tiene que
pasar entre capas. La frontera entre capas tiene que ser la más sencilla
posible.
8) El número de capas tiene que ser lo bastante grande para que funcio-
nes diferentes no tengan que ponerse juntas en la misma capa. También
tendrá que ser lo bastante pequeño para que su arquitectura no sea di-
fícil de manejar.
Las capas son las que se muestran en la figura siguiente.

Las capas se pueden agrupar en dos subconjuntos convenientemente diferen-

ciados:
• Capas�inferiores. Son proveedoras de servicios de transporte de las capas Nota

superiores. Tratan problemas tales como errores del sistema de transmi-
Hay que señalar la sospecho-
sión, búsqueda de rutas óptimas, etc. sa coincidencia del número de
capas de OSI con el de SNA, la
arquitectura de red para gran-
• Capas�superiores. Su misión es dar servicios al usuario del sistema de co- des sistemas de IBM, que esta-
ba en pleno apogeo en el mo-
municaciones. Confían en las prestaciones de los niveles inferiores. mento en que se definió OSI.
El objetivo del modelo es el desarrollo de protocolos para desarrollar redes

internacionales. Algunos protocolos se desarrollaron, pero otros, en cambio,
se dejaron de lado en favor de Internet (TCP/IP).
8.2.1. Proceso de encapsulación y desencapsulación
El modelo OSI describe cómo se desplaza la información desde los programas

de aplicación de diferentes ordenadores en un medio de la red. Cada capa
realiza dos procesos de comunicación:
• Comunicación�horizontal. Comunicación con su capa de igual nivel del

otro sistema, que recibe el nombre de protocolo.
• Comunicación�vertical. Comunicación con sus niveles inmediatamente

superior e inferior, que recibe el nombre de primitivas de servicio.
Cuando un usuario necesita transmitir datos a un destino, el sistema de red va

añadiendo información de control (cabeceras) para cada uno de los servicios
que utilizará la red para ejecutar la orden de transmisión.
8.3. Modelo TCP/IP
(14)
TCP/IP es la abreviatura de
En el modelo TCP/IP
14
se pueden distinguir cuatro capas: Transmission Control Protocol/In-
ternet Protocol.
• La capa interfaz de red.

• La capa de red o Internet.
• La capa de transporte.
• La capa de aplicación.
Pasemos a describirlas brevemente.
La comparación de los modelos arquitectónicos de OSI y TCP/IP es la siguiente.

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

observar en la siguiente figura.
Los datos de información del nivel aplicación son encapsulados en la capa de

transporte, donde se le añade la cabecera del protocolo TCP, conformando la
unidad de información denominada segmento. Cuando se envía el segmento
al nivel de red, queda encapsulado dentro de la cabecera del protocolo IP don-
de se indican las direcciones IP de la unidad de información llamada paquete
en este nivel. Este paquete es enviado a la tarjeta de red y allí es encapsulado
según las normas del protocolo del nivel de enlace. Normalmente añade una
cabecera del protocolo de enlace al principio del paquete. En muchos proto-
colos también se añade una cola de datos que sirve para la detección de errores
al final del paquete. La unidad de información aquí recibe el nombre de trama.
Finalmente, los datos son enviados por el medio de transmisión en forma de
impulsos electromagnéticos o bits.
8.4. Modelo OSI comparado con modelo TCP/IP
El modelo OSI, de orientación más académica, es más coherente y modular

y está menos condicionado por cualquier protocolo en particular. Por ello se
utiliza principalmente como modelo de referencia para describir otros tipos
de arquitecturas, como la TCP/IP (el modelo TCP/IP nunca se utiliza para des-
cribir otras arquitecturas que no sean la suya propia). El modelo OSI hace una
distinción muy clara entre servicios, interfaces y protocolos, conceptos que a
menudo se confunden en el modelo TCP/IP.
El modelo OSI nunca ha pasado de ser un bonito desarrollo teórico, aunque

la mayoría de los grandes fabricantes de ordenadores y compañías telefónicas
impulsaron su utilización ofreciendo productos y servicios basados en él. Las
razones principales que motivaron este fenómeno se resumen como sigue:
• OSI apareció tarde. Como todo estándar, se tardaron años en definir una
arquitectura de capas con funcionalidades y servicios perfectamente defi-
nidos. 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 comple-

ja, es muy complicado y muchas veces repite en diferentes capas las mis-
mas funciones. El nacimiento de TCP/IP fue a la inversa: primero se espe-
cificaron los protocolos, y después se definió el modelo como una simple
descripción de los protocolos ya existentes. Por este motivo, el modelo
TCP/IP es más simple que el OSI.
• Los productos comerciales que se basaron en OSI eran malos y caros. La

poca demanda obligaba a las empresas desarrolladoras a fijar altos precios
con el fin de recuperar sus costosísimas inversiones. En contraste, TCP/IP
fue rápidamente incorporado al UNIX de Berkeley donde funcionaba bas-
tante bien, y todo eso a un precio sensiblemente menor: ¡era gratuito!
• Mientras que TCP/IP era visto como parte de UNIX, es decir, una cosa que
realmente funcionaba y estaba al margen de toda sospecha de parcialidad,
OSI era considerado un invento de la Administración para controlar las
telecomunicaciones (un engendro político-burocrático).
Difusión de TCP/IP y del

Por todo eso, TCP/IP se convirtió en el líder mundial absoluto en inter- modelo OSI
conexión de redes. No obstante, TCP/IP tampoco se libró de la crítica.
Hoy en día, la difusión de TCP/
Por una parte, no distingue conceptos tan importantes como servicio, IP por toda Europa es comple-
ta, mientras que los servicios
interfaz y protocolo. En segundo lugar, el modelo TCP/IP no es ningún basados en protocolos OSI han
modelo, es decir, su utilización como esquema de referencia resulta bas- desaparecido prácticamente.
tante inútil en el estudio de otras arquitecturas. En tercer lugar, en el

modelo TCP/IP la capa ordenador principal-red es más bien una interfaz
que una capa, ya que la única cosa que se especifica de ella es que tiene
que ser capaz de transmitir paquetes IP.
9. Breve historia de las comunicaciones
La década de los sesenta vio la aparición de los primeros ordenadores comer-

ciales. Eran grandes, caros y poco potentes. Sólo los podían comprar organis-
mos oficiales, grandes empresas o universidades, y lo más normal era que sólo
compraran uno (o algunos, pero no uno para cada usuario, como hoy estamos
acostumbrados a ver). Por eso, estos ordenadores tenían sistemas operativos
multitarea y multiusuario, para que diferentes usuarios, haciendo diferentes
trabajos, los pudieran utilizar simultáneamente. El acceso a estos ordenadores
se hacía mediante terminales sin ninguna capacidad de proceso, pasivos.
No tardó mucho en aparecer la necesidad de poder alejar los terminales de la

unidad central para conectarse, por ejemplo, desde casa o desde una delega-
ción al ordenador principal.
(15)
Para poder hacer este acceso remoto, la primera solución que aportaron los Recordad que la red telefónica
sólo deja pasar sonidos entre unos
ingenieros informáticos de la época fue utilizar la red telefónica que, por su
márgenes de frecuencia.
ubicuidad, les evitaba tener que generar ninguna infraestructura nueva. Sólo
hacía falta un aparato que adaptara los bits a la red15. Estos aparatos son los
módems.
Los primeros módems eran de 300 bps y generaban dos tonos diferentes: uno
para el 1 lógico y otro para el 0. Actualmente, van a 56.000 bps, que es el má-
ximo que permite la actual red telefónica convencional. Los módems no sólo
servían para poder alejar los terminales pasivos de los ordenadores principales,
también permitían interconectar ordenadores entre sí, de manera que desde
los terminales de uno se podía acceder a los de otro y viceversa.
Módems de los años ochenta
La tecnología de conmutación de circuitos se desarrolló originalmente para las

comunicaciones telefónicas, y una de sus características fundamentales era la
ocupación en exclusiva de los recursos mientras duraba la conexión, cosa que,
como ya hemos visto, justificaba la tarificación por tiempo. Pero las comuni-
caciones informáticas no son cortas, intensas y esporádicas como las de voz.
Al conectar un terminal a un ordenador principal mediante dos módems, no
se pasan datos durante todo el rato que dura la conexión: puede haber largos
períodos de tiempo en los que no pase ningún bit y ratos en los que haya un
intercambio de datos intenso, aunque, desde luego, a una velocidad de trans-
misión mucho más baja que la que se puede mantener entre el terminal y el
ordenador conectados directamente. Las facturas telefónicas empezaron a ser
astronómicas, y desproporcionadas, respecto del uso real de la red.
Períodos en la historia de Internet
Internet es, como tantas otras tecnologías innovadoras, un invento militar. Nació del
interés del ejército norteamericano en los años sesenta por conseguir comunicaciones
fiables y descentralizadas. Es decir, para evitar que un misil bien dirigido pudiera hacer
saltar por los aires un centro vital de comunicaciones. Se pueden establecer cuatro perío-
dos clave en la historia de Internet:
• Primer período: 1957-1970. Nacimiento de Internet.

• Segundo período: 1970-1990. Del Ejército a la Universidad.
• Tercer período: 1990-1995. Expansión fuera de los ámbitos militares y universitarios.
• Cuarto período: 1996-Actualidad. Multimedia y cientos de millones de usuarios.
Primer período: 1957-1970. Nacimiento de Internet
Dentro del primer período de la historia de Internet podemos destacar los siguientes
acontecimientos:
• 1945: Publicación de la primera referencia a una red electrónica similar a Internet:

"Memex", citado en el artículo "As We May Think", de Vannevar Bush (director de la
Oficina de Investigación Científica y Desarrollo norteamericana).
• 1957: Durante la guerra fría, la Unión Soviética lanza el Sputnik, el primer satélite
artificial de comunicaciones. En respuesta a este hecho, Estados Unidos crea el AR-
PA16, en el seno del Departamento de Defensa estadounidense.
• 1961: Leonard Kleinrock (MIT) publica el primer artículo sobre la teoría de conmu-
tación de paquetes.
• 1962: Licklider (MIT) lanza la idea de la "Galactic Network", una red interconectada
globalmente a través de la que cualquiera podría acceder desde cualquier lugar a datos
y programas. Licklider fue el principal responsable del programa de investigación en
ordenadores en ARPA, la agencia de investigación avanzada del Pentágono.
• 1964: Paul Baran (RAND Corporation) realiza sus estudios sobre "Redes de comuni-
cación distribuidas o descentralizadas". También promueve el uso de redes de con-
mutación de paquetes de datos (Packet Switching Networks).
• 1961-1965: La idea de red de paquetes descentralizada había sido trabajada en para-

lelo por tres grupos de investigación americanos, sin que los investigadores conocie-
ran 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 interco-

nexión de computadores, que se llamó ARPANET y fue el antecesor de lo que después
se llamaría Internet.
• 1966: Se desarrolla el concepto de red de ordenadores, que se llamaría ARPANET. La

red ARPANET podía interconectar los diferentes ordenadores de los investigadores
que se fueran conectando a esta red, naciendo así el Backbone Network.
• 1967: La nueva red, denominada ARPANet, recibe la señal de salida. Un año más
tarde se diseñan los primeros programas y el primer hardware específico para redes.
• 1969: Hay cuatro centros interconectados a través de sus IMP (Internet embrionaria).
UCLA (Los Ángeles) es seleccionada para ser el primer nodo de ARPANET. El centro
de investigación de Standford (SRI) proporciona un segundo nodo. El tercer nodo en
la Universidad de California, Santa Bárbara, y el cuarto nodo en la Universidad de
Utah. Estos cuatro nodos constituyeron la red original de ARPANet.
(16)
ARPA es la abreviatura en inglés de la Agencia de Proyectos de Investigación Avanzada.
(17)
NPL es la abreviatura de National Physical Laboratories (institución del Reino Unido).
Pronto, las grandes empresas presionaron a las compañías telefónicas del mo- CCITT
mento para que desarrollaran redes pensadas para transportar datos, con un
El CCITT es un organismo in-
sistema de tarificación que se ajustara al tráfico de datos real y permitiera más ternacional patrocinado por las
velocidad que los escasos 300 o 1.200 bps que se alcanzaban en aquella épo- operadoras de telefonía, de-
dicado a tareas de normaliza-
ca utilizando la red telefónica. La respuesta fueron las redes de conmutación ción en el ámbito de las tele-
comunicaciones. El 1 de marzo
de paquetes. El envío de datos no se tiene que hacer necesariamente en tiem- de 1993 pasó a llamarse Inter-
po real (las transmisiones de voz, sí). Por lo tanto, no hace falta establecer el national Telecommunication
Union Standardization Sector
camino entre los dos puntos antes de empezar la transmisión y mantenerlo (ITU-T).
mientras dura el intercambio de datos. En lugar de eso, se empaquetan los bits

que se tienen que transmitir y se dan a la central más próxima para que los
envíe cuando pueda a la siguiente, y así sucesivamente, hasta que lleguen a
su destino. Si cuando llega un paquete a una central todos los enlaces con la
siguiente están ocupados, no pasa nada, se le hace esperar poniéndolo en una
cola para enviarlo cuando haya un enlace disponible.
Nodos en ARPANET en 1971
La transmisión por paquetes tiene la ventaja de que sólo ocupa los recursos
cuando realmente se utilizan, no todo el tiempo. Pero, como contrapartida,
se tiene que soportar el retardo que pueda haber desde que los paquetes salen
del origen hasta que llegan a su destino, y que es variable, porque las esperas
en las colas son aleatorias, dependen del estado de la red. Pero, como hemos
dicho, eso, en comunicación de datos, es hasta cierto punto tolerable. Con
respecto a la cuestión económica, no tiene sentido que se cobre por tiempo de
conexión: en las redes de datos se paga por bits transmitidos.
Hay otro peligro: los paquetes se pueden perder. Hay que tener presente que CERT
las colas son limitadas y, si una cola ya está llena cuando llega un paquete, éste
El Computer Emergency Res-
no se podrá guardar y se perderá. Hay que prever mecanismos que eviten estas ponse Team (CERT) es un
pérdidas y regulen el flujo de información entre los nodos de conmutación. equipo de respuesta de emer-
gencia de ordenadores que
mantiene datos sobre todas las
incidencias en red y sobre las
Las compañías telefónicas desarrollaron redes de este tipo, y el CCITT emitió principales amenazas.
un estándar, el X.25, que ha sido en definitiva el que ha adoptado todo el
mundo hasta hace poco.
Segundo período: 1970-1990. Del Ejército a la Universidad
Dentro del segundo período de la historia de Internet podemos destacar los siguientes
acontecimientos:
• Años�1970. Durante este período, la red fue de acceso restringido a los investigadores
y a las empresas privadas que participaban en proyectos financiados por la Adminis-
tración.
• 1970. El Network Working Group (NWG), liderado por S. Crocker, acabó el protocolo
ordenador principal a ordenador principal inicial para ARPANET, denominado Net-
work Control Protocol (NCP, protocolo de control de red). Kevin MacKenzie inventa
el primer emoticón: :-). Vinton Cerf escribe por primera vez la palabra Internet. Está
considerado el padre de la red. Más tarde diseñó el protocolo TCP/IP, que actualmente
rige las comunicaciones por Internet.
• 1971. Ray Tomlison (BBN18) crea los protocolos básicos del correo (e-mail), incluida
la convención de la arroba para separar el nombre de la persona del identificador del
ordenador.
• 1972. Se presenta públicamente ARPANET en la International Computer Communi-

cation Conference. Investigadores del MIT dieron a luz el germen de lo que sería el
sistema de transferencia de archivos FTP y telnet. El Sistema de Agencias de Infor-
mación de Defensa crea la IANA o Autoridad de asignación de números de Internet,
responsable de asignar una dirección única a cada computador conectado a Internet.
• 1973. Vint Cerf y Bob Kahn especifican la primera versión del programa de control
de transmisión (TCP), que se desarrolló después hasta convertirlo en el Transmission
Control Protocol/Internet Protocol (TCP/IP), los protocolos que actualmente permi-
ten el funcionamiento de Internet. Berkeley desarrolló el BSD UNIX. ARPA dio una
copia de TCP/IP a Berkeley y se incorporó este software a la versión UNIX. Nace la
posibilidad de realizar un FTP.
• 1979. Nace Usenet. Creada por tres estudiantes, Tom Truscott, Jim Ellis y Steve Bello-
vin. Usenet es un servicio de grupos de noticias, las populares "news".
• 1980. Aparecen las primeras aplicaciones TCP/IP. Internet ya tiene 212 servidores.
• 1981. El año 1981, IBM lanza el primer PC, con el sistema operativo de una pyme
denominada Microsoft.
• 1982. ARPANet adopta el protocolo TCP/IP como estándar. Se crea la EuNet (Euro-
pean Unix Network). La European Unix Network (EuNet), conectada a ARPANet, se
creó en 1982 para proporcionar servicios de correo electrónico y servicios Usenet a
diversas organizaciones usuarias en los Países Bajos, Dinamarca, Suecia e Inglaterra.
• 1983. Considerado como el año en que nació realmente Internet al separarse la parte
militar y la civil de la red. Hasta el 1 de enero de 1983, la incipiente Internet estuvo
funcionando con un antecesor de los protocolos TCP/IP; aquel día, los ya miles de
ordenadores conectados se cambiaron al nuevo sistema. Internet ya dispone de 562
servidores (ordenadores interconectados). El mismo año se creó el sistema de nom-
bres de dominios (.com, .edu, etc., más las siglas de los países), que prácticamente se
ha mantenido hasta ahora.
• 1984. El ordenador pasa a estar al alcance de la gente, y su implantación se acelera

cuando se presenta el Macintosh. El número de servidores conectados a la red ha-
bía superado ya los 1.000. Al año siguiente se forjaba Well, la primera comunidad
comercial de usuarios. Se crea en Wisconsin el primer name server, con lo que ya no
se necesita conocer el path de localización de un computador, precursor del servicio
DNS de Internet.
• 1985. Entra en funcionamiento el Domain Name Server (DNS), un método para re-
solver nombres en direcciones numéricas. El primer dominio se otorga el 15 de mar-
zo a Symbolics.com. Internet ya tiene 1.961 servidores y los sufijos .com, .net y .org
añadidos. En abril aparecen los primeros dominios con letra, que fueron acmu.edu,
purdue.edu, rice.edu y ucla.edu, todos ellos todavía en activo sin duda, y todos uni-
versitarios, también sin duda. En junio del mismo año aparece el primer dominio
gubernamental, css.gov, y en julio, mitre.org. El primer dominio de un país se atri-
buyó en julio de aquel mismo año a Gran Bretaña: co.uk. En España, los ordenadores
de diferentes universidades se conectaban entre sí y con el Centro Europeo de Físi-
ca de Partículas (CERN). El Ministerio de Educación y Ciencia, a través de la Secre-
taría de Universidades, elaboró un plan para interconectar los centros de cálculo de
las universidades. Asimismo, un grupo de expertos de las universidades, centros de
cálculo, organismos públicos de investigación y Telefónica, bajo la coordinación de
Fundesco, realizó un informe que se llamó Proyecto IRIS (Interconexión de Recursos
Informáticos).
• 1987. Nace la primera versión de Windows. Hay más de 10.000 servidores en todo
el mundo.
• 1988. Se produce el primer gran ataque vírico de Internet, cuando el "gusano de Mo-
rris" 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 or-
denador. A raíz del "gusano de Morris" se crea el Computer Emergency Response Team
(CERT). Jarkko Oikarinen, un joven finlandés, decide modificar el comando talk del
Unix para permitir que diversas personas puedan charlar de forma simultánea. Así
nace el chat, el Internet Relay Chat (IRC), que permite que se pueda conversar en
línea en la red. En 1988 nace el programa IRIS dentro del Plan Nacional de Investiga-
ciones y Desarrollo Tecnológico para dar conectividad a científicos e investigadores.
La financiación y supervisión de esta red correría a cargo de la Comisión Interminis-
terial de Ciencia y Tecnología, y de su gestión y dirección se encargaría Fundesco.
• 1989. Nace RIPE para interconectar las redes europeas. El número de servidores co-
nectados a Internet alcanza ya los 100.000. Este mismo año, se inaugura también la
primera conexión de un sistema de correo electrónico comercial en Internet (MCI y
Compuserve). Nace Archie. Hasta aquel momento nadie se había planteado nunca la
hipótesis de que en Internet las cosas pudieran tener un orden, ni de crear un direc-
torio. Las direcciones eran tan pocas que se suponía que todo el mundo las conocía.
Por este motivo, se crea el primer catálogo (un programa denominado Archie). Archie
tuvo tal éxito que colapsó el tráfico en Estados Unidos y Canadá en cuanto se tuvo
noticia de su existencia. Por este motivo, la Universidad MacGill de Montreal obligó
a su autor a cerrarlo. Por suerte, lo hizo después de que Archie ya estuviera replicado
en otros ordenadores. Archie fue el precedente de Gopher y Veronica y, de alguna
remota manera, el primer intento de directorio de recursos de Internet.
(18)
BBN es la abreviatura de la empresa Bolt, Beranek and Newman.
Cuando empezó a ser habitual disponer de más de un ordenador en la misma

instalación, apareció la necesidad de interconectarlos para poder compartir los
diferentes recursos: dispositivos caros, como impresoras de calidad, un disco
duro que almacenara los datos de la empresa, un equipo de cinta para hacer
copias de seguridad, etc.
El diseño de las redes de área local siguió caminos completamente diferentes

de los que se utilizaron para las redes de gran alcance. En las redes de área local
se necesita, habitualmente, establecer comunicaciones "de muchos a uno" y
"de uno a muchos", cosa difícil de conseguir con las redes de conmutación,
pensadas para interconectar dos estaciones. Para este tipo de redes es más ade-
cuada la difusión con medio compartido, en la que los paquetes que salen de
una estación llegan a todo el resto simultáneamente. En la recepción, las esta-
ciones los aceptan o ignoran según que sean sus destinatarias o no.
Se habla de difusión porque los paquetes se difunden por todas partes, y de

medio compartido porque esta difusión se hace sobre un medio común que
las estaciones comparten.
De la década de los sesenta son también los primeros estándares de arquitec-

turas de protocolos. Hay que tener presente que el intercambio de informa-
ción entre ordenadores tiene toda una serie de implicaciones, entre las que se
incluyen las siguientes:
• Aspectos eléctricos: los cables, los conectores, las señales, etc.
• La manera de agrupar los bits para formar paquetes y la de controlar que

no se produzcan errores de transmisión.
• La identificación de los ordenadores dentro de la red y la manera de con-

seguir que la información que cualquier ordenador genera llegue a quien
se pretende que la reciba.
Abordar todos estos aspectos de una manera global resulta inviable: demasia-
das cosas demasiado diferentes entre sí. Por eso, ya desde el principio, se desa-
rrollaron modelos estructurados en niveles: en cada nivel se lleva a cabo una
tarea, y la cooperación de todos los niveles proporciona la conectividad que-
rida por los usuarios.
Hay que tener presente que, en la época que nos ocupa, la informática estaba
en manos de muy pocos fabricantes e imperaba la filosofía del servicio inte-
gral: cada fabricante lo proporcionaba todo (ordenadores, cables, periféricos,
sistema operativo y software). Por lo tanto, cuando una empresa se quería in-
formatizar, escogía una marca y quedaba ligada a ella para toda vida.
En la década de los setenta, el panorama cambió radicalmente, sobre todo a

causa de tres acontecimientos:
• La propuesta del protocolo Ethernet para redes locales.
• La aparición del sistema operativo Unix, no ligado a ninguna marca co-

mercial, compatible con todas las plataformas de hardware que había.
• La invención de los protocolos TCP/IP, embrión de la actual Internet.
Se había allanado el camino para la aparición de los sistemas abiertos: no ha-

bía que atarse a ninguna marca para tenerlo todo. El hardware podía ser de
un proveedor, el sistema operativo de otro, las aplicaciones de otro y los pro-
tocolos, públicos.
Tercer período: 1990-1995. Expansión fuera de los ámbitos militar y

universitario
Dentro del tercer período de la historia de Internet podemos destacar los siguientes acon-
tecimientos:
En la parte superior de la imagen se puede
• 1990. Nacen el primer proveedor de acceso a Internet comercial y el Electronic Fron- ver el primer banner de Internet en HotWired
tiers Foundation (EFF), una ONG de defensa de ciberderechos. La red tiene ya cente- (1994).
nares de miles de servidores (313.000). Este año también aparece Windows 3.0. En
España, Fundesco cambia el nombre del programa IRIS por REDIRIS y se conecta al
backbone de Internet (NSFNET19), al lado de Argentina, Brasil, Chile, India, Suiza,
Austria, Irlanda y Corea del Sur.
• 1991. Tim Berners-Lee, investigador en el centro europeo CERN, en Suiza, elaboró

su propuesta de un sistema de hipertexto compartido: era el primer esbozo de la
World Wide Web. Como el ARPANet veinte años atrás, su propósito era poner en
comunicación a los científicos. La WWW es una creación europea fruto del trabajo de
Tim Berners-Lee y Robert Cailauu. Su objetivo era buscar una herramienta de trabajo
para crear y leer textos a través de una red que permitiera intercomunicar a los físicos
de todo el mundo. Berners-Lee creó el HTML, el HTTP y las URL.
• 1992. Nace la Internet Society, la "autoridad" de la red. Surgía como el lugar donde
pactar los protocolos que harían posible la comunicación. El Internet Activities Board
(IAB) se integra en la Internet Society. En el IAB destacó la Internet Engineering Task
Force (IETF), que tenía como función el desarrollo de Internet a corto plazo y la res-
ponsabilidad de la dirección técnica. La mayor parte de los Request For Comments
(RFC) se elaboran en el IETF, y éstos iban aumentando cada año. Internet ya tiene
1.136.000 servidores. En España aparece Goya Servicios Telemáticos, primer provee-
dor de acceso comercial.
• 1993. Aparece el primer visualizador gráfico de páginas web: Mosaic, el antecesor de

Netscape. Hasta aquel momento la red era sólo texto: ahora sobre un fondo gris apa-
recen documentos con gráficos y enlaces en azul. El crecimiento de Internet supera
el 350.000% (casi dos millones de ordenadores). Marc Andreeseen, cocreador de Mo-
saic, funda Netscape junto con el veterano ejecutivo de Silicon Valley Jim Clarke. En
septiembre, la Universidad Juan Carlos I de Castellón publica el primer servidor web
de España, donde ya había 10 nodos y 15.000 máquinas bajo el dominio .es.
• 1994. Año del primer spam: los abogados de Arizona Canter & Siegel lanzan el 5 de
marzo de 1994 un anuncio en 6.000 grupos de noticias, y son perseguidos por los
furiosos internautas, que consiguen que los expulsen de su ISP (y de la abogacía). En
octubre, ATT y Zima (una marca de refrescos) ponen los primeros banners comerciales
de la historia en Hotwired. Pero no todo son desgracias: también se abren el primer
centro comercial, la primera radio y el primer banco en la red. El número de servidores
de Internet alcanza los 3.800.000. En la Universidad de Stanford dos estudiantes crean
un directorio de cosas interesantes de la red, al que bautizan Yahoo! Lycos. Se difunde
la versión comercial del navegador Netscape Navigator. En España nace Servicom.
• 1995. Se empiezan a cobrar los dominios. Sun crea Java, y RealAudio incorpora so-
nido en la Red. Microsoft lanza con gran publicidad Windows 95 y anuncia un giro
estratégico hacia Internet. El fabricante Digital (DEC) crea AltaVista, un buscador de
Internet. Nacen la librería Amazon.com y el sitio de subastas eBay. Hay más de 5 mi-
llones de servidores conectados a Internet. La espina dorsal de NSFNET empieza a ser
sustituida por proveedores comerciales interconectados. Salida a bolsa de Netscape,
la tercera major hasta entonces, que marca el comienzo del boom de Internet.
(19)
Las siglas NSFNET corresponden a National Science Foundation Network.
(20)
TCP/IP nació a partir de un encargo de la Defense Advanced Research Project En castellano, Agencia de Pro-
20 yectos de Investigación Avanzada
Agency (DARPA) a la comunidad científica americana para tener una red para la Defensa.
mundial que fuera reconfigurable fácil y automáticamente en caso de destruc-
(21)
ción de algún nodo o algún enlace. ISO son las siglas de la Interna-
tional Organization for Standardi-
zation, en castellano, Organización
La pila TCP/IP es una jerarquía de protocolos que ofrecía conectividad y, a pe- Internacional de Estandarización.
sar de tener poco que ver con las que ya había, era una opción más en el mer-
cado. Ante una oferta tan grande, y dispar, de protocolos, la ISO21 y el CCITT
propusieron un modelo nuevo que intentaba reunir de alguna manera todo
lo que ya se había propuesto y que pretendía ser completo, racional y muy
bien estructurado (la TCP/IP tiene fama de ser una pila de protocolos anár-
quica), con la intención, por lo tanto, de que se convirtiera en un modelo de
referencia. Es la llamada pila de protocolos OSI (open systems interconnection).
Internet, que nació y creció en las universidades, se empezó a hacer popular
en la década de los noventa, a medida que los que conocían la red la iban "en-
señando", y su popularización estalló cuando saltó al mundo de la empresa,
en todas sus vertientes: como escaparate de productos o como canalizador de
contactos comerciales.
Tim Berners Lee. Creador de la WWW
Su origen universitario, sin embargo, ha marcado esta evolución en muchos

sentidos. Por ejemplo, el modelo cliente/servidor de aplicaciones distribuidas.
Es un modelo sencillo y al mismo tiempo potente, y casi todas las aplicacio-
nes que se hacen servir en Internet lo siguen. El Telnet, o apertura de sesión
remota, la transferencia de ficheros (FTP), el correo electrónico y, sobre todo,
la WWW (World Wide Web) son ejemplos claros de aplicaciones que siguen
este modelo. Las dos primeras han caído en desuso un poco, pero tanto el
correo como la WWW son las estrellas hoy en día en Internet. Tímidamente,
aparecen nuevas propuestas de aplicaciones, pero la WWW, que nació como
un servicio de páginas estáticas enlazadas con hiperenlaces, se está convirtien-
do en la interfaz de usuario de toda la red, porque actualmente se utiliza para
servir páginas dinámicas (se crean en el momento en que se sirven), e incluso,
como código que se ejecuta en el ordenador cliente (applets).
En este momento tenemos dos redes completamente independientes entre sí,

pero de alguna manera superpuestas:
• Una red analógica, con conmutación de circuitos, pensada para voz.

• Una red digital, con conmutación de paquetes, pensada para datos.
La red telefónica, tal como la hemos descrito hasta ahora, es completamente

analógica: la señal electromagnética que viaja desde un teléfono hasta otro es
analógica (varía continuamente y en cada momento puede tomar cualquier
valor) y los circuitos electrónicos que componen la red también lo son.
Los enlaces entre centrales de la red telefónica se hacían con señales analógi-
cas con muchos canales multiplexados en frecuencia, y tenían que recorrer,
a veces, grandes distancias. La atenuación de la señal inherente a la distancia
que había que recorrer se tenía que corregir mediante repetidores que la am-
plificaran, cosa que aumentaba el ruido presente en la línea. Muy a menudo, la
señal recibida era de una calidad muy baja porque la transmisión analógica no
permite eliminar el ruido ni las interferencias en la recepción. No hay ninguna
manera de saber exactamente qué se ha enviado desde el origen y qué es ruido
añadido. En 1972 se hicieron públicos los primeros resultados del tratamiento
digital de la señal aplicada a audio, básicamente orientado a su almacenaje. El
CD estaba viendo la luz. Convertir un sonido (una magnitud física que puede
tomar cualquier valor en cualquier momento) en una serie de 0 y 1 (dos únicos
valores conocidos) permitía corregir fácilmente cualquier ruido añadido.
El descubrimiento del procesamiento digital de la señal, y sus aplicaciones en

los campos del sonido y la imagen, ha sido un hito primordial en el mundo
de las comunicaciones. Básicamente, ha permitido reducir drásticamente el
efecto del ruido, lo cual ha permitido, por una parte, incrementar la calidad
de recepción de las señales y, por otra, aumentar la velocidad de transmisión
con los mismos medios.
Las compañías telefónicas empezaron a sustituir los enlaces internos (entre

centrales) por señales digitales, pero manteniendo el bucle de abonado (línea
y terminal) analógico. La digitalización de la señal de sonido se hace dentro
de la central local, después del filtro de 4 kHz, y se vuelve a pasar a analógico
en la central correspondiente en el otro extremo de la comunicación. Eso ha
hecho cambiar sustancialmente los procesos de conmutación: ahora se tiene

que trabajar con bits y, por lo tanto, las centrales electromecánicas se tienen
que sustituir por ordenadores.
Esta digitalización de la parte interna de la red de voz hizo que confluyeran de

alguna manera las dos redes, la telefónica y la de datos: los enlaces digitales
entre centrales se utilizaban indistintamente para paquetes de datos y para
transmisiones de voz.
Cuarto período: 1996-Actualidad. Multimedia y cientos de millones de

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

servidores en la red. En España se crea ESPANIX para intercambiar tráfico local; a
finales de año hay 500 proveedores y un millón de internautas, gracias a Infovía.
• 1998. Microsoft, con su Explorer, tiene más del 80% de los navegadores, y es deman-
dado por abuso de posición dominante. La red tiene 300 millones de páginas. Nace
Google y AOL compra Netscape. Se registra el dominio comercial dos millones. El
Gobierno estadounidense anuncia un plan para privatizar Internet que es rechazado;
un segundo plan es mejor recibido.
• 1999. Nace Napster, el primer programa de intercambio de ficheros (P2P). En España,

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

Bowl de fútbol americano, a mediados de enero, se anuncian 17 compañías "punto-
com", que pagan 2 millones de dólares por 30 segundos de anuncio cada una. En
marzo, el índice NASDAQ alcanza su pico histórico: 5.048 puntos; durante el verano
se inicia una larga caída. Terra compra Lycos por 12.500 millones de dólares, y al
lado de Telefónica empieza a ofrecer ADSL. Los operadores de cable empiezan a pres-
tar servicio de banda ancha doméstica en España. La tienda de ropa Boo.com bate
récords, con una facturación en seis meses de 160 millones de dólares. Microsoft es
condenado por abusar de su cuasi-monopolio en sistemas operativos. Se calcula que
la web supera los 1.000 millones de páginas.
• 2001. Arranca con el pleito abierto de nuevo por las discográficas contra Napster por
favorecer la piratería, pleito que acaba por provocar su cierre en julio por orden ju-
dicial (y su resurrección como servicio de pago). En febrero, Napster había batido su
propio récord, con 13,6 millones de usuarios. Napster cierra en julio por orden judi-
cial (volverá a salir como servicio de pago). America Online compra en enero Time
Warner, el mayor grupo mediático del mundo, en lo que se considera el definitivo
triunfo de los nuevos medios sobre los viejos. La empresa Kozmo de venta por Inter-
net con entrega rápida quiebra en abril. Su competidora Webvan sufre igual suerte.
En mayo se lanza el programa SETI@Home, el primer gran proyecto de computación
distribuida; en menos de un mes proporciona más potencia de cálculo que el mayor
superordenador disponible entonces.
• 2002. La crisis de las puntocom continúa profundizándose. Los dominios son noticia,
con la apertura de tres nuevos dominios de máximo nivel (.name para personas, .coop
para cooperativas y .aero para empresas aeronáuticas) que no tendrán mucho éxito.
En octubre, un ataque concertado consigue desconectar a 8 de los 13 ordenadores de
los que depende todo el sistema de dominios, lo cual acelera los planes para reforzarlo.
Explosión en el uso de los weblog o blogger: páginas escritas por los cibernautas en
las que éstos explican anécdotas de sus propias vidas y dan a conocer sus opiniones.
Lo que queda de Napster es adquirido por el conglomerado alemán Bertelsmann.
• 2003. Año de la música. La patronal musical de Estados Unidos (RIAA) denuncia

por primera vez a usuarios finales por intercambiar música en redes P2P. Apple lanza
su tienda de música iTunes, asociada al reproductor iPod. Después de dos años de
continua caída del valor AOL Time, Warner elimina el "AOL" de su nombre. WiFi
se consolida como alternativa de acceso sin hilo. Diversas plagas ensucian Internet;
desde Slammer, que se extendió en 10 minutos echando abajo a 8 servidores raíz y
afectando a bancos y el tráfico aéreo, hasta SobigF y Blaster. Después de una cierta
parada entre 2001 y 2002, se recupera el vigoroso ritmo de crecimiento del número
de servidores en la red. Este año también empieza el ataque judicial de SCO contra
Linux.
• 2004. Empieza la recuperación. Sale a bolsa Google, que lanza su correo web de 1 Gb
Gmail. Guerra de buscadores: Yahoo! abandona a Google y compra diversas empre-
sas, Microsoft potencia MSN Search y Amazon lanza A9. La música de pago también
se caldea, con la entrada de Wal-Mart, Sony, Virgin, eBay y Microsoft; iTunes tiene el
70% del mercado. El navegador Firefox v1.0 hace mella en el dominio del Explorer
de Microsoft, al que arranca un 5%. En Estados Unidos, la banda ancha supera a los
módems y la campaña de las presidenciales demuestra el poder de los blogs llamados
"Rathergate"; el precandidato Howard Dean usa la red para la movilización del elec-
torado y la recaudación de fondos. En España Terra vende Lycos por 105 millones de
dólares. El copyleft avanza con la extensión de las licencias Creative Commons.
• 2005. Existen más servidores raíz fuera de Estados Unidos que en su territorio. La red
tiene más de 300 millones de ordenadores principales, casi 60 millones de dominios
activos, más de 4.000 millones de páginas web indexadas por Google y más de 900
millones de internautas. Suecia tiene la penetración más alta (74% de la población),
y España ocupa el puesto 22 por accesos de banda ancha (casi 2,5 millones) y el 12
por número de internautas (14 millones), pero está por debajo de la media europea
en penetración. Diversos accidentes y ataques difunden información privada en la
red. Microsoft responde a Firefox con el lanzamiento de una versión no prevista del
Explorer. Apple presenta el iPod Shuffle, basado en memoria flash. El mercado de la
publicidad en línea se despierta, y diversos medios españoles relanzan sus páginas
web. A finales de este mismo año nace Youtube.
• 2006. Aparecen los principales exponentes de la revolución de la Web 2.0: Facebook

y GoogleEarth. El fenómeno de la red interactiva y dinámica empieza a extenderse.
Se empiezan a esbozar nuevas tendencias de computación distribuida. Aparece el
término cloud computing.
• 2007. Las plataformas de descarga de contenidos basados en tecnologías p2p agluti-

nan la mayoría del tráfico de la Red. XMPP se convierte en estándar de facto para las
comunicaciones de mensajería instantánea. Gmail deja de ser beta y se convierte en
accesible para todo el mundo. Writely, adquirido por Google el año anterior, es lla-
mado Google Docs. Nace Android como sistema operativo para dispositivos móviles.
• 2008. Auge en el acceso a Internet mediante dispositivos móviles. Amplia adopción

de la tecnología 3G. Quincuagésimo aniversario del nacimiento de la red. El Gobier-
no chino construye un sistema de filtraje y censura en la red para controlar los con-
tenidos que llegan a los usuarios del país asiático.
• 2009. Se esboza la Internet de las cosas. Aparece 6LowPan como iniciativa para pro-
veer de dirección IPv6 a las redes de sensores. Se extiende la oferta de servicios a la
Red. Auge del cloud computing.
• 2010. Facebook llega a los 400 millones de usuarios. Google es boicoteado en China.
Amazon EC2 y Google Application Engine se disputan el mercado del cloud. IBM se
desmarca de la competencia por el mercado cloud ofreciendo soluciones basadas en
escritorios remotos (eyeOS). Se empieza a hablar de redes cognitivas.
Una vez digitalizada la red telefónica, el paso siguiente tenía que ser llevar la
transmisión de bits hasta las casas. Eso permitía, por una parte, ofrecer a los
usuarios en su casa la transmisión de datos además de la tradicional de voz
y, por otra, ofrecer a los abonados un abanico de nuevos servicios asociados
a una comunicación enteramente digital de punta a punta. Este servicio de
transmisión digital mediante la red telefónica se conoce como red digital de
servicios integrados (RDSI). Ofrece dos canales independientes de 64 kbps, que
permiten hablar y conectarse a Internet simultáneamente, o, con un hardware
adecuado, aprovechar los dos canales juntos para navegar a 128 kbps.
El uso de la red telefónica para transmitir datos tiene una limitación impor- RDSI
tante por lo que respecta al máximo de bits por segundo permitidos, y las re-
La red digital de servicios inte-
des específicas de datos son muy caras para su uso doméstico. Desde la década grados (RDSI) corresponde a
de los noventa se han estudiado maneras de conseguir llevar hasta las casas las siglas ISDN (integrated ser-
vices digital network) en inglés.
o las empresas un buen caudal de bits por segundo (banda ancha) a un pre-
cio razonable, de manera que las nuevas aplicaciones multimedia se puedan
explotar al máximo. Para conseguir esta banda ancha, se han seguido dos ca-
minos 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 do-
minantes. Estas redes se aprovechan para dar un servicio integral: televisión,
teléfono y datos. Con respecto al segundo, las compañías telefónicas de toda
la vida han querido sacar partido del cableado que ya tienen hecho y, por eso,
han desarrollado las tecnologías ADSL, que permiten hacer convivir en el bu-
cle de abonado la señal telefónica y una señal de datos que puede llegar a los
8 Mbps (o 20 Mbps con tecnología ADSL+).
Resumen
El módulo ha introducido los conceptos fundamentales de las redes de com-

putadores. Hemos visto que éstas son una composición de sistemas hardware,
software y protocolos que permiten la comunicación entre dispositivos remo-
tos. Hemos visto las topologías más comunes de las redes de comunicación y
que éstas también se pueden clasificar por su alcance.
La arquitectura de las redes de computadores está estructurada en diferentes

niveles. Hemos visto que existe un modelo de referencia denominado OSI,
que define siete niveles de red. Los niveles más bajos se ocupan de los aspec-
tos físicos de la comunicación, desde la caracterización del medio a la codifi-
cación de la información transmitida. Las capas superiores usan las interfaces
de abstracción de sus capas subyacentes construyendo así un sistema comple-
jo que permite la transmisión estructurada de información entre dispositivos
remotos. La división en capas y las interfaces permiten la abstracción de las
funcionalidades de las capas subyacentes en las capas superiores permitiendo
así que las capas se puedan modificar y/o cambiar sin que ello afecte al com-
portamiento de la red. Los conceptos de interfaz y cabecera son clave para en-
tender la estructuración en capas de una red.
No obstante, hemos visto también que el modelo OSI es complejo y no ha

sido utilizado más que como modelo de referencia. En realidad, Internet usa
un modelo TCP/IP más simple pero funcional. El módulo ha presentado am-
bos modelos y los ha comparado. Finalmente, el módulo repasa la historia de
las comunicaciones. Conocer la historia nos ayuda a entender el porqué de
determinadas particularidades de las redes de comunicaciones actuales.
En los próximos módulos profundizaremos en el conocimiento de los niveles

de la red. En este curso hemos adoptado un enfoque top-down, es decir, desde
los niveles más próximos a la aplicación hasta los niveles más específicos del
hardware. Esta aproximación puede diferir de la de algunos otros documentos
de referencia, en los que las redes se presentan a la inversa, primero, conocien-
do los niveles físicos, y, finalmente, presentando los niveles de aplicación. El
módulo "Las capas de la red de computadores" presenta en detalle los niveles
de transporte, el nivel de red que es primordial, los principales conceptos de
los niveles de enlace de datos y físico, que, como veréis, están fuertemente
interrelacionados. El módulo "Seguridad en la red" adopta otro enfoque y nos
presenta aspectos relacionados con la seguridad de las redes de computadores,
hoy en día de primordial importancia. El módulo 4 nos presenta el nivel de
aplicación donde se profundiza en los conceptos fundamentales que rigen las
aplicaciones en Internet (el correo, la web, etc.). Finalmente, el módulo "Co-
municaciones inalámbricas" profundiza en el conocimiento de las comunica-

ciones sin hilos que se están convirtiendo en el eje principal de las tecnologías
de red actuales.
Bibliografía
Kurose, J.; Ross, K. (2005). Computer Networking: a top-down approach featuring the Internet
(5.ª ed.). Boston: Addison-Wesley Publishing Company.
Tanenbaum, A. S. (2003). Redes de computadores (4.ª ed.). Nueva York: Prentice-Hall Profes-
sional Technical Reference.
Las capas de
la red de
computadores
PID_00147723
© FUOC • PID_00147723 Las capas de la red de computadores
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. El nivel de transporte....................................................................... 7
1.1. Objetivos ...................................................................................... 7
1.2. Servicios ofrecidos por la capa de transporte ............................. 8
1.3. Relación entre la capa de transporte y la capa de red ................. 9
1.4. Transporte no orientado a la conexión: UDP ............................. 12
1.4.1. Cabecera UDP ................................................................ 12
1.4.2. Cabecera UDP ................................................................ 13
1.5. Transporte orientado a la conexión: TCP ................................... 14
1.5.1. Funcionamiento básico de TCP ..................................... 15
1.5.2. Cabecera TCP ................................................................. 16
1.5.3. Establecimiento de la conexión .................................... 19
2. El nivel de red.................................................................................... 21
2.1. Funcionalidades básicas: direccionamiento ................................ 21
2.2. Servicios de red ........................................................................... 24
2.2.1. Modelo de red en modo de circuitos virtuales .............. 25
2.2.2. Modelo de red en modo datagrama .............................. 26
2.2.3. Servicio de red orientado y no orientado a la
conexión ........................................................................ 27
2.3. Direccionamiento en Internet: el protocolo IP ........................... 27
2.3.1. IPv4 ................................................................................ 28
2.3.2. IPv6 ................................................................................ 42
2.4. 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
3. El enlace de datos y el control de acceso al medio.................... 54

3.1. Terminología y definiciones ....................................................... 55
3.2. Tipo de enlaces ........................................................................... 56
3.3. Tipo de servicios suministrado en la capa de red ....................... 56
3.4. Servicios proporcionados por la capa de enlace ......................... 57
3.5. Adaptadores y dispositivos de red .............................................. 58
4. El nivel físico...................................................................................... 60
4.1. Medios de transmisión ................................................................ 60
4.1.1. Par trenzado ................................................................... 60

4.1.2. Cable coaxial de banda base ......................................... 62
4.1.3. Fibra óptica .................................................................... 62
Resumen....................................................................................................... 64
Bibliografía................................................................................................. 65
© FUOC • PID_00147723 5 Las capas de la red de computadores
Introducción
En este módulo veremos en detalle las características y funcionamiento de los

diferentes niveles de la red. El objetivo del módulo es dar una visión general
del funcionamiento interno de una red de computadores, ya sea de área local,
ya a gran escala, como es Internet. La aproximación a los niveles de la red
será desde los niveles más próximos a las aplicaciones hasta los niveles más
específicos del hardware.
Como hemos visto en el módulo "Conceptos de redes de computadores", las

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

funcionamiento de una red de computadores.
Objetivos
El estudio de este módulo os tiene que permitir alcanzar los objetivos siguien-
tes:
1. Profundizar en el conocimiento de cada una de las capas de las redes de

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

1. El nivel de transporte
El nivel de transporte abstrae la complejidad de la red a las aplicaciones. En

este módulo, veremos su funcionamiento con detalle.
1.1. Objetivos
La capa de transporte se encarga de proveer comunicación extremo a extremo

entre procesos de aplicaciones ubicadas en diferentes hosts. Desde el punto de
vista de la aplicación, es como si los hosts estuvieran directamente conectados,
pero en realidad podrían estar en lugares opuestos del planeta, conectados
mediante múltiples routers y tipo de enlaces diferentes. La capa de transporte
ofrece las funcionalidades básicas para alcanzar este nivel de comunicación
lógica, sin que las aplicaciones se tengan que preocupar de la infraestructura
de red subyacente.
Mensajes extremo a extremo
Los protocolos de la capa de transporte se implementan en los dispositivos

extremos de la red y no en los routers ni en los dispositivos intermedios. La
información transmitida por las aplicaciones es convertida en paquetes de la
capa de transporte, conocidos como segmentos�de�la�capa�de�transporte. Los
segmentos de la capa de transporte se construyen dividiendo la información
que quiere transmitir la aplicación en segmentos de un tamaño determinado,
a los que se añade una cabecera. Cada segmento se envía a la capa de red don-
de 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 pa-
sando por diferentes dispositivos que únicamente examinarán la información
correspondiente a la capa de red. Sólo los receptores, al recibir el datagrama
en la capa de red, extraerán el segmento de transporte y lo pasarán a la capa
de transporte del receptor. La capa de transporte procesará el segmento y lo
pasará a la aplicación correspondiente.
En este módulo estudiaremos con detalle los protocolos y funcionalidades de

la capa de transporte de datos, haciendo énfasis en los protocolos de transpor-
te de datos de Internet, User Datagram Protocol (UDP) y Transmission Con-
trol Protocol (TCP), que ofrecen servicios diferentes a las aplicaciones que los
invocan.
La jerarquía TCP/IP
1.2. Servicios ofrecidos por la capa de transporte
La capa de transporte ofrece las siguientes funcionalidades:
• Garantiza la transmisión sin errores, extremo a extremo, independiente-

mente del tipo de red.
• Controla la transmisión extremo a extremo.
• Es responsable del control de flujo de los datos y del control de congestión

de la red.
• Es responsable de establecer, mantener y finalizar las conexiones entre dos

hosts o un host y un servidor en una red.
• Asegura que los datos lleguen sin pérdidas, sin errores y sin ser duplicadas.
• Ordena los paquetes que llegan.

• Se encarga de fragmentar los mensajes y recomponerlos en destino cuando

es necesario.
• Permite la multiplexación de diversas conexiones de transporte sobre una

misma conexión de red.
1.3. Relación entre la capa de transporte y la capa de red
La capa de transporte se ubica justo por encima de la capa de red en

la pila de protocolos. Mientras que la capa de transporte se encarga de
proveer comunicación lógica entre procesos que se ejecutan en hosts
diferentes, la capa de red provee comunicación lógica entre hosts. Esta
diferencia es sustancial, pues la capa de transporte tiene que permitir
que múltiples procesos se comuniquen de forma lógica haciendo uso
de una única conexión lógica provista por la capa de red. Este concepto
se llama multiplexación y demultiplexación de la capa de transporte.
Además, la capa de red no da garantías de entrega de la información, no ga-

rantiza la entrega de los segmentos, ni tampoco garantiza la integridad de la
información contenida en el segmento. Por esta razón, la capa de red no�es
confiable. La misión, pues, de la capa de transporte consiste por una parte en
proveer la transmisión de datos fiable y permitir la comunicación proceso a
proceso en una red creada comunicando host a host.
Para introducir los protocolos del nivel de transporte, nos centramos en la je-
rarquía de protocolos Transmission Control Protocol/Internet Protocol (TCP/
IP). En esta jerarquía se definen dos protocolos de transporte: el UDP y el TCP.
El UDP no está orientado a la conexión, lo que quiere decir que no implementa

fases de establecimiento de la conexión, envío de datos y fin de la conexión,
mientras que el TCP está orientado a la conexión.
En el caso de la jerarquía TCP/IP, se definen dos direcciones que relacionan el

nivel de transporte con los niveles superior e inferior:
• La dirección�IP es la dirección que identifica un subsistema dentro de una

red.
• El puerto identifica la aplicación que requiere la comunicación.
Para identificar las diferentes aplicaciones, los protocolos TCP/IP marcan cada
paquete (o unidad de información) con un identificador de 16 bits llamado
puerto.
• Puertos� conocidos. Están regulados por la Internet Assigned Numbers

Authority (IANA). Ocupan el rango inferior a 1.024 y son utilizados para
acceder a servicios ofrecidos por servidores.
• Puertos�efímeros. Son asignados de forma dinámica por los clientes den-

tro de un rango específico por encima de 1.023. Identifican el proceso del
cliente sólo mientras dura la conexión.
0-255 (IANA) Aplicaciones públicas.
255-1.023(IANA) Asignados a empresas con aplicaciones comerciales.
> 1.023 No están registrados (efímeros).
Puerto de aplicaciones públicas establecidas por IANA
Decimal Palabra clave Descripción
0 Reservado
1-4 No asignado
5 RJE Entrada remota de tareas
7 ECHO Eco
9 DISCARD Descartar
11 USERS Usuarios activos
13 DAYTIME De día
15 NETSTAT Quién está conectado o NETSTAT
17 QUOTE Cita del día
19 CHARGEN Generador de caracteres
20 FTP-DATA Protocolo de transferencia de archivos (datos)
21 FTP Protocolo de transferencia de archivos
23 TELNET Conexión de terminal
25 SMTP Protocolo SMTP (simple mail transfer protocol)
37 TIME Hora
39 RLP Protocolo de ubicación de recursos
42 NAMESERVER Servidor de nombre de anfitrión
43 NICNAME Quién es
53 DOMAIN Servidor de denominación
67 BOOTPS Servidor de protocolo de arranque
68 BOOTPC Cliente del protocolo de arranque
69 TFTP Protocolo trivial de transferencia de archivos

Decimal Palabra clave Descripción
75 Cualquier servicio privado de conexión telefónica
77 Cualquier servicio RJE privado
79 FINGER Finger
80 HTTP Protocolo de transferencia de hipertexto
95 SUPDUP Protocolo SUPDUP
101 HOSTNAME Servidor de nombre de anfitrión NIC
102 ISO-TSAP ISO-TSAP
113 AUTH Servicio de autenticación
117 UUCP-PATH Servicio de ruta UUCP
123 NTP Protocolo de tiempo de red
137 NetBIOS Servicio de nombres
139 NetBIOS Servicio de datagramas
143 IMAP Interim mail access protocol
150 NetBIOS Servicio de sesión
156 SQL Servidor SQL
161 SNMP Simple network management protocol
179 BGP Border gateway protocol
190 GACP Gateway access control protocol
194 IRC Internet relay chat
197 DLS Servicio de localización de directorios
224-241 No asignado
242-255 No asignado
Puertos usados por algunos de los protocolos de nivel aplicación

Actividad
¿Conocéis aplicaciones comerciales o de software libre que utilicen un puerto determi-

nado? ¿Qué puertos utilizan Skype, Emule, BitTorrent, MSN?
1.4. Transporte no orientado a la conexión: UDP
El User Datagram Protocol (UDP) es un protocolo no orientado a la co-

nexión, de manera que no proporciona ningún tipo de control de erro-
res ni de flujo, aunque utiliza mecanismos de detección de errores. En
caso de detectar un error, el UDP no entrega el datagrama a la aplica-
ción, sino que lo descarta.
Hay que recordar que, por debajo, el UDP está utilizando el IP, que también
es un protocolo no orientado a la conexión, y que, básicamente, lo que ofrece
UDP, en comparación con IP, es la posibilidad de multiplexar conexiones de
procesos sobre una misma conexión de red.
La simplicidad del UDP hace que sea ideal para aplicaciones que requieren
pocos retardos (por ejemplo, aplicaciones en tiempo real o el DNS). El UDP
también es ideal para los sistemas que no pueden implementar un sistema tan
complejo como el TCP. UDP es útil en aplicaciones donde no importe la pér-
dida de paquetes, como telefonía o videoconferencia sobre TCP/IP, monitori-
zación de señales, etc. Estas aplicaciones no toleran retardos muy variables.
Si un datagrama llega más tarde del instante en que tendría que ser recibido,
entonces se descarta porque es inservible para la aplicación. Eso se traduce en
un ruido en el sonido o la imagen, que no impide la comunicación. La tabla
siguiente muestra algunas de las aplicaciones más comunes que hacen uso de
UDP.
Aplicaciones Puertos
TFTP 69
SNMP 161
DHCP - BOOTP 67/68
DNS 53
1.4.1. Cabecera UDP
La unidad de cabecera de UDP es el datagrama UDP.
• Cada escritura por parte de la aplicación provoca la creación de un data-

grama UDP. No hay segmentación.
• Cada datagrama UDP creado es encapsulado dentro de un datagrama IP

(nivel 3) para su transmisión.
1.4.2. Cabecera UDP
La cabecera del datagrama UDP está formada por 8 bytes. Tiene cuatro campos.
• Puertos�(fuente�y�destino): permiten identificar los procesos que se co-

munican.
(1)
• UDP�length: longitud total del datagrama UDP (payload UDP + 8). Es un Abreviatura de application pro-
gramming interface.
campo redundante, ya que IP lleva la longitud también. Como la longitud
máxima de un datagrama IP es de 65.335 bytes (16 bits de longitud de
datagrama):
– Longitud máxima de un datagrama UDP: 65.335 - 20 bytes = 65.315
bytes.
– Longitud mínima de un datagrama UDP: 8 bytes.
– Longitud de datos datagrama UDP: 65.315 - 8 bytes = 65.307 bytes.
– El tamaño de un datagrama UDP depende del sistema operativo. Casi

1
todas las API limitan la longitud de los datagramas UDP (lo mismo
para TCP) a la longitud máxima de los buffers de lectura y escritura de-
finidos por el sistema operativo (llamadas al sistema "read" y "write").
Se suele usar 8.192 bytes como tamaño máximo del datagrama UDP
(FreeBSD).
• UDP�checksum: detector de errores, cuyo objetivo consiste en comprobar Checksum

que nadie ha modificado el datagrama UDP y que éste llega a su destino
El checksum se calcula hacien-
correctamente. Si el checksum UDP es erróneo, se descarta el datagrama do el complemento a 1 de la
UDP y no se genera ningún tipo de mensaje hacia el origen. El checksum suma de todas las palabras de
16 bits que conforman el data-
se aplica conjuntamente a una pseudocabecera más la cabecera UDP más grama UDP.
el campo de datos. Esta pseudocabecera tiene 3 campos de la cabecera del
paquete IP que se envía. Cabe mencionar que el checksum del datagrama
IP sólo cubre la cabecera IP.
Ejemplo
Supongamos que tenemos el datagrama (descompuesto en 3 palabras de 16 bits):
0110011001100000
0101010101010101
1000111100001100
La suma de las dos primeras palabras de 16 bits es:
Añadiendo la tercera palabra obtenemos:
Ahora hacemos el complemento a 1 (cambiando 0 por 1) y obtenemos:
1011010100111101
Esta última palabra se añade también al datagrama UDP. En la recepción se hace la suma
de todas las palabras de 16 bits, que tiene que dar 1111111111111111.
1.5. Transporte orientado a la conexión: TCP
El Transmission Control Protocol (TCP) es un protocolo de nivel de transporte

que se usa en Internet para la transmisión fiable de información. Quizás sea el
protocolo más complejo e importante de la pila de protocolos de Internet.
Como hemos visto, el UDP no garantiza la entrega de la información que le

proporciona una aplicación. Tampoco reordena la información en el caso de
que llegue en un orden diferente del utilizado para transmitirla. Hay aplica-
ciones que no pueden tolerar estas limitaciones. Para superarlas, el nivel de
transporte proporciona TCP.
El TCP da fiabilidad a la aplicación, es decir, garantiza la entrega de toda

la información en el mismo orden en que ha sido transmitida por la
aplicación de origen. Para conseguir esta fiabilidad, el TCP proporciona
un servicio orientado a la conexión con un control de flujo y errores.
(2)
TCP es un protocolo ARQ2, extremo a extremo, orientado a la conexión (fases ARQ es la abreviatura de Auto-
matic Repeat-reQuest Protocol; en
de establecimiento de la conexión, envío de datos y cierre de la conexión) y castellano, protocolo de repetición
bidireccional (full duplex). La unidad de datos TCP es el "segmento TCP". TCP, de petición automática.
a diferencia de UDP, intenta generar segmentos de un tamaño óptimo que se

denomina Maximum Segment Size (MSS), generalmente el mayor posible para
minimizar el sobrecoste (overhead en inglés) de las cabeceras, sin que produzca
fragmentación en el nivel IP. Al igual que UDP, TCP utiliza multiplexación
mediante el uso de puertos, tal como hemos visto con anterioridad.
Proporciona fiabilidad mediante los siguientes controles:
• Control�de�errores. TCP es parecido al Go-Back-N pero no descarta seg-

mentos posteriores cuando llegan fuera de secuencia. Permite las retrans-
misiones selectivas.
• Control�de�flujo (ventana advertida). Sirve para adaptar la velocidad entre

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

cidad del emisor a los encaminadores intermedios de la red y evitar así que
se colapsen sus memorias intermedias y se puedan perder paquetes.
En transmisión, TCP se encarga de fragmentar los datos del nivel aplicación, y

les asigna un número de secuencia antes de enviar los fragmentos al nivel IP.
En recepción, como los segmentos pueden llegar fuera de orden, TCP los tiene
que reordenar antes de pasarlos a los niveles superiores.
1.5.1. Funcionamiento básico de TCP
En cada extremo, TCP mantiene una memoria intermedia de transmisión y

una de recepción. La aplicación utiliza los llamamientos al sistema operativo
read() y write() para leer y escribir en estas memorias intermedias. Cuando la
aplicación escribe la información que se tiene que enviar al emisor, TCP la
guarda en una memoria intermedia de transmisión. Cuando la memoria in-

termedia de Tx está llena, el llamamiento write() queda bloqueado hasta que
vuelva a haber espacio.
Cada vez que llegan segmentos de datos al receptor, el API read() los pasa al
nivel superior y se envían sus correspondientes confirmaciones. A medida que
los datos van siendo confirmados por el receptor, se van borrando de la me-
moria intermedia de transmisión y queda espacio libre para que la aplicación
siga escribiendo.
1.5.2. Cabecera TCP
La cabecera TCP está formada por los siguientes elementos:
• Source�Port / Destination�Port: puertos origen y destino que identifican

las aplicaciones.
• Sequence�Number: número de secuencia del segmento. Identifica el pri-

mer byte dentro de este segmento de la secuencia de bytes enviados hasta
aquel momento.
• Initial�Seq.�Number�(ISN): primer número de secuencia escogido por el

protocolo TCP.
• Seq� Number: será un número a partir de ISN. Por lo tanto, para saber
cuántos bytes llevamos enviados hay que hacer Seq. Number - ISN".
• Acknowledgment� Number: contiene el próximo número de secuencia

que el transmisor del ACK espera recibir, es decir, es "Seq. Number + 1" del
último byte recibido correctamente.
– TCP es FULL-DUPLEX: cada extremo mantiene un Seq. Number y un
Ack Number.
• Header�length: longitud total de la cabecera del segmento TCP en words

de 32 bits (igual que el campo header length de la cabecera IP).
– Tamaño mínimo de la cabecera TCP = 20 bytes (header length = 5).
– Tamaño máximo de la cabecera TCP = 60 bytes (header length = 15).
• Reserved: bits reservados para posibles ampliaciones del protocolo. Se po-

nen 0.
• Flags: hay 6 flags (bits) en la cabecera. Son válidos si están en 1.
• Urgente�(URG): indica que se utiliza el campo Urgent Pointer de la cabe-

cera TCP.
• Acknowledgement�(ACK): indica que se utiliza el campo Acknowledge-

ment Number. Válido para todos menos para el SYN inicial.
• Push�(PSH): indica que el receptor tiene que pasar los datos de la memo-
ria intermedia de recepción a los niveles superiores tan rápidamente co-
mo sea posible. Operación más rápida sin llenar la memoria intermedia.
La activación de este flag depende de la implementación. Las implemen-
taciones derivadas de BSD lo activan cuando la memoria intermedia de Tx
se queda vacía.
• Reset�(RST): se activa cuando se quiere abortar la conexión. Un ejemplo

es cuando se recibe un segmento de un cliente dirigido a un puerto donde
no hay ningún servidor escuchando. En este caso, TCP contesta con un
segmento con el flag de reset activado.
• Synchronize�(SYN): se utiliza en el establecimiento de la conexión, duran-

te la sincronización de los números de secuencia al inicio de la conexión.
• Finalize�(FINAL): se utiliza en la finalización de la conexión.
• Advertised�Window�Size: tamaño de la ventana advertida por el receptor

al transmisor (Sliding Window) para el control de flujo. La ventana máxi-
ma es de 65.535 bytes.
• TCP�Checksum: se utiliza para detectar errores en el segmento TCP, y para

tener una mayor certeza de que el segmento no ha llegado a un destino
equivocado.
• Igual que en UDP, el checksum TCP se aplica conjuntamente a una pseudo-

cabecera + la cabecera TCP + el campo de datos TCP. Esta pseudocabecera
tiene 3 campos de la cabecera IP y el tamaño del segmento TCP (cabecera
+ payload).
– La pseudocabecera sólo es para calcular el checksum: no se transmite
en el segmento TCP, ni se incluye en la longitud del paquete IP.
– El tamaño del segmento TCP no se pone en la cabecera TCP, sólo se
tiene en cuenta en el cálculo del checksum.
– A diferencia de UDP, en TCP el cálculo del checksum es obligatorio.
• Urgent�Pointer: Campo válido si flag URG = 1. Implementa un mecanismo

para indicar datos urgentes (es decir, que se tienen que atender lo más
pronto posible). Es un puntero en el Seq Number que indica la parte de
datos urgentes dentro del campo de datos. Los datos urgentes irán desde
el primer byte del segmento hasta el byte indicado por el Urgent Pointer.
Este flag se utiliza rara vez. Un ejemplo es cuando se teclea un control-C
(interrupción) desde la aplicación telnet.
• Options: TCP permite añadir opciones a la cabecera, pero, a diferencia de

IP, las opciones de TCP suelen utilizarse. Podemos destacar:
– Maximum�Segment�Size: se utiliza durante el establecimiento de la
conexión para sugerir el valor del MSS en el otro extremo MSS = MTU
red directamente conectada - IP Header - TCP Header (sin opciones).
Si la red es ethernet (MTU 1500), entonces MSS = 1460.
– Window�Scale�Factor: se utiliza durante el establecimiento de la co-
nexión para indicar que el valor de la ventana advertida se tiene que
multiplicar por este factor de escala. Eso permite advertir ventanas ma-
yores de 216.
– Timestamp: se utiliza en el cálculo del RTT.
– SACK: permite que TCP haga retransmisión selectiva (selective ack).

TCP utiliza el campo ACK para indicar hasta dónde se ha recibido co-
rrectamente. Con la opción SACK, el receptor puede indicar bloques
de segmentos que se han recibido correctamente más allá del segmen-
to confirmado por el ACK. De esta manera, el emisor puede escoger
mejor los segmentos que se tienen que retransmitir.
• Padding: bytes de relleno añadidos para que la cabecera tenga un múltiplo

de 32 bits.
Actividad
Asumimos que un extremo cliente TCP (emisor) ha escogido el 28.325 como número de
secuencia inicial (ISN), mientras que el extremo receptor TCP (servidor) ha escogido como
ISN el 12.555. ¿Qué indica un segmento cliente (emisor) TCP con número de secuencia
29.201, número ACK 12.655 y ventana 1.024?
Solución
El número de secuencia indica que el cliente ya ha transmitido desde el byte

28.325 hasta el byte 29.200 (875 bytes en total) y que en este segmento transmi-
tirá a partir del byte 29.201. El número ACK indicará al receptor que el emisor
ha recibido correctamente hasta el byte 12.654 y que espera recibir a partir del
12.655. La ventana indica al receptor que el cliente sólo puede aceptar 1.024 by-
tes antes de confirmarlos. Por lo tanto, el servidor TCP actualizará su ventana de
transmisión en 1.024.
1.5.3. Establecimiento de la conexión
TCP es un protocolo orientado a la conexión tal como hemos dicho con an-
terioridad. Eso implica que en todo proceso de comunicación habrá una fase
de establecimiento de la conexión donde emisor y receptor se sincronizan con
el fin de poder intercambiar datos. EN TCP se usa el algoritmo 3-Way Hands-
hake, que consiste en el intercambio de tres segmentos que no llevan datos
(sólo es la cabecera TCP):
1) El emisor envía un segmento SYN, con petición de conexión.
2) El receptor (servidor) devuelve un segmento SYN + ACK como respuesta.
3) El cliente responde con un segmento ACK que reconoce el SYN + ACK. Una
vez establecida la conexión se pasa a la fase de envío de datos.
De la misma manera que el establecimiento de la conexión, se hace necesario

un proceso de finalización de la conexión. El cierre de la conexión puede de-
berse a diversas causas:
• El cliente o el servidor cierra la conexión (LLS close()).

• Por alguna razón se envía un reset de la conexión (flag activo RST).
• Cierre a causa de una interrupción, un control∧D o un control∧C, etc.
La finalización también se hace por medio del envío de segmentos TCP. El

primer segmento de final puede enviarlo tanto el cliente como el servidor. El
cierre normal se produce a causa de un close() del cliente, lo que provoca el
intercambio de 3 o 4 segmentos TCP.
2. El nivel de red
La capa de red se encarga de proporcionar conectividad y ofrecer mecanismos

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

por tres grandes bloques:
1) el protocolo que describe la manera de enviar información,
2) el protocolo de direccionamiento, que decide por dónde tienen que

ir los datagramas para llegar a su destino,
3) la capa de red también identifica el mecanismo para informar de

cualquier error que se haya producido en el envío de la información.
2.1. Funcionalidades básicas: direccionamiento
Una red está compuesta básicamente por dos tipos de entidades, los clientes
(también conocidos por el nombre de hosts o el de equipos finales) y los enca-
minadores (o routers). Los clientes son los equipos de red encargados de la co-
municación, son el origen y el final de la misma. Normalmente son servidores
de información o equipos de usuarios finales que acceden a los servidores. Por
su parte, los encaminadores, a pesar de que en determinados casos también
pueden ser equipos finales, se limitan a enviar la información que reciben por
una interfaz de entrada a la correspondiente de salida que lleve los datagramas
hacia su destino. Para poder saber hacia dónde va la información, los encami-
nadores se sirven de lo que se conoce como tablas de direccionamiento.
La capa de red necesita que tanto los encaminadores como los equipos finales
tengan un identificador único. Este identificador permite que cualquier otro
equipo de la red lo pueda localizar y enviarle información. En particular, en
una red como Internet estos identificadores se conocen como direcciones (di-
recciones IP).
Ejemplo de red con encaminadores y equipos finales
La figura siguiente muestra una red con ocho encaminadores y dos equipos finales. En la
figura también se puede observar una simplificación de cómo funciona un encaminador
internamente. Para simplificar, en vez de indicar las direcciones de los diversos equipos
hemos identificado, por una parte, los diferentes encaminadores con R (de routers) y un
número que los identifica, y por otra, los diferentes equipos finales con H (de hosts) y
un número para identificarlos.
Los encaminadores están compuestos por una serie de interfaces de entrada y

salida, que son las encargadas de recibir los datagramas de los equipos vecinos;
estas interfaces están controladas por unas colas (o buffers) que almacenan
los paquetes (de entrada o de salida) para poder enviarlos cuando sea posible,
o lo que es lo mismo, cuando el encaminador tenga recursos para atender
las colas de entrada, o bien cuando la red tenga recursos (ancho de banda
disponible) para las colas de salida. Internamente, el encaminador dispone de
una lógica para decidir qué hacer con los datagramas que llegan. Esta decisión
normalmente implica enviar el datagrama por otra interfaz que lo llevará más
cerca de su destino.
Así, el datagrama va saltando por los encaminadores hasta llegar al destino.

Cada equipo de red por el que pasa el datagrama se conoce como salto o hop.
Hay que señalar que los encaminadores trabajan a nivel de red, lo que quiere
decir que no interpretan los campos presentes en los niveles superiores, tal
como muestra la figura siguiente.
Capas usadas por el direccionamiento en protocolos de red
Cuando un equipo envía un datagrama hacia un destino, dicho datagrama

va dirigido inicialmente al encaminador asociado a la red del equipo. Este en-
caminador 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 des-
tino final. La lista de encaminadores que sigue un datagrama se conoce como
el camino o path del datagrama. Hay que señalar que este path será diferente
dependiendo del origen y el destino del datagrama.
Como muestra, se puede ver en la figura del ejemplo anterior que el camino que siguen
los datagramas para ir desde H1 hasta H2 es H1-R1-R4-R7-R8-H2, haciendo un total de
5 saltos para llegar al destino.
Hemos dicho que el equipo envía el datagrama al encaminador de su red, lo

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

cuál es el siguiente salto para enviar el datagrama.
4) Si hemos podido conseguir la dirección, enviamos el datagrama (con las

direcciones de red origen y destino originales) al siguiente salto del path o al
equipo final si estamos en el last hop.
5) Repetir desde el paso 2 hasta que el datagrama llegue a su destino.
Diagrama de bloques simplificado del envío de un datagrama a un equipo de red
El datagrama no sigue cualquier path, sino que los encaminadores dis-

ponen de una tabla de direccionamiento (forwarding table o routing ta-
ble) que indica por qué interfaz se tienen que enviar los datagramas en
función de su destino. Para llenar estas tablas es necesario utilizar unos
algoritmos de direccionamiento.
2.2. Servicios de red
El servicio de red define las características que tiene que tener el transporte
punto a punto de los datos en la capa de red. Así, se definen características
como la fiabilidad en el envío de la información, orden de llegada de los pa-
quetes, umbrales de retardo en hacer llegar la información a destino, informa-
ción de congestión en la red, etc., entre los diferentes emisores y receptores
dentro de la red.
Actualmente existen dos modelos de servicios de red claramente diferenciados,

el modelo�de�circuito�virtual y el modelo�de�datagrama. A continuación se
describen los dos, aunque haremos más énfasis en el modelo de datagrama,
dado que es el utilizado por el nivel de red propuesto por Internet y, por lo
tanto, el más relevante en la actualidad.
2.2.1. Modelo de red en modo de circuitos virtuales
Un circuito virtual es un camino que se preconfigura entre dos puntos

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

radas:
1)�Establecimiento�del�circuito�virtual: esta fase se inicia en la capa de red

del emisor, utilizando la dirección del receptor. El emisor envía un datagrama
de creación de circuito que provoca que cada nodo intermedio reserve los re-
cursos pedidos de forma iterativa hasta llegar al destino. Cada uno de los no-
dos intermedios tendrá que actualizar su estado para acomodar el nuevo cir-
cuito, o denegar la creación en caso de que no queden más recursos disponi-
bles (normalmente, ancho de banda). Si el establecimiento del circuito puede
llegar hasta el destinatario se avisa al emisor indicando que la conexión ha
sido satisfactoria y se puede empezar a enviar información.
2)� Transferencia� de� datos: en el caso de que se haya podido establecer el

circuito virtual se puede empezar a enviar datos entre los dos puntos.
3)�Desconexión�del�circuito�virtual: esta desconexión puede iniciarla tanto

el emisor como el receptor, y se avisa secuencialmente a través de la capa de red
a todos los nodos intermedios hasta llegar al otro extremo. Esta desconexión
permite liberar los recursos ocupados por el circuito.
Actividad
¿Qué diferencias creéis que pueden existir entre el inicio de un circuito virtual en la capa
de red y el establecimiento de una conexión en la capa de transporte? (por ejemplo, el
three-way-handshaking).
Solución
El establecimiento de la conexión de la capa de transporte involucra únicamente

a dos sistemas finales. Los dos extremos acuerdan la comunicación y determinan
los parámetros de conexión, mientras que los nodos intermedios de la red no
intervienen. Por el contrario, el establecimiento de un circuito virtual en la capa
de red obliga a involucrar a todos los nodos intermedios.
El principal inconveniente que tiene la utilización de circuitos virtuales es que

los nodos intermedios tienen que mantener las reservas de recursos pedidas
independientemente de que se estén utilizando, con el potencial problema de
infrautilizar la red.
2.2.2. Modelo de red en modo datagrama
Si enviar información a través de un circuito virtual implica previamente esta-

blecer un camino y reservar recursos, en una red en modo datagrama (también
llamado conmutación de paquetes), el paquete se envía directamente a la red
con una dirección origen y una dirección destino. Entonces, es trabajo de la
red (a través de las tablas de direccionamiento de cada encaminador) el hacer
llegar el paquete a su destino.
Como se puede comprobar, en este tipo de comunicación no hay reserva de

recursos ni camino preestablecido entre los extremos de la comunicación. Por
lo tanto, a un encaminador le pueden llegar datagramas de diferentes desti-
nos a la vez, y los datagramas pueden seguir caminos diferentes para llegar al
destino (dependiendo de los algoritmos de direccionamiento), lo que provoca
el efecto lateral de que los paquetes pueden llegar fuera de orden (el paquete
número 2 llega antes que el número 1).
Las redes en modo datagrama son las más usadas actualmente, debido princi-
palmente a que el protocolo de red de Internet (IP) lo utiliza. A pesar de que
hemos visto que el modelo de datagrama hace una utilización de los recur-
sos más eficiente, eso viene con un coste asociado. Con este tipo de redes se
complica muchísimo la priorización del tráfico, ya que nunca se sabe a priori
cuánto tráfico se recibirá, y lo que es más grave, no se sabe qué prioridad se
tiene que dar a cada uno de los flujos de datos presentes en la red, tanto es así
que Internet se basa en el paradigma conocido como best effort, que implica
que la red no nos da ninguna garantía de calidad y que "lo hará lo mejor que
pueda" para hacer llegar el datagrama en su destino.
Actividad
¿Cuál de los dos modelos de red vistos consideráis que hace un uso de los recursos más
eficiente?
Solución
El hecho de que un circuito virtual obligue a hacer una prerreserva de recursos

implica que se tiene que conocer previamente el modelo y el patrón de tráfico
que sigue la aplicación, pero como eso, a priori, no es posible muchas veces, se
acostumbra a hacer lo que se conoce como overprovisioning (reservar más recursos
de los que se consideran necesarios), lo que inequívocamente lleva a un sistema
menos eficiente en términos de recursos.
Por su parte, utilizar el modo datagrama no implica ninguna prerreserva, con lo

que la red siempre enviará tan rápidamente como pueda la información, siempre
y cuando haya recursos disponibles.
2.2.3. Servicio de red orientado y no orientado a la conexión
Análogamente a los protocolos de transporte que hemos visto anteriormente,

en el nivel de red también podemos tener protocolos orientados a la conexión
y otros que no lo sean. La principal diferencia entre las dos alternativas es que
en el servicio orientado a conexión se guarda el estado de la conexión, o lo
que es lo mismo, se tiene conocimiento de todas las conexiones establecidas,
mientras que en el caso del servicio no orientado a conexión no se tiene cons-
tancia de las conexiones existentes. Un ejemplo claro de servicio de red orien-
tado a la conexión es el modelo de circuitos virtuales visto anteriormente.
Hay que señalar que el diseño de un protocolo de red no orientado a conexión

no excluye que a niveles superiores (transporte) se pueda definir un protocolo
orientado a conexión. El ejemplo más indicativo de eso es la pila de protocolos
TCP/IP, donde TCP es orientado a la conexión mientras que IP no lo es. Tanto
es así que la arquitectura actual de Internet sólo proporciona el modelo de
servicio de datagrama, lo que no garantiza el orden de los paquetes, el retardo
en el envío, ni la llegada del datagrama.
2.3. Direccionamiento en Internet: el protocolo IP
El protocolo de capa de red por excelencia es Internet Protocol (IP). IP

es un protocolo que basa el intercambio de información en el modelo
no orientado a conexión. IP es el protocolo utilizado en Internet para
identificar los nodos de la red, así como también para enviar la informa-
ción de una forma estándar e independiente de la tecnología de red uti-
lizada. Otra característica muy importante de IP es que no implementa
mecanismos que garanticen la integridad de los datos que se envían por
la red (eso se hace en la capa de transporte), sólo se comprueba que no
haya errores de transmisión en la cabecera.
Todos los protocolos de red requieren algún mecanismo con el fin de identifi- Ved también
car los nodos de la red; esta identificación en el protocolo IP se realiza a través
En el subapartado "Direcciona-
de lo que se conoce como dirección IP; actualmente existen dos versiones dimiento en Internet: el protoco-
ferentes del protocolo IP: IPv4 e IPv6. IPv4 es el protocolo más utilizado en la lo IP" se detalla cómo funcio-
nan los protocolos IPv4 e IPv6
actualidad en Internet, pero, dado el gran crecimiento que ha sufrido la red, y qué ventajas e inconvenien-
tes tienen.
se ha propuesto una extensión, IPv6, más actual y que algún día se prevé que
sustituya al IPv4.
2.3.1. IPv4
IPv4 fue propuesto en 1981 (documento RFC-791) y en la actualidad todavía

es el protocolo de red por excelencia. IPv4 define el formato que se tiene que
utilizar para enviar información entre dos puntos distantes de la red; el proto-
colo proporciona mecanismos que determinan cómo se divide el direcciona-
miento de una forma escalable en una red tan grande como Internet.
La cabecera IP
IPv4 define qué información de control y qué formato tienen que tener los
paquetes que se envían a la red. Por eso, y al igual que con los protocolos de
transporte vistos anteriormente, es necesario definir una cabecera que sirva
para poder identificar los paquetes. La cabecera de Ipv4 se puede ver en la
figura siguiente.
En esta figura podemos ver los siguientes elementos:
Versión�(4�bits): indica qué protocolo de red utiliza este datagrama. Para IPv4
está fijado en 0x04.
• Hdr.�Len�(4�bits): la cabecera IP puede tener un tamaño variable a causa del

campo de opciones. Ese tamaño indica en qué punto empiezan los datos
del protocolo de transporte. En particular, dicho campo indica el valor en
función de la cantidad de palabras de 4 octetos que tiene la cabecera; así,
un valor de 0x05 quiere decir una cabecera de 20 octetos, el valor usado
en la mayoría de los casos por ser el tamaño por defecto cuando no hay
opciones.
• Type�of�Service�(ToS)�(8�bits): este campo permite distinguir entre dife-

rentes tipos de datagramas IP; inicialmente se definieron parámetros en
función de: retardo bajo, tasa de transferencia alta o fiabilidad. Así, depen-
diendo del tipo de tráfico que contenga el paquete, por ejemplo tráfico
interactivo, puede quererse un retardo bajo, o en el caso de que el tráfico

sea de baja prioridad, se puede querer un coste mínimo. La lista de los di-
ferentes tipos de servicio se puede encontrar en el documento RFC-1349.
En realidad, los encaminadores normalmente ignoran este campo y utili-
zan la técnica best effort para encaminar los paquetes.
• Total�Length�(16�bits): indica el tamaño total del datagrama en octetos,

lo que incluye la cabecera así como el campo de datos. Los 16 bits indican
un tamaño máximo del datagrama de 65.535 octetos. Aunque en general
el tamaño máximo utilizado es de 1.500 octetos.
• Identifier�(16�bits),�flags�(3�bits)�y�fragmentation�(13�bits): estos campos Ved también

hacen referencia a lo que se conoce como fragmentación IP.
La fragmentación será expli-
cada en el subapartado "Frag-
• TTL�(8�bits): inicialmente, este campo hacía referencia al tiempo de vida mentación IP".
del datagrama en milisegundos. Pero en la práctica contiene el máximo

número de routers que puede atravesar el paquete hasta que llegue al des-
tino. A cada salto, un encaminador decrementa en 1 el valor de este cam-
po, cuando el TTL llega a 0, el paquete es descartado. Con esta técnica se
permite descartar datagramas en el caso de que haya algún bucle provo-
cado por algún problema con el sistema de direccionamiento, y así evitar
tener paquetes en la red más tiempo del necesario. De este campo se pue-
de derivar que el "diámetro" máximo posible de Internet es de 255 saltos.
Aunque en la actualidad no acostumbra a superar los 30.
• Protocol�(8�bits): este campo indica el protocolo presente en la capa de

transporte, que será capaz de interpretarlo. Normalmente, este campo pue-
de ser 0x06 para TCP o 0x11 para UDP. La lista completa se puede en-
contrar 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 trans-
porte y distinguirlos fácilmente, pasando el control al que corresponda de
forma eficiente.
• Header�Checksum�(16�bits): permite detectar algunos tipos de error de

transmisión a la cabecera. Es importante señalar que no se comprueba la
integridad de la capa de transporte y superiores. Recordemos que IP no
garantiza la recepción de los datos. El checksum se calcula tratando cada
dos octetos de la cabecera como enteros y sumándolos utilizando aritmé-
tica de complemento a 1, ignorando para la suma el mismo campo que
contiene el checksum. La integridad se comprueba comparando la suma
con la almacenada en la cabecera. En caso de error, el paquete se descar-
ta. Un pequeño inconveniente de este checksum es que cada encaminador
tiene que recalcularlo para cada paquete, dado que el campo TTL (y quizás
algunas opciones) cambian a cada salto.
• Dirección�Origen�(32�bits): indica la dirección origen del paquete. Ved también
Se puede encontrar más infor-

• Dirección�Destino�(32�bits): adonde va dirigido el paquete. mación sobre el direcciona-
miento en el subapartado "Di-
reccionamiento IPv4".
• IP�Options: este campo es el que hace que la cabecera IP pueda ser variable
en tamaño. Las opciones, que normalmente no se utilizan, permiten am-
pliar las funcionalidades de la cabecera IP. A pesar de no hacerse servir casi
nunca, el hecho de comprobar su existencia en cada encaminador reduce
mucho el rendimiento del protocolo IPv4. Por eso, durante el diseño de la
versión 6 del protocolo se cambió la forma de implementar estas opciones.
• Padding: por motivos de eficiencia, los datos tienen que empezar en una
posición múltiple de 4 octetos, por lo tanto, en el caso de que algunas
opciones introduzcan una desalineación, el padding, que normalmente es
todo ceros, alinea a la palabra del siguiente campo.
• Data�(payload): los datos del datagrama que se pasarán al nivel de trans-

porte, o sea, la información que realmente se quiere transmitir.
Fragmentación IP
(3)
Uno de los puntos más críticos a la hora de diseñar el protocolo IP fue la nece- En inglés, Maximum Transfer
Unit (MTU).
sidad de introducir la fragmentación. La fragmentación IP es necesaria porque
no todas las redes, ni todos los protocolos de enlace de datos, pueden trans-
portar paquetes de tamaño arbitrario. En general, el tamaño máximo vendrá
delimitado en función de la tecnología de red utilizada. Por lo tanto, a causa
de la diversidad de tecnologías que actualmente coexisten en Internet, pode-
mos encontrar casos en los que el tamaño máximo de trama permitido3 sea
menor en algún encaminador dentro del camino a seguir por los datagramas,
forzando a IP a dividir la trama en fragmentos más pequeños que se puedan
transmitir. Un ejemplo puede ser Ethernet, que permite tramas de un tama-
ño máximo de 1.500 bytes, mientras que una tecnología como Asynchronous
Transfer Mode (ATM) en general tiene el máximo en 9.180 bytes. Hace falta
señalar que cuando se fragmenta un datagrama IP, cada fragmento tiene que
ser autocontenido, y tiene que poder ser ensamblado en el destino final (ha-
cerlo en los encaminadores intermedios supondría una pérdida de rendimien-
to considerable), por lo que sólo dividir el datagrama no es suficiente, es ne-
cesario hacer algún tipo de proceso.
Cuando se tiene que dividir un datagrama IP, primero se replica la cabecera IP

para cada fragmento, y acto seguido se actualizan los campos de la cabecera:
identification, flag y fragmentation offset. Así, todos los fragmentos pertenecien-
tes al mismo datagrama tendrán el mismo identificador, cada fragmento con-
tendrá el desplazamiento y finalmente el flag, que será 1 si hay más paquetes,
o 0 si es el último. Por las restricciones en la implementación, y para reducir
el número de bits que se utilizan para almacenar este desplazamiento, se de-
cidió hacerlo con múltiplos de 8 bytes; así, un desplazamiento de 64 bytes –o

sea, que el fragmento IP contenga desde el byte 65 del datagrama original– se
representará con un 8 en el campo fragmentation offset (ya que 8 x 8 = 64).
Ejemplo de fragmentación
En la figura siguiente se puede ver el caso en que un equipo envía un paquete de tamaño
MTU = 2.500 bytes. Lo que quiere decir que el paquete tendrá 2.480 bytes de información
útil y 20 de cabecera. A la hora de fragmentar se generan dos paquetes diferentes, uno
de 1.480 + 20 y otro de 1.000 + 20. Como se puede ver, el tamaño útil no cambia, pero,
por el hecho de tener dos paquetes diferentes, estamos replicando la cabecera. El valor
del identificador viene dado por un contador interno en el encaminador que fragmenta,
el desplazamiento (offset) para el primer fragmento es 0, y el flag 1, lo que indica que
todavía hay más fragmentos, para el segundo fragmento el offset contiene un 185, ya que
se especifica con grupos de 8 bytes, y un 0 en el flag, que indica que se trata del último
fragmento del datagrama original. Cuando el datagrama llegue a su destino final será
reensamblado y pasado a los niveles superiores de forma transparente.
Direccionamiento IPv4
Los protocolos de red necesitan disponer de una dirección única que permita
identificar todos los nodos de la red. En el caso de Ipv4, tal como se puede
deducir de la cabecera IPv4, la máxima cantidad de direcciones disponibles
es muy grande: 232 (4.294.967.296). Para simplificar su escritura, se dividen
los 32 bit en 4 bloques de 8 bits cada uno, y además, en vez de utilizar la
representación binaria, que es poco legible, en la práctica se escribe la dirección
IP en notación decimal separada por puntos; la dirección estará formada por
4 bloques de números entre 0 y 28 - 1 (255).
Representación binaria y decimal de una dirección IP
Además, tener un número tan grande de direcciones supone un enorme pro-

blema de gestión, por lo que se propuso un sistema de asignación de direccio-
nes jerárquico. En Internet, las direcciones IP están compuestas por dos partes,
la parte de red y la parte del equipo, lo que se utiliza para poder estructurar las
direcciones y organizarlas por zonas administrativas.
La parte de red está formada por los bits superiores de la dirección IP

e indica a qué red pertenece un conjunto de equipos, o lo que es lo
mismo, cuál es el encaminador de salida del conjunto de equipos. Por
el contrario, la parte del equipo son los bits inferiores de la dirección IP
e identifican el equipo dentro de su red.
Inicialmente, esta división con redes se hizo a través de clases, concretamente

se definieron 5 clases diferentes (A, B, C, D y E) tal como muestra la tabla
siguiente:
• Las direcciones�de�clase�A son las destinadas a empresas muy grandes, Carencia de direcciones IP
como por ejemplo IBM, o grandes operadoras americanas, como AT&T
El reparto de clases A es uno
WorldNet Services, y proporcionan acceso a 224 (16.777.216) equipos por de los causantes de la fuerte
carencia de direcciones IP en la
red, donde 8 bits están destinados a identificar la red y el resto hasta los actualidad.
32 se utilizan para los equipos finales. De direcciones de clase A hay un
total de 27 (255).
• Las direcciones�de�clase�B son las que se dan a grandes entidades, uni-

versidades y determinados proveedores de Internet. Permiten repartir 216
(65.536) equipos por red, y hay un total de 214 (16.384) direcciones de
clase B.
• En el caso de las direcciones�de�clase�C, son las destinadas a medianas

8
empresas con fuerte presencia en Internet; en este caso se dispone de 2
21
(256) direcciones, con un total de 2 (2.097.152) direcciones de tipo C a
repartir.
• Con respecto a las direcciones�de�clase�D, se consideran un tipo de clase

especial, denominadas clases multicast, que sirven para enviar el tráfico
denominado punto multipunto.
• Finalmente, las direcciones�de�clase�E están reservadas para un uso futuro.
División de redes por clases
Clase Bits�iniciales Bits�Red Rango�Red
A 0 7 (+1) 1.0.0.0-127.0.0.0
B 10 14 (+2) 128.0.0.0-191.255.0.0
C 110 21 (+3) 192.0.0.0-223.255.255.0
D 1110 - 224.0.0.0-239.0.0.0
E 11110 - 240.0.0.0-255.0.0.0
Direcciones de propósito específico
Aparte de la división en redes también se destinaron una serie de direcciones

de propósito específico para casos especiales:
• Direcciones�de�host. Indican un equipo dentro de la red actual y tienen

la forma 0.host, donde host es la parte del equipo de la red actual, o sea,
que la parte de la dirección de red es todo 0.
• Direcciones�de�red. Hacen referencia a la red, pero no a los equipos dentro

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

La dirección se representa con red.255 para direcciones de clase C. Análo-
gamente al caso de las direcciones de red, las de clase B serán red.255.255,
y las de clase A, red.255.255.255, o sea, que la dirección del equipo de red
es todo 1. Siempre que se reciba un datagrama en la dirección de broadcast
todos los equipos tienen que responder.
Las direcciones de broadcast, a su vez, tienen una dirección especial, que

es la 255.255.255.255, que hace referencia a toda la red (Internet). En-
tonces, si alguien enviara un datagrama a la dirección 255.255.255.255
toda la Internet tendría que responder. Como eso provocaría graves pro-
blemas de escalabilidad y exceso de tráfico, no hay ningún encamina-
dor que reenvíe tráfico broadcast por sus interfaces. El tráfico de broad-
cast siempre se quedará en la red que lo ha emitido.
Actividad
Dada la dirección IP 120.1.32.54, indicad cuál es la dirección de red, la dirección del host
y la dirección de broadcast de la red.
Solución
La dirección 120.1.32.54 forma parte de las direcciones de clase A, por lo tanto,

la dirección de red será la 120.0.0.0, la del host la 0.1.32.54 y la de broadcast sería
la 120.255.255.255.
• Direcciones�de�loopback. Son desde la 127.0.0.0 hasta la 127.0.0.255 y son

las que se utilizan internamente por los equipos. Cuando un equipo arran-
ca, automáticamente crea una interfaz virtual (interfaz de loopback) para
uso interno del sistema operativo, normalmente sólo se utiliza la 127.0.0.1.
• Direcciones�privadas. Son las utilizadas por redes locales internas que no

salen a Internet. La lista con todos los rangos privados se puede encontrar
en la tabla siguiente. Como se observa en dicha tabla, se pueden configu-

rar internamente diversos rangos de direcciones privadas, cuya utilidad es
evitar colisiones en asignaciones de direcciones en configuraciones inter-
nas con nodos de otras redes del exterior. Otra funcionalidad es permitir
asignar más direcciones a nuestras redes que IP públicas asignadas por los
operadores.
Lista de rangos de direcciones privadas
Clase Rango�Red Número�de�subredes
A 10.0.0.0-10.255.255.255 1
B 172.16.0.0-172.31.255.255 16
C 192.168.0.0-192.168.255.255 255
Network Address Translation
El problema principal de las direcciones privadas es que no pueden acceder a Internet

directamente, los encaminadores nunca enviarán a Internet el tráfico originado o con
destino a direcciones privadas, ya que no saben cómo encaminar el salto siguiente. Con
el fin de evitar esta limitación y permitir la transferencia de datos entre direcciones pri-
vadas y públicas, los encaminadores incluyen una técnica denominada Network Address
Translation (NAT).
Network Address Translation (NAT)
Por lo que se puede deducir de lo que se ha visto hasta ahora, cada equipo de Referencia bibliográfica
una red IPv4 tiene que disponer de una IP pública para poder acceder a la red.
La NAT está definida en de-
Uno de los problemas principales que se encuentran cuando se piden IP a las talle en los documentos RFC-
operadoras es, generalmente, que el usuario (o la empresa) tiene más equipos 2663 y RFC-3022.
que IP asignadas. Un ejemplo de eso es el del usuario con conexión ADSL, que
recibe una sola IP por parte de la compañía telefónica, mientras que muchas
veces el usuario dispone de diversos equipos, como el PC de sobremesa, el
portátil, la PDA, etc. Con el fin de permitir que todos los equipos se puedan
conectar a la red al mismo tiempo hay dos opciones, pedir más IP (solución
difícil y cara) o utilizar direcciones IP privadas y configurar el encaminador
para que haga la conversión desde la dirección IP privada a la IP pública dis-
ponible. Eso se puede conseguir mediante lo que se conoce como NAT.
NAT es una tabla de traducción que se utiliza de la siguiente forma. Si, por
ejemplo, un cliente con dirección privada quiere establecer una conexión con
un equipo que tiene una dirección IP pública (punto 1 de la figura siguiente)
–por ejemplo, un servidor–, el cliente enviará el paquete hacia el encamina-
dor de su red. El mencionado encaminador tendrá configurada una tabla de
traducción, donde transformará la IP origen del datagrama en una IP pública
que tenga reservada a tal efecto. Para completar la traducción, el encaminador
mapeará el puerto origen (de la capa de transporte) en un nuevo puerto origen
asignado por el encaminador. El punto 2 de la figura muestra un ejemplo, en
el que el encaminador transforma la IP origen (192.168.1.4) y el puerto origen
(5.674) del equipo en la IP pública del encaminador (123.26.1.12) y un puerto
asignado dinámicamente (20.543 en el ejemplo). La estación destino ve un
datagrama como si hubiera sido enviado por el encaminador, al que responde

de la forma habitual usando TCP/IP. Finalmente, el encaminador, al recibir
la respuesta, mira la tabla de traducción y deshace el cambio para enviar el
paquete final a la estación origen. Si la entrada no hubiera estado en la tabla,
el encaminador hubiera asumido que el paquete iba realmente dirigido a él.
Ejemplo de red con NAT
Este mecanismo es muy útil cuando se quiere evitar el uso de direcciones pú-
blicas, a pesar de que tiene una serie de inconvenientes que no permiten usarlo
en determinados entornos. Primero, hay protocolos de aplicación (por ejem-
plo, FTP) que incrustan la IP del cliente dentro del datagrama, esta IP es usada
por el servidor para establecer una nueva conexión (por ejemplo, el caso del
FTP activo), y como el cliente incrusta la IP privada, eso impide que se pueda
establecer la conexión.
Otro problema importante es que todas las conexiones se tienen que iniciar
desde el equipo con IP privada, ya que el encaminador tiene que establecer la
entrada en la tabla de traducción antes de poder enviar información hacia el
equipo con IP privada, lo que normalmente implica que no se puedan tener
servidores con IP privadas. Hay que decir, sin embargo, que eso se puede solu-
cionar con una técnica denominada Port Address Translation (PAT), en la que
el encaminador tiene configurado de forma estática un mapeado, por lo que
cuando llega un datagrama a un puerto concreto, automáticamente reenvía
el paquete hacia el equipo que esté configurado con IP privada. En según qué
entornos, el PAT se conoce también como Destination NAT (DNAT) o incluso
como puerto Forwarding, pero la idea de fondo es la misma.
Classless inter Domain Routing
Una vez definidas las diferentes clases de redes, se vio que esta solución era
claramente insuficiente, ya que forzaba igualmente a las grandes y medianas
operadoras (con clases A y B) a gestionar desde un solo equipo un número de
direcciones demasiado grande, por lo que se propuso el Classless inter Domain
Routing (CIDR).
CIDR propone un mecanismo más flexible para poder subdividir nues-

tras redes. CIDR no sustituye la división por clases, que continúan sien-
do las unidades básicas de asignación de direcciones; por el contrario,
CIDR nos permite dividir las direcciones asignadas en subredes más pe-
queñas y manejables.
Así, con CIDR, la separación entre el equipo y la red se consigue gracias a una
máscara. Esta máscara tiene la forma de una dirección IP, que enmascara los
bits de una dirección normal para poder distinguir el equipo y la red de forma
sencilla.
Ejemplo de máscara
Una máscara de 255.255.255.0 permite separar la dirección de red de la del equipo final
haciendo AND con la dirección IP, así:
143 . 45 .1 . 23
255 . 255 . 255 .0
143 . 45 .1 .0
De donde se puede extraer la dirección de la subred (los unos de la máscara - 143.45.1) y

la dirección del equipo (los ceros de la máscara - 23). En este caso, la red constará de 28 IP
válidas como una clase C, de las que 28 - 2 serán asignables a equipos; hay que recordar
que las direcciones especiales de red y de broadcast (143.45.1.0 y 143.45.1.255, respecti-
vamente) no son asignables. La representación de esta subred se hace con la siguiente
nomenclatura: 143.45.1.23/255.255.255.0.
Como se puede observar, eso nos da un nivel más fino de división que simpli-
ficará mucho la gestión interna de redes; si una entidad dispone de una clase
B (146.43.0.0), internamente la entidad puede decidir subdividir las 65.536
direcciones en varias subredes, por ejemplo, con 256 subredes de 256 IP cada
una: desde la 146.43.0.0/255.255.255.0 a la 146.43.255.0/255.255.255.0. Ob-
servad que los valores de 255 y 0 para la dirección de red son correctos, sin
que representen direcciones de broadcast y de red, respectivamente. Eso lo po-
demos saber gracias a la máscara.
Una restricción no escrita, pero generalmente adoptada a la hora de definir las

máscaras, es que todos los unos de la máscara tienen que ser consecutivos.
Máscaras correctas e incorrectas
Máscaras como 255.145.0.0 se consideran inválidas, ya que, traducidas a formato binario,

daría:
11111111 10010001 00000000 00000000
Mientras que otras, como 255.255.128.0, son totalmente correctas ya que, en formato
binario, resulta:
11111111 11111111 11111110 00000000
Donde todos los unos son consecutivos, a pesar de no estar alineados en el octeto.
Esta restricción de los unos consecutivos nos permite simplificar la represen-

tación de la máscara en un formato más compacto; así, otra forma de indicar
la separación entre la red y el equipo es a través de un formato que indica
cuántos bits representan la red, por ejemplo, 143.45.1.23/24 indica que la má-
quina 143.45.1.23 pertenece a la red 143.45.1.0/255.255.255.0, o, lo que es lo
mismo, que tiene 24 bits para la dirección de red y 8 para la de los equipos.
Por otra parte, gracias a la clasificación por subredes, los encaminadores tie-
nen el trabajo más fácil, ya que para poder decidir la ruta que tiene que tomar
cualquier datagrama, es suficiente mirar la red de destino, y no es necesario
comprobar toda la dirección IP. La dirección IP entera, idealmente, sólo la mi-
rará 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 en-
caminadores basan la decisión de direccionamiento en una política llamada
Longest Prefix Match, lo que significa que, de todas las rutas posibles, siempre
se coge la que tiene más bits coincidentes con el destino del paquete.
Actividad
Dentro de las siguientes subredes e IP, indicad cuántas IP asignables puede contener la
red y explicad el significado.
Dirección IP�asignables Explicación
147.83.32.0/24
1.23.167.23/32
1.23.167.0/32
147.83.32.0/16
Solución
147.83.32.0/24 254 Es una dirección de red en la que tenemos 8 bits para los equipos; sabiendo que la
8
dirección de broadcast y la de red no son asignables, acabamos con el total de 2 - 2
direcciones para asignar.
1.23.167.23/32 1 Dirección con una subred con sólo un equipo. No es útil en un caso real, pero es co-
rrecta.
1.23.167.0/32 1 Como no hay parte de equipo, todo es de red, el hecho de que el último octeto sea
0 hace que la IP no sea una dirección de red genérica sino una específica, como en el
caso anterior.
147.83.32.0/16 1 Hace referencia al equipo 32.0 de la red de clase B 147.83.0.0. Hay que señalar que
no es una dirección de red, ya que no todos los bits de fuera de la máscara son 0;
así, se trata como una dirección de equipo.
Actividad
En la dirección de clase B 143.45.0.0/16, indicad qué subredes /20 se pueden crear y

cuántos equipos contienen cada una.
Solución
(4)
El CIDR se utiliza generalmente en conjunción con la máscara de subred de En inglés, Variable Length Sub-
4 net Mask (VLSM).
tamaño variable , técnica que tiene por objetivo optimizar la utilización de
las direcciones IP a través de una asignación inteligente de las máscaras de
red. Esta asignación se hará ahora teniendo en cuenta el número de máquinas
de cada subred y se asignarán máscaras de tamaño ajustado a las necesidades
particulares de cada una. VLSM se puede ver como la creación de subredes de
las subredes.
Actividad
1) Dada la red de la figura, se nos proporciona el rango de direcciones 147.83.85.0/24.

Se pide que se asignen rangos de direcciones a todas las subredes y a los enlaces entre
los encaminadores.
2) ¿Qué problema tiene la asignación de direcciones hecha en el ejercicio anterior?
Solución
1) La asignación de direcciones se puede hacer siguiendo la siguiente política:
• Los 20 equipos más el router necesitan un total de 5 bits (25 = 32).
• Los 10 + 1 equipos tienen suficiente con 4 bits (24 = 16).
• Los 5 + 1 equipos necesitan 3 (23 = 8), con lo que esta subred no podrá crecer más.
• Finalmente, los enlaces punto a punto necesitarán 2 bits, ya que necesitamos

espacio para las direcciones de broadcast y de red.
En resumidas cuentas, nos harán falta un prefijo /27, un /28, un /29 y tres prefijos
/30 respectivamente. De esta manera, una posible asignación sería:
• Los 20 equipos pueden usar la 147.83.85.0/27, donde el último byte se-

ría 000XXXXX. Con dirección de red 147.83.85.0 y dirección de broadcast
147.83.85.31.
• Los 10 equipos dispondrán de la 147.83.85.32/28 donde el último byte se-

rá 0010XXXX. Con dirección de red 147.83.85.32 y dirección de broadcast,
147.83.85.47.
• En el caso de los 5 equipos utilizaremos la subred 147.83.85.48/29 donde el últi-

mo byte será 00110XXX. Con dirección de red 147.83.85.48 y dirección de broad-
cast, 147.83.85.55.
• Finalmente, los tres prefijos /30 (de los enlaces entre los encaminadores) se pue-
den dividir con el último byte 001110XX, 001111XX y 010000XX, respectiva-
mente. O sea, 147.83.85.56/30, 147.83.85.60/30 y 147.83.85.64/30. Con direccio-
nes de red 147.83.85.56, 147.83.85.60 y 147.83.85.64. Con direcciones de broad-
cast 147.83.85.59, 147.83.85.63 y 147.83.85.67.
2) El problema de esta asignación viene dado por el hecho de que se ha ajusta-

do demasiado el número de bits para cada subred, y en el caso de que crezca el
número de equipos (especialmente en la subred de cinco equipos), nos tocaría
redimensionar la red de nuevo con el coste que eso supone.
Tipo de datagramas IP
IPv4 especifica tres tipos de tráfico claramente diferenciados dentro de

la red: unicast, broadcast y multicast.
El tráfico� unicast es el más común, la comunicación está formada por dos

interlocutores que se intercambian información, a menudo estas conexiones
son desde un cliente hacia un servidor, que a la vez puede tener conexiones
unicast hacia otros clientes.
El tráfico�broadcast se basa en enviar la información a todos los equipos pre- Requisitos del tráfico
sentes en una subred. Como ya hemos visto anteriormente, eso se puede con- broadcast
seguir enviando un paquete a una dirección que sea la dirección de red y todo Hay que señalar, sin embargo,
1 a la dirección del equipo final, por ejemplo, para la red 126.76.31.0/24, la que enviar tráfico broadcast
normalmente requiere algún
dirección de broadcast sería 126.76.31.255. privilegio en la red (ser admi-
nistrador), además, los enca-
minadores en general no pro-
Finalmente, el caso del tráfico�multicast se basa en el paradigma de enviar pagan este tipo de tráfico con
el fin de evitar problemas de
información desde un solo origen hacia muchos destinos a la vez; la base del seguridad, como, por ejemplo,
ataques del tipo Denial of Ser-
tráfico multicast es que el emisor no tiene por qué tener conocimiento de vice (DoS).
quiénes serán sus receptores (al contrario de la política de unicast, que requiere
conocer a los interlocutores). Eso se consigue a través de lo que se conoce co-
mo 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 conoci-
dos como permanentes.
Así, si una estación concreta está interesada en recibir un contenido multicast,

lo que hará será suscribirse al servicio mediante el protocolo Internet Group
Management Protocol (IGMP), que especifica el formato del paquete que se
tiene que generar con el fin de poder registrarse en un grupo y poder recibir
el contenido. IGMP soporta dos tipos de paquetes, los de pregunta y los de
respuesta. Normalmente, los de pregunta son paquetes dirigidos a todos los
equipos donde los que tienen sesiones multicast activas responden, así los
encaminadores (que tienen que tener soporte para multicast) pueden construir
lo que se conoce como el árbol multicast, para encaminar los paquetes hacia
sus destinos.
La ventaja principal de multicast es que la información que se envía,

en vez de replicarse desde el origen una vez por cada destino forma un
árbol de manera que se minimiza el número de copias.
Actividad
Un servidor de chat tiene en un momento dado un total de 80 clientes conectados por

todo el mundo. Indicad qué número y de qué tipo son las conexiones que tiene abiertas
este servidor.
Solución
Dado que el chat es un protocolo que utiliza TCP/IP, y que los clientes, a pesar de
hablar entre ellos, pasan siempre por el servidor, se trata del típico escenario con
80 conexiones unicast entre los 80 clientes y el servidor.
Actividad
Un administrador de la red 147.83.0.0/16 quiere enviar un paquete de broadcast a la

subred 147.83.20.0/24. Indicad qué dirección de destino tendría el paquete, cuántos pa-
quetes se generarían y a cuántas máquinas como máximo podría llegar.
Solución
Dado que la subred a la que se quiere enviar el broadcast tiene 8 bits, eso implica
que se generaría un solo paquete con dirección destino 147.83.20.255 y que lo
recibirían como máximo 255 - 2 = 253 estaciones. Ya que la dirección 147.83.20.0
y la 147.83.20.255 están reservadas para la dirección de red y la de broadcast,
respectivamente.
El futuro de Ipv4
Cuando se diseñó IPv4 se creía que su gran número de direcciones IP (232) se-
ría suficiente para poder aguantar el gran crecimiento que se esperaba de una
red como Internet. Hay que recordar que Internet entró en funcionamiento
en 1969 con el nombre de ARPANet, un proyecto subvencionado por el De-
partamento de Defensa de Estados Unidos. Eso provocó que, cuando Internet
se desplegó al cabo de unos años en la red comercial, el reparto de direccio-
nes no se hiciera de forma equitativa, y las grandes empresas estadounidenses
pudieron adjudicarse una gran cantidad de direcciones de clase A, dejando a
países, como China y otros que se han desarrollo posteriormente, con muchas
menos direcciones de las necesarias. Como referencia, Estados Unidos tiene
sobre 1.500 millones de direcciones asignadas, mientras que China, con una
población mucho más numerosa, sólo dispone de 200 millones, aproximada-
mente. Para hacerse una idea, España tiene asignadas en la actualidad en tor-
no a 22 millones.
Con este paradigma, muy pronto se ve que con la actual política para el reparto
de direcciones, dentro de muy poco tiempo ya no quedarán direcciones IPv4
disponibles para asignar, lo que implicará inevitablemente que Internet no
podrá crecer más. Con el fin de minimizar este problema, se diseñó la NAT,
como ya hemos visto, que permite utilizar direcciones privadas para acceder
a la red con una sola IP pública. En la actualidad, países como China o la
India están haciendo un uso intensivo de la NAT por la falta de direcciones
disponibles.
Como esta solución no es escalable y comporta una serie muy importante de Implantación del
problemas a los proveedores de servicios se llegó a la conclusión de que los protocolo IPv6
32 bits de direccionamiento del protocolo IPv4 eran insuficientes, por eso se Por motivos económicos no
diseñó el protocolo IPv6, como veremos a continuación. está implantado todavía IPv6,
y si la demanda de direcciones
IPv4 sigue al ritmo actual, se
prevé que la IANA asignará el
2.3.2. IPv6 último rango de direcciones
IPv4 a mediados del 2011 y
que las autoridades regionales
La carencia de direcciones IPv4 incentivó el diseño de un nuevo protocolo de agotarán las que tienen pen-
dientes de asignar en el 2012,
red, IPv6. En la actualidad, IPv6 está totalmente desarrollado, aunque todavía lo que seguramente forzará a
muchos países a adoptar pre-
no es posible utilizarlo dentro de la red comercial, ya que los operadores toda-
maturamente IPv6. En este
vía no han preparado sus equipos ni tampoco han hecho el reparto de direc- sentido, países como Japón,
China, la India y algunos de
ciones a sus usuarios. Eso, y la dificultad de implantar progresivamente esta América del Sur, ya han adop-
tado el protocolo y utilizan al-
nueva versión y sustituir la anterior es lo que está retrasando su incorporación gunas técnicas que permiten
en el ámbito comercial. la interoperabilidad de los dos
protocolos.
Este subapartado describe brevemente este protocolo y destaca sus diferencias

con la versión anterior, así como las novedades que incorpora. Para acabar el
subapartado, se describen los principales problemas que hay para la migración
de Ipv4 a IPv6.
Motivación
Inicialmente, a la hora de diseñar el protocolo, se pensó que no era necesario

crear un protocolo entero y que sería suficiente con hacer una adaptación de
IPv. Pero enseguida se vio que, para poder disfrutar de buenas optimizaciones
en comparación con la versión anterior, harían falta bastantes más cambios.
Así se optó por un diseño que tiene poco en común con la versión anterior.
El motivo principal que llevó a plantearse una nueva versión del protocolo era
el limitado rango de direcciones que permite IPv4, que, aunque pueda parecer
muy elevado, se vio que sería claramente insuficiente para cubrir la demanda
del mercado en un futuro. Sobre todo, la aparición en los últimos años de una
gran cantidad de dispositivos móviles que quieren formar parte de la gran red
que es Internet ha provocado rápidamente que los 32 bits de direccionamien-
to IPv4 sea insuficiente, tanto es así que si todos estos dispositivos se quisie-
ran conectar de forma simultánea en la red, los operadores probablemente
tendrían problemas por la falta de direcciones IPv4. Para ver este problema
sólo hay que pensar en cuántos teléfonos móviles hay en la actualidad; sólo
en el Estado español hay alrededor de 44 millones, mientras que el número
de IP que hay asignadas actualmente en el país es de unos 22 millones. Eso,
sin contar los usuarios que se conectan desde sus hogares. Cabría pensar que
el problema se podría minimizar con la utilización de NAT, pero, a la larga,
eso puede suponer un grave problema de rendimiento en los encaminadores
por tener que mantener las tablas de traducción de direcciones de millones de
conexiones a la vez. Encima, cada vez hay más pequeñas y medianas empre-
sas que quieren ofrecer a sus clientes una serie de servicios que precisan una
conexión permanente a la red, con el consecuente gasto de direcciones y la

imposibilidad de utilizar la NAT masivamente. IPv6 soluciona este problema
proponiendo un campo de direcciones de 128 bits.
Cabecera IPv6
La cabecera IPv6 tiene una longitud fija de 40 octetos (tal como se puede ver
en la figura siguiente), y consta de los campos siguientes:
• Version�(4�bits): indica la versión del protocolo que contiene el paquete.

Este campo tiene el mismo significado que el de la versión IPv4, pero ahora
con el valor0x06.
• Traffic�Class�(8�bits): este campo clasifica un paquete dentro de un tipo

de tráfico determinado, conceptualmente es el equivalente del Type Of
Service (TOS) de IPv4.
• Flow�Label�(20�bits): sirve para etiquetar un conjunto de paquetes que

tengan las mismas características; servirá para poder ofrecer calidad de ser-
vicio.
• Payload�Length�(16�bits): longitud del payload del paquete, o sea, el pa-

quete sin la cabecera IP. El tamaño viene representado en octetos.
• Next�Header�(8�bits): este campo es una gran innovación de IPv6 respecto

de IPv4, dado que permite tener una cabecera básica de tamaño fijo. Este
campo indica la posición en que se puede encontrar la siguiente cabecera,
ahorrando así tiempo de proceso a los encaminadores intermedios al no
haber opciones.
• Hop�Limit�(8�bits): este campo es equivalente del TTL de IPv4, pero cuenta

directamente hops y no tiempo.
• Source�Address�(128�bits): dirección del host que ha originado el paquete.
• Destination�Address�(128�bits): dirección del host al que va destinado el

paquete.
Cabecera IPv6
A partir de los datos de la cabecera se puede observar que la diferencia

más directa que hay entre ambos protocolos es la longitud de las direc-
ciones IP, donde IPv4 tiene 32 bits, IPv6 pasa a tener 128. Este aumento
en el espacio de direccionamiento permite que el rango de direcciones
de la red pase de 232 a 2128 direcciones posibles.
Como ahora tenemos muchos más bits para la dirección, la forma de

especificar direcciones IPv6 se hace con la notación� de� los� dos� pun-
tos. Donde una dirección IPv6 se representa con bloques de 16 bits re-
presentados en hexadecimal y separados por el símbolo ":". Por ejem-
plo, 2001:0DB8:0000:0000:0319:8A2E:0370:7348. Una simplificación de es-
ta notación se puede aplicar en el caso de que una dirección tenga
muchos 0 consecutivos; la forma abreviada de representarla es utilizan-
do "::"; así, la forma compacta de representar la dirección anterior sería:
2001:0DB8::0319:8A2E:0370:7348.
Otra diferencia notable entre IPv4 e IPv6 es la jerarquización de las direccio-

nes. La asignación de direcciones IPv4 se hizo, en su tiempo, de una forma
muy anárquica, dado que no se esperaba que el crecimiento de Internet fue-
ra tan espectacular. Actualmente, cada corporación u operadora de telefonía
tiene rangos de direcciones muy dispersos y mal dimensionados, lo que hace
extremadamente difícil la gestión de las direcciones disponibles, la asignación
de las nuevas y el direccionamiento global. Por eso, lo que ha hecho IPv6 ha
sido jerarquizar de una forma más inteligente el reparto de sus direcciones, de
forma que cada país, operador o ISP, dispone de un rango concreto con un nú-
mero de direcciones proporcional a su posible utilización de la red. Indepen-
dientemente de la mejora de esta jerarquía en cuanto a localización geográfica,
el hecho de separar de esta manera las direcciones permite asignar nuevas de
una forma mucho más sencilla que hasta ahora.
De forma parecida a IPv4, se puede identificar qué tipo de dirección es sólo

con el prefijo de la dirección IPv6, como indica la siguiente tabla.
Asignación de direcciones
Prefijo Espacio�de�asignación
0000::/8 Reservado. Las direcciones de loopback y las direc-

ciones con integración de IPv4 salen de este prefijo
0100::/8 Reservado
0200::/7 Reservado
0400::/6 Reservado
0800::/5 Reservado
1000::/4 Reservado
2000::/3 Dirección unicast global. De aquí sale el rango de direcciones

125
que se repartirán a los usuarios. Hay 2 direcciones disponibles.
4000::/3 Reservado
6000::/3 Reservado
8000::/3 Reservado
A000::/3 Reservado
C000::/3 Reservado
E000::/4 Reservado
F000::/5 Reservado
F800::/6 Reservado
FC00::/7 Dirección unicast local única
FE00::/9 Reservado
FE80::/10 Dirección de enlace local unicast (link-local)
FEC0::/10 Reservado
FF00::/8 Direcciones multicast
Un hecho muy interesante que se consideró para hacer esta asignación de di-
recciones es que da la posibilidad de representar direcciones de diversas tec-
nologías incrustadas dentro de la nueva versión del protocolo. De esta mane-
ra, se pueden representar direcciones IPv4, e incluso direcciones hardware del
enlace de datos (como, por ejemplo, Ethernet).
La gran ventaja de insertar otros tipos de direcciones directamente en IPv6 es

que tienen un prefijo asignado; así, por ejemplo, para tener una dirección Et-
hernet de un equipo dentro de un IPv6 el prefijo LAN es FE80::/10. Por tanto,
si la dirección de la tarjeta Ethernet es 00:90:F5:0C:0F:ED, entonces, la direc-
ción IPv6 queda así: FE80::0090:F50C:0FED. Como se puede observar, el pro-
ceso también se puede realizar a la inversa, cuando llega un paquete con el

prefijo de red FE80 ya se puede suponer que se trata de una dirección local
(link local) y se puede extraer la dirección hardware fácilmente. Además, con
este mecanismo, cualquier interfaz de red puede configurarse de forma auto-
mática y autónoma.
Hay que señalar que IPv6, aparte de tener direcciones unicast, broadcast
y multicast, como IPv4, añade soporte para un cuarto tipo, que son las
direcciones anycast.
Las direcciones anycast son una gran innovación de IPv6, sobre todo porque
aprovechan las direcciones unicast ya existentes. Así, una dirección unicast se
vuelve anycast desde el momento en que se asigna una misma IPv6 a más de
una interfaz (incluyendo equipos diferentes). La idea que hay detrás de esta
implementación es que responda a las peticiones de un servicio concreto la
estación más próxima.
Imaginemos dos servidores web con la misma IPv6, por ejemplo,

2001:0DB8::0319:8A2E:0370:7348, cuando la red reciba un paquete dirigido hacia esta
IPv6, lo enviará a las dos estaciones, la primera que responda será la que esté más cerca
del equipo que hace la petición. Actualmente, por complejidades en la implementación
de este tipo de direcciones, sólo se utilizan para encaminadores. Así, una subred puede
tener más de un encaminador para salir a Internet usando el mismo prefijo, y cada equipo
utiliza el que esté más próximo a la estación, que consigue de forma sencilla un sistema
de balanceo de carga.
Otra innovación relevante que incorpora IPv6 es la utilización mucho más

intensiva del tráfico multicast dentro de las redes locales, tanto es así que
los equipos, por defecto, escuchan a direcciones multicast con el prefijo
FF02::1:FF00:0000/104, con el fin de evitar la generación de tráfico broadcast
que afecta a todos los equipos de la subred y no siempre es deseable.
Otras mejoras menores que introduce este protocolo son:
• Mecanismo� de� opciones� ampliado: las opciones forman parte de una

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

nes ha sido sustancialmente mejorada con respecto a su predecesor. Uno
de los motivos principales de eso es el hecho de que se puede añadir la
dirección hardware dentro de la dirección IPv6; así, sólo con un prefijo
dado por el dispositivo de direccionamiento más próximo y con la direc-
ción hardware se garantiza una dirección única a escala mundial. Siempre
que se utilice el prefijo asignado por el operador a la hora de generar la

dirección.
• Facilidad�para�la�asignación�de�recursos: lo que con IPv4 era el Type of

Service ahora se llama Traffic Class, aunque también se tiene la posibilidad
de marcar flujos individuales, lo que da mucha más flexibilidad a la hora
de marcar tráfico prioritario.
• Capacidades�de�seguridad: como la seguridad, hoy día, es un tema tan

importante, IPv6 incluye características de autenticación y privacidad. Por
defecto, IPv6 incluye funcionalidades nativas para la creación de redes pri-
vadas virtuales (VPN, en la abreviatura en inglés) a través de IPsec (RFC-
4301), protocolo de cifrado de los datos en tiempo real que con IPv4 era
opcional.
Actividad
Un PC con una tarjeta Ethernet con MAC 34:27:A4:6F:AE:53. El operador le proporciona

el prefijo 2001:0A54:0039::/48. Indicad la dirección link-local y la dirección de autocon-
figuración de este equipo.
Solución
La dirección link-local vendrá dada por el prefijo link-local, así la dirección será:
FE80::3427:A46F:AE53. Mientras que la dirección de autoconfiguración sale del
prefijo y del MAC, por lo tanto: 2001:0A54:0039::3427:A46F:AE53.
Problemas de la migración en IPv6
Uno de los motivos principales por los que todavía se trabaja con IPv4 es la
dificultad que comporta la migración al nuevo protocolo. La incompatibilidad
de las direcciones y de las cabeceras de ambos protocolos hace que la actuali-
zación a la nueva versión no sea fácil. También hay que tener en cuenta que
las aplicaciones existentes sólo soportan el sistema de direcciones de IPv4, que
para aceptar las nuevas direcciones se tiene que cambiar el código de la apli-
cación, y también todos los llamamientos al sistema de acceso a la red.
Aparte del nivel de aplicación, hay otro problema muy grave. Dada la gran di-
versidad de redes que forman Internet, hay funcionando equipos muy diver-
sos, 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 enca-
minadores de la red, con el consecuente gasto económico y de tiempo que eso
supone, cosa que muchas de las empresas no están dispuestas a aceptar (espe-
cialmente las grandes corporaciones estadounidenses, que son las que tienen
suficientes direcciones).
Por último, a causa de la gran utilización que se hace actualmente de Internet,

es un gran problema tener que parar todas las redes para hacer la migración.
Así, el problema que se encuentra es el enorme gasto económico para las em-
presas que controlan todas sus transacciones a través de la red, lo que fuerza
a hacer la migración de forma progresiva, transparente para los usuarios y sin
dejar de ofrecer los servicios disponibles en ningún momento.
Mecanismos para asistir la transición
La migración entre dos protocolos cuando uno se está utilizando masivamente

es extremadamente compleja. Como hemos visto, las razones, normalmente,
son económicas, ya que la gran mayoría de las aplicaciones actualmente sólo
soportan IPv4, y migrarlas a la nueva versión no siempre es sencillo (por ejem-
plo, aplicaciones bancarias). Por otra parte, todo el equipamiento hardware
que forma el backbone de la red, si bien está preparado para soportar IPv6, no
siempre tiene la configuración correcta, ni la asignación de direcciones hecha.
En cualquier caso, se espera que haya una fase de coexistencia de los dos pro-
tocolos. De todas formas, a pesar de la coexistencia, hay escenarios que obli-
gan a diseñar un plan de migración controlado. Así, los diferentes mecanismos
de transición se pueden dividir en dos grandes grupos: mecanismos básicos y
mecanismos para la interconexión de islas.
En cuanto a los mecanismos básicos, se pueden distinguir dos, el conocido

como Dual-Stack, en el que los equipos utilizan simultáneamente los dos pro-
tocolos y se conectan con el que más se ajuste a las necesidades del momento,
y el de Tunneling, en el que dos equipos con Dual-Stack crean un túnel IPv4
entre ellos, y por dentro del túnel se comunican con IPv6.
Hay que señalar que un túnel es el mecanismo por el que se encapsulan dos
protocolos de red dentro de un mismo datagrama, así hay dos cabeceras de
red consecutivas del nivel de red. IPv4 soporta el mecanismo de túnel a través
de un valor especial en el campo Protocolo que se encuentra en la cabecera.
Por lo que respecta a los mecanismos para conectar islas, pretenden resolver el
caso en el que diversas máquinas interconectadas a través de IPv6 (isla IPv6)
se quieren conectar con otra isla IPv6, pero por el camino hay una isla IPv4,
tal como muestra la figura siguiente.
Redes IPv4 y redes IPv6
Estos mecanismos también están basados principalmente en túneles. Se pue-

den distinguir los siguientes tipos:
• Túneles�configurados: los extremos de los túneles entre las islas se confi-

guran de forma manual entre las dos redes. Los extremos tienen que ser
dual-stack.
• Túneles� automáticos: se utilizan direcciones IPv4 mapeadas dentro de

IPv6 con el prefijo reservado, que es el ::/96, por ejemplo, ::195.123.57.93,
que el encaminador convierte a la dirección IPv4, y en el otro extremo se
vuelve a convertir a la IPv6. Los extremos no se dan cuenta del cambio y
se pueden comunicar con IPv6 sin problemas.
• Túnel�Broker: se utiliza un broker (gestor), que indica al cliente un script

con el fin de hacer el túnel de forma automática. El cliente tiene que ser
dual-stack, ya que la petición en el broker va con IPv4, que contesta con un
script que permite conectar a un Tunnel-Server (que también es dual-stack)
al que permite conectarse a la red IPv6.
• 6to4: se asigna una dirección IPv4 compatible con el prefijo IPv6 en

los encaminadores, los cuales hacen un túnel. Por ejemplo, para la red
2001:d002:0507::/48 el encaminador tendría la dirección 208.2.5.7 (que
sale de d002:0507). En el otro extremo se haría la operación análoga y se
establecería el túnel.
2.4. Protocolos de soporte a IP
Tanto IPv4 como IPv6 son protocolos de red, pero ambos necesitan soporte
de otros protocolos de la misma capa para poder llevar a cabo ciertas funcio-
nalidades que sería complejo conseguir de otra manera. A pesar de que, dadas
las diferencias estructurales entre los dos protocolos, muchos de los servicios
son diferentes, todos se engloban en este subapartado para simplificar la com-
prensión, ya que, si bien los protocolos divergen, su funcionalidad a menudo
es muy similar.
2.4.1. Internet Control Message Protocol
IP es un protocolo no orientado a conexión que tiene por objetivo el envío de

información independientemente de la tecnología de niveles inferiores utili-
zada. Eso proporciona un entorno ideal para poder comprobar el estado de la
red, o enviar información de control en el caso de que haya problemas en la
red. Por ejemplo, cuando un datagrama no puede llegar a su destino, o bien
hay congestión en un enlace, o bien a un paquete se le ha expirado el TTL.
Todas estas situaciones requieren de algún protocolo, que trabajando en la
misma capa que IP permita avisar de forma automática de cualquiera de estos
eventos. Por eso se diseñó el Internet Control Message Protocol (ICMP).
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. Bibliografía
Descripción de los diferentes mensajes ICMP Para una descripción más

completa de todos los tipos
Mensaje Descripción de mensajes existentes con
ICMP se puede consultar el
Destination�unreachable Indica que no se puede llegar al destino. Este mensaje tiene un documento RFC-792.
campo de código que indica si es culpa de la red, del equipo en
particular o bien del puerto. También distingue si no se puede
llegar al destino o bien si el destino es desconocido.
Echo�request/�Echo�reply Estos dos mensajes son el de petición y el de respuesta, cuando

una estación recibe un echo request, tiene que responder con un
echo reply si está activa. En general es aconsejable que todos los
equipos respondan estas peticiones, aunque por seguridad mu-
chas veces se filtran los mensajes.
La aplicación por excelencia que utiliza los echo request/reply es
el ping.
Source�quench Este paquete sirve para regular, indica que aquel enlace está su-
friendo congestión. Actualmente este tipo de paquete no se uti-
liza porque el control se hace mayoritariamente en la capa de
transporte.
Router�advertisement Este paquete de ICMP se envía a una dirección multicast donde

todos los encaminadores escuchan por defecto. Con este men-
saje es posible descubrir automáticamente la existencia de nue-
vos encaminadores en la red.
Router�discovery Es un paquete complementario del de router advertisement. Pero

en este caso es un encaminador que acaba de entrar en una red
que pregunta qué otros encaminadores hay en la red.
TTL�expired Cuando el TTL de un paquete llega a 0 éste se descarta, y el en-

caminador que lo ha descartado genera un paquete TTL expired
en el origen del paquete descartado.
IP�header�bad En el caso de que se detecte un error de checksum en la cabece-

ra de un paquete IP, éste se descarta y se avisa al origen con es-
te paquete ICMP.
Los mensajes ICMP tienen varias utilidades, desde reportar errores hasta de-
purar el estado de la red. Una de las herramientas más utilizadas para poder
ver si un equipo está conectado a la red es el ping. Otra funcionalidad es po-
sible gracias al campo TTL de la cabecera IP, que ayuda a realizar otra tarea de
depuración mediante una herramienta llamada traceroute; esta herramien-
ta nos permite descubrir los encaminadores intermedios entre el origen y el
destino de los datagramas. Para conseguir saber qué encaminadores cruza un
datagrama, el traceroute envía paquetes IP consecutivos con un TTL de 1,
otro de 2, otro de 3, y así sucesivamente hasta llegar al destino. El efecto de
eso es que el primer encaminador, al recibir un paquete con TTL = 1, lo de-
crementa, y al ser 0, lo descarta y envía de vuelta un paquete ICMP de TTL
expired. Ahora sólo hace falta que la aplicación mire a quien ha enviado este
paquete (IP origen) para saber de qué router se trata. Por descontado, con TTL
= 2 sucederá lo mismo con el segundo encaminador, y después con el tercero,
y así sucesivamente hasta el destino.
2.4.2. Address Resolution Protocol
Para enviar un datagrama IP a una estación de la misma red que el emisor Dirección de nivel de
es necesario descubrir qué dirección del nivel del enlace de datos tiene esta enlace
estación, ya que las tecnologías de capas inferiores no entienden qué es una La dirección de nivel de enla-
dirección IP. Así pues, para que la IP funcione necesita interactuar con las ca- ce es conocida como dirección
MAC y viene dada por los dis-
pas inferiores y descubrir de forma automática cuál es la dirección de enlace positivos de red. Cada disposi-
tivo de red tiene una dirección
de datos a la que responde un equipo para poder intercambiarse información. MAC única.
El protocolo Address Resolution Protocol (ARP) fue diseñado específicamente
para IPv4, y como veremos más adelante, para IPv6 existe el Network Disco-
very Protocol.
Para conseguir el descubrimiento de la dirección hardware de un equipo a

partir de su IP, ARP se sirve de la funcionalidad que nos proporciona la capa
de enlace de datos para enviar paquetes de broadcast. Entonces la procesa con
el fin de conseguir la dirección hardware (llamada MAC) y poder enviar el
paquete, tal como se puede ver en el diagrama de la figura siguiente.
Diagrama de secuencia para el envío de un paquete IP
El proceso de ARP, ilustrado en la siguiente figura con un ejemplo, sigue una

serie de pasos con el fin de descubrir la dirección. Lo primero que se tiene que
conseguir es la dirección MAC del siguiente salto, por eso se envía un paquete
ARP a la dirección de broadcast de nuestra red local. Este ARP buscará la IP
del destino o bien la del encaminador dependiendo de si la estación forma
parte de la subred o no. Una vez se obtiene la dirección MAC, se construye un

paquete que tiene como dirección MAC destino la obtenida por ARP y como IP
destino la original (o sea, en el caso de que se envíe el paquete al encaminador,
esta IP será la del destino final, no la del encaminador).
Ejemplo de petición por ARP
RARP
Hemos visto que ARP nos sirve para poder descubrir qué dirección MAC corresponde a
una IP, también hemos visto la importancia de esta operación. Por compleción, ARP tiene
una variante denominada RARP, que nos permite realizar la operación inversa, o sea,
desde una dirección MAC poder averiguar a qué IP corresponde. RARP no es exactamente
un protocolo de la capa de red, ya que incluye muchas funcionalidades de la capa de
enlace de datos, pero, dada la estrecha relación con ARP, se acostumbran a considerar
conjuntamente. RARP ya no se utiliza, ya que hay protocolos como BOOTP y DHCP que
nos ofrecen esta y más funcionalidades como veremos a continuación.
2.4.3. Network Discovery Protocol
ARP es un protocolo que fue diseñado específicamente para IPv4; con los avan-
ces de las redes hasta hoy ha probado que es insuficiente para según qué servi-
cios. Por eso, con la aparición de IPv6, se decidió que hacía falta un protocolo
más completo. Así apareció el Network Discovery Protocol (NDP).
NDP es un protocolo que permite descubrir a los vecinos existentes en una

red local. El modo de operar es muy similar al que utilizábamos con IPv4,
ahora se envían neighbour solicitations y se reciben neighbour advertisements. Sin
embargo, la gran diferencia con ARP es que se utiliza tráfico multicast en vez
de broadcast. Y que NDP forma parte de un protocolo mayor llamado ICMPv6,
que es la extensión en IPv6 del protocolo ICMP.
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 automa-
tizar este procedimiento, la dirección multicast Solicited-Node de una es-
tación se construye de la siguiente manera: se cogen los últimos tres oc-
tetos de la dirección unicast y se añade al principio el prefijo multicast
FF02::1:FF00:0000/104. Por ejemplo, la dirección multicast Solicited-Node pa-
ra 2001:630:1310:FFE1:02C0:4EA5:2161:AB39 sería la FF02::1:FF61:AB39. En-
tonces, la estación se pone a escuchar al grupo multicast para responder con
la dirección hardware del equipo al que va dirigida la petición.
Eso nos da la versatilidad que no todos los nodos reciben los anuncios, así
en el caso de que no vayan dirigidos hacia ellos ya ni los llegan a ver, con la
reducción en el uso de recursos que eso supone.
2.4.4. Dynamic Host Configuration Protocol
El siguiente protocolo de red que veremos no es realmente un protocolo de

red, sino un protocolo de aplicación. De todas formas, dado que se utiliza para
configurar la red, se explica en este subapartado. El Dynamic Host Configura-
tion Protocol (DHCP) fue inicialmente definido en el documento RFC-1531.
Es un protocolo que utilizan los dispositivos con el fin de obtener información
de la configuración de los parámetros de red por un equipo IPv4 de forma
automática.
El administrador de la red configura un prefijo de red, conjuntamente con un

subrango de direcciones destinadas a autoconfiguración (este rango de direc-
ciones se llama pool). Cuando se recibe una petición, el protocolo comprueba
si el cliente está autorizado; si lo está se le asigna una IP preconfigurada, que
se obtiene de una base de datos a partir de la dirección hardware del equipo,
o bien una al azar del pool si la dirección hardware no se encuentra. Esta ce-
sión de IP va controlada por un temporizador; cuando este temporizador ex-
pira 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 evi-
tar que caduquen. Para hacer todas estas tareas DHCP utiliza UDP para enviar
la información.
Entrando en un poco más de detalle, un cliente, cuando dé de alta una inter-

faz, enviará un DHCP discovery, que es un paquete broadcast con el fin de
descubrir servidores DHCP. El servidor, cuando ve el paquete, comprueba la
validez del cliente (base de datos de MAC) y envía un DHCP Offer con su IP. Al
que el cliente responde directamente con un DHCP request, que finalmente el
servidor acepta con un DHCP acknowledgement, que contiene la duración de
la IP y la configuración específica que el cliente haya pedido al DHCP request.
Por ejemplo, encaminador por defecto, servidor de DNS, etc.
3. El enlace de datos y el control de acceso al medio
Hemos visto que la capa de red proporciona un servicio de comunicación en-

tre dos máquinas, estableciendo diferentes rutas o caminos entre ellas. Cada
ruta de comunicación está formada por una serie de enlaces, que conectan la
máquina origen con la de destino utilizando unos dispositivos encaminado-
res intermedios. Cuando un datagrama del nivel de red sale de la máquina
origen hacia la máquina destino, va atravesando cada uno de estos enlaces
individuales que conforman el recorrido extremo a extremo.
Se hace necesaria una capa lógica adicional situada inmediatamente bajo la

capa de red, que se ocupe de suministrar a ésta un transporte de información
fiable entre los diferentes enlaces que atraviesa a lo largo de un recorrido. Esta
capa recibe el nombre de nivel de enlace, y se sitúa por encima de la capa física.
La capa física no es capaz de aportar ninguno de los elementos necesarios para
la transmisión efectiva de información en un enlace.
El nivel�de�enlace consiste en dos programas o procesos que se ejecutan

a ambos lados de un enlace y se comunican entre sí. Para que estos dos
procesos se puedan comunicar es necesario establecer:
• un formato para la información que se intercambian, y
• un conjunto de reglas de comportamiento o protocolos necesarios

para la transmisión de datos.
El principal cometido de la capa de enlace es conseguir que la comunicación

de datos en un enlace se realice correctamente a través de un medio físico de
transmisión. De una forma gráfica, podemos decir que el nivel de enlace se
encarga de establecer y mantener un puente de comunicación entre dos nodos
vecinos, para que por encima puedan circular los datagramas de nivel superior.
Ruta de comunicación creada entre dos máquinas finales, formada por 5 enlaces: 2 enlaces comunican las máquinas finales con
los routers de la red y 3 enlaces internos intercomunican sólo routers de la red.
De la observación de la figura anterior, podemos destacar dos características

muy importantes del nivel de enlace:
• Los enlaces, a lo largo de un recorrido de comunicación, pueden utilizar

diferentes protocolos de la capa de enlace y estar constituidos por tecno-
logías de base totalmente diferentes. Un encaminador puede disponer de
diferentes enlaces y cada uno de ellos puede utilizar un protocolo de nivel
de enlace diferente. En la figura podemos observar cómo un datagrama
enviado desde la máquina origen es manejado por Ethernet en el primer
enlace, por el protocolo ATM en el segundo enlace, y va cambiando de
tecnología sucesivamente en cada nuevo enlace.
(5)
• Una de las funcionalidades básicas del nivel de enlace consiste en encap- PDU son las siglas de Protocol
5 Data Unit.
sular/desencapsular los datagramas de la capa de red en PDU de informa-
ción de la capa de enlace, también llamados tramas. Observemos las fle-
chas de la figura que indican el flujo que sigue la información a lo largo
del recorrido. Cuando una trama llega al encaminador desde un enlace
entrante, la capa de enlace desencapsula/extrae el datagrama de la trama
recibida y lo entrega a la capa de red. Una vez la capa de red ha determina-
do el enlace de salida por donde debe encaminar el datagrama, lo envía al
enlace. Aquí el datagrama es encapsulado según las normas del protocolo
de este enlace y preparado para ser enviado.
3.1. Terminología y definiciones
El nodo es la máquina o encaminador.
El enlace es el canal que conecta dos nodos adyacentes al recorrido de

la comunicación.
El protocolo de�la�capa�de�enlace es la forma de comunicarse entre los

nodos, para mover un datagrama sobre un enlace individual. Define el
formato de los paquetes (PDU) intercambiados entre los nodos en los
extremos del enlace, así como las acciones adoptadas por estos nodos
cuando envían y reciben estos paquetes.
La trama son las unidades de datos intercambiadas por un protocolo de

la capa de enlace. El nodo transmisor encapsula el datagrama de la capa
en una trama de la capa de enlace y transmite la trama al enlace, y un
nodo receptor recibe la trama y extrae el datagrama.
3.2. Tipo de enlaces
Básicamente podemos destacar dos tipos de enlaces:
• Enlaces�de�comunicación�punto�a�punto. Sólo participan dos entidades

o puntos. Son enlaces 1 a 1: compuestos por un único nodo emisor en
un extremo del enlace y un único nodo receptor en el otro. Ambos nodos
utilizan en exclusiva el enlace, sin compartir el canal.
Ejemplos de enlaces punto a punto
Son enlaces punto a punto:
• Bucle de abonado local, cable de dos hilos telefónico para acceso a Internet.
• Las redes de área local FastEthernet.
• Las redes de área local GigabitEthernet.
• PPP, HDLC (a nivel de enlace), X.25 a nivel de red y TCP a nivel de transporte (en
este caso es además extremo-a-extremo).
• Enlaces�broadcast�o�canales�de�multidifusión. Son enlaces 1 a N, donde

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

• Las redes de área local sin cable Wifi.
• Los enlaces con satélites.
• Las redes de acceso híbrido fibra-cable (HFC).
• Las redes de área local Token Ring.
• Las redes de área local FDDI.
3.3. Tipo de servicios suministrado en la capa de red
El tipo de servicio que la capa de enlace suministra a la capa de red suele ser
alguno de los siguientes:
• Servicio�no�orientado�a�conexión�y�sin�acuse�de�recibo. El envío se hace

sin esperar ninguna indicación del receptor sobre el éxito o fracaso de la
operación. Tampoco se establece o libera una conexión. Este tipo de servi-
cio es apropiado cuando la tasa de error es muy baja (redes locales o fibra
óptica) y se deja la misión de comprobar la corrección de la transmisión a
las capas superiores (nivel de red o de transporte). También se usa el servi-
cio no confirmado cuando se quiere transmitir información en tiempo real
(típicamente voz o datos) y no se quiere sufrir el retardo que impondría un
servicio más sofisticado en la capa de enlace (se supone que este tipo de
información puede sufrir una pequeña tasa de error sin efecto apreciable).
• Servicio�no�orientado�a�conexión�con�acuse�de�recibo. Se produce un
acuse de recibo para cada trama enviada, aunque todavía no hay estable-
cimiento dé conexión. De esta manera el emisor puede estar seguro de que
ha llegado.
• Servicio�orientado�a�conexión�con�acuse�de�recibo. Es el más seguro y

sofisticado. El emisor y el receptor establecen una conexión explícita de
antemano, se enumeran las tramas a enviar y se asegura que todas sean
recibidas correctamente en el destino, y se transmiten seguidamente a la
capa de red. En el servicio orientado a conexión se pueden distinguir tres
fases: establecimiento de la conexión, envío de los datos, y finalización de
la conexión. En la primera se disponen los contadores y memorias tempo-
rales necesarios para la transmisión, en la segunda se envían los datos, y en
la tercera se libera la memoria ocupada con datos temporales y variables.
3.4. Servicios proporcionados por la capa de enlace
El servicio básico del nivel de enlace consiste en mover correctamente un da-

tagrama de nivel de red, desde un nodo hasta otro adyacente sobre un enla-
ce de comunicación fijando en el recorrido. Los posibles servicios que puede
ofrecer un protocolo de la capa de enlace son:
• Gestión�de�las�tramas. El nivel de enlace se encarga de la organización y

gestión de las tramas.
– Entramado o composición de la trama.
– Sincronización a nivel de trama.
– Transparencia de trama.
– Numeración y secuenciación (números de secuencia).
– Direccionamiento: si existe más de un posible destino de un mensaje
es necesario identificarlo perfectamente.
• Gestión� del� enlace. Todo el proceso de inicio, mantenimiento y finali-

zación de la transmisión requiere un considerable esfuerzo de gestión y
coordinación.
• Control�de�flujo. La estación emisora y la receptora se tienen que poner

de acuerdo sobre el ritmo de transmisión de datos. Si la estación receptora
recibe las tramas más rápidamente de lo que es capaz de procesarlas, el ni-
vel de enlace remoto ha de "frenarlas" para evitar que se sature la memoria
intermedia o memoria temporal que almacena las tramas pendientes.
• Control�de�errores. Se trata de una de las funciones básicas del nivel de

enlace. Se asume que el medio de transmisión subyacente no es perfecto
e introduce errores de transmisión. Es necesario destinar una parte de los
bits que se intercambian a la detección y la posterior gestión de los errores,
para controlar que no se produzcan errores de transmisión. En el control

de errores se distinguen tres conjuntos de técnicas:
– Detección de errores. Utilización de códigos detectores de errores efi-
cientes.
– Corrección de errores, si se utilizan códigos correctores adecuados.
– Retransmisión de tramas erróneas (entrega fiable).
• Control�de�acceso�al�medio. Esta funcionalidad cobra relevancia en los

enlaces de acceso múltiple o broadcast, donde un número determinado
de nodos comparten el mismo medio físico. El modelo OSI divide la capa
de enlace en dos subcapas: la LLC (Logical Link Layer) y la MAC (Medium
Access Control). La subcapa MAC es la encargada de especificar las reglas
con que se transmite una trama sobre el enlace. Los protocolos MAC coor-
dinan la transmisión de las tramas de los nodos, con el objetivo de evitar
las colisiones de tramas. En los enlaces punto a punto los protocolos de
acceso al medio dejan de tener sentido.
3.5. Adaptadores y dispositivos de red
Los nodos o encaminadores se conectan a los enlaces a través de un adapta-

dor, conocido como tarjeta de interfaz de red o Network Interface Card (NIC).
Físicamente, un adaptador es una placa hardware (una tarjeta PCMCIA o un
dispositivo conectado al puerto USB) que contiene todos los elementos de un
pequeño computador: memoria RAM, chip DSP, una interfaz de bus con la
máquina, y una interfaz de enlace. Normalmente se encuentra alojado en la
misma capa física que el resto del nodo, comparte la alimentación y los buses
con el resto del nodo, y está en el fondo bajo el control del nodo.
Un adaptador tiene un cierto grado de autonomía:
• En�recepción: cuando recibe una trama, determina si ésta tiene errores. Si

es así, la rechaza sin notificarlo a su nodo padre. Si es correcta, desencap-
sulará el datagrama de la capa de red e interrumpirá a su nodo padre para

pasarlo hacia arriba de la pila de protocolos.
• En�transmisión: cuando un nodo pasa un datagrama hacia abajo en la

pila de protocolos a un adaptador, delega totalmente en éste la tarea de
transmitir el datagrama sobre el enlace. El adaptador encapsula el datagra-
ma en una trama y transmite la trama en el enlace de comunicación.
Los componentes principales de un adaptador son la interfaz del bus y la del

enlace. La interfaz del bus es responsable de comunicar con el nodo padre del
adaptador. Transfiere datos e información de control entre el adaptador y el
nodo padre. La interfaz del enlace es responsable de implementar el protocolo
de la capa de enlace. También incluye el hardware de transmisión y recepción.
El protocolo de la capa de enlace está, mayoritariamente, implementado en

este adaptador. Si el protocolo de la capa de enlace proporciona detección
de errores, entrega fiable (numeración y reconocimientos) o acceso aleatorio
(además de enmarcar y quitar el marco de datagramas), entonces estas funcio-
nalidades están implementadas completamente en los adaptadores.
4. El nivel físico
(6)
Para acabar este módulo, estudiaremos la última capa del modelo OSI6. El nivel OSI es la abreviatura de Open
Systems Interconnection; en cas-
físico caracteriza la señal y su modulación, así como describe los medios de tellano, interconexión de sistemas
transmisión físicos. abiertos.
En este módulo no entraremos en los fundamentos matemáticos de la modu-

lación y de la señal. Simplemente tenemos que saber que la información bi-
naria se puede transmitir por un medio a través de las variaciones de alguna
propiedad física, habitualmente, el voltaje o la intensidad. Podemos represen-
tar el valor de esta magnitud física como una función dependiente del tiem-
po. Dada esta función en forma de onda, podemos codificarla para transmi-
tir la información que queremos. Este es el fundamento de la transmisión de
información a través de un medio y sobre el que se basa toda la teoría de la
comunicación.
4.1. Medios de transmisión
Existen varios medios de transmisión en función de su ancho de banda, retar-

do, coste, facilidad de uso, instalación y mantenimiento. Los medios se pue-
den clasificar en medios guiados (par de hilos, fibra óptica) o no-guiados (on-
das de radio, láser a través del aire). Los siguientes factores de un medio de
transmisión determinan la velocidad máxima de transmisión y la distancia
máxima del medio:
• Ancho�de�banda. Al aumentar el ancho de banda se puede aumentar la

velocidad de transmisión.
• Atenuación. En orden decreciente van el par trenzado, el cable coaxial y

la fibra óptica.
• Interferencias. En orden decreciente van el par trenzado y el cable coaxial.
• Número�de�receptores. Atenúan y distorsionan la señal que supone una

menor distancia.
4.1.1. Par trenzado
Se trata del sistema más antiguo y todavía es muy utilizado en la actualidad.

Consiste en dos pares de hilos de cobre o de acero cubierto con cobre, aproxi-
madamente de un milímetro de diámetro cada uno, que están envueltos entre
sí en forma de hélice, como una molécula de ADN.
Se puedem utilizar tanto en las transmisiones digitales como en las analógicas. Coste del par trenzado
El ancho de banda que ofrecen depende del grueso del cable y de la distancia.
Debido a su bajo coste y su
rendimiento, es un sistema
Es un sistema muy utilizado en los sistemas de telefonía. Generalmente, los muy popular. El coste es el
más económico (más que el
teléfonos de las viviendas están conectadas con la centralita telefónica a través coaxial o la fibra óptica) por
metro, pero tiene unos costes
de pares trenzados (su ancho de banda es de 4 KHz). También se utiliza en las de conectividad parecidos a
LAN a velocidades de 10, 100 y 1.000 Mbps. Es muy utilizado en las conexiones los de otros medios.
punto a punto, y su ámbito geográfico suele ser de unos 100 metros (en redes
Ethernet).
Los primeros pares trenzados no apantallados se llamaban Unshielded Twisted

Pair (UTP). El par trenzado habitualmente se agrupaba en cuatro pares trenza-
dos más dentro de una protección de plástico. Este tipo de cable se llamaba de
categoría 3. Después se introdujeron los cables de categoría 5, agrupamientos
con más densidad por centímetro de vueltas en el cable, que ofrecían unas
características de mayor calidad sobre largas distancias.
Par trenzado no apantallado (UTP)
Después vino la evolución al tipo de cableado Shielded Twisted Pair (STP), lla-
mado par trenzado apantallado, donde cada par de hilos tiene una protección
individual.
Par trenzado apantallado (STP)

4.1.2. Cable coaxial de banda base
El cable coaxial tiene un recubrimiento superior a los pares trenzados, y fun-

ciona 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, so-
porta velocidades de 1 a 2 Gbps. Se pueden utilizar distancias más largas pero
con velocidades de transmisión más bajas. Este tipo de cable se ha utilizado
para interconectar los equipos de las centrales telefónicas, para alguna red de
área local o para la televisión por cable. Es más económico que la fibra óptica
y más caro que el par trenzado.
4.1.3. Fibra óptica
Un sistema de comunicaciones ópticas está formado por tres componentes:

una fuente de luz, el medio de transmisión y el detector de luz. Convencio-
nalmente, un impulso de luz indica un bit con valor 1, y la ausencia de luz
indica un bit de valor 0. El medio de transmisión es una fibra óptica muy fi-
na. El detector genera un impulso eléctrico cuando la luz incide sobre él. Así
pues, instalando una fuente de luz al inicio de la fibra óptica y un detector de
luz al final de la fibra, tenemos un sistema de transmisión unidireccional que
acepta señales eléctricas, las convierte en impulsos de luz que se transmiten y
se reconvierten en una señal eléctrica al final de la fibra.
La materia prima de la fibra óptica es el vidrio, un material no excesivamente

caro y existente en grandes cantidades en nuestro planeta. El vidrio utilizado
en las fibras ópticas es un vidrio transparente. La velocidad de transmisión es
muy elevada, llegando a varios Gbps en 30 km de distancia.
Fibra óptica
Resumen
En este módulo se han visto en detalle las características y el funcionamiento

de los diferentes niveles de la red. El objetivo del módulo ha sido dar una vi-
sión general del funcionamiento interno de una red de computadores, ya de
área local, ya a gran escala, como es Internet. La aproximación a los niveles
de la red se ha hecho desde los niveles más próximos a las aplicaciones hasta
los niveles más específicos del hardware. En primer lugar se ha introducido el
nivel de transporte que ofrece fiabilidad a la red permitiendo el acceso de dife-
rentes aplicaciones a un único medio de transmisión, la red. Se ha visto que el
funcionamiento de la red se rige en gran medida por el protocolo TCP, que es
orientado a conexión y ofrece garantías de fiabilidad en la red. Para aplicacio-
nes que no requieren garantías existe el protocolo UDP que es usado mayori-
tariamente por aplicaciones en tiempo real. Seguidamente se ha presentado la
capa de red. El nivel de red es primordial para el funcionamiento de Internet
pues nos permite dirigir e identificar los nodos de una red. En este apartado
hemos visto IPv4 e IPv6. Se ha presentado el modelo de direccionamiento y la
problemática actual con el número de direcciones en la red.
Se ha presentado la capa de enlace que abstrae los nodos de la red del medio
físico sobre el que transmiten la información. Se ha visto que esta capa se
encarga de dirigir la información entre nodos físicos adyacentes y garantizar
transmisión fiable entre ellos. Hay que destacar la tarea de la subcapa de con-
trol de acceso al medio que permite transmitir información entre dos nodos
independientemente de la tecnología de red utilizada, ya sea inalámbrica o ca-
bleada. Finalmente, se ha hecho una breve introducción al nivel físico que se
encarga de los aspectos de modulación y codificación de las señales físicas que
son dependientes directamente de la tecnología y el medio de transmisión. Se
han visto los principales medios de transmisión.
Bibliografía
Almquist, P. (1992, julio). "RFC-1349: Type of Service in the Internet Protocol Suite". Con-
sultant.
Bing, B. (2000). High-Speed Wireless ATM and LAN. Londres: Artech House. ISBN 1-58053-
092-3.
Bing, B. (2000). Broadband Wireless Access. Dordrecht: Kluwer Academic Publishers. ISBN
0-7923-7955-1.
Croft, B.; Gilmore, J. (1985, septiembre). "RFC-951: Bootstrap Protocol (BOOTP)". Stanford
University & Sun Microsystems,
Dijkstra, E. W. (1959). "A note on two problems in connexion with graphs". Numerische
Mathematik (núm. 1, pág. 269-271).
Droms, R. (1993, octubre). "RFC-1531: Dynamic Host Configuration Protocol". Lewisburg:

Bucknell University.
Gartner, F. C. (2003). A Survey of Self-Stabilizing Spanning-Tree Construction Algorithms. Lau-

sana: 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 Specifi-

cation". Marina del Rey: Information Sciences Institute, University of Southern California.
Intel Corporation (1999, 20 septiembre). "Preboot Execution Environment (PXE) Specifi-

cation".
Kent, S.; Seo, K. (2005, diciembre). "RFC-4301: Security Architecture for the Internet Pro-
tocol". 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 (BGP-
4)".
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 Trans-
lator (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 Profes-
sional Technical Reference.
Seguridad en la
red
PID_00147721
© FUOC • PID_00147721 Seguridad en la red
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 7
1. Cortafuegos.......................................................................................... 9
1.1. Sistemas cortafuegos ................................................................... 10
1.2. Construcción de sistemas cortafuegos ........................................ 11
1.2.1. Encaminadores con filtrado de paquetes ...................... 11
1.2.2. Pasarela en el ámbito de aplicación .............................. 13
2. Redes privadas virtuales.................................................................. 16

2.1. Definición y tipo de redes privadas virtuales ............................. 16
2.2. Configuraciones y protocolos utilizados en VPN ....................... 17
3. Introducción a la criptografía....................................................... 20
3.1. Criptografía de clave simétrica ................................................... 22
3.1.1. Algoritmos de cifrado de flujo ...................................... 24
3.1.2. Algoritmos de cifrado de bloque ................................... 26
3.1.3. Uso de los algoritmos de clave simétrica ....................... 29
3.1.4. Funciones hash seguras .................................................. 32
3.2. Criptografía de clave pública ...................................................... 34
3.2.1. Algoritmos de clave pública .......................................... 34
3.2.2. Uso de la criptografía de clave pública .......................... 37
3.2.3. Infraestructura de clave pública .................................... 38
4. Certificados digitales........................................................................ 39
4.1. Cadenas de certificados y jerarquías de certificación ................. 40
4.2. Listas de revocación de certificados ............................................ 40
5. 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
5.3. Protocolos de seguridad .............................................................. 46
5.3.1. PGP ................................................................................. 47
5.4. SSL ............................................................................................... 49
5.4.1. Características del protocolo SSL/TLS ............................ 50
5.4.2. El transporte seguro SSL/TLS ......................................... 52

5.5. Transacciones seguras en red ...................................................... 58
5.5.1. Secure Electronic Transaction ........................................ 58
5.5.2. 3D-Secure ....................................................................... 59
Resumen....................................................................................................... 60
Bibliografía................................................................................................. 63
© FUOC • PID_00147721 5 Seguridad en la red
Introducción
La seguridad en la red es un aspecto de primordial importancia. Cada día apa-

recen nuevas aplicaciones remotas o en red; estas aplicaciones almacenan la
información en hardware remoto y requieren intercambios de datos constan-
tes entre nuestros ordenadores personales y los servidores remotos. Todo este
flujo de información hace necesaria la existencia de mecanismos para evitar
el uso malicioso de la información y asegurar la privacidad y protección de
los usuarios de la red.
A la hora de proteger las redes de comunicaciones, la criptografía es la herra-

mienta fundamental que nos permite evitar que alguien intercepte, manipule
o falsifique los datos transmitidos. Dedicaremos una parte de este módulo a
introducir los conceptos de la criptografía necesarios para entender cómo se
aplica a la protección de las comunicaciones.
La finalidad básica de la criptografía es el envío de información secreta. Si

aplicamos una transformación, conocida como cifrado, a la información que
queremos mantener en privado, aunque un adversario consiga ver qué datos
estamos enviando le serán completamente ininteligibles. Sólo el destinatario
legítimo será capaz de hacer la transformación inversa y recuperar los datos
originales.
En el módulo también estudiaremos los sistemas cortafuegos que se encarga-

rán de proteger el acceso a determinados puntos de la red. Veremos que un
sistema cortafuegos actúa como una barrera central para reforzar el control
de acceso a los servicios que se ejecutan tanto en el interior como el exterior
de la red. El cortafuegos intenta prevenir los ataques del exterior contra las
máquinas internas de una red denegando peticiones de conexión desde partes
no autorizadas.
Por otra parte veremos también que existen redes�privadas�virtuales que se

construyen haciendo uso de los nodos de una red, pero que, mediante técnicas
criptográficas y protocolos seguros, permiten aislar a los usuarios de esta red
de los de la red de comunicación.
Finalmente haremos una pasada por los diferentes protocolos y aplicaciones

más relevantes para asegurar las redes de comunicaciones. Conoceremos las
cookies, los contenidos dinámicos y cómo éstos pueden afectar a la seguridad
de una sitio web. La existencia de protocolos como SSL/TLS en el nivel de
transporte ha permitido que se pueda dotar de seguridad a las aplicaciones
en red y a sus protocolos. En este módulo también conoceremos el funciona-

miento de estos protocolos y, de paso, cómo se pueden hacer transacciones
seguras en la red.
Objetivos
El estudio de este módulo os permitirá alcanzar los objetivos siguientes:
1. Conocer los principales mecanismos de seguridad en la red.
2. Conocer los fundamentos de la criptografía y los certificados digitales.
3. Tener una visión global de los elementos de la red que pueden precisar
mecanismos de seguridad y conocer los posibles puntos débiles de una red
de computadores.
1. Cortafuegos
Cuando un equipo está conectado a una red de computadores se pueden iden-

tificar tres áreas de riesgo:
1) El número de puntos que se pueden utilizar como origen para realizar un

ataque contra cualquier componente de la red se incrementa. En un sistema
aislado (sin conexión), un requisito necesario para ser atacado es forzosamente
la existencia de un acceso físico al equipo. Pero en el caso de un sistema en
red, cada uno de los equipos que pueda enviar información hacia la víctima
podrá ser utilizado por un posible atacante.
Algunos servicios (como por ejemplo web y DNS) necesitan estar abiertos pú-
blicamente, de forma que cualquier equipo conectado a Internet podría ser el
origen de una posible actividad maliciosa contra ellos. Eso hace que sea muy
probable la existencia de ataques regulares contra estos sistemas.
2) La segunda área de riesgo incluye la expansión del perímetro físico del sis-
tema telemático al que acaba de ser conectado el equipo. Cuando la máquina
está aislada, cualquier actividad puede ser considerada como interna del equi-
po (y por lo tanto, de confianza). El procesador trabaja con los datos que en-
cuentra en la memoria, que al mismo tiempo han sido cargados desde un me-
dio de almacenamiento secundario. Estos datos están realmente bien protegi-
dos contra actos de modificación, eliminación, observación maliciosa, etc., ya
que se transfieren entre diferentes componentes de confianza.
Pero esta misma premisa no es cierta cuando los datos son transferidos a tra-
vés de una red. La información transmitida por el medio de comunicación es
reenviada por dispositivos que están totalmente fuera del control del recep-
tor. Esta información podría ser leída, almacenada, modificada y más tarde
retransmitida hacia el receptor legítimo. Especialmente en grandes redes co-
mo Internet, no es trivial la autenticación del origen que se presenta como el
emisor de un mensaje.
3) Finalmente, la tercera área de riesgo se debe al aumento del número de ser-

vicios de autenticación (generalmente un servicio de login-password) que un
sistema conectado a la red tiene que ofrecer, con respecto a un sistema aislado.
Estos servicios no dejan de ser simples aplicaciones (con posibles errores de
programación o de diseño) que protegen el acceso a los recursos de los equi-
pos del sistema. Un error o vulnerabilidad en alguno de estos servicios puede
poner en apuros a todo el sistema.
La prevención de ataques es la suma de una serie de mecanismos de

seguridad que proporcionan un primer nivel de defensa contra cierto
tipo de ataques antes de que éstos lleguen a su objetivo.
1.1. Sistemas cortafuegos
(1)
Los sistemas cortafuegos1 son un mecanismo de control de acceso sobre la capa En inglés, firewall.
de red. La idea básica es separar nuestra red (donde los equipos que intervienen
son de confianza) de los equipos del exterior (potencialmente hostiles).
Un sistema cortafuegos actúa como una barrera central para reforzar el control
de acceso a los servicios que se ejecutan tanto en el interior como en el exterior
de la red. El cortafuegos intentará prevenir los ataques del exterior contra las
máquinas internas de nuestra red denegando peticiones de conexión desde
partes no autorizadas.
Un cortafuegos puede ser cualquier dispositivo utilizado como mecanismo de

control de acceso a nivel de red para proteger una red en particular o un con-
junto de redes. En la mayoría de los casos, los sistemas cortafuegos se utilizan
para prevenir accesos ilícitos al interior de la red.
Un cortafuegos es aquel sistema de red expresamente encargado de se-

parar redes de computadores y efectuar un control del tráfico existen-
te entre ellas. Este control consiste, en última instancia, en permitir o
denegar el paso de la comunicación de una red a otra mediante el con-
trol de los protocolos Transmission Control Protocol/Internet Protocol
(TCP/IP).
A la hora de instalar y configurar un sistema cortafuegos en nuestra red, se

tiene que tener presente lo siguiente:
1) Todo el tráfico que sale del interior hacia el exterior de la red a proteger, y
viceversa, tiene que pasar por el cortafuegos. Eso se puede conseguir bloquean-
do físicamente todo el acceso al interior de la red a través del sistema.
2) Sólo el tráfico autorizado, definido en las políticas de seguridad local del

sistema, podrá traspasar el bloqueo.
3) El propio cortafuegos tiene que estar protegido contra posibles intrusiones.

Eso implica el uso de un sistema operativo de confianza con suficientes garan-
tías de seguridad.
1.2. Construcción de sistemas cortafuegos
En el sentido más general, un sistema cortafuegos consta de software y hard-

ware. El software puede ser propietario, shareware, o freeware. Por otra parte,
el hardware podrá ser cualquiera que pueda soportar este software.
Actualmente, dos de las tecnologías más utilizadas a la hora de construir sis-

temas cortafuegos son las siguientes:
• Encaminadores con filtrado de paquetes.

• Pasarelas en el ámbito de aplicación.
1.2.1. Encaminadores con filtrado de paquetes
Un encaminador con filtrado de paquetes es un dispositivo que enca-

mina el tráfico TCP/IP (encaminador de TCP/IP) sobre la base de una
serie de reglas de filtrado que deciden qué paquetes se encaminan a tra-
vés de él y cuáles son descartados.
Las reglas de filtrado se encargan de determinar si a un paquete le está permi-

tido pasar de la parte interna de la red a la parte externa, y viceversa, verifi-
cando el tráfico de datos legítimo entre ambas partes.
(2)
Los encaminadores con filtrado de paquetes, al trabajar a nivel de red, pueden UDP es la abreviatura de User
Datagram Protocol.
aceptar o denegar paquetes fijándose en las cabeceras del protocolo (tanto IP
como UDP2, TCP...), en las que se incluyen:
• Direcciones de origen y de destino.

• Tipos de protocolo e indicadores especiales.
• Puertos de origen y de destino o tipo de mensaje (según el protocolo).
• Contenido de los paquetes.
• Tamaño del paquete.
Las reglas están organizadas en conjuntos de listas con una determinada polí-
tica por defecto (denegarlo todo, aceptarlo todo...).
Cada paquete que llegue al dispositivo será comparado con las reglas, empe-
zando por el principio de la lista hasta que se encuentre la primera coinciden-
cia. Si existe alguna coincidencia, se activará la acción indicada en la regla
(denegar, aceptar, redirigir...).
Por el contrario, si no es posible ninguna coincidencia, se consultará la política

por defecto para saber qué acción tomar (dejar pasar el paquete, descartarlo,
redireccionarlo, etc.). Si se trata, por ejemplo, de una política de denegación
por defecto, en el caso de no existir ninguna coincidencia con el paquete será
descartado éste.
Una política de denegación por defecto acostumbra a ser más costosa de man-
tener, ya que será necesario que el administrador indique explícitamente todos
los servicios que tienen que permanecer abiertos (el resto, por defecto, serán
todos denegados).
En cambio, una política de aceptación por defecto es más sencilla de adminis-

trar, pero incrementa el riesgo de permitir ataques contra nuestra red, ya que
requiere que el administrador indique explícitamente qué paquetes hay que
descartar (el resto, por defecto, serán todos aceptados).
Ventajas y desventajas de los encaminadores con filtrado de pa-

quetes
La construcción de un sistema cortafuegos mediante un encaminador con fil- Iptables

trado de paquetes es realmente económica, ya que generalmente se suele hacer
Un ejemplo de encaminador
con hardware ya disponible. Además, ofrece un alto rendimiento a redes con con filtro de paquetes podría
una carga de tráfico elevada. ser la aplicación�iptables, im-
plementada como una par-
te del software de direcciona-
miento del kernel Linux.
Adicionalmente, esta tecnología permite la implantación de la mayor parte de
las políticas de seguridad necesarias.
Las políticas de seguridad son el resultado de documentar las expectativas de

seguridad, intentando plasmar en el mundo real los conceptos abstractos de
seguridad. Pueden definirse de manera procesal (plasmando de forma práctica
las ideas o filosofías de la empresa en cuanto a seguridad) o de manera formal
(utilizando un modelo matemático que intente abarcar todos los posibles es-
tados y operaciones).
A pesar de estas ventajas, los encaminadores de red con filtrado de paquetes

pueden presentar algunas deficiencias, como, por ejemplo:
• Muchos de los encaminadores utilizados pueden ser vulnerables a ataques

existentes (aunque la mayoría de los distribuidores tienen los correspon-
dientes paquetes de actualizaciones para solucionarlo). Por otra parte, no
suelen tener capacidades de registro. Eso provoca que al administrador le
sea difícil saber si el propio encaminador está siendo atacado.
• Su capacidad de actuación puede llegar a deteriorarse a causa de la utiliza-

ción de un filtrado excesivamente estricto, dificultando también el proceso
de gestión del dispositivo si este número de reglas llega a ser muy elevado.
• Las reglas de filtrado pueden llegar a ser muy complicadas, lo que provoca
en ocasiones que los posibles descuidos en su configuración sean aprove-
chados por un atacante para realizar una violación de la política de segu-
ridad.
1.2.2. Pasarela en el ámbito de aplicación
(3)
Una pasarela en el ámbito de aplicación, conocida también como servidor En inglés, proxy.
3
intermediario , no direcciona paquetes a nivel de red sino que actúa como
retransmisor en el ámbito de aplicación. Los usuarios de la red contactarán
con el servidor intermediario, que a su vez estará ofreciendo un servicio proxy
asociado a una o más aplicaciones determinadas.
El servicio proxy se encargará de realizar las conexiones solicitadas con el ex-

terior, y cuando reciba una respuesta se encargará de retransmitirla hacia el
equipo que había iniciado la conexión. Así, el servicio proxy ejecutado en la
pasarela aplicará las normas para decidir si se acepta o se rechaza una petición
de conexión.
Una pasarela separa completamente el interior del exterior de la red en la capa

de enlace, ofreciendo únicamente un conjunto de servicios en el ámbito de
aplicación. Eso permite la autenticación de los usuarios que realizan peticiones
de conexión y el análisis de conexiones en el ámbito de aplicación.
Estas dos características hacen que las pasarelas ofrezcan una mayor seguridad
con respecto a los filtros de paquetes, presentando un rango de posibilidades
muy elevado. Por el contrario, la penalización introducida por estos disposi-
tivos es mucho mayor. En el caso de una gran carga de tráfico en la red, el
rendimiento puede llegar a reducirse drásticamente.
En la práctica, las pasarelas y los dispositivos de red con filtrado de paquetes

son complementarios. Así, estos dos sistemas se pueden combinar, lo que pro-
porcionará más seguridad y flexibilidad que si sólo se utilizara uno, tal como
se muestra en la figura siguiente.
Cuando la pasarela autentifica al cliente, abre una conexión al servidor proxy,

siendo éste el responsable de transmitir los datos que el cliente recibe del ser-
vidor intermediario.
Este funcionamiento particular provoca que las pasarelas en el ámbito de apli-

cación presenten un rendimiento inferior al de los filtros de paquetes. Con
el fin de evitarlo, los servidores intermediarios hacen una copia de los datos
transmitidos para entregárselos a otro cuando éste los solicite.
El uso de las pasarelas proporciona diversos beneficios. De entrada, las pasa-

relas permiten sólo aquellos servicios para los cuales hay un servidor proxy
habilitado. Así, si una pasarela contiene servicios intermediarios tan sólo para
los servicios HTTP y DNS, entonces sólo HTTP y DNS serán permitidos en la
red interna. El resto de los servicios serán completamente rechazados.
Otro beneficio del uso de pasarelas es que el protocolo también puede ser fil-
trado, prohibiendo así el uso de diferentes subservicios dentro de un mismo
servicio permitido. Por ejemplo, mediante una pasarela que filtrara conexio-
nes FTP, sería posible prohibir únicamente el uso del comando PUT de FTP
dejando habilitados el resto de comandos. Esta característica no es posible ob-
tenerla sólo con el uso de filtros de paquetes.
Adicionalmente, los servidores intermediarios también pueden implantar el

filtro de conexiones por dirección IP de la misma manera que los filtros de
paquetes, ya que la dirección IP está disponible en el ámbito de aplicación en
el cual se hará el filtrado.
A pesar de obtener más control global sobre los servicios vigilados, las pasarelas
también presentan algunas problemáticas. Uno de los primeros inconvenien-
tes a destacar es la necesidad de tener que configurar un servidor proxy para
cada servicio de la red que se ha de vigilar (HTTP, DNS, Telnet, FTP...). Además,
en el caso de protocolos cliente-servidor, como, por ejemplo, Telnet, pueden
llegar a ser necesarios algunos pasos adicionales para conectar el punto final
de la comunicación.
2. Redes privadas virtuales
Los protocolos seguros que hemos visto hasta ahora permiten proteger las co-
municaciones, por ejemplo, de una aplicación implementada como un pro-
ceso cliente que se ejecuta en un ordenador y un proceso servidor que se eje-
cuta en otro ordenador. Si hay otras aplicaciones que también necesitan una
comunicación segura entre estos dos ordenadores, o entre ordenadores situa-
dos en las mismas redes locales, pueden hacer uso de otras instancias de los
protocolos seguros: nuevas asociaciones de seguridad IPsec, nuevas conexio-
nes SSL TLS, etc.
(4)
Una posibilidad alternativa es establecer una red privada virtual4 entre estos En inglés, Virtual Private Net-
work (VPN).
ordenadores o las redes locales en las que están situados.
2.1. Definición y tipo de redes privadas virtuales
Una red�privada�virtual (VPN) es una configuración que combina el

uso de dos tipos de tecnologías:
• Las tecnologías de seguridad que permiten la definición de una red

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

en vez de una conexión física dedicada a la red privada, se pueda
utilizar una infraestructura de red pública, como es Internet, para
definir por encima de ella una red�virtual.
Por lo tanto, una VPN es una red lógica o virtual creada sobre una infraestruc-
tura compartida, pero que proporciona los servicios de protección necesarios
para una comunicación segura.
Dependiendo de la situación de los nodos que hacen uso de esta red, podemos
considerar tres tipos de VPN:
1) Éste es el caso habitual en que una empresa dispone de redes locales en

diferentes sedes, geográficamente separadas, en cada una de las cuales hay
una red privada o intranet, de acceso restringido a sus empleados. Si interesa
que desde una de las sedes se pueda acceder a las intranets de las otras sedes,
se puede usar una VPN para interconectar estas redes privadas y formar una
intranet única.
2) Cuando un empleado de la empresa quiere acceder a la intranet desde un

ordenador remoto, puede establecer una VPN de este tipo entre este ordenador
y la intranet de la empresa. El ordenador remoto puede ser, por ejemplo, un
PC que el empleado tiene en su casa, o un ordenador portátil desde el que se
conecta a la red de la empresa cuando está de viaje.
3) A veces, a una empresa le interesa compartir una parte de los recursos de su

intranet con determinados usuarios externos, como, por ejemplo, proveedores
o clientes de la empresa. La red que permite estos accesos externos a una intra-
net se llama extranet, y su protección se alcanza mediante una VPN extranet.
2.2. Configuraciones y protocolos utilizados en VPN
A cada uno de los tipos de VPN le suele corresponder una configuración es-
pecífica.
• En las VPN entre intranets, la situación más habitual es que en cada in-
tranet haya una pasarela�VPN que conecta la red local con Internet. Esta
pasarela se comunica con la de las otras intranets, aplicando el cifrado y
las protecciones que sean necesarias para las comunicaciones de pasarela
a pasarela a través de Internet. Cuando los paquetes llegan a la intranet
de destino, la pasarela correspondiente los descifra y los reenvía por la
red local hasta el ordenador que los tenga que recibir. De esta manera se
utiliza la infraestructura pública como Internet, en lugar de establecer lí-
neas privadas dedicadas, que supondrían un coste más elevado. También
se aprovecha la fiabilidad y redundancia que proporciona Internet, ya que
si una ruta no está disponible siempre se pueden encaminar los paquetes
por otro lugar, mientras que con una línea dedicada la redundancia supo-
ne un coste todavía mayor.
(5)
• En las VPN de acceso remoto, a veces llamadas VPDN5, un usuario se puede VPDN son las siglas de Virtual
Private Dial Network.
comunicar con una intranet a través de un proveedor de acceso a Internet,
utilizando tecnología convencional, como, por ejemplo, a través de un
módem ADSL. El ordenador del usuario tiene que disponer de software
cliente�VPN para comunicarse con la pasarela VPN de la intranet y llevar a
cabo la autenticación necesaria, el cifrado, etc. Así, también se aprovecha
la infraestructura de los proveedores de Internet para el acceso a la intranet,
sin necesidad de llamadas a un módem de la empresa, que pueden llegar
a tener un coste considerable.
• El caso de las VPN extranet puede ser como el de las VPN entre intranets,
en las que la comunicación segura se establece entre pasarelas VPN, o bien
como el de las VPN de acceso remoto, en las que un cliente VPN se comu-
nica con la pasarela de la intranet. La diferencia, sin embargo, es que, en
este caso, normalmente el control de acceso es más restrictivo para permi-
tir sólo el acceso a los recursos autorizados.
La definición de una red virtual se lleva a cabo mediante el establecimiento

de túneles, que permiten encapsular paquetes de la red virtual, con sus pro-
tocolos, dentro de paquetes de otra red, que normalmente es Internet, con su
protocolo, es decir IP.
Para la comunicación entre las diferentes intranets, o entre el ordenador que

accede remotamente y la intranet, se pueden utilizar los protocolos que sean
más convenientes. Los paquetes de estos protocolos, para poder hacerlos llegar
a su destino a través de Internet, se pueden encapsular en datagramas IP, que
contendrán en su interior los paquetes originales. Cuando llegan a su destino,
estos datagramas se desencapsulan para recuperar los paquetes con el formato
"nativo" del protocolo correspondiente.
Uso de túneles en una VPN
Hay diversos protocolos que pueden ser utilizados para establecer los túneles,
dependiendo del nivel de la comunicación en el que se quiera hacer la pro-
tección.
El protocolo utilizado en la gran mayoría de configuraciones VPN es IPsec en

modo túnel, generalmente con ESP para cifrar los datos, y opcionalmente con
AH para autenticar los paquetes encapsulados. Las pasarelas VPN, en este caso,
son pasarelas seguras Ipsec.
En el caso de las VPN de acceso remoto o VPDN, existe la posibilidad de en-

capsular tramas PPP, que son las que transmite normalmente un cliente VPN
de este tipo, sobre datagramas IP. Hay diversas opciones para encapsular PPP
(que, a su vez, puede encapsular otros protocolos de red, como IPX, etc., y
posiblemente IP) sobre IP:
(6)
• 6
El protocolo PPTP (RFC 2637) especifica una técnica para la encapsulación PPTP es la abreviatura de Point-
to-Point Tunneling Protocol.
de tramas PPP pero no añade servicios de autenticación. Estos servicios se
pueden realizar con los mismos protocolos que utiliza PPP, como Password
Authentication Protocol (BUCHE) o Challenge Handshake Authentication
Protocol (CHAP).
(7)
• 7
El protocolo L2F (RFC 2637) es parecido al PPTP pero también puede tra- L2F es la abreviatura de Layer
Two Forwarding.
bajar con SLIP, además de con PPP. Para la autenticación puede utilizar
protocolos auxiliares como Remote Authentication Dial-In User Service
(RADIUS).
(8)
• El protocolo L2TP8 (RFC 2661) combina las funcionalidades que ofrecen L2TP es la abreviatura de Layer
Two Tunneling Protocol.
PPTP y L2F.
(9)
SSH es la abreviatura de Secure
• 9
El protocolo SSH ofrece la posibilidad de redirigir puertos TCP sobre un Shell.
canal seguro, que podemos considerar como un túnel a nivel de transpor-

te. Desde este punto de vista, también se podría considerar una conexión
SSL TLS como un túnel en el ámbito del transporte que proporciona con-
fidencialidad y autenticación. Habitualmente, sin embargo, este último
tipo de túnel no sirve para cualquier tipo de tráfico sino sólo para datos
TCP, y por lo tanto no se considera parte integrante de una VPN.
3. Introducción a la criptografía
A lo largo de la historia se han diseñado diferentes técnicas para ocultar el Criptografía

significado de la información que no interesa que sea conocida por extraños.
Los términos criptografía, crip-
Algunas de ellas ya se utilizaban en tiempo de la antigua Grecia o del Imperio tología, etc. provienen de la
romano: por ejemplo, se atribuye a Julio César la invención de un código para raíz griega kryptós, que quiere
decir 'escondido'.
enviar mensajes cifrados que no pudieran ser interpretados por el enemigo.
La criptografía estudia, desde un punto de vista matemático, los méto-

dos para proteger la información. Por otra parte, el criptoanálisis estu-
dia las posibles técnicas para contrarrestar los métodos criptográficos,
y es de gran utilidad para ayudar a hacerlos más robustos y difíciles
de atacar. El conjunto formado por estas dos disciplinas, criptografía y
criptoanálisis, se llama criptología.
Uso del cifrado
El hecho de usar el cifrado parte de la constatación de que intentar evitar la interceptación

de la información por parte de un intruso (espía) es muy costoso. Enviar mensajes cifrados
es más fácil, y así, aunque un espía los pueda ver, no podrá interpretar la información
que contienen.
Cuando la protección que queremos obtener consiste en garantizar el secreto

de la información, es decir, la confidencialidad, utilizamos el método cripto-
gráfico conocido como cifrado.
Si M es el mensaje que queremos proteger o texto�en�claro, cifrarlo consiste

en aplicarle un algoritmo de cifrado f, que lo transforme en otro mensaje que
llamaremos texto�cifrado, C. Eso lo podemos expresar como:
C = f(M)
A fin de que este cifrado sea útil, tiene que existir otra transformación o algo-
ritmo de descifrado f-1, que permita recuperar el mensaje original a partir del
texto cifrado:
M - f-1 (C)
La cifra de César
La cifra�de�César consiste en sustituir cada letra del mensaje por la que hay tres posicio-
nes después en el alfabeto (volviendo a empezar por la letra A si llegamos a la Z). Así, si
aplicamos este algoritmo de cifrado al texto en claro "ALEA JACTA EST" (y utilizamos el
alfabeto latino actual, porque en tiempos de César no había letras como la "W"), obtene-
mos el texto cifrado "DOHD MDFWD HVW". El descifrado en este caso es bien sencillo:
sólo hay que sustituir cada letra por la que hay 3 posiciones después en el alfabeto.
Un esquema como el de la cifra de César tiene el inconveniente de que si el

enemigo descubre cuál es el algoritmo de cifrado (y a partir de aquí deduce el
algoritmo inverso), será capaz de interpretar todos los mensajes cifrados que
capture. Entonces, habría que instruir a todos los "oficiales de comunicacio-
nes" del ejército para que aprendieran un nuevo algoritmo, lo cual podría re-
sultar complicado. En vez de eso, lo que se hace hoy es utilizar como algoritmo
una función con un parámetro denominado clave.
Ejemplo de uso de una clave
El algoritmo de Julio César se puede generalizar definiendo una clave k que indique cuán-
tas posiciones se adelanta cada letra en el alfabeto. La cifra de César, pues, utiliza k = 3.
Para el descifrado se puede utilizar el mismo algoritmo, pero con la clave invertida (de
º e, x = -k).
Entonces, podemos hablar de una función de cifrado e con una clave de cifra-
do k, y una función de descifrado d con una clave�de�descifrado x:
C = e(k,M)
M = d(x,C) = d(x,e(k,M))
Así, una solución al problema del espía que se entera de cómo descifrar los
mensajes podría ser continuar utilizando el mismo algoritmo, pero con una
clave diferente.
Seguridad por ocultismo
A lo largo de la historia ha habido casos que han demostrado la peligrosidad de basar

la protección en mantener los algoritmos en secreto (lo que se conoce como "seguridad
por ocultismo"). Si el algoritmo es conocido por muchos, es más fácil que se detecten las
debilidades o vulnerabilidades y se puedan corregir rápidamente. Si no, un experto po-
dría deducir el algoritmo por ingeniería inversa, y acabar descubriendo que tiene puntos
débiles por donde atacarlo, como pasó con el algoritmo A5/1 de la telefonía móvil GSM.
Una premisa fundamental en la criptografía moderna es la llamada su-

posición�de�Kerckhoffs, de acuerdo con la cual los algoritmos tienen
que ser conocidos públicamente y su seguridad sólo tiene que depen-
der de la clave. En lugar de intentar ocultar el funcionamiento de los
algoritmos, es mucho más seguro y efectivo mantener en secreto sólo
las claves.
Un algoritmo se considera seguro si a un adversario le es imposible obtener el

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

no puede ser invertido ni con recursos infinitos. Los algoritmos que se hacen
servir en la práctica son (o intentan ser) computacionalmente seguros.
La acción de intentar descifrar mensajes sin conocer la clave de descifrado se

llama "ataque". Si el ataque tiene éxito, se suele decir coloquialmente que se
ha conseguido "romper" el algoritmo. Hay dos maneras de llevar a cabo un
ataque:
• Mediante el criptoanálisis, es decir, estudiando matemáticamente la ma-

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

gráficos utilizados en la protección de las comunicaciones. A partir de ahora,
consideraremos los mensajes en claro, los mensajes cifrados y las claves como
secuencias de bits.
3.1. Criptografía de clave simétrica
Los sistemas criptográficos de�clave�simétrica se caracterizan por que la

clave de descifrado x es idéntica a la clave de cifrado k, o bien se puede
deducir directamente a partir de ésta.
Para simplificar, supondremos que en este tipo de sistemas la clave de desci-

frado es igual a la de cifrado: x = k (si no, siempre podemos considerar que en
el algoritmo de descifrado el primer paso es calcular la clave x a partir de la k).
Por eso, estas técnicas criptográficas se llaman de clave simétrica, y, a veces,
también de clave�compartida. Así, tenemos:
C = e(k,M)
M = d(k,C) = d(k,e(k,M))
La seguridad del sistema reside, pues, en mantener en secreto la clave k. Cuan-

do los participantes en una comunicación quieren intercambiarse mensajes
confidenciales, tienen que escoger una clave secreta y utilizarla para cifrar los
mensajes. Entonces pueden enviar estos mensajes por cualquier canal de co-
municación, en la confianza de que, aunque el canal sea inseguro y susceptible
de ser inspeccionado por terceros, ningún espía Z será capaz de interpretarlos.
Si el sistema es de clave compartida, es necesario que el valor de la clave secreta

k que utilizan A y B sea el mismo. Ahora bien, ¿cómo se pueden asegurar de
que sea así? Está claro que no pueden enviar la clave escogida a través del canal
de comunicación de que disponen, porque la hipótesis inicial es que este canal
es inseguro y cualquiera podría descubrir la información que se transmite.
Una posible solución es utilizar un canal aparte, que pueda ser considerado
suficientemente seguro:
Canales seguros
Podrían ser ejemplos de "cana-

les seguros" el correo tradicio-
nal (no electrónico) o un servi-
cio de mensajería "física", una
conversación telefónica o cara
a cara, etc.
Esta solución, sin embargo, tiene algunos inconvenientes. Por una parte, se
supone que el canal seguro no será de uso tan ágil como el canal inseguro (si
lo fuera, sería mucho mejor enviar todos los mensajes confidenciales sin cifrar
por el canal seguro, y olvidarnos del canal inseguro). Por lo tanto, puede ser
difícil ir cambiando la clave. Y por otra parte, este esquema no es bastante
general: puede ser que tengamos que enviar información cifrada a alguien
con quien no podemos contactar de ninguna otra manera. Como veremos

más adelante, estos problemas relacionados con el intercambio�de�claves se
solucionan con la criptografía asimétrica.
A continuación repasaremos las características básicas de los principales algo-

ritmos criptográficos de clave simétrica, los cuales agruparemos en dos cate-
gorías: algoritmos de flujo y algoritmos de bloque.
3.1.1. Algoritmos de cifrado de flujo
El funcionamiento de una cifra de flujo consiste en combinar el texto

en claro M con un texto de cifrado S que se obtiene a partir de la clave
simétrica k. Para descifrar sólo hay que hacer la operación inversa con
el texto cifrado y el mismo texto de cifrado S.
La operación de combinación que se utiliza típicamente es la suma, y la ope-

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

En efecto, cuando se aplican bit a bit, las dos son idénticas a la operación lógica
"o exclusiva", denotada con el operador XOR ("eXclusive OR'') o el símbolo ⊕.
Así, pues:
C = M⊕ S(k)
M = C⊕ S(k)
En los esquemas de cifrado de flujo, el texto en claro M puede ser de cualquier

longitud, y el texto de cifrado S tiene que ser al menos igual de largo. De
hecho, no hay que disponer del mensaje entero antes de empezar a cifrarlo
o descifrarlo, ya que se puede implementar el algoritmo para que trabaje con
un "flujo de datos" que va llegando (el texto en claro o el texto cifrado) y otro
"flujo de datos" que se va generando a partir de la clave (el texto de cifrado). De
aquí procede el nombre de este tipo de algoritmos. La figura siguiente ilustra
el mecanismo básico de su implementación.
Esquema del cifrado y descifrado de flujo
Hay diferentes maneras de obtener el texto de cifrado S en función de la clave

k:
• Si se escoge una secuencia k más corta que el mensaje M, una posibilidad

sería repetirla cíclicamente tantas veces como haga falta para ir sumándola
al texto en claro. El inconveniente de este método es que se puede romper
fácilmente, sobre todo cuanto más corta sea la clave (en el caso mínimo,
el algoritmo sería equivalente a la cifra de César).
• En el otro extremo, se podría hacer directamente S(k) = k. Eso quiere decir

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

pseudoaleatorias a partir de una semilla (un número que actúa como
parámetro del generador), y lo que se intercambia como clave secreta k es
sólo esta semilla.
Ejemplo de funciones pseudoaleatorias
Son ejemplos de funciones pseudoaleatorias las basadas en registros de desplazamiento

realimentados (feedback shift registers o FSR). El valor inicial del registro es la semilla.
Para ir obteniendo cada bit pseudoaleatorio se desplazan todos los bits del registro una
posición y se coge el que sale fuera del registro. El bit que queda libre en el otro extremo
se llena con un valor que es función del resto de bits.
Las secuencias pseudoaleatorias se llaman así porque intentan parecer aleato-

rias pero, claro está, son generadas algorítmicamente. En cada paso, el algorit-
mo estará en un determinado estado, que vendrá dado por sus variables inter-
nas. Como las variables serán finitas, habrá un número máximo de posibles
estados diferentes. Eso quiere decir que, al cabo de un cierto período, los datos
generados se volverán a repetir. Para que el algoritmo sea seguro, interesa que
el período de repetición sea cuanto más largo mejor (con relación al mensaje a
cifrar), con el fin de dificultar el criptoanálisis. Las secuencias pseudoaleatorias
también han de tener otras propiedades estadísticas equivalentes a las de las
secuencias aleatorias puras.
Cifras�síncronas�y�asíncronas
Si el texto de cifrado S depende exclusivamente de la clave k, se dice que

el cifrado es síncrono. Este cifrado tiene el problema de que, si por algún
error de transmisión se pierden bits (o llegan repetidos), el receptor se
desincronizará y sumará bits del texto S con bits del texto cifrado C
que no tocan, con lo cual el texto descifrado a partir de entonces será
incorrecto.
Eso se puede evitar con el cifrado asíncrono (o "autosincronizante"), en

el cual el texto S se calcula a partir de la clave k y el mismo texto cifrado
C. Es decir, en vez de realimentarse con sus propios bits de estado, el
generador se realimenta con los n últimos bits cifrados transmitidos.
De esta manera, si se pierden m bits consecutivos en la comunicación,
el error afectará como máximo al descifrado de m + n bits del mensaje
original.
Ejemplos de algoritmos de cifrado de flujo
Los algoritmos de cifrado de flujo actualmente en uso tienen la propiedad de ser poco
costosos de implementar. Las implementaciones en hardware son relativamente simples
y, por lo tanto, tienen un rendimiento eficiente (en términos de bits cifrados por segun-
do). Pero también las implementaciones en software pueden ser bastante eficientes.
Las características del cifrado de flujo lo hacen apropiado para entornos en los que haga
falta un rendimiento alto y los recursos (capacidad de cálculo, consumo de energía) sean
limitados. Por eso se suelen utilizar en comunicaciones móviles: redes locales sin hilos,
telefonía móvil, etc.
3.1.2. Algoritmos de cifrado de bloque
En una cifra de bloque, el algoritmo de cifrado o descifrado se aplica

separadamente a bloques de entrada de longitud fija b, y para cada uno
de ellos el resultado es un bloque de la misma longitud.
Para cifrar un texto en claro de L bits hace falta dividirlo en bloques de b

bits cada uno y cifrar estos bloques uno a uno. Si L no es múltiplo de b, se
pueden añadir bits adicionales hasta llegar a un número entero de bloques,
pero entonces puede ser necesario indicar de alguna manera cuántos bits había
realmente en el mensaje original. El descifrado también se tiene que realizar
bloque a bloque. La figura siguiente muestra el esquema básico del cifrado de
bloque.
Esquema del cifrado de bloque
Muchos de los algoritmos de cifrado de bloque se basan en la combinación de

dos operaciones básicas: sustitución y transposición.
La sustitución consiste en traducir cada grupo de bits de la entrada a

otro, de acuerdo con una permutación determinada.
La cifra de César sería un ejemplo simple de sustitución, en el que cada grupo

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

ro según un patrón determinado.
Ejemplo de transposición
Un ejemplo de transposición podría ser formar grupos de cinco letras, incluidos los es-
pacios en blanco, y reescribir cada grupo (1,2,3,4,5) en el orden (3,1,5,4,2):
Texto�en�claro: A L E A J A C T A E S T
Texto�cifrado: E A A L C J A T A S T E
La transposición por sí sola no dificulta extraordinariamente el criptoanálisis,

pero puede combinarse con otras operaciones para añadir complejidad a los
algoritmos de cifrado.
El producto�de�cifras, o combinación en cascada de diversas transformacio-

nes criptográficas, es una técnica muy efectiva para implementar algoritmos
bastante seguros de manera sencilla. Por ejemplo, muchos algoritmos de ci-
frado de bloque se basan en una serie de iteraciones de productos sustitución-
transposición.
Confusión�y�difusión
Dos propiedades deseables en un algoritmo criptográfico son la "confu-

sión", que consiste en esconder la relación entre la clave y las propieda-
des estadísticas del texto cifrado, y la "difusión", que propaga la redun-
dancia del texto en claro a lo largo del texto cifrado para que no sea
fácilmente reconocible.
La confusión hace que cambiando un solo bit de la clave cambien mu-

chos bits del texto cifrado, y la difusión hace que el cambio de un solo
bit del texto en claro afecte también a muchos bits del texto cifrado.
En un bucle de productos de cifras básicas, la sustitución contribuye

a la confusión, mientras que la transposición contribuye a la difusión.
La combinación de estas transformaciones simples, repetidas diversas
veces, hace que los cambios en la entrada se propaguen por toda la salida
por un "efecto avalancha".
Ejemplos de algoritmos de cifrado de bloque
Durante muchos años el algoritmo de cifrado de bloque ha sido el algoritmo más estu-
diado y, al mismo tiempo, el más utilizado. Desarrollado por IBM durante los años seten-
ta, fue adoptado por el NBS norteamericano (nombre que tenía entonces el actual NIST)
como estándar para el cifrado de datos del año 1977. NBS y NISTNBS eran las siglas de
National Bureau of Standards, y NIST son las siglas de National Institute of Standards
and Technology.
El algoritmo admite una clave de 64 bits, pero sólo 7 de cada 8 intervienen en el cifrado.
Un posible uso de los bits de la clave DES que no influyen en el algoritmo es como bits
de paridad, de manera que la longitud efectiva de la clave es de 56 bits. Los bloques de

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

escoger el algoritmo que sea más apropiado a las necesidades de cada aplica-
ción: normalmente, a más seguridad menos velocidad de cifrado, y viceversa.
Un aspecto a tener en cuenta es que si bien el cifrado puede hacer que un ata-
cante no descubra directamente los datos transmitidos, a veces es posible que
se pueda deducir información indirectamente. Por ejemplo, en un protocolo
que utilice mensajes con una cabecera fija, la aparición de los mismos datos
cifrados varias veces en una transmisión puede indicar dónde empiezan los
mensajes.
Eso no pasa con las cifras de flujo si su período es lo bastante largo, pero en
una cifra de bloque, si dos bloques de texto en claro son iguales y se utiliza
la misma clave, los bloques cifrados también serán iguales. Para contrarrestar
esta propiedad, se pueden aplicar en diversos modos�de�operación a las cifras
de bloque:
1)�Modo�ECB�(Electronic�Codebook). Es el más sencillo, y consiste simplemen- Nombre del modo ECB

te en dividir el texto en bloques y cifrar cada uno de manera independiente.
Modo ECB (Electronic Code-
Este modo presenta el problema de dar bloques iguales cuando en la entrada book) da la idea de que se pue-
hay bloques iguales. de considerar como una sim-
ple sustitución bloque a blo-
que, de acuerdo con un códi-
Modo de operación ECB go o diccionario (con muchas
entradas, eso sí) que viene da-
do por la clave.
2)�Modo�CBC�(Cipher�Block�Chaining). En el modo CBC, antes de cifrar cada

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

Modo CFB como cifra de
flujo
Es fácil ver que el modo CFB (y

también el OFB) se puede con-
siderar como una cifra de flujo
que utiliza como función ge-
neradora una cifra de bloque.
3)�Modo�CFB�(Cipher�Feedback). En el modo CFB, el algoritmo de cifrado no

se aplica directamente al texto en claro sino a un vector auxiliar (inicialmente
igual al VI). Del resultado del cifrado se toman n bits que se suman a n bits
del texto en claro para obtener n bits de texto cifrado. Estos bits cifrados se
usan al mismo tiempo para actualizar el vector auxiliar. El número n de bits
generados en cada iteración puede ser menor o igual que la longitud de bloque
b. Tomando por ejemplo n = 8, tenemos una cifra que genera un byte cada vez
sin tener que esperar a tener un bloque entero para poder cifrarlo.
Modo de operación CFB
4)�Modo�OFB�(Output�Feedback). El modo OFB es como el CFB, pero en lugar

de actualizar el vector auxiliar con el texto cifrado, se actualiza con el resulta-
do obtenido del algoritmo de cifrado. La propiedad que diferencia este modo
de los otros es que un error en la recepción de un bit cifrado afecta sólo al
descifrado de este bit.
Modo de operación OFB
5)�Otros�modos. A partir de los modos anteriores se pueden definir diversas

variantes. Por ejemplo, el modo CTR (Counter) es como el OFB, pero el vector
auxiliar no se realimenta con el cifrado anterior sino que es simplemente un
contador que se va incrementando.
Hay otra técnica para evitar que en textos de entrada iguales se obtengan tex-
tos cifrados iguales, que es aplicable también a los cifrados que no usan vec-
tor de inicialización (incluidas las cifras de flujo). Esta técnica consiste en mo-
dificar la clave secreta con bits aleatorios antes de usarla en el algoritmo de
cifrado (o en el de descifrado). Como estos bits aleatorios sirven para dar un
"sabor" diferente a la clave, se les suele llamar bits�de�sal. Igual que el vector
de inicialización, los bits de sal se envían en claro antes del texto cifrado.
3.1.4. Funciones hash seguras
(10)
Aparte de cifrar datos, hay algoritmos basados en técnicas criptográficas que En inglés, message digest.
se usan para garantizar la autenticidad de los mensajes. Un tipo de algoritmos
de estas características son las llamadas funciones�hash�seguras, también co-
nocidas como funciones de resumen�de�mensaje10.
En general, podemos decir que una función hash nos permite obtener una
cadena de bits de longitud fija, relativamente corta, a partir de un mensaje de
longitud arbitraria:
H = h(M)
Para mensajes M iguales, la función h tiene que dar resúmenes H iguales. Pero
si dos mensajes dan el mismo resumen H no necesariamente tienen que ser
iguales. Eso es así porque sólo hay un conjunto limitado de posibles valores
H, ya que su longitud es fija, y en cambio puede haber muchos más mensajes
M (si la longitud puede ser cualquiera, habrá infinitos).
Para poder aplicarla en un sistema de autenticación, la función h tiene que ser Secreto de los algoritmos
una función hash segura.
Notad que las funciones hash
son conocidas ya que todo el
mundo tiene que poder calcu-
lar los resúmenes de la misma
Se entiende que una función hash o de resumen es segura si cumple manera.
estas condiciones:
1) Es unidireccional, es decir, si tenemos H = h(M), es computacional-

mente inviable encontrar M a partir del resumen H.
2) Es resistente�a�colisiones, es decir, dado un mensaje M cualquiera,

es computacionalmente inviable encontrar un mensaje M'¹ M tal que
h(M') = h(M).
Estas propiedades permiten el uso de las funciones hash seguras para dar un
servicio de autenticidad basado en una clave secreta S compartida entre dos
partes A y B. Aprovechando la unidireccionalidad, cuando A quiere enviar un
mensaje M a B puede preparar otro mensaje Ms, por ejemplo, concatenando el
original con la clave: Ms = (M,s). Entonces envía a B el mensaje M y el resumen
del mensaje Ms.
Para comprobar la autenticidad del mensaje recibido, B verifica que el resumen

corresponde efectivamente a Ms. Si es así, quiere decir que lo ha generado
alguien que conoce la clave secreta s (que tendría que ser A), y también que
nadie ha modificado el mensaje.
Otra técnica consistiría en calcular el resumen del mensaje M y cifrarlo utili-

zando s como clave de cifrado.
Autenticidad y confidencialidad
Cifrar sólo el resumen, en lugar del mensaje entero, es más eficiente porque hay menos
bits a cifrar. Eso, claro está, suponiendo que sólo haga falta autenticidad, y no confiden-
cialidad. Si también interesa que el mensaje sea confidencial, entonces sí que hay que
cifrarlo entero.
Para verificar la autenticidad hace falta recuperar el resumen enviado, desci-

frándolo con la clave secreta s, y compararlo con el resumen del mensaje M.
Un atacante que quisiera modificar el mensaje sin conocer la clave podría in-
tentar sustituirlo por otro que dé el mismo resumen, con lo que B no detectaría
la falsificación. Pero si la función de resumen es resistente a colisiones, eso le
tendría que ser imposible al atacante.
Con el fin de dificultar los ataques contra las funciones de resumen, por una
parte los algoritmos tienen que definir una relación compleja entre los bits de
la entrada y cada bit de la salida. Por otra parte, los ataques de fuerza bruta se
contrarrestan haciendo bastante larga la longitud del resumen. Por ejemplo,
los algoritmos usados actualmente generan resúmenes de 128 o 160 bits. Eso
quiere decir que un atacante podría tener que probar del orden de 2128 o 2160
mensajes de entrada para encontrar una colisión (es decir, un mensaje dife-
rente que diera el mismo resumen).
Pero hay otro tipo de ataque más ventajoso para el atacante, llamado ataque
del�cumpleaños. Un ataque de este tipo parte del supuesto de que el atacante
puede escoger el mensaje que será autenticado. La víctima lee el mensaje y,
si está de acuerdo, lo autentica con su clave secreta. Pero el atacante ha pre-
sentado este mensaje porque ha encontrado otro que da el mismo resumen,
y por lo tanto puede hacer creer al destinatario que el mensaje auténtico es
este otro. Y eso se puede conseguir haciendo una búsqueda de fuerza bruta
con muchas menos operaciones: del orden de 264 o 280, si el resumen es de
128 o 160 bits, respectivamente.
Resistencia fuerte a las colisiones
La resistencia de los algoritmos de resumen a las colisiones, tal como la hemos definido,
a veces se llama "resistencia débil", mientras que la propiedad de ser resistente a ataques
del cumpleaños se llama " resistencia fuerte".
Paradoja del cumpleaños
El nombre de este tipo de ataque viene de un problema clásico de probabilidades cono-

cido como la "paradoja del cumpleaños". El problema consiste en encontrar el número
mínimo de personas que tiene que haber en un grupo para que la probabilidad de que
al menos dos de ellas celebren su cumpleaños el mismo día sea superior al 50%. Una
respuesta intuitiva puede ser que la solución es del orden de 200, pero este resultado
no es correcto. Podría serlo si se quisiera obtener el número de personas necesarias para
que hubiera un 50% de probabilidad de coincidencia con una persona determinada. Si
aceptamos que la coincidencia sea entre cualquier pareja de personas, la solución es un
número mucho menor: 23.
La conclusión es que si una función de resumen puede dar N valores diferentes, para que
la probabilidad de encontrar dos mensajes con el mismo resumen sea del 50% el número
de mensajes que hay que probar es del orden de √N
Ejemplos de funciones hash seguras
El esquema de la mayoría de funciones hash usadas actualmente es parecido al de los

algoritmos de cifrado de bloque: el mensaje de entrada se divide en bloques de la misma
longitud, y a cada uno se le aplica una serie de operaciones junto con el resultado obte-
nido del bloque anterior. El resultado que queda después de procesar el último bloque
es el resumen del mensaje.
Esquema de las funciones de resumen
El objetivo de estos algoritmos es que cada bit de la salida dependa de todos los bits de la
entrada. Eso se consigue con diversas iteraciones de operaciones que "mezclen" los bits
entre sí, de manera parecida a cómo la sucesión de transposiciones en los cifrados de
bloque provoca un "efecto avalancha" que garantiza la difusión de los bits.
Hasta hace poco, el algoritmo de hash más usado era el MD5 (Message Digest 5). Pero
como el resumen que da es de sólo 128 bits, y aparte se han encontrado otras formas de
generar colisiones parciales en el algoritmo, actualmente se recomienda utilizar algorit-
mos más seguros, como el SHA-1 (Secure Hash Algorithm-1). El algoritmo SHA-1, publi-
cado en 1995 en un estándar del NIST (como revisión de un algoritmo anterior llamado
simplemente SHA), da resúmenes de 160 bits. En el 2002 el NIST publicó variantes de
este algoritmo que generan resúmenes de 256, 384 y 512 bits.
3.2. Criptografía de clave pública
Trataremos ahora los conceptos fundamentales de la criptología de clave pú-

blica.
3.2.1. Algoritmos de clave pública
Como hemos visto en el subapartado anterior, uno de los problemas de la crip-

tografía de clave simétrica es el de la distribución de las claves. Este problema
se puede solucionar si utilizamos algoritmos�de�clave�pública, también lla-
mados algoritmos�de�clave�asimétrica.
En un algoritmo criptográfico de clave pública se utilizan claves dife-

rentes para el cifrado y el descifrado. Una de ellas, la clave�pública, se
puede obtener fácilmente a partir de la otra, la clave�privada, pero en
cambio es computacionalmente muy difícil obtener la clave privada a
partir de la clave pública.
Los algoritmos de clave pública típicamente permiten cifrar con la clave pú-
blica (kpub) y descifrar con la clave privada (kpr):
C = e(kpub,M)
M = d(kpr,C)
Pero también puede haber algoritmos que permitan cifrar con la clave privada
y descifrar con la pública (más adelante veremos cómo se puede utilizar esta
propiedad):
C = e(kpr,M)
M = d(kpub,C)
Adaptación de los problemas difíciles
Si el avance de la tecnología reduce el tiempo de resolución, se puede aumentar la longi-

tud n, con lo cual harán falta unas cuantas operaciones más para el planteamiento, pero
la complejidad de la solución crecerá exponencialmente.
Los algoritmos de clave pública se basan en problemas matemáticos "fáciles"

de plantear a partir de la solución, pero "difíciles" de resolver. En este contexto,
se entiende que un problema es fácil si el tiempo para resolverlo, en función
de la longitud n de los datos, se puede expresar en forma polinómica, como,
por ejemplo, n2 + 2n (en teoría de la complejidad, se dice que estos problemas
son de la "clase P"). Si el tiempo de resolución crece más rápidamente, como
por ejemplo con 2n, el problema se considera difícil. Así, se puede escoger un
valor de n tal que el planteamiento sea viable pero la resolución sea computa-
cionalmente intratable.
Un ejemplo de problema fácil de plantear pero difícil de resolver es el de los

logaritmos discretos. Si trabajamos con aritmética módulo m, es fácil calcular
esta expresión:
y = bx mod m
El valor x se llama logaritmo discreto de y en base b módulo m. Escogiendo

convenientemente b y m, puede ser difícil calcular el logaritmo discreto de
cualquier y. Una posibilidad es ir probando todos los valores de x: si m es un
número de n bits, el tiempo para encontrar la solución aumenta proporcional-
mente a 2n. Hay otros métodos más eficientes para calcular logaritmos discre-
tos, pero el mejor algoritmo conocido también necesita más tiempo de lo que
se puede expresar polinómicamente.
Ejemplo de operaciones módulo m
Para obtener 1411 mod 19 podemos multiplicar 11 veces el número 14, dividir el resultado
entre 19 y tomar el residuo de la división, que es igual en 13. Pero también se puede
aprovechar que el exponente 11 es 1011 en binario (11 = 1·23 + 0·22 + 1·21 + 1·20), y por
lo tanto 1411 = 148 · 142 · 141, para obtener el resultado con menos multiplicaciones:
Así, sabemos que log14 13 = 11 (mod 19). Pero si tuviéramos que obtener el logaritmo
de cualquier otro número y tendríamos que ir probando uno a uno los exponentes hasta
encontrar uno que dé como resultado y. Y si en vez de tratarse de números de 4 o 5 bits
como éstos fueran números de más de 1.000 bits, el problema sería intratable.
Así pues, los algoritmos de clave pública se tienen que diseñar de manera que
sea inviable calcular la clave privada a partir de la pública, y lógicamente tam-
bién tiene que ser inviable invertirlos sin saber la clave privada, pero el cifrado
y el descifrado se tienen que poder realizar en un tiempo relativamente corto.
En la práctica, los algoritmos utilizados permiten cifrar y descifrar fácilmente, Velocidad de la

pero todos ellos son considerablemente más lentos. Por eso, la criptografía de criptografía de clave
pública
clave pública se suele utilizar sólo en los problemas que la criptografía simé-
trica no puede resolver: el intercambio de claves y la autenticación con no El cifrado y descifrado con al-
goritmos de clave pública pue-
repudio (firmas digitales). de llegar a ser dos o tres ór-
denes de magnitud más lento
que con criptografía simétrica.
que los equivalentes con crip-
tografía simétrica.
Los mecanismos de intercambio�de�claves permiten que dos partes se
pongan de acuerdo en las claves simétricas que utilizarán para comuni-
carse, sin que un tercero que esté escuchando el diálogo pueda deducir
cuáles son estas claves.
Ejemplo de mecanismos de intercambio de claves
A puede escoger una clave simétrica k, cifrarla con la clave pública de B, y enviar el
resultado a B. Entonces B descifrará con su clave privada el valor recibido, y sabrá cuál
es la clave k que ha escogido A. El resto de la comunicación irá cifrada con un algoritmo
simétrico (mucho más rápido), utilizando esta clave k. Los atacantes, como no conocerán
la clave privada de B, no podrán deducir el valor de k.
La autenticación basada en clave pública se puede llevar a cabo si el

algoritmo permite utilizar las claves a la inversa: la clave privada para
cifrar y la clave pública para descifrar.
Si A envía un mensaje cifrado con su clave privada, todo el mundo podrá

descifrarlo con la clave pública de A, y al mismo tiempo todo el mundo sabrá
que el mensaje sólo lo puede haber generado quien conozca la clave privada
asociada (que tendría que ser A). Ésta es la base de las firmas�digitales.
Ejemplos de algoritmos de clave pública
El RSA es el algoritmo más utilizado en la historia de la criptografía de clave pública. Su

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

pública son el intercambio de claves para proporcionar confidencialidad, y la
firma digital para proporcionar autenticidad y no repudio.
El problema de la confidencialidad entre dos partes que sólo disponen de un

canal inseguro para comunicarse se resuelve con la criptografía de clave públi-
ca. Cuando A quiere enviar un mensaje secreto M a B, no hay que cifrar todo
el mensaje con un algoritmo de clave pública (eso podría resultar muy lento),
sino que se escoge una clave simétrica ks, llamada a veces clave�de�sesión o
clave�de�transporte, y se cifra el mensaje con un algoritmo simétrico utilizan-
do esta clave. Lo único que hay que cifrar con la clave pública de B ( ) es
la clave de sesión. En recepción, B utiliza su clave privada ( ) para recuperar

la clave de sesión ks y, entonces, ya puede descifrar el mensaje cifrado.
Ya que la clave de sesión es un mensaje relativamente corto (por ejemplo,

si es una clave DES sólo tendrá 56 bits), un atacante podría intentar romper
el cifrado a la fuerza bruta, pero no intentando descifrar el mensaje con los
posibles valores de la clave privada , sino cifrando los posibles valores de la
clave de sesión ks con la clave pública . En el caso de una clave de sesión

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

vada del firmante. Sin embargo, por cuestión de eficiencia, lo que se
cifra no es directamente el mensaje a firmar, sino sólo su resumen cal-
culado con una función hash segura.
Cuando A quiera enviar un mensaje firmado, tendrá que obtener su resumen

y cifrarlo con la clave privada . Para verificar la firma, el receptor tiene que
descifrarla con la clave pública y comparar el resultado con el resumen del
mensaje: si son iguales, quiere decir que el mensaje lo ha generado A y nadie
lo ha modificado. Como se supone que la función de resumen es resistente a
colisiones, un atacante no podrá modificar el mensaje sin que la firma deje
de ser válida.
3.2.3. Infraestructura de clave pública
Tal como hemos visto hasta ahora, la criptografía de clave pública permite re-
solver el problema del intercambio de claves, haciendo uso de las claves pú-
blicas de los participantes. Ahora, sin embargo, se plantea otro problema: si
alguien nos dice que es A y su clave pública es kpub, ¿cómo poder saber que
kpub es realmente la clave pública de A? Porque es perfectamente posible que
un atacante Z genere su par de claves (k'pr,k'pub) y nos diga "yo soy A, y mi
clave pública es k'pub".
Una posible solución a este problema es que haya alguien de confianza que
nos asegure que efectivamente las claves públicas pertenecen a sus supuestos
propietarios. Ese alguien puede firmar un documento que diga "la clave públi-
ca de A es ", y publicarlo para que todo el mundo tenga conocimiento de
ello. Este tipo de documento se llama certificado�de�clave�pública y es la base
de lo que se conoce como infraestructura�de�clave�pública�(PKI).
4. Certificados digitales
Un certificado de clave pública consta de tres partes básicas:
1) Una identificación de usuario, como, por ejemplo, su nombre.

2) El valor de la clave pública de este usuario.
3) La signatura de las dos partes anteriores.
(11)
Si el autor de la signatura es alguien en quien confiamos, el certificado nos En inglés, Certification Autho-
rity (CA).
sirve como garantía de que la clave pública pertenece al usuario que figura en
ella. Quien firma el certificado puede ser una autoridad que se responsabilice
de verificar de manera fehaciente la autenticidad de las claves públicas. En
este caso, se dice que el certificado ha sido generado por una autoridad�de
certificación11.
Puede haber diferentes formatos de certificados, pero el más usado es el de los El directorio X.500
certificados�X.509, especificado en la definición del servicio�de�directorio
La especificación del directorio
X.500. X.500 está publicada en la Se-
rie de Recomendaciones ITU-T
X.500, una de las cuales es la
El directorio X.500 permite almacenar y recuperar información, expresada co- Recomendación X.509.
mo atributos, de un conjunto de objetos. Los objetos X.500 pueden represen-
tar, por ejemplo, países, ciudades, o bien empresas, universidades (en general, (12)
En inglés, Distinguished Name
organizaciones), departamentos, facultades (en general, unidades organizati- (DN).
vas), personas, etc. Todos estos objetos están organizados jerárquicamente en
forma de árbol (en cada nodo del árbol hay un objeto) y, dentro de cada nivel,
los objetos se identifican mediante un atributo� distintivo. A escala global,
cada objeto se identifica con un nombre�distintivo12, que no es más que la
concatenación de los atributos distintivos que hay entre la raíz del árbol y el
objeto en cuestión.
El sistema de nombres es, pues, parecido al DNS de Internet, con la diferencia Ejemplos de nombre
de que los componentes de un nombre DNS son simples cadenas de caracteres, distintivo
y los de un DN X.500 son atributos, cada uno con un tipo y un valor. Algunos ejemplos de tipos de
atributos que se pueden usar
como atributos distintivos en
X.500 define un protocolo de acceso al servicio que permite realizar operacio- un DN son: countryName (ha-
bitualmente denotado con la
nes de consulta, y también operaciones de modificación de la información de abreviatura "c"), stateOrPro-
los objetos. Estas últimas operaciones, sin embargo, normalmente sólo están vinceName ("st"), localityName
("l"), organizationName ("o"),
permitidas a ciertos usuarios autorizados, y por lo tanto hacen falta mecanis- organizationalUnitName ("ou"),
commonName ("cn"), surna-
mos de autenticación de los usuarios, y estos mecanismos están definidos en me ("sn"), etc. Un ejemplo de
la Recomendación X.509. Hay un mecanismo básico que utiliza contraseñas, DN es "c=ES, st=Barcelona,
l=Barcelona, o=Universitat
y un mecanismo más avanzado que utiliza certificados. Oberta de Catalunya, ou=SI,
cn=cv.uoc.edu".
4.1. Cadenas de certificados y jerarquías de certificación
Un certificado nos soluciona el problema de la autenticidad de la clave pública

si está firmado por una CA en la que confiamos. Pero ¿qué pasa si nos comu-
nicamos 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 autenti-

cidad de su clave pública, firmado por otra CA. Esta otra CA quizá sí la conoce-
mos, o quizá tiene a su vez un certificado firmado por una tercera CASA, y así
sucesivamente. De esta manera, se puede establecer una jerarquía de autorida-
des de certificación, en la que las CA de nivel más bajo emiten los certificados
de usuario, y las CA de cada nivel son certificadas por una de nivel superior.
En un mundo ideal, podría haber una CA raíz que estuviera en la cima de la

jerarquía y tuviera la máxima autoridad. En la práctica, esta CA raíz global
no existe, y seguramente no existirá nunca (sería difícil que la aceptara todo
el mundo). En lugar de haber un solo árbol que comprenda todas las CA del
mundo, lo que hay en realidad son árboles independientes (algunos posible-
mente con una sola CA), cada uno con su CA raíz.
Para que podamos verificar la autenticidad de su clave pública, un usuario nos

puede enviar su certificado, más el certificado de la CA que lo ha emitido, más
el de la CA que ha emitido este otro certificado, etc., hasta llegar al certificado
de una CA raíz. Eso es lo que se denomina una cadena�de�certificados. Los
certificados de las CA raíz tienen la propiedad de ser autofirmados, es decir,
están firmados por ellas mismas.
Un posible tipo de extensión de los certificados X.509 es basicConstraints, y

un campo de su valor indica si el certificado es de CA (se puede usar su clave
para emitir otros certificados) o no. En el caso de que lo sea, otro subcampo
(pathLenConstraint) permite indicar el número máximo de niveles de la je-
rarquía por debajo de esta CA.
4.2. Listas de revocación de certificados
(13)
La Recomendación X.509, además de definir el formato de los certificados, En inglés, Certificate Revocation
List (CRL).
también define otra estructura denominada lista�de�revocación�de�certifica-
dos13.
Una lista de este tipo sirve para publicar los certificados que han dejado de
ser válidos antes de su fecha de caducidad. Los motivos pueden ser diversos:
se ha emitido otro certificado que sustituye al revocado, ha cambiado el DN
del titular (por ejemplo, ha dejado de trabajar en la empresa donde estaba), le
han robado su clave privada, etc.
Así, si queremos asegurarnos completamente de la validez de un certificado,

no basta con verificar su firma, sino que tendremos que obtener la versión
actual de la CRL (publicada por la CA que emitió el certificado) y comprobar
que el certificado no aparezca en esta lista.
Una CA normalmente actualizará su CRL de forma periódica, añadiendo cada

vez los certificados que hayan sido revocados. Cuando llegue la fecha de ca-
ducidad que constaba en el certificado, ya no habrá que volver a incluirlo en
la CRL. Eso permite que las CRL no crezcan indefinidamente.
5. Seguridad en la red
Hasta el momento hemos visto aspectos teóricos y prácticos relacionados con

la arquitectura de la red y los protocolos de comunicación. En este apartado se
presenta una visión de los conceptos de seguridad más enfocada a los ámbitos
de aplicación y transporte de la red. Trataremos los aspectos a considerar en el
desarrollo de aplicaciones como los protocolos de seguridad más usados hoy
en día.
5.1. Cookies
Las cookies (galletas) son un mecanismo para facilitar información sobre la

navegación realizada. En definitiva, son una herramienta utilizada por los ser-
vidores web para almacenar información sobre sus visitantes.
Una cookie es un fichero de texto que algunos servidores web graban

en nuestro ordenador con información sobre la navegación realizada
en sus páginas. Este fichero se guarda en nuestro propio disco duro, y
será devuelto posteriormente al servidor cuando éste lo solicite.
La caducidad de estas cookies, momento en el cual dejarán de ser activas, la

determina el diseñador de la web del servidor, y puede variar entre el tiempo
de la propia sesión y el de una fecha especificada. Las cookies no causan daños
en el sistema, ya que sólo permiten reconocer al usuario cuando se conecta a
un sitio web, registrando las visitas. En concreto, pueden llegar a guardar la
contraseña utilizada para acceder a aquella página, datos personales del usua-
rio, etc.; incluso así, muchos usuarios no desean este tipo de control no auto-
rizado y prefieren el anonimato, siendo éste casi el único problema real de las
cookies. Destaquemos también que existen virus que buscan esta información
"sensible" dentro de las cookies.
Por medio de las opciones de configuración del navegador se puede habilitar

o deshabilitar la aceptación de cookies. También podemos configurarlo para
que nos avise de la llegada de alguna cookie. Con las últimas versiones de los
navegadores se ha ido mejorando el sistema de gestión de las cookies.
Técnicamente, las cookies son trozos de datos arbitrarios definidos por el ser-
vidor web y enviados al navegador. El navegador las devuelve sin modificar al
servidor, reflejando así un estado (memoria de acontecimientos anteriores) en
las transacciones HTTP, que de otra manera serían independientes de estado.
Sin las cookies, cada petición de una página web o un componente de una
página web sería un acontecimiento aislado, sin ninguna relación con el resto
de peticiones de otras páginas del mismo sitio.
Al devolver una cookie al servidor web, el navegador le proporciona un me- Navegadores y cookies
dio para relacionar la solicitud de la página actual con solicitudes de páginas
Las especificaciones de cookies
anteriores. Además de ser definidas por un servidor web, las cookies también sugieren que los navegadores
pueden ser definidas por un script en un lenguaje como JavaScript, si éste está tienen que soportar un núme-
ro mínimo de cookies o una
soportado y habilitado en el navegador web. cantidad mínima de memoria
por almacenarlas. En concreto,
se espera que un navegador
El servidor que establece la cookie puede especificar una fecha de borrado, en sea capaz de almacenar al me-
nos 300 cookies de 4 kilobytes
cuyo caso la cookie será borrada en dicha fecha. Un sitio de compras podría cada una y al menos 20 coo-
kies por servidor o dominio.
querer ayudar a sus clientes potenciales recordándoles las cosas que había en
su cesta de la compra, incluso si cierran el navegador sin realizar la compra y
vuelven más tarde, para evitar que tengan que buscar los productos de nuevo.
En este caso, el servidor crearía una cookie con fecha de borrado según el deseo
del diseñador del sitio web. Si no se define una fecha de borrado, la cookie es
borrada cuando el usuario cierra su navegador. Por lo tanto, definir una fecha
de borrado es una manera de hacer que la cookie sobreviva entre una sesión y
otra. Por esta razón, a las cookies con fecha de borrado se las llama persistentes.
5.2. Contenidos activos
En los últimos años la web ha evolucionado desde el contenido estático que

nos permitía crear HTML hasta contenidos completamente dinámicos, que
constituyen ya hoy en día la mayoría de las páginas web. Un contenido diná-
mico es creado en tiempo de ejecución por un conjunto de procesos que se
ejecutan tanto en el cliente como en el servidor, y eso depende de la tecnolo-
gía utilizada. En este sentido, la seguridad de la web requiere técnicas cada vez
más específicas con el fin de asegurar los contenidos y proteger las maquinas
de códigos maliciosos. En este sentido introduciremos algunas de las tecnolo-
gías usadas para la creación de contenido dinámico.
5.2.1. Applets
Un applet es un componente de software que corre en el contexto de otro

programa, por ejemplo, un navegador web. El applet tiene que correr en un
contenedor, que lo proporciona un programa anfitrión mediante un plug-in, o
en aplicaciones, como teléfonos móviles, que soportan el modelo de progra-
mación por applets. Los applets se ejecutan en el contexto del cliente y por
lo tanto requieren de técnicas que aseguren que la ejecución no dañará la má-
quina cliente.
A diferencia de un programa, un applet no puede correr de manera indepen-

diente, ofrece información gráfica y a veces interactúa con el usuario, típica-
mente carece de sesión y tiene privilegios de seguridad restringidos. Un applet
normalmente lleva a cabo una función muy específica que carece de uso in-
dependiente.
Los applets tienen restricciones de seguridad fuertes en lo que respecta a su

acceso al ordenador cliente que los está ejecutando. Las políticas de seguridad
son, pues, un factor muy importante a tener en cuenta cuando se desarrolla
este tipo de software.
5.2.2. Servlets/JSP
Los servlets son objetos Java ejecutados por un servidor de aplicaciones y res-
ponden a invocaciones HTTP, sirviendo páginas dinámicas cuyo contenido
generalmente es un fichero HTML generado dinámicamente.
(14)
Un servlet es capaz de recibir una invocación y generar una respuesta en fun- En inglés, Web Application Ar-
chive.
ción de los datos de la invocación, el estado del propio sistema y los datos
a que pueda acceder. Los servlets pueden estar empaquetados dentro de un
fichero de formato WAR14, como aplicación web, dentro de un contenedor.
La ejecución de un servlet se hace dentro de uno o más procesos del servidor

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

son objetos MIME. Las aplicaciones que se ejecutan en el servidor reciben el
nombre de CGI.
Las aplicaciones CGI fueron una de las primeras maneras prácticas de crear
contenido dinámico para las páginas web. En una aplicación CGI, el servidor
web pasa las solicitudes del cliente a un programa externo. Este programa pue-
de estar escrito en cualquier lenguaje que soporte el servidor, aunque por ra-
zones de portabilidad se suelen usar lenguajes de script. La salida de este pro-
grama es enviada al cliente en lugar del archivo estático tradicional. CGI ha
hecho posible la implementación de funciones nuevas y variadas en las pági-
nas web, de tal manera que esta interfaz se ha convertido rápidamente en un
estándar, que se implementa en todo tipo de servidores web.
Las CGI son programas que podrían introducir problemas de seguridad si han
sido programados malintencionadamente. Por este motivo, muchos de los
proveedores de hosting de páginas web no permiten la ejecución de este tipo
de servicios web.
5.2.4. ASP/PHP
(16)
El servidor de páginas activas16 corresponde a la tecnología introducida por En inglés, Active Server Pages
(ASP).
Microsoft en el año 1996, y permite el uso de diferentes scripts y componentes
ActiveX al lado del tradicional HTML para mostrar páginas generadas dinámi-
camente. Se basa en el VBScript, pero existen diversos lenguajes de programa-
ción que se pueden utilizar, como, por ejemplo, Perl, Javascript, etc. ASP es
una tecnología dinámica que funciona en el lado del servidor, lo que significa
que, cuando el usuario solicita un documento ASP, las instrucciones de pro-
gramación dentro del script se ejecutan en el servidor para enviar al navega-
dor únicamente el código HTML resultante. Al usuario sólo se le envía lo que
solicita, y no puede acceder a ningún otro servicio del servidor. Así, una de sus
aplicaciones más importantes es la del acceso a bases de datos.
Existen otros lenguajes con funcionalidades parecidas. Entre ellos destacare- Dirección web
mos el PHP (Hypertext Preprocessor), que es un lenguaje de programación recomendada
creado para desarrollar aplicaciones web, muy similar a los lenguajes de pro- Para saber más sobre PHP po-
gramación C o C++. Su código se inserta en las páginas HTML, y se ejecuta déis consultar la siguiente di-
rección: http://www.php.net.
en el servidor.
Hay que destacar la aparición de muchos frameworks que facilitan el desarrollo

de aplicaciones web, a la vez que integran las funcionalidades de generación
de contenido y su almacenaje. Por ejemplo, Cake, Rails, etc.
5.2.5. RIA
RIA (Rich Internet Applications) es un acrónimo que engloba una gran multi-
tud de términos que definen una serie de aplicaciones cuyos contenidos son
dinámicos y se cargan en el tiempo de inicialización. La aplicación sólo hace
consultas al servidor para obtener datos de las bases de datos mientras que las
herramientas (reproductores de vídeo, procesamiento de imágenes) ya están
cargadas en el lado del cliente. Eso hace que se puedan ofrecer funcionalidades
mucho más ricas y entornos multimedia más conseguidos.
Se puede decir que las RIA son la nueva generación de las aplicaciones y una
tendencia ya impuesta por empresas como Macromedia, Magic Software, Sun
o Microsoft, que están desarrollando recursos para hacer de este tipo de apli-
caciones una realidad. Estas aplicaciones están basadas en plataformas J2EE
o.NET, con un front-end Flash, Java Swing, Java FX o Google Web Toolkit, y
utilizan una arquitectura cliente/servidor asíncrona, segura y escalable, junto
con una interfaz de usuario web. Entre los beneficios principales de las aplica-
ciones RIA tenemos una mejora importante en la experiencia visual, que hacen
del uso de la aplicación alguna cosa muy sencillo, mejoras en la conectividad
y despliegue instantáneo de la aplicación, agilizando su acceso, garantizan la
desvinculación de la capa de presentación, es decir, el acceso a la aplicación
desde cualquier computador en cualquier lugar del mundo. Un framework que
permite desarrollar de forma sencilla este tipo de aplicaciones es Google Web
Toolkit.
5.3. Protocolos de seguridad
Los protocolos definen las reglas y las normas que utilizan los ordenadores
para comunicarse con la red. Internet es un canal inseguro para enviar infor-
mación. Cuando se tiene que enviar un mensaje por Internet, se le hace pa-
sar por numerosos nodos intermedios antes de llegar a su destino. Alguno de
estos nodos intermedios podría interceptar, leer, destruir o modificar la infor-
mación enviada.
Muchas veces, durante el proceso de diseño de una aplicación la seguridad es

un aspecto que se deja de lado y se acaba añadiendo con posterioridad. En
muchos casos, estos añadidos no han contemplado todos los posibles proble-
mas y, por lo tanto, hacen que la aplicación pueda ser vulnerable.
(17)
En un principio, en el modelo OSI17 de comunicaciones, se decidió poner todo OSI es la abreviatura de Open
Systems Interconnection, en cas-
lo que se refiere a seguridad en el nivel de presentación. De esta manera, se tellano, interconexión de sistemas
podría ofrecer este servicio a todas las aplicaciones. No obstante, el modelo abiertos.
OSI no tuvo éxito y, por lo tanto, esta solución no ha sido usada.
Si analizamos el modelo Internet, basado en el protocolo TCP/IP, veremos que

no existe ningún nivel de presentación, pero podemos llegar a establecer una
cierta equivalencia entre ambos modelos que nos será útil para señalar los
sistemas de seguridad que podemos establecer en cada uno de los niveles. En

el nivel de aplicación podemos implementar aquellos servicios de seguridad
que sean específicos de cada aplicación.
El servicio de seguridad pasa a través de aplicaciones intermedias. Por ejemplo,

Pretty Good Privacy (PGP), Secure Electronic Transactions (SET), S/MIME, etc.
Por debajo del nivel de aplicación, podemos llegar a intercalar servicios de
seguridad como Secure Sockets Layer (SSL), Transporte Layer Secure (TLS), etc.
Entre los niveles TCP y IP, podríamos establecer medidas de seguridad trans-
parentes en las aplicaciones. Ejemplo: IPSEC. Incluso por debajo del nivel IP,
podemos llegar a cifrar las cabeceras IP, pero ello tiene el inconveniente de que,
si no se realiza correctamente el descifrado, los datos no llegarán a su destino.
5.3.1. PGP
Existen herramientas basadas en algoritmos criptográficos que permiten pro-

teger la información que se intercambia a través de la red. Pretty Good Privacy
(PGP) es un protocolo que permite cifrar (encriptar) ficheros y mensajes de
correo electrónico de manera que sólo puedan acceder a ellos los usuarios que
determinemos. De forma adicional, PGP permite realizar una firma digital de
los ficheros y mensajes, con lo que se puede garantizar la integridad de los

mismos. Mediante este programa podemos llevar la gestión de claves, cifrar y
firmar digitalmente mensajes y ficheros, borrado seguro de ficheros, etc.
Resumiendo, sus dos usos más comunes son los siguientes:
• Garantizar que un fichero informático (mensaje de correo electrónico, fi-

chero de texto, hoja de cálculo, imagen, etc.) ha sido creado por quien
dice ser su creador (firma digital).
• Impedir que personas sin autorización lean un fichero informático (en-

criptación).
No obstante, aunque tiene otras funciones, nos centraremos en las dos formas
más comunes de uso de PGP, la firma digital y la encriptación. Para usar cual-
quiera de estas funciones, el usuario de PGP tiene que crear una pareja de cla-
ves (una pública y otra privada), que son la base sobre la que se sostiene la
criptografía de claves públicas, basada en los algoritmos de clave asimétrica.
Crear la pareja de claves es muy sencillo, ya que es la aplicación PGP la que
se encarga prácticamente de todo.
Para que se pueda utilizar PGP, los interlocutores tendrán que tener instalado
el programa. Al instalarse el programa se generan unas claves. Una de las cla-
ves que forman la pareja es la clave privada, a la que siempre hay que proteger
contra los accesos no autorizados, ya que toda nuestra seguridad se basa en que
nadie más tenga acceso a ella. Para reducir su vulnerabilidad, la clave privada
está protegida por una contraseña compleja en forma de frase que es mucho
más segura que una contraseña típica de menos de diez caracteres. Su utilidad
es desencriptar los mensajes que nos sean enviados de forma segura. Por el
contrario, la clave pública hay que distribuirla a todas las personas con las que
queramos mantener comunicaciones seguras. Podría parecer que distribuir li-
bremente nuestra clave pública es una forma de bajar nuestras defensas, pero
no es así: la clave pública está encriptada y, además, su única utilidad es cifrar
(encriptar) los mensajes y ficheros que los otros nos quieran enviar. Con ella es
imposible desencriptar los mensajes o ficheros que alguien nos haya enviado;
tampoco es posible hacerse pasar por nosotros firmando un fichero. Para eso
sería preciso disponer de la clave privada.
PGP se puede integrar en los programas de correo electrónico más usuales para
hacer que encriptar y firmar mensajes no consista más que en pulsar un botón.
Al encriptar un mensaje, se nos pedirá que indiquemos a quién lo enviaremos,
para así escoger la clave pública correcta con que cifrarlo. Para firmar, en cam-
bio, se nos pedirá que tecleemos la contraseña de nuestra clave privada, con
lo cual evitamos también que alguien que use nuestro ordenador en nuestra
ausencia pueda hacerse pasar por nosotros.
Para cifrar los datos se utiliza un algoritmo de clave simétrica, cuya clave se
cifra con un algoritmo de clave asimétrica. De esta manera se combinan las
mejores propiedades de ambos: la seguridad de un algoritmo asimétrico (don-
de clave pública y privada son diferentes) con la rapidez y robustez de un al-
goritmo simétrico (cuya clave es única y, por lo tanto, vulnerable). Un tercer
algoritmo se utiliza para firmar documentos: se extrae un conjunto de bits del
mensaje (resumen) con una función hash y se cifra con la clave privada del
emisor. Así, por su modo de funcionamiento, PGP (y programas similares),
consta de los tres subsistemas: cifrado del documento con clave asimétrica,
cifrado con clave simétrica y firma digital.
Cuando se desea enviar un correo o fichero encriptado de B a A, PGP lo en-

cripta usando un sistema simétrico (generalmente IDEA o DES), usando una
clave aleatoria –clave DES–, que posteriormente se encripta (por ejemplo, con
RSA con la clave pública de A, KAp). Se envían el documento cifrado con la
clave aleatoria y ésta encriptada con la clave RSA privada del destinatario.
Cuando A recibe el correo y desea desencriptarlo, su programa PGP descifra

primero la clave simétrica con su clave privada RSA (Kas), y después descifra
el documento usando la clave desencriptada –clave DES–.
5.4. SSL
Secure Socket Layer es un sistema de protocolos de carácter general diseñado

en 1994 por la empresa Nestcape Communications Corporation, basado en la
aplicación conjunta de criptografía simétrica, criptografía asimétrica (de clave
pública), certificados digitales y firmas digitales, para ofrecer conexiones segu-
ras a través de Internet. Este grupo de protocolos comprende:
• El protocolo de transporte Secure Sockets Layer (SSL), desarrollado por

Netscape Communications a principios de los años noventa. La primera
versión de este protocolo, sobradamente difundida e implementada, fue la
2.0. Poco después, Netscape publicó la versión 3.0, con muchos cambios
con respecto a la anterior, que hoy casi ya no se utiliza.
• La especificación Transport Layer Security (TLS), elaborada por la Internet

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

familia de protocolos Wireless Application Protocol (WAP) para el acceso
a la red desde dispositivos móviles. La mayoría de los protocolos WAP son
adaptaciones de los ya existentes a las características de las comunicacio-
nes sin hilos, y en particular el WTLS está basado en el TLS 1.0. Las dife-
rencias se centran principalmente en aspectos relativos al uso eficiente del
ancho de banda y de la capacidad de cálculo de los dispositivos, que puede

ser limitada.
5.4.1. Características del protocolo SSL/TLS
El objetivo inicial del diseño del protocolo SSL fue proteger las conexiones en-
tre clientes y servidores web con el protocolo HTTP. Esta protección tenía que
permitir al cliente asegurarse de que se había conectado al servidor auténtico,
y enviarle datos confidenciales, como, por ejemplo, un número de tarjeta de
crédito, con la certeza de que nadie más que el servidor es capaz de ver estos
datos.
Las funciones de seguridad, sin embargo, no se implementaron directamente

en la protección de aplicación HTTP, sino que se optó por introducirlas en el
nivel de transporte. Así podría haber muchas más aplicaciones que hicieran
uso de esta funcionalidad.
A tal fin se desarrolló una interfaz de acceso a los servicios del nivel de transpor-
te basada en la interfaz estándar de los sockets. En esta nueva interfaz, funcio-
nes como connect, accept, send o recv fueron sustituidas por otras equivalentes
pero que utilizaban un protocolo de transporte seguro: SSL_connect, SSL_accept,
SSL_send, SSL_recv, etc. El diseño se hizo de manera tal que cualquier aplica-
ción que utilizara TCP a través de los llamamientos de los sockets podía hacer
uso del protocolo SSL sólo cambiando estos llamamientos. De aquí viene el
nombre del protocolo.
Diseño del protocolo SSL
Datagramas en WTLS
Una característica distintiva del WTLS es que no solamente permite proteger conexiones
TCP, como hacen SSL y TLS, sino que también define un mecanismo de protección para
las comunicaciones en modo datagrama, usado en diversas aplicaciones móviles.
Los servicios de seguridad que proporcionan los protocolos SSL TLS son:
• Confidencialidad. El flujo normal de información en una conexión SSL

TLS consiste en intercambiar paquetes con datos cifrados mediante claves
simétricas (por motivos de eficiencia y rapidez). Al inicio de cada sesión,
cliente y servidor se ponen de acuerdo sobre las claves que utilizarán pa-
ra 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 en-
viados en sentido contrario. Para evitar que un intruso que esté escuchan-
do el diálogo inicial pueda saber cuáles son las claves acordadas, se sigue
un mecanismo seguro de intercambio de claves, basado en criptografía de
clave pública. El algoritmo concreto para este intercambio también se ne-
gocia durante el establecimiento de la conexión.
• Autenticación�de�entidad. Con un protocolo basado en firmas digitales,

el cliente puede confirmar la identidad del servidor al que se ha conec-
tado. Para validar las firmas, el cliente necesita conocer la clave pública
del servidor, y eso normalmente se hace a través de certificados digitales.
SSL/TLS también prevé la autenticación del cliente de cara al servidor. Esta
posibilidad, sin embargo, no se usa tan a menudo porque muchas veces,
en vez de autenticar automáticamente al cliente a nivel de transporte, las
mismas aplicaciones utilizan su propio método de autenticación.
Autenticación de cliente
Un ejemplo de autenticación de cliente en el ámbito de aplicación son las contraseñas

que pueden introducir los usuarios en formularios HTML. Si la aplicación utiliza este
método, al servidor ya no le hace falta autenticar al cliente a nivel de transporte.
• Autenticación�de�mensaje. Cada paquete enviado en una conexión SSL

TLS, además de ir cifrado, puede incorporar un código MAC para que el
destinatario compruebe que nadie ha modificado el paquete. Las claves
secretas para el cálculo de los códigos MAC (una para cada sentido) tam-
bién se acuerdan de forma segura en el diálogo inicial.
Además, los protocolos SSL TLS están diseñados con estos criterios adicionales:
• Eficiencia. Dos de las características de los SSL TLS, la definición de se-

siones y la compresión de los datos, permiten mejorar la eficiencia de la
comunicación.
– Si el cliente pide dos o más conexiones simultáneas o muy seguidas,
en lugar de repetir la autenticación y el intercambio de claves (opera-
ciones computacionalmente costosas porque intervienen algoritmos
de clave pública), existe la opción de reutilizar los parámetros previa-
mente acordados. Si se hace uso de esta opción, se considera que la
nueva conexión pertenece a la misma sesión que la anterior. En el es-
tablecimiento de cada conexión se especifica un identificador�de�se-
sión, que permite saber si la conexión empieza una sesión nueva o es
continuación de otra.
– SSL TLS prevé la negociación de algoritmos de compresión para los

datos intercambiados, para compensar el tráfico adicional que intro-
duce la seguridad. Ni SSL 3.0 ni TLS 1.0, sin embargo, especifican nin-
gún algoritmo concreto de compresión.
Conexiones consecutivas o simultáneas
Una situación típica en la que se usa SSL TLS es la de un navegador web que accede a una
página HTML que contiene imágenes: con HTTP "no persistente" (el único modo definido
en HTTP 1.0), eso requiere una primera conexión para la página y, a continuación, tantas
conexiones como imágenes haya. Si las conexiones pertenecen a la misma sesión SSL
TLS, sólo hay que hacer la negociación una vez.
• Extensibilidad. Al principio de cada sesión, cliente y servidor negocian los

algoritmos que utilizarán para el intercambio de claves, la autenticación y
el cifrado (además del algoritmo de compresión). Las especificaciones de
los protocolos incluyen unas combinaciones predefinidas de algoritmos
criptográficos, pero dejan abierta la posibilidad de añadir nuevos algorit-
mos si se descubren otros que sean más eficientes o más seguros.
5.4.2. El transporte seguro SSL/TLS
La capa de transporte seguro que proporciona SSL/TLS se puede considerar

dividida en dos subcapas.
• La subcapa superior se encarga básicamente de negociar los parámetros de

seguridad y transferir los datos de la aplicación. Tanto los datos de nego-
ciación como los de aplicación se intercambian en mensajes.
• En la subcapa inferior, estos mensajes son estructurados en registros a los

cuales se aplica, según corresponda, la compresión, la autenticación y el
cifrado.
Estructura de la capa SSL/TLS

El protocolo�de�registros�SSL�TLS es el que permite que los datos pro-

tegidos sean convenientemente codificados por el emisor e interpreta-
dos por el receptor. Los parámetros necesarios para la protección, como
los algoritmos y las claves, se establecen de forma segura al inicio de la
conexión mediante el protocolo�de�negociación�SSL/TLS.
El protocolo de negociación SSL/TLS
El protocolo de negociación SSL TLS, también llamado protocolo�de�apretón

de�manos (Handshake Protocol), tiene por finalidad autenticar el cliente y/o el
servidor, y acordar los algoritmos y claves que utilizarán de una manera segura,
es decir, garantizando la confidencialidad y la integridad de la negociación.
Como todos los mensajes SSL/TLS, los mensajes del protocolo de negociación
se incluyen dentro del campo de datos de los registros SSL/TLS para ser trans-
mitido al destinatario. La estructura de un mensaje de negociación es la que
se muestra en la figura siguiente.
Formato de los mensajes de negociación SSL/TLS
El contenido del mensaje tendrá unos determinados campos dependiendo del

tipo de mensaje de negociación de que se trate. En total hay 10 tipos diferentes,
que veremos a continuación en el orden en que se tienen que enviar.
1)� Petición� de� saludo� (Hello� Request). Cuando se establece una conexión,
el servidor normalmente espera que el cliente inicie la negociación. Alterna-
tivamente, puede optar por enviar un mensaje Hello Request para indicar al
cliente que está preparado para empezar. Si durante la sesión el servidor quiere
iniciar una renegociación, también lo puede indicar al cliente enviándole un
mensaje de este tipo.
2)�Saludo�de�cliente�(Client�Hello). El cliente envía un mensaje Client Hello

al inicio de la conexión o como respuesta a un Hello Request. Este mensaje
contiene la siguiente información:
• La versión del protocolo que el cliente quiere utilizar.
(18)
• Una cadena de 32 bytes aleatorios18. De los 32 bytes aleatorios que
se envían en los mensajes de salu-
do, los 4 primeros tienen que ser
• Opcionalmente, el identificador de una sesión anterior, si el cliente desea una marca de tiempo, con preci-
sión de segundos.
volver a utilizar los parámetros que se le concedieron.
• La lista de las combinaciones de algoritmos criptográficos que el cliente

ofrece utilizar, por orden de preferencia. Cada combinación incluye el al-
goritmo de cifrado, el algoritmo de MAC y el método de intercambio de
claves.
• La lista de los algoritmos de compresión ofrecidos, por orden de preferen- Algoritmos de compresión
cia (como mínimo tiene que haber uno, aunque sea el algoritmo nulo).
El único algoritmo de compre-
sión previsto en SSL TLS es el
Algoritmos criptográficos previstos en SSL/TLS algoritmo nulo, es decir, nin-
guna compresión.
SSL TLS contempla los algoritmos criptográficos siguientes:
• Cifrado: RC4, DES, Triple DES, RC2, IDEA y FORTEZZA (este último sólo en SSL 3.0).
• MAC: MD5 y SHA-1.
• Intercambio de claves: RSA, Diffie-Hellman y FORTEZZA KEA (este último sólo en

SSL 3.0).
Si sólo interesa autenticar la conexión, sin confidencialidad, también se puede usar el

algoritmo de cifrado nulo.
3)�Saludo�de�servidor�(Server�Hello). Como respuesta, el servidor envía un

mensaje Server Hello, que contiene esta información:
• La versión del protocolo que se utilizará en la conexión. La versión será

igual a la que envió el cliente, o inferior si ésta no es soportada por el
servidor.
• Otra cadena de 32 bytes aleatorios.
• El identificador de la sesión actual. Si el cliente envió uno y el servidor

quiere reanudar la sesión correspondiente, tiene que responder con el mis-
mo identificador. Si el servidor no quiere reanudar la sesión (o no puede
porque ya no guarda la información necesaria), el identificador enviado
será diferente. Opcionalmente, el servidor puede no enviar ningún iden-
tificador para indicar que la sesión actual ya no podrá ser reanudada.
• La combinación de algoritmos criptográficos escogida por el servidor en la

lista de las enviadas por el cliente. Si se reanuda una sesión anterior, esta
combinación tiene que ser la misma que se utilizó entonces. El algoritmo
de compresión escogido por el servidor, o el que se utilizó en la sesión que
se reanuda.
Si se ha decidido continuar una sesión anterior, cliente y servidor ya pueden

empezar a utilizar los algoritmos y claves previamente acordados y se saltan
los mensajes que vienen a continuación, pasando directamente a los de fina-
lización de la negociación (mensajes finished).
4)�Certificado�de�servidor�(certificate)�o�intercambio�de�claves�de�servidor
(server�key�exchange). Si el servidor puede autenticarse delante del cliente, que
es el caso más habitual, envía el mensaje certificate. Este mensaje normalmente
contendrá el certificado X.509 del servidor, o una cadena de certificados. Si

el servidor no tiene certificado, o se ha acordado un método de intercambio
de claves que no utiliza, tiene que enviar un mensaje server key exchange, que
contiene los parámetros necesarios para el método a seguir.
5)�Petición�de�certificado�(certificate�request)
• Tipo de certificados: En SSL TLS están contemplados los certificados de

clave pública RSA, DSA o FORTEZZA KEA (este último tipo sólo en SSL
3.0). En el caso de que se tenga que realizar también la autenticación del
cliente, el servidor le envía un mensaje Certificate Request. Este mensaje
contiene una lista de los posibles tipos de certificado que el servidor puede
admitir, por orden de preferencia, y una lista de los DN de las autoridades
de certificación que el servidor reconoce.
6)�Fin�de�saludo�de�servidor�(Server�Hello�Done). Para acabar esta primera

fase del diálogo, el servidor envía un mensaje Server Hello Done.
7)�Certificado�de�cliente�(Certificate)
• Cliente sin certificado: Si el cliente recibe una petición de certificado pero

no tiene ninguno apropiado, en SSL 3.0 tiene que enviar un mensaje de
aviso, pero en TLS 1.0 tiene que enviar un mensaje Certificate vacío. En
cualquier caso, el servidor puede responder con un error fatal, o bien con-
tinuar sin autenticar al cliente. Una vez el servidor ha enviado sus mensa-
jes iniciales, el cliente ya sabe cómo continuar el protocolo de negociación.
En primer lugar, si el servidor le ha pedido un certificado y el cliente tiene
alguno de las características solicitadas, lo envía en un mensaje Certificate.
8)�Intercambio�de�claves�de�cliente�(Client�Key�Exchange). El cliente envía

un mensaje Client Key Exchange, cuyo contenido depende del método de inter-
cambio de claves acordado. En el caso de seguir el método RSA, en este men-
saje hay una cadena de 48 bytes que se utilizará como secreto�pre-maestro,
cifrada con la clave pública del servidor.
Un posible ataque contra la negociación es modificar los mensajes para que

las dos partes acuerden utilizar el protocolo SSL 2.0, que es más vulnerable.
Para evitar este ataque, en los dos primeros bytes del secreto pre-maestro tiene
que estar el número de versión que se envió en el mensaje Client Hello. Enton-
ces, cliente y servidor calculan el llamado secreto�maestro, que es otra cadena
de 48 bytes. Para hacer este cálculo, se aplican funciones hash al secreto pre-
maestro y a las cadenas aleatorias que se enviaron en los mensajes de saludo.
A partir del secreto maestro y las cadenas aleatorias, se obtienen:
• Las dos claves para el cifrado simétrico de los datos (una para cada sentido:
de cliente a servidor y de servidor a cliente).
• Las dos claves MAC (también una para cada sentido).
• Los dos vectores de inicialización para el cifrado, si se utiliza un algoritmo

de bloque.
9)�Verificación�de�certificado�(Certificate�Verify). Si el cliente ha enviado un

certificado en respuesta a un mensaje Certificate Request, ya puede autenticarse
demostrando que posee la clave privada correspondiente mediante un men-
saje Certificate Verify. Este mensaje contiene una firma, generada con la clave
privada del cliente, de una cadena de bytes obtenida a partir de la concatena-
ción de todos los mensajes de negociación intercambiados hasta ahora, desde
el Client Hello hasta el Client Key Exchange.
10)�Finalización�(Finished). A partir de este punto ya se pueden utilizar los

algoritmos criptográficos negociados. Cada parte envía a la otra una notifica-
ción de cambio de cifrado seguida de un mensaje Finished. La notificación de
cambio de cifrado sirve para indicar que el siguiente mensaje será el primero
enviado con los nuevos algoritmos y clavos.
El mensaje Finished sigue inmediatamente a la notificación de cambio de ci-

frado. Su contenido se obtiene aplicando funciones hash al secreto maestro y a
la concatenación de todos los mensajes de negociación intercambiados, desde
el Client Hello hasta el anterior a éste (incluido el mensaje Finished de la otra
parte, si ya lo ha enviado). Normalmente será el cliente el primero en enviar
el mensaje Finished, pero en el caso de reanudar una sesión anterior, será el
servidor quien lo envíe primero, justo después del Server Hello.
Una de las principales diferencias entre SSL 3.0 y TLS 1.0 está en la técnica
usada para obtener los códigos de verificación de los mensajes Finished, y tam-
bién para calcular el secreto maestro y obtener las claves a partir de este secreto
(en SSL se utilizan funciones hash directamente, y en TLS se utilizan códigos
HMAC).
El contenido del mensaje Finished sirve para verificar que la negociación se

ha llevado a cabo correctamente. Este mensaje también permite autenticar al
servidor delante del cliente, ya que el primero necesita su clave privada para
descifrar el mensaje Client Key Exchange y obtener las claves que se utilizarán
en la comunicación.
Una vez enviado el mensaje Finished, se da por acabada la negociación, y clien-

te y servidor pueden empezar a enviar los datos de aplicación utilizando los
algoritmos y claves acordados.
Los siguientes diagramas resumen los mensajes intercambiados durante la fase

de negociación SSL TLS.
Negociación de una sesión SSL/TLS nueva
Negociación de una sesión SSL/TLS que se reanuda

Además de los mensajes de negociación, notificaciones de cambio de cifrado y Ejemplos de errores

datos de aplicación, también se pueden enviar mensajes de error. Estos men- fatales
sajes contienen un código de nivel de gravedad, que puede ser "mensaje de Son ejemplos de errores fata-
aviso" o " error fatal", y un código de descripción del error. Un error fatal pro- les: MAC incorrecto, tipo de
mensaje inesperado, error de
voca el fin de la conexión y la invalidación del identificador de sesión corres- negociación, etc. (TLS 1.0 pre-
vé más códigos de error que
pondiente, es decir, la sesión no podrá ser reanudada. SSL 3.0).
También se puede enviar un mensaje de aviso para indicar el fin normal de

la conexión. Para evitar ataques de truncamiento, si una conexión acaba sin
haber enviado este aviso se invalidará su identificador de sesión.
5.5. Transacciones seguras en red
Conviene conocer también diferentes iniciativas para permitir las transaccio-

nes seguras en internet. Presentamos las más importantes.
5.5.1. Secure Electronic Transaction
A raíz de las faltas del protocolo SSL, diferentes empresas y organismos bus-
caron un sistema que permitiera realizar operaciones sensibles por Internet
de forma segura, como los pagos, con el fin de estimular la confianza de los
consumidores en el comercio electrónico. En 1996 un grupo de empresas del
sector financiero, informático y de seguridad (Visa International, MasterCard,
Microsoft, Nestcape, IBM, RSA, etc.) anunció el desarrollo de esta nueva tec-
nología.
(19)
Secure Electronic Transaction19 (SET) es un protocolo que permite dar seguri- En castellano, transacciones
electrónicas seguras.
dad en las transacciones por Internet que utilizan tarjetas de crédito. Sus es-
pecificaciones se pueden encontrar en el sitio web oficial de SETco, organismo
Dirección web
encargado de homologar los módulos de programación y los certificados de- recomendada
sarrollados por empresas privadas que se usan en implementaciones del pro-
Podéis acceder al histórico de
tocolo SET. la página web de SETco en:
http://web.archive.org/web/
*/www.setco.org
Su funcionamiento se basa en el uso de certificados digitales y sistemas cripto-
gráficos. Los primeros, para asegurar la perfecta identificación de todas aque-
llas parejas que intervienen en una transacción en línea basada en el uso de
tarjetas de pago, y los segundos, para proteger el envío de los datos sensibles
en su viaje entre los diferentes servidores que participan en el proceso. Una de
sus características es la de separar el proceso de compra del de pago.
Como inconvenientes de la SET mencionaremos su complejidad y lentitud.

Normalmente, con SSL no se necesita certificado ni software adicional, sólo
seleccionar los productos que hay que comprar y aceptar el pago. La lentitud
de la SET se debe a que se han de realizar diferentes verificaciones de identidad
e integridad por parte de diversas entidades a lo largo de una transacción.
5.5.2. 3D-Secure
3D-Secure es un sistema promovido por Visa/Mastercard con la finalidad de

incentivar el comercio electrónico, que intenta evitar los fraudes cuando el
pago se realiza con tarjetas de crédito. Está basado en el modelo de los "tres
dominios", en el cual se requiere:
1) Que la entidad emisora de la tarjeta autentique al cliente o titular de la

tarjeta (comprador): dominio del emisor.
2) Que la entidad adquirente autentique al comercio (vendedor): dominio del

adquirente.
3) Que ambas partes (entidad emisora y entidad adquirente) sean reconocidas

mutuamente como legítimas para efectuar la transacción, y que ésta se com-
plete de forma segura: dominio de intercambio.
En este modelo se deja al arbitrio de cada una de las entidades la elección del
"procedimiento de autenticación". De esta manera, tienen flexibilidad para se-
leccionar el método de autenticación más apropiado para sus comercios y ti-
tulares, y sustituirlo por nuevas soluciones cuando lo consideren conveniente.
La confidencialidad e integridad de la información de pago se consigue con la
utilización del protocolo SSL. El proceso de compra con 3D Secure funciona
como una compra normal en un comercio en línea, con la particularidad de
que, a la hora de introducir la información de pago, el comprador tendrá que
facilitar la contraseña 3D-Secure-Secure. De esta manera, se confirma que es
el propio titular de la tarjeta, y no un tercero sin autorización, quien efectúa
la transacción.
Resumen
El módulo ha hecho una introducción a los conceptos básicos de la seguridad

en las redes de comunicación. Los cortafuegos se han presentado como me-
didas pasivas de seguridad en los sistemas en red. Hemos visto que un corta-
fuegos puede ser tanto hardware como software y que incluso se pueden com-
binar diferentes sistemas para asegurar una red.
Se ha presentado el concepto de red privada virtual (VPN), que no es más

que una red lógica o virtual creada sobre una infraestructura compartida, pero
que proporciona los servicios de protección necesarios para una comunicación
segura. Las redes� privadas� virtuales (VPN) permiten utilizar la red pública
Internet como si fuera una red privada dedicada, por ejemplo, entre diversas
intranets de una misma organización. La técnica básica que utilizan las VPN
son los túneles, en los que los paquetes protegidos se encapsulan dentro de
datagramas IP que circulan de manera normal por la red Internet.
En este módulo también hemos visto que las técnicas�criptográficas permiten

cifrar un texto mediante una clave�de�cifrado, y que basta con conocer la cla-
ve�de�descifrado correspondiente para ser capaz de obtener el texto original.
Según la relación que haya entre las dos claves, los algoritmos criptográficos
se clasifican en algoritmos�simétricos si la clave de cifrado y la de descifrado
son la misma, y algoritmos�de�clave�pública si las claves son diferentes. Los
algoritmos simétricos, a su vez, se pueden clasificar en algoritmos�de�flujo, si
el cifrado consiste en añadir al texto datos pseudoaleatorios calculados a partir
de la clave, o algoritmos�de�bloque,�si�el�cifrado�se�hace�sobre�bloques�de
tamaño�fijo�del�texto�original.
La particularidad de la criptografía de clave pública es que, a partir de una de las

claves, la clave�privada, se puede deducir fácilmente la otra, la clave�pública,
mientras que la deducción inversa es prácticamente imposible. Eso permite
que todo el mundo que conozca la clave pública de un usuario pueda utilizarla
para cifrar datos confidenciales, con la seguridad que sólo quien tenga la clave
privada podrá descifrarlos, sin necesidad de acordar ninguna clave secreta a
través de un canal aparte. El uso de las claves al revés (la privada para cifrar y
la pública para descifrar) es la base de las firmas�digitales.
Como la criptografía de clave pública es computacionalmente más costosa que

la simétrica, no se utiliza nunca directamente para obtener confidencialidad,
sino siempre a través de una clave de sesión simétrica. De la misma manera, la
firma de un texto no se calcula directamente a partir del texto, sino aplicando

una función hash segura. La propiedad de este tipo de función es que es muy
difícil encontrar un mensaje que dé el mismo hash que otro.
Después de esta aproximación más teórica y para concluir el módulo se han

presentado diferentes conceptos de seguridad de la red en los niveles de apli-
cación y transporte. Hemos profundizado en el conocimiento de un protoco-
lo, el SSL/TLS, de la capa de transporte que sirve para dotar de seguridad a las
comunicaciones de las aplicaciones en red. El uso típico de los protocolos SSL
TLS es para proteger de manera transparente un protocolo de aplicación como
es HTTP. El protocolo HTTPS es simplemente la combinación de HTTP con el
transporte seguro SSL/TLS.
Bibliografía
Menezes, A. J.; Oorschot, P. C. van; Vanstone, S. A. (1996). Handbook of Applied Cryp-
tography. Boca Ratón: CRC Press.
SETco. Disponible en web.

<http://web.archive.org/web/*/www.setco.org>. [Fecha de consulta: 12 de abril del 2010.]
Stallings, W. (2003). Cryptography and Network Security, Principles and Practice (3.ª ed.). Upper
Saddle River: Prentice-Hall.
Yuan, R.; Strayer, W. T. (2001). Virtual Private Networks, Technologies and Solutions. Boston:
Addison-Wesley.
El nivel de
aplicación
Silvia Llorente Viejo
PID_00147724
© FUOC • PID_00147724 El nivel de aplicación
Índice
Introducción............................................................................................... 7
Objetivos....................................................................................................... 8
1. Arquitecturas de aplicaciones distribuidas................................ 9

1.1. Cliente-servidor (client/server en inglés) ...................................... 10
1.1.1. Aplicaciones basadas en la web ..................................... 12
1.2. De igual a igual (peer-to-peer, en inglés) ...................................... 13
1.2.1. Aplicaciones de igual a igual ......................................... 15
1.3. Ventajas y desventajas de cliente-servidor y de igual a igual ...... 16
1.4. Requerimientos de las aplicaciones ............................................ 17
2. DNS: Servicio de nombres en Internet......................................... 19

2.1. DNS: base de datos jerárquica y distribuida ............................... 21
2.2. Caching de DNS ........................................................................... 23
2.3. Peticiones recursivas frente a peticiones iterativas ..................... 24
2.4. Registros DNS .............................................................................. 25
2.5. Consideraciones de seguridad ..................................................... 26
3. La web y el HTTP.............................................................................. 27
3.1. HTTP: Hypertext Transfer Protocol.................................................. 28
3.1.1. Conexiones persistentes y no persistentes .................... 29
3.2. Formato de los mensajes HTTP .................................................. 30
3.2.1. Mensaje HTTP de petición ............................................ 30
3.2.2. Mensaje HTTP de respuesta ........................................... 31
3.3. HTTPS (HTTP seguro) .................................................................. 33
3.4. Cookies ........................................................................................ 34
3.5. Características de la demanda de páginas web ........................... 35
3.6. Servidores intermediarios ............................................................ 37
3.7. El GET condicional ..................................................................... 38
3.8. Distribución de contenidos ......................................................... 39
3.8.1. Redes de distribución de contenidos ............................. 41
4. Transferencia de ficheros................................................................ 43
4.1. Seguridad en la transferencia de ficheros ................................... 44
5. Correo electrónico en Internet....................................................... 45

5.1. SMTP ............................................................................................ 46
5.2. Formato de los mensajes ............................................................ 47
5.2.1. Formato de mensajes MIME .......................................... 48
5.3. Protocolos para acceder a los buzones de correo ........................ 50
5.3.1. POP3 ............................................................................... 51

5.3.2. IMAP ............................................................................... 52
5.3.3. Web ................................................................................ 53
6. Aplicaciones de igual a igual para la compartición de

ficheros.................................................................................................. 54
6.1. Redes superpuestas no estructuradas .......................................... 54
6.2. Redes superpuestas estructuradas ................................................ 57
7. Mensajería instantánea.................................................................... 60
7.1. XMPP ........................................................................................... 60
8. Telnet y Secure Shell: acceso a ordenadores remotos............... 63

8.1. Seguridad del protocolo Telnet ................................................... 63
8.2. Secure Shell ................................................................................. 64
9. Aplicaciones multimedia en red.................................................... 65

9.1. Ejemplos de aplicaciones multimedia ........................................ 65
9.1.1. Streaming de audio y vídeo almacenados ...................... 66
9.2. Streaming en directo de audio y vídeo ........................................ 66
9.2.1. Audio y vídeo en tiempo real interactivo ..................... 67
9.3. Multimedia en Internet .............................................................. 67
9.3.1. Compresión de audio y vídeo ....................................... 69
9.3.2. Formatos de audio y vídeo ............................................ 71
10. Streaming de audio y vídeo almacenados................................... 74

10.1. Acceso vía servidor de web ......................................................... 75
10.2. Real Time Streaming Protocol (RTSP) ............................................. 76
10.2.1. Los estados del RTSP ..................................................... 78
10.2.2. Diagrama de estados del cliente .................................... 78
10.2.3. Diagrama de estados del servidor .................................. 79
10.2.4. Métodos RTSP ................................................................ 80
10.2.5. El protocolo RTSP .......................................................... 80
10.2.6. El mensaje de petición RTSP ......................................... 81
10.2.7. El mensaje de respuesta RTSP ........................................ 82
10.2.8. Ejemplo de uso del protocolo RTSP .............................. 83
11. Protocolos para aplicaciones interactivas en tiempo real...... 86

11.1. Real Time Transport Protocol (RTP) ............................................... 86
11.1.1. Descripción del RTP ....................................................... 86
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
11.3.3. El mensaje de petición SIP ............................................ 97

11.3.4. El mensaje de respuesta SIP ........................................... 98
11.4. H.323 ........................................................................................... 99
11.5. Skype ............................................................................................ 101
12. Anexos................................................................................................... 103

12.1. Anexo 1. El protocolo RTSP ........................................................ 103
12.1.1. Órdenes .......................................................................... 103
12.1.2. Códigos de estado .......................................................... 103
12.1.3. Cabeceras ....................................................................... 104
12.2. Anexo 2. El formato de los paquetes RTCP ................................ 105
12.2.1. Informe de emisor (SR) .................................................. 105
12.2.2. Informe de receptor (RR) ............................................... 107
12.2.3. Descripción de elementos de la fuente (SDES) .............. 108
12.2.4. Paquete de cierre (BYE) ................................................. 109
12.2.5. Paquete definido por la aplicación (APP) ...................... 109
12.3. Anexo 3. El protocolo SIP ........................................................... 110
12.3.1. Códigos de estado .......................................................... 110
12.3.2. Cabeceras ....................................................................... 112
Resumen....................................................................................................... 114
Bibliografía................................................................................................. 115
© FUOC • PID_00147724 7 El nivel de aplicación
Introducción
En este módulo didáctico, se describe toda una serie de aplicaciones que uti-
lizan Internet como medio de comunicación y también los protocolos de co-
municaciones que tienen asociados. Estas aplicaciones se conocen como apli-
caciones distribuidas, ya que están formadas por diferentes partes y cada una
se encuentra en máquinas diferentes.
Normalmente, hay una parte denominada servidor que se ejecuta en un orde-

nador, a la cual se conectan los diferentes clientes (que se encuentran en otros
ordenadores remotos) con el fin de pedir los servicios (generalmente, solicitan
la ejecución de algún tipo de operación).
En este módulo, veremos en primer lugar algunos conceptos básicos referentes

a las aplicaciones distribuidas, y después, una serie de aplicaciones distribuidas
en Internet, cuyas características siguientes estudiaremos.
• El�modelo: describimos los diferentes elementos que forman la aplicación

y sus características.
• El�protocolo: exponemos las ideas principales del protocolo de comuni-

caciones de cada aplicación.
• El�modelo�de�información: describimos el formato de información de los

protocolos que tienen uno concreto.
• La� funcionalidad: explicamos la funcionalidad y los comandos que la

proporcionan.
Incluimos ejemplos breves del intercambio de comandos para facilitar su com-

prensión.
Objetivos
En este módulo didáctico, encontraréis las herramientas necesarias para alcan-

zar los objetivos siguientes:
1. Comprender el modelo cliente-servidor y el modelo peer-to-peer, que sirven

como base de la implementación de aplicaciones distribuidas.
2. Conocer las aplicaciones distribuidas más utilizadas en Internet y enten-

der los principios básicos de funcionamiento de los protocolos de comu-
nicación que estas usan.
1. Arquitecturas de aplicaciones distribuidas
Hay muchas definiciones de aplicaciones distribuidas. Aquí os ponemos una

que creemos que encaja muy bien con el enfoque de este módulo:
Una aplicación distribuida está formada por una colección de ordena-

dores autónomos enlazados por una red de ordenadores y soportados
por un software que hace que la colección actúe como un servicio inte-
grado.
Una arquitectura de software determina cómo se identifican y se asignan los

componentes del sistema; cómo interactúan los componentes para formar el
sistema; la cantidad y la granularidad de la comunicación que se necesita para
la interacción, y los protocolos de la interfaz usada por la comunicación.
La arquitectura que hay que utilizar en cada caso depende de muchos factores.
Ahora mencionaremos las características más significativas que hay que con-
siderar cuando se diseña una aplicación a escala Internet.
La primera característica es la gran�cantidad�tanto�de�ordenadores�como�de

usuarios que hay en Internet. Relacionado con esto, está la dispersión geográ-
fica de los mismos. La dispersión�geográfica afecta a la manera en la que los
componentes del grupo perciben las acciones que pasan a la aplicación. Por
ejemplo, los usuarios de la aplicación pueden percibir dos acciones que pasan
en dos extremos opuestos del mundo en diferente orden, según la proximidad
de cada componente al componente generador de la acción. Según la aplica-
ción, necesitaremos o no mecanismos para abordar estas situaciones.
Una tercera característica es la�autonomía de los diferentes ordenadores que

forman la aplicación. Es muy habitual que diferentes partes de una aplicación
estén bajo dominios administrados por diferentes administradores. Relaciona-
da con esta característica está la seguridad. Cada organización tiene unas po-
líticas de seguridad diferentes, como por ejemplo cortafuegos. Es preciso que
las aplicaciones distribuidas que diseñamos se puedan ejecutar teniendo en
cuenta estas restricciones impuestas por los diferentes administradores.
Una cuarta característica es la calidad�de�servicio. En una aplicación distri-

buida a escala Internet, este es un aspecto fundamental que vendrá muy con-
dicionado por la latencia de la red, los cortes y otros fenómenos que le puedan
afectar.
Finalmente, están los aspectos relacionados con la movilidad: dispositivos

que se conectan y desconectan; acceso desde diferentes ubicaciones; trabajo
en modo desconectado; calidad de acceso menor (ancho de banda, fiabilidad,
etc.). Este último aspecto, sin embargo, mejorará mucho a medida que estos
servicios se generalicen.
(1)
En este módulo, trataremos las dos arquitecturas distribuidas más utilizadas De igual a igual en inglés se de-
1 nomina peer-to-peer o p2p.
hoy día: cliente-servidor y de igual a igual . Hay otras arquitecturas distribuidas
como el grid, la publicación-suscripción o el código móvil, entre otras, que no
trataremos en este material.
1.1. Cliente-servidor (client/server en inglés)
En el modelo cliente-servidor hay dos tipos de componentes.
• Clientes: hacen peticiones de servicio. Normalmente, los clientes

inician la comunicación con el servidor.
• Servidores: proveen servicios. Normalmente, los servidores esperan

recibir peticiones. Una vez han recibido una petición, la resuelven
y devuelven el resultado al cliente.
Esta idea se puede aplicar de manera muy variada a muchos tipos diferentes
de aplicaciones. Un ejemplo que ayudará a entenderlo es la web. El navegador
es el cliente y los ordenadores a los cuales nos conectamos y de los que obte-
nemos las páginas son los servidores.
Los servidores pueden ser con estado o sin estado. Un servidor sin estado no
mantiene ninguna información entre peticiones. Un servidor con estado pue-
de recordar información entre peticiones. El alcance de esta información pue-
de ser global o específico de una sesión. Un servidor web con páginas web
estáticas es un ejemplo de servidor sin estado, mientras que un servidor que

genere las páginas de manera dinámica (como la Intrauoc del Campus Virtual
de la UOC) es un ejemplo de servidor con estado.
Un servidor también puede ser cliente de otros servidores, tal y como se ve en

la figura siguiente. Por ejemplo, una aplicación de correo vía web actúa como
servidor para el navegador y como cliente del servidor de correo que gestio-
na los mensajes del usuario en cuestión. Los servidores web y los otros servi-
cios disponibles en Internet son clientes del servicio de resolución de nombres
(DNS). Un tercer ejemplo son los buscadores (search engines), que permiten a
los usuarios acceder a sumarios de información de páginas web extendidas por
muchos sitios web de toda Internet. Un buscador es al mismo tiempo servi-
dor y cliente: responde a peticiones provenientes de los navegadores clientes
y ejecuta programas que, actuando como clientes (robots web; en inglés, web
crawlers), acceden a servidores de Internet buscando información. De hecho,
un buscador incluirá diferentes hilos de ejecución, algunos sirviendo al cliente
y otros ejecutando robots web.
Los servicios también se pueden implementar como diferentes procesos servi-

dores que se ejecutan en diferentes ordenadores y que interactúan para pro-
porcionar un servicio a procesos clientes siguientes. Los servidores se pueden
repartir los diferentes objetos que componen el servicio que proporcionan o
pueden mantener réplicas de los objetos en distintos ordenadores.
Ejemplo de partición de datos
La web proporciona un ejemplo habitual de partición de los datos, en el que cada servidor
gestiona su conjunto de recursos. Un usuario utiliza un navegador para acceder a un
recurso situado en cualquiera de los servidores.
La reproducción se usa para incrementar el rendimiento y la disponibilidad y para mejo-

rar la tolerancia a fallos. Proporciona múltiples copias consistentes de los datos en pro-
cesos que se ejecutan en diferentes ordenadores. Por ejemplo, la web proporcionada en
www.google.com (o www.uoc.edu) está registrada en diferentes servidores que tienen da-

tos reproducidos.
1.1.1. Aplicaciones basadas en la web
Un caso particular de aplicaciones cliente-servidor son las aplicaciones que se

ejecutan aprovechando la arquitectura de la web. Estas aplicaciones se basan
en el hecho de tener toda la capacidad de procesamiento en un servidor web (o
conjunto de servidores) al que se accede desde un navegador web. Cuando el
usuario hace clic sobre un enlace de la página web que tiene en su navegador,
se genera una petición en el servidor que contiene la información. El servidor,
al recibir la petición, retorna la página pedida si la petición era a una página,
o retorna el resultado de ejecutar una aplicación si el enlace correspondía a un
código para ejecutar (por ejemplo, CGI o Servlet). El navegador web propor-
ciona a la aplicación un entorno donde presentar la información. La comuni-
cación entre cliente y servidor se hace utilizando el protocolo HTTP. El resul-
tado que retorna el servidor al cliente se envía en formato HTML, de manera
que para el cliente web es totalmente transparente si accede a una página web
o a una aplicación que genera un resultado formateado en HTML.
Las aplicaciones basadas en la web tienen la ventaja de que son accesibles des-
de cualquier ordenador que disponga de un navegador (la práctica totalidad
de los ordenadores conectados hoy día a Internet), sin que sea preciso tener
nada más instalado en el ordenador local. El uso de estas arquitecturas tam-
bién facilita el diseño de las aplicaciones, ya que no hay que implementar la
comunicación entre el cliente y el servidor (se utiliza el protocolo HTTP); y
la parte de presentación de la aplicación se facilita mucho por el hecho de
formatear el documento en HTML y aprovechar las funcionalidades que pro-
porciona el navegador (como los intérpretes de Javascript y Java).
La facilidad y universalidad en el acceso a las aplicaciones que proporciona esta

arquitectura es la base de los servicios ofrecidos en Internet. Algunos ejemplos
son el Campus Virtual de la UOC; los servidores de correo web tipo Yahoo o
Google, y los bancos por Internet.
1.2. De igual a igual (peer-to-peer, en inglés)
De una manera muy genérica, podemos decir que un sistema de igual

a igual se caracteriza por ser un sistema distribuido, en el que todos los
nodos tienen las mismas capacidades y responsabilidades, y en el que
toda la comunicación es simétrica.
En Internet, desde sus orígenes, ha habido sistemas y aplicaciones que se han

comportado siguiendo la filosofía de igual a igual. Estos sistemas se han carac-
terizado por el hecho de ser totalmente descentralizados, de gran escala y con
capacidad para autoorganizarse. El ejemplo paradigmático son los mensajes
Usenet.
Los mensajes Usenet
Los mensajes Usenet (Usenet News en inglés) son un sistema global y descentralizado
de grupos de discusión en Internet. Los usuarios leen y ponen mensajes que parecen
correos electrónicos (se les denomina artículos) en un número determinado de grupos
de noticias, que están organizados formando jerarquías lógicas de temas (por ejem-
plo, informática.linux.distribuciones o informática.lenguajesProgramación.tutoriales).
Los mensajes se distribuyen entre un gran número de servidores, que almacenan y se
reenvían mensajes unos a otros. Los usuarios se bajan los mensajes y ponen otros nuevos
en uno de los servidores. El intercambio de mensajes entre los servidores hace que, a la
larga, los mensajes lleguen a todos los servidores.
Sin embargo, el fenómeno de igual a igual empieza como tal a finales de los
noventa, de la mano de Napster. En la época de la explosión de Internet –a
partir de 1994–, la vertiente de colaboración que había dominado Internet
hasta aquel momento empezó a perder protagonismo frente a la vertiente más
comercial, que imponía la arquitectura cliente-servidor, liderada por la web
como arquitectura estrella.
Dentro de este contexto dominado por la centralización de la arquitectura

cliente-servidor, los usuarios de Napster descubrieron que el efecto agregado
de que cada individuo pusiera canciones al servicio de una comunidad era que
los participantes de la comunidad encontraban con facilidad las canciones que
les interesaban.
El funcionamiento de Naspter era muy sencillo. Usaba un servidor (o índice)

para proporcionar un servicio de directorio. Cuando un usuario arrancaba un
nodo de Naster, este se conectaba al servidor y publicaba la lista de canciones
que el nodo local hacía pública. De esta manera, el servicio de directorio sabía,
para cada igual, qué objetos tenía disponibles para compartir. Cuando alguien
buscaba una canción, hacía una petición de la canción al servidor, y este le
contestaba la lista de nodos que tenían un título similar. El usuario elegía uno
y se bajaba la canción directamente de este nodo.
Los grandes cambios que aporta Napster, tanto desde el punto de vista de la ar-
quitectura 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 indi-
vidual, deciden aportar al sistema (autonomía de los usuarios).
• La disponibilidad de un fichero depende de si los usuarios que lo tienen

están conectados al sistema (conectividad puntual o ad hoc en inglés).
• Hay muchos usuarios que proporcionan un mismo fichero (tolerancia a

fallos).
• Los recursos necesarios para almacenar los ficheros los aportan los mismos
usuarios (coste del sistema).
• El sistema evoluciona y se adapta a medida que los usuarios se conectan

o desconectan (autoorganización).
• El sistema soporta a muchos usuarios (escalabilidad). De hecho, llegó a

haber millones de usuarios conectados a Napster.
• Al haber muchas reproducciones de una canción, la carga está repartida

(mejora de rendimiento).
Aunque hubiera un servidor o índice, se considera que Napster era un sistema

de igual a igual, porque los ficheros se encontraban en los ordenadores de los
usuarios y la bajada se hacía directamente entre el ordenador que buscaba la
canción y el que la ofrecía.
Esta manera de organizar grandes cantidades de información a escala Internet

para facilitar la compartición resultó muy eficaz. La prueba de esto la encon-
tramos tanto en el hecho de que el sistema llegó a tener millones de usuarios,
como en el hecho de que muchas empresas discográficas lo vieron como una
amenaza. Precisamente, el motivo de que Napster dejara de funcionar fue que
denunciaron a los propietarios del servicio de directorio por infringir las leyes
del copyright. El caso Napster acabó con una sentencia judicial que forzó el
cierre del servidor índice.
A raíz del éxito de la solución, mucha gente se animó a hacer propuestas más Determinismo
descentralizadas y que superasen las limitaciones de Napster. Gnutella es un
Por determinismo entendemos
ejemplo de esto: se basa en un algoritmo de inundación para localizar el fiche- que diferentes ejecuciones de
ro que se busca y, de esta manera, elimina el punto único de fallo que supone una misma operación den el
mismo resultado. Sistemas co-
tener un servicio centralizado de directorio. Una vez localizado el fichero, la mo el de tipo Gnutella no son
deterministas. El algoritmo que
bajada se hace directamente entre quien quiere el fichero y quien lo propor- utilizan para localizar ficheros
ciona. Esta solución tiene el inconveniente de que no es determinista. dentro del sistema no garanti-
za que si un fichero está en al-
guno de los iguales lo encuen-
tre. Puede que, según el cami-
1.2.1. Aplicaciones de igual a igual no que haya seguido la consul-
ta, nos diga que no lo ha en-
contrado, cuando sí que está.
Los sistemas y las aplicaciones de igual a igual se han hecho populares de la
mano de las aplicaciones de compartición de ficheros, pero hay otros tipos de
aplicaciones. Skype es otro sistema tipo de igual a igual que es muy popular. Ved también
Skype proporciona telefonía en Internet. Utiliza un protocolo propietario de Las aplicaciones de igual a
la implementación del que se conocen pocas cosas. Funciona siguiendo una igual para la compartición de
ficheros como KazaA están ex-
organización con superiguales tal y como lo hace KaZaA. De hecho, Skype fue plicadas en el apartado "Apli-
caciones de igual a igual para
fundada por los fundadores de KaZaA. Un aspecto que hay que destacar es que la compartición de ficheros" de
consigue superar los problemas que tienen los iguales cuando están detrás de este módulo didáctico.
un cortafuego o los problemas derivados del NAT (network address translation).

También hay otros sistemas de igual a igual para la comunicación síncrona Bibliografía
(como la mensajería instantánea), juegos, sistemas de procesamiento distri- complementaria
buido (como SETI@home) o software para la colaboración (como Groove). Encontraréis más informa-
ción sobre el funcionamiento
SETI@home interno de Skype en:
S.�A.�Baset;�H.�Schulzrinne
SETI@home es un proyecto que tiene como objetivo detectar vida inteligente fuera de la (2006, abril). "An analysis of
Tierra. Distribuye procesamiento entre muchos ordenadores personales que están suscri- the Skype peer-to-peer inter-
tos al proyecto y analiza datos de radiotelescopios, aprovechando las grandes cantidades net telephony protocol". Pro-
de tiempo de procesamiento que los PC desperdician porque no hacen nada. ceedings of IEEE INFOCOM
2006. Barcelona.
Groove
Groove es un sistema de igual a igual para facilitar la colaboración y comunicación en

grupos pequeños. Proporciona herramientas para la compartición de ficheros, la mensa-
jería instantánea, el calendario, la gestión de proyectos, etc.
1.3. Ventajas y desventajas de cliente-servidor y de igual a igual
Como se ha visto, cliente-servidor y de igual a igual son dos maneras de plan-

tear el diseño de una aplicación. También se ha mencionado que hay otros
paradigmas. Este esfuerzo de caracterización, sin embargo, no nos tiene que
confundir. A la hora de la verdad, las aplicaciones no implementan nunca una
arquitectura pura y muchas veces son híbridos entre diferentes modelos. Cada
aplicación tiene sus necesidades y hay que utilizar las características que nos
ofrece cada paradigma con el fin de construir una aplicación que satisfaga las
necesidades de sus usuarios.
La tabla siguiente pretende resumir las ventajas y desventajas tanto del clien-
te-servidor como del igual a igual. No pretende ser exhaustiva. Además, hablar
de ventajas y desventajas es muy personal o dependerá de cada situación. Lo
que para alguien o en una situación es una ventaja, para algún otro u otra
situación es una desventaja. Y al revés pasa lo mismo.
Ventajas Desventajas
Cliente-servidor • Datos en los servidores, lo que facilita el control de la • La centralización del modelo: punto único de fallo, de-
seguridad, control de acceso, consistencia de la infor- pendencia de la autoridad administrativa que provee
mación, etc. el servicio, vulnerabilidad a ataques.
• Hay muchas tecnologías maduras para los sistemas • Escalabilidad condicionada a la capacidad de hacer cre-
cliente-servidor. Esto hace que haya soluciones muy cer el servidor o conjunto de servidores que proporcio-
probadas y que garantizan la seguridad, facilidad de nan el servicio. Relacionado con esto, es muy costoso
uso y amigabilidad de la interfaz. construir un sistema que soporte cargas altas de con-
• Relativa facilidad para actualizar los elementos de un tenidos pesados.
sistema cliente-servidor. • Cuando hay muchos clientes que hacen peticiones, el
• El desarrollo de aplicaciones centralizadas es más sen- servidor se puede congestionar. En entornos en los que
cillo que el de las descentralizadas. la demanda puede ser muy variable o incierta, es nece-
• Hay unos responsables de garantizar el servicio, que sario sobredimensionar el servicio para atender cargas
son los proveedores del servicio (o de cada una de las que quizá sólo ocurren de manera esporádica o asumir
partes de estos). que en ciertas situaciones puede haber congestión.
Ventajas Desventajas
De�igual�a�igual • Descentralización: los diferentes miembros (iguales) • El comportamiento descentralizado es complejo de im-
del sistema son los propietarios y tienen el control de plementar.
los datos y recursos de su ordenador. • La responsabilidad del sistema está difundida entre los
• El coste de la propiedad (o la mayor parte de esta si usuarios: si los usuarios no aportan recursos suficientes,
es un sistema de igual a igual híbrido) está repartido el sistema no puede funcionar.
entre los usuarios. • Tecnología muy nueva. Aunque hay sistemas muy usa-
• Escalable: dado que las operaciones se hacen directa- dos y que funcionan bien, las técnicas utilizadas toda-
mente entre los iguales, el sistema puede soportar más vía tienen que madurar.
operaciones que si hubiera un nodo que centralizara • El dinamismo del sistema hace que el sistema sea utili-
las operaciones. zable sólo si su disponibilidad satisface las necesidades
• Autoorganización: no hace falta que un componente de los usuarios. En la mayor parte de los casos, esto
del sistema supervise la evolución del sistema cuando pasa por la reproducción (tanto de información como
cambia su escala (aumentan los usuarios o la carga); de capacidad de procesamiento).
hay fallos, o los iguales se conectan o desconectan. • Seguridad: a los problemas habituales de los sistemas
distribuidos hay que añadir mecanismos para que la in-
formación que se aporte sea válida, que no haya usua-
rios que obtengan información sin aportarla, etc. Estos
aspectos todavía no están bien resueltos.
1.4. Requerimientos de las aplicaciones
Las aplicaciones dialogan utilizando un protocolo de transporte. En termino-

logía de niveles, se dice que transporte ofrece unos servicios a aplicación, o
dicho al revés, la aplicación requiere al nivel de transporte unas capacidades.
En general, estas capacidades giran en torno a tres ejes.
• Transferencia fiable: algunas aplicaciones, como el correo electrónico o la

transferencia de archivos, necesitan que la información que viaja llegue
y llegue bien. La fiabilidad de la transferencia es entonces un requisito
crucial. En cambio, hay aplicaciones que se basan en la transmisión de voz
o imagen en tiempo real que no necesita esta fiabilidad, porque si se pierde
uno o varios paquetes, la reproducción del sonido o la imagen original
todavía es posible, aunque con defectos aceptables.
• Ancho de banda: una transmisión de imagen en tiempo real necesita un

ancho de banda concreto para que se pueda hacer de manera aceptable,
pero el envío de un mensaje de correo electrónico se puede hacer con
cualquier ancho de banda, por pequeño que sea.
• Temporización: las aplicaciones que permiten comunicaciones en tiempo

real, ya sea con sonido, imagen o los dos, necesitan que el ritmo de recep-
ción de los paquetes sea constante, para que en recepción se pueda repro-
ducir el sonido o la imagen original de manera continua, tal y como se
captó en origen.
Por lo tanto, cada aplicación tiene unos requerimientos diferentes, y por esto
en el nivel de transporte hay diferentes opciones para satisfacer estos requeri-
mientos. Los protocolos originales de Internet (TCP y UDP) se concentraban
en el primer requerimiento, porque las primeras aplicaciones que se especifi-
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.
2. DNS: Servicio de nombres en Internet
(2)
Los ordenadores conectados a Internet están identificados de manera única En inglés, Domain Name System
(DNS).
por su dirección IP. Las direcciones IP son difíciles de recordar y por este moti-
vo se utilizan nombres del estilo de www.uoc.edu o smtp.uoc.edu para identi-
Formato de las direcciones
ficar los diferentes recursos u ordenadores de Internet. El sistema de nombres
IP
de dominio2 es un servicio desplegado en Internet que permite hacer la tra-
Las direcciones IP tienen el as-
ducción entre nombres y direcciones IP. pecto siguiente: 213.73.40.99,
donde cada punto separa un
byte del 0 al 255 expresado en
El DNS3 es un servicio que recibe millones de peticiones y tiene que ser capaz notación decimal.
de resolverlas de manera muy rápida. Para hacernos una idea del volumen de
peticiones que debe ser capaz de gestionar el DNS, sólo es necesario que nos
fijemos en dos de las aplicaciones más populares de Internet: la web y el correo
electrónico. Cada vez que escribimos una dirección web en el navegador, este
hace una consulta al DNS para saber a qué dirección IP corresponde. Y cada vez
que enviamos un mensaje de correo electrónico, se hace una consulta al DNS
para saber a qué servidor de correo hay que enviar el correo correspondiente
al dominio de la dirección de correo electrónico.
(3)
A continuación, podemos ver los pasos que se siguen para que el ordenador El DNS está especificado en los
RFC 1.034 y PFC 1.035 y actualiza-
del usuario pueda enviar una petición de página web al URL www.uoc.edu/
do en otros RFC.
eimt/index.html:
1) El ordenador del usuario es el que ejecuta la parte cliente de la aplicación

DNS.
2) El navegador extrae el nombre del sitio web –www.uoc.edu en este caso–

del URL y lo pasa a la parte cliente de la aplicación DNS.
3) El DNS cliente envía la petición (que contiene el nombre del sitio web) a
un servidor DNS.
4) En algún momento futuro el cliente DNS recibirá la respuesta, que contiene

la dirección IP correspondiente al sitio web.
5) Cuando el navegador recibe la dirección IP del DNS, puede iniciar la cone-

xión TCP con el servidor HTTP ubicado en el puerto 80 de esta dirección IP.
La figura siguiente muestra cómo el correo electrónico o el navegador interac-

túan con el DNS.
Os habréis dado cuenta de que la pregunta al DNS introduce un retraso adi-

cional –a veces sustancial– a la aplicación Internet que lo invoca. Afortunada-
mente, como veremos más adelante, la dirección IP está cacheada en algún
DNS "cercano", lo que ayuda a reducir el tráfico DNS en la red, así como el
retraso medio del DNS.
Otros servicios importantes que proporciona el DNS, aparte de los ya vistos de

traducción entre el nombre del ordenador y su dirección IP, son los siguientes.
• Alias: a veces interesa que un ordenador tenga más de un nombre. En es-

te caso, tiene un nombre que se denomina canónico, que es el nombre
del ordenador, y después tiene otros nombres que son sus alias. Estos alias
normalmente son más sencillos de recordar. En este caso, se puede invo-
car el DNS para obtener el nombre canónico del ordenador, así como su
dirección IP. En el caso de la UOC, www.uoc.edu es un alias del nombre
canónico www-org.uoc.edu.
• Alias�del�servidor�de�correo: es importante que las direcciones de correo

electrónico sean fáciles de recordar. El nombre del servidor que gestiona
el correo puede ser más complicado de recordar y puede haber más de
un servidor que responda cuando se pide por un dominio determinado.
De hecho, el campo MX permite que una institución o empresa tenga el
mismo nombre (un alias) para el dominio de correo electrónico y para
el servidor web. Por ejemplo, en la UOC tanto el servidor web como el
dominio de correo electrónico se denominan uoc.edu.
• Distribución�de�carga: el DNS se usa también para hacer distribución de Ved también

carga entre servidores replicados, como servidores web. Sitios web muy ac-
Para saber más sobre la distri-
cedidos pueden estar replicados en muchos servidores, cada uno corriendo bución de contenidos, podéis
en un ordenador diferente y con una dirección IP distinta. En este caso, ver el subapartado 3.8.
una manera de repartir la carga entre los servidores es asociar un conjunto

de direcciones IP a un nombre canónico. El DNS contiene este conjunto
de direcciones. Cuando un cliente hace una consulta al DNS por un nom-
bre al que le corresponde un conjunto de direcciones contesta todas las
direcciones IP, pero en cada respuesta rota el orden de estas. Puesto que
normalmente el servidor HTTP envía la petición a la primera dirección
IP de la lista, se consigue una distribución de carga entre los servidores.
Esta rotación también se utiliza en el correo electrónico, y de este modo

muchos servidores de correo pueden tener el mismo nombre. Últimamen-
te, compañías de distribución de contenidos como Akamai usan el DNS
de maneras más sofisticadas para proporcionar distribución de contenidos
web. Estas compañías utilizan el DNS para hacer que los usuarios se des-
carguen los contenidos de ubicaciones cercanas.
2.1. DNS: base de datos jerárquica y distribuida
El DNS es una base de datos jerárquica y distribuida organizada de ma-

nera autónoma, que proporciona un rendimiento a tiempo real a una
audiencia global con contribuidores globales.
Un diseño sencillo para el DNS sería tener un servidor que contuviera todas
las equivalencias entre nombres y direcciones IP. Los clientes enviarían las pe-
ticiones de resolución al servidor DNS y este las contestaría directamente. Esta
solución centralizada sería sencilla de implementar, pero tendría numerosos
inconvenientes por el hecho de que actualmente en Internet hay millones de
servidores. Sería necesario que tuviera una base de datos muy grande capaz
de soportar un volumen de consultas muy grande, además de ser capaz de
gestionar una frecuencia alta de actualizaciones de las entradas, como nuevos
hosts o cambios en los hosts.
Con el fin de poder atender estos requerimientos de escala (número de entra-

das y número de peticiones), el DNS usa muchos servidores organizados de
manera jerárquica y distribuidos por todo el mundo. Ningún servidor DNS
tiene todas las equivalencias entre nombres y direcciones IP. Estas equivalen-
cias están distribuidas en los diferentes servidores DNS.
Hay tres tipos de servidores DNS.
• Servidores�DNS�raíz: hay trece servidores DNS raíz (etiquetados de la A Dirección web

a la M). Cada uno de estos servidores raíz en realidad es un clúster de recomendada
servidores reproducidos, por seguridad y fiabilidad. En http://www.root-

servers.org/ podéis ver la ubi-
cación de los servidores DNS
• Servidores�DNS�de�nivel�de�dominio�superior4: son los responsables de raíz.
los dominios de primer nivel como org, com, net, edu o cat, así como de
todos los dominios de países (us, es, etc.). (4)
En inglés, top-level domain (TLD).
(5)
• Servidores�DNS�autorizados5: cada organización con ordenadores acce- En inglés, authoritative DNS ser-
vers.
sibles desde Internet tiene que proporcionar registros DNS accesibles pú-
blicamente que permitan hacer la equivalencia entre los nombres de sus
ordenadores y la dirección IP de estos. Un servidor DNS autorizado hospe-
da estos registros. Estos registros pueden estar en servidores DNS autoriza-
dos de la propia organización o en servidores DNS autorizados de algún

proveedor de servicios. En este caso, la organización tiene que pagar por
este servicio. La mayoría de las grandes empresas, universidades y centros
de investigación mantienen sus servidores DNS autorizados primario y se-
cundario (backup).
Porción de la jerarquía de servidores DNS
Hay otro tipo de servidores DNS, denominados servidores�DNS�locales, que Proveedor de acceso a
aunque estrictamente no pertenecen a la jerarquía de servidores, son claves Internet
para la arquitectura del DNS. Cada empresa proveedora de acceso a Internet Proveedor de acceso a Inter-
(PAI o ISP en inglés) –como una universidad o una empresa de telecomunica- net (PAI) o proveedor de servi-
cios de Internet (en inglés, In-
ciones que proporciona acceso a Internet a usuarios domésticos– tiene un ser- ternet Servide Provider, ISP) es
una empresa que ofrece a sus
vidor DNS local. Cuando un nodo se conecta a su PAI, este le proporciona la clientes acceso a Internet. Un
dirección IP de uno o más servidores DNS locales (normalmente, esto se hace PAI conecta a sus usuarios a In-
ternet mediante diferentes tec-
de manera automática vía DHCP). Cuando un ordenador hace una consulta al nologías como DSL (normal-
mente ADSL), módem de red
DNS, la consulta se envía al servidor DNS local, que actúa como proxy, y este telefónica conmutada, cable
la envía a la jerarquía de servidores DNS para que resuelva la petición. módem, Wi-Fi, etc.
Muchos PAI también ofrecen
otros servicios relacionados
DHCP con Internet como correo elec-
trónico, hospedaje de páginas
Dynamic Host Configuration Protocol (DHCP) es un protocolo de red que permite a los web, registro de dominios, etc.
nodos de una red IP obtener sus parámetros de configuración de manera automática. Se
trata de un protocolo de tipo cliente-servidor. El cliente hace broadcast de una petición
para información de configuración. El servidor DHCP recibe la petición y responde con
información de configuración de su base de datos de configuración. Generalmente, un
servidor posee una lista de direcciones IP dinámicas y las va asignando a los clientes a
medida que estas van estando libres, sabiendo en todo momento quién ha estado en
posesión de aquella IP, cuánto tiempo la ha tenido o a quién se le ha asignado después.
En el caso de no utilizar DHCP, cada ordenador de la red tiene que configurarse manual-
mente, tarea costosa y propensa a errores.
Ejemplo de obtención de dirección IP
A continuación, hay un ejemplo de los pasos que se seguirían para que el ordenador
estudiante.pai.cat obtenga la dirección IP del ordenador sd.eimt.uoc.edu.
1)estudiante.pai.cat envía la petición a su servidor DNS local.
2) El servidor DNS local reenvía la petición a un servidor DNS raíz.
3) El servidor DNS raíz retorna una lista de direcciones IP de servidores DNS responsables
del dominio edu.
4) El servidor DNS local reenvía la petición a uno de estos servidores DNS TLD.
5) El servidor DNS TLD contesta la dirección IP del servidor autorizado por el dominio
uoc.edu.
6) El servidor DNS local reenvía la petición al servidor DNS de la Universitat Oberta de

Catalunya (dns.uoc.edu).
7) El servidor DNS de la Universitat Oberta de Catalunya responde la dirección IP del

ordenador sd.eimt.uoc.edu.
Peticiones DNS iterativas
Frecuentemente, sucede que el servidor TLD no conoce el nombre del ser-

vidor autorizado sino sólo de un servidor DNS intermedio, el cual sí cono-
ce 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 servi-
dor DNS intermediario, dns.uoc.edu, recibe una petición por un ordenador
con el nombre acabado en eimt.uoc.edu, retorna a dns.pai.cat la dirección
IP de dns.eimt.uoc.edu, que es el servidor DNS autorizado para todos los
ordenadores acabados en eimt.uoc.edu. El servidor DNS local preguntaría,
finalmente, a dns.eimt.uoc.edu la dirección IP de sd.eimt.uoc.edu.
2.2. Caching de DNS
Como se puede ver, cada vez que se pide la resolución de un nombre se envían
muchos mensajes, lo que hace incrementar el tiempo para obtener la respues-
ta y que haya muchos mensajes DNS circulando por Internet. Con el objetivo
de reducir este número de mensajes, el DNS hace caching. En el ejemplo de la

última figura del subapartado 2.1, el servidor DNS local se guardaría una copia
de la dirección IP responsable del dominio uoc.edu. De esta manera, si al ca-
bo de un rato recibe una petición por un ordenador del dominio uoc.edu, ya
preguntaría directamente al servidor DNS autorizado por uoc.edu. El servidor
DNS local también puede guardarse una copia de la dirección IP de los servi-
dores TLD y ahorrarse preguntar a los servidores DNS raíz. Dado que la equiva-
lencia entre hosts y direcciones IP no es permanente, los servidores DNS des-
cartan la información cacheada al cabo de un cierto tiempo (frecuentemente
dos días).
2.3. Peticiones recursivas frente a peticiones iterativas
El ejemplo de la última figura del subpartado 2.1 utiliza tanto peticiones�re-

cursivas como peticiones�iterativas. La petición de estudiante.pai.cat
a dns.pai.cat es recursiva, ya que pide a dns.pai.cat que no resuelva la
equivalencia en ningún sitio suyo. Las otras tres consultas son iterativas, ya
que las respuestas se retornan directamente a dns.pai.cat. En teoría, las pe-
ticiones al DNS pueden ser recursivas o iterativas. La figura siguiente muestra
la cadena de peticiones para el caso de una resolución recursiva. En la prác-
tica, la mayoría de las peticiones siguen el esquema de la figura que hemos
mencionado antes.
Petición DNS
2.4. Registros DNS
Los servidores DNS almacenan registros�de�recursos, que tienen los campos

siguientes.
(6)
• Nombre. En inglés, time to live (TTL).
• Valor.
• Tipo.
• Tiempo de vida6: el TTL es el tiempo máximo para que un recurso se borre
de la caché.
Los tipos más usuales son los siguientes:
• A: Nombre es el nombre del ordenador y Valor es su dirección IP.
• NOS: Nombre es un dominio (por ejemplo, uoc.edu) y Valor es el nombre

de un servidor autorizado para este dominio (por ejemplo, dns.uoc.edu).
• CNAME: Valor es el nombre canónico de un alias (nombre). Permite

obtener el nombre canónico de un alias (por ejemplo, sd.uoc.edu,
einfsun1.uoc.edu, CNAME).
• MX: Valor es el nombre canónico de un servidor de correo que tiene Name

como alias (por ejemplo, uoc.edu, correu2.uoc.edu, MX). MX permite
que los servidores de correo tengan nombres más sencillos. También per-
mite que una organización pueda tener el mismo alias para el dominio de
correo que para el servidor web. Si se quiere obtener el nombre canónico
del servidor de correo, se preguntará por el campo MX y si se quiere obte-
ner el del otro servidor, se preguntará por el campo CNAME.
2.5. Consideraciones de seguridad
El DNS se diseñó sin considerar la seguridad. Un tipo de vulnerabilidad es la Contaminación de la

contaminación de la memoria caché del DNS, que hace creer en un servidor memoria caché del DNS
DNS que ha recibido información auténtica cuando en realidad no es así. La contaminación de la memo-
ria caché del DNS (DNS cache
poisoning o DNS cache pollu-
Domain Name System Security Extensions (DNSSEC) modifica el DNS para aña- tion en inglés) es una situación
creada maliciosamente o de
dir respuestas firmadas digitalmente, lo que proporciona a los clientes DNS manera intencionada que pro-
(resolvedores) autenticación del origen de los datos DNS, integridad de datos porciona datos a una caché de
DNS que no está originada por
–pero no disponibilidad ni confidencialidad– y denegación de existencia au- el servidor DNS autorizado. Es-
te hecho puede ocurrir por un
tenticada. error en el software, por mala
configuración de los servidores
DNS o por acciones malinten-
cionadas que se aprovechan
de la arquitectura abierta del
DNS.
Extensión del DNSSEC
A partir de julio del 2010, to-

dos los servidores raíz tendrían
que utilizar DNSSEC (http://
www.root-servers.org/).
3. La web y el HTTP
La web es un sistema formado por millones de páginas escritas en hipertexto HTML

mediante el lenguaje de marcaje HTML y conectadas entre sí mediante víncu-
El Hyper Text Markup Lan-
los, de manera que formen un solo cuerpo de conocimiento por el cual se pue- guage (HTML) es un lengua-
de navegar fácilmente. Con un navegador web, se pueden visualizar páginas je de marcaje diseñado para
estructurar textos y relacio-
que pueden contener texto, imágenes, vídeos y otro multimedia y navegar de narlos en forma de hipertex-
to. El World Wide Web Con-
unas páginas a otras usando los hiperenlaces. sortium (W3C) controla la
evolución del HTML: http://
www.w3.org.
La introducción de la web a principios de los noventa supuso una revolución
en Internet. Internet dejó de ser una red utilizada mayoritariamente por in-
vestigadores, académicos y alumnos de universidad para pasar a ser un medio
de comunicación, interacción y publicación de información que ha entrado a
formar parte de nuestra cotidianidad.
La web se basa en tres estándares para funcionar:
• El Uniform Resource Locator (URL), que se encarga de dar una direc-

ción única con el fin de localizar cada objeto.
• El Hyper Text Transfer Protocol (HTTP), que especifica la manera en

la que se enviará y se recibirá la información entre el navegador y
el servidor.
• El Hyper-text Markup Language (HTML), un método para especificar

cómo se tiene que ver esta información en el navegador.
En este módulo nos centraremos en el HTTP. Antes, sin embargo, veremos los
aspectos básicos de los URL. El URL es una cadena de caracteres que informa
al navegador de:
• El ordenador donde está el recurso al que hace referencia.

• El protocolo que tiene que utilizar para obtener este recurso.
• La manera en la que el servidor web encontrará cuál es el recurso.
La sintaxis que se utiliza en el URL es:

protocolo://[usuario:contraseña]@host[:puerto]/[cami-
no],
donde usuario:contraseña, el puerto y el camino son opcionales.
Los protocolos más habituales son: http, ftp (File Transfer Protocol) y file (para Ved también
el acceso y la localización de archivos dentro de sistemas de ficheros).
El protocolo ftp se trata en el
apartado 4 de este módulo.
El host identifica la máquina donde está el recurso. Puede ser un nombre
(www.wikipedia.org) o una dirección IP (192.12.34.11). El puerto es el número
de puerto TCP del servidor, donde se conectará el navegador.
Ejemplo
En la dirección http://www.empresa.com/producto/descipcion.html, http es el nombre

del protocolo, www.empresa.com es la dirección del servidor de la empresa y /produc-
to/descripcion.html es el camino hasta llegar al objeto en el servidor. En este caso no
hay ningún puerto especificado, lo que quiere decir que se utiliza el puerto 80, que es el
puerto por defecto de los servidores web.
3.1. HTTP: Hypertext Transfer Protocol
(7)
El HTTP7 es un protocolo a nivel de aplicación para sistemas hipermedia co- El HTTP está definido en los RFC
1.945 y 2.616.
laborativos y distribuidos, que es la base de la web. El HTTP sigue el paradig-
ma cliente-servidor. Clientes y servidores se intercambian mensajes HTTP. El
HTTP define la estructura de estos mensajes y cómo el cliente y el servidor
intercambian los mensajes. Se basa en un transporte fiable –el más habitual
es TCP–, aunque podría funcionar en otros transportes fiables. El puerto por
defecto para establecer las conexiones es el puerto asignado oficialmente al
servicio www, que es el puerto 80.
Ejemplo
Una página�web está formada por diferentes objetos. Un objeto es un
fichero –que puede ser de diferentes tipos: un fichero HTML, una ima- Una página que contiene tex-
to en HTML y dos imágenes
gen, un applet Java o un vídeo– dirigible por un URL. La mayoría de en GIF contiene tres objetos:
la página HTML base y las dos
las páginas web consisten en un fichero base formateado en HTML que imágenes.
referencia a diferentes objetos.
La figura siguiente ilustra el funcionamiento de la interacción entre un servi-

dor web y unos clientes web: un cliente envía un mensaje HTTP al servidor y
este lo procesa y contesta con otro mensaje HTTP. Dado que los navegadores
web implementan la parte cliente HTTP, a menudo nos referiremos a clientes
HTTP como navegadores. Los navegadores también implementan otras partes,
como el visualizador que formatea los documentos HTML y los presenta a los
usuarios.
Los servidores HTTP no mantienen ninguna información sobre los

clientes, y por este motivo se dice que el HTTP es un protocolo�sin�es-
tado.
3.1.1. Conexiones persistentes y no persistentes
El HTTP tiene dos modos de conexión.
• Conexiones�persistentes: en el caso de las conexiones persistentes, se obra

una conexión TCP diferente para enviar la petición/respuesta para cada
objeto que contiene la página que se quiere bajar (es decir, la petición y
respuesta de un mismo objeto viajan por la misma conexión).
• Conexiones�no�persistentes: en el caso de las conexiones no persistentes,

todas las peticiones y respuestas de los objetos de una página se envían por
la misma conexión TCP. Por defecto, el HTTP usa conexiones persistentes,
aunque tanto los clientes como los servidores HTTP se pueden configurar
para usar conexiones no persistentes.
Ventajas Inconvenientes
Conexiones�persistentes Después de enviar una respuesta, el servidor deja Tarda más en bajar los objetos de una página, ya
abierta la conexión TCP con el cliente. Esto permi- que no aprovecha el paralelismo que se puede obte-
te que futuras peticiones y respuestas entre el clien- ner bajando cada objeto de la página por separado.
te y el servidor se pueden enviar por esta conexión
TCP (ya se trate de objetos pertenecientes a la mis-
ma página o de diferentes páginas). Además, no ha-
ce falta que esperen a que les toque el turno de ser
servidas ya que la conexión ya está abierta.
El servidor cierra la conexión TCP con el cliente
cuando hace un rato que no se usa.
Ventajas Inconvenientes
Conexiones�no Permite tener más de una conexión en paralelo, lo Hay que establecer más conexiones:
persistentes que reduce el tiempo de respuesta. • La bajada de cada objeto sufre un retraso, debido
al tiempo de establecimiento de la conexión TCP
y al tiempo de hacer la petición del objeto.
• Para cada conexión hay que mantener informa-
ción: buffers y otras variables del TCP, lo que
puede ser una molestia para el servidor web, ya
que puede estar atendiendo muchas peticiones de
manera simultánea.
3.2. Formato de los mensajes HTTP
A continuación veremos los mensajes HTTP de petición y respuesta.
3.2.1. Mensaje HTTP de petición
Seguidamente, presentamos el ejemplo de un mensaje de petición HTTP.
GET /MiDirectorio/pagina.html HTTP/1.1

Host: www.servidor.edu
Como podéis ver, el mensaje está escrito en ASCII. Cada línea acaba con un
carry return y un line feed. La última línea está acabada con una línea en blan-
co (una línea que sólo contiene un carry return y un line feed). Los mensajes
pueden tener más líneas.
A la primera línea se la denomina línea�de�petición. Las siguientes reciben el

nombre de líneas�de�cabecera. La línea de petición tiene tres campos.
• El� método: puede tener diferentes valores GET, POST, HEAD, PUT,
DELETE, etc. El método más usado es el GET. El método GET se usa cuando
el navegador pide un objeto.
• El�URL: identifica el objeto. En el ejemplo, se pide el objeto /MiDirec-

torio/pagina.html.
• Versión� de� HTTP: en el ejemplo, el navegador implementa la versión

HTTP/1.1.
La línea de cabecera Host: www.servidor.edu indica en qué ordenador está Ved también
el objeto. De entrada esta cabecera podría parecer superflua, pero es útil para
En el subapartado 3.6 se tratan
los proxy cache web. los servidores proxy cache web.
De manera más general, en la figura siguiente encontraréis el formato de los

mensajes HTTP de petición.
Es fácil ver que el formato de los mensajes de petición sigue el ejemplo que
hemos visto anteriormente, con una diferencia: el formato general contiene
un "cuerpo". El cuerpo está vacío en el caso del método GET, pero se utiliza con
el método POST. Los clientes HTTP acostumbran a utilizar el método POST
para enviar datos de un formulario (por ejemplo, cuando un usuario propor-
ciona palabras para hacer una busca en un buscador). Con un mensaje POST,
el usuario está pidiendo una página web a un servidor pero el contenido de
la página web depende de lo que el usuario ha introducido en los campos del
formulario. Si el valor del campo método es POST, el cuerpo contiene lo que
el usuario ha introducido en los campos de formulario.
Merece la pena mencionar que no siempre que se utiliza un formulario los

datos se envían usando el método POST. Con frecuencia se usa el método GET
y los datos se incluyen en el URL. Por ejemplo, si un formulario que utiliza
el método GET tiene dos campos (modelo y cantidad) y los valores de los dos
campos son AT y 23, entonces el URL tendrá la estructura siguiente:
www.negocio.com/compra?modelo=TA&cantidad=23
3.2.2. Mensaje HTTP de respuesta
A continuación, se muestra un ejemplo de posible mensaje HTTP de respuesta.
HTTP/1.1 200 Ok
Date: Wed, 24 Feb 2010 19:05:40 GMT
Server: Apache/1.3.3 (Unix)
Last-Modified: Wed, 18 Feb 2009 21:11:55 GMT
Content-Length: 3245
Content-Type: text/html
(datos datos datos...)

La respuesta tiene tres partes.
• Una�línea�de�estado, que tiene, a su vez, tres partes:

– La versión del protocolo
– Un código de estado
– El mensaje correspondiente al código de estado
• Unas�cabeceras. En el ejemplo anterior: Ved también

– Date: indica el día y la hora en los que se creó y envió la respuesta.
Veréis en el subapartado 3.6
No es el día y la hora en los que se creó o modificó por última vez que la cabecera Last-Modi-
el objeto, sino el momento en el que el servidor obtiene el objeto del fied es una cabecera crítica
para los servidores caché.
sistema de ficheros, lo incluye en el mensaje de respuesta y lo envía.
– Server: indica que el mensaje lo generó un servidor web Apache.
– Last-Modified: indica el día y la fecha en los que se creó o modificó
por última vez el objeto.
– Content-Length: indica el número de bytes del objeto que se envía.
– Content-Type: indica que el objeto que contiene el cuerpo es del
tipo texto HTML.
• Un�cuerpo: contiene el objeto pedido.
En la figura siguiente, encontraréis el formato general de los mensajes HTTP

de respuesta.
Algunos códigos de estado son los siguientes.
• 200 OK: la petición ha tenido éxito y la información se retorna incluida

en la respuesta.
• 301 Moved Permanently: el objeto pedido se ha cambiado de ubicación.

El nuevo URL está especificado en la cabecera Location: del mensaje de
respuesta. El cliente obtendrá de manera automática el nuevo URL.
• 400 Bad Request: código de error genérico que indica que el servidor
no ha podido entender la petición.
• 404 Not Found: el documento pedido no existe en el servidor.
• 505 HTTP Version Not Supported: el servidor no soporta la versión

del protocolo HTTP pedido.
Mensaje HTTP de respuesta real
Es muy fácil ver un mensaje HTTP de respuesta real. Sólo hay que hacer un Telnet en un
servidor web y después teclear en línea un mensaje pidiendo un objeto que esté hospe-
dado en el servidor. Podéis probar con el ejemplo siguiente8:
telnet www.uoc.edu 80
GET /index.html HTTP/1.1
Host: www.uoc.edu
Con Telnet se obra una conexión TCP en el puerto 80 del servidor www.uoc.edu. A con-
tinuación, se envía un mensaje HTTP de petición (aunque no veáis lo que estáis escri-
biendo, se enviará una vez pulséis el retorno. Si os equivocáis no sirve de nada borrar, ya
que se enviarán todos los caracteres. Será necesario que volváis a empezar). Recibiréis un
mensaje de respuesta que contendrá el fichero HTML de la página que habéis pedido.
(8)
Recordad que hay que pulsar dos veces la tecla de retorno después de teclear la última
línea.
3.3. HTTPS (HTTP seguro)
El Hypertext Transfer Protocol Secure (HTTPS) es una combinación del

HTTP con el protocolo SSL/TLS para proporcionar cifrado e identifica-
ción segura del servidor. La idea principal tras el HTTPS es crear un canal
seguro sobre una red insegura. Esto asegura una protección razonable
frente a intrusos que quieran espiar la comunicación y ataques man-in-
the-middle, siempre y cuando el certificado del servidor esté verificado
y se pueda confiar en el mismo.
Ataque man-in-the-middle
El ataque man-in-the-middle es una forma de espiar en la que el atacante crea conexiones

independientes con las víctimas y hace pasar los mensajes entre estas a través de él. Esto
hace que las víctimas piensen que están hablando directamente entre sí a través de una
conexión privada cuando, en realidad, la conversación está controlada por el atacante.
Un ataque man-in-the-middle tiene éxito sólo cuando el atacante puede hacerse pasar por
cada una de las víctimas. La mayoría de los protocolos de cifrado incluyen alguna forma
de autenticación para evitar este tipo de ataques. Por ejemplo, el SSL autentica el servidor
mediante una autoridad de certificación en la que confían las dos partes.
El HTTPS confía en unas autoridades de certificación que se venden preins-

taladas en los navegadores web. A partir de aquí, las conexiones HTTPS son
fiables si y sólo si se cumple lo siguiente:
• El usuario confía en que la autoridad certificadora genera certificados para

sitios web legítimos.
• El sitio web proporciona un certificado válido (un certificado firmado por

una autoridad en la que se puede confiar).
• El certificado identifica de manera clara el sitio web.
• O bien los nodos de Internet que intervienen son fiables, o bien el usuario
confía en que el protocolo de cifrado usado (TLS o SSL) hace que no se
pueda espiar la comunicación.
3.4. Cookies
(9)
El HTTP es un protocolo sin estado. Esto simplifica el diseño del servidor y Las cookies están definidas en el
RFC 2.965.
hace que este tenga un rendimiento elevado, ya que es capaz de soportar miles
de conexiones TCP simultáneas. A veces, sin embargo, conviene que el servi-
dor web pueda identificar a usuarios. Las cookies9 se usan para este propósito.
Permiten a los servidores web tener información de los usuarios. Las cookies
se pueden usar para autenticar, almacenar preferencias del cliente, identificar
una sesión, mantener un seguimiento de las compras en una tienda virtual o
cualquier otro cosa que se pueda hacer a partir de almacenar datos textuales.
La mayoría de los sitios web comerciales usan cookies.
Una cookie es una pequeña porción de texto almacenado en el ordena-

dor del usuario por el navegador web, que consiste en una o más parejas
nombre-valor que contienen porciones de información.
El servidor web envía la cookie al navegador web como una cabecera de la

respuesta. A partir de este momento, el navegador web envía la cookie cada vez
que accede al servidor. El navegador web almacena las cookies en un fichero
local gestionado por el navegador. El servidor web puede tener una base de
datos con la información relacionada con las cookies.
Ejemplo de uso de una cookie
Supongamos que hay un cliente que se quiere conectar al servidor web de la UOC. Cuan-
do la petición llega al servidor de la UOC, el servidor crea un identificador único y una
entrada a una base de datos que este identificador indexa. A continuación contesta al
navegador del cliente incluyendo la cabecera Set-cookie: en la respuesta HTTP, que
contiene el identificador. El navegador recibe la respuesta HTTP y almacena la cookie
recibida en un fichero en el que almacena las cookies.
En el ejemplo de la figura siguiente, el fichero de cookies ya contiene una de una conexión

anterior a Youtube. El usuario continúa navegando por el sitio web de la UOC. Cada vez
que pide una página web, el navegador consulta el fichero de cookies y añade una línea
de cabecera a la petición HTTP. Si el usuario vuelve al sitio web de la UOC unos días más
tarde, continúa añadiendo la cabecera Cookie: en los mensajes de petición.
Las cookies, al ser texto, no son ejecutables. Por el hecho de no ser ejecutables,
no se pueden replicar por sí mismas y, por lo tanto, no son virus. Debido al
mecanismo para guardar y leer las cookies, estas se pueden usar como spyware.
Los productos antispyware pueden avisar a los usuarios sobre algunas cookies
porque estas se pueden usar para hacer un seguimiento de las operaciones del
usuario o vulnerar la privacidad.
La mayoría de los navegadores modernos permiten a los usuarios decidir si

quieren aceptar o no las cookies de las páginas visitadas, pero la no aceptación
de estas puede hacer que algunas páginas web no funcionen correctamente.
3.5. Características de la demanda de páginas web
Un servidor web puede tener miles de documentos y, sin embargo, recibir la

mayoría de las peticiones para un único documento.
(10)
La ley de Zipf debe su nom-
Ley�de�Zipf bre a George Kingsley Zipf (1902-
1950).
En muchos casos, la popularidad relativa entre diferentes sitios web o
10
entre distintas páginas de un cierto sitio web se rige por la ley de Zipf ,
que formulada de manera sencilla sería: muy pocos casos tienen mucha
popularidad y muchos casos tienen muy poca.
Distribución de popularidad que sigue la ley de Zipf
Casos ordenados por popularidad en el eje x, valor de popularidad en el eje

y
La popularidad de un sitio web puede ser muy variable. Puede recibir muy
pocas visitas durante mucho tiempo y, de repente, recibir varias veces más
peticiones de las que puede servir: es un tráfico en ráfagas.
Evolución del tráfico entrante y saliente de un sitio web típico durante una semana
Podéis observar la gran variación horaria y la reducción de tráfico durante el fin de semana.
Un servidor puede recibir avalanchas repentinas de tráfico. Por ejemplo, por

las estadísticas del servidor web que se ve en la figura siguiente sabemos que,
después de ser anunciado en la página de noticias Slashdot, sufrió un exceso
de visitas tan alto que el servidor se bloqueó.
Flash crowd
Un cuento de ciencia ficción de Larry Niven (1973) predijo que una consecuencia de
un mecanismo de teletransporte barato sería que grandes multitudes se materializarían
de manera instantánea en los lugares con noticias interesantes. Treinta años después, el
término se usa en Internet para describir los picos de tráfico web cuando un determinado
sitio web se convierte repentinamente en popular y es visitado de manera masiva.
También se conoce como efecto slashdot o efecto /., que se da cuando un sitio web resulta
inaccesible a causa de las numerosas visitas que recibe cuando aparece en un artículo del
sitio web de noticias Slashdot (en castellano, Barrapunto).
Peticiones web por hora, servidas por http://counter.li.org durante tres días
Se puede ver que mientras que el número habitual de operaciones (peticiones web) estaba por debajo de 500, subió
rápidamente a unas 2.500, lo que provocó el fallo del sistema. Después de reconfigurarlo, estuvo soportando durante unas
doce horas en torno a 3.000 peticiones por hora para bajar posteriormente a valores normales. La historia completa está en la
dirección: http://counter.li.org/slashdot.
3.6. Servidores intermediarios
(11)
Un servidor intermediario11 es una entidad de la Red que satisface las peticio- En inglés, web cache o proxy-ca-
che.
nes HTTP en lugar del servidor web al que iba dirigida la petición. Los servi-
dores intermediarios mantienen una copia de los objetos accedidos reciente-
mente en un disco del servidor. La figura siguiente muestra el funcionamiento
general de un servidor intermediario.
El navegador del usuario se puede configurar para que todas las peticiones
HTTP del usuario vayan primero al servidor web intermediario. A partir de este
momento:
1) Cada nueva petición del usuario establecerá una conexión TCP con el proxy-
cache y le enviará la petición HTTP.
2) Si el proxy-cache tiene una copia del objeto, lo retorna dentro de un mensaje

HTTP de respuesta al navegador cliente.
3) En caso de que el proxy-cache no tenga el objeto pedido, este abre una nueva
conexión TCP con el servidor origen de la petición para pedirle el objeto.
4) Al recibir la petición, el servidor origen envía el objeto en una respuesta

HTTP al proxy-cache.
5) Finalmente, el proxy-cache almacena el objeto recibido en su disco local y

envía una copia, en un mensaje HTTP de respuesta, al navegador cliente (en
la conexión TCP establecida entre el cliente y el proxy-cache).
(12)
El proxy-cache actúa como servidor del cliente y como cliente del servidor. Los En inglés, Internet Service Provi-
12 ders (ISP)
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 pe-

ticiones.
• Puede reducir de manera significativa el tráfico del enlace de la institución

con Internet.
Los servidores intermediarios se usan también en otros protocolos además del

HTTP. En general, se sitúan en una discontinuidad para hacer una función.
Por ejemplo, para hacer un cambio de red: una máquina conectada a la red
interna de una organización, que usa direcciones IPv4 privadas (por ejemplo,
10.*.*.*), y también a Internet, puede hacer de proxy-cache para la traducción
de direcciones IP entre las dos redes (NAT).
Network Address Translation (NAT)
En los paquetes IP salientes: sustituir la dirección IP de las máquinas internas (no válidas
en Internet) por la suya propia; en los paquetes IP entrantes: sustituir su propia dirección
IP por la de una máquina interna y reenviar el paquete hacia la red interna. Para saber a
quién se tiene que entregar, el servidor intermediario debe asociar cada uno de sus puertos
a las máquinas internas, ya que una dirección de transporte es una pareja (dirección IP,
puerto).
3.7. El GET condicional
Hemos visto que el caching puede reducir el tiempo de respuesta percibido por
el usuario, pero la copia que tenga la caché puede ser obsoleta. Es decir, el
objeto hospedado en el servidor web puede haberse modificado de manera
posterior a que al cliente lo copiara en su caché. Para solucionarlo, el protocolo

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

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

Last-Modified: de cuando el servidor envió el objeto. Esta petición
GET, que se denomina GET condicional, indica al servidor que envíe el
objeto sólo si el objeto se ha modificado desde la fecha especificada.
En el caso de que el objeto no se haya modificado desde la fecha indicada, el

servidor web contesta un mensaje a la caché como el siguiente:
HTTP/1.1 304 Not Modified
Date: Tue, 24 Mar 2009 18:23:40 GMT
(sin cuerpo)
304 Not Modified en la línea de estado del mensaje de respuesta indica a

la caché que puede pasar su copia del objeto al navegador que ha hecho la
solicitud. Hay que destacar que el mensaje de respuesta del servidor no incluye
el objeto, ya que esto sólo haría malgastar ancho de banda y la percepción del
usuario sobre el tiempo de respuesta.
3.8. Distribución de contenidos
Los mecanismos de proxy-cache son útiles para que una comunidad de usua-
rios que comparten una conexión a Internet puedan ahorrar ancho de banda
y reducir transferencias repetitivas de objetos. Sin embargo, esta sólo es una
parte del problema. Diferentes agentes participan en el rendimiento de una
transferencia web.
• Proveedor� de� contenidos� (servidor� web): debe planificar su capacidad

para dar servicio en horas punta y aguantar posibles avalanchas de peti-
ciones, y de esta manera tener una cierta garantía de que sus clientes dis-
pondrán de un buen servicio con cierta independencia de la demanda.
• Cliente: podría usar una memoria caché para economizar recursos de la

red. Cuando un contenido se encuentra en más de un lugar, debería elegir
el mejor servidor en cada momento. El original o una réplica "rápida" (o

llevar el objeto a trozos desde distintos lugares al mismo tiempo).
• Réplica: si un servidor guarda una réplica de algún contenido, probable-

mente es porque quiere ofrecerlo y reducir la carga del servidor original.
Por lo tanto debe ser "conocido" por sus clientes, pero además el contenido
tiene que ser consistente con el contenido original.
• Proveedor�de�red: debería elegir el mejor camino para una petición, vía

direccionamiento IP, vía resolución DNS (resolver nombres en la dirección
IP más próxima al cliente que consulte, aunque no es lo más habitual),
vía servidores proxy-cache HTTP y evitar zonas congestionadas (hot spots)
o flash crowd (congestión en el servidor y en la red próxima debida a una
avalancha de demandas).
En este subapartado, nos centraremos en los sistemas de distribución de docu-

mentos para ayudar a mejorar el rendimiento de la web. Más concretamente,
nos centraremos en qué puede hacer el proveedor de los contenidos.
Las aplicaciones que ofrecen contenidos en Internet se enfrentan al reto de la

escala: un único servidor frente a millones de personas que de manera even-
tual pueden pedir sus servicios todos al mismo tiempo: el proveedor de infor-
mación debe poner tantos recursos como audiencia pueda tener.
Una opción muy utilizada es que el proveedor del contenido disponga de di-
ferentes réplicas de la información. Hay varios trucos para repartir peticiones
entre los diferentes servidores que contienen las réplicas:
• Mirrors con un programa que redirige la petición HTTP a la mejor réplica.
• Hacer que el servicio de nombres DNS retorne distintas direcciones IP. Nor-
malmente, se envía la petición HTTP a la primera dirección de la lista de
direcciones IP recibidas del DNS. Si esta lista está ordenada de manera di-
ferente en cada petición al DNS (método round roben), cada vez se hará la
petición a una dirección IP diferente.
• Redireccionamiento a nivel de transporte (conmutador de nivel 4, L4

switch): un encaminador mira los paquetes IP de conexiones TCP hacia un
servidor web (puerto 80) y las redirige a la máquina interna menos cargada.
• Redireccionamiento a un nivel de aplicación (conmutador de nivel 7, L7

switch): un encaminador que mira las conexiones HTTP y puede decidir
con qué réplica contactar en función del URL solicitado. Muy complejo.
• Enviar todas las peticiones a un servidor intermediario inverso que res- Réplica
ponda con contenido guardado en la memoria o que pase la petición a
Una réplica (en inglés, mirror)
uno o varios servidores internos. es una copia exacta de otro
lugar de Internet. Los mirrors
proporcionan múltiples fuen-
tes para una misma informa-
ción y son especialmente útiles
3.8.1. Redes de distribución de contenidos por la fiabilidad que esto com-
porta. También para que el
usuario acceda a la ubicación
Han surgido empresas que se han dedicado a instalar máquinas en muchos más próxima o para repartir la
carga entre diferentes servido-
lugares del mundo y algoritmos para decidir qué máquina es la más adecuada res.
para atender las peticiones, según la ubicación del cliente y la carga de la red.
Estas empresas venden este "servidor web distribuido" a distintos clientes que (13)
En inglés, Content Delivery Net-
pagan por disponer de un sistema de servicio web de gran capacidad y que works (CDN).
puede responder a demandas de contenidos extraordinariamente altas. Estos
sistemas se denominan redes de distribución de contenidos13. Akamai
Se pueden encontrar diferen-

Una CDN es un software intermediario (middleware) entre proveedores de con- tes empresas que ofrecen es-
te servicio de redes de distribu-
tenidos y clientes web. La CDN sirve contenidos desde distintos servidores re- ción de contenidos. Akamai es
partidos por todo el planeta. La infraestructura de la CDN está compartida por la más importante. A fecha de
febrero del 2010, la UOC uti-
distintos clientes de la CDN y las peticiones tienen en cuenta la situación de lizaba Akamai para proporcio-
nar el contenido de su portal.
la Red para hacer que cada cliente web obtenga el contenido solicitado desde
el servidor más eficiente de la CDN (habitualmente una combinación del más
próximo, el menos cargado y el que tiene un camino con más ancho de banda
con el cliente).
La CDN dispone de un gran número de puntos de servicio en multitud de

proveedores de Internet y puede actuar sobre lo siguiente.
• El DNS: cuando se resuelve un nombre, el servidor DNS responde según la

ubicación de la dirección IP del cliente.
• El servidor web: cuando se pide una página web, se reescriben los URL
internos según la ubicación de la dirección IP del cliente.
• Cuando se pide un objeto a la dirección IP de un servidor de la CDN, el

conmutador (switch) de acceso a un conjunto de distintos servidores proxy-
cache, o réplicas, puede redirigir la conexión al servidor menos cargado del
grupo (todo el conjunto responde bajo una misma dirección IP).
Ejemplo de funcionamiento de una CDN
La figura siguiente muestra el ejemplo de los posibles pasos que se pueden dar cuando se
hace la petición de una página web con imágenes.
1) El cliente pide al servidor origen (www.foo.com) una página sobre música. El servi-
dor informa al navegador web que la página pedida contiene varios objetos. El URL de
estos objetos se modifica para que hagan referencia a la CDN. Por ejemplo, en lugar
de contestar http://www.foo.com/musica/Beethoven.gif contesta http://www.cdn.com/
www.foo.com/musica/Beethoven.gif.
2) El navegador pide al DNS que resuelva www.cdn.com. La petición llega hasta el DNS
autorizado por este dominio, que es un DNS de la empresa propietaria de la CDN. La
CDN responde con la dirección IP del nodo de la CDN más próximo a la ubicación del
navegador web (que es el que hace la petición para los contenidos) al DNS de la CDN. Esta
"proximidad" se calcula a partir de información que va recogiendo sobre las distancias
de los nodos de la CDN al ISP.
3) Finalmente, el navegador web pide los objetos al nodo de la CDN que le han asignado.
Las CDN no se utilizan sólo para distribuir contenidos web. También se usan
para streaming de audio y vídeo, tanto almacenado como en directo.
Finalmente hay que decir que, para proporcionar su servicio, las CDN usan el
DNS para unas funciones para las que no está diseñado. Las CDN utilizan el
DNS para redirigir las peticiones de manera transparente, pero este mecanismo
de redirección sobrecarga el DNS ya que hace que las peticiones dirigidas a la
CDN no se puedan cachear.
4. Transferencia de ficheros
(14)
El protocolo de transmisión de ficheros FTP14 permite transferir ficheros de Siglas en inglés de File Transfer
Protocol
un ordenador a otro. Funciona siguiendo el modelo cliente servidor sobre una
conexión TCP/IP. En la figura siguiente, se puede ver el funcionamiento del
FTP a grandes rasgos.
Para hacer la transferencia, el usuario debe conectarse al ordenador remoto

proporcionando un usuario y un password. La transferencia se puede hacer
tanto del ordenador del usuario al ordenador remoto como al revés.
El FTP utiliza dos conexiones entre el cliente y el servidor, una para

los datos y otra para el control. La conexión�de�control usa el puerto
TCP número 21 y se utiliza para enviar información de control, como el
usuario y el password, comandos para cambiar de directorio o comandos
para pedir y enviar ficheros. Esta conexión se mantiene abierta durante
toda la sesión. La conexión�de�datos se utiliza para enviar los ficheros
y se hace por el puerto TCP número 20. Se establece una conexión de
datos para cada fichero. Una vez enviado, la conexión se cierra. En el
caso de que se quiera enviar otro fichero, se abre una nueva conexión
de datos.
El servidor FTP mantiene información de estado durante una sesión. El servi-

dor tiene que asociar la conexión de control con una cuenta de usuario y debe
saber en todo momento en qué directorio se encuentra el usuario, ya que este
puede ir cambiando de directorio en el servidor remoto.
Los comandos se envían codificados en ASCII y finalizados con un carriage

return y un line feed. Las respuestas también acaban con un carriage return y un
line feed. Los comandos consisten en cuatro caracteres ASCII en mayúsculas,
algunos con argumentos opcionales. Algunos de los comandos más usuales

(estos comandos son del protocolo, no los comandos que el usuario pone en
el intérprete de comandos de la aplicación FTP cliente) son los siguientes.
• USER nombreUsuario: para enviar el nombre de usuario al servidor.
• PASS clave: para enviar la clave de acceso al servidor.
• LIST: para pedir al servidor que envíe la lista de ficheros del directorio
remoto actual. La lista de ficheros se envía por una conexión de datos.
• RETR fichero: para obtener un fichero del directorio actual del ordena-
dor remoto.
• STOR fichero: para enviar un fichero al directorio actual del ordenador

remoto.
Cada comando enviado al ordenador remoto genera una respuesta de este. Bibliografía
Las respuestas son números de tres dígitos seguidos de un mensaje opcional.
Acerca de las peticiones y
Algunas respuestas habituales son: las respuestas, encontraréis
más información sobre los
comandos y respuestas en el
• 331 Username Ok, password required RFC 959.
• 125 Data connection already open; transfer starting
• 425 Can't open data connection
• 452 Error writing file
4.1. Seguridad en la transferencia de ficheros
(15)
La especificación original del FTP es inherentemente insegura porque no tiene SFTP es la abreviatura de SSH
File Transfer Protocol o Secure File
ningún método para transferir datos de manera cifrada. Esto quiere decir que
Transfer Protocol.
en la mayoría de las configuraciones de red, el nombre de usuario, la clave de
acceso, los comandos FTP y los ficheros transferidos se pueden capturar desde (16)
FTPS es la abreviatura de FTP
la misma red utilizando un sniffer. La solución habitual a este problema es usar sobre SSL.
SFTP15 o FTPS16.
IETF
El SFTP es un protocolo que proporciona acceso, transferencia y gestión
de ficheros sobre un canal fiable. Normalmente se utiliza con el SSH, y El SFTP fue diseñado por la In-
ternet Engineering Task Force
el SSH es el que proporciona el canal fiable, aunque se podría utilizar (IETF) como una ampliación
del Secure Shell Protocol (SSH)
con otros protocolos de seguridad. Por lo tanto, la seguridad no la pro- versión 2.0.
porciona directamente el protocolo SFTP, sino el SSH o el protocolo que
se utilice para este propósito.
5. Correo electrónico en Internet
El correo electrónico existe desde los principios de Internet. En los años se-
senta los sistemas mainframe ya tenían formas de comunicación uno a uno
tipo mensajería, y a lo largo de los años estos sistemas han ido evolucionando
hasta llegar al nivel de sofisticación y potencia actuales. Hoy día, es una de las
aplicaciones más importantes y usadas de Internet.
En la figura siguiente, se presenta una visión del sistema de correo en Internet.

Cuando un usuario quiere enviar un mensaje, el agente usuario de mensajería
que está utilizando envía el mensaje a un servidor de correo. Este –el servidor
de correo origen– pregunta al DNS la dirección correspondiente al campo MX
del dominio destino del mensaje y envía el mensaje al puerto 25 de este servi-
dor de correo vía SMTP. La transmisión del mensaje se hace utilizando el pro-
tocolo TCP porque proporciona una transmisión fiable de los datos. Una vez
el servidor destino ha aceptado el mensaje, lo almacena en el buzón del usua-
rio destinatario para que más adelante el usuario destinatario –previa autenti-
cación de este– lo lea vía un agente usuario de mensajería. Debemos destacar
el hecho de que el protocolo SMTP normalmente no utiliza ningún servidor
intermediario entre el servidor origen ni el destino. La comunicación se hace
directamente aunque cada uno esté en una punta del mundo.
Visión de alto nivel del sistema de correo electrónico en Internet

En el caso de que el servidor origen no pueda enviar el mensaje al servidor

destino por algún fallo, el servidor origen encola el mensaje y reintenta en-
viarlo más tarde. Los reintentos se hacen normalmente cada treinta minutos.
Si después de algunos días no se puede entregar el mensaje, el servidor origen
elimina el mensaje y notifica al remitente que no lo ha podido entregar.
5.1. SMTP
El protocolo Simple�Mail�Transfer�Protocol (SMTP) está definido en el RFC RFC del SMTP

2.821 y es el estándar actual de transmisión de correo electrónico en Internet.
El primer RFC que describe el
SMTP data de 1982 (RFC 821),
El protocolo SMTP tiene muy buenas cualidades, como se puede deducir por pero antes de esta fecha ya ha-
bía versiones de lo que ahora
el éxito que ha conseguido, pero arrastra algunos inconvenientes heredados es el SMTP.
del pasado. Por ejemplo, tanto el cuerpo de los mensajes como las cabeceras
van codificados en caracteres ASCII de 7 bits. Esto hace que cualquier dato que
no esté codificado en este formato deba codificarse en ASCII de 7 bits antes de
enviarlo y volverse a descodificar una vez recibido.
Ejemplo de envío de un mensaje
A continuación, ponemos el ejemplo del envío de un mensaje uoc.edu a upc.cat utili-

zando SMTP. El ejemplo muestra los comandos que se intercambian una vez la conexión
fiable (la conexión TCP) ha sido establecida. Con el objetivo de clarificar la comprensión
del ejemplo, los comandos que envía el cliente (originador) se han prefijado con C: y los
del servidor (receptor) con S:. También hemos numerado las líneas para poder referirnos
a estos más fácilmente.
1 S: 220 upc.cat
2 C: HELO uoc.edu
3 S: 250 Hello uoc.edu please to meet you
4 C: MAIL FROM: <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 envía el mensaje Este es un mensaje de correo de ejem-

plo. ¿Verdad que es sencillo? desde el servidor de correo uoc.edu a upc.cat.
Como parte del diálogo, el cliente envía los comandos: HELO, MAIL FROM, RCPT TO,
DATA y QUIT. El cliente envía el mensaje (líneas 10 a 11) después del comando DATA y lo
acaba con una línea que sólo contiene un punto (línea 12: CRLF.CFLR), y que indica el
final del mensaje enviado al servidor. El servidor contesta cada comando con un código
de respuesta y un texto opcional explicativo (en inglés).
El protocolo SMTP usa conexiones persistentes. En el caso de que el servidor Diálogo con el servidor
origen tenga más de un mensaje para enviar al mismo servidor destino, los SMTP
mensajes se envían aprovechando la misma conexión TCP. El cliente empieza Si tenéis acceso a un servidor
cada mensaje con un nuevo MAIL FROM: uoc.edu, acaba cada mensaje con SMTP que no requiera auten-
ticación, vosotros mismos po-
un punto en una línea que sólo contiene un punto y envía el comando QUIT déis intentar dialogar directa-
mente con el servidor SMTP.
una vez ha acabado de enviar todos los mensajes. Para hacerlo, sólo tenéis que
hacer: telnet nombre-
Servidor 25, siendo nom-
5.2. Formato de los mensajes breServidor el del servidor
SMTP al cual os conectáis. Al
hacer esto, estáis establecien-
do una conexión TCP con el
Tal y como sucede en las cartas postal que tienen un sobre y una carta, los
servidor SMTP. Podéis repe-
mensajes de correo electrónico tienen dos partes. tir los comandos del ejemplo
prefijados con C: y veréis que
se envía un mensaje de correo
electrónico. (Intentad poner
• Cabecera: incluye la información general del mensaje. Sería equivalente como recipiente una dirección
al sobre de la carta postal y está formada por varios campos cabecera. de correo electrónico vuestra y
recibiréis el mensaje.)
• Cuerpo�del�mensaje: contiene el mensaje en sí. Corresponde al contenido

de la carta postal. Esta parte es opcional.
Formato de las cabeceras
El RFC 822 especifica el formato de las cabeceras, así como su semántica. Cada campo
de la cabecera consta de un nombre�del�campo seguido del carácter ":/, opcionalmente
acompañado por un cuerpo�del�campo, y acaba con un CRLF.
Ejemplo de cabecera de un mensaje
El ejemplo del subapartado 5.1 no contiene ninguna cabecera. En la continuación repe-

timos el mismo mensaje, incluyendo la cabecera del mensaje. De este modo, primero
encontramos la cabecera (líneas 10 a 13), seguida del cuerpo del mensaje (líneas 14 y
15). Tal y como se puede ver en la línea 13, el separador entre la cabecera y el cuerpo del
mensaje es una línea en blanco (o sea, CRLF). Estos campos de la cabecera son diferentes
de los comandos del SMTP ((HELO, MAIL FROM, RCPT TO, DATA y QUIT)), aunque puedan
parecer similares.
1 S: 220 upc.cat
2 C: HELO uoc.edu
3 S: 250 Hello uoc.edu please to meet you
4 C: MAIL FROM: <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
5.2.1. Formato de mensajes MIME
(17)
Tal y como hemos dicho anteriormente, una limitación de la norma RFC 822 MIME es la abreviatura de Mul-
tipurpose Internet Mail Extensions.
es que define un formato de mensaje y un contenido con una única parte de
texto en ASCII de 7 bits. Se vio que este formato era muy pobre y que hacía falta
RFC del formato MIME
algún método para superar sus limitaciones. El formato MIME17 redefine el
formato del mensaje para permitir, sin perder la compatibilidad con el formato El formato de mensajes MIME
está especificado en los RFC
definido por el RFC 822, dar apoyo a: 2.045, 2.046, 2.047, 4.288,
4.289 y 2.049.
• Texto codificado con un juego de caracteres diferente del ASCII de 7 bits.

• Adjunciones que no sean texto.
• Cuerpos del mensaje con múltiples partes.
• Cabeceras codificadas con un juego de caracteres diferente del ASCII de
7 bits.
Para hacerlo, MIME define un conjunto de nuevos campos de cabecera MI-

ME-version, Content-ID, Content-Type, Content-Disposition y Con-
tent-Transfer-Encoding.
En este módulo, nos centraremos en Content-Type: y Content-Transfer-

Encoding::.
Content-Type
Content-Type: indica al agente de usuario de mensajería receptor del

mensaje qué tipo de contenido contiene el cuerpo del mensaje, lo que
permite que este tome la acción apropiada para cada contenido de men-
saje. El tipo de contenido se especifica con un tipo y un subtipo.
Ejemplo
Content-Type: image/JPEG
indica que el cuerpo del mensaje contiene una imagen formateada en JPEG. De esta
manera, el agente usuario de mensajería que reciba el mensaje puede hacer las acciones
necesarias, como enviar el cuerpo del mensaje a un descompresor JPEG.
Formato: Content-Type: type/subtype; parameters
Algunos�tipos Algunos�subtipos
text plain, html
image jpeg, gif
audio basic, mp4, mpeg
video mpeg, quicktime
application msword, octet-stream, zip

La Internet Assigned Numbers Authority (IANA) mantiene la lista de tipos

y subtipos. Podéis encontrarla en http://www.iana.org/assignments/media-ty-
pes.
Content-Transfer-Encoding
Recordad que hemos dicho que los mensajes SMTP tienen que ir codificados
en ASCII de 7 bits. La cabecera Content-Transfer-Encoding: indica que
el cuerpo del mensaje ha sido codificado en ASCII y el tipo de codificación
utilizado.
Ejemplo
Content-Transfer-Encoding: base64
indica que se ha utiliza la codificación base64 para codificar el cuerpo del mensaje. La
codificación base64 codifica una secuencia arbitraria de bytes en una forma que satisface
las reglas del ASCII de 7 bits, y por lo tanto, no confundirá el SMTP.
Otra técnica popular para codificar que también satisface el ASCII de 7 bits es
la quoted-printable, que se acostumbra a utilizar para convertir texto codificado
en ASCII de 8 bits (que puede contener caracteres no ingleses) en ASCII de 7
bits.
Ejemplo de quoted-printable
El siguiente es un ejemplo de quoted-printable:
Subject: =?iso-8859-1?Q?Qu=E9?= tal =?iso-8859-1?Q?est=E1s=3F?=
que corresponde a "Subject: ¿Qué tal estás?", donde:
• = delimita la secuencia codificada con quoted-printable. En este caso, hay delimitadas

dos secuencias: ¿Qué y estás?
• ? separa las partes.
• Codificado en ISO-8859-1.
• Q: codificación quoted-printable.
• E9 es el código correspondiente a é en la codificación ISO-8859-1
Cuando volváis a recibir un mensaje (frecuentemente reenviado) con una secuencia co-
mo esta ya sabréis de dónde sale :-)
A continuación, pondremos un ejemplo que incluirá los diferentes aspectos

vistos sobre el formato MIME:
From: marques@uoc.edu
To: puig@upc.cat
Subject: Foto del niño
MIME-version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
(datos codificados en base64

............................................................datos
codificados en base64)
La cabecera MIME-version indica la versión de MIME que se está utilizando.
La cabecera Content-Type: también se utiliza para que un mensaje pueda

contener texto y ficheros adjuntos. En este caso, a la cabecera Content-Type:
se le añade un indicador de inicio y final de cada parte (boundary).
S/MIME (Secure/Multipurpose Internet Mail Extensions) es un estándar para cifra-

do de clave pública y firma de correo electrónico encapsulado en MIME. S/MI-
ME proporciona:
• Autenticación, integridad y no repudio (usando firma digital).

• Privacidad y seguridad de los datos (usando cifrado).
5.3. Protocolos para acceder a los buzones de correo
Los servidores SMTP guardan los mensajes recibidos en los buzones de correo
de los destinatarios de los mensajes. Es posible acceder a estos mensajes co-
nectándose al servidor SMTP y ejecutando un programa para leer el correo.
La mayoría de los usuarios, sin embargo, leen el correo electrónico desde un
ordenador personal, mediante un cliente de correo que les ofrece un conjunto
amplio de funcionalidades y que incluye la posibilidad de ver mensajes mul-
timedia y adjunciones.
5.3.1. POP3
(18)
POP318 es un protocolo del ámbito aplicación para que un agente de usuario de El protocolo POP3 (Post Office
Protocol versión 3) está especifica-
correo electrónico (el cliente) pueda obtener el correo de un servidor de correo do en el RFC 1939.
remoto. El funcionamiento es muy sencillo. El cliente abre una conexión TCP
con el servidor en el puerto 110. Una vez establecida esta conexión, el POP3
pasa por tres fases.
1)�Autorización: el usuario envía un usuario y una clave de acceso (en claro)

para autenticar al usuario.
2)� Transacción: el agente de usuario baja mensajes. En esta fase, el agente

de usuario puede marcar los mensajes para que se borren, eliminar marcas de
borrar y obtener información sobre el buzón del usuario.
3)� Actualización: ocurre después de que el cliente ha ejecutado el pedido

QUIT, que finaliza la sesión POP3. En este momento, el servidor borra los men-
sajes que se habían marcado para ser borrados.
Los comandos son palabras clave, que pueden estar seguidas de argu-
mentos, y que acaban con un salto de línea (CRLF). Tanto las palabras
clave como los argumentos son caracteres ASCII imprimibles.
Las respuestas consisten en un indicador de estado (+OK) o (-ERR) que puede

estar seguido por una información adicional.
• +OK: el servidor indica al cliente que el comando recibido era correcto
• -ERR: el servidor indica al cliente que había algo erróneo en el comando

recibido.
Ejemplo de una sesión de autenticación
El siguiente es un ejemplo de una sesión de autenticación (una vez establecida la cone-

xión al puerto TCP 110 del servidor de correo).
+OK POP3 server ready

USER marques
+OK
PASS uoc
+OK user successfully logged on
Conexión a un servidor de correo
Si tenéis acceso a un servidor de correo que no requiera utilizar una conexión segura, os
podéis intentar conectar con telnet servidorCorreo 110.
El usuario puede configurar su agente de usuario –utilizando POP3– para que aplique la
política "baja los mensajes y bórralos" o la política "baja los mensajes y deja copia de los
mismos en el servidor".
Ejemplo de bajar y borrar los mensajes
El agente de usuario obtiene una lista de los mensajes (LIST), y los va bajando (RETR) y
borrando (DELE) uno a uno. Por claridad, identificamos las líneas emitidas por el agente
de usuario con C: y por el servidor de correo con S:
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
C: RETR 1
S: +OK 120 octets
S: < el servidor de POP3 envía el mensaje 1>
S: .
C: DELE 1
S: +OK message 1 deleted
C: RETR 2
S: +OK 200 octets
S: < el servidor de POP3 envía el mensaje 2>
S: .
C: DELE 2
S: +OK message 2 deleted
C: QUIT
S: +OK POP3 server signing off
Un problema del modo "baja los mensajes y bórralos" es que el correo se ba-
ja en un ordenador. Si el usuario posteriormente quiere acceder al correo des-
de otro ordenador no lo podrá hacer, ya que el servidor ya no contendrá los
mensajes. Esto es problemático para usuarios que acostumbran a leer el correo
desde diferentes ordenadores, por ejemplo el ordenador de casa, un ordenador
portátil, el trabajo, etc.
El servidor POP3 no guarda estado entre sesiones.
5.3.2. IMAP
(19)
El protocolo IMAP19 es un protocolo de acceso a correo como el POP3, pero El IMAP está especificado en el
RFC 3.501.
tiene muchas más funcionalidades. También es más complejo de implementar,
tanto en la parte cliente como en la parte del servidor.
(20)
Los servidores IMAP20 asocian cada mensaje a una carpeta. Cuando un men- IMAP es la abreviatura de Inter-
net Mail Access Protocol.
saje llega al servidor, este se asocia a la carpeta INBOX. Posteriormente, el re-
ceptor puede mover este mensaje a otra carpeta creada por el mismo usuario.
También puede leerlo, borrarlo, etc. El protocolo IMAP proporciona coman-
dos para permitir a los usuarios crear carpetas y para mover mensajes de una
carpeta a otra. El IMAP también proporciona comandos que permiten a los
usuarios hacer buscas de mensajes que satisfagan ciertos criterios en las carpe-
tas remotas. De todo esto, ya se ve que los servidores IMAP deben mantener
información entre sesiones IMAP: los nombres de las carpetas, qué mensajes
están asociados a cada carpeta, etc.
Otra característica interesante del IMAP es que tiene comandos que permiten
al agente de usuario obtener partes de un mensaje: puede obtener sólo las ca-
beceras del mensaje, o sólo una parte de un mensaje multiparte (por ejemplo,
el texto del mensaje sin el fichero adjunto). Esto es especialmente útil cuando
se utiliza una conexión con poco ancho de banda.
5.3.3. Web
Una manera muy popular de acceder al correo es mediante un navegador web.

En este caso, el agente de usuario es el navegador web y el usuario se comunica
con su buzón vía HTTP. De esta manera, cuando se quiere leer un mensaje
el navegador lo obtiene del servidor de correo usando el protocolo HTTP, y
cuando se quiere enviar un mensaje, el navegador lo envía al servidor de correo
usando también el protocolo HTTP.
6. Aplicaciones de igual a igual para la compartición

de ficheros
La arquitectura de igual a igual es una manera de construir aplicaciones que Bibliografía

persigue la utilización de los recursos informáticos y el ancho de banda que recomendada
aportan los usuarios de la aplicación aunque estos estén conectados de manera En el artículo de Lua�y�otros
intermitente. (2005). "A survey and com-
parison of peer-to-peer over-
lay network schemes". IEEE
Las aplicaciones de igual a igual se han popularizado de la mano de las apli- Communications Surveys &
Tutorials (vol. 7, núm. 2) en-
caciones de compartición de ficheros. La primera fue Napster, pero la han ido contraréis un resumen de có-
mo funcionan las redes su-
siguiendo otras aplicaciones. En este material presentaremos varias, que nos perpuestas de igual a igual
tienen que ayudar a entender cómo funcionan estos tipos de aplicaciones. Ca- más populares, así como
una comparativa entre estas.
da una de estas aplicaciones utiliza su propia organización interna y sus pro- También encontraréis más
pios protocolos. detalle de los sistemas expli-
cados en este apartado.
Los nodos que forman el sistema o aplicación de igual a igual se organizan

formando una red superpuesta (overlay network, en inglés) que funciona sobre
la red física que conecta los nodos. Hay diferentes maneras de organizar esta
red superpuesta, las cuales se pueden dividir en dos categorías: estructuradas
y no estructuradas.
6.1. Redes superpuestas no estructuradas
Un sistema de igual a igual que utilice una red superpuesta del tipo no estruc-
turado es un sistema que está compuesto de iguales que se conectan a la red
sin conocer su topología. Estos sistemas usan mecanismos de inundación pa-
ra enviar consultas mediante la red superpuesta. Cuando un igual recibe la
pregunta, envía al igual que la ha originado una lista de todo el contenido
que encaja con la pregunta. Aunque las técnicas basadas en la inundación
van bien para localizar objetos altamente reproducidos y son resistentes ante
las conexiones y desconexiones de los nodos, no tienen un comportamiento
muy bueno cuando se hacen buscas de objetos poco reproducidos. De esta
manera, las redes superpuestas no estructuradas tienen fundamentalmente un
problema: cuando deben gestionar un ritmo elevado de consultas o cuando
hay crecimientos repentinos del tamaño del sistema, se sobrecargan y tienen
problemas de escalabilidad.
A pesar de que el sistema de direccionamiento basado en claves que utilizan

los sistemas de igual a igual estructurados –veremos este tipo de sistemas en el
próximo subapartado– pueda localizar de manera eficiente objetos y, además,
sea escalable, sufre sobrecargas significativamente mayores que los sistemas
no estructurados por contenidos populares. Por este motivo, los sistemas des-
centralizados no estructurados se usan más.
Algunos ejemplos de sistemas no estructurados son Gnutella, FastTrack/Ka-

ZaA, BitTorrent y Overnet/eDonkey2000.
Gnutella: protocolo totalmente descentralizado para hacer buscas sobre una

topología de iguales totalmente plana. Ha sido (y todavía lo es) muy usado.
Para localizar un objeto, un igual pregunta a sus vecinos. Estos inundan a
sus vecinos y así hasta un cierto radio. Este mecanismo es extremadamente
resistente ante entradas y salidas de nodos, pero los mecanismos actuales de
busca no son escalables y generan cargas no esperadas en el sistema. La figura
siguiente muestra un ejemplo de busca.
KaZaA: es un sistema de ficheros descentralizado en el que los nodos se agru-

pan en torno a superiguales (super-peers en inglés) para hacer las buscas más
eficientes, tal y como se muestra en la figura siguiente. La comunicación entre
los iguales en KaZaA se hace utilizando el protocolo Fast Track, que es un pro-
tocolo propietario. Los superiguales son iguales del sistema que se han elegido
para que mantengan metainformación que hará las buscas más eficientes. En
el momento de una busca, el igual pregunta al superigual al que está conec-
tado. Este, de manera similar a lo que hace Gnutella, hace un broadcast a los
otros superiguales.
Los iguales se conectan a un superigual. Las consultas se encaminan hacia los

superiguales. Las bajadas se hacen entre iguales.
BitTorrent: es un sistema de igual a igual para distribuir grandes volúmenes de Bibliografía

datos sin que el originador de la información tenga que soportar todo el cos- complementaria
te de los recursos necesarios para servir el contenido. Este tipo de soluciones Para más información sobre
son útiles para distribuir contenidos que son muy populares. BitTorrent utiliza el funcionamiento de BitTo-
rrent, podéis consultar el ar-
servidores para gestionar las bajadas. Estos servidores almacenan un fichero tículo siguiente:
que contiene información sobre el fichero: longitud, nombre, información de B.�Cohen (2003, junio). "In-
centives Build Robustness in
resumen (hashing information, en inglés) y el URL del tracker. El tracker (podéis BitTorrent". Proc. First Works-
ver la figura siguiente) conoce todos los iguales que tienen el fichero (tanto hop the Economics of Peer-to-
Peer Systems. Berkeley, CA:
de manera total como parcial) y hace que los iguales se conecten unos con University of Berkeley.
otros para bajar o subir los ficheros. Cuando un nodo quiere bajar un fichero
envía un mensaje al tracker, que le contesta con una lista aleatoria de nodos
que están bajando el mismo fichero. BitTorrent parte los ficheros en trozos
(de 256 kB) para saber qué tiene cada uno de los iguales. Cada igual que está
bajando el fichero anuncia a sus iguales los trozos que tiene. El protocolo pro-
porciona mecanismos para penalizar a los usuarios que obtienen información
sin proporcionarla. De esta manera, a la hora de subir información, un igual
elegirá otro igual del que haya recibido datos.
eDonkey: es un sistema de igual a igual híbrido organizado en dos niveles

para el almacenamiento de información. Está formado por clientes y servido-
res. Los servidores actúan como concentradores para los clientes y permiten
a los usuarios localizar los ficheros que hay en la Red. Esta arquitectura pro-
porciona bajada concurrente de un fichero desde distintas ubicaciones, uso de
funciones resumen (hash, en inglés) para la detección de ficheros corruptos,
compartición parcial de ficheros mientras se bajan y métodos expresivos pa-
ra hacer buscas de ficheros. Para que un nodo se pueda conectar al sistema,
es necesario que conozca un igual que actúe como servidor. En el proceso de
conexión, el cliente proporciona al servidor la información sobre los ficheros
que comparte. Cuando un cliente busca un fichero, los servidores proporcio-
nan las ubicaciones de los ficheros. De esta manera, los clientes pueden bajar
los ficheros directamente de las ubicaciones indicadas.
eMule puede funcionar tanto sobre la red eDonkey como sobre Kad. Kad es
una implementación de Kademlia, una red superpuesta estructurada (en el
próximo apartado se explica cómo funcionan estos tipos de sistemas).
6.2. Redes superpuestas estructuradas
La topología de la red superpuesta sobre la cual se construyen estos sistemas

está fuertemente controlada y el contenido no va a cualquier lugar, sino a uno
determinado que hace que las consultas sean más eficientes. Estos sistemas
utilizan tablas de hash distribuidas (distributed hash tables o DHT, en inglés)
como sustratos, en los cuales la ubicación de los objetos (o valores) se hace de
manera determinista. Los sistemas que se basan en DHT tienen la propiedad
de que asignan los identificadores de nodos de una manera consistente a los
iguales dentro de un espacio con muchos identificadores. A los objetos de
datos se les asigna un identificador, que se denomina clave, elegido dentro del
mismo espacio de nombres. El protocolo de la red superpuesta mapea las claves
en un único nodo entre los conectados. Estas redes superpuestas soportan el
almacenamiento y la recuperación de pares {clave,valor} en la red superpuesta.
Este tipo de sistemas usan un sistema de direccionamiento estructurado, man-

teniendo tanto la descentralización de Gnutella como la eficiencia y garantía
de localizar los resultados de Napster.
Por este motivo, cada igual mantiene una tabla de direccionamiento peque-
ña. Los mensajes se direccionan de una manera progresiva hacia los iguales
a través de caminos de superposición. Cada nodo envía el mensaje al nodo
de su tabla de direccionamiento que tiene un identificador más próximo a la
clave en el espacio de identificadores. Los diferentes sistemas basados en DHT
tienen distintos esquemas de organización para los objetos de datos y su espa-
cio de claves y estrategias de direccionamiento. En teoría, los sistemas basados
en DHT garantizan que, como media, se puede localizar cualquier objeto en
O(log N) saltos en la red superpuesta, donde N es el número de iguales en el
sistema. El camino entre dos nodos en la red física puede ser muy diferente
del camino en la red superpuesta DHT. Esto puede provocar que la latencia en
las buscas en un sistema de igual a igual basado en una red DHT sea bastan-
te grande y pueda afectar negativamente al rendimiento de la aplicación que
funcione por encima.
Ejemplos de redes superpuestas estructuradas
Can, Chord, Tapestry, Pastry, Kademlia, DKS o Viceroy son ejemplos de redes superpues-
tas estructuradas.
Podéis encontrar más información de estos sistemas en:
CAN
S.�Ratnasamy�y�otros (2001). "A Scalable Content Addressable Network". Proc. ACM SIG-
COMM (págs. 161-72).
Chord
I.�Stoica;�R.�Morris�y�otros (2003). "Chord: A Scalable Peer-to-Peer Lookup Protocol for

Internet Applications". IEEE/ACM Trans. Net. (vol. 11, núm. 1, págs. 17-32).
Tapestry
B.�Y.�Zhao�y�otros (2004, enero). "Tapestry: A Resilient Global-Scale Overlay for Service

Deployment". IEEE JSAC (vol. 22, núm. 1, págs. 41-53).
Pastry
A.�Rowstron;�P.�Druschel (2001). "Pastry: Scalable, Distributed Object Location and Rou-

ting for Large-scale Peer-to-peer Systems". Proc. Middleware.
Kademlia
P.� Maymounkov;� D.� Mazieres (2002, febrero). "Kademlia: A Peer-to-Peer Information

System Based on the XOR Metric". Proc. IPTPS (págs. 53-65). Cambridge, MA: EE. UU.
DKS
DKS(N,k,f). A Familiy of Low Communication, Scalable and Fault-Tolerant Infrastructures for

P2P Applications.
Viceroy
D.�Malkhi;�M.�Naor;�D.�Ratajczak (2002, julio). "Viceroy: A Scalable and Dynamic Emu-

lation of the Butterfly". Proc. ACM PODC 2002 (págs. 183-92). Monterey, CA: EE. UU.
eMule tiene una versión que funciona sobre la red Kad, que es una implemen-
tación de Kadmelia. Kad mejora la localización de ficheros en la Red y la hace
más resistente a ataques a los servidores centrales.
7. Mensajería instantánea
La mensajería instantánea es una forma de comunicación textual en tiempo

real entre dos o más personas a través de Internet o algún otro tipo de red. La
mensajería instantánea se diferencia del correo electrónico en que el usuario
percibe sincronismo en la comunicación, aunque muchos de los sistemas de
mensajería instantánea también permiten enviar mensajes a personas que en
aquel momento no están conectadas. En este caso, el destinatario recibirá el
mensaje cuando se vuelva a conectar al sistema.
La mensajería instantánea permite una comunicación efectiva y eficiente y

consigue una recepción inmediata de la confirmación o la respuesta. Normal-
mente, las respuestas se pueden guardar y consultar con posterioridad.
Frecuentemente, combinado con la mensajería instantánea o en torno a la

misma también encontramos otras funcionalidades que la hacen aún más
completa y popular, como cámaras de vídeo o la posibilidad de hablar direc-
tamente mediante Internet. En este apartado, sin embargo, nos centraremos
en la mensajería instantánea textual.
7.1. XMPP
(21)
El XMPP21 es un protocolo libre de mensajería instantánea de especificaciones XMPP es la abreviatura de Ex-
tensible Messaging Presence Proto-
abiertas basado en el XML, y que ha sido estandarizado por la IETF. col. El XMPP antes se conocía co-
mo jabber.
22
Como se puede ver en la siguiente figura, el XMPP utiliza una arquitectura (22)
El puerto estándar para el
cliente-servidor descentralizada: de manera similar a como lo hace el SMTP, XMPP es el 5222.
no hay un servidor central que coordine la mensajería. Los clientes no se co-
munican directamente unos con otros, lo hacen mediante los servidores. Arquitecturas
centralizadas
De manera similar al correo electrónico, cada usuario tiene una dirección úni- Otros sistemas de mensajería
ca formada por dos campos: un nombre de usuario (único para cada servidor) instantánea como Windows Li-
ve Messenger o AOL Instant
seguido de la dirección DNS del servidor que hospeda al usuario, separados Messenger utilizan arquitectu-
ras centralizadas.
por el símbolo @, 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 envía el mensaje a su servidor (en este caso, el servidor 3).
a) El servidor 3 pide al DNS la dirección IP correspondiente al servidor 1.

b) Si el servidor 3 bloquea la comunicación hacia el servidor 1, el mensaje se

descarta.
2) El servidor 3 obra una conexión con el servidor 1.
a) Si el servidor 1 bloquea los mensajes procedentes del servidor 3, el mensaje

se descarta.
b) Si el cliente 3 no está conectado en estos momentos, el servidor 1 almacena

el mensaje para entregarlo más adelante.
3) El servidor 1 entrega el mensaje al cliente 3.
Los puntos fuertes del protocolo XMPP son los siguientes.
• Descentralización: cualquiera puede tener un servidor XMPP. No hay un

servidor centralizado que coordine la mensajería.
• Estándares�libres: la Internet Engineering Task Force tiene el XMPP apro-

bado como un estándar de mensajería instantánea y presencia (RFC 3.920
y RFC 3.921).
• Seguridad: los servidores XMPP se pueden aislar de la red XMPP pública

(por ejemplo, en la intranet de una compañía), y el núcleo de XMPP in-
cluye seguridad (vía SASL y TLS).
• Flexibilidad: por encima del XMPP, se pueden añadir funcionalidades a

medida.
• Al ser un protocolo abierto, cada usuario puede utilizar un cliente XMPP SASL
diferente, siempre y cuando cumpla las especificaciones del XMPP.
El Simple Authentication and Se-
curity Layer (SASL) es un fra-
Los puntos débiles del protocolo XMPP son los siguientes. mework para la autenticación
y la seguridad de los datos en
protocolos de Internet. Separa
los mecanismos de autentica-
• Overhead�de�la�información�de�presencia: en torno al 70% del tráfico ción de los protocolos de apli-
entre servidores XMPP es información de presencia, cuyo 60% es redun- cación haciendo posible –en
teoría– que cualquier mecanis-
dante. La información de presencia permite saber qué amigos o contactos mo de autenticación soporta-
do por el SASL se pueda utili-
hay conectados y, por lo tanto, es posible enviar mensajes instantáneos. zar en cualquier protocolo de
aplicación. Está especificado
en el RFC 4.422.
• La�inclusión�de�datos�binarios�es�ineficiente: XMPP se codifica como un
único documento XML. Para incluir datos binarios, estos se deben codifi-
car en base64. Cuando hay que enviar cantidades considerables de datos Jingle
binarios (por ejemplo, envío de ficheros), lo mejor es hacer el envío de Jingle es una ampliación del
manera externa al XMPP y utilizar mensajes XMPP para coordinarse. XMPP para iniciar y gestionar
sesiones multimedia entre dos
entidades XMPP, de manera
que sean interoperables con
estándares existentes de Inter-
net.
8. Telnet y Secure Shell: acceso a ordenadores remotos
(23)
El protocolo Telnet23 se usa en Internet o en redes de área local para propor- La especificación de Telnet se
publicó en el año 1983 en el están-
cionar una comunicación bidireccional interactiva en el acceso a ordenadores dar RFC 854.
remotos. Está basado en el protocolo de transporte TCP. En una comunicación
Telnet, normalmente se sigue el modelo cliente-servidor, es decir, el sistema
usuario establece una conexión con el sistema proveedor, que está esperando
peticiones de conexión en un puerto determinado. Se puede utilizar cualquier
número de puerto para las conexiones y, de hecho, hay muchas aplicaciones
que utilizan el protocolo Telnet para la comunicación, cada una con su propio
número.
La aplicación básica, sin embargo, es establecer una sesión de trabajo interac- Terminal virtual de red
tiva con el sistema servidor. En este caso, el número de puerto utilizado es
Un terminal virtual de red, en
el 23. Esta sesión de trabajo en el ordenador remoto se hace vía un terminal inglés Network Virtual Termi-
virtual. Para resolver el problema del control del terminal en la aplicación de nal (NVT), es un dispositivo
imaginario por el cual se defi-
sesiones interactivas, en el protocolo Telnet se utiliza el concepto de terminal nen unas funciones de control
canónicas, de manera que se
virtual de red o NVT. Un NVT es un terminal virtual con una funcionalidad puede establecer una corres-
muy básica, definida en la misma especificación del protocolo. pondencia entre estas funcio-
nes y las de cada tipo de ter-
minal real.
Cuando se establece la conexión entre el cliente y el servidor, inicialmente

se supone que la comunicación se produce entre dos NVT. Esto quiere decir
que tanto el sistema cliente como el sistema servidor deben mapear sus carac-
terísticas en las de un NVT y suponer que en el otro extremo de la conexión
hay otro NVT. En el modo de operación normal, cada terminal acepta datos
del usuario y los envía mediante la conexión establecida al otro terminal, y
acepta también los datos que llegan por la conexión y los presenta al usuario.
La comunicación se hace en bytes de 8 bits.
8.1. Seguridad del protocolo Telnet
Telnet no es un protocolo seguro, por las razones siguientes:
• No cifra ningún dato enviado a través de la conexión (ni las claves de

acceso), y esto permite espiar la comunicación y poder utilizar la clave de
acceso –así como cualquier otra información enviada– más adelante para
usos malintencionados.
• La mayoría de las implementaciones de Telnet no proporcionan autenti-

cación que asegure que la comunicación se lleva a cabo entre los dos or-
denadores deseados y no está interceptada por el camino.
8.2. Secure Shell
La solución a la falta de seguridad del protocolo Telnet ha sido el protocolo Puerto TCP 22
Secure Shell (SSH).
El puerto estándar para con-
tactar a un servidor SSH es el
puerto TCP 22.
El SSH proporciona la funcionalidad de Telnet con los añadidos siguien-
tes:
a) Permite el cifrado para evitar que sea posible interceptar los datos
que se envían.
b) Permite la autenticación con clave pública para asegurar que el orde-

nador remoto es quien dice ser. El SSH tiene la debilidad de que el usua-
rio debe confiar en la primera sesión con un ordenador cuando todavía
no ha adquirido la clave pública del servidor.
9. Aplicaciones multimedia en red
Las aplicaciones multimedia en red tienen unos requerimientos muy diferen-

tes a los de las aplicaciones tradicionales en la red Internet (correo electrónico,
transferencia de ficheros, etc.).
Si tenemos en cuenta dos de los requerimientos más relevantes que tienen Ved también
las aplicaciones de red, como son la tolerancia a pérdidas de datos y las con-
Para una descripción comple-
sideraciones temporales, nos damos cuenta de que estos son especialmente ta de los requerimientos de las
importantes para las aplicaciones multimedia en red. aplicaciones en red, podéis ver
en este mismo módulo el su-
bapartado 1.4, "Requerimien-
tos de las aplicaciones".
Con respecto a la pérdida de datos, se tiene que decir que las aplicaciones
multimedia son muy tolerantes: las pérdidas ocasionales de datos lo único que
hacen es que haya un salto en la imagen o en el sonido; sin embargo, si se
continúa recibiendo información, se puede continuar normalmente la comu-
nicación. Por el contrario, se trata de aplicaciones muy sensibles al retraso, lo
cual hace que las consideraciones temporales se deban tener muy en cuenta.
Así pues, a lo largo de los subapartados siguientes veremos que los paquetes
que llegan con un retraso de más de unos centenares de milisegundos no sir-
ven para nada en una aplicación multimedia y se pueden descartar (un sonido
que se ha emitido hace dos segundos con respecto a lo que se está escuchando
o una imagen que ya ha pasado no hay que mostrarlos al usuario).
Estas características de alta tolerancia a pérdidas y mucha sensibilidad al re-

traso hacen que las aplicaciones multimedia sean muy diferentes a las aplica-
ciones tradicionales, en las que es mucho más importante que lleguen todos
los datos (si falta alguna parte, la información recibida será inservible) que el
tiempo que estos datos tarden en llegar al destinatario (que puede hacer que la
experiencia de usuario no sea muy buena, pero si al final recibe todos los datos,
habrá cumplido los requerimientos). En los próximos subapartados veremos
algunos ejemplos de aplicaciones multimedia y qué nos podemos encontrar
actualmente en Internet para el soporte de estas aplicaciones.
9.1. Ejemplos de aplicaciones multimedia
Hay muchos tipos de aplicaciones multimedia actualmente en la red Inter-

net. En este subapartado describiremos brevemente tres de los grandes tipos
de aplicaciones multimedia que nos podemos encontrar: streaming de audio
/ vídeo almacenados, streaming en directo de audio / vídeo y audio / vídeo en
tiempo real interactivo. Ninguna de estas aplicaciones cubre el caso en el que
nos bajamos un contenido y después lo vemos. Este caso tiene que ver con
la transferencia de ficheros que se puede hacer con protocolos como HTTP
(Hypertext Transfer Protocol) y FTP (File Transfer Protocol).
9.1.1. Streaming de audio y vídeo almacenados
En este tipo de aplicaciones, los clientes piden contenidos de audio y vídeo

comprimidos almacenados en servidores. Estos contenidos pueden ser, por
ejemplo, programas de televisión, vídeos caseros, canciones, sinfonías o pro-
gramas de radio. Esta clase de aplicaciones tienen tres características distinti-
vas.
• Contenidos�almacenados: el contenido multimedia está ya grabado y se

almacena en el servidor. Como resultado, el usuario puede detener la re-
producción, rebobinar o indexar el contenido. El tiempo de respuesta de
un contenido de este tipo puede ir de uno a diez segundos para ser acep-
table.
• Streaming: cuando un usuario recibe un contenido con la técnica del strea-

ming, la reproducción empieza poco después de haber hecho la petición
del contenido. De esta manera, el usuario ve una parte del contenido,
mientras que el resto se va recibiendo a medida que se reproduce. En este
caso, el tiempo de respuesta es más bajo. Con esta técnica evitamos el re-
traso que podemos tener si debemos bajarnos todo el contenido.
• Reproducción�continua: una vez la reproducción del contenido multi-

media empieza, tiene que transcurrir tal y como se grabó originalmente.
Esto hace que haya unos fuertes requerimientos de retraso en la entrega de
los datos en este tipo de aplicación. La aplicación de usuario debe recibir a
tiempo los datos del servidor para poder hacer la reproducción de mane-
ra correcta. Aunque esta aplicación tiene unos requerimientos de retraso
importantes, no son tan fuertes como para el streaming en directo o las
aplicaciones de tiempo real, que veremos a continuación.
9.2. Streaming en directo de audio y vídeo
Este tipo de aplicaciones funcionan como el broadcast tradicional de radio y

televisión –un emisor transmite a muchos receptores–, sólo que se hace por
Internet. Con este tipo de streaming se pueden recibir emisiones de radio y
televisión en directo desde cualquier punto del mundo.
Puesto que en el streaming de audio y vídeo la información no está almacenada,

el usuario no puede tirar adelante la reproducción del contenido recibido. Lo
que sí permiten algunas aplicaciones es parar la reproducción e incluso ir hacia
atrás (aunque esto último sólo es posible si se ha almacenado el contenido en
el disco del usuario mientras se iba reproduciendo).
Aunque para enviar este tipo de streams se podrían utilizar conexiones multi-
cast (un emisor transmite a diferentes receptores en una única conexión), la
verdad es que se hacen múltiples conexiones unicast (una conexión para cada
receptor).
Se requiere una reproducción continuada, pero los requerimientos de interac-

tividad no son tan críticos como las aplicaciones interactivas en tiempo real
y pueden aceptarse retrasos en el inicio de la reproducción de hasta diez se-
gundos.
9.2.1. Audio y vídeo en tiempo real interactivo
Este tipo de aplicaciones permiten que los usuarios interactúen en tiempo real. Direcciones web
Actualmente, hay bastantes aplicaciones de este tipo que permiten que los recomendadas
usuarios hagan audio o videoconferencias mediante Internet. Windows Mes- Aplicaciones de audio y ví-
senger, Google Talk o Skype son algunos ejemplos de aplicaciones que permi- deo interactivo:
Windows Messenger: http:/
ten establecer conexiones de audio y/o vídeo. Algunas de estas aplicaciones
/ www.microsoft.com/win-
también permiten llevar a cabo llamadas telefónicas a teléfonos fijos o móviles dows/messenger/features.asp
(haciendo un pequeño pago), como es el caso de Skype. Google Talk: http://
www.google.com/talk/ intl/
se/
El retraso permitido en estas aplicaciones no debe ser mayor que unos cente- Skype: http://
www.skype.com/intl/es/
nares de milisegundos. Así pues, retrasos de más de 400 milisegundos harían
que una comunicación de voz fuera prácticamente imposible.
9.3. Multimedia en Internet
IP es un protocolo de tipo best effort, es decir, que intenta entregar los paque-
tes tan pronto como puede, pero sin dar ninguna garantía. Los protocolos de
transporte TCP/UDP funcionan sobre IP, y por lo tanto tampoco pueden dar
garantías de cuándo llegará un determinado paquete a su destino. Por este
motivo, el envío de datos multimedia por Internet es una tarea difícil de que
ha tenido hasta ahora un éxito limitado.
En las aplicaciones de streaming de audio y vídeo almacenados, retrasos de

entre cinco y diez segundos pueden ser aceptables. Así pues, si no se produce
un pico de tráfico o los paquetes no deben pasar por enlaces congestionados,
podremos disfrutar del streaming de manera satisfactoria.
Por otra parte, el uso de las aplicaciones de streaming interactivo de audio y

vídeo hasta ahora no ha sido tan satisfactorio a causa de las restricciones en
el retraso de los paquetes y en el denominado paquet jitter. El paquet jitter es
la variabilidad que pueden tener los retrasos de paquetes enviados entre un
origen y un destino dentro del mismo stream. Puesto que el audio y el vídeo
se deben reproducir con la misma temporización con la cual se grabaron, el
jitter se tiene que eliminar antes de hacer la reproducción de los datos. El re-
productor debe almacenar los paquetes por un corto periodo de tiempo para
eliminar el jitter antes de reproducir el stream.
Con el fin de eliminar el jitter, habitualmente se combinan tres mecanismos:
1) Añadir un número de secuencia a cada paquete de datos enviado. El emisor

incrementa este número en cada paquete enviado.
2) Añadir un timestamp a cada paquete. El emisor pone en cada paquete el

momento en el que se generó.
3) Retrasar la reproducción del paquete en el receptor. El retraso en la repro-

ducción tiene que ser lo bastante grande como para garantizar que los paque-
tes se han recibido antes del momento de su reproducción. Este retraso puede
ser fijo o adaptativo a lo largo de la sesión. Los paquetes que no llegan antes
del momento de su reproducción se consideran perdidos y se descartan.
Con estos tres mecanismos, se pueden utilizar dos técnicas de reproducción

dependientes del retraso: retraso�fijo o retraso�adaptativo en el momento de
la reproducción de los datos. El retraso fijo consiste en reproducir el paquete de
datos exactamente x milisegundos después de la creación del paquete de datos.
Así pues, si el timestamp del paquete era t, su reproducción se tiene que hacer en
el instante t + x, siempre que el paquete haya llegado antes de este momento.
El valor de x depende de la aplicación, pero para telefonía por Internet es
posible soportar hasta 400 milisegundos. Si es menos, se produce el riesgo de
que no lleguen. El retraso adaptativo consiste en adaptarse a las condiciones
de pérdida de paquetes y retrasos que tengamos durante la comunicación. La
manera de hacer esto es calcular el retraso de la red y la variación del retraso
e ir ajustando el retraso en la reproducción de acuerdo con estos datos.
El streaming interactivo funciona bien si se dispone de un buen ancho de ban-

da, en el que el retraso y el jitter son pequeños.
Las aplicaciones multimedia funcionarían mejor en la red Internet si existiera

la posibilidad de reservar una parte del ancho de banda para el envío de este
tipo de información. Sin embargo, esto no parece que tenga que suceder, al
menos de momento. Por esto, es necesario utilizar algún otro tipo de técnicas,
como por ejemplo usar UDP en lugar de TCP para el envío de los datos, in-
troducir retrasos en el envío de los datos o, si se trata de streaming de conteni-
dos almacenados, enviar datos de antemano (utilizando técnicas de buffering)
cuando la conexión lo permite. Incluso se puede enviar información redun-
dante para mitigar los efectos de la pérdida de paquetes.
Puesto que para este tipo de datos no es muy adecuado reenviar los paquetes,
lo que se hace es utilizar otras técnicas de recuperación de errores, como son
forward error correction (FEC) e interleaving.
El FEC consiste en enviar datos redundantes al stream original. De esta ma-

nera, se pueden reconstruir versiones aproximadas de los paquetes originales
perdidos. Una manera de hacer FEC es enviar un paquete redundante cada n
paquetes. Esto hace que si se pierde un paquete de estos n, se pueda recuperar.
Si se pierden más, entonces esto ya no es posible. De todos modos, si se envían
muchos paquetes redundantes hay más retraso. La otra técnica para hacer FEC
es enviar los datos redundantes en un stream con calidad más baja. Si se pierde
un paquete del stream original, entonces se toma el paquete del stream de baja
calidad y se reproduce en el momento que le toca. De esta manera, aunque
se mezclen paquetes de alta y baja calidad, no se pierde ningún paquete y la
experiencia del usuario es bastante buena.
El interleaving consiste en que el emisor envía los paquetes en un orden dife-

rente del de su reproducción, para minimizar las pérdidas en un grupo de pa-
quetes. De esta manera se reducen las pérdidas, pero no es una técnica adecua-
da para audio y vídeo interactivo, por el retraso en la recepción de los datos;
sin embargo, sí funcionaría bien para audio y vídeo almacenados. La ventaja
de esta técnica es que no se necesita más ancho de banda, ya que el stream
enviado es el mismo.
9.3.1. Compresión de audio y vídeo
Para enviar datos multimedia (audio y vídeo) por Internet es necesario digi-
talizar y comprimir estos datos. La razón por la cual hay que digitalizar los
datos es muy sencilla: las redes de ordenadores transmiten bits; así pues, to-
da la información que se transmite tiene que estar representada con bits. La
compresión es importante porque el audio y el vídeo sin comprimir ocupan
mucho espacio, con el consumo de ancho de banda que esto implica. Eliminar
la redundancia en las señales de audio y vídeo reduce en varios órdenes de
magnitud el ancho de banda que se necesita para transmitir la información.
El�ancho�de�banda�necesario�y�la�compresión
Una imagen de 1.024 píxeles –en la que cada píxel se presenta con 24
bits, 8 para los colores rojo, azul y verde– necesita 3 MB sin compresión.
Si se aplica una tasa de compresión de 1:10, tendremos que esta misma

imagen necesita 300 KB para ser representada.
Suponiendo que tuviéramos que enviar las dos imágenes por un canal
de 64 kbps, en el primer caso tardaría 7 minutos en enviarse, mientras
que en el segundo el tiempo de transmisión se reduce en un factor de 10.
Compresión de audio
La compresión de tipo PCM�(pulse�code�modulation) se basa en la recogida

de muestras de audio a una frecuencia determinada. El valor de cada muestra
es un número real arbitrario. El valor de cada muestra se redondea a un deter-
minado valor finito (tenemos un número de valores finitos para las muestras).
Cada uno de estos valores se representa con un número finito de bits, que
depende del número de valores que pueden tomar las muestras. Por ejemplo,
si se tienen 256 posibles valores de muestras, utilizaríamos un byte para repre-
sentarlas.
Para el caso de la PCM, se toman 8.000 muestras por segundo y cada muestra Ejemplos en el uso de la
se representa con 8 bits. Esto nos da una señal digital con una tasa de 64.000 PCM
bits por segundo. La señal digital puede descodificarse y convertirse de nuevo Algunos ejemplos en el uso
en una señal analógica, pero esta señal será diferente de la señal analógica ori- de la PCM son la codificación
de voz con 8.000 muestras/
ginal como consecuencia del muestreo. Si se recogen más muestras y se toman segundo y 8 bits/muestra, lo
que da una tasa de 64 kbps. El
más valores posibles para estas muestras, la señal analógica descodificada será CD de audio también utiliza la
mucho más parecida a la señal original. PCM, con 44.100 muestras/se-
gundo y 16 bits/muestra. Esto
da una tasa de 705,6 kbps pa-
ra canales mono y 1,411 Mbps
Aunque la velocidad de las conexiones en Internet ha mejorado (recordemos para estéreo.
que un módem proporcionaba una velocidad máxima de 56 kbps), la compre-
sión de audio y vídeo es todavía muy importante. Así pues, podemos encon-
trar algunos ejemplos de compresión de voz con tasas de bits más bajas como
GSM (13 kbps) o G.729 (8 kbps).
Para la compresión de sonido con calidad casi de CD, la técnica más popular
es el estándar de compresión MPEG 1 Layer 3, más conocido como MP3. Las
tasas de compresión de MP3 suelen ser 96 kbps, 128 kbps y 160 kbps, con poca
degradación del sonido.
Compresión de vídeo
El vídeo es una sucesión de imágenes, transmitidas a una tasa constante, como

24 o 30 imágenes por segundo. Una imagen sin comprimir es una sucesión
de píxeles, en la que cada píxel se representa con un número de bits que in-
dican color y luminosidad. Hay dos tipos de redundancia en los vídeos que
se pueden aprovechar para comprimir: redundancia espacial y redundancia
temporal. La redundancia espacial consiste en tener repeticiones dentro de la
misma imagen y la temporal, en redundancia entre imágenes consecutivas.
Para vídeo, los estándares de compresión MPEG son también los más popula-
res. Estos incluyen MPEG 1 para la compresión con calidad de CD de vídeo (1,5
Mbps), MPEG 2 para calidad de DVD (3-6 Mbps) y MPEG 4 para compresión
orientada a objetos. Las técnicas de compresión MPEG se basan en el hecho
de explotar la redundancia temporal entre imágenes además de la compresión
que tiene en cuenta la redundancia espacial que ya proporciona JPEG. Otros

estándares de compresión de vídeo son H.261 o Quicktime (este último es un
formato propietario de Apple).
9.3.2. Formatos de audio y vídeo
Existen muchos formatos diferentes de audio y vídeo, y aquí presentaremos Bibliografía

los más conocidos y utilizados. Los formatos de vídeo más conocidos para recomendada
trabajar en la red Internet son Quicktime Movie (Apple), Real Media (Real Más información sobre los
Networks), Windows Media (Microsoft), Audio/Video Interleaved (Microsoft), formatos de audio y vídeo:
J.�Niederst (2006). Web De-
MPEG (mpg) y Flash Video (Adobe). A continuación, hacemos un resumen de
sign in a Nutshell (3.ª ed.). Se-
sus características principales. bastopol: O'Reilly.
• Quicktime�Movie: originalmente estaba pensado como formato de vídeo,

pero ahora se puede utilizar para contener cualquier tipo de medio (imá-
genes, audio, vídeo, Flash, etc.). Es un formato propietario de Apple. Es
posible hacer streaming de este formato utilizando algún servidor de strea-
ming dedicado. Se puede simular también el streaming sobre HTTP si se
utiliza FastStart, que hace que el vídeo se empiece a reproducir al mismo
tiempo que se está bajando.
• Real�Media: es uno de los formatos más utilizados para hacer streaming.

Se trata de un formato propietario de la compañía Real Networks y hay
que tener un sistema Real Media para poder hacer el streaming. También
permite hacer seudostreaming vía HTTP.
• Windows�Media: se trata del formato de vídeo creado por Microsoft. Hay

dos formatos, Windows Media Video (.wmv) y Advanced Streaming For-
mat (.asf). Se necesita un servidor de tipo Windows Media Server para crear
este tipo de ficheros. Permite hacer streaming y transmisiones de vídeo en
directo.
• Audio/Video� Interleaved: es un formato de vídeo creado también por

Microsoft para su Video For Windows (VFW), la arquitectura multimedia
de Windows 95. Ha sido sustituido por el formato Windows Media. Con
este formato no se puede hacer streaming, hay que bajar el contenido y
después reproducirlo.
• MPEG: formato estándar definido por el Moving Picture Experts Group

(MPEG). Soporta tres tipos de información: audio, vídeo y streaming (que
significa que soporta audio y vídeo sincronizados). Este formato ofrece una
alta compresión con pocas pérdidas.
• Flash�Video: es un formato de vídeo creado por Flash (.flv) que permite

hacer streaming. Funciona con la aplicación Flash Player, lo cual hace que
no se necesite un reproductor dedicado para poder ver los vídeos. Además,
permite las mismas características de interactividad que ahora ofrecen las

animaciones hechas con Flash (ficheros .swf).
Los formatos de audio más conocidos para trabajar en la red Internet son WAV/
AIFF, MP3, Quicktime Audio (Apple), MIDI, Real Media Audio (Real Networks),
Windows Media Audio (Microsoft) y Flash (Adobe). A continuación hacemos
un resumen de sus características principales.
• WAV/AIFF: estos dos formatos tienen características muy similares. El Wa-

veform Audio Format (.wav) fue originalmente diseñado para los sistemas
operativos Windows, mientras que el Audio Interchange File Format (.aiff)
fue diseñado para sistemas Apple. Ahora ya no se utilizan tanto, ya que
hay otros formatos que ofrecen más compresión con una calidad parecida,
como por ejemplo el MP3. No permiten hacer streaming, pero son los for-
matos que se utilizan como base para otros formatos (como RealAudio). Si
se comprimen, pierden mucha calidad de sonido.
• MP3: se trata del formato más popular en la red Internet. Ofrece una muy
buena calidad de sonido, al mismo tiempo que permite hacer una alta
compresión de datos. Sigue el estándar MPEG-1 Nivel-III y se basa en com-
primir la información partiendo de la percepción auditiva de las personas.
Se puede hacer streaming de este formato y también se puede bajar con
HTTP o FTP.
• Quicktime�Audio: aunque el formato Quicktime está pensado para vídeo,

también permite incluir audio. Este formato permite hacer streaming y seu-
dostreaming con HTTP, además de poder bajarse.
• MIDI: quiere decir Musical Instrument Digital Interface y se trata de un tipo

diferente de formato de audio de los vistos hasta ahora. Se diseñó inicial-
mente como estándar para que los instrumentos musicales electrónicos se
pudieran comunicar entre los mismos. No contiene información de audio,
sino órdenes de cómo se tendrían que tocar las diferentes notas, con ins-
trucciones sobre longitud y volumen. Los ficheros MIDI ocupan muy poco
y son ideales para conexiones con un ancho de banda bajo. No se puede
hacer streaming de este formato.
• Real�Media�Audio: fue uno de los primeros formatos que permitían ha-

cer streaming de audio mediante la Red. Necesita un servidor dedicado, el
RealServer, que permite negociar el ancho de banda y la transmisión RTSP.
Se puede hacer seudostreaming de este formato con un servidor HTTP, si
hay un tráfico limitado.
• Windows�Media�Audio: es el formato de audio para streaming creado por

Microsoft. Hay dos opciones: Windows Media Audio (.wma), que no per-
mite streaming, y Active Streaming File (.asf) para streaming. El codec para
este formato es propietario y se necesita un servidor dedicado para hacer

streaming.
• Flash: se trata de un formato que permite añadir sonidos de fondo a las

páginas HTML y, además, da características de interactividad y animación.
En este caso, no hay retrasos en la reproducción y, una vez bajado el fichero
Flash, la interactividad y el sonido están permanentemente disponibles.
10. Streaming de audio y vídeo almacenados
Las aplicaciones de streaming de audio y vídeo se han popularizado en los úl-

timos años por diferentes motivos. Por una parte, los usuarios tienen cada
vez más capacidad de almacenamiento y también redes con mayor ancho de
banda, que permiten recibir la información multimedia pedida en un corto
espacio de tiempo.
Sin embargo, para recibir los datos de streaming hay que tener una aplicación
dedicada (lo que se conoce como media player o reproductor), que sea capaz
de ofrecer las características siguientes.
• Descompresión: los datos audio y vídeo están casi siempre comprimidos

para ahorrar espacio de disco y ancho de banda. El reproductor deberá
descomprimir el audio y el vídeo a medida que se reciben.
• Eliminación�del�jitter: el paquete jitter es la variabilidad del retraso que

hay entre origen y destino dentro de un mismo stream. Puesto que el audio
y el vídeo se tienen que reproducir con la misma temporización con la
cual se grabaron, el jitter se debe eliminar antes de hacer la reproducción.
El receptor almacenará los paquetes por un corto periodo de tiempo para
que sea posible eliminar el jitter antes de reproducir el stream.
• Corrección�de�errores: a causa de los errores imprevisibles en la red, una

parte de los paquetes se podría perder. Si se pierden demasiados paquetes,
entonces la calidad del stream recibido es inaceptable. Algunas técnicas
para recuperar los datos perdidos son las siguientes.
– Reconstruir los paquetes perdidos mediante el envío de paquetes re-
dundantes.
– Hacer que el cliente pida de manera explícita los paquetes perdidos.
– Interpolar los datos perdidos a partir de los datos recibidos.
En los siguientes subapartados veremos dos maneras de hacer streaming de

audio y vídeo almacenados. La primera consiste en utilizar un servidor de web
tradicional, en el que el audio y el vídeo están almacenados en el sistema de
ficheros. La otra manera de recibir un stream es el uso de un protocolo de
streaming específico, como es el Real Time Streaming Protocol (RTSP).
10.1. Acceso vía servidor de web
Desde el punto de vista de un servidor de web, los ficheros de audio y vídeo

son objetos accesibles desde el servidor como cualquier otro tipo de fichero,
como una página HTML o una imagen.
Así pues, el usuario utilizaría su navegador para acceder al fichero de audio o

vídeo. Este acceso establecería una conexión TCP con el servidor y, una vez
establecida esta conexión, pediría el recurso (fichero de audio o vídeo) con
un mensaje de petición HTTP con la correspondiente orden HTTP (podría ser
una orden GET). El servidor genera un mensaje de respuesta, en el que estará
encapsulado el fichero pedido. La recepción de este fichero hará que se abra
el programa reproductor y, cuando este tenga bastantes datos, empezará a re-
producir el fichero recibido.
La figura siguiente muestra de manera muy simple cómo se produciría esta

comunicación.
1) El usuario pide con su navegador un archivo multimedia (por ejemplo, ha-

ciendo clic en un enlace web). Esta petición genera un mensaje de petición
HTTP.
2) El servidor busca el recurso en su sistema de ficheros y lo envía al navegador

del cliente. Esta respuesta viaja en un mensaje de respuesta HTTP.
3) El navegador guarda los datos en el disco y estos datos son reproducidos por
un reproductor de archivos multimedia, que deberá descomprimir los datos,
eliminar los retrasos y solucionar los errores de datos que se hayan podido
producir.
En este caso, encontramos el problema de que hasta que el navegador no recibe

el objeto multimedia entero, no lo puede pasar al reproductor. Si el archivo
es muy grande, el retraso será inaceptable. Por este motivo, lo que se hace
normalmente es que el servidor de web se comunique directamente con el
reproductor y le envíe los datos. De esta manera, el reproductor recibe los datos
y cuando tiene suficientes para reproducir el contenido, empieza a hacerlo, al
mismo tiempo que continúa recibiendo datos.
La manera de hacer que el servidor web se conecte directamente con el repro-

ductor es sustituyendo el recurso multimedia por un fichero de metadatos, que
contiene la información de dónde se encuentra el recurso multimedia del que
se tiene que hacer streaming e incluso del tipo de codificación. De esta manera,
el navegador recibe un fichero de metadatos, que pasa al reproductor y este
se encarga de conectar con la dirección contenida en el fichero de metadatos.
Así pues, el inicio de la reproducción puede empezar mucho antes de haber
recibido todo el fichero multimedia.
10.2. Real Time Streaming Protocol (RTSP)
(24)
El protocolo RTSP24 establece y controla tanto uno como varios streams sin- El RFC que define el RTSP es el
2.326.
cronizados de datos multimedia, como pueden ser el audio y el vídeo. No hace
el envío de los datos, aunque el envío de información de control en medio de
la transmisión de datos es posible. Lo que hace el RTSP es de control remoto
a través de la Red para los servidores de datos multimedia.
En el RTSP no hay conexiones, lo que tenemos son sesiones mantenidas por el

servidor. Cada sesión tiene su identificador. Una sesión RTSP no está vinculada
a una conexión de nivel de transporte. Esto quiere decir que, durante una
sesión RTSP, se pueden abrir y cerrar tantas sesiones de transporte como sea
necesario. También se puede utilizar UDP como protocolo de transporte, un
protocolo sin conexión.
Los streams controlados por el RTSP pueden utilizar RTP, pero el funcionamien- Ved también
to del RTSP no depende del mecanismo de control utilizado para enviar los
Sobre el RTP, podéis ver más
datos multimedia. El protocolo RTSP es muy parecido al protocolo HTTP/1.1 adelante el subapartado 11.1
(la versión 1.1 del protocolo HTTP), lo cual hace que se puedan añadir me- de este módulo didáctico.
canismos de extensión para el HTTP que también se pueden aplicar al RTSP.

Sin embargo, el RTSP es diferente del HTTP en un buen número de aspectos
importantes.
• El RTSP introduce métodos nuevos y tiene un identificador de protocolo

propio (rtsp://).
• Un servidor RTSP tiene que mantener el estado en la mayoría de los casos,

justo al contrario de lo que hace el HTTP.
• Tanto el cliente como el servidor RTSP pueden hacer peticiones.
• Los datos los transporta un protocolo diferente del RTSP.
• El URI de petición del RTSP siempre contiene el URI absoluto. En el HTTP,

el URI de petición sólo lleva la ruta absoluta al fichero y el nombre del
servidor va en una cabecera aparte.
El protocolo soporta las operaciones siguientes.
a) Recuperación de datos del servidor de contenidos multimedia: el cliente

puede pedir una descripción de una presentación vía HTTP o cualquier otro
método. Si la presentación se está emitiendo en multicast, la descripción de
esta contiene su dirección multicast y los puertos que se utilizarán. Si la pre-
sentación se envía en unicast sólo a este cliente, el cliente da el destino por
motivos de seguridad.
b) Invitación de un servidor de datos a una conferencia: un servidor de datos

puede ser invitado a unirse a una conferencia existente, tanto para reproducir
datos en la presentación o para grabar todos o una parte de los datos trans-
mitidos en la presentación. Este modo es muy útil para aplicaciones de ense-
ñanza distribuida. Muchos participantes pueden tomar parte en las mismas,
pulsando los botones de control remoto.
c) Añadir contenido a una presentación existente: es muy útil especialmente

para el caso de presentaciones en directo, ya que el servidor le puede decir al
cliente que hay nuevos datos disponibles.
Un fichero de descripción de una presentación sería un ejemplo de lo que en la

distribución de contenidos mediante un servidor de web hemos denominado
un fichero de metadatos. Este fichero contiene una descripción de los streams
que forman parte de la presentación, incluyendo el lenguaje de codificación
y otros parámetros que ayudan al usuario a elegir la mejor combinación de
datos. Cada contenido (por ejemplo, el audio y el vídeo se podrían transmi-
tir en streams separados) tiene su propia URL, que apunta a un determinado
contenido dentro de un determinado servidor. El fichero también describe los
métodos de transporte que se soportan. Además de los datos del contenido, la
descripción de la dirección destino de la red y el puerto se tiene que determi-
nar. Hay diferentes modos de operación.
1) Unicast: los datos se transmiten al origen de la petición RTSP, en el número

de puerto seleccionado por el cliente.
2) Multicast (el servidor elige dirección): el servidor selecciona la dirección mul-

ticast y el puerto. Este caso es el típico para transmisiones de datos multimedia
en directo.
3) Multicast (el cliente elige dirección): si el servidor participa en una confe-

rencia multicast existente, la dirección multicast, el puerto y la clave de cifrado
vienen dados por la descripción de la conferencia.
10.2.1. Los estados del RTSP
El RTSP controla streams que se pueden enviar por un protocolo separado,

independiente del protocolo de control. También puede pasar que el RTSP
funcione sobre conexiones TCP, mientras que los datos se envían por UDP. Así
pues, la transmisión de datos continúa ocurriendo aunque no se envíen datos
de control RTSP. Otra posibilidad es que un stream de datos esté controlado por
peticiones RTSP y que estas peticiones viajen en diferentes conexiones TCP.
Por todas estas razones, es necesario mantener el estado de la sesión RTSP, con
el objetivo de correlacionar las peticiones que se refieren al mismo stream.
10.2.2. Diagrama de estados del cliente
El cliente puede estar en cuatro estados posibles: Init, Ready, Playing y Recor-
ding. 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 afirma-
tiva a SETUP, o se ha recibido una confirmación al envío de la orden PAUSE
estando en Playing o Recording. Los estados Playing y Recording indican que se
ha recibido una confirmación afirmativa a las órdenes PLAY y RECORD, de
manera respectiva.
La figura siguiente muestra los estados por los cuales ha pasado el cliente,
como respuesta a las órdenes que envía. Las transiciones se producen cuando
el cliente recibe una confirmación positiva a la orden enviada (la orden se
indica en la flecha correspondiente).
10.2.3. Diagrama de estados del servidor
El servidor puede estar en cuatro estados posibles: Init, Ready, Playing y Recor-
ding. El estado Init indica que el servidor está a la espera de recibir una orden
SETUP correcta. Es el estado inicial. El estado Ready indica que el último SETUP
recibido fue correcto y se envió la confirmación correspondiente, o que en los
estados Playing y Recording la orden PAUSE se recibió y se confirmó. El estado
Playing indica que se ha recibido la orden PLAY y se confirmó y que se están
enviando los datos al cliente. El estado Recording indica que el servidor está
grabando los datos.
La figura siguiente muestra los estados por los cuales ha pasado el servidor,
como respuesta a las órdenes que recibe (y de las cuales envía confirmación al
cliente). Las transiciones se producen cuando el servidor recibe una orden y
ha enviado una confirmación positiva (la orden se indica en la flecha corres-
pondiente).
10.2.4. Métodos RTSP
Los métodos RTSP siguientes son los más relevantes a la hora de cambiar de
estado y de hacer la reserva de recursos para el stream en el lado servidor.
• SETUP: el servidor reserva recursos para un stream e inicia una sesión RTSP.
• PLAY y RECORD: se inicia la transmisión de datos de un stream inicializado

con SETUP.
• PAUSE: detiene temporalmente la transmisión de datos, sin liberar los re-

cursos del servidor.
• TEARDOWN: libera los recursos asociados al stream. La sesión RTSP se bo-

rra del servidor.
Los métodos RTSP que modifican el estado de la sesión utilizan el campo Se-
sión de la cabecera RTSP, que veremos en el subapartado siguiente. Para con-
sultar la lista entera de métodos, podéis ver el RFC del RTSP.
10.2.5. El protocolo RTSP
En este subapartado veremos el protocolo RTSP, incluyendo el formato del

mensaje de petición y respuesta y los campos de cabecera. Muchas de las ca-
racterísticas del protocolo se heredan del HTTP, pero aquí haremos una des-
cripción completa. El URL del protocolo RTSP tiene la forma siguiente:
Esquemas RTSP
En RTSP, los URL pueden empezar con RTSP o RTSPU. El uso de RTSP indica que funciona
sobre un nivel de transporte fiable (TCP), mientras que RTSPU indica que el protocolo
funciona sobre un nivel de transporte no fiable (UDP).
rtsp://host:port/cami/al/recurso
Ejemplo:
rtsp://servidor.multimedia.com:554/programa_tv.html
Los URL tendrían que evitar utilizar direcciones IP en lugar del nombre del
host, y pueden referirse a un único stream o a una serie de streams agregados.
El RTSP es un protocolo basado en mensajes de texto. Esto facilita su imple-

mentación y ampliación (sólo hay que definir un nuevo método o una nueva
cabecera). A continuación, veremos el formato de los mensajes de petición y
respuesta de RTSP.
10.2.6. El mensaje de petición RTSP
La figura siguiente muestra el formato del mensaje de petición. Este mensaje

consta de tres partes bien diferenciadas: la línea de petición, la cabecera de
petición y el cuerpo del mensaje.
La línea de petición tiene la forma siguiente:
OrdenRTSP [Espacio] URI-petición [Espacio] Versión-RTSP [Salto línea]
La orden RTSP indica qué orden del protocolo estamos utilizando. El URI-pe- Ved también
tición identifica el recurso al cual queremos acceder, y la versión RTSP indica
Los valores de las órdenes
la versión del protocolo que estamos utilizando. [Espacio] es un espacio en RTSP, así como el formato de
blanco y [Salto línea] está representado por los caracteres Salto de línea (ASCII la versión RTSP, están explica-
dos con detalle en el anexo 1.
10) y Retorno de carro (ASCII 13). El resto de los espacios en blanco se han
puesto por claridad.
Nombre-campo: [Espacio] valor-campo [Salto línea]
La cabecera de petición tiene tres partes: la cabecera general, la cabecera pro-

piamente de petición y la cabecera de entidad. El formato de todos los campos
de las cabeceras es el siguiente:
• La cabecera general representa información general que es independiente

de si el mensaje es de petición o de respuesta.
• La cabecera de petición contiene campos que sólo tienen sentido para un

mensaje de petición.
• La cabecera de entidad contiene información sobre el cuerpo del mensaje Ved también
(que también se conoce como entidad).
Los valores que pueden tomar
las cabeceras de entidad están
El cuerpo del mensaje lleva la información, si la hay, asociada a la petición. explicados con detalle en el
anexo 1.
10.2.7. El mensaje de respuesta RTSP
La figura siguiente muestra el formato del mensaje de respuesta. Este mensaje

consta de tres partes bien diferenciadas: la línea de estado de la respuesta, la
cabecera y el cuerpo del mensaje.
La línea de estado de la respuesta tiene la forma siguiente:
Versión-RTSP [Espacio] Código-Estado [Espacio] por Descripción-Estado [Salto línea]
La versión RTSP define la versión del protocolo que se está utilizando, el código Ved también
de estado define el éxito o error en la petición y la descripción del estado es
Los valores de los códigos y las
una descripción textual del código de estado. [Espacio] es un espacio en blanco descripciones de estado están
y [Salto línea] está representado por los caracteres Salto de línea (ASCII 10) y explicados con detalle en el
anexo 1.
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 pro-

piamente de respuesta y la cabecera de entidad. El formato de todos los cam-
pos de las cabeceras es el siguiente:

La cabecera general representa información general que es independiente de Ved también

si el mensaje es de petición o de respuesta. La cabecera de respuesta contiene
campos que sólo tienen sentido para un mensaje de respuesta. La cabecera de estas tres cabeceras están ex-
entidad contiene información sobre el cuerpo del mensaje (que también se plicados con detalle en el ane-
xo 1.
conoce como entidad).
El cuerpo del mensaje lleva la información, si la hay, asociada a la respuesta.
10.2.8. Ejemplo de uso del protocolo RTSP
En este subapartado veremos un ejemplo de uso del protocolo RTSP, con las
peticiones y respuestas que nos encontraríamos en una comunicación real.
En este ejemplo, el cliente establece una conexión TCP en el puerto 554 del
servidor y envía la orden OPTIONS, indicando la versión del protocolo RTSP
que utilizará. El servidor confirma esta orden con un mensaje 200 OK (indi-
cando que ha ido bien). Este código de respuesta es igual al equivalente en
HTTP.
Petición del cliente:
OPTIONS rtsp://servidor.multimedia.com:554 RTSP/1.0

Cseq: 1
Respuesta del servidor:
RTSP/1.0 200 OK Cseq: 1
En un segundo paso, el cliente envía una orden de tipo DESCRIBE, que indica SDP y MHEG
al servidor el contenido concreto que queremos. El servidor vuelve a respon-
El Session Description Protocol
der con un 200 OK, incluyendo una descripción completa del contenido, en (SDP) está definido en el RFC
algún formato estandarizado –por ejemplo, Session Description Protocol (SDP) o 4.566.
Multimedia and Hypermedia Ex-
Multimedia and Hypermedia Experts Group (MHEG). perts Group (MHEG): http://
www.mheg.org.
DESCRIBE rtsp://servidor.multimedia.com:554/videos/
video.html RTSP/1.0
Cseq: 2
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=6023-
6024
Como se puede ver, además de las líneas de petición y respuesta, los mensajes
llevan cabeceras que indican el número de secuencia del mensaje (Cseq) o las
características de la entidad enviada (Content-type o Content-length).
En el siguiente paso de la negociación, el cliente envía una orden SETUP en

la que le dice al servidor los mecanismos de transporte que quiere utilizar y
el orden de preferencia. El cliente indica que quiere utilizar UDP como proto-
colo de transporte y los puertos 5067 y 5068 para la transferencia de datos.
El servidor confirma los datos de transporte y puertos del cliente y añade el
identificador de sesión y sus puertos de transferencia.
Después de establecer la conexión, el cliente está listo para empezar a recibir

el stream y envía la orden PLAY. Esta orden sólo contiene el URL del contenido
y el identificador de la sesión enviado previamente por el servidor. El servidor
confirma la orden y se empieza a enviar el stream.
Si el cliente decide parar el stream, lo puede hacer con la orden TEARDOWN.

El servidor envía la confirmación de que ha recibido la orden y se para el envío
RTSP.
PLAY rtsp:// servidor.multimedia.com:554/videos/

video.mpg RTSP/1.0
Cseq: 4
Session: 12345678
La figura siguiente resume los intercambios anteriores:

11. Protocolos para aplicaciones interactivas en

tiempo real
11.1. Real Time Transport Protocol (RTP)
(25)
El Real Time Transport Protocol (RTP)25 es un protocolo definido por la Inter- El RFC que define el RTP y el
RTCP es el 3.550.
net 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
Ved también
vídeo. Este protocolo es complementario a otros protocolos de tiempo real,
como SIP o H.323. Los protocolos SIP o H.323 se
verán más adelante dentro de
este mismo apartado.
11.1.1. Descripción del RTP
Ved también
El RTP funciona sobre el protocolo de transporte UDP. El emisor encapsula
un trozo de datos (chunk, en inglés) dentro del paquete RTP, que también se En este subapartado 11.1 ha-
blaremos del RTP, y en el 11.2
encapsula dentro de un datagrama UDP, el cual viaja en un paquete IP. El re- hablaremos del protocolo de
ceptor extrae los datos RTP del datagrama UDP y pasa los datos al reproductor control del RTP, el RTCP.
para que este descodifique el contenido y lo reproduzca.
Si una aplicación incluye RTP, será más fácil que pueda interoperar con otras
aplicaciones multimedia. Por ejemplo, si dos fabricantes ofrecen un software
de telefonía sobre IP e incorporan RTP en su producto, la interconexión entre
sus productos será más factible.
El RTP no ofrece ningún mecanismo que permita asegurar que los datos llegan
a su destino a tiempo o con la calidad de servicio adecuada. Tampoco garantiza
que los paquetes lleguen en orden, ya que el protocolo RTP sólo se reconoce
en los extremos y los direccionadores toman los paquetes IP que contienen
RTP como si fueran cualquier otro paquete IP y no los diferencian del resto.
El RTP permite asociar a cualquier dispositivo (una cámara, un micrófono,

etc.) su propio stream de paquetes. Así pues, si dos usuarios quieren hacer una
videoconferencia, se pueden abrir dos streams de audio y vídeo, uno en cada
sentido para cada tipo de datos. La realidad es que los streams de audio y vídeo
están entrelazados, se envían como un único stream y se establece una única
conexión para enviar los dos streams (audio y vídeo).
El RTP forma parte del nivel de aplicación (estaría por encima del UDP, que es
el nivel de transporte), pero también se puede ver como un subnivel dentro
del nivel de transporte. En la figura siguiente se puede ver esta distinción de
forma gráfica:
11.1.2. La cabecera del RTP
El formato de la cabecera RTP se puede ver en la figura siguiente.
Los primeros 12 octetos están presentes en todos los paquetes RTP, mientras Mezclador RTP
que la lista de identificadores CSRC (Contributing Source) sólo está presente
Un mezclador RTP se encar-
cuando hay un mezclador. ga de cambiar el formato del
stream con el fin de adecuarlo
al ancho de banda del recep-
Los campos tienen el significado siguiente. tor.
• Versión (V): 2 bits. Este campo identifica la versión RTP. La versión actual
es la 2.
• Relleno (P): 1 bit. Si este bit está activado, el paquete contiene unos o más
octetos de relleno adicional en los datos. El último octeto de relleno indica
cuántos octetos se tienen que descartar, incluyendo el mismo. Esta técnica
puede ser necesaria para algunos algoritmos de cifrado que necesitan un
tamaño de bloque fijo.
• Extensión (X): 1 bit. Si está activado, la cabecera fija sólo puede llevar una
extensión.
• Número de CSRC (CC): 4 bits. Este campo contiene el número de identi-

ficadores CSRC que hay en la cabecera fija.
• Marcador (M): 1 bit. La interpretación de este campo está definida por un

perfil, que indica por qué se debe utilizar en un determinado contexto.
• Tipo de contenido (PT): 7 bits. Este campo identifica el formato de los

datos que se están enviando con RTP.
• Número de secuencia: 16 bits. Este número se incrementa en uno cada

vez que se envía un paquete de datos RTP y puede utilizarse para detectar
pérdidas de datos y restaurar la secuencia del paquete. El valor inicial debe
ser aleatorio.
• Timestamp: 32 bits. Indica el momento de tiempo del primer octeto en-

viado en este paquete de datos RTP.
• SSRC: 32 bits. Este campo identifica la fuente de sincronización. Tiene que

ser aleatorio para que dos fuentes de sincronización de una sesión RTP no
tengan el mismo identificador.
• Lista CSRC: de 0 a 15 elementos, 32 bits por elemento. Identifica las fuen-

tes que contribuyen a los datos contenidos en este paquete RTP.
11.2. Real Time Control Protocol (RTCP)
El protocolo de control del RTP (RTCP) se basa en la transmisión periódica de

paquetes de control a todos los participantes en una sesión, utilizando el mis-
mo mecanismo de distribución que los paquetes de datos enviados con RTP. El
protocolo que haya por debajo tiene que ofrecer la posibilidad de multiplexar
paquetes de datos y de control, por ejemplo, por medio de números de puerto
UDP diferentes. El RTCP lleva a cabo cuatro funciones básicas:
1) Da información sobre la calidad de los datos distribuidos. Esto forma parte

del rol del RTP como protocolo de transporte y está muy relacionado con las
funcionalidades de control de congestión ofrecidas por otros protocolos de
transporte.
2) Mantiene un identificador persistente a nivel de transporte de una fuente

RTP, que se denomina nombre canónico o CNAME, ya que, en el transcurso de la
comunicación, el identificador SSRC puede cambiar si se detecta un conflicto
o se reinicia un programa. Con el CNAME, si el identificador SSRC cambia, se
pueden recuperar los participantes de la sesión.
3) Las dos funcionalidades anteriores necesitan que todos los participantes

envíen paquetes RTCP, aunque se tiene que controlar la tasa de envío por si hay
un número elevado de participantes. Si cada participante envía los paquetes
de control a todos los otros, cada uno puede observar independientemente el
número de participantes. Este número sirve para calcular la tasa a la cual se
envían los paquetes.
4) La última función es opcional, y consiste en comunicar un mínimo de in-

formación de control de la sesión, como que se muestre la identificación de
un participante en la interfaz de usuario.
11.2.1. Los paquetes RTCP
Los paquetes RTCP pueden transportar diferentes tipos de información de con-

trol.
• SR: informe del emisor (Sender Report, en inglés), para transmitir y recibir
estadísticas de los participantes que son emisores activos.
• RR: informe del receptor (Receiver Report, en inglés), para recibir estadísti-
cas de los participantes que no son emisores activos. También se puede
combinar con el SR para los emisores activos que tienen que informar so-
bre más de 31 fuentes de datos (el máximo que se puede indicar en un
paquete de tipo SR).
• SDES: elementos de descripción de la fuente, incluyendo el CNAME.
• BYE: indica que se ha dejado de participar.
• APP: funcionalidades específicas de la aplicación.
Cada paquete RTCP empieza con una parte fija similar a la que tienen los
paquetes de datos RTP, seguida de una serie de elementos estructurados que
pueden tener una estructura variable de acuerdo con el tipo de paquete, pero
que deben tener una longitud múltiple de 32 bits. Se incluyen campos para
indicar la alineación y un campo de longitud para hacer que los paquetes RTCP
sean apilables. Los paquetes RTCP pueden enviarse de manera consecutiva, sin
tener que ponerles ningún separador, y formar de este modo un paquete RTCP
compuesto, que se puede enviar en un único paquete del nivel inferior (por
ejemplo, UDP). Cada paquete RTCP dentro del paquete compuesto se tiene
que procesar de manera independiente del resto de los paquetes. Sin embargo,
para llevar a cabo las funciones del protocolo, se imponen las restricciones
siguientes:
a) La recepción de estadísticas (en SR o RR) se tiene que enviar tan frecuente-

mente como lo permitan las restricciones de ancho de banda para maximizar
la resolución de las estadísticas. Por este motivo, cada paquete RTCP compues-
to 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.
c) El número de tipos de paquetes que pueden aparecer inicialmente en el pa-

quete compuesto se tiene que limitar para aumentar el número de bits cons-
tantes en la primera palabra del paquete y la probabilidad de validar con éxito
los paquetes RTCP contra paquetes de datos RTP que tengan la dirección mal
o que no estén relacionados.
Todos los paquetes RTCP se deben enviar obligatoriamente en paquetes com-

puestos 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 infor-
me, para facilitar la validación de la cabecera. Esto se tiene que hacer siem-
pre, aunque no se hayan enviado o no se hayan recibido datos. En este
caso, se tiene que enviar un paquete RR vacío.
• RR adicionales: si el número de fuentes de las que se debe reportar es ma-

yor 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 inter- Ved también
valo de envío de informes para calcular correctamente el ancho de banda de
El formato específico de cada
RTCP por participante. paquete RTCP se define en el
anexo 2 de este módulo didác-
tico.
11.2.2. Uso del ancho de banda en el protocolo RTCP
Para el funcionamiento del RTCP, se puede ver que, en una conexión con un
emisor y muchos receptores (que pueden comunicarse con multicast), los datos
enviados con RTCP pueden exceder en gran manera los datos enviados con
RTP por el emisor. Por este motivo, el RTCP modifica la tasa de envío de los
paquetes RTCP a medida que aumenta el número de participantes en la sesión.
El RTCP intenta mantener su tráfico en el 5% del ancho de banda de la sesión.

Veamos esto con un ejemplo.
Ancho de banda RTSP
Si un emisor transmite a una velocidad de 2 Mbps, el RTCP intenta limitar su tráfico en

el 5% de estos 2 Mbps, que serían 100 kbps.
El protocolo da el 75% de esta tasa, 75 kbps, a los receptores, y el resto, los 25 kbps res-
tantes, al emisor. Los 75 Kbps de los receptores se reparten entre los mismos de manera
igualitaria. De este modo, si hay R receptores, cada receptor puede enviar tráfico RTCP a
una tasa de 75 kbps/R y el emisor envía a una tasa de 25 kbps. Los participantes (emisores
o receptores) determinan el periodo de transmisión de un paquete RTCP calculando di-
námicamente el tamaño medio de paquete RTCP (en toda la sesión) y dividiéndolo entre
el tamaño medio de paquete RTCP que puede enviar a su tasa asignada.
Para resumir, el periodo en el que un emisor puede enviar un paquete RTCP es:
Y en resumen, el periodo en el que un receptor puede enviar un paquete RTCP es:
11.3. Session Initiation Protocol (SIP)
Hay muchas aplicaciones en Internet que necesitan la creación y gestión de

sesiones, entendiendo sesión como un intercambio de datos entre distintos
participantes. La implementación de las sesiones se hace difícil por el compor-
tamiento de los que participan en las mismas: los usuarios cambian de loca-
lización, pueden tener distintas maneras de identificarse e intercambian dife-
rentes tipos de datos, a veces de manera simultánea. Hay muchos protocolos
que permiten trabajar con sesiones multimedia en tiempo real con las que es
posible transmitir texto, audio o vídeo.
(26)
El Session Initiation Protocol (SIP)26 trabaja en cooperación con estos protocolos, El RFC donde se define el SIP es
el 3.261.
y permite que los diferentes agentes de usuario (aplicaciones que utilizan a los
usuarios para comunicarse) puedan encontrarse y ponerse de acuerdo con el
Aplicaciones que utilizan
tipo de sesión que quieren compartir. Para localizar a los participantes de una el SIP
sesión y para otras funciones, el SIP permite la creación de una infraestructura
Windows Live Messenger y
de hosts (denominados proxy servers), a la que las aplicaciones de usuario pue- Yahoo Messenger son dos apli-
den enviar peticiones de registro, invitación a las sesiones y otras peticiones. caciones que utilizan SIP.
El SIP es una herramienta que permite gestionar sesiones independientemente

de los protocolos de transporte que haya por debajo y sin ninguna dependen-
cia del tipo de sesión establecida.
11.3.1. Funcionalidad del SIP
El SIP es un protocolo de control de nivel de aplicación que puede establecer,

modificar y finalizar sesiones multimedia (conferencias). Como ejemplo de se-
sión, tenemos las llamadas telefónicas mediante Internet. El SIP también per-
mite invitar a participantes a sesiones existentes, como por ejemplo las confe-
rencias multicast. También se pueden añadir y quitar contenidos multimedia
de una sesión existente. Con SIP, los usuarios pueden tener un único identifi-
cador externo, independientemente de su localización de red.
El SIP considera cinco aspectos diferentes para el establecimiento y la finaliza-

ción de comunicaciones multimedia.
• Localización del usuario: hace referencia al sistema final que se hará para
la comunicación.
• Disponibilidad del usuario: indica si el usuario quiere participar en las co-

municaciones.
• Capacidad de los usuarios: indica el medio y los parámetros del medio que
se utilizarán.
• Inicio de la sesión: llamada, establecimiento de la sesión y parámetros a

los dos extremos de la comunicación.
• Gestión de la sesión: incluye la transferencia y finalización de sesiones,

modificando los parámetros de la sesión y llamando a los servicios.
El SIP no es un sistema completo de comunicaciones, sino que se trata de un

componente que se puede complementar con otros protocolos de Internet con
el fin de implementar una aplicación multimedia entera. Por ejemplo, se pue-
den utilizar los protocolos RTP y RTCP para el transporte y control del envío
de datos o el protocolo RTSP para el control del streaming de datos multimedia.
El SIP no ofrece servicios, sino primitivas que se pueden utilizar para ofrecer
diferentes tipos de servicio. Por ejemplo, el SIP tiene una primitiva que permite
encontrar a un usuario y enviarle datos opacos a su localización. Si estos datos
consisten en una descripción de sesión definida, por ejemplo con SDP, los
extremos de la comunicación pueden ponerse de acuerdo con los parámetros
de la sesión.
El SIP tampoco ofrece servicios de control de las conferencias, ni define cómo

se tiene que gestionar una conferencia. Sin embargo, se puede utilizar para ini-
ciar 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 segu-
ridad sea muy importante. Por este motivo, el SIP ofrece toda una serie de me-
canismos de seguridad que incluyen la prevención de la denegación de servi-
cio, la autenticación de usuarios y proxies, la protección de la integridad y los
servicios de cifrado y privacidad.
La figura siguiente muestra un ejemplo de funcionamiento del SIP:

En este ejemplo, Amalia y Cristina quieren establecer una sesión SIP. Cada in-
tercambio tiene al lado un número entre paréntesis (n), para hacer de referen-
cia en la explicación del mismo. También se muestran los dos servidores proxy
que actúan en nombre de Amalia y Cristina para facilitar el establecimiento
de la sesión.
(27)
Amalia llama a Cristina utilizando su identidad SIP, una especie de URI, deno- El RFC del TLS es el 4.346.
minado URI SIP. Un URI SIP es semejante a una dirección de correo electrónico;
lo definiremos más adelante, pero contiene un host y un nombre de usuario.
En este caso, este URI es sip: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 dirección de Cristina o puede haberla elegido
de un enlace o una agenda. También existen los URI SIP seguros, que se deno-
minan SIPS, como por ejemplo sips:cris@vic.cat. En este caso, se utilizaría el
Transport Layer Security (TLS)27 para proveer de una conexión segura y cifrada
para transportar los mensajes SIP.
El SIP se basa en un mecanismo de petición/respuesta muy similar al modelo

de transacciones HTTP. Cada transacción consiste en una petición que invoca
un método del servidor y, como mínimo, una respuesta. En este ejemplo, la
transacción empieza cuando Amalia envía una orden INVITE dirigida al URI
SIP de Cristina.
A continuación, se muestra la información que llevaría asociada la orden IN-

VITE:
INVITE sip:cris@vic.cat SIP/2.0

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 línea contiene el método, con el URI SIP origen y la versión

de SIP.
• Las líneas siguientes son cabeceras, que contienen información sobre el Ved también
origen y el destino de la comunicación (From, To), la dirección donde
Se puede encontrar una lista
Amalia quiere recibir las respuestas, indicada en Via, y algunos identifica- completa de las cabeceras SIP
dores únicos. Cseq es un número de secuencia que se incrementa con cada en el anexo 3 de este módulo
didáctico.
nueva petición. Contact contiene el URI SIP que representa la ruta directa
hacia Amalia, formada por un nombre de usuario y el nombre de dominio.
El número Max-Forwards indica el número máximo de saltos que puede
dar esta petición y, finalmente, Content-Type y Content-Length contie-
nen información sobre el cuerpo del mensaje.
Los parámetros específicos de la sesión no se definen con SIP, sino con otro
protocolo, como el SDP, que no veremos aquí.
Puesto que el teléfono de Amalia no sabe dónde encontrar a Cristina o el ser-

vidor SIP de bcn.cat, envía la orden INVITE a su servidor de dominio, bcn.cat
(1). El servidor bcn.cat es un tipo de servidor SIP conocido como proxy server.
Su función es redireccionar las peticiones SIP en nombre de quien las envía.
En este ejemplo, el proxy server recibe la petición INVITE (2) y responde con
una respuesta 100 (Trying) (3). Esto indica que la petición se ha recibido bien
y que se está intentando enviar INVITE a su destino. La respuesta SIP tiene la
forma de un código de 3 cifras y una frase descriptiva (como HTTP).
El proxy server bcn.cat encuentra la dirección SIP del dominio vic.cat. De esta
manera, consigue la dirección del proxy server de vic.cat y le reenvía la orden
INVITE (2). Este contesta con un 100 (Trying) (5), para indicar que está traba-
jando en servir la petición. El proxy server consulta una base de datos para en-
contrar la dirección de Cristina y le envía la petición INVITE (4) a su teléfono
SIP. Cuando el teléfono recibe la petición, suena para informar a Cristina de
que está recibiendo una llamada. El teléfono SIP indica que se está haciendo
la llamada enviando un mensaje de tipo 180 (Ringing) (6), (7), (8), que llega
hasta el teléfono de Amalia. Cuando la respuesta llega al teléfono de Amalia,
este hace alguna indicación de que está sonando el teléfono en el otro extre-
mo. En este caso, Cristina responde a la llamada, lo cual hace que se envíe una
respuesta de tipo 200 OK (9), (10), (11). Amalia envía un ACK (12). En este
momento, hay que negociar los parámetros de la sesión con el protocolo SDP.
A continuación, se muestra cómo sería el mensaje de respuesta enviado por
el teléfono SIP de Cristina:
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy03.vic.cat
;branch=z9hG4bKnashds8;received=192.0.2.3
Vía: SIP/2.0/UDP proxy01.bcn.cat
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc01.bcn.cat
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Cristina <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 línea contiene la respuesta, con la versión de SIP, el código de

respuesta y la descripción.
• Las líneas siguientes son cabeceras. Via, From, Call-ID y Cseq se copian de
la petición INVITE (ahora hay distintas cabeceras de tipo Via para indicar
la comunicación mediante los proxy servers). Contact contiene el URI SIP
que representa la ruta directa hacia Cristina, formada por un nombre de
usuario y nombre de dominio. Content-Type y Content-Length contienen
información sobre el cuerpo del mensaje.
La sesión multimedia entre Cristina y Amalia ha empezado y pueden enviar

los datos multimedia en el formato acordado. En general, estos paquetes se-
guirán una ruta diferente de la de los mensajes SIP. Durante la comunicación,
se pueden cambiar las características de la sesión volviendo a enviar una orden
INVITE.
Para acabar la sesión, Cristina envía una orden BYE (cuelga) (13). Este BYE
se envía directamente al teléfono de Amalia, sin pasar por los proxies. Amalia
responde con un 200 OK (14). En este caso, no hay ACK.
11.3.2. El protocolo SIP
En este subapartado veremos el protocolo SIP, incluyendo el formato de los URI SIP
mensajes de petición y respuesta y los campos de cabecera. Muchas de las ca-
En SIP, los URI (direcciones)
racterísticas del protocolo se heredan de HTTP, pero no se trata de una exten- pueden empezar con SIP o
sión. Por ejemplo, el SIP puede utilizar UDP para enviar sus peticiones y res- SIPS. El uso de SIPS indica que
se tiene que establecer una co-
puestas. Las direcciones (URI SIP) de los usuarios que utilizan este protocolo nexión segura (con TLS) para
llevar a cabo la comunicación.
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 máquina (host) a la que se está

dirigiendo. En este contexto, host se refiere a un dominio.
• password: el password asociado al usuario. Aunque se puede poner, su uso

no está recomendado, porque significa enviarlo "en claro" y es un riesgo
de seguridad.
• host: el ordenador que ofrece el recurso SIP. Este campo puede contener un
nombre de dominio o una dirección IP numérica. Se recomienda utilizar
el nombre de dominio.
• port: el número de puerto al que se tiene que enviar la petición.
• uri parameters: parámetros que afectan a la petición que lleva el URI. Los
parámetros se representan como nom-param=valor-param. Están separa-
dos de host:port con punto y coma y entre estos también se separan con
punto y coma.
• headers: campos de cabecera que se pueden incluir en la petición repre-

sentada por el URI.
SIP es un protocolo basado en mensajes de texto. Esto facilita su implemen-

tación y ampliación. A continuación, veremos el formato de los mensajes de
petición y respuesta SIP.
11.3.3. El mensaje de petición SIP
La figura siguiente muestra el formato del mensaje de petición. Este mensaje

consta de tres partes bien diferenciadas: la línea de petición, la cabecera de
petición y el cuerpo del mensaje.
La línea de petición tiene la forma siguiente:
OrdenSIP [Espacio] URI-petición [Espacio] Versión-SIP [Salto línea]
El orden SIP indica qué orden del protocolo estamos utilizando. El URI-peti-
ción identifica el recurso al que queremos acceder, y la versión SIP indica la
versión del protocolo que estamos utilizando. [Espacio] es un espacio en blan-
co y [Salto línea] está bien representado por los caracteres Salto de línea (ASCII
puesto por claridad. Las órdenes SIP son: REGISTER, INVITE, ACK, CANCEL,
BYE y OPTIONS. La funcionalidad de cada método es la siguiente.
• REGISTER: permite registrar un recurso, para que después se puedan llevar

a cabo comunicaciones SIP.
• INVITE: permite iniciar una sesión por parte de un usuario.
• ACK: indica que se ha aceptado la petición enviada con INVITE y que la

sesión se ha establecido.
• CANCEL: permite cancelar una petición ya enviada. Se genera un mensaje

de error y se tiene que dejar de procesar la petición. Sólo se tendría que
utilizar para cancelar un INVITE.
• BYE: permite finalizar la sesión.
• OPTIONS: permite pedir las características de un programa cliente o de un

proxy server.
La cabecera de petición tiene tres partes: la cabecera general, la cabecera pro-

piamente de petición y la cabecera de entidad. El formato de todos los campos
de las cabeceras es el siguiente:

si el mensaje es de petición o de respuesta. La cabecera de petición contiene
campos que sólo tienen sentido para un mensaje de petición. La cabecera de estas tres cabeceras están ex-
xo 3.
El cuerpo del mensaje lleva la información, si la hay, asociada a la petición.
11.3.4. El mensaje de respuesta SIP
La figura siguiente muestra el formato del mensaje de respuesta. Este mensaje

consta de tres partes bien diferenciadas: la línea de estado de la respuesta, la
cabecera y el cuerpo del mensaje.
La línea de estado de la respuesta tiene la forma siguiente:
Versión-SIP [Espacio] Código-Estado [Espacio] por Descripción-Estado [Salto línea]
La versión SIP define la versión del protocolo que se está utilizando, y el código Ved también
de estado define el éxito o error en la petición y la descripción del estado, que
Los valores de los códigos y
es una descripción textual del código de estado. [Espacio] es un espacio en descripciones de estado están
blanco y [Salto línea] está representado por los caracteres Salto de línea (ASCII explicados con detalle en el
anexo 3.
puesto por claridad.
La cabecera de respuesta tiene tres partes: la cabecera general, la cabecera pro-

piamente de respuesta y la cabecera de entidad. El formato de todos los cam-
pos de las cabeceras es:

si el mensaje es de petición o de respuesta. La cabecera de respuesta contiene
campos que sólo tienen sentido para un mensaje de respuesta. La cabecera de estas tres cabeceras están ex-
xo 3.
El cuerpo del mensaje lleva la información, si la hay, asociada a la respuesta.
11.4. H.323
Este protocolo está considerado como una alternativa al SIP y es muy popular
a la hora de transmitir audio y vídeo en tiempo real. Está dedicado a la trans-
misión de voz sobre IP (voice over IP –VOIP–, en inglés). Con H.323, es posible
comunicar un equipo conectado a Internet con un teléfono conectado a la
red telefónica.
H.323 incluye distintas especificaciones:
• Negociación de codificaciones de audio y vídeo entre los extremos de la

comunicación.
• Cómo se envían los trozos de datos de audio y vídeo. H.323 obliga a utilizar
RTP.
• Cómo los equipos se comunican con sus gatekeepers.
• Cómo los equipos conectados a Internet se conectan con los teléfonos

conectados a la red telefónica.
El requerimiento mínimo de H.323 es que se debe soportar el audio, pero las Formatos de datos
características de vídeo son opcionales. De esta manera, los fabricantes pue- utilizados en H.323
den ofrecer unos equipos sencillos con las características de audio y dejar para G.711 – Audio http://
equipos más sofisticados la parte de vídeo. Para transmitir los datos de audio, www.itu.int/rec/T-REC-G.711/
en.
se tiene que utilizar un estándar que utiliza PCM (G.711) para generar voz di- QCIF H.261 – Vídeo http://
gitalizada tanto en 56 kbps como 64 kbps. Aunque el vídeo es opcional, en www.itu.int/rec/T-REC-H.261/
en.
caso de que el terminal lo tenga, debe soportar como mínimo el estándar QCIF
H.261.
La figura siguiente muestra un ejemplo de arquitectura de un sistema H.323:
El gateway es un elemento opcional que sólo se necesita si queremos conectar

equipos que están en una red diferente, como la red telefónica.
El gatekeeper es un elemento opcional en la comunicación entre terminales

H.323. Sin embargo, es el elemento más importante de una red H.323, ya que
hace de punto central de todas las llamadas que hay dentro de una zona y
proporciona servicios a los terminales registrados y control de las llamadas. Se
podría decir que el gatekeeper hace de conmutador virtual.
Para acabar este subapartado, se describen las diferencias principales entre SIP
y H.323.
• H.323 es un conjunto integrado de protocolos para hacer conferencias

multimedia que incluye: señalización, registro, control de admisión, trans-
porte y codecs. Por otra parte, SIP sólo se encarga de iniciar y gestionar la
sesión, sin hacer ninguna imposición en el transporte o los formatos de
audio o vídeo soportados.
• H.323 fue definido por ITU (telefonía), mientras que SIP fue definido por
IETF (Internet). Esto hace que el punto de vista de los dos sea muy dife-
rente.
• H.323 es un estándar complejo, formado por muchas partes, mientras que

SIP es mucho más simple y, por lo tanto, más fácil de implementar.
11.5. Skype
Skype es un sistema de telefonía peer-to-peer (P2P) que funciona sobre la red KaZaa
Internet. Es la competencia de estándares de transmisión de voz sobre IP (VoIP)
KaZaa es una aplicación P2P
como SIP o H.323. Fue desarrollada por el equipo que hizo KaZaa en el año de descarga de contenidos
2003. que tuvo mucho éxito hace
unos años. Utiliza el mismo
protocolo P2P que Skype, Fast-
Track.
Se trata de una aplicación muy utilizada desde que se creó, tanto en sus servi-
cios gratuitos como de pago. Ofrece muchas funcionalidades, incluyendo au-
dio y videoconferencias gratuitas, el uso de tecnologías P2P (descentralizado)
para no tener problemas con cortafuegos o con la traducción de direcciones
(en inglés, Network Address Translation, NAT) y las múltiples medidas para que
no se pueda reconocer el protocolo o el software que la implementan.
La identificación del usuario que llama está enmascarada cuando se hace una
llamada. La diferencia principal entre Skype y otros servicios es que utiliza
tecnología P2P, mientras que el resto utiliza arquitecturas cliente-servidor. La
implementación de P2P que utiliza es FastTrack, implementada en la aplica-
ción KaZaa. La arquitectura que implementa FastTrack es una red superpuesta
(overlay network, en inglés) con dos tipos de nodos: los nodos normales y los
supernodos. Un nodo normal es un ordenador en el que se ha instalado la
aplicación Skype y que permite hacer llamadas y enviar mensajes de texto. Los
supernodos son end-points de la red Skype. Cualquier nodo que tenga una IP
pública y bastantes recursos (memoria, ancho de banda, etc.) puede conver-
tirse 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 su-
pernodo. Todavía tenemos otro elemento en la red, el servidor de login, que
es el que almacena los usuarios y las palabras de paso en toda la red Skype
(los nombres de usuario son únicos). Aparte de este servidor, el resto de las
operaciones en la red (busca de usuarios, envío de mensajes y llamadas, etc.)
se hace de manera totalmente descentralizada.
El directorio de Skype está completamente descentralizado y distribuido entre

los nodos de la red, lo que significa que es fácilmente escalable cuando se tie-
ne un gran número de usuarios sin necesidad de una estructura compleja. Las
llamadas se envían a través de otros usuarios de Skype en la red para facilitar la
comunicación cuando hay cortafuegos o NAT. Esto hace que los usuarios que
se conectan directamente a la red (sin NAT) tengan más tráfico para direccio-
nar las llamadas de otros usuarios. Puesto que se trata de una red superpuesta,
cada cliente Skype tiene que mantener una lista de nodos accesibles. Esta lista
es la lista de hosts y contiene la dirección IP y el número de puerto de los su-
pernodos. En sistemas Windows, se guarda en el registro.
Es posible desarrollar programas que utilicen la API de Skype para acceder a

su red. Sin embargo, el código es cerrado y el protocolo propietario, lo que
dificulta su interoperabilidad con otros sistemas.
12. Anexos
12.1. Anexo 1. El protocolo RTSP
12.1.1. Órdenes
La tabla siguiente describe las órdenes RTSP:
Orden Descripción
OPTIONS Permite al cliente pedir información sobre las opciones de comunicación con el servidor.
DESCRIBE Recupera la información del contenido multimedia identificado por el URL que se envía con la orden.
ANNOUNCE Si lo envía el cliente, se está indicando la descripción de una presentación. Si lo envía el servidor, se actua-
liza la información de la descripción de la sesión en tiempo real.
SETUP Especifica los parámetros del mecanismo de transporte. Se puede enviar a media sesión, para cambiar es-
tos parámetros.
PLAY Se indica al servidor que se debe iniciar el envío de datos.
PAUSE Se indica al servidor que se quiere parar temporalmente la recepción de datos de la sesión.
TEARDOWN Se cierra la recepción de datos.
GET_PARAMETER Pide el valor de un parámetro de la descripción de la sesión.
SET_PARAMETER Envía el valor de un parámetro de la descripción de la sesión.
REDIRECT Se indica al cliente que se tiene que conectar a otro servidor.
RECORD Se inicia la grabación de datos de acuerdo con la descripción de la presentación.
12.1.2. Códigos de estado
Los códigos de estado son de cinco tipos: 1XX, informativos, 2XX, petición
lograda, 3XX, redireccionamiento, 4XX, error en la petición del cliente y 5XX,
error en el servidor.
Sólo se han puesto los códigos específicos de RTSP, el resto están definidos en
el RFC de HTTP.
Tipo de código Valor Descripción
Informativo 100 El cliente puede continuar con la petición.
Éxito 250 Poco espacio de almacenamiento. Puede suceder con la orden RECORD.
Redirección 3XX Los mismos que HTTP.
Error�parte�cliente 405 El recurso no puede ejecutar el método pedido.
Error�parte�cliente 451 El servidor no soporta alguno de los parámetros indicados en la petición.
Error�parte�cliente 452 La conferencia no se ha encontrado.
Error�parte�cliente 453 No hay suficiente ancho de banda para recibir el contenido.
Error�parte�cliente 454 La sesión no se ha encontrado.
Error�parte�cliente 455 El método no es válido en el estado actual del protocolo.
Error�parte�cliente 456 Un parámetro indicado en la cabecera no se puede procesar.
Error�parte�cliente 457 El rango pedido está fuera de los límites.
Error�parte�cliente 458 Un parámetro que se quería modificar con SET_PARAMETER es sólo de lectura.
Error�parte�cliente 459 El parámetro no se puede aplicar al recurso. Sólo se puede aplicar a un stream
Error�parte�cliente 460 El parámetro no se puede aplicar al recurso. Sólo se puede aplicar a una presentación.
Error�parte�cliente 461 El tipo de transporte no está soportado.
Error�parte�cliente 462 El cliente no es accesible.
Error�parte�servidor 551 Una opción enviada a la cabecera no es soportada.
12.1.3. Cabeceras
En la tabla siguiente, se describen las cabeceras del protocolo RTSP que son
específicas de este protocolo. El resto están definidas en el RFC de HTTP:
Cabecera Descripción
Accept Tipos de contenidos aceptados en la presentación.
Allow Métodos RTSP soportados por el servidor.
Bandwidth Ancho de banda calculado del cliente.
Blocksize Tamaño de datos preferido por el cliente. No incluye las cabeceras de protocolos de niveles inferio-
res (IP, UDP, RTSP).
Cache-Control Control del mecanismo de caché de los contenidos.
Conference Establece una conexión entre esta conferencia y un stream existente.
Content-Length Longitud del contenido enviado en el cuerpo del mensaje.
CSeq Número de secuencia en la sesión RTSP de pares petición/respuesta.
Expires Momento en el que el contenido estará obsoleto.
If-Modified-Since Se utiliza con SETUP y DESCRIBE. Si la descripción no se ha modificado desde el momento indicado
en esta cabecera, se envían datos.
Last-Modified Última vez en la que se modificó la descripción del recurso.
Proxy-Require Parámetros que debe soportar un proxy.
Require Sirve para preguntar al servidor qué opciones soporta.
RTP-Info Indica parámetros específicos de RTP en una orden PLAY.
Scale Permite indicar si el contenido se quiere ver a velocidad normal, más rápida o más lenta.
Session Identificador de la sesión.
Speed Pide que la transferencia de datos se haga a una determinada velocidad.
Transporte Protocolo de transporte utilizado.
Unsupported Características no soportadas por el servidor.
12.2. Anexo 2. El formato de los paquetes RTCP
En este anexo, se describen los datos que contiene cada uno de los paquetes
del protocolo RTCP.
12.2.1. Informe de emisor (SR)
La figura siguiente muestra los campos del paquete de tipo SR:

Este tipo de paquete tiene tres secciones y una cuarta, opcional, que son las
extensiones y que están definidas por los perfiles.
La primera sección es la cabecera y tiene ocho octetos. Los campos son los
siguientes.
• Versión (V): 2 bits. Identifica la versión de RTP y es la misma que para los
paquetes de datos. La versión actual es la 2.
• Relleno (P): 1 bit. Si el bit de relleno está activado, este paquete RTCP tiene
octetos de relleno que no forman parte de la información de control, pero
que están incluidos en la longitud del paquete. El último octeto de relleno
indica cuántos octetos se tienen que ignorar, incluido el mismo. En un pa-
quete compuesto, sólo se debe añadir relleno a los paquetes individuales.
• Contador de recepción de informes (RC): 5 bits. El número de bloques de

recepción de informes que hay en este paquete. 0 también es válido.
• Tipo de paquete (PT): 8 bits. Contiene una constante con valor 200 para
identificar que se trata de un paquete de tipo SR.
• Longitud: 16 bits. Longitud del paquete en palabras de 32 bits menos 1,

incluyendo cabecera y relleno.
• SSRC: 32 bits. Identificador de la fuente de sincronización del creador de

este paquete SR.
La segunda sección, la sección del emisor, tiene 20 octetos de longitud y está

presente en cualquier paquete de tipo SR. Hace un resumen de los datos trans-
mitidos por este emisor. Los campos son los siguientes.
• NTP timestamp: 64 bits. Indica el tiempo en el que este informe se envió.

Se puede utilizar para calcular el tiempo de propagación de la información
si se combina con timestamps como paquetes de tipo RR.
• RTP timestamp: 32 bits. Tiene el mismo valor que el campo anterior, pero
con las mismas unidades que los timestamps de los paquetes RTP.
• Número de paquetes enviados por el emisor: 32 bits. El número de paque-

tes RTP de datos transmitidos por el emisor desde que se inició la transmi-
sión hasta el envío de este paquete.
• Número de octetos enviados por el emisor: 32 bits. Número total de octe-

tos de datos (sin incluir cabeceras ni relleno) transmitidos en paquetes de
datos RTP por el emisor desde que se inició la transmisión hasta el envío
de este paquete.
La tercera sección contiene 0 o más bloques de informes de recepción, depen-

diendo del número de fuentes recibidas por este emisor desde el último infor-
me. Cada bloque contiene las estadísticas siguientes.
• SSRC_n (identificador de la fuente): 32 bits. El identificador de la fuente

SSRC a la cual pertenece la información enviada en este bloque.
• Fracción de pérdidas: 8 bits. La fracción de paquetes RTP perdidos por la

fuente SSRC_n desde que se envió el último paquete de tipo SR o RR.
• Número acumulado de paquetes perdidos: 24 bits. El número total de pa-

quetes perdidos desde el inicio de la recepción.
• Número de secuencia más alto recibido: 32 bits. Los 16 bits más altos con-
tienen el número de secuencia más alto recibido y el resto son extensiones
al número de secuencia.
• Jitter entre llegadas: 32 bits. Una estimación estadística de la variancia del

tiempo entre llegadas de los paquetes de datos RTP, medido en unidades
de timestamp y expresado como un entero sin signo.
• Último SR (LSR): 32 bits. La mitad de los 64 bits recibidos en el NTP times-

tamp del último paquete de tipo SR recibido desde la fuente SSRC_n.
• Retraso desde el último SR (DLSR): 32 bits. El retraso entre el último SR

recibido desde SSRC_n y el envío de este paquete de información.
12.2.2. Informe de receptor (RR)
La figura siguiente muestra los campos del paquete de tipo RR:

El formato de este tipo de paquete es igual al del paquete SR, excepto por el
hecho de que el tipo de paquete tiene la constante 201 y la información del
emisor (timestamps NTP y RTP y número de paquetes y octetos enviados) no
está.
12.2.3. Descripción de elementos de la fuente (SDES)
La figura siguiente muestra los campos del paquete de tipo SDES:
Este tipo de paquete tiene una estructura en tres niveles compuesta por una
cabecera y cero o más porciones, cada una de estas formada por elementos que
describen la fuente identificada por la porción.
La primera sección es la cabecera y tiene ocho octetos. Los campos son los
siguientes.
• Versión (V), relleno (P) y longitud tienen el mismo significado que los
definidos por el paquete SR.
• Número de fuentes emisoras (SC): 5 bits. El número de porciones SSRC/

CRSC por las cuales son contenidas en un paquete SDES.
• Tipo de paquete (PT): 8 bits. Contiene la constante 202.
• Cada porción contiene un identificador de SSRC/CSRC, seguido de una

lista de elementos SDES. Cada elemento consiste en un campo de 8 bits
que indica el tipo, un campo de 8 bits que es un contador del número de
octetos que indica la longitud del campo (sin la cabecera) y el texto del
elemento, que no puede pasar de 255 octetos.
Como ejemplo de elemento SDES, veremos cómo se representa el campo CNA-

ME.
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 cons-
tante.
12.2.4. Paquete de cierre (BYE)
La figura siguiente muestra los campos del paquete de tipo BYE:
El paquete BYE indica que uno o más fondos ya no están activos. Los campos
son los siguientes.
• Número de fuentes emisoras (SC): 5 bits. El número de porciones SSRC/

CRSC por las cuales son contenidas en un paquete SDES.
12.2.5. Paquete definido por la aplicación (APP)
La figura siguiente muestra los campos del paquete de tipo APP:
El paquete APP está pensado para que las aplicaciones añadan funcionalidad.
Los campos son:
• Subtipo: 5 bits. Puede utilizarse para definir un subtipo de aplicaciones.

• Nombre: 8 octetos. Nombre escogido por la persona que ha definido los

paquetes de tipo APP, para diferenciarlos de otros paquetes de tipo APP.
• Datos dependientes de la aplicación: longitud variable. Este campo puede

aparecer o no. Es directamente interpretado por la aplicación y no por RTP.
Tiene que ser múltiplo de 32 bits.
12.3. Anexo 3. El protocolo SIP
12.3.1. Códigos de estado
Los códigos de estado son de 5 tipos: 1XX, respuestas provisionales, 2XX, pe-
tición lograda, 3XX, redireccionamiento, 4XX, error en la petición del cliente,
5XX, error en el servidor y 6XX, errores globales (específicos del SIP).
Muchos de los códigos de estado están heredados del protocolo HTTP, pero
también hay códigos específicos del SIP. Los códigos HTTP que no tengan sen-
tido en SIP no se deben utilizar.
Respuestas�provisionales 100 Indica que el siguiente host (salto, hop, en inglés) ha recibido la petición.
Respuestas�provisionales 180 Indica que la petición INVITE se ha recibido en el otro lado y se avisa al usuario.
Respuestas�provisionales 181 La llamada se está redirigiendo.
Respuestas�provisionales 182 La llamada se ha puesto en la cola, porque el receptor de la llamada no está dispo-
nible.
Respuestas�provisionales 183 Información sobre el progreso de la llamada.
Éxito 200 La petición ha ido bien.
Redirección 300 Indica que hay múltiples opciones en la localización de la dirección del usuario al
que se llama.
Redirección 301 El usuario ha cambiado de dirección y se le tiene que llamar a la nueva dirección
indicada en la cabecera Contact.
Redirección 302 El usuario ha cambiado de dirección y se le tiene que llamar a la nueva dirección
indicada en la cabecera Contact.
Redirección 305 Se tiene que utilizar un proxy.
Redirección 380 La llamada no ha sido posible, pero hay servicios alternativos disponibles.
Redirección 400 Formato de petición erróneo.
Redirección 401 El usuario necesita autenticarse.

Redirección 402 Reservado para uso futuro.
Error�parte�cliente 403 El servidor no quiere servir la petición del cliente, aunque tenía un formato correc-
to.
Error�parte�cliente 404 El usuario a quien se ha llamado no se encuentra en el servidor.
Error�parte�cliente 405 El método pedido no se puede ejecutar para la dirección indicada.
Error�parte�cliente 406 El recurso no es aceptable según los valores enviados en la cabecera Accept.
Error�parte�cliente 407 El cliente se tiene que autorizar delante de un proxy.
Error�parte�cliente 408 El servidor no ha podido producir una respuesta a tiempo.
Error�parte�cliente 410 El recurso ya no está disponible en el servidor.
Error�parte�cliente 413 El tamaño de la entidad enviada por el cliente es demasiado grande para que el
servidor la pueda tratar.
Error�parte�cliente 414 El tamaño del URI es demasiado grande para que el servidor lo pueda tratar.
Error�parte�cliente 415 El tipo de datos del contenido no está soportado por el servidor.
Error�parte�cliente 416 La petición no se puede servir, porque el esquema indicado en el URI del recurso
no se reconoce.
Error�parte�cliente 420 El servidor no reconoce las extensiones indicadas en la cabecera.

Proxy-Require
Error�parte�cliente 421 Los programas necesitan una extensión específica para poder servir la petición.
Error�parte�cliente 423 El servidor rechaza la petición, porque expira demasiado pronto.
Error�parte�cliente 480 Se ha podido llegar hasta el servidor, pero el usuario al que se ha llamado no está
disponible temporalmente.
Error�parte�cliente 481 La transacción no existe.
Error�parte�cliente 482 Se ha detectado un bucle en la llamada.
Error�parte�cliente 483 Se ha pasado el máximo de hosts indicados en la cabecera MaxHops.
Error�parte�cliente 484 La dirección del usuario al que se ha llamado es incompleta.
Error�parte�cliente 485 La dirección es ambigua.
Error�parte�cliente 486 El usuario no acepta la llamada.
Error�parte�cliente 487 La petición se ha acabado con un CANCEL o un BYE.
Error�parte�cliente 488 La petición no es aceptable, por algún parámetro indicado.

a la sesión
Error�parte�cliente 491 Hay otra petición pendiente.
Error�parte�cliente 493 El cuerpo del mensaje lleva un tipo MIME que el servidor no puede tratar.
Error�parte�servidor 500 Error interno del servidor, que hace que no pueda servir la petición.
Error�parte�servidor 501 El servidor no tiene implementada la funcionalidad necesaria para servir la peti-
ción.
Error�parte�servidor 502 El servidor recibe un error cuando hace de proxy o gateway.
Error�parte�servidor 503 El servicio está temporalmente no disponible.
Error�parte�servidor 504 El servidor no recibe una respuesta de un servidor externo a tiempo.
Error�parte�servidor 505 El servidor no soporta la versión del protocolo indicada por el cliente.
Error�parte�servidor 513 El mensaje es demasiado largo para que el servidor lo pueda procesar.
Error�general 600 El usuario llamado no está disponible.
Error�general 603 El usuario llamado no quiere aceptar la llamada.
Error�general 604 El usuario llamado no existe.
Error�general 606 La petición no es aceptable, por algún parámetro indicado en la sesión.
12.3.2. Cabeceras
En la tabla siguiente se describen las cabeceras del protocolo SIP que son espe-
cíficas de este protocolo. El resto están definidas en el RFC de HTTP:
Alert-Info Tono de llamada alternativo.
Allow Métodos soportados.
Authentication-Info Información por autenticación mutua
Authorization Credenciales de autorización del cliente.
Call-ID Identificación de una llamada o de una serie de los registros de un cliente.
Call-Info Información adicional sobre los participantes en la llamada.
Contact Contiene una URI que puede tener diferentes significados según el contexto.
Content-Disposition Indicación de la organización del cuerpo del mensaje, en términos de las partes que pueda tener
y los formatos MIME.
Content-Encoding Codificación preferida por el contenido.
Content-Length Longitud del contenido enviado en el cuerpo del mensaje.
Cseq Número de secuencia asociado a una petición.
Date Fecha y hora en los que se creó el mensaje.
Error-Info Información adicional sobre el error expresado en el código de respuesta.
Expires Momento en el que el contenido estará obsoleto.
From Iniciador de la petición.
In-Reply-To Referencia a los identificadores de la llamada asociados a la llamada actual.
Max-Forwards Límite al número de proxies o gateways que pueden reenviar la petición.

Min-Expires Intervalo de refresco mínimo.
Organization Nombre de la organización a la cual pertenece quien genera la petición.
Priority Prioridad de la llamada desde el punto de vista del cliente.
Proxy-Authorization Identificación del cliente frente a un proxy que pide autenticación.
Proxy-Require Requerimientos que debe tener el proxy.
Record-Route El proxy llena esta cabecera para indicar que las futuras peticiones tienen que pasar por el mismo.
Reply-To URI de retorno que no debe ser en absoluto el mismo que el de la cabecera From.
Require Características esperadas del programa de usuario.
Retry-After Indicación de cuándo el servicio volverá a estar disponible.
Route Descripción de los proxies por los cuales tendría que pasar la petición.
Server Descripción del software que utiliza el servidor.
Subject Tema de la llamada.
Supported Extensiones soportadas por el programa de usuario.
Timestamp Indicación de cuándo el programa cliente efectuó la llamada.
To Receptor de la llamada.
Unsupported Descripción de las características no soportadas.
Via Indicación del camino que ha seguido la petición y que se tiene que utilizar para las respuestas.
WWW-Authenticate Valor de respuesta de autenticación.

Resumen
En este módulo, se ha empezado describiendo las arquitecturas de aplicaciones

más habituales en Internet: cliente servidor y de igual a igual, así como los
requerimientos de las aplicaciones orientadas al envío de datos o de mensajes.
A continuación, se han descrito las aplicaciones distribuidas más habituales

en Internet y diferentes estándares que están relacionados: Web y HTTP, DNS,
SMTP, FTP, XMPP, Telnet y SSH, Gnutella, KaZaA, BitTorrent y eDonkey.
Después, se han introducido los requerimientos de las aplicaciones multime-

dia en red.
Finalmente, se han visto una serie de técnicas y protocolos para trabajar con
contenidos multimedia en Internet, tanto por streaming de audio y vídeo:
RTSP; como por aplicaciones interactivas en tiempo real: RTP, RTCP, SIP, H3.23
y Skype.
Bibliografía
Kurose, J. F.; Ross, W. K. Computer Networking (5.ª edición). Boston: Addison Wesley. ISBN
0-321-49770-8.
Este libro proporciona una visión completa de los diferentes aspectos relacionados con las
redes de ordenadores. En este módulo interesa el capítulo 2 ("Application Layer"), en el que se
pueden encontrar los conceptos básicos de la Web, el correo electrónico, la transferencia de
ficheros y el servicio de directorio de Internet. También hay un apartado de igual a igual que
puede complementar la visión de los sistemas de igual a igual dada en este módulo.
Keagy, S. (2000). Integrating Voice and Data Networks. Indianapolis: Cisco Press.
En este libro se describe el protocolo SIP.
Niederst, J. (2006). Web Design in a Nutshell (3.ª ed.). Sebastopol: O'Reilly.
En este libro hay dos secciones dedicadas a los formatos de audio y vídeo que se transmiten
por Internet.
Hersent, O.; Gurle, D.; Petit, J. P. (1999). IP Telephony: Packet-Based Multimedia Commu-
nications Systems. Indianapolis: Addison Wesley Professional.
En este libro, se describen los protocolos SIP y H.323 para la implementación de telefonía
sobre IP.
Artículos
Baset, S.; Schulzrinne, H. (2004). "An Analysis of the Skype Peer-To-Peer Internet Telep-
hony Protocol".
Este artículo describe la arquitectura y el protocolo de Skype basados en la captura de los

datos enviados por la red que han hecho los autores.
Lua y otros (2005). "A survey and comparison of peer-to-peer overlay network schemes".
IEEE Communications Surveys&Tutorials (vol. 7, núm. 2).
En este artículo encontraréis un resumen de cómo funcionan las redes superpuestas de igual
a igual más populares, así como una comparativa entre las mismas. También encontraréis
más detalle de los sistemas explicados en este módulo.
Comunicaciones
inalámbricas
PID_00147722
© FUOC • PID_00147722 Comunicaciones inalámbricas
© FUOC • PID_00147722 Comunicaciones inalámbricas
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 7
1. Sistemas de comunicación de la telefonía móvil....................... 9

1.1. GSM (global system for mobile communication) ............................ 10
1.2. GPRS ............................................................................................ 16
1.3. EDGE ........................................................................................... 19
1.4. UMTS ........................................................................................... 19
1.4.1. Equipos móviles ............................................................. 28
2. Redes inalámbricas............................................................................ 29
2.1. Infrarrojos .................................................................................... 30
2.2. Bluetooth ..................................................................................... 33
2.3. ZigBee .......................................................................................... 40
2.4. WiFi ............................................................................................. 43
2.5. WiMax ......................................................................................... 47
Resumen....................................................................................................... 54
Bibliografía................................................................................................. 55
© FUOC • PID_00147722 5 Comunicaciones inalámbricas
Introducción
Las ondas infrarrojas, microondas y ondas hertzianas son las llamadas radia-
ciones electromagnéticas que se utilizan en el campo de las telecomunicacio-
nes inalámbricas (sin cable).
En las primeras comunicaciones a larga distancia que se realizaron, se utili-

zaban columnas de humo o luz creada con antorchas de fuego. La luz se ha
usado como medio de comunicación por su facilidad de producirse y porque
recorre distancias largas a gran velocidad. La ventaja de las ondas infrarrojas,
microondas y hertzianas es que no son visibles para el ojo humano, a pesar de
que pueden servir para la comunicación de información.
En los últimos años, el mercado de las comunicaciones inalámbricas se ha po-

pularizado debido a las ventajas de las redes sin hilos: movilidad, flexibilidad,
facilidad de instalación, escalabilidad, dinamismo en los cambios de la topo-
logía, y la posibilidad de llegar donde no llega el cable. Como principales in-
convenientes podemos destacar su elevado coste inicial y su seguridad.
Dentro del mundo de las comunicaciones sin hilos, podemos distinguir dos
grandes grupos:
• Sistemas de comunicación con telefonía móvil.

• Redes inalámbricas.
Actualmente, la gran mayoría de la población tiene un teléfono móvil, y su

uso ha experimentado un crecimiento exponencial en todo el mundo durante
los últimos años. Inicialmente, la telefonía móvil, que sólo servía para man-
tener conversaciones telefónicas, evolucionó con la posibilidad de realizar en-
víos de pequeños mensajes de texto (SMS). Más adelante se posibilitó el acce-
so a Internet, primero a través del protocolo WAP, después el aumento de las
velocidades de acceso a Interent con GPRS y finalmente, con las tecnologías
UMTS, que permiten disponer de terminales móviles (teléfonos, ordenadores
de bolsillo...) multimedia con múltiples servicios y aplicaciones con conexio-
nes a altas velocidades.
A escala mundial se ha alcanzado la cifra de 4.000 millones de abonados mó-

viles, con un índice de penetración en torno al 60%. En el 2009, China era
el mercado más importante, con más de 600 millones de usuarios. El sistema
GSM era el más utilizado, con una cuota en turno al 80% y más de 3.000 mi-
llones de usuarios. El número de usuarios de 3G en el mundo superaba los 900
millones (250 millones UMTS/HSPA).
La evolución de las redes inalámbricas de área local WiFi, gracias a la popu-

larización de los accesos domésticos a Internet, se ha extendido en multitud
de hogares y empresas, así como la utilización del protocolo Bluetooth para
interconectar diferentes accesorios y dispositivos en ordenadores, impresoras,
ratones, teclados, etc.
Objetivos
El estudio de los materiales didácticos de este módulo tiene que permitiros

alcanzar los objetivos siguientes:
1. Conocer las tecnologías más habituales y actuales utilizadas en la telefonía

móvil comercial.
2. Tener una visión general de la rápida evolución histórica de la tecnología

móvil en los últimos treinta años.
3. Entender bien las características y limitaciones de cada tecnología de tele-

fonía móvil.
4. Saber cuáles son las funcionalidades actuales y futuras que se ofrecen a los
usuarios de la telefonía móvil.
5. Conocer los estándares y los nombres de las redes inalámbricas de uso más
común en la actualidad.
6. Entender bien la diferencia de las funcionalidades de las redes inalámbri-

cas según su tipología: consumo, prestaciones, velocidad de transmisión,
distancia entre los equipos, etc.
7. Saber elegir una tecnología inalámbrica concreta para una situación par-
ticular.
1. Sistemas de comunicación de la telefonía móvil
En 1985 surgió en Europa la primera generación (1G) de teléfonos móviles

después de adaptar el sistema advanced mobile phone system (AMPS) a los requi-
sitos europeos denominados total access communications system (TACS). TACS
engloba todas las tecnologías de comunicaciones móviles analógicas. Con ella
se podía transmitir voz pero no datos. Actualmente, esta tecnología está ob-
soleta y desaparecerá en el futuro.
Debido a la sencillez y las limitaciones de la primera generación surgió el sis-

tema global system for mobile communications (GSM), que marcó el comienzo
de la segunda generación (2G) de la telefonía móvil. Esta tecnología puede
transmitir datos, además de las bien conocidas conversaciones de voz, a una
velocidad de 9,6 kbit/s; la transmisión de datos se inició con el servicio de
mensajería corta o mensajes SMS.
Después, surgió la tecnología WAP, que consistía en unas páginas web pensa-
das para verlas con las pantallas monocromas de los teléfonos móviles. Las pri-
meras conexiones se hacían con llamadas al proveedor telefónico, que trans-
mitía los datos como si fuera un módem tradicional y los transmitía a una
velocidad de 9,6 kbits/s.
En el 2001 surgió la denominada segunda generación y media (2,5G), como

paso previo a la tercera generación (3G). En la 2,5G están incluidas todas las
tecnologías que permiten una mayor capacidad de transmisión de datos y que
surgieron como paso previo a las tecnologías 3G. Dentro de esta generación
nació la tecnología general packet radio service (GPRS), que permitía acceder a
Internet a través del protocolo TCP/IP. La velocidad de comunicación era de
54 kbits/s de bajada y 9,6 kbits/s de subida, y el servicio se pagaba por los datos
descargados, no por el tiempo de conexión.
Con la finalidad de facilitar las comunicaciones inalámbricas debido a su ge-

neralización en todo el mundo, la International Telecommunication Union
(ITU) adoptó diferentes interfaces de acceso radioeléctrico llamadas internatio-
nal mobile telecommunications-2000 (IMT-2000) o comunicaciones móviles in-
ternacionales.
Después surgieron las tecnologías 3G, que se definen dentro del IMT-2000 (de
la ITU) que marca el estándar para que todas las redes 3G sean compatibles
unas con otras. Actualmente, el 3GPP (3er generation partnership project) está
trabajando con el universal mobile telecommunications system (UMTS), una de las
tecnologías que utilizan los móviles de tercera generación (3G). Esta tecnología
permite descargar datos a una velocidad de hasta 2 Mbits/s, lo que fomenta la
aparición de nuevas aplicaciones y servicios.
A pesar de todo, la tecnología UMTS no está actualmente concebida para su-

plantar la tecnología ADSL por cable de los hogares, empresas y oficinas, ya
que todavía sólo se factura por descarga de datos. También es necesario que en
la zona donde se utiliza haya cobertura para esta tecnología. Además, también
hace falta que en la zona donde se opera haya cobertura para esta tecnología.
Hoy día, la tecnología UTMS se puede utilizar para conexiones a Internet, co-
rreo electrónico, FTP (transferencia de archivos), telnet (terminal remoto), vi-
deoconferencias, comercio electrónico, etc.
La cuarta generación (4G) será el futuro de la tecnología móvil, con velocida-

des de transmisión de 50 Mbps de subida y 100 Mbps de bajada, y utilizará
diferentes tecnologías (MIMO, HSDPA, OFDM).
1.1. GSM (global system for mobile communication)
(1)
El sistema global system for mobile communication1 (GSM) es un estándar acep- En castellano, sistema global de
comunicación móvil.
tado por los teléfono móviles o celulares. GSM es el nombre de un grupo de
estandarización, ideado en 1982, pensado para crear un estándar de comuni-
cación para los teléfonos móviles europeos.
El sistema GSM, por ser un sistema estándar, ofrece la ventaja de permi-

tir al usuario disfrutar de los servicios contratados al mantenerlo conec-
tado de manera automática independientemente de la parte del mundo
donde se encuentre. Eso es posible gracias al hecho de que, al ser un
sistema celular global, el espacio está dividido en celdas, de modo que
cada una de ellas dispone de una estación de radio que le da cobertura.
De esta manera, a medida que un usuario se desplaza de una celda a otra,
la cobertura y la transmisión se recuperan de manera automática en la
nueva estación de radio gracias al hecho de que todas ellas se encuen-
tran interconectadas (proceso denominado handover). Por este motivo,
y a causa del auge de este sistema de comunicación, puede ocurrir que,
en algunos lugares y ciertas épocas del año, el sistema quede congestio-
nado cuando la demanda de servicio en una celda o zona geográfica
concreta supera su capacidad, como pasa en algunas zonas turísticas en
temporadas de gran afluencia.
El estándar GSM proporciona recomendaciones pero no requerimientos. Las

especificaciones definen en detalle las funciones y los requerimientos de las
interfaces, pero no describen el hardware de los equipos. La razón de hacerlo
así es limitar al máximo el número de diseñadores para hacer posible que un

mismo operador de telecomunicaciones pueda adquirir los equipos de varios
fabricantes diferentes.
La red GSM se divide en tres sistemas:
1) el sistema de conmutación (switching system, SS),

2) el sistema de estación base (base station system, BSS), y
3) el sistema de operación y soporte (operation and support system, OSS).
Los elementos básicos de una red GSM se describen en la siguiente figura.
El sistema de conmutación (SS) es el responsable de gestionar el procesamiento Suscriptor

de las llamadas y las funciones del suscriptor. Su estructura está constituida
Es el cliente-usuario de un ope-
por los elementos siguientes: rador de telecomunicación.
• Registro�de�localización�(HLR). Es una base de datos utilizada para guar-

dar y gestionar las suscripciones. Se la considera la base de datos más im-
portante y guarda la información permanente sobre los suscriptores, los
perfiles de servicios de los suscriptores, información de localización y es-
tado de la actividad. Cuando una persona individual compra una suscrip-
ción (se da de alta con un operador de telecomunicaciones) a uno de los
operadores de telecomunicaciones (operador PC), la persona queda regis-

trada en el HLR de este operador.
• Centro�de�conmutación�de�los�servicios�móviles�(MSC). El MSC propor-

ciona las funciones de conmutación de telefonía en el sistema. Controla
las llamadas a, y desde, otros teléfonos y sistemas de datos.
• Registro�de�localización�de�los�visitantes�(VLR). La VLR es una base de

datos que contiene información temporal sobre los suscriptores que ne-
cesitan el MSC como suscriptores visitantes. El VLR se integra dentro del
MSC. Cuando una estación móvil permanece en una nueva área MSC, el
VLR conectado a este MSC pedirá información sobre la estación móvil a
la HLR. Después, la estación móvil realiza una llamada, y el VLR tendrá
la información necesaria para realizar el establecimiento de llamada sin
necesidad de tener que interrogar al HLR constantemente.
• Centro�de�autoidentificación�(AUC). El AUC proporciona autoidentifi-

cación y encriptación para determinar la identidad y asegurar la confiden-
cialidad de cada llamada. Protege las operaciones de red contra diferentes
tipos de fraudes.
• Registro�de�la�identidad�de�los�equipos�(EIR). El EIR es una base de datos

que contiene información sobre la identidad de los equipamientos móviles
que realiza la prevención que las llamadas sean escuchadas, no autorizadas
o detectar estaciones móviles defectuosas.
El sistema de estación base (BSS) realiza todas las funciones relacionadas con
la transmisión por radio, que consiste en controladores de estación base (BSC)
y las estaciones transmisoras base (BTS). Sus funciones son las siguientes:
• El BSC proporciona todo el control de las funciones de los enlaces físicos

entre el MSC y el BTS. Es un conmutador de alta capacidad que proporcio-
na funciones como el control de la radiofrecuencia (RF), información de
la configuración de celda, niveles de potencia en las BTS. Varios BSC son
servidos por un mismo MSC.
• El BTS proporciona la interfaz de radio hacia la estación móvil. El BTS es

el equipamiento de radio (transmisores y receptores y antenas) que se ne-
cesita para proporcionar servicio a cada celda. Un grupo de BTS es contro-
lado por un BSC.
El centro de mantenimiento y operaciones (OMC) se conecta a todos los equi-

pos en el sistema de conmutación y a los BSC. La implementación del OMC se
llama el sistema de soporte y operaciones (OSS). El OSS es la entidad funcional
a partir de la cual el operador de la red controla y monitoriza el sistema. El
OSS ofrece al cliente soporte para las operaciones de mantenimiento centrali-
zadas, regionales y locales. Una función importante del OSS es proporcionar

una visión global de la red y dar soporte a las actividades de mantenimiento
de las diferentes organizaciones.
Otros elementos son el message center (MXE), que guarda los mensajes de datos,
de voz, y de fax; el mobile service node (MSN), que proporciona servicios de red
inteligentes, el gateway mobile services switching center (GMSC), que sirve para
inteconectar dos redes, y la GSM interworking unit (GIWU), que consiste en el
hardware y software de la interfaz de varios redes.
La red GSM se construye a partir de áreas geográficas. La siguiente figura mues-

tra las agrupaciones en celdas, áreas de localización (LA), áreas de servicio
MSC/VLR y áreas públicas móviles de tierra (PLMN).
La celda es el área de cobertura proporcionada por una estación base de trans-

misión (BTS). La distribución más habitual de posicionar las celdas es crearlas
hexagonales para aumentar la cobertura de la red y minimizar los efectos de
los transmisores de las celdas contiguas.
La red GSM identifica cada celda a través de la identidad global de celda (CGI),
que es un número asignado a cada celda. Un área de localización es un con-
junto de celdas. En esta área es donde el suscriptor está situado. Cada área de
localización está servida por uno o más controladores de estaciones base, para
una sola MSC. A cada área de localización se le asigna un número denominado
identidad de localización de área.
Cada área de servicio MSC/VLR representa la parte de la red GSM que es cu-
bierta 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:

GSM transmite entre las frecuencias de 1,850-1,9990 MHz (teléfono móvil y

estación base), y su velocidad de transmisión máxima puede ser de 270 Kbps.
Hay dos tipos de servicios básicos ofrecidos por GSM: telefonía y datos.
Los servicios de telefonía son básicamente los servicios de voz que proporcio-
nan los suscriptores para comunicarse con otros suscriptores (telefonía nor-
mal y llamadas de emergencia). Los servicios de datos son básicamente los si-
guientes:
• Servicio de fax de grupo III: permite que un fax GSM se pueda comunicar
con un fax analógico.
• Servicio de transmisión de mensajes cortos SMS: 160 caracteres alfanumé-

ricos entre estaciones móviles, garantizando que los mensajes se guarda-
rán si la otra estación no está conectada, y, por tanto, se recibirán con toda
seguridad.
• Servicio de buzón de voz: una máquina del operador recibe y guarda las
llamadas y mensajes del buzón de voz.
• Servicio de envío de mensajes broadcast entre los suscriptores de un área.
• Servicio de correo de fax: el suscriptor puede recibir un mensaje de fax en

cualquier máquina de fax.
Otros servicios que ofrece GSM
Otros servicios suplementarios que ofrece GSM son:
• redireccionamiento de llamadas entrantes hacia otro número de teléfono

• prevención o filtrado de determinadas llamadas salientes de la estación móvil
• prevención o filtrado de recepción de determinadas llamadas
• aviso del coste de una llamada o un mensaje
• conversaciones telefónicas múltiples
• etc.
El suscriptor, para comunicarse dentro de la red GSM, utiliza el teléfono móvil,

que internamente es un transmisor y receptor de señales. El teléfono móvil
está formado por diferentes circuitos de control; tiene unos dispositivos de
amplificación y modulación/desmodulación de la señal, circuitos de codifica-

ción y descodificación de señales A/D y D/A, un altavoz y un micrófono, una
batería, una pantalla, un teclado y una antena.
El teléfono móvil lleva una tarjeta inteligente, denominada módulo de iden-

tificación de suscriptor (SIM). Es un elemento exclusivo del suscriptor del ser-
vicio y constituye la base del sistema de abonado ofrecido por el operador
de la red. Cuando se introduce dentro de un teléfono móvil, éste adquiere el
número de teléfono asociado a la tarjeta SIM. Dentro de cada tarjeta SIM se
guarda la international mobile suscriber identity (IMSI), que es la identificación
internacional del suscriptor.
1.2. GPRS
El general packet radio service (GPRS) o servicio general de paquetes vía radio
es una extensión del GSM, que permite la transmisión de datos por paquetes,
con velocidades de transferencia de 56 a 144 Kbps. Servicios como el wireless
application protocol (WAP), servicio de mensajería multimedia (MMS), acceso a
Internet o SMS pueden utilizar el GPRS. La transferencia de datos de GPRS se
cobra por volumen de información transmitida, no por tiempo, independien-
temente de si el usuario utiliza toda la capacidad del canal o está en estado
de inactividad.
GPRS es una tecnología de conmutación de paquetes que surge como

una evolución de las redes GSM para proporcionar mayor velocidad y
más prestaciones en el acceso móvil a servicios de datos e Internet. Com-
plementa las redes GSM, y no las sustituye. Es una buena alternativa a
la migración progresiva hacia la tercera generación de redes móviles y
permite una introducción gradual de aplicaciones y servicios para eva-
luar la viabilidad y rentabilidad del acceso móvil a Internet.
GPRS se basa en una red de conmutación superpuesta a la red GSM. Fue nece-
sario instalar nuevos nodos y elementos de red sobre la red GSM para soportar
servicios de conmutación de paquetes pero se utiliza la misma infraestructura
GSM en el subsistema de radio. Las estaciones base son las mismas en GSM
que en GPRS.
Los tipos de terminales GPRS pueden ser de:
• Clase�A: soporta tanto servicios GSM como servicios GPRS de manera si-
multánea.
• Clase�B: soporta servicios GSM y servicios GPRS, pero de forma alternativa,

no simultánea.
• Clase�C: soporta servicios GPRS de forma exclusiva, habitualmente en for-

ma de tarjeta para insertar en un PC portátil.
Acceso a Internet
Un acceso propio a Internet podría ser de la siguiente manera con APN: movistar.es.
El perfil estaría configurado por defecto para navegar por Internet con el TME como
proveedor del servicio y acceso a los diferentes servicios ubicados en la red de TME. La
secuencia de acciones sería:
1) MS solicita la activación de un contexto con el APN movistar.es.
2) El MS proporciona un identificador y una contraseña genéricos. Por ejemplo, usuario:

MOVISTAR; clave: MOVISTAR.
3) El GGSN solicita la asignación de una dirección IP.
4) El servidor Radius del TME asigna una dirección IP al MS.
5) El MS puede acceder a Internet a través de la red de TME.

Por ejemplo, se puede crear una conexión a Internet en un ordenador portátil de las
siguientes maneras:
• Creando una conexión entre el portátil y un teléfono móvil mediante el protocolo

bluetooth (o un enlace de infrarrojos). El teléfono móvil tiene la capacidad de crear
una conexión a Internet a través de la red GPRS. La comunicación entre el ordenador
y el teléfono móvil se hace a través de una aplicación que gestiona la conexión entre
los dos equipos.
• Conectando al ordenador directamente con una tarjeta PC Card con un SIM GSM
El wireless application protocol (WAP) es un protocolo con el objetivo de la com-

binación de dos tecnologías de comunicación inalámbrica e Internet. Funcio-
na sobre GSM, pero lo puede hacer sobre GPRS o UMTS, como veremos más
adelante. Se trata de un protocolo que permite la conexión de terminales mó-
viles a fuentes externas de forma interactiva, ya sean servidores IP, bases de
datos o multimedia. Por ejemplo, las estaciones móviles para navegar por In-
ternet incorporan un micronavegador WAP, que es equivalente a un navega-
dor web. El micronavegador es el visualizador que permite ver páginas WML,
que es un lenguaje muy parecido al HTML. Las pasarelas WAP convierten pá-
ginas HTML en páginas WML, teniendo en cuenta el reducido tamaño de las
pantallas y las funcionalidades de los dispositivos móviles (teléfonos móviles,
PDA...).
Otros usos de WAP
WAP también ofrece servicios

para la transferencia asíncro-
na de mensajes multimedia
(MMS), y también permite en-
viar y recuperar los mensajes
en un servidor e-mail de Inter-
net a través de las oportunas
conversiones.
Difusión de EDGE
Últimamente han aparecido

tarjetas de red y teléfonos mó-
viles con tecnología EDGE de
diversos fabricantes, como el
aumento de redes y operado-
res en diversos países con esta
tecnología.
1.3. EDGE
Enhanced data for global evolution (EDGE) y enhanced data rates for GSM
evolution son tecnologías que permiten aumentar las velocidades de
transmisión de datos y la eficiencia espectral, facilitando nuevas aplica-
ciones y el aumento de la capacidad para el uso en servicios de telefonía
móvil.
Suponen un paso adelante en los servicios de datos de GSM y GPRS y distingue:
• Enhanced circuit-switched data (ECSD).

• Enhanced general packet radio service (EGPRS).
1.4. UMTS
El espectacular desarrollo que ha experimentado la tecnología de los sistemas

de comunicación y el acceso a todo tipo de información por parte de los usua-
rios son algunas de las causas que han potenciado el desarrollo de una nueva
generación de terminales de comunicación capaz de facilitar la interconexión
de las distintas redes mundiales.
Los sistemas UMTS (o UTMS) o sistemas de tercera generación (3G o W-CD-

MA) han ido desplazando gradualmente los sistemas GSM actuales a causa de
las grandes ventajas que supone para los usuarios tener a su disposición un
sistema de interconexión global de todas las redes. UMTS equivale a la tercera
generación de comunicaciones móviles. Una generación más fiable y flexible
que las dos anteriores.
IMT-2000 define un estándar global para la tercera generación, iniciativa de la

ITU para proveer de acceso inalámbrico a la infraestructura global de teleco-
municaciones a través de sistemas por vía satélite y sistemas terrestres. UMTS
es la propuesta europea (ETSI) para promover la utilización de UMTS Terres-
trial Radio Access (UTRA) en el IMT-2000. 3GPP (Third Generation Partnership
Project) es un foro formado por organismos de diferentes países (ETSI, TTA,
TTC y CWTS) para la elaboración de especificaciones técnicas para UMTS.
Los objetivos de IMT son: la convergencia de redes fijas y móviles, igua-

lar la calidad de servicio, ofrecer servicios multimedia simétricos y asi-
métricos, roaming global, asignación dinámica de ancho de banda hasta
un máximo inicial de 2 Mbps, acceso personalizado –concepto de virtual
home environment (VHE) para definir un perfil de servicio constante y
homogéneo independiente de la red que le sirve el abonado–, uso de la
tecnología de paquetes y protocolos IP, soporte de un amplia gama de
terminales, y capacidad para un alta densidad de usuarios.
En la implantación de los sistemas 3G juega un papel muy importante el fo- Dirección web
ro UMTS, un organismo independiente, creado en 1996, en el que participan recomendada
cerca de 170 compañías de 30 países, pertenecientes a las industrias suminis- Podéis acceder al foro UMTS
tradoras de equipos, operadores de telecomunicaciones y organismos de regu- a través de la página web
http://www.umts-forum.org.
lación. El foro está comprometido en la formación del consenso necesario pa-
ra introducir y desarrollar con éxito el estándar UMTS y así poder satisfacer
la demanda del mercado de unas comunicaciones móviles personales de bajo
coste y alta calidad. Los países europeos lo están desarrollando en cooperación
con las organizaciones de estandarización en el 3G.
UMTS en España
España fue uno de los países pioneros en la tecnología UMTS, y ha sido uno de los pri-
meros países en lanzar el servicio. En el 2000 se adjudicaron cuatro licencias UMTS dis-
ponibles a las operadoras Telefónica Móviles (Movistar), Airtel (actualmente Vodafone),
Amena (actualmente Orange) y el consorcio Xfera (más conocido como Yoigo).
Las fases del desarrollo de UMTS han sido:
• Primera�fase. Elaboración de las descripciones técnicas y evaluación de

las soluciones para UTRAN. Concluir con una descripción detallada de
UTRAN en la que se incluyen los protocolos de interfaz de radio, los pro-
tocolos internos y los protocolos del subsistema de red.
• Segunda�fase. Elaboración de las especificaciones del Release 99 para la

integración de UMTS con las redes GSM/GPRS existentes.
• Tercera�fase. Corrección iterativa de las especificaciones prevista para fi-

nales del 2001.
• Cuarta� fase. Incremento del bit rate para alcanzar tasas superiores a 2
Mbits/s.
Arquitectura global GSM
UMTS es una tecnología apropiada para una gran variedad de usuarios y de

tipos de servicios, y no únicamente para usuarios avanzados. UMTS ofrece fa-
cilidad de uso y costes bajos, servicios modernos y mejorados, acceso rápido,
transmisión de paquetes de datos y velocidad de transferencia de datos a de-
manda, entorno de servicios amigable y consistente.
Las características más sobresalientes de UMTS son: roaming sin fisuras,

acceso global rápido, multimedia, separación de servicios y plataformas,
un terminal puede estar conectado a varios nodos a la vez, velocidad
de transmisión de hasta 2 Mbps, capacidad para determinar la posición,
mecanismos de seguridad, calidad de servicio (servicios de valor añadi-
do o calidad) muy desarrollada, VHE (interfaz para cualquier red).
UMTS proporciona servicios de fácil uso y adaptables para abordar las nece-
sidades y preferencias de los usuarios, una amplia gama de terminales para
realizar un fácil acceso a distintos servicios y bajo coste de los servicios para
hacerse con un mercado masivo. También ofrece la capacidad de ofrecer dife-
rentes formas de tarificación y el servicio de roaming internacional.
UMTS ha evolucionado para integrar todos los servicios ofrecidos por las dis-
tintas tecnologías y redes actuales (GSM, RDSI, Internet...) y se puede utili-
zar en determinados terminales (teléfono fijo, inalámbrico, celular, terminal
multimedia...), tanto en ambientes profesionales como domésticos, ofrecien-
do una mayor calidad de servicios y soportando la personalización del usuario
y los servicios multimedia móviles en tiempo real. Los terminales son multi-
modo y multibanda, con cámara incorporada, pantalla de color y una gran
memoria.
Los servicios 3G combinan el acceso móvil de alta velocidad con los servicios
basados en el protocolo IP. Pero la 3G no sólo lleva una conexión rápida al
World Wide Web (WWW), sino que, además, implica nuevas formas de comu-
nicación, de acceder a la información, de hacer negocios, aprender y disfrutar

del tiempo libre, que relegan al pasado las conexiones fijas y lentas. Como
la 3G puede realizar múltiples conexiones simultáneamente desde un mismo
terminal móvil, un usuario se puede conectar a una base de datos remota para
obtener información sin necesidad de interrumpir una sesión de videoconfe-
rencia.
Para asegurar el éxito de los servicios 3G, se proporciona a los usuarios unas
comunicaciones muy eficientes, con una alta velocidad y calidad, y fáciles de
utilizar. Por eso ofrecen: transmisión de alta fiabilidad, hasta 384 kbits/s en es-
pacios abiertos y 2 Mbits/s con baja movilidad, uso del ancho de banda diná-
mico en función de la aplicación, soporte tanto en conmutación de paquetes
como de circuitos, acceso a Internet (navegación WWW), videojuegos, comer-
cio electrónico, vídeo y audio en tiempo real, diferentes servicios simultáneos
en una sola conexión, calidad de voz con la red fija, mayor capacidad y uso
eficiente del espectro, personalización de servicios según el perfil de usuario,
servicios dependientes de la posición, incorporación gradual en coexistencia
con los sistemas actuales de 2 GR, itinerancia o roaming (incluido el interna-
cional) entre diferentes operadores y cobertura mundial con servicios terres-
tres y por satélite.
La estructura de las redes UMTS está compuesta por dos grandes subre-
des: la red de telecomunicaciones y la red de gestión. La primera es la
encargada de sustentar el trasvase de información entre los extremos de
una conexión. La segunda tiene como objetivo la provisión de medios
para la facturación y tarificación de los abonados. Tiene los siguientes
elementos:
• Núcleo de la red (core network).

• Red de acceso a radio (UTRAN).
• Terminal móviles.
La velocidad de transferencia de datos que la Unión Internacional de Teleco-

municaciones (UIT) requiere en su solución IMT-2000 va desde los 144 kbit/s
sobre vehículos a gran velocidad, hasta los 2 Mbits/s sobre terminales en in-
teriores de edificios (cifra al menos 60 veces superior a la que se tenía cuan-
do se utilizaba un módem convencional para la red telefónica conmutada, la
telefonía de toda la vida), pasando por los 384 kbit/s en usuarios móviles en
vehículos de baja velocidad.
Los tipos de celdas en UMTS son:

• Macroceldas (radio entre 1 y 40 Km). Cobertura celular en grandes áreas

abiertas y las celdas sirven de paraguas para cubrir agujeros entre zonas
con microceldas.
• Microceldas (radio entre 50 y 1.000 metros). Son la cobertura celular en

áreas urbanas y autopistas. Usan antenas direccionales, y sirven también
para cubrir las zonas oscuras en macroceldas.
• Picoceldas (radio inferior a 50 metros). Se usan en entornos residenciales e

interiores de oficinas. La zona cubierta depende de la estructura del edificio
y los materiales utilizados.
Después de la implantación del sistema UMTS, el concepto de teléfono móvil

ha cambiado radicalmente, pasando de ser un simple instrumento de comu-
nicación a convertirse en un terminal multimedia con múltiples capacidades
para la comunicación y el ocio, gracias a la gran cantidad de servicios ofrecidos
y que crecen cada día. Además, para zonas en las que la telefonía móvil no
llega o llega de manera deficiente, la tecnología UMTS habilita la posibilidad
de hacer llegar los servicios de telecomunicaciones avanzados.
Nuevos servicios a través de UMTS
Actualmente, algunos operadores ya ofrecen vídeollamadas, vídeo mensajería, descarga

de juegos, música de calidad MP3, clips de vídeo e imágenes en directo de temas de
actualidad y la conexión a Internet para navegar desde el móvil. Algunos operadores ya
prometen canal de televisión 24 horas en directo, cursos en línea, etc.
Los modelos de mercado UMTS son:
• Modelos de interrelación:
– B2B: Business-to-Business.
– B2E: Business-to-Employee.
– B2C: Business-to-Consumer.
• Clases de servicios básicos:

– Intranet/extranet móvil.
– Servicios de localización.
– Servicios de voz.
– Servicios de mensajería multimedia.
– Acceso móvil a Internet.
– Ocio personalizado.
Gráfico de la implantación de UMTS
UMTS ofrece servicios básicos de telecomunicación:
• Servicios� portadores: servicios de conmutación de circuitos para trans-

misión de voz y audio, servicios de conmutación de paquetes (llamadas
virtuales, canales virtuales permanentes, conectividad RDSI –interactiva:
conversación, mensajería a demanda–, distribución –envío continuo a
múltiples usuarios–, señalización a los usuarios). En la transferencia de la
información puede ofrecer una tasa binaria constante de información ga-
rantizada, una tasa binaria variable dinámicamente no garantizada, una
tasa binaria variable dinámicamente en tiempo real con una tasa binaria
mínima garantizada. El tráfico puede ser punto a punto o unidireccional
punto-multipunto (multicast, broadcast). Con respecto a la calidad de la
información, puede tener un máximo retardo en la transferencia, una va-

riación en el retardo, una tasa de error de bit y una tasa de datos.
Tasas de transmisión en redes de acceso móvil. Tiempo de descarga de

aplicaciones típicas
Aplicación RDSI GSM GRPS UMTS
E-mail�(10�Kbytes) 1s 8s 0,7 s 0,04 s
Página�web�(20�Kbytes) 2s 20 s 1,6 s 0,1 s
Fichero�PowerPoint�(2�Mbytes) 4 min 28 min 2 min 7s
Videoclip�(4�Mbytes) 8 min 48 min 4 min 14 s
• Teleservicios: servicios de telecomunicación que proporcionan la capaci-

dad de comunicación completa entre los usuarios, incluidas las funciones
de los equipos terminales, en funciones de los protocolos acordados en-
tre los operadores de red: telefonía (voz, fax, transmisión de datos), tele-
conferencia (multiparte, llamadas múltiples, llamadas en grupo), servicios
propios UMTS (audio, vídeo, multimedia, emergencia, mensajería, movi-
lidad), servicios multimedia interactivos (IMN: datos, gráficos, imágenes,
audio y vídeo interactivo).
Teleservicios de UMTS
Algunos ejemplos de teleservicios propios de UMTS son: petición de bases de datos, ser-
vicio de listín telefónico, navegación y localización, e-mail, llamadas de emergencia, lla-
madas de emergencia masiva, servicios de mensajería corta (fax, mensajes de voz, co-
rreo electrónico), control de equipos remotamente, telecompra, monitorización de vídeo,
mensajes de voz, paginación, transmisión de audio y vídeo...
Servicio Duración de la llamada Tasa de datos (kbit/s) Error de bit Retardo (ms)
Telefonía 2 min. 8-32 10

-4 40
• Voz 1h 32-128 -4 40
10
• Teleconferencia
Videotelefonía 2 min. 64-348 10

-7 40-90
Videoconferencia 1h 348-768 10
-7 90
Mensajería Sin conexión 1,2-9,6 10

-6 100
• SMS 2 min. 8-32 -4 90
10
• Buzón de voz Sin definir 64 -7
100
• Videomensaje Sin conexión 1,2-64 10 100
-6
• Correo electrónico 10
Bases�de�datos Sin definir 2,4-768 10

-6 200+
Telecompra Sin definir 2,4-768 10

-6 90
Teleacción/control Sin definir 1,2-64 10

-6 100-200
• Servicios�suplementarios: servicios que modifican o complementan un

servicio básico de telecomunicación, como, por ejemplo, la identificación
del número (marcación abreviada, rechazo de llamadas, identificación de

grupos de llamadas), redireccionamiento de llamadas y finalización de las
llamadas, comunicación multiparte (llamadas entre grupos cerrados de
usuarios), tarificación (información adicional sobre la llamada), restricción
de llamadas (rechazo de llamadas entrantes).
• Servicios�de�valor�añadido: servicios adicionales específicos de un usua-

rio, como, por ejemplo, movilidad personal (transferencia de números de
teléfono en cualquier terminal a través de USIM, entorno virtual donde
el usuario puede establecer su propia lista de servicios), ancho de banda
a demanda, utilización eficiente de recursos por servicios que dependen
críticamente de variaciones en la tasa de transmisión MMS y vídeo según
la calidad-precio que desee el usuario...
El virtual home environment (VHE) es el entorno portable de servicios

personales disponibles para el usuario en las diferentes redes y termi-
nales. Los usuarios acceden a las mismas características personalizadas,
interfaz de usuario y servicios particulares con independencia de la red
y el terminal, en cualquier lugar donde esté localizado. Así, los servicios
personalizados incluyen los datos de usuario personalizados, el conjun-
to de servicios integrados desde la perspectiva del usuario independien-
temente de la red de acceso (fija, móvil, inalámbrica...).
Las clases de calidad de servicio en UMTS son:
• Clase�conversacional: permite la conversación en directo (real time) entre

los usuarios. El retardo máximo viene dado por la percepción humana de
audio y vídeo.
• Clase�de�tramas�(streaming): recepción audio y vídeo en un solo sentido.

Conserva la relación temporal entre las entidades (retardo limitado).
• Clase�interactiva: una máquina o un humano recibe datos bajo demanda.

Depende del patrón de interacción y de la carga de datos (por ejemplo,
acceso a web o a una base de datos).
• Clase�de�fondo�(background): el usuario envía y recibe datos en segundo

plano y el destino no espera los datos en un período de tiempo preciso
(correo electrónico, SMS, recepción de registros de datos...).
Los atributos del QoS pueden ser:
(2)
• Tráfico unidireccional/bidireccional. Sigla de unidad de datos del ser-
vicio.
• Clase de tráfico: conversacional, streaming, interactivo, background.
• Tasa binaria máxima (kbps) y tasa binaria garantizada (kbps).
• Orden de envío (sí/no).

• Tamaño máximo de la SDU2 (bytes).
• Información de formato de la SDU (bits).
• Tasa de error de SDU y tasa de error de bit en la SDU.
• Reenvío de la SDU errónea (sí/no).
• Retardo en la transferencia (ms).
• Prioridad de gestión de tráfico.
• Prioridad en la asignación / retención de canal.
• Descriptor estadístico de la fuente.
• Indicación de señalización (sí/no).
Clase de tráfico Conversacional Técnica Interactivo Trasfondo

tramas
Tasa de bits máxima (kbps) <=16.000 <=16.000 <= 16.000 – tiem- <= 16.000 – tiem-
po de sistema po de sistema
Orden de entrega Sí/no Sí/no Sí/no Sí/no
Medida máxima de SDU (unidad de da- <= 1.500 o 1.502 <=1.500 <= 1.500 o 1.502 <= 1.500 o 1.502
tos de servicio) (octetos) o 1.502
Información en formato SDU Sí Sí
Entrega de SDU erróneas Sí/no/– Sí/no/– Sí/no/– Sí/no/–
BER (probabilidad de error de bit) resi-

dual
Porcentaje de errores de SDU
Retraso de transferencia (ms) 100 – valor mínimo 300 – valor

mínimo
Tasa de bits garantizada (kbps) <=16.000 <=16.000
Prioridad de gestión del tráfico 1, 2, 3
Prioridad de asignación/retención 1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3
Descriptor estadístico de origen Habla/desconocida Habla/des-

conocida
Indicación señalizadora Sí/no
El valor añadido de las aplicaciones y servicios sigue las normas de las 4 Qs:
• Cualquier lugar: oficina, casa, carretera y medio de transporte.

• Cualquier red: GSM/GPRS, EDGE, UMTS.
• Cualquier dispositivo: teléfono móvil, PDA, portátil.
• Cualquier situación: negocios, ocio, educación.
Las características clave serán su universalidad, que siempre estará encendido,

su alcance, la personalización, la accesibilidad y la localización.
La evolución de UMTS irá hacia las tecnologías high speed downlink packet ac-
cess (HSDPA) (3,5G y 3,75G) con terminales HSUPA y a los teléfonos de cuarta
generación (4G) para mejorar el rendimiento por el uso simultáneo de aplica-
ciones y aumentar la cobertura de tecnologías 3G, de forma que el rendimien-
to de la red se incremente hasta un 81% con respecto a GPRS y se produzca
una evolución en millones de usuarios los próximos años.
UMTS
1.4.1. Equipos móviles
Para que los usuarios utilicen los servicios 3G hacen falta nuevos teléfonos
y otros terminales capaces de proporcionar los servicios que aquellos desean,
desde la telefonía móvil hasta los multimedia (voz, datos y vídeo).
Los teléfonos móviles UMTS son muy útiles para el viajero y el cosmopolita.
Están diseñados de manera tal que puedan realizar el roaming en otras redes
UMTS (en el supuesto de que su proveedor UMTS se asocie con el proveedor
local UMTS) en diversas zonas del mundo. Además, casi todos los teléfonos
UMTS, a excepción del Japón, son UMTS/GSM de modo dual; eso significa
que durante una llamada, si salimos fuera de los límites de la zona UMTS, la
llamada será transferida por una cobertura GSM.
Teléfono móvil
Los teléfonos UMTS soportan una gran variedad de frecuencias ya que tienen
que poder utilizarse en todo el mundo. Muchos países aportan diferentes fre-
cuencias UMTS. Al igual que las tarjetas SIM para teléfonos GSM, existe la tar-
jeta USIM para los teléfonos UMTS. Parecidas a las tarjetas SIM, las tarjetas
USIM son una forma de identificar y autentificar a nivel local a los clientes
itinerantes. Si las redes UMTS tienen un acuerdo entre ellas, a continuación,
un usuario móvil puede utilizar sus teléfonos UMTS en otra red, aunque los
precios pueden cambiar. Las tarjetas USIM tienen espacio para almacenar los
contactos, mensajes y otra información. De la misma manera que las tarjetas
SIM, las tarjetas USIM también se pueden cambiar de un teléfono a otro, y el
nuevo mantendrá la identificación de la tarjeta.
2. Redes inalámbricas
Las diferentes tecnologías sin hilos (Wireless) se suelen agrupar basándose en

el radio de acción (alcance) de cada una de ellas:
• Redes�personales�sin�hilos�(WPAN,�wireless�personal�area�network). Este
concepto se aplica cuando la distancia que se quiere cubrir es del orden de
unos cuantos metros. La familia de estándares más representativos son el
802.15.1 (Bluetooth), el 802.15.3a (UWB) y el 802.15.4 (Zigbee).
• Redes�locales�sin�hilos�(WLAN,�wireless�local�area�network). Permiten
dar servicios a distancias del orden de un centenar de metros (un piso,
una planta de un edificio, una nave industrial, unas cuantas calles, etc.).
El estándar más destacado en este campo es el 802.11 (WiFi).
• Redes�metropolitanas�sin�hilos�(WMAN,�wireless�metropolitan�area�net-
work). Permiten dar servicios a distancias del orden de unos cuantos kiló-
metros (un barrio, un pueblo, una urbanización...). El estándar más desta-
cado en este campo es el 802.16 (WiMAX).
• Redes�de�gran�alcance�sin�hilos�(WWAN,�wireless�wide�area�network).
Tienen una cobertura más amplia. La familia de estándares más represen-
tativos es la de GSM, GPRS y UMTS.
Clasificación de las tecnologías sin hilos

2.1. Infrarrojos
En el año 1800, Friedrich William Herschel descubrió la radiación infrarroja.

Esta radiación tiene longitudes de onda más largas que la luz visible, pero más
cortas que las microondas. Sus frecuencias son menores que las de la luz visi-
ble y mayores que las de las microondas. La fuente primaria de una radiación
infrarroja es el calor o radiación térmica. Cualquier objeto que tenga una tem-
peratura superior al cero absoluto (-273,15 °C o 0° Kelvin) irradia ondas en la
banda infrarroja.
Ventaja de la luz infrarroja
La luz se ha utilizado como medio de comunicación por su facilidad de producirse y

porque recorre distancias largas a gran velocidad. La ventaja de las ondas infrarrojas,
microondas y hertzianas es que no son visibles para el ojo humano, a pesar de que pueden
servir para la comunicación de información.
Dentro del mundo de las comunicaciones, se utiliza mucho porque hace falta
relativamente poca energía para generarla. Los primeros en utilizarla fueron
los ingenieros de una empresa que comunicaron una calculadora con una im-
presora para imprimir los cálculos que hacía. Otro ejemplo muy cotidiano al
respecto es el mando a distancia del televisor o del reproductor de DVD.
De forma general, podemos definir la comunicación infrarroja como un

haz enfocado de luz en el espectro de frecuencia infrarroja, medido en
terahertz o billones de hercios (ciclos por segundo), donde se modula la
información y se envía de un transmisor a un receptor a una distancia
relativamente corta.
En el año 1993, 50 compañías se unificaron para crear el IrDA, estándares in-

ternacionales para el equipo y los programas utilizados en los enlaces de co-
municación por infrarrojos. La norma "IrDASerial Infrared Data Link Standard
Version 1.1." establece tres niveles que deben cumplir los equipos en las sec-
ciones física, infrared link access protocol (IrLAP) e infrared link management pro-
tocol (IrLMP). Las características de la norma son:
• Bajo coste de implementación.

• Bajos requerimientos de potencia.
• Conectividad direccional, punto a punto.
• Alta inmunidad al ruido.
• Optimización por transferencia de datos.
Los datos informáticos se tratan con numeración binaria, la cual, en la comu- Ejemplo de un puerto IrDA de la placa madre
de un ordenador
nicación infrarroja se codifica como un bit 0 si hay luz, o como un bit 1 si no
hay luz. Podemos ver la comunicación infrarroja como un cable virtual por
el que pasan los datos de un elemento a otro. Este tipo de comunicación que
permite enviar los bits de información uno detrás de otro se llama comunica-
ción en serie.
La capa física tiene un codificador y un descodificador que transforman los

niveles 1 y 0 de la señal binaria en pulsos de duración y formato especificados.
Tiene un transductor (IrTxRx) consistente en un emisor (LED) y un detector
(fotodíode). Un valor binario "0" se representa por un pulso, con una duración
nominal mínima de 1,6 microsegundos y un máximo de 3/16 del período de
bit. Un "1" se representa por la ausencia de pulso.
Esta comunicación exige que el receptor de la información esté a la espera, lo

que implica que el sensor receptor utilice energía para detectar cuando llega
la luz. Por ello los elementos móviles con batería (teléfonos móviles, PDA...)
necesitan activar y desactivar la recepción de datos.
La capa de transporte se define como un flujo de datos serie asincrónica con-

vencional compuesto por sucesivos caracteres, donde cada carácter está com-
puesto por un bit de arranque, 8 bits de datos, sin paridad, y un bit de parada.
(3)
Con respecto al protocolo de enlace, IrDA ha definido y adoptado un proto- High-Level Data Link Control es
3 un protocolo de comunicaciones
colo denominado IrLAP, que es una adaptación del clásico HDLC . Transmite de propósito general punto a pun-
información para pedir una conexión a 9.600 baudios. to.
Las velocidades de transmisión son:
• SIR (Serial IR - 115,2 kbps).

• MIR (velocidad media - 1,152 Mbps).
• FIR (alta velocidad - 4 Mbps).
• VFIR (muy alta velocidad - 16 Mbps).
La comunicación entre el emisor y el receptor que se establece puede ser:
• Una línea recta directa entre el emisor y el receptor (comunicación punto

a punto).
• Si apuntamos a una pared para hacer una "carambola" entre el emisor y el

receptor, establecemos una comunicación cuasidifusa.
• Una comunicación difusa, en la que no hace falta que haya una visión
directa entre emisor y receptor, de manera que los equipos tienen que ser
muy potentes.
2.2. Bluetooth
Actualmente, la tecnología Bluetooth es la tecnología sin hilos más popular. Se Origen del nombre
trata de un protocolo basado en el estándar de comunicaciones IEEE 802.15, Bluetooth
pensado por la transmisión de datos y voz sin hilos entre dispositivos, me- El nombre Bluetooth tiene su
diante una radiofrecuencia. Al inicio del desarrollo de los productos Bluetooth origen en el rey danés Harald
Blatand (Harold Bluetooth en
de primera generación, se tuvo en cuenta lo siguiente: inglés) que unificó los pueblos
de Dinamarca, Noruega y Sue-
cia, que antes estaban en gue-
• El sistema tenía que ser universal. rra.
• El emisor había de consumir poca energía, ya que se usaba en equipos que

funcionan con batería.
• La conexión debía permitir la transmisión de datos y voz (aplicaciones

multimedia).
• Tenía que ser de bajo coste (el objetivo fue unos cuantos dólares para cada
dispositivo).
De acuerdo con estos requisitos, Ericsson desarrolló en 1994 una tecnología

que utiliza un canal de comunicación con un máximo de 720 Kb/s (1 Mbps
de velocidad bruta), con un rango óptimo (opcionalmente de 100 metros con
repetidores).
En 1999 se creó el SIG (grupo de interés especial) de Bluetooth, formado por las
empresas Ericsson, Intel, IBM, Toshiba y Nokia. Este SIG trabaja para definir,
desarrollar, promover y publicar el protocolo Bluetooth. Actualmente, este SIG
tiene más de 9.000 miembros.
Esta tecnología es propietaria, es decir, que sólo puede producirla quien tie-
ne la patente. Por eso sólo puede introducir esta tecnología en sus productos
quien pertenece al SIG de Bluetooth. Actualmente, la velocidad máxima de
transmisión oscila entre 1 Mbps y 3 Mbps.
Difusión de la tecnología Bluetooth
Actualmente existen muchos dispositivos electrónicos que incorporan el protocolo Blue-

tooth: auriculares con micrófono, ordenadores, PDA, ratones, teléfonos móviles, impre-
soras, gafas Oackley, cámaras fotográficas, teclados, otros dispositivos de entrada de or-
denadores, etc. Logotipo de Bluetooth
Los sectores industriales en los que se utiliza son: automoción, aeronáutica, naval, otros
transportes, bienes de equipo mecánico, eléctrico, electrodomésticos, ordenadores, equi-
pos de oficina, hogar, telecomunicaciones y equipos electrónicos y otros segmentos in-
dustriales. En el sector servicios tenemos: los financieros, contenidos y ocio, administra-
ción y servicios públicos, servicios privados para empresas.
Esta tecnología representa una ventaja con respecto a la tecnología de comu-

nicación por infrarrojos ya que no hace falta que los dispositivos tengan que
verse directamente para comunicarse (como ocurre con un mando a distancia
y un aparato de televisión por infrarrojos).
Brevemente, los servicios de las conexiones Bluetooth que actualmente se sue-

len ofrecer en algunos sistemas operativos como Windows o Linux:
• Transferencia�de�elementos�del�PIM: permite que los dispositivos Blue-

tooth remotos intercambien tarjetas de visita con este equipo, para aceptar
elementos del personal information manager (PIM) con elementos de calen-
dario, contactos, notas y mensajes de los Bluetooth remotos.
• Sincronización�del�PIM: permite que los dispositivos Bluetooth remotos

sincronicen una base de datos PIM con las del PIM del equipo.
• Transferencia�de�archivos: permite que los dispositivos Bluetooth remo-

tos realicen operaciones de archivo en un directorio específico en este equi-
po y en los subdirectorios y archivo de este directorio.
• Acceso�a�la�red: permite que los dispositivos Bluetooth remotos compar-

tan la conexión a la red de este equipo, que puede ofrecer acceso a Internet.
• Acceso�telefónico�a�redes: en este caso se puede utilizar para acceder des-

de un ordenador a Internet a través de un teléfono móvil. El teléfono mó-
vil accede a Internet por GPRS, y la conexión móvil-ordenador se hace por
Bluetooth. El ordenador ve el teléfono móvil como si fuera un módem
clásico conectado directamente al ordenador (a pesar de que la comuni-

cación entre los dos dispositivos sea inalámbrica). El ordenador crea una
conexión a Internet a través del "módem" mediante el protocolo PPP con
el operador del servicio de Internet (operador de telefonía móvil).
• Puerto�serie�Bluetooth: permite que los dispositivos Bluetooth remotos

se conecten al equipo a través de un puerto serie inalámbrico.
• Fax: permite que los dispositivos Bluetooth remotos utilicen las opciones
del equipo para enviar un fax.
• Pasarela�de�audio: permite que los dispositivos Bluetooth remotos, como

unos auriculares, reemplacen el micrófono y los altavoces del equipo.
• Auriculares: permite que los dispositivos Bluetooth remotos, como un te-

léfono móvil, utilicen el micrófono y los altavoces de este equipo con dis-
positivos propios de entrada y salida. De hecho, cuando este servicio está
conectado, el equipo se convierte en los auriculares del dispositivo remoto.
El sistema Bluetooth consiste en un transmisor de radio, una banda frecuencial

de transmisión y una serie de protocolos de comunicaciones (físico, enlace,
lógico).
En muchos casos se ha desarrollado un chip CMOS que gasta mucha menos

energía que un teléfono móvil (un 97% aproximadamente), controla la emi-
sión de radio y una parte que controla digitalmente las señales recibidas. Los
valores típicos de consumo se muestran en la siguiente tabla.
Modo Potencia
En espera Menos de 0,3 mA
Voz 8 a 30 mA
Datos 5 mA (media)
mA = miliamperio
Bluetooth emite a la frecuencia de 2,4 GHz, que es una banda base, es decir,
que no interfiere las frecuencias utilizadas para la industria, la ciencia y la
medicina. Como se verá posteriormente, en este aspecto es bastante parecido
a un sistema WiFi.
El sistema tiene un transmisor de saltos de frecuencia, que consiste en una

técnica de modulación en la que la señal se emite sobre una serie de frecuencias
aparentemente aleatorias. De esta manera, los receptores no autorizados sólo
ven una señal ininteligible.
Cuando tenemos diversos dispositivos sincronizados por un reloj y una

secuencia de saltos de frecuencia, también comparte el mismo canal fí-
sico de radio. Uno de ellos proporciona estos valores de referencia (sin-
cronización y saltos de frecuencia) y se denomina dispositivo�maestro,
mientras que los otros se llaman dispositivos�esclavos.
Pequeña red Bluetooth
Bluetooth permite conexiones punto a punto, y punto a multipunto. Cuando

tenemos un maestro y uno o varios esclavos, creamos un piconet. Un disposi-
tivo maestro sólo puede pertenecer a una piconet, mientras que un dispositivo
esclavo se puede conectar a varias piconets al mismo tiempo (red dispersa).
Una red Piconet Bluetooth

Una red scatternet Bluetooth
Dentro de una piconet, cada dispositivo esclavo se conecta al dispositivo mas-

ter por un canal físico. Cada uno de estos canales físicos se divide en slots. Los
paquetes que viajan entre el master y el esclavo están colocados dentro de estos
slots. Los canales físicos no se crean entre los esclavos. Todas las transmisiones
de paquetes son gestionadas y controladas por el dispositivo master. El master,
de manera secuencial, autoriza cada dispositivo para ver si requiere su servi-
cio. El dispositivo master es el responsable de sincronizar todos los dispositivos
para asegurar un cierto ritmo de transmisión de la información.
Un dispositivo que se une a una piconet lo puede hacer de dos maneras. En la

primera, el dispositivo empieza a descubrir todos los otros dispositivos blue-
tooth dentro de su radio de acción y a proporcionar información con respecto
al tipo de servicio que necesita. Los dispositivos que ofrecen uno o más de los
servicios demandados responden al dispositivo que demanda el servicio. En

la segunda manera, el master busca dentro de su radio de acción, y, una vez
descubiertos los dispositivos, éstos son añadidos automáticamente a la pico-
net de acuerdo con las medidas de seguridad que tienen tanto el master como
el esclavo.
Distancia entre dispositivos
La distancia entre dos dispositivos para establecer un canal de comunicación depende

de la clase de potencia emitida. Actualmente existen tres clases de potencia según que
la distancia sea de:
1) Menos de 10 metros.
2) Aproximadamente 10 metros.
3) Aproximadamente 100 metros.
El protocolo Bluetooth establece tres niveles de seguridad:
• Nivel�1:�no�hay�seguridad. El dispositivo funciona en modo promiscuo,

permitiendo que cualquier otro equipo Bluetooth se conecte al dispositivo.
• Nivel�2:�seguridad�a�nivel�de�servicio. Soporta autoidentificación, encrip-

tación y autorización una vez se ha establecido el canal de comunicación.
• Nivel� 3:� seguridad� a� nivel� de� enlace. Las medidas de seguridad se im-
plantan antes de que el canal de comunicación se haya establecido. Pro-
porciona encriptación y autoidentificación.
Para configurar los dispositivos, en primer lugar hay que establecer un SSID
(identificador) del dispositivo.
Al encontrar los dispositivos, se establece un protocolo de seguridad basado en

un código. Este código puede ser de cuatro cifras o una frase larga. El código
se comprueba en el dispositivo maestro y en el dispositivo esclavo. Si es el
mismo, entonces se establece el acoplamiento y empieza el intercambio de
información.
Esta tecnología también sufre ataques a la seguridad, y por eso tenemos que
saber cuáles son y cómo se pueden detectar. Las empresas sacan mejoras (ac-
tualizaciones) para evitar estos ataques a sus productos:
• Bluejacking: permite enviar datos en forma de texto a un móvil. Este pro- Bluetooth y red local
cedimiento no modifica ningún dato, pero quien recibe este ataque puede
Los dispositivos Bluetooth per-
llegar a pensar que tiene un virus en su dispositivo. miten integrarse dentro de
una red de área local y acceder
a la memoria de éstos como si
• Bluebugging: permite ejecutar pedidos en un teléfono móvil sin que el fuera un recurso de red local.
propietario reciba ningún aviso. El atacante puede hacer llamadas, enviar
mensajes y otras acciones.
• Bluesnarfing: permite acceder a datos internos del teléfono, leerlos o mo-

dificarlos. Sólo afecta equipos antiguos.
• Car�whisperer: permite el acceso a un teléfono de manos libres de coche,

y por lo tanto, escuchar llamadas o el micrófono, o enviar sonido al dis-
positivo.
• Cabir�worm: programa gusano que, al instalarse en un teléfono, se copia

en otros teléfonos. Sólo afecta al sistema operativo Symbian OS.
• Denial� of� service� (DoS): consiste en denegar el servicio de Bluetooth al

usuario, cosa que obliga el aparato a apagar el servicio.
2.3. ZigBee
ZigBee es el nombre de la especificación de un conjunto de protocolos

de alto nivel de comunicación inalámbrica para su utilización en radio
digital de bajo consumo, basado en el estándar WPAN IEEE 802.15.4.
Su objetivo son las aplicaciones que requieren comunicaciones seguras
con baja tasa de envío de datos y maximización de la vida útil de las
baterías.
La tecnología ZigBee se diferencia por su bajo consumo, su topología de red

en malla, y su integración fácil (se pueden fabricar nodos con muy poca elec-
trónica).
La relación entre IEEE 802.15.4-2003 y ZigBee es parecida a la existente entre

IEEE 802.11 y WiFi Alliance. La especificación 1.0 de ZigBee se aprobó en el
2004 y está disponible en miembros del grupo de desarrollo (ZigBee Alliance).
Un primer nivel de suscripción, llamado adapter, permite la creación de pro-
ductos para su comercialización adoptando la especificación por un determi-
nado precio. Esta especificación está disponible al público para fines no co-
merciales. Con el tiempo, se han ido creando nuevas versiones de la especifi-
cación original. En diciembre del año 2006 se publicó la especificación actual.
Comercialización de productos ZigBee
ZigBee tiene los módulos transmisores inalámbricos más baratos de la historia, y produ-
cidos de manera masiva. Tendrán un coste aproximado de 6 euros, y dispondrán de una
antena integrada, control de frecuencia y una pequeña batería.
ZigBee utiliza la banda de frecuencias ISM para usos industriales, científicos y

médicos. En concreto, en Europa utiliza la banda de 868 MHz. También mu-
chas empresas optan por la banda de 2,4 GHz disponible en todo el mundo. El
desarrollo de esta tecnología se basa en su sencillez y bajo coste. Un nodo Zig-

Bee más completo requiere menos del 10% del hardware que necesita un nodo
Bluetooth (requiere muchos menos circuitos analógicos de lo que es habitual).
Los protocolos ZigBee están definidos para su uso en aplicaciones encastadas

con requerimientos muy bajos de transmisión de datos y consumo energético.
Se pueden utilizar para realizar un control industrial, albergar sensores empo-
trados, recolectar datos médicos, detectar humo o intrusos y en domótica o
teleasistencia. Una red en su conjunto utilizará una cantidad muy pequeña de
energía, de forma que cada dispositivo individual pueda tener una autonomía
de hasta cinco años antes de necesitar un recambio en su sistema de alimen-
tación.
Ejemplo de una aplicación domótica con ZigBee
Las desventajas de ZigBee son: tasa de transferencia muy baja, sólo manipula
textos pequeños en comparación con otras tecnologías, trabaja de manera que
no es compatible con Bluetooth porque no llega a tener las mismas tasas de
transferencia, ni la misma capacidad de soporte para nodos, tiene una menor
cobertura porque pertenece a redes sin hilos del tipo WPAN.
Una red ZigBee puede constar de un máximo de 65.535 nodos distribuidos en

subredes de 255 nodos (frente a los 8 nodos máximo de una subred Piconet
Bluetooth). Puede alcanzar una velocidad de 250 Kbps y se utiliza en aquellas
aplicaciones donde la transferencia de datos es baja (artículos de juguetería,
detectores...) frente al Bluetooth, que se suele utilizar en teléfonos móviles o
dispositivos de entrada/salida en equipos informáticos en los que se requie-
re una velocidad de transmisión mayor. Provee conexiones seguras entre los
dispositivos. Los dispositivos ZigBee son muy baratos y de construcción muy
sencilla.
En una red ZigBee existen tres tipos de dispositivos:

1)�Coordinador�ZigBee�(Coordinator,�ZC). El tipo de dispositivo más com-

pleto. Tiene que existir uno por cada red. Sus funciones son las de encargarse
de controlar la red y los caminos que tienen que seguir los dispositivos para
conectarse entre ellos. Requiere de memoria y capacidad de computación.
2)�Router�ZigBee�(ZR). Interconecta dispositivos separados en una topología

de la red. Ofrece un nivel de aplicación para ejecutar un código de usuario.
3)�Dispositivo�final�(End�Device,�ZED). Tiene la funcionalidad necesaria de

comunicarse al nodo padre (el coordinador o el router) pero no puede trans-
mitir información destinada a otros dispositivos. De esta manera, este tipo de Coordinador ZigBee
nodo puede estar dormido la gran mayoría de tiempo, lo que aumenta la vida
media de sus baterías. Un ZED tiene unos requerimientos mínimos de memo-
ria y por eso es significativamente muy económico.
Ejemplo de instalación ZigBee
En el caso de una aplicación domótica, en una habitación de la casa tendríamos diversos

dispositivos finales (un interruptor y una lámpara) y una red de interconexión realizada Routers ZigBee
con routers ZigBee y gobernada por el coordinador.
Si nos basamos en la funcionalidad, se puede plantear una segunda clasifica-

ción de los dispositivos ZigBee:
• Dispositivo�de�funcionalidad�completa�(FFD): también conocido como

nodo activo. Puede recibir mensajes en formato 802.15.4. Puede funcionar
como router o como coordinador, o se puede utilizar en dispositivos de
red que actúen de interfaz con los usuarios.
• Dispositivo�de�funcionalidad�reducida�(RFD): también conocido como

nodo pasivo. Tiene unas capacidades y funcionalidades limitadas (especi-
Dispositivo final
ficadas en el estándar) con el objetivo de conseguir un bajo coste y una
gran simplicidad. Básicamente son los sensores y actuadores de la red.
Un nodo ZigBee, tanto activo como pasivo, reduce su consumo gracias

a que puede estar dormido la mayor parte del tiempo (incluso muchos
días seguidos). Cuando se requiere su uso, el nodo ZigBee es capaz de
despertar en un tiempo muy reducido y dormir otra vez cuando no lo
necesiten. Un nodo cualquiera despierta aproximadamente en 15 mili-
segundos.
ZigBee permite tres topologías de red:
1)�Topología�en�estrella: el coordinador se sitúa en el centro.
2)�Topología�en�árbol: el coordinador será la raíz del árbol.

3)�Topología�en�malla: al menos uno de los nodos tendrá más de dos cone-

xiones.
La topología más interesante es la topología en malla. Permite que, si en un

momento determinado un nodo del camino falla y se cae, se pueda realizar la
comunicación entre todos los otros nodos debido a que se rehacen todos los
caminos. La gestión de los caminos la realiza el coordinador.
La seguridad de las transmisiones y los datos son puntos clave en la tecnología

ZigBee. Ésta utiliza el modelo de seguridad de la subcapa MAC IEEE 802.15.4,
la cual especifica cuatro servicios de seguridad:
1) control de accesos (el dispositivo mantiene una lista de los dispositivos com-
probados por la red),
2) datos encriptados (se usa la encriptación con un código de 128 bits),
3) integración de tramas (los datos se protegen para que no sean modificadas

por otros), y
4) secuencia de refresco (se comprueba que las tramas no han sido reemplaza-
das por otras). El controlador de red comprueba estas tramas de refresco y su
valor, para ver si son las esperadas.
2.4. WiFi
Últimamente se habla mucho del WiFi, una tecnología inalámbrica que en Nombre "Wifi"
sus distintas versiones (802.11a, b y g) puede ofrecer desde 11 Mbits/s hasta
El nombre Wifi corresponde a
54 Mbits/s, y tiene distintas aplicaciones, especialmente en entornos locales las siglas de Wireless Fidelity, y
(de corta distancia) como aeropuertos, hoteles, estaciones de servicio, centros se refiere a los procedimientos
utilizados para las comunica-
comerciales, convenciones, pequeños pueblos..., en los que se ofrece acceso ciones de redes locales (distan-
cias cortas) sin hilos (wireless
a Internet. local area network o WLAN).
En Wi-Fi se utilizan las ondas portadoras de radio para transmitir la informa-

ción. Los datos se superponen a la onda portadora de radio y se pueden extraer
en el receptor final en un proceso conocido como modulación/demodulación.
Un access point (AP) es el dispositivo que hace de puente entre una red
cableada y una red inalámbrica. Podemos pensar que, de alguna mane- Logotipo de Wifi
ra, es la antena a la que nos conectamos.
Si las ondas se transmiten a diversas frecuencias, puede haber varias ondas

portadoras de radio al mismo tiempo, sin que se interfieren unas con otras.
Los puntos de acceso (access point) reciben la información, la guardan, y la
acces points
retransmiten entre la red sin hilos y la red cableada. Si los dispositivos WiFi se
comunican sin ningún punto de acceso, sino entre ellos, crearemos una red
llamada ad hoc.
Topología simple ad hoc (sin punto de acceso) y topología con un solo punto de
acceso (BSS)
Topología más compleja: red cableada y puntos de acceso inalámbricos

El IEEE 802 es un comité y grupo de estudio de estándares que pertenece al

Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) que actúa sobre redes
de ordenadores. La especificación concreta del sistema WiFi es la IEEE 802.11.
Además de estas velocidades, el alcance de las comunicaciones puede llegar

a varios centenares de metros en espacios abiertos. Continuamente aparecen
equipos que pueden llegar a distancias cada vez más largas.
Los estándares IEEE 802.11b y 802.11g utilizan la banda de frecuencias de 2,4

a 2,5 GHz. En Europa, el ETSI (Instituto Europeo de Normas de Telecomunica-
ciones) ha definido trece canales dentro de esta banda de señal. Pero no se uti-
lizan todos, porque se suplantan y producen interferencias. Los más utilizados
son los canales 1, 4, 9 y 13, ya que no son adyacentes y no reciben interferen-
cias. Esta configuración sólo se hace habitualmente en el punto de acceso, ya
que los dispositivos clientes detectan la señal. Para utilizar estas frecuencias no
hace falta ninguna autorización (o licencia) de la administración competente,
y por lo tanto, es una tecnología muy utilizada en entornos locales como edi-
ficios, oficinas, hospitales...
Red WiFi doméstica
Los elementos que se necesitan para crear una red en casa sin cable son un punto de ac-
ceso, para conectar al encaminador (router), y un dispositivo WiFi, para conectar a nues-
tro ordenador. Un punto de acceso es un dispositivo encargado de conectar dispositivos
WiFi para crear una red sin hilos. Habitualmente, también disponemos de un conector
para red con cable y podemos conectar la red sin cable con la red cableada. Muchos de los
encaminadores actuales ya llevan incorporado el punto de acceso, y ofrecen tres servicios
en un solo equipo: red sin hilos, red con hilos y encaminador a Internet. En el equipo
encaminador encontramos la antena, que sirve para las comunicaciones sin cable; los
cuatro puertos para la red Ethernet (de color amarillo habitualmente) y finalmente, el
puerto de comunicación con Internet.
Si conectamos muchos puntos de acceso entre sí, el alcance de la red sin

hilos aumentará. Esta acción se conoce como itinerancia, o en inglés,
roaming.
Para establecer comunicación con el punto de acceso nuestro ordenador nece-

sita un dispositivo WiFi. Este dispositivo sirve para recibir y enviar las ondas de
radio donde está la información. Actualmente muchos ordenadores ya llevan
integrado el dispositivo WiFi dentro de la placa madre. En los modelos más
antiguos que no lo llevan incorporado se puede conectar al ordenador con tres
elementos: tarjetas PCI, tarjetas PCMCIA y tarjetas USB.
Existe una amplia variedad de antenas:
• Omnidireccionales. Tienen poco alcance, pero permiten un radio de co-

bertura de 360°, unos 300 metros en el exterior.
• Unidireccionales. Tienen más alcance, pero sólo en una sola dirección.
Una vez se ha establecido comunicación entre una tarjeta sin cable y otro
dispositivo, la tarjeta se comporta como cualquier tarjeta Ethernet cableada y
se tiene que configurar como tal.
Para poder establecer la conexión entre un punto de acceso y un dispositivo

WiFi hace falta configurar primero el punto de acceso. Cada punto de acceso
tiene su propia configuración, y actualmente se configuran con un entorno
gráfico al que se accede con el protocolo web. Cuando iniciamos por primera
vez un punto de acceso, el dispositivo tiene unos parámetros de configuración
básicos que pueden no satisfacer nuestros intereses. Muchos de estos paráme-
tros se pueden cambiar. El más importante es el serie set identifier (SSID): indi-
ca el identificador del servicio, y es el código (o nombre) que se incorpora a
todas las comunicaciones sin cable para identificarlas como parte de la red (es
el nombre que aparece cuando desde un ordenador se realiza la función de
buscar redes inalámbricas). También se lo conoce como nombre de la red. El
punto de acceso, para identificarse, emitirá señales con este parámetro. Tam-
bién con el entorno gráfico se puede modificar el canal en el que emitimos la
señal de onda portadora de radio. Habitualmente no cambiaremos este pará-
metro, pero si decidimos hacerlo, seguiremos las recomendaciones del ETSI.
Una de las cosas más importantes que se tiene que configurar es la seguridad
de la comunicación para poder dar acceso a nuestra red sin hilos a los equipos
o personas que queramos.
El�cifrado�WEP (Wireless Encryption Protocol) codifica la información que

viaja por el aire de cada trama de datos enviados por el adaptador mediante
unas claves (64, 128 y 256 bits).
Existe otro tipo de cifrado, el WPA (WiFi Protected Access), que proporciona
más seguridad que el WEP; además, facilita la autoidentificación del usuario
(exige una clave y una contraseña para entrar dentro de la Red, y codifica la
información transmitida por el aire).
Para la mayoría de redes pequeñas, la encriptación WAP es la manera más

sencilla de tener una seguridad efectiva. De las tres opciones, la PSK String es
la mejor para implantar.
Estándar Ancho Consumo de potencia Ventajas Aplicaciones

de banda
Wi-Fi Hasta 54 400 mA transmitiendo Gran ancho de banda Navegar por Internet, red de ordenadores,
Mbps transferencia de ficheros
Bluetooth 1 Mbps 40 mA transmitiendo Interoperatividad, sustituto del USB sin hilos, móviles, informática casera
cable
ZigBee 250 kbps 30 mA transmitiendo, 3 mA Batería de larga duración, bajo Control remoto, productos dependientes
en reposo coste de la batería, sensores, juegos
-3
1mA = 10 amperios
2.5. WiMax
Actualmente hay una gran demanda de servicios de acceso de banda ancha

(altas velocidades de transmisión) en Internet y otras aplicaciones de voz y da-
tos. De manera cableada actualmente se ofrecen servicio con las líneas ADSL, y
de manera inalámbrica WiMax es la solución que sirve tanto a los operadores
de telecomunicaciones como a los usuarios. Con WiMax se está creando un
mercado masivo de soluciones inalámbricas.
Un nuevo estándar WMAN de banda ancha apareció promovido y desarrolla-

do por el grupo WiMax (wireless interoperability for microwave access) –acceso
inalámbrico de banda ancha–, que tiene dos miembros muy representativos,
como Intel y Nokia. La etiqueta WiMax está asociada globalmente al propio
nombre del estándar IEEE 802.16. La tecnología WiMax supone una evolución
con respecto al WiFi. Permite la conectividad entre puntos fijos, nómadas y
móviles, y eventualmente la conectividad móvil sin necesidad de tener una
línea punto a punto con una estación base.
Haciendo una analogía, WiMax es al estándar IEEE 802.16 lo que Wifi al es-
tándar IEEE 802.11.
Wimax Forum
El Wimax Forum es una agrupación de más de 350 compañías que se encarga de promo-
ver la interoperabilidad de dispositivos 802.16 y la unificación de los estándares a nivel
mundial. Incluye fabricantes de chips y de equipos y empresas que ofrecen servicios. Wi-
max Forum promueve la utilización del estándar IEEE 802.16, la certificación de equipos,
la interoperabilidad de Wimax entre diferentes marcas y la conformidad verificada en
laboratorios autorizados.
WiMax utiliza bandas de frecuencia con y sin licencia gubernamental. La ban-

da que no necesita ninguna autorización administrativa está entre 2,4 y 5 GHz.
Estas bandas se tienen que utilizar con mucha cautela, ya que existe la posibi-
lidad de una gran interferencia. En algunos países todavía no se han asignado
las bandas WiMax.
La norma inicial IEEE 802.16, publicada en diciembre del 2001, sirvió para
fomentar la operatividad entre los sistemas local multipoint distribution system
(LMDS). Inicialmente, el rango de frecuencias era entre 10 y 66 GHz con ne-
cesidad de visión directa (entre emisor y receptor). A principios del 2003, con
la aparición del 802.16a para ratificar el estándar inicial 802.16, se amplió el
rango de frecuencias hacia las bandas de 2 a 11 GHz. En el año 2004 aparece el
estándar 802.16-2004 o IEEE 802.16d, también conocido como WiMAX, para
cubrir las carencias del IEEE 802.16a.
En resumidas cuentas, existen dos estándares, IEEE 802.16d para WiMax

fija, y IEEE 802.16e para WiMax móvil.
802.16 802.16a 802.16e
Espectro 10-66 GHz < 11 GHz < 6 GHz
Funciona- Sólo con vi- Sin visión directa (NLOS) Sin visión directa (NLOS)
miento sión directa
Ancho 32-134 Mbps Hasta 75 Mbps con Hasta 15 Mbps con canales de 5 MHz
de�banda canales de 20 MHz
Modu- QPSK, 16QAM OFDM con 256 Mismo que 802.16a

lación y 64 QAM subportadoras
Movilidad Sistema fijo Sistema fijo Movilidad pedestre
Ancho�del 20, 25 y Selección entre El mismo que 802.16a con los cana-
espectro 28 MHz 1,25 y 20 MHz les de subida para ahorrar potencia
Distancia 2-5 km aprox. 5-50 km aprox. 2-5 km aprox.
Hay que mencionar la aparición del equipamiento denominado pre-WiMAX.

Muchos fabricantes no esperaron a la aprobación definitiva del estándar
802.16, y decidieron sacar al mercado (y todavía lo siguen haciendo actual-
mente) equipos que implementan un protocolo propietario basado en los de-
sarrollos realizados para la tecnología WiMAX. Estos dispositivos, a pesar de
proporcionar altas prestaciones, no permiten interoperabilidad con los otros
fabricantes. Pero, en cambio, trabajan en bandas de frecuencia libre (sin licen-
cia), de manera que han acabado siendo una buena opción (y muy utilizada)
para despliegues en este tipo de entornos.
Con respecto a velocidades, hay que diferenciar entre la velocidad de trans-

misión en el aire y la velocidad real (conocida como throughput). En el caso
concreto de WiMAX y pre-WiMAX, la velocidad de los equipos es ligeramente
diferente:
Velocidades pre-WiMAX / WiMAX
Tecnología Velocidad máxima aire Velocidad máxima real
pre-WiMAX 54 Mbps ~30 Mbps
WiMAX 70 Mbps ~40 Mbps
Sus principales características se resumen a continuación:
• Modulación� adaptativa: se escogen dinámicamente en función de las

condiciones del enlace, si éste tiene un buen comportamiento (pocas pér-
didas), se utiliza una modulación que más bits y, por lo tanto, la velocidad
aumenta. En función de la distancia de la estación a la estación base se
utiliza un tipo de modulación u otra: 64QAM, 16QAM, QPSK...
• Banda�frecuencial: se puede trabajar en banda libre de 5,4 GHz, pero con

poca potencia y con visión directa. También hay banda licenciada (hace
falta un permiso de la administración para utilizar una determinada fre-
cuencia) en 3,5 GHz, donde no es imprescindible la visión directa.
• Elementos: hay dos tipos de componentes, la estación base (unidades de

acceso, AU) y las unidades de abonado (SU).
• Perfiles: permiten enlaces punto a punto (con visión directa) y punto mul-
tipunto (sin necesidad de visión directa).
• Permite�calidad�de�servicio�(QoS): gracias al hecho de que WiMAX es-

tá orientado a la conexión. También ofrece la especificación antes de la
transmisión de la calidad de servicio demandada (QoS): por ejemplo, la
voz y el vídeo requieren una baja latencia (retraso), pero soportan bien la
pérdida de un poco de información, mientras que las aplicaciones de datos
tienen que estar libres de errores pero toleran bien el retraso.
• Usuarios: soporta varios centenares de usuarios por canal.
WiMax ofrece varios cualidades de servicio:
• Unsolicited�grant�service�(UGS): tráfico de velocidad constante (constant

bit rate), datos en tiempo real con paquetes de tamaño fijo: VoIP sin su-
presión del silencio.
• Real-time�polling�service�(rtPS): datos en tiempo real con paquetes de ta-

maño variable generados en intervalos periódicos, como los paquetes de
vídeo Moving Picture Expert Group (MPEG).
• Extended�real-time�polling�service�(ertPS): es una optimización de UGS y

rtPS: datos en tiempo real con paquetes de tamaño variable generados en
intervalos periódicos, tal como los VoIP con supresión de silencio.
• Non-real-time�polling�service�(nrtPS): soporta datos que toleran retardos

como la transferencia de archivos (FTP: file transfer protocol).
• Best�effort�(BE): diseñado para soportar tráfico para el que no se ha de-

finido ningún tipo de nivel de QoS, tal como la navegación a través de
Internet.
Ofrece la posibilidad de formar redes en malla (mesh networks) para que los
distintos usuarios se puedan comunicar entre sí, sin necesidad de tener una
visión directa entre ellos.
Las primeras versiones de WiMax fueron pensadas para comunicaciones pun-

to a punto, o punto a multipunto típicas de radioenlaces por microondas. Las
futuras redes ofrecerán total movilidad y podrán competir con las redes celu-
lares. WiMax es adecuado para unir puntos con mucho tráfico de información
WiFi a las redes de los operadores de telecomunicaciones sin necesidad de es-
tablecer un enlace fijo. WiMax amplía la cobertura de una red WiFi y puede
proveer una alternativa seria o complemento a las redes 3G.
Topología red WiMAX

WiMax soporta las llamadas antenas inteligentes (smart antennas) propias de

las redes celulares en 3G. Estas antenas inteligentes emiten un haz de radiación
muy estrecho que se puede ir moviendo electrónicamente para enfocar siem-
pre al receptor, con lo que evitan las interferencias entre canales adyacentes y
se consume menos potencia para tener el haz más concentrado.
Otra aplicación es la de ofrecer servicios a las zonas rurales de difícil acceso,

a las que no llegan las redes cableadas. Es una tecnología muy adecuada para
establecer radioenlaces, debido a su gran cobertura y capacidad, y a un coste
muy competitivo frente otras alternativas.
La instalación de estaciones base WiMax es sencilla y económica, utilizando

un hardware que llegará a ser estándar.
Diferentes fases de WiMax
A la izquierda, estación de usuario acceso fijo. A

la derecha, estación base acceso fijo.
WiMax móvil y IEEE 802.16e, soportan varias tecnologías de antenas inteli-

gentes:
• Beamforming.
• Space-time code (STC).
• Multiplexación espacial.
En definitiva, WiMax nos ofrece un ancho de banda para equipos fijos

y móviles, puede coexistir junto con WiFi y 3G, soporta aplicaciones
basadas en IP (datos, Internet, VoIP, etc.), garantiza la seguridad y la
calidad del servicio, y tiene diferentes sectores en el mercado.
Más de 250 operadores han realizado pruebas en más de 65 países, tal como
se ve en la figura siguiente.
Comparativa de WiMAX con otras tecnologías
WiMAX 802.16 WiFi 802.11 MBWA 802.20 UMTS y CD-

MA2000
Velocidad 124 Mbit/s 11-54 Mbit/s 16 Mbit/s 2 Mbit/s
Cobertura 40-70 km 300 m 20 km 10 km
Licencia Sí/No No Sí Sí
Ventajas Velocidad y exten- Velocidad Velocidad y Rango y

sión geográfica y precio movilidad movilidad
Inconve- Interferencias Baja cobertura Precio alto Lento y caro

nientes
Resumen
En este módulo hemos visto la evolución histórica de la telefonía móvil, su

crecimiento exponencial en número de usuarios a escala mundial, y cómo esta
tecnología y sus aplicaciones han evolucionado en muy pocos años. Se ha pa-
sado básicamente de sólo poder transmitir mensajes de texto con la tecnología
móvil GSM, a mejorar las conexiones a Internet con la tecnología GPRS, para
acabar en las últimas aplicaciones totalmente multimedia sobre tecnologías
EDGE y UMTS por el considerable aumento de las velocidades de transmisión
y de sus coberturas.
En el ámbito de las redes inalámbricas se han visto las de uso más cotidiano, las
redes WiFi para aplicaciones de alcance local (vivienda, oficina), con distan-
cias entre los equipos pequeñas (varios centenares de metros). Para incremen-
tar la distancia entre los equipos (varios kilómetros) se ha desarrollado la tec-
nología inalámbrica WiMax. Además, para interconectar dispositivos en muy
poca distancia se utiliza la tecnología infrarroja y la bluetooth. Finalmente,
para instalar redes de sensores donde el consumo es el factor principal a tener
en cuenta, existe la tecnología ZigBee para que las baterías de estos sensores
tengan una larga duración.
Bibliografía
Abad, F. J.; Canudas, J. M.; Martínez, R.; Nogueira, E. (2008). Informàtica 4t. ESO.
Barcelona: Teide. ISBN: 978-84-307-8685-5.
Direcciones web
Bluetooth. Disponible en web:

<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 Politécnica de Madrid. "Comunicaciones móviles 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 España. Disponible en web:

<http://www.zigbee.es>. [Fecha de consulta: 13 de abril del 2010.]

Redes Multimedia PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Redes Multimedia PDF

Transféré par

Droits d'auteur :

Formats disponibles

Redes multimedia

Xavier Vilajosana Guillén (coordinador)

Xavier Vilajosana Guillén Miquel Font Rosselló Silvia Llorente Viejo

Joan Manuel Marqués Puig

Doctor en Informática, especializa-

Primera edición: septiembre 2010

La asignatura Redes multimedia pretende dar una visión global e introductoria

El módulo "Conceptos de redes de computadores" introduce los principales

El módulo "Seguridad en la Red" complementa al resto y presenta los conceptos

Por último, el módulo "Comunicaciones sin hilos" concluye el curso explican-

El estudio de los materiales didácticos de esta asignatura os ha de permitir

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

2. Conocer los principales protocolos de nivel aplicación, entender su fun-

4. Tener conocimiento de los conceptos principales que rigen la comunica-

11. Protocolos para aplicaciones interactivas en tiempo real

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

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

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

9. Breve historia de las comunicaciones.......................................... 44

Las redes de ordenadores actuales son una composición de dispositivos, téc-

Dedicaremos este módulo a introducir las ideas y los conceptos básicos de

El módulo profundiza en la definición de una red de computadores y nos pre-

Veremos que en un principio se definió una jerarquía llamada Open Systems

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

2. Conocer los componentes de una red de computadores, tanto los de hard-

3. Conocer la arquitectura de una red de computadores, la separación por

4. Saber diferenciar las redes por su alcance.

5. Tener una visión general de la evolución de las redes de computadores

1. Conceptos de redes y comunicaciones en Internet

Durante las dos primeras décadas de existencia de los computadores, éstos

La evolución de las tecnologías ha llevado a un crecimiento progresivo del uso

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

La idea de Internet apareció a mediados de los años sesenta cuando la Agencia

Desde entonces, Internet ha evolucionado hasta el sistema de hoy en día, en

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

Las redes de computadores se pueden clasificar de diferentes formas. Gene-

3.1. Topologías de red

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

Las topologías más conocidas son las de:

• Bus. Todos los equipos están conectados a un único medio de transmisión

• Árbol. La topología en árbol se considera una topología mixta de las topo-

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

• En�malla. La topología en malla es aquella en la que todos los equipos es-

Ejemplos típicos de topologías de red

3.2. Tipo de conmutación

En el entorno de las redes, la conmutación hace referencia al establecimiento

3.2.1. Conmutación de circuitos

La conmutación de circuitos se basa en establecer un circuito físico entre los

1)� Establecimiento� del� circuito. Esta fase se encarga de buscar un camino

2)�Transferencia�de�datos. Ahora, las estaciones ya pueden intercambiar la

3)�Desconexión. Una vez se ha acabado la comunicación es obligatorio liberar

Ejemplo de creación de circuitos

Un ejemplo de creación de circuitos es el que se muestra en el diagrama de tiempo de la

Diagrama de tiempo del establecimiento de un circuito

Red telefónica básica

El ejemplo más clásico de la conmutación de circuitos es la antigua red telefónica básica

3.2.2. Conmutación de paquetes

Uno de los principales problemas que encontramos con la conmutación de

dos y no pueden ser utilizados por ninguna otra estación. El problema se ve

Así, con el fin de mejorar la conmutación de circuitos de cara a estas nuevas

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

Así, la conmutación de paquetes, en vez de reservar recursos en un circuito,

Como se ha dicho, la conmutación de paquetes tiene que permitir diferentes