Perché è meglio usare byte illeggibili per la comunicazione con il server client?

Vorrei sostenere un protocollo binario basato su Protocollo buffer . C'è un piccolo vantaggio, secondo me, in un protocollo leggibile dall'uomo, supponendo che il protocollo non significhi sia letto da un umano.

L'uso dei buffer di protocollo offre la compattezza di un protocollo binario con la flessibilità di un protocollo basato su testo (ad es. con campi opzionali e simili). Ha anche il vantaggio di essere in grado di generare automaticamente il codice di serializzazione / deserializzazione, quindi è possibile utilizzare oggetti strongmente tipizzati nel codice del programma.

PUOI usare le stringhe (guarda il protocollo http, ftp, ...) ma probabilmente ti imbatterai in problemi di codifica (meno ora che l'UTF8 è diventato di fatto lo standard ma ti imbatterai ancora in qualcosa come UTF16 e dovremo renderne conto)

avresti anche bisogno di scrivere un parser di stringhe che gestisca correttamente l'input malformato (se non altro per eliminare la connessione invece di bloccarsi)

tuttavia l'analisi del binario spesso si riduce a una sequenza di switch(in&MASK){case FIRST_CASE:...} che è molto più efficiente

tuttavia accanto a tutto questo c'è la quantità di dati che stai trasmettendo: il binario può essere molto più compatto delle stringhe per il protocollo comparabile

In realtà ci sono pochissimi buoni motivi per fare binari. Quella che hai menzionato - la sicurezza - è una falsa promessa. Stai crittografando o meno i tuoi dati; la trasmissione binaria in chiaro è ancora chiara, richiede solo un minimo di abilità da leggere. Un altro motivo menzionato - la codifica del testo - è effettivamente un problema risolto a questo punto. Il rovescio della medaglia, la codifica binaria può creare problemi interessanti - pensate in grande-contro-littleian.

I vantaggi dei protocolli testuali sono che sono molto più facili da capire, costruire, eseguire il debug, usare e hackerare. Non hai bisogno di tanti strumenti per arrivare da nessuna parte. Quando hai bisogno di strumenti, c'è una serie infinita di strumenti testuali a tua disposizione. Con il tuo protocollo binario personalizzato puoi definire il set di strumenti per il meglio o per il peggio.

Questo non vuol dire che i protocolli binari non hanno il loro posto - ci sono molte applicazioni che richiedono quel tipo di compattezza e puntualità. Ma il binario non dovrebbe essere la risposta predefinita.

hai bisogno di mantenere la leggibilità del protocollo stesso? Se è così, perché? I protocolli leggibili dall'uomo (vale a dire stringhe di testo) come nell'esempio che hai dato hanno molti aspetti negativi. Il primo ovvio è il fabbisogno di larghezza di banda; è sicuramente molto più compatto per inviare 0x01, 0x00 di qualcosa come "USER LOGIN \ n", per non parlare di frasi più lunghe come hai descritto. Il secondo è la sicurezza. Ad esempio, cosa significano i byte 0x3C, 0x02 e 0x7F in termini di protocollo? L'unico modo per capire è iniziare a decodificare i binari. Molto più noioso lavoro, e non sempre così banale.

Francamente, non vedo assolutamente alcun beneficio reale nell'usare protocolli leggibili dall'uomo, a meno che non siano specificamente intesi ad essere leggibili dall'uomo - qualcosa che non vedo succedere spesso. Vorrei un consiglio strong contro le stringhe nei protocolli. Per favore, non farlo.

Internet ha lotti di esperienza con protocolli binari e testuali. I protocolli testuali sono la norma, non perché " lo facciamo sempre in questo modo ", ma perché oltre 40 anni di esperienza hanno dimostrato che i protocolli testuali sono significativamente più facili da utilizzare e perché le considerazioni sull'ampiezza di banda raramente alla lunga.

Non confondere "binario" e "sicuro". Non c'è nulla di intrinsecamente sicuro su un protocollo binario. Anche i protocolli binari non documentati sono stati decodificati. Allo stesso modo, non c'è nulla di intrinsecamente insicuro su un protocollo testuale. La sicurezza nasce da piani ben ponderati contro gli attacchi, non dalla semplice oscurità.

Ci sono due motivi che mi vengono in mente:

1. Le richieste e le risposte codificate sono generalmente più brevi delle richieste di "testo normale". Se invii molti dati questo potrebbe diventare importante. Al giorno d'oggi è meno così con connessioni più veloci e se si inviano solo piccole quantità di dati.

2. La sicurezza è una preoccupazione reale. Se le richieste e le risposte vengono inviate in chiaro, possono essere lette mentre sono in transito (attacchi man in the middle) e, dati i pacchetti sufficienti, la tua applicazione potrebbe essere compromessa. Le persone potrebbero inviare richieste false per ottenere dati dal tuo sistema, inserire dati falsi nel tuo sistema e generalmente fare un casino di cose. Anche se questo è vero anche per i dati binari, è più difficile e meno ovvio di cosa siano i dati.