Почему мы не отправляем двоичный код вместо текста на http?

Ответ 1

Протокол HTTP сам по себе читается как текст. Это полезно, потому что вы можете telnet на любой сервер и общаться с ним.

Текст также позволяет вам легко просматривать HTTP-связь с помощью программы, например wirehark. Вы можете легко диагностировать источник проблем.

HTTP определяет способ работы с resources. Эти ресурсы не обязательно должны быть текстом, они могут быть изображениями или чем-либо еще. Текстовый ресурс может быть отправлен как двоичный, указав заголовок Content-Encoding. Тип ресурса указывается через заголовок Content-Type.

Таким образом, ваш вопрос действительно применим только к самому HTTP-протоколу, а не к полезной нагрузке, которая является ресурсами.

Интернет будет быстрее, и браузеры смогут быстро загружать двоичные страницы.

Я не думаю, что это правда. Самая медленная часть - это, вероятно, установление соединения и медленный запуск TCP.

Вот пример того, как ответ HTTP отправляет текстовый ресурс с двоичным представлением:

HTTP/1.1 200 OK
Сервер: Apache/2.0
Контентное кодирование: gzip
Контент-длина: 1533 Content-Type: text/html; кодировка = ISO-8859-1

Ответ 2

Текстовые протоколы имеют много важных преимуществ:

• Предполагая, что вы используете UTF-8 или другую октетно-ориентированную кодировку, проблем с байтовым порядком не существует.
• Получение согласия на текстовые схемы (например, сделанные в XML) достаточно сложно. Представьте, что вы пытаетесь заставить всех согласиться, сколько бит должно быть в двоичном протоколе.
  • В связи с этим представьте, что вы пытаетесь заставить их согласиться на представление с плавающей запятой. Это не очень гипотетично - IBM угрожала сорвать усилия по стандартизации ECMAScript 5 по проблемам представления с плавающей точкой.
• Веб-интерфейс основан на тексте, и я имею в виду не только уровень протокола. Большая часть контента - текст (в свое время почти ВСЕ содержимое было текстовым). Таким образом, современные языки программирования выросли вокруг идеи, что они работают с текстом, и что разбор двоичных форматов менее важен.
  • Не так давно мне пришлось создать неясный двоичный формат в Python для взаимодействия с унаследованной системой. Это оказалось гораздо более болезненным, чем я мог себе представить. Анализ был бы намного хуже.
• Разработчик не может смотреть на поток байтов и сказать "о, моя длина строки отсутствует", как он может смотреть, например. XML-документ и сказать "о, этот элемент не закрылся". Это значительно облегчает разработку и устранение неполадок.
• Производительность переоценена, и в наши дни синтаксические анализаторы XML являются "достаточно быстрыми". Если вы делаете то, что действительно должно иметь каждый последний бит производительности, вытесненной из аппаратного обеспечения, вы почти наверняка не делаете ничего на базе Интернета и, вероятно, будете создавать свой собственный двоичный протокол для связи между двумя приложениями, которые вы уже управления.

Ответ 3

Существуют бинарные стандарты связи, многие из которых являются досрочно http. Я построил/работал над протоколом базы данных клиент/сервер, который был двоичным, и он работал и был эффективным побайтовым. Итак, вопрос: почему текстовый формат WIN на рынке?

Я думаю, что, вероятно, есть много факторов, но я считаю, что они являются самыми важными:

• Возможно, вы не помните, что в пред-XML-дни, но при сортировке байтов байт-порядок использовался как головная боль. Каждый бит был драгоценным, поэтому форматы файлов были упакованы настолько сильно, насколько это возможно. Но как только вы пытались обмениваться файлами между компьютерами Mac и ПК и мэйнфреймами, вы поняли, что двоичная версия целого числа далека от стандартного. Программисты провели бесчисленные часы, исправляя это.
• Отладка и разработка намного проще с текстовыми потоками. Как заметил кто-то, вы можете использовать сеанс терминала telnet, чтобы выполнить некоторую разработку. Много раз вы можете игнорировать проблемы с кодировкой символов. Unix простая метафора труб и потоков, вероятно, является основной причиной успеха. Это просто проще.

Ответ 4

Ну, это похоже на некропостинг, но... похоже, вы предсказывали будущее. HTTP 2.0 будет двоичным.

Ответ 5

Уже было предложено: http://en.wikipedia.org/wiki/Binary_XML

Ответ 6

Вы всегда можете gzip текст.

Ответ 7

В прежние времена он считался тратой ресурсов (пропускной способности) для кодирования двоичного кода как текста. Вам не только нужно кодировать и декодировать, но вы должны четко понимать тип двоичного объекта и, возможно, структуру объекта, который вы хотите отправить. XML иногда дает вам иллюзию, что это происходит автоматически. Но это не так.

Текстовые кодировки имеют, как упоминалось Брайаном, большое преимущество, что вы, как человек, можете легко генерировать и отлаживать их.

Интересным, нетекстовым форматом является ASN.1 (Абстрактная синтаксическая нотация № 1). Вместе с правилами кодирования (BER - Basic Encoding Rules, DER - Distinguished Rules Encoding Rules и т.д.) Вы получаете очень и очень компактное кодирование двоичных структур, которое сильно оптимизировано для сетевой передачи. Здесь определяется даже обращение с разными байтовыми полами.  ASN.1 использовался и распространялся в X-семействе протоколов (X.25, X.400, X.500 и т.д.). Он по-прежнему используется в LDAP. Существуют также правила кодирования, определенные для кодирования данных в XML (XER - правила кодирования XML). См. http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One.

Ответ 8

Он может оставаться как текст, когда мы, люди, взаимодействуем с этими данными, то есть через представления пользовательского интерфейса, редактируя или просто читаем.

Если программная система решает преобразовать текст в двоичный файл для компактного хранения, кеширования или передачи, он может это сделать, но он должен быть за сценой. Так что это просто оптимизация. И поскольку преждевременная оптимизация - корень многих проблем, она может быть реализована в очень поздней позиции на дорожной карте проекта.