Что такое http

Инструменты для просмотра сетевого трафика по HTTP (* поток данных в передающей среде; состоит из передаваемых данных и служебной информации, необходимой для организации их прохождения)

Разработчикам доступно множество инструментов для мониторинга HTTP трафика. Здесь будут перечислены наиболее популярные.

Без сомнений, фаворитом среди веб-разработчиков  является инспектор Chrome/Webkit.

Также в их распоряжении имеются прокси для отладки веб-приложений, например, Fiddler (* работает с трафиком между вашим компьютером и удаленным сервером и позволяет просматривать и менять его) для Windows и Charles Proxy для OSX. Мой коллега, Rey Bango, написал замечательную статью на эту тему. Мой коллега, Rey Bango, написал замечательную статью на эту тему.

Из набора программ с интерфейсом командной строки для мониторинга трафика HTTP у нас имеются такие утилиты, как curl, tcpdump и tshark.

Как убрать предупреждение в Яндекс Браузере?

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

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

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

Обратите внимание:

Триколор ошибка 0: как исправить такое?

Формат ответа

Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

• HTTP версия
• Код статуса
• Сообщение статуса, понятное для человека

Обычный статус выглядит примерно так:

HTTP/1.1 200 OK

Заголовки ответа могут быть следующими:

response-header = Accept-Ranges
                | Age
                | ETag
                | Location
                | Proxy-Authenticate
                | Retry-After
                | Server
                | Vary
                | WWW-Authenticate

• Age время в секундах, когда сообщение было создано на сервере.
• ETag MD5 сущности для проверки изменений и модификаций ответа.
• Location используется для перенаправления и содержит новый URL адрес.
• Server определяет сервер, где было сформирован ответ.

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

Пример сеанса FTP

Мы подключились к серверу на порт 21, создали управляющее соединение, сервер нам выдал ответ. 

Ответ FTP сервера, также как и ответы серверов многих прикладных протоколов состоят из двух частей, первая 220 статус, а вторая поясняющее сообщение Welcome to the FTP Server. Статус ответа 220, коды которой начинаются с 2, говорят об успешном выполнении команды, поясняющее сообщение содержит приветствие “Добро пожаловать на FTP сервер”. 

Сначала необходимо пройти аутентификацию. Для этого используется команда USER anonymous и мы хотим подключиться, как анонимный пользователь. 

Сервер отвечает сообщением со статусом 331. Код, который начинается с 3 говорит о том, что предыдущая команда была выполнена успешно и ожидается продолжение выполнения связанных действий. 

Устанавливаем бинарный режим передачи файлов с помощью команды TYPE 1. Сервер отвечает, что тип передачи данных успешно установлен в 1. 200 Type set to 1. 

Мы хотим загрузить сервера в файл, показан путь /pud/tex/latex/llncs2e.zip, но перед тем как загрузить, мы хотим узнать его размер, для этого выдаем команду SIZE /pud/tex/latex/llncs2e.zip. Сервер в ответ выдает размер файла в байтах 213 230229. 

Переходим в пассивный режим с помощью команды PASV. 

В ответ сервер говорит, что он перешел в пассивный режим 227 Entering Passive Mod (213, 71, 6, 142, 35, 141) и передает нам 6 чисел, которые нужно использовать для установки соединения для передачи данных. Первые 4 числа это IP-адрес, вторые два числа используются, чтобы узнать порт на который нужно установить соединение. Первое число 35 нужно умножить на 256 и прибавить второе число 141, так мы узнаем порт. 

Для того, чтобы загрузить нужный нам файл используем команду RETR /pud/tex/latex/llncs2e.zip. После того, как мы выдали эту команду сервер ждет, что мы установим соединение с IP-адресом и портом, которые он нам указал. 

После того, как соединение для передачи данных установлено, сервер сообщает нам об этом в управляющем соединении. 150 Opening BINARY mode data connection for /pud/tex/latex/llncs2e.zip (230229 bytes). Также сервер говорит, что передача данных ведется в бинарном режиме. 

После того, как передача файла закончена, сервер сообщает нам об этом 226 Transfer complete. Клиент выдает команду QUIT чтобы разорвать соединение. Сервер сообщает нам некоторую статистику, сколько было передано байт и файлов. 221 You have transferred 239229 bytes in 1 file. И говорит до свидания 221 Goodbye. На этом сеанс работы по протоколу FTP завершен. 

Кэширование в HTTP

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

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

