Alternativa relativamente más rápida y segura para HTTPS

Question

Alternativa relativamente más rápida y segura para HTTPS

#1 de Philipp (45 votos)
#2 de Steffen Ullrich (32 votos)
#3 de D.W. (12 votos)

16

Estoy trabajando en un juego multijugador. Tenía la intención de que todos los datos se intercambiaran a través de HTTPS, pero es demasiado lento. Las redes de alta latencia toman más de un segundo para el protocolo de enlace SSL. Si bien el juego está basado en turnos y no requiere una transferencia de datos extremadamente rápida, el ping de 1000-2000 ms sigue siendo inaceptable.

¿Qué protocolos / enfoques puedo usar para transferir datos de forma segura, con la menor latencia posible?

Editar: Solo para responder a tus preguntas sobre la carga útil, esto es el resultado de una unidad atacando a un edificio enemigo (obviamente no estoy enviando una cadena de unos y ceros, esto es solo una representación binaria):

00000000 10010011 01010001 00100011 01011100 01010001 01010000

Desglose de mensajes:

00000000  client's request executed with status "OK", other values correspond to specific error messages.

10        Object is owned by Player 2
010       Object is a building
0110      Object is located at x=6  (always 0<=x<=14)
101       Object is located at y=5  (always 0<=y<=6), owner and location is sufficient to describe any object uniquely
0001      1 byte-worth of modified attributes follows
0010 0011 Object's health is now 3

01        Object is owned by Player 1
011       Object is a unit
1000      Object is located at x=8
101       Object is located at y=5
0001      1 byte-worth of modified attributes follows
0101 0000 This object can no longer move/attack this turn

No creo que pueda obtener más densidad de datos sin que sea caro para la CPU.

tls

pregunta Mirac7 15.01.2016 - 13:50

fuente

3 respuestas

32

Las redes de alta latencia toman más de un segundo para el protocolo SSL

No debería haber necesidad de hacer un apretón de manos completo para cada intercambio de mensajes. El protocolo de enlace solo se necesita al inicio de la conexión TCP, por lo tanto, simplemente deje la conexión abierta. Entonces la latencia es lo que tienes con cualquier otra conexión TCP establecida. Si necesita menos latencia a costa de la posible pérdida o duplicación de paquetes, utilice DTLS, es decir, TLS con datagramas (UDP).

Aparte de eso, HTTP (s) podría no ser el protocolo óptimo para su uso en conexiones de alta latencia y ancho de banda bajo. La encapsulación de la carga útil solo en la solicitud y respuesta HTTP tiene una sobrecarga no trivial (dependiendo de la cantidad de carga útil) y si la carga útil basada en texto de uso frecuente (es decir, JSON, XML o similar) solo agrega más sobrecarga. El intercambio de datos basado en binarios (como protobuf o similar) hace un uso mucho mejor de los recursos disponibles.

respondido por el Steffen Ullrich 15.01.2016 - 14:10

fuente

12

Si desea una conexión basada en TCP, use TLS. Configure la conexión de antemano, de modo que pague la latencia de 2 RTT una vez y luego nunca más deberá volver a pagarla. Puede usar la extensión SPDY si desea reducir el costo de latencia inicial por única vez de establecer la conexión inicialmente.

Si desea una conexión basada en UDP, use DTLS . Esto puede reducir aún más la latencia, al eliminar las retransmisiones de TCP y otras cosas que TCP hace que pueden introducir latencia en ciertas circunstancias. Una vez más, configure la conexión con anticipación, de modo que pague la latencia de 2 RTT una vez y luego nunca tenga que pagarla nuevamente.

respondido por el D.W. 15.01.2016 - 18:07

fuente

Lea otras preguntas en las etiquetas tls

Emacs y EasyPG no realizan el cifrado de clave pública ¿Por qué es posible que el usuario root elimine los registros?

score 45 · Accepted Answer

HTTPS es HTTP a través de TLS .

Si implementas un juego, el uso de HTTP no suele ser una buena idea. El protocolo HTTP está diseñado para solicitar documentos, no para juegos en tiempo real. Una mejor idea sería desarrollar su propio protocolo directamente basado en TCP o UDP (UDP es más rápido, mientras que TCP es más fácil de usar, pero ese es un tema para desarrollo del juego stackexchange ) y canalícelo a través de TLS.

El proceso de intercambio de claves que consume tiempo solo debe realizarse una vez que se establece la conexión. Cuando mantienes la misma conexión abierta durante el juego, la única sobrecarga de latencia se debe al cifrado y descifrado. TLS es compatible con múltiples conjuntos de cifrado (conjuntos de algoritmos criptográficos que se utilizan). La elección de la suite de cifrado se puede utilizar para encontrar un compromiso entre el rendimiento y la seguridad.