бинарные vs текстовые протоколы

Мне интересно, каковы различия между двоичными и текстовыми протоколами. Я читал, что двоичные протоколы более компактны / быстрее обрабатываются. Как это работает? Так как вы должны отправить такое же количество данных? Нет?

например, как строка "hello" будет отличаться по размеру в двоичном формате?

спасибо

6 ответов


Если все, что вы делаете-это передача текста, то да, разница между ними не очень значительны. Но подумайте о попытке передать такие вещи, как:

  • Numbers-используете ли вы строковое представление числа или двоичный файл? Особенно для больших чисел двоичный файл будет более компактным.
  • структуры данных-как вы обозначаете начало и конец поля в текстовом протоколе? Иногда двоичный протокол с полями фиксированной длины больше компактный.

текстовые протоколы лучше с точки зрения удобочитаемости, простоты переопределения и простоты отладки. Бинарные протоколы более компактны.

тем не менее, вы можете сжать текст с помощью библиотеки, такой как LZO или Zlib, и это почти так же компактно, как двоичный (с очень маленькой производительностью для сжатия/декомпрессии.)

вы можете прочитать подробнее на эту тему здесь:
http://www.faqs.org/docs/artu/ch05s01.html


строка "hello" сама по себе не будет отличаться по размеру. Разница в размере / производительности заключается в дополнительной информации, которую вводит сериализация (сериализация-это то, как программа представляет данные для передачи, чтобы ее можно было повторно конструтировать, как только она попадет на другой конец канала).

например, при сериализации следующего в .NET с помощью XML (один из методов сериализации текста):

string helloWorld = "Hello World!";

Вы можете получить что-то вроде (Я знаю, что это не точно):

<helloWorld type="String">Hello World!</helloWorld>

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


двоичные протоколы лучше, если вы используете контрольные биты / байты

Я.е вместо того, чтобы отправить сообщение:Здравствуйте! в двоичном формате это может быть 0x01, за которым следует ваше сообщение (предполагая, что 0x01-это управляющий байт, который означает msg)

Итак, поскольку в текстовом протоколе вы отправляете msg: hello\0 ...он включает 10 байт где, как и в двоичном протоколе, это будет 0x01Hello\0 ...это включает в себя 7 байт

и другой пример, Предположим, вы хотите отправить число скажем 255, в тексте его 3 байты где как в двоичном его 1 байт i.e 0xFF


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

протокол является частью сообщения " Привет, могу ли я подключиться? У меня есть кое-какие данные, куда их девать? У тебя есть ответ для меня? здорово! спасибо, пока!"

каждый бит преобразования (вероятно) намного меньше в двоичном протоколе, например, HTTP (который основан на тексте):

Если бы у вас был стандарт кодировки, я уверен, вы могли бы придумать последовательность символов меньше, чем 4 байта, необходимые для слова "PUSH"


Я бы не сказал, что двоичные форматы быстрее обрабатываются. Если вы посмотрите на CSV или текстовый формат с фиксированной длиной поля-он все еще может быть быстро обработан.

Я бы сказал, Все зависит от того, кто является потребителем. Если человек находится в конце (например, для HTTP или RSS), то нет необходимости каким-то образом сжимать данные, за исключением, возможно, сжатия.

двоичным протоколам нужны Парсеры / конверторы, которые трудно расширить и сохранить обратную совместимость. Чем выше вы идете в стеке протоколов, тем больше ориентированных на человека протоколов (TCP является двоичным, поскольку пакеты должны обрабатываться маршрутизаторами на высокой скорости, но XML более удобен для человека).

Я думаю, что изменения размера сегодня не имеют большого значения. Например,hello будет принимать ту же сумму в двоичном формате, что и в текстовом формате, потому что текстовый формат также "двоичный" для компьютера - только то, как мы интерпретируем данные.