Perché tanti protocolli Internet sono testuali?

Da quello che ho trovato, una molto grande quantità di protocolli che viaggiano su internet sono "text-based" piuttosto che binario. I protocolli in questione includono, ma non sono limitati a HTTP, SMTP, FTP (penso che questo sia tutto basato su testo?), WHOIS, IRC.

In effetti, alcuni di questi protocolli saltano attraverso alcuni cerchi ogni volta che vogliono trasmettere dati binari .

C'è una ragione dietro questo? I protocolli basati su testo hanno ovviamente un po 'di sovraccarico in quanto richiedono l'invio di più dati per trasmettere la stessa quantità di informazioni (vedi esempio sotto). Quali benefici superano questo?

Per testo , intendo che la maggior parte dei caratteri utilizzati nel protocollo sono compresi tra 0x20(spazio) e 0x7E( ~), con il "carattere speical" occasionale utilizzato per scopi molto speciali , come newline, null, ETX ed EOT. Ciò si oppone alla trasmissione di dati binari non elaborati sulla connessione.

Ad esempio, la trasmissione dell'intero 123456come testo implicherebbe l'invio della stringa 123456(rappresentata in esadecimale 31 32 33 34 35 36), mentre il valore binario a 32 bit verrebbe inviato come (rappresentato in esadecimale) 0x0001E240(e come puoi vedere, "contiene" il carattere null speciale .

Quando il mondo era più giovane e i computer non erano tutti glorificati su PC, le dimensioni delle parole variavano (un dicembre 2020 che avevamo qui intorno aveva 36 bit), il formato dei dati binari era un problema controverso (big endian vs little endian e persino più strano gli ordini di bit erano ragionevolmente comuni). C'era poco consenso sulla dimensione / codifica dei caratteri (ASCII, EBCDIC erano i principali contendenti, il nostro DEC aveva codifiche 5/6/7/8 bit / caratteri). ARPAnet (il predecessore di Internet) è stato progettato per connettere macchine di qualsiasi descrizione. Il comune denominatore era (ed è tuttora) testo. Potresti essere ragionevolmente certo che il testo codificato a 7 bit non verrebbe alterato dai mezzi sottostanti per spedire i dati (fino a poco tempo fa, l'invio di email in una codifica a 8 bit garantiva che il destinatario avrebbe ricevuto messaggi mutilati,

Se si rovistano, ad esempio, le descrizioni dei protocolli telnet o FTP (i primi protocolli Internet, l'idea di rete era quindi quella di connettersi in remoto a un "supercomputer" e mescolare i file avanti e indietro), si vede che la connessione include la negoziazione di molti dettagli prendiamo come uniforme,

Sì, il binario sarebbe (un po ') più efficiente. Ma le macchine e i ricordi (e anche le reti) sono cresciuti enormemente, quindi il pezzettino del passato è un ricordo del passato (principalmente). E nessuno nella loro mente giusta suggerirà di strappare tutti i protocolli esistenti per sostituirli con quelli binari. Inoltre, i protocolli di testo offrono una tecnica di debug molto utile. Oggi non installo mai il server Telnet (meglio usare il protocollo SSH crittografato per le connessioni remote), ma devo telnet client a portata di mano per "parlare" con alcuni server errati per capire quali sono gli ostacoli. Oggi probabilmente useresti netcat o ncat per andare in giro ...

Un vantaggio che potrebbe essere trascurato è la capacità di sperimentare . Se stai spingendo bit nel tubo, dovrai scrivere qualche utilità che si traduce EHLOin 0x18o simili. Invece di farlo, puoi semplicemente telnet in un server di posta, inviare EHLOed essere sulla tua strada.

Nulla ti impedisce al giorno d'oggi di scrivere codice in Assembly o Brainf * ck , e potresti benissimo salvare alcuni bit in questo modo. Tuttavia, spiegare cosa hai fatto esattamente a qualcun altro in modo che possano capire e interagire con il tuo codice non sarà facile se lo fai.

Con i protocolli, è importante che gli utenti siano prontamente in grado di imparare come usarli, dato che la maggior parte delle persone che utilizzavano ARPAnet o gli inizi di Internet erano persone che si sentivano a proprio agio dietro un terminale.

Argomenti simili, a proposito, sono oggi presenti nelle aziende. Dovremmo serializzare su JSON o BSON (rappresentazione binaria di JSON)? Se serializzi su BSON, perdi un po 'di spese generali, ma ora hai bisogno di un traduttore per convertire il tuo BSON in JSON e viceversa, poiché un essere umano dovrà leggere quei dati a un certo punto quando qualcosa inevitabilmente va storto.

Non è che molti protocolli Internet siano basati su testo. In effetti, se dovessi indovinare, direi che i protocolli basati su testo sono in minoranza. Per quasi tutti i protocolli testuali che vedi su Internet ci sono almeno due protocolli binari che le persone hanno inventato per inviare dati uguali o simili.

Ma è vero che la maggior parte del traffico Internet utilizza protocolli basati su testo. Questo fatto è interessante se si presume che ci siano molti più protocolli binari rispetto al testo ma molti più traffico di testo rispetto al binario. Significa che la maggior parte dei protocolli di successo su Internet sono basati su testo. Fatta eccezione per un numero limitato di applicazioni (bittorrent è un esempio) i protocolli binari tendono a morire.

All'inizio di Internet, le società tendevano a progettare e utilizzare il protocollo binario (ad esempio MSN, non il sito Web MSN di oggi, l'originale MicroSoft Network proprietario che avrebbe dovuto sostituire HTTP) mentre i militari, gli istituti di ricerca e gli accademici tendevano a progettare e utilizzare il protocollo basato su testo. Parte del motivo era che la costruzione e il debug dei protocolli binari era difficile e le aziende possono permettersi di pagare le persone per farlo mentre i militari, i ricercatori e gli accademici lo facevano nel loro tempo libero senza pagare (la maggior parte delle persone che hanno sviluppato Internet avevano lavori non legati allo sviluppo di Internet).

Quando scrivi il codice nei fine settimana come hobby e non sei pagato per fare ciò che fai, tendi a scegliere la soluzione più semplice: il testo. Quindi i protocolli basati su testo sono stati utilizzati da più persone rispetto ai protocolli binari.

Ma questa non è la storia completa. Costruire una rete è difficile. Davvero difficile. Oggi siamo così abituati a Internet che non ci rendiamo pienamente conto di quale miracolo dell'ingegneria sia. Quasi ogni aspetto di Internet si è evoluto da una correzione di bug. Ad esempio, utilizziamo l'indirizzo IP anziché l'indirizzo MAC perché ci consente di costruire router con solo kilobyte (o in questi giorni megabyte) anziché terabyte di RAM per la tabella di routing. Più problemi abbiamo cercato di risolvere, più tendiamo a preferire i protocolli testuali per eseguirne il debug. Una volta che abbiamo avuto abbastanza esperienza nello sviluppo di protocolli di rete di basso livello, quando è arrivato il momento di sviluppare protocolli applicativi, la maggior parte dei programmatori e ingegneri esperti tendeva a preferire i protocolli di testo.

Per esperienza personale, ho lavorato per un'azienda che costruisce router e ho anche lavorato per un'azienda che costruisce apparecchiature di telemetria, quindi ho molta esperienza lavorando con protocolli binari come TCP / IP, ARP, IEC60870-5- 101 e DNP3. Ho anche lavorato con protocolli di testo come HTTP, POP3 e NMEA. Ho anche lavorato con formati di dati binari come ASN.1 e formati di dati di testo come JSON e XML. Se dovessi scegliere, sceglierei il testo quasi ogni volta. L'unica volta che sceglierei binario è se il protocollo è veramente di basso livello (quindi implementerei quel tanto che basta per poter scrivere un protocollo basato su testo in cima o esso) o i dati sono naturalmente binari (come i file audio) .

Il binario strutturato ha anche dei limiti nell'espanderlo. Durante i miei giorni di lavoro con FidoNet e la creazione di un gateway tra esso e UUCP / USNET, le intestazioni dei messaggi di Fidonet erano un binario strutturato. Espanderlo anche solo provando ad aggiungere un byte da qualche parte significa rompere tutto ciò che sta cercando di lavorare con esso. Avere un'intestazione o un protocollo di testo significa che puoi espandere qualcosa senza rompere le cose.

La tua domanda può essere interpretata in tre modi:

1. Perché i dati numerici vengono trasmessi in rappresentazione testuale, come se fossero stati stampati con ad esempio printf()?
2. Perché i protocolli del classico livello di applicazione - ad es. Il canale di controllo ftp, smtp, http - usano tradizionalmente tutti un set di caratteri ASCII a 7 bit? (ASCII a 7 bit può essere considerato "testo" perché la maggior parte dei byte corrisponde a glifi stampabili o codici di controllo del testo come newline e da feed.)
3. Perché i BLOB di dati binari vengono spesso convertiti in ASCII a 7 bit quando vengono inviati su Internet, ad esempio come allegato di posta?

La risposta alla prima è l'interoperabilità. I valori interi e in virgola mobile hanno rappresentazioni binarie diverse su macchine diverse, o persino compilatori, o anche con opzioni di compilatore solo diverse. Trasmetterli in modo efficace tramite l' printf/scanfinteroperabilità è semplice. Si noti che questa scelta è stata fatta solo per i protocolli di livello superiore di cui alcuni sono menzionati sopra; a livello di rete i dati vengono trasmessi binariamente. Per questo, TCP / IP definisce una rappresentazione intera binaria e le librerie che implementano TCP / IP forniscono i mezzi per convertire tra le rappresentazioni di host e di rete con htonle amici.

La risposta alla seconda domanda è probabilmente che RFC 206 (notare il numero basso - 1971!) Descrive il protocollo telnet, su cui si basano molti protocolli a livello di applicazione, come una sostituzione diretta del teletipo

funzione di cui è di fare un terminale di sistema online sembrano a qualsiasi sistema di time-sharing telescrivente-compatibili sulla rete come se fosse collegato direttamente a quel sistema .

(Enfasi nel testo originale.) Almeno alcuni teletipi e in particolare le reti di teletipi hanno usato ASCII a 7 bit come set di caratteri che deve averlo reso una scelta naturale.

La risposta alla terza è semplicemente che, poiché i protocolli del livello applicazione sono basati su telnet e telnet è ascii a 7 bit, molti software e hardware non sono stati preparati per gestire i dati a 8 bit . L'invio di allegati binari potrebbe essere considerato un uso improprio della posta elettronica; quindi i cerchi. Oggi questo di solito non è più vero e i protocolli vengono continuamente estesi (o semplicemente utilizzati) per gestire direttamente i dati binari.