Http: протокол, который каждый разработчик должен знать (часть 1)

Talks and Presentations

Preliminary HTTP/1.1 Performance
Evaluation by Jim Gettys

The HTTP/1.1 performance
paper explains the experiments in detail, and was recently
submitted for publication. This work shows how you can gain as much as
a factor of 10 in number of packets and 2 in times of speed by using
HTTP/1.1 pipelining. Earliest results were presented at the IETF meeting in San Jose,
December 1996, and more complete results at the W3C Advisory Committee Meeting
in England in January.

Overview of new HTTP/1.1 functionality and
changes from HTTP/1.0 by Jim Gettys

This presentation gives a good overview of new features. It will be
updated occasionally as it is presented. The presentation is also
available for Microsoft
PowerPoint

PEP — An Extension Mechanism for HTTP
by Henrik Frystyk Nielsen and Rohit Khare

This presentation was given at the IETF meeting in
Montreal, June 1996.

Как работает HTTP, и зачем нам это знать

Программировать на PHP можно и без знания протокола HTTP, но есть ряд ситуаций, когда для решения задач нужно знать, как именно работает веб-сервер. Ведь PHP — это, в первую очередь, серверный язык программирования.

Протокол HTTP очень прост и состоит, по сути, из двух частей:

• Заголовков запроса/ответа;
• Тела запроса/ответа.

Сначала идёт список заголовков, затем пустая строка, а затем (если есть) тело запроса/ответа.

И клиент, и сервер могут посылать друг другу заголовки и тело ответа, но в случае с клиентом доступные заголовки будут одни, а с сервером — другие. Рассмотрим пошагово, как будет выглядеть работа по протоколу HTTP в случае, когда пользователь хочет загрузить главную страницу социальной сети «Вконтакте».

1. Браузер пользователя устанавливает соединение с сервером vk.com и отправляет следующий запрос:

GET / HTTP/1.1
Host: vk.com

2. Сервер принимает запрос и отправляет ответ:

3. Браузер принимает ответ и показывает готовую страницу

Больше всего нам интересен самый первый шаг, где браузер инициирует запрос к серверу vk.com
Рассмотрим подробнее, что там происходит. Первая строка запроса определяет несколько важных параметров, а именно:

• Метод, которым будет запрошен контент;
• Адрес страницы;
• Версию протокола.

— это метод (глагол), который мы применяем для доступа к указанной странице. является самым часто используемым методом, потому что он говорит серверу о том, что клиент всего лишь хочет прочитать указанный документ. Но помимо есть и другие методы, один из них мы рассмотрим уже в следующем разделе.

После метода идет указание на адрес страницы — URI (универсальный идентификатор ресурса). В нашем случае мы запрашиваем главную страницу сайта, поэтому используется просто слэш — .
Последним в этой строке идет версия протокола и почти всегда это будет

После строки с указанием основных параметров всегда следует перечисление заголовков, которые передают серверу дополнительную полезную информацию: название и версию браузера, язык, кодировку, параметры кэширования и так далее.
Среди всех этих заголовков, которые передаются при каждом запросе, есть один обязательный и самый важный — это заголовок . Он определяет адрес домена, который запрашивает браузер клиента.

Сервер, получив запрос, ищет у себя сайт с доменом из заголовка , а также указанную страницу.
Если запрошенный сайт и страница найдены, клиенту отправляется ответ:
Такой ответ означает, что всё хорошо, документ найден и будет отправлен клиенту. Если говорить более обобщённо, стартовая строка ответа имеет следующую структуру:

Больше всего здесь интересен именно код состояния, он же код ответа сервера.
В этом примере код ответа — 200, что означает: сервер работает, документ найден и будет передан клиенту. Но не всегда всё идет гладко.
Например, запрошенный документ может отсутствовать или сервер будет перегружен, в таком случае клиент не получит контент, а код ответа будет отличным от 200.

