Webship: Ang Pinaka RFC-Compatible na Web Server sa Mundo

Ang web ay pinananatiling magkakaugnay sa pamamagitan ng tumpak na kasunduan. Ang isang Content-Length field ay dapat may parehong kahulugan sa bawat paglipat. Ang isang cache ay hindi dapat muling gamitin ang isang tugon na nangangailangan ng pagpapatunay. Ang isang maling hugis na HTTP/3 field section ay dapat mabigo sa tamang saklaw. Ang isang ligtas na pamamaraan ay dapat manatiling ligtas matapos itong dumaan sa isang reverse proxy.

Ang Webship 1.3.1 ay binuo sa paligid ng isang patakaran: mahalaga ang bilis lamang kapag nananatili ang kahulugan ng mga byte.

Kaya naman inilarawan namin ang Webship bilang pinaka-RFC-compatible na pangkalahatang layunin na web server sa buong mundo. Ito ay isang pahayag sa inhinyeriya na may malinaw na hangganan, hindi pahayag na ang bawat opsyonal na tampok sa bawat RFC ay umiiral. Ang mapa sa ibaba ay naglilista ng 52 RFC na nakaaapekto sa aktibong galaw ng Webship server o sa mga pinanghahawakang pundasyon ng protocol nito. Ang kasalukuyang pamantayan ang nauna. Ang mga napalitang dokumento ay tinutukoy bilang compatibility lineage. Ang mga draft na espesipikasyon ay hindi muling tinatawag bilang RFC.

Ang pagkakatugma ay kilos, hindi isang tatak

Ang Webship ay naglalapat ng mga pamantayan sa mga lugar kung saan madalas nagiging malabo ang mga production server:

• Tinatanggihan ng HTTP/1.1 framing ang magkasalungat na haba, di-wastong mga transfer coding, sobrang laki na mga target ng kahilingan, maling hugis ng chunks, at mga anyo ng request-smuggling.
• Itinatanggihan ng HTTP/2 at HTTP/3 ang ipinagbabawal na mga patlang ng koneksyon, sinusuri ang mga pseudo-field, nililimitahan ang mga compressed na seksyon ng patlang, at pinananatiling hiwalay ang mga error sa stream mula sa mga error sa koneksyon.
• Pinapanatili ng mga static na file ang semantika ng HEAD, mga validator, pagkakasunud-sunod ng precondition, mga byte range, mga redirect, at mga uri ng nilalaman.
• Pinapanatili ng reverse proxy ang framing, pagkakansela, trailers, upgrades, ligtas na mga retry, at pagpapasa ng pagkakakilanlan habang tinatanggal ang mga field na hop-by-hop.
• Kinakalkula ng cache ang edad, kasariwaan, muling pagpapatunay, Vary, bisa, at mga patakaran sa paggamit ng lipas sa halip na ituring ang caching bilang isang shortcut na key-value.
• Ang TLS, QUIC, ACME, early data, at WebTransport ay gumagamit ng limitadong estado at tahasang patakaran sa pagkabigo.

Parehong mga patakaran ang nalalapat sa mabilis na daan. Hindi nagtatakda ang Webship ng isang “tamang” daan at ibang benchmark na daan.

Semantika ng HTTP, pag-frame, pag-cache, at pag-proxy

