Webship: El servidor web más compatible con RFC del mundo

La web se mantiene unida por acuerdos exactos. Un campo Content-Length debe significar lo mismo en cada salto. Una caché no debe reutilizar una respuesta que requiera validación. Una sección de campo HTTP/3 mal formada debe fallar en el alcance correcto. Un método seguro debe seguir siendo seguro después de pasar por un proxy inverso.

Webship 1.3.1 se construye en torno a una regla: la velocidad solo cuenta cuando los bytes conservan su significado.

Es por eso que describimos Webship como el servidor web de propósito general más compatible con las RFC del mundo. Esta es una afirmación de ingeniería con un límite visible, no una afirmación de que todas las funciones opcionales en cada RFC existan. El mapa a continuación nombra las 52 RFC que afectan el comportamiento activo del servidor de Webship o sus fundamentos de protocolo propios. Los estándares actuales aparecen primero. Los documentos reemplazados se identifican como linaje de compatibilidad. Las especificaciones en borrador no se reclasifican como RFC.

La compatibilidad es comportamiento, no una insignia

Webship aplica estándares en los lugares donde los servidores de producción con mayor frecuencia se vuelven ambiguos:

• El enmarcado HTTP/1.1 rechaza longitudes conflictivas, codificaciones de transferencia inválidas, objetivos de solicitud sobredimensionados, fragmentos malformados y formas de contrabando de solicitudes.
• HTTP/2 y HTTP/3 rechazan los campos de conexión prohibidos, validan los pseudo-campos, limitan las secciones de campos comprimidos y mantienen los errores de flujo separados de los errores de conexión.
• Los archivos estáticos preservan la semántica de HEAD, los validadores, el orden de las condiciones previas, los rangos de bytes, las redirecciones y los tipos de contenido.
• El proxy inverso preserva el enmarcado, la cancelación, los encabezados finales, las actualizaciones, los reintentos seguros y la identidad de reenvío mientras elimina los campos de salto a salto.
• La caché calcula la edad, la frescura, la revalidación, Vary, la invalidación y las reglas de uso obsoleto en lugar de tratar el almacenamiento en caché como un atajo de clave-valor.
• TLS, QUIC, ACME, datos tempranos y WebTransport utilizan estado limitado y una política de fallo explícita.

Las mismas reglas se aplican en el camino rápido. Webship no define un camino “correcto” y un camino de referencia diferente.

Semántica, enmarcado, almacenamiento en caché y proxy de HTTP

• RFC 3986 — Identificador Uniforme de Recursos (URI): Sintaxis Genérica. Webship normaliza referencias relativas de Location y Content-Location, incluidos los segmentos con puntos, antes de las decisiones de invalidación de caché.
• RFC 6455 — El Protocolo WebSocket. Las actualizaciones de proxy inverso validan la clave WebSocket, el valor aceptado, el subprotocolo, las extensiones y la transición de túnel.
• RFC 6585 — Códigos de Estado HTTP Adicionales. Los campos de solicitud sobredimensionados utilizan la respuesta 431 definida cuando todavía es posible una respuesta HTTP.
• RFC 6797 — Seguridad de Transporte Estricta HTTP. Strict-Transport-Security se emite solo a través de transporte seguro y nunca se filtra desde una entrada de caché neutral al transporte hacia HTTP en texto claro.
• RFC 7235 — Autenticación HTTP/1.1. Los tokens del esquema de autenticación se analizan sin considerar mayúsculas y minúsculas, incluida la superficie de control MCP protegida. Su semántica general de HTTP ahora se encuentra en el RFC 9110.
• RFC 7239 — Extensión HTTP Forwarded. Los operadores pueden seleccionar un campo Forwarded basado en estándares, campos legacy X-Forwarded, ambos o ninguno; los campos de identidad entrante no confiables se eliminan primero.
• RFC 7540 — HTTP/2. Esto se conserva como linaje de compatibilidad con HTTP/2; el contrato activo de HTTP/2 es su sucesor, RFC 9113.
• RFC 7541 — HPACK: Compresión de encabezados para HTTP/2. La pila HTTP/2 propiedad de Webship limita el estado del decodificador y las tablas del codificador mientras preserva el formato de transmisión HPACK y la codificación Huffman.
• RFC 7838 — Servicios Alternativos de HTTP. Alt-Svc anuncia un endpoint HTTP/3 sin cambiar el origen representado por la URL.
• RFC 8441 — Inicialización de WebSockets con HTTP/2. Webship admite la base de negociación extended-CONNECT descendente. No pretende que un upstream HTTP/1.1 implemente CONNECT extendido de HTTP/2; las combinaciones de upstream no admitidas fallan explícitamente.
• RFC 8470 — Uso de datos tempranos en HTTP. Las solicitudes tempranas que Webship no procesará reciben 425 Too Early en lugar de ser manejadas con suposiciones inseguras de reproducción.
• RFC 8941 — Valores de campo estructurados para HTTP. Los valores de prioridad de HTTP utilizan el análisis de diccionario de campos estructurados; los campos opcionales malformados se ignoran en su totalidad.
• RFC 9110 — Semántica HTTP. Los métodos, códigos de estado, campos, validadores, precondiciones, redirecciones, metadatos de contenido, HEAD, CONNECT, OPTIONS y la semántica de rangos comparten un contrato vigente entre las versiones del protocolo.
• RFC 9111 — Caché HTTP. Webship implementa edad corregida, frescura explícita, Vary, only-if-cached, must-revalidate, proxy-revalidate, uso seguro de contenido obsoleto e invalidación de URIs efectivas y relacionadas.
• RFC 9112 — HTTP/1.1. Las reglas de línea de solicitud, campo, longitud del cuerpo, codificación de transferencia, fragmento, remolque, persistencia y delimitación por cierre se aplican antes del despacho de la aplicación.
• RFC 9113 — HTTP/2. El orden de pseudo-campos, autoridad, campos de conexión prohibidos, restricciones de TE, ciclo de vida del flujo, control de flujo, GOAWAY y el alcance de errores son manejados por la ruta H2 propiedad de Webship.
• RFC 9114 — HTTP/3. Webship posee las rutas de solicitud, flujo de control, SETTINGS, flujo crítico, cancelación y errores de flujo frente a conexión utilizadas por su servidor HTTP/3.
• RFC 9204 — QPACK: Compresión de campos para HTTP/3. La capacidad de la tabla dinámica está limitada por el límite anunciado, los flujos de instrucciones siguen siendo analizables con capacidad cero, y el estado inválido se convierte en el error QPACK requerido.
• RFC 9218 — Esquema de Priorización Extensible para HTTP. La urgencia y la entrega incremental guían la programación de HTTP/3 mientras los parámetros de prioridad desconocidos permanecen extensibles.
• RFC 9220 — Inicialización de WebSockets con HTTP/3. Webship implementa la base de SETTINGS extended-CONNECT de HTTP/3 utilizada por los protocolos túnel modernos; eso no implica que se acepte cualquier protocolo CONNECT posible.
• RFC 9297 — Datagramas HTTP y el Protocolo de Cápsulas. Las sesiones de WebTransport utilizan decodificación de cápsulas limitada y asociación de Datagramas HTTP, manejando las cápsulas desconocidas como puntos de extensión en lugar de fallas del analizador.
• RFC 9421 — Firmas de Mensajes HTTP. La procedencia de respuesta Ed25519 opcional puede cubrir la identidad de la versión y configuración de Webship sin reemplazar TLS o la autenticación de la aplicación.
• RFC 10008 — El método HTTP QUERY. Webship trata QUERY como seguro e idempotente, conserva su cuerpo durante el proxy, incluye el cuerpo y los metadatos de representación en la identidad de la caché, prohíbe la frescura heurística, admite comportamiento condicional y de rango, y nunca invalida una caché únicamente porque se haya utilizado QUERY.

Transporte y control de congestión de QUIC

• RFC 3465 — Control de congestión TCP con conteo adecuado de bytes. La lógica de conteo adecuado de bytes es parte de la línea de control de congestión NewReno utilizada por la implementación QUIC de Webship.
• RFC 4303 — Carga Útil de Seguridad de Encapsulación IP. Webship no implementa IPsec ESP; su desduplicador de paquetes QUIC utiliza la técnica de anti-repetición de ventana deslizante del RFC solo como línea de implementación.
• RFC 5681 — Control de congestión de TCP. Los umbrales de pérdida y reordenamiento heredan las restricciones de control de congestión establecidas donde QUIC se basa en la práctica de TCP.
• RFC 6298 — Cálculo del temporizador de retransmisión de TCP. Los cálculos de tiempo de ida y vuelta suavizado y de varianza contribuyen al modelo de recuperación de QUIC.
• RFC 8312 — CUBIC para redes de larga distancia rápidas. Esta es la especificación anterior de CUBIC mantenida como linaje del algoritmo; RFC 9438 es el estándar actual.
• RFC 8899 — Descubrimiento de MTU de capa de paquetización para transportes de datagramas. DPLPMTUD configurable descubre el tamaño de datagrama QUIC utilizable sin depender de señales de capa de red frágiles.
• RFC 8999 — Propiedades independientes de la versión de QUIC. Los encabezados largos, los identificadores de conexión, la negociación de versión y el análisis invariante siguen siendo seguros antes de que se ejecute un decodificador específico de la versión.
• RFC 9000 — QUIC: un transporte multiplexado y seguro basado en UDP. Los identificadores de conexión, flujos, control de flujo, migración, validación de direcciones, Retry, restablecimiento sin estado, parámetros de transporte y el comportamiento de cierre forman la base del transporte HTTP/3 de Webship.
• RFC 9001 — Uso de TLS para asegurar QUIC. Los secretos iniciales, la protección de paquetes, la protección de encabezados, la integridad de Retry, las fases de claves y la integración de TLS siguen las reglas de QUIC-TLS.
• RFC 9002 — Detección de Pérdidas y Control de Congestión de QUIC. Los espacios de número de paquete, los reconocimientos, PTO, la detección de pérdidas, la recuperación y la contabilidad de la congestión impulsan la fiabilidad del transporte.
• RFC 9221 — Una extensión de datagrama no confiable para QUIC. Los cuadros de DATAGRAMA de QUIC negociados transportan tráfico de WebTransport no confiable sin convertirlo en contenido de flujo.
• RFC 9287 — Engrasando el bit QUIC. El engrase del bit QUIC reduce la osificación mientras preserva la seguridad de la negociación.
• RFC 9308 — Aplicabilidad del Protocolo de Transporte QUIC. Los valores predeterminados operativos, como el tiempo de inactividad limitado y las recomendaciones de implementación, informan la política de transporte de producción de Webship.
• RFC 9369 — QUIC Versión 2. Se implementan los tipos de paquetes de la versión 2, claves iniciales, integridad de Retry, actualizaciones de claves y negociación de versión junto con QUIC v1.
• RFC 9438 — CUBIC para redes rápidas y de larga distancia. El estándar actual de CUBIC regula el controlador de congestión CUBIC de Webship; BBR y NewReno siguen siendo seleccionables cuando la carga de trabajo lo requiere.

TLS, certificados y gestión automática de certificados

