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

Фреймы HTTP/2

Сообщения HTTP/1.x имеют несколько недостатков в отношении производительности:

• Заголовки, в отличие от тел, не сжимаются.
• Заголовки, которые зачастую практически совпадают у идущих подряд сообщений, приходится передавать по отдельности.
• Мультиплексность невозможна. Приходится открывать соединение для каждого сообщения, а тёплые (warm) соединения TCP эффективнее холодных (cold).

HTTP/2 переходит на новый уровень: он делит сообщения HTTP/1.x на фреймы, которые внедряются в поток. Фреймы данных из заголовков отделены друг от друга, что позволяет сжимать заголовки. Несколько потоков можно объединять друг с другом — такой процесс называется мультиплексированием — что позволяет более эффективно использовать TCP-соединения.

Фреймы HTTP сейчас прозрачны для веб-разработчиков. Это дополнительный шаг, который HTTP/2 делает по отношению к сообщениям HTTP/1.1 и лежащему в основе транспортному протоколу. Для реализации фреймов HTTP веб-разработчикам не требуется вносить изменения в имеющиеся APIs; если HTTP/2 доступен и на сервере, и на клиенте, он включается и используется.

URL¶

См.также

https://ru.wikipedia.org/wiki/URL

URL (Uniform Resource Locator) – унифицированный указатель на ресурс.

Основным объектом манипуляции в HTTP является ресурс, на который указывает
URL в запросе клиента. Список всех доступных ресурсов сайта образуют дерево,
в котором каждая ветка будет являться адресом URL.

Дерево доступных ресурсов сайта

Ресурсы представляют из себя либо реальные файлы на сервере, например: HTML,
js, png, …, либо логические сущности, которые генерируют содержимое на лету
(в момент поступления запроса), например: список новостей, погода, фотогалерея,
каталог товаров и прочее. Соответственно такие ресурсы называют статическими
(неизменными) или динамическими.

Еще существуют абстрактные ресурсы, которые присутствуют в пути но этот
адрес самостоятельно не существует, например:

• http://example.com/ – главная страница сайта
• http://example.com/blog/ – список статей
• http://example.com/blog/article/1 – статья 1 в блоге
• http://example.com/blog/article/ – абстрактный ресурс, который присутствует
  в пути, но реально его не существует. По данной ссылке сервер вернет ошибку
  404 Not Found. Такие ресурсы нужны для большей читаемости URL и
  семантического разделения сущностей.

URI

См.также

• https://ru.wikipedia.org/wiki/URI
• URI,URL,URN

URL является подмножеством более широкого термина URI (Uniform Resource
Identifier), который обобщает вид различных идентификаторов.

Примеры URI:

ldap:///c=GB?objectClass?one

mailto:John.Doe@example.com

news:comp.infosystems.www.servers.unix

tel:+1-816-555-1212

telnet://192.0.2.16:80/

ftp://ftp.is.co.za/rfc/rfc1808.txt

http://www.ietf.org/rfc/rfc2396.txt

urn:oasis:names:specification:docbook:dtd:xml:4.1.2

URN

См.также

https://ru.wikipedia.org/wiki/URN

URN (Uniform Resource Name) — идентифицирует путь до ресурса.

Пример:

• URI =
• URL = http://lectureskpd.readthedocs.io
• URN = /kpd/3.http.html

Идентификатор ресурса можно представить в виде формулы:

URI = URL + URN

Примечание

В обществе URI часто назвают как URL.

Структура URL

См.также

http://www.ietf.org/rfc/rfc3986.txt

Структура URL представлена на схеме ниже:

 foo://example.com:8042/over/there?name=ferret#nose
 \_/   \______________/\_________/ \_________/ \__/
  |           |            |            |        |
схема   имя(IP) и порт    путь        запрос   элемент
  |   _____________________|__
 / \ /                        \
 urn:example:animal:ferret:nose

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

• ws
• ftp
• http
• https
• file
• mailto
• xmpp

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

• user:123
• user

Адрес ресурса

