web udp public
1.0.0
Этот репозиторий призван выразить общественную потребность в технологии, обеспечивающей связь сервер-клиент с малой задержкой , без обязательной надежности и/или упорядоченной механики доставки базового транспортного протокола.
И формируйте требования на основе существующих потребностей и потенциальных будущих приложений. Мотивировать членов W3C, сообщество IETF и поставщиков браузеров начать обсуждение и предложить RFC, чтобы стимулировать дальнейшую разработку решения.
Пиар и обсуждение в Issues приветствуются. Распространяйте информацию, RT приветствуется.
За последние годы Интернет быстро развивался, улучшая сетевые возможности с помощью таких технологий, как: WebSockets, WebRTC, HTTP/2, события, отправленные сервером, QUIC .
Эти технологии имеют собственную область применения и позволяют веб-платформе иметь:
и еще много богатого и мощного опыта
В последние годы появилась еще одна среда: HTML5 Games . 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, который сделает его более доступным для веб-разработчиков.
Существует черновая спецификация API WebTransport, которая позволяет веб-приложениям устанавливать интерактивные, двунаправленные, мультиплексированные сетевые соединения - с поддержкой как надежной, так и ненадежной связи.
Такой API и реализация базового протокола должны решать проблемы безопасности, чтобы сделать его удобным для Интернета:
API должен решать эти проблемы безопасности, не усложняя API для внешнего интерфейса, а также реализацию внутреннего интерфейса. Вот почему UDPSocket не является вариантом.
Список потенциальных базовых протоколов, которые можно использовать для реализации:
