Почему протокол HTTP разработан в виде обычного текста?
Вчера я обсуждал с коллегами HTTP. Спрашивается, почему HTTP разработан в виде обычного текста. Конечно, он может быть разработан двоичным способом, как протокол TCP, с использованием флагов для представления различных видов методов (POST, GET) и переменных (заголовки HTTP). Итак, почему HTTP устроен именно так? Есть какие-то технические или исторические причины?
Ответы 10
Многие протоколы Интернет-приложений используют более или менее простой текст для протокола (см. FTP, POP, SMTP и т. д.).
Это значительно упрощает взаимодействие и устранение неполадок.
Так проще "прочитать" трафик или создать клиент или сервер?
Вы можете спорить, упрощает ли это фактически, но, безусловно, это было намерением.
Конечно, есть - вы смотрите на необработанный трафик и видите, что происходит. Большинство людей лучше интерпретируют строки, чем необработанные двоичные байты, тогда как компьютеры достаточно быстры, поэтому снижение производительности незначительно.
HTTP означает «Протокол передачи гипертекста».
Первоначально он был разработан как способ обслуживания текстовых документов, отсюда и протокол на основе текста.
То, что мы делаем с HTTP сейчас, выходит далеко за рамки его первоначального намерения.
Как и многие другие интернет-протоколы, которые не являются «гипертекстом».
причина, который является одновременно техническим и историческим, заключается в том, что текстовые протоколы почти всегда предпочтительны в мире Unix.
Ну это не совсем причина, а шаблон. Обоснование этого заключается в том, что текстовые протоколы позволяют вам видеть, что происходит в сети, просто сбрасывая все, что происходит. Вам не нужен специализированный анализатор, как для TCP / IP. Это упрощает отладку и поддержку.
Не только HTTP, но и многие протоколы основаны на тексте (например, FTP, POP3, SMTP, IMAP).
Возможно, вы захотите взглянуть на Искусство программирования под Unix для более подробного объяснения этой штуки с Unix.
Обсуждение в TAOUP того, почему текстовые протоколы хороши, очень и очень актуально. Также обратите внимание на количество ошибок в реализациях протоколов, описанных в таких вещах, как ASN.1. (И они часто проще, чем двоичные протоколы, не описанные в ASN.1!)
Как и в случае с RFC 2616 раздел 3.7.1 для HTTP 1.1, ключевым идентификатором строки команды или заголовка является CRLF разрыва строки текста; текстовые протоколы приложений упрощают ведение разговора (для устранения неполадок) исключительно с клиентом Telnet. Это также упрощает программирование с помощью вызовов ReadLine () и сопоставления текстовых строк.
Разрыв параметра CRLF также дает почти неограниченные произвольные расширения заголовков, в отличие от заголовков TCP или IP фиксированного размера, где жестко кодируются битовые смещения.
В HTTP содержание запроса почти всегда на несколько порядков больше, чем накладные расходы протокола. Преобразование протокола в двоичный позволит сэкономить очень небольшую полосу пропускания, а легкая возможность отладки, которую предлагает текстовый протокол без труда, превосходит незначительную экономию полосы пропускания двоичного протокола.
Исторически все начинается с RFC822 (СТАНДАРТ ДЛЯ ФОРМАТА ТЕКСТОВЫХ СООБЩЕНИЙ ARPA), последней версией которого является RFC5322 (Формат Интернет-сообщений). SMTP (RFC 821) был одним из самых популярных протоколов на основе RFC822. И HTTP родился из SMTP (вашего почтового протокола).
В случае с http некоторые люди работают над его «бинарной» версией, они назвали ее Embedded Binary HTTP (EBHTTP).
Я люблю:
...preferred in the Unix world.
причина, но это не входит в какое-либо объяснение того, почему.
Чтобы понять, почему вам нужно поставить себя на место дизайнера, который хочет создать полезный продукт.
A) Вы можете задокументировать дерьмо из бессмысленной тарабарщины (двоичный файл).
Б) Разработайте или надейтесь, что другие разработают инструменты, которые осмысленно изображают вашу бессмысленную тарабарщину.
или же
A) Вы можете задокументировать дерьмо из осмысленного текста, который использует язык как инструмент самодокументирующего протокола.
Б) Нет немедленной необходимости в дополнительных инструментах, а дополнительные инструменты будет намного проще писать и отлаживать.
Он создает поэтапную доставку и создает то, что легче понять и вспомнить при разработке в будущем. Это также создает ситуацию, когда абстракция более высокого уровня больше не нужна.
Представьте себе мир, в котором установка значения заголовка не так проста, как словарь / карта где-нибудь в вашем фреймворке. Когда вы сталкиваетесь с ошибками, вам придется постоянно задаваться вопросом, верна ли ваша структура или нет, потому что вы не могли легко увидеть, что она делает правильные вещи без дополнительных инструментов. Это был бы мир HTTP, если бы каждой структуре нужно было изобрести / реализовать свою собственную абстракцию более высокого уровня (на ум приходят браузеры).
Многие разработчики протоколов хотят эффективности, этот дизайн ориентирован на удобство использования, которое имеет первостепенное значение в индустрии разработки программного обеспечения. Невозможные преждевременно оптимизированные инструменты создают ненужное бремя для разработчиков программного обеспечения, и это бремя проявляется повсеместно.
Теперь двоичный файл на основе HTTP / 2 гораздо менее подвержен ошибкам.
Особенно, когда вы можете открыть сеанс telnet и подделать одну или обе стороны разговора для отладки.