Чому так багато інтернет-протоколів на основі тексту?

Як я знайшов, дуже велика кількість протоколів, які подорожують по Інтернету, є "текстовими", а не двійковими. Протоколи, про які йдеться, включають HTTP, SMTP, FTP (я думаю, це все на основі тексту?), WHOIS, IRC.

Насправді, деякі з цих протоколів стрибають через обручі, коли вони хочуть передавати двійкові дані .

Чи є причина в цьому? Текстові протоколи, очевидно, мають дещо накладні витрати, оскільки їм потрібно надсилати більше даних для передачі однакового обсягу інформації (див. Приклад нижче). Які переваги переважують це?

Під текстом я маю на увазі, що більшість символів, що використовуються в протоколі, знаходяться між 0x20(пробіл) і 0x7E( ~), при цьому випадкові "спікальні символи" використовуються для особливих цілей , таких як нові рядки, null, ETX та EOT. Це протилежне передачі необроблених, двійкових даних через з'єднання.

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

Коли світ був молодшим, а комп’ютери не були всім прославленими ПК, розміри слів варіювались (у DEC 2020 році у нас тут було 36 розрядних слів), формат бінарних даних був суперечливим питанням (великий ендіан проти маленького ендіана і навіть більш дивний порядки бітів були досить поширеними). Немало консенсусу щодо розміру / кодування символів (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 і навпаки, оскільки людині доведеться читати ці дані в якийсь момент, коли щось неминуче піде не так.

Справа не в тому, що багато інтернет-протоколів є текстовими. Насправді, якби я здогадувався, я б сказав, що текстові протоколи є меншиною. Практично для кожного текстового протоколу, який ви бачите в Інтернеті, є щонайменше два двійкові протоколи, які люди винайшли для надсилання одних і тих же або подібних даних.

Але це правда, що більшість інтернет- трафіку використовують текстові протоколи. Цей факт цікавий, якщо припустити, що існує багато більше бінарних протоколів, ніж текстових, але набагато більше текстового трафіку, ніж двійкових. Це означає, що більшість успішних протоколів в Інтернеті є текстовими. За винятком невеликої кількості застосунків (один із прикладів - bittorrent) бінарні протоколи, як правило, гинуть.

У перші дні Інтернету корпорації прагнули розробляти та використовувати бінарний протокол (наприклад, MSN, а не веб-сайт MSN сьогодні, оригінальна власна мережа MicroSoft, яка повинна була замінити HTTP), тоді як військові, науково-дослідні інститути та вчені розробити та використовувати текстовий протокол. Частина причини полягала в тому, що складання та налагодження бінарних протоколів було важким, і корпорації можуть дозволити собі платити людям за це, тоді як військові, дослідники та науковці робили це у вільний час без оплати (більшість людей, які розвивали Інтернет, мали робочі місця, не пов'язані з розвитком Інтернету).

Коли ви пишете код у вихідні дні як хобі і не платите за те, що робите, ви схильні вибирати простіше рішення - текст. Тож текстові протоколи звикли більшість людей, ніж двійкові протоколи.

Але це ще не повна історія. Побудувати мережу важко. Дійсно важко. Сьогодні ми так звикли до Інтернету, що не до кінця усвідомлюємо, що це за диво інженерії. Майже кожен аспект Інтернету розвивався з виправлення помилок. Наприклад, ми використовуємо IP-адресу замість MAC-адреси, оскільки це дозволяє нам будувати маршрутизатори лише кілобайт (або в ці дні мегабайти) замість терабайтів оперативної пам’яті для таблиці маршрутизації. Чим більше і більше проблем ми намагалися вирішити, тим більше ми віддаємо перевагу текстовим протоколам для їх налагодження. Коли ми мали достатньо досвіду розробки мережевих протоколів низького рівня, коли прийшов час розробляти протоколи додатків, більшість досвідчених програмістів та інженерів, як правило, віддавали перевагу текстовим протоколам.

З особистого досвіду я працював у маршрутизаторі компанії, а також працював у телевізійному обладнанні обладнання, тому маю великий досвід роботи з бінарними протоколами, такими як TCP / IP, ARP, IEC60870-5- 101 та DNP3. Я також працював з текстовими протоколами, такими як HTTP, POP3 та NMEA. Я також працював з бінарними форматами даних, такими як ASN.1 та текстовими форматами даних, такими як JSON та XML. Якби я вибирав, я вибирав би текст майже кожного разу. Єдиний раз, коли я вибрав бинарний, - це якщо протокол насправді низького рівня (тоді я б реалізував достатньо, щоб я міг розкласти текстовий протокол зверху чи він) або дані, природно, бінарні (наприклад, аудіофайли) .

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

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

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

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

Відповідь на друге питання, ймовірно, що RFC 206 (зверніть увагу на низьку кількість - 1971!) Описує протокол telnet, на якому базується багато протоколів рівня додатків, як пряму заміну телетайпу

функція якого полягає в тому, щоб термінал Інтернет-системи відображався в будь-якій сумісній з телетайпами системі обміну часом у Мережі так, ніби він був безпосередньо підключений до цієї системи .

(Наголос в оригінальному тексті.) Принаймні деякі телетипи і, зокрема, телетипні мережі, використовували 7-бітний ASCII як набір символів, який, мабуть, зробив це природним вибором.

Третя відповідь полягає в тому, що, оскільки протоколи рівня додатків засновані на telnet, а telnet - це 7-бітова ascii, багато програмного та апаратного забезпечення не були готові працювати з 8-бітовими даними . Надсилання бінарних вкладених файлів може вважатися неправильним використанням електронної пошти; звідси обручі. Сьогодні це, як правило, більше не відповідає дійсності, і протоколи постійно розширюються (або просто використовуються) для прямої обробки двійкових даних.