2010-03-02 22 views
19

Me pregunto cuáles son las diferencias entre los protocolos binarios y basados ​​en texto. He leído que los protocolos binarios son más compactos/más rápidos de procesar. ¿Cómo funciona eso? ¿Ya que tienes que enviar la misma cantidad de datos? ¿No?binario vs protocolos de texto

E.g ¿cómo se diferenciaría la cadena "hola" en tamaño en formato binario?

gracias

+2

Una pregunta más interesante sería _cuando_ elegir un protocolo binario o basado en texto, es decir, cuáles son sus ventajas (des) generales. El enlace en la respuesta de Max E. es útil aquí. –

+0

Esa es una pregunta más interesante cuando ya sabes la diferencia entre un protocolo binario y de texto, pero hay personas como yo que todavía tienen que aprender que :) –

+0

Posible duplicado de [¿Están los protocolos binarios muertos?] (Http: // stackoverflow .com/questions/2525188/are-binary-protocols-dead) –

Respuesta

17

Si todo lo que hace es transmitir texto, entonces sí, la diferencia entre los dos no es muy significativa. Pero considere tratar de transmitir cosas como:

  • Números: ¿utiliza una cadena de caracteres de un número o el binario? Especialmente para números grandes, el binario será más compacto.
  • Estructuras de datos: ¿cómo denota el comienzo y el final de un campo en un protocolo de texto? A veces, un protocolo binario con campos de longitud fija es más compacto.
2

la cadena "Hola" en sí no sería diferir en tamaño. La diferencia de tamaño/rendimiento se encuentra en la información adicional que introduce la serialización (la serialización es la forma en que el programa representa los datos que se transferirán para que pueda reconstruirse una vez que llegue al otro extremo del conducto).

Por ejemplo, cuando la serialización de los siguientes en .NET utilizando XML (uno de los métodos de serialización de texto):

string helloWorld = "Hello World!"; 

Es posible conseguir algo como (sé que esto no es exacto):

<helloWorld type="String">Hello World!</helloWorld> 

Considerando que la serialización binaria sería capaz de representar los datos de forma nativa en binario sin todas las marcas adicionales.

0

Si utiliza ASN.1 y BER para enviar "hola" en un mensaje de protocolo de esta manera:

ProtocolMessage ::= String 
; 

continuación, 1 byte tarda en codificar su octer identificador, 1 byte tarda en codificar la longitud y La codificación UTF-8 de "hello" es otros 5 bytes. Entonces el mensaje de resultado es 7 bytes.

2

protocolos binarios son mejores si está utilizando bits/bytes

de control es decir, en lugar de enviar msg: Hola en binario que puede ser 0x01 seguido de tu mensaje (suponiendo 0x01 es un byte de control que representa msg)

Así, ya en el protocolo de texto que envíe msg: hola \ 0 ... se trata de 10 bytes donde como en protocolo binario sería 0x01Hello \ 0 ... se trata de 7 bytes

Y otro ejemplo , suponga que desea enviar un número, digamos 255, en texto sus 3 bytes donde como en binario es 1 byte, es decir 0xFF

+0

Sería más común que 4 bytes brutos (0x0000_00FF) admitieran enteros más grandes, y generalmente debe contar el delimitador en los protocolos de texto, dando al menos 4 bytes allí también ("255" + 1). –

+0

@Roger Pate: El punto es que los protocolos binarios tienen * potencialmente * una entropía más alta en comparación con los protocolos textuales. Si supiera que el número está entre 1 y 255, ¿por qué usaría un número entero para codificarlo? También puedo darle la vuelta a su ejemplo: si realmente se necesitan números grandes (por ejemplo, números enteros de 1 a 4.294.967.295), cualquier número superior a 999 se codifica con mayor eficiencia con 32 bits fijos en lugar de 4 bytes. – Caffeine

+0

@Caffeine: como se muestra, estoy usando "byte" como "8 bits", entonces 32 bits es idéntico a 4 bytes. –

-4

No diría que los formatos binarios son más rápidos de procesar. Si echas un vistazo al formato de texto CSV o de campo fijo, todavía se puede procesar rápidamente.

Yo diría que todo depende de quién es el consumidor.Si el ser humano está al final (como HTTP o RSS), entonces no hay necesidad de compactar de algún modo los datos, excepto tal vez de comprimirlos.

Los protocolos binarios necesitan analizadores/conversores, difíciles de extender y mantener la compatibilidad con versiones anteriores. Cuanto más alto va en la pila de protocolos, más protocolos orientados a los humanos son (TCP es binario, ya que los enrutadores deben procesar los paquetes a gran velocidad, pero XML es más amigable para los humanos).

Creo que las variaciones de tamaño hoy no importan mucho. Para su ejemplo, hello tomará la misma cantidad en formato binario que en formato de texto, porque el formato de texto también es "binario" para la computadora, solo importa la forma en que interpretamos los datos.

+7

-1 Los formatos binarios pueden ser mucho más rápidos de procesar porque pueden coincidir mucho mejor con la representación de la máquina. HTTP se utiliza para la comunicación de computadora a computadora, así como para computadora a máquina. Los protocolos binarios (pueden) tienen menos necesidad de analizadores/convertidores que los protocolos de texto. Cuanto más alto va en la pila de protocolos, más ** abstractos son los protocolos, no orientados a los humanos. Y el binario se puede considerar como orientado a los humanos siempre que tengas un buen lector (qué decir de GIFF o JPG). La variación de tamaño puede importar muchísimo, piense en dispositivos móviles y en la web móvil. – MarkJ

+5

esto está mal en muchos niveles, ni siquiera es divertido –

1

Debe tener claro qué parte del protocolo y qué parte de los datos. Los protocolos de texto pueden enviar datos binarios y los protocolos binarios pueden enviar datos de texto.

El protocolo es la parte del mensaje que dice "Hola, ¿me puedo conectar? Tengo algunos datos, ¿dónde debería ponerlo ?, ¿Me han respondido? ¡Muy bien! ¡Gracias, adiós!"

Cada bit de la conversión es (probablemente) mucho más pequeña en un protocolo binario, Tomar HTTP, por ejemplo (que se basa el texto):

si tuviera un estándar de codificación apuesto a que podría llegar a la secuencia de caracteres más pequeños que los 4 bytes necesarios para la palabra 'PUSH'

+2

Por otro lado, 3 bytes más pequeños no es "mucho más pequeño". Sí, puede sumar, pero a veces las personas se entusiasman con el 75% de ahorro potencial y no buscan más. (Y para el registro, he sido culpable de esto bastantes veces). –

10

Los protocolos de texto son mejores en términos de legibilidad, facilidad de reimplementación y facilidad de depuración. Los protocolos binarios son más compactos.

Sin embargo, puede comprimir el texto con una biblioteca como lzo o Zlib, y esto es casi tan compacta como binarios (con muy poco impacto en el rendimiento de compresión/descompresión.)

Usted puede leer más información sobre el asunto aquí:
http://www.faqs.org/docs/artu/ch05s01.html

+2

También puede comprimir datos binarios. Transmitir números como texto comprimido es mucho más lento que los números puros. – bokan

Cuestiones relacionadas