Протокол http. основные типы http запросов

Как подключить http/2

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

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

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

Для подключения HTTP/2 нет необходимости вносить какие-либо изменения непосредственно на ресурсе. URL страниц, ссылки, разметки, данные для Яндекс.Вебмастера и Google Search Console – все остается без изменений.

Протокол подключается на отдающем данные сервере, то есть, сервере хостера. Если у вас внешний хостинг, скорее всего страницы сайта передаются на http/2 для всех браузеров.

В случае с собственным виртуальным или выделенным сервером,
поддержку протокола необходимо внедрить на уровне модуля к серверу Nginx или
Apache.

Nginx

Протокол поддерживается в версиях сервера от 1.9.5 и новее, так что обязательно обновите устаревший Nginx. Далее запустите файл, расположенный по пути /etc/nginx/nginx.conf. Найдите секцию Сервер со строкой:

Поменяйте ее на

Сохраните изменения и перезапустите сервер при помощи
команды:

Apache

Для подключения протокола http/2 вам понадобится версия сервера от 2.4.17 и новее. Если у вас устаревшая версия Apache, обновите его и подключите mod http2.

Затем откройте файл apache.conf и добавьте в него следующие команды:

Далее остается лишь перезапустить сервер. Все готово.

Если вы хотите проверить, поддерживается ли HTTP/2, скачайте специальное расширение для Chrome или Firefox. Можно воспользоваться и сервисом проверки скорости Айри. Если протокол поддерживается, в результатах проверки отобразится соответствующая зелена надпись.

Идентификация и аутентификация

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

Существует несколько мер, при помощи которых сервер извлекает эту информацию, и большинство веб-сайтов используют гибридные методы:

• Заголовки запросов: From, Referer, User-Agent – их мы уже рассмотрели в части 1
• Client-IP — IP адрес клиента,
• Fat Urls — Сохранение состояния текущего пользователя, изменив URL и перенаправив на другой URL после каждого клика; каждый клик, по сути, накапливает состояние,
• Cookies — самый популярный и ненавязчивый подход.

Cookies позволяют серверу передавать обязательную информацию для исходящих сообщений с помощью заголовка ответа Set-Cookie. Cookie устанавливается с одной или более парой имя=значение, разделенных точкой с запятой (;), например: Set-Cookie: session-id=12345ABC; username=nettuts.

Сервер также может ограничить Cookie для конкретного домена или его части (domain и path),что делает их стойкими (неизменными) к истекающим значениям (expires). Cookies автоматически отсылаются браузером при каждом запросе к серверу, и браузер гарантирует, что в запросе отправлены только специальные domain- и path- cookies-сы. Заголовок запроса Cookie: name=value используется для отправки этих cookies на сервер.

“Лучший способ определить пользователя — попросить зарегистрироваться на сайте, но чтобы это реализовать потребуются усилия как со стороны разработчика, так и со стороны пользователя.”

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

HTTP 1.1 — что это за протокол?

HTTP (англ. «протокол передачи гипертекста») — сетевой протокол верхнего уровня для передачи гипертекстовых и произвольных данных в интернете.

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

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

Актуальная версия протокола — 1.1. Ее описание находится в спецификации RFC.

HTTP используется в клиент-серверной инфраструктуре передачи данных. Как это работает? Приложение на стороне «клиент» формирует запрос для обработки на стороне «сервер», после чего ответ отправляется обратно «клиенту». Затем «клиент» может инициировать дополнительные запросы, получать новые ответы. И так далее.

Наиболее распространенное «клиентское» приложение это веб-браузер через который осуществляется доступ к веб-ресурсам. С развитием мобильных технологий к браузерам добавились еще мобильные приложения на разнообразных смартфонах и планшетах. Причем серверная сторона современных многопрофильных приложений может одновременно обрабатывать данные и из браузера, и со смартфона. Все это через протокол HTTP.

Более того, HTTP часто выступает как протокол-транспорт для трансфера других прикладных протоколов и их API: WebDAV, XML-RPC, REST, SOAP. Ну а данные передаваемые по API могут иметь самый разный формат: XML, JSON и другие.