• RFC 3986 — Pantay na Tagatukoy ng Mapagkukunan (URI): Pangkalahatang Sintaks. Pinapantay ng Webship ang mga relatibong reperensya ng Lokasyon at Nilalaman-Lokasyon, kasama ang mga segmentong tuldok, bago ang mga desisyon sa pagwawaksi ng cache.
• RFC 6455 — Ang WebSocket Protocol. Sinusuri ng reverse-proxy upgrades ang WebSocket key, accept value, subprotocol, extensions, at tunnel transition.
• RFC 6585 — Karagdagang HTTP Status Codes. Ang mga sobrang laki na field ng kahilingan ay gumagamit ng tinukoy na 431 na tugon kung saan posible pa rin ang isang tugon ng HTTP.
• RFC 6797 — HTTP Strict Transport Security. Ang Strict-Transport-Security ay ipinapadala lamang sa pamamagitan ng secure na transport at hindi kailanman naipapasa mula sa isang transport-neutral na cache entry papunta sa cleartext HTTP.
• RFC 7235 — Pagpapatotoo ng HTTP/1.1. Ang mga token ng scheme ng pagpapatotoo ay ipinaparse nang hindi sensitibo sa kaso, kabilang ang protektadong MCP control surface. Ang pangkalahatang semantika ng HTTP nito ay ngayon nasa RFC 9110.
• RFC 7239 — Pinalawak na HTTP na Forwarded. Maaaring pumili ang mga operator ng isang pamantayang batay sa patlang na Forwarded, mga lumang patlang na X-Forwarded, pareho, o wala sa isa man; ang mga hindi pinagkakatiwalaang papasok na patlang ng pagkakakilanlan ay tinatanggal muna.
• RFC 7540 — HTTP/2. Ito ay pinananatili bilang pagkakaugnay sa pagiging compatible ng HTTP/2; ang aktibong kontrata ng HTTP/2 ay ang tagapagmana nito, RFC 9113.
• RFC 7541 — HPACK: Pag-compress ng Header para sa HTTP/2. Pinaghihigpitan ng HTTP/2 stack na pagmamay-ari ng Webship ang estado ng decoder at mga talahanayan ng encoder habang pinapanatili ang HPACK wire format at Huffman coding.
• RFC 7838 — HTTP Alternative Services. Ipinapahayag ng Alt-Svc ang isang HTTP/3 endpoint nang hindi binabago ang pinagmulan na kinakatawan ng URL.
• RFC 8441 — Pag-bootstrapping ng WebSockets gamit ang HTTP/2. Sinusuportahan ng Webship ang downstream extended-CONNECT negotiation foundation. Hindi nito ipinagkakaila na ang isang HTTP/1.1 upstream ay nagpapatupad ng HTTP/2 extended CONNECT; ang mga hindi suportadong kombinasyon ng upstream ay malinaw na nabibigo.
• RFC 8470 — Paggamit ng Maagang Data sa HTTP. Ang mga maagang kahilingan na hindi ipoproseso ng Webship ay makakatanggap ng 425 Too Early sa halip na iproseso gamit ang hindi ligtas na mga palagay sa replay.
• RFC 8941 — Mga Structured na Halaga ng Field para sa HTTP. Ang mga halaga ng prioridad ng HTTP ay gumagamit ng parsed na diksyunaryo ng structured-field; ang mga maling anyo ng opsyonal na mga field ay hindi pinapansin nang buo.
• RFC 9110 — HTTP Semantics. Ang mga pamamaraan, status code, mga patlang, mga tagasuri, mga kundisyon bago, mga redirect, metadata ng nilalaman, HEAD, CONNECT, OPTIONS, at mga semantics ng saklaw ay nagbabahagi ng isang kasalukuyang kontrata sa lahat ng bersyon ng protocol.
• RFC 9111 — HTTP Caching. Ipinapatupad ng Webship ang naituwid na edad, tahasang kasariwaan, Vary, only-if-cached, must-revalidate, proxy-revalidate, ligtas na paggamit ng lipas na, at pagbawi ng bisa ng epektibo at may kinalamang mga URI.
• RFC 9112 — HTTP/1.1. Ang request-line, field, body-length, transfer-coding, chunk, trailer, persistence, at close-delimited na mga patakaran ay ipinatutupad bago ang application dispatch.
• RFC 9113 — HTTP/2. Ang pseudo-field na order, awtoridad, ipinagbabawal na mga connection field, mga limitasyon ng TE, lifecycle ng stream, kontrol ng daloy, GOAWAY, at saklaw ng error ay hinahandle ng H2 path na pag-aari ng Webship.
• RFC 9114 — HTTP/3. Pag-aari ng Webship ang kahilingan, control-stream, SETTINGS, critical-stream, pagkansela, at mga path ng error sa stream-laban-sa-connection na ginagamit ng HTTP/3 na server nito.
• RFC 9204 — QPACK: Pag-compress ng Field para sa HTTP/3. Ang kapasidad ng dynamic-table ay limitado ng ipinakitang hangganan, ang mga instruction stream ay nananatiling mai-parse kahit sa zero na kapasidad, at ang hindi wasto na estado ay nagiging kinakailangang QPACK na error.
• RFC 9218 — Napapalawak na Iskema ng Prayoridad para sa HTTP. Ang kagyat at incremental na paghahatid ay gumagabay sa HTTP/3 na pagsasaayos habang ang hindi kilalang mga parameter ng prayoridad ay nananatiling napapalawak.
• RFC 9220 — Pagpapasimula ng WebSockets gamit ang HTTP/3. Ipinapatupad ng Webship ang HTTP/3 extended-CONNECT SETTINGS na pundasyon na ginagamit ng mga modernong tunneled na protocol; hindi nito ipinapahiwatig na tinatanggap ang bawat posibleng CONNECT na protocol.
• RFC 9297 — HTTP Datagrams at ang Capsule Protocol. Ang mga WebTransport session ay gumagamit ng bounded capsule decoding at HTTP Datagram association, kung saan ang mga hindi kilalang capsule ay hinahandle bilang extension points sa halip na mga pagkabigo sa parser.
• RFC 9421 — HTTP Message Signatures. Opsyonal na Ed25519 na pinagmulan ng tugon ay maaaring saklawin ang paglabas at pagkakakilanlan ng configuration ng Webship nang hindi pinapalitan ang TLS o pagpapatunay ng aplikasyon.
• RFC 10008 — Ang HTTP QUERY Method. Tinuturing ng Webship ang QUERY bilang ligtas at idempotent, pinapanatili ang katawan nito sa pamamagitan ng proxying, isinasama ang katawan at representation metadata sa cache identity, ipinagbabawal ang heuristic freshness, sinusuportahan ang conditional at range na pag-uugali, at hindi kailanman binabalewala ang cache lamang dahil ginamit ang QUERY.

