Tema N° 2: Capa de Aplicación

Las aplicaciones de red son la razón de ser de una red de computadoras ya que sin
ellas no existiría la necesidad de diseñar protocolos de red para darles soporte.
Entre estas aplicaciones se incluyen las clásicas aplicaciones basadas en texto que se
hicieron populares en las décadas de 1970 y 1980, como son el correo electrónico de
texto, el acceso remoto a computadoras, la transferencia de archivos, los grupos de
noticias y los chats de texto. Entre éstas, también se incluye la tan conocida World
Wide Web, acompañada de la navegación web, las búsquedas web y el comercio
electrónico. Además, tenemos que citar las dos aplicaciones estrella aparecidas a
finales del milenio: la mensajería instantánea con listas de contactos y la
compartición de archivos P2P. Asimismo, también se incluyen muchas aplicaciones
de audio y vídeo, como la telefonía por Internet, la compartición de vídeos y los
flujos de vídeo, la radio por Internet y la televisión IP (IPTV).

Comunicación entre procesos

Antes de crear una aplicación de red, son necesarios conocimientos básicos sobre
cómo los programas que se ejecutan en varios sistemas terminales se comunican entre
sí. En la jerga de los sistemas operativos, realmente no son los programas sino los
procesos los que se comunican, donde un proceso puede interpretarse como un
programa que se ejecuta dentro de un sistema terminal.
Los procesos de dos sistemas terminales diferentes se comunican entre ellos
intercambiando mensajes a través de la red de computadoras. Un proceso emisor crea
y envía mensajes a la red; un proceso receptor recibe estos mensajes y posiblemente
responde devolviendo mensajes.

Procesos Cliente/Servidor
Una aplicación de red consta de parejas de procesos que se envían mensajes entre sí a
través de una red, donde el proceso que inicia la comunicación es rotulado cómo
cliente mientras que el proceso que espera ser contactado para comenzar la sesión es
caratulado cómo servidor. En una aplicación web, un navegador sería un proceso
cliente y el servidor web un proceso servidor.
Un proceso envía mensajes a la red y los recibe a través de un socket, siendo un
proceso análogo a una casa y un socket análogo a la puerta de esta.
Un socket es la interfaz entre la capa de aplicación y la capa de transporte de un host,
también conocido cómo Interfaz de programación de aplicaciones (API,
Application Programming Interface), que opera entre la aplicación y la red, ya que el
socket es la interfaz de programación con la que se construyen las aplicaciones de red.
El desarrollador de la aplicación del socket tiene el control sobre todos los elementos
del lado de la capa de aplicación del socket pero apenas sobre el lado de la capa de
transporte de éste: el programador puede elegir el protocolo de transporte y fijar, por
ejemplo, los tamaños máximos del buffer y de segmento.

Seleccionado el protocolo, la aplicación se construye utilizando los servicios de la

capa de transporte proporcionados por dicho protocolo.

Direccionamiento de procesos
Para enviar una carta a un destino concreto, ese destino necesita disponer de una
dirección. Similarmente, para que un proceso que se está ejecutando en un host pueda
enviar paquetes a otro proceso ejecutándose en un proceso distinto, el proceso
receptor necesita tener una dirección.
Para identificar el proceso receptor, tienen que especificarse dos elementos de
información: la dirección del host (dirección IP) y un identificador del proceso de
recepción de destino.
El identificador del proceso receptor es necesario puesto que el host podría estar
ejecutando muchas aplicaciones de red. Un número de puerto de destino sirve a este
propósito ya que las aplicaciones populares tiene asignados números de puerto
específicos. Por ejemplo, un servidor web tiene el número 80 y un proceso de servidor
de correo (que utilice SMTP) tiene el número 25.

Tipos de Servidores
En la comunicación basada en sockets, un servidor corre en un host en particular y
tiene un socket que está ligado a un puerto en particular. El servidor espera y escucha
en ese socket a que el cliente le haga un pedido de conexión. Si todo está bien, el
servidor acepta el pedido de conexión. Pero, ¿qué sucede cuando varios clientes tratan
de conectarse al mismo tiempo a un servidor?
Servidor Iterativo
Estos servidores procesan una petición a la vez: reciben la petición, la procesan y
luego envían la respuesta antes de manejar otra petición. Durante la conversación, el
puerto no puede escuchar otras peticiones.
Si hay interacción del servicio con el usuario, por ejemplo, transferir un archivo y
digitar el nombre, el servidor queda en espera de que el usuario conteste, al igual que
el resto de las peticiones, si las hubiera. Si se espera demasiado tiempo, se produce un
timeout de petición, y se procede a escuchar a la siguiente petición.

Servidor Concurrente
Pueden atender a múltiples clientes al mismo tiempo. Se trata de crear una nueva línea
de ejecución, un thread, cada vez que llega un nuevo cliente. Este thread se hace
cargo de las peticiones de ese cliente y luego termina (exit).
Este tipo de servidores no pueden usar un sólo puerto debido a las múltiples
conexiones abiertas en simultáneo. Se necesitan muchos puertos, pero un servidor
puede usar sólo un puerto bien-conocido, por lo que la solución es tener, además,
muchos puertos efímeros. Luego de establecida la conexión en el puerto
bien-conocido, el servidor asigna un puerto temporario a esa conexión de modo de
librar el puerto bien-conocido para el siguiente cliente que desee establecer una
conexión.

Servidor con y sin Estado

Los protocolos de red para navegadores web y servidores se clasifican en dos tipos:
sin estado y con estado. La palabra “estado” se refiere a la condición o la calidad de
ser en un momento dado. Que un protocolo sea con o sin estado depende de la
duración de la interacción que tenga un cliente con él y de la cantidad de información
que se almacene.

Con estado
Para entenderlo, consideremos una analogía: una llamada telefónica. En este caso la
conexión, una vez establecida, es mantenida de principio a fin para asegurar la
comunicación continua. Si un cliente hace una petición a un servidor, espera una
respuesta de algún tipo. Si no la recibe, la envía de vuelta.
Sin embargo, la característica principal es que mantiene el estado de todas sus
sesiones, ya sea de autenticación o una solicitud de información. Son aquellos que se
pueden usar repetidamente, cómo el online banking o el email, donde lo que sucedió
en transacciones anteriores puede tener impacto en la transacción actual.
Un ejemplo sería FTP, donde, durante una sesión FTP, el cliente establece una
conexión de control, y luego se lleva a cabo la transferencia de datos.
Si bien ofrece un rendimiento superior debido al seguimiento continuo de la
información, requiere asignación de memoria para almacenar los datos (lo cual no lo
hace muy seguro) y, por lo general, requieren almacenamiento de respaldo.

Sin estado
Consideremos otra analogía: mensajes de texto. El emisor simplemente manda un
SMS, pero no tiene confirmación de que ha sido recibido. No puede haber verificación
cruzada de estado o reintentos.
Aquí, el emisor envía el estado de sesión relevante al receptor de tal manera que cada
solicitud puede interpretarse sin referencia al estado de sesión de solicitudes
anteriores, que el receptor retiene.
HTTP es un ejemplo ya que cada solicitud es ejecutada independientemente de las
solicitudes anteriores.

La ventaja es que requiere una pequeña cantidad de recursos porque no se realizan

seguimientos de las comunicaciones en numerosas líneas y es más fácil recuperarse de
fallos ya que no se mantiene ningún estado, mejorando la confiabilidad.
En desventajas tenemos que son inherentemente menos capaces ya que no almacenan
información. También podría ser esencial incluir información en cada solicitud y,
cómo resultado, el servidor deberá interpretar está nueva información.

Servicios de transporte disponibles para las aplicaciones

Muchas redes proporcionan más de un protocolo de la capa de transporte cuyos
servicios pueden clasificarse de forma bastante general según cuatro parámetros:
transferencia de datos fiable, tasa de transferencia, temporización y seguridad.

Transferencia de datos fiable

En una red de computadoras, pueden perderse paquetes, ya sea por desbordar el buffer
de un router, ser descartado por un host o un router debido a que posee bits
corrompidos. En muchas aplicaciones, esta pérdida puede tener consecuencias
catastróficas (por ejemplo, en aplicaciones financieras).
Si un protocolo proporciona un servicio de entrega garantizado, se dice que
proporciona una transferencia de datos fiable. Cuando un protocolo de transporte
suministra este servicio, el proceso emisor puede pasar sus datos al socket y sabe con
certidumbre que llegarán sin errores al proceso receptor.
Si un protocolo no proporciona este servicio, los datos podrían nunca llegar al proceso
receptor, lo cual puede ser aceptable para aplicaciones tolerantes a pérdidas, cómo
son la mayoría de las aplicaciones multimedia de audio/video en tiempo real.
Tasa de transferencia
La tasa de transferencia disponible es la tasa a la que el proceso emisor puede
suministrar bits al proceso de recepción. Puesto que otras sesiones compartirán el
ancho de banda a lo largo de la ruta, y que estas sesiones inician y terminan
aleatoriamente, la tasa de transferencia puede fluctuar. Si un protocolo no puede
brindar el servicio de una tasa de transferencia disponible garantizada a una velocidad
específica, la aplicación tendrá que realizar la codificación a una velocidad menor o
tendrá que renunciar.
Las aplicaciones con requisitos de tasa de transferencia se conocen cómo aplicaciones
sensibles al ancho de banda, de las cuáles son ejemplo muchas aplicaciones
multimedia actuales, pero algunas emplean técnicas de codificación adaptativa para
realizar la codificación a una velocidad que se adapte a la tasa de transferencia.
Las aplicaciones que pueden hacer uso de la tasa de transferencia disponible, mucha o
poca, se conocen cómo aplicaciones elásticas, de las cuáles son ejemplos el correo
electrónico, la transferencia de archivos y las transferencias web.

Temporización
Las garantías de temporización pueden darse de diversas formas, cómo puede ser la
garantía que cada bit que el emisor empuja por su socket llegará a destino en no más
de 100 milisegundos. Las aplicaciones cómo la telefonía por Internet, los entornos
virtuales y los juegos multijugador tienen restricciones de temporización estrictas
sobre la entrega de datos para que sean efectivas puesto que retardos largos darían
lugar a pausas antinaturales en una conversación o un retardo entre la acción y la
visualización de esa acción en un juego.

