Привет! Сегодня мы будем разбираться в протоколах HTTP и HTTPS. Но для начала давай проясним один момент: речь идет о протоколах передачи данных по сети на прикладном уровне модели OSI. С моделью OSI, как ты помнишь, мы разбирались в одной из предыдущих статей. А если не помнишь — вот она.
Что такое протокол передачи данных
Так называют общепринятое соглашение, благодаря которому разработчики разных сервисов отправляют информацию в едином виде.
Например, используя Google Chrome, ты можешь получить информацию и с Facebook, и с Twitter, потому что разработчики передают ее с помощью стандартного протокола HTTP, а твой браузер умеет его обрабатывать.
Единые правила очень удобны и самим разработчикам серверных частей: существует очень много библиотек, которые могут за тебя преобразовать информацию и отправить по необходимому протоколу.
Изначально HTTP задумывался как протокол передачи HTML-страниц. Долгое время так и было, но сейчас программисты частенько передают по нему и строки, и медиафайлы. В общем, этот протокол универсальный и гибкий, и использовать его действительно просто. А как это делать — сейчас разберемся.
Структура HTTP
Сразу стоит отметить, что HTTP-протокол состоит только из текста. Ну а нас больше всего интересует структура, в которой расположен этот текст.
Каждое сообщение состоит из трех частей:
Стартовая строка (Starting line) — определяет служебные данные.
Заголовки (Headers) — описание параметров сообщения.
Тело сообщения (Body) — данные сообщения. Должны отделяться от заголовков пустой строкой.
По HTTP-протоколу можно отправить запрос на сервер (request) и получить ответ от сервера (response). Запросы и ответы немного отличаются параметрами.
Тело сообщения отсутствует.
В HTTP-запросе обязательны только стартовая строка и заголовок Host.
Теперь разберем все по порядку.
HTTP-запрос должен содержать какой-то метод. Всего их девять: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT. Самые распространенные — GET и POST. Этих двух методов на первых порах будет достаточно.
GET — запрашивает контент из сервера. Поэтому у запросов с методом GET нет тела сообщения. Но при необходимости можно отправить параметры через path в таком формате:
https://cdn.javarush.com/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2
Здесь:
javarush.com — хост,
/send — путь запроса,
? — разделитель, обозначающий, что дальше следуют параметры запроса.
В конце перечисляются параметры в формате ключ=значение, разделенные амперсандом.
POST — публикует информацию на сервере. POST-запрос может передавать разную информацию: параметры в формате ключ=значение, JSON, HTML-код или даже файлы. Вся информация передается в теле сообщения.
Например:
Запрос отправляется по адресу javarush.com/user/create/json, версия протокола — HTTP/1.1. Accept указывает, какой формат ответа клиент ожидает получить, Content-Type — в каком формате отправляется тело сообщения. Content-Length — количество символов в теле.
HTTP-запрос может содержать много разных заголовков. Подробнее с ними можно ознакомиться в спецификации протокола.
HTTP-ответы
После получения запроса, сервер его обрабатывает и отправляет ответ клиенту:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98
<html>
<head>
<title>An Example Page</title>
</head>
<body>
<p>Hello World</p>
</body>
</html>
Стартовая строка в респонсе содержит версию протокола (HTTP/1.1), Код статуса (200), Описание статуса (OK). В заголовках — тип и длина контента. В теле ответа — HTML-код, который браузер прорисует в HTML-страницу.
Response Status Codes
С телом сообщения и заголовками все ясно, а о кодах статусов стоит сказать пару слов. Response Status Codes всегда трехзначные, и первая цифра кода указывает категорию ответа:
1xx — информационный. Запрос получен, сервер готов к продолжению;
2xx — успешный. Запрос получен, понятен и обработан;
3xx — перенаправление. Следующие действия нужно выполнить для обработки запроса;
4xx — ошибка клиента. Запрос содержит ошибки или не отвечает протоколу;
5xx — ошибка сервера. Сервер не смог обработать запрос, хотя был составлен верно;
Вторая и третья цифры в коде детализируют ответ.
Например:
200 OK — реквест получен и успешно обработан;
201 Created — реквест получен и успешно обработан, в результате чего создан новый ресурс или его экземпляр;
301 Moved Permanently — запрашиваемый ресурс был перемещен навсегда, и последующие запросы к нему должны происходить по новому адресу;
307 Temporary Redirect — ресурс перемещен временно. Пока к нему можно обращаться, используя автоматическую переадресацию;
403 Forbidden — запрос понятен, но нужна авторизация;
404 Not Found — сервер не нашел ресурс по этому адресу;
501 Not Implemented — сервер не поддерживает функциональность для ответа на этот запрос;
505 HTTP Version Not Supported — сервер не поддерживает указанную версию HTTP-протокола.
Вдобавок к статус-коду ответа также отправляется описание статуса, благодаря которому интуитивно понятно, что значит конкретный статус.
HTTP-протокол очень практичен: в нем предусмотрено большое количество хедеров, используя которые можно настроить гибкое общение между клиентом и сервером. Все хедеры запросов и ответов, методы запросов и статус-коды ответов невозможно рассмотреть в одной статье. При необходимости можешь почитать официальную спецификацию протокола, которая описывает все нюансы.
HTTP-протокол принято использовать на порту 80, поэтому когда ты видишь адрес, который заканчивается портом 80, можешь быть уверен, что к нему нужно обращаться по HTTP.
С развитием технологий и активным перемещением персональных данных в интернет пришлось задуматься о том, как обеспечить дополнительную защиту информации, которую клиент передает серверу. В результате появился протокол HTTPS.
В чем отличие между HTTPS и HTTP
HTTPS синтаксически идентичен протоколу HTTP, то есть использует те же стартовые строки и заголовки. Единственные отличия — дополнительное шифрование и порт по умолчанию (443).
HTTPS шифруется между HTTP и TCP, то есть между прикладным и транспортным уровнями. Если забыл, что это такое, загляни в статью о модели OSI.
Современный стандарт шифрования — по протоколу TLS. В эту темы мы слишком углубляться не будем, но запомни, что шифрование происходит перед тем, как информация попадает на транспортный уровень. В HTTPS шифруется абсолютно вся информация, кроме хоста и порта, куда отправлен запрос.
Для перевода сервера на использование HTTPS протокола вместо HTTP, нам не нужно менять код сервера. Включение этой фичи происходит в контейнерах сервлетов, о которых мы поговорим в следующих статьях.
А на сегодня все. Впрочем, погоди. Чтобы пощупать HTTP-запросы, открой Google Chrome, нажми F12, выбери вкладку Network. Тут будут отображаться все реквесты и респонсы, отправленные/полученные твоим браузером.
Часть 4.Основы MavenЧасть 5. Сервлеты. Пишем простое веб-приложениеЧасть 6. Контейнеры сервлетовЧасть 7. Знакомство с паттерном MVC (Model-View-Controller)Часть 8. Пишем небольшое приложение на spring-boot
С данным утверждением не согласен - "Тело сообщения отсутствует." - тело можно передать с помощью метода GET, а вот то что не рекомендуется отпавлять данные в теле запроса GET по спецификации - тут уже истина проявляется.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