Строка https

Несколько веб-сайтов HTTPS на одном IP-адресе

Для устранения этого ограничения было разработано расширение к протоколу TLS под названием Server Name Indication (SNI). Его должны поддерживать и сервер, и клиент. И хотя поддержка SNI сегодня широко распространена, она всё-таки не гарантирована на 100%, если для вас важна гарантия совместимости со всеми возможными клиентами.

Подробности о запуске SNI под Apache, nginx и IIS (8+) см. в соответствующей документации.

Что такое HTTP‑ и HTTPS‑протоколы

Чтобы понять, что такое HTTPS, сначала надо разобраться с HTTP.

HTTP (HyperText Transfer Protocol) — это протокол передачи данных в интернете. Он был создан для обмена гипертекстовыми (HTML) документами — такими, как веб‑страницы и изображения, — между сервером и браузером.

В адресной строке сайта, который использует HTTP, будет написано “http://”. Сейчас сайты практически не используют такой протокол.

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

HTTPS (HyperText Transfer Protocol Secure) — более безопасное расширение HTTP; оно обеспечивает безопасность при передаче конфиденциальной информации.

Если сайт использует HTTPS, то адрес начинается с “https://” вместо “http://”.

Сайт, использующий HTTPS

HTTPS отличается от HTTP тем, что он шифрует данные, которые передаются между сервером и браузером, чтобы защитить их от злоумышленников. Это делается с помощью SSL‑сертификата, подробнее о котором мы расскажем ниже.

Let’s Encrypt

Процитируем сайт Let’s Encrypt:

Let’s Encrypt — это бесплатный, автоматизированный и открытый центр сертификации (CA), который работает для общественного блага. Сервис Let’s Encrypt предоставляется Internet Security Research Group (ISRG).

Ключевые принципы Let’s Encrypt:Бесплатность
Любой владелец доменного имени может использовать Let’s Encrypt для получения бесплатного доверенного сертификата. Автоматизация
Программное обеспечение на веб-сервере может взаимодействовать с Let’s Encrypt для безболезненного получения сертификата, безопасной конфигурации его и автоматического продления. Безопасность
Let’s Encrypt служит платформой для лучших методов продвинутой защиты TLS, как на стороне центра сертификации, так и помогая операторам веб-сайтов правильно обезопасить свои сервера. Прозрачность
Все выданные или отозванные сертификаты будут публично записаны и доступны для просмотра кем угодно. Открытость
Протокол автоматической выдачи и продления будет опубликован как открытый стандарт, который могут использовать другие. Сотрудничество
Во многом как протоколы, лежащие в основе Интернета, Let’s Encrypt — это совместный проект для блага сообщества, неподконтрольный какой-либо организации.

Чтобы воспользоваться преимуществами Let’s Encrypt, нужно правильно настроить свой аккаунт на хостинге или сервере. Let’s Encrypt выдаёт краткосрочные сертификаты, которые следует регулярно обновлять, чтобы веб-сайт HTTPS оставался работоспособным.

Как это работает

Есть некоторые существенные отличия в работе Let’s Encrypt и других центров сертификации. В соответствии с тремя первыми пунктами, перечисленными выше, вот эти отличия:

Ограничения

Let’s Encrypt выдаёт только сертификаты DV. Сертификаты OV и EV не поддерживаются, и в данный момент нет планов их поддержки. Выдаются сертификаты на один или несколько доменов, но в данный момент нет сертификатов с поддоменами (подстановочными знаками). Для получения дополнительной информации см. Let’s Encrypt FAQ.

Автоматический режим работы Let’s Encrypt навязывает некоторые ограничения на использование, чтобы защитить инфраструктуру от умышленных и неумышленных злоупотреблений. Лимиты на интенсивность использования достаточно высоки, чтобы помешать обычным пользователям даже с сотнями доменов в распоряжении. Но если вы управляете сертификатами HTTPS в очень больших масштабах, то стоит ознакомиться с этими лимитами.

Более старые и экзотические клиенты (до Windows XP SP3) не поддерживаются. Подробности см. на странице совместимости.

Зачем переводить сайт на HTTPS

Google, Яндекс и другие поисковые системы не просто отдают предпочтение сайтам, использующим HTTPS, но и могут наказывать те ресурсы, которые не используют защищенный протокол.

Google о том, что HTTPS — сигнал для ранжирования

Шаг 2. Приобретение сертификата HTTPS

Чтобы получить сертификат для вашего веб-сайта, сначала купите кредит на сертификат HTTPS выбранного типа (DV, OV, EV, один сайт, несколько сайтов, поддомены — см. выше) у продавца сертификатов. По окончании процесса вам нужно будет отправить запрос на получение сертификата, который потратит купленный кредит для выбранного домена. Вас попросят предоставить (то есть вставить в поле для загрузки) весь текст CSR, включая строки ——BEGIN CERTIFICATE REQUEST—— и ——END CERTIFICATE REQUEST——. Если вам нужен сертификат EV или OV, то нужно будет указать юридическое лицо, для которого вы запрашиваете сертификат. У вас также могут попросить дополнительные документы, подтверждающие тот факт, что вы представляете эту компанию. Затем регистратор сертификатов проверит ваш запрос (и все сопутствующие документы) и выдаст подписанный сертификат HTTPS.

Получение сертификата HTTPS

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

Самоподписанные сертификаты

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

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

Можно создать самоподписанный сертификат на любой платформе, где есть OpenSSL.

openssl x509 -signkey example.com.key -in example.com.csr -req -days 365 -out example.com.crt

Всё программное обеспечение для работы с протоколом HTTP разделяется на три большие категории:

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

Первоначально протокол HTTP разрабатывался для доступа к гипертекстовым документам Всемирной паутины. Поэтому основными реализациями клиентов являются браузеры (агенты пользователя). Для просмотра сохранённого содержимого сайтов на компьютере без соединения с Интернетом были придуманы офлайн-браузеры. При нестабильном соединении для загрузки больших файлов используются менеджеры закачек; они позволяют в любое время докачать указанные файлы после потери соединения с веб-сервером. Некоторые виртуальные атласы (такие как Google Планета Земля и NASA World Wind) тоже используют HTTP.

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

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

Различия SSL сертификатов

SSL-сертификаты имеют несколько разновидностей. Они классифицируются следующим доверительным факторам:

1. Проверка в упрощенном виде — DV (domain validation). Подтверждение права на пользование доменом. Обычно такой сертификат можно получить бесплатно.

2. Стандартная проверка OV (organization validation). Кроме права на владение доменом, подтверждается фактическое существование организации.

3. Расширенная проверка EV (extended validation). Подтверждает большую степень доверия – к перечисленным выше факторам прибавляется правомерное осуществление работы компании.

Применяя SSL-сертификат для ресурса, его владелец автоматически увеличивает степень доверия потенциальных клиентов и поисковиков. В момент загрузки страницы в адресной строке появляется надпись «Защищено» или «Secure» — клиенты уже знают, что данные не попадут к мошенникам. Помимо безопасности, переход на HTTPS способствует повышению позиций сайта в поисковой выдаче и предупреждает уход потенциальных клиентов к конкурентам.

Hypertext Transfer Protocol (HTTP)

HTTP — это стандартный сетевой протокол, используемый для отправки запросов и ответов в вебе. H TTP-запросы в общем случае состоят из трёх компонентов:

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

Распространённые методы запросов:

Распространённые коды состояния, которые сервер может отправлять в качестве ответа:

Hypertext Transfer Protocol Secure (HTTPS) — это расширение HTTP, используемое для безопасных онлайн-коммуникаций. Этот протокол требует, чтобы у серверов были доверенные сертификаты и чтобы они использовали Transport Layer Security (TLS) — протокол безопасности, надстроенный поверх TCP и предназначенный для шифрования данных, передаваемых между клиентом и сервером.

Что запомнить

HTTP/1.1 200 OK
Date: Wed, 11 Feb 2009 11:20:59 GMT
Server: Apache
X-Powered-By: PHP/5.2.4-2ubuntu5wm1
Last-Modified: Wed, 11 Feb 2009 11:20:59 GMT
Content-Language: ru
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close
(пустая строка)
(запрошенная страница в HTML)

Аналогично выглядит ответ 203. Что существенно — непосредственно запрашиваемые данные отделены от HTTP-заголовков с помощью CR, LF, CR, LF.

Предположим, что у вымышленной компании «Example Corp.» есть основной сайт по адресу «http://example.com» и домен-псевдоним «example.org». Клиент посылает запрос страницы «О компании» на вторичный домен (часть заголовков опущена):

Так как домен «example.org» не является основным и компания не собирается в будущем его использовать в других целях, их сервер вернёт код для постоянного перенаправления, указав в заголовке Location целевой URL:

В заголовке Location можно указывать фрагменты как в данном примере. Браузер не указал фрагмент в запросе, так как его интересует весь документ. Но он автоматически прокрутит страницу до фрагмента «contacts», как только загрузит её. В тело ответа также был помещён короткий HTML-документ со ссылкой, с помощью которой посетитель попадёт на целевую страницу, если браузер не перейдёт на неё автоматически. Заголовок Content-Type содержит характеристики именно этого HTML-пояснения, а не документа, который находится по целевому URI.

Допустим, эта же компания «Example Corp.» имеет несколько региональных представительств по всему миру. И для каждого представительства у них есть сайт с соответствующим ccTLD. Запрос главной страницы основного сайта «example.com» может выглядеть так:

Сервер принял во внимание заголовок Accept-Language и сформировал ответ со временным перенаправлением на российский сервер «example.ru», указав его адрес в заголовке Location:

Обратите внимание на заголовок Cache-Control: значение «private» сообщает остальным серверам (в первую очередь прокси) что ответ может кэшироваться только на стороне клиента. В противном случае не исключено, что следующие посетители из других стран будут переходить всё время не в своё представительство.

Для перенаправления также используются коды ответа 303 (See Other) и 307 (Temporary Redirect).

Докачка и фрагментарное скачивание

В обоих случаях клиенты произведут свой первый запрос наподобие этого:

Заголовок Referer указывает, что файл был запрошен с главной страницы сайта. Менеджеры закачек обычно тоже его указывают, чтобы эмулировать переход со страницы сайта. Без него сервер может ответить 403 (Access Forbidden), если не допускаются запросы с других сайтов. В нашем случае сервер вернул успешный ответ:

HTTP/1.1 200 OK
Date: Thu, 19 Feb 2009 12:27:04 GMT
Server: Apache/2.2.3
Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT
ETag: «56d-9989200-1132c580»
Content-Type: video/x-msvideo
Content-Length: 160993792
Accept-Ranges: bytes
Connection: close

(двоичное содержимое всего файла)

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

Исходя из значения заголовка Content-Length, менеджер закачек поделит весь объём на равные фрагменты и запросит их по отдельности, организовав несколько потоков. Если сервер не укажет размер, то клиенту параллельное скачивание реализовать не удастся, но при этом он сможет докачивать файл, пока сервер не ответит 416 (Requested Range Not Satisfiable).

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

Сервер не обязан помнить, какие и от кого запросы были до этого, и поэтому клиент снова вставил заголовок Referer, как будто это его самый первый запрос. Указанное значение заголовка Range говорит серверу: «Выдай содержимое от 88080384-го байта до самого конца». В связи с этим сервер вернёт ответ:

HTTP/1.1 206 Partial Content
Date: Thu, 19 Feb 2009 12:27:08 GMT
Server: Apache/2.2.3
Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT
ETag: «56d-9989200-1132c580»
Accept-Ranges: bytes
Content-Range: bytes 88080384-160993791/160993792
Content-Length: 72913408
Connection: close
Content-Type: video/x-msvideo

(двоичное содержимое от 84-го мегабайта)

Заголовок Accept-Ranges здесь уже не обязателен, так как клиент уже знает об этой возможности сервера. О том, что передаётся фрагмент, клиент узнаёт по коду 206 (Partial Content). В заголовке Content-Range содержится информация о данном фрагменте: номера начального и конечного байта, а после слэша — суммарный объём всего файла в байтах. Обратите внимание на заголовок Content-Length — в нём указывается размер тела сообщения, то есть передаваемого фрагмента. Если сервер вернёт несколько фрагментов, то Content-Length будет содержать их суммарный объём.

Теперь вернёмся к менеджеру закачек. Зная суммарный объём файла «conf-2009.avi», программа поделила его на 10 равных секций.

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

