La capa de aplicación

Una aplicación de red consta de programas que se ejecutan en sistemas terminales: teléfonos, portátiles y servidores. Sus procesos intercambian mensajes a través de la red. Los encaminadores y conmutadores reenvían los paquetes; no necesitan que se instale un nuevo programa de aplicación cada vez que alguien crea un servicio nuevo.

Dos formas de repartir el trabajo

Una arquitectura de aplicación describe cómo divide la aplicación el trabajo entre los sistemas terminales. Es independiente de la arquitectura por capas de la red. El desarrollador elige dónde se ejecutan los programas y confía en que la red existente los conecte.

En un diseño cliente-servidor, los clientes contactan con un servidor siempre encendido en una dirección conocida. Un navegador solicita un documento a un servidor web, que lo devuelve. Otros navegadores no necesitan estar conectados para que funcione ese intercambio. Un servicio popular puede distribuir la función de servidor entre miles de máquinas en centros de datos; un único nombre público puede representar a ese grupo. Los equipos, la electricidad, la refrigeración y las conexiones a internet cuestan dinero.

Un diseño entre pares, o P2P, permite que los dispositivos de los usuarios intercambien datos directamente. Un par puede solicitar un fragmento de archivo y también subir fragmentos que ya tiene. Los pares pueden desconectarse o cambiar de dirección, por lo que la aplicación debe encontrar pares disponibles y seguir funcionando cuando cambia la participación.

Sigue un intercambio

Supón que un grupo de investigación distribuye un conjunto de datos grande. En un diseño cliente-servidor, cada investigador descarga una copia del servidor del grupo. Diez investigadores nuevos suponen diez copias más que ese servidor debe subir. En un diseño P2P, los investigadores que ya tienen algunos fragmentos se los envían a los recién llegados. Cada investigador que se incorpora puede añadir tanto capacidad como demanda. Esto es autoescalabilidad: los recursos de la aplicación crecen con la participación.

La autoescalabilidad sigue dependiendo de contribuciones útiles. Un par con un enlace de subida lento añade menos capacidad que uno con un enlace rápido. Muchos enlaces domésticos son asimétricos: la descarga es más rápida que la subida. Un par que se desconecta no aporta nada mientras está fuera de línea. El software P2P también debe proteger a los participantes frente a pares no fiables y animar a los usuarios a subir datos en vez de limitarse a obtenerlos.

Coordinación central y transferencia directa

Un diseño híbrido combina la coordinación de un servidor con la transferencia de datos P2P. Un rastreador de BitTorrent informa a un par sobre otros pares; no tiene que enviar el archivo. Del mismo modo, un servicio de llamadas puede localizar a los participantes mediante un servidor, permitir que sus dispositivos intercambien contenidos multimedia directamente y usar un servidor de retransmisión cuando no hay un trayecto directo disponible. Clasifica el trayecto que transporta los datos por separado del trayecto que establece la conexión.

Las palabras cliente y servidor también describen funciones en un intercambio individual. Si el par Mira inicia una solicitud al par Leo, Mira es el cliente y Leo es el servidor de ese intercambio. Pueden invertir sus funciones un momento después. P2P elimina la dependencia de servidores de contenido dedicados; no elimina las funciones de iniciar y responder.

Un programa de aplicación en ejecución es un proceso. Los procesos de distintos sistemas terminales intercambian mensajes mediante sockets, las interfaces de software entre las capas de aplicación y transporte. El código de la aplicación decide qué significa el mensaje; el servicio de transporte lleva sus bytes o datagramas.

Encuentra el proceso receptor

Una dirección IP identifica un sistema terminal, pero este puede ejecutar muchos servicios. Un número de puerto identifica un extremo de transporte en él. Para contactar con un servicio HTTPS en 203.0.113.10, un cliente normalmente se dirige al puerto 443. Su propio sistema operativo suele asignarle un puerto de origen temporal o efímero.

Los puertos son valores de 16 bits, de 0 a 65 535. Los puertos de sistema ocupan del 0 al 1023, los puertos registrados del 1024 al 49 151 y los puertos dinámicos del 49 152 al 65 535. Entre los puertos de servicio habituales están HTTP 80, HTTPS 443, transferencia SMTP 25 y DNS 53. Un puerto forma parte del direccionamiento; no indica que el tráfico esté cifrado o sea fiable.

Acuerda los mensajes

Un protocolo de la capa de aplicación define los tipos de mensajes, la sintaxis, la semántica y las reglas de intercambio. Los tipos distinguen una solicitud de una respuesta. La sintaxis describe los campos y separadores. La semántica indica a cada participante qué significan esos campos. Las reglas de intercambio determinan cuándo envía un proceso un mensaje y cómo responde el receptor. Las especificaciones públicas, a menudo RFC, permiten que se comuniquen programas escritos por distintos desarrolladores.

Un protocolo es un componente de una aplicación. La web también necesita navegadores, servidores y documentos. Definir HTTP por sí solo no crea un navegador ni decide el aspecto de su interfaz.

Relaciona el servicio con la necesidad

Considera cuatro necesidades: entrega correcta, rendimiento suficiente, retardo aceptable y seguridad. Un archivo adjunto de correo necesita todos los bytes. Una llamada de voz puede tolerar cierta pérdida de contenido multimedia, pero se ve afectada si el audio antiguo llega demasiado tarde. Un vídeo almacenado necesita un rendimiento sostenido cercano a su tasa de bits codificada, mientras que una descarga elástica puede usar la tasa disponible.

TCP incluye control de flujo para proteger al receptor y control de congestión para reducir la sobrecarga de la red. No proporciona un ancho de banda mínimo ni un plazo de entrega. UDP por sí mismo no añade fiabilidad ni control de congestión. Elegirlo no elimina la congestión del trayecto.

Por ejemplo, un juego que envía posiciones 30 veces por segundo produce una actualización reciente aproximadamente cada 33 ms. Puede usar UDP para que una actualización perdida se sustituya por otra más nueva sin esperar a que se retransmita. El chat del juego sigue necesitando una entrega fiable, ya sea mediante TCP o mediante la fiabilidad añadida por su propio protocolo.

