web udp public
1.0.0
이 저장소는 기본 전송 프로토콜의 필수 신뢰성 및/또는 순서화된 전달 메커니즘 없이 서버-클라이언트 저지연 통신을 가능하게 하는 기술에 대한 대중의 요구를 표현하기 위한 것입니다.
그리고 기존 요구 사항과 잠재적인 미래 애플리케이션의 요구 사항을 구체화합니다 . W3C 회원, IETF 커뮤니티 및 브라우저 공급업체가 토론을 시작하고 솔루션에 대한 추가 개발을 촉진하기 위해 RFC를 제안하도록 동기를 부여합니다.
이슈에 대한 PR 및 토론을 환영합니다. 소문을 퍼뜨리세요. RT를 환영합니다.
웹은 WebSocket, WebRTC, HTTP/2, 서버 전송 이벤트, QUIC 와 같은 기술을 사용하여 네트워킹 기능을 향상하면서 지난 몇 년 동안 빠르게 발전했습니다.
이러한 기술에는 고유한 적용 영역이 있으며 웹 플랫폼에서 다음을 수행할 수 있습니다.
더욱 풍부하고 강력한 경험을 제공합니다.
최근에는 HTML5 게임 이라는 또 다른 매체가 탄생했습니다. Adobe Flash는 사라지고 HTML5 게임 산업은 꾸준히 성장하고 있습니다.
이는 가장 접근하기 쉬운 멀티플레이어 게임 중 하나인 IO 게임의 탄생으로 이어졌습니다. 인기 있는 예: agar.io, slither.io 등. 이들 모두는 현재 실시간 서버-클라이언트 통신을 위해 유일하게 실행 가능한 기술인 WebSocket에 의존합니다. 서버-클라이언트용 WebRTC는 지나치게 복잡합니다(자세히 읽어보세요).
그러나 게임용 TCP에는 제한이 있으므로 이는 네트워크 기능을 제한합니다. 게임에만 국한된 것이 아니라 지연 시간이 짧고 신뢰할 수 없으며 순서가 없는 서버-클라이언트 통신에 대한 사용 사례가 많이 있다는 점을 언급할 가치가 있습니다.
대기 시간 및 정체 . TCP는 안정적이고 순서대로 패킷을 전달하며 연결 기반 프로토콜입니다. TCP를 통한 UDP(또는 대안)의 필요성은 다양한 경우에 TCP를 통한 UDP(또는 대안)의 이점에 대해 많은 기사에서 널리 논의되기 때문에 의문의 여지가 없습니다. 여기서 우리는 그것을 요약하려고 노력하고 있습니다. UDP가 가장 인기가 있지만 이러한 노력을 위한 유일한 전송 프로토콜 옵션은 아니라는 점을 언급할 가치가 있습니다.
신뢰성 - 이는 애플리케이션 로직에서 항상 원하는 것은 아니며, 오래된 정보는 더 이상 관련이 없으므로 무시할 수 있습니다. TCP는 패킷 전달을 보장하므로 패킷 승인 및 재전송이 필요하기 때문에 정체가 발생하고 지연 시간이 급증하게 됩니다. UDP(또는 대안)는 기본적으로 신뢰성을 보장하지 않으므로 최신 데이터가 최대한 빨리 전달되도록 보장하는 이점으로 사용될 수 있는 정체 문제를 방지합니다.
순차적 전달 - TCP는 순서화 및 승인을 사용하여 순차적 읽기 및 패킷 재전송을 보장합니다. 이로 인해 읽기가 차단되어 대기 시간이 급증하고 네트워크 환경의 패킷 손실이 높을 경우 상황이 더욱 악화됩니다.
신뢰성을 보장하지 않고 즉시 사용 가능한 순서대로 전달되는 프로토콜로, 개발자가 필요한 경우 그 위에 기술을 구현하거나 하이브리드 접근 방식을 사용할 수 있습니다. 이는 완벽하지 않은 네트워크 환경에서 안정적인 전달 타이밍과 낮은 대기 시간을 제공합니다. 혼잡 제어를 통해 인터넷 인프라의 압도를 완화하여 보안 문제를 해결합니다.
이 문제를 해결하는 옵션 중 하나는 RFC 6455에 설명된 협상 메커니즘을 사용하여 기존 WebSockets 프로토콜에 새로운 확장을 추가하는 것입니다. 이는 UDP(또는 대체) 프로토콜 통신을 설정하기 위한 추가 기능을 구현합니다. 이는 WebSocket의 기존 원본 기반 보안 모델의 이점을 누릴 수 있으며 개발자가 해당 확장이 어느 쪽(서버 또는 클라이언트)에서 지원되지 않는 경우 TCP 논리로 대체할 수 있는 점진적인 접근 방식을 따를 수 있습니다.
또 다른 접근 방식은 UDP(또는 대체) 네트워킹 논리의 고유한 기능을 처리하고 잠재적으로 메시지 전송 방법에 대한 세부적인 옵션을 통해 개발자에게 추가 기능을 제공하는 WebSocket과 매우 유사한 완전히 새로운 API를 개발하는 것입니다.
WebRTC의 현재 상태는 지나치게 복잡하며 주로 P2P 통신용으로 설계되었습니다. 이로 인해 서버-클라이언트 통신에 잘 채택되지 않으며 많은 개발자 리소스가 필요합니다. 간단히 말해서, 오늘날의 WebSocket처럼 단독 웹 개발에 친화적이지 않습니다. WebRTC의 일부 부분을 사용하여 서버-클라이언트 시나리오에 더 쉽게 액세스할 수 있게 하고 웹 개발자가 더 쉽게 액세스할 수 있도록 단순화된 API를 허용하는 요구 사항을 모듈화하고 단순화하기 위해 사양을 확장하는 잠재적인 옵션입니다.
신뢰할 수 있는 통신과 신뢰할 수 없는 통신을 모두 지원하여 웹 애플리케이션이 대화형, 양방향, 다중 네트워크 연결을 설정할 수 있도록 하는 WebTransport API의 초안 사양이 있습니다.
이러한 API와 기본 프로토콜 구현은 보안 문제를 해결하여 웹 친화적으로 만들어야 합니다.
API는 프런트엔드 API와 백엔드 구현을 지나치게 복잡하게 하지 않으면서 이러한 보안 문제를 해결해야 합니다. 그렇기 때문에 UDPSocket은 옵션이 아닙니다.
구현에 사용할 수 있는 잠재적인 기본 프로토콜 목록:
