12.2 Web开发——Web开发演变¶

内容梗概¶

本课沿着时间线梳理 Web 开发的技术演变：从最朴素的静态网页（服务器直接返回磁盘上的 HTML 文件），到动态网页的两条技术路线——后端用各语言 Web 框架自动生成 HTML、前端用 Ajax 实现局部动态更新。后端部分重点讲解了三代机制：CGI（每请求起一个进程，开销大）、FastCGI（常驻进程，消除进程切换开销）、WSGI（Python 提出的标准，把 Web Server、中间件、应用都变成同一框架内的模块，通过回调函数协作），并指出 Flask 正是 WSGI 模式的代表。

知识点详解¶

阶段一：静态网页（约 00:00–07:40）¶

最朴素的模式：浏览器通过 HTTP 请求把 Web 服务器上的某个 HTML/JS/CSS 文件下载下来展示。
以 Apache 这类 Web 服务器软件为例：URL 可拆分为协议（http://）、域名（主机）、路径（path，如 /abc/cde）。访问根目录 / 时，服务器会去网站对应文件夹下找默认的 index.html（除非改默认配置，这个名字是固定的），把文件内容通过 HTTP 返回。
特点：所有人任何时间看到的内容完全一样；无法实现用户交互——不能接受用户输入后在服务器端运算并返回不同结果（如"上传图片、服务器美化磨皮后再下载"做不到）。
静态网页并未过时：2015 年前后静态网站生成器回潮，特别适合做博客（每个人来看都一样）。例如：
Hexo（Node.js 生态，字幕中读音为 Hexel）：自动把 Markdown 转成 HTML 并组织好结构，传到服务器即成博客；
MkDocs（Python）：老师的课程网站就是用它把 Markdown 课件自动转成 HTML 放到服务器上。

阶段二：动态网页（约 07:40–18:30）¶

需求驱动：登录、用户系统、个性化内容（如 B 站首页每个人推荐的视频不同）——需要服务器记录用户偏好并为其生成新页面。
两种思路（老师声明前后端划分"不严谨、比较粗暴"，仅供理解）：
后端思路：涌现大量 Web 框架，每个用户访问时，后端用 Python / Java / PHP 甚至 C 语言动态生成不同的 HTML。
前端思路：后端生成的方案有个弊端——Web 服务器不能主动通知浏览器，页面更新必须靠用户切换 URL 或刷新页面。于是出现 Ajax（异步 JavaScript 和 XML）：页面加载后，其中运行的 JavaScript 代码在**不刷新页面**的情况下向服务器发送 HTTP 请求，拿到响应后局部修改页面内容（如实时显示商品库存数量，每秒刷一次）。早期返回数据用 XML 格式，现在更多是 JSON 字符串。
前端/后端的划分：在浏览器里跑的东西（JS、CSS 等）叫前端；Web Server 及其后面的交互程序叫后端。如今这个界限已很模糊。
移动互联网时代前端框架大火：除了 Chrome、Firefox、Edge、IE，还有 iPad、iPhone、安卓、小程序等各种前端展示需求，催生大量前端框架（课上提到"最火的三个前端框架"作为扩展知识，与本课内容关系不大）。

后端机制演变：CGI → FastCGI → WSGI（约 19:00–39:30）¶

CGI（通用网关接口）（约 22:00 起）：
是一套标准/机制，满足该标准即可开发 CGI 应用程序（经典的如 Java、PHP 的 CGI 程序），跑起来本质上也是一个进程（process）。
工作流程：Web Server 收到 HTTP 请求后，不再直接读文件返回，而是把请求中的**路径和参数**（URL 中 ?a=1&b=2 这种形式）传给 CGI 进程；CGI 程序根据路径找到对应 HTML（如 index.html），读出内容后按参数修改（如把某字符串替换成 username 参数的值"安静"或"小王"），再把处理结果返回给 Web Server，最终返回浏览器。这样不同用户就能看到不同内容。
传参方式：最早通过**环境变量**传递，也可通过建立本地 TCP 连接传递（仅提一下，不展开）。
致命问题：CGI 进程**不是常驻**的——每来一个请求就启动一次进程、处理完退出，不断的进程切换非常消耗服务器资源；大量请求时进程切换不过来服务器就会挂掉（类似被 DoS 拒绝服务攻击），效率极低。
FastCGI（约 28:37 起）：
特点就是"快"：逻辑与 CGI 完全一致，但处理进程**永远常驻**，Web Server 通过 TCP 端口或文件进行进程间通信把参数和路径发给它，处理完返回，进程不退出，从而消除了进程切换的开销。
支持绝大多数 Web 服务器（Apache、Nginx、Tomcat）和绝大多数语言（Java、PHP，早年甚至有 C 写的）。
WSGI（Web Server Gateway Interface）（约 31:40 起）：
Python 提出的标准（最早 Python 专用，现在越来越多语言采用）。核心思想：不再是"Web Server 一个进程 + 应用另一个进程"，而是把各部分都变成 Web 框架（framework）内的模块（module）。
框架内大致包含：处理 HTTP 请求的 Web Server 模块 → 符合 WSGI 标准的中间件（middleware，相当于代理人）→ 应用程序（如 a.py 里的 index 函数）。
工作流程：Web Server 模块处理 HTTP 请求，把参数和路径发给 WSGI 中间件；中间件可做程序员自定义的处理（也可什么都不做），再按规则把参数、路径以及一个**回调函数（callback）**交给对应的应用函数；应用函数（如 index）处理完后主动调用 callback 通知中间件，处理结果逐层返回给 Web Server 模块，最终返回浏览器。
相比 FastCGI 的优势：模块间可用回调函数形式协作，框架整合度高、更灵活，且兼容 FastCGI 逻辑——框架可以不提供 Web Server 部分，交给 Nginx/Apache 去做；也可以像作业中那样不装 Apache，Flask 自带的 HTTP 处理模块 + 自带 WSGI 中间件即可直接对外服务。
WSGI 只是标准，有各种实现可供选择（课上提到 Python 中两个特别有名的 WSGI 服务器实现，配合 Django/Flask 使用）。

示例与演示¶

本课以概念讲解为主，老师在白板（板书）上画图演示了三个模型：
CGI 模型：Web Server 进程 ↔ CGI 进程，传"参数 + 路径"，每请求一起一退。
FastCGI 模型：同样的交互，但应用进程常驻。
WSGI 模型：框架内 Web Server 模块 → WSGI 中间件 → 应用函数，经 callback 回调返回。
举例说明动态生成：username=安静 时读出 index.html 把指定位置替换为"安静"再返回。
预告：接下来用 Python 的 Flask 框架演示静态/动态两个例子。

重点与难点¶

理解三代后端机制要解决的核心问题：CGI 解决"能不能动态生成内容"，FastCGI 解决"进程频繁启停的性能问题"，WSGI 解决"框架整合度与灵活性"。
URL 的结构拆分：协议 + 域名 + 路径（path）+ 参数（?a=1&b=2），路径和参数是后端框架做路由和处理的输入。
静态网页不等于过时——静态网站生成器（Hexo、MkDocs）在博客等场景仍是主流方案。
Ajax 的本质：浏览器中的 JavaScript 代替用户发起 HTTP 请求并局部更新页面，服务器端无法主动推送（在该模型下）。

关联内容¶

承接 12.1 的"浏览器—HTTP—服务器"基本模型，把它按时间轴展开成技术演变史。
WSGI 模型是 12.4–12.7 讲 Flask 的理论基础：Flask 自带 Web Server 模块和 WSGI 中间件。
静态网站生成器 MkDocs 呼应老师课程网站的实际构建方式；Hexo 呼应同学搭博客的实践。
前端框架、JSON 等作为扩展阅读提示，衔接学生的 Web 前端课程。