Añade seguridad a la pila

Ni TCP ni UDP por sí solos cifran los datos de la aplicación. HTTP/1.1 y HTTP/2 suelen usar TLS sobre TCP para HTTPS. TLS añade confidencialidad, integridad y autenticación del servidor. HTTP/3 usa QUIC sobre UDP; QUIC proporciona fiabilidad, control de congestión y TLS 1.3 integrado. Por tanto, el vídeo almacenado que se entrega mediante HTTP usa TCP o QUIC, mientras que las llamadas interactivas suelen transportar el contenido multimedia mediante UDP.

Una página web suele estar formada por varios objetos, cada uno con su propia URL. El HTML base indica las imágenes, los scripts y otros archivos. En https://www.example.org/docs/intro.html, el esquema es https, el sistema terminal es www.example.org y la ruta es /docs/intro.html.

Lee una solicitud y una respuesta

HTTP sigue intercambios de solicitud y respuesta. Una solicitud HTTP/1.1 comienza con un método, una ruta y una versión:

GET /docs/intro.html HTTP/1.1
Host: www.example.org
Connection: close

La línea de solicitud y las líneas de cabecera terminan con CRLF. Una línea en blanco termina las cabeceras y después puede aparecer un cuerpo opcional. Host es obligatorio en HTTP/1.1 porque varios sitios pueden compartir una dirección de servidor. Connection: close solicita el cierre después de la respuesta.

GET obtiene un objeto. HEAD solicita las cabeceras de su respuesta sin el cuerpo. POST envía datos en el cuerpo de una solicitud; un GET también puede llevar valores de formulario en la cadena de consulta de su URL. PUT almacena un objeto en una URL especificada y DELETE elimina uno.

La respuesta comienza con una línea de estado como HTTP/1.1 200 OK, seguida de cabeceras, una línea en blanco y el cuerpo. Content-Type identifica la representación; Content-Length indica su longitud en bytes. Las clases de estado son 1xx información, 2xx éxito, 3xx redirección, 4xx error del cliente y 5xx error del servidor. Un 301 apunta a una nueva URL en Location; un 304 permite reutilizar una copia almacenada en caché. Un 404 significa que el servidor respondió que no se encontró el objeto solicitado, no que el servidor fuera inaccesible. Otros códigos útiles son 400, 500 y 505.

HTTP no tiene estado: cada solicitud puede entenderse sin las solicitudes anteriores. Un sitio web puede mantener el estado de inicio de sesión o del carrito por encima de HTTP. Un GET normal repetido puede devolver el objeto de nuevo, mientras que una solicitud condicional puede validar una copia guardada.

Cuenta los tiempos de ida y vuelta

Para un objeto en una nueva conexión TCP, cuenta un RTT para establecer la conexión y otro para la solicitud y el comienzo de la respuesta. Después añade el tiempo de transmisión del objeto. Con un RTT de 30 ms, un tamaño de 500 kB y una tasa de 50 Mbps:

El total es 60 ms más 80 ms, o 140 ms. Este modelo omite DNS, TLS y el tiempo de procesamiento. Un intercambio de establecimiento completo de TLS 1.3 sobre la nueva conexión TCP añade otro RTT.

Reutiliza o vuelve a abrir la conexión

Una conexión no persistente transporta un objeto. Una conexión persistente puede transportar solicitudes posteriores sin otro establecimiento TCP. La persistencia es la opción predeterminada en HTTP/1.1, aunque las conexiones inactivas terminan por cerrarse.

Para un objeto HTML y ocho imágenes pequeñas, con un RTT de 20 ms y tiempos de transmisión insignificantes:

Las solicitudes de imágenes dependen de recibir el HTML. Incluso con la obtención en paralelo, no pueden comenzar antes de que se conozcan sus URL. Cuenta esas etapas de dependencia antes de contar los intercambios de establecimiento. Los navegadores HTTP/1.1 suelen usar varias conexiones por sistema terminal; la transmisión en cadena es un modelo de tiempos, no un requisito para la persistencia.

Las solicitudes HTTP son independientes, pero una tienda puede recordar un carrito. Un navegador también puede reutilizar una imagen en vez de descargarla de nuevo. Las cookies permiten el reconocimiento entre solicitudes; las cachés permiten reutilizar respuestas.

Sigue una cookie

En una primera visita, shop.example.com crea una entrada en la base de datos para un visitante y devuelve Set-Cookie: id=1678. El navegador guarda ese valor. Las solicitudes posteriores que coinciden incluyen Cookie: id=1678, lo que permite al servidor buscar el carrito. La cookie es un dato, no código ejecutable, y el propio carrito puede permanecer en la base de datos del servidor.

Los atributos de una cookie controlan su uso. Expires o Max-Age establece un tiempo de vida; una cookie sin ninguno de los dos es una cookie de sesión. Domain y Path restringen las solicitudes a las que se aplica. Secure restringe su envío a HTTPS, HttpOnly impide el acceso mediante scripts de la página y SameSite controla el envío en contextos entre sitios. La restauración de sesión puede conservar las cookies de sesión cuando un navegador restaura una sesión anterior.

Las cookies de origen pertenecen al sitio visitado. Un servicio de terceros integrado puede usar cookies en distintos sitios para reconocer un navegador. Safari bloquea las cookies de terceros de forma predeterminada; Firefox las separa por sitio; Chrome ofrece controles al usuario y las bloquea en el modo de incógnito. Las normas de la Unión Europea exigen consentimiento para las cookies que no son estrictamente necesarias para prestar un servicio solicitado.

Sigue una solicitud con caché

Una caché web almacena respuestas HTTP. Un navegador tiene su propia caché. Un proxy de caché se sitúa entre los clientes y los servidores de origen: sirve directamente un acierto de caché o, ante un fallo, obtiene, almacena y reenvía una respuesta. Actúa como servidor frente al navegador y como cliente frente al origen. Un proxy puede existir sin almacenar en caché.