Seguridad
Un protocolo puede proporcionar uno o más servicios de seguridad. Por ejemplo,
cifrar los datos transmitidos por el emisor, lo que implica que el servicio debe
proporcionar confidencialidad entre los procesos, incluso si los datos son observados
en el camino.
Otros servicios pueden ser los mecanismos para garantizar la integridad de los datos y
mecanismos de autenticación en el punto terminal.

Servicios de transporte proporcionados por Internet

Internet pone a disposición dos protocolos de transporte: TCP y UDP.
TCP (Transfer Control Protocol)
El modelo de servicio TCP incluye un servicio orientado a la conexión y un servicio
de transferencia de datos fiable.
Servicio orientado a la conexión
TCP hace que el cliente y el servidor intercambien la información de control de la
capa de transporte entre sí antes de que empiecen a fluir los mensajes del nivel de
aplicación. Este proceso denominado de negociación, reconocimiento o de
establecimiento de conexión, alerta al cliente y al servidor, permitiéndoles prepararse
para el intercambio de paquetes. Una vez hecha la negociación, existe una conexión
TCP entre los sockets de los procesos la cual es full-dúplex pues pueden enviarse
mensajes entre sí al mismo tiempo. Una vez se ha terminado de enviar mensajes, se
desactiva la conexión

Servicio de transferencia de datos fiable

Los procesos pueden confiar en TCP para entregar todos los datos sin errores y en el
orden correcto.

TCP también incluye un mecanismo de control de congestión que regula el proceso

emisor cuando la red está congestionada. También intenta limitar cada conexión TCP
para que utilice una cuota equitativa de ancho de banda, lo cual es dañino en
aplicaciones de audio/video en tiempo real pues tienen requisitos mínimos de tasa de
transferencia, sin contar que son tolerantes a las pérdidas. Por esto, los desarrolladores
de este tipo de aplicaciones a menudo optan por UDP en vez de TCP.

UDP (User Datagram Protocol)

Es un protocolo ligero simple que proporciona servicios mínimos. No está orientado a
la conexión, proporciona un servicio de transferencia de datos no fiable (no ofrece
garantías de que el mensaje llegue al receptor, o lleguen en orden) y no tiene
mecanismos de control de gestión.
Cómo las aplicaciones en tiempo real toleran ciertas pérdidas pero requieren una
velocidad mínima para ser efectivas, los desarrolladores suelen optar por este
protocolo.

Ambos protocolos no ofrecen los servicios relativos a las tasas de transferencias y la

temporización, y aún así, aplicaciones cómo la telefonía por Internet funcionan puesto
que estas han sido diseñadas para hacer frente a esta falta de garantías de la mejor
manera posible. No obstante, un diseño inteligente tiene sus limitaciones cuando el
retardo es excesivo.

En resumen, Internet puede ofrecer servicios satisfactorios a aplicaciones sensibles al

tiempo, pero no puede proporcionar garantías de ancho de banda ni de temporización.
Web y HTTP
World Wide Web
La World Wide Web (WWW) es un depósito de información enlazada entre sí desde
puntos de todo el mundo. Hoy en día, la WWW es un servicio cliente-servidor
distribuido, en el que un cliente que utiliza un navegador puede acceder a un servicio
mediante un servidor. Sin embargo, el servicio proporcionado se distribuye en muchos
lugares llamados sitios. Cada sitio contiene uno o más documentos, denominados
páginas web, los cuáles están compuestos de objetos. Un objeto es un archivo, cómo
puede ser un archivo HTML, una imagen JPEG, un video, etc. Por ejemplo, si una
página web contiene texto HTML y cinco imágenes, entonces la página contiene seis
objetos.

Cada página Web, también, puede contener algunos enlaces a otras páginas Web en el
mismo o en otros sitios. Es decir, una página web puede ser simple (no tiene enlaces a
otras páginas) o compuesta.

Página web simple, que tiene imágenes incrustadas y puede recuperarse utilizando
una sola transacción de solicitud/respuesta.
Página web compuesta; supongamos que el documento que queremos recuperar
contiene referencias a otro archivo y a una imágen. El documento principal y la
imagen están almacenados en archivos diferentes en el mismo sitio (archivo A y
archivo B) y el archivo referenciado está en otro sitio (archivo C). Cómo son tres
archivos, se necesitan tres transacciones. Primero se recupera una copia del
documento principal, el cual posee referencias a los otros dos archivos. El usuario, al
navegar, puede hacer click en la referencia a la imagen para invocar la segunda
transacción y recuperar una copia de la imagen. Lo mismo para el archivo
referenciado, se invoca la tercera transacción.

Estos ejemplos muestran la idea de hipertexto e hipermedia. Hipertexto significa

crear documentos que refieran a otros documentos. Hipermedia es un término
aplicado a documentos que contienen enlaces a otros documentos textuales o
documentos que contienen gráficos, vídeos o audios.

Componentes
Cliente web (Navegador)
Interpretan y muestran un documento web. Cada navegador consiste, usualmente, de
tres partes: un controlador, un protocolo cliente e intérpretes.

El controlador recibe información del teclado o del mouse y usa los programas del
cliente para acceder al documento. Una vez que se ha accedido al documento, el
controlador utiliza uno de los intérpretes para mostrar el documento en la pantalla.
El protocolo del cliente puede ser FTP, TELNET o HTTP. El intérprete puede ser
HTML, Java o JavaScript, dependiendo del tipo de documento.

Servidor web
La página web está guardada en un servidor. Cada vez que llega una solicitud de
cliente, el documento correspondiente es enviado. Para mejorar la eficiencia, los
servidores por lo general almacenan los archivos solicitados en un caché en memoria.
Un servidor también puede volverse más eficiente a través de múltiples subprocesos o
multiprocesamiento. En este caso, un servidor puede responder a más de una solicitud
a la vez.

Localización de Objetos (URL, Uniform Resource Locator)

Un cliente que quiera acceder a una página web necesita el nombre del archivo y la
dirección. Para facilitar el acceso, se usan localizadores. URL es un localizador
estándar para especificar cualquier tipo de información en Internet. La URL define
cuatro cosas: el protocolo, la computadora host, el puerto y el camino.

El protocolo es el programa de aplicación cliente-servidor utilizado para recuperar el

documento (Gopher, FTP, HTTP, TELNET).
El host es el nombre de dominio de la computadora donde está la información, y que
usualmente comienza con “www” (no es obligatorio).
El puerto es opcional que aparezca. Si está incluido, es insertado entre el host y el
camino.
El camino es el nombre de la ruta del archivo donde se encuentra la información.

Ejemplo: http://www.cs.washington.edu/index.html
Este enlace tiene tres partes: el protocolo (http), el nombre DNS del host
(www.cs.washington.edu) y el nombre de la ruta (index.html).

Categorías de páginas web

Las páginas web pueden ser agrupadas en tres categorías: estáticas, dinámicas y
activas.

Documentos estáticos
Son documentos de contenido fijo que son creados y almacenados en un servidor, y
donde el cliente sólo puede obtener una copia del documento. Es decir, el contenido
del documento es determinado cuando es creado, no cuando es usado. Este tipo de
documentos se preparan usando lenguajes cómo: HTML (Hypertext Markup
Language), XML (Extensible Markup Language), XSL (Extensible Style Language) y
XHTML (Extended Hypertext Markup Language).

Documentos dinámicos
Son creados por un servidor web cada vez que un navegador solicita el documento.
Cuando llega una solicitud, el servidor web ejecuta un programa de aplicación o un
script que crea un documento dinámico, retornando el resultado al navegador. Cómo
un nuevo documento es creado de solicitud en solicitud, los contenidos pueden variar.
Un ejemplo simple es la recuperación del tiempo y fecha de un servidor.
Interfaz de Entrada Común (CGI, Common Gateway Interface): es una tecnología
que crea y maneja documentos dinámicos. CGI es un conjunto de estándares que
define cómo se escribe un documento dinámico, cómo se ingresan los datos al
programa y cómo se usa el resultado de salida. Estos programas pueden estar escritos
en cualquier lenguaje que sea conveniente para el desarrollador, como Python, Ruby,
Perl, etc.
Common: indica que el estándar define un conjunto de reglas común a cualquier
lenguaje o plataforma.
Gateway: significa que un programa CGI puede ser usado para acceder a otros
recursos cómo bases de datos, paquetes gráficos, etc.
Interface: significa que es un conjunto de términos predefinidos, variables, llamadas,
etc.

El problema de la tecnología CGI es la ineficiencia resultante si parte del documento

dinámico a ser creado es estático y no cambia de solicitud en solicitud. Por ejemplo,
una página mostrando partes de autos con su stock y precio. El stock y el precio
pueden variar, pero las partes siempre serán las mismas.
La solución es crear un archivo que contenga la parte fija del documento utilizando
HTML e incrustar un script, un código fuente, que el servidor puede ejecutar para
proporcionar la sección de precios y disponibilidad variables.
Algunas de las tecnologías más comunes involucradas en la creación de documentos
dinámicos con scripts son: PHP (Hypertext Preprocessor, que usa el lenguaje Perl),
JSP (Java Server Pages, que usa Java para el script), ASP (Active Server Pages,
producto de Microsoft que usa Visual Basic para el script), y ColdFusion, que
incorpora consultas de bases de datos SQL en el documento HTML.

Documentos activos
Para muchas aplicaciones, se necesita un programa o script que se ejecute del lado del
cliente, por ejemplo, cuando se quiere ejecutar un programa que crea gráficos
animados o un programa que interactúa con el usuario.
Java Applets: Una forma de crear documentos activos es usando Java applets. Un
applet es un programa escrito en Java en el servidor, compilado y listo para ejecutarse.
El proceso cliente (navegador) crea una instancia de esta applet y la ejecuta usando
una de dos formas: solicitando el applet en la URL y recibiendolo en forma binaria, ó
recibiendo y ejecutando un archivo HTML que tiene insertado la dirección del applet
cómo una etiqueta.

