Webship: Server Web Paling Kompatibel dengan RFC di Dunia

Web dijaga oleh kesepakatan yang tepat. Sebuah field Content-Length harus memiliki arti yang sama pada setiap lompatan. Cache tidak boleh menggunakan kembali respons yang memerlukan validasi. Bagian field HTTP/3 yang salah bentuk harus gagal pada cakupan yang tepat. Metode aman harus tetap aman setelah melewati reverse proxy.

Webship 1.3.1 dibangun berdasarkan satu aturan: kecepatan hanya penting ketika byte mempertahankan maknanya.

Itulah mengapa kami menggambarkan Webship sebagai server web serba guna yang paling kompatibel dengan RFC di dunia. Ini adalah klaim rekayasa dengan batas yang terlihat, bukan klaim bahwa setiap fitur opsional di setiap RFC ada. Peta di bawah ini menyebutkan 52 RFC yang memengaruhi perilaku server aktif Webship atau fondasi protokol yang dimilikinya. Standar saat ini disebutkan pertama. Dokumen yang digantikan diidentifikasi sebagai garis keturunan kompatibilitas. Spesifikasi draf tidak diberi label ulang sebagai RFC.

Kecocokan adalah perilaku, bukan lencana

Webship menerapkan standar di tempat-tempat di mana server produksi paling sering menjadi ambigu:

• Framing HTTP/1.1 menolak panjang yang bertentangan, kode transfer yang tidak valid, target permintaan yang terlalu besar, potongan yang salah bentuk, dan bentuk penyelundupan permintaan.
• HTTP/2 dan HTTP/3 menolak bidang koneksi yang dilarang, memvalidasi pseudo-field, membatasi bagian bidang yang dikompresi, dan menjaga kesalahan stream terpisah dari kesalahan koneksi.
• File statis mempertahankan semantik HEAD, validator, urutan prasyarat, rentang byte, pengalihan, dan jenis konten.
• Proxy terbalik mempertahankan framing, pembatalan, trailer, peningkatan, percobaan ulang aman, dan identitas pengiriman sambil menghapus bidang hop-by-hop.
• Cache menghitung umur, kesegaran, revalidasi, Vary, invalidasi, dan aturan penggunaan basi daripada memperlakukan caching sebagai pintasan kunci-nilai.
• TLS, QUIC, ACME, data awal, dan WebTransport menggunakan keadaan terbatas dan kebijakan kegagalan yang eksplisit.

Aturan yang sama berlaku pada jalur cepat. Webship tidak menetapkan satu jalur “benar” dan jalur tolok ukur yang berbeda.

Semantik HTTP, pembingkaian, caching, dan proxying

• RFC 3986 — Uniform Resource Identifier (URI): Sintaks Umum. Webship menormalkan referensi Lokasi dan Lokasi-Konten relatif, termasuk segmen titik, sebelum keputusan invalidasi cache.
• RFC 6455 — Protokol WebSocket. Peningkatan reverse-proxy memvalidasi kunci WebSocket, nilai accept, subprotokol, ekstensi, dan transisi tunnel.
• RFC 6585 — Kode Status HTTP Tambahan. Bidang permintaan yang terlalu besar menggunakan respons 431 yang ditentukan ketika respons HTTP masih memungkinkan.
• RFC 6797 — Keamanan Transportasi Ketat HTTP. Strict-Transport-Security hanya dikirim melalui transportasi yang aman dan tidak pernah bocor dari entri cache netral-transport ke HTTP teks-terbuka.
• RFC 7235 — Autentikasi HTTP/1.1. Token skema autentikasi diparsing tanpa memperhatikan huruf besar/kecil, termasuk permukaan kontrol MCP yang terlindungi. Semantik HTTP umumnya sekarang terdapat di RFC 9110.
• RFC 7239 — Ekstensi HTTP Forwarded. Operator dapat memilih field Forwarded berbasis standar, field X-Forwarded warisan, keduanya, atau tidak sama sekali; field identitas masuk yang tidak terpercaya dihapus terlebih dahulu.
• RFC 7540 — HTTP/2. Ini dipertahankan sebagai garis keturunan kompatibilitas HTTP/2; kontrak HTTP/2 yang aktif adalah penerusnya, RFC 9113.
• RFC 7541 — HPACK: Kompresi Header untuk HTTP/2. Tumpukan HTTP/2 milik Webship membatasi status decoder dan tabel encoder sambil mempertahankan format wire HPACK dan pengkodean Huffman.
• RFC 7838 — Layanan Alternatif HTTP. Alt-Svc mengiklankan endpoint HTTP/3 tanpa mengubah origin yang direpresentasikan oleh URL.
• RFC 8441 — Bootstrapping WebSockets dengan HTTP/2. Webship mendukung fondasi negosiasi extended-CONNECT downstream. Webship tidak berpura-pura bahwa upstream HTTP/1.1 mengimplementasikan extended CONNECT HTTP/2; kombinasi upstream yang tidak didukung akan gagal secara eksplisit.
• RFC 8470 — Menggunakan Data Awal dalam HTTP. Permintaan awal yang tidak akan diproses oleh Webship akan menerima 425 Too Early alih-alih diperlakukan dengan asumsi pengulangan yang tidak aman.
• RFC 8941 — Nilai Field Terstruktur untuk HTTP. Nilai prioritas HTTP menggunakan parsing kamus field-terstruktur; field opsional yang salah bentuk diabaikan secara keseluruhan.
• RFC 9110 — Semantik HTTP. Metode, kode status, bidang, validator, prasyarat, pengalihan, metadata konten, HEAD, CONNECT, OPTIONS, dan semantik rentang memiliki satu kontrak saat ini di seluruh versi protokol.
• RFC 9111 — Caching HTTP. Webship menerapkan usia yang dikoreksi, kesegaran eksplisit, Vary, only-if-cached, must-revalidate, proxy-revalidate, penggunaan stale yang aman, dan invalidasi URI yang efektif serta terkait.
• RFC 9112 — HTTP/1.1. Aturan request-line, field, body-length, transfer-coding, chunk, trailer, persistence, dan close-delimited diterapkan sebelum pengiriman ke aplikasi.
• RFC 9113 — HTTP/2. Urutan pseudo-field, otoritas, bidang koneksi yang dilarang, pembatasan TE, siklus hidup stream, kontrol aliran, GOAWAY, dan cakupan kesalahan ditangani oleh jalur H2 milik Webship.
• RFC 9114 — HTTP/3. Webship memiliki jalur request, control-stream, SETTINGS, critical-stream, pembatalan, dan error stream-versus-connection yang digunakan oleh server HTTP/3-nya.
• RFC 9204 — QPACK: Kompresi Field untuk HTTP/3. Kapasitas tabel dinamis dibatasi oleh batas yang diumumkan, aliran instruksi tetap dapat diurai pada kapasitas nol, dan status yang tidak valid menjadi kesalahan QPACK yang diperlukan.
• RFC 9218 — Skema Prioritas yang Dapat Diperluas untuk HTTP. Panduan urgensi dan pengiriman bertahap mengatur penjadwalan HTTP/3 sementara parameter prioritas yang tidak diketahui tetap dapat diperluas.
• RFC 9220 — Memulai WebSockets dengan HTTP/3. Webship mengimplementasikan dasar SETTINGS extended-CONNECT HTTP/3 yang digunakan oleh protokol tunneling modern; itu tidak berarti setiap protokol CONNECT yang mungkin diterima.
• RFC 9297 — Datagram HTTP dan Protokol Kapsul. Sesi WebTransport menggunakan decoding kapsul terbatas dan asosiasi Datagram HTTP, dengan kapsul yang tidak dikenal ditangani sebagai titik ekstensi alih-alih kegagalan parser.
• RFC 9421 — Tanda Tangan Pesan HTTP. Provenansi respons Ed25519 opsional dapat mencakup identitas rilis dan konfigurasi Webship tanpa menggantikan TLS atau autentikasi aplikasi.
• RFC 10008 — Metode QUERY HTTP. Webship menganggap QUERY aman dan idempoten, mempertahankan isinya saat melalui proxy, menyertakan metadata isi dan representasi dalam identitas cache, melarang kesegaran heuristik, mendukung perilaku bersyarat dan rentang, dan tidak pernah membatalkan cache hanya karena QUERY digunakan.

Transport dan pengendalian kemacetan QUIC

