Webship: Pelayan Web Paling Serasi RFC di Dunia

Web disatukan oleh perjanjian yang tepat. Medan Content-Length mesti membawa maksud yang sama pada setiap lompatan. Cache tidak boleh menggunakan semula respons yang memerlukan pengesahan. Seksyen medan HTTP/3 yang cacat mesti gagal pada skop yang betul. Kaedah yang selamat mesti kekal selamat selepas ia melalui proksi terbalik.

Webship 1.3.1 dibina berdasarkan satu peraturan: kelajuan hanya penting apabila bait mengekalkan maknanya.

Itulah sebabnya kami menggambarkan Webship sebagai pelayan web serba guna yang paling serasi dengan RFC di dunia. Ini adalah tuntutan kejuruteraan dengan sempadan yang jelas, bukan tuntutan bahawa setiap ciri pilihan dalam setiap RFC wujud. Peta di bawah menamakan 52 RFC yang mempengaruhi tingkah laku pelayan aktif Webship atau asas protokol yang dimiliki olehnya. Standard semasa disebut terlebih dahulu. Dokumen yang telah digantikan dikenal pasti sebagai garis keturunan keserasian. Spesifikasi draf tidak dinamakan semula sebagai RFC.

Keserasian adalah tingkah laku, bukan lencana

Webship menerapkan piawaian di tempat-tempat di mana server produksi paling kerap menjadi samar:

• Pemframan HTTP/1.1 menolak panjang yang bertentangan, pengkodan pemindahan tidak sah, sasaran permintaan yang terlalu besar, cebisan yang cacat, dan bentuk penyeludupan permintaan.
• HTTP/2 dan HTTP/3 menolak medan sambungan yang dilarang, mengesahkan pseudo-medan, mengehadkan bahagian medan termampat, dan memisahkan ralat aliran daripada ralat sambungan.
• Fail statik mengekalkan semantik HEAD, pengesah, susunan prasyarat, julat bait, pengalihan, dan jenis kandungan.
• Proksi songsang mengekalkan pembingkaian, pembatalan, treler, peningkatan, cubaan selamat, dan pengecaman penghantaran sambil menanggalkan medan hop-by-hop.
• Cache mengira umur, kesegaran, pengesahan semula, Vary, pemansuhan, dan peraturan penggunaan lapuk daripada menganggap caching sebagai pintasan kekunci-nilai.
• TLS, QUIC, ACME, data awal, dan WebTransport menggunakan keadaan terhad dan dasar kegagalan yang jelas.

Peraturan yang sama terpakai pada laluan pantas. Webship tidak menetapkan satu laluan 'betul' dan laluan penanda aras yang berbeza.

Semantik HTTP, pembingkaian, penimbanan, dan proksi