Javascript: si la parte activa es pequeña, puede escribirse en un lenguaje de script

(usualmente Javascript); luego puede ser interpretado y ejecutado por el cliente al
mismo tiempo.

HTTP (Hypertext Transfer Protocol)

El Protocolo de Transferencia de Hipertexto es el protocolo de la capa de la
aplicación de la Web, se implementa en dos programas: un programa cliente y un
programa servidor los cuáles se comunican entre sí intercambiando mensajes HTTP.
HTTP define la estructura de estos mensajes y cómo el cliente y el servidor
intercambian los mensajes.
Cuando un usuario solicita una página web, el navegador envía al servidor mensajes
de solicitud HTTP para los objetos contenidos en la página. El servidor recibe las
solicitudes y responde con mensajes HTTP que contienen los objetos.

HTTP utiliza TCP cómo su protocolo de transporte subyacente en el puerto

bien-conocido 80. El cliente inicia una conexión TCP con el servidor. Establecida
esta, los procesos de navegador y de servidor acceden a TCP a través de sus interfaces
de socket.
El cliente envía mensajes de solicitud HTTP a su interfaz de socket y recibe mensajes
de respuesta de su interfaz de socket. En el servidor ocurre de forma similar.
El servidor envía los archivos solicitados sin almacenar ninguna información acerca
del estado del cliente. Si un cliente pide el mismo objeto dos veces en un espacio de
tiempo de unos pocos segundos, el servidor no responde diciendo que acaba de servir
dicho objeto al cliente, sólo reenvía el objeto ya que ha olvidado por completo que ya
lo había hecho. Por esto se dice que HTTP es un protocolo sin memoria de estado.

Tipos de Conexiones
En muchas aplicaciones de Internet, el cliente y el servidor están en comunicación
durante un periodo de tiempo amplio, realizando una serie de solicitudes y respuestas.
El desarrollador de la aplicación debe decidir si cada par de solicitud/respuesta se
envía a través de una conexión TCP separada o enviarse todas las solicitudes con sus
respuestas a través de la misma conexión.
Si se usa el primer método, la aplicación utiliza conexiones no persistentes; si se usa
la segunda opción, se habla de conexiones persistentes.

Conexión NO persistente
Supongamos que hemos solicitado una página que consiste de un archivo base HTML
y diez imágenes JPEG, todos en un mismo servidor, y que la página es
http://www.unaEscuela.edu/unDepartamento/home.index. Lo que ocurre es:
 1. El proceso cliente HTTP inicia una conexión TCP con el servidor
www.unaEscuela.edu en el puerto 80, y asociados a la conexión habrá un
socket en el cliente y uno en el servidor.
2. El cliente HTTP envía un mensaje de solicitud HTTP al servidor a través de
su socket, incluyendo el nombre de la ruta /unDepartamento/home.index.
3. El proceso servidor HTTP recibe el mensaje, recupera el objeto (de RAM o
disco), lo encapsula en un mensaje de respuesta HTTP y lo envía al cliente.
4. El proceso servidor HTTP indica a TCP que cierre la conexión (aunque este
no lo hace hasta asegurarse que el cliente ha recibido el mensaje en perfecto
estado).
5. El cliente HTTP recibe el mensaje de respuesta. Termina la conexión TCP. El
mensaje indica que el objeto es un archivo HTML; se extrae el archivo, se
examina y localizan las referencias a los 10 objetos JPEG.
6. Los cuatro primeros pasos se repiten para cada objeto JPEG.

Estos pasos ilustran el uso de conexiones no persistentes, donde cada conexión se

cierra después de que el servidor envíe el objeto. Para este ejemplo, se generaron 11
conexiones TCP.
Claro que es un ejemplo vago y, por defecto, la mayoría de los navegadores abren de
5 a 10 conexiones TCP paralelo.

Para estimar la cantidad de tiempo que transcurre desde que un cliente solicita el
archivo base hasta que lo recibe, definimos el tiempo de ida y vuelta (RTT,
Round-Trip Time), que es el tiempo que tarda un paquete pequeño en viajar desde el
cliente al servidor, y volver al cliente.
Cuando un usuario hace clic en un hipervínculo, hace que el navegador inicie una
conexión TCP entre éste y el servidor web, lo que implica un proceso de “acuerdo en
tres fases”: el cliente envía un pequeño segmento TCP al servidor, éste lo reconoce y
responde con otro segmento TCP y, por último, el cliente devuelve un mensaje de
reconocimiento al servidor. Las dos primeras partes de este proceso tarda un periodo
de RTT. Luego de estas dos primeras partes, el cliente envía a la conexión TCP el
mensaje de solicitud HTTP combinado con la tercera parte de la negociación. Luego
de que el mensaje llega, el servidor envía el archivo HTML a la conexión. Este
mensaje de solicitud/respuesta consume otro RTT.
El tiempo de respuesta total es aproximadamente dos RTT más el tiempo de
transmisión del archivo HTML en el servidor.
Conexión persistente
Las conexiones no persistentes presentan ciertos inconvenientes, cómo el de
establecer y mantener una conexión nueva por cada objeto solicitado, lo que implica
asignar buffers TCP, mantener las variables TCP tanto en cliente cómo en servidor.
Esto puede sobrecargar al servidor si éste está sirviendo cientos de solicitudes de
cientos de clientes. Además está el tiempo de retardo de entrega de dos RTT.
Con las conexiones persistentes, se deja abierta la conexión TCP luego de enviar
una respuesta, de modo que las siguiente solicitudes y respuestas entre mismo cliente
y servidor se envíen a través de la misma conexión. Es decir, una página completa
(un archivo base y diez imágenes) se podría enviar a través de una misma conexión
(procesamiento en cadena).
También existe la posibilidad de pipelining donde se envían solicitudes una tras otra
sin esperar a obtener las respuestas de las solicitudes pendientes

En la siguiente imagen se comparan los tres tipos de conexiones:

La parte (a) muestra tres solicitudes, una después de la otra en conexiones separadas.
En la parte (b), la página se obtiene mediante una conexión persistente.
Y en la parte (c) hay una conexión persistente con solicitudes canalizadas.
Para las conexiones persistentes surge el problema de cuándo cerrar la conexión. Una
conexión a un servidor debe permanecer abierta mientras se carga la página, de modo
que si el cliente clickea en un vínculo que solicita otra página del servidor, está
solicitud entra de inmediato. Pero no hay garantía de que esto suceda, por lo que es
común que las conexiones se cierren luego de un período de inactividad o cuando
haya una gran cantidad de conexiones abiertas y se necesite cerrar algunas.

El modo por defecto de HTTP utiliza conexiones persistentes con

procesamiento en cadena.

Mensajes HTTP
Los mensajes HTTP, son los medios por los cuales se intercambian datos entre
servidores y clientes. Hay dos tipos de mensajes: solicitudes, enviadas por el cliente al
servidor, para pedir el inicio de una acción; y respuestas, que son la respuesta del
servidor.
Las peticiones y respuestas HTTP, comparten una estructura similar, compuesta de:

- Una línea de inicio (start-line) describiendo la petición a ser implementada, o

su estado, sea de éxito o fracaso.
 - Un grupo opcional de cabeceras HTTP, indicando la petición o describiendo
el cuerpo (body) que se incluye en el mensaje.
- Una línea vacía (empty-line) indicando toda la metainformación ha sido
enviada.
- Un campo de cuerpo de mensaje opcional (body) que lleva los datos
asociados con la petición (como contenido de un formulario HTML), o los
archivos o documentos asociados a una respuesta (como una página HTML, o
un archivo de audio, vídeo, etc).

Mensajes de solicitud
Un mensaje de solicitud consiste de una línea de solicitud, una cabecera y, a veces,
un cuerpo. Por ejemplo:
GET /unadireccion/pagina.html HTTP/1.1
Host: www.unaescuela.edu
Connection: close
User-agent: Mozilla/4.0
Accept-language: fr

La primera línea es la línea de solicitud y las siguientes son las líneas de cabecera.

La línea de solicitud consta de tres campos: el campo método (el tipo de solicitud),
el campo URL, y el campo de la versión HTTP. En el ejemplo está solicitando
(GET) el objeto /unadireccion/pagina.html, y está utilizando la versión 1.1 de HTTP.
Luego de la línea de solicitud, pueden haber cero o más líneas de cabecera, las cuáles
son información adicional que envía el cliente al servidor.
La línea Host: www.unaescuela.edu específica el host donde reside el objeto, útil
para las caches de proxy.
La línea Connection: close, el navegador le dice al servidor que cierre la conexión
después de enviar el objeto solicitado.
La línea User-agent específica el tipo de navegador que está haciendo la solicitud
(pueden haber diferentes versiones del objeto dependiendo del agente de usuario).
La línea Accept-language indica que el usuario prefiere recibir una versión, en este
ejemplo, en francés del objeto, si estuviera disponible; caso contrario, se envía la
versión por defecto.

Mensajes de respuestas
Un mensaje de respuesta típico:
HTTP/1.1 200 OK
Connection: close
Date: Sat, 07 Jul 2007 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Sun, 6 May 2007 09:23:24 GMT
Content-Length: 6821
Content-Type: text/html
(datos datos datos datos datos ...)

Tiene tres secciones: una línea de estado inicial, seis líneas de cabecera, y el cuerpo
de entidad.

La línea de estado contiene tres campos: la versión del protocolo, el código de

estado y el mensaje explicativo del estado.

Algunas de las líneas de cabecera del ejemplo:

La línea Date indica la hora y fecha en la que se creó la respuesta HTTP y fue enviada
por el servidor.
La línea Content-length específica el número de bytes del objeto que está siendo
enviado.
La línea Content-type indica que el objeto en el cuerpo de entidad es texto HTML.
Cache
Una caché HTTP es un almacén local de mensajes de respuesta y el subsistema que
controla el almacenamiento, la recuperación y la eliminación de mensajes en él. Un
caché almacena respuestas almacenables en caché para reducir el tiempo de respuesta
y el consumo de ancho de banda de la red en futuras solicitudes equivalentes.
Las respuestas HTTP tienen dos estados: fresh (nuevo) y stale (viejo). El estado
fresh indica, generalmente, que la respuesta sigue siendo válida y puede ser reusada,
mientras que el estado stale significa que la respuesta cacheada ya ha expirado. El
criterio para determinar cuándo una respuesta es fresh ó stale es el tiempo de vida
(age: el tiempo que ha pasado desde que la respuesta fue generada).

