Генерация http запросов

Методы

С помощью URL, мы определяем точное название хоста, с которым хотим общаться, однако какое действие нам нужно совершить, можно сообщить только с помощью HTTP метода. Конечно же существует несколько видов действий, которые мы можем совершить. В HTTP реализованы самые нужные, подходящие под нужды большинства приложений.

Существующие методы:

GET: получить доступ к существующему ресурсу. В URL перечислена вся необходимая информация, чтобы сервер смог найти и вернуть в качестве ответа искомый ресурс.

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

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

DELETE: служит для удаления существующего ресурса.

Данные методы самые популярные и чаще всего используются различными инструментами и фрэймворками. В некоторых случаях, PUT и DELETE запросы отправляются посредством отправки POST, в содержании которого указано действие, которое нужно совершить с ресурсом: создать, обновить или удалить.

Также HTTP поддерживает и другие методы:

HEAD: аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.

TRACE: во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.

OPTIONS: используется для определения возможностей сервера, его параметров и конфигурации для конкретного ресурса.

HTTP-ответы

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

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

После строки состояния сервер отправляет клиенту в заголовках информацию о себе и запрошенном документе. Заголовки завершаются пустой строкой (т.е. двумя идущими подряд последовательностями CRLF).

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

В HTTP 1.0 сервер, завершив отправку запрошенных данных, отсоединяется от клиента и транзакция на этом заканчивается, если только не был отправлен заголовок Connection: Keep-Alive. Однако в HTTP 1.1 сервер должен поддерживать соединение, позволяя клиенту делать дополнительные запросы, даже если заголовок Connection не был отправлен. Если не нужно такое поведение, следует отправить заголовок Connection: close, который указывает, что после отправки ответа соединение должно быть закрыто.

Symbols

Имя и Фамилия

1.2. Пишем наш первый HTTP запрос

Если Вы думаете, что все слишком сложно, то Вы ошибаетесь. Человек так устроен, что просто не способен создавать что-то сложное, иначе он сам в этом запутается 🙂

Итак, есть браузер и есть Web-сервер. Инициатором обмена данными всегда выступает браузер. Web-сервер никому, никогда просто так ничего не пошлет, чтобы он что-нибудь отправил браузеру  надо, чтобы браузер об этом попросил. Простейший HTTP запрос моет выглядеть, например, так:

GET http://www.php.net/ HTTP/1.0\r\n\r\n

• GET (В переводе с английского означает «получить»)  тип запроса, тип запроса может быть разным, например POST, HEAD, PUT, DELETE (часть из них мы рассмотрим ниже).
• http://www.php.net/  URI (адрес) от которого мы хотим получить хоть какую-нибудь информацию (естественно мы надеемся подучить HTML страницу).
• HTTP/1.0  тип и версия протокола, который мы будем использовать в процессе общения с сервером.
• \r\n  конец строки, который необходимо повторить два раза, зачем, станет понятно немного позднее.

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

В стандарте HTTP  1.0 не было возможности использовать постоянное соединение. Уже после публикации стандарта был придуман специальный заголовок Connection: keep-alive. Клиент добавляет этот заголовок к запросу, для того чтобы попросить сервер не закрывать соединение после передачи ответа. Если сервер понимает этот заголовок и поддерживает постоянное соединение, он оставляет соединение открытым и добавляет этот заголовок к ответу.

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

Рассмотрим пример использования заголовка

Посылаем запрос http, используя метод GET, хотим получить страничку со статьями по протоколам (/tehnologii/protokoli), которые находятся на сайте (www.zvondozvon.ru) по протоколу HTTP/1.0.

Добавляем заголовок Connection:keep-alive для того чтобы попросить сервер не разрывать соединение после того как он передаст нам web-страницу.

Сервер присылает нам ответ

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

Разница между HTTP и HTTPS

HTTP – открытый протокол передачи данных, а HTTPS – закрытый, имеющий надстройку шифрования. Первый по умолчанию использует 80 порт и никак не отображается в браузере, второй – 443, а его название отображается в браузере возле домена с пометкой серого значка замочка. Это сразу бросается в глаза. Увидев такой в адресной строке, можете не переживать – передаваемые данные шифруются сайтом, их не получится добыть третьим лицам. То есть сайты с HTTPS вызывают больше доверия у посетителей, ведь многие знают о значении этой технологии.

Данные, передаваемые по HTTP, меньше по объёму, поэтому их передача в обе стороны занимает чуть меньше времени. Но, если сайт нормально оптимизирован, то разница в скорости не будет бросаться в глаза. Да и многие пользователи понимают: лучше подождать пару секунд, не переживая, доберутся ли их деньги, реквизиты и пароли до сервера назначения в безопасности. Кроме того, поисковые системы, в частности, Google и Yandex считают HTTPS одним из признаков качественного сайта.

Расчет теплоизоляционного слоя: формулы и примеры

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

ГСОП=(tв-tот)xzот

tв — показатель температуры внутри помещения, обычно составляет 18-22ºC;

tот — значение средней температуры;

zот — длительность отопительного сезона, сутки.

Значения для подсчета можно найти в СНиП 23-01-99.

При вычислении теплового сопротивления конструкции, необходимо сложить показатели каждого слоя: R=R1+R2+R3 и т. д. Исходя из средних показателей для частных и многоэтажных домов определены примерные значения коэффициентов:

• стены — не менее 3,5;
• потолок — от 6.

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

Пример: стена из силикатного кирпича толщиной в 0,5 м, которая утепляется пенопластом.

Rст.=0,5/0,7=0,71 — тепловое сопротивление стены

R- Rст.=3,5-0,71=2,79 — величина для пенопласта

Имея все данные, можно рассчитать необходимый слой утеплителя по формуле: d=Rxk

Для пенопласта теплопроводность k=0,038

d=2,79×0,038=0,10 м — потребуются плиты пенопласта толщиной в 10 см

По такому алгоритму легко подсчитать оптимальную величину теплоизоляции для всех участков дома, кроме пола. При вычислениях, касающихся утеплителя основания, необходимо обратиться к таблице температуры грунта в регионе проживания. Именно из нее берутся данные для вычисления ГСОП, а далее ведется подсчет сопротивления каждого слоя и искомая величина утеплителя.

Обеспечение безопасности

Базовая схема идентификации не предоставляет безопасного метода идентификации пользователя, не обеспечивает она и каких-либо средств защиты объектов, которые передаются открытым текстом по используемым физическим сетям. HTTP не мешает внедрению дополнительных схем идентификации и механизмов шифрования или других мер, улучшающих безопасность системы (например, SSL или одноразовых паролей).
Наиболее серьезным дефектом базового механизма идентификации в HTTP является то, что пароль пользователя передается по сети в незашифрованном виде.

Аутентификация клиентов

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

Передача конфиденциальной информации

Подобно любому общему протоколу передачи данных, HTTP не может регулировать содержимое передаваемых данных, не существует методов определения степени конфиденциальности конкретного фрагмента данных в пределах контекста запроса. Следовательно, приложения должны предоставлять как можно больше контроля провайдеру информации.
Четыре поля заголовка представляют интерес с точки зрения сохранения конфиденциальности: Server, Via, Referer и From.
Раскрытие версии программного обеспечения сервера может привести к большей уязвимости машины сервера к атакам на программы с известными слабостями. Разработчики должны сделать поле заголовка Server конфигурируемой опцией

Прокси, которые служат в качестве сетевого firewall, должны предпринимать специальные предосторожности в отношении передачи информации заголовков, идентифицирующей ЭВМ, за пределы firewall.

Персональная информация

Клиентам HTTP небезразличнен доступ к некоторым данным (например, к имени пользователя, IP-адресу, почтовому адресу, паролю, ключу шифрования и т.д.). Система должна быть тщательно сконструирована, чтобы предотвратить непреднамеренную утечку информации через протокол HTTP. Мы настоятельно рекомендуем, чтобы был создан удобный интерфейс для обеспечения пользователя возможностями управления распространением такой информации.