Un acierto cercano reduce el retardo, la carga del origen y el tráfico del enlace de acceso. Para 90 solicitudes por segundo de 1 Mbit cada una en promedio, el tráfico ofrecido es de 90 Mbps. En un enlace de acceso de 100 Mbps, la intensidad de tráfico es 0,9, un valor con el que las colas pueden crecer mucho. Una tasa de aciertos del 40 % deja que el 60 % atraviese el enlace: 54 Mbps y una intensidad de 0,54. Si los aciertos tardan 10 ms y los fallos 200 ms, el tiempo medio de respuesta es:

Este cálculo de tráfico supone que los grupos de aciertos y fallos tienen el mismo tamaño medio de objeto. Una tasa de aciertos medida solo por el número de solicitudes no tiene por qué ser igual a la fracción de bytes ahorrados cuando los tamaños de los objetos difieren.

Comprueba la vigencia antes de reutilizar

Un GET condicional envía If-Modified-Since con una fecha de modificación guardada o If-None-Match con una ETag guardada. Un objeto que no ha cambiado produce 304 Not Modified sin cuerpo del objeto. La caché reutiliza su copia. Un objeto que ha cambiado produce 200 OK con el reemplazo. La validación ahorra la transmisión del cuerpo, pero sigue requiriendo un viaje de ida y vuelta al origen.

Un proxy compartido normalmente no puede inspeccionar el contenido de una conexión HTTPS que lo atraviesa. Las cachés de los navegadores y los servidores CDN que actúan en nombre de un sitio pueden almacenar contenido en los extremos donde esas respuestas están disponibles en forma legible.

Las versiones de HTTP mantienen el significado de los métodos, estados, campos y URL. Un 404 sigue significando que no se encontró el recurso solicitado. Lo que cambia es cómo viajan las solicitudes y las respuestas: HTTP/1.1 usa mensajes de texto, mientras que HTTP/2 y HTTP/3 usan tramas binarias.

Permite que avancen las respuestas pequeñas

En una conexión HTTP/1.1, las respuestas ordenadas pueden hacer que un objeto pequeño espere detrás de uno grande. Esto es el bloqueo de cabecera de cola en la capa de aplicación. Abrir varias conexiones TCP reduce esa espera, pero supone establecimientos adicionales y da a la página varias conexiones que compiten entre sí y están sujetas al control de congestión.

HTTP/2 divide los mensajes en tramas y asigna un flujo a cada intercambio de solicitud y respuesta. El emisor intercala tramas de distintos flujos en una conexión TCP. La compresión de cabeceras, llamada HPACK, reduce los datos repetidos de los campos. Las prioridades pueden orientar qué respuestas se atienden primero.

Para una comparación simplificada, una respuesta grande tiene 1000 tramas y ocho pequeñas tienen dos tramas cada una. Envía una trama por intervalo de tiempo. Enviar primero la respuesta grande hace que las respuestas pequeñas terminen entre los intervalos 1002 y 1016, con una media de 1009. Enviar por turnos una trama de cada flujo que no ha terminado permite que las respuestas pequeñas terminen en los intervalos 11 a 18, con una media de 14,5. La respuesta grande termina en el intervalo 1016. La intercalación cambia los tiempos de finalización sin aumentar la tasa de transmisión del enlace.

HTTP/2 también especificó el envío anticipado del servidor, que envía contenido antes de una solicitud. Los principales navegadores lo han desactivado. En su lugar, una respuesta 103 Early Hints señala recursos para que el navegador pueda empezar a solicitarlos.

Encuentra el punto de bloqueo restante

TCP entrega un solo flujo ordenado de bytes. Si faltan bytes, los posteriores esperan a su recuperación incluso cuando contienen tramas de otro flujo HTTP/2. HTTP/2 elimina el bloqueo por el orden de las respuestas, pero conserva este bloqueo en la capa de transporte.

HTTP/3 asigna HTTP a QUIC, un protocolo de transporte que funciona sobre UDP, y comprime las cabeceras con QPACK. QUIC proporciona flujos fiables, control de flujo y de congestión y seguridad TLS 1.3. Cada flujo tiene su propio orden de entrega. Los datos que faltan en un flujo no impiden, por sí solos, la entrega de datos ya recibidos en otro. El control de congestión compartido y las dependencias de la aplicación aún pueden afectar a varios flujos.

QUIC usa identificadores de conexión para que una conexión pueda sobrevivir a un cambio de dirección IP, como al pasar de Wi-Fi a una red celular. Su implementación puede actualizarse junto con una biblioteca de la aplicación, lo que evita el lento despliegue de cambios en TCP en los sistemas operativos y los dispositivos intermedios de red.

Compara una conexión nueva

Con un RTT de 50 ms y sin costes de DNS ni de procesamiento, TCP más TLS 1.3 tarda dos RTT antes de que salga la primera solicitud HTTP/2. Una primera respuesta comienza después de unos 150 ms. QUIC combina el establecimiento del transporte y de la seguridad en un RTT, por lo que una respuesta HTTP/3 puede comenzar después de unos 100 ms. Las conexiones QUIC reanudadas pueden usar datos 0-RTT, pero el riesgo de repetición limita qué solicitudes pueden enviarse de forma segura por anticipado.

Los navegadores pueden descubrir HTTP/3 mediante Alt-Svc o registros DNS HTTPS. Si UDP está bloqueado, pueden recurrir a HTTP sobre TCP. HTTP/3 sigue siendo fiable porque QUIC proporciona fiabilidad por encima de UDP.

Un nombre como www.example.org resulta cómodo para una persona. Una conexión necesita una dirección IP. El sistema de nombres de dominio, o DNS, es tanto la base de datos distribuida de registros de nombres como el protocolo de aplicación que se usa para consultarla. Normalmente utiliza el puerto 53 y funciona de forma independiente de HTTP.

Divide el trabajo de resolución de nombres

Lee www.example.org. de derecha a izquierda: raíz, org, example y después www. El punto final representa la raíz y suele omitirse en la escritura cotidiana. Un servidor centralizado para todos los nombres crearía un punto de fallo, un cuello de botella de tráfico y trayectos largos para los clientes lejanos.