Las respuestas stale no se descartan inmediatamente. HTTP tiene un mecanismo para

transformar una respuesta stale en una respuesta fresh preguntando al servidor origen.
Esto se denomina validación o revalidación, la cual se realiza mediante una solicitud
condicional que incluye un header de solicitud If-Modified-Since o If-None-Match.

If-Modified-Since
La siguiente respuesta se generó a las 22:22 y tiene max-age de 1 hora, por lo que se
sabe que es fresh hasta las 23:22.
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT
Cache-Control: max-age=3600

<!doctype html>
...

A las 23:22, la respuesta se vuelve stale y la caché no puede ser reutilizada. Así que la
caché realiza una petición con un header If-Modified-Since, para preguntar al
servidor si han habido cambios desde el tiempo especificado
GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
If-Modified-Since: Tue, 22 Feb 2022 22:00:00 GMT
El servidor responderá con un 304 Not Modified si el contenido no ha cambiado
desde el tiempo especificado.
Al recibir esta respuesta, el cliente revierte la respuesta stale en fresh y puede ser
reutilizada durante 1 hora.

FTP (File Transfer Protocol)

El Protocolo de Transferencia de Archivos es un protocolo que permite transferir
archivos de un host a otro. FTP difiere de otras aplicaciones de cliente/servidor dado
que establece dos conexiones entre los host: una conexión es usada para transferencia
de datos y la otra para control de información (comandos y respuestas). Esta
separación hace a FTP más eficiente.
FTP usa dos puertos TCP bien-conocidos: puerto 21 para el control de conexión y el
puerto 20 usado para la conexión de datos.

En este modelo básico de FTP, el cliente tiene tres componentes: interfaz de usuario,
el proceso de control de clientes, y el proceso de transferencia de datos del cliente.
El servidor tiene dos componentes: el proceso de control del servidor y el proceso
de transferencia de datos del servidor. La conexión de control se realiza entre los
procesos de control. La conexión de datos se realiza entre los procesos de
transferencia de datos.

Conexiones
Conexión de control
Se crea en dos pasos:
1) El servidor emite una apertura pasiva en el conocido puerto 21 y espera a un
cliente.
2) El cliente usa un puerto efímero y emite una apertura activa.
La conexión permanece abierta durante todo el proceso. El tipo de servicio, utilizado
por el protocolo IP, es minimizar la demora porque se trata de una conexión
interactiva entre un usuario (humano) y un servidor. El usuario escribe comandos y
espera recibir respuestas sin demora significativa.

Conexión de datos
Se crea de la siguiente forma:
1) El cliente emite una apertura pasiva utilizando un puerto efímero. Es hecho por
el cliente ya que es éste el que emite los comandos para transferir archivos.
2) El cliente envía este número de puerto al servidor utilizando el comando PORT.
3) El servidor recibe el número de puerto y emite una apertura activa utilizando el
puerto bien-conocido 20 y el número del puerto efímero recibido.
Cuando un usuario inicia una sesión FTP con un host remoto, el lado del cliente
(usuario) establece una conexión de control TCP con el lado de servidor (host remoto)
en el puerto 21, donde el cliente envía la identificación y contraseña del usuario cómo
parte de los comandos FTP. Cuando el servidor recibe un comando para realizar una
transferencia de archivo, éste inicia una conexión de datos TCP con el cliente. FTP
envía un archivo a través de la conexión de datos y luego se cierra. Si durante la
misma sesión, el usuario desea transferir otro archivo, FTP abre otra conexión de
datos.
La conexión de datos permanece abierta mientras dura la sesión, pero se crea una
nueva conexión de datos para cada archivo transferido (no es persistente).
A lo largo de la sesión, el servidor FTP tiene que mantener un estado del usuario. En
concreto, el servidor debe asociar la conexión de control con una cuenta de usuario
específica y debe estar al tanto del directorio actual del usuario cuando éste se mueve
por el árbol del directorio remoto. Llevar el control de esta información de estado para
cada sesión de usuario activa restringe de forma significativa el número total de
sesiones que FTP puede mantener simultáneamente.

Comandos y respuestas
Los comandos (cliente → servidor) y las respuestas (servidor → cliente) se envían a
través de la conexión de control en formato ASCII de 7 bits. Cada comando consta de
cuatro caracteres ASCII en mayúsculas, y algunos emplean argumentos opcionales:
- USER nombre_de_usuario: se usa para enviar la identificación del usuario
al servidor.
- PASS contraseña: envía la contraseña al servidor.
- LIST: se usa para pedir una lista de todos los archivos existentes en el
directorio remoto actual, la cual se envía a través de una conexión de datos.
- RETR nombre_de_archivo: hace que el host remoto inicie una conexión de
datos y envíe el archivo solicitado.
 - STOR nombre_de_archivo: se usa para almacenar (introducir) un archivo
en el directorio actual del host remoto.
Cada comando va seguido de una respuesta las cuáles son números de tres dígitos con
un mensaje opcional:
- 331 Username OK, password required
- 125 Data connection already open; transfer starting
- 425 Can’t open data connection
- 452 Error writing file

Correo Electrónico (SMTP, POP, IMAP, MIME)

El correo electrónico es un medio de comunicación asíncrono (las personas envían y
leen los mensajes cuando les conviene, sin tener que coordinarse con las agendas de
otras personas). Mediante las listas de correo, se pueden enviar mensajes de correo
electrónico y correo basura (spam) a miles de destinatarios al mismo tiempo. A
menudo incluyen adjuntos, hipervínculos, texto en formato HTML y fotografías.

Componentes

Agentes de usuario
Permiten a los usuarios leer, responder, reenviar, guardar y componer mensajes.
Cuando un usuario A termina de componer su mensaje, su agente de usuario envía el
mensaje a su servidor de correo, donde es colocado en la cola de mensajes salientes
del servidor de correo. Cuando el usuario B quiere leer su mensaje, su agente de
usuario recupera el mensaje de su buzón, que se encuentra en el servidor de correo.
Servidores de correo
Los servidores de correo forman el núcleo de la infraestructura del correo
electrónico. Cada destinatario tiene un buzón de correo en uno de los servidores de
correo. Si el servidor del usuario A no puede enviar el mensaje al servidor del usuario
B, entonces el servidor del usuario A mantiene el mensaje en una cola de mensajes e
intenta enviarlo más tarde (cada 30 minutos, más o menos). Si después de varios días
no se ha conseguido, el servidor elimina el mensaje y notifica al emisor.

SMTP
SMTP es el principal protocolo de la capa de aplicación para el correo electrónico.
Utiliza TCP para transferir el correo desde el servidor emisor al servidor destinatario.
SMTP tiene dos lados, cliente y servidor. Cuando un servidor de correo envía
mensajes, actúa cómo un cliente SMTP. Cuando un servidor recibe mensajes, actúa
cómo un servidor SMTP.
Un ejemplo del funcionamiento básico de SMTP:
1) Ana invoca a su usuario de agente de usuario (AU), proporciona la dirección
de correo de Ben, compone un mensaje e indica al AU que lo envíe.
2) El AU envía el mensaje al servidor de correo de Ana, donde se coloca en una
cola de mensajes.
3) El lado del cliente de SMTP (en servidor de correo de Ana) ve el mensaje, abre
una conexión TCP con el servidor SMTP ejecutándose en el servidor de correo
de Ben.
4) Después de la fase de negociación, el cliente SMTP envía el mensaje a través
de la conexión TCP.
5) En el servidor de correo de Ben, el lado del servidor de SMTP recibe el
mensaje, y el servidor de correo coloca el mensaje en el buzón de Ben.
6) Ben invoca a su agente de usuario para leer el mensaje cuando quiera.

SMTP usa comandos y respuestas para transferir mensajes entre cliente y servidor.
Comandos
Enviados desde el cliente al servidor, consisten de una palabra clave seguida de cero o
más argumentos.

HELO: usado por el cliente para identificarse, el argumento es el dominio del host del
cliente. HELO: challenger.atc.fhda.edu
MAIL FROM: usado por el cliente para identificar al emisor, el argumento es el correo
del emisor. MAIL FROM: forouzan@challenger.atc.fhda.edu
RCPT TO: usado por el cliente para identificar el destinatario, el argumento es el correo
del destinatario. Si son múltiples, el comando se repite.
DATA: este comando envía el mensaje. Todas las líneas luego de DATA son tratadas
cómo el mensaje, el cual termina con una línea conteniendo un punto.

Respuestas
Código de tres dígitos enviado desde el servidor al cliente que puede ser seguido de
información textual adicional (similar a HTTP):
El primer dígito indica la categoría de la respuesta
- 2XX: operación concluida con éxito
- 3XX: orden, el servidor está pendiente de que el cliente le envíe nuevos datos.
- 4XX: respuesta de error transitorio, pero se espera a que se repita la
instrucción.
- 5XX: indica una condición de error permanente, por lo que no debe repetirse la
orden

Formato de los mensajes de correo

Cuando una persona envía un correo, una cabecera que contiene la información
administrativa antecede al cuerpo del mensaje, separadas por una línea en blanco
(CRLF).
Cada línea de cabecera consta de una palabra clave seguida de dos puntos y un
valor, algunas obligatorias y otras opcionales. Toda cabecera tiene que estar formada
por una línea de cabecera From y una línea de cabecera To.
From: alicia@crepes.fr
To: benito@hamburger.edu
Subject: Búsqueda del significado de la vida. (opcional)
Fases de transferencia de correo
El proceso de transferencia de un mensaje de correo consta de tres fases:
establecimiento de la conexión, transferencia del correo y finalización de la
conexión.
Establecimiento de la conexión
Después de que un cliente haya realizado una conexión TCP al conocido puerto 25,
el servidor SMTP inicia la fase de conexión, la cual consta de los siguientes pasos:
Servidor: 220 service ready (listo para recibir)
Cliente: HELO: deanza.edu (el cliente se identifica)
Servidor: 250 OK

Transferencia del correo

Una vez establecida la conexión entre el cliente SMTP y el servidor, se puede
intercambiar un solo mensaje entre un remitente y uno o más destinatarios. Esta fase
consta de ocho pasos. Los pasos 3 y 4 se repiten si hay más de un destinatario.
1) El cliente envía MAIL FROM para introducir el emisor del mensaje.
2) El servidor responde
3) El cliente envía RCPT TO con el destinatario
4) El servidor responde
5) El cliente envía DATA para inicializar la transferencia del mensaje
6) El servidor responde
7) El cliente envía el contenido del mensaje en líneas consecutivas. Cada línea
termina con un token de fin de línea de dos caracteres (retorno de carro y
avance de línea). El mensaje termina con una línea que contiene solo un punto
8) El servidor responde

C: MAIL FROM: forouzan@deanza.edu

S: 250 OK
C: RCPT TO firouz@net.edu
S: 250 OK
C: DATA
S: 354 start mail input
C: From: Behrouz Forouzan
C: To: Firouz Mosharraf
C: Date: 1/6/05
C: Subject: Network
C: Blank line
C: /* data message */
C: .
S: 250 OK
Finalización de la conexión
Una vez transferido el mensaje, el cliente termina la conexión TCP.
C: QUIT
S: 221 service closed

Comparación con HTTP

- HTTP es principalmente un protocolo pull (extracción): alguien carga la
información en un servidor web y los usuarios utilizan HTTP para extraer la
información. SMTP es fundamentalmente un protocolo push (inserción): el
servidor de correo emisor introduce el archivo en el servidor de correo receptor.
- SMTP requiere que cada mensaje esté en formato ASCII de 7 bits. Los datos
HTTP no imponen esta restricción.
- HTTP encapsula cada objeto en su propio mensaje de respuesta HTTP. El
correo Internet incluye todos los objetos del mensaje en un mismo mensaje.

Cabeceras MIME
El correo electrónico tiene una estructura simple, y esa simplicidad viene con un
precio: limitaciones. No puede ser usada para lenguajes que no sean inglés y no se
puede usar para enviar archivos binarios o datos de video o audio.
MIME (Multipurpose Internet Mail Extensions, extensiones de correo de Internet
multipropósito) es un protocolo complementario que permite enviar datos que no son
ASCII a través del correo electrónico transformando datos no-ASCII en el sitio del
emisor a datos NVT ASCII y los entrega al agente de usuario del cliente para ser
enviados. El mensaje se transforma a los datos originales en el destinatario.

MIME define cinco cabeceras que pueden ser añadidas para definir los parámetros de
transformación:

1) MIME-Version: versión de MIME usada.

2) Content-Type: define el tipo de datos usados en el cuerpo del mensaje. El
contenido y subcontenido están separados por una barra. Dependiendo del
subtipo, la cabecera puede tener otros parámetros.
a) Texto: ASCII de 7 bits. Dos subtipos: simple y HTML.
b) Multiparte: el cuerpo contiene múltiples partes independientes y debe
definirse el límite entre ellas con un parámetro. Tiene cuatro subtipos:
mixto, paralelo, digest y alternativo.
c) Mensaje: el cuerpo es en sí mismo un mensaje de correo completo, una
parte de un mensaje de correo o un puntero a un mensaje. Tres subtipos:
RFC822 (si el cuerpo encapsula otro mensaje), parcial (si el mensaje
original ha sido fragmentado y ese correo es una parte; se re ensamblan
en destino y deben llevar tres parámetros: id, número y total) y
cuerpo-externo (indica que el mensaje es una referencia al mensaje
original).
d) Imagen: imagen no animada. Dos subtipos: JPEG y GIF.
e) Video: un subtipo: MPEG
f) Audio: un subtipo: básico, que utiliza datos de audio estándar de 8 kHz.
g) Aplicación: el mensaje es un tipo de dato no establecido previamente.
Dos subtipos: PostScript (formato Adobe PostScript) y flujo de octetos
(archivo binario).
3) Content-Transfer-Encoding: método para codificar los mensajes:
a) 7 bit: NVT ASCII; no debe exceder los 1000 caracteres.
b) 8 bit: pueden enviarse caracteres no-ASCII; máximo 1000 caracteres.
c) Binario: codificación de 8 bits que puede exceder los 1000 caracteres.
En este y el anterior, MIME no hace codificación, el protocolo SMTP
debería ser capaz de transferir caracteres no-ASCII de 8 bits, por lo que
no son recomendados.
d) Base64: solución para enviar datos hechos de bytes cuando el bit más
alto no es necesariamente cero. Base64 transforma este tipo de datos en
caracteres imprimibles, que luego se pueden enviar como caracteres
ASCII o cualquier tipo de conjunto de caracteres compatible con el
mecanismo de transferencia de correo subyacente.
e) Citado-imprimible: si sólo una pequeña porción de los datos son
no-ASCII, se envían cómo tres caracteres: el primero es el signo igual
(=) y los dos siguientes la representación hexadecimal del byte.
4) Content-Id: identifica el mensaje en un entorno de múltiples mensajes.
5) Content-Description: define si el cuerpo es imagen, audio o video.
Protocolos de acceso para correo electrónico
¿Cómo hacen los destinatarios, que ejecutan un agente de usuario en su PC local, para
obtener sus mensajes que están en un servidor de correo de su ISP? No pueden utilizar
SMTP porque obtener los mensajes implica una operación de extracción, y SMTP es
un protocolo push.
Se utilizan otros protocolos: POP3, IMAP4 y HTTP.

POP3 (Post Office Protocol-version 3)

El Protocolo de Oficina de Correos versión 3 es un protocolo de acceso a correo
extremadamente simple. Se inicia cuando el agente de usuario abre una conexión TCP
en el puerto 110 al servidor de correo. Establecida la conexión, POP3 pasa a través de
tres fases:
- Autorización: el agente de usuario (AU) envía un nombre de usuario y
contraseña para autenticar al usuario.
- Transacción: el AU recupera los mensajes. El AU también puede marcar los
mensajes para borrado, eliminar las marcas de borrado y obtener estadísticas de
correo.
- Actualización: ocurre luego que el cliente ejecuta QUIT, terminando la sesión
POP3. En ese instante, el servidor de correo borra los mensajes que hayan sido
marcados para borrado.
En una transacción, el AU ejecuta comandos y el servidor devuelve una respuesta :
+OK o -ERR.
Un problema con el modo de descarga y borrado es que si un usuario lee un mensaje
en una computadora en la oficina, no puede leerlo en su computadora en casa.
En el modo descargar y guardar, el AU deja los mensajes en el servidor de correo
por lo que el usuario puede leerlos desde distintas máquinas.
Durante una sesión POP3 entre AU y servidor de correo, el servidor POP3 mantiene
cierta información de estado: la relación de los mensajes de usuario que han sido
marcados para ser borrados. Sin embargo, no conserva la información de estado de
una sesión a otra.

IMAP (Internet Mail Access Protocol)

El Protocolo de Acceso de Correo de Internet es similar a POP3 pero tiene más
características; IMAP es más poderoso y complejo.
POP3 tiene algunas deficiencias: no permite al usuario organizar su correo en el
servidor, no puede crear carpetas en el servidor, y no permite chequear parcialmente
los contenidos de un correo antes de descargarlo.
IMAP provee las siguientes funciones extra. Un usuario puede:
- Chequear un correo antes de descargarlo.
- Buscar en el contenido del correo una cadena específica antes de descargarlo.
- descargar parcialmente un correo, lo que es útil si el ancho de banda es
limitado.
- Crear, eliminar o renombrar buzones en el servidor de correo.
- Crear una jerarquía de buzones en una carpeta para el almacenamiento de
correo.

Correo electrónico Web

Cada vez más usuarios acceden a su correo a través de navegadores web. Con este
servicio, el AU es un navegador web y el usuario se comunica con su buzón remoto a
través de HTTP. Cuando un usuario desea acceder o enviar un correo, esto se hace
utilizando HTTP en vez de POP3 o IMAP (acceso) o SMTP (envío).

DNS (Domain Name System)

Las personas acceden a la información en línea utilizando nombres de host como
nytimes.com o espn.com, pero estos nombres proporcionan poca o ninguna
información acerca de la ubicación del host y constan de caracteres alfanuméricos de
longitud variable, por lo que son difíciles de procesar por los routers. Por esto, los
hosts también se identifican mediante direcciones IP. Para reconciliar estas
preferencias, se necesita un servicio que traduzca los nombres de host en direcciones
IP. Esta es la tarea principal del Sistema de Nombres de Dominio. DNS es una base
de datos distribuida implementada en una jerarquía de servidores y un protocolo de la
capa de aplicación que permite a los hosts consultar dicha base de datos que se ejecuta
sobre UDP y utiliza el puerto 53.
Otros protocolos, cómo HTTP, SMTP y FTP, usan DNS para traducir los nombres de
los hosts suministrados por el usuario en direcciones IP.
Por ejemplo, supongamos que un usuario solicita el URL
www.unaescuela.edu/index.html. Para que el host del usuario pueda enviar un mensaje
de solicitud HTTP al servidor web www.unaescuela.edu, el host debe obtener primero
la dirección IP:
1) El navegador extrae el nombre del host del URL (www.unaes…).
2) Se pasa el nombre del host al cliente DNS.
3) El cliente de DNS envía una consulta con el nombre del host a un servidor
DNS.
4) El cliente DNS recibe una respuesta con la dirección IP correspondiente.
5) Se inicia una conexión TCP con el proceso servidor HTTP en puerto 80 en esa
dirección.

DNS proporciona algunos otros servicios:

- Alias de host: un host con un nombre complicado puede tener uno o más alias,
y el nombre original se dice que es el nombre canónico. Una aplicación puede
invocar DNS para obtener el nombre de host canónico para un determinado
alias.
- Alias del servidor de correo: una aplicación de correo puede invocar al
servicio DNS para obtener el nombre de host canónico para un determinado
alias, así como la dirección IP del host.
- Distribución de carga: DNS también se emplea para realizar la distribución de
carga entre servidores replicados. Los sitios con una gran carga de trabajo
(cómo google) están replicados en varios servidores, ejecutándose en sistemas
terminales distintos con IPs diferentes. Para los servidores web replicados hay
asociados un conjunto de direcciones IP con un único nombre de host
canónico. La BD de DNS contiene este conjunto de direcciones.
Estructura
Tiempo atrás, el mapeo se realizaba usando un archivo host que tenía dos columnas:
nombre y dirección. Cada host podía almacenar el archivo en su disco y actualizarlo
periódicamente desde un archivo host master.
Sin embargo, en estos tiempos, es imposible tener un sólo archivo host ya que sería
demasiado grande para ser almacenado en cada host, y además sería imposible
actualizar todos los archivos cada vez que haya un cambio.
Una solución podría ser un servidor que contuviera todas las correspondencias entre
nombres y direcciones. En este diseño centralizado, los clientes dirigirían las consultas
a un mismo servidor DNS, Pero este diseño viene con problemas:
- Único punto de fallo: si el servidor DNS falla, también falla toda la red
Internet.
- Volumen de tráfico: un sólo servidor tendría que gestionar todas las consultas.
- Base de datos centralizada distante: un único servidor no puede “estar cerca”
de todos los clientes, lo que podría llevar a retardos significativos.
- Mantenimiento: no sólo sería enorme, sino que tendría que ser actualizada con
frecuencia.
En resumen, no es escalable. Por eso DNS utiliza un diseño distribuido.

DNS utiliza un gran número de servidores, organizados jerárquicamente y

distribuidos alrededor del mundo donde ningún servidor DNS dispone de todas las
correspondencias de todos los hosts de Internet, sino que están repartidas.

Clases de servidores
Existen tres clases de servidores DNS: DNS raíz, DNS de dominio de nivel superior
(TLD, Top-Level Domain) y DNS autoritativos.

Suponga que un cliente DNS desea la dirección IP del host www.amazon.com:

primero, el cliente contacta a un servidor raíz, el cual devuelve las direcciones IP
para los servidores TLD del dominio .com.
Luego, el cliente contacta a uno de los servidores TLD que devuelve la dirección IP
de un servidor autoritativo para amazon.com.
Por último, el cliente contacta un servidor autoritativo el cual devuelve la dirección
del host www.amazon.com.
DNS raíz
Cada servidor es una agrupación (cluster) de servidores replicados. Proporcionan
información a los clientes sobre los servidores DNS de los que pueden recibir datos
sobre la dirección IP solicitada. Hay 13 direcciones IP diferentes que sirven a la zona
raíz de DNS, y existen cientos de servidores raíz redundantes en todo el mundo para
gestionar las solicitudes a la zona raíz.

Dominio de nivel superior (TLD)

Responsable de dominios cómo com, edu, org, net, edu, gov; y de los
correspondientes a los países, cómo uk, fr, ca, jp.

DNS autoritativos
Las organizaciones con hosts accesibles públicamente proporcionan registros DNS
que establecen la correspondencia entre nombres y direcciones IP, las cuáles son
albergadas por estos servidores.

En este diseño los nombres son definidos en una estructura de árbol invertido con la
raíz al principio.

Cada nodo en el árbol tiene una etiqueta (cadena, máximo de 63 caracteres). La

etiqueta de la raíz es una cadena vacía. DNS requiere que los hijos de cada nodo
(ramificados de un mismo nodo) tenga distintas etiquetas para garantizar la unicidad
de los nombres de dominio.
Un nombre de dominio completo es una secuencia de etiquetas separadas por puntos,
se leen desde el nodo a la raíz.
Nombre de dominio completamente calificado (FQDN, Fully Qualified Domain
Name): Si una etiqueta termina en null, es FQDN. Contiene todas las etiquetas, desde
la más específica a la más general, que define el nombre del host (www.google.com.)
Nombre de dominio parcialmente calificado (PQDN, Partly Qualified Domain
Name): cuando una etiqueta no termina en null. Es usado cuando el nombre a ser
resuelto pertenece al mismo sitio que el cliente. Aquí el resolvedor puede suministrar
la parte faltante (sufijo) para formar un FQDN.

Resolución de nombres
Un host que necesita asignar una dirección a un nombre o un nombre a una dirección
llama a un cliente DNS llamado resolutor. Este accede al servidor DNS más cercano
con una solicitud de mapeo. Si el servidor tiene la información, satisface al resolutor;
sino lo remite a otros servidores o solicita a otros servidores que proporcionen la
información.
Luego de recibir el mapeo, lo interpreta para ver si es una solución o un error, y
finalmente entrega el resultado al proceso que lo pidió.

Resolución recursiva
El cliente (resolutor) puede solicitar una respuesta recursiva de un servidor de
nombres. Esto significa que el resolutor espera que el servidor proporcione la
respuesta final. Si el servidor es la autoridad para el nombre de dominio, chequea su
base de datos y responde. Caso contrario, envía la solicitud a otro servidor (el padre,
usualmente) y espera la respuesta, y así sucesivamente. Cuando se resuelve la
consulta, la respuesta viaja hasta el cliente que la solicitó.
Resolución iterativa
El cliente envía la solicitud. Si el servidor es la autoridad para el nombre, envía la
respuesta. Si no le envía al cliente la dirección IP de un servidor que piensa podría
resolver la consulta, por lo que el cliente es responsable de repetir la consulta al
segundo servidor, y así sucesivamente. Es iterativo porque el cliente debe repetir la
misma consulta a diferentes servidores.

Caché DNS
Cada vez que un servidor recibe una consulta por un nombre que no está en su
dominio, debe chequear su base de datos por direcciones IP de servidores. La
reducción de esta búsqueda incrementaría la eficiencia, y DNS lo maneja con caché.
Cuando un servidor pregunta por un mapeo a otro servidor, éste lo guarda en su
memoria caché antes de enviarlo al cliente. Si el mismo u otro cliente pide el mismo
mapeo, chequea su memoria caché y resuelve el problema (también marca la respuesta
cómo sin autorización).
Acelera procesos pero también tiene sus problemas. Si un servidor mantiene un mapeo
en caché por un largo tiempo, puede terminar enviando un mapeo desactualizado. Para
esto se utilizan dos técnicas. Primero, el servidor autorizado siempre añade el
time-to-live (TTL) que define en segundos por cuánto tiempo se puede cachear la
información. Luego de ese tiempo es invalido y se debe enviar una nueva consulta al
servidor. Segundo, DNS requiere que cada servidor mantenga un contador TTL para
cada mapeo que cachea. La memoria caché debe ser buscada periódicamente en busca
de mapeos expirados, y eliminarlos.

Mensajes DNS
DNS tiene dos tipos de mensajes: consulta y respuesta. Ambos tienen el mismo
formato. La consulta consiste de una cabecera y registros de preguntas. La
respuesta consiste de una cabecera, registros de preguntas, registros de respuestas,
registros de autorización y registros adicionales.

Componentes
Cabecera
12 bytes

- Identificación: Campo de 16 bits usado por el cliente para unificar la respuesta

con la consulta, distintos en cada consulta. El servidor duplica este número en
la respuesta correspondiente.
- Flags: Campo de 16 bits que consiste de:

- QR (query/responde): 1 bit. 0 si es consulta, 1 si es respuesta.

- OpCode: 4 bits. Tipo de consulta/respuesta. 0, estándar; 1, inverso; 2
solicitud de estado del servidor.
- AA (Servidor autorizado): 1 bit. Respuesta. 1, el servidor de nombre es
un servidor autorizado.
- TC (truncado): 1 bit. Si es 1, la respuesta era más de 512 bytes y fue
truncada. Usado cuando DNS usa UDP.
- RD (discusión requerida): 1 bit. Si es 1, el cliente quiere una respuesta
recursiva. Seteado en consulta y repetido en respuesta.
- RA (recursión disponible): 1 bit. Cuando es seteado en la respuesta,
significa que la respuesta recursiva está disponible.
- Reservado: 3 bits seteados en 000.
- rCode: 4 bits. Muestra el estado del error en la respuesta. 0, sin error; 1,
error de formato; 2, problema en el servidor de nombres; 3 problema de
referencia de dominio; 4, tipo de consulta no soportado; 5, prohibido
administrativamente; 6-15, reservados.
 - Número de registros de preguntas: 16 bits. Contiene el número de consultas
en la sección de preguntas del mensaje.
- Número de registro de respuestas: 16 bits. Número de registros de respuesta
en la sección de respuestas del mensaje. Es 0 en el mensaje de consulta.
- Número de registros de autorización: 16 bits. Número de registros de
autorización en la sección de autorización de la respuesta. 0 en consulta.
- Número de registros adicionales: 16 bits. Número de registros adicionales en
la sección adicional del mensaje de respuesta. 0 en consulta.

Sección de preguntas
Contiene uno o más registros de preguntas, presente en mensajes de consulta y
respuesta.
Sección de respuestas
Contiene uno o más registros de recursos, presente sólo en mensajes de respuesta, e
incluye la respuesta del servidor al cliente.
Sección autorizada
Contiene uno o más registros de recursos, presente sólo en mensajes de respuesta.
Provee información (nombre de dominio) acerca de uno o más servidores autorizados
para la consulta.
Sección de información adicional
Contiene uno o más registros de recursos, presente sólo en mensajes de respuesta.
Provee información adicional que puede ayudar al resolutor Por ejemplo, el servidor
puede dar el nombre de dominio de un servidor autorizado al resolutor en la sección
de autorización, e incluir la dirección IP de éste en la sección de información
adicional.

Tipos de registros
Registros de preguntas
Usados por el cliente para obtener información de un servidor, contiene el nombre del
dominio.
 - Nombre de consulta: campo de longitud variable que contiene un nombre de
dominio. El campo count refiere al número de caracteres en cada sección.

- Tipo de consulta: 16 bits.

- Clase de la consulta: 16 bits. Define el protocolo específico usando DNS.

- Clase 1 (IN): Internet
- Clase 2 (CSNET): Red CSNET (obsoleta)
- Clase 3 (CS): La red COAS
- Clase 4 (HS): El servidor Hesiod desarrollado por MIT

