Бинарные протоколы против текстовых протоколов

Ответ 1

Бинарный протокол в сравнении с текстовым протоколом на самом деле не связан с тем, как закодированы двоичные капли. Разница в том, действительно ли протокол ориентирован на структуры данных или вокруг текстовых строк. Позвольте привести пример: HTTP. HTTP - текстовый протокол, хотя при отправке jpeg-изображения он просто отправляет необработанные байты, а не их кодировку.

Но что делает HTTP текстовым протоколом, что обмен для получения jpg выглядит так:

Запрос:

GET /files/image.jpg HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.01 [en] (Win95; I)
Host: hal.etc.com.au
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8

Ответ:

HTTP/1.1 200 OK
Date: Mon, 19 Jan 1998 03:52:51 GMT
Server: Apache/1.2.4
Last-Modified: Wed, 08 Oct 1997 04:15:24 GMT
ETag: "61a85-17c3-343b08dc"
Content-Length: 60830
Accept-Ranges: bytes
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/jpeg

<binary data goes here>

Обратите внимание, что это может быть очень легко упаковано гораздо более тесно в структуру, которая будет выглядеть (на C) чем-то вроде

Запрос:

struct request {
  int requestType;
  int protocolVersion;
  char path[1024];
  char user_agent[1024];
  char host[1024];
  long int accept_bitmask;
  long int language_bitmask;
  long int charset_bitmask;
};

Ответ:

struct response {
  int responseType;
  int protocolVersion;
  time_t date;
  char host[1024];
  time_t modification_date;
  char etag[1024];
  size_t content_length;
  int keepalive_timeout;
  int keepalive_max;
  int connection_type;
  char content_type[1024];
  char data[];
};

Если имена полей не должны передаваться вообще и где, например, responseType в структуре ответа есть int со значением 200 вместо трех символов: 2 '' 0 '' 0 ', То, что представляет собой текстовый протокол: тот, который предназначен для передачи как плоский поток (обычно воспринимаемый человеком) строк текста, а не как структурированные данные многих разных типов.

Ответ 2

Здесь вид вид определения:

Вы узнаете это, когда увидите его.

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

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

> fg,m4wr76389b zhjsfg gsidf7t5e89wriuotu nbsdfgizs89567sfghlkf
>  b9er t8ß03q+459tw4t3490ß´5´3w459t srt üßodfasdfäasefsadfaüdfzjhzuk78987342
< mvclkdsfu93q45324äö53q4lötüpq34tasä#etr0 awe+s byf eart

[Представьте себе тонну другого непечатаемого дерьма. Одна из проблем при передаче разницы между текстом и двоичным файлом заключается в том, что вы должны выполнять передачу в тексте: -)]

Или вот так:

< HELLO server.example.com
> HELLO client.example.com
< GO
> GETFILE /foo.jpg
< Length: 3726
< Type: image/jpeg
< READY?
> GO
< ... server sends 3726 bytes of binary data ...
> ACK
> BYE

[Я только что сделал это на месте.]

Там просто не так много двусмысленности.

Другое определение, которое я иногда слышал, это

текстовый протокол - это тот, который можно отлаживать с помощью telnet

Может быть, я показываю свою небрежность здесь, но я действительно писал и читал электронные письма через SMTP и POP3, читал статьи в Usenet через NNTP и просматривал веб-страницы через HTTP с помощью telnet, ни по какой другой причине, кроме как видеть, это действительно сработает.

Собственно, во время написания этого я снова застал лихорадку:

bash-4.0$ telnet smtp.googlemail.com 25
Trying 74.125.77.16...
Connected to googlemail-smtp.l.google.com.
Escape character is '^]'.
< 220 googlemail-smtp.l.google.com ESMTP Thu, 15 Apr 2010 19:19:39 +0200
> HELO
< 501 Syntactically invalid HELO argument(s)
> HELO client.example.com
< 250 googlemail-smtp.l.google.com Hello client.example.com [666.666.666.666]
> RCPT TO:Me <[email protected]>
< 503 sender not yet given
> SENDER:Me <[email protected]>
< 500 unrecognized command
> RCPT FROM:Me <[email protected]>
< 500 unrecognized command
> FROM:Me <[email protected]>
< 500-unrecognized command
> HELP
< 214-Commands supported:
< 214 AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP ETRN
> MAIL FROM:Me <[email protected]>
< 250 OK
> RCPT TO:You <[email protected]>
< 250 Accepted
> DATA
< 354 Enter message, ending with "." on a line by itself
> From: Me <[email protected]>
> To: You <[email protected]>
> Subject: Testmail
>
> This is a test.
> .
< 250 OK id=1O2Sjq-0000c4-Qv
> QUIT
< 221 googlemail-smtp.l.google.com closing connection
Connection closed by foreign host.

Черт, прошло довольно много времени с тех пор, как я это сделал. Довольно много ошибок: -)