Transport ng QUIC at kontrol ng pagsisikip

• RFC 3465 — TCP Pagkontrol ng Pagkaipit gamit ang Angkop na Pagbilang ng Byte. Ang lohika ng angkop na pagbilang ng byte ay bahagi ng NewReno na pinagmulan ng pagkontrol ng pagkaipit na ginagamit ng QUIC na implementasyon ng Webship.
• RFC 4303 — IP Encapsulating Security Payload. Hindi ipinatupad ng Webship ang IPsec ESP; ang deduplikador ng QUIC packet nito ay gumagamit lamang ng sliding-window anti-replay technique ng RFC bilang pinagmulan ng implementasyon.
• RFC 5681 — TCP Congestion Control. Ang mga threshold ng pagkawala at pagbabago ng ayos ay namamana sa itinatag na mga limitasyon ng congestion-control kung saan ang QUIC ay nakabase sa kasanayan ng TCP.
• RFC 6298 — Pagkalkula ng Retransmission Timer ng TCP. Ang pinakinis na round-trip time at mga kalkulasyon ng baryasyon ay nag-aambag sa modelo ng pagsasaayos ng QUIC.
• RFC 8312 — CUBIC para sa Mabilis na Pangmatagalang Distansya na Mga Network. Ito ang mas maagang espesipikasyon ng CUBIC na nanatili bilang linya ng algorithm; ang RFC 9438 ang kasalukuyang pamantayan.
• RFC 8899 — Pagdiskubre ng Packetization Layer Path MTU para sa Mga Datagram na Transport. Ang nako-konpigurang DPLPMTUD ay natutuklasan ang magagamit na laki ng QUIC datagram nang hindi umaasa sa marupok na signal ng network layer.
• RFC 8999 — Mga Ari-arian ng QUIC na Hindi Naka-depende sa Bersyon. Mananatiling ligtas ang mahahabang header, mga ID ng koneksyon, negosasyon ng bersyon, at invariant parsing bago tumakbo ang version-specific decoder.
• RFC 9000 — QUIC: Isang Batay-sa-UDP na Multiplexed at Ligtas na Transport. Ang mga Connection ID, streams, control ng daloy, migration, beripikasyon ng address, Retry, stateless reset, transport parameters, at ugali sa pagsasara ay bumubuo sa base ng HTTP/3 transport ng Webship.
• RFC 9001 — Paggamit ng TLS upang Siguraduhin ang QUIC. Ang mga paunang lihim, proteksyon ng packet, proteksyon ng header, integridad ng Retry, mga yugto ng susi, at integrasyon ng TLS ay sumusunod sa mga patakaran ng QUIC-TLS.
• RFC 9002 — QUIC Pag-detect ng Pagkawala at Kontrol ng Sakuna. Ang mga espasyo ng numero ng pakete, pagkilala, PTO, pag-detect ng pagkawala, paggaling, at pag-account ng sakuna ay nagtutulak sa pagiging maaasahan ng transportasyon.
• RFC 9221 — Isang Hindi Maaasahang Datagram Extension sa QUIC. Ang mga na-negotiate na QUIC DATAGRAM frame ay nagdadala ng hindi maaasahang trapiko ng WebTransport nang hindi ito ginagawa bilang nilalaman ng stream.
• RFC 9287 — Pagpapadulas sa QUIC Bit. Ang pagpapadulas ng QUIC-bit ay nagpapababa ng ossification habang pinapanatili ang kaligtasan ng negosasyon.
• RFC 9308 — Ang Aplikabilidad ng QUIC Transport Protocol. Ang mga operational default tulad ng limitadong oras ng pagka-idle at gabay sa deployment ay nag-iinform sa patakaran sa produksyon ng transport ng Webship.
• RFC 9369 — QUIC Bersyon 2. Ang mga uri ng packet ng Bersyon 2, unang mga susi, integridad ng Retry, pag-update ng susi, at negosasyon ng bersyon ay ipinatupad kasabay ng QUIC v1.
• RFC 9438 — CUBIC para sa Mabilis at Malalayong Netzwerk. Ang kasalukuyang pamantayan ng CUBIC ay namamahala sa CUBIC congestion controller ng Webship; ang BBR at NewReno ay nananatiling maaaring piliin kung kinakailangan ng gawain.

