Python Web - WSGI 与 ASGI

[TOC]

从 Web 服务器开始

Web 服务器的核心使命：URL 与资源的映射

从本质上讲，Web 服务器的核心工作，就是实现 URL 和服务器资源之间的映射。当我们谈论“资源”时，主要指两类：

静态资源 (Static Resources)：这些是预先存在于服务器硬盘上的文件，无需额外处理即可直接发送给浏览器。例如：CSS 样式表 (style.css)、图片 (logo.png)、HTML 文件 (index.html) 以及 JavaScript 脚本 (main.js)。
动态资源 (Dynamic Resources)：这些资源并非现成的文件，而是程序代码实时运行后生成的结果。例如，当请求 /api/users/123 时，服务器需要运行一段 Python 代码，去数据库查询 ID 为 123 的用户信息，然后将这些信息格式化为 JSON 字符串返回。这个动态生成的 JSON 字符串就是动态资源。

为了最高效地处理这两类截然不同的资源，Web 服务器的生态系统逐渐演化出了明确的分工。

术业有专攻：Nginx 与 Gunicorn

在实际部署中，我们通常会组合使用不同特长的服务器。Nginx 和 Gunicorn 就是一对经典的黄金搭档。

Nginx：面向网络 I/O 的“交通警察”

我们要建立一个博客网站，最主要的功能就是用户访问某个网址的时候，网站返回给他们一个 HTML 页面。这就需要一个可以处理静态资源的 Web 服务器，Nginx 就是最经常选取的方案。它是一个用 C 语言编写的高性能 Web 服务器，其设计哲学是以最高的效率处理网络 I/O 和高并发连接。

处理静态资源 (核心强项): 当一个 GET /images/logo.png 请求到达时，Nginx 会迅速定位到硬盘上的对应文件，并利用操作系统底层的高效机制将文件内容直接发送到网络。这个过程快如闪电。
处理动态资源 (角色：转发): Nginx 自身无法执行 Python 代码。当一个 GET /api/users 请求到达时，Nginx 会扮演“交通警察”的角色，将这个请求原封不动地转发 (Proxy) 给在后端等待的 Python 应用服务器（比如 Gunicorn）。

Gunicorn：专注运行 Python 应用的“执行官”

我们要启动一个 Flask 的 Web 应用，用户访问某个 API，后台就执行相应 Python 代码并返回结果。这里就需要一个可以处理动态资源的 Web 应用服务器。Gunicorn 是一个用 Python 编写的典型应用服务器，它的核心使命是为 Python Web 应用提供一个标准的、健壮的运行时环境。

处理动态资源 (核心使命): 当 Gunicorn 收到 /api/users 这个请求时，它的工作是加载并执行我们的 Python Web 应用代码，生成动态内容，然后将结果返回。
处理静态资源 (能力有限，效率低下): Gunicorn 也能处理静态文件，但这无异于让一位米其林大厨去送外卖，效率极低。在生产环境中，这项工作应该完全交给 Nginx。

黄金搭档的工作模式

特性	Nginx	Gunicorn / Uvicorn
主要语言	C	Python
设计哲学	高性能网络 I/O，事件驱动	运行和管理 Python 应用
URL 映射	URL -> 静态文件或代理地址	(被代理的)请求 -> Python 可执行对象
静态资源处理	极其高效 (专长)	非常低效 (不推荐)
动态资源处理	无法执行，只能转发 (代理)	执行 Python 代码生成动态内容 (专长)
核心角色	反向代理、负载均衡器、静态文件服务器	应用服务器 (Application Server)

服务器与应用的对话：协议的诞生

Web 应用服务器，最关键的一步就是，Gunicorn 该如何将请求交给我们的 Flask 应用，并让它执行代码呢？

思考一下我们写的 Flask 代码，这里的 app 就是我们的 Flask Web 应用：

