El rendimiento en streaming no es solo una preocupación de los reproductores de video. Los artefactos de software, los pesos de los modelos, las copias de seguridad, las bibliotecas de audio y las exportaciones grandes de API dependen todos de los mismos fundamentos: mover bytes rápidamente, preservar la carga útil exacta, respetar la contraflujo y detenerse limpiamente cuando un cliente se desconecta.
Webship trata esos requisitos como un único problema de transporte a través de HTTP/1.1, HTTP/2, HTTP/3, entrega directa de archivos, proxy inverso y WebTransport. La ruta rápida es útil solo cuando conserva el enmarcado, la cancelación, los trailers, la inspección de seguridad y la memoria limitada.
Capacidad de transmisión medida de 100 MB
La capacidad de ejecución 1.3.1 de Debian de Webship midió el rendimiento medio de la carga útil con un accesorio fijo de 100 MB. Cada muestra aceptada requería el cuerpo de respuesta exacto de 99,943,778 bytes y cero errores de cliente, protocolo, proxy, fallo de página principal y HTTP/3 pérdida de paquetes.
| modo Webship | TLS HTTP/1.1 | TLS HTTP/2 | TLS HTTP/3 | | --- | ---: | ---: | ---: | | Entrega directa de archivos | 4,194.8 MiB/s | 3,574.3 MiB/s | 2,096.9 MiB/s | | Proxy inverso con terminación TLS | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | Proxy inverso con paso de TLS | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |
En la comparación registrada, Webship produjo la mediana más alta directa y terminada en TLS para cada protocolo medido. La matriz completa incluye Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora y Bun en la [página de comparativas](/benchmarks).
Estos números miden la capacidad en el host de referencia. No son una promesa para una ruta de internet arbitraria. La latencia del almacenamiento, el ancho de banda de la red, el tiempo de ida y vuelta, la pérdida de paquetes, la política TLS, la concurrencia y el comportamiento del origen todavía determinan la velocidad real de entrega.
Un binario, tres estrategias de transporte
Una gran respuesta no se beneficia de la misma política que un pequeño documento HTML. Webship mantiene el camino de solicitud ordinario conservador y solo promueve una respuesta masiva probada.
HTTP/1.1: menos transiciones alrededor del archivo
En Linux, Webship mantiene la cabecera de la respuesta y la carga útil del archivo dentro de un intervalo TCP cork de mejor esfuerzo. Una vez que una gran respuesta TLS califica para la ruta masiva, la entrega directa de archivos puede moverse de los registros Rustls a TLS de kernel unidireccional auditado y usar sendfile sin copiar la carga útil a través de un búfer de aplicación.
La conexión todavía comienza en TLS en el espacio de usuario. Las respuestas pequeñas permanecen allí. Webship solicita la transición a kTLS solo después de que un cuerpo de respuesta de al menos 1 MiB demuestre que la conexión está transportando datos masivos.
HTTP/2: procesamiento por lotes sin interrumpir el control de flujo
La multiplexación HTTP/2 hace que el almacenamiento en búfer no controlado sea costoso. Webship agrupa escrituras mientras conserva los límites de control de flujo de la transmisión y de la conexión. Para la transmisión de alta concurrencia, un búfer de escritura TLS de 128 KiB puede contener dos tramas DATA de 64 KiB, mientras que el presupuesto de envío de la conexión sigue siendo explícito y limitado.
Un marco de cuerpo ascendente ya preparado se puede precargar sin evitar el Hyper framing, remolques, cancelación, inspección o contrapresión. Eso reduce una ronda de programador evitables mientras se mantiene intacto el contrato del protocolo.
HTTP/3: Control de ritmo QUIC en lugar de kTLS
HTTP/3 nunca utiliza la ruta TCP kTLS. Webship aplica control de ritmo QUIC consciente del transporte, empaquetado de datagramas limitado, DPLPMTUD y micro-loteo impulsado por temporizador por reactor. Las respuestas grandes de HTTP/3 y las sesiones aceptadas de WebTransport pueden seleccionar BBR sin cambiar la política CUBIC utilizada por el tráfico ordinario.
La calificación de estabilidad HTTP/3 centrada utilizó siete muestras aceptadas. La transmisión en streaming terminada en TLS entregó una mediana de 1,938.6 MiB/s con un coeficiente de variación del 2.12%. La transmisión en modo pasante de TLS entregó 1,748.5 MiB/s con un coeficiente de variación del 1.65%. Ambas series no presentaron errores de integridad del cuerpo, del cliente, del protocolo ni de pérdida de paquetes.
¿Entrega directa o proxy inverso?
Use la entrega directa cuando Webship sea el propietario del árbol de archivos desplegado. Esto elimina el salto de origen y permite la ruta de archivos estáticos más eficiente.
Un sitio mínimamente multi-protocolo se ve así:
listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"
[[sites]]
domain = "media.example.com"
root = "/srv/media"
[sites.protocols]
h1 = true
h2 = true
h3 = true
[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"Utilice la terminación TLS de proxy inverso cuando Webship deba enrutar por ruta, aplicar WAF o verificaciones de API Shield, hacer cumplir límites de cuerpo, agregar encabezados de reenvío u observar campos HTTP:
[reverse_proxy]
enabled = true
tls_termination = true
[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true
[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"
[[reverse_proxy.routes]]
domain = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]Configure tls_termination = false cuando el origen debe conservar el texto plano de la aplicación y las claves activas de sesión. El paso a través no puede inspeccionar campos HTTP cifrados. Por lo tanto, el paso a través TCP se enruta mediante SNI de ClientHello, mientras que el paso a través HTTP/3 requiere un origen UDP compartido.
Ajustar la transmisión masiva explícitamente
Para la transmisión TLS de alta concurrencia HTTP/2, Webship documenta estos ajustes vinculados al proceso:
[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"El presupuesto de conexión anterior proporciona 128 KiB de crédito para 256 flujos activos. Trátalo como una decisión de capacidad, no como un valor predeterminado universal. Mide la memoria, la latencia y el rendimiento con la concurrencia esperada antes de aumentarlo.
En Linux, cargue los módulos TLS y BBR del núcleo y permita que la cuenta de servicio Webship seleccione BBR. Webship falla antes de enlazarse cuando su capacidad requerida del núcleo no está disponible, por lo que una implementación no puede reclamar silenciosamente la ruta optimizada mientras se ejecuta sin ella. Otros sistemas operativos conservan las rutas portátiles Rustls y de control de congestión documentadas para su plataforma.
WebTransport es una forma de transmisión diferente
WebTransport combina flujos confiables y datagramas no confiables a través de una sesión segura. No utiliza TCP kTLS. El punto final diagnóstico limitado de Webship valida los orígenes y aplica límites de sesión, flujo, cápsula, datagrama, byte y tiempo de inactividad.
En la ejecución de capacidad 1.3.1, WebTransport directo alcanzó 1,018.1 MiB/s para flujos fiables y 1,038.9 MiB/s para datagramas. La transferencia TLS alcanzó 548.6 MiB/s y 629.7 MiB/s respectivamente. Ambos modos pasaron los cinco muestras sin muestras rechazadas, sin datagramas perdidos y sin fallas importantes del cliente.
Prefiera HTTP/3 para nuevos clientes WebTransport. La ruta HTTP/2 existe por compatibilidad con la configuración de borradores caducados más antiguos.
Qué verificar antes del tráfico de producción
- Prueba los tamaños exactos de medios o artefactos que vas a servir, no solo una pequeña respuesta sintética.
- Verifique la longitud de la respuesta y el resumen del contenido en el cliente.
- Cancelación de ejercicios, solicitudes de rango, lectores lentos y comportamiento de origen semi-cerrado.
- Mida el rendimiento sostenido junto con la CPU, la memoria, los errores de socket, las retransmisiones y la latencia de cola.
- Valide los modos directo, terminado en TLS y de paso por separado; tienen diferentes límites de seguridad y enrutamiento.
- Mantenga la instrumentación desactivada para el tráfico normal de producción, luego habilite diagnósticos limitados deliberadamente al investigar.
- Vuelve a verificar el pre-vuelo de Linux kTLS y BBR después de cambios en el kernel, el contenedor o el sandbox de systemd.
La transmisión es rápida cuando todo el camino coopera. El diseño de Webship mantiene las optimizaciones de datos a granel específicas del protocolo mientras preserva un modelo operativo y un estándar de corrección.
Lee la documentación completa de [Webship 1.3.1](/docs/1.3.1), revisa la [metodología de referencia y la matriz de competidores](/benchmarks), o descarga una versión firmada desde [Descargas](/downloads).