De flesta infrastrukturlag betalar inte för en webbserver isolerat. De betalar för allt som ackumuleras runt den: överflödig beräkningskapacitet reserverad för topptrafik, separata säkerhetstjänster, telemetriagenter, konfigurationsautomation och den ingenjörstid som krävs för att hålla dessa delar konsekventa.
Det gör webbservern till ett infrastrukturkostnadsbeslut. En snabbare binär fil är användbar. Ett mindre, mer hanterbart produktsystem är det verkliga affärsresultatet.
Genomströmning är viktig när det påverkar kapacitetsplanen
Webship är byggd i Rust för högbelastad statisk leverans och omvänd proxying över HTTP/1.1, HTTP/2, och HTTP/3. I den aktuella verifierade Debian-direktserveringsmatrisen, upprätthöll fyra Webship-arbetare en median på 1 041 848 förfrågningar per sekund över h2c och 307 727 krypterade förfrågningar per sekund över HTTP/3.
En separat, samtidig jämförelse på samma värd ger konkurrenskonteksten. I det körningen levererade Webship 1 015 870 förfrågningar per sekund över h2c mot 192 324 för Nginx. Över HTTP/3 TLS levererade Webship 317 138 förfrågningar per sekund mot 35 207 för Envoy. Varje publicerat resultat är medianen av fem accepterade prover med isolerade CPU-set och fel-fria korrekthetsgrindar.
Dessa mätningar är bevis, inte en universell kapacitetlöfte. Applikationens beteende, svarsstorlek, TLS-konfiguration, cacheträffrate, nätverksförhållanden och upstream-latens kommer att påverka resultatet. Den relevanta frågan är inte om ett huvudnummer överförs oförändrat. Det är om Webship låter din arbetsbelastning uppfylla sina serviceobjektiv med färre noder eller mer marginal per nod.
Granska den fullständiga metodiken och varje konkurrentresultat på Webship benchmark-sidan.
Konsolidering är där ekonomin blir verklig
En konventionell edge kan innebära en webbserver, omvänd proxy, TLS-terminator, cache, WAF, hastighetsbegränsare, mått-endpoint och en separat operativ API. Varje komponent kan varautmärkt, men det kombinerade systemet skapar fler konfigurationsytor, nätverksövergångar, uppgraderingar, felmodeller och fakturor.
Webship tar med statiska filer, applikationsproxies, TLS 1.3, HTTP/3, WebTransport, caching, WAF, DDoS-kontroller, API-sköld, svarssäkerhetshuvuden, observerbarhet och operativ kontroll i en distribuerbar binär fil.
För arbetsbelastningar som passar den gränsen kan konsolidering minska mer än CPU-behovet. Det kan minska antalet tjänster som en ingenjör måste tillhandahålla, övervaka, säkra och rekonciliera under en incident. Webship påstår inte att ersätta ett globalt CDN, ett uppströmsrensande nätverk eller varje specialist säkerhetsprodukt.uct. Det ger teamen en stark självhostad grund innan en annan tjänst blir nödvändig.
AI-native bör innebära kontrollerade operationer
Att lägga till ett chattgränssnitt till infrastrukturen är inte operationell automation. En AI-native webbserver behöver en begränsad kontrollyta, tydlig policy, validering, granskningsbarhet och återställning.
Webship exponerar autentiserade Model Context Protocol-operationer för att läsa och validera konfiguration, förklara förfrågningspolicy, jämföra skuggändringar, köra trafikscenarier, inspektera begränsad diagnostik, hantera cacheposter, kontrollera TLS-status och tillämpa eller återställa godkända runtime-säkra ändringar.
Kontrolllyssnaren är isoleradted från den publika trafikvägen och bör förbli på loopback eller ett privat nätverk bakom TLS och en stark bearer-token. Runtime-säkra patchar kan appliceras utan att avbryta trafiken. Ändringar i lyssnare, TLS och autentisering kräver fortfarande en avsiktlig omstart. Den skillnaden gör automatiseringen användbar utan att låtsas att varje produktionsändring är risk-free.
See AI-agent quick start för den operativa model.
Säkerhet hör hemma i den första configuration
Webship börjar med en säkerhetsbaslinje: WAF-inspektion, per-klient DDoS-kontroller, botutmaning, validering av API-endpoint och innehållstyp, svarsäkerhetsheaders och dot-file-skydd. Kontrollerna körs idataplan istället för att lägga till ännu ett standardnätverkshopp.
Inbyggd betyder inte klar. Operatörer ansvarar fortfarande för brandväggspolicy, hemligheter, ursprungssäkerhet, uppdateringar, applikationssäkerhet och arbetsbelastningsspecifik regeljustering. Fördelen är att den första distributionen redan har en sammanhängande plats för att genomdriva och inspektera dessa beslut.
Bygg affärsfallet på din egen trafik
En trovärdig utvärdering bör besvara fyra frågor:
- Bevarar Webship korrektheten av förfrågningar över dina statiska, proxy-, WebSocket- och moderna protokollvägar?
- Vad händer med ihållande genomströmning, toppfördröjning, CPU och minne under representativ trafik?
- Hur många edge-komponenter kan konsolideras utan att förlora en kapacitet som ert team är beroende av?
- Kan operatörer och AI-agenter diagnostisera, validera, ändra och rulla tillbaka policyn inom din säkerhetsmodell?
Run Webship bredvid den befintliga edge, spela upp produktionsliknande trafik och hålla den gamla lyssnaren tillgänglig för rollback. Konvertera uppmätt hållbar genomströmning till en nodräkningsmodell och lägg sedan till driftskostnaden för varje komponent som återstår. Det ger ett försvarbart infrastrukturbeslut istället för en benchmark-driven guess.
Webship erbjuder en 14-dagars utvärderingsväg för team som vill testa ekonomin innan de binder sig. Börja med documentation, välj en signerad version från downloads, och jämför den med det system du använder idag.