<схема>://<логин>:<пароль>@ <хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

• localhost:8080
• yandex.ru
• 213.180.204.11
• 127.0.0.1:6543
• yandex.ru:80
• 192.168.0.13:22

Пара <хост>:<порт> называется INET SOCKET или просто сокет, определяет
входную точку приложения и идентифицирует адрес по которому с ним можно
связаться.

HTTP по умолчанию использует порт 80, это знают веб-сервера, поэтому его можно не указывать.

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

somedir/somefile.html

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>? <параметры>#<якорь>

text=foobar&from=fx3&lr=213

Якорь

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры># <якорь>

someanchor

Якорь указывает на расположение в самом документе.
Пример якоря

5 последних уроков рубрики «Разное»

• Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.

• Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

  Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

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

• Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Прогнозирование запросов ресурсов

В типичном веб-приложении клиент отправляет GET-запрос и получает страницу в формате HTML. Обычно это индексная страница сайта. Исследуя содержимое страницы, клиент может обнаружить, что для полной визуализации страницы ему необходимо извлечь дополнительные ресурсы, такие как файлы CSS и JavaScript. Клиент определяет, что эти дополнительные ресурсы ему нужны, только после получения ответа от исходного GET-запроса. Таким образом, он должен сделать дополнительные запросы для извлечения этих ресурсов и завершения соединения страницы. Эти дополнительные запросы в конечном итоге увеличивают время загрузки.

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

HTTP/1.1: встраивание ресурсов

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

Но со встраиванием ресурсов есть несколько проблем. Встраивание в документ HTML – целесообразное решение для небольших текстовых ресурсов, но большие файлы в нетекстовых форматах могут значительно увеличить размер HTML документа, что в конечном итоге может снизить скорость соединения и вообще свести на нет исходное преимущество этой техники. Кроме того, поскольку встроенные ресурсы больше не отделены от HTML-документа, у клиента нет механизма для сокращения ресурсов или для размещения ресурса в кэше. Если ресурсу требуется несколько страниц, каждый новый HTML-документ будет содержать в своем коде один и тот же ресурс, что приведет к увеличению размера HTML-документов и времени загрузки (обработка займет больше времени, чем если бы ресурс просто кэшировался в начале).

Таким образом, основным недостатком встраивания является то, что клиент не может разделить ресурс и документ. Для оптимизации соединения необходим более высокий уровень контроля, который HTTP/2 стремится предоставить с помощью Server Push.

HTTP/2: механизм Server Push

Поскольку HTTP/2 поддерживает множество одновременных ответов на первоначальный GET запрос клиента, сервер может отправить клиенту ресурс вместе с запрошенной HTML-страницей, предоставляя ресурс до того, как клиент запросит его. Этот процесс называется Server Push. Таким образом, HTTP/2-соединение может выполнить ту же задачу по встраиванию ресурсов, при этом сохраняя разделение между помещаемым ресурсом и документом. Это означает, что клиент может решить кэшировать или отклонить отправленный ресурс отдельно от основного HTML-документа. Так HTTP/2 устраняет основной недостаток встраивания ресурсов.

В HTTP/2 этот процесс начинается, когда сервер отправляет кадр PUSH_PROMISE, чтобы сообщить клиенту, что он собирается отправить ресурс. Этот кадр включает в себя только заголовок сообщения и позволяет клиенту заранее узнать, какой ресурс отправит сервер. Если ресурс уже кэширован, клиент может отклонить отправку, отправив в ответ кадр RST_STREAM. Кадр PUSH_PROMISE также предотвращает отправку дублированного запроса на сервер (поскольку клиент знает, какие ресурсы сервер собирается отправить).

Здесь важно отметить, что Server Push делает акцент на контроль клиента. Если клиенту необходимо отрегулировать приоритет Server Push или даже отключить его, он может в любое время отправить кадр SETTINGS для изменения этой функции HTTP/2

Несмотря на то, что функция Server Push имеет большой потенциал, она не всегда оптимизирует работу веб-приложения. Например, некоторые веб-браузеры не всегда могут отменить отправленные запросы, даже если клиент уже кэшировал ресурс. Если клиент по ошибке разрешает серверу отправлять дублирующийся ресурс, Server Push может израсходовать соединение. В конце концов, принудительный Server Push должен использоваться по усмотрению разработчика. Больше о том, как использовать Server Push стратегически и оптимизировать веб-приложения, можно узнать из шаблона PRPL, разработанного Google. Чтобы узнать больше о возможных проблемах, связанных с принудительным Server Push, читайте этот пост.

Что значит и где применяется HTTPS-протокол?

Ну, про обмен данными по протоколу HTTP вы уже все знаете: любая передача данных осуществляется через запросы по этому протоколу-транспорту. А зачем тогда нужен HTTPS и что он из себя представляет? Ведь жили же нормально и без него?

Проблема в том что данные по HTTP не защищаются и передаются в открытом виде. Интернет — глобальная распределенная сеть узлов. И если вы передаете открытые данные по незащищенному протоколу (Wi-Fi в ТРЦ сюда тоже относится), то один из этих узлов может перехватить их.

Не специально конечно, может быть просто взлом усилиями злоумышленников. HTTPS и создан для того чтобы соединение было безопасным, а данные передавались в зашифрованном виде по криптографическому протоколу SSL/TLS. Это специальная «обертка» поверх HTTP, она шифрует данные, делая их недоступными для злоумышленников и посторонних людей.

HTTPS — англ. «безопасный протокол передачи гипертекста».

Так что в отличие от 80 порта, используемого по умолчанию в HTTP, в HTTPS используется TCP-порт 443 и есть ключ для шифрования. Ключ может быть длиной 40, 56, 128 или 256 бит, достаточный уровень безопасности на данный момент начинается со 128-битных ключей.

Сейчас все браузеры поддерживают HTTPS — он включается автоматически, когда есть возможность и этого требует сервер.

Жизненно важно использовать HTTPS в следующих сервисах:

• Электронные платежные системы (банки, электронные деньги и прочее);
• Сервисы принимающие и отправляющие приватную информацию и персональные данные, например у Яндекса это: Паспорт, Такси, Директ, Метрика, Почта, Деньги, Вебмастер и другие;
• Социальные сети и личные кабинеты в интернет-сервисах;
• Поисковые системы.

Работает HTTPS просто. Объясню на примере.

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

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

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

Все — вот так просто работает HTTPS.

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

Единственный нюанс здесь — надо знать, что вы отправляете данные именно туда, куда нужно. И что конечный пункт и является пунктом назначения. Но нужно подтвердить и точно знать, что конечный адресат существует и управляется тем самым сервером, куда отправляются данные.

Для этого серверы получают в центрах сертификации специальные HTTPS-сертификаты безопасности, которые подтверждают «конечность» пункта назначения (что сайт не является узлом передающим данные дальше) и работоспособность технологии шифрования SSL/TLS, т.е. безопасность соединения.

А вот как выглядит сам сертификат:

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

Осуществляя взаимодействие «клиент-сервер» по протоколу HTTPS можно не беспокоиться за сохранность данных — вы надежно защищены от прослушивания сетевого соединения: атак снифферов и man-in-the-middle.

Что означает перечеркнутый значок HTTPS и зеленый значок HTTPS, в чем разница? В безопасности. Зеленый — безопасный, красный и перечеркнутый — небезопасный.

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

Specifications, Drafts, Papers and Reports

HTTP Working Group

• List of all HTTP RFCs
  • RFC 2616:
    Hypertext Transfer Protocol — HTTP/1.1
  • RFC 2617: HTTP
    Authentication: Basic and Digest Access Authentication
• Previous HTTP specifications and drafts. If
  you are looking for previous drafts then have a look at the HTTP draft specification change history
• The IETF HTTP working
  group list of Internet drafts and RFCs
• The Distributed
  Authoring and Versioning working group maintains a list of their
  drafts
• David M. Kristol maintains a page on HTTP
  State Management — a.k.a. cookies
• Koen Holtman maintains a page on transparent HTTP content
  negotiation

Related Protocols

HTTP Extension Framework

An extension mechanism for HTTP designed to address the tension
between private agreement and public specification and to accommodate
extension of HTTP clients and servers by software components

Multiplexing Protocol (MUX)

A draft proposal for introducing asynchronous messaging support at a
layer below HTTP

Handling of
fragment identifiers in redirected URLs

An Internet Draft with a proposal for an issue that HTTP leaves
unspecified.

HTTP-NG — Hypertext Transfer Protocol — Next
Generation

a former W3C Activity on reengineering the basic protocol
architecture by using modularity, simplicity and layering.

Background

• Overview of Time — What is the state of time on the
  Internet?
• Interesting Papers and MUST
  reads! A collection of papers from work shops, conferences etc.
• — also check out the comprehensive
  compression overview
• Classic HTTP Documents — read how it all
  started

Other Areas and Protocols

• The HTTP-NG activity has information about  the former W3C
  HTTP-NG Activity
• The Propagation, Caching and Replication
  area has a lot of information about caching schemes and scalability
• Internet Message Access Protocol
  (IMAP) is a method of accessing electronic mail or bulletin board
  messages that are kept on a (possibly shared) mail server
• Next Generation Internet (NGI)
  Initiative. On October 10, 1996, President Clinton and Vice President
  Gore announced their commitment to the Next Generation Internet (NGI)
  Initiative, based upon strong research and development programs across
  Federal agencies.
• The Web Robots Pages —
  information about Web robots and how to manage them
• What’s the Internet
  weather like? A really useful service from UCLA
• A few other Internet protocols
  relevant to HTTP

Yves Lafon
, @(#) $Id: Overview.html,v 1.244 2014-06-11 14:21:46 ylafon Exp $

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

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

HTTP
Упорство Сжатие HTTPS QUIC
ПОЧТОВЫЙ ПЛАСТЫРЬ
Поля заголовка
Cookie-файлы ETag Место расположения HTTP-реферер DNT X-Forwarded-For
Коды состояния
301 перемещен навсегда 302 Найдено 303 См. Другое 403 Запрещено 404 Не Найдено 451 Недоступно по юридическим причинам
Методы контроля доступа безопасности
Базовая аутентификация доступа Дайджест-проверка подлинности доступа
Уязвимости безопасности
Внедрение HTTP-заголовка Контрабанда HTTP-запросов Разделение HTTP-ответа Загрязнение параметров HTTP

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

HTTP сообщения

HTTP/1.1 и более ранние HTTP сообщения человеко-читаемы. В версии HTTP/2 эти сообщения встроены в новую бинарную структуру, фрейм, позволяющий оптимизации, такие как компрессия заголовков и мультиплексирование. Даже если часть оригинального HTTP сообщения отправлена в этой версии HTTP, семантика каждого сообщения не изменяется и клиент воссоздаёт (виртуально) оригинальный HTTP-запрос. Это также полезно для понимания HTTP/2 сообщений в формате HTTP/1.1.

Существует два типа HTTP сообщений, запросы и ответы, каждый в своём формате.

Примеры HTTP запросов:

Запросы содержат следующие элементы:

• HTTP-метод, обычно глагол подобно , или существительное, как или , определяющее операцию, которую клиент хочет выполнить. Обычно, клиент хочет получить ресурс (используя ) или передать значения HTML-формы (используя ), хотя другие операция могут быть необходимы в других случаях.
• Путь к ресурсу: URL ресурсы лишены элементов, которые очевидны из контекста, например без protocol (), domain (здесь ), или TCP port (здесь ).
• Версию HTTP-протокола.
• Заголовки  (опционально), предоставляющие дополнительную информацию для сервера.
• Или тело, для некоторых методов, таких как , которое содержит отправленный ресурс.

Примеры ответов:

Ответы содержат следующие элементы:

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