Registros de recursos
Cada nombre de dominio está asociado con un registro llamado registro de recursos.
La base de datos de un servidor consiste en registros de recursos, y estos son también
los que devuelve un servidor al cliente.

- Nombre de dominio: campo de longitud variable. Es un puntero desplazado

hacia el campo de nombre de dominio correspondiente en el registro de
preguntas.
 - Tipo de dominio: Igual al campo en el registro de preguntas, excepto que los
últimos dos tipos no son permitidos.
- Clase del dominio: Igual al campo en el registro de preguntas.
- Tiempo de vida: 32 bits. Define el número de segundos que la respuesta es
válida. Un valor cero indica que no puede ser cacheada.
- Longitud de datos de recurso: 16 bits.
- Datos de recurso: longitud variable. Contiene la respuesta a la consulta o el
nombre de dominio de un servidor autorizado o información adicional. El
formato y contenidos dependen del valor del campo de tipo:
- Un número: escrito en octetos (por ejemplo, una dirección IP)
- Un nombre de dominio: expresados en secuencias de etiquetas donde
cada etiqueta es precedida de un campo de 1 byte indicando el número
de caracteres en cada etiqueta.
- Un puntero desplazado: los nombres de dominios pueden ser
reemplazados por puntero, un campo de 2 bytes con cada uno de los 2
bits de orden superior establecidos en 1 (11).
- Una cadena de caracteres: campo de 1 byte seguido del número de
caracteres definido en el campo de longitud.

Encapsulación
DNS puede usar UDP o TCP, ambos en el puerto 53. UDP es usado cuando el tamaño
de la respuesta es menor a 512 bytes.
Si el resolutor tiene conocimiento previo del tamaño de la respuesta, elige con
anterioridad cuál protocolo usar.
Si no lo sabe, puede usar UDP. Sin embargo, si la respuesta excede los 512 bytes, el
servidor trunca el mensaje y activa el bit TC. Luego, el resolutor abre una conexión
TCP y repite la solicitud para obtener una respuesta completa.

Login remoto: Telnet y SSH

TELNET
Es una abreviación de TErminaL NETwork (Terminal de red). Es el protocolo
TCP/IP estándar para el servicio de terminal virtual propuesto por ISO. TELNET
permite el establecimiento de una conexión a un sistema remoto de tal forma que la
terminal local parece ser un terminal en el sistema remoto.
TELNET es un programa de aplicación cliente-servidor de propósito general.
Cuando un usuario quiere acceder a un programa de aplicación o utilidad localizado
en una máquina remota, pueden hacer login remoto, y es donde el cliente TELNET y
los programas de servidor entran en uso. Lo que el usuario tipea se envía al driver del
terminal donde el sistema operativo local los acepta pero no los interpreta. Los
caracteres son enviados al cliente TELNET que los transforma a un set de caracteres
universales llamados caracteres de Terminal Virtual de Red (NVT, Network Virtual
Terminal) y los entrega al stack TCP/IP local.

Los comandos o textos en este formato viajan a través de Internet y llegan al stack
TCP/IP de la máquina remota. Aquí son entregados al sistema operativo y pasado al
servidor TELNET, el cual transforma los caracteres para que puedan ser entendidos
por la computadora remota. Sin embargo, estos no pueden ser pasados directamente al
SO porque no está diseñado para recibir caracteres de un servidor TELNET, sino de
un driver de terminal. La solución es añadir un software llamado driver de
pseudo-terminal que pretende que los caracteres vienen de un terminal. De ahí el SO
los pasa al correspondiente programa de aplicación.

Terminal Virtual de Red (NVT)

El mecanismo para acceder a una computadora remota es complejo debido a que cada
computadora y SO maneja su propio set de caracteres.
Si se quiere acceder remotamente, primero debería saberse a qué tipo de computadora
se quiere conectar e instalar el emulador de terminal específico usado por esa
computadora. TELNET soluciona este problema al definir una interfaz universal,
NVT. A través de está interfaz, el cliente TELNET traduce caracteres que vienen del
terminal local y los entrega a la red. El servidor TELNET los traduce de su forma
NVT a una aceptable por la computadora remota.

Set de caracteres NVT

Utiliza dos sets: uno para datos y otro para control. Ambos de 8 bits.

- Caracteres de datos: NVT ASCII. Caracteres de 8 bits donde los bits de

menor orden son los mismos de US ASCII y el de mayor orden es 0.
- Caracteres de control: caracter de 8 bits donde el bit de mayor orden es 1.
Algunos ejemplos:
- EOF (236 - 11101100): End of file
- EOR (239 - 11101111): End of record
- BRK (243 - 11110011): Break

TELNET usa sólo una conexión TCP. El servidor usa el puerto bien conocido 23 y el
cliente usa un puerto efímero. La misma conexión es usada para enviar los datos y los
caracteres de control y esto se logra al incorporar los caracteres de control en el flujo
de datos. Para distinguir datos de control, cada secuencia de caracteres de control debe
estar precedida un caracter de control especial llamado interpret as control (IAC,
interpretar cómo control).

Por ejemplo, suponer que un usuario quiere que un servidor muestre un archivo en un
servidor remoto y tipea: cat file1. Excepto que comete un error y tipea filea en vez de
file1, por lo que el usuario borra un caracter y el resultado seria:
cat file<backspace>1
Pero el usuario no puede editar localmente así que el backspace es traducir a dos
caracteres remotodos ( IA EC), los cuáles se incorporan en la información y se envían
al servidor remoto.

SSH
Secure Shell proporciona un mecanismo para autenticar un usuario remoto, transferir
entradas desde el cliente al host y retransmitir la salida de vuelta al cliente. El servicio
se creó como un reemplazo seguro para el TELNET sin cifrar y utiliza técnicas
criptográficas para garantizar que todas las comunicaciones hacia y desde el servidor
remoto sucedan de manera encriptada.
Componentes
Posee cuatro componentes:

SSH-TRANS (Protocolo de la capa de transporte de SSH)

Como TCP no es seguro, SSH primero usa un protocolo independiente que crea un
canal seguro arriba de TCP (SSH-TRANS). Cuando el software que implementa este
protocolo es llamado, el cliente y servidor usan TCP para establecer una proconexión
insegura. Luego intercambian varios parámetros de seguridad para establecer el canal
seguro. Este protocolo provee:
- Privacidad o confidencialidad del mensaje intercambiado.
- Integridad de datos: garantía de que los mensajes intercambiados entre cliente
y servidor no serán modificados por un intruso.
- Autenticación del servidor: el cliente está seguro de que el servidor es quien
dice ser.
- Compresión de mensajes: mejora la eficiencia y hace que sea más difícil
atacar.

SSH-AUTH (Protocolo de autenticación de SSH)

Luego de establecer el canal seguro entre cliente y servidor, y de autenticar el servidor
para el cliente, SSH llama a otro software para autenticar el cliente para el servidor.

SSH-CONN (Protocolo de conexión de SSH)

Finalizada la autenticación, SSH llama a un software que implementa el tercer
protocolo, SSH-CONN. Uno de los servicios que provee es hacer multiplexing.
SSH-CONN toma el canal seguro establecido y permite que el cliente cree múltiples
canales lógicos sobre él.

Aplicación SSH
Al terminar la fase de conexión, SSH permite a programas de aplicación usar la
conexión. Cada aplicación puede crear un canal lógico y beneficiarse de una conexión
segura.
Técnicas de cifrado

Cifrado simétrico
Se utiliza una clave secreta tanto para el cifrado cómo para el descifrado de un
mensaje, tanto por el cliente como por el host durante una sesión SSH. Cualquiera con
la clave puede descifrar el mensaje. A menudo se llama clave compartida (shared
key). El proceso de creación de una clave simétrica se lleva a cabo mediante un
algoritmo de intercambio de claves.
Lo que hace que este algoritmo sea particularmente seguro es que la clave nunca se
transmite entre cliente y servidor. Estos comparten datos públicos y luego los
manipulan para calcular de forma independiente la clave secreta. Incluso si un tercero
captura los datos, no será capaz de calcular la clave porque no se conoce el algoritmo.

Cifrado asimétrico
Utiliza dos claves separadas para el cifrado y el descifrado. Estas se conocen como la
clave pública (public key) y la clave privada (private key), y juntas forman el par
de claves pública-privada (public-private key pair).
La clave pública se distribuye abiertamente y se comparte con todas las partes. Está
vinculada estrechamente con la clave privada en términos de funcionalidad, la clave
privada no se puede calcular matemáticamente desde la clave pública. La relación
entre ambas es compleja: un mensaje cifrado por la clave pública de una máquina sólo
puede ser descifrado por la misma clave privada de la máquina. Está relación
unidireccional significa que la clave pública no puede descifrar sus propios mensajes
ni nada cifrado por la clave privada. Por lo tanto, cualquier parte con la capacidad de
descifrar mensajes firmados públicamente debe poseer la clave privada
correspondiente.
Este cifrado no se usa para cifrar toda la sesión SSH. Antes de iniciar una conexión
segura, ambas partes generan pares de claves públicas-privadas temporales y
comparten sus respectivas claves privadas para producir la clave secreta compartida.
Una vez que se ha establecido una comunicación simétrica segura, el servidor utiliza
la clave pública de los clientes para generar y desafiar y transmitirla al cliente para su
autenticación. Si el cliente puede descifrar correctamente el mensaje, significa que
contiene la clave privada necesaria para la conexión. Y entonces comienza la sesión
SSH.

Hashing
Difiere de las dos anteriores en el sentido de que nunca están destinadas a ser
descifradas. Generan un valor único de una longitud fija para cada entrada que no
muestra una tendencia clara que pueda explotarse. Esto los hace prácticamente
imposibles de revertir.
Es fácil generar un hash criptográfico de una entrada dada, pero imposible de generar
la entrada del hash. Esto significa que si un cliente tiene la entrada correcta, pueden
generar el hash criptográfico y comparar su valor para verificar si poseen la entrada
correcta. SSH utiliza hashes para verificar la autenticidad de los mensajes. Esto se
hace usando HMACs, o códigos de autenticación de mensajes basados en hash. Esto
asegura que el comando recibido no se altere de ninguna manera.

