|
|
@@ -0,0 +1,81 @@
|
|
|
+**Концентратор (хаб)** - самое простое устройство, которое раскидывает входящие пакеты данных по всем портам.
|
|
|
+
|
|
|
+**Коммутатор (свитч)** - распределяет пакеты данных не всем подключенным устройствам, а учитывает 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
|
|
|
+```
|
