Я давно наблюдаю в программировании засилие текстовых протоколов обмена. Мода на представление информации в «читаемом человеком» (human readable) виде пошла с языков группы SGML — HTML и XML. Раздутых и переусложнённых, иногда, до идиотизма. Одно время XML стал настолько мейнстримным, что им пытались представить вообще любую передаваемую информацию где бы то ни было. Этот процесс родил, в том числе, таких чудовищ ума как веб-сервисы и SOAP: архитектуры самоконфигурирующихся служб, которые, по факту, никому на самом деле не нужны. Потому, что они всё равно требуют той же самой ручной конфигурации уровнями ниже и выше (адаптации программной архитектуры).

Проблемы тут две: как в избыточности архитектуры самих веб-сервисов (но сейчас не о них), так и в вопиюще порочной идее уменьшать плотность данных, представляя их в текстовом виде.

Тут мне можно возразить с точки зрения борьбы со сложностью. Благодаря усложнению внутренней архитектуры протоколов, передающихся кадров данных, достигается, вроде как, уменьшение сложности использования таких протоколов «вовне». Теоретически, это должно быть так. Однако, любой, кто хоть раз занимался настройкой всего стека какой-нибудь SOAP на клиенте и сервере ради передачи 400 байт фактических данных начнёт немного сомневаться в справедливости этого утверждения.  Зачем весь этот самоконфигурирующийся огород ради применения в одной конкретной задаче, интерфейсное выражение которой если и будет в дальнейшем меняться, то меняться оно будет вместе с клиентскими приложениями.

Текст против плотности

Но это лишь половина беды. Если архитектурная избыточность именно веб-сервисов ещё может быть хоть как-то оправдана по отношению к каким-то частным задачам, то снижение плотности потока данных только от самого факта использования именно текста не оправдано вообще ничем, кроме каких-то психологических загонов. И такое снижение плотности данных актуально, если брать в качестве референтной систему кодирования текста ASCII. А если Юникод? Хорошо, если используется кодировка UTF-8 и передаваемые данные состоят исключительно из латинских символов, тогда потери плотности будут примерно такими же. А если, скажем, не латиница? Или используется система кодирования UTF-16? Данные тут же растянутся ещё в два раза без всякого увеличения их содержательной части!

Но дальше — больше. Посмотрим на сами данные. Хорошо, если они изначально представляют собой текст: в таком вырожденном случае особой существенной разницы действительно не будет. Но такая частность встречается крайне редко. В большинстве случаев необходимо передавать, помимо каких-то небольших фрагментов текста, числа и бинарные данные.

Рассмотрим передачу целого числа размерностью 4 байта. Да, само по себе оно занимает 4 байта данных. Но его текстовое представление для передачи может занимать от одного байта до 10 байт в зависимости от его длины.

Стандартные числа с плавающей точкой: 4 байта в своём натуральном представлении в памяти, и, опять же, от 1 (но такого я ещё не видел) до «очень много» в текстовом представлении, в зависимости от необходимой точности (количества знаков после запятой).

Хитом же этого парада являются изначально бинарные данные, сырые массивы байт. Так как они обычно не могут быть напрямую представлены в текстовом виде, потому что их значения перекрывают служебные коды текстовых кодировок, была придумана и повсеместно используется система трансляции в текст BASE64. Она использует 64 текстовых символа (латинский алфавит, цифры, и 2 вспомогательных знака пунктуации) для представления двоичных данных. Благодаря хитрым перестановкам бит, итоговые данные (в номинальном количестве символов, это важно) длиннее оригинала на 33%.

Текст против вычислительного времени

Но и это ещё не всё! В программных продуктах данные для передачи хранятся в размеченных структурах памяти. Если опустить проблематику данных с переменной длиной и вложенных структур, то передав по проводу (или внутри одного вычислителя, это неважно) просто сам блок памяти с данными и применив к нему на другой стороне ту же разметку, мы уже полностью восстановим данные на другом пире. Всё.

При текстовом кодировании данных, которые изначально существовали в памяти в качестве бинарного блока, необходима провести работу по их развёртке в текстовое представление. Потом передать по проводу в виде последовательности байт (но уже представляющих текстовый «вид» изначальной структуры, да), что зачастую требует дополнительной работы по переводу этого текста из внутренней кодировки в транспортную. Затем, на другой стороне, накопить эти данные в виде бинарного блока, интерпретировать этот бинарный блок в виде текста, а затем провести работу по обратному разбору (парсингу) полученного текста в изначальный двоичный блок.

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

XML против здравого смысла

Но предыдущие рассуждения были предварительным теоретизированием. Если пойти дальше, окажется, что мы не можем просто передать данные в текстовом виде — нужна некоторая их дополнительная разметка, что бы принимающая сторона могла понять что именно ей пришло и в каких местах сообщения находятся какие части куска информации. И вот на этом месте всё вышеперечисленное люто накрывает система разметки XML. Или JSON, это не так важно. Не вдаваясь в детали, все они чрезвычайно избыточны сами по себе и дополнительно, иногда в два раза, увеличивают размер сообщения, ещё уменьшая плотность данных. Но кроме пустой нагрузки на провод, они ещё и довольно сложны в разборе (парсинге). Получается, провод греется сильнее, программы с обеих сторон проделывают ещё больше работы по трансляции туда-сюда протокольных кадров и структур памяти.

 

И весь этот цирк с жонглированием данными в разных форматах представления происходит в месте настолько тёмном, что, скорей всего, его вообще никто и никогда не увидит. А программе абсолютно всё равно, в каком виде представлены данные, если определён набор их биекций из/в внутренние структуры. В итоге мы получаем весьма туманную деятельность по разогреванию атмосферы планеты.

comments powered by HyperComments