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

Question

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

вот что говорит Википедия о бинарных протоколах:

Бинарный протокол - это протокол, который предназначен или должен быть прочитан машиной, а не человеком (http://en.wikipedia.org/wiki/Binary_protocol)

о, давай!

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

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

Answer 1

Двоичный протокол по сравнению с текстовым протоколом на самом деле не о том, как кодируются двоичные двоичные объекты. Разница заключается в том, ориентирован ли протокол на структуры данных или текстовые строки. Позвольте мне привести пример: HTTP. HTTP - это текстовый протокол, хотя при отправке изображения в формате JPEG он просто отправляет необработанные байты, а не их текстовую кодировку.

Но что делает HTTP текстовым протоколом, так это то, что обмен на get 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' , Вот что такое текстовый протокол: протокол, предназначенный для передачи в виде плоского потока (обычно удобочитаемого) строк текста, а не в виде структурированных данных разных типов.

Answer 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 <Me@Example.Com>
< 503 sender not yet given
> SENDER:Me <Me@Example.Com>
< 500 unrecognized command
> RCPT FROM:Me <Me@Example.Com>
< 500 unrecognized command
> FROM:Me <Me@Example.Com>
< 500-unrecognized command
> HELP
< 214-Commands supported:
< 214 AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP ETRN
> MAIL FROM:Me <Me@Example.Com>
< 250 OK
> RCPT TO:You <You@SomewhereElse.Example.Com>
< 250 Accepted
> DATA
< 354 Enter message, ending with "." on a line by itself
> From: Me <Me@Example.Com>
> To: You <You@SomewhereElse.Example.Com>
> 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.

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

Answer 3

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

Afik

Двоичный протокол - Биты граничные Заказ очень критичен

Например, RTP

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

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

Например, SIP

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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

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

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

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

.

Answer 6

Оба используют разные наборы символов, текстовый, использует сокращенный набор символов, двоичный файл включает в себя все, что может, не только «буквы» и «цифры» (вот почему в Википедии написано «человек»)

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

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

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

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

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

Answer 7

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

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

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

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

Answer 8

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

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

Answer 9

Я думаю, вы ошиблись. Не протокол определяет, как данные выглядят на «проводе», а тип данных определяет, какой протокол использовать для его передачи. Возьмем, к примеру, сокет tcp, файл jpeg будет отправлен и получен с двоичным протоколом, потому что это двоичные данные (не читаемые человеком, байты, которые входят в диапазон 32-126 ASCII), но вы можете отправить / получить текстовый файл с оба протокола, и вы не заметите разницу.