usar - websockets vs http performance
WebSockets, UDP y puntos de referencia (5)
Los websockets HTML5 actualmente usan una forma de comunicación TCP. Sin embargo, para los juegos en tiempo real, TCP simplemente no lo va a cortar (y es una gran razón para usar alguna otra plataforma, como la nativa). Como probablemente necesite UDP para continuar un proyecto, me gustaría saber si las especificaciones para HTML6 o lo que sea soportarán UDP.
Además, ¿hay puntos de referencia confiables para WebSockets que puedan comparar el protocolo WS con un protocolo de socket directo de bajo nivel?
Me gustaría saber si las especificaciones para HTML6 o lo que sea compatible con UDP?
WebSockets no lo hará. Uno de los beneficios de WebSockets es que se conecta a la conexión HTTP existente . Esto significa que para los servidores proxy y cortafuegos WebSockets se parece a HTTP para que no se bloqueen.
Es probable que las conexiones UDP arbitrarias nunca sean parte de ninguna especificación web debido a problemas de seguridad . Lo más cercano a lo que está buscando probablemente sea parte de WebRTC y su protocolo JSEP asociado.
¿Hay algún punto de referencia confiable ... que ... compare el protocolo WS con un protocolo de socket directo de bajo nivel?
No que yo supiese. Voy a salir mal y predecir que WebSockets será más lento;)
En una LAN, puede obtener tiempos de ida y vuelta para mensajes a través de WebSocket de 200 microsec (desde el navegador JS al servidor WebSocket y viceversa), que es similar a los ping sin procesar de ICMP. En MAN, es alrededor de 10ms, WAN (sobre ADSL residencial a servidor en el mismo país) alrededor de 30ms, y así sucesivamente hasta alrededor de 120-200ms a través de 3.5G. El punto es: WebSocket no agrega prácticamente ninguna latencia a la que obtendrá de todos modos, en función de la red.
La sobrecarga de nivel de cable de WebSocket (en comparación con TCP sin formato) está entre 2 octetos (carga útil desenmascarada de longitud <126 octetos) y 14 octetos (carga útil enmascarada de longitud> 64k) por mensaje (los números anteriores suponen que el mensaje no está fragmentado en múltiples Marcos de WebSocket). Muy bajo.
Para un análisis más detallado de la sobrecarga de nivel de cable WebSocket, consulte esta publicación de blog ; esto incluye análisis que cubren capas además de WebSocket también.
Más aún: con una implementación de WebSocket capaz de procesar la transmisión, puede (después del saludo inicial inicial de WebSocket) iniciar un solo mensaje y marco de WebSocket en cada dirección y luego enviar hasta 2 ^ 63 octetos sin ninguna sobrecarga. Básicamente, esto hace que WebSocket sea un preludio elegante para TCP sin formato. Advertencia: los intermediarios pueden fragmentar el tráfico según su propia decisión. Sin embargo, si ejecuta WSS (que es WS seguro = TLS), ningún intermediario puede interferir, y allí está: TCP sin formato, con un preludio compatible con HTTP (protocolo de enlace de WS).
WebRTC utiliza RTP (= basado en UDP) para el transporte de medios, pero también necesita un canal de señalización (que puede ser WebSocket, por ejemplo). RTP está optimizado para el transporte de medios en tiempo real tolerante a pérdidas. "Juegos en tiempo real" a menudo significa transferir no medios, sino cosas como posiciones de jugadores. WebSocket funcionará para eso.
Nota: El transporte de WebRTC puede realizarse a través de RTP o asegurado cuando se encuentra sobre SRTP. Ver "Perfiles RTP" here .
No hay soporte UDP para Websockets (realmente debería haberlo), sin embargo, aparentemente puede usar la API RTCDataChannel de WebRTC para comunicaciones tipo UDP. Hay un buen artículo aquí:
http://www.html5rocks.com/en/tutorials/webrtc/datachannels/
RTCDataChannel realmente usa SCTP que tiene confiabilidad configurable y entrega ordenada. Puede hacer que actúe como UDP diciéndole que entregue mensajes desordenados y establezca el número máximo de retransmisiones en 0.
No he probado nada de esto sin embargo.
Para resumir, si desea usar TCP para juegos de varios jugadores, debe usar lo que llamamos técnicas de transmisión adaptativa . En otras palabras, debe asegurarse de que la cantidad de datos en tiempo real enviados para sincronizar el mundo del juego entre los clientes se rija por el ancho de banda y la latencia actualmente disponibles para cada cliente.
La aceleración dinámica, la fusión, la entrega delta y otros mecanismos son técnicas de transmisión adaptativa, que no hacen mágicamente TCP tan eficiente como UDP, pero lo hacen utilizable para varios tipos de juegos.
Traté de explicar estas técnicas en un artículo: Optimización de la sincronización de juegos 3D multijugador en la web ( http://blog.lightstreamer.com/2013/10/optimizing-multiplayer-3d-game.html ).
También di una charla sobre este tema el mes pasado en HTML5 Developer Conference en San Francisco. El video acaba de estar disponible en YouTube: http://www.youtube.com/watch?v=cSEx3mhsoHg
Recomiendo desarrollar su juego usando WebSockets en una red cableada local y luego pasar a la API del canal de datos WebRTC una vez que esté disponible. Como @oberstet señala correctamente, las latencias promedio de WebSocket son básicamente equivalentes a TCP o UDP en bruto, especialmente en una red local, por lo que debería estar bien para su fase de desarrollo. La API del canal de datos WebRTC está diseñada para ser muy similar a WebSockets (una vez que se establece la conexión), por lo que debería ser bastante simple de integrar una vez que esté ampliamente disponible.
Su pregunta implica que UDP es probablemente lo que usted quiere para un juego de baja latencia y eso es verdad. Ya puede estar enterado de esto ya que está escribiendo un juego, pero para aquellos que no lo son, aquí hay una guía rápida sobre TCP vs UDP para juegos en tiempo real:
TCP es un mecanismo de transporte fiable y ordenado, y UDP es el mejor esfuerzo. TCP entregará todos los datos que se envían y en el orden en que se enviaron. Los paquetes UDP se envían a medida que llegan, pueden estar fuera de servicio y pueden tener espacios vacíos (en una red congestionada, los paquetes UDP se descartan antes que los paquetes TCP). TCP suena como una gran mejora, y es para la mayoría de los tipos de tráfico de red, pero esas funciones tienen un costo: un paquete retrasado o caído causa que todos los siguientes paquetes se retrasen también (para garantizar la entrega en orden).
Los juegos en tiempo real generalmente no pueden tolerar el tipo de retrasos que pueden resultar de los sockets TCP, por lo que usan UDP para la mayor parte del tráfico del juego y tienen mecanismos para manejar datos descartados y fuera de orden (por ejemplo, agregar números de secuencia al datos de carga útil). No es tan grave si pierdes una actualización de posición del jugador enemigo porque un par de milisegundos más tarde recibirás otra actualización de posición (y probablemente ni siquiera lo notarás). Pero si no obtienes actualizaciones de posición durante 500 ms y luego de repente las sacas todas una vez, eso resulta en un juego terrible.
Dicho todo esto, en una red cableada local, los paquetes casi nunca se retrasan ni se descartan, por lo que TCP está perfectamente bien como objetivo de desarrollo inicial. Una vez que la API del Canal de datos WebRTC esté disponible, puede considerar pasar a eso. La propuesta actual tiene confiabilidad configurable basada en reintentos o temporizadores.
Aquí hay algunas referencias: