Webship: Der RFC-kompatibelste Webserver der Welt

Das Web wird durch genaue Vereinbarungen zusammengehalten. Ein Content-Length-Feld muss an jedem Knoten dasselbe bedeuten. Ein Cache darf keine Antwort wiederverwenden, die eine Validierung erfordert. Ein fehlerhafter HTTP/3-Feldabschnitt muss im richtigen Umfang fehlschlagen. Eine sichere Methode muss auch nach dem Durchlaufen eines Reverse-Proxys sicher bleiben.

Webship 1.3.1 basiert auf einer Regel: Geschwindigkeit zählt nur, wenn die Bytes ihre Bedeutung behalten.

Deshalb beschreiben wir Webship als den RFC-kompatibelsten Allzweck-Webserver der Welt. Dies ist eine technische Aussage mit einem sichtbaren Rahmen, nicht die Behauptung, dass jedes optionale Feature in jedem RFC vorhanden ist. Die nachstehende Karte nennt die 52 RFCs, die das aktive Serververhalten von Webship oder seine eigenen Protokollgrundlagen beeinflussen. Aktuelle Standards stehen an erster Stelle. Abgelöste Dokumente werden als Kompatibilitätslinie gekennzeichnet. Entwurfspezifikationen werden nicht als RFCs umbenannt.

Kompatibilität ist Verhalten, kein Abzeichen

Webship wendet Standards an den Stellen an, an denen Produktionsserver am häufigsten unklar werden:

• HTTP/1.1-Rahmung lehnt widersprüchliche Längen, ungültige Transfer-Codierungen, übergroße Anforderungsziele, fehlerhafte Chunks und Request-Smuggling-Formen ab.
• HTTP/2 und HTTP/3 lehnen verbotene Verbindungsfelder ab, validieren Pseudo-Felder, begrenzen komprimierte Feldabschnitte und halten Stream-Fehler von Verbindungsfehlern getrennt.
• Statische Dateien bewahren HEAD-Semantik, Validatoren, Reihenfolge von Vorbedingungen, Byte-Bereiche, Weiterleitungen und Inhaltstypen.
• Der Reverse-Proxy bewahrt Framing, Abbruch, Trailer, Upgrades, sichere Wiederholungen und Weiterleitungsidentität, während er Hop-by-Hop-Felder entfernt.
• Der Cache berechnet Alter, Frische, Revalidierung, Vary, Ungültigmachung und Regeln für die Nutzung von veraltetem Inhalt, anstatt das Caching als einfachen Schlüssel-Wert-Kurzbefehl zu behandeln.
• TLS, QUIC, ACME, frühe Daten und WebTransport verwenden begrenzten Zustand und explizite Fehlerpolitik.

Die gleichen Regeln gelten auf dem Schnellweg. Webship definiert keinen „richtigen“ Weg und einen anderen Benchmark-Weg.

HTTP-Semantik, Rahmen, Caching und Proxying

• RFC 3986 — Einheitlicher Ressourcen-Identifier (URI): Generische Syntax. Webship normalisiert relative Location- und Content-Location-Verweise, einschließlich Punktsegmente, bevor Entscheidungen zur Cache-Invalidierung getroffen werden.
• RFC 6455 — Das WebSocket-Protokoll. Reverse-Proxy-Updates validieren den WebSocket-Schlüssel, akzeptieren Wert, Subprotokoll, Erweiterungen und Tunnel-Übergang.
• RFC 6585 — Zusätzliche HTTP-Statuscodes. Für übergroße Anforderungsfelder wird die definierte 431-Antwort verwendet, wenn eine HTTP-Antwort noch möglich ist.
• RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security wird nur über eine sichere Verbindung gesendet und gelangt niemals von einem transportneutralen Cache-Eintrag auf unverschlüsseltes HTTP.
• RFC 7235 — HTTP/1.1 Authentifizierung. Authentifizierungsschema-Tokens werden ohne Beachtung der Groß-/Kleinschreibung geparst, einschließlich der geschützten MCP-Steueroberfläche. Ihre allgemeinen HTTP-Semantiken sind jetzt in RFC 9110 zu finden.
• RFC 7239 — Weitergeleitete HTTP-Erweiterung. Betreiber können ein standardbasiertes Forwarded-Feld, veraltete X-Forwarded-Felder, beides oder keines auswählen; nicht vertrauenswürdige eingehende Identitätsfelder werden zuerst entfernt.
• RFC 7540 — HTTP/2. Dies wird als HTTP/2-Kompatibilitätslinie beibehalten; der aktive HTTP/2-Vertrag ist dessen Nachfolger, RFC 9113.
• RFC 7541 — HPACK: Header-Komprimierung für HTTP/2. Webships eigener HTTP/2-Stack begrenzt den Decoder-Zustand und die Encoder-Tabellen, während das HPACK-Wire-Format und die Huffman-Codierung beibehalten werden.
• RFC 7838 — HTTP Alternative Services. Alt-Svc bewirbt einen HTTP/3-Endpunkt, ohne die durch die URL dargestellte Herkunft zu ändern.
• RFC 8441 — Bootstrapping von WebSockets mit HTTP/2. Webship unterstützt die nachgelagerte erweiterte-CONNECT-Verhandlungsgrundlage. Es wird nicht vorgetäuscht, dass ein HTTP/1.1-Upstream HTTP/2 extended CONNECT implementiert; nicht unterstützte Upstream-Kombinationen schlagen explizit fehl.
• RFC 8470 — Verwendung von Early Data in HTTP. Frühzeitige Anfragen, die Webship nicht verarbeitet, erhalten 425 Too Early, anstatt unter unsicheren Wiederholungsannahmen behandelt zu werden.
• RFC 8941 — Strukturierte Feldwerte für HTTP. HTTP-Prioritätswerte verwenden das Parsen von strukturierten Felder-Dictionaries; fehlerhafte optionale Felder werden vollständig ignoriert.
• RFC 9110 — HTTP-Semantik. Methoden, Statuscodes, Felder, Validatoren, Voraussetzungen, Weiterleitungen, Inhaltsmetadaten, HEAD, CONNECT, OPTIONS und Bereichssemantik teilen einen aktuellen Vertrag über die Protokollversionen hinweg.
• RFC 9111 — HTTP-Caching. Webship implementiert korrigiertes Alter, explizite Frische, Vary, only-if-cached, must-revalidate, proxy-revalidate, sichere Nutzung veralteter Inhalte und Ungültigmachung von effektiven und verwandten URIs.
• RFC 9112 — HTTP/1.1. Anfragezeile, Feld, Körperlänge, Transfer-Codierung, Chunk, Trailer, Persistenz und Close-begrenzte Regeln werden vor der Anwendungsausführung durchgesetzt.
• RFC 9113 — HTTP/2. Pseudo-Feldreihenfolge, Autorität, verbotene Verbindungsfelder, TE-Beschränkungen, Lebenszyklus des Streams, Flusskontrolle, GOAWAY und Fehlerbereich werden vom H2-Pfad von Webship behandelt.
• RFC 9114 — HTTP/3. Webship besitzt die Pfade für Anfragen, Steuerströme, SETTINGS, kritische Ströme, Abbruch sowie Stream-gegen-Verbindung-Fehler, die von seinem HTTP/3-Server verwendet werden.
• RFC 9204 — QPACK: Feldkompression für HTTP/3. Die Kapazität der dynamischen Tabelle ist durch das angekündigte Limit begrenzt, Befehlströme bleiben auch bei null Kapazität analysierbar, und ein ungültiger Zustand wird zum erforderlichen QPACK-Fehler.
• RFC 9218 — Erweiterbares Priorisierungsschema für HTTP. Dringlichkeit und inkrementelle Zustellung leiten die HTTP/3-Planung, während unbekannte Prioritätsparameter erweiterbar bleiben.
• RFC 9220 — Bootstrapping von WebSockets mit HTTP/3. Webship implementiert die HTTP/3 extended-CONNECT SETTINGS-Basis, die von modernen getunnelten Protokollen verwendet wird; das bedeutet nicht, dass jedes mögliche CONNECT-Protokoll akzeptiert wird.
• RFC 9297 — HTTP-Datagramme und das Kapselprotokoll. WebTransport-Sitzungen verwenden begrenztes Kapsel-Decodieren und HTTP-Datagrammzuordnung, wobei unbekannte Kapseln als Erweiterungspunkte statt als Parser-Fehler behandelt werden.
• RFC 9421 — HTTP-Nachrichtensignaturen. Optionale Ed25519-Antwortherkunft kann die Webship-Version und Konfigurationsidentität abdecken, ohne TLS oder Anwendungsauthentifizierung zu ersetzen.
• RFC 10008 — Die HTTP QUERY-Methode. Webship behandelt QUERY als sicher und idempotent, bewahrt seinen Körper beim Weiterleiten durch einen Proxy, schließt Körper und Repräsentations-Metadaten in die Cache-Identität ein, verbietet heuristische Frische, unterstützt bedingtes Verhalten und Bereichsverhalten und macht einen Cache niemals ungültig, nur weil QUERY verwendet wurde.

QUIC-Transport und Staukontrolle

• RFC 3465 — TCP-Staukontrolle mit angemessener Byte-Zählung. Die Logik der angemessenen Byte-Zählung ist Teil der NewReno-Staukontrolllinie, die in Webships QUIC-Implementierung verwendet wird.
• RFC 4303 — IP Encapsulating Security Payload. Webship implementiert IPsec ESP nicht; sein QUIC-Paket-Deduplizierer verwendet die Anti-Replay-Technik mit gleitendem Fenster aus dem RFC nur als Implementierungslinie.
• RFC 5681 — TCP-Staukontrolle. Verlust- und Umsortierungsschwellen übernehmen die etablierten Staukontrollgrenzen, wobei QUIC auf der TCP-Praxis aufbaut.
• RFC 6298 — Berechnung des TCP-Wiederübertragungs-Timers. Berechnungen der geglätteten Round-Trip-Zeit und der Varianz tragen zum QUIC-Wiederherstellungsmodell bei.
• RFC 8312 — CUBIC für schnelle Langstreckennetze. Dies ist die frühere CUBIC-Spezifikation, die als Algorithmuslinie beibehalten wird; RFC 9438 ist der aktuelle Standard.
• RFC 8899 — Packetization Layer Path MTU Discovery für Datagrammtransporte. Konfigurierbares DPLPMTUD entdeckt die nutzbare QUIC-Datagrammgröße, ohne sich auf fragile Netzwerkschichtsignale zu verlassen.
• RFC 8999 — Versionsunabhängige Eigenschaften von QUIC. Lange Header, Verbindungs-IDs, Versionsverhandlungen und unveränderliches Parsen bleiben sicher, bevor ein versionsspezifischer Decoder ausgeführt wird.
• RFC 9000 — QUIC: Ein UDP-basierter multiplexierter und sicherer Transport. Verbindungs-IDs, Streams, Flusskontrolle, Migration, Adressvalidierung, Retry, zustandsloses Zurücksetzen, Transportparameter und Schließverhalten bilden die HTTP/3-Transportbasis von Webship.
• RFC 9001 — Verwendung von TLS zur Sicherung von QUIC. Anfangsgeheimnisse, Paket-Schutz, Header-Schutz, Retry-Integrität, Schlüsselphasen und TLS-Integration folgen den QUIC-TLS-Regeln.
• RFC 9002 — QUIC-Verlustdetektion und Staukontrolle. Paketnummern-Räume, Bestätigungen, PTO, Verlustdetektion, Wiederherstellung und Stauabrechnung treiben die Transportsicherheit voran.
• RFC 9221 — Eine unzuverlässige Datagramm-Erweiterung für QUIC. Aushandelte QUIC-DATAGRAMM-Frames übertragen unzuverlässigen WebTransport-Verkehr, ohne ihn in Stream-Inhalt umzuwandeln.
• RFC 9287 — Greasing des QUIC-Bits. Das Greasing des QUIC-Bits reduziert die Versteinerung, während die Sicherheit der Aushandlung erhalten bleibt.
• RFC 9308 — Anwendbarkeit des QUIC-Transportprotokolls. Betriebsvorgaben wie begrenzte Leerlaufzeit und Bereitstellungsrichtlinien informieren die Produktionstransportpolitik von Webship.
• RFC 9369 — QUIC Version 2. Version 2-Pakettypen, Initialschlüssel, Retry-Integrität, Schlüsselaktualisierungen und Versionsaushandlung werden zusammen mit QUIC v1 implementiert.
• RFC 9438 — CUBIC für schnelle und Langstreckennetze. Der aktuelle CUBIC-Standard regelt Webships CUBIC-Staukontroller; BBR und NewReno bleiben auswählbar, wenn die Arbeitslast dies erfordert.