Методы протокола

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

Сервер может применять какие угодно методы. Для сервера или клиента нет методов являющихся обязательными. Если сервер не смог определить метод указанный клиентом, то он должен возвратить статус 501 – «Not Implemented». Если сервер определил метод, но его нельзя применить к конкретному ресурсу, то будет возвращено сообщение содержащее код 405 – «Method Not Allowed».

Во всех этих случаях сервер должен включить в ответное сообщение заголовок «Allow». Список включает в себя поддерживаемые методы. Все серверы обязаны поддерживать минимально методы GET и HEAD.

GET – применяется для запроса содержимого указанного источника. При помощи метода также можно начать какой-нибудь процесс. При этом в тело сообщения ответа нужно включить сведения о ходе реализации процесса. Клиент имеет возможность передать параметры исполнения запроса в URL целевого ресурса сразу после символа «?»: GET/path/resource?

HEAD – применяется аналогично методу GET. Отличие заключается в том, что в ответе сервера нет тела. Запрос HEAD как правило используется для извлечения метаданных, проверки существования ресурса, то есть валидация URL. Также этот запрос нужен для того, чтобы узнать, было ли изменение ресурса с момента предыдущего обращения. Еще одним часто используемым методом является метод POST.

Параметры запроса

Мы привыкли, что на нашем сайте каждый PHP-сценарий отвечает за одну страницу. Посетитель сайта вводит в адресную строку путь, который состоит из имени домена и имени PHP-сценария. Например, так: .
Но как быть, если одна страница должна показывать разную информацию?

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

Из чего состоит URI

URI — это уникальный идентификатор ресурса. Ресурс в нашем случае — это полный путь до страницы сайта. И вот как может выглядеть ресурс для показа погоды за конкретный день:

Разберем, из чего состоит этот URI.
Во-первых, здесь есть имя домена: .
Затем идёт имя сценария:
А всё что идёт после — это параметры запроса.

Параметры запроса — это как бы дополнительные атрибуты адреса страницы. Они отделяются от имени страницы знаком запроса. В примере выше параметр запроса только один: date=2017-10-30.
Имя этого параметра:, значение: .
Параметров запроса может быть несколько, тогда они разделяются знаком амперсанда:

В примере выше указывается два аргумента: дата и единица измерения температуры.

Параметры запроса как внешние переменные

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

Получение параметров запроса

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

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

В этом задании вы сможете потренироваться использовать .

Формирование URI с параметрами запроса

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

Здесь мы использовали две функции:

• — получает имя текущего сценария;
• — преобразует ассоциативный массив в строку запроса.

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

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

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

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

Передача файлов по FTP через терминал

Мы могли бы использовать telnet для передачи файлов по FTP через терминал, но это слишком сложно и не нужно. Существует консольный клиент FTP с более простым синтаксисом и достаточными возможностями. Сначала рассмотрим общий синтаксис и команды утилиты:

$ ftp опции адрес_сервера

Опций у утилиты всего несколько, но нам нужно их рассмотреть, потому что они могут быть вам очень полезны:

• -A — использовать активный режим во время передачи файлов;
• -p — использовать пассивный режим, используется по умолчанию;
• -i — отключать интерактивный режим во время передачи файлов;
• -n — попытаться использовать автоматический вход;
• -e — отключить историю команд;
• -v — максимально подробный вывод;
• -d — включить режим отладки.

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

