Использование встроенного веб-сервера Sanic в Production - PullRequest
0 голосов
/ 10 октября 2019

Django документация гласит их сервер разработки:

Не используйте этот сервер во всем, что напоминает производственную среду. Он предназначен только для использования при разработке. (Мы занимаемся созданием веб-фреймворков, а не веб-серверов.)

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

Развернуть Sanic очень просто, используя один из трех вариантов: встроенный веб-сервер, веб-сервер ASGI или gunicorn. Также очень распространено размещение Sanic за обратным прокси-сервером, например, nginx.

Для меня это означает свободу от Apache. Это также означает, что Nginx, Gunicorn, Daphne, Uvicorn, Hypercorn и т. Д. Являются необязательными.

Однако я обнаружил некоторые негативные комментарии относительно встроенного сервера в Sanic: веб-сервер python, который написан так, чтобы быстро умирать. С другой стороны, их репозиторий GitHub кажется очень активным. Они обращались к проблемам, упомянутым в сообщении Reddit?

Я что-то упустил?

1 Ответ

2 голосов
/ 11 октября 2019

В выпуске 1 рассматриваются параметры размера запроса и времени ожидания, которые допускают DoS-атаки, наводняя сервер слишком большим количеством данных. Эти параметры могут быть изменены администратором в соответствии с оборудованием сервера и требованиями сайта, на котором выполняется. При этом значения по умолчанию, вероятно, должны быть ниже, чем они, чтобы сделать такие атаки на ненастроенные серверы более сложными.

В выпуске 2 утверждается, что в потоковых ответах отсутствует обработка противодавления. Текущая версия имеет управление потоком и, таким образом, получает надлежащее управление противодавлением, избегая таких проблем. Поскольку при проектировании асинхронных протоколов в Python это было упущено из виду, у многих приложений в прошлом были такие проблемы, возможно, в том числе и у Sanic во время написания блога.

Как и сейчас, сервер Sanic можетбезусловно, работает непосредственно в Интернете, и на самом деле это намного безопаснее, чем запуск Django за nginx или Apache, где любой длительный POST-запрос блокирует весь рабочий Django.

...