protokoły binarne a protokoły tekstowe

czy ktoś ma dobrą definicję tego, co to jest protokół binarny? a czym właściwie jest protokół tekstowy? jak to się ma do siebie pod względem liczby bitów przesłanych w sieci?

oto co Wikipedia mówi o protokołach binarnych:

Protokół binarny to protokół, który jest przeznaczony lub oczekiwany do odczytu przez maszynę, a nie przez człowieka ( http://en.wikipedia.org/wiki/Binary_protocol )

Och przestań!

aby było jasne, jeśli mam plik jpg, w jaki sposób zostałby on przesłany przez protokół binarny, a jak przez tekstowy? oczywiście pod względem bitów / bajtów przesyłanych przewodem.

pod koniec dnia, jeśli spojrzysz na łańcuch, sam jest tablicą bajtów, więc rozróżnienie między dwoma protokołami powinno opierać się na tym, jakie rzeczywiste dane są wysyłane w sieci. innymi słowy, w jaki sposób dane początkowe (plik jpg) są kodowane przed wysłaniem.

Protokół binarny a protokół tekstowy nie dotyczy tak naprawdę kodowania binarnych obiektów blob. Różnica polega naprawdę na tym, czy protokół jest zorientowany na struktury danych, czy na ciągi tekstowe. Podam przykład: HTTP. HTTP jest protokołem tekstowym, nawet jeśli wysyła obraz jpeg, po prostu wysyła nieprzetworzone bajty, a nie kodowanie tekstu.

Ale to, co sprawia, że ​​HTTP jest protokołem tekstowym, to fakt, że wymiana w celu pobrania pliku jpg wygląda następująco:

Żądanie:

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

Odpowiedź:

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>

Zauważ, że można to bardzo łatwo upakować znacznie ściślej w strukturę, która wyglądałaby (w C) jakoś

Żądanie:

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;
};

Odpowiedź:

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[];
};

Gdzie nazwy pól w ogóle nie musiałyby być przesyłane i gdzie, na przykład, responseTypew strukturze odpowiedzi jest liczba całkowita o wartości 200 zamiast trzech znaków „2” 0 „0”. Tym właśnie jest protokół tekstowy: zaprojektowany tak, aby był przekazywany jako płaski strumień (zwykle czytelnych dla człowieka) wierszy tekstu, a nie jako ustrukturyzowane dane wielu różnych typów.

Oto swoista definicja wykroczenia:

Dowiesz się, kiedy to zobaczysz.

Jest to jeden z tych przypadków, w których bardzo trudno jest znaleźć zwięzłą definicję obejmującą wszystkie przypadki narożne. Ale jest to również jeden z tych przypadków, w których przypadki narożne są całkowicie nieistotne, ponieważ po prostu nie występują w prawdziwym życiu.

Prawie wszystkie protokoły, które napotkasz w prawdziwym życiu, będą wyglądać tak:

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

[Wyobraź sobie mnóstwo innych niedrukowalnych bzdur. Jednym z wyzwań związanych z przekazaniem różnicy między tekstem a binarnymi jest to, że musisz przekazać tekst :-)]

Lub tak:

< 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

[Właśnie wymyśliłem to na miejscu.]

Po prostu nie ma tam zbyt wielu niejasności.

Inną definicją, którą czasami słyszałem, jest

protokół tekstowy to taki, który można debugować za pomocą telnet

Może ja pokazuję moje nerdiness tutaj, ale nie faktycznie napisany i czytać wiadomości e-mail za pośrednictwem protokołu SMTP i POP3, czytać artykuły usenet przez NNTP i przeglądać strony internetowe za pośrednictwem protokołu HTTP przy użyciu telnet, dla żadnego innego powodu niż żeby zobaczyć, czy to rzeczywiście dzieło.

Właściwie pisząc to, znowu złapałem gorączkę:

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.

Cholera, minęło sporo czasu, odkąd to zrobiłem. Sporo błędów tam :-)

Przykłady protokołów binarnych: RTP , TCP , IP .

Przykłady protokołów tekstowych: SMTP , HTTP , SIP .

Powinno to pozwolić na uogólnienie na rozsądną definicję protokołów binarnych i tekstowych.

Wskazówka: po prostu przejdź do przykładowych sekcji lub diagramów. Służą do zilustrowania kołyszącej odpowiedzi Tylera .

