Retour au blog Webship

Ingénierie Webship

Webship : Le serveur web le plus compatible RFC au monde

Webship transforme les exigences des RFC en comportements explicites à travers HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, la mise en cache, le proxy inverse, WebTransport, ACME et la nouvelle méthode QUERY. Explorez la carte complète des 52 normes RFC.

Le web est maintenu par des accords exacts. Un champ Content-Length doit signifier la même chose à chaque étape. Un cache ne doit pas réutiliser une réponse qui nécessite une validation. Une section de champ HTTP/3 mal formée doit échouer au niveau approprié. Une méthode sûre doit rester sûre après être passée par un proxy inverse.

Webship 1.3.1 est construit autour d'une règle : la vitesse compte seulement lorsque les octets conservent leur signification.

C’est pourquoi nous décrivons Webship comme le serveur web généraliste le plus compatible RFC au monde. Il s’agit d’une affirmation technique avec une limite visible, et non d’une affirmation selon laquelle chaque fonctionnalité optionnelle de chaque RFC existe. La carte ci-dessous nomme les 52 RFC qui affectent le comportement actif du serveur de Webship ou ses fondations protocolaires propres. Les standards actuels viennent en premier. Les documents remplacés sont identifiés comme une lignée de compatibilité. Les projets de spécifications ne sont pas requalifiés en tant que RFC.

La compatibilité est un comportement, pas un badge

Webship applique des normes aux endroits où les serveurs de production deviennent le plus souvent ambigus :

  • Le cadrage HTTP/1.1 rejette les longueurs conflictuelles, les codages de transfert invalides, les cibles de requête surdimensionnées, les fragments malformés et les formes de contrebande de requête.
  • HTTP/2 et HTTP/3 rejettent les champs de connexion interdits, valident les pseudo-champs, limitent les sections de champs compressés et maintiennent les erreurs de flux séparées des erreurs de connexion.
  • Les fichiers statiques préservent la sémantique HEAD, les validateurs, l'ordre des préconditions, les plages d'octets, les redirections et les types de contenu.
  • Le proxy inverse préserve l'encadrement, l'annulation, les en-têtes de fin, les mises à niveau, les réessais sûrs et l'identité de transfert tout en supprimant les champs de saut par saut.
  • Le cache calcule l'âge, la fraîcheur, la revalidation, Vary, l'invalidation et les règles d'utilisation périmée plutôt que de traiter la mise en cache comme un raccourci clé-valeur.
  • TLS, QUIC, ACME, les données précoces et WebTransport utilisent un état borné et une politique d'échec explicite.

Les mêmes règles s'appliquent sur le chemin rapide. Webship ne définit pas un « chemin correct » et un chemin de référence différent.

Sémantique HTTP, structuration, mise en cache et intermédiation

  • RFC 3986 — Identifiant Uniforme de Ressource (URI) : Syntaxe Générique. Webship normalise les références relatives Location et Content-Location, y compris les segments point, avant les décisions d'invalidation du cache.
  • RFC 6455 — Le protocole WebSocket. Les mises à niveau via un reverse-proxy valident la clé WebSocket, la valeur acceptée, le sous-protocole, les extensions et la transition de tunnel.
  • RFC 6585 — Codes d'état HTTP supplémentaires. Les champs de requête surdimensionnés utilisent la réponse 431 définie lorsque qu'une réponse HTTP est encore possible.
  • RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security n'est émis qu'au-dessus d'un transport sécurisé et ne fuit jamais d'une entrée de cache neutre par rapport au transport vers le HTTP en clair.
  • RFC 7235 — Authentification HTTP/1.1. Les jetons du schéma d'authentification sont analysés de manière insensible à la casse, y compris la surface de contrôle MCP protégée. Sa sémantique HTTP générale se trouve maintenant dans le RFC 9110.
  • RFC 7239 — Extension HTTP Forwarded. Les opérateurs peuvent choisir un champ Forwarded basé sur les standards, les anciens champs X-Forwarded, les deux, ou aucun ; les champs d'identité entrants non fiables sont supprimés en premier.
  • RFC 7540 — HTTP/2. Cela est conservé comme lignée de compatibilité HTTP/2 ; le contrat HTTP/2 actif est son successeur, le RFC 9113.
  • RFC 7541 — HPACK : Compression des en-têtes pour HTTP/2. La pile HTTP/2 détenue par Webship limite l'état du décodeur et les tables de l'encodeur tout en préservant le format sur le fil HPACK et le codage Huffman.
  • RFC 7838 — Services HTTP alternatifs. Alt-Svc annonce un point de terminaison HTTP/3 sans modifier l'origine représentée par l'URL.
  • RFC 8441 — Initialisation des WebSockets avec HTTP/2. Webship prend en charge la fondation de négociation extended-CONNECT en aval. Il ne prétend pas qu'un amont HTTP/1.1 implémente extended CONNECT de HTTP/2 ; les combinaisons d'amont non prises en charge échouent explicitement.
  • RFC 8470 — Utilisation des données anticipées dans HTTP. Les requêtes anticipées que Webship ne traitera pas reçoivent 425 Too Early au lieu d'être traitées avec des hypothèses de relecture non sécurisées.
  • RFC 8941 — Valeurs de champs structurés pour HTTP. Les valeurs de priorité HTTP utilisent l'analyse de dictionnaire de champ structuré ; les champs optionnels mal formés sont complètement ignorés.
  • RFC 9110 — Sémantique HTTP. Les méthodes, codes d'état, champs, validateurs, préconditions, redirections, métadonnées de contenu, HEAD, CONNECT, OPTIONS et la sémantique des plages partagent un contrat unique à travers les versions du protocole.
  • RFC 9111 — Mise en cache HTTP. Webship implémente l'âge corrigé, la fraîcheur explicite, Vary, only-if-cached, must-revalidate, proxy-revalidate, l'utilisation sûre des contenus périmés et l'invalidation des URI effectives et associées.
  • RFC 9112 — HTTP/1.1. Les règles de ligne de requête, de champ, de longueur du corps, de codage de transfert, de chunk, de trailer, de persistance et de fermeture délimitée sont appliquées avant la distribution à l'application.
  • RFC 9113 — HTTP/2. L'ordre des pseudo-champs, l'autorité, les champs de connexion interdits, les restrictions TE, le cycle de vie des flux, le contrôle de flux, GOAWAY et la portée des erreurs sont gérés par le chemin H2 appartenant à Webship.
  • RFC 9114 — HTTP/3. Webship possède les chemins de requête, flux de contrôle, SETTINGS, flux critique, annulation et erreur flux-contre-connexion utilisés par son serveur HTTP/3.
  • RFC 9204 — QPACK : Compression des champs pour HTTP/3. La capacité de la table dynamique est limitée par la limite annoncée, les flux d'instructions restent analysables à capacité zéro, et un état invalide devient l'erreur QPACK requise.
  • RFC 9218 — Schéma de priorisation extensible pour HTTP. L'urgence et la livraison incrémentale guident la planification HTTP/3 tandis que les paramètres de priorité inconnus restent extensibles.
  • RFC 9220 — Initialisation des WebSockets avec HTTP/3. Webship implémente la base SETTINGS étendues-CONNECT de HTTP/3 utilisée par les protocoles modernes en tunnel ; cela n'implique pas que tous les protocoles CONNECT soient acceptés.
  • RFC 9297 — Datagrammes HTTP et le protocole Capsule. Les sessions WebTransport utilisent un décodage de capsule limité et une association de datagrammes HTTP, les capsules inconnues étant traitées comme des points d’extension plutôt que comme des échecs de l’analyseur.
  • RFC 9421 — Signatures de messages HTTP. La traçabilité facultative des réponses Ed25519 peut couvrir l'identité de la version et de la configuration de Webship sans remplacer TLS ou l'authentification de l'application.
  • RFC 10008 — La méthode HTTP QUERY. Webship considère QUERY comme sûr et idempotent, préserve son corps lors du passage par un proxy, inclut le corps et les métadonnées de représentation dans l'identité du cache, interdit la fraîcheur heuristique, prend en charge le comportement conditionnel et par plage, et n'invalide jamais un cache simplement parce que QUERY a été utilisé.

