Capítulo 2: La Capa de Aplicación Flashcards
Capa de Aplicación
¿Cuáles son las dos arquitecturas de red predominantes en Internet? Explicar las características de cada una. Dar un ejemplo de una aplicación que use ambas arquitecturas.
Se tienen dos arquitecturas de red predominantes en Internet, y son: cliente-servidor y peer-to-peer.
- Cliente-servidor: los clientes no interactúan entre sí, sino que lo hacen a través del servidor. El servidor tiene una dirección IP fija y conocida, tal que un cliente siempre puede contactarlo. En general, no alcanza con un sólo servidor, y se usan data centers.
-
Peer-to-peer (P2P): los clientes (peers) pueden comunicarse entre sí, sin depender de los servidores. Los peers son los dispositivos controlados por los usuarios (smartphones, tablets, notebooks).
Ejemplos: BitTorrent, Skype.
Su principal ventaja es la auto-escalabilidad, dado que cada host suma capacidad de servicio a la aplicación al distribuir archivos para otros peers. También se dice que es eficiente económicamente ya que no requiere de una cantidad significativa de servidores y ancho de banda.
Las desventajas son que tiene problemas de seguridad, reliability y performance.
Los servicios de mensajería usan ambas arquitecturas, donde las direcciones IP se trackean mediante servidores, pero los mensajes son enviados directamente de usuario a usuario.
¿De qué consisten las aplicaciones en la red? ¿Qué interfaz usan los procesos para enviar y recibir mensajes de la red?
Las aplicaciones en la red consisten de pares de procesos que se envían mensajes entre sí a través de la red.
Por ejemplo, un cliente browser intercambia mensajes con un servidor, una app P2P transfiriendo archivos de un peer a otro, etc.
Los procesos utilizan sockets, que son la interfaz entre la capa de aplicación y la capa de transporte dentro de un host. También se los puede pensar como la API entre la aplicación y la red.
¿Qué 2 aspectos del socket están en manos del desarrollador de la aplicación?
Hay dos aspectos del socket que están en manos del desarrollador de la app. Estos son:
- La elección del protocolo de transporte.
- La capacidad de ajustar algunos parámetros de la capa de transporte, como:
- El tamaño del buffer
- El tamaño de los segmentos.
¿Qué datos se deben tener para identificar al proceso recibido en el proceso de destino?
Para identificar al proceso recibido en el proceso de destino, se necesita la dirección del host (IP) y un identificador del proceso en el host de destino (puerto).
¿Qué 4 servicios pueden ofrecer los protocolos de capa de transporte a las aplicaciones?
Los protocolos de capa de transporte pueden ofrecer 4 servicios a las aplicaciones:
- [TRA]
Transferencia de datos confiable (RDT)
: garantiza la llegada y la integridad de los datos. - [CA]
Caudal (throughput)
: garantizar una tasa mínima a la que el proceso de origen puede entregarle datos al proceso receptor. - [SIN]
Sincronización
: permite garantizar un umbral de demora en la transmisión de los datos (que ningún bit tarde más dex
ms en llegar a destino). - [SE]
Seguridad
: permite encriptar la información, chequear que la información no haya sido alterada en el camino, autenticar los extremos, etc.
¿Qué define un protocolo de la capa de aplicaciones y qué protocolos de transporte provee Internet?
Los protocolos de la capa de aplicaciones define cómo intercambiar mensajes entre procesos. En particular:
- [Tipo] Los tipos de mensajes a intercambiar.
- [Forma] La sintaxis de los mensajes.
- [Contenido] La información que se envía en el mensaje.
- [Cómo y Cuándo] Las reglas para determinar a un proceso cuándo y cómo enviar y recibir mensajes.
En un nivel inferior, los protocolos de transporte que se proveen son TCP y UDP.
¿Qué servicios provee TCP?
TCP provee 3 servicios:
- Orientado a la conexión: establece una conexión entre las dos entidades (handshake) antes de que empiece el flujo de datos.
- Reliable data transfer: garantiza la llegada y la integridad de los datos.
- Control de congestión para no sobrecargar la red.
¿Qué servicios provee UDP?
UDP provee servicios mínimos.
- Sin conexión: no tiene handshake, empieza a enviar los datos de una.
- Unreliable data transfer: podría pasar que los datos lleguen en distinto orden al que se enviaron.
- No tiene un mecanismo de control de congestión.
- ¿Qué es HTTP?
- ¿Dónde se implementa?
- ¿Qué se define en HTTP?
- ¿Qué protocolo de transporte usa HTTP?
- ¿Qué significa que HTTP sea un protocolo sin estado?
- ¿Cómo se hace para identificar a un usuario para administrar el acceso si no se mantiene estado?
HTTP es el protocolo de la capa de aplicación de la web. Se implementa tanto en el cliente como en el servidor, que interactúan entre sí intercambiando mensajes HTTP. HTTP define la estructura de los mensajes y cómo deben enviarlos tanto el cliente como el servidor.
Básicamente, HTTP define cómo los clientes web deben solicitar páginas web al servidor y cómo los servidores deben enviar dichas páginas al cliente.
HTTP usa TCP como protocolo de transporte.
Que HTTP sea un protocolo sin estado significa que el servidor responde solicitudes sin almacenar ningún tipo de información sobre el cliente. Para identificar usuarios y administrar el acceso se utilizan las cookies
, que están compuestas por:
- un header en el mensaje de solicitud HTTP
- un header en el mensaje de respuesta HTTP
- un archivo que se almacena en el host pero lo controla el browser del usuario
- una base de datos en el backend del sitio web.
¿Cuándo una conexión TCP es persistente?
¿Quién decide hacerlo así?
¿Qué desventajas presentan las conexiones no persistentes?
Una conexión TCP es persistente
cuando todas las solicitudes se realizan bajo la misma conexión TCP. Si se utilizan conexiones separadas por cada par de request/response, se dice que es una conexión no persistente.
Esta es una decisión que debe tomar el desarrollador de la aplicación, y se indica en el campo connection
del mensaje HTTP (Connection: close => se cierra la conexión después de responder).
Las desventajas de las conexiones no persistentes son:
- tiene que crearse y mantenerse una nueva conexión por cada objeto solicitado, alocando buffers y variables, resultando costoso.
- Hay una demora de 2RTT por cada objeto que se solicita (el handshake, y el par request/response).
En conexiones persistentes, se deja abierta la conexión y el servidor HTTP la cierra luego de un tiempo sin recibir nada.
¿Cómo se compone una request HTTP?
Una request HTTP se compone de la primer línea, los headers y el body.
La primer línea es la request line
. Contiene 3 cosas:
- el método (GET, POST, PUT, DELETE, HEAD)
- la URL
- la versión de HTTP.
Lo siguiente son los 4 headers.
-
Host
indica dónde reside el objeto -
Connection
indica si debe cerrarse la conexión después de responder -
User-Agent
es el browser de la solicitud -
Accept-language
indica el idioma preferente del objeto
Al final se encuentra el body.
¿Cómo se compone una respuesta HTTP?
Una respuesta HTTP se compone de una primer línea, los headers y el body.
La primer línea contiene:
- la versión
- el código de estado
- una frase de estado
Lo siguiente son los 6 headers:
- Connection: persistencia de la conexión
- Fecha
- Fecha de última modificación: se usa para la caché de objetos
- Tamaño: número de bytes en el objeto
- Tipo: tipo de contenido
- Server: tipo de servidor
Al final se encuentra el body, que contiene al propio objeto solicitado.
¿Qué es una caché web (o servidor proxy)? ¿Cómo funciona? ¿Qué ventajas y defectos tiene?
Una caché web (o servidor proxy) es un servidor de almacenamiento que responde solicitudes HTTP en nombre de un servidor web de origen. Lo que hace es mantener copias de los objetos más recientemente consultados. Es configurable desde el browser.
Funcionamiento:
1. El browser establece una conexión TCP con la caché y le solicita algún objeto.
2. La caché verifica si tiene almacenada una copia del objeto solicitado. Si la tiene, la devuelve en una respuesta HTTP.
3. Si la caché no tiene una copia almacenada, establece una conexión TCP con el servidor original y le envía una solicitud.
4. Cuando recibe la respuesta del servidor, guarda una copia del objeto y envía otra copia al cliente.
Ventajas:
- Reduce el tiempo de respuesta a solicitudes.
- Puede reducir significativamente el tráfico en los enlaces de acceso, llevando a reducir costos porque ayuda a mantener bajo el ancho de banda.
Defecto: podría pasar que el objeto cacheado no esté actualizado. Para eso existe el conditional GET, un mecanismo que permite a la caché verificar que sus objetos almacenados estén al día agregando un header If-Modified-Since a la solicitud con el método GET, y pidiendo el objeto al servidor sólo si el objeto fue modificado desde la fecha indicada en el header.
¿De qué 3 elementos se compone el sistema de mails?
El sistema de mails se compone por tres elementos:
- user agents
- mail servers
- El Simple Mail Transfer Protocol (SMTP).
User agents son los agentes que permiten leer, reenviar, responder, guardar y redactar mensajes; por ejemplo Microsoft Outlook.
El protocolo SMTP usa el servicio de transferencia de datos confiable de TCP para transferir mails del servidor de mails del sender al servidor del mails del recipient.
¿Cómo funciona el SMTP cuando se quiere enviar un mail de una casilla a otra? ¿En qué se diferencian HTTP y SMTP?
Cuando se quiere enviar un mail de una casilla a otra, el SMTP funciona en 3 pasos:
- El cliente SMTP establece una conexión TCP al puerto 25 del servidor SMTP. Si el servidor está caído, vuelve a intentar más tarde.
- Una vez establecida la conexión, cliente y servidor hacen un hand-shaking donde el cliente indica el mail del sender y del recipient.
- El cliente envía el mensaje.
Se repite el proceso si el cliente necesita enviar más mensajes, sino se cierra la conexión.
Las diferencias entre HTTP y SMTP son:
- HTTP es un pull protocol, la conexión la inicia el cliente que quiere recibir algo. SMTP es un push protocol, el mail server inicia la conexión TCP para enviarle algo a otro mail server.
- SMTP requiere que el cuerpo del mensaje esté en formato 7-bit ASCII.
- HTTP devuelve cada objeto encapsulado en una respuesta distinta, mientras que SMTP devuelve todo en un mismo mensaje.