Бэкенд1 Flashcards
Что такое клиент-серверная архитектура?
Клиент-серверная архитектура представляет собой модель взаимодействия между программными компонентами, при которой один компонент (клиент) обращается к другому компоненту (серверу) для получения данных
Клиент - это
это устройство или приложение, которое отправляет запросы на сервер для получения данных или выполнения определенных задач. Может быть написан на разных языках программирования и работать на разных устройствах.
Сервер - это
Сервер предоставляет данных или услуги клиенту. Он обрабатывает запрос, выполняет определенный запрос и отправляет обратно ответ на запросы клиенту.
API - это
это набор определенных правил, протоколов и инструментов, который позволяют различным программным приложениям взаимодействовать между собой. API определяет способы, с помощью которых приложения могут отправлять запросы друг другу для получения данных или выполнения определенных операций.
Основные правила общения, которые могут быть часть API:
Формат: JSON, XMl.
Методы: GET, POST, PUT, DELETE.
Аутентификация и безопасность: токены, ключи доступа, пароли и тд.
Описание эндопоинтов: эндопоинты - это конечные точки в API, определящие конкретные адреса и URL, по которым можно отправить запросы для получения определенных данных и выполнения определенных действий.
Документация и справочные материалы: swagger - документация к API/
HTTP - это
это протокол передачи данных, который используется для обмена информацией между клиентами и серверами в сети Интернет.
Разница между HTTP и HTTPS
HTTP: протокол передачи данных, не шифруется, не используются сертификаты, порт 80.
HTTPS: расширение протокола передачи данных, шифруется, используются сертификаты, порт 443.
HTTPS - это
это расширение протокола HTTP с использованием шифрования для обеспечения безопасной передачи данных.
SSL-сертификат - это
SSL-сертификат - это цифровой сертификат, удостоверяющий подлинность веб-сайта и позволяющий использовать зашифрованное соединение.
Методы запросов HTTP
GET - получение данных с сервера
PUT - загрузка или обновление содержимого ресурса на сервере
POST - отправка данных на сервер
DELETE - удаление ресурсов с сервера
PATCH - частичное обновление ресурса на сервере
Разница между GET и POST
Предназначение:
GET - получение данных
POST - отправка данных
Способ перелечи данных:
GET- через URL
POST- в теле HTTP запроса
Объем передаваемых данных:
GET - до 2048 символов
POST - без ограничений
Возможность отправки файлов:
GET - не поддерживается
POST - поддерживается
Возможность сохранения:
GET - можно скопировать, сохранить
POST - нельзя
Скорость обработки:
GET - быстрее и с меньшим потреблением ресурсов
POST - медленнее и тяжелее( из-за наличия тела)
Защита данных:
GET - данные видны всем в адресной строке, в истории браузера и тд, данные не защищены
POST - данные защищены
Поддержка соединений:
GET - не разрывает HTTP соединение
POST - разрывает HTTP соединение
Безопасные методы
Безопасные методы предназначены для получения данных и не должны влиять на состояние ресурсов на сервере, т.е. не должны инициировать какие-либо изменения данных или их структуры.
GET - запрос данных с сервера, извлекает данные и не должен вносить изменений в состояние данных на сервере.
HEAD - сервер возвращает только заголовки ответа без тела сообщения, позволяет извлечь метаданные, связанные с ресурсом, не передавая сам ресурс.
OPTIONS - используется для запроса описания параметров связи для целевого ресурса без вызова какого-либо действия на сервере.
Идемпотентные методы - это
это методы, которые либо не изменяют состояние в базе данных, либо изменяют состояние только при первом запросе. GET, PUT, DELETE, HEAD, OPTIONS
Из чего состоит HTTP запросы:
Стартовая строка - определяет тип сообщения.
-Метод HTTP запроса
-Цель запроса
-Версия используемого протокола
Заголовки - характеризует тело сообщения, параметры передачи и тд. “Имя-Заголовок: Значение”
Три категории заголовков:
-Общего назначения- применяется ко всему сообщению
-Заголовки запроса - уточняют некоторую информацию о запросе, сообщая дополнительный контекст или ограничивая его некоторыми логическими условиями
-Заголовки представления - описывает формат данных сообщения и используемую кодировку(только с телом)
Тело сообщения - данные сообщения. Обязательно должно отделяться псто строкой от заголовка.
Не у каждого HTTP-метода предполагается наличие тела.
HTTP запросы. Основные элементы запроса на сервер
- Метод запроса(GET, POST, PUT, DELETE, PATCH)
- URL - указывает сервер и точный адрес ресура на сервере
- Headers (заголовки) - содержит дополнительную информацию о запросе и клиенте, отправляющем запрос.
- Body (тело запроса) - необязательный компонент, присутствующий в некоторых типах запросов.
- Query Parameters (параметры запроса) - опциональные ключи и значения, которые добавляются к URL запроса после знака вопроса. Используются для передачи дополнительной информации серверу.
- Cookies(куки) - хотя они обычно передаются в заголовках запроса, они играют важную роль в управление сессиями и аутентификации пользователя, позволяя серверу идентифицировать возвращающего пользователя.
HTTP ответы. Основные элементы ответа на сервере
- Status Line (статусная строка) - содержит версию протокола HTTP, используемую сервером, числовой статусный код ответа
- Response Headers (заголовки ответа) - дополнительная информация о сервере и о том, как должен быть обработан запрос.
- Пустая строка - отделяет заголовок ответа от тела ответа.
- Response Body (тело ответа) - содержит данные, запрошенные клиентом
HTTP заголовки
HTTP Headers - несколько строчек текста в определенном формате, которые либо уточняют запрос, либо описывают содержимое тело сообщения.
-General Headers (общие заголовки) - в запросах ит ответах
-Request Headers (заголовки запроса) - только в запросах
-Response Headers (заголовки ответа) - только в ответах
Общие заголовки и заголовки запроса:
Accept: указывает тип данных, которые клиент может обработать.
Authorization: содержит информацию о доступе к ресурсу.
Cache-Control: управляет кэшированием ресурсов.
Connection: управляет соединением между клиентом и сервером.
Content-Length: указывает размер тела сообщения.
Content-Type: указывает тип содержимого сообщения.
User-Agent: указывает информацию о браузере или клиенте
Заголовки ответа:
Cache-Control: управляет кэшированием ресурсов.
Content-Language: указывает язык, используемый для тела сообщения.
Content-Length: указывает размер тела сообщения.
Content-Type: указывает тип содержимого сообщения.
Date: указывает дату и время отправки сообщения.
Location: указывает URL, на который клиент должен перейти.
Set-Cookie: устанавливает соое на клиенте.
Протоколы передачи данных:
TCP (Transmission Control Protocol): TCP является протоколом транспортного уровня в модели OSI. Он обеспечивает надежную и устойчивую передачу данных между устройствами. ТСР разделяет данные на пакеты, нумерует их и гарантирует их доставку в правильном порядке. Он также обеспечивает контроль ошибок и управление потоком данных.
UDP (User Datagram Protocol): UDP также является протоколом транспортного уровня и обеспечивает более легковесный способ передачи данных. В отличие от TCP, UDP не гарантирует надежную доставку данных и не обеспечивает контроль ошибок и управление потоком. Он часто используется для передачи данных, где небольшая потеря пакетов приемлема, например, в потоковом видео или в онлайн-играх.
НТТР (Hypertext Transfer Protocol): HTTP является протоколом прикладного уровня, используемым для передачи данных в вебе. Он базируется на протоколе ТСР и определяет стандарты для запросов и ответов между веб-браузерами и веб-серверами.
Формирование HTTPS запроса
- Установка ТСР-соединения: Клиент устанавливает ТСР-соединение с сервером на порту 443.
- Процесс SSL/TLS (Handshake): После установки ТСР-соединения, происходит процесс рукопожатия SSL/TLS, который включает в себя следующие шаги:
Приветствие (Hello): Клиент и сервер обмениваются сообщениями, включая поддерживаемые версии протокола и криптографические алгоритмы.
Обмен сертификатами: Сервер предоставляет свой цифровой сертификат клиенту, который содержит открытый ключ сервера и подпись центра сертификации.
Аутентификация: Клиент проверяет, что сертификат подписан доверенным центром сертификации, что гарантирует подлинность сервера.
3.Формирование НТТР запроса: После успешного установления безопасного соединения клиент формирует НТТР запрос так же, как и в случае НТТР, но с использованием “https” в URL и с префиксом “https://” перед именем хоста.
- Шифрование данных: Все данные, включая заголовки и тело запроса, шифруются с использованием симметричного ключа, который был установлен в процессе рукопожатия SSL/TLS.
- Отправка запроса: Зашифрованный НТТР запрос отправляется по безопасному соединению.
- Обработка сервером: Сервер расшифровывает полученные данные, обрабатывает НТТР запрос и отправляет зашифрованный НТТР ответ обратно клиенту.
Статус коды
HTTP статус коды представляют собой трехзначные числа, которые сервер отправляет в ответ на запрос клиента.
1хх (Информационные коды)
2хх (Успешные коды) 200ОК - запрос успешно выполнен, 201 Created - ресурс успешно создан в ответ на POST-запрос
3хх (Коды перенаправления) 301 Moved Permanently - ресурс перемещен на постоянной основе, 302 Found - ресурс временно перемещен, 304 Not Modified - ресурс не был изменен с момента последнего запроса.
4хх (Коды ошибок клиентов) 400 Bad Request - запрос некорректен или не может быть обработан сервером, 401 Unauthorized - клиент не авторизован для доступа к ресурсу, 403 Forbidden - ограничение или отсутствие доступа к материалу на странице, которую клиент пытается загрузить, 404 Not Found - запрашиваемый ресурс не найден на сервере, 405 Method Not Allower - метод запроса не разрешен для данного ресурса
5хх(Коды ошибок сервера) 500 Internal Server Error - общая ошибка сервера, 503 Server Unavailable - сервер временно не может обрабатывать запросы
Кеш и куки - это. Их связь и их влияние на производительность.
Кеш - это временное хранение данных в браузере, которое позволяет ускорить загрузку веб-страниц и улучшить производительность.
Куки - небольшие текстовые файлы, которые хранятся на компьютере пользователя и содержат информацию о его действиях на веб-страницах.
Они связаны тем, что они оба используются для хранения данных в браузере.
Они имеют влияние на производительность браузера. Кеш может ускорить загрузку веб-страниц, а Куки могут помочь в персонализации веб-страниц.
REST и REST API - это
REST - это архитектурны стиль взаимодействия компонентов распределенной системы, который используют для передачи данных между сервером и клиентом.
REST API - это API основанный на принципах REST-а.
Что такое SOAP? Как выглядит сообщение SOAP?
это буквально протокол доступа к объектам . Чаще всего используется по вверх HTTP, однако могут использоваться и другие протоколы вроде SMTP и FTP.
Envelope - корневой элемент, который определяет сообщение и пространство имен, использованное в документе
Header - содержит атрибуты сообщения
Body - содержит сообщение, которым обмениваются сообщения
Fault - необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработки сообщения
Разница между XML и HTML
XML создан для работы с данными (именное для передачи данных между системами)
HTML создан для отображения данных
WSDL и XSD
WSDL - файл, который используется для описания веб-сервисов
XSD - это язык описания структуры XML документа
Плюсы и минусы монолитного подхода
Плюсы:
-Простота и легкость в разработки - компоненты системы тесно связаны, поэтому писать и тестировать такой код легок.
-Производительность и эффективность - тк все компоненты выполняются в рамках одного процесса, нет нужды в межпроцессном взаимодействие.
-Среда совместно используемых данных - у всех компонентов прямой доступ к той же базе данных, что позволяет беспрепятственно обмениваться этими данными
Минусы:
-Масштабирование - масштабировать монолиты не так уж просто, ведь все приложение масштабируется как единое целое.
-Стек - монолиты часто “связаны” на определенном стеке технологий.
Плюсы и минусы микросервисной архитектуры:
Плюсы:
-Масштабируемость и гибкость - каждый микросервис можно масштабировать независимо от других, исходя от его конкретных потребностей.
-Разнообразие и автономия - каждый сервер работает обособленно, так что можно подобрать для него разные технологии и фреймворки
-Непрерывная доставка и развертывание - сервисы не имеют привязку друг к другу, благодаря чему их можно разрабатывать, тестировать и развертывать обособленно.
Минусы:
-Сложность с управление распределенной системой
-Издержки на координацию и взаимодействие процессов
