WebSocket vs HTTP para Transferencia de archivos: A Comparison
Comparativa entre WebSocket y HTTP para la transferencia de archivos: benchmarks de rendimiento, casos de uso y compromisos de implementación.
Para la transferencia de archivos, HTTP gana casi siempre. Es sin estado, funciona a través de cualquier proxy corporativo, se beneficia de la multiplexación HTTP/2 y del QUIC de HTTP/3, e integra limpiamente con CDN, URLs prefirmadas y APIs de almacenamiento de objetos como S3. WebSocket (RFC 6455) destaca en la mensajería bidireccional en tiempo real —chat, edición colaborativa, paneles en vivo— pero ofrece poca ventaja para mover archivos grandes e introduce desventajas reales: sin caché nativa, soporte pobre de CDN, problemas con intermediarios y gestión de memoria del lado del servidor más compleja. Aquí está la comparativa detallada con cifras.
La diferencia de protocolo fundamental
HTTP es petición-respuesta, sin estado y cacheable. Cada petición lleva cabeceras, llega a un servidor o CDN y devuelve una respuesta. HTTP/2 multiplexa muchas peticiones en una sola conexión TCP; HTTP/3 (RFC 9114) corre sobre QUIC con mejor recuperación de pérdidas y reanudación sin RTT. WebSocket comienza como una petición HTTP Upgrade, luego convierte la conexión TCP en un protocolo basado en tramas full-duplex. Ese canal bidireccional persistente es potente para aplicaciones interactivas pero arquitectónicamente incómodo para la transferencia masiva de archivos, donde el flujo es predominantemente en un sentido.
Benchmarks de rendimiento y latencia
En un enlace gigabit entre un cliente en Tokio y un servidor en US-East, los benchmarks típicos muestran: HTTP/1.1 con un único PUT a 40–80 Mbps por los límites de escalado de la ventana TCP, HTTP/2 multiparte (8 flujos paralelos, partes de 8 MB) a 400–800 Mbps, HTTP/3 sobre QUIC ligeramente mejor bajo pérdida de paquetes en un 10–30 por ciento, y WebSocket con tramas binarias a 200–500 Mbps limitado por el control de flujo de conexión única. WebSocket no es más rápido porque sigue siendo TCP por debajo, pero usa la conexión de forma menos eficiente que las peticiones HTTP paralelas.
Fragmentación y subidas reanudables
HTTP tiene estándares bien definidos para la subida fragmentada. El protocolo tus.io usa HTTP PATCH con cabeceras Upload-Offset. S3 Multipart Upload usa UploadPart con números de parte y ETags. Ambos sobreviven a interrupciones de red, reanudan desde el último fragmento exitoso y funcionan entre reinicios del cliente gracias al estado persistido en IndexedDB. La fragmentación con WebSocket es ad hoc: defines tu propia trama, números de secuencia y acuses de recibo. Cada equipo reinventa la misma lógica de reanudación, normalmente peor que las opciones HTTP probadas en batalla.
Compatibilidad con CDN y edge
Las CDN como Cloudflare, CloudFront, Fastly y Akamai cachean respuestas HTTP en los PoP edge, a menudo reduciendo a la mitad los tiempos de descarga globalmente. Las peticiones GET para objetos estáticos pueden cachearse por URL o URL firmada. El tráfico WebSocket normalmente pasa a través de las CDN sin cachearse, y muchos proxies empresariales deshabilitan o limitan el upgrade de WebSocket. Las redes corporativas con proxies TLS interceptores a veces rompen WebSocket por completo. Para un servicio de transferencia con audiencia global, esto por sí solo es razón suficiente para preferir HTTP: los 300+ PoP de Cloudflare hacen que las descargas cercanas sean dramáticamente más rápidas para HTTP, pero ofrecen poco para las cargas de WebSocket.
Uso de recursos en el servidor
Los servidores HTTP gestionan miles de conexiones concurrentes con memoria mínima porque las peticiones son de corta duración. Nginx, caddy y net/http de Go admiten cada uno más de 10.000 conexiones concurrentes por nodo con RAM modesta. Cada conexión WebSocket es de larga duración, manteniendo un socket TCP, un buffer de lectura, un buffer de escritura y con frecuencia el estado de la aplicación. A escala, los parques de WebSocket necesitan un ajuste cuidadoso de ulimit, TCP keepalive y memoria por conexión. Las implementaciones de Kubernetes tienen problemas con las sesiones pegajosas de WebSocket y el apagado graceful durante los despliegues progresivos.
URLs prefirmadas y subidas directas al almacenamiento
La característica killer de HTTP en la transferencia de archivos son las URLs prefirmadas. Tu aplicación genera una URL firmada apuntando directamente a S3, R2 o GCS, y el cliente sube directamente al almacenamiento de objetos. Tus servidores de aplicación nunca tocan los bytes. Sin ancho de banda de proxy, sin presión de memoria, sin I/O de archivos. WebSocket no tiene equivalente. Para usar WebSocket en subidas, normalmente haces proxy a través de tu servidor de aplicación, que luego escribe al almacenamiento, duplicando los costes de ancho de banda y añadiendo latencia. Una subida de 10 GB mediante el pipeline WebSocket-a-app-a-S3 usa 20 GB de ancho de banda del servidor; las subidas HTTP directas a S3 usan el ancho de banda de tu servidor solo para pequeñas llamadas de metadatos.
Cuándo WebSocket realmente ayuda
WebSocket encaja bien en los flujos de trabajo relacionados con archivos. Notificaciones de progreso de subida en tiempo real entre pestañas o dispositivos: los broadcasts de WebSocket se entregan al instante. Edición colaborativa de archivos: las bibliotecas CRDT como yjs y Automerge usan WebSocket para pequeños mensajes de delta, con los assets grandes reales transferidos mediante HTTP. Señalización en vivo para transferencias peer-to-peer WebRTC: WebSocket es el transporte de señalización estándar antes de que se abran los canales de datos P2P. Notificaciones enviadas por el servidor de que un destinatario ha descargado el archivo: WebSocket permite notificar al emisor al instante sin polling. El patrón es WebSocket para eventos, HTTP para bytes.
Ventajas de HTTP/2 y HTTP/3
HTTP/2 (RFC 7540) y HTTP/3 (RFC 9114) cierran la mayoría de las brechas que WebSocket solía explotar. HTTP/2 multiplexa múltiples peticiones sobre una sola conexión TCP, eliminando el límite de 6 conexiones por origen. Server Push permite al servidor enviar recursos de forma proactiva, reduciendo los viajes de ida y vuelta. HTTP/3 corre sobre QUIC, que gestiona la pérdida de paquetes por flujo en lugar de bloquear toda la conexión, crucial en redes móviles con pérdidas. Los Server-Sent Events (EventSource) proporcionan push del servidor al cliente en un sentido sobre HTTP, más sencillo que WebSocket cuando solo el servidor necesita empujar datos.
Seguridad y controles de origen
La historia de seguridad de HTTP es madura. CORS (Cross-Origin Resource Sharing) controla qué orígenes pueden subir o descargar. CSP (Content Security Policy) restringe desde dónde los clientes pueden obtener recursos. TLS 1.3 asegura el transporte. Las URLs prefirmadas incluyen firmas HMAC para evitar la manipulación y pueden tener alcance exacto para claves de objeto con expiración. WebSocket tiene controles de origen más débiles. La cabecera Origin puede ser falsificada por clientes que no son navegadores. Muchos servidores WebSocket no validan el origen, lo que lleva a ataques de secuestro de WebSocket entre sitios. Implementar protecciones equivalentes requiere una validación cuidadosa de tokens en cada trama.
Cuándo gana cada uno
| Criterio | HTTP | WebSocket | |---|---|---| | Subidas/descargas de archivos grandes | Gana (multiparte, URLs prefirmadas, CDN) | Pierde (flujo único, sin caché) | | Mensajes bidireccionales en tiempo real | Pierde (el polling es ineficiente) | Gana (full-duplex nativo) | | Compatibilidad con CDN | Gana (caché edge global) | Pierde (raramente cacheado) | | Recursos del servidor a escala | Gana (sin estado, conexiones cortas) | Pierde (larga duración, RAM por conexión) | | Compatibilidad con proxy empresarial | Gana (HTTP estándar) | Pierde (el proxy a menudo bloquea Upgrade) | | Subidas reanudables | Gana (tus.io, S3 multipart) | Ad hoc (requiere implementación propia) |
Para un servicio de transferencia como HexaTransfer, HTTP más subidas multiparte fragmentadas más subidas directas a S3 es la arquitectura correcta, con WebSocket opcional para progreso en vivo o eventos de notificación al destinatario superpuestos encima.
Pruébalo en https://hexatransfer.com — gratuito, sin cuenta, hasta 10 GB.
Envía archivos grandes de forma segura con cifrado de extremo a extremo
Transfiere archivos de hasta 10 GB gratis con cifrado de extremo a extremo. Sin necesidad de cuenta. Tus archivos se cifran en tu navegador antes de subirlos: nadie más puede leerlos.
Enviar un archivo