• account — отправить серверу свой пароль для авторизации;
• append — добавить локальный файл в конец удаленного файла на сервере;
• ascii — передавать файлы в кодировке ASCII;
• binary — передавать файлы в бинарном формате;
• bye — завершить сессию;
• cd — перейти в папку;
• cdup — перейти в папку уровнем выше;
• chmod — изменить права на файл;
• delete — удалить файл с сервера;
• dir — посмотреть список файлов в папке;
• get — скачать файл из сервера на локальную машину;
• hash — отображать статус передачи файла;
• lcd — сменить рабочую директорию на локальной машине;
• ls — список файлов в папке;
• mdelete — удалить несколько файлов;
• mget — скачать несколько файлов;
• mkdir — создать папку;
• mput — передать несколько файлов на сервер;
• open — подключится к удаленному FTP серверу;
• put — передать файл на сервер;
• pwd — вывести текущую папку;
• recv — то же самое что и get;
• rename — переименовать файл на сервере;
• rmdir — удалить папку;
• size — узнать размер файла;
• user — авторизоваться на сервере.

Это далеко не все команды, которые вы можете использовать для передачи файлов, но здесь перечислено все самое основное, и вам их точно хватит для решения простых задач.

Сначала подключаемся к нашему серверу, команде нужно передать адрес сервера:

Затем авторизуемся на сервере, нужно передать логин и пароль:

Только после этого перед нами открывается командная оболочка FTP клиента. Именно здесь будет выполняться передача файлов ftp. Изменим текущую папку на FTP, затем посмотрим ее содержимое и выведем полный адрес текущей папки:

Перейдем в папку documents на удаленном сервере и посмотрим ее содержимое:

Чтобы скачать файл по FTP с удаленного сервера нам нужно использовать команду get. Просто передайте команде имя файла:

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

Загрузка файлов по FTP на сервер выполняется с помощью команды put, причем, здесь, как и в предыдущей команде можно задать имя создаваемого файла:

Также можно управлять файлами на удаленном сервере. Переименуем файл doument1.pdf, так чтобы он назывался правильно:

Затем удалим document3:

Для завершения сеанса FTP наберите Bye:

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

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

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

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

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

Недостатки:

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

Действительно ли HTTP/2 работает быстрее?

Специалисты из HttpWatch провели несколько тестов и выявили серьезное ускорение от использования HTTP/2.

На скриншоте ниже показана скорость загрузки страницы с использованием HTTP/1.1:

А на этом скриншоте — результат с использованием HTTP/2:

Скорость загрузки выросла на 23%. Эксперты HttpWatch также отмечают, что технология пока не до конца оптимизирована, и ожидают реальное ускорение в районе 30%.

Мы в «Айри» также проводили тестирование в январе-феврале 2016 года, чтобы выяснить, сколько может выиграть реальный сайт после перевода на протокол HTTPS + HTTP/2. В среднем по нескольким сайтам, которые уже прошли предварительную оптимизацию по скорости (сжатие и объединение файлов, сетевая оптимизация), клиентская скорость загрузки выросла на 13-18% только за счет включения HTTP/2.

Стоит упомянуть, что не все эксперименты были столь однозначны. На «Хабре» был описан эксперимент, поставленный командой «Яндекс.Почты». Тестировался протокол SPDY, но напомним, что HTTP/2 разрабатывался на основе SPDY и очень близок к нему в плане используемых методов.

Команда «Яндекс.Почты», протестировав SPDY на части своих реальных пользователей, установила, что среднее время загрузки изменилось всего лишь на 0,6% и не превысило статистической погрешности. Однако специалисты «Яндекс.Почты» обнаружили, тем не менее, положительный момент от использования SPDY. Поскольку число соединений с серверами уменьшилось (это ключевая особенность SPDY и HTTP/2), то нагрузка на серверы заметно сократилась).

Основы HTTP

HTTP обеспечивает общение между множеством хостов и клиентов, а также поддерживает целый ряд сетевых настроек.

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

Общение между хостом и клиентом происходит в два этапа: запрос и ответ. Клиент формирует HTTP запрос, в ответ на который сервер даёт ответ (сообщение). Чуть позже, мы более подробно рассмотрим эту схему работы.

Текущая версия протокола HTTP — 1.1, в которой были введены некоторые новые фишки. На мой взгляд, самые важные из них это: поддержка постоянно открытого соединения, новый механизм передачи данных chunked transfer encoding, новые заголовки для кэширования. Что-то из этого мы рассмотрим во второй части данной статьи.