Dlaczego tak wiele protokołów internetowych opiera się na tekście?

Z tego, co odkryłem, bardzo duża liczba protokołów podróżujących przez Internet jest oparta na tekście, a nie binarnie. Protokoły, o których mowa, obejmują między innymi HTTP, SMTP, FTP (myślę, że ten jest w całości oparty na tekście?), WHOIS, IRC.

W rzeczywistości niektóre z tych protokołów przeskakują niektóre obręcze, gdy chcą przesyłać dane binarne .

Czy jest tego powód? Protokoły tekstowe mają oczywiście narzut, ponieważ wymagają wysłania większej ilości danych w celu przesłania tej samej ilości informacji (patrz przykład poniżej). Jakie korzyści przewyższają to?

Pod pojęciem tekstowym rozumiem, że większość znaków używanych w protokole to między 0x20(spacja) i 0x7E( ~), a od czasu do czasu „znak mowy” używany jest do bardzo specjalnych celów , takich jak znaki nowej linii, null, ETX i EOT. Jest to przeciwne do przesyłania surowych danych binarnych przez połączenie.

Na przykład przesłanie liczby całkowitej 123456jako tekstu wymagałoby wysłania ciągu 123456(przedstawionego w postaci szesnastkowej jako 31 32 33 34 35 36), podczas gdy 32-bitowa wartość binarna zostałaby wysłana jako (przedstawiona w postaci szesnastkowej) 0x0001E240(i jak widać „zawiera” specjalny znak zerowy .

Kiedy świat był młodszy, a komputery nie były wszystkimi chwalebnymi komputerami PC, rozmiary słów były różne (w DEC 2020 mieliśmy około 36 bitów), format danych binarnych był spornym problemem (duży endian vs. mały endian, a nawet dziwniejszy porządek bitów był dość powszechny). Nie było zgody co do wielkości / kodowania znaków (ASCII, EBCDIC były głównymi konkurentami, nasza DEC miała 5/6/7/8 bitów / kodowanie znaków). ARPAnet (poprzednik internetowy) został zaprojektowany do łączenia maszyn dowolnego opisu. Wspólnym mianownikiem był (i nadal jest) tekst. Można mieć całkowitą pewność, że 7-bitowy kodowany tekst nie zostanie zniekształcony przez podstawowe metody przesyłania danych (do niedawna wysyłanie wiadomości e-mail w 8-bitowym kodowaniu gwarantowało, że odbiorca otrzyma okaleczone wiadomości,

Jeśli przeszukujesz np. Opisy protokołów telnet lub FTP (pierwsze protokoły internetowe, pomysł sieci polegał na łączeniu się zdalnie z „superkomputerem” i tasowaniu plików tam iz powrotem), zobaczysz, że połączenie obejmuje negocjowanie wielu szczegółów bierzemy za mundur,

Tak, binarny byłby (trochę) bardziej wydajny. Ale maszyny i wspomnienia (a także sieci) ogromnie się rozrosły, więc trochę przeszukiwania przeszłości należy już do przeszłości (głównie). I nikt przy zdrowych zmysłach nie zasugeruje zerwania wszystkich istniejących protokołów w celu zastąpienia ich binarnymi. Poza tym protokoły tekstowe oferują bardzo przydatną technikę debugowania. Dzisiaj nigdy nie instaluję serwera Telnet (lepiej używaj szyfrowanego protokołu SSH do połączeń zdalnych), ale muszę mieć klienta telnet, który może „porozmawiać” z jakimś błędnym serwerem, aby znaleźć problemy. Dzisiaj pewnie używać netcata lub nkat dla futzing wokół ...

Jedną z zalet, którą można przeoczyć, jest możliwość eksperymentowania . Jeśli spychasz kawałki rurki, będziesz musiał napisać jakieś narzędzie, które tłumaczy EHLOna 0x18lub podobne. Zamiast tego możesz po prostu telnet EHLOpołączyć się z serwerem poczty, wysłać i być w drodze.

Nic nie powstrzymuje was w tym dniu i wieku od pisania kodu w Zgromadzeniu lub Brainf * ck , a może bardzo dobrze uratować jakieś bity w ten sposób. Jednak wyjaśnienie, co dokładnie zrobiłeś komuś innemu, aby mógł on zrozumieć Twój kod i wchodzić w interakcje z nim, nie będzie łatwe, jeśli to zrobisz.

W przypadku protokołów ważne jest, aby użytkownicy mogli łatwo nauczyć się z nich korzystać, ponieważ większość ludzi, którzy korzystali z ARPAnet lub początków Internetu, czuli się dobrze za terminalem.

Nawiasem mówiąc, podobne argumenty toczą się dziś w firmach. Czy powinniśmy dokonać serializacji do JSON lub BSON (binarna reprezentacja JSON)? Jeśli serializujesz do BSON, tracisz trochę narzutów, ale teraz potrzebujesz tłumacza, aby przekonwertować BSON na JSON i odwrotnie, ponieważ człowiek będzie musiał odczytać te dane w pewnym momencie, gdy coś nieuchronnie pójdzie nie tak.

Nie jest tak, że wiele protokołów internetowych opiera się na tekście. W rzeczywistości, gdybym zgadywał, powiedziałbym, że protokoły tekstowe należą do mniejszości. Dla prawie każdego protokołu tekstowego, który widzisz w Internecie, istnieją co najmniej dwa protokoły binarne, które ludzie wymyślili, aby wysłać te same lub podobne dane.

Ale prawdą jest, że większość ruchu internetowego korzysta z protokołów tekstowych. Ten fakt jest interesujący, jeśli założymy, że istnieje o wiele więcej protokołów binarnych niż tekst, ale znacznie więcej ruchu tekstowego niż binarny. Oznacza to, że większość udanych protokołów w Internecie jest oparta na tekście. Z wyjątkiem niewielkiej liczby aplikacji (przykładem jest bittorrent) protokoły binarne zwykle giną.

We wczesnych dniach Internetu korporacje miały tendencję do projektowania i używania protokołu binarnego (na przykład MSN, a nie dzisiejszej strony MSN, oryginalnej zastrzeżonej sieci MicroSoft, która miała zastąpić HTTP), podczas gdy wojsko, instytuty badawcze i naukowcy mieli tendencję do zaprojektuj i użyj protokołu tekstowego. Częściowo dlatego, że budowanie i debugowanie protokołów binarnych było trudne, a korporacje stać na to, aby płacić ludziom za to, podczas gdy wojsko, badacze i naukowcy robili to w wolnym czasie za darmo (większość ludzi, którzy opracowali Internet, mieli miejsca pracy niezwiązane z rozwojem Internetu).

Kiedy piszesz kod w weekendy jako hobby i nie zarabiasz za robienie tego, co robisz, zwykle wybierasz prostsze rozwiązanie - tekst. Tak więc protokoły tekstowe były używane przez większą liczbę osób niż protokoły binarne.

Ale to nie jest pełna historia. Budowa sieci jest trudna. Naprawdę trudny. Jesteśmy tak przyzwyczajeni do Internetu, że nie zdajemy sobie w pełni sprawy z tego, jak cudem jest inżynieria. Prawie każdy aspekt Internetu ewoluował w wyniku naprawy błędu. Na przykład używamy adresu IP zamiast adresu MAC, ponieważ pozwala nam budować routery z kilobajtami (lub dzisiejszymi megabajtami) zamiast terabajtów pamięci RAM dla tabeli routingu. Im więcej problemów próbowaliśmy rozwiązać, tym bardziej preferujemy protokoły tekstowe do ich debugowania. Kiedy mieliśmy wystarczające doświadczenie w tworzeniu niskopoziomowych protokołów sieciowych, kiedy przyszedł czas na opracowanie protokołów aplikacji, większość doświadczonych programistów i inżynierów preferowała protokoły tekstowe.

Z własnego doświadczenia pracowałem dla firmy budującej routery, a także pracowałem dla firmy budującej sprzęt telemetryczny, więc mam duże doświadczenie w pracy z protokołami binarnymi, takimi jak TCP / IP, ARP, IEC60870-5- 101 i DNP3. Pracowałem również z protokołami tekstowymi, takimi jak HTTP, POP3 i NMEA. Pracowałem również z binarnymi formatami danych, takimi jak ASN.1 i formatami danych tekstowych, takimi jak JSON i XML. Gdybym miał wybrać, prawie za każdym razem wybrałbym tekst. Jedyny raz, gdy wybieram binarny, to jeśli protokół jest naprawdę niskiego poziomu (wtedy zaimplementuję tylko tyle, że mogę umieścić na nim protokół tekstowy) lub dane są naturalnie binarne (jak pliki audio) .

Strukturalny plik binarny ma również ograniczenia w rozszerzaniu go. W ciągu moich dni pracy z FidoNet i budowania bramy między nim a UUCP / USNET, nagłówki wiadomości Fidonet były ustrukturyzowanym plikiem binarnym. Poszerzenie go nawet o dodanie bajtu oznacza rozbicie wszystkiego, co próbuje z nim pracować. Posiadanie nagłówka tekstu lub protokołu oznacza, że ​​możesz rozwinąć coś bez rozbijania.

Twoje pytanie można interpretować na trzy sposoby:

1. Dlaczego dane liczbowe są przesyłane w postaci tekstowej, tak jakby zostały wydrukowane np. printf()?
2. Dlaczego klasyczne protokoły warstwy aplikacji - np. Kanał kontrolny ftp, smtp, http - tradycyjnie używają 7-bitowego zestawu znaków ASCII? (7-bitowy kod ASCII można uznać za „tekst”, ponieważ większość bajtów odpowiada drukowanym glifom lub kodom sterującym tekstem, takim jak znak nowej linii i z kanału informacyjnego).
3. Dlaczego obiekty BLOB danych binarnych są często konwertowane na 7-bitowe ascii, gdy są przesyłane przez Internet, np. Jako załącznik do wiadomości?

Odpowiedzią na pierwszą jest interoperacyjność. Wartości całkowite i zmiennoprzecinkowe mają różne reprezentacje binarne na różnych komputerach, a nawet kompilatorach, a nawet z różnymi opcjami kompilatora. Ich efektywne przesyłanie printf/scanfułatwia interoperacyjność. Zauważ, że tego wyboru dokonano tylko dla protokołów wyższego poziomu, z których kilka wspomniano powyżej; w warstwie sieci dane są przesyłane binarnie. W tym celu protokół TCP / IP definiuje binarną reprezentację liczb całkowitych, a biblioteki implementujące protokół TCP / IP zapewniają środki do konwersji między reprezentacją hosta i sieci htonloraz przyjaciółmi.

Odpowiedź na drugie pytanie jest prawdopodobnie taka, że RFC 206 (zwróć uwagę na niską liczbę - 1971!) Opisuje protokół telnet, na którym opiera się wiele protokołów warstwy aplikacji, jako bezpośrednia zamiana teletypu

którego funkcją jest wyświetlanie terminala systemu online w dowolnym systemie współdzielenia czasu zgodnym z typem teletekstu w sieci, tak jakby był bezpośrednio podłączony do tego systemu .

(Podkreślenie w oryginalnym tekście.) Przynajmniej niektóre typy teletekstu, a w szczególności sieci teletypów, używały 7-bitowego ASCII jako zestawu znaków, co musiało sprawić, że był to naturalny wybór.

Odpowiedź na trzecie pytanie polega na tym, że ponieważ protokoły warstwy aplikacji są oparte na telnecie, a telnet ma 7 bitów ascii, wiele oprogramowania i sprzętu nie było przygotowanych do obsługi danych 8-bitowych . Wysyłanie załączników binarnych można uznać za niewłaściwe użycie wiadomości e-mail; stąd obręcze. Dzisiaj zwykle nie jest to już prawdą, a protokoły są ciągle rozszerzane (lub po prostu używane) do bezpośredniej obsługi danych binarnych.