двійкові протоколи v. текстові протоколи

хтось має гарне визначення того, що таке двійковий протокол? а що таке текстовий протокол насправді? як вони порівнюються між собою з точки зору бітів, відправлених по дроту?

ось що говорить wikipedia про двійкові протоколи:

Двійковий протокол - це протокол, який призначений або очікується прочитати машиною, а не людиною ( http://en.wikipedia.org/wiki/Binary_protocol )

о, давай!

щоб бути більш зрозумілим, якщо у мене є файл jpg, як би він надсилався через двійковий протокол, а як через текстовий? з точки зору бітів / байтів, що надсилаються по дроту, звичайно.

врешті-решт, якщо ви подивитесь на рядок, він сам є масивом байтів, тому різниця між 2 протоколами повинна спиратися на те, які фактичні дані надсилаються по дроту. іншими словами, про те, як кодуються початкові дані (файл jpg) перед відправкою.

Бінарний протокол у порівнянні з текстовим протоколом насправді не стосується того, як кодуються двійкові краплі. Різниця насправді полягає в тому, орієнтований протокол навколо структур даних або навколо текстових рядків. Наведу приклад: 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>

Зверніть увагу, що це могло б бути набагато щільніше упаковано в структуру, яка виглядала б (у С) приблизно так

Запит:

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'. Ось що являє собою текстовий протокол: той, який призначений для передачі як рівний потік (як правило, читається людиною) рядків тексту, а не як структуровані дані багатьох різних типів.

Ось своєрідне визначення:

Ви це дізнаєтесь, коли побачите.

Це один з тих випадків, коли дуже важко знайти стисле визначення, яке охоплює всі кутові справи. Але це також один із тих випадків, коли кутові випадки абсолютно неактуальні, оскільки вони просто не трапляються в реальному житті.

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

> 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

Може бути , я показую свою nerdiness тут, але я б на самому справі написано і читати електронну пошту через 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.

Блін, вже давно я не робив цього. Досить багато помилок :-)

Приклади двійкових протоколів: RTP , TCP , IP .

Приклади текстових протоколів: SMTP , HTTP , SIP .

Це повинно дозволити вам узагальнити розумне визначення бінарних та текстових протоколів.

Підказка: просто перейдіть до прикладів розділів або діаграм. Вони служать для ілюстрації хисткої відповіді Тайлера .

Як більшість із вас припустили, ми не можемо розрізнити, чи є протокол двійковим або текстовим, просто переглядаючи вміст дроту

AFIK

Бінарний протокол - біти є граничними Порядок дуже важливий

Наприклад, RTP

Перші два біти є версією Наступний біт - це біт MarkUp

Текстовий протокол - Розділювачі, характерні для протоколу Порядок полів не важливий

Наприклад, SIP

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

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

o бути більш зрозумілим, якщо у мене є файл jpg, як би він надсилався через двійковий протокол, а як> через текстовий? з точки зору бітів / байтів, що надсилаються по дроту, звичайно.

вам слід прочитати цей Base64

будь-які коментатори цінуються, я намагаюся дійти до суті речей тут.

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

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

Як ми можемо надіслати файл зображення в SOAP: Клацніть тут

Це показує, що двійкові дані приєднуються як такі [ДОПОМОГА], а їх посилання зберігаються у повідомленні SOAP.

Отже, протокол базується на тексті, а дані [Image] - це двійкове вкладення, кодування якого не має значення

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

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

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

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