Terlalu disederhanakan: Anda perlu sesuatu yang mengeksekusi Python tetapi Python bukan yang terbaik dalam menangani semua jenis permintaan.
[Penafian: Saya seorang pengembang Gunicorn]
Kurang disederhanakan: Terlepas dari apa server aplikasi yang Anda gunakan (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy) segala jenis penyebaran non-sepele akan memiliki sesuatu di hulu yang akan menangani permintaan yang seharusnya tidak ditangani oleh aplikasi Django Anda. Contoh sepele dari permintaan tersebut melayani aset statis (gambar / css / js).
Ini menghasilkan dua tingkatan pertama dari "arsitektur tiga tingkat" klasik. Yaitu, server web (Nginx dalam kasus Anda) akan menangani banyak permintaan untuk gambar dan sumber daya statis. Permintaan yang perlu dihasilkan secara dinamis kemudian akan diteruskan ke server aplikasi (Gunicorn dalam contoh Anda). (Sebagai tambahan, yang ketiga dari tiga tingkatan adalah basis data)
Secara historis, masing-masing tingkatan ini akan di-host di mesin yang terpisah (dan kemungkinan besar akan ada banyak mesin di dua tingkatan pertama, yaitu: 5 server web mengirimkan permintaan ke dua server aplikasi yang pada gilirannya meminta satu basis data).
Di era modern sekarang kita memiliki aplikasi dari semua bentuk dan ukuran. Tidak setiap proyek akhir pekan atau situs bisnis kecil benar-benar membutuhkan tenaga kuda dari beberapa mesin dan akan berjalan cukup bahagia dalam satu kotak. Ini telah memunculkan entri baru ke dalam array solusi hosting. Beberapa solusi akan menggabungkan server aplikasi ke server web (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, dll). Dan sama sekali tidak jarang meng-host database pada mesin yang sama dengan salah satu dari kombinasi server web / aplikasi ini.
Sekarang dalam kasus Gunicorn, kami membuat keputusan khusus (menyalin dari Ruby Unicorn) untuk menjaga hal-hal terpisah dari Nginx sambil mengandalkan perilaku proksi Nginx. Khususnya, jika kita dapat berasumsi bahwa Gunicorn tidak akan pernah membaca koneksi langsung dari internet, maka kita tidak perlu khawatir tentang klien yang lambat. Ini berarti bahwa model pemrosesan untuk Gunicorn sangat sederhana.
Pemisahan ini juga memungkinkan Gunicorn ditulis dalam Python murni yang meminimalkan biaya pengembangan sementara tidak berdampak signifikan terhadap kinerja. Ini juga memungkinkan pengguna kemampuan untuk menggunakan proxy lain (dengan asumsi mereka buffer dengan benar).
Mengenai pertanyaan kedua Anda tentang apa yang sebenarnya menangani permintaan HTTP, jawaban sederhana adalah Gunicorn. Jawaban lengkapnya adalah Nginx dan Gunicorn yang menangani permintaan tersebut. Pada dasarnya, Nginx akan menerima permintaan dan jika itu permintaan dinamis (umumnya didasarkan pada pola URL) maka itu akan memberikan permintaan itu ke Gunicorn, yang akan memprosesnya, dan kemudian mengembalikan respons ke Nginx yang kemudian meneruskan respons kembali ke aslinya klien.
Jadi sebagai penutup, ya. Anda membutuhkan Nginx dan Gunicorn (atau yang serupa) untuk penyebaran Django yang tepat. Jika Anda secara khusus ingin menjadi tuan rumah Django dengan Nginx, maka saya akan menyelidiki Gunicorn, mod_uwsgi, dan mungkin CherryPy sebagai kandidat untuk sisi Django.