• RFC 3986 — Pengenal Sumber Seragam (URI): Sintaks Umum. Webship menormalkan rujukan Lokasi dan Kandungan-Lokasi relatif, termasuk segmen noktah, sebelum keputusan pembatalan cache.
• RFC 6455 — Protokol WebSocket. Kenaikan proksi terbalik mengesahkan kunci WebSocket, nilai terima, subprotokol, peluasan, dan peralihan terowong.
• RFC 6585 — Kod Status HTTP Tambahan. Medan permintaan yang terlalu besar menggunakan respons 431 yang ditakrifkan apabila respons HTTP masih boleh dilakukan.
• RFC 6797 — Keselamatan Pengangkutan Teguh HTTP. Strict-Transport-Security hanya dihantar melalui pengangkutan selamat dan tidak pernah bocor daripada entri cache neutral-pengangkutan ke atas HTTP teks jelas.
• RFC 7235 — HTTP/1.1 Pengesahan. Token skim pengesahan dianalisis tanpa mengira huruf besar atau kecil, termasuk permukaan kawalan MCP yang dilindungi. Semantik HTTP umum kini terdapat dalam RFC 9110.
• RFC 7239 — Sambungan HTTP Teruskan. Pengendali boleh memilih medan Forwarded berasaskan piawaian, medan X-Forwarded warisan, kedua-duanya, atau tiada; medan identiti masuk yang tidak dipercayai akan dipadam terlebih dahulu.
• RFC 7540 — HTTP/2. Ini dikekalkan sebagai keturunan keserasian HTTP/2; kontrak HTTP/2 yang aktif adalah penerusnya, RFC 9113.
• RFC 7541 — HPACK: Pemampatan Header untuk HTTP/2. Tumpukan HTTP/2 milik Webship mengehadkan keadaan penyahkod dan jadual pengekod sambil mengekalkan format wayar HPACK dan pengekodan Huffman.
• RFC 7838 — Perkhidmatan Alternatif HTTP. Alt-Svc mengiklankan titik akhir HTTP/3 tanpa menukar asal yang diwakili oleh URL.
• RFC 8441 — Memulakan WebSockets dengan HTTP/2. Webship menyokong asas rundingan extended-CONNECT huluan. Ia tidak berpura-pura bahawa huluan HTTP/1.1 melaksanakan HTTP/2 extended CONNECT; gabungan huluan yang tidak disokong gagal secara nyata.
• RFC 8470 — Menggunakan Data Awal dalam HTTP. Permintaan awal yang tidak akan diproses oleh Webship akan menerima 425 Too Early dan bukannya diproses dengan anggapan ulangan yang tidak selamat.
• RFC 8941 — Nilai Medan Berstruktur untuk HTTP. Nilai keutamaan HTTP menggunakan parsing kamus medan-berstruktur; medan pilihan yang rosak diabaikan sepenuhnya.
• RFC 9110 — Semantik HTTP. Kaedah, kod status, medan, validator, prasyarat, pengalihan, metadata kandungan, HEAD, CONNECT, OPTIONS, dan semantik julat berkongsi satu kontrak semasa merentasi versi protokol.
• RFC 9111 — Pengcachean HTTP. Webship melaksanakan umur yang diperbetulkan, kesegaran eksplisit, Vary, only-if-cached, must-revalidate, proxy-revalidate, penggunaan selamat sementara lapuk, dan penamatan URI berkesan dan berkaitan.
• RFC 9112 — HTTP/1.1. Garis permintaan, medan, panjang-badan, pengekodan-pemindahan, ketulan, treler, kesinambungan, dan peraturan berakhir-tutup dikuatkuasakan sebelum penghantaran aplikasi.
• RFC 9113 — HTTP/2. Susunan medan pseudo, autoriti, medan sambungan terlarang, sekatan TE, kitar hidup aliran, kawalan aliran, GOAWAY, dan skop ralat dikendalikan oleh laluan H2 milik Webship.
• RFC 9114 — HTTP/3. Webship memiliki laluan permintaan, aliran kawalan, SETTINGS, aliran kritikal, pembatalan, dan ralat aliran-lawan-sambungan yang digunakan oleh pelayannya HTTP/3.
• RFC 9204 — QPACK: Pemampatan Medan untuk HTTP/3. Kapasiti jadual dinamik dihadkan oleh had yang diiklan, aliran arahan tetap boleh dianalisis pada kapasiti sifar, dan keadaan tidak sah menjadi ralat QPACK yang diperlukan.
• RFC 9218 — Skema Keutamaan Boleh Diperluas untuk HTTP. Panduan kecemasan dan penghantaran secara berperingkat mengawal penjadualan HTTP/3 sementara parameter keutamaan yang tidak diketahui kekal boleh diperluas.
• RFC 9220 — Memulakan WebSockets dengan HTTP/3. Webship mengimplimentasikan asas SETTINGS extended-CONNECT HTTP/3 yang digunakan oleh protokol terowong moden; itu tidak bermakna setiap protokol CONNECT yang mungkin diterima.
• RFC 9297 — Datagram HTTP dan Protokol Kapsul. Sesi WebTransport menggunakan penyahkodan kapsul terhad dan persatuan Datagram HTTP, dengan kapsul yang tidak diketahui dikendalikan sebagai titik sambungan tambahan dan bukannya kegagalan penganalisis.
• RFC 9421 — Tandatangan Mesej HTTP. Provenans respons Ed25519 pilihan boleh merangkumi pelepasan Webship dan identiti konfigurasi tanpa menggantikan TLS atau pengesahan aplikasi.
• RFC 10008 — Kaedah QUERY HTTP. Webship menganggap QUERY sebagai selamat dan idempoten, mengekalkan badan (body) melalui proksi, termasuk metadata badan dan representasi dalam identiti cache, mengharamkan kesegaran heuristik, menyokong tingkah laku bersyarat dan julat, dan tidak pernah membatalkan cache hanya kerana QUERY digunakan.

Pengangkutan QUIC dan kawalan kesesakan

