двоичные протоколы В. текст Протоколов

Question

двоичные протоколы В. текст Протоколов

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

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

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

да ладно!

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

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

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

приветики!

9 63

text protocols binary-tree

9 ответов:

вот своего рода определение cop-out:

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

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

почти все протоколы, с которыми вы столкнетесь в реальной жизни, будут выглядеть так это:
> 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.
черт возьми, прошло довольно много времени с тех пор, как я сделал это. Довольно много ошибок там : -)

20

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

AFIK

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

например., RTP

первые два бита версия Следующий бит-это бит разметки

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

например., SIP

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

thnx

байт

4

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

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

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

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

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

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

3

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

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

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

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

3

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

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

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

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

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

двоичные протоколы потребляют меньше пропускной способности

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

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

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

он предназначен для массового использования: многими людьми, реализациями или приложениями; поэтому упрощенная отладка/обслуживание очень важны.

.

3

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

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

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

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

1

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

0

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

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

0

Tyler McHenry · Accepted Answer · 2010-04-15 15:30:30

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