Белые волосы и бинарные протоколы
В конце прекрасного выступления Джейсона Смита из Container Solutions на Kubecon на прошлой неделе о бинарных протоколах один из молодых участников задал интересный вопрос. «Являются ли современные бинарные протоколы такими же болезненными, как, как я слышал, ASN.1?» Ответ был «нет», но есть еще несколько интересных уроков из эволюции бинарных протоколов, над которыми стоит задуматься.
Двоичный или текстовый - текст выигран
В былые времена, когда пропускную способность и процессор было сложно найти, мы использовали двоичные, а не текстовые протоколы для связи между процессами. Это было связано с тем, что двоичные протоколы занимали меньше места на проводе и им требовалось меньше циклов процессора для кодирования и декодирования. Одной из самых популярных двоичных кодировок была абстрактная синтаксическая нотация 1 (ASN.1).
Обратной стороной двоичного кода было то, что сообщения было трудно читать на глаз, поэтому было сложно диагностировать проблемы. Вам часто приходилось расшифровывать сообщения вручную. Когда в конце 90-х годов прошлого века пропускная способность и ЦП стали более распространенными, на смену пришли текстовые кодировки, такие как XML и JSON. Они были дорогими, но их было гораздо проще отлаживать - вы могли легко увидеть, было ли что-то неправильно сформировано или просто неожиданным.
Двоичный возвращается
Теперь, когда микросервисные архитектуры генерируют большое количество трафика, текстовые протоколы снова выглядят слишком затратными по ресурсам, поэтому мы возвращаемся к бинарным протоколам. Но извлекли ли мы уроки, которые оттолкнули нас от них?
Какие уроки ASN.1 преподает нам о современных двоичных протоколах?
ASN.1 был очень ранним (1984 г.) стандартом двоичного протокола, который был изобретен для решения тех же проблем, что и современные буферы протоколов. Так что же с этим не так?
- ASN.1 предшествовал общему открытому исходному коду. Стандартной библиотеки для кодирования и декодирования ASN.1 не было, каждый написал свой кодировщик. При взаимодействии вы часто декодировали двоичные сообщения, закодированные другим кодировщиком. Это означает, что не будет большого количества несоответствий, которые необходимо устранить с помощью ручного декодирования, и обходных путей в вашей реализации кодировщика.
Урок первый: если вы собираетесь взаимодействовать, будет намного проще, если все будут использовать одну и ту же библиотеку кодирования. Не полагайтесь на соответствие стандарту.
- Чтобы усугубить это, существовали, казалось бы, бесконечные варианты кодирования ASN.1, что еще больше усложняло написание согласованных кодировщиков.
Урок второй: если вы собираетесь изобрести двоичный протокол, будьте проще. Чем больше у вас вариантов кодирования и чем больше существует кодировщиков, тем сложнее будет обеспечить бесперебойную совместимость.
И это история происхождения моих седых волос.
Конец примечания - глядя на Linkerd, который я никогда не пробовал, похоже, что он может эффективно принудить к использованию согласованной версии кодировщика ??? Звучит удобно?