TLS, mga sertipiko, at awtomatikong pamamahala ng sertipiko

• RFC 3339 — Petsa at Oras sa Internet: Mga Timestamp. Ang mga bintana ng renewal ng ACME ay gumagamit ng magkakatugmang mga timestamp sa Internet.
• RFC 4648 — Base16, Base32, at Base64 na Pag-encode ng Datos. Ang mga halaga ng ACME JOSE at materyal para sa handshake ng WebSocket ay gumagamit ng kinakailangang Base64 at Base64url na mga alpabeto at mga patakaran sa padding.
• RFC 5280 — Internet X.509 PKI Certificate at CRL Profile. Ang pag-parse ng sertipiko at ang mga generated na challenge certificates ay gumagamit ng tamang DNS at binary IP na mga anyo ng subjectAltName.
• RFC 5869 — HMAC-based Extract-and-Expand Key Derivation Function. Ang HKDF-SHA-256 at HKDF-SHA-384 na pagkuha, kabilang ang mga hangganan ng output, ay sumusuporta sa mga susi ng TLS at QUIC.
• RFC 6066 — TLS Extensions. Pinipili ng SNI ang mga pagkakakilanlan ng DNS, habang ang mga literal na IP address ay tama na hindi kabilang sa karaniwang anyo ng HostName.
• RFC 7301 — Pagpapatupad ng TLS Application-Layer Protocol Negotiation. Pinipili ng ALPN ang HTTP/1.1, HTTP/2, HTTP/3, at ang hiwalay na protocol ng ACME challenge sa hangganan ng TLS.
• RFC 7638 — Thumbprint ng JSON Web Key. Ang mga thumbprint ng key ng ACME account ay nakukuha sa canonical na anyo ng JWK.
• RFC 7807 — Mga Detalye ng Problema para sa HTTP APIs. Kinokonsumo ng Webship ang format ng dokumento ng problema na kinakailangan ng mga RFC 8555 ACME server. Pinalitan ng mas bagong pagtutukoy ng Mga Detalye ng Problema ito para sa mga bagong pangkalahatang layunin na API, ngunit ang normatibong dependency ng ACME ay nananatiling malinaw.
• RFC 8446 — TLS 1.3. Ginagamit ng Webship ang TLS 1.3 para sa pampublikong TLS, kabilang ang session tickets, pag-update ng susi, mga alerto, patakaran sa maagang datos, at derivasyon ng susi ng QUIC.
• RFC 8555 — Automated na Kapaligiran para sa Pamamahala ng Sertipiko. Ang account, order, awtorisasyon, hamon, finalization, pag-download ng sertipiko, at mga daloy ng pag-renew ay awtomatiko na may nakapaloob na pamamahala ng input.
• RFC 8737 — ACME TLS-ALPN-01 Challenge. Ang isang challenge-only TLS path ay nakikipag-ayos lamang sa acme-tls/1 at naglilingkod ng kinakailangang kritikal na acmeIdentifier na extension sa sertipiko.
• RFC 8738 — ACME IP Identifier Validation Extension. Sinusuportahan ng Webship ang mga order ng sertipiko para sa IPv4 at IPv6, binary IP SANs, at reverse-address SNI para sa IP TLS-ALPN-01 na beripikasyon.
• RFC 9525 — Pagkakakilanlan ng Serbisyo sa TLS. Ang mga pangalan ng DNS at pagkakakilanlan ng IP ay tinutugma sa ilalim ng kasalukuyang mga patakaran ng pagkakakilanlan ng serbisyo, nang walang wildcard o pangkaraniwang pamamaraang pangalan para sa mga IP address.
• RFC 9773 — ACME Renewal Information Extension. Maaaring magmula ang mga window ng renewal mula sa CA, na nagpapahintulot sa Webship na ligtas na ikalat ang mga renewal sa halip na gumamit ng isang matibay na lokal na iskedyul.