Кэширование требует место на локальном диске компьютера, но сейчас это не составляет проблем. Поддержка кэширования ресурсов встроена прямо в протокол http. Основная проблема заключается в том, что браузеру необходимо определить можно ли брать страницу из кэша, или страница изменилась и необходимо обращаться за ней к web –серверу. В http для этой цели используется заголовок Expires. Этот заголовок web-сервер добавляет к ресурсу, когда передает http ответ и заголовок говорит о том, до какого времени можно хранить ресурс в кэше.

В примере ресурс можно хранить до 12 июня, после этого ресурс устареет и необходимо снова обращаться к серверу. Однако не все web-серверы устанавливают этот заголовок. Если заголовок Expires не установлен, то  браузер может использовать некоторые Эвристики. Например, он может использовать поле last-modified в котором указываются дата последнего изменения ресурса.

В примере 25 мая 2016 года. Если страница долго не менялось, то можно предположить, что в ближайшее время она не изменится, и можно брать ее копию из кэша. С другой стороны при таком подходе возможны ошибки. Например, наша эвристика может заключаться в том, что мы берем из кэша те страницы, которые не менялись в течение двух недель, но страница может меняться 1 раз в месяц.

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

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

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

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

Преимущества протокола HTTPS

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

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

Плюсы HTTP:

• Повышение безопасности – шифруется всё: URL-адреса, номера кредиток, история просмотров и т. д.;
• HTTPS – фактор ранжирования в поисковой выдаче;
• Повышенное доверие у посетителей;
• Сохранение / улучшение конверсии.

Обслуживание соединения со стороны сервера

В основном сервер прослушивает входящие сообщения и обрабатывает их по мере поступления запросов. Операции сервера включают в себя:

• создание сокета для начала прослушивания 80-го (или другого) порта,
• получение запроса и анализ сообщения,
• обработку ответа,
• установку заголовка ответа,
• отправку ответа клиенту,

прерывание соединение, если возникло сообщение: Connection: close.

Естественно, это далеко не полный перечень операций. Для создания наиболее индивидуальных ответов веб-сайты и программы должны “понимать”, кто посылает запросы. За это отвечают процессы идентификации и аутентификации.

Конвейерная обработка HTTP (pipelining)

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

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

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

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

Обозначение эмоций символами в первых текстовых смайлах

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

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

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

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

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

Кроме набора общеупотребимых символов люди стали использовать отдельные символы из экзотических раскладок, которые стали доступны благодаря распространению кодировок Юникод, которые содержали десятки тысяч всевозможных знаков. Достаточно было лишь скопировать нужный символ или вставить в текст его код. Так, например, появились такие вот аналоги написания смеющегося смайла — ?_? или ? или ?

Вы их видите только благодаря тому, что на вашем компьютере стоит набор шрифтов в формате Юникода, куда зашиты не только такие причудливые значки, но даже около 1000 кодов Emoji-смайлов, о которых мы уже говорили. Еще несколько примеров интересных символов сложившихся в смайлы:

1. ┌༼◉ل͟◉༽┐
2. ( ͡° ͜ʖ ͡°)
3. ¯_ (ツ) _/¯
4. (ง ͠° ͟ل͜ ͡°)ง
5. ʕ•ᴥ•ʔ
6. (ᵔᴥᵔ)
7. ┌( ಠ‿ಠ)┘
8. (ಠ╭╮ಠ)
9. …(__/)…(=’.’=)…E|||||З…(“) _ («)

Что они означают вы уж сами догадайтесь. А если не догадались, но они вам понравились и вы хотите больше, то милости просим в каталог текстовых и символьных смайликов.

Что дает HTTPS для ранжирования сайта?

Преимущества и недостатки протокола

Многолетняя практика выявила у протокола HTTP немало достоинств и недостатков. Несколько слов о тех и о других.

Достоинства:

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

Недостатки:

• Отсутствие «навигации». У протокола HTTP отсутствуют в явном виде средства навигации среди ресурсов сервера. Например, клиент не может явным образом запросить список доступных файлов, как в протоколе FTP. Полностью эта проблема решена в расширяющем HTTP протоколе WebDAV с помощью добавленного метода PROPFIND. Данный метод позволяет не только получить дерево каталогов, но и список параметров каждого ресурса.
• Отсутствие поддержки распределённости. Изначально протокол HTTP разрабатывался для решения типичных бытовых задач, где само по себе время обработки запроса должно занимать незначительное время или вовсе не приниматься в расчёт. Однако со временем стало очевидно, что при промышленном использовании с применением распределённых вычислений при высоких нагрузках на сервер протокол HTTP оказывается непригоден. В связи с этим с 1998 году был предложен альтернативный протокол HTTP-NG (англ. HTTP Next Generation), но этот протокол до сих пор находится на стадии разработки.

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)

О средствах настройки, проверки

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

