Sostituire HTTP con un semplice TCP in un'applicazione client-server

0

Sto costruendo una piccola applicazione composta da:

  • Client (riga di comando)

  • Logica aziendale (server remoto)

È un semplice gioco di tick-tack-toe in cui il client invia informazioni al server su quale campo è stato contrassegnato e il server restituisce un disegno ASCII aggiornato della scheda.

La mia idea iniziale era implementare la comunicazione client-server usando RPC su HTTP.

Tuttavia, dal momento che HTTP usa comunque una connessione TCP, e non sembra che abbia bisogno delle intestazioni HTTP (sto inviando una quantità veramente piccola di dati) non sarebbe un'idea migliore usare solo un semplice connessione TCP e fare RPC in questo modo?

Posso incorrere in qualche problema se una grande quantità di giocatori concorrenti (clienti) decidono di connettersi al mio gioco (cioè devo chiudere la connessione TCP ad ogni richiesta o tenerla aperta mentre il gioco continua)?

    
posta Rtsne42 29.09.2017 - 22:29
fonte

1 risposta

3

Questo sembra un compito a casa, e in tal caso dovresti probabilmente fare solo ciò che è più facile, in linea con ciò che l'istruttore si aspetta. Se vuoi imparare il più possibile, fallo in entrambi i modi. Il motivo per cui ho sollevato questa questione, è che molti dei vantaggi dell'utilizzo di HTTP non saranno evidenti in un esempio di giocattolo con pochi requisiti del mondo reale.

Quindi perché utilizzare HTTP rispetto a un semplice socket TCP? Paul ha menzionato una preoccupazione pratica per quanto riguarda il firewall traversal. Un'altra preoccupazione pratica è che esistono già librerie che gestiranno le comunicazioni HTTP sia sul lato di invio che di ricezione. Se si utilizza un socket non elaborato, è necessario risolvere i problemi che i server HTTP o HTTP già risolvono, come interrompere l'input in messaggi discreti e demultiplexare le richieste. A un livello più architettonico, utilizzando un'interfaccia standardizzata e uniforme, è possibile applicare funzionalità su livelli che non hanno bisogno di sapere nulla della propria applicazione. Ad esempio, crittografia tramite TLS o livelli di memorizzazione nella cache o meccanismi di controllo dell'accesso o compressione trasparente.

Detto questo, HTTP non è utilizzabile per tutto. L'HTTP non è adatto per dati a bassa latenza, in rapida evoluzione e sensibili al fattore tempo. In effetti, TCP è spesso inadatto a utilizzare i protocolli basati su UDP. Come si allude a, il sovraccarico di HTTP può portare ai metadati che dominano la larghezza di banda per i piccoli messaggi. Nella maggior parte dei casi questo non ha molta importanza dal momento che è necessario un gran numero di messaggi per poi creare colli di bottiglia nella larghezza di banda. HTTP / 2 cambia anche l'equazione qui un po '.

    
risposta data 29.09.2017 - 23:26
fonte

Leggi altre domande sui tag