GET /conf-2009.avi HTTP/1.0
Range: bytes=64397516-80496894

Ответ сервера в этом случае будет следующим (часть заголовков опущена — см. полный пример выше):

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 64397516-80496894/160993792
Content-Length: 16099379

(двоичное содержимое 4-й части)

Если подобный запрос отправить серверу, который не поддерживает фрагменты, то он вернёт стандартный ответ 200 (OK) как было показано в самом начале, но без заголовка Accept-Ranges.

См. также частичные GET, байтовые диапазоны, ответ 206, ответ 416.

Шаг 3. Установка сертификата HTTPS для своего веб-сайта

Проверьте, что у вас есть доступ к веб-сайту по адресу https://www.example.com. Если всё работает нормально, то вы, вероятно, захотите поставить постоянный редирект HTTP-трафика на HTTPS. Для этого нужно добавить несколько строчек в файл .htaccess (если у вас веб-сервер Apache) в корневой директории на своём сервере.

Если файл .htaccess уже существует, то вставьте только строчки RewriteCond и RewriteRule сразу после существующей директивы RewriteEngine On.

Linux, FreeBSD

Разместите в соответствующих директориях сгенерированный секретный ключ (example.com.key), запрос на подпись сертификата (example.com.csr) и действительный сертификат HTTPS (example.com.crt):

Файлы должны принадлежать руту и быть защищены настройкой разрешения 600.

Apache

Чтобы активировать HTTPS на своём сайте, нужно сделать следующее:

Начните с проверки mod_ssl. В зависимости от операционной системы, должен работать один из вариантов:

Если он не установлен или не работает, то попробуйте это:

Отредактируйте файл конфигурации Apache (httpd.conf):

Эта конфигурация была сгенерирована с помощью упомянутого ранее Mozilla SSL Configuration Generator. С его помощью проверьте актуальность конфигурации. Отредактируйте правильные пути для сертификата и секретного ключа. Показанная здесь конфигурация сгенерирована с промежуточными настройками — прочитайте об ограничениях и конфигурациях браузера для каждой настройки, прежде чем выбрать наиболее подходящую для себя.

В коде были сделаны некоторые изменения, чтобы обрабатывать редиректы с HTTP на HTTPS, а также с не-www на домен с www (полезно для задач SEO).

Nginx

Отредактируйте файл конфигурации nginx (nginx.conf):

Генератор автоматически генерирует код для обработки редиректов с HTTP на HTTPS и изначально активирует поддержку HTTP/2!

Internet Information Server под Windows

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

Тестирование сервера

После того, как ваш сервер сконфигурирован и начал работать по HTTPS, я настоятельно рекомендую проверить безопасность конфигурации при помощи Qualys SSL Server Test. Он сканирует ваш веб-сайт, в том числе выполняет всестороннюю оценку конфигурации, выявляет возможные слабости и даёт рекомендации. Следуйте его советам для ещё большего улучшения конфигурации защиты сервера.

Продление

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

Отзыв

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

Жизненный цикл запроса веб-страницы

Что же происходит, когда мы переходим на linkedin.com? Что делает браузер, чтобы запросить HTML для этой страницы с сервера LinkedIn? Чтобы ответить на эти вопросы, нам сначала нужно взглянуть на её URL. Полный URL может выглядеть примерно так: https://www.linkedin.com:443/feed. Давайте его разберём.

Мы рассмотрели основные части URL, но он может включать в себя и другие элементы. Например, параметры запросов — пары «ключ-значение», которые мы передаём серверу, чтобы предоставить ему больше информации, обычно для фильтрации контента. Также можно добавить фрагмент. В нём используется символ фунта #, после чего добавляется ID какого-то элемента в HTML и браузеры обрабатывают это, по умолчанию выполняя скроллинг к этому элементу.

Чтобы создать TCP-соединение, клиент должен инициировать подключение. Клиент делает это, отправляя пакет синхронизации (SYN), а сервер отвечает клиенту подтверждением синхронизации. Затем клиент отвечает серверу, подтверждая, что получил подтверждение синхронизации. Это называется подтверждением клиентом и сервером, а также трёхэтапным рукопожатием (three-way handshake).

После этого два компьютера подключены друг к другу по TCP, поэтому могут начать передавать HTTP-сообщения. Когда пользователь уходит с веб-сайта, соединение завершается. Для завершения этого TCP-соединения каждая из сторон отправляет другой стороне пакет завершения (fin), который другая сторона подтверждает. Это обозначает завершение соединения.

Типы SSL‑сертификатов для HTTPS

HTTPS шифрует данные с помощью особого SSL‑сертификата — его каждый сайт получает самостоятельно.

SSL‑сертификат (Secure Sockets Layer) — это цифровой сертификат, который подтверждает подлинность веб‑сайта и обеспечивает шифрование данных, передаваемых между сервером и браузером. S SL выдают центры сертификации (ЦС).

Так выглядит адрес сайта, получившего SSL‑сертификат

Так выглядит адрес сайта, у которого нет сертификата

SSL‑сертификаты бывают разных типов в зависимости от того, какой уровень проверки подлинности сайта необходим. Основные типы SSL‑сертификатов включают в себя:

Подойдёт небольшим сайтам: лендингам, сайтам‑визиткам.

Как создать одностраничный сайт

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

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

Совместное использование HTTP и HTTPS

Рис.1 Стандартная конфигурация сети. Пользователь на хосте клиента (CH) хочет осуществить безопасную транзакцию, но уязвим для атаки «человек в середине».

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

Как браузеры рендерят контент

Что делает браузер с файлами HTML, получив их от сервера? Как он превращает этот HTML в страницу, с которой может взаимодействовать пользователь? Процесс получения файла HTML и его преобразования в пользовательский интерфейс называется критическими этапами рендеринга (critical rendering path). Всего существует пять критических этапов рендеринга:

▍ Динамические изменения

Что происходит, когда JavaScript пытается изменить какие-то элементы на странице? Мы можем разделить такие изменения на три типа:

На этапе парсинга HTML браузер находит различные ресурсы и запрашивает их, например, изображения. Но в случае высокоприоритетных ресурсов наподобие таблиц стилей и скриптов, которые необходимы для работы страницы, используется нечто под названием сканер предварительной загрузки (pre-load scanner). Во время парсинга HTML он проходит по HTML в поисках всех ресурсов, имеющих высокий приоритет, и делает к ним HTTP-запросы ещё в процессе парсинга. Благодаря этому, нам не приходится ждать возврата этих запросов, как бы это происходило, если бы HTML искал их.

▍ Оптимизация под критические этапы рендеринга

Что же мы можем сделать для оптимизации своего кода? Вот несколько идей:

Это ключевые концепции, необходимые для понимания работы веба. Надеюсь, они будут вам полезны.

🏆 Голосуй за нас на премии «ЦОДы РФ»!

Основой HTTP является технология «клиент-сервер», то есть предполагается существование:

HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (в частности, для этого используется HTTP-заголовок). Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

Большинство протоколов предусматривает установление TCP-сессии, в ходе которой один раз происходит авторизация, и дальнейшие действия выполняются в контексте этой авторизации. H TTP же устанавливает отдельную TCP-сессию на каждый запрос; в более поздних версиях HTTP было разрешено делать несколько запросов в ходе одной TCP-сессии, но браузеры обычно запрашивают только страницу и включённые в неё объекты (картинки, каскадные стили и т. п.), а затем сразу разрывают TCP-сессию. Для поддержки авторизованного (неанонимного) доступа в HTTP используются cookies; причём такой способ авторизации позволяет сохранить сессию даже после перезагрузки клиента и сервера.

При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно. H TTP перед тем, как передать сами данные, передаёт заголовок «Content-Type: тип/подтип», позволяющий клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с CGI-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска данного файла на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы разных типов — в простейшем случае картинки в разных форматах).

Кроме того, HTTP позволяет клиенту прислать на сервер параметры, которые будут переданы запускаемому CGI-скрипту. Для этого же в HTML были введены формы.

Перечисленные особенности HTTP позволили создавать поисковые машины (первой из которых стала AltaVista, созданная фирмой DEC), форумы и Internet-магазины. Это коммерциализировало Интернет, появились компании, основным полем деятельности которых стало предоставление доступа в Интернет (провайдеры) и создание сайтов.