• IPv6;
• IPv4.

Обратите внимание! iPv4 — вариант стандартной настройки для большинства ситуаций. IPv6 — новая версия протокола, которая до сих пор остаётся невостребованной

Доступ к состоянию сети с помощью системного трея помогут провести проверку в случае необходимости. Значок на панели сообщит пользователю о том, доступна сеть или нет. Определение текущего статуса не доставляет проблем.

В чем различия между http и https?

Теперь перейдем к основному вопросу: в чем заключается главная разница между http и https? По ранее описанным особенностям протоколов можно понять, какие между ними отличия. Но если посмотреть более пристально, то можно понять, что есть и другие отличительные черты.

1. Каждый из протоколов функционирует при помощи специальных портов. Но для работы http используется порт 80, а для https – 443.
2. С учетом того, как работает https, мы ранее сделали вывод, что применяемое шифрование данных надежно защищает их от злоумышленников. Для их расшифровки используются специальные ключи, хранящиеся на сервере. Для http это не характерно.
3. Защищенное соединение гарантирует полную сохранность данных. Даже если в них будут внесены незначительные коррективы, система моментально их зафиксирует.
4. Протокол безопасности предоставляет аутентификацию. То есть, пользователь может быть уверен в том, что попадет именно на тот ресурс, который ищет. Такой подход помогает предотвратить любые посторонние вмешательства.

Есть еще несколько важных моментов, о которых нужно знать. Понимая, что означает https в адресе сайта, вы можете быть полностью уверенными в безопасном подключении к серверу. Но такой протокол «тянет» определенную часть ресурсов с этого самого сервера, поэтому загрузка сайта может несколько замедлиться.

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

Нужно ли переходить на HTTPS?

Если ваш сайт содержит информацию, которая быть надежно защищена, то переходить на безопасный протокол нужно обязательно. В противном случае в любой момент важные данные могут быть украдены и использованы в мошеннических целях. Но будьте готовы к тому, что за переход на https вам придется вносить дополнительную плату, если выберете платный SSL-сертификат. А также оплачивать услуги программиста фрилансера от 1000 до 3000 рублей.

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

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

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)

Symbols

Постоянное соединение в HTTP

Альтернативный подход, который называется постоянное соединение, заключается в том что можно один раз установить соединение tcp и затем использовать его для загрузки различных ресурсов не только HTML страницы, но и стилевых файлов, javascript, картинок и всех связанных ресурсов. TCP соединения разрываются после того, как все ресурсы были загружены.

По-английски постоянное соединение называется HTTP persistent connection или HTTP keep-alive. Использование постоянного соединения позволяет повысить скорость загрузки web-страниц.

1. Во-первых, нет необходимости каждый раз устанавливать HTTP соединения, то есть мы не проходим процедуру трехкратного рукопожатия.
2. Во вторых, скорость передачи данных при установке нового соединения TCP низкая. Для того чтобы регулировать скорость передачи данных, TCP используют размер окна, чем больше размер окна тем больше скорость передачи данных. Так как при установке соединения, TCP ничего не знает про сеть, то используется маленький размер окна, который увеличивается при получении каждого подтверждения с помощью механизма slowstart, а затем аддитивного увеличения мультипликативного уменьшения. Если мы не открываем каждый раз новое соединение, а используем существующие, то нам не надо каждый раз начинать с маленького размера окна, и мы используем существующее TCP соединение, которое позволяет передавать данные на высокой скорости.

Постскриптум.

Думаю, что о передаче запросов на сервер не стоит рассказывать подробно. Это уже дело чисто РНР техники :-). Достаточно внимательно прочитать раздел о функциях работы с сокетами, или о функциях модуля CURL в официальной документации РНР.

Из выше сказанного, надеюсь теперь понятно, почему вопрос: «Как мне сформировать POST запрос, используя функцию header?»  бессмысленен. Функция header(string) добавляет запись только в заголовок запроса, но никак не в тело запроса.

Есть еще один тип запросов  Content-Type: multipart/mixed, надеюсь после прочтения данной статьи Вы легко разберетесь с данным типом сами. Подробно изучить его можно

О запросах других типов можно прочитать в официальной спецификации протокола HTTP 1.0 здесь.

Идентификация в HTTPS

Идентификация сервера

HTTP/TLS запросы генерируются путём разыменования URI, вследствие чего имя хоста становится известно клиенту. В начале общения, сервер посылает клиенту свой сертификат, чтобы клиент идентифицировал его. Это позволяет предотвратить атаку посредника. В сертификате указывается URI сервера. Согласование имени хоста и данных, указанных в сертификате, происходит в соответствии с протоколом RFC2459.