WebTransport: tumpak tungkol sa kung ano ang istandardisado

Ang WebTransport sa ibabaw ng HTTP/3 ay hindi binibilang bilang ikalimampu't tatlong RFC. Simula sa Webship 1.3.1, ang wire mapping nito ay nananatiling draft-ietf-webtrans-http3-16. Ipinapatupad ng Webship ang draft na iyon sa ibabaw ng standard na HTTP/3, extended CONNECT, QUIC DATAGRAM, HTTP Datagram, at Capsule layers na nabanggit sa itaas. Ipinapatupad din nito ang negotiated RESET_STREAM_AT extension na kinakailangan upang mapanatili ang maaasahang prefix na nagtatakda ng session kapag ni-reset ang isang WebTransport stream.

Mahalaga ang pagkakaibang iyon. Hindi pinapabuti ang pagkakatugma sa mga pamantayan sa pamamagitan ng pagtawag sa isang draft na RFC. Pinapabuti ito sa pamamagitan ng malinaw na pagsubaybay sa draft, paghihiwalay nito mula sa karaniwang HTTP na mga landas, pakikipagkasundo sa bawat extension, pagtatakda ng bawat session na yaman, at pagsubok sa pagkansela at pag-uugali ng kabiguan.

Bakit mahalaga ang lawak na ito sa produksyon

Ang isang depekto sa pamantayan ay bihirang nag-iisa. Ang maling paghawak ng HSTS ay maaaring tumawid sa hangganan ng cache. Ang isang maling pormang QPACK na utos ay maaaring huminto sa hindi kaugnay na mga kahilingan. Ang isang hindi ligtas na palagay tungkol sa maagang datos ay maaaring paulit-ulit na isagawa ang isang operasyon. Ang isang QUERY cache key na hindi kasama ang katawan ng kahilingan ay maaaring magbalik ng resulta ng ibang query. Ang isang proxy na nag-aalis ng trailers o maling humahawak sa pagkakansela ay tahimik na nagbabago ng isang protocol ng aplikasyon.

Tinatrato ng arkitektura ng Webship ang mga ito bilang magkakaugnay na mga alalahanin. Ang mga limitasyon ng parser, inspeksyon sa seguridad, caching, reverse proxying, estado ng transport, at instrumentation ay nagbabahagi ng malinaw na mga kontrata. Ang resulta ay isang server na maaaring lumipat sa pagitan ng HTTP/1.1, HTTP/2, HTTP/3, static na paghahatid, reverse proxying, streaming, at WebTransport nang hindi nagbibigay sa bawat mode ng magkakaibang kahulugan ng pagiging tama.

Suriin ang pahayag

Huwag basta-basta maniwala sa isang sukdulan. Basahin ang [Webship 1.3.1 documentation](/docs/1.3.1), suriin ang configuration at mga hangganan ng protocol, at ulitin ang inilathalang pag-uugali. Pagkatapos, [i-download ang Webship](/downloads) at subukan ang mga edge case na mahalaga sa iyong sistema.