**Концентратор (хаб)** - самое простое устройство, которое раскидывает входящие пакеты данных по всем портам.

**Коммутатор (свитч)** - распределяет пакеты данных не всем подключенным устройствам, а учитывает MAC-адреса устройств, подключенных к соответствующим портам.

**Маршрутизатор (роутрер)** - более продвинутый чем свитч, позволяет настройки.

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

**Порт** определяет какому приложение пришел тот или иной пакет.
<h4>DNS</h4>
Нужен для сопоставления имени IP-адресу хоста.
**TTL** - time to live. Этот параметр домена отвечает за время кеширования IP-адреса хоста на DNS серверах.
**Записи DNS:**
* A-запись — для сопоставления доменного имени IPv4-адресу.
* AAAA-запись — для сопоставления доменного имени IPv6-адресу.
* TXT-запись — для хранения любой текстовой информации. Используется, например, для верификации домена на разных сервисах или для хранения антиспам-настроек почты на домене.
* MX-запись — для почтового сервера.
<h4>HTTP</h4>
Отправка 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` — ошибка сервера. Может быть много разных серверных ошибок, все они имеют номера, начинающиеся с пятерки.
<h6>Cookie</h6>
Сервер просит клиента установить определенное значение cookie для отправки в последующих запросов. Например, может использоваться в идентификации пользователя.
Формат заголовка для установки Cookies (упрощённый):

```
Set-Cookie: cookie-name=cookie-value; Domain=domain-value
```

Например — кука с именем `name` и значением `Alexey` для домена `google.com`:

```
Set-Cookie: name=Alexey; Domain=google.com
```
<h6>URL</h6>
```
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 подробнее мы познакомимся позже.

<h6>Способы передачи данных на сервер:</h6>

- передача данных в составе элемента пути, например, `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 это позволяет)

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

<h6>Методология REST</h6>
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`.
<h4>Дополнительные материалы</h4>
По протоколу 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, поэтому берите его сразу на заметку и в целом можете начинать читать его.