• RFC 3465 — Kontrol Kemacetan TCP dengan Perhitungan Byte yang Tepat. Logika perhitungan-byte-tepat adalah bagian dari garis keturunan kontrol kemacetan NewReno yang digunakan oleh implementasi QUIC Webship.
• RFC 4303 — IP Encapsulating Security Payload. Webship tidak mengimplementasikan IPsec ESP; deduplikator paket QUIC-nya menggunakan teknik anti-replay jendela geser dari RFC tersebut hanya sebagai garis keturunan implementasi.
• RFC 5681 — Kontrol Kemacetan TCP. Ambang kehilangan dan pengurutan kembali mewarisi batasan kontrol kemacetan yang sudah ada di mana QUIC dibangun berdasarkan praktik TCP.
• RFC 6298 — Menghitung Timer Retransmisi TCP. Perhitungan waktu putaran balik yang dihaluskan dan varians berkontribusi pada model pemulihan QUIC.
• RFC 8312 — CUBIC untuk Jaringan Jarak Jauh Cepat. Ini adalah spesifikasi CUBIC sebelumnya yang dipertahankan sebagai garis keturunan algoritma; RFC 9438 adalah standar saat ini.
• RFC 8899 — Penemuan MTU Jalur Lapisan Paket untuk Transport Datagram. DPLPMTUD yang dapat dikonfigurasi menemukan ukuran datagram QUIC yang dapat digunakan tanpa bergantung pada sinyal lapisan jaringan yang rentan.
• RFC 8999 — Properti QUIC yang Tidak Tergantung Versi. Header panjang, ID koneksi, negosiasi versi, dan parsing invarian tetap aman sebelum decoder spesifik versi dijalankan.
• RFC 9000 — QUIC: Transport Multiplexed dan Aman Berbasis UDP. ID koneksi, aliran, kontrol aliran, migrasi, validasi alamat, Retry, reset tanpa status, parameter transport, dan perilaku penutupan membentuk dasar transport HTTP/3 Webship.
• RFC 9001 — Menggunakan TLS untuk Mengamankan QUIC. Rahasia awal, proteksi paket, proteksi header, integritas Retry, fase kunci, dan integrasi TLS mengikuti aturan QUIC-TLS.
• RFC 9002 — Deteksi Kehilangan dan Kontrol Kemacetan QUIC. Ruang nomor paket, pengakuan, PTO, deteksi kehilangan, pemulihan, dan perhitungan kemacetan mendorong keandalan transportasi.
• RFC 9221 — Ekstensi Datagram Tidak Andal untuk QUIC. Frame DATAGRAM QUIC yang dinegosiasikan membawa lalu lintas WebTransport yang tidak andal tanpa mengubahnya menjadi konten stream.
• RFC 9287 — Mengolesi Bit QUIC. Pengolesan bit QUIC mengurangi ossifikasi sambil mempertahankan keamanan negosiasi.
• RFC 9308 — Kegunaan Protokol Transport QUIC. Default operasional seperti waktu menganggur terbatas dan panduan penerapan memberikan informasi bagi kebijakan transportasi produksi Webship.
• RFC 9369 — QUIC Versi 2. Jenis paket Versi 2, kunci awal, integritas Retry, pembaruan kunci, dan negosiasi versi diimplementasikan bersama QUIC v1.
• RFC 9438 — CUBIC untuk Jaringan Cepat dan Jarak Jauh. Standar CUBIC saat ini mengatur pengendali kemacetan CUBIC Webship; BBR dan NewReno tetap dapat dipilih ketika beban kerja membutuhkannya.

TLS, sertifikat, dan manajemen sertifikat otomatis