• 404 — если сервер доступен, но запрошённый документ не найден;
• 503 — если сервер не может обрабатывать запросы по техническим причинам.

Спецификация HTTP 1.1 определяет 40 различных кодов HTTP.

После стартовой строки следуют заголовки, а затем тело ответа.

2019

Google придумала, как заставить сайты перейти на HTTPS

Начиная с 2010 года, корпорация изменит свое отношение к сайтам, полностью не перешедшим на HTTPS и продолжающим загружать некоторые ресурсы страниц (например, видео, аудио, изображения и скрипты) по HTTP.

Загружаемые сайтами ресурсы по HTTPS и по HTTP называются «смешанным контентом» и представляют собой проблему с самого первого дня внедрения HTTPS

В течение нескольких лет браузеры игнорировали проблему «смешанного контента», для них было важно лишь, чтобы главный домен загружался по HTTPS.. Тем не менее, в последнее время компании Google и Mozilla, каждая по своему, активно продвигают HTTPS

Mozilla и ее партнеры запустили сервис Let’s Encrypt, предоставляющий бесплатные, простые в развертывании TLS-сертификаты. В свою очередь, Google Chrome стал обозначать загружаемые по HTTP сайты как небезопасные (Not Secure).

Тем не менее, в последнее время компании Google и Mozilla, каждая по своему, активно продвигают HTTPS. Mozilla и ее партнеры запустили сервис Let’s Encrypt, предоставляющий бесплатные, простые в развертывании TLS-сертификаты. В свою очередь, Google Chrome стал обозначать загружаемые по HTTP сайты как небезопасные (Not Secure).

Теперь же Google намерена пойти еще дальше и заставить сайты полностью перейти на HTTPS. Начиная с версии Chrome 79, в браузер постепенно будут вноситься изменения, которые в итоге приведут к полной блокировке «смешанного контента» по умолчанию. Уже в Chrome 80 «смешанные» аудио и видео будут автоматически обновляться до HTTPS. В случае невозможности загрузки контента по HTTPS, он будет блокироваться. В Chrome 81 этот подход будет также применяться к «смешанным» изображениям.

Власти Казахстана перехватывают трафик Facebook, Google и «ВКонтакте»

Спустя неделю после того, как правительство Казахстана начало перехватывать весь HTTPS-трафик, стали известны некоторые подробности о происходящем в стране. Подробнее здесь.

Правительство Казахстана начало перехватывать весь HTTPS-трафик в стране

17 июля 2019 года правительство Казахстана начало перехватывать весь интернет-трафик HTTPS в стране. Для этого местных телекоммуникационных операторов обязали к тому, чтобы заставлять пользователей на все свои устройства и в браузеры специальный сертификат, разработанный властями.

После установки сертификата правительственные органы Казахстана смогут расшифровывать HTTPS-трафик пользователей, просматривать его содержимое, снова шифровать его с помощью своего сертификата и отправлять по назначению. Это позволяет правительству Казахстана легко отслеживать действия своих граждан в Интернете.

Как пишет издание ZDNet, пользователи, пытающиеся получить доступ к интернету с 17 июля 2019 года, перенаправляются на веб-страницы, на которых содержатся инструкции по установке корневого государственного сертификата в браузерах для мобильных устройств и компьютеров.

Без установки сертификата зайти на сайты с HTTPS (а таких большинство) нельзя — интернет-провайдер блокирует доступ и выдаёт страницу-заглушку, подобную той, которая представлена ниже.

Жителей Казахстана обязали установить сертификат безопасности «для защиты от хакерских атак и просмотра противоправного контента»

На этой странице выведено следующее сообщение:

Операторы Kcell и Activ заявили, что сертификат был внедрен из-за участившихся случаев хищения персональных данных казахстанцев и кражи денег с их банковских карт. Он защитит абонентов «от хакерских атак и просмотра противоправного контента». У сертификата не будет доступа к персональным данным абонента, утверждают Kcell.

HTTP-СОЕДИНЕНИЕ

