Почему Django не обслуживает staticfiles в production?

Мне интересно, почему Django не обслуживает статические файлы в продакшене, когда DEGUB = False.

STATICFILES_DIRS
. Мы указываем STATICFILES_DIRS, чтобы сказать Django, где искать статические файлы, привязанные к указанному приложению.

STATIC_ROOT
. Мы указываем STATIC_ROOT, чтобы сообщить Django, где хранить файлы после запуска python manage.py collectstatic, поэтому каждый статический файл хранится по пути, указанному в STATIC_ROOT.
. Предположим, что мы установили STATIC_ROOT = "staticfiles/".
. Это означает, что когда мы выполним команду collectstatic, все файлы, находящиеся внутри путей STATICFILES_DIRS, будут храниться в "staticfiles/"

STATIC_URL. Наконец, мы указываем STATIC_URL в качестве "префикса", чтобы сообщить Djando, где искать статические файлы, например, в теге HTML <link>, url, который мы видим, основан на STATIC_URL значении

Когда мы загружаем наш проект на сервер, мы загружаем весь проект, то есть каждый файл. Почему Django не может сам обслуживать статические файлы при работе на сервере?
. Как я только что сказал, мы загружаем всю папку, поэтому файлы, которые мы загрузили, находятся там (и статические файлы тоже!).

ВОПРОСЫ

  • Мне просто интересно, почему мы должны указывать staticfiles на основе сервера в production, когда Django мог бы сделать все за нас, как он всегда делал на localhost?
    • .
  • Разве загрузка файлов из другого хранилища не намного медленнее, чем из основной папки проекта?

Мне просто интересно, почему мы должны указывать staticfiles на основе сервера в production, когда Django мог бы сделать все за нас, как он всегда делал на localhost?

Потому что это скорее всего неэффективно и небезопасно. Каждый раз, когда делается запрос, запрос проходит через все промежуточное ПО, затем представление выдает ответ, который снова проходит через промежуточное ПО к клиенту. Если вы запросите тот же файл во второй раз, то, скорее всего, он не будет иметь никакого кэширования и, таким образом, повторит этот процесс снова. Если вы работаете с веб-сервером типа Nginx/Apache, он, вероятно, будет кэшировать результат. Если вы работаете с CDN, то он также свяжется с ближайшим сервером и таким образом получит доступ к этим ресурсам более эффективным способом.

Другая проблема - безопасность. Если вы указываете путь к файлу, который не должен обслуживаться, то веб-сервер должен предотвратить доступ браузера к этому файлу. Некоторые хакеры, например, пытаются получить доступ к исходным файлам браузера, чтобы затем искать уязвимости. Это не должно быть возможным. Вероятно, такие веб-серверы, как Apache или Nginx, имеют более продвинутые механизмы безопасности для этого.

Если вы действительно этого хотите, вы можете использовать WhiteNoise, чтобы позволить Django обслуживать статические файлы и медиафайлы в продакшене. Это приложение Django было оптимизировано для безопасности и эффективности. Хотя трудно сказать, будет ли оно иметь тот же уровень, что и сервер Apache или Nginx.

Разве загрузка файлов из другого хранилища не намного медленнее, чем загрузка из основной папки проекта?

Веб-сервер не будет обращаться к другому хранилищу: это сделает браузер. Таким образом, возможно, что вместо веб-сервера он будет обращаться к CDN. Возможно, это несколько менее эффективно, поскольку веб-браузер обычно повторно использует открытое соединение с сервером, чтобы сделать больше запросов, но часто вы уже обращались к CDN, например, для файлов JavaScript. Кроме того, CDN оптимизированы для максимально эффективной доставки контента: браузер обычно связывается с браузером, расположенным близко к клиенту, и обычно также существует балансировка нагрузки и избыточность, чтобы снизить вероятность того, что сервер больше не сможет обслуживать ресурс.

Вернуться на верх