Мой друг недавно задал мне следующий вопрос: учитывая, что у Django уже есть runserver, почему он не расширился до готового к работе HTTP-сервера для клиентов?Вместо этого люди создают uwsgi сервер, который говорит на WSGI и предоставляет то, на что Nginx перенаправляет трафик путем обратного проксирования ...
Исходя из того, что я знаю, многие другие языки используют этот шаблон:«простой» HTTP-сервер, предназначенный для разработки, а также интерфейс для * GI (ASGI / WSGI / FCGI / CGI), которому веб-сервер должен обратный прокси-сервер.В чем основная причина того, что эти веб-серверы не готовы к работе и вместо этого предполагают наличие другого веб-сервера?
Вот некоторые из моих теорий, но я не уверен, что мне не хватает чего-то большегосущественный:
- История: динамические веб-сайты восходят к Perl / PHP, оба работали как "тупой" CGI-бэкэнд, который был в основном фильтром, который обрабатывал HTTP-запрос (stdin) к ответу (stdout).Эта архитектура работала некоторое время и стала распространенным шаблоном:
- Производительность: веб-приложения часто пишутся на языках, не поддерживающих JIT, и наличие веб-сервера, написанного на таком языке, приводит к дополнительным издержкам, в то время как миллисекунды имеют значение.Кроме того, это позволяет нам ускорить статическую обработку файлов,
- Безопасность:
runserver Django явно описывается как потенциально небезопасный, согласно этой цитате : НЕ ИСПОЛЬЗУЙТЕЭТО СЕРВЕР В НАСТРОЙКЕ ПРОДУКЦИИ.Он не прошел аудит безопасности или тесты производительности.(И так оно и будет.
Последний пункт, по-видимому, предполагает, что написание готового к работе HTTP-сервера слишком сложно, чтобы соответствовать целям Django, какого рода преимуществадела должны быть поддержаны, чтобы попасть туда?
Является ли какой-либо из пунктов действительно действительным, или я скучаю по слону в комнате здесь?