Ответ 3

Как многие из вас предложили, мы не можем различить, является ли протокол двоичным или текстовым, просто посмотрев на содержимое в сети

Afik

Двоичный протокол - Биты являются граничными. Порядок очень важен

Например, RTP

Первые два бита - версия Следующий бит - бит MarkUp

Текстовый протокол - разделители, специфичные для протокола Порядок полей не важен

Например, SIP

Еще одно - в двоичном протоколе мы можем разделить байт, т.е. Один бит может иметь конкретное индивидуальное значение; В то время как в текстовом протоколе минимально значимой единицей является BYTE. Вы не можете разделить байт.

Ответ 4

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

o быть более ясным, если у меня есть файл jpg, как это будет отправляться через двоичный протокол и как > через текстовый? в терминах бит/байтов, отправленных на провод, конечно.

вы должны прочитать это Base64

все комценты оценены, я пытаюсь понять суть вещей здесь.

Я думаю, что сущность сужения кодировки, сужает сложность и достижима мобильность, совместимость. Сложнее устраивать и соглашаться со многими уважать широкую кодировку (или широко распространенную). Латинский/латинский алфавит и арабские цифры известны во всем мире. (Есть, конечно, другие соображения, чтобы уменьшить код, но это основной)

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

Ответ 5

Примеры двоичных протоколов: RTP, TCP, IP.

Примеры текстовых протоколов: SMTP, HTTP, SIP.

Это должно позволить вам обобщить на разумное определение бинарных текстовых протоколов.

Подсказка: просто перейдите к разделам примера или диаграммам. Они служат для иллюстрации качающегося ответа Тайлера.

Ответ 6

Я случайно нашел этот старый вопрос и решил добавить свое мнение, по крайней мере, проверить его.

В большинстве ответов объясняется, как текстовые и бинарные протоколы отличаются от машинной точки зрения. С человеческой точки зрения, текстовый протокол является удобочитаемым человеком/редактируемым (человек может читать и писать пакеты без декодера/кодировщика). Это означает, по крайней мере, два преимущества: упрощенная отладка/поддержка реализации текстового протокола и возможность тестирования с помощью простых и универсальных инструментов, таких как telnet.

Еще одно небольшое преимущество: текстовые протоколы считаются более доверчивыми, потому что (я думаю) это невозможно или просто трудно использовать отверстие в реализации протокола для выполнения какого-либо вредоносного кода, например. путем использования переполнения буфера. Это небольшое преимущество, поскольку бинарные протоколы могут быть одинаковыми с помощью кодировки base64.

Есть также некоторые недостатки текстовых протоколов:

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

Попытка скомпилировать окончательную рекомендацию из этого:

Назначение протокола как текстового, когда:

• Это протокол управления, который можно рассматривать как последовательность команд или запросы/ответы ((интерактивные).С точки зрения реализации, он может быть реализован как конечный конечный автомат. В качестве примера рассмотрим потоковое мультимедиа: RTSP - протокол управления, использует конечный автомат и состоит из запросов/ответов - это текстовый протокол, когда RTP является двоичным протоколом, поскольку содержит в основном естественные двоичные данные, такие как мультимедийные потоки.
• Он предназначен для массового использования: многими людьми, реализациями или приложениями; поэтому очень важна упрощенная отладка/обслуживание.

.

Ответ 7

Как отправить файл изображения в SOAP: Нажмите здесь

Это показывает, что двоичные данные прикреплены как таковые [ATTACHMENT], и его ссылка сохраняется в сообщении SOAP.

Итак, протокол основан на тексте, а данные [Image] - это двоичное вложение, кодирование которого не имеет отношения

Таким образом, SOAP является текстовым протоколом из-за того, как мы указываем заголовки Soap, а не фактические данные, закодированные в нем.

Ответ 8

Я думаю, вы поняли это неправильно. Это не протокол, который определяет, как данные смотрят на "провод", но это тип данных, который определяет, какой протокол использовать для его передачи. Возьмем, к примеру, tcp-сокет, файл jpeg будет отправлен и получен с помощью двоичного протокола: "вызывают его двоичные данные (не читаемые человеком, байты, которые входят в диапазон ascii 32-126), но вы можете отправить /recv текстовый файл с оба протокола, и вы не заметите разницы.

Ответ 9

Текстовый протокол может быть понятным и обширным. Это самоочевидно, потому что сообщение включает имена полей только в самом сообщении. Вы не можете понять, какое значение означает в сообщении двоичного протокола, если вы не ссылаетесь на спецификацию протокола.

Это обширно означает, что HTTP как текстовый протокол просто делает простые правила, но вы можете расширить структуру данных, свободно добавляя новые заголовки или изменяя тип контента для транспортировки разных полезных нагрузок. А заголовки являются метаданными и имеют возможность согласования и автоматической адаптации.