Networks & Protocols
Сети и Протоколы
Сети и Протоколы
Общая теория
Модель OSI (Для общего развития)
Инфа с сайта: Что такое модель OSI и зачем она нужна: препарируем слоёный пирог интернета
Модель OSI (Open System Interconnection), или эталонная модель взаимодействия открытых систем описывает, как устройства в локальных и глобальных сетях обмениваются данными и что происходит с этими данными.
При этом сама по себе эталонная модель — нестандарт интернета, как, например, TCP/IP; её можно сравнить с фреймворками в мире языков программирования: в OSI «из коробки» доступны разные веб-стандарты — UDP, HTTP, FTP, Telnet и другие. Всего таких протоколов — более 100 штук.
Модель OSI включает семь слоев, или уровней, — причём каждый из них выполняет определённую функцию: например, передать данные или представить их в понятном для человека виде на компьютере. Кстати, у каждого слоя — свой набор протоколов.
рис. Семислойная модель OSI
1-й уровень OSI — физический (L1, physical layer)
На самом нижнем уровне модели OSI данные представляют собой физические объекты — ток, свет или радиоволны. Они передаются по проводам или с помощью беспроводных сигналов.
Этот слой работает с кабелями, контактами в разъёмах, модуляцией сигнала, кодированием единиц и нулей и другими низкоуровневыми штуками. По сути, первый уровень — это уровень проводов и физических способов передачи сигнала. Минимальная абстракция.
рис. Данные в виде сигналов передаются между устройствами
Самый известный протокол на физическом уровне — Ethernet. Он описывает, как сигналы кодируются и передаются по проводам. Кроме него есть Bluetooth, Wi-Fi и ИК-порт, которые также содержат инструкции для передачи данных.
Устройства физического уровня — концентраторы и репитеры. Они работают с физическим сигналом «втупую» и не вникают в его логику: получили данные — передали их дальше по проводу.
2-й уровень OSI — канальный (L2, data link layer)
Над физическим уровнем располагается канальный. Его задача — проверить целостность полученных данных и исправить ошибки. Этот уровень «поумнее» предыдущего: он уже понимает, что разные амплитуды напряжений отвечают разным битам — нулям и единицам. А ещё канальный уровень умеет кодировать сигналы в биты и передавать их дальше.
Полученные с нижнего уровня данные делятся на фреймы, или кадры. Каждый фрейм состоит из служебной информации — например, адреса отправителя и адреса получателя, — а также самих данных.
рис. Структура фрейма
Получается что-то вроде почтового конверта. На лицевой стороне у него написано, от кого пришло письмо, а внутри находится само письмо (в нашем случае данные).
Лицевая сторона конверта — это MAC-адрес устройства, которое отправило нам информацию. Он нужен, чтобы идентифицировать устройства в локальной сети, состоит из 48 или 64 бит и выглядит примерно так:
рис. Запись MAC-адреса в шестнадцатеричной системе счисления
Еще один важный факт о MAC-адресах: когда на заводе собирают ноутбук или смартфон, ему сразу же присваивают определенный MAC-адрес, который потом уже никак нельзя поменять. MAC-адрес настольных ПК зашит в сетевую карту, поэтому его можно изменить, только заменив эту самую карту.
рис. MAC - address в Linux
С помощью команды ifconfig можно узнать MAC-адрес вашего Macbook или компьютера на Linux. В Windows нужно ввести команду ipconfig.
Канальный уровень не так прост — он делится ещё на два подуровня:
уровень управления логическим каналом — LLC (logical link control);
уровень управления доступом к среде — тот самый MAC (media access control).
Первый подуровень нужен для взаимодействия с верхним уровнем, сетевым, а второй — для взаимодействия с нижним, физическим.
Устройства канального уровня — коммутаторы и мосты. Они нужны, чтобы передавать фреймы нужному адресату. Протоколы канального уровня — PPP, CDP.
3-й уровень OSI — сетевой (L3, network layer)
Этот уровень отвечает за маршрутизацию данных внутри сети между компьютерами. Здесь уже появляются такие термины, как «маршрутизаторы» и «IP-адреса».
Маршрутизаторы позволяют разным сетям общаться друг с другом: они используют MAC-адреса, чтобы построить путь от одного устройства к другому.
Данные на сетевом уровне представляются в виде пакетов. Такие пакеты похожи на фреймы из канального уровня, но используют другие адреса получателя и отправителя — IP-адреса.
Чтобы получить IP-адрес обоих устройств (отправителя и получателя), существует протокол ARP (address resolution protocol). Он умеет конвертировать MAC- в IP-адрес и наоборот.
рис. Устройство пакета
4-й уровень OSI — транспортный (L4, transport layer)
Из названия понятно, что на этом уровне происходит передача данных по сети. Так и есть. Два главных протокола здесь — TCP и UDP. Они как раз и отвечают за то, как именно будут передаваться данные.
TCP (Transmission Control Protocol) — это протокол, который гарантирует доставку данных в корректном виде. Он жёстко следит за каждым битом информации, но работает гораздо медленнее UDP.
Например, когда вы вводите логин и пароль при входе в социальную сеть, очень важно, чтобы все символы отправились в определённой последовательности. Если какие-то потеряются или изменятся, вы просто не сможете авторизоваться. Поэтому протокол TCP использует разные методы проверок — например, контрольные суммы.
рис. Схема TCP
А вот в видео или аудио небольшие потери не критичны, зато важна скорость передачи данных. Для таких задач как раз и придумали протокол UDP (user datagram protocol). Он уже не проверяет цельность битов, его задача — как можно быстрее передать данные с одного устройства на другое.
В протоколе TCP данные делятся на сегменты. Каждый сегмент — часть пакета. Сегменты нужны, чтобы передавать информацию по сети, учитывая ее пропускную способность.
Например, если вы передаете данные с компьютера, у которого пропускная способность 100 Мб/c, на смартфон с пропускной способность 10 Мб/c, то данные разделятся так, чтобы не застревать в самом медленном устройстве.
Ещё сегментация важна для надёжности. Один большой пакет может потеряться или направиться не тому адресату. А маленькие пакеты снижают риск подобных ошибок и даже позволяют проверять их количество. Если какой-то сегмент не получилось доставить, протокол TCP может запросить его у отправителя снова. Так обеспечивается надёжность.
В UDP данные делятся на датаграммы — это примерно то же, что и пакет, только датаграммы автономны. Каждая датаграмма имеет всё необходимое, чтобы дойти до получателя. Поэтому они не зависят от сети и могут доставляться по разным маршрутам и в произвольном порядке.
5-й уровень OSI — сеансовый (L5, session layer)
Начиная с этого уровня и выше, данные имеют уже нормальный вид — например, привычных нам JPEG- или MP3-файлов. Задача сети на этих уровнях — представить информацию в понятном для человека виде и сделать так, чтобы пользователь мог её как-то «потрогать».
Сеансовый уровень управляет соединениями, или сессиями. Типичный пример — звонок по Skype или Zoom. Когда вы звоните другому человеку, между вашими компьютерами устанавливается соединение, по которому передаются аудио и видео. Если такое соединение разорвать, то и ваш звонок прервется.
На сеансовом уровне очень важно, чтобы соединение правильно установилось и поддерживалось. То есть механизмы протоколов должны проверить, что у обоих собеседников есть нужные кодеки и сигнал между устройствами присутствует.
6-й уровень OSI — уровень представления данных (L6, presentation layer)
На этом уровне происходит преобразование форматов данных — их кодирование и сжатие. Например, полученные данные могут превратиться в GIF- или MP4-файл. То же самое происходит и в обратном порядке: когда пользователь отправляет файл другому человеку, данные сначала конвертируются в биты и сжимаются, а потом уже передаются на транспортный уровень.
Помимо кодирования и сжатия на уровне представления, данные могут шифроваться — если, конечно, это необходимо.
рис. процесс отправки данных с одного устройства на другое
7-й уровень OSI — прикладной (L7, application layer)
Последний уровень модели OSI — прикладной. На нём находятся сетевые службы, которые помогают без проблем серфить в интернете.
Прикладной уровень похож на некий графический интерфейс для всей модели OSI — с его помощью пользователь взаимодействует с другими уровнями, даже не подозревая об этом. Этот интерфейс называется сетевым.
Самые популярные из сетевых интерфейсов — это HTTP, HTTPS, FTP и SMTP. А «устройства» здесь — это уже программы: Zoom, Telegram, браузеры.
Описание кратко
Как на практике работает сетевая модель OSI
В начале статьи мы задались вопросом: а как передаются сообщения в Telegram? Настало время на него ответить — и показать весь процесс передачи данных по модели OSI.
Мы хотим отправить сообщение нашему другу. Печатаем текст и нажимает кнопку «Отправить», а дальше перемещаемся внутрь компьютера.
Прикладной уровень. Приложение Telegram работает на прикладном уровне модели OSI. Когда мы печатаем текст сообщения и нажимаем кнопку «Отправить», эти данные передаются на сервер мессенджера, а оттуда — нашему другу.
Весь процесс проходит через API разных библиотек — например, для HTTP-запросов. Интерфейсы позволяют без лишних проблем обмениваться данными и не погружаться в то, как они представлены на низком уровне. Всё, что нужно знать, — это какую функцию вызвать и какие переменные туда передать.
Уровень представления. Здесь данные должны преобразоваться в унифицированный формат, чтобы их можно было передавать на разные устройства и операционные системы. Например, если мы отправляем сообщение c Windows на macOS, данные должны быть в читаемом для компьютеров Apple виде. Такая же ситуация и с другими устройствами.
Раз мы собираемся передать данные на другой компьютер, их нужно перевести в бинарный формат. После этого начнётся сам процесс передачи по сети.
Сеансовый уровень. Чтобы данные успешно передались сначала на сервер Telegram, а затем к нашему другу, приложению нужно установить соединение, или сеанс. Он обеспечивает синхронизацию между устройствами и восстанавливает связь, если она прервалась.
Благодаря сеансам вы можете видеть, что собеседник что-то печатает или отправляет вам картинки или видео. Но главная задача этого соединения — обеспечить стабильное соединение для передачи данных.
Транспортный уровень. Когда соединение установлено и данные унифицированы, пора передавать их. Этим занимается транспортный уровень.
Здесь данные разбиваются на сегменты и к ним добавляется дополнительная информация — например, номер порта и контрольные суммы. Всё это нужно, чтобы данные дошли до пользователя в целостности.
Сетевой уровень. Теперь данным нужно найти маршрут к устройству нашего друга, а затем отправить их по нему. Поэтому данные упаковываются в пакеты и к ним добавляются IP-адреса.
Чтобы получить IP-адрес устройств, которым нужно отправить пакеты, маршрутизаторы (устройства сетевого уровня) обращаются к ARP. Этот протокол быстро найдёт адрес получателя и отдаст его нам.
Канальный уровень. Здесь данные передаются от одного MAC-адреса к другому. Изначальный текст делится на фреймы — с заголовками и контрольными суммами для проверки целостности данных.
Физический уровень. И на самом нижнем уровне данные в виде электрических сигналов передаются по проводам, кабелям или по радиоволнам. Тут только одна задача — как можно быстрее откликаться на сигналы свыше.
После прохождения всех уровней модели OSI сообщение успешно доставляется на устройство нашего друга. Правда, в реальности это занимает всего миллисекунды.
HTTP
Определение HTTP
HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данных. Основой HTTP является технология «клиент-сервер». HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.
Серверы как основные поставщики услуг хранения и обработки информации (обработка запросов).
Клиенты — конечные потребители услуг сервера (отправка запроса).
Прокси (посредники) для выполнения транспортных служб.
Структура HTTP-сообщения
Стартовая строка (англ. Starting line) — определяет тип сообщения. Стартовые строки различаются для запроса и ответа.
Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения. Для версии протокола 1.1 сообщение запроса обязательно должно содержать заголовок Host.
Тело сообщения (англ. Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой. Тело сообщения может отсутствовать, но стартовая строка и заголовок являются обязательными элементами. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа — только тело сообщения.
Метод HTTP (англ. HTTP Method) — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.
Методы HTTP
Далее идет информация о каждом методе в подробностях, стоит помнить, что работа методов зависит ОТ РЕАЛИЗАЦИИ на стороне сервера. Можно всю работу через GET настроить, но человечество создало данные абстракции, чтобы не путаться при общении друг с другом.
OPTIONS - Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов. Также в заголовке ответа может включаться информация о поддерживаемых расширениях.
GET - Используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса. Может иметь ТЕЛО!!!!!
HEAD - Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.
Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше — копия ресурса помечается как устаревшая.
POST - Применяется для передачи пользовательских данных заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер.
PUT - Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существует ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же ресурс был изменен, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-*, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или недопустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented). Сообщения ответов сервера на метод PUT не кэшируются.
Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.
Patch - Аналогично PUT, но применяется только к фрагменту ресурса.
DELETE - Удаляет указанный ресурс.
TRACE - Возвращает полученный запрос так, что клиент может увидеть, какую информацию промежуточные серверы добавляют или изменяют в запросе.
CONNECT - Преобразует соединение запроса в прозрачный TCP/IP-туннель, обычно чтобы содействовать установлению защищенного SSL-соединения через зашифрованный прокси.
Response-code/Status-code
Код, который получает клиент с ответом на свой запрос.
Отличия HTTP и HTTP(S)
HTTPS (HyperText Transfer Protocol Secure) — это тот же самый HTTP, но он добавляет шифрование передаваемых данных, используя криптографические протоколы, такие как SSL или TLS. На сервере размещается специальный сертификат и приватный ключ, с помощью которых происходит проверка подлинности, шифрование и расшифрование данных.
Передача данных по HTTPS происходит следующим образом: при посещении веб-сайта браузер делает запрос к серверу для получения информации о сертификате; получив копию SSL-сертификата со специальным ключом шифрования, проверяет подлинность сертификата. Если проверка проходит успешно, то используя полученный ключ, шифрует и отправляет данные на сервер, где они расшифровываются. Ключ действителен только для текущей сессии и уничтожается после ее завершения.
HTTP передает данные в «сыром» виде никак их не шифруя, поэтому перехватив их, злоумышленник может завладеть конфиденциальными данными, а если они будут зашифрованы, то даже, перехватив данные, не имея ключа, их будет практически невозможно расшифровать. HTTP по умолчанию использует 80 TCP-порт, а HTTPS использует 443.
ВАЖНО! В рамках нагрузочного тестирования, если конечное решение на ПРОМ контуре использует SSL, необходимо использовать его и в СНТ (средствах нагрузочного тестирования). Поскольку SSL даёт ~10-50 ms к времени отклика.
REST-API
Определение и ограничения
REST – архитектурный стиль взаимодействия приложений, очень простой, без каких- либо прослоек(прослоек, значит данные приходят в каком виде, в таком и уходят). Если использовать его, то повышается производительность приложения и упрощению архитектуры. Он полностью построен на http(s), формат обмена данными использует json, но можно и xml. Так как используется в основном http, то пользуют методы: get (получить инфу), post (передать от клиента параметры, мэил, пароль итд), delete, put(поменять значение), patch (частичное обновление ресурса).
Эти методы HTTP безопасные: GET , HEAD(запрос метаданных о ресурсах, без тела запроса) или OPTIONS(запрос информации о доступных методах, заголовки поддерживаются для данного ресурса), они не меняет состояние сервера. Другими словами, безопасный метод проводит операции “только чтение” (read-only). Все безопасные методы являются также идемпотентными(результат не меняется при повторных вызовах), как и некоторые другие, но при этом небезопасные, такие как PUT или DELETE.
Множество входов (endpoint), то есть для каждой процедуры/функции – свой вход.
При API REST данные запрашиваются в url, методами, которые были представлены в предыдущем предложении.
Свойства архитектуры REST
Свойства архитектуры, которые зависят от ограничений, наложенных на REST-системы:
Производительность: взаимодействие компонентов системы может являться доминирующим фактором производительности и эффективности сети с точки зрения пользователя;
Масштабируемость для обеспечения большого числа компонентов и взаимодействий компонентов.
Рой Филдинг (один из главных авторов спецификации протокола HTTP) описывает влияние архитектуры REST на масштабируемость следующим образом:
Простота унифицированного интерфейса;
Открытость компонентов к возможным изменениям для удовлетворения изменяющихся потребностей (даже при работающем приложении);
Прозрачность связей между компонентами системы для сервисных служб;
Переносимость компонентов системы путем перемещения программного кода вместе с данными;
Надежность, выражающаяся в устойчивости к отказам на уровне системы при наличии отказов отдельных компонентов, соединений или данных.
Требования к архитектуре REST
Существует пять обязательных ограничений для построения распределенных REST-приложений по Филдингу, и одно необязательное.
Накладываемые ограничения определяют работу сервера в том, как он может обрабатывать и отвечать на запросы клиентов. Действуя в рамках этих ограничений, система приобретает такие желательные свойства, как производительность, масштабируемость, простота, способность к изменениям, переносимость, отслеживаемость и надёжность.
Если сервис-приложение нарушает любое из этих ограничительных условий, данную систему нельзя считать REST-системой.
Обязательными условиями-ограничениями являются:
Модель клиент-сервер
Первым ограничением, применимым к гибридной модели, является приведение архитектуры к модели клиент-сервер. Разграничение потребностей является принципом, лежащим в основе данного накладываемого ограничения. Отделение потребности интерфейса клиента от потребностей сервера, хранящего данные, повышает переносимость кода клиентского интерфейса на другие платформы, а упрощение серверной части улучшает масштабируемость. Наибольшее же влияние на всемирную паутину, пожалуй, имеет само разграничение, которое позволяет отдельным частям развиваться независимо друг от друга, поддерживая потребности в развитии интернета со стороны различных организаций.
Отсутствие состояния
Протокол взаимодействия между клиентом и сервером требует соблюдения следующего условия: в период между запросами клиента никакая информация о состоянии клиента на сервере не хранится (Stateless protocol или «протокол без сохранения состояния»). Все запросы от клиента должны быть составлены так, чтобы сервер получил всю необходимую информацию для выполнения запроса. Состояние сессии при этом сохраняется на стороне клиента. Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например, в службу базы данных) для поддержания устойчивого состояния, например, на период установления аутентификации. Клиент инициирует отправку запросов, когда он готов (возникает необходимость) перейти в новое состояние.
Во время обработки клиентских запросов считается, что клиент находится в переходном состоянии. Каждое отдельное состояние приложения представлено связями, которые могут быть задействованы при следующем обращении клиента.
Кэширование
Как и во Всемирной паутине, клиенты, а также промежуточные узлы, могут выполнять кэширование ответов сервера. Ответы сервера, в свою очередь, должны иметь явное или неявное обозначение как кэшируемые или некэшируемые с целью предотвращения получения клиентами устаревших или неверных данных в ответ на последующие запросы. Правильное использование кэширования способно частично или полностью устранить некоторые проблемы клиент-серверного взаимодействия, еще больше повышая производительность и масштабируемость системы.
Единообразие интерфейса
Наличие унифицированного интерфейса является фундаментальным требованием дизайна REST-сервисов. Унифицированные интерфейсы позволяют каждому из сервисов развиваться независимо.
К унифицированным интерфейсам предъявляются следующие четыре ограничительных условия:
Идентификация ресурсов
Все ресурсы идентифицируются в запросах, например, с использованием URI в интернет-системах. Ресурсы концептуально отделены от представлений, которые возвращаются клиентам. Например, сервер может посылать данные из базы данных в виде HTML, XML или JSON, ни один из которых не является типом хранения внутри сервера.
Манипуляция ресурсами через представление
Если клиент хранит представление ресурса, включая метаданные — он обладает достаточной информацией для модификации или удаления ресурса.
«Самоописываемые» сообщения
Каждое сообщение содержит достаточно информации, чтобы понять, каким образом его обрабатывать. К примеру, обработчик сообщения (parser), необходимый для извлечения данных, может быть указан в списке MIME-типов.
Гипермедиа как средство изменения состояния приложения (HATEOAS)
Клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на сервере (к примеру, гиперссылки в гипертексте). Исключая простые точки входа в приложение, клиент не может предположить, что доступна какая-то операция над каким-то ресурсом, если не получил информацию об этом в предыдущих запросах к серверу. Не существует универсального формата для предоставления ссылок между ресурсами, Web Linking (RFC 5988 -> RFC 8288) и JSON Hypermedia API Language являются двумя популярными форматами представления ссылок в REST HYPERMEDIA сервисах.
Слои
Клиент обычно не способен точно определить, взаимодействует ли он напрямую с сервером или же с промежуточным узлом, в связи с иерархической структурой сетей (подразумевая, что такая структура образует слои). Применение промежуточных серверов способно повысить масштабируемость за счет балансировки нагрузки и распределенного кэширования. Промежуточные узлы также могут подчиняться политике безопасности с целью обеспечения конфиденциальности информации.
Код по требованию (необязательное ограничение)
В разделе не хватает ссылок на источники (см. рекомендации по поиску).
Информация должна быть проверяема, иначе она может быть удалена. Вы можете отредактировать статью, добавив ссылки на авторитетные источники в виде сносок. (16 марта 2017)
REST может позволить расширить функциональность клиента за счёт загрузки кода с сервера в виде апплетов или скриптов. Филдинг утверждает, что дополнительное ограничение позволяет проектировать архитектуру, поддерживающую желаемую функциональность в общем случае, но, возможно, за исключением некоторых контекстов.
Идемпотентные методы
Идемпотентный метод - это метод, который может быть вызван несколько раз подряд с одинаковыми параметрами входных данных, и каждый раз он будет давать одинаковый результат. Такой метод не изменяет состояние системы при повторном вызове и не приводит к нежелательным побочным эффектам. Это важно для систем, где повторное выполнение операции может быть нежелательным или даже опасным, например, при работе с финансовыми транзакциями.
Идемпотентность обычно достигается путем использования уникальных идентификаторов для каждой операции и проверки наличия таких идентификаторов перед выполнением операции.
SOAP
SOAP – протокол обмена сообщениями. Довольно старый, но пользуется спросом. Передает слишком большие сообщения, из-за этого снижает скорость обработки.
Поддерживает только XML. Отсюда следует, что мы должны куда-то передать XML и получить назад также XML. Поддерживать общий протокол передачи данных, что обеспечивает эффективность сетевой связи. Можно проверять на SOAP, чтобы избежать ошибки типа, проверяем с помощью XSD - тем он и лучше. Дает возможность избежать ошибок.
XML может иметь схему, где прописано какой тип должен иметь тот или иной атрибут.
Основывается на RPC (Remote Procedure Call, удаленный вызов процедур) – один вход (ссылка) на сервис для множества процедур.
При обращении к нему необходимо указать название процедуры, которую хотите вызвать и входные данные, которые нужны для этой процедуры;
Работает только по протоколу POST;
Может работать с различными протоколами. Например SMTP, FTP, HTTP, HTTPS. Чаще всего HTTP, но это не принципиально.
Всегда есть четкое описание методов WSDL(язык описания веб-сервисов и доступа к ним, который основан на языке XML), то есть прописано, что делает SOAP сервер;
XSD(XML SCHEMA DEFINITION) – язык описания структуры XML документа. Эта схема определяет то какие типы данных XML может принимать, число вложенных элементов, атрибуты, элементы, последовательность в которой отправлены эти элементы.
APACHE CXF – платформа с открытым исходным кодом, которая работает с WSDL. То есть она умеет валидировать и преобразовывать - WSDL to XML, WSDL TO SOAP, XSD to WSDL;
Как работает: клиент обращается к soap клиенту, который построен на soap, он принимает запрос клиента и после этого идет с этим запросом http и Soap (инструкцией) к soap серверу с запросом от клиента, который хранит необходимые данные и который также работает на Soap. Тот ему отвечает и дает ответ. Soap клиент принимает ответ и отдает данные клиенту по http.
Алгоритмы балансировки нагрузки
Статические алгоритмы
Не учитывают текущую загрузку узлов.
Round Robin (RR) – запросы распределяются по очереди.
Weighted Round Robin – как RR, но с весами (более мощные серверы получают больше запросов).
IP Hash – клиент всегда попадает на один и тот же сервер (на основе хеша IP).
Least Connections – запрос отправляется на сервер с наименьшим числом активных соединений.
Динамические алгоритмы
Учитывают текущую загрузку.
Least Response Time – выбирается сервер с наименьшим временем отклика.
Least Bandwidth – предпочтение отдается серверу с наименьшей используемой пропускной способностью.
Resource-Based – балансировка на основе загрузки CPU, RAM и других метрик.
Балансировка в структурах данных
Применяется для поддержания эффективности операций в деревьях, хеш-таблицах и других структурах.
Балансировка бинарных деревьев поиска (BST)
AVL-дерево – строгая балансировка (разница высот поддеревьев ≤ 1).
Красно-черное дерево – менее строгая балансировка, но быстрее вставка/удаление.
Splay-дерево – "самонастраивающееся" дерево, перемещающее часто используемые узлы ближе к корню.
Балансировка в хеш-таблицах
Consistent Hashing – минимизирует перераспределение данных при изменении числа серверов (используется в распределенных системах, например, в Redis, Cassandra).
B-деревья и B+-деревья
Используются в базах данных и файловых системах для балансировки глубины дерева при частых вставках и удалениях.
Балансировка в распределенных системах
Raft, Paxos – алгоритмы консенсуса для распределенного управления состоянием.
Gossip-протоколы – децентрализованное распространение информации о нагрузке.
Выбор алгоритма
Зависит от задачи:
Для веб-серверов – Round Robin, Least Connections.
Для баз данных – B-деревья, Consistent Hashing.
Для распределённых систем – Raft, Gossip.
GRPC (раздел на когда нибудь, не обязательно)
NGINX (ТОЖЕ БУДЕТ)
HAPROXY (БУДЕТ БУДЕТ)
F5 (ТОЧНО БУДЕТ)