3 параметры протокола

Взаимодействие по протоколу HTTP

Как упоминалось ранее, HTTP-сервер принимает запросы от клиентов через известный TCP-порт 80 (или порт 443 для HTTPS) . HTTP-клиенты могут использовать любой доступный TCP-порт для исходящих подключений. Общая последовательность событий HTTP выглядит следующим образом.

HTTP-запрос GET

1. Клиент отправляет запрос на TCP-подключение к порту 80 сервера (или 443 для HTTPS).
2. Если используется протокол HTTPS, то после установления TCP-подключения следует подтверждение TLS, чтобы проверить подлинность сервера и установить безопасный канал.
3. Клиент отправляет запрос GET ресурс HTTP/1.1 и другие сведения заголовка.
4. Сервер создает сообщение HTTP/1.1 200 OK с дополнительной информацией, за которой следует содержимое запрошенного ресурса (при наличии).
5. Сервер отключается от клиента (протокол TLS завершает работу, если используется протокол HTTPS).
6. Клиент отключается от сокета (протокол TLS завершает работу после оповещения об отключении от сервера).

HTTP-запрос PUT

1. Клиент отправляет запрос на TCP-подключение к порту 80 (или 443) сервера.
2. Если используется протокол HTTPS, то после установления TCP-подключения следует подтверждение TLS, чтобы проверить подлинность сервера и установить безопасный канал.
3. Клиент отправляет запрос PUT HTTP/1.1 и другие сведения заголовка, за которыми следует содержимое ресурса.
4. Сервер создает сообщение «HTTP/1.1 200 OK» с дополнительной информацией, за которой следует содержимое запрошенного ресурса.
5. Сервер разрывает подключение.
6. Клиент разрывает соединение.

Примечание

Как уже упоминалось, HTTP-сервер может изменить стандартный порт подключения (80 или 443) на любой другой порт с помощью службы nx_web_http_client_set_connect_port() , что позволяет веб-серверам, использующим альтернативные порты, подключаться к клиентам.

Переходим на HTTPS

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

Шаг 1: Подготовка сайта

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

Чтобы избежать предупреждения, указанного выше, необходимо изменить все внутренние ссылки с абсолютных на относительные. Например, ссылку http://ssl.ru/testpage/ потребуется заменить на /testpage/. Также стоит внимательно проверить все ссылки на скрипты в коде страниц. 

Второй момент — проверка медиаконтента, в который входят изображения, видеоклипы, презентации и прочее. Необходимо посмотреть, какой на страницах сайта используется контент и по какому протоколу он запрашивается. Если используется HTTP, то рекомендуется загрузить все файлы на сервер и установить относительные ссылки. В противном случае указывайте только проверенные сайты: YouTube, Facebook, VK и так далее.

Теперь можно переходить к подключению SSL.

Шаг 2: Установка SSL-сертификата

Устанавливаем SSL:

Проверить подлинность сертификата можно на различных сервисах, например, Namecheap. Все просто: вводим домен с портом 443 и жмем «Check». При успешной проверке будет отображена надпись «It’s all good. We have not detected any issues».

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

Шаг 3: Настройка редиректа на HTTPS

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

Первый вариант:

RewriteEngine On

RewriteCond %{SERVER_PORT} !^443$

RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} 

Второй вариант:

RewriteEngine On

RewriteCond %{HTTPS} =off

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} 

Третий вариант:

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteCond %{HTTP:X-Forwarded-Proto} !https

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} 

Также мы можем сделать редирект с HTTP через административную панель CMS системы. В OpenCart для этого нужно открыть файл config.php и прописать в него следующее:

define('HTTPS_SERVER', 'https://yourdomain.com/');

В WordPress изменить wp-config.php:

define('FORCE_SSL_ADMIN', true);

Для получения подробной информации о редиректах на других CMS обратитесь к их документации.

Шаг 4: Настройка для поисковых систем

Если ваш сайт индексируется Google, Яндекс или другими поисковиками, то после перехода на HTTPS необходимо им об этом сообщить. В частности, нужно:

1. Изменить все теги «rel=canonical» в HTML-коде. Они должны указывать на ссылки с защищенным протоколом.
2. В файлы robots.txt и sitemap.xml необходимо добавить страницы с HTTPS.
3. Проверить корректность указанных данных в Яндекс.Метрика и Google Search Console.
4. Проверить отображение и доступность вашего сайта через поисковик.

Готово! На этом переход с HTTP на HTTPS завершен. Надеюсь, что у вас не возникло сложностей

Спасибо за внимание!

Настройка резервирования пространства имен

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

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

В следующем примере используется средство Netsh.exe:

Эта команда добавляет резервирование URL-адресов для указанного пространства имен URL-адреса для учетной записи DOMAIN\user. Для получения дополнительных сведений об использовании команды netsh введите в командной строке и нажмите клавишу ВВОД.

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

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

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

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

IETF Related Information

The Internet Engineering Task Force
(IETF) is the protocol engineering and development arm of the Internet. The
IETF is a large open international community of network designers, operators,
vendors, and researchers concerned with the evolution of the Internet
architecture and the smooth operation of the Internet. It is open to any
interested individual.

• Current Internet
  Drafts (IDs)
• Request for
  Comments (RFCs) and another very nice interface to
  RFCs
• Information on Internet
  Official Protocol Standards and
• Internet Standards
  Process about the IETF standards process.

Working Groups Related to HTTP

These are the IETF working groups
working on HTTP directly related issues:

• Content Negotiation
  (conneg) IETF Working Group with mailing list and archives
• HTTP wg (http) with mailing list and archives
• WWW Distributed Authoring and Versioning (webdav) with
  mailing list and archives
• Web Transaction Security wg (wts)

Paul Hoffman at the Internet Mail
Consortium maintains an excellent list of IETF working groups directly related
to Internet Mail. The following list are working groups of more distant
nature relative to HTTP.

• Application
  Configuration Access Protocol wg (acap)
• Internet Printing Protocol
  (ipp)
• Multiparty
  Multimedia Session Control (mmusic)
• TCP Implementation
  (tcpimpl)

You can also check the full list of IETF working
groups.

IETF Meetings

Also check out the IETF meeting page for
the latest information. We keep a small list of notes from previous HTTP wg
meetings at various IETF meetings:

Los Angeles, CA, USA, March-April1998

Where, how-to,
agenda etc.

Washington, DC, USA, December 1997

HTTP-WG
notes from the meeting and the complete on-line
Procedings

Munich, Germany, 11-15 August 1997

HTTP-WG
notes from the meeting and the complete
on-line Proceedings

Memphis, TN, 7-11 April 1997

HTTP-WG
notes from the meeting and the complete on-line
Proceedings

San Jose, CA, 9-13 December 1996

HTTP-WG
notes from the meeting and the complete
on-line proceedings.

Montreal, Quebec CANADA, 24-28 June 1996

HTTP-WG notes from
the meeting

Other Organizations Related to IETF

An unordered list of organizations related to IETF:

• The Internet Engineering
  Steering Group (IESG) which consists of the IETF Area directors
  together with the Chair of the IETF.
• The Internet Research Task Force
  (IRTF) is a composed of a number of focused, long-term, small Research
  Groups. These groups work on topics related to Internet protocols,
  applications, architecture and technology.
• The Internet Architecture Board
  (IAB) is a body of the Internet Society responsible for overall
  architectural considerations in the Internet.
• The Internet Society (ISOC) is a
  non-governmental International organization for global cooperation and
  coordination for the Internet and its internetworking technologies and
  applications.
• The Internet Assigned Numbers
  Authority (IANA) is the central coordinator for the assignment of
  unique parameter values for Internet protocols

Формат запроса

Запрос выглядит примерно так:

Request-Line = Method SP URI SP HTTP-Version CRLF
Method = "OPTIONS"
       | "HEAD"
       | "GET"
       | "POST"
       | "PUT"
       | "DELETE"
       | "TRACE"

SP — это разделитель между токенами. Версия HTTP указывается в HTTP-Version. Реальный запрос выглядит так:

GET /articles/http-basics HTTP/1.1
Host: www.articles.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Список возможных заголовков запроса:

request-header = Accept
               | Accept-Charset
               | Accept-Encoding
               | Accept-Language
               | Authorization
               | Expect
               | From
               | Host
               | If-Match
               | If-Modified-Since
               | If-None-Match
               | If-Range
               | If-Unmodified-Since
               | Max-Forwards
               | Proxy-Authorization
               | Range
               | Referer
               | TE
               | User-Agent

В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.

Что важно понимать про HTTP

1. HTTP — это протокол общения клиент-серверных приложений в вебе. Набор правил, который помогает клиентам (прежде всего браузерам) и веб-серверам понимать друг друга.
2. HTTP — это про формат общения, а не про управление сервером HTTP-командами. Клиент может отправить что угодно: удали страницу сайта, создай нового пользователя, выдай список всех пользователей — но сервер не обязан их выполнять, он лишь обязан ответить в формате HTTP, чтобы клиент его понял. То есть благодаря HTTP сервер поймёт, что клиент хочет, а потом уже решит, как это обработать и вернёт результат. Может быть удалит страницу, а может и нет.
3. В HTTP общение всегда начинает клиент. А веб-сервер висит и ждёт. Сейчас есть способы инициировать запрос с сервера, но изначально протокол для этого не предназначен.
4. HTTP-протокол не имеет шифрования, поэтому передавать персональные данные и прочие приватные данные через него не безопасно. В таком случае нужно использовать HTTPS.
5. Простой способ изучить заголовки запроса и ответа — открыть консоль браузера на нужной странице и обновить её. В разделе Network/Сеть отобразятся все запросы с этой страницы, включая запросы на картинки и статические файлы.

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

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

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

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

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

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

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