Los servidores raíz remiten a los resolutores a los servidores de dominio de nivel superior. Los servidores TLD los remiten a los servidores autoritativos de los dominios subordinados al TLD. Los servidores autoritativos publican los registros reales de un dominio. Las 13 identidades con nombre de los servidores raíz se replican en muchas instancias físicas; 13 no es el número de máquinas que sostienen el DNS mundial.

El sistema terminal normalmente envía su pregunta a un resolutor local, proporcionado por su organización, su ISP o un servicio público. Ese resolutor trabaja en nombre del sistema terminal. No es otro nivel entre la raíz y el TLD en la jerarquía de nombres.

Sigue una consulta con la caché vacía

Un portátil de un campus necesita la dirección IPv4 de www.example.org:

1. El portátil pide la respuesta final a su resolutor local.
2. El resolutor pregunta a un servidor raíz y recibe una referencia a los servidores de .org.
3. Pregunta a un servidor de .org y recibe una referencia a los servidores autoritativos de example.org.
4. Pregunta a un servidor autoritativo y recibe 203.0.113.25.
5. Devuelve la dirección al portátil.

Hay cuatro pares de consulta y respuesta, u ocho mensajes. La solicitud del sistema terminal es recursiva: obtén la respuesta por mí. Las consultas del resolutor son iterativas: cada servidor contactado responde según lo que sabe o remite al resolutor al siguiente. La raíz no obtiene la dirección del servidor web en nombre del portátil.

Reutiliza las respuestas hasta que termine su TTL

Un registro de recursos lleva un tiempo de vida, o TTL, medido en segundos. Los resolutores conservan los registros reutilizables en cachés hasta que termina su tiempo de vida permitido. Pueden almacenar en caché tanto referencias como direcciones finales. Un TLD o una delegación de dominio guardados permiten que una consulta posterior omita los pasos anteriores. Los sistemas operativos y los navegadores también pueden tener cachés.

Con un RTT de 2 ms entre el sistema terminal y el resolutor y un RTT de 30 ms para cada una de tres consultas secuenciales a la jerarquía, la consulta con la caché vacía tarda unos 92 ms. Una dirección almacenada en la caché del resolutor tarda unos 2 ms. Los tiempos de espera se suman porque cada referencia proporciona información necesaria para la siguiente consulta.

El almacenamiento en caché también retrasa los cambios. Si un resolutor almacenó una dirección con un TTL de una hora justo antes de una actualización, puede seguir devolviendo la dirección anterior durante el tiempo de vida restante. Reducir un TTL antes de un cambio planificado limita este solapamiento; cambiar solo el registro autoritativo no sustituye todas las copias almacenadas en caché.

El DNS hace más que buscar direcciones a partir de nombres. Admite alias, encuentra servidores de correo y distribuye la carga al devolver varias direcciones para un servicio. Estas funciones explican por qué la entrega del correo electrónico y la selección de una CDN también dependen del DNS.

El DNS almacena registros de recursos con un nombre, un valor, un tipo y un TTL. El tipo indica al resolutor cómo interpretar el valor. Un registro de dirección, un alias y un registro de servidor de correo responden a preguntas distintas sobre el mismo dominio.

Lee el tipo de registro

Por ejemplo, www.example.org. 3600 IN A 203.0.113.25 proporciona el nombre del titular, el TTL, la clase de internet, el tipo y la dirección. Un valor NS es un nombre, no una dirección. Una referencia puede incluir un registro A separado que proporciona la dirección del servidor de nombres, a menudo llamado registro de enlace (glue) cuando es necesario para resolver la delegación.

Un CNAME como media.example.org que apunta a edge.cdn.example.net lleva al resolutor a buscar la dirección del destino. Un registro MX, en cambio, dirige la entrega del correo. Con preferencias 10 y 20, prueba primero el servidor de correo con preferencia 10; un número mayor no significa una prioridad más alta.

Lee el mensaje que rodea los registros

Las consultas y las respuestas comparten un formato. La cabecera de 12 bytes contiene un número de identificación, indicadores y recuentos de entradas en cuatro secciones. La respuesta copia el identificador de la consulta para que quien la solicitó pueda relacionarla con el intercambio.

La sección de pregunta indica lo que se solicitó. La sección de respuesta contiene los registros correspondientes. La sección de autoridad puede contener referencias NS, mientras que la sección adicional proporciona registros útiles, como direcciones de servidores de nombres. En la salida impresa de dig, qr indica una respuesta, rd significa que se solicitó recursión y ra significa que hay recursión disponible. NOERROR indica que no hay un error DNS; NXDOMAIN indica que el nombre consultado no existe. Una respuesta sin error puede aun así carecer de un registro del tipo solicitado.

Para publicar un nuevo dominio, su propietario lo registra y proporciona la información de sus servidores autoritativos. La delegación del dominio padre dirige las consultas a esos servidores, que publican los propios registros de sistemas terminales y de correo del dominio. Registrar el nombre no convierte al registrador en el servidor que contiene todos los registros.

Entrega y protección

La mayoría de los intercambios DNS pequeños usan el puerto UDP 53. Una respuesta UDP truncada tiene activado su indicador TC; el resolutor puede volver a intentarlo por el puerto TCP 53. TCP también permite transferencias de zona. Por tanto, el DNS no se limita a UDP.

El tráfico DNS clásico expone los nombres consultados a quienes observan su trayecto. DNS sobre TLS o DNS sobre HTTPS cifra el intercambio entre el cliente y el resolutor, normalmente en los puertos 853 y 443, respectivamente. El cifrado de ese intercambio y la autenticidad de un registro son propiedades distintas.

En el envenenamiento de caché, un resolutor acepta una respuesta falsificada y después envía a los usuarios a una dirección incorrecta. Los identificadores y puertos de origen impredecibles dificultan que las respuestas falsificadas coincidan con una consulta. DNSSEC añade firmas que permiten verificar la autenticidad de los registros; no oculta la consulta. La inundación también puede hacer que los servidores DNS sean inaccesibles. La replicación y las referencias almacenadas en caché reducen la dependencia de la raíz para cada solicitud, pero los fallos de un proveedor autoritativo muy utilizado aún pueden interrumpir muchos sitios.

