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