Разное

TCP, UPD

Это транспортные уровни в стеке протоколов.

TCP, Transmission Control Protocol - протокол передачи данных, отвечает за надёжную доставку данных и сохранение порядка передаваемых сообщений. Например, TCP используется для передачи файлов, причём в сети файлы не передаются целиком, а дробятся и передаются в виде относительно небольших сообщений. Далее на другом устройстве все полученные части повторно собираются в файл. В TCP из-за полной проверки целостности пакетов размер передаваемых данных выше, чем у протокола UPD. 

UPD, User Datagram Protocol - протокол передачи данных, где неважно, если часть пакетов будет потеряно при передаче. Проще говоря, просто отправляет пакеты и не ждет ничего в ответ. Из-за этого достигается высокая скорость в ущерб надежности. Чаще всего UDP применяется в чувствительных ко времени службах, где потерять пакеты лучше, чем ждать. Например: онлайн-звонки и конференции, стриминг видео, онлайн-трансляции, онлайн-игры. А также и в DNS-серверы, поскольку они должны быть быстрыми и эффективными.

HTTP

HTTP - это протокол передачи гипертекста. Проще говоря, это тип разметки, которая добавляется в текстовые документы для определенного отображения текста. В стеке протоколов HTTP находится на прикладном уровне и использует потокол TCP для передачи данных. Режим работы HTTP - запрос-ответ: клиент посылает серверу запрос на передачу web-страницы, после чего сервер пересылает эту страницу клиенту. При этом нет жестко заданного формата пакетов: используется текстовый режим.

REST, RPC, SOAP

REST

REST представляет собой стиль архитектуры ПО для распределенных систем. REST — это набор правил того, как программисту организовать написание кода серверного приложения, чтобы все системы легко обменивались данными и приложение можно было масштабировать. Для сервисов, построенных с учётом REST, применяют термин «RESTful». В отличие от сервисов на основе SOAP, не существует «официального» стандарта для RESTful веб-API. Дело в том, что REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют такие стандарты, как HTTP, URL, JSON и, реже, XML.

Требования к архитектуре REST:

1. Модель клиент-сервер

2. Отсутствие состояния

3. Кэширование

4. Единообразие интерфейса

5. Слои

6. Код по требованию (необязательное ограничение)

Пример реализации RESTful: JSON через HTTP

RPC

RPC, remote procedure call - уалённый вызов процедур — класс технологий, позволяющих программам вызывать исполнение блока кода на сервере. Обычно реализация RPC-технологии включает два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов.

В то время как REST рассматривает всё как ресурсы, RPC рассматривает действия. Клиенты обычно передают имя метода и аргументы серверу и получают обратно JSON или XML.

Плюсы:

• Очень прост.
• Легковесный payload, высокая производительность за счёт сериализации.

Минусы:

• Труден в обнаружении ошибок.
• Практически нет стандартизации.
• Может быть создано слишком много эндпоинтов. В REST например, на один эндпоинт можно навесить несколько действий, благодаря различию в передаваемом методе (GET, POST и т. д.)

SOAP

SOAP — это протокол, представляет собой XML, включающий:

• Envelope (конверт) – корневой элемент, который определяет сообщение и пространство имен, использованное в документе,
• Header (заголовок) – содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации,
• Body (тело) – содержит сообщение, которым обмениваются приложения,
• Fault – необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений. И запрос, и ответ должны соответствовать структуре SOAP.

Пример реализации SOAP: XML поверх SOAP через HTTP

GraphQL

GraphQL — это язык запросов для API. GraphQL позволяет клиентам определять структуру требуемых данных. Сервер возвращает именно эту структуру.

Пример запроса:

POST /graphql
HOST api.github.com
Content-Type: application/json
Authorization: bearer OAUTH-TOKEN
{
   user(login: "username") {
    id
    name
    company
    createdAt
   }
}

Пример ответа:

{   "data": {
      "user": {
         "id": "xxx",
         "name": "Ivan Ivanov",
         "company": "myCompany",
         "createdAt": "2001-01-10T12:00:00Z"
      }
   }
}

В отличие от REST и RPC API, GraphQL требует только один эндпоинт URL. Также вам не нужны разные HTTP-методы для описания операции. Вместо этого вы указываете в теле JSON выполняете ли вы запрос или мутацию. GraphQL поддерживает методы GET и POST.

Что происходит, когда вводишь адрес страницы в браузере?

Для начала нужно понимать, что вводя адрес страницы, мы получаем некоторую информацию ввиде текста, картинок, видео на свой компьютер от другого компьютера.

Вводимый адрес страницы говорит браузеру, где именно достать информацию. Любой адрес страницы имеет обязательные части: протокол, хост. И необязательные: порт, путь, параметры запроса.

По протоколу определяется способ отправки данных на компьютер, где хранится искомая информация (его называют Сервер), и получения данных обратно на компьютер, на котором мы и вводим адрес сайта. Его называют Клиентом. Чаще всего используется протокол https, в котором описывается, как нужно передавать данные по сети. https состоит из нескольких уровней: сетевой (IP), транспортный (TCP), сеансовый уровень, уровень представления (SSL / TLS) и прикладной уровень (HTTP). Например, TCP описывает, что данные нужно разделить по частям, а не отправлять единым файлом, причём во время передачи этих частей (или по-другому говорят пакетов) по каналам связи часть из них может потеряться, поэтому TCP проверяет, чтобы все пакеты были доставлены и снова собраны в один файл.

В адресе страницы после протокола идёт хост, который даёт информацию о том, на каком сервере нужно искать информацию. Каждый сервер имеет свой адрес, называемый ip-адрес, который состоит из цифр, разделённых точкой. Хост может состоять и из букв. Чтобы знать, где именно находится сервер, существуют DNS сервера. Если используется хост в символьном формате, то он сначала преобразовывается в цифровой вид в этих DNS серверах, а затем обращается к конкретному серверу по этому ip-адресу.

Далее, на сервере может стоять механизм определения, к какому конкретно сервису нужно обратиться. Такой механизм обычно называется прокси-сервер. Он определяет нужный сервис по символьному названию хоста, если использовалось символьное название. А также по порту. Порты позволяют навешивать на один хост несколько сервисов. Если порт не указан, то используется 443 в случае с https. Для повышения быстродействия прокси-сервер может делать балансировку нагрузки, перенаправляя запрос на разные серверы с таким же сервисом.

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

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

Например, когда мы только вводим адрес страницы, мы формируем запрос с методом GET. По сути передаётся текстовая информация на сервер. Пришедшие данные с сервера также имеют текстовый формат, в котором также указывается служебная информация и сгенерированные данные. Эти данные описываются в формате html в виде тегов, которые объясняют браузеру, что нужно отобразить, как нужно отобразить информацию (инструкции или по-другому программный код в css тегах) и как с ней можно взаимодействовать (код в js тегах). Когда мы отправляем какие-то данные на сервер, то отправляется, как правило, не GET запрос, а, например, POST, PUT или PATCH, который содержит отправляемые данные в теле запроса.

Источники

1. https://tproger.ru/articles/vybor-request-response-paradigmy-api-rest-rpc-ili-graphql/
2. https://proglib.io/p/computer-networking
3. https://selectel.ru/blog/tcp-vs-udp/