emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

Forwarded from Системный сдвиг

Сколько вы знаете способов передачи данных на клиент по инициативе сервера?

В комментариях к предыдущему посту отмечают, что GraphQL не совсем верно упоминать рядом с Websockets, это вещи разного уровня. Давайте разберемся, и вспомним все варианты отправки данных с на клиент в тот момент, когда их решил отправить сервер.

Я насчитал 6 (добавляйте, если знаете ещё):

1. Long polling — обычный http-запрос, но сервер дает ответ только в тот момент, когда у него появились/изменились данные. Если данные не появились до истечения таймаута, соединение разрывается, но клиент тут же его восстанавливает. После получения ответа соединение тоже восстанавливается.

2. WebHooks — по сути, обратный вызов http. Серверу каким-то образом нужно сообщить адрес эндпоинта клиента и код события, по наступлении которого нужно этот эндпоинт вызвать. Сообщить можно через настройки, а можно через специальное API. В терминах языков программирования — это callback. Когда на сервере произойдет событие, он вызовет ваш эндпоинт.

3. WebSockets — отдельный протокол, первоначальное соединение устанавливается через http, в котором клиент передает хедер upgrade, и дальше уже происходит переключение протокола, и общение идёт через websocket — полнодуплексный канал между клиентом и сервером, где они оба могут пересылать друг другу сообщения (текстовые или бинарные). Очевидные кейсы: чат, многопользовательская игра, совместное редактирование документа/картинки. Отличается от других асинхронных способов получения данных тем, что соединение полнодуплексное — клиент может отправлять данные в том же соединении.

4. Server-Sent Events (SSE) — почему-то редко вспоминают, но это штука, похожая на long polling, только сервер может пересылать несколько порций данных сразу в одном соединении. И это тоже http! Клиент при этом указывает специальный тип контента: text/event-stream (если шлет в веб-браузер) и application/stream+json (если шлет в другой клиент, не в браузер).

5. HTTP/2 streams — бинарный протокол, на базе которого работает gRPC. HTTP/2 в принципе построен на понятии потока, в котором клиент что-то запрашивает, а сервер что-то шлет в ответ... Так что идея полнодуплексного обмена появляется почти автоматически — почему бы серверу в том же потоке не слать данные по собственной инициативе.

6. HTTP/3, который QUIC — примерно то же, что и HTTP/2 — на уровне использования приложением, все различия внутри: он на основе UDP, а не TCP, что дает ряд преимуществ, в основном в скорости. Подробнее про HTTP разных версий можно почитать тут. В двух словах — борьба идет за число открытых соединений с сервером: в HTTP/1.0 соединение обрывается после каждого ответа сервера, в HTTP/1.1 появился заголовок keep-alive, сохраняющий TCP соединение, в HTTP/2 много соединений TCP от клиента к серверу объединили в одно, а в HTTP/3 вообще перешли на UDP, в котором вообще нет сложного процесса установки соединений.

Разобраться со всеми этими технологиями бывает сложновато, поэтому низкоуровневые протоколы пакуют в инструменты более высокого уровня абстракции — типа того же GraphQL или разнообразных API в браузере (streams API, fetch API, WebTransport) — про которые программисты уже не думают, как они внутри устроены, а просто ими пользуются.

На самом деле, внутри GraphQL либо WebSocket, либо multipart subscriptions over HTTP (ещё один способ, похожий на SSE — когда мы устанавливаем соединение по http, сервер говорит, что будет отдавать multipart/mixed контент, а потом начинает эти части клиенту отдавать по мере появления/изменения).

А  стримминг в gRPC работает по технологии HTTP/2 или HTTP/3, это тоже обертка.

Что в этом для аналитиков? А вот что: кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими. При высокой интенсивности обмена между системами будет просто открываться канал, в котором они будут обмениваться сообщениями, а уж будут эти сообщения устроены вокруг операций с ресурсами, или вокруг вызова функций, или это будет поток сообщений в стиле event-driven — это на логическом уровне будет разбираться приложение.

👍15❤1

www.tgoop.com/emacsway_log/1495

2.04K viewsIvan, Feb 17 at 19:56

Сколько вы знаете способов передачи данных на клиент по инициативе сервера?

В комментариях к предыдущему посту отмечают, что GraphQL не совсем верно упоминать рядом с Websockets, это вещи разного уровня. Давайте разберемся, и вспомним все варианты отправки данных с на клиент в тот момент, когда их решил отправить сервер.

Я насчитал 6 (добавляйте, если знаете ещё):

1. Long polling — обычный http-запрос, но сервер дает ответ только в тот момент, когда у него появились/изменились данные. Если данные не появились до истечения таймаута, соединение разрывается, но клиент тут же его восстанавливает. После получения ответа соединение тоже восстанавливается.

2. WebHooks — по сути, обратный вызов http. Серверу каким-то образом нужно сообщить адрес эндпоинта клиента и код события, по наступлении которого нужно этот эндпоинт вызвать. Сообщить можно через настройки, а можно через специальное API. В терминах языков программирования — это callback. Когда на сервере произойдет событие, он вызовет ваш эндпоинт.

3. WebSockets — отдельный протокол, первоначальное соединение устанавливается через http, в котором клиент передает хедер upgrade, и дальше уже происходит переключение протокола, и общение идёт через websocket — полнодуплексный канал между клиентом и сервером, где они оба могут пересылать друг другу сообщения (текстовые или бинарные). Очевидные кейсы: чат, многопользовательская игра, совместное редактирование документа/картинки. Отличается от других асинхронных способов получения данных тем, что соединение полнодуплексное — клиент может отправлять данные в том же соединении.

4. Server-Sent Events (SSE) — почему-то редко вспоминают, но это штука, похожая на long polling, только сервер может пересылать несколько порций данных сразу в одном соединении. И это тоже http! Клиент при этом указывает специальный тип контента: text/event-stream (если шлет в веб-браузер) и application/stream+json (если шлет в другой клиент, не в браузер).

5. HTTP/2 streams — бинарный протокол, на базе которого работает gRPC. HTTP/2 в принципе построен на понятии потока, в котором клиент что-то запрашивает, а сервер что-то шлет в ответ... Так что идея полнодуплексного обмена появляется почти автоматически — почему бы серверу в том же потоке не слать данные по собственной инициативе.

6. HTTP/3, который QUIC — примерно то же, что и HTTP/2 — на уровне использования приложением, все различия внутри: он на основе UDP, а не TCP, что дает ряд преимуществ, в основном в скорости. Подробнее про HTTP разных версий можно почитать тут. В двух словах — борьба идет за число открытых соединений с сервером: в HTTP/1.0 соединение обрывается после каждого ответа сервера, в HTTP/1.1 появился заголовок keep-alive, сохраняющий TCP соединение, в HTTP/2 много соединений TCP от клиента к серверу объединили в одно, а в HTTP/3 вообще перешли на UDP, в котором вообще нет сложного процесса установки соединений.

Разобраться со всеми этими технологиями бывает сложновато, поэтому низкоуровневые протоколы пакуют в инструменты более высокого уровня абстракции — типа того же GraphQL или разнообразных API в браузере (streams API, fetch API, WebTransport) — про которые программисты уже не думают, как они внутри устроены, а просто ими пользуются.

На самом деле, внутри GraphQL либо WebSocket, либо multipart subscriptions over HTTP (ещё один способ, похожий на SSE — когда мы устанавливаем соединение по http, сервер говорит, что будет отдавать multipart/mixed контент, а потом начинает эти части клиенту отдавать по мере появления/изменения).

А  стримминг в gRPC работает по технологии HTTP/2 или HTTP/3, это тоже обертка.

Что в этом для аналитиков? А вот что: кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими. При высокой интенсивности обмена между системами будет просто открываться канал, в котором они будут обмениваться сообщениями, а уж будут эти сообщения устроены вокруг операций с ресурсами, или вокруг вызова функций, или это будет поток сообщений в стиле event-driven — это на логическом уровне будет разбираться приложение.

BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.