Обслуживание Python (Flask) API REST через HTTP2

Question

У меня есть служба REST Python, и я хочу обслуживать ее с помощью HTTP2. Моя текущая настройка сервера - nginx -> Gunicorn. Другими словами, nginx (порт 443 и 80, который перенаправляется на порт 443) работает как обратный прокси-сервер и отправляет запросы в Gunicorn (порт 8000, без SSL). nginx работает в режиме HTTP2, и я могу проверить, что с помощью chrome и проверки столбца «protocol» после отправки простого GET на сервер. Однако Gunicorn сообщает, что запросы, которые он получает, являются HTTP1.0. Кроме того, я coulnt't найти его в этом списке: https://github.com/http2/http2-spec/wiki/Implementations Итак, мои вопросы:

• Можно ли служить приложение Python (Flask) с http2? Если да, какие серверы поддерживают его?
• В моем случае (один обратный прокси-сервер и один обслуживающий фактический API), какой сервер должен поддерживать HTTP2?

Причина, по которой я хочу использовать HTTP2, заключается в том, что в некоторых случаях мне нужно выполнить тысячи запросов, и мне было интересно узнать, может ли функция мультиплексированных запросов HTTP2 ускорить процесс. С запросами HTTP1.0 и Python в качестве клиента каждый запрос занимает ~ 80 мс, что неприемлемо. Другим решением было бы просто загрузить/загрузить ресурсы REST и отправить несколько запросов с одним запросом. Да, эта идея звучит просто прекрасно, но мне действительно интересно узнать, может ли HTTP2 ускорить работу.

Наконец, я должен упомянуть, что для клиентской стороны я использую запросы Python с адаптером Hyper http2.

Answer 1

Возможно ли использовать приложение Python (Flask) с HTTP/2?

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

В моем случае (один обратный прокси-сервер и один обслуживающий фактический API), какой сервер должен поддерживать HTTP2?

Теперь я собираюсь идти по тонкому льду и давать мнения.

Способ, которым был распространен HTTP/2, заключается в использовании пограничного сервера, который говорит HTTP/2 (например, ShimmerCat или NginX). Этот сервер завершает TLS и HTTP/2, а оттуда использует HTTP/1, HTTP/1.1 или FastCGI для общения с внутренним приложением.

Может, по крайней мере теоретически, пограничный сервер говорить HTTP/2 в веб-приложении? Да, но HTTP/2 сложный и для внутренних приложений он не очень хорошо окупается.

Это связано с тем, что большинство веб-приложений основаны на обработке запросов на контент, и это достаточно хорошо сделано с HTTP/1 или FastCGI. Хотя есть исключения, веб-приложения мало используют для тонкостей HTTP/2: мультиплексирования, определения приоритетов, множества несложных мер предосторожности и т. Д.

В результате разделение проблем, на мой взгляд, хорошее.

---

Ваш 80 мс Время отклика может иметь мало общего с протоколом HTTP вы используете, но если эти 80 мс, в основном тратится на ожидание ввода/вывода, то, конечно, работает вещи параллельно хорошая вещь ,

Gunicorn будет использовать поток или процесс для обработки каждого запроса (если только вы не прошли лишнюю милю, чтобы сконфигурировать блендер greenlets), подумайте, разрешите ли Gunicorn выдавать тысячи задач в вашем случае.

Если содержимое ваших запросов позволяет это сделать, возможно, вы можете создавать временные файлы и обслуживать их с помощью пограничного сервера HTTP/2.

Answer 2

Теперь можно обслуживать HTTP/2 непосредственно из приложения Python, например, используя Twisted. Вы спросили конкретно о приложении Flask, хотя в этом случае я (с предубеждением) рекомендую Quart, который API Flask переопределяется поверх asyncio (с поддержкой HTTP/2).

Действительная проблема,

С HTTP1.0 и Python запросов, как клиент, каждый запрос занимает ~ 80ms

подсказывает мне, что проблема, которую вы можете испытывать, что каждый запрос открывает новое соединение. Это можно было бы облегчить с помощью connection pool, не требуя HTTP/2.