Соединение между клиентом и сервером устанавливается обязательно до того, как они смогут “общаться” друг с другом, при этом используется самый надежный протокол-TCP. По умолчанию, TCP использует 80-ый порт. Поток разбивается на пакеты IP,что гарантирует получение пакетов в правильном порядке без потерь. HTTP-протокол прикладного уровня TCP, основанного на IP. HTTPS — защищенная версия HTTP, куда вставлены дополнительные уровни между HTTP и TCP, называемые TLS и SSL (Transport Layer Security и Secure Sockets Layer, соответственно). По умолчанию, HTTPS использует 443-ий TCP-порт, и в данной статье будет рассмотрен именно HTTPS- протокол.

Подключение HTTP идентифицируется как <исходный IP, исходный порт> и <IP приемника, порт приемника>. На клиентском уровне протокол представлен кортежем: <IP, порт>. Установка соединения между двумя конечными точками — процесс многоступенчатый. Он включает в себя следующие шаги:

• расчет IP адреса по имени хоста DNS,
• установление соединения с сервером,
• отправка запроса,
• ожидание ответа,
• закрытие соединения.

В HTTP/1.0, все соединения закрывались после одной транзакции. Таким образом, если клиент запрашивал три отдельных изображения с одного сервера, он трижды подключался к удаленному хосту. Как видно на схеме выше, это вызывает множество задержек в сети, что приводит к не-оптимальной работе.

Чтобы избавиться от этих задержек, в HTTP/1.1 были введены постоянные соединения — долгоживущие соединения, которые остаются открытыми, пока клиент не закроет их. Эти соединения используются по умолчанию, а чтобы произвести транзакцию клиент должен установить соединение: “Connection: close” в заголовке запроса. Это значит, что сервер должен прервать соединение сразу после того, как оправит ответ клиенту.

Помимо постоянных соединений, браузеры / клиенты для минимизации времени задержек сети используют метод, называемый параллельные соединения. Старая концепция параллельных соединений заключается в создании пула соединений (как правило, не более шести соединений). То есть, если клиент хочет загрузить с веб-сайта шесть ресурсов, создаются шесть параллельных соединений, в результате чего время отклика становится минимальным. Это огромный плюс по сравнению с последовательными соединениями, где клиент скачивает ресурсы друг за другом.

Параллельные соединения в сочетании с постоянными соединениями — вот ответ сегодняшним технологиям сведения к минимуму задержки в сети. Углубленный анализ подключений HTTP рассмотрен в разделе (спецификация HTTP)

Отношение поисковых систем к http/2

В отличие от протокола SPDY, где соединение между сервером и пользователем необходимо в обязательном порядке шифровать посредством HTTPS, при использовании второй версии HTTP такой необходимости нет. Однако разработчики браузеров придумали, как заставить клиентов использовать защищенный протокол – они реализовали протокол только для TLS. В связи с этим все, кто желает перейти на http/2, обязаны первым делом начать пользоваться https.

Да и это не единственная причина, по которой нужно прибегать
к безопасному соединению. Если ваш сайт использует обычный HTTP протокол,
он не сможет подняться на высокие позиции в результатах выдачи в Google, так как для поисковой
системы наличие HTTPS протокола – один из факторов ранжирования. Браузеры уже помечают
для пользователей сайты без TLS-соединения
«небезопасными».

На заметку. Без защищенного соединения вы не сможете воспользоваться огромным количеством функций HTML5, такими как геолокация.

С 19 декабря 2016 года компания Google заявила, что их основной робот поддерживает HTTP/2 – это явный признак того, что поисковик хорошо относится к протоколу. Аналитик команды Google Джон Мюллер лично подтвердил, что использование нового протокола будет поощряться хорошим ранжированием сайтов, переведенных на него, так как он ускоряет их работу.

