protocolos binarios v. protocolos de texto

Aquí hay una especie de definición de cop-out:

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 abarque todos los casos de esquina. Pero también es uno de esos casos donde 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

[Imagine una tonelada de otros basura no imprimible. Uno de los desafíos en la transmisión de la diferencia entre texto y binario es que usted tiene que hacer 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 mucha 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 estoy mostrando mi nerd aquí, pero Yo tengo realmente escribió y leyó correos electrónicos a través de SMTP y POP3, leyó artículos de usenet a través de NNTP y vio páginas web a través de HTTP usando telnet, sin otra razón que para 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 <[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.

Maldita sea, ha pasado bastante tiempo desde que he hecho esto. Bastantes errores allí: -)

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

AFIK

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

Eg., RTP

Los dos primeros bits son versión El siguiente bit es Markup bit

Protocolo de texto-Delimitadores específicos del protocolo El orden de los campos no es importante

Eg., SIP

Uno más es en binario, protocolo, 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 significativa mínima es BYTE. No puedes dividir un byte.

Thnx

- Bytes

Ambos usan un conjunto de caracteres diferente, el texto, usa un conjunto de caracteres reducido, el binario incluye todo lo que puede, no solo "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 a través de un protocolo binario y cómo >a través de uno de texto? en términos de bits / bytes enviados en el cable, por supuesto.

Deberías leer esto Base64

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

Creo que la esencia para reducir el conjunto de caracteres, es reducir la complejidad, y alcanzar la portabilidad, la compatibilidad. Es más difícil organizar y estar de acuerdo con muchos para respetar un conjunto de caracteres amplio, (o un amplio 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 una principal)

Digamos que en los protocolos binarios el "contrato" entre las partes es sobre bits, primer bit significa esto, segundo, etc.. o incluso bytes (pero con la libertad de usar el conjunto de caracteres sin pensar en la portabilidad), por ejemplo, en un sistema cerrado privado 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 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 esas fueron las razones, binario para soluciones muy personalizadas y texto para sistemas abiertos o / y portátiles.

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 vs de texto.

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

Accidentalmente encontré esta vieja pregunta y decidí agregar mi opinión, al menos para comprobarla.

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

Un pequeño beneficio más: los protocolos de texto son tratados como más confiables, porque (supongo) es imposible o simplemente difícil usar un agujero en la implementación del protocolo para ejecutar algún código malicioso, por ejemplo, explotando el desbordamiento de búfer. Es un pequeño beneficio porque los protocolos binarios pueden lograr lo mismo mediante la codificación base64.

También hay algunas desventajas de los protocolos de texto:

• La implementación de protocolos de texto suele ser más difícil de implementar que binario, por el analizador.
• Los protocolos binarios consumen menos ancho de banda

Tratando de compilar alguna recomendación final de esto:

Diseñar un protocolo como texto cuando:

• Es un protocolo de control que puede ser tratado como una serie de comandos o requests / replies ((interactivo). Desde el punto de vista de la implementación, se puede implementar como una máquina de estados finitos. Como ejemplo, considere la transmisión multimedia: RTSP-un protocolo de control, utiliza la máquina de estado y consiste en solicitudes / respuestas - es un protocolo de texto, cuando RTP es un protocolo binario porque lleva principalmente datos binarios naturales como flujos multimedia.
• Está diseñado para uso masivo: por muchas personas, implementaciones o aplicaciones; por lo que la depuración/mantenimiento simplificado es muy importante.

.

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.

Entonces, el protocolo está basado en texto y los datos[Imagen] son 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 Soap y no los datos reales codificados en él.

Creo que te equivocaste. No es el protocolo el 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 el socket tcp por ejemplo, un archivo jpeg será enviado y recibido con un protocolo binario porque son datos binarios (no legibles por humanos, bytes que van entre el rango ascii de 32-126), pero puede enviar / recv un archivo de texto con ambos protocolos y no notaría la diferencia.

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 propio mensaje. No puede entender qué valor significa en el mensaje de protocolo binario si no se refiere a la especificación del protocolo.

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