unitywebrequest - ¿Por qué no enviamos binarios en lugar de texto en http?

unitywebrequest get json (8)

Parece que el binario sería más compacto y se puede deserializar de forma estándar, ¿por qué se usa el texto en su lugar? Parece ineficaz y los marcos web se ven obligados a hacer nada más que atormentarse con cuerdas. ¿Por qué no hay un estándar binario? La web sería mucho más rápida y los navegadores podrían cargar páginas binarias muy rápido.

Si tuviera que iniciar un protocolo binario (protocolo hiperbinario HBP), ¿qué tipo de estándares definiría?

Los protocolos basados en texto tienen muchas ventajas importantes:

Asumiendo que está utilizando UTF-8 u otra codificación orientada a octetos, no hay problemas de orden de bytes con los que lidiar.
Hacer que todos estén de acuerdo con los esquemas basados en texto (como los que se hacen en XML) es bastante difícil. Imagine tratar de hacer que todos acuerden cuántos bits debe ser un número en el protocolo binario.
- Relacionado, imagine tratar de hacer que se pongan de acuerdo sobre una representación en coma flotante. Esto no es demasiado hipotético: IBM amenazó con descarrilar el esfuerzo de estandarización de ECMAScript 5 sobre los problemas de representación en coma flotante.
La web está basada en texto, y no solo me refiero a un nivel de protocolo. Gran parte del contenido es texto (al mismo tiempo, casi TODO el contenido era texto). Como tal, los lenguajes de programación modernos han crecido en torno a la idea de que están trabajando con texto, y que el análisis de formatos binarios es menos importante.
- No hace mucho tiempo, tuve que generar un formato binario oscuro en Python para interactuar con un sistema heredado. Resultó ser mucho más doloroso de lo que hubiera imaginado. Analizarlo habría sido mucho, mucho peor.
Un desarrollador no puede ver una secuencia de bytes y decir "oh, la longitud de mi cadena falta", de la forma en que puede ver, por ejemplo, un documento XML y decir "oh, ese elemento no se cerró". Esto hace que el desarrollo y la resolución de problemas sean mucho más fáciles.
El rendimiento está sobrevalorado, y los analizadores XML son "lo suficientemente rápidos" en estos días. Si estás haciendo cosas que realmente tienen que tener hasta el último pedazo de rendimiento extraído del hardware, seguramente no estarás haciendo nada basado en la web, y probablemente estés construyendo tu propio protocolo binario para comunicarte entre dos aplicaciones que ya controlar.

Existen estándares de comunicación binarios, muchos de los cuales son anteriores a http. Construí / trabajé en un protocolo de base de datos cliente / servidor que era binario, y funcionó y fue eficiente por bytes. Entonces la pregunta es, ¿por qué un WIN de formato de texto en el mercado?

Creo que probablemente haya muchos factores, pero creo que estos son los más importantes:

Puede que no recuerde los días anteriores al XML, pero el orden de bytes solía ser un dolor de cabeza real cada vez que intentaba intercambiar datos. Cada bit era precioso, por lo que los formatos de archivo se empaquetaban lo más ajustadamente posible. Pero tan pronto como trataste de intercambiar archivos entre Macs, PC y mainframes, te diste cuenta de que la versión binaria de un entero estaba lejos de ser estándar. Los programadores pasaron incontables horas rectificando esto.
La depuración y el desarrollo son mucho más fáciles con flujos de texto. Como alguien señaló, puede usar una sesión de terminal telnet para hacer parte del desarrollo. Muchas veces puede ignorar los problemas de codificación de caracteres. La metáfora simple de Unix de tuberías y corrientes es probablemente la razón principal por la que ha tenido éxito. Es simplemente más fácil.

El protocolo HTTP en sí es legible como texto. Esto es útil porque puede hacer telnet en cualquier servidor y comunicarse con él.

Ser texto también le permite ver fácilmente la comunicación HTTP con un programa como wireshark. A continuación, puede diagnosticar la fuente de problemas fácilmente.

HTTP define una forma de trabajar con los resources . Estos recursos no necesitan ser texto, pueden ser imágenes o cualquier otra cosa. Un recurso de texto se puede enviar como binario al especificar el encabezado Content-Encoding . Su tipo de recurso se especifica mediante el encabezado Content-Type .

Por lo tanto, su pregunta realmente solo se aplica al protocolo HTTP en sí, y no a la carga útil, que son los recursos.

La web sería mucho más rápida y los navegadores podrían cargar páginas binarias muy rápido.

No creo que esto sea cierto. La parte más lenta es probablemente el establecimiento de la conexión y el inicio TCP lento .

Aquí hay un ejemplo de cómo una respuesta HTTP enviaría un recurso de texto con una representación binaria:

HTTP / 1.1 200 OK
Servidor: Apache / 2.0
Content-Encoding: gzip
Content-Length: 1533 Content-Type: text / html; juego de caracteres = ISO-8859-1

Siempre puedes descomprimir tu texto.

Ya ha sido propuesto: http://en.wikipedia.org/wiki/Binary_XML

En el pasado, se consideraba una pérdida de recursos (ancho de banda) codificar binarios como texto. No solo tiene que codificar y decodificar, sino que debe tener muy claro el tipo de objeto binario y quizás la estructura del objeto que desea enviar. XML a veces te da la ilusión de que esto viene automáticamente. Pero no es así

Las codificaciones de texto tienen, como lo menciona Brian, la gran ventaja de que usted, como ser humano, puede generarlas y depurarlas fácilmente.

Un formato interesante, no textual es ASN.1 (Notación de sintaxis abstracta No.1). Junto con las reglas de codificación (BER - Basic Encoding Rules, DER - Distinguished Encoding Rules, etc.) terminas en una codificación muy, muy compacta de estructuras binarias, que está altamente optimizada para la transferencia de red. Incluso el manejo de diferentes sexos byte se define aquí. Se utilizó ASN.1 y se propagó en la familia de protocolos X. (X.25, X.400, X.500, etc.). Todavía se usa en LDAP. También hay reglas de codificación definidas para codificar datos en XML (XER - Reglas de codificación XML). Ver http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One .

Puede permanecer como texto, siempre que nosotros, los humanos, interactuemos con esa información, es decir, a través de las vistas de IU, ya sea editando o simplemente leyendo.

Si el sistema de software decide convertir texto en binario para almacenamiento compacto, caché o transferencia, puede hacerlo, pero debe estar detrás de las escenas. Por lo tanto, es solo cuestión de optimización. Y como la optimización prematura es la raíz de muchos problemas, se puede implementar en una posición muy avanzada en el mapa de ruta del proyecto.

Bueno, parece que hay anuncios negativos, pero ... parece que estabas prediciendo el futuro. HTTP 2.0 será binario.