Arquitectura P2P (Peer-to-Peer)

En una red entre iguales o entre pares existe una mínima (o ninguna) dependencia
de una infraestructura de servidores dedicados situados en centros de datos. En su
lugar, la aplicación explota la comunicación entre parejas de hosts conectados de
forma intermitente, conocidos cómo pares (peers), los cuales no son propiedad del
proveedor del servicio, sino que son ordenadores.
Entre las aplicaciones que utilizan esta arquitectura se incluye la compartición de
archivos (cómo BitTorrent), la aceleración de descarga con ayuda de pares (cómo
Xunlei), y la telefonía y videoconferencia por Internet (cómo Skype).

Cabe mencionar que algunas aplicaciones tienen arquitecturas híbridas, combinado

cliente-servidor y P2P. Por ejemplo, en muchas aplicaciones de mensajería instantánea, los
servidores se utilizan para hacer un seguimiento de las direcciones IP de los usuarios, pero
los mensajes de usuario a usuario se envían directamente entre los host de dichos usuarios.

Una de las ventajas de P2P es su auto-escalabilidad. Una aplicación de compartición

de archivos P2P, aunque cada par genera una carga de trabajo solicitando archivos,
también añade capacidad de servicio al sistema, distribuyendo archivos a otros pares.
También presenta una buena relación coste-prestación, ya que normalmente no
requiere una infraestructura de servidores ni un gran ancho de banda.
Sin embargo, plantean problemas de seguridad, rendimiento y fiabilidad, debido a su
naturaleza descentralizada.

BitTorrent
Es un popular protocolo P2P para la distribución de archivos. En la jerga de
BitTorrent, la colección de todos los pares que participan en la distribución de un
determinado archivo se conoce cómo torrent (torrente). Los peers de un torrent
descargan fragmentos del mismo tamaño del archivo de uno a otro (típicamente es
de 256KB). Cuando un par se une por primera vez a un torrent, no tiene fragmentos. A
lo largo del tiempo los va acumulando. A la vez que descarga fragmentos, actualiza
fragmentos en otros pares. Una vez un par ha adquirido el archivo completo, puede
abandonar el torrent, o puede permanecer y continuar suministrando fragmentos a
otros pares.

Funcionamiento
Cada torrente tiene un nodo de infraestructura denominado tracker (rastreador) que
son los que organizan la distribución de un archivo, y son los que tienen la
información necesaria para que los diferentes usuarios se conecten entre sí. Por lo
tanto, estos trackers serían como el único punto de encuentro al que los clientes deben
conectarse obligatoriamente. Cuando un par se une a un torrent, se registra mediante
el tracker y, periódicamente, informa de que todavía se encuentra allí. Así, el tracker
sigue la pista a los pares que están participando en el torrent.

Cuando empieza la descarga, lo primero que hace tu cliente de BitTorrent es

conectarse al tracker para pedirle información. El tracker proporciona una lista inicial
de peers con este archivo escogida al azar y envía las direcciones IP de estos.
Obtenida la lista, el usuario (ej, Alicia en la imagen) intenta establecer conexiones
TCP concurrentes con los pares.
Periódicamente, Alicia pregunta a cada uno de sus “vecinos” (pares con los que
conectó) por la lista de fragmentos de la que disponen. Obtenida la información,
procede a solicitar los fragmentos que ella no tiene.

Solicitando fragmentos
Para decidir qué fragmentos solicitar, se utiliza la técnica primero el menos común,
que consiste en determinar de entre los fragmentos que uno no tiene, los fragmentos
menos comunes (fragmentos con menor número de copias repetidas) entre sus
vecinos, y solicita esos primero. Así, estos fragmentos se redistribuirán más
rápidamente, consiguiendo que el número de copias sea aproximadamente igual
dentro del torrent.
Enviando fragmentos
Para determinar a qué solicitudes responder, BitTorrent utiliza un algoritmo de
intercambio inteligente donde la idea es dar prioridad a los vecinos que están
suministrando sus datos a mayor velocidad, el algoritmo de bloqueo.
Este se describe desde el punto de vista del par local, por lo que “interesado”
es interesado en el par local y “bloqueado” es bloqueado por el par local.
1) En este algoritmo, cómo máximo, 4 pares remotos pueden estar desbloqueados
e interesados a la vez.
2) Cada 10 segundos, los pares remotos interesados se ordenan de acuerdo a su
velocidad de bajada hacia el par local, y los 3 más rápidos son desbloqueados.
3) Cada 30 segundos, un par interesado adicional se desbloquea aleatoriamente.
Esto se llama desbloqueo optimista (optimistic unchoke), que tiene dos
objetivos: permite evaluar la capacidad de bajada de nuevos pares y posibilita
que los pares que no tienen fragmentos, puedan compartir su primer fragmento.

Video Streaming and CDN (Content Distribution

Network)

Streaming sobre HTTP

En los flujos multimedia HTTP, los videos se almacenan en servidores HTTP cómo
archivos normales, con URL específicos. Cuando un usuario quiere ver el video,
establece una conexión TCP, emite una solicitud GET, el servidor envía entonces el
archivo de video dentro de un mensaje de respuesta HTTP, con la máxima velocidad
que permiten los protocolos de red subyacentes y las condiciones existentes de tráfico.
En el lado del cliente, los bytes se acumulan en un buffer. Cuando superan un umbral,
la aplicación comienza la reproducción.
Los flujos HTTP presentan una carencia fundamental: todos reciben la misma
versión codificada del video, a pesar de las variaciones en cuanto a ancho de
banda disponible para cada cliente, lo que condujo al desarrollo de un nuevo tipo de
flujo de videos basado en HTTP.

DASH (Dynamic Adaptive Streaming over HTTP)

En DASH (Flujos dinámicos adaptativos sobre HTTP), el video se codifica en varias
versiones, teniendo cada versión una tasa de bits distinta y, por tanto, un nivel de
calidad diferente. Cada versión se almacena en un servidor HTTP, cada uno con su
propia URL, y además dispone de un archivo de manifiesto que indica las URL,
junto con su correspondiente tasa de bits.
El cliente solicita primero ese archivo y determina cuáles son las versiones
disponibles. dinámicamente segmentos de video de unos pocos segundos de duración.
Cuando el ancho de banda disponible es grande, el cliente selecciona de forma natural
los segmentos de una versión de alta tasa de bits. Caso contrario, selecciona una
versión con menor tasa de bits.
Así, DASH permite que el cliente cambie libremente entre distintos niveles de calidad.

CDN (Redes de distribución de contenido)

Actualmente, muchas empresas de vídeo a través de Internet distribuyen a la carta
flujos de vídeos de múltiples Mbps a millones de usuarios diariamente, y enviar éste
tráfico a ubicaciones de todo el mundo al mismo tiempo constituye un desafío.
La solución más directa sería construir un único centro de datos masivo donde
almacenar los vídeos y enviar los flujos de vídeo desde allí a los clientes. Pero esto
tiene tres problemas principales:
1) Distancia entre el cliente y el centro de datos: mientras mayor sea la
distancia, probablemente atravesará muchos ISP, tal vez en continentes
distintos. Si uno de esos enlaces proporciona tasa de transferencia inferior a la
velocidad a la que se consume el vídeo, la tasa de transferencia extremo a
extremo también será inferior, y provocará congelamientos de la imagen.
2) Múltiples copias: un vídeo popular será enviado muchas veces a través de los
mismos enlaces de comunicaciones lo que provoca desperdicio de ancho de
banda y que la propia empresa pague a su ISP por enviar los mismo bytes una
y otra vez.
3) Único punto de fallo: si se cae el centro de datos o sus enlaces con Internet, la
empresa no podrá distribuir ningún flujo de vídeo.

Para enfrentar esto, la mayoría de las empresas utilizan redes de distribución de

contenido (CDN), la cual gestiona servidores situados en múltiples ubicaciones
geográficamente distribuidas, almacena copias de los vídeos (y otros tipos de
contenido web) en sus servidores y trata de dirigir cada solicitud de usuario a una
ubicación de la CDN que proporcione la mejor experiencia de usuario posible.

Funcionamiento
Cuando se indica al navegador del host de un usuario que extraiga un vídeo concreto
(identificado mediante URL), la CDN debe interpretar la solicitud para determinar
un clúster de servidores de la CDN adecuado para ese cliente y redirigir la solicitud a
un servidor situado en dicho clúster. La mayoría de las CDN aprovechan DNS para
hacer esto.
Ejemplo: Un proveedor de contenido (NetCinema) utiliza una empresa proveedora de
servicios CDN (KingCDN). En las páginas de NetCinema, cada vídeo tiene una URL que
incluye la palabra “video” y un ID unívoco (Transformers →
http://video.netcinema.com/6Y7B23V)
1) El usuario visita la página de NetCinema.
2) El usuario hace clic sobre el link de Transformers. Allí, el host del usuario
envía una solicitud DNS preguntando por video.netcinema.com.
3) El servidor DNS local (LDNS), retransmite la solicitud a un servidor DNS
autoritativo de NetCinema, que observa la cadena “vídeo”. Para “transferir” la
consulta DNS a KingCDN, el servidor autoritativo envía al LDNS un nombre
de host perteneciente al dominio de KingCDN (por ejemplo,
a1105.kingcdn.com).
4) La consulta entra en la infraestructura DNS privada de KingCDN. LDNS envía
una segunda consulta, preguntando por a1105.kingcdn.com y el sistema
devuelve al LDNS las direcciones IP de un servidor de contenido de KingCDN.
Es aquí donde se específica el servidor CDN desde el cual recibirá el cliente su
contenido.
5) El LDNS reenvía al host del usuario la dirección IP del nodo CDN encargado
de servir el contenido.
6) Recibida la dirección, se establece una conexión TCP directa con el servidor
situado en dicha dirección IP y transmite una solicitud GET HTTP para el
video deseado. Si se usa DASH, el servidor enviará primero al cliente un
archivo de manifiesto con una lista de URL, uno para cada versión del vídeo, y
el cliente selecciona dinámicamente segmentos de las distintas versiones.