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


94

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

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

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

о, давай!

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

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


Ответы:


169

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


19
+1 за однострочное определение «Разница действительно в том, ориентирован ли протокол на структуры данных или на текстовые строки».
Фрэнк Шеарар,

2
Тайлер, спасибо за ответ, я бы сказал, довольно глубокий. компьютерный сценарий, который основан на том, с чем мы все согласны, по проводам перемещаются только нули и единицы. скажите, пожалуйста, отражает ли это то, что вы думаете. скажем, я хочу отправить номер 15 (dec) по сети (у вас есть 2 идентичных компьютера в сети, никакого большого / маленького индийского хаоса и т. д.). если я собираюсь использовать двоичный протокол (скажем, я отправляю его через сокет TCP), он будет передаваться как 00001111, но если я собираюсь использовать текстовый протокол, он будет идти как 00110001 (ASCII для char 1) И 00110101 (ASCII для символа 5) правда или хрень? :)
der_grosse

1
Это правильно. Преимущество использования текстового способа заключается не только в удобочитаемости человеком, но и в отсутствии необходимости беспокоиться о порядке байтов, если ваши числа имеют длину более одного байта.
Тайлер МакГенри,

1
Я не согласен ни с однострочным определением, ни с примером отправки char 15, чтобы увидеть различия, как я сказал в своем ответе, вы должны знать всю кодировку и разделители / протокол, вы не можете сказать на основе одного примера данных, если протокол основан на тексте или двоичном коде. Вы можете «смотреть» на кабель и видеть 65 (символ «A»), но вы все равно не можете сказать, что это текстовый или бинарный протокол. Оба могут иметь одинаковое представление для одного символа или нет, но это не принципиально.
Эрнан Эче

25

Вот определение вроде отговорки:

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

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

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

> 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.

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


7

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

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

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

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


1
Фрэнк, спасибо за ссылки, но когда я закончу с RFC, будет 2099 :) Я хотел получить ответы от людей, которые их уже читали. Я все еще обдумываю ответ Тайлера МакГенри ...
der_grosse

Должен сказать, отличный обмен.
Икра.

5

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

AFIK

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

Например, RTP

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

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

Например, SIP

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


2

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

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

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

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

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

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


Я знаю о base64 и о том, что он делает, и это именно то, что я имел в виду, когда отправлял вопрос. base64 хорош, когда я хочу отправить что-либо в его представлении (кодировке) ASCII, чтобы это был текстовый протокол. технически он разбивает битовый ввод на пары по 6, использует таблицу поиска и так далее. может ли кто-нибудь дать подобное объяснение того, как работает двоичный протокол? дополнительный вопрос: на каком уровне OSI мы можем говорить о двоичных и текстовых протоколах и каково точное значение этих миров на этих уровнях?
der_grosse

1
Примером двоичного кода являются протоколы низкого уровня, такие как простая последовательная связь ( en.wikipedia.org/wiki/Asynchronous_serial_communication ) или способ хранения данных в памяти ( en.wikipedia.org/wiki/Data_structure_alignment ). Что касается OSI ... ну, потому что текстовые и двоичные протоколы используются для представления данных (не только для связи), они не должны быть на любом уровне OSI, сказал, что я могу сказать, что уровни 1,2,3,4 имеют "двоичный протокол », а« текстовый протокол »может быть на 5,6,7.
Эрнан Эче

1

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

Это показывает, что двоичные данные прикреплены как таковые [ПРИЛОЖЕНИЕ], а их ссылка сохраняется в сообщении SOAP.

Итак, протокол основан на тексте, а данные [Изображение] представляют собой двоичное вложение, кодировка которого не имеет значения.

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


0

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


нет, не думаю, что я ошибся. Я все еще ищу (хорошее) определение, ЧТО ТАКОЕ бинарный протокол. пример с jpeg должен был прояснить мой вопрос и ничего больше, не делать его центром вопроса. Я должен сказать, что протокол определяет, как данные выглядят при передаче по проводу, иначе почему это протокол ??
der_grosse

Я дал вам точное определение, вы просто должны внимательно прочитать. «Бинарный протокол управляет байтами, которые входят в диапазон 32–126 ascii, также называемых непечатаемыми символами»
Симоне Маргарителли

текстовые протоколы обрабатывают их также, разделяя их на более мелкие, которые соответствуют таблице ASCII. и так далее. так что в лучшем случае ваше определение расплывчато. но спасибо за вклад.
der_grosse

0

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.