protocolos binarios versus protocolos de texto

94

¿Alguien tiene una buena definición de lo que es un protocolo binario? y ¿qué es un protocolo de texto en realidad? ¿Cómo se comparan estos entre sí en términos de bits enviados por cable?

esto es lo que dice Wikipedia sobre los protocolos binarios:

Un protocolo binario es un protocolo que se pretende o se espera que sea leído por una máquina en lugar de un ser humano ( http://en.wikipedia.org/wiki/Binary_protocol )

¡Oh vamos!

para ser más claro, si tengo un archivo jpg, ¿cómo se enviaría a través de un protocolo binario y cómo a través de uno de texto? en términos de bits / bytes enviados por cable, por supuesto.

al final del día, si observa una cadena, es en sí misma una matriz de bytes, por lo que la distinción entre los 2 protocolos debe basarse en los datos reales que se envían por el cable. en otras palabras, sobre cómo se codifican los datos iniciales (archivo jpg) antes de ser enviados.

text  binary  protocols 
— der_grosse
fuente
posible duplicado de protocolos binarios frente a texto
— dkinzer

Respuestas:

169

El protocolo binario versus el protocolo de texto no se trata realmente de cómo se codifican los blobs binarios. La diferencia es realmente si el protocolo está orientado en torno a estructuras de datos o cadenas de texto. Déjame darte un ejemplo: HTTP. HTTP es un protocolo de texto, aunque cuando envía una imagen jpeg, solo envía los bytes sin formato, no una codificación de texto de ellos.

Pero lo que hace que HTTP sea un protocolo de texto es que el intercambio para obtener el jpg se ve así:

Solicitud:

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

Respuesta:

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>

Tenga en cuenta que esto podría haberse empaquetado mucho más fácilmente en una estructura que se vería (en C) algo como

Solicitud:

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

Respuesta:

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

Donde los nombres de los campos no tendrían que transmitirse en absoluto y donde, por ejemplo, responseTypeen la estructura de respuesta es un int con el valor 200 en lugar de tres caracteres '2' '0' '0'. Eso es lo que es un protocolo basado en texto: uno que está diseñado para comunicarse como un flujo plano de líneas de texto (generalmente legibles por humanos), en lugar de como datos estructurados de muchos tipos diferentes.

— Tyler McHenry
fuente
19
+1 para la definición de 1 línea "La diferencia es realmente si el protocolo está orientado alrededor de estructuras de datos o alrededor de cadenas de texto".
— Frank Shearar
2
Tyler, gracias por la respuesta, una bastante profunda debería decir. escenario geek que reside en lo que todos estamos de acuerdo, en el recorrido del cable solo 0 y 1. Dime por favor si esto captura lo que dices. Digamos que quiero enviar el número 15 (dec) a través de la red (tiene 2 computadoras idénticas en la red, sin caos indio grande / pequeño, etc.) si voy a usar un protocolo binario (digamos que lo envío a través de un socket TCP), esto irá en el cable como 00001111 pero si voy a usar un protocolo de texto, será 00110001 (ASCII para el carácter 1) Y 00110101 (ASCII para char 5) ¿cierto o una mierda? :)
— der_grosse
1
Eso es correcto. La ventaja de hacerlo en forma de texto no solo es la legibilidad humana, sino también no tener que preocuparse por el endianismo si sus números tienen más de un byte de longitud.
— Tyler McHenry
1
No estoy de acuerdo con la definición de 1 línea ni con el ejemplo de enviar char 15, para ver las diferencias, como puse en mi respuesta, debes conocer todo el juego de caracteres y los delimitadores / protocolo, no puedes decir basado en un solo ejemplo de datos si el protocolo está basado en texto o en binario. Podría estar "mirando" el cable y ver un 65 (carácter 'A') y todavía no puede decir que es un protocolo basado en texto o binario. Ambos pueden tener la misma representación para un solo carácter o no, pero eso no es fundamental.
— Hernán Eche
25

Aquí hay una especie de definición de evasión:

Lo sabrá cuando lo vea.

Este es uno de esos casos en los que es muy difícil encontrar una definición concisa que cubra todos los casos de esquina. Pero también es uno de esos casos en los que los casos de la esquina son completamente irrelevantes, porque simplemente no ocurren en la vida real.

Casi todos los protocolos que encontrará en la vida real se verán así:

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

[Imagínese un montón de basura no imprimible allí. Uno de los desafíos para transmitir la diferencia entre texto y binario es que debe realizar la transmisión en texto :-)]

O así:

< 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

[Acabo de inventar esto en el acto.]

Simplemente no hay tanta ambigüedad allí.

Otra definición que he escuchado a veces es

un protocolo de texto es uno que puede depurar usando telnet

Tal vez esté mostrando mi nerd aquí, pero en realidad he escrito y leído correos electrónicos a través de SMTP y POP3, leído artículos de Usenet a través de NNTP y he visto páginas web a través de HTTP telnet, sin otra razón que ver si realmente funcionaría.

En realidad, mientras escribía esto, cogí la fiebre de nuevo:

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.

Maldita sea, ha pasado bastante tiempo desde que hice esto. Hay bastantes errores allí :-)

— Jörg W Mittag
fuente
7

Ejemplos de protocolos binarios: RTP , TCP , IP .

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

Esto debería permitirle generalizar a una definición razonable de protocolos binarios frente a protocolos de texto.

Sugerencia: simplemente pase a las secciones de ejemplo o los diagramas. Sirven para ilustrar la contundente respuesta de Tyler .

— Frank Shearar
fuente
1
Frank, gracias por los enlaces, pero cuando termine con las RFC será 2099 :) Quería algunas respuestas de personas que ya las han leído. Sin embargo, todavía estoy reflexionando sobre la respuesta de Tyler McHenry ...
— der_grosse
Debo decir, gran compartir.
— Iqra.
5

Como la mayoría de ustedes sugirió, no podemos diferenciar si el protocolo es binario o de texto simplemente mirando el contenido en el cable.

AFIK

Protocolo binario: los bits son límites El orden es muy crítico

Por ejemplo, RTP

Los primeros dos bits son la versión El siguiente bit es el bit MarkUp

Protocolo de texto: delimitadores específicos del protocolo El orden de los campos no es importante

Por ejemplo, SIP

Una más es que, en el protocolo binario, podemos dividir un byte, es decir, un solo bit puede tener un significado individual específico; Mientras que en un protocolo de texto, la unidad mínima significativa es BYTE. No puede dividir un byte.

— toyvenu
fuente
2

Ambos usan un conjunto de caracteres diferente, el de texto, usa un conjunto de caracteres reducido, el binario incluye todo lo que puede, no solo "letras" y "números" (es por eso que wikipedia dice "ser humano")

Para ser más claro, si tengo un archivo jpg, ¿cómo se enviaría a través de un protocolo binario y cómo> a través de uno de texto? en términos de bits / bytes enviados por cable, por supuesto.

deberías leer esto Base64

Cualquier comentario es apreciado, estoy tratando de llegar a la esencia de las cosas aquí.

Creo que la esencia para reducir el juego de caracteres es reducir la complejidad y alcanzar la portabilidad y la compatibilidad. Es más difícil organizar y estar de acuerdo con muchos para respetar un conjunto de caracteres amplio (o lo que sea) El alfabeto latino / romano y los números arábigos son mundialmente conocidos. (Por supuesto, hay otras consideraciones para reducir el código, pero esa es la principal)

Digamos que en los protocolos binarios el "contrato" entre las partes se trata de bits, el primer bit significa esto, el segundo eso, etc. o incluso bytes (pero con la libertad de usar el juego de caracteres sin pensar en la portabilidad) por ejemplo en un sistema cerrado privado o (cerca de los estándares de hardware), sin embargo, si diseña un sistema abierto, debe tener en cuenta cómo se representarán sus códigos en un amplio conjunto de situaciones, por ejemplo, ¿cómo se representarán en una máquina en el otro lado del mundo? aquí vienen los protocolos de texto donde el contrato será lo más estándar posible. He diseñado ambos y esas fueron las razones, binario para soluciones muy personalizadas y texto para sistemas abiertos y / o portátiles.

— Hernán Eche
fuente
Sé sobre base64 y lo que hace, y esto es exactamente lo que tenía en mente cuando publiqué la pregunta. base64 es bueno cuando quiero enviar algo en su representación ASCII (codificación), por lo que sería un protocolo de texto. técnicamente divide la entrada de bits en pares de 6, usa una tabla de búsqueda y así sucesivamente. ¿Alguien puede proporcionar una explicación similar de cómo funciona un procol binario? pregunta complementaria: ¿a qué nivel OSI podemos hablar de protocolos binarios y de texto y cuál es el significado exacto de estos mundos en esos niveles?
— der_grosse
1
Un ejemplo de binario son los protocolos de bajo nivel como la comunicación en serie simple ( en.wikipedia.org/wiki/Asynchronous_serial_communication ) o cómo se almacenan los datos en la memoria ( en.wikipedia.org/wiki/Data_structure_alignment ). Acerca de OSI ... bueno, porque los protocolos de texto y binarios se utilizan para representar datos (no solo para la comunicación), no necesitan estar en ningún nivel de OSI, dicho eso, puedo decir que la capa 1,2,3,4 tiene "binario protocolo "y" protocolo de texto "pueden estar en 5,6,7.
— Hernán Eche
1

¿Cómo podemos enviar un archivo de imagen en SOAP? Haga clic aquí

Esto muestra que los datos binarios se adjuntan como tales [ADJUNTO] y su referencia se guarda en el mensaje SOAP.

Por lo tanto, el protocolo se basa en texto y los datos [Imagen] son ​​archivos adjuntos binarios cuya codificación no es relevante

Por lo tanto, SOAP es un protocolo de texto debido a la forma en que especificamos los encabezados de Soap y no los datos reales codificados en él.

— Karan Kaw
fuente
0

Creo que te equivocaste. No es el protocolo lo que determina cómo se ven los datos en el "cable", pero es el tipo de datos el que determina qué protocolo usar para transmitirlos. Tome tcp socket, por ejemplo, un archivo jpeg se enviará y recibirá con un protocolo binario porque son datos binarios (no legibles por humanos, bytes que van entre el rango 32-126 ascii), pero puede enviar / recibir un archivo de texto con ambos protocolos y no notaría la diferencia.

— Simone Margaritelli
fuente
No, no creo que me haya equivocado. Todavía estoy buscando una (buena) definición de QUÉ ES un protocolo binario. el ejemplo con el jpeg fue para aclarar mi pregunta y nada más, no lo convierta en el centro de la pregunta. Debo decir que el protocolo determina cómo se ven los datos cuando se transmiten por el cable, de lo contrario, ¿por qué es un protocolo?
— der_grosse
Te di una definición precisa, solo tienes que leer con atención. "Un protocolo binario administra los bytes que se encuentran entre el rango 32-126 ascii, también llamados caracteres no imprimibles"
— Simone Margaritelli
los protocolos de texto los manejan también dividiéndolos en otros más pequeños que se ajustarán a la tabla ASCII. y así. entonces, en el mejor de los casos, su definición es vaga. pero gracias por el aporte.
— der_grosse
0

El protocolo de texto puede explicarse por sí mismo y ser extenso. Se explica por sí mismo porque el mensaje incluye los nombres de los campos solo en el mensaje. No puede comprender qué significa el valor en el mensaje del protocolo binario si no se refiere a la especificación del protocolo.

Su extenso significa que HTTP como protocolo de texto solo crea reglas simples, pero puede extender la estructura de datos agregando libremente nuevos encabezados o cambiando el tipo de contenido para transportar diferentes cargas útiles. Y los encabezados son los metadatos y tienen la capacidad de negociación y adaptación automática.

— Chao
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.