El correo electrónico separa la redacción de un mensaje de su entrega. Un agente de usuario es la aplicación o página web que se usa para leer y escribir correo. Un servidor de correo almacena el correo entrante en buzones y mantiene los mensajes salientes en una cola. SMTP transfiere mensajes entre sistemas.

Sigue la entrega después del envío

Alicia envía un mensaje para Bob a su propio servidor. Ese servidor consulta los registros MX del dominio de Bob, resuelve la dirección del servidor elegido y abre una conexión TCP al puerto 25. Envía el mensaje al servidor de Bob, que lo almacena en su buzón. El servidor de Alicia es el cliente SMTP durante esa transferencia, aunque actúa como servidor para el agente de usuario de Alicia en otro intercambio.

Si el destino no está disponible temporalmente, la cola de salida conserva el mensaje para volver a intentarlo. El dispositivo de Alicia puede desconectarse mientras su servidor sigue trabajando. Después de varios fallos, puede enviarse un informe de no entrega al remitente del sobre.

Lee el diálogo

SMTP usa comandos de texto y respuestas numéricas. Este es un intercambio de entrega abreviado; C: y S: identifican a los dos participantes y no se transmiten como parte de cada comando.

S: 220 mail.example.net ready
C: EHLO mail.example.org
S: 250 mail.example.net
C: MAIL FROM:<alice@example.org>
S: 250 OK
C: RCPT TO:<bob@example.net>
S: 250 OK
C: DATA
S: 354 Send message
C: From: Alice <alice@example.org>
C: To: Bob <bob@example.net>
C: Date: Tue, 03 Mar 2026 10:02:44 +0100
C: Subject: Lab report
C:
C: The report is ready.
C: .
S: 250 Message accepted
C: QUIT
S: 221 Closing

EHLO presenta al sistema terminal emisor. MAIL FROM establece el remitente del sobre; cada RCPT TO indica un destinatario del sobre. DATA inicia el mensaje y una línea que contiene solo un punto lo termina. Una conexión puede transportar más de un mensaje. Las clases de respuesta distinguen el éxito (2xx), una solicitud de más datos (3xx), un fallo temporal (4xx) y un fallo permanente (5xx). Una respuesta 4xx requiere volver a intentarlo más tarde; un fallo 5xx necesita otro tratamiento, a menudo un rebote.

Separa las direcciones de entrega de los campos mostrados

El sobre SMTP controla el encaminamiento. Los campos From: y To: dentro del mensaje se muestran al lector. Pueden diferir del sobre. Un destinatario en copia oculta puede aparecer en RCPT TO sin aparecer en las cabeceras visibles del mensaje. Responder a un mensaje y notificar un fallo de entrega no tienen por qué usar la misma dirección.

Un usuario normalmente envía correo mediante SMTP autenticado en el puerto 587 con STARTTLS o en el puerto 465 con TLS desde el principio. La transferencia entre servidores normalmente usa el puerto 25 y puede negociar STARTTLS. El envío al servidor y la transferencia tienen funciones distintas, aunque ambos usen SMTP. HTTP generalmente obtiene objetos solicitados; SMTP envía activamente un mensaje preparado.

Comprueba el dominio del remitente

Un campo From: visible es fácil de falsificar. SPF comprueba si el sistema terminal emisor está autorizado para el dominio del sobre. DKIM verifica la firma de un mensaje mediante una clave pública publicada en DNS. DMARC vincula un resultado satisfactorio de SPF o DKIM con el dominio visible de From mediante la alineación de dominios y publica una política para los fallos. Superar SPF para un dominio del sobre no relacionado no valida por sí solo al remitente visible.

La transferencia de correo, el contenido de los mensajes y el acceso al buzón son partes distintas del correo electrónico. SMTP traslada un mensaje a un servidor de correo. El mensaje tiene su propio formato de cabecera y cuerpo, y el destinatario accede después al buzón almacenado mediante otro protocolo.

Lee el mensaje en sí

Un mensaje comienza con campos como From:, To:, Date:, Subject: y Message-ID:. Una línea en blanco separa estas cabeceras del cuerpo. Permanecen como parte del mensaje almacenado; los comandos SMTP MAIL FROM y RCPT TO no se convierten en cabeceras del mensaje.

El formato básico usa líneas de texto. MIME, extensiones multipropósito de correo de internet, describe contenido más variado mediante campos adicionales. Content-Type: text/plain; charset=UTF-8 describe texto sin formato y su codificación de caracteres. image/jpeg identifica una imagen. multipart/mixed describe varias partes, separadas por una cadena delimitadora, como una nota de texto seguida de un archivo adjunto. Cada parte puede tener su propio tipo de contenido y codificación de transferencia.

Content-Transfer-Encoding describe cómo se representa una parte para su transferencia. Base64 convierte cada grupo de tres bytes en cuatro caracteres ASCII. Para un archivo adjunto de 3 MB, 3 000 000 bytes se convierten en 4 000 000 de caracteres antes de añadir los saltos de línea y las cabeceras del mensaje. La codificación añade aproximadamente un tercio al tamaño. Por tanto, el límite de tamaño total de un mensaje en un servidor no puede compararse únicamente con el tamaño original del archivo adjunto. Quoted-printable es otra codificación adecuada para texto mayormente legible.

Elige un protocolo de acceso al correo

El servidor del destinatario puede recibir correo mientras sus dispositivos están desconectados. Cuando el destinatario vuelve, un protocolo de acceso al correo permite a un cliente obtener los mensajes almacenados.

IMAP puede obtener las cabeceras de un mensaje o partes seleccionadas sin descargar todos los archivos adjuntos. Normalmente usa el puerto 143 con STARTTLS o el puerto 993 con TLS desde el principio. POP3 normalmente usa el puerto 110 o TLS en el 995. Sus marcas de eliminación surten efecto cuando la sesión termina normalmente. Descargar y conservar deja copias en el servidor, pero POP3 no proporciona las carpetas en el servidor ni los indicadores compartidos de IMAP.

Supón que Bob consulta el correo en un portátil antes de salir de casa y después en un teléfono. Si el portátil usa POP3 en modo descargar y eliminar, el teléfono puede encontrar vacío el buzón del servidor. Con IMAP, marcar un mensaje como leído en el portátil cambia el estado del servidor, que el teléfono también puede ver. La diferencia está en la sincronización del buzón, no en la entrega mediante SMTP.

