Gunicorn 是一款成熟的 WSGI HTTP 服务器，以其出色的稳定性和广泛的社区支持而闻名，是处理传统 Python Web 应用的可靠选择。然而，它不直接支持 HTTP/2 和 WebSocket 协议，这意味着在需要实时通信的场景下，Gunicorn 无法独立完成任务。

Daphne 作为一款 ASGI 服务器，在功能上更进一步，它不仅能处理标准的 HTTP 请求，还原生支持 HTTP/2 和 WebSocket 协议。这使得 Daphne 成为构建需要实时交互的应用（如在线聊天应用）的理想选择，因为它无需额外的配置即可处理 WebSocket 连接。

在实际应用中，可以将 Gunicorn 和 Daphne 结合使用，并借助 Nginx 等反向代理服务器进行流量分发。例如，可以将 WebSocket 请求（如 `/ws/` 路径）定向到 Daphne 服务器，而将其他 HTTP 请求定向到 Gunicorn 服务器，从而充分利用两者的优势，实现高效且功能全面的 Web 服务部署。

Gunicorn is a WSGI HTTP server for Python applications. It can serve your dynamic Python application with the help of a reverse-proxy program like Nginx.

Daphne is like Gunicorn but for ASGI. It also supports the HTTP/2.0 and WebSocket protocols in addition to Gunicorn.

Which one should be preferred, and when?

Imagine you are going to write a Django chat app. You would have to use WebSocket for a real-time and non-polling chat app. Gunicorn cannot do this alone. You can still serve your Django application with Gunicorn, but you should at least use Daphne to handle requests sent over the WebSocket protocol and a reverse-proxy like Nginx to send those requests to the Daphne service. For example, you can redirect all the connections on the path /ws/ to your Daphne service, while redirecting the rest to Gunicorn.

Daphne vs Gunicorn

Although this comparison may seem like comparing apples and oranges at first glance, it's still important. That's because unlike Gunicorn, Daphne can also do what Gunicorn can, like handling traditional HTTP requests. This makes it possible to use only Daphne for any type of request in your, say, chat application. However, you might wonder if it's worth choosing Daphne while everyone else seems to be using Gunicorn for HTTP requests.

Daphne

+ Handles any type of requests like HTTP, HTTP/2, WebSocket
+ You don't have to reverse-proxy WebSocket requests by the path (like /ws/)
- No proven stability?
- No enough community support?

Gunicorn

+ Proven stability
+ Community support
- No support for HTTP/2, WebSocket
- You'll need a reverse-proxy + another server for unsupported request types

Using both at the same time

This is another solution. We can redirect incoming requests to appropriate services via Nginx. Below is an example Nginx configuration:

upstream server_http {    server backend:8000;}upstream server_ws {    server daphne:9001;}server {    listen 80;    # ...    location / {        proxy_pass http://server_http;        # ...    }    location /ws/ {        proxy_pass http://server_ws;        proxy_http_version 1.1;        proxy_set_header Upgrade $http_upgrade;        proxy_set_header Connection "upgrade";        # ...    }    # ...}

With this Nginx configuration, the connections to the /ws/ path will be redirected to the daphne service running on the port 9001, while the rest will be handled by the backend service, which could be a Gunicorn server running on the port 8000.