Каков механизм проталкивания на стороне сервера grpc?

Question

Пока я пишу сервис с использованием grpc, я пытаюсь сравнить http / 2 с веб-сокетом по механизму проталкивания на стороне сервера.

Я знаю, что для websocket клиент отправит запрос с помощью команды Upgrade: WebSocket and Connection: обновить заголовки на сервер и установить долгоживущее соединение. После этого сервер отправит данные бесплатно после установления соединения.

Но для grpc, так как он маршрутизируется по http / 2, со страницы вики, https://en.wikipedia.org/wiki/HTTP/2_Server_Push,, он говорит, что серверу нужно будет предсказать потенциальные запросы, которые клиент отправит, и отправить кадр PUSH_PROMISE на ранней стадии. насколько это возможно.

Вот мои два вопроса:

1. Означает ли это, что серверу также потребуется получить соответствующий ответ (запрос) от клиента в ответ на этот заголовок PUSH_PROMISE, чтобы решить, хочет ли клиент получить или отклонить определенный push-запрос?

2. В Grpc, если у меня потоковая передача на стороне сервера, скажем, отправлять сообщение каждые 1 секунду с сервера. Означает ли это, что серверу необходимо отправлять PUSH_PROMISE клиенту каждую 1 секунду или хотя бы до того, как каждый кадр данных, который сервер отправляет клиенту?

Answer 1

gRPC в настоящее время не поддерживает / не использует PUSH_PROMISE.

Потоковые RPC в gRPC используют потоки HTTP / 2;весь RPC содержится в запросе / ответе в HTTP.Основное отличие состоит в том, что реализации HTTP / 2 обычно позволяют таким потокам быть потоковыми и двунаправленными (клиент может отправлять больше в запросе после прочтения части ответа), тогда как в HTTP / 1 это было попаданием или пропуском.

В gRPC клиент всегда будет инициировать RPC.Но для потоковой передачи на сервере сервер может с течением времени отвечать несколькими сообщениями через поток.Это будет похоже на сценарий, который вы описали с помощью веб-сокетов.