Sigue un mensaje de correo web más allá del navegador

Un navegador envía o lee correo mediante HTTPS. El proveedor de correo web sigue usando SMTP para trasladar el correo al servidor de otro dominio. Por tanto, un recorrido completo puede usar HTTPS del remitente al proveedor, SMTP entre proveedores y después IMAP o HTTPS en el extremo receptor. Llamar correo web a un servicio describe su interfaz de usuario y su conexión con el navegador, no todos los protocolos usados en el recorrido del mensaje.

Distribuir un archivo significa que cada destinatario debe obtener una copia completa. El cuello de botella no siempre es el servidor: una descarga lenta o una capacidad total de subida insuficiente pueden determinar el tiempo mínimo. El modelo estándar supone que los enlaces de acceso son los cuellos de botella y que el núcleo tiene suficiente capacidad.

Compara las cotas inferiores

Sea $F$ el número de bits del archivo y $N$ el número de destinatarios. El servidor sube a $u_s$; el par $i$ sube a $u_i$ y descarga a $d_i$. La tasa de descarga más baja entre los pares es $d_{min}$. Usa unidades compatibles, como Mbit y Mbps, para que la división produzca segundos.

Con la distribución cliente-servidor, el servidor debe enviar $NF$ bits y el par más lento debe recibir $F$ bits:

En P2P, el servidor debe introducir cada bit al menos una vez. Los pares siguen teniendo que descargar el archivo y todo el sistema debe subir suficientes datos para todas las copias:

Toma el máximo, porque todos los requisitos deben cumplirse durante la distribución. Sumar los términos supondría erróneamente que esas actividades de subida y descarga ocurren una tras otra. Estas son cotas inferiores; la sobrecarga del protocolo, los pares no disponibles y otros cuellos de botella pueden hacer que las transferencias reales sean más lentas.

Resuelve una comparación

Para un archivo de 2 Gbit, usa 2000 Mbit. Supón que la subida del servidor es de 100 Mbps, la descarga más lenta de 20 Mbps y que cada uno de los 100 pares sube a 5 Mbps.

El término de servidor en cliente-servidor es 200 000 Mbit divididos entre 100 Mbps, o 2000 s. El término de la descarga más lenta es 100 s. Por tanto, su cota es 2000 s.

En P2P, introducir el archivo tarda al menos 20 s. La descarga más lenta sigue tardando 100 s. La capacidad total de subida es 100 más 500, o 600 Mbps; distribuir 200 000 Mbit tarda al menos unos 333 s. La cota P2P es de unos 333 s. Con 1000 pares, la cota cliente-servidor aumenta a 20 000 s, mientras que la cota P2P es de unos 392 s. Con tasas de subida iguales entre los pares, el término de capacidad total se aproxima al tamaño del archivo dividido entre la tasa de subida de un par cuando el número de pares crece mucho.

Intercambia fragmentos en BitTorrent

Un torrent es un grupo que comparte un archivo. Los pares intercambian fragmentos, descubren vecinos mediante un rastreador o una tabla hash distribuida y pueden subir datos antes de terminar la descarga. Una semilla tiene el archivo completo y sigue compartiéndolo.

La estrategia primero el fragmento más raro elige un fragmento necesario que tienen menos vecinos y ayuda a conservar fragmentos que de otro modo podrían desaparecer cuando un par se marcha. Decide qué solicitar. La reciprocidad fomenta un intercambio útil al favorecer a los vecinos que proporcionan datos rápidamente; decide a quién subir datos.

En el diseño original, se desbloquea a cuatro vecinos interesados a la vez, incluido uno mediante desbloqueo optimista. La elección habitual se reconsidera aproximadamente cada 10 s y el par optimista aproximadamente cada 30 s. Ese turno de exploración da a los recién llegados una forma de obtener fragmentos iniciales y ayuda a descubrir mejores compañeros. El rastreador coordina el descubrimiento; no es la fuente de datos de cada fragmento.

Un vídeo consta de fotogramas que se muestran a lo largo del tiempo. La compresión elimina información repetida dentro de un fotograma (redundancia espacial) y entre fotogramas (redundancia temporal). El resultado codificado tiene una tasa de bits: la cantidad de datos de vídeo necesaria para cada segundo de reproducción.

Relaciona la tasa, el tamaño y el tiempo de reproducción

Un vídeo de dos horas a 5 Mbps contiene 36 000 Mbit, o 4,5 GB. Multiplica la tasa por la duración para obtener bits y después divide entre ocho para obtener bytes. Un rendimiento medio del trayecto inferior a la tasa de vídeo seleccionada acaba vaciando cualquier búfer finito durante la reproducción continua.

Un reproductor puede comenzar antes de descargar el vídeo completo. Almacena los datos próximos en un búfer, medido aquí en segundos de vídeo reproducible. La reproducción consume ese búfer mientras las descargas lo reponen. Un búfer inicial mayor protege frente a las caídas de rendimiento, pero aumenta el retardo de inicio.

Solicita un segmento cada vez

DASH, transmisión adaptativa dinámica sobre HTTP, almacena varias versiones codificadas a distintas tasas y divide cada una en segmentos. Un manifiesto enumera las versiones disponibles y las URL de los segmentos. El cliente solicita un segmento con HTTP GET y vuelve a elegir una versión en el siguiente límite entre segmentos. HLS usa un enfoque similar con listas de reproducción.

El reproductor toma la decisión de adaptación según el rendimiento medido y el nivel del búfer. Una estimación reciente de rendimiento alta favorece una tasa mayor; un nivel bajo del búfer exige cautela. Elegir la tasa más alta observada una sola vez puede causar una interrupción si la siguiente descarga se ralentiza. Los reproductores también intentan evitar cambios de calidad frecuentes que distraigan.

Calcula la descarga de un segmento

