Как клиент и сервер взаимодействуют в вебе

Вроде бы, тема совсем для начинающих. Как клиент (браузер) общается с сервером (сайтом) в вебе? Но готов поспорить, что процентов 80 пиэмов не смогут внятно об этом рассказать. Для них и статья. Оставшиеся 20, выросшие из технарей, вряд ли извлекут из этой публикации что-то новое.

Полетели.

Веб работает в архитектуре клиент‑сервер. С одной стороны веб‑сервер, с другой — клиент: браузер, приложение (например, для андроида или айфона) или даже другой веб‑сервер. Клиент и веб‑сервер общаются с помощью протокола HTTP (Hypertext Transfer Protocol) — специального языка и набора правил. Раньше в начале любого адреса в адресной строке мы видели http://, потом как-то все перешли на безопасную зашифрованную версию https:// А сейчас этот префикс, по крайней мере хром, не отображает вовсе.

Когда мы открываем сайт в браузере, браузер посылает запрос, буквально пишет серверу «Дай мне страницу index.html» или «Дай мне goatse.jpg»:

GET /index.html HTTP/1.1
Host: bychko.ru
User-Agent: Chrome

Здесь GET — это метод запроса, /index.html — путь к тому, что мы запрашиваем, а HTTP/1.1 — версия протокола. Дальше идут заголовки — набор строк в формате ключ: значение. Это дополнительная информация, которая помогает серверу узнать больше о клиенте и его запросе.

Сервер на этот запрос отвечает «Забирай страницу» или «Вот goatse.jpg»:

HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html>
<html>
  ...
</html>

200 — это код, статус ответа. Сервер всегда возвращает статус ответа. По этому коду клиент понимает, всё ли нормально. А именно:

Коды в интервале от 200 до 299 — запрос успешен, показываем данные пользователю.

Коды в интервале от 300 до 399 — редирект. Такое бывает, когда у странички меняется адрес, а пользователь стучится по старому и его перенаправляют. 

Коды в интервале от 400 до 499 — это ошибки на стороне клиента. Например, 404 Not Found — указанной страницы нет.

Коды в интервале от 500 до 599 — ошибки сервера. Например, 500 Internal Server Error — внутренняя ошибка сервера, проблема в коде. Есть телеграм-канал с приколами «Пятисотые на проде».

В целом, пользователю про этот обмен сообщениями знать ничего не надо. Да и менеджеру тоже. Но если вы руководите разработкой чего-то клиент-серверного, не помешает умение заглянуть в консоль. Для этого нужно открыть веб‑инспектор с помощью ⌘+Option+I на Маке и Ctrl+Shift+I или F12 в дру­гих ОС. Потом переключаемся на вкладку «Сеть» (вы удивитесь, сколько всякого говна грузится вместе с вашим любимым сайтом):

Хромовский инспектор, отображающий сетевые запросы

Очень часто на собеседованиях спрашивают: чем отличается GET от POST?

Гетом браузер забирает данные от сервера, постом отправляет данные — строчки из полей формочек или файлы. Когда вы откликаетесь на вакансию на сайте компании и прикрепляете резюме, всё содержимое формы, вместе с pdf отправляется на сервер именно POST-ом.

Ещё бывают:

  • PUT — «замени», 
  • PATCH — «обнови», 
  • DELETE — «удали».

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

GET и POST принципиально отличаются тем, как с помощью них передаются данные, параметры на сервер. В случае с GET данные идут в адресе, урле, а в случае с POST — в теле запроса. Ну, вы понимаете — чтобы запросить данные, надо отправить урл с запросом, а чтобы отправить данные — засунуть их в тело и заслать на сервер. А именно:

GET /search?text=управление рисками HTTP/1.1
Host: bychko.ru
POST /search HTTP/1.1
Host: bychko.ru
Content-Type: application/x-www-form-urlencoded

text=управление рисками

В остальном, детальные различия между GET и POST вот такие:

GET

Запрашивает данные с сервера.

Параметры передаются в URL-е, вы можете их видеть в адресной строке браузера.

Нужен для поиска, фильтрации, загрузки страничек.

Остаётся в истории браузера1, можно добавить в закладки

Post

Отправляет данные на сервер.

Параметры передаются в теле запроса, в адресной строке их не видно.

Нужен для отправки форм (например, данные заказа авиабилета), файлов.

Не остаётся в истории браузера, нельзя добавить в закладки.


  1. Умные люди подсказывают, что остаётся запрос в истории браузера или нет, зависит не от типа запроса, а от кода ответа. Если на запрос POST ответить с кодом 200, 404, 500 и пр., он также останется в истории. Чтобы в историю не попало, нужно вернуть код перенаправления. Правилом хорошего тона в веб‑программировании является всегда возвращать «временный редирект» (код 302), на запросы POST, независимо от результата обработки. ↩︎

Опубликовано

в

,

от

Подпишитесь на новые посты, чтобы не пропускать их (РКН о сборе имейлов уведомлён должным образом):

Добавить комментарий

Предыдущий пост
Владимир Бычко описывает техсобес на руководителя проектов в «Сараффан Радио».…