TLS, Zertifikate und automatische Zertifikatsverwaltung

• RFC 3339 — Datum und Uhrzeit im Internet: Zeitstempel. ACME-Erneuerungszeiträume verwenden interoperable Internet-Zeitstempel.
• RFC 4648 — Base16, Base32 und Base64-Datenkodierungen. ACME JOSE-Werte und WebSocket-Handshake-Material verwenden die erforderlichen Base64- und Base64url-Alphabete sowie die Padding-Regeln.
• RFC 5280 — Internet X.509 PKI-Zertifikat- und CRL-Profil. Die Zertifikatsanalyse und die generierten Challenge-Zertifikate verwenden korrekte DNS- und binäre IP-subjectAltName-Formen.
• RFC 5869 — HMAC-basierte Extract-and-Expand-Schlüsselerzeugungsfunktion. HKDF-SHA-256 und HKDF-SHA-384 Ableitung, einschließlich Ausgabebegrenzungen, bildet die Grundlage für TLS- und QUIC-Schlüssel.
• RFC 6066 — TLS-Erweiterungen. SNI wählt DNS-Identitäten aus, während literal IP-Adressen korrekt von der gewöhnlichen HostName-Form ausgeschlossen werden.
• RFC 7301 — TLS-Anwendungsprotokoll-Aushandlung. ALPN wählt HTTP/1.1, HTTP/2, HTTP/3 und das isolierte ACME-Herausforderungsprotokoll an der TLS-Grenze aus.
• RFC 7638 — JSON Web Key Thumbprint. ACME-Kontoschlüssel-Thumbprints werden in der kanonischen JWK-Form abgeleitet.
• RFC 7807 — Problem-Details für HTTP-APIs. Webship verwendet das Problem-Dokument-Format, das von RFC 8555 ACME-Servern verlangt wird. Die neuere Problem-Details-Spezifikation ersetzt es für neue allgemeine APIs, aber ACME’s normative Abhängigkeit bleibt explizit bestehen.
• RFC 8446 — TLS 1.3. Webship verwendet TLS 1.3 für öffentliches TLS, einschließlich Sitzungstickets, Schlüsselaktualisierungen, Warnungen, Early-Data-Richtlinien und QUIC-Schlüsselableitung.
• RFC 8555 — Automatische Zertifikatsverwaltungsumgebung. Account-, Bestell-, Autorisierungs-, Challenge-, Finalisierungs-, Zertifikat-Download- und Erneuerungsabläufe werden mit begrenzter Eingabeverarbeitung automatisiert.
• RFC 8737 — ACME TLS-ALPN-01 Challenge. Ein nur für Herausforderungen vorgesehenes TLS-Pfad verhandelt nur acme-tls/1 und stellt die erforderliche kritische acmeIdentifier-Zertifikatserweiterung bereit.
• RFC 8738 — ACME IP-Identifier-Validierungserweiterung. Webship unterstützt IPv4- und IPv6-Zertifikatsbestellungen, binäre IP-SANs und Reverse-Address-SNI für die IP-TLS-ALPN-01-Validierung.
• RFC 9525 — Dienstidentität in TLS. DNS-Namen und IP-Identitäten werden nach den aktuellen Regeln zur Dienstidentität abgeglichen, ohne Platzhalter oder Abkürzungen für IP-Adressen im Common Name.
• RFC 9773 — ACME-Erneuerungsinformations-Erweiterung. Erneuerungsfenster können von der CA kommen, wodurch Webship die Erneuerungen sicher verteilen kann, anstatt einen starren lokalen Zeitplan zu verwenden.

WebTransport: genau darüber, was standardisiert ist

WebTransport über HTTP/3 wird nicht als fünfzigdritter RFC gezählt. Ab Webship 1.3.1 bleibt seine Wire-Mapping-Spezifikation draft-ietf-webtrans-http3-16. Webship implementiert diesen Entwurf auf der standardisierten HTTP/3-, erweiterten CONNECT-, QUIC-DATAGRAM-, HTTP-Datagram- und Capsule-Ebene, die oben genannt wurden. Es implementiert auch die ausgehandelte RESET_STREAM_AT-Erweiterung, die erforderlich ist, um ein zuverlässiges, auf Sitzungen bezogenes Präfix zu bewahren, wenn ein WebTransport-Stream zurückgesetzt wird.

Diese Unterscheidung ist wichtig. Die Kompatibilität mit Standards wird nicht dadurch verbessert, dass ein Entwurf als RFC bezeichnet wird. Sie wird dadurch verbessert, dass der Entwurf explizit verfolgt wird, von gewöhnlichen HTTP-Pfaden isoliert wird, jede Erweiterung ausgehandelt wird, jede Sitzungsressource begrenzt wird und das Verhalten bei Abbruch und Fehlern getestet wird.

Warum diese Breite in der Produktion wichtig ist

Ein Standards-Bug ist selten isoliert. Falsches HSTS-Handling kann eine Cache-Grenze überschreiten. Eine fehlerhafte QPACK-Anweisung kann nicht zusammenhängende Anfragen beenden. Eine unsichere Early-Data-Annahme kann eine Operation erneut ausführen. Ein QUERY-Cache-Schlüssel, der den Anfragekörper weglässt, kann das Ergebnis einer anderen Abfrage zurückgeben. Ein Proxy, der Trailer entfernt oder Abbrüche falsch behandelt, kann ein Anwendungsprotokoll stillschweigend ändern.

Die Architektur von Webship behandelt diese als miteinander verbundene Anliegen. Parser-Grenzen, Sicherheitsprüfung, Caching, Reverse-Proxy, Transportzustand und Instrumentierung teilen explizite Verträge. Das Ergebnis ist ein Server, der zwischen HTTP/1.1, HTTP/2, HTTP/3, statischer Bereitstellung, Reverse-Proxy, Streaming und WebTransport wechseln kann, ohne dass jeder Modus eine andere Definition von Korrektheit benötigt.

Überprüfen Sie die Behauptung

Nehmen Sie ein Superlativ nicht auf Vertrauen hin. Lesen Sie die [Webship 1.3.1 Dokumentation](/docs/1.3.1), untersuchen Sie die Konfigurations- und Protokollgrenzen und reproduzieren Sie das veröffentlichte Verhalten. Laden Sie dann [Webship herunter](/downloads) und testen Sie die Grenzfälle, die für Ihr System wichtig sind.