Alternativa più sicura relativamente più veloce per HTTPS

Question

Alternativa più sicura relativamente più veloce per HTTPS

#1 da (45 voti)
#2 da (32 voti)
#3 da (12 voti)

16

Sto lavorando a una partita multiplayer. Intendevo che tutti i dati fossero scambiati su HTTPS, ma è troppo lento. Le reti ad alta latenza richiedono più di un secondo per l'handshake SSL. Anche se il gioco è a turni e non richiede un trasferimento dei dati veloce, il ping 1000-2000 ms non è accettabile.

Quali protocolli / approcci posso utilizzare per trasferire i dati in modo sicuro, con la minore latenza possibile?

Modifica: solo per rispondere alle tue domande sul payload, ecco qual è il risultato di un'unità che attacca un edificio nemico (ovviamente non sto inviando una stringa di uno e zero, questa è solo una rappresentazione binaria): / p>

00000000 10010011 01010001 00100011 01011100 01010001 01010000

Analisi messaggi:

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

Non penso di poter ottenere più densità di dati senza renderlo costoso sulla CPU.

tls

posta Mirac7 15.01.2016 - 13:50

fonte

3 risposte

32

High latency networks take over a second for SSL handshake

Non ci dovrebbe essere bisogno di fare una stretta di mano per ogni scambio di messaggi. L'handshake è necessario solo all'avvio della connessione TCP, quindi lascia aperta la connessione. Quindi la latenza è ciò che si ha con qualsiasi altra connessione TCP stabilita. Se hai bisogno di meno latenza al costo di possibili perdite o duplicazioni di pacchetti, usa DTLS, cioè TLS con datagrammi (UDP).

Oltre a quello HTTP (s) potrebbe non essere il protocollo ottimale per l'utilizzo su connessioni ad alta latenza e bassa larghezza di banda. L'incapsulamento del payload nella richiesta e nella risposta HTTP ha un overhead non banale (a seconda della quantità di payload) e se il carico utile basato su testo spesso utilizzato (ad es. JSON, XML o simile) aggiunge solo un ulteriore overhead. Lo scambio di dati basato su binari (come protobuf o simili) fa un uso migliore delle risorse disponibili.

risposta data 15.01.2016 - 14:10

fonte

12

Se vuoi una connessione basata su TCP, usa TLS. Impostare la connessione in anticipo, in modo da pagare la latenza 2 RTT una volta e quindi non è mai necessario ripagarla. È possibile utilizzare l'estensione SPDY se si desidera ridurre il costo di latenza iniziale iniziale per stabilire inizialmente la connessione.

Se desideri una connessione basata su UDP, utilizza DTLS . Ciò può ridurre ancora più latenza, eliminando le ri-trasmissioni TCP e altre cose che TCP può introdurre la latenza in determinate circostanze. Ancora una volta, imposta la connessione in anticipo, quindi paghi una volta la latenza 2 RTT e non dovrai più ripagarla.

risposta data 15.01.2016 - 18:07

fonte

Leggi altre domande sui tag tls

Questa sfiducia è davvero necessaria? Yubikey / GPG con chiave firmata OpenSSH

score 45 · Accepted Answer

HTTPS è HTTP su TLS .

Se implementi un gioco, usare HTTP non è di solito una buona idea. Il protocollo HTTP è progettato per la richiesta di documenti, non per i giochi in tempo reale. Un'idea migliore sarebbe quella di sviluppare il tuo protocollo direttamente basato su TCP o UDP (UDP è più veloce mentre TCP è più facile da usare, ma questo è un argomento per lo sviluppo del gioco stackexchange ) e tunnel attraverso TLS.

Il processo di scambio di chiavi che richiede molto tempo deve essere eseguito una volta sola quando si stabilisce la connessione. Quando si mantiene aperta la stessa connessione durante il gioco, l'unico sovraccarico di latenza è causato dalla crittografia e dalla decrittografia. TLS supporta più suite di crittografia (set di algoritmi crittografici che vengono utilizzati). La scelta della suite di crittografia può essere utilizzata per trovare un compromesso tra prestazioni e sicurezza.