• RFC 3339 — Tanggal dan Waktu di Internet: Cap Waktu. Jendela pembaruan ACME menggunakan cap waktu Internet yang dapat saling dioperasikan.
• RFC 4648 — Base16, Base32, dan Base64 Encoding Data. Nilai ACME JOSE dan materi handshake WebSocket menggunakan alfabet dan aturan padding Base64 dan Base64url yang diperlukan.
• RFC 5280 — Profil Sertifikat dan CRL PKI X.509 Internet. Parsing sertifikat dan sertifikat tantangan yang dihasilkan menggunakan bentuk subjectAltName DNS dan IP biner yang benar.
• RFC 5869 — Fungsi Derivasi Kunci Ekstrak-dan-Perluas berbasis HMAC. Derivasi HKDF-SHA-256 dan HKDF-SHA-384, termasuk batas keluaran, mendasari kunci TLS dan QUIC.
• RFC 6066 — Ekstensi TLS. SNI memilih identitas DNS, sementara alamat IP literal dengan benar dikecualikan dari bentuk HostName biasa.
• RFC 7301 — Negosiasi Protokol Lapisan Aplikasi TLS. ALPN memilih HTTP/1.1, HTTP/2, HTTP/3, dan protokol tantangan ACME yang terisolasi di batas TLS.
• RFC 7638 — Sidik Jari Kunci Web JSON. Sidik jari kunci akun ACME diturunkan dalam bentuk JWK kanonik.
• RFC 7807 — Detail Masalah untuk API HTTP. Webship menggunakan format dokumen-masalah yang diwajibkan oleh server ACME RFC 8555. Spesifikasi Detail Masalah yang lebih baru menggantikannya untuk API tujuan umum yang baru, tetapi ketergantungan normatif ACME tetap eksplisit.
• RFC 8446 — TLS 1.3. Webship menggunakan TLS 1.3 untuk TLS publik, termasuk tiket sesi, pembaruan kunci, peringatan, kebijakan data awal, dan derivasi kunci QUIC.
• RFC 8555 — Lingkungan Manajemen Sertifikat Otomatis. Alur akun, pesanan, otorisasi, tantangan, finalisasi, unduhan sertifikat, dan pembaruan dilakukan secara otomatis dengan penanganan input yang terbatas.
• RFC 8737 — Tantangan ACME TLS-ALPN-01. Jalur TLS khusus tantangan hanya menegosiasikan acme-tls/1 dan menyediakan ekstensi sertifikat acmeIdentifier kritis yang diperlukan.
• RFC 8738 — Ekstensi Validasi Identifikasi IP ACME. Webship mendukung pesanan sertifikat IPv4 dan IPv6, SAN IP biner, dan SNI alamat balik untuk validasi IP TLS-ALPN-01.
• RFC 9525 — Identitas Layanan dalam TLS. Nama DNS dan identitas IP dicocokkan menurut aturan identitas layanan saat ini, tanpa wildcard atau jalan pintas nama umum untuk alamat IP.
• RFC 9773 — Ekstensi Informasi Pembaruan ACME. Jendela pembaruan dapat berasal dari CA, memungkinkan Webship untuk menyebarkan pembaruan dengan aman alih-alih menggunakan satu jadwal lokal yang kaku.

WebTransport: tepat tentang apa yang distandarisasikan

WebTransport di atas HTTP/3 tidak dihitung sebagai RFC yang ke-lima puluh tiga. Sampai Webship 1.3.1, pemetaan wire-nya tetap draft-ietf-webtrans-http3-16. Webship mengimplementasikan draf tersebut di atas HTTP/3 yang telah distandarisasi, CONNECT yang diperluas, QUIC DATAGRAM, HTTP Datagram, dan lapisan Capsule yang disebutkan di atas. Ini juga mengimplementasikan ekstensi RESET_STREAM_AT yang dinegosiasikan yang diperlukan untuk mempertahankan awalan pengenal sesi yang andal ketika aliran WebTransport di-reset.

Perbedaan itu penting. Kompatibilitas standar tidak meningkat dengan menyebut sebuah draf sebagai RFC. Itu meningkat dengan melacak draf tersebut secara eksplisit, mengisolasinya dari jalur HTTP biasa, merundingkan setiap ekstensi, membatasi setiap sumber daya sesi, dan menguji perilaku pembatalan dan kegagalan.

Mengapa luas ini penting dalam produksi

Bug standar jarang terjadi secara terisolasi. Penanganan HSTS yang salah dapat melampaui batas cache. Instruksi QPACK yang salah format dapat menghentikan permintaan yang tidak terkait. Asumsi early-data yang tidak aman dapat memutar ulang suatu operasi. Kunci cache QUERY yang mengabaikan tubuh permintaan dapat mengembalikan hasil dari kueri yang berbeda. Proxy yang menghapus trailer atau salah menangani pembatalan dapat diam-diam mengubah protokol aplikasi.

Arsitektur Webship memperlakukan ini sebagai kepedulian yang saling terhubung. Batas parser, pemeriksaan keamanan, caching, reverse proxying, status transportasi, dan instrumentasi berbagi kontrak yang eksplisit. Hasilnya adalah satu server yang dapat berpindah antara HTTP/1.1, HTTP/2, HTTP/3, pengiriman statis, reverse proxying, streaming, dan WebTransport tanpa memberikan setiap mode definisi kebenaran yang berbeda.

Verifikasi klaim

Jangan begitu saja mempercayai kata superlatif. Baca [dokumentasi Webship 1.3.1](/docs/1.3.1), periksa konfigurasi dan batasan protokol, dan ulangi perilaku yang diterbitkan. Kemudian [unduh Webship](/downloads) dan uji kasus ekstrem yang penting untuk sistem Anda.