Да, поддержка современного протокола на сайте не влияет непосредственно на его позиции в поисковой выдаче. Но так как скорость загрузки страниц является значительным критерием ранжирования, то HTTP/2 непременно поможет в SEO-продвижении. И если ускорить работу сайта, то обязательно улучшатся показатели поведенческих факторов, что и приведет к положительному ранжированию.

У быстро загружающихся страниц куда меньше отказов, чем у «медленных»,
потому что посетителю удобнее на нормально работающей странице изучать контент
и совершать какие-либо действия.

HTTP-сеанс [ править ]

HTTP-сеанс — это последовательность сетевых транзакций запрос – ответ. Клиент HTTP инициирует запрос, устанавливая соединение протокола управления передачей (TCP) с определенным портом на сервере (обычно порт 80, иногда порт 8080; см. Список номеров портов TCP и UDP ). HTTP-сервер, прослушивающий этот порт, ожидает сообщения запроса от клиента. После получения запроса сервер отправляет обратно строку состояния, например « HTTP / 1.1 200 OK », и собственное сообщение. Тело этого сообщения обычно является запрошенным ресурсом, хотя также может быть возвращено сообщение об ошибке или другая информация.

Постоянные соединения править

В HTTP / 0.9 и 1.0 соединение закрывается после одной пары запрос / ответ. В HTTP / 1.1 был введен механизм keep-alive, при котором соединение можно было повторно использовать для более чем одного запроса. Такие постоянные соединения заметно сокращают задержку запроса, поскольку клиенту не нужно повторно согласовывать соединение TCP 3-Way-Handshake после отправки первого запроса. Еще один положительный побочный эффект заключается в том, что в целом соединение со временем становится быстрее из-за механизма TCP.

Версия 1.1 протокола также улучшила оптимизацию полосы пропускания для HTTP / 1.0. Например, в HTTP / 1.1 введено кодирование передачи по частям, позволяющее передавать контент в постоянных соединениях в потоковом режиме, а не в буфере. Конвейерная обработка HTTP дополнительно сокращает время задержки, позволяя клиентам отправлять несколько запросов, прежде чем ждать каждого ответа. Еще одним дополнением к протоколу стало обслуживание байтов , когда сервер передает только часть ресурса, явно запрошенную клиентом.

Состояние сеанса HTTP править

HTTP — это протокол без сохранения состояния . Протокол без сохранения состояния не требует, чтобы HTTP-сервер сохранял информацию или статус о каждом пользователе в течение нескольких запросов. Однако некоторые веб-приложения реализуют состояния или сеансы на стороне сервера, используя, например, файлы cookie HTTP или скрытые переменные в веб-формах .

Методы HTTP

• Метод/Описание
• HEAD/Прочитать заголовок веб-страницы
• GET/Прочитать веб-страницу
• POST/Добавить к веб-странице
• PUT/Сохранить веб-страницу
• TRACE/Отослать назад запрос
• DELETE/Удалить веб-страницу
• OPTIONS/Отобразить параметры
• CONNECT/Зарезервировано для будущего использования

Разберем методы HTTP подробнее

Метод GET. запрашивает страницу (файл, объект), закодированную по стандарту MIME. Это самый употребляемый метод. Структура метода:
GET имя_файла HTTP/1.1

Метод HEAD. Этот метод запрашивает заголовок сообщения. При этом страница не загружается. Этот метод позволяет узнать время последнего обновления страницы, что нужно для управления КЭШем страниц. Этот метод позволяет проверить работоспособность запрашиваемого URL.

Метод PUT. Этот метод может поместить страницу на сервер. Тело запроса PUT включает размещаемую страницу, которая закодирована по MIME. Это метод требует идентификации клиента.

Метод POST. Этот метод добавляет содержимое к уже имеющейся странице. Используется, как пример, для добавления записи на форум.

Метод DELETE. Этот метод уничтожает страницу. Метод удаления требует подтверждения прав пользователя на удаление.

Метод TRACE. Этот метод отладки. Он указывает серверу отослать запрос назад и позволяет узнать, искажается или нет, запрос клиента, вернувшись от сервера.

Метод CONNECT – метод резерва, не используется.

Метод OPTIONS позволяет запросить свойства сервера и свойства любого файла.

В общении клиента и сервера «запрос-ответ», сервер обязательно генерирует ответ. Это может быть веб-страница или строку состояния с кодом состояния. Код состояния вам хорошо известен. Один из кодов известный код 404 –Страница не найдена.

Различие между HTTP и HTTPS

Большинство людей не знают о различиях между http:// и https://, поскольку оба они почти визуально схожи. Знание различий между ними имеет первостепенное значение для поддержания безопасного и эффективного сайта, способного защитить информацию и данные. Браузеры были разработаны таким образом, что строка URL-адреса будет выделять буквы S в HTTPS другим цветом, чтобы пользователи могли их заметить.

Вот некоторые очевидные различия между ними:

HTTP — В настоящее время шифрование данных не осуществляется.
Каждая URL-ссылка использует HTTP в качестве основного типа протокола передачи гипертекста. Учитывая это, HTTP уподобляется системе, которая не принадлежит ни одному государству. Это позволяет включить любое соединение по требованию.
По сути, этот протокол является протоколом прикладного уровня. Это означает, что он больше фокусируется на информации, которая предоставляется пользователю, но не на том, как эти данные передаются от узла-источника к получателю

Это может нанести ущерб, так как это средство доставки может быть легко перехвачено и отслежено злоумышленниками сторонних пользователей (обычно известными как хакеры).

HTTPS — Данные зашифрованы.
По сравнению с HTTP, информация о пользователе, такая как номера кредитных карт и другие формы важной личной информации, зашифрована. Это предотвращает доступ вредоносных пользователей третьих сторон к этим формам конфиденциальных данных в любой форме.
При более безопасной сети пользователи будут иметь более высокий уровень доверия при использовании сайта, поскольку их данные зашифрованы, а пользователям со злым умыслом будет трудно взломать свои данные.

Статистика показывает, что 84% покупателей покидают веб-сайты после того, как узнают, что веб-сайт передает данные по незащищенному каналу.
29% пользователей осознают разницу между HTTP и HTTPS и активно ищут эту разницу в адресной строке.
Являясь новой формой технологии, HTTPS все еще имеет несколько особенностей, которые до сих пор считаются экспериментальными

В связи с этим более старые типы браузеров будут испытывать трудности с адаптацией к этим веб-сайтам.
По сравнению с простой настройкой сайта с HTTP, переход на HTTPS требует от пользователя прохождения нескольких юридических процедур для получения SSL-сертификата. Это означает, что владельцы страниц и сайтов вынуждены тратить деньги. Получение SSL-сертификатов является платной услугой от центра сертификации.
Благодаря процессу кодирования сервер направляет энергию и время обработки на кодирование информации до того, как она будет передана.

Резюме технических различий между HTTP и HTTPS:

• HTTP небезопасен, в то время как HTTPS является безопасным протоколом.
• HTTP использует TCP порт 80, в то время как HTTPS использует TCP порт 4433.
• HTTP работает на прикладном уровне, в то время как HTTPS работает на транспортном уровне безопасности (TLS).
• Для HTTP не требуется сертификат SSL, но HTTPS требует, чтобы сертификат SSL был подписан и внедрен центром сертификации (ЦС).
• HTTP не обязательно требует подтверждения домена, в то время как HTTPS в обязательном порядке требует подтверждения домена и определенных сертификатов, которые требуют юридического оформления.
• Во время зашифровки данных непосредственно перед их передачей для протокола HTTPS шифрование данных в HTTP не выполняется.
• HTTPS является расширением протокола HTTP. В этом случае он работает совместно с другим протоколом, а именно Secure Sockets Layer (SSL) для безопасной передачи данных.
• Как HTTP, так и HTTPS не обращаются к данным, которые будут передаваться по назначению. И наоборот, SSL не имеет никакого отношения к тому, как будут выглядеть данные.