Transport QUIC et contrôle de congestion

TLS, certificats et gestion automatique des certificats

WebTransport : précis sur ce qui est standardisé

WebTransport sur HTTP/3 n'est pas compté comme un cinquante-troisième RFC. À partir de Webship 1.3.1, sa cartographie en ligne reste draft-ietf-webtrans-http3-16. Webship implémente ce brouillon au-dessus du HTTP/3 standardisé, du CONNECT étendu, du QUIC DATAGRAM, du Datagram HTTP et des couches Capsule nommées ci-dessus. Il implémente également l'extension négociée RESET_STREAM_AT requise pour préserver un préfixe d'identification de session fiable lorsqu'un flux WebTransport est réinitialisé.

Cette distinction est importante. La compatibilité avec les standards n’est pas améliorée en appelant un brouillon un RFC. Elle est améliorée en suivant explicitement le brouillon, en l’isolant des chemins HTTP ordinaires, en négociant chaque extension, en limitant chaque ressource de session et en testant le comportement en cas d’annulation et de défaillance.

Pourquoi cette étendue est importante dans la production

Un bug de standards est rarement isolé. Une gestion incorrecte du HSTS peut traverser une limite de cache. Une instruction QPACK mal formée peut terminer des requêtes non liées. Une hypothèse de données précoces non sécurisée peut rejouer une opération. Une clé de cache QUERY qui omet le corps de la requête peut renvoyer le résultat d'une requête différente. Un proxy qui supprime les trailers ou gère mal l'annulation peut modifier silencieusement un protocole d'application.

L'architecture de Webship considère ces éléments comme des préoccupations liées. Les limites du parseur, l'inspection de sécurité, la mise en cache, le proxy inverse, l'état du transport et l'instrumentation partagent des contrats explicites. Le résultat est un serveur capable de passer entre HTTP/1.1, HTTP/2, HTTP/3, la livraison statique, le proxy inverse, le streaming et WebTransport sans donner à chaque mode une définition différente de la validité.

Vérifiez la réclamation

Ne prenez pas un superlatif pour argent comptant. Lisez la [documentation de Webship 1.3.1](/docs/1.3.1), inspectez la configuration et les limites du protocole, et reproduisez le comportement publié. Ensuite, [téléchargez Webship](/downloads) et testez les cas limites qui sont importants pour votre système.

Ingénierie Webship

Streaming avec Webship : Haut débit sans compromettre l'exactitude

Apprenez comment Webship sert et fait office de proxy pour de gros fichiers médias via HTTP/1.1, HTTP/2 et HTTP/3 en utilisant kTLS adaptatif, le contrôle de débit BBR, des tampons limités et des dispositifs d'intégrité sans erreur.

Lire l'article

Votre serveur Web est une décision de coût d'infrastructure

Webship combine la livraison à haut débit en Rust, les protocoles modernes, la protection intégrée, l'observabilité locale et les opérations natives de l'IA dans un seul runtime, offrant aux équipes d'infrastructure une voie crédible vers moins de serveurs et moins de composants en périphérie.

Lire l'article

Webship 1.3.1 : Capacité accrue pour HTTP/2 et les proxys inverses

Webship 1.3.1 augmente la capacité directe h2c de 34,19 %, le HTTP/2 TLS direct de 26,67 % et le H1 de reverse-proxy de 15,10 % par rapport à la version 1.2.0, tout en renforçant la stabilité et la précision du transport.

Lire l'article