1
2
3
4
5...剩余内容已隐藏
查看完整文章以阅读更多
查看完整文章
🍊
柑橘 RSS
订阅源浏览器信息
windsong
xxxx的个人博客
马上订阅 windsong RSS 更新: https://www.windsong.top/atom.xml
Python Web - WSGI 与 ASGI
2025年9月10日 16:19
Python Web - WSGI 与 ASGI
[TOC]
从 Web 服务器开始
Web 服务器的核心使命：URL 与资源的映射
从本质上讲，Web 服务器的核心工作，就是实现 URL 和服务器资源之间的映射。当我们谈论“资源”时，主要指两类：
静态资源 (Static Resources)：这些是预先存在于服务器硬盘上的文件，无需额外处理即可直接发送给浏览器。例如：CSS 样式表 (style.css)、图片 (logo.png)、HTML 文件 (index.html) 以及 JavaScript 脚本 (main.js)。
动态资源 (Dynamic Resources)：这些资源并非现成的文件，而是程序代码实时运行后生成的结果。例如，当请求 /api/users/123 时，服务器需要运行一段 Python 代码，去数据库查询 ID 为 123 的用户信息，然后将这些信息格式化为 JSON 字符串返回。这个动态生成的 JSON 字符串就是动态资源。
为了最高效地处理这两类截然不同的资源，Web 服务器的生态系统逐渐演化出了明确的分工。
术业有专攻：Nginx 与 Gunicorn
在实际部署中，我们通常会组合使用不同特长的服务器。Nginx 和 Gunicorn 就是一对经典的黄金搭档。
Nginx：面向网络 I/O 的“交通警察”
我们要建立一个博客网站，最主要的功能就是用户访问某个网址的时候，网站返回给他们一个 HTML 页面。这就需要一个可以处理静态资源的 Web 服务器，Nginx 就是最经常选取的方案。它是一个用 C 语言编写的高性能 Web 服务器，其设计哲学是以最高的效率处理网络 I/O 和高并发连接。
处理静态资源 (核心强项): 当一个 GET /images/logo.png 请求到达时，Nginx 会迅速定位到硬盘上的对应文件，并利用操作系统底层的高效机制将文件内容直接发送到网络。这个过程快如闪电。
处理动态资源 (角色：转发): Nginx 自身无法执行 Python 代码。当一个 GET /api/users 请求到达时，Nginx 会扮演“交通警察”的角色，将这个请求原封不动地转发 (Proxy) 给在后端等待的 Python 应用服务器（比如 Gunicorn）。
Gunicorn：专注运行 Python 应用的“执行官”
我们要启动一个 Flask 的 Web 应用，用户访问某个 API，后台就执行相应 Python 代码并返回结果。这里就需要一个可以处理动态资源的 Web 应用服务器。Gunicorn 是一个用 Python 编写的典型应用服务器，它的核心使命是为 Python Web 应用提供一个标准的、健壮的运行时环境。
处理动态资源 (核心使命): 当 Gunicorn 收到 /api/users 这个请求时，它的工作是加载并执行我们的 Python Web 应用代码，生成动态内容，然后将结果返回。
处理静态资源 (能力有限，效率低下): Gunicorn 也能处理静态文件，但这无异于让一位米其林大厨去送外卖，效率极低。在生产环境中，这项工作应该完全交给 Nginx。
黄金搭档的工作模式
特性 Nginx Gunicorn / Uvicorn
主要语言 C Python
设计哲学 高性能网络 I/O，事件驱动 运行和管理 Python 应用
URL 映射 URL -> 静态文件 或 代理地址 (被代理的)请求 -> Python 可执行对象
静态资源处理 极其高效 (专长) 非常低效 (不推荐)
动态资源处理 无法执行，只能转发 (代理) 执行 Python 代码生成动态内容 (专长)
核心角色 反向代理、负载均衡器、静态文件服务器 应用服务器 (Application Server)
服务器与应用的对话：协议的诞生
Web 应用服务器，最关键的一步就是，Gunicorn 该如何将请求交给我们的 Flask 应用，并让它执行代码呢？
思考一下我们写的 Flask 代码，这里的 app 就是我们的 Flask Web 应用： 
1
2
3
4
5...剩余内容已隐藏
查看完整文章以阅读更多
查看完整文章
🍊
柑橘 RSS
订阅源浏览器信息
windsong
xxxx的个人博客
马上订阅 windsong RSS 更新: https://www.windsong.top/atom.xml
Python Web - WSGI 与 ASGI
2025年9月10日 16:19
Python Web - WSGI 与 ASGI
[TOC]
从 Web 服务器开始
Web 服务器的核心使命：URL 与资源的映射
从本质上讲，Web 服务器的核心工作，就是实现 URL 和服务器资源之间的映射。当我们谈论“资源”时，主要指两类：
静态资源 (Static Resources)：这些是预先存在于服务器硬盘上的文件，无需额外处理即可直接发送给浏览器。例如：CSS 样式表 (style.css)、图片 (logo.png)、HTML 文件 (index.html) 以及 JavaScript 脚本 (main.js)。
动态资源 (Dynamic Resources)：这些资源并非现成的文件，而是程序代码实时运行后生成的结果。例如，当请求 /api/users/123 时，服务器需要运行一段 Python 代码，去数据库查询 ID 为 123 的用户信息，然后将这些信息格式化为 JSON 字符串返回。这个动态生成的 JSON 字符串就是动态资源。
为了最高效地处理这两类截然不同的资源，Web 服务器的生态系统逐渐演化出了明确的分工。
术业有专攻：Nginx 与 Gunicorn
在实际部署中，我们通常会组合使用不同特长的服务器。Nginx 和 Gunicorn 就是一对经典的黄金搭档。
Nginx：面向网络 I/O 的“交通警察”
我们要建立一个博客网站，最主要的功能就是用户访问某个网址的时候，网站返回给他们一个 HTML 页面。这就需要一个可以处理静态资源的 Web 服务器，Nginx 就是最经常选取的方案。它是一个用 C 语言编写的高性能 Web 服务器，其设计哲学是以最高的效率处理网络 I/O 和高并发连接。
处理静态资源 (核心强项): 当一个 GET /images/logo.png 请求到达时，Nginx 会迅速定位到硬盘上的对应文件，并利用操作系统底层的高效机制将文件内容直接发送到网络。这个过程快如闪电。
处理动态资源 (角色：转发): Nginx 自身无法执行 Python 代码。当一个 GET /api/users 请求到达时，Nginx 会扮演“交通警察”的角色，将这个请求原封不动地转发 (Proxy) 给在后端等待的 Python 应用服务器（比如 Gunicorn）。
Gunicorn：专注运行 Python 应用的“执行官”
我们要启动一个 Flask 的 Web 应用，用户访问某个 API，后台就执行相应 Python 代码并返回结果。这里就需要一个可以处理动态资源的 Web 应用服务器。Gunicorn 是一个用 Python 编写的典型应用服务器，它的核心使命是为 Python Web 应用提供一个标准的、健壮的运行时环境。
处理动态资源 (核心使命): 当 Gunicorn 收到 /api/users 这个请求时，它的工作是加载并执行我们的 Python Web 应用代码，生成动态内容，然后将结果返回。
处理静态资源 (能力有限，效率低下): Gunicorn 也能处理静态文件，但这无异于让一位米其林大厨去送外卖，效率极低。在生产环境中，这项工作应该完全交给 Nginx。
黄金搭档的工作模式
特性 Nginx Gunicorn / Uvicorn
主要语言 C Python
设计哲学 高性能网络 I/O，事件驱动 运行和管理 Python 应用
URL 映射 URL -> 静态文件 或 代理地址 (被代理的)请求 -> Python 可执行对象
静态资源处理 极其高效 (专长) 非常低效 (不推荐)
动态资源处理 无法执行，只能转发 (代理) 执行 Python 代码生成动态内容 (专长)
核心角色 反向代理、负载均衡器、静态文件服务器 应用服务器 (Application Server)
服务器与应用的对话：协议的诞生
Web 应用服务器，最关键的一步就是，Gunicorn 该如何将请求交给我们的 Flask 应用，并让它执行代码呢？
思考一下我们写的 Flask 代码，这里的 app 就是我们的 Flask Web 应用： 
1
2
3
4
5...剩余内容已隐藏
查看完整文章以阅读更多
查看完整文章