Jak większość z was sugerowała, nie możemy rozróżnić, czy protokół jest binarny, czy tekstowy, po prostu patrząc na zawartość w sieci

AFIK

Protokół binarny - bity to granica Kolejność jest bardzo ważna

Np. RTP

Pierwsze dwa bity to wersja. Następny bit to bit MarkUp

Protokół tekstu - ograniczniki specyficzne dla protokołu Kolejność pól nie jest ważna

Np. SIP

Co więcej, w protokole binarnym możemy podzielić bajt, tj. Pojedynczy bit może mieć określone indywidualne znaczenie; W protokole tekstowym minimalną znaczącą jednostką jest BYTE. Nie możesz podzielić bajtu.

Oba używają innego zestawu znaków, tekstowego, używają zredukowanego zestawu znaków, binarny zawiera wszystko, co może, nie tylko „litery” i „cyfry” (dlatego wikipedia mówi „istota ludzka”)

o będzie bardziej jasne, jeśli mam plik jpg, w jaki sposób zostałby on przesłany za pomocą protokołu binarnego i jak> poprzez protokół tekstowy? oczywiście pod względem bitów / bajtów przesyłanych przewodem.

powinieneś przeczytać ten Base64

wszelkie uwagi są mile widziane, staram się dotrzeć do istoty rzeczy.

Myślę, że istotą zawężenia zestawu znaków jest zawężenie złożoności i osiągnięcie przenośności, kompatybilności. Trudniej jest ułożyć i zgodzić się z wieloma, aby uszanować szeroki zestaw znaków (lub szeroki cokolwiek). Alfabet łaciński / łaciński i cyfry arabskie są znane na całym świecie. (Oczywiście istnieją inne kwestie związane z redukcją kodu, ale to jest główny)

Powiedzmy, że w protokołach binarnych "kontrakt" między częściami dotyczy bitów, pierwszy bit oznacza to, drugie tamto itd. Lub nawet bajty (ale z możliwością swobodnego używania zestawu znaków bez myślenia o przenośności), na przykład w zamkniętym systemie lub (blisko standardów sprzętowych), jednak jeśli projektujesz system otwarty, musisz wziąć pod uwagę, w jaki sposób twoje kody będą reprezentowane w szerokim zestawie sytuacji, na przykład jak będą reprezentowane w maszynie po drugiej stronie świata ?, więc oto protokoły tekstowe, w których umowa będzie tak standardowa, jak to tylko możliwe. Zaprojektowałem oba i to były powody, binarne dla bardzo niestandardowych rozwiązań oraz tekst dla systemów otwartych i / lub przenośnych.

Jak możemy wysłać plik obrazu w SOAP: Kliknij tutaj

Pokazuje to, że dane binarne są dołączone jako takie [ZAŁĄCZNIK], a ich odniesienie jest zapisywane w komunikacie SOAP.

Tak więc protokół jest oparty na tekście, a dane [Obraz] to załącznik binarny, którego kodowanie nie jest istotne

Tak więc SOAP jest protokołem tekstowym ze względu na sposób, w jaki określamy nagłówki Soap, a nie faktyczne zakodowane w nim dane.

Myślę, że źle to zrozumiałeś. To nie protokół określa, jak dane wyglądają na „przewodzie”, ale typ danych określa, którego protokołu należy użyć do ich transmisji. Weźmy na przykład gniazdo tcp, plik jpeg zostanie wysłany i odebrany za pomocą protokołu binarnego, ponieważ są to dane binarne (nieczytelne dla człowieka, bajty mieszczące się w zakresie 32-126 ascii), ale możesz wysłać / odzyskać plik tekstowy z oba protokoły i nie zauważysz różnicy.

Protokół tekstowy może być zrozumiały i obszerny. Jest to oczywiste, ponieważ wiadomość zawiera nazwy pól tylko w samej wiadomości. Nie możesz zrozumieć, która wartość oznacza w komunikacie protokołu binarnego, jeśli nie odniesiesz się do specyfikacji protokołu.

Jest obszerny, co oznacza, że ​​HTTP jako protokół tekstowy po prostu tworzy proste reguły, ale możesz rozszerzyć strukturę danych, swobodnie dodając nowe nagłówki lub zmieniając typ zawartości, aby transportować różne ładunki. Nagłówki są metadanymi i mają możliwość negocjacji i automatycznej adaptacji.