Как передаются эти данные? Чаще всего по TCP/IP-соединению: приложение-клиент по умолчанию использует TCP-порт 80, а сервер может использовать любой другой, но обычно это тоже 80 порт.

Объект манипуляций в HTTP это ресурс, указываемый в URI запроса клиентского приложения, чтобы корректно идентифицировать «что вообще нужно». Обычно это файлы, данные или логические объекты, которые хранятся на сервере. При этом в запросе можно указать, как именно представить одни и те же данные: какой выбрать формат, кодировку, язык. Такая «фича» позволяет обмениваться не только гипертекстом, но и двоичными данными.

Второй особенностью HTTP является отсутствие сохранения состояния между последовательными парами «запрос-ответ». Но это не проблема, потому что компоненты приложений на клиентской или серверной стороне само могут хранить информацию о состоянии последних запросов и ответов. На стороне клиента такая информация называется cookies («куки»), на стороне сервера — sessions («сессии»).

При этом для клиентского браузера не проблема следить за задержкой ответа сервера, а для сервера — хранить заголовки последних запросов и IP-адреса клиентов. Но, еще раз подчеркну, сам протокол об этом ничего не знает — он только передает данные.

Принимать участие в передаче данных могут и посредники (прокси-сервера), для того чтобы отличить прокси от конечных серверов (т.н. «исходный сервер»).

Самое волшебство начинается, когда одна и та же программа (клиентская или серверная) может выполнять функции посредник, клиента, сервера — в зависимости от задач.

Оптимизация

Оптимизация с помощью HTTP keep-alive

Протокол HTTP работает поверх протокола TCP («Transmission Control Protocol»). TCP — это надёжный протокол двусторонней передачи потока данных. TCP работает, пересылая пакеты данных от клиента к серверу и обратно. TCP-пакет состоит из заголовка и данных. В заголовке указаны, помимо прочего, IP-адреса клиента и сервера, номера TCP-портов, используемых на клиенте и сервере, и набор флагов. Для HTTP на сервере обычно используется стандартный TCP-порт номер 80.

TCP-соединение между клиентом и сервером устанавливается с помощью классического «TCP three-way handshake». Сначала клиент посылает серверу пакет с флагом SYN. В ответ сервер посылает пакет с флагами SYN+ACK. Наконец, клиент посылает ещё один пакет, с флагом ACK и с этой минуты соединение считается установленным, и клиент может посылать свои данные, в нашем случае — HTTP-запрос.
Понятно, что если десяток тысяч браузеров установит с сервером keep-alive соединение, то они достаточно быстро исчерпают его ресурсы. Поэтому во всех серверах есть конфигурируемый тайм-аут, по истечении которого keep-alive соединение разрывается, если на нём не было никакой активности.

Клиент может запросить разрыв соединения после ответа, передав в запросе заголовок Connection: close. Аналогично, сервер может сообщить в ответе, что не желает поддерживать keep-alive соединение, передав точно такой же заголовок: Connection: close. Вообще говоря, все эти расшаркивания с взаимным уведомлением, строго говоря, не налагают никаких обязанностей. И сервер, и клиент должны быть полностью готовы к тому, что соединение прервётся в любой момент времени по инициативе другой стороны без каких-либо уведомлений.

Для того, чтобы соблюсти целостность keep-alive соединения, сервер должен знать длину ответа. Самый простой способ — указать её в заголовке Content-Length. Если длина ответа не указана обработчиком, то сервер вынужден перед отправкой ответа установить заголовок Connection: close и закрыть соединение со своей стороны после отправки ответа.

Оптимизация с помощью компрессии

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

Способность принимать компрессированное содержимое клиент анонсирует серверу с помощью заголовка Accept-Encoding: gzip. Если сервер настроен на сжатие соответствующего контента, то он может добавить заголовок ответа Content-Encoding: gzip (не путать с Transfer-Encoding) и отправить клиенту сжатое содержимое.

Оптимизация с помощью HTTP-pipelining

Когда мы делаем серию запросов и ответов в рамках одного keep-alive соединения, важную роль в производительности играет время задержки (latency) между запросом и ответом. Задержка может быть вызвана как высокой задержкой на канале, так и большим временем обработки запросов на сервере. Перед посылкой очередного запроса мы должны дождаться завершения обработки следующего. Чтобы справиться с этой проблемой, может использоваться технология HTTP-pipelining.

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

См. Также [ править ]

• Сравнение протоколов передачи файлов
• Протокол ограниченного приложения — семантически подобный протоколу HTTP, но с использованием UDP- или UDP-подобных сообщений, предназначенных для устройств с ограниченными возможностями обработки; повторно использует HTTP и другие интернет-концепции, такие как тип интернет-носителя и веб-ссылки (RFC 5988)
• Согласование содержания
• Дайджест-проверка подлинности доступа
• HTTP-сжатие
• HTTP / 2 — разработан рабочей группой IETF по протоколу передачи гипертекста (httpbis)
• HTTP-MPLEX — усовершенствованная версия HTTP с обратной совместимостью для улучшения времени поиска страниц и веб-объектов в перегруженных сетях, предложенная Робертом Маттсоном.
• Список полей заголовка HTTP
• Список кодов состояния HTTP
• Передача репрезентативного состояния (REST)
• Вариант объекта
• Веб-кеш
• WebSocket

HTTP-заголовки

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

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

Заголовки запросов

К числу наиболее важных HTTP-заголовков, которые можно включать в запросы, но нельзя включать в ответы, относятся:

Заголовок Accept

Это список MIME-типов, принимаемых клиентом, в формате тип/подтип. Элементы списка должны разделяться запятыми:

Accept: text/html, image/gif, */*

Элемент */* указывает, что все типы будут приняты и обработаны клиентом. Если тип запрошенного файла не может быть обработан клиентом, возвращается ошибка HTTP 406 «Not acceptable» (недопустимо).

Заголовок From

Указывает адрес электронной почты в Интернете учетной записи пользователя, под которой работает клиент, направивший запрос:

From: alexerohinzzz@gmail.com

Заголовок Referer

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

Referer: http://www.professorweb.ru

Заголовок User-Agent

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

User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko) 
   Chrome/24.0.1312.56 Safari/537.17

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

Заголовки ответов

В ответы могут включаться следующие заголовки:

Заголовок Content-Type

Используется для указания типа данных, отправляемых получателю или, в случае метода HEAD, тип данных, который был бы отправлен в ответ на запрос GET:

Content-Type: text/html

Заголовок Expires

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

Expires: Fri, 19 Aug 2012 16:00:00 GMT

Заголовок Location

Определяет точное расположение другого ресурса, к которому может быть перенаправлен клиент. Если это значение представляет собой полный URL, сервер возвращает клиенту «redirect» для непосредственного извлечения указанного объекта:

Location: http://www.samplesite.com

Если ссылка на другой файл относится к серверу, должен указываться частичный URL.

Заголовок Server

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

Server: Microsoft-IIS/7.0

Общие заголовки

Несколько заголовков могут включаться как в запрос, так и в ответ, например:

Заголовок Date

Используется для установки даты и времени создания сообщения:

Date: Tue, 16 Aug 2012 18:12:31 GMT

Заголовок Connection

В НТТР/1.0 мы могли использовать в запросе заголовок Connection, указывая, что хотим сохранить соединение после отправки ответа. Теперь такое поведение принято по умолчанию, и в HTTP/1.1 можно использовать заголовок Connection, чтобы указать, что постоянное соединение не нужно:

Connection: close

Ссылки [ править ]

1. ^ Филдинг, Рой Т .; Геттис, Джеймс; Могул, Джеффри С.; Нильсен, Хенрик Фристик; Масинтер, Ларри; Лич, Пол Дж .; Бернерс-Ли, Тим (июнь 1999 г.). . IETF . DOI . RFC .
2. . . caniuse.com . Проверено 2 июня 2020 .
3. . IETF. Июль 2014 г. RFC .
4. Belshe, M .; Peon, R .; Томсон, М. . Проверено 10 февраля 2015 .
5. Бенджамин, Дэвид. . tools.ietf.org . Проверено 2 июня 2020 . Это снижает барьер для развертывания TLS 1.3, что является значительным улучшением безопасности по сравнению с TLS 1.2.
6. Епископ, Майк (9 июля 2019 г.). . tools.ietf.org . проект-ietf-quic-http-22 . Проверено 16 августа 2019 .
7. Cimpanu, Каталин. . ZDNet . Проверено 19 ноября 2018 .
8. Cimpanu, Каталин (26 сентября 2019). . ZDNet . Проверено 27 сентября 2019 года .
9. . Блог Cloudflare . 2019-09-26 . Проверено 30 октября 2019 .
10. . 2019-11-19 . Проверено 23 января 2020 .
11. . . п. 12. сек. 1.4. DOI . .
12. . W3.org. 1998-05-14 . Проверено 1 августа 2010 .
13. Бернерс-Ли, Тим. . Консорциум World Wide Web . Проверено 31 августа 2010 года .
14. Тим Бернерс-Ли . . Консорциум World Wide Web . Проверено 24 июля 2010 года .
15. Рэггетт, Дэйв. . Консорциум World Wide Web . Проверено 11 июня 2010 года .
16. Рэггетт, Дэйв; Бернерс-Ли, Тим. . Консорциум World Wide Web . Проверено 29 сентября 2010 года .
17. Рэггетт, Дэйв. . Консорциум World Wide Web . Проверено 29 сентября 2010 года .
18. . Webcom.com Глоссарий . Архивировано из на 2001-11-21 . Проверено 29 мая 2009 .
19. ^ Филдинг, Рой Т .; Решке, Джулиан Ф. (июнь 2014 г.). . IETF. DOI . RFC .
20. ^ . . п. 31. сек. 4. DOI . .
21. . 090502 apacheweek.com
22. Бернерс-Ли, Тим; Филдинг, Рой Т .; Нильсен, Хенрик Фристик. . . IETF. С. 30–32. сек. 8. дои . RFC .
23. . . С. 51–57. сек. 9. дои . .
24. . Tools.ietf.org . Проверено 26 июня 2019 .
25. . Tools.ietf.org . Проверено 26 июня 2019 .
26. . Tools.ietf.org . Проверено 26 июня 2019 .
27. Джейкобс, Ян (2004). . Находки группы технической архитектуры . W3C . Проверено 26 сентября 2010 года .
28. . . п. 54. сек. 9.5. DOI . .
29. . . п. 55. сек. 9.6. DOI . .
30. . . IETF. Июнь 1999. с. 57. сек. 9.9. DOI . RFC . Проверено 23 февраля 2014 года .
31. Khare, Рохит; Лоуренс, Скотт (май 2000 г.). . IETF. DOI . RFC .
32. . US-CERT . 2002-05-17 . Проверено 10 мая 2007 .
33. Дюссо, Лиза; Снелл, Джеймс М. (март 2010 г.). . IETF. DOI . RFC .
34. . . п. 36. сек. 5.1.1. DOI . .
35. ^ Эдигер, Брэд (21 декабря 2007 г.). . O’Reilly Media, Inc. стр. 188. ISBN
36. Кантрелл, Кристиан (2005-06-01). . Блоги Adobe . Adobe. Архивировано из на 2017-08-19 . Проверено 19 ноября 2018 .
37. ^ . OWASP . Проверено 22 июня 2016 .
38. . . сек. 3.7.1. DOI . .
39. . . п. 39. сек. 6.1. DOI . .
40. Канаван, Джон (2001). Основы сетевой безопасности . Норвуд, Массачусетс: Artech House. С. 82–83. ISBN .
41. Залевски, Михал. . Проверено 30 апреля 2015 года .
42. . Проверено 30 апреля 2015 года .
43. . Проверено 30 апреля 2015 года .
44. Луотонен, Ари; Франкс, Джон (22 февраля 1996 г.). . IETF. Идентификатор draft-ietf-http-range-retrieval-00.
45. Ноттингем, Марк (октябрь 2010 г.). . IETF. DOI . RFC .
46. . IETF. 2012 г.

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)

Приложение C. Собранный ABNF

В приведенной ниже ABNF правила списка расширены в соответствии с .