• RFC 3339 — Fecha y hora en Internet: Marcas de tiempo. Las ventanas de renovación de ACME utilizan marcas de tiempo de Internet interoperables.
• RFC 4648 — Codificaciones de datos Base16, Base32 y Base64. Los valores ACME JOSE y el material del saludo de WebSocket usan los alfabetos y las reglas de relleno requeridos de Base64 y Base64url.
• RFC 5280 — Perfil de certificado y CRL PKI X.509 de Internet. El análisis de certificados y los certificados de desafío generados utilizan formas correctas de DNS y IP binaria en subjectAltName.
• RFC 5869 — Función de Derivación de Claves Extracción y Expansión basada en HMAC. La derivación HKDF-SHA-256 y HKDF-SHA-384, incluidos los límites de salida, sustenta las claves TLS y QUIC.
• RFC 6066 — Extensiones TLS. SNI selecciona identidades DNS, mientras que las direcciones IP literales se excluyen correctamente de la forma habitual de HostName.
• RFC 7301 — Negociación de Protocolos a Nivel de Aplicación TLS. ALPN selecciona HTTP/1.1, HTTP/2, HTTP/3 y el protocolo de desafío ACME aislado en el límite TLS.
• RFC 7638 — Huella digital de clave Web JSON. Las huellas digitales de las claves de cuenta ACME se derivan en la forma canónica de JWK.
• RFC 7807 — Detalles de Problemas para APIs HTTP. Webship utiliza el formato de documento de problemas requerido por los servidores ACME según RFC 8555. La especificación más reciente de Detalles de Problemas lo reemplaza para nuevas APIs de propósito general, pero la dependencia normativa de ACME sigue siendo explícita.
• RFC 8446 — TLS 1.3. Webship utiliza TLS 1.3 para TLS público, incluyendo tickets de sesión, actualizaciones de claves, alertas, política de datos tempranos y derivación de claves QUIC.
• RFC 8555 — Entorno de Gestión Automática de Certificados. Los flujos de cuenta, pedido, autorización, desafío, finalización, descarga de certificados y renovación están automatizados con manejo de entradas acotadas.
• RFC 8737 — Desafío ACME TLS-ALPN-01. Un camino TLS solo para desafíos negocia únicamente acme-tls/1 y sirve la extensión de certificado crítica acmeIdentifier requerida.
• RFC 8738 — Extensión de Validación de Identificador IP de ACME. Webship admite órdenes de certificados IPv4 e IPv6, SANs de IP binarios y SNI de dirección inversa para la validación IP TLS-ALPN-01.
• RFC 9525 — Identidad del servicio en TLS. Los nombres de DNS y las identidades IP se comparan según las reglas actuales de identidad del servicio, sin atajos de comodines o nombres comunes para direcciones IP.
• RFC 9773 — Extensión de Información de Renovación ACME. Las ventanas de renovación pueden provenir de la CA, permitiendo que Webship distribuya las renovaciones de manera segura en lugar de usar un único calendario local rígido.

WebTransport: preciso sobre lo que está estandarizado

WebTransport sobre HTTP/3 no se cuenta como un quincuagésimo tercer RFC. A partir de Webship 1.3.1, su mapeo en la transmisión sigue siendo draft-ietf-webtrans-http3-16. Webship implementa ese borrador sobre el HTTP/3 estandarizado, CONNECT extendido, DATAGRAMA QUIC, Datagram HTTP y las capas de Cápsula mencionadas anteriormente. También implementa la extensión RESET_STREAM_AT negociada requerida para preservar un prefijo identificador de sesión fiable cuando se reinicia un flujo de WebTransport.

Esa distinción importa. La compatibilidad con los estándares no se mejora llamando a un borrador un RFC. Se mejora siguiendo el borrador explícitamente, aislándolo de las rutas HTTP ordinarias, negociando cada extensión, limitando cada recurso de sesión y probando el comportamiento de cancelación y fallo.

Por qué esta amplitud importa en la producción

Un error de estándares rara vez está aislado. El manejo incorrecto de HSTS puede cruzar un límite de caché. Una instrucción QPACK malformada puede terminar solicitudes no relacionadas. Una suposición insegura sobre datos tempranos puede repetir una operación. Una clave de caché QUERY que omite el cuerpo de la solicitud puede devolver el resultado de una consulta diferente. Un proxy que elimina trailers o maneja incorrectamente la cancelación puede cambiar silenciosamente un protocolo de aplicación.

La arquitectura de Webship trata estos como asuntos conectados. Los límites del analizador, la inspección de seguridad, la caché, el proxy inverso, el estado del transporte y la instrumentación comparten contratos explícitos. El resultado es un servidor que puede moverse entre HTTP/1.1, HTTP/2, HTTP/3, entrega estática, proxy inverso, transmisión y WebTransport sin darle a cada modo una definición diferente de corrección.

Verifica la afirmación

No confíes en un superlativo. Lee la [documentación de Webship 1.3.1](/docs/1.3.1), inspecciona la configuración y los límites del protocolo, y reproduce el comportamiento publicado. Luego, [descarga Webship](/downloads) y prueba los casos límite que importan para tu sistema.