web udp public
1.0.0
การซื้อคืนนี้มีไว้เพื่อ แสดงความต้องการสาธารณะ สำหรับเทคโนโลยีเพื่อให้สามารถ สื่อสารระหว่างเซิร์ฟเวอร์และไคลเอ็นต์ได้ โดย ไม่ จำเป็นต้องมีความเชื่อถือได้และ/หรือกลไกการจัดส่งตามคำสั่งของโปรโตคอลการขนส่งพื้นฐาน
และ กำหนดความต้องการ จากความต้องการที่มีอยู่และการใช้งานในอนาคตที่อาจเกิดขึ้น เพื่อจูงใจสมาชิก W3C, ชุมชน IETF และผู้จำหน่ายเบราว์เซอร์ให้เริ่มการสนทนาและเสนอ RFC เพื่อกระตุ้นการพัฒนาเพิ่มเติมสำหรับโซลูชัน
ยินดีต้อนรับการประชาสัมพันธ์และการอภิปรายในประเด็นต่างๆ กระจายคำ ยินดีต้อนรับ RT's
เว็บมีการพัฒนาอย่างรวดเร็วในช่วงหลายปีที่ผ่านมา โดยปรับปรุงความสามารถด้านเครือข่ายโดยใช้เทคโนโลยีต่างๆ เช่น: WebSockets, WebRTC, HTTP/2, Server-Sent Events, QUIC
เทคโนโลยีเหล่านั้นมีพื้นที่การใช้งานของตัวเองและเปิดใช้งานแพลตฟอร์มเว็บให้มี:
และประสบการณ์อันเข้มข้นและทรงพลังอีกมากมาย
ในช่วงไม่กี่ปีที่ผ่านมามีสื่ออื่นเกิดขึ้น: เกม HTML5 . Adobe Flash กำลังจะยุติลง และอุตสาหกรรมเกม HTML5 ก็เติบโตอย่างต่อเนื่อง
ซึ่งนำไปสู่การกำเนิดของ IO Games - หนึ่งในเกมที่มีผู้เล่นหลายคนที่เข้าถึงได้มากที่สุด ตัวอย่างยอดนิยมบางส่วน: agar.io, slither.io และอีกมากมาย พวกเขาทั้งหมดพึ่งพาเทคโนโลยีเดียวที่ทำงานในปัจจุบันสำหรับการสื่อสารเซิร์ฟเวอร์-ไคลเอนต์แบบเรียลไทม์ - WebSockets WebRTC สำหรับเซิร์ฟเวอร์ไคลเอ็นต์มีความซับซ้อนมากเกินไป (อ่านเพิ่มเติม)
แต่สิ่งนี้จะจำกัดความสามารถของเครือข่าย เนื่องจาก TCP สำหรับเกมมีขีดจำกัด เป็นที่น่าสังเกตว่ามัน ไม่ได้เกี่ยวกับเกมเท่านั้น แต่ยังมีกรณีการใช้งานมากมายสำหรับการสื่อสารระหว่างเซิร์ฟเวอร์และไคลเอนต์ที่มีเวลาแฝงต่ำ ไม่น่าเชื่อถือ และไม่มีการเรียงลำดับ
ความหน่วง และ ความแออัด TCP มีการจัดส่งแพ็กเก็ตที่เชื่อถือได้และสั่งซื้อและเป็นโปรโตคอลที่ใช้การเชื่อมต่อ ความจำเป็นของ UDP (หรือทางเลือกอื่น) บน TCP ไม่ได้อยู่ภายใต้คำถาม เนื่องจากมีการพูดคุยกันอย่างกว้างขวางในบทความมากมายเกี่ยวกับประโยชน์ของ UDP (หรือทางเลือก) บน TCP ในกรณีต่างๆ ที่นี่เราพยายามที่จะสรุปมัน น่าสังเกตว่า UDP นั้นได้รับความนิยมมากที่สุด แต่ไม่ใช่ตัวเลือกโปรโตคอลการขนส่งเดียวสำหรับความพยายามนี้
ความน่าเชื่อถือ - ตรรกะของแอปพลิเคชันไม่ต้องการสิ่งนี้เสมอไป ข้อมูลที่ล้าสมัยอาจไม่เกี่ยวข้องอีกต่อไปและสามารถเพิกเฉยได้ TCP จะรับประกันการจัดส่งแพ็กเก็ต ซึ่งนำไปสู่ความแออัดซึ่งส่งผลให้เวลาแฝงพุ่งสูงขึ้นเนื่องจากจำเป็นต้องรับทราบและจัดส่งแพ็กเก็ตอีกครั้ง UDP (หรือทางเลือกอื่น) ไม่รับประกันความน่าเชื่อถือทันที จึงหลีกเลี่ยงปัญหาความแออัดซึ่งสามารถนำมาใช้เป็นประโยชน์เพื่อให้แน่ใจว่าข้อมูลล่าสุดจะถูกส่งโดยเร็วที่สุด
การจัดส่งตามคำสั่ง - TCP ใช้การเรียงลำดับและการตอบรับเพื่อรับประกัน การอ่าน ตามคำสั่งและการส่งแพ็กเก็ตอีกครั้ง สิ่งนี้นำไปสู่การบล็อกการอ่าน ซึ่งนำไปสู่ความล่าช้าและแย่ลงหากสภาพแวดล้อมเครือข่ายมีการสูญเสียแพ็กเก็ตที่สูงขึ้น
โปรโตคอลที่ไม่รับประกันความน่าเชื่อถือและสั่งการจัดส่งนอกกรอบ ช่วยให้นักพัฒนาสามารถใช้เทคนิคใดๆ นอกเหนือจากนั้นได้หากจำเป็น หรือใช้แนวทางแบบไฮบริด ซึ่งให้เวลาการส่งมอบที่เสถียรและเวลาแฝงต่ำในสภาพแวดล้อมเครือข่ายที่ไม่สมบูรณ์ ด้วยการควบคุมความแออัดเพื่อลดโครงสร้างพื้นฐานอินเทอร์เน็ตที่ล้นหลามเพื่อแก้ไขข้อกังวลด้านความปลอดภัย
หนึ่งในตัวเลือกในการแก้ปัญหานี้คือการเพิ่มส่วนขยายใหม่ให้กับโปรโตคอล WebSockets ที่มีอยู่โดยใช้กลไกการเจรจาต่อรองที่อธิบายไว้ใน RFC 6455 ซึ่งจะใช้ฟังก์ชันพิเศษเพื่อสร้างการสื่อสารโปรโตคอล UDP (หรือทางเลือก) สิ่งนี้จะได้รับประโยชน์จากโมเดลความปลอดภัยตามต้นทางที่มีอยู่ของ WebSockets และช่วยให้นักพัฒนาปฏิบัติตามแนวทางแบบก้าวหน้าซึ่งสามารถถอยกลับไปใช้ตรรกะ TCP ได้ หากส่วนขยายดังกล่าวไม่ได้รับการสนับสนุนโดยฝ่ายใดฝ่ายหนึ่ง (เซิร์ฟเวอร์หรือไคลเอ็นต์)
อีกวิธีหนึ่งคือการพัฒนา API ใหม่ทั้งหมด ซึ่งคล้ายกับ WebSockets มากที่จะจัดการกับคุณสมบัติเฉพาะของตรรกะเครือข่าย UDP (หรือทางเลือกอื่น) รวมถึงอาจมอบคุณสมบัติพิเศษสำหรับนักพัฒนาด้วยตัวเลือกวิธีการส่งข้อความอย่างละเอียด
สถานะปัจจุบันของ WebRTC มีความซับซ้อนมากเกินไป และได้รับการออกแบบมาเพื่อการสื่อสารแบบเพียร์ทูเพียร์เป็นหลัก ด้วยเหตุนี้จึงไม่ได้รับการยอมรับอย่างดีสำหรับการสื่อสารระหว่างเซิร์ฟเวอร์และไคลเอ็นต์ และต้องใช้ทรัพยากรสำหรับนักพัฒนาจำนวนมาก พูดง่ายๆ ก็คือ มันไม่ได้เป็นมิตรกับการพัฒนาคนเดียวเหมือน WebSockets ในทุกวันนี้ ตัวเลือกที่เป็นไปได้ในการขยายข้อมูลจำเพาะเพื่อทำให้เป็นโมดูลและลดความซับซ้อนของข้อกำหนดที่จะอนุญาตให้ใช้บางส่วนของ WebRTC ทำให้สามารถเข้าถึงได้มากขึ้นสำหรับสถานการณ์ไคลเอนต์เซิร์ฟเวอร์ และ API ที่เรียบง่ายซึ่งจะทำให้นักพัฒนาเว็บเข้าถึงได้มากขึ้น
มีข้อกำหนดฉบับร่างของ WebTransport API ที่อนุญาตให้เว็บแอปพลิเคชันสร้างการเชื่อมต่อเครือข่ายแบบโต้ตอบ สองทิศทาง และมัลติเพล็กซ์ พร้อมรองรับการสื่อสารทั้งที่เชื่อถือได้และไม่น่าเชื่อถือ
การใช้ API และโปรโตคอลพื้นฐานดังกล่าวควรจัดการกับข้อกังวลด้านความปลอดภัยเพื่อให้เป็นมิตรกับเว็บ:
API ควรจัดการกับข้อกังวลด้านความปลอดภัยเหล่านั้น โดยไม่ทำให้ API สำหรับส่วนหน้าและส่วนหลังซับซ้อนเกินไป นั่นเป็นสาเหตุที่ UDPSocket ไม่ใช่ตัวเลือก
รายการโปรโตคอลพื้นฐานที่เป็นไปได้ที่สามารถนำมาใช้สำหรับการนำไปใช้งาน:
