Почему так много интернет-протоколов основаны на тексте?

Из того, что я обнаружил, очень большое количество протоколов, которые передаются через Интернет, являются «текстовыми», а не двоичными. Рассматриваемые протоколы включают, но не ограничиваются HTTP, SMTP, FTP (я думаю, что все эти текстовые?), WHOIS, IRC.

Фактически, некоторые из этих протоколов перепрыгивают через некоторые обручи всякий раз, когда они хотят передать двоичные данные .

Есть ли причина этого? Текстовые протоколы, очевидно, имеют некоторые издержки, поскольку требуют отправки большего количества данных для передачи того же объема информации (см. Пример ниже). Какие преимущества перевешивают это?

Под текстовым я подразумеваю, что большинство символов, используемых в протоколе, находятся между 0x20(пробел) и 0x7E( ~), причем случайные «специальные символы» используются для очень специальных целей , таких как символы новой строки, ноль, ETX и EOT. Это противоположно передаче необработанных двоичных данных по соединению.

Например, передача целого числа в 123456виде текста потребует отправки строки 123456(представленной в шестнадцатеричном виде 31 32 33 34 35 36), тогда как 32-разрядное двоичное значение будет отправлено как (представленного в шестнадцатеричном виде) 0x0001E240(и, как вы можете видеть, «содержит» специальный нулевой символ). ,

