web udp public
1.0.0
Repo ini untuk mengungkapkan kebutuhan publik akan teknologi yang memungkinkan komunikasi latensi rendah server-klien , tanpa keandalan wajib dan/atau mekanisme pengiriman yang dipesan dari protokol transport yang mendasarinya.
Dan membentuk persyaratan dari kebutuhan yang ada dan potensi penerapan di masa depan. Untuk memotivasi Anggota W3C, Komunitas IETF dan Vendor Browser untuk memulai diskusi dan mengusulkan RFC guna mendorong pengembangan lebih lanjut untuk mendapatkan solusi.
Humas dan diskusi di Issues dipersilakan. Sebarkan beritanya, RT dipersilakan.
Web berkembang pesat selama beberapa tahun terakhir, meningkatkan kemampuan jaringan menggunakan teknologi seperti: WebSockets, WebRTC, HTTP/2, Server-Sent Events, QUIC .
Teknologi tersebut memiliki area penerapannya sendiri dan platform web yang memungkinkan untuk memiliki:
dan masih banyak lagi pengalaman yang kaya dan kuat
Dalam beberapa tahun terakhir, media lain telah lahir: Game HTML5 . Adobe Flash akan dihentikan, dan industri game HTML5 terus berkembang.
Hal ini menyebabkan lahirnya IO Games - salah satu game multipemain yang paling mudah diakses di luar sana. Beberapa contoh populer: agar.io, slither.io dan masih banyak lagi. Mereka semua saat ini mengandalkan satu-satunya teknologi yang layak untuk komunikasi server-klien real-time – WebSockets. WebRTC untuk klien-server terlalu rumit (baca lebih lanjut).
Namun hal ini membatasi kemampuan jaringan karena TCP untuk permainan mempunyai batas . Perlu disebutkan bahwa ini bukan hanya tentang game - ada banyak kasus penggunaan untuk komunikasi server-klien dengan latensi rendah yang tidak dapat diandalkan dan tidak teratur.
Latensi dan kemacetan . TCP memiliki pengiriman paket yang andal dan teratur serta merupakan protokol berbasis koneksi. Kebutuhan UDP (atau alternatif) melalui TCP tidak diragukan lagi karena hal ini dibahas secara luas di banyak artikel tentang manfaat UDP (atau alternatif) melalui TCP dalam berbagai kasus. Di sini kami mencoba merangkumnya saja. Perlu disebutkan bahwa UDP adalah yang paling populer, namun bukan satu-satunya pilihan protokol transport untuk upaya ini.
Keandalan - hal ini tidak selalu diinginkan oleh logika aplikasi, informasi yang sudah ketinggalan zaman mungkin tidak relevan lagi dan dapat diabaikan. TCP akan memastikan pengiriman paket, yang menyebabkan kemacetan yang mengakibatkan lonjakan latensi karena kebutuhan pengakuan dan pengiriman ulang paket. UDP (atau alternatifnya) tidak menjamin keandalan, sehingga menghindari masalah kemacetan yang dapat digunakan sebagai manfaat untuk memastikan data terbaru dikirimkan secepatnya.
Pengiriman Terpesan - TCP menggunakan pengurutan dan pengakuan untuk menjamin pembacaan pesanan dan pengiriman ulang paket. Hal ini menyebabkan pemblokiran pembacaan, yang menyebabkan lonjakan latensi dan menjadi lebih buruk jika lingkungan jaringan memiliki kehilangan paket yang lebih tinggi.
Protokol yang tidak menjamin keandalan dan pengiriman yang dipesan secara langsung, memungkinkan pengembang untuk menerapkan teknik apa pun di atasnya jika diperlukan atau menggunakan pendekatan hibrid. Hal ini memberikan waktu pengiriman yang stabil dan latensi rendah di lingkungan jaringan yang kurang sempurna. Dengan pengendalian kemacetan untuk memitigasi infrastruktur internet yang kewalahan untuk mengatasi masalah keamanan.
Salah satu opsi untuk mengatasi hal ini adalah dengan menambahkan ekstensi baru ke protokol WebSockets yang ada menggunakan mekanisme negosiasi yang dijelaskan dalam RFC 6455. Yang akan mengimplementasikan fungsionalitas tambahan untuk membangun komunikasi protokol UDP (atau alternatif). Hal ini akan mendapatkan keuntungan dari model keamanan WebSockets berbasis asal yang ada dan memungkinkan pengembang untuk mengikuti pendekatan progresif di mana mereka dapat kembali ke logika TCP jika ekstensi tersebut tidak didukung oleh salah satu pihak (server atau klien).
Pendekatan lain adalah dengan mengembangkan API yang benar-benar baru, sangat mirip dengan WebSockets yang akan membahas fitur unik dari logika jaringan UDP (atau alternatif), serta berpotensi menyediakan fitur tambahan untuk pengembang dengan opsi terperinci tentang cara mengirim pesan.
Keadaan WebRTC saat ini terlalu rumit dan dirancang terutama untuk komunikasi peer-to-peer. Karena hal ini tidak diadopsi dengan baik untuk komunikasi server-klien dan memerlukan banyak sumber daya pengembang. Sederhananya, ini tidak ramah web-dev solo seperti WebSockets saat ini. Opsi potensial untuk memperluas spesifikasi untuk memodulasi dan menyederhanakan persyaratan yang memungkinkan penggunaan beberapa bagian WebRTC sehingga lebih mudah diakses untuk skenario server-klien dan menyederhanakan API yang akan membuatnya lebih mudah diakses oleh pengembang web.
Ada rancangan spesifikasi WebTransport API yang memungkinkan aplikasi web membuat koneksi jaringan interaktif, dua arah, dan multipleks - dengan dukungan untuk komunikasi yang andal dan tidak dapat diandalkan.
Implementasi API dan protokol yang mendasarinya harus mengatasi masalah keamanan agar ramah web:
API harus mengatasi masalah keamanan tersebut, tanpa membuat API menjadi terlalu rumit untuk front-end dan juga implementasi untuk back-end. Itu sebabnya UDPSocket bukanlah suatu pilihan.
Daftar protokol dasar potensial yang dapat digunakan untuk implementasi:
