RFC 2068

RFC 2068 — это документ из серии Request for Comments (RFC), опубликованный в январе 1997 года, который определил первую версию протокола HTTP/1.1 (Hypertext Transfer Protocol версии 1.1). Данный протокол является основным протоколом прикладного уровня для передачи гипертекстовых документов, используемым во Всемирной паутине (World Wide Web). RFC 2068 был разработан рабочей группой HTTP (HTTP Working Group) под руководством Роя Филдинга (Roy T. Fielding) и других авторов, и представлял собой значительное развитие по сравнению с предыдущей версией протокола, HTTP/1.0, описанной в RFC 1945.

История и предпосылки создания

Проблемы HTTP/1.0

Протокол HTTP/1.0, стандартизированный в 1996 году в RFC 1945, имел ряд существенных ограничений, которые стали критическими по мере роста популярности Интернета в середине 1990-х годов. Основные недостатки включали:

• Отсутствие постоянных соединений: После каждого запроса и ответа TCP-соединение разрывалось. Для загрузки веб-страницы, содержащей множество элементов (изображения, CSS, JavaScript), требовалось устанавливать и закрывать десятки отдельных соединений, что создавало значительную задержку и нагрузку на серверы и сеть.
• Ограниченные возможности кэширования: HTTP/1.0 имел примитивные механизмы управления кэшем (заголовки Pragma и Expires), что часто приводило к некорректному кэшированию или его отсутствию.
• Проблемы с виртуальным хостингом: В HTTP/1.0 не было обязательного заголовка Host, что делало невозможным размещение нескольких веб-сайтов на одном IP-адресе (на одном сервере). Сервер мог определить, какой сайт запрашивается, только по IP-адресу, что было неэффективно.
• Отсутствие поддержки контент-негосиации и частичных запросов: Не было возможности запрашивать только часть файла (например, для докачки) или автоматически выбирать версию документа (язык, кодировка) на основе предпочтений клиента.

Разработка HTTP/1.1

Работа над новой версией протокола началась в 1995 году в рамках HTTP Working Group (HTTP-WG) при поддержке Internet Engineering Task Force (IETF). Целью было создание протокола, который устранил бы ограничения HTTP/1.0, улучшил производительность и обеспечил более надёжную работу веб-приложений. RFC 2068 стал результатом этой работы и был опубликован в январе 1997 года. Он заменил более ранние проекты и экспериментальные реализации, такие как протокол HTTP-NG.

Основные нововведения RFC 2068

RFC 2068 ввёл ряд ключевых механизмов, которые стали основой современного веба.

Постоянные соединения (Persistent Connections)

Самое значительное нововведение. RFC 2068 сделал постоянные соединения (keep-alive) поведением по умолчанию. После отправки ответа сервер не закрывал TCP-соединение, а оставлял его открытым для последующих запросов от того же клиента. Это позволяло:

• Сократить задержки на установку и закрытие TCP-соединений.
• Снизить нагрузку на серверы (меньше открываемых сокетов).
• Уменьшить сетевой трафик.

Обязательный заголовок Host

Протокол потребовал обязательного включения заголовка Host в каждый HTTP-запрос. Этот заголовок указывал имя хоста (доменное имя) запрашиваемого ресурса. Это позволило реализовать виртуальный хостинг (shared hosting) — размещение множества веб-сайтов на одном IP-адресе, что стало экономически эффективным решением для хостинг-провайдеров.

Контент-негосиация

RFC 2068 ввёл механизмы контент-негосиации, позволяющие клиенту и серверу согласовывать наиболее подходящую версию ресурса. Клиент мог отправлять заголовки Accept, Accept-Language, Accept-Charset, Accept-Encoding, указывая свои предпочтения. Сервер, в свою очередь, выбирал наиболее подходящий вариант из доступных (например, для русскоязычного пользователя отдавал русскую версию страницы).

Кэширование

Протокол значительно расширил возможности управления кэшированием. Были введены новые заголовки:

• Cache-Control: позволял задавать директивы для кэширующих прокси-серверов и браузеров (например, max-age, no-cache, public, private).
• ETag (Entity Tag): уникальный идентификатор версии ресурса, позволяющий серверу проверять, изменился ли ресурс с момента последнего запроса (условные запросы).
• If-None-Match, If-Modified-Since: позволяли клиенту запрашивать ресурс только в том случае, если он изменился, что экономило трафик.

Частичные запросы (Range Requests)

RFC 2068 ввёл поддержку частичных запросов с помощью заголовка Range. Клиент мог запросить не весь файл, а только его часть (например, для докачки прерванной загрузки или для потокового видео). Сервер отвечал кодом 206 Partial Content и передавал только запрошенный диапазон байтов.

Другие улучшения

• Поддержка кодов состояния: Были добавлены новые коды состояния, такие как 100 Continue (позволяет клиенту проверить, примет ли сервер тело запроса, прежде чем отправлять его целиком), 206 Partial Content, 300 Multiple Choices, 307 Temporary Redirect.
• Методы запросов: Определены методы OPTIONS, TRACE, CONNECT.
• Улучшенная обработка ошибок: Более детальные сообщения об ошибках и коды состояния.

Структура и содержание документа

RFC 2068 представлял собой объёмный документ (более 160 страниц), состоящий из нескольких разделов:

1. Введение: Описание целей и области применения протокола.
2. Общая архитектура: Определение модели взаимодействия клиент-сервер, роли прокси-серверов, шлюзов и туннелей.
3. Синтаксис сообщений: Определение формата HTTP-запросов и ответов (строка запроса/состояния, заголовки, тело сообщения).
4. Заголовки: Подробное описание всех стандартных заголовков запроса и ответа.
5. Методы запросов: Определение семантики методов GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE, CONNECT.
6. Коды состояния: Полный список кодов состояния (1xx, 2xx, 3xx, 4xx, 5xx) с описанием.
7. Кэширование: Описание механизмов кэширования и управления кэшем.
8. Безопасность: Обсуждение вопросов безопасности, включая аутентификацию (Basic и Digest) и защиту от атак.
9. Совместимость с HTTP/1.0: Описание того, как HTTP/1.1 взаимодействует с клиентами и серверами, поддерживающими только HTTP/1.0.

Значение и влияние

RFC 2068 стал фундаментом для современного веба. Он решил ключевые проблемы масштабирования и производительности, которые сдерживали развитие Интернета в конце 1990-х годов. Без постоянных соединений и виртуального хостинга современный веб с миллионами сайтов и высокой нагрузкой был бы невозможен.

Однако RFC 2068 не был лишён недостатков. Некоторые его положения были двусмысленными или сложными для реализации. В результате, в 1999 году была опубликована уточнённая версия протокола HTTP/1.1 — RFC 2616, которая заменила RFC 2068. RFC 2616 устранила многие неясности, исправила ошибки и стала основной спецификацией HTTP/1.1 на долгие годы. Впоследствии RFC 2616 был заменён серией документов (RFC 7230–7235) в 2014 году, которые разбили спецификацию на более мелкие и управляемые части.

Несмотря на то, что RFC 2068 был заменён, его историческое значение огромно. Он стал первым стандартом, который превратил HTTP из простого протокола для передачи файлов в мощный и гибкий протокол, способный поддерживать современные веб-приложения.

Критика и ограничения

Основная критика RFC 2068 касалась его сложности и объёма. Многие разработчики и администраторы серверов находили его трудным для полного понимания и реализации. Некоторые механизмы, такие как контент-негосиация, были реализованы не полностью или с ошибками в ранних версиях браузеров и серверов. Кроме того, RFC 2068 не полностью решил проблему «head-of-line blocking» (блокировки начала очереди), когда один медленный запрос мог задерживать все последующие запросы в рамках одного постоянного соединения. Эта проблема была окончательно решена только с появлением HTTP/2.

Источники

• RFC 2068 — Hypertext Transfer Protocol — HTTP/1.1 (январь 1997)
• RFC 1945 — Hypertext Transfer Protocol — HTTP/1.0 (май 1996)
• RFC 2616 — Hypertext Transfer Protocol — HTTP/1.1 (июнь 1999)
• Fielding, R. T., et al. «Hypertext Transfer Protocol — HTTP/1.1». RFC 2068, 1997.
• Berners-Lee, T., et al. «Hypertext Transfer Protocol — HTTP/1.0». RFC 1945, 1996.