Когда мир был моложе, и компьютеры были не все прославленные ПК, слово размеров варьировали (в DEC-2020 мы здесь было 36 битных слов), формат двоичных данных был спорный вопрос (большой байтов против небольшой Endian, и даже страннее порядки битов были достаточно распространены). Был небольшой консенсус в отношении размера / кодировки символов (основными претендентами были ASCII, EBCDIC, у нашего DEC было 5/6/7/8 бит / символьное кодирование). ARPAnet (интернет-предшественник) был разработан для подключения машин любого описания. Общим знаменателем был (и остается) текст. Вы можете быть достаточно уверены, что 7-битный кодированный текст не будет искажен базовыми средствами для отправки данных (до недавнего времени отправка электронной почты в некоторой 8-битной кодировке несла гарантию, что получатель получит искаженные сообщения,

Если вы покопаетесь, например, в описаниях протоколов telnet или FTP (первые интернет-протоколы, идея сети заключалась в том, чтобы удаленно подключаться к «суперкомпьютеру» и перетасовывать файлы туда-сюда), вы увидите, что соединение включает в себя согласование множества деталей. мы берем как униформу,

Да, двоичный код будет (немного) более эффективным. Но машины и воспоминания (а также сети) очень сильно выросли, так что скудные уроды ушли в прошлое (в основном). И никто в здравом уме не предложит разорвать все существующие протоколы, чтобы заменить их двоичными. Кроме того, текстовые протоколы предлагают очень полезную технику отладки. Сегодня я никогда не устанавливаю telnet-сервер (лучше использовать зашифрованный протокол SSH для удаленных подключений), но мне нужно telnet-клиент, чтобы удобно «разговаривать» с каким-то ошибочным сервером, чтобы выяснить ошибки. Сегодня вы, вероятно, будете использовать netcat или ncat для суеты ...

Одним из преимуществ, которое можно упустить, является возможность экспериментировать . Если вы пихаете биты вниз по трубке, вам нужно написать какую-нибудь утилиту, которая переводит EHLOв 0x18или тому подобное. Вместо этого вы можете просто подключиться к почтовому серверу через telnet, отправить EHLOи отправиться в путь.

Ничто не мешает вам в наше время писать код на ассемблере или в Brainf * ck , и вы вполне можете сэкономить некоторые биты, сделав это. Однако объяснить, что именно вы сделали с кем-то другим, чтобы они могли понимать и взаимодействовать с вашим кодом, будет нелегко, если вы сделаете это.

При использовании протоколов важно, чтобы пользователи были в состоянии узнать, как их использовать, поскольку большинство людей в те времена, которые использовали ARPAnet или зародыши Интернета, были людьми, которые чувствовали себя комфортно за терминалом.

Подобные аргументы, кстати, сегодня проходят в компаниях. Должны ли мы сериализовать в JSON или BSON (двоичное представление JSON)? Если вы сериализовали в BSON, вы потеряли некоторые накладные расходы, но теперь вам нужен переводчик для преобразования вашего BSON в JSON и наоборот, так как человеку придется читать эти данные в какой-то момент, когда что-то неизбежно пойдет не так.

Дело не в том, что многие интернет-протоколы основаны на тексте. На самом деле, если бы я догадался, я бы сказал, что текстовые протоколы в меньшинстве. Почти для каждого текстового протокола, который вы видите в Интернете, есть как минимум два двоичных протокола, которые люди изобрели для отправки одинаковых или похожих данных.

Но это правда, что большинство интернет- трафика используют текстовые протоколы. Этот факт интересен, если предположить, что двоичных протоколов намного больше, чем текстовых, но намного больше текстового трафика, чем двоичных. Это означает, что большинство успешных протоколов в Интернете основаны на тексте. За исключением небольшого числа приложений (например, битторрент) бинарные протоколы имеют тенденцию к смерти.

В первые дни Интернета корпорации имели тенденцию разрабатывать и использовать двоичный протокол (например, MSN, а не веб-сайт MSN сегодня, оригинальную проприетарную сеть MicroSoft, которая должна была заменить HTTP), в то время как военные, исследовательские институты и ученые стремились к разработать и использовать текстовый протокол. Одной из причин было то, что создание и отладка двоичных протоколов были трудными, и корпорации могут позволить себе платить людям за это, в то время как военные, исследователи и ученые занимались этим в свободное время без оплаты (большинство людей, которые разработали Интернет, имели работа, не связанная с развитием интернета).

Когда вы пишете код по выходным в качестве хобби и вам не платят за то, что вы делаете, вы склонны выбирать более простое решение - текст. Таким образом, текстовые протоколы используются большим количеством людей, чем двоичные протоколы.

Но это еще не все. Построить сеть сложно. Очень трудно. Сегодня мы настолько привыкли к Интернету, что не до конца понимаем, что это за чудо инженерной мысли. Почти все аспекты Интернета возникли из-за исправления ошибок. Например, мы используем IP-адрес вместо MAC-адреса, потому что он позволяет нам создавать маршрутизаторы с килобайтами (или в наши дни мегабайтами) вместо терабайтов ОЗУ для таблицы маршрутизации. Чем больше проблем мы пытались решить, тем больше мы склонны отдавать предпочтение текстовым протоколам для их устранения. Когда у нас было достаточно опыта в разработке сетевых протоколов низкого уровня, когда пришло время разрабатывать прикладные протоколы, большинство опытных программистов и инженеров предпочитали текстовые протоколы.

Исходя из личного опыта, я работал в компании, занимающейся созданием маршрутизаторов, а также в компании, занимающейся созданием телеметрического оборудования, поэтому у меня большой опыт работы с двоичными протоколами, такими как TCP / IP, ARP, IEC60870-5- 101 и ДНП3. Я также работал с текстовыми протоколами, такими как HTTP, POP3 и NMEA. Я также работал с двоичными форматами данных, такими как ASN.1, и текстовыми форматами данных, такими как JSON и XML. Если бы я выбрал, я бы выбрал текст почти каждый раз. Единственный раз, когда я выбрал бы двоичный файл, это если протокол действительно низкоуровневый (тогда я реализовал бы достаточно для того, чтобы я мог добавить текстовый протокол поверх него или его), или данные были естественно двоичными (например, аудиофайлы). ,

Структурированный двоичный файл также имеет ограничения в его расширении. В мои дни работы с FidoNet и создания шлюза между ним и UUCP / USNET заголовки сообщений Fidonet были структурированным двоичным файлом. Расширить его, даже просто попытавшись добавить байт куда-нибудь, означает сломать все, что пытается с ним работать. Наличие текстового заголовка или протокола означает, что вы можете расширять что-либо без проблем.

Ваш вопрос можно интерпретировать тремя способами:

1. Почему числовые данные передаются в текстовом виде, как если бы они были напечатаны, например, с помощью printf()?
2. Почему классические протоколы прикладного уровня - например, канал управления ftp, smtp, http - традиционно все используют 7-битный набор символов ASCII? (7-битный ASCII можно считать «текстовым», потому что большинство байтов соответствуют печатным глифам или текстовым управляющим кодам, таким как перевод строки и из ленты.)
3. Почему капли двоичных данных часто преобразуются в 7-битные ascii, когда они отправляются через Интернет, например, в виде почтового вложения?

Ответ на первый - совместимость. Целые числа и значения с плавающей запятой имеют разные двоичные представления на разных машинах, или даже компиляторах, или даже просто с разными опциями компилятора. Эффективная их передача через printf/scanfинтерфейс обеспечивает легкость взаимодействия. Обратите внимание, что этот выбор был сделан только для протоколов более высокого уровня, некоторые из которых упомянуты выше; на сетевом уровне данные передаются в двоичном формате. Для этого TCP / IP определяет двоичное целочисленное представление, а библиотеки, реализующие TCP / IP, предоставляют средства для преобразования между хостом и сетевым представлением с htonlдрузьями.

Ответ на второй вопрос, вероятно, заключается в том, что RFC 206 (обратите внимание на небольшое число - 1971!) Описывает протокол telnet, на котором основаны многие протоколы прикладного уровня, в качестве прямой замены телетайпа.

чья функция заключается в терминал Интернет система появится в любой телетайп-совместимый, разделения времени системы в сети , как если бы это были подключены непосредственно к этой системе .

(Акцент в исходном тексте.) По крайней мере, некоторые телетайпы и в частности сети телетайпов использовали 7-битный ASCII в качестве набора символов, что должно было сделать его естественным выбором.

Ответ на третий вопрос заключается в том, что, поскольку протоколы прикладного уровня основаны на telnet, а telnet является 7-битным ascii, многие программные и аппаратные средства не были готовы к работе с 8-битными данными . Отправка двоичных вложений может рассматриваться как злоупотребление электронной почтой; отсюда обручи. Сегодня это обычно уже не так, и протоколы постоянно расширяются (или просто используются) для непосредственной обработки двоичных данных.