Considera segmentos de 4 s codificados a 1, 2,5, 5 y 8 Mbps. Con un rendimiento medido de 6 Mbps, el segmento de 5 Mbps contiene 20 Mbit. Se descarga en unos 3,33 s y añade 4 s de contenido reproducible mientras la reproducción consume unos 3,33 s. Si la reproducción continúa, el búfer crece unos 0,67 s.

Un segmento de 8 Mbps contiene 32 Mbit y tarda unos 5,33 s, por lo que el búfer se reduce unos 1,33 s. Los 6 Mbps del trayecto son una tasa de transferencia; no convierten una codificación de 8 Mbps en una de 6 Mbps.

Si el rendimiento baja a 3 Mbps, el mismo segmento de 5 Mbps tarda unos 6,67 s. El búfer pierde unos 2,67 s por segmento. Cambiar a la versión de 2,5 Mbps produce un segmento de 10 Mbit que tarda unos 3,33 s, lo que permite que el búfer vuelva a crecer. Para que la reproducción continúe sin interrupciones durante una descarga, el búfer inicial también debe durar hasta que haya nuevos datos reproducibles disponibles.

Transmisiones almacenadas y llamadas interactivas

La transmisión de vídeo almacenado usa objetos HTTP normales, que las cachés de los navegadores y los servidores CDN pueden servir. Por tanto, funciona sobre TCP o QUIC según la versión de HTTP. Las llamadas interactivas suelen usar transporte multimedia basado en UDP porque esperar contenido antiguo puede ser peor que perderlo.

Un evento en directo también puede usar transmisión HTTP segmentada, pero el reproductor espera a que se produzca cada segmento y mantiene un búfer con retraso respecto a la acción en directo. Los segmentos más cortos pueden reducir ese retardo, aunque aumentan el número de solicitudes. Saltar a una posición que no está en el búfer también exige volver a llenarlo, lo que puede reducir brevemente la calidad.

Una red de distribución de contenidos, o CDN, sirve copias de contenido desde muchos lugares. Evita enviar a todos los espectadores a un centro de datos lejano y reduce las transferencias repetidas a larga distancia. Distribuir la capacidad del servicio también reduce la dependencia de un único sitio.

Sitúa el contenido cerca de sus usuarios

Una CDN privada pertenece a un proveedor; una CDN de terceros atiende a muchos clientes. Ambas pueden entregar imágenes, scripts, software y páginas web, además de vídeo. La fuente original del contenido es el origen. Los grupos de servidores CDN mantienen copias para que el origen no tenga que atender todas las solicitudes.

Hay dos estrategias de ubicación útiles:

La ubicación y el abastecimiento de contenido son decisiones distintas. Con el almacenamiento bajo demanda, un grupo que no tiene un objeto lo obtiene del origen o de otro grupo, lo almacena y lo sirve. Con la distribución anticipada, el proveedor envía los objetos por adelantado, a menudo durante períodos de poco tráfico. La primera solicitud de un objeto que no está en la caché de una CDN bajo demanda todavía puede depender del origen.

Sigue una cesión mediante DNS

Un usuario solicita https://video.stream.example.com/v/6Y7B23V:

1. El resolutor del usuario pregunta por video.stream.example.com.
2. El servidor autoritativo del proveedor devuelve un CNAME al espacio de nombres de la CDN, como a1105.cdn.example.net.
3. El resolutor sigue ese nombre hasta el servicio DNS autoritativo de la CDN.
4. La CDN selecciona un grupo y devuelve una dirección como 198.51.100.17.
5. El cliente se conecta a ese servidor mediante HTTPS y solicita el contenido.

El CNAME cambia dónde continúa la resolución del nombre. El DNS devuelve información de nombres; los bytes del vídeo llegan después mediante HTTP. Si el contenido está segmentado, muchas solicitudes normales de segmentos siguen el mismo trayecto básico hasta un servidor seleccionado.

Elige una ubicación útil

El grupo más cercano en un mapa puede tener un trayecto de red deficiente o estar sobrecargado. Una decisión basada en DNS puede ver la ubicación del resolutor, que puede estar lejos del usuario. Una selección mejor puede usar mediciones de retardo y pérdidas, la carga actual y, a veces, información sobre la red del cliente.

El direccionamiento IP anycast ofrece otra forma de llegar a un servicio cercano: varias ubicaciones anuncian la misma dirección IP y el encaminamiento de internet elige un trayecto hacia una de ellas. La ubicación resultante depende del encaminamiento, no solo de la distancia física. Un servidor cercano al espectador aún puede entregar vídeo de mala calidad si el enlace de acceso del propio espectador es el cuello de botella.

Open Connect de Netflix instala equipos dentro de las redes de los ISP y se conecta en puntos de intercambio. El contenido se carga antes de que exista demanda, lo que reduce el tráfico ascendente en las horas de mayor actividad. Sus servicios de aplicación y la entrega de vídeo codificado no tienen por qué ejecutarse en la misma infraestructura. Otros diseños de CDN privadas pueden llenar las cachés bajo demanda. En cada caso, la transmisión adaptativa controla qué tasa solicita el reproductor, mientras que la CDN ayuda a determinar el trayecto y el servidor desde el que se atienden esas solicitudes.

Los sockets de Python envían bytes. Codifica una cadena antes de enviarla y descodifica después los bytes recibidos; la codificación de texto predeterminada es UTF-8. AF_INET selecciona IPv4 y SOCK_DGRAM selecciona UDP. Empieza con un servicio local para que ambos procesos puedan usar la dirección de bucle local 127.0.0.1.

Ejecuta primero el receptor

Este servidor gestiona datagramas de texto cortos y responde en mayúsculas:

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as server:
    server.bind(("127.0.0.1", 12000))
    while True:
        data, client_addr = server.recvfrom(2048)
        reply = data.decode().upper().encode()
        server.sendto(reply, client_addr)

bind asigna al socket su dirección y puerto de recepción. Vincularlo a 127.0.0.1 acepta solo tráfico local. En cambio, la cadena de dirección vacía "" lo vincula a todas las interfaces IPv4, lo que hace que otros sistemas terminales puedan acceder al servicio cuando la red lo permite. Detén el servidor en ejecución antes de iniciar otra copia en el mismo extremo.