Пользователи часто ошибочно полагают, что HTTPS и SSL являются одними и теми же протоколами. HTTPS безопасен, так как использует SSL для передачи данных. В настоящее время TSL медленно сворачивает использование SSL, поскольку это еще более безопасный способ шифрования данных, который будет отправляться.

Преимущество http/2 для разработчиков

Современный протокол избавляет разработчиков от большого
количества устаревших мероприятий, к которым ранее им приходилось прибегать для
ускорения загрузки документов:

• Доменное
  шардирование. Раньше в http/1.1
  число открытых соединений было ограничено. Но можно было установить большое количество
  соединений за счет загрузки файлов сразу с нескольких поддоменов, чтобы
  ускорить работу. Такой подход был особенно актуальным для сайтов, куда
  загружено множество изображений. Теперь благодаря HTTP/2 нет нужды прибегать к домен-шардингу,
  потому что протокол дает возможность запросить неограниченное количество ресурсов.
  Тем более, что с новым протоколом доменное шардирование не только не повысит производительность,
  но и нагрузит сервер лишними соединениями.
• Объединение
  скриптов Java и CSS. Процедура заключается в том, чтобы из множества
  маленьких файлов создать один большой. Это конечно уменьшает число запросов, но
  пользователь, посетив страницу, загрузит абсолютно все CSS и JS файлы, даже те, которые ему не
  понадобятся. Соответственно объединение файлов съедает память. Еще одна
  трудность – все элементы нуждаются в одновременной чистке из кэша, так как
  недопустимо, чтобы дата окончания срока действия каждого из них разнилась. Если
  поменять даже одну строку в CSS,
  срок действия закончится у всех элементов одновременно. HTTP/2 позволяет не прибегать к объединению
  файлов, потому что он не затрачивает много ресурсов.
• Объединение
  картинок (спрайты). Тоже снижает количество запросов, но так как вес изображения
  увеличится, загружаться он будет дольше. Более того, для показа хотя бы одной
  картинки нужно загрузить весь спрайт. Вывод – применение спрайтов чревато занятием
  больших объемов памяти.
• Доменные
  имена без cookie. Подразумевает загрузку
  изображений, JS и CSS файлов с другого домена, где нет данных cookie.
• Перенос JavaScript, CSS, картинок в HTML-файл. Аналогично уменьшает количество соединений, но
  страница не отобразится до полной загрузки всего файла.

Почему важно искать возможности ускорить загрузку страниц сайта?

Джон Мюллер, аналитик из команды Google Webmaster Trends, в своем блоге написал, что наличие на сайте поддержки HTTP/2 не является напрямую ранжирующим фактором в Google. В то же время, скорость загрузки — сама по себе значительный фактор ранжирования, поэтому имеет смысл начать использовать HTTP/2 для SEO-продвижения.

Он добавил, что само по себе ускорение работы сайта должно положительно влиять на ранжирование за счет поведенческих факторов. У более «быстрой» страницы меньше процент отказов — скорее всего, больше пользователей что-то сделают на такой странице, и это повлияет на ранжирование в поиске.

Джон Мюллер также сообщил, что Googlebot скоро начнет поддерживать HTTP/2. И кто знает — может, в будущем наличие HTTP/2 на сайте и станет ранжирующим фактором. Ведь поисковики постоянно меняют алгоритмы.

3.3 Форматы даты/времени.

3.3.1 Полная дата.

HTTP приложения исторически допускали три различных формата для
представления даты/времени:

      Sun, 06 Nov 1994 08:49:37 GMT  ; , дополненный в 
      Sunday, 06-Nov-94 08:49:37 GMT ; , переписанный как 
      Sun Nov  6 08:49:37 1994       ; формат asctime() ANSI C