Прокси

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

Веб-разработчики могут использовать прокси для следующих целей:

• Кэширование. Кэш-серверы сохраняют веб-страницы или другой контент локально, для более быстрого поиска информации и снижения требований к пропускной способности сайта.
• Аутентификация. Для контроля прав доступа к приложениям и онлайн-информации.
• Логирование. Нужен для хранения данных, таких как IP-адреса клиентов, отправивших запросы на сервер.
• Веб-фильтрация. Контролирует доступ к веб-страницам, которые могут быть небезопасными или содержать неприемлемый контент.
• Балансировка нагрузки. Позволяет обрабатывать клиентские запросы не одному серверу, а сразу нескольким.

Форматы сообщений запроса/ответа

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

Давайте посмотрим на структуру передаваемого сообщения через HTTP:

message = <start-line>
          *(<message-header>)
          CRLF
          

<start-line> = Request-Line | Status-Line
<message-header> = Field-Name ':' Field-Value

Между заголовком и телом сообщения должна обязательно присутствовать пустая строка. Заголовков может быть несколько:

Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.

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

Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:

general-header = Cache-Control
               | Connection
               | Date
               | Pragma
               | Trailer
               | Transfer-Encoding
               | Upgrade
               | Via
               | Warning

Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.

Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache — это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

Заголовок Upgrade используется для изменения протокола.

Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.

Заголовки сущностей

В заголовках сущностей передаётся мета-информация контента:

entity-header  = Allow
               | Content-Encoding
               | Content-Language
               | Content-Length
               | Content-Location
               | Content-MD5
               | Content-Range
               | Content-Type
               | Expires
               | Last-Modified

Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

С помощью данных заголовков, можно задать нужную для ваших задач информацию.

Пример запроса HTTP

Рассмотрим примеры запроса и ответа HTTP. 

HTTP работают в текстовом режиме, нам необходимо подключиться к веб-серверу, например www.zvondozvon.ru к порту 80 по протоколу TCP. Дальше мы пишем запрос, используем метод GET хотим получить ресурс /tehnologii/protokoli и указываем версию протокола по которой мы хотим работать HTTP 1.1. Так как мы используем версию 1.1 нам необходимо указать заголовок host, доменное имя сервера с которым мы работаем www.zvondozvon.ru, этого вполне достаточно для того чтобы веб-сервер нам ответил. 

Ответ веб-сервера начинается со статуса 200 ok, обработка запроса произошла успешно, также вначале указываются версия протокола, которая используется HTTP 1.1. Затем идут несколько заголовков реализации веб-сервера nginx, тип передаваемой страницы текста html кодировка utf-8, длина страницы 5161 байт, также здесь могут идти другие заголовки, которые вам передал сервер. 

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

Продолжение про протокол HTTP читайте в статье постоянное соединение и кэширование протокола HTTP.

Синтаксис

Data URL состоит из четырёх сегментов: приставки (), MIME типа, описывающего  тип данных, дополнительного ключевого слова для нетекстовых данных и самой строки данных:

data:,<данные>

описывается строкой в формате MIME типа, например для JPEG файла изображения. При не указывании типа данных, браузер автоматически будет интерпретировать строку данных, как 

Если данные представляют собой какую-либо текстовую информацию, вы можете просто вставить эту текстовую строку в Data URL (используя соответствующие для типа данных сущности и знаки экранирования). В ином случае вам будет необходимо использовать ключевое слово перед вставкой base64-кодированных бинарных данных. Дополнительную информацию о MIME типах вы сможете найти здесь и здесь (en-US).

Несколько примеров:

Простые text/plain данные

base64-кодированная версия примера выше

HTML строка вида:

HTML строка, вызывающая JavaScript alert функцию. Заметьте необходимость закрывающего <script> тега.

WEB и HTTP сервисы: сходства и различия

WEB и HTTP сервисы очень сходны между собой, но все же в них есть кардинальные отличия. Сходны они тем, что: 

• Предназначены для доступа к базе данных снаружи, 
• Работают посредством веб-технологий, поверх протокола TCP,
• Оба поддерживают технологии XML и JSON. 

Теперь расскажем о различиях. 

WEB технология — это сервисно-ориентированная технология, она по сути является удаленным вызовом процедур. Мы проектируем описание процедур, описание передаваемых параметров, и с помощью WEB сервисов мы эти процедуры можем вызывать. 1С со своей стороны также предоставляет технологию XDTO, которая позволяет валидировать входящие и исходящие данные, передаваемые в формате XML. 

HTTP сервисы же основаны практически на голом HTTP, и эта технология  ресурсно-ориентированная. Нет описания, нет проверки типов, нет проверки входящих и исходящих данных — есть только заголовки, параметры и тело запроса. И исторически используется формат данных JSON. 

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)