protocolos binários v. protocolos de texto

alguém tem uma boa definição do que é um protocolo binário? e o que é um protocolo de texto na verdade? como eles se comparam entre si em termos de bits enviados na transmissão?

aqui está o que a wikipedia diz sobre protocolos binários:

Um protocolo binário é um protocolo que se destina ou se espera que seja lido por uma máquina em vez de por um ser humano ( http://en.wikipedia.org/wiki/Binary_protocol )

Oh vamos lá!

para ser mais claro, se eu tiver um arquivo jpg como ele seria enviado através de um protocolo binário e como através de um texto? em termos de bits / bytes enviados no fio, é claro.

no final do dia, se você olhar para uma string, ela é um array de bytes, então a distinção entre os 2 protocolos deve estar em quais dados reais estão sendo enviados na transmissão. em outras palavras, em como os dados iniciais (arquivo jpg) são codificados antes de serem enviados.

O protocolo binário versus protocolo de texto não trata realmente de como os blobs binários são codificados. A diferença é realmente se o protocolo é orientado em torno de estruturas de dados ou de strings de texto. Deixe-me dar um exemplo: HTTP. HTTP é um protocolo de texto, embora, ao enviar uma imagem jpeg, ele apenas envie os bytes brutos, não uma codificação de texto deles.

Mas o que torna o HTTP um protocolo de texto é que a troca para obter o jpg se parece com isto:

Solicitação:

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

Resposta:

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>

Observe que isso poderia facilmente ter sido compactado de forma muito mais compacta em uma estrutura que se pareceria (em C) com algo como

Solicitação:

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

Resposta:

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

Onde os nomes de campo não precisariam ser transmitidos de forma alguma e onde, por exemplo, o responseTypena estrutura de resposta é um int com o valor 200 em vez de três caracteres '2' '0' '0'. Isso é o que um protocolo baseado em texto é: aquele que é projetado para ser comunicado como um fluxo plano de linhas de texto (geralmente legíveis), em vez de dados estruturados de muitos tipos diferentes.

Aqui está uma espécie de definição de fuga:

Você saberá quando vir.

Este é um daqueles casos em que é muito difícil encontrar uma definição concisa que abranja todos os casos extremos. Mas também é um daqueles casos em que os casos secundários são completamente irrelevantes, porque simplesmente não ocorrem na vida real.

Quase todos os protocolos que você encontrará na vida real serão semelhantes a este:

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

[Imagine uma tonelada de outras porcarias não imprimíveis ali. Um dos desafios em transmitir a diferença entre texto e binário é que você tem que fazer a transmissão em texto :-)]

Ou assim:

< 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

[Acabei de inventar isso na hora.]

Simplesmente não há muita ambigüidade aí.

Outra definição que tenho ouvido algumas vezes é

um protocolo de texto é aquele que você pode depurar usando telnet

Talvez eu esteja mostrando minha nerdice aqui, mas na verdade eu tenho escrito e lido e-mails via SMTP e POP3, lido artigos da Usenet via NNTP e visto páginas da web via HTTP usando telnet, por nenhuma outra razão a não ser para ver se realmente funcionaria.

Na verdade, enquanto escrevia isso, meio que peguei a febre novamente:

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.

Droga, já faz um bom tempo que não faço isso. Alguns erros aí :-)

Exemplos de protocolos binários: RTP , TCP , IP .

Exemplos de protocolos de texto: SMTP , HTTP , SIP .

Isso deve permitir que você generalize para uma definição razoável de protocolos binários versus de texto.

Dica: basta pular para as seções de exemplo ou os diagramas. Eles servem para ilustrar a resposta de balanço de Tyler .

Como muitos de vocês sugeriram, não podemos diferenciar se o protocolo é binário ou texto simplesmente olhando para o conteúdo na transmissão

AFIK

Protocolo binário - Bits são limites A ordem é muito crítica

Por exemplo, RTP

Os primeiros dois bits são a versão O próximo bit é o bit de marcação

Protocolo de texto - Delimitadores específicos para protocolo A ordem dos campos não é importante

Por exemplo, SIP

Outra é, no protocolo binário, podemos dividir um byte, ou seja, um único bit pode ter um significado individual específico; Enquanto em um protocolo de texto, a unidade mínima significativa é BYTE. Você não pode dividir um byte.

Ambos usam conjuntos de caracteres diferentes, o texto um, usa um conjunto de caracteres reduzido, o binário inclui tudo o que pode, não apenas "letras" e "números", (é por isso que a wikipedia diz "ser humano")

Para ser mais claro, se eu tiver um arquivo jpg como ele seria enviado através de um protocolo binário e como> através de um texto? em termos de bits / bytes enviados no fio, é claro.

você deve ler este Base64

quaisquer comentários são apreciados, estou tentando chegar à essência das coisas aqui.

Acho que a essência para estreitar o conjunto de caracteres é estreitar a complexidade e alcançar portabilidade, compatibilidade. É mais difícil combinar e concordar com muitos para respeitar um conjunto de caracteres Wide (ou qualquer outro). O alfabeto latino / romano e os algarismos arábicos são conhecidos mundialmente. (Existem, é claro, outras considerações para reduzir o código, mas essa é a principal)

Digamos que em protocolos binários o "contrato" entre as partes seja sobre bits, primeiro bit significa isso, segundo aquele, etc. ou mesmo bytes (mas com a liberdade de usar o conjunto de caracteres sem pensar em portabilidade) por exemplo em sistema fechado privado ou (próximo aos padrões de hardware), no entanto, se você projetar um sistema aberto, terá que levar em consideração como seus códigos serão representados em um amplo conjunto de situações, por exemplo, como serão representados em uma máquina do outro lado do mundo? aqui vêm os protocolos de texto onde o contrato será o mais normal possível. Eu projetei os dois motivos, binários para soluções muito customizadas e texto para sistemas abertos e / ou portáteis.

Como podemos enviar um arquivo de imagem em SOAP: Clique aqui

Isso mostra que os dados binários são anexados como tal [ANEXO] e sua referência é salva na mensagem SOAP.

Portanto, o protocolo é baseado em texto e os dados [Imagem] são anexos binários cuja codificação não é relevante

Portanto, o SOAP é um protocolo de texto devido à maneira como especificamos os cabeçalhos do Soap e não os dados reais codificados nele.

Eu acho que você entendeu errado. Não é o protocolo que determina como os dados aparecem no "fio", mas é o tipo de dados que determina qual protocolo usar para transmiti-los. Pegue o soquete tcp por exemplo, um arquivo jpeg será enviado e recebido com um protocolo binário porque seus dados binários (não legíveis por humanos, bytes que vão entre o intervalo 32-126 ASCII), mas você pode enviar / receber um arquivo de texto com ambos os protocolos e você não notaria a diferença.

O protocolo de texto pode ser autoexplicativo e extenso. É autoexplicativo porque a mensagem inclui os nomes dos campos apenas na própria mensagem. Você não pode entender qual valor significa na mensagem do protocolo binário se não consultar a especificação do protocolo.

É extenso significa que HTTP como um protocolo de texto apenas cria regras simples, mas você pode estender a estrutura de dados adicionando livremente novos cabeçalhos ou alterando o tipo de conteúdo para transportar diferentes cargas úteis. E os cabeçalhos são os metadados e têm a capacidade de negociação e adaptação automática.