protocolos binarios v. Protocolos de texto

Question

¿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 entre sí en términos de bits enviados por el cable?

aquí es lo que dice Wikipedia sobre los protocolos binarios:

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

vienen oh en!

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

al final del día si mira una cadena, ella misma es una matriz de bytes por lo que la distinción entre los 2 protocolos debe descansar en qué datos reales se envían por cable. en otras palabras, sobre cómo se codifica la información inicial (archivo jpg) antes de enviarse.

se comentan todos los comentarios, estoy tratando de llegar a la esencia de las cosas aquí.

saludos!

Answer 1

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 a estructuras de datos o alrededor de cadenas de texto. Déjame dar un ejemplo: HTTP. HTTP es un protocolo de texto, aunque cuando envía una imagen JPEG, simplemente envía los bytes sin formato, no una codificación de texto de ellos.

Pero lo que hace HTTP un protocolo de texto es que el intercambio de llegar el jpg tiene el siguiente aspecto:

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 este fácilmente podría haber sido empaquetado mucho más firmemente en una estructura que se vería (en C) algo así 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 campo no tendrían que ser transmitidos en absoluto, y donde, por ejemplo, el responseType en 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 ser comunicado como un flujo plano de líneas de texto (generalmente legibles por humanos), en lugar de como datos estructurados de muchos tipos diferentes.

Answer 2

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

Answer 3

ambos usos diferentes juego de caracteres, el texto uno, utilizar un juego de caracteres reducida, el binario incluye todo lo posible, no sólo "letras" y "números", (por eso Wikipedia dice "ser humano")

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

usted debe leer este Base64

ningún comentarios son apprecited, yo estoy tratando de llegar a la esencia de las cosas aquí.

Creo que la esencia para reducir el juego de caracteres, se está reduciendo la complejidad y la portabilidad, la compatibilidad. Es más difícil organizar y aceptar que muchos respeten un conjunto de caracteres amplio, (o uno más amplio). El alfabeto latino/romano y los números arábigos son mundialmente conocidos. (Por supuesto, existen otras consideraciones para reducir el código, pero esa es una principal)

Digamos en los protocolos binarios que el "contrato" entre las partes se trata de bits, el primer bit significa esto, el segundo que, etc. o incluso bytes (pero con la libertad de usar el juego de caracteres sin pensar en la portabilidad) por ejemplo en sistemas cerrados privados o (cerca de 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 un conjunto de situaciones, por ejemplo, ¿cómo se representará en una máquina al otro lado del mundo ?, así que aquí vienen los protocolos de texto donde el contrato será lo más estándar posible. He diseñado ambos y esos fueron los motivos, binarios para soluciones muy personalizadas y texto para sistemas abiertos y/o portátiles.

Answer 4

Ejemplos de protocolos binarios: RTP, TCP, IP.

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

Esto debería permitir generalizar a una definición razonable de protocolos binarios y de texto.

Sugerencia: simplemente salte a las secciones de ejemplo, o los diagramas. Sirven para ilustrar Tyler's rocking answer.

Answer 5

Aquí es una especie de definición de escabullirse:

lo sabrás cuando lo veas.

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 que los casos de esquina son completamente irrelevantes, porque simplemente no ocurren en la vida real.

casi todo los protocolos que se encontrará en la vida real, o bien tener este aspecto:

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

[imaginar una tonelada de basura otra no imprimible allí.Uno de los retos en la transmisión de la diferencia entre el texto y binario es que usted tiene que hacer el transporte en el 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 hacer esto en el punto .]

Simplemente no hay mucha ambigüedad allí.

Otra definición que a veces he oído es

un protocolo de texto es uno que puede depurar utilizando telnet

Tal vez estoy mostrando mi nerdiness aquí, pero tener realmente escrito y leer correos electrónicos a través de SMTP y POP3, leer artículos de usenet a través de NNTP y páginas web visitadas a través de HTTP usando telnet, sin más motivo que ver si realmente funcionaría.

En realidad, al escribir esto, yo un poco llamó 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. 

Joder, ha sido bastante tiempo desde que he hecho esto. Muy pocos errores en que hay :-)

Answer 6

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

AFIK

Protocolo binario - Los bits son límites orden es muy crítico

Por ejemplo, RTP

primeros dos bits son bits versión siguiente es poco marcado de

.

protocolo de texto - Los delimitadores específicos de protocolo orden de los campos no es importante

Por ejemplo, SIP

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

thnx

-Bytes

Answer 7

me encontré accidentalmente esta vieja pregunta y decidió añadir mi opinión, al menos para comprobarlo.

La mayoría de las respuestas explican cómo el texto y los protocolos binarios son diferentes del punto de vista de la máquina. Desde el punto de vista humano, un protocolo de texto es legible/editable por el ser humano (un ser humano puede leer y escribir paquetes sin decodificador/codificador). Esto significa al menos dos beneficios: la depuración/mantenimiento simplificado de la implementación del protocolo de texto y la posibilidad de realizar pruebas mediante herramientas simples y universales como telnet.

Una pequeña ventaja más: los protocolos de texto se consideran más confiables, porque (supongo) es imposible o simplemente es difícil usar un agujero en la implementación del protocolo para ejecutar algún código malicioso, p. explotando el desbordamiento del búfer. Es una pequeña ventaja porque los protocolos binarios pueden lograr lo mismo con la codificación base64.

allí son también algunas desventajas de los protocolos de texto:

• Texto aplicación protocolos suelen ser más difficalt para implementar que la binaria, debido analizador.
• protocolos binarios son menos ancho de banda que consume

Tratando de compilar algunas recomendación final de esta:

Desing un protocolo como un texto de uno cuando:

• Es un protocolo de control que se pueden tratada como una serie de comandos o solicitudes/respuestas ((interactivo). Desde el punto de vista de la implementación, puede implementarse como una máquina de estados finitos. Como ejemplo, considere la transmisión multimedia: RTSP - un protocolo de control, uso s máquina de estados y consiste en solicitudes/respuestas - es un protocolo de texto, cuando RTP es un protocolo binario porque transporta datos binarios casi naturales como flujos multimedia.
• Está destinado al uso masivo: por muchas personas, implementaciones o aplicaciones; así que la depuración/mantenimiento simplificado es muy importante.

.

Answer 8

How can we send an image file in SOAP: Click here

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

Por lo tanto, el protocolo está basado en texto y datos [Imagen] se adjunto binario cuya codificación no es relevante

Por lo tanto, SOAP es un protocolo de texto debido a la forma en que especificamos cabeceras de jabón y datos no reales codificados en ella.

Answer 9

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

Su extenso significado HTTP como protocolo de texto solo hace que las reglas sean simples, pero puede ampliar 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.