Прекратить трафик GRPC с помощью nginx
Этот недавний пост говорит, что nginx может прекратить HTTP / 2 а также GRCP трафика.
Из всех иллюстраций и текста не похоже, что он вообще может прерывать трафик grpc, только прокси, пересылка и маршрутизация трафика.
Причина в том, что я хочу предложить простые сервисы через nginx с PHP. Я знаю, что сам PHP обладает способностью реализовывать http / 2 и grpc, но это своего рода «руководство», ничего готового к использованию нет из коробки. Если мы сможем использовать nginx для завершения, это, вероятно, будет работать легко.
Еще одна вещь, которую я не понимаю из того же поста:
Примечание: NGINX не поддерживает HTTP / 1 и HTTP / 2 одновременно на порту открытого текста (не TLS). Требуются предварительные знания о том, какая версия протокола будет использоваться. Если вы хотите обрабатывать обе версии протокола через открытый текст, создайте порт прослушивания для каждой из них.
Когда оба являются открытым текстом, фактически используемый протокол известен заранее (потому что это открытый текст), и мы можем прослушивать оба на одном и том же порту. Два разных порта имеют смысл только для меня, когда один из протоколов не в открытом виде.
Может кто-нибудь прояснить эти два момента для меня?
Решение
Для меня это означает «прекратить» в смысле способности действовать как конечная точка для пользователя извне системы. Точно так же, как вы часто «завершаете» HTTPS в граничной точке (например, Nginx), но затем передаете незашифрованный HTTP-трафик на нисходящий сервер.
Таким образом, вам все еще нужен отдельный сервер, который понимает, как обрабатывать gRPC, и он должен быть доступен через порт для nginx, чтобы общаться с ним, используя grpc_pass,
От Примеры PHP на сайте gRPC кажется, что PHP используется только в качестве gRPC-приложения на стороне клиента, а не на стороне сервера:
Обратите внимание, что в настоящее время вы можете создавать только клиенты на PHP для gRPC
услуги — вы можете узнать, как создать серверы gRPC в нашем другом
учебные пособия, например Node.js.
Поэтому вам нужен сервер gRPC на стороне сервера (например, Node.js) для ответа на ваши вызовы gRPC — и это не может быть просто nginx, хотя nginx можно использовать для маршрутизации вызовов gRPC на этот сервер gRPC. Существуют различные причины иметь веб-сервер, такой как nginx, перед внутренним сервером приложений, включая: разгрузку SSL / TLS, обработку статического содержимого, балансировку нагрузки и т. Д.
Когда оба являются открытым текстом, протокол, который будет использоваться на самом деле, известен
фронт (потому что это открытый текст), и мы могли бы слушать как на
тот же порт.
Это не так просто, как вы думаете. Синтаксический анализ сообщений для определения того, являются ли они тем или иным протоколом, на самом деле довольно сложный — особенно учитывая, что HTTP / 1 является текстовым, HTTP / 2 — двоичным, а gRPC использует только HTTP / 2 в качестве транспортного уровня и даже не использует семантику HTTP под ним. этот.
Обычно для HTTP-сервера есть три способа узнать, является ли он HTTP / 2 или нет:
- Сначала используйте открытый текст HTTP, а затем обновите его до HTTP / 2.
- Используйте зашифрованный HTTPS, где это согласовано с использованием ALPN (или более старого NPN), как часть настройки TLS перед отправкой первого HTTP-сообщения.
- Используйте открытый текст HTTP, но предположите, что это соединение HTTP / 2 (из-за некоторых предыдущих предварительные знания о сервисе на этом порту) и так просто начните говорить HTTP / 2.
Похоже, Nginx делает не разрешить первый способ обновления для преобразования открытого HTTP / 1.1-соединения в HTTP / 2. Это означает, что для обычного текстового HTTP это позволяет только немедленно использовать соединение как HTTP / 2 («предварительные знания»). Eсть запросить использование HTTP / 1 и HTTP / 2 на одном и том же порту для разных соединений но, если честно, я могу понять, почему это еще не было завершено, так как я бы учел этот низкий приоритет, учитывая, что основной сценарий использования HTTP / 2 на данный момент — для браузеров (которые только HTTPS) или для сервисов, таких как gRPC, которые, вероятно, должен знать, являются ли они HTTP / 2 или нет.
Кроме того, как упоминалось выше, gRPC на самом деле не относится к HTTP — он просто использует уровень двоичного кадрирования HTTP / 2 для отправки сообщений gRPC через мультиплексированное соединение с управлением потоком. Это похоже на то, как веб-сокеты используют соединение HTTP TCP для отправки сообщений, которые не являются HTTP (хотя веб-сокеты обычно используют семантику HTTP для согласования соединения веб-сокета).
Поэтому, как я уже сказал, для меня имеет смысл не усложнять ситуацию и пытаться угадать протокол, когда не используется HTTPS — это должно быть известно в большинстве случаев.
Другие решения
Других решений пока нет …