Первый формат выбран в качестве стандарта Интернета и представляет
подмножество фиксированной длины, как определено в RFC 1123
(модифицированном RFC 822). Второй формат находится в общем
пользовании, но основан на устаревшем и потерявшем статус стандарта
RFC 850 , описывающем форматы дат, он обладает тем недостатком,
что год указывается не в четырехразрядной нотации. Клиенты и
серверы HTTP/1.1, которые анализируют значение даты, ДОЛЖНЫ
понимать все три формата (для совместимости с HTTP/1.0), но
генерировать для представления значений дат в полях заголовка HTTP
ДОЛЖНЫ только формат RFC 1123 .

Обратите внимание: Поощряется практика, при которой получатели
значений дат здраво воспринимают значения дат, которые, возможно,
посланы не HTTP приложениями, что имеет место при загрузке или
регистрации сообщений через прокси-сервера/шлюзы к SMTP или NNTP.

Все без исключений форматы HTTP даты/времени ДОЛЖНЫ быть
представлены в Greenwich Mean Time (GMT). В первых двух форматах
данный факт указывается включением трехсимвольного сокращения «GMT»
в качестве часового пояса. В asctime() формате это ДОЛЖНО
подразумеваться при чтении.

          HTTP-date    = rfc1123-date | rfc850-date | asctime-date

          rfc1123-date = wkday "," SP date1 SP time SP "GMT"
          rfc850-date  = weekday "," SP date2 SP time SP "GMT"
          asctime-date = wkday SP date3 SP time SP 4DIGIT

          date1        = 2DIGIT SP month SP 4DIGIT
                         ; день месяц год (например 02 Jun 1982)

          date2        = 2DIGIT "-" month "-" 2DIGIT
                         ; день-месяц-год (напрмер 02-Jun-82)

          date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
                         ; месяц день (например, Jun  2)

          time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
                         ; 00:00:00 - 23:59:59

          wkday        = "Mon" | "Tue" | "Wed"
                       | "Thu" | "Fri" | "Sat" | "Sun"

          weekday      = "Monday" | "Tuesday" | "Wednesday"
                       | "Thursday" | "Friday" | "Saturday" | "Sunday"

          month        = "Jan" | "Feb" | "Mar" | "Apr"
                       | "May" | "Jun" | "Jul" | "Aug"
                       | "Sep" | "Oct" | "Nov" | "Dec"

Обратите внимание: Эти требования — это требования к для
форматам даты/времени, которые применяются внутри потока
протокола HTTP. Клиентам и серверам не требуется использовать
эти форматы для представления пользователю, регистрации
запросов и т.д.

3.3.2 Разность секунд (delta seconds).

Некоторые поля HTTP заголовка позволяют указывать значения времени
в виде целого числа секунд, представленного в десятичной форме,
которые должны пройти с того момента, как сообщение было получено.

          delta-seconds  = 1*DIGIT

Заключение о протоколе HTTP

Итак, постоянное соединение HTTP позволяет использовать одно и то же TCP соединение для загрузки нескольких ресурсов. Это позволяет сократить время на установку соединения TCP, нет необходимости каждый раз проходить процедуру трехкратного рукопожатия.

В стандарте http 1.0 не было поддержки постоянного соединения, эта возможность была добавлена уже после публикации стандарта в виде заголовка connection: keep-alive. В стандарте http 1.1 все соединения по умолчанию постоянны и заголовок connection: keep-alive использовать не обязательно.

Мы рассмотрели кэширование web и его поддержку в протоколе http. Если в страницу, ввести какой-то ресурс из кэша, то загрузка происходит значительно быстрее, чем если мы обращаемся за тем же самым ресурсом в сеть. Необходимо иметь ввиду, что данные кэшируется не только в кэше web-браузера, это так называемый частный кэш, который является отдельным для каждого пользователя, но и данные могут быть закэшированные в других местах. Например, на прокси-серверах, на обратных прокси-серверах, которые копируют запросы большого количества пользователей и такой кэш называется разделяемый.