Conceptos clave de la capa de aplicación

Introducción a la capa de aplicación en redes informáticas

La capa de aplicación es la capa más alta del modelo OSI y del modelo TCP/IP. En ella se encuentran los protocolos que permiten a los usuarios finales interactuar con la red: HTTP, FTP, DNS, SMTP, entre otros. Este curso aborda los conceptos clave que aparecen en los exámenes de informática y redes, ofreciendo explicaciones claras, ejemplos prácticos y buenas prácticas para optimizar el rendimiento y la seguridad de tus aplicaciones.

Modelos cliente‑servidor vs. peer‑to‑peer (P2P)

Definición de cada modelo

En el modelo cliente‑servidor, los clientes solicitan recursos a uno o varios servidores dedicados que están diseñados para estar siempre disponibles. En contraste, el modelo peer‑to‑peer distribuye la carga entre los propios usuarios (peers), sin un servidor central de alta disponibilidad.

Diferencia principal de disponibilidad

La diferencia esencial radica en que en cliente‑servidor siempre hay un servidor siempre disponible, mientras que en P2P no existe un servidor de alta disponibilidad; cada peer puede actuar como cliente y como servidor de forma temporal.

• Ventaja del modelo cliente‑servidor: fiabilidad y control centralizado.
• Ventaja del modelo P2P: escalabilidad y tolerancia a fallos.

Servicios de transporte y requisitos de throughput

¿Qué es el throughput?

El throughput es la cantidad de datos que una conexión puede transmitir por unidad de tiempo. En aplicaciones de streaming, un mínimo de 5 Kbps es necesario para que el video se perciba como fluido.

Tipo de servicio recomendado

Para garantizar ese mínimo, se debe priorizar un servicio que garantice un throughput mínimo aunque sea elástico. Los protocolos de capa de transporte como TCP pueden ofrecer garantías de ancho de banda mediante mecanismos de control de congestión, mientras que UDP no asegura throughput.

• TCP: confiable, con control de flujo y congestión.
• UDP: rápido pero sin garantías de entrega ni de ancho de banda.

HTTP no‑persistente y cálculo de RTT

Conceptos básicos

En una conexión HTTP no‑persistente, cada objeto requiere una nueva conexión TCP. El proceso típico incluye:

1. Establecimiento de la conexión (handshake de tres vías).
2. Envío de la petición HTTP.
3. Recepción de la respuesta y cierre de la conexión.

Cálculo de RTT para un objeto de 10 KB

Si el cliente ya conoce la URL, se necesitan dos RTT más el tiempo de transferencia del objeto:

• Primer RTT: handshake TCP (SYN, SYN‑ACK, ACK).
• Segundo RTT: envío de la petición y recepción de la respuesta.
• Tiempo de transferencia: depende del ancho de banda disponible.

Ventajas de HTTP/2 sobre HTTP/1.1

Problema del head‑of‑line (HoL)

En HTTP/1.1, la multiplexación de peticiones en una única conexión TCP provoca bloqueo de cabeza: si un paquete se retrasa, todas las peticiones posteriores quedan en espera.

Solución de HTTP/2

HTTP/2 divide los objetos en frames y los envía intercalados, reduciendo el bloqueo. Además, permite la multiplexación simultánea de múltiples flujos dentro de la misma conexión, mejorando la latencia y el rendimiento.

• Uso de binary framing para mayor eficiencia.
• Compresión de encabezados con HPACK.
• Prioridad de flujos para optimizar la entrega.

Resolución iterativa de DNS

¿Cómo funciona?

En la resolución iterativa, el cliente consulta a un servidor DNS y este le indica cuál es el siguiente servidor que debe consultar. Cada paso devuelve el nombre del servidor que debe ser consultado a continuación, no la dirección IP final.

Pasos típicos

1. El cliente pregunta al servidor raíz.
2. El servidor raíz responde con la dirección del servidor TLD.
3. El cliente consulta al servidor TLD, que devuelve la dirección del servidor autoritativo.
4. Finalmente, el servidor autoritativo entrega la dirección IP solicitada.

Uso del método HTTP GET en formularios

¿Dónde se incluyen los datos?

Al usar GET, los datos del formulario se envían en la línea de petición después del signo de interrogación en la URL. No se utilizan el cuerpo del mensaje ni cookies para este propósito.

Resumen de puntos clave

• Los datos aparecen después del carácter ? en la URL.
• Son visibles en los logs y pueden ser almacenados en caché.
• Ideal para consultas que no modifican el estado del servidor.

Cómo recordarlo

• Mnemotécnico: “GET → Go En Texto”.
• Visualiza la URL como una ruta que lleva la información.

Códigos de estado HTTP más comunes

301 Moved Permanently

El código 301 Moved Permanently indica que el recurso solicitado ha sido trasladado de forma permanente a una nueva URL. Los navegadores suelen actualizar automáticamente la dirección y los motores de búsqueda transfieren la autoridad del enlace.

Otros códigos relevantes

• 200 OK – petición exitosa.
• 400 Bad Request – sintaxis incorrecta.
• 404 Not Found – recurso no encontrado.

FTP activo y puertos de datos

Modo activo

En FTP activo, el cliente abre un puerto aleatorio y envía el comando PORT al servidor. El servidor, a su vez, inicia la conexión de datos desde su puerto 20 (puerto de datos) hacia el puerto especificado por el cliente.

Resumen rápido

• Puerto de control: 21.
• Puerto de datos del servidor: 20.
• El servidor actúa como cliente en la transferencia de datos.

Conclusión y buenas prácticas

Dominar los conceptos de la capa de aplicación es esencial para diseñar sistemas robustos y eficientes. Recuerda:

• Elegir el modelo cliente‑servidor o P2P según los requisitos de disponibilidad.
• Priorizar servicios de transporte que garanticen el throughput necesario.
• Utilizar HTTP/2 para reducir el head‑of‑line y mejorar la velocidad.
• Comprender la resolución iterativa de DNS para depurar problemas de nombres.
• Aplicar correctamente los métodos HTTP (GET vs. POST) y los códigos de estado.
• Configurar adecuadamente los puertos en FTP activo y pasivo.

Con estos conocimientos, estarás preparado para enfrentar preguntas de examen y, lo que es más importante, para implementar soluciones de red profesionales.