Acasă Explorează Ajutor
Autentificare
Home
/
obsidian
2
0
Bifurcare 0
Fisiere Probleme 0 Trageți solicitările 0 Wiki
Ramură: tmp
Ramuri Etichete
obsidian
/
hardcore web development
/
5-6-7 Internet.md

5-6-7 Internet.md 18 KB
Permalink Istoric Crud

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

Коммутатор (свитч) - распределяет пакеты данных не всем подключенным устройствам, а учитывает 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

    $ 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. Ссылка. В частности тут подробно описаны все HTTP-методы, HTTP-статусы и вся прочая информация. Я считаю, что это полезно полистать.

Также относительно недавно вышла книга на русском языке «HTTP/2 в действии», Поллард Б. Книга описывает нововведения и особенности второй версии протокола HTTP (будем об этом говорить в следующей главе).

И также неплохие материалы по HTTP (как и по другим темам веб-технологий) приведены на сайте MDN, Mozilla Developer Network, ссылка. В частности тут приведены отличные описание HTTP-статусов.

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