• RFC 3465 — Kawalan Kesesakan TCP dengan Pengiraan Bai Sesuai. Logik pengiraan-bai-sesuai adalah sebahagian daripada garis keturunan kawalan kesesakan NewReno yang digunakan oleh pelaksanaan QUIC Webship.
• RFC 4303 — Muatan Keselamatan Pengangkapan IP. Webship tidak melaksanakan IPsec ESP; deduplikasi paket QUICnya menggunakan teknik anti-ulang tetingkap gelangsar RFC hanya sebagai garis keturunan pelaksanaan.
• RFC 5681 — Kawalan Kesesakan TCP. Ambang kehilangan dan penyusunan semula mewarisi had kawalan kesesakan yang telah ditetapkan di mana QUIC dibina berdasarkan amalan TCP.
• RFC 6298 — Mengira Pemasa Pemulangan Semula TCP. Pengiraan masa perjalanan balik yang dilicinkan dan variasi menyumbang kepada model pemulihan QUIC.
• RFC 8312 — CUBIC untuk Rangkaian Jauh Pantas. Ini adalah spesifikasi CUBIC yang terdahulu yang dikekalkan sebagai keturunan algoritma; RFC 9438 adalah standard semasa.
• RFC 8899 — Penemuan MTU Laluan Lapisan Pengemasan untuk Penghantaran Datagram. DPLPMTUD yang boleh dikonfigurasikan menemui saiz datagram QUIC yang boleh digunakan tanpa bergantung pada isyarat lapisan rangkaian yang rapuh.
• RFC 8999 — Sifat Bebas Versi QUIC. Header panjang, ID sambungan, rundingan versi, dan parsing tetap selamat sebelum penyahkod versi-spesifik dijalankan.
• RFC 9000 — QUIC: Pengangkutan Pelbagai dan Selamat Berasaskan UDP. ID sambungan, aliran, kawalan aliran, migrasi, pengesahan alamat, Retry, reset tanpa status, parameter pengangkutan, dan tingkah laku tutup membentuk asas pengangkutan HTTP/3 Webship.
• RFC 9001 — Menggunakan TLS untuk Menjamin Keselamatan QUIC. Rahsia awal, perlindungan paket, perlindungan tajuk, integriti Retry, fasa kunci, dan integrasi TLS mengikuti peraturan QUIC-TLS.
• RFC 9002 — Pengesanan Kehilangan dan Kawalan Kesesakan QUIC. Ruang nombor paket, pengakuan, PTO, pengesanan kehilangan, pemulihan, dan pengiraan kesesakan memacu kebolehpercayaan pengangkutan.
• RFC 9221 — Sambungan Datagram Tidak Boleh Dipercayai ke QUIC. Bingkai DATAGRAM QUIC yang dirundingkan membawa trafik WebTransport yang tidak boleh dipercayai tanpa menukarnya menjadi kandungan aliran.
• RFC 9287 — Greasing Bit QUIC. Greasing bit QUIC mengurangkan pengerasan sambil mengekalkan keselamatan rundingan.
• RFC 9308 — Kesesuaian Protokol Pengangkutan QUIC. Tetapan operasi seperti masa tidak aktif terhad dan panduan penyebaran memaklumkan dasar pengangkutan pengeluaran Webship.
• RFC 9369 — QUIC Versi 2. Jenis paket Versi 2, kunci awal, integriti Retry, kemas kini kunci, dan rundingan versi dilaksanakan bersama-sama dengan QUIC v1.
• RFC 9438 — CUBIC untuk Rangkaian Pantas dan Jarak Jauh. Standard CUBIC semasa mengawal pengawal kesesakan CUBIC Webship; BBR dan NewReno kekal boleh dipilih apabila beban kerja memerlukannya.

TLS, sijil, dan pengurusan sijil automatik

• RFC 3339 — Tarikh dan Masa di Internet: Cap Masa. Tetingkap pembaharuan ACME menggunakan cap masa Internet yang boleh bekerjasama.
• RFC 4648 — Pengekodan Data Base16, Base32, dan Base64. Nilai ACME JOSE dan bahan sambungan tangan WebSocket menggunakan abjad Base64 dan Base64url yang diperlukan serta peraturan padding.
• RFC 5280 — Profil Sijil PKI X.509 Internet dan CRL. Pemecahan sijil dan sijil cabaran yang dijana menggunakan bentuk subjectAltName DNS dan IP binari yang betul.
• RFC 5869 — Fungsi Derivasi Kunci Berdasarkan HMAC Extract-dan-Expand. Derivasi HKDF-SHA-256 dan HKDF-SHA-384, termasuk batas output, menyokong kunci TLS dan QUIC.
• RFC 6066 — Sambungan TLS. SNI memilih identiti DNS, manakala alamat IP literal dikecualikan dengan betul daripada bentuk HostName biasa.
• RFC 7301 — Rundingan Protokol Lapisan Aplikasi TLS. ALPN memilih HTTP/1.1, HTTP/2, HTTP/3, dan protokol cabaran ACME terasing di sempadan TLS.
• RFC 7638 — Cap Jari Kunci Web JSON. Cap jari kunci akaun ACME diperoleh dalam bentuk JWK kanonik.
• RFC 7807 — Butiran Masalah untuk API HTTP. Webship menggunakan format dokumen-masalah yang diperlukan oleh pelayan ACME RFC 8555. Spesifikasi Butiran Masalah yang lebih baru menggantikannya untuk API tujuan umum yang baru, tetapi kebergantungan normatif ACME kekal jelas.
• RFC 8446 — TLS 1.3. Webship menggunakan TLS 1.3 untuk TLS awam, termasuk tiket sesi, kemas kini kunci, amaran, dasar data awal, dan penurunan kunci QUIC.
• RFC 8555 — Persekitaran Pengurusan Sijil Automatik. Aliran akaun, pesanan, kebenaran, cabaran, pemuktamahan, muat turun sijil, dan pembaharuan adalah automatik dengan pengendalian input yang terikat.
• RFC 8737 — Cabaran ACME TLS-ALPN-01. Laluan TLS hanya cabaran hanya merundingkan acme-tls/1 dan menyampaikan sambungan sijil acmeIdentifier kritikal yang diperlukan.
• RFC 8738 — Sambungan Pengesahan Pengenal IP ACME. Webship menyokong pesanan sijil IPv4 dan IPv6, SAN IP binari, dan SNI alamat terbalik untuk pengesahan IP TLS-ALPN-01.
• RFC 9525 — Identiti Perkhidmatan dalam TLS. Nama DNS dan identiti IP dipadankan mengikut peraturan identiti perkhidmatan semasa, tanpa jalan pintas wildcard atau nama umum untuk alamat IP.
• RFC 9773 — Sambungan Maklumat Pembaharuan ACME. Tetingkap pembaharuan boleh datang dari CA, membolehkan Webship mengedarkan pembaharuan dengan selamat dan bukannya menggunakan satu jadual tempatan yang kaku.

WebTransport: tepat tentang apa yang telah distandardkan

WebTransport melalui HTTP/3 tidak dikira sebagai RFC ke-lima puluh tiga. Sehingga Webship 1.3.1, pemetaan wayarnya kekal sebagai draft-ietf-webtrans-http3-16. Webship melaksanakan draf tersebut di atas HTTP/3 yang telah distandardkan, CONNECT yang dipanjangkan, DATAGRAM QUIC, Datagram HTTP, dan lapisan Kapsul yang dinamakan di atas. Ia juga melaksanakan sambungan RESET_STREAM_AT yang dirundingkan yang diperlukan untuk mengekalkan awalan pengecam sesi yang boleh dipercayai apabila aliran WebTransport direset.

Perbezaan itu penting. Keserasian piawaian tidak bertambah baik dengan menamakan draf sebagai RFC. Ia bertambah baik dengan menjejak draf tersebut secara jelas, memisahkannya dari laluan HTTP biasa, merundingkan setiap sambungan tambahan, mengehadkan setiap sumber sesi, dan menguji tingkah laku pembatalan serta kegagalan.

Mengapa keluasan ini penting dalam pengeluaran

Pepijat piawaian jarang terpencil. Pengendalian HSTS yang salah boleh melintasi sempadan cache. Arahan QPACK yang cacat boleh menamatkan permintaan yang tidak berkaitan. Andaian data awal yang tidak selamat boleh mengulangi operasi. Kekunci cache QUERY yang mengabaikan badan permintaan boleh memulangkan keputusan pertanyaan yang berbeza. Proksi yang menanggalkan trailer atau mengendalikan pembatalan dengan salah boleh secara senyap mengubah protokol aplikasi.

Arkitektur Webship menganggap ini sebagai perkara yang saling berkaitan. Had pengurai, pemeriksaan keselamatan, caching, proksi terbalik, keadaan pengangkutan, dan instrumen berkongsi kontrak yang jelas. Hasilnya ialah satu pelayan yang boleh bergerak antara HTTP/1.1, HTTP/2, HTTP/3, penghantaran statik, proksi terbalik, penstriman, dan WebTransport tanpa memberi setiap mod definisi yang berbeza mengenai ketepatan.

Sahkan tuntutan itu

Jangan percaya sesuatu yang luar biasa begitu sahaja. Baca [dokumentasi Webship 1.3.1](/docs/1.3.1), periksa konfigurasi dan sempadan protokol, dan hasilkan semula tingkah laku yang diterbitkan. Kemudian [muat turun Webship](/downloads) dan uji kes tepi yang penting untuk sistem anda.