recvfrom bloquea la ejecución hasta que llega un datagrama. Devuelve los datos y la dirección del emisor, incluido su puerto. El servidor usa ese par devuelto como destino de sendto, por lo que puede responder a clientes cuyos puertos efímeros no conocía de antemano.

Envía una solicitud y limita la espera

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as client:
    client.settimeout(2.0)
    client.sendto(b"hello network", ("127.0.0.1", 12000))
    try:
        data, server_addr = client.recvfrom(2048)
        print(data.decode())
    except TimeoutError:
        print("No reply within 2 seconds")

El prefijo b crea un literal de bytes; "hello network".encode() produce los mismos bytes. El sistema operativo asigna el puerto local del cliente cuando es necesario. La respuesta esperada es HELLO NETWORK. Ninguno de los programas llama a listen ni a accept, porque UDP no establece una conexión de transporte.

Una respuesta que no llega no indica al cliente exactamente qué ha fallado. La solicitud o la respuesta pueden haberse perdido, o puede que ningún servidor esté escuchando. El tiempo de espera máximo permite que la aplicación recupere el control. Algunos sistemas pueden informar de un puerto de destino cerrado como un error; Windows puede lanzar ConnectionResetError durante la recepción.

Respeta los límites de los datagramas

Cada recepción gestiona un datagrama. Dos datagramas no se combinan en un solo mensaje. Si el búfer de recepción es demasiado pequeño, en los sistemas Unix habituales se descarta el exceso de ese datagrama; Windows puede informar de un error. Otra recepción no recupera la parte final que falta. Elige un búfer suficientemente grande para los mensajes esperados de la aplicación.

El límite de carga útil UDP sobre IPv4 es de 65 507 bytes con una cabecera IPv4 de tamaño mínimo. Es un máximo del protocolo, no un objetivo útil para el tamaño habitual de los datagramas. Un programa que necesita detectar pérdidas puede numerar los mensajes, registrar los tiempos de envío con time.perf_counter() y contar los vencimientos del tiempo de espera. Dos vencimientos de diez solicitudes dan una tasa de pérdida medida del 20 %. Volver a enviar una solicitud puede causar un procesamiento duplicado, por lo que un diseño con tiempo de espera y reintentos también puede necesitar una forma de reconocer números de mensaje repetidos.

TCP proporciona al programa un flujo de bytes ordenado. No conserva los límites de las llamadas a sendall. Una prueba corta completa puede llegar en un solo recv, pero un programa correcto también debe gestionar una solicitud dividida entre varias recepciones.

Delimita una solicitud de texto

Elige un salto de línea como delimitador. El cliente envía una línea UTF-8 y el servidor devuelve una línea en mayúsculas. Este servidor lee hasta encontrar ese delimitador antes de descodificar:

from socket import socket, AF_INET, SOCK_STREAM

with socket(AF_INET, SOCK_STREAM) as server:
    server.bind(("127.0.0.1", 12000))
    server.listen(5)
    while True:
        conn, client_addr = server.accept()
        with conn:
            data = b""
            while b"\n" not in data:
                chunk = conn.recv(1024)
                if not chunk:
                    break
                data += chunk
            if b"\n" in data:
                line = data.split(b"\n", 1)[0]
                conn.sendall(line.decode().upper().encode() + b"\n")

listen crea un socket de escucha. accept devuelve un nuevo socket de conexión y la dirección del cliente. Usa conn para los bytes de este cliente; el socket original sigue disponible para aceptar más conexiones. Aquí se atiende a los clientes de uno en uno. El límite de cinco afecta a las conexiones pendientes, no a cinco hilos de trabajo activos.

Completa el lado del cliente

from socket import create_connection

with create_connection(("127.0.0.1", 12000), timeout=2) as client:
    client.sendall(b"hello network\n")
    data = b""
    while b"\n" not in data:
        chunk = client.recv(1024)
        if not chunk:
            raise EOFError("Reply ended before its newline")
        data += chunk
    print(data.split(b"\n", 1)[0].decode())

El resultado esperado es HELLO NETWORK. sendall sigue enviando hasta que se entregan todos los bytes proporcionados o se produce un error. Una sola llamada a send puede enviar solo una parte e informa de cuántos bytes aceptó. Ninguna de las dos llamadas proporciona al receptor límites de mensajes de aplicación.

Este servicio acepta una línea por conexión. Un servicio persistente con varios mensajes conservaría los bytes posteriores al primer salto de línea para su siguiente mensaje. Los prefijos de longitud y el cierre de la dirección de envío son otras opciones de delimitación. Recibir b"" significa que el par ha terminado su lado de envío; no es un fragmento vacío que deba seguir intentándose.

Relaciona el código con protocolos reales

Una solicitud HTTP/1.1 también es una secuencia de bytes:

from socket import create_connection

request = ("GET / HTTP/1.1\r\n"
           "Host: example.com\r\n"
           "Connection: close\r\n\r\n")
with create_connection(("example.com", 80), timeout=5) as sock:
    sock.sendall(request.encode("ascii"))
    chunks = []
    while True:
        chunk = sock.recv(4096)
        if not chunk:
            break
        chunks.append(chunk)
print(b"".join(chunks).decode(errors="replace")[:200])

Esto muestra el comienzo de la respuesta sin procesar, incluidos su estado y sus cabeceras. Un servidor puede devolver un error o una redirección; el código no presupone un cuerpo de respuesta concreto. HTTPS en el puerto 443 necesita envolver la conexión en TLS con verificación del certificado y del nombre del sistema terminal, no solo cambiar el número de puerto. Por ejemplo, ssl.create_default_context().wrap_socket(sock, server_hostname="example.com") envuelve un socket conectado después de import ssl. Una conexión rechazada suele significar que no hay nadie escuchando; el tráfico descartado silenciosamente puede agotar el tiempo de espera. Para reiniciar rápidamente un servidor en Unix, establecer SO_REUSEADDR antes de bind puede permitir la reutilización mientras se cierra una conexión antigua; no permite que dos sockets de escucha activos ocupen el mismo extremo. Los servidores concurrentes usan hilos o bucles de eventos y distinguen las conexiones mediante los pares de dirección y puerto de ambos extremos.