Если имя сервера не совпадает с указанным в сертификате, то пользовательские программы, например браузеры, сообщают об этом пользователю. В основном, браузеры предоставляют пользователю выбор: продолжить незащищённое соединение или прервать его.

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

Обычно сервер не располагает информацией о клиенте, достаточной для его идентификации. Однако для обеспечения повышенной защищённости соединения используется так называемая two-way authentication. При этом сервер после подтверждения его сертификата клиентом также запрашивает сертификат. Таким образом, схема подтверждения клиента аналогична идентификации сервера.

Аутентификация

HTTP действительно поддерживает рудиментарную форму аутентификации, называемой Основной Проверкой Подлинности (Basic Authentication), точно также как и более надежную форму — Краткую Проверку Подлинности (Digest Authentication).

В Основной Проверке Подлинности сервер сразу же отвергает запрос клиента с WWW-Authenticate и кодом состояния 401 — Unauthorized. Увидев этот заголовок, браузер отображает диалоговое окно входа с запросом имени пользователя и пароля. Эта информация отправляется в фотмате BASE64 в заголовке запроса на аутентификацию. Теперь сервер может проверить запрос и разрешить доступ, если учетные данные верны. Некоторые серверы могут даже отправить заголовок Autentification-Info, содержащий дополнительные детали об аутентификации.

Следствием Основной Проверки Подлинности является Проверка Подлинности Прокси. Вместо веб-сервера, задача аутентификации состоит в запрашивании промежуточного прокси-сервера. Прокси-сервер отправляет заголовок Proxy-Authenticate с кодом статуса 407-Unauthorized. В свою очередь, клиенту предлагается посылать мандаты с помощью заголовка запроса Proxy-Authorization.

Краткая Проверка Подлинности похожа на Основную ПП техникой, схожей с WWW-Authenticate и заголовками авторизации, но Краткая ПП использует более надежные хэш-функции для шифрования имени пользователя и пароля (обычно- MD5 или KD дайджест-функций). Хотя Краткая ПП должна быть более безопасной, чем Основная ПП, веб-сайты обычно используют Основную ПП из-за её простоты. Для смягчения проблем безопасности Основные ПП используются в сочетании с SSL (Secure Sockets Layer).

Протокол Secure HTTP

Протокол HTTPS обеспечивает безопасное соединение в Интернете. Самый простой способ узнать, используете ли Вы его: проверить адресную строку браузера. Защищенный компонент HTTPs включает в себя вставленный слой шифрования / дешифрования между HTTP и TCP- Secure Sockets Layer (SSL) или улучшенный протокол Transport Layer Security (TLS).

SSL использует мощный алгоритм шифрования при помощи RSA и криптографии с открытым ключом. Так как безопасные транзакции в Интернете необычайно важны, разработка универсальных стандартов, основанных на Инфраструктуре Открытых Ключей (PKI) ведется уже давно.

Существующие клиенты / серверы не должны изменить способ обработки сообщения, так что большая часть тяжелой работы проходит в слое SSL. Таким образом, вы можете разрабатывать веб-приложения, используя Основные ПП и автоматически пользоваться преимуществами SSL за счет перехода на протокол https://. Однако, чтобы веб-приложение работало на протоколе HTTPS, необходимо иметь рабочий цифровой сертификат, развернутый на сервере.

Сертификаты

Также как человеку нужен паспорт для удостоверения личности, серверу нужен цифровой сертификат для идентификации. Сертификаты (или “certs”) выдаются Центром Сертификации (CA) и поручаются за Вашу личность в Интернете. CA хранят в себе PKI. Наиболее распространенная форма сертификатов- стандарт X.509 v3, который содержит такую информацию:

• поставщик сертификата,
• алгоритм сертификации,
• имя субъекта или организации, для которой создается сертификат,
• открытый ключ информации для субъекта,
• Сертифицированная Подпись, использовавшая заданный алгоритм подписи.

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

Как только сертификат сверен, вступает в силу полная и безопасная передача SSL.

HyperText Transfer Protocol

Интернет протокол HTTP – HyperText Transfer Protocol является протоколом передачи гипертекста. Он предназначен для передачи различной информации между клиентом и сервером и является символьно-ориентированным клиент-серверным протоколом.

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

Всего было четыре версии протокола. Самый первый вариант интернет протокола HTTP 0.9 был выпущен в 1991 году и впервые издан в январе 1992 года. Он привел к урегулированию норм и правил взаимосвязи между клиентами и серверами HTTP, а соответственно к точному разграничению функций между этими элементами. Были запротоколированы основные синтаксические и семантические принципы и положения.

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