Почему мы не отправляем двоичный файл вокруг вместо текста на http?
Кажется, что двоичный файл был бы более компактным и может быть десериализован стандартным способом, почему текст используется вместо этого? Это кажется неэффективным, и веб-платформы вынуждены сделать не что иное как валяющий дурака со строками. Почему не там двоичный стандарт? Сеть была бы путем быстрее, и браузеры будут в состоянии загрузить двоичные страницы очень быстро.
Если бы я должен был запустить протокол двоичной синхронной передачи данных (HBP hyper протокол двоичной синхронной передачи данных), какие стандарты я определил бы?
6 ответов
Сам протокол HTTP читается как текст. Это полезно, потому что вы можете подключиться к любому серверу через Telnet и общаться с ним.
Текст также позволяет легко наблюдать за HTTP-коммуникацией с помощью такой программы, как wirehark. Затем вы можете легко диагностировать источник проблем.
HTTP определяет способ работы с ресурсами . Эти ресурсы не обязательно должны быть текстом, они могут быть изображениями или чем-то еще. Текстовый ресурс можно отправить как двоичный, указав заголовок Content-Encoding . Тип вашего ресурса указывается в заголовке Content-Type .
Таким образом, ваш вопрос действительно относится только к самому протоколу HTTP, а не к полезной нагрузке, которая является ресурсами.
В Интернете можно было бы быстрее, и браузеры смогут загружать двоичные страницы очень быстро.
Я не делаю ' Не думаю, что это правда. Самой медленной частью, вероятно, является установление соединения и медленный запуск TCP .
Вот пример того, как ответ HTTP отправляет текстовый ресурс в двоичном представлении:
HTTP / 1.1 200 OK
Сервер: Apache / 2.0
Кодирование содержимого: gzip
Длина содержимого: 1533 Тип содержимого: текст / html; charset = ISO-8859-1
Там есть стандарты двоичной связи, многие из которых предшествуют http. Я построил / работал над протоколом базы данных клиент / сервер, который был двоичным, и он действительно работал и был эффективным в побайтовом отношении. Итак, вопрос в том, почему текстовый формат выиграл на рынке?
Я думаю, что, вероятно, есть много факторов, но я считаю, что это самые важные:
- Вы не можете вспомнить из pre-XML дней, но порядок байтов был головной болью при попытке обмена данными. Каждый бит был драгоценен, поэтому форматы файлов были упакованы максимально плотно. Но как только вы попытались обмениваться файлами между Mac, ПК и мэйнфреймами, вы поняли, что двоичная версия целого числа далека от стандартной. Программисты потратили бесчисленные часы, исправляя это.
- Отладка и разработка с текстовыми потоками намного проще. Как кто-то заметил, вы можете использовать сеанс терминала telnet для выполнения некоторых работ. Часто можно игнорировать проблемы с кодировкой символов. Простая метафора Unix с конвейерами и потоками, вероятно, является основной причиной успеха. Это просто проще.
Текстовые протоколы имеют много важных преимуществ:
- Предполагая, что вы используете UTF-8 или другую октетно-ориентированную кодировку, нет проблем с порядком байтов, с которыми нужно бороться.
- Довольно сложно убедить всех согласиться с текстовыми схемами (такими, как те, что реализованы в XML). Представьте, что вы пытаетесь убедить всех согласиться, сколько битов должно быть у числа в двоичном протоколе.
- Соответственно, представьте, что пытаетесь убедить их согласовать представление с плавающей запятой. Это не слишком гипотетически - IBM пригрозила сорвать усилия по стандартизации ECMAScript 5.
- Интернет основан на тексте, и я имею в виду не только на уровне протокола. Большая часть содержимого - это текст (когда-то почти ВСЕ содержимое было текстом). Таким образом, современные языки программирования выросли вокруг идеи, что они работают с текстом, и что анализ двоичных форматов менее важен.
- Не так давно мне пришлось сгенерировать неясный двоичный формат в Python для взаимодействия с устаревшей системой. Это оказалось намного больнее, чем я мог себе представить. Анализировать его было бы намного, намного хуже.
- Разработчик не может взглянуть на поток байтов и сказать «о, моя длина строки отсутствует» так, как он может взглянуть, например, на XML-документ и сказать «о, этот элемент не закрылся ". Это значительно упрощает разработку и устранение неполадок.
- Производительность переоценена, и анализаторы XML в наши дни «достаточно быстрые». Если вы делаете что-то, что действительно требует максимальной производительности оборудования, вы почти наверняка не делаете что-либо через Интернет, и, вероятно, будет создавать ваш собственный двоичный протокол для связи между двумя приложениями, которые вы уже контролируете.
Это уже было предложено: http://en.wikipedia.org/wiki/Binary_XML
В прежние времена это считалось пустой тратой (пропускная способность) ресурсы для кодирования двоичного файла как текста. Вы должны не только кодировать и декодировать, но и четко понимать тип двоичного объекта и, возможно, структуру объекта, который вы хотите отправить. XML иногда создает иллюзию, что это происходит автоматически. Но это не так.
Текстовые кодировки, как упомянул Брайан, имеют большое преимущество, заключающееся в том, что вы, как человек, можете легко их генерировать и отлаживать.
Интересным нетекстовым форматом является ASN.1 (Абстрактная синтаксическая нотация № 1). ). Вместе с правилами кодирования (BER - Basic Encoding Rules, DER - Distinguished Encoding Rules, и т. Д.) Вы получаете очень и очень компактное кодирование двоичных структур, который оптимизирован для передачи по сети. Здесь определяется даже обработка разных байтовых полов. ASN.1 использовался и распространялся в семействе протоколов X. (X.25, X.400, X.500 и т. Д.). Он все еще используется в LDAP. Также существуют правила кодирования, определенные для кодирования данных в XML (XER - XML Encoding Rules). См. http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One .