Authorization = credentials

BWS = <BWS, смотри , >

OWS = <OWS, смотри , >

Proxy-Authenticate = *( «,» OWS ) challenge *( OWS «,» )
Proxy-Authorization = credentials

WWW-Authenticate = *( «,» OWS ) challenge *( OWS «,» )

auth-param = token BWS «=» BWS ( token / quoted-string )
auth-scheme = token

challenge = auth-scheme [ 1*SP ( token68 / [ ( «,» / auth-param ) *( OWS «,» ) ] ) ]
credentials = auth-scheme [ 1*SP ( token68 / [ ( «,» / auth-param ) *( OWS «,» ) ] ) ]

quoted-string = <quoted-string, смотри , >

token = <token, смотри , >
token68 = 1*( ALPHA / DIGIT / «-» / «.» / «_» / «~» / «+» / «/» ) *»=»

3.1 Версия HTTP.

HTTP использует схему нумерации типа «<major>.<minor>», для указания
версии протокола. Стратегия версификации протокола предназначена
для того, чтобы позволить отправителю указать формат сообщения и
свои способности понимания для дальнейшей HTTP связи, прежде чем
он получит что-либо посредством этой связи. При добавлении
компонентов сообщения, которые не воздействуют на поведение
связи, или компонентов, которые добавляются только к расширяемым
значениям поля, номер версии не меняется. Когда внесенные в протокол
изменения добавляют возможности, которые не изменяют общий алгоритм
анализа сообщений, но которые расширяют семантику сообщения и
подразумевают дополнительные возможности отправителя, увеличивается
<Minor> номер. Когда формат сообщения протокола изменяется
увеличивается <Major> номер.

Версия HTTP сообщения обозначается полем HTTP-version в первой
строке сообщения.

          HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

Обратите внимание, что major и minor числа ДОЛЖНЫ обрабатываться
как отдельные целые числа и что каждое может состоять более чем из
одной цифры. Таким образом, HTTP/2.4 — более низкая версия, чем
HTTP/2.13, которая в свою очередь ниже чем HTTP/12.3

Нули ДОЛЖНЫ
игнорироваться получателями и НЕ ДОЛЖНЫ посылаться.

Приложения, посылающие сообщения запросов или ответов, которые
описывает эта спецификация, ДОЛЖНЫ включить HTTP версию
(HTTP-version) «HTTP/1.1». Использование этого номера версии
указывает, что посылающее приложение по крайней мере условно
совместимо с этой спецификацией.

HTTP версия приложения — это самая высокая HTTP версия, для которой
приложение является по крайней мере условно совместимым.

Приложения, реализующие прокси-сервера и шлюзы, должны быть
внимательны, когда пересылают сообщения протокола различных версий.
Начиная с момента, когда версия протокола указывает возможности
отправителя, прокси-сервер/шлюз никогда НЕ ДОЛЖЕН посылать
сообщения, версия которых больше, чем HTTP версия отправителя; если
получена более высокая версия запроса, то прокси-сервер/шлюз ДОЛЖЕН
или понизить версию запроса, отдав сообщение об ошибке, или
переключиться на туннельное поведение. У запросов, версия которых
ниже, чем HTTP версия прокси-сервера/шлюза МОЖНО перед пересылкой
увеличить версию; ответ прокси-сервера/шлюза на этот запрос ДОЛЖЕН
иметь ту же самую major версию, что и запрос.

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

Различие между 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, поскольку это еще более безопасный способ шифрования данных, который будет отправляться.

Ссылки

8.1. Нормативные ссылки

Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, June 2014.

Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, June 2014.

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Caching», RFC 7234, June 2014.

8.2. Информационные ссылки

Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, September 2004.

van der Stock, A., Ed., «A Guide to Building Secure Web Applications and Web Services», The Open Web Application Security Project (OWASP) 2.0.1, July 2005, <https://www.owasp.org/>.

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, «HTTP Authentication: Basic and Digest Access Authentication», RFC 2617, June 1999.

Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

Josefsson, S., «The Base16, Base32, and Base64 Data Encodings», RFC 4648, October 2006.

Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.