div - protocolos binarios v. protocolos de texto
title attribute anchor tag (9)
¿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?
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 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 observa una cadena, en sí misma es una matriz de bytes, por lo que la distinción entre los dos protocolos debe basarse en los datos reales que se envían por cable. en otras palabras, sobre cómo se codifica la información inicial (archivo jpg) antes de enviarse.
cualquier comentario está incluido, estoy tratando de llegar a la esencia de las cosas aquí.
saludos!
Accidentalmente encontré esta vieja pregunta y decidí agregar mi opinión, al menos para verificarla.
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.
Un pequeño beneficio más: los protocolos de texto se tratan con más confianza, 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, por ejemplo, explotando el desbordamiento del búfer. Es una pequeña ventaja porque los protocolos binarios pueden lograr lo mismo con 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 la binaria, debido al analizador sintáctico.
- Los protocolos binarios consumen menos ancho de banda
Tratando de compilar alguna recomendación final de esto:
Diseñando un protocolo como texto uno cuando:
- Es un protocolo de control que se puede tratar como una serie de comandos o solicitudes / respuestas ((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 datos binarios casi naturales como flujos multimedia.
- Está pensado para el uso masivo: por muchas personas, implementaciones o aplicaciones; así que la depuración / mantenimiento simplificado es muy importante.
.
Ambos usan diferentes juegos de caracteres, uno de texto, usan un juego de caracteres reducido, el binario incluye todo lo que puede, no solo "letras" y "números", (es por eso que Wikipedia dice "ser humano")
o 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.
deberías leer este Base64
cualquier comentario está incluido, 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 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, hay otras consideraciones para reducir el código, pero ese es uno 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 los bytes (pero con la libertad de usar el juego de caracteres sin pensar en la portabilidad) por ejemplo en 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á en una máquina al 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 esos fueron los motivos, binarios para soluciones muy personalizadas y texto para sistemas abiertos y / o portátiles.
Aquí hay una especie de definición de escape:
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 todos los protocolos que encontrarás 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
[Imagina una tonelada de otra basura no imprimible allí. Uno de los desafíos al transmitir la diferencia entre el texto y el binario es que tienes que hacer la transportació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
[Me inventé 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 nerdidad aquí, pero en realidad he escrito y leído correos electrónicos a través de SMTP y POP3, leo artículos de usenet a través de NNTP y vi páginas web a través de HTTP usando telnet , sin más motivo que ver si realmente funcionaría.
En realidad, mientras escribía esto, volví a sentir la fiebre:
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.
Maldición, ha pasado bastante tiempo desde que hice esto. Bastantes errores allí :-)
Como la mayoría de ustedes sugirió que no podemos diferenciar si el protocolo es Binario o texto simplemente mirando el contenido en el cable
AFIK
Protocolo binario: los bits son límite El orden es muy crítico
Ej., RTP
Los primeros dos 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
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 puedes dividir un byte.
thx
-Bytes
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 será enviado y recibido 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 usted no notaría la diferencia.
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 o de texto.
Sugerencia: solo salte a las secciones de ejemplo o los diagramas. Sirven para ilustrar la respuesta oscilante de Tyler .
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 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 muy fácilmente haber sido empaquetado mucho más estrechamente 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 transmitirse en absoluto, y donde, por ejemplo, el responseType de 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.
El protocolo de texto puede ser autoexplicativo 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.
Es extenso significa que HTTP como un protocolo de texto solo crea reglas 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.
¿Cómo podemos enviar un archivo de imagen en SOAP? Haga clic aquí
Esto muestra que los datos binarios están adjuntos como tales [ADJUNTO] y su referencia se guarda en el mensaje SOAP.
Entonces, el protocolo está basado en texto y los datos [Image] 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.