**Концентратор (хаб)** - самое простое устройство, которое раскидывает входящие пакеты данных по всем портам. **Коммутатор (свитч)** - распределяет пакеты данных не всем подключенным устройствам, а учитывает MAC-адреса устройств, подключенных к соответствующим портам. **Маршрутизатор (роутрер)** - более продвинутый чем свитч, позволяет настройки. **Уровни протокола TCP/IP:** 1) Прикладной уровень или уровень приложения - FTP, SMB (или самба для доступа к сетевым директориям), HTTP, HTTPS, SSH, DNS. 2) Транспортный уровень - уровень протоколов TCP, UDP. 3) Межсетевой уровень - уровень протокола IP 4) Канальный уровень - как передаются данные **Порт** определяет какому приложение пришел тот или иной пакет.

DNS

Нужен для сопоставления имени IP-адресу хоста. **TTL** - time to live. Этот параметр домена отвечает за время кеширования IP-адреса хоста на DNS серверах. **Записи DNS:** * A-запись — для сопоставления доменного имени IPv4-адресу. * AAAA-запись — для сопоставления доменного имени IPv6-адресу. * TXT-запись — для хранения любой текстовой информации. Используется, например, для верификации домена на разных сервисах или для хранения антиспам-настроек почты на домене. * MX-запись — для почтового сервера.

HTTP

Отправка HTTP запроса с методом **HEAD** ```bash $ nc google.com 80 HEAD / HTTP/1.0 ``` HTTP-статусы ответа: - `200 OK` — при обработке запроса не возникло ошибок, всё в порядке, нормальный запрос и нормальный ответ; - `201 CREATED` — данные успешно созданы на сервере, этот ответ применяется для методов POST и PUT. Почему для PUT он может применяться, у нас же PUT не создаёт данные? На самом деле PUT тоже может создавать новые записи, если клиент генерирует их идентификаторы, как мы узнаем позже; - `204 NO CONTENT` — запрос успешно обработан, но в теле нет данных для ответа, этот статус может использоваться для DELETE-запросов, то есть удалили и удалили, что тут еще скажешь, или PUT-запросов — обновили данные и обновили, всё; - `301 MOVED PERMANENTLY` — веб-страница «переехала» на новый адрес на постоянной основе, это статус для переадресации, когда мы заходим в браузере на одну веб-страницу, а нас автоматически перебрасывает на другую. Один из способов сделать такое — как раз веб-серверу в HTTP заголовке отдать статус 301 и указать новый адрес страницы; - `304 NOT MODIFIED` — содержимое страницы не изменилось с прошлого запроса и его не нужно загружать снова; - `400 BAD REQUEST` — этот статус говорит о какой-то общей ошибке запроса, без конкретики; - `401 UNAUTHORIZED` — в запросе не передан корректный токен аутентификации, то есть его нет или он некорректный. Токен аутентификации — это строка, которая идентифицирует пользователя, который выполняет запрос, как правило токен аутентификации выдаётся пользователю после аутентификации, то есть ввода логина и пароля на сервисе; - `403 FORBIDDEN` — пользователь сейчас не авторизован для доступа к этому веб-сервису, то есть у него нет для этого прав; - `404 NOT FOUND` — пожалуй, самый известный HTTP статус, страница или ресурс не найдены. Возникает, когда веб-сервер не находит у себя запрашиваемый адрес. Например, веб-сервер Google на момент написания этих строк ничего не знает об адресе `http://google.com/chto-proiskhodit/`, если вы откроете её в браузере, то увидите ошибку 404, а также увидите 404 HTTP статус, если отправите на этот адрес запрос с использованием Telnet (попробуйте!); - `405 METHOD NOT ALLOWED` — показывает, что веб-сервис в целом существует, но не может обработать переданный HTTP-метод, этот метод для этого сервиса недопустим; - `409 CONFLICT` — конфликт, чаще всего при выполнении PUT-запроса. Например, в нашей БД у каждого пользователя уникальный email, и вот один из пользователей пытается обновить в своем профиле email на тот, что уже есть у другого пользователя в нашей БД — тогда 409й статус это отличный вариант сказать клиентскому коду о том, что происходит; - `422 UNPROCESSABLE ENTITY` — синтаксис запроса верный, но какое-то значение некорректно. Например, запрос ожидает, что будет передан телефон в формате +79…, а телефон передан в другом формате; - `500 Internal Server Error` — внутренняя ошибка сервера, на сервере что-то пошло не так, без уточнения что именно; - `501 NOT IMPLEMENTED` — сервер не может выполнить запрос, так как он не распознаёт запрос, например, потому что переданный HTTP-метод неизвестен; - `502 BAD GATEWAY` — ошибка шлюза, когда сервер, стоящий за прокси-сервером, падает — если пока не поняли, о чем речь, не страшно, дальше разберемся; - `503 SERVICE UNAVAILABLE` — сервис недоступен, например, потому что что-то на нём сейчас перезагружается. Разделение по типам: - `2xx` — успешные ответы; - `3xx` — редирект, то есть перенаправление на другой адрес; - `4хх` — ошибки клиентского запроса, когда запрос неверный, например, запрос несуществующей страницы или запрос с неправильными данными, неправильной структурой и так далее; - `5xx` — ошибка сервера. Может быть много разных серверных ошибок, все они имеют номера, начинающиеся с пятерки.
Cookie
Сервер просит клиента установить определенное значение cookie для отправки в последующих запросов. Например, может использоваться в идентификации пользователя. Формат заголовка для установки Cookies (упрощённый): ``` Set-Cookie: cookie-name=cookie-value; Domain=domain-value ``` Например — кука с именем `name` и значением `Alexey` для домена `google.com`: ``` Set-Cookie: name=Alexey; Domain=google.com ```
URL
``` https://www.google.com/search?q=python&start=10#something ``` - часть `https://` это, как мы уже знаем, протокол, в данном случае HTTPs, шифрованный HTTP; - `www.google.com` это доменное имя; - порт в данном случае не указан, так как указан протокол HTTPs, значит, будет использован порт «по умолчанию», 443й, то есть эти URI имеют идентичный результат: `https://www.google.com/search?q=python&start=10#something` `https://www.google.com:443/search?q=python&start=10#something` - часть `/search` отвечает за адрес ресурса на веб-сервере; - следующая часть `?q=python&start=10` это дополнительные параметры, которые передаются на сервер, их ещё называют query-параметрами, параметрами запроса. Такие динамические параметры используются программами на сервере, обрабатывающими запрос. В данном случае параметр `q` (вероятно, сокращение от _query_, что можно перевести как _запрос_), равен `python`, то есть поисковый запрос для этой странички это слово «python», а параметр `start` равен `10`, этот параметр похоже используется Google для разбивки результатов поисковой выдачи на страницы. Как видно, query-параметры в URI разделяются символом `&`; - часть `#something` это так называемый _anchor_ — якорь на странице. Например, если страница представляет собой длинный текст, разбитый на разделы, можно каждому разделу установить свой якорь, тогда, открывая страницу с указанием якоря для первого раздела наша страничка сразу «проскроллится», то есть пролистается до первого раздела. Эти якори явным образом указываются в HTML-документе. Как мы помним, HTML-документ это просто текстовый документ с определённой заложенной в него структурой. Вот эта структура в частности и позволяет делать такие якори внутри страницы. С HTML подробнее мы познакомимся позже.
Способы передачи данных на сервер:
- передача данных в составе элемента пути, например, `https://google.com/search/python` или `https://rroom.io/user/alexey.goloburdin` - query-параметры, например, `https://google.com/search?q=python&start=10&lang=ru`. Если надо использовать символ `&` в составе значения параметра, он заменяется на `%26`: `google.com/search?q=you%26me`. Для пробелам замена на `%20`. - передача в теле запроса, например, в теле POST-запроса - в cookies - в HTTP-заголовках запроса, в том числе своих HTTP-заголовках запроса (HTTP это позволяет) - есть и другие варианты, например, веб-сокеты, но это уже специфика для своих задач
Методология REST
CRUD — сокращение от Create, Read, Update, Delete. Как может выглядеть API для CRUD-операций по книгам: - `POST /books/` — создание новой книги - `GET /books/` — чтение списка книг. Пагинация, то есть разбитие списка книг на страницы, осуществляется Query-параметрами, например, так: - `GET /books/?page=3`. Параметр `page` равен `3`. Наш бэкенд-сервис считает эти параметры и поймет, что запрашивается страница с номером 3. Аналогично для каких-то динамических фильтров могут использоваться тоже query-параметры. - `GET /books/123` — получение информации по книге с идентификатором `123` - `PUT /books/123` — обновление информации по книге с идентификатором `123` — причем обновляется вся книга, то есть должны быть переданы все поля книги этому сервису на вход - `PATCH /books/123` — частичное обновление книги с идентификатором `123` , например, только её названия. Если этот сервис примет на вход только название книги, то он должен изменить название книги и всё - `DELETE /books/123` — удаление данных о книге с идентификатором `123` Каждый из этих веб-сервисов отдаёт свои HTTP-статусы, которые подробно говорят клиенту о том, что именно произошло на бэкенде с запросом, например: - если клиент запрашивает список книг и книги найдены, то статус `200`; - если клиент запрашивает одну книгу по идентификатору и книга не найдена, то статус `404`; - если клиент пытается добавить книгу, но не передал токен аутентификации или токен некорректный, то `401`; - если клиент передал корректный токен аутентификации, но пользователю почему-то нельзя добавлять книги — например, если их могут добавлять на сайт только какие-то конкретные пользователи, не все, то статус `403`; - если пытается обновить несуществующую книгу — `404`; - если клиент создал новую книгу успешно — `201`; - если клиент успешно обновил книгу — `204` или `200`.

Дополнительные материалы

По протоколу HTTP можно почитать собственно первоисточник — например, RFC 2616, это RFC по HTTP/1.1. [Ссылка](https://www.rfc-editor.org/rfc/rfc2616). В частности тут подробно описаны все HTTP-методы, HTTP-статусы и вся прочая информация. Я считаю, что это полезно полистать. Также относительно недавно вышла книга на русском языке «HTTP/2 в действии», Поллард Б. Книга описывает нововведения и особенности второй версии протокола HTTP (будем об этом говорить в следующей главе). И также неплохие материалы по HTTP (как и по другим темам веб-технологий) приведены на сайте MDN, Mozilla Developer Network, [ссылка](https://developer.mozilla.org/ru/docs/Web/HTTP/Basics_of_HTTP). В частности тут [приведены](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/422) отличные описание HTTP-статусов. Когда будем изучать фронтенд-технологии, мы будем часто обращаться к сайту MDN, поэтому берите его сразу на заметку и в целом можете начинать читать его.