HTTP 与 Web 服务器基础

tags: #http #web-server #web #nodejs #build-your-own-x #阶段1-1

[!summary] 本笔记的范围 本笔记对应 00-总览/Build Your Own X分阶段实践总路线 的「阶段 1.1：HTTP 与 Web Server 基础知识」。目标是建立准确的概念模型，为以后阅读 TCP、Socket、字节流和 Web Server 实现做准备。

本次只整理知识，不创建代码，不运行实验，不实现服务器。

与已有笔记的关系

• 01-Web基础/HTTP请求完整链路：从浏览器到数据库的请求链路概览。
• browser-server-communication：浏览器和服务器的职责边界。
• 00-总览/Build Your Own X实践记录-阶段1-Web与前端：阶段实践计划，不代表 Web Server 已经实现。
• 00-总览/阶段1实验代码说明-Node.js Web Server：实验设计说明，不代表实验已经运行。

这篇笔记补充基础定义、HTTP 消息结构、URL、状态码、Header、Body、路由和常见误区。它不重复已有笔记的完整请求链路，而是解释链路中的基本概念。

1. Web Server 是什么

1.1 Web Server 作为软件

Web Server 作为软件，是一个能够等待网络请求、理解请求、决定如何处理，并返回响应的程序。

它通常会完成这些工作：

1. 监听某个网络地址和端口。
2. 接收客户端发来的数据。
3. 把数据识别为 HTTP 请求，或交给 HTTP 库解析。
4. 根据请求的方法、路径、Header 和 Body 执行业务逻辑。
5. 生成 HTTP 响应。
6. 把响应发送回客户端。

「返回网页」只是 Web Server 的一种用途。它也可以返回 JSON、图片、音频、视频、下载文件或错误信息。

1.2 Web Server 作为服务器设备

日常语言中的「服务器」也可能指一台设备，或者一台正在运行服务的计算机。这台设备可以是：

• 云主机。
• 公司机房里的物理机。
• 家里的电脑。
• 虚拟机。
• 容器所在的宿主机。

设备本身不是 Web Server。只有设备上运行了提供 Web 服务的软件，才有了 Web Server 能力。一台电脑也可以同时运行浏览器、数据库、Node.js 服务和其他程序。

1.3 HTTP Server 与 Web Server 的关系

在初学阶段，这两个词经常混用：

• HTTP Server：重点强调它通过 HTTP 接收和返回消息。
• Web Server：更宽泛，通常指对外提供 Web 内容或 Web 能力的软件和整体服务。

一个简单的 HTTP Server 可以是 Web Server 的最小形态。生产环境中的 Web Server 可能还包括静态文件服务、反向代理、TLS 终止、缓存、压缩、日志和安全控制。

1.4 浏览器与 Web Server 的关系

浏览器通常负责发起请求和显示结果，Web Server 通常负责接收请求和返回结果。浏览器并不只会请求网页，也会请求 CSS、JavaScript、图片、字体和 JSON 数据。

1.5 Node.js 为什么可以创建 Web Server

Node.js 是一个可以在浏览器之外运行 JavaScript 的运行时。它提供网络、文件、进程等服务端能力，也提供 HTTP 和 TCP 相关模块，因此 JavaScript 程序可以：

• 监听端口。
• 接收网络连接。
• 读取请求数据。
• 生成响应。
• 访问文件和数据库。
• 调用其他服务。

Node.js 不是 Web Server 本身。Node.js 是运行 Web Server 程序的运行时；你写的程序、Node.js 提供的 API，以及运行它的系统共同组成服务。

1.6 一个简单场景

用户在浏览器输入：

https://example.com/

可以把过程想象成：

浏览器：我想要根路径的内容
  ↓
网络：找到 example.com 对应的目标
  ↓
Web Server：收到请求，判断它要访问 /
  ↓
Web Server：读取文件或执行程序，生成响应
  ↓
浏览器：收到 HTML，解析并显示页面

如果 HTML 里还引用了 CSS、JavaScript 和图片，浏览器通常会继续发起更多请求。

2. Client 与 Server

2.1 什么是 Client

Client 是发起请求、使用某项服务的一方。浏览器是最常见的 HTTP Client，但下面这些也可以是 Client：

• 手机 App。
• Node.js 程序。
• Python 脚本。
• 命令行工具。
• 另一个后端服务。
• 自动化测试程序。

2.2 什么是 Server

Server 是等待请求、提供数据或能力的一方。它可以提供网页、数据、身份验证、文件、计算能力或其他业务服务。

2.3 Client 和 Server 是通信角色

Client 和 Server 首先是一种通信角色，而不是设备类型：

谁发起这一次请求，谁在这次通信中扮演 Client；
谁等待并处理这一次请求，谁在这次通信中扮演 Server。

同一个程序在不同场景中可以拥有不同角色。例如：

浏览器 → 你的 Node.js Web Server
浏览器是 Client，Node.js 程序是 Server。

你的 Node.js 程序 → 天气 API
你的 Node.js 程序是 Client，天气 API 的程序是 Server。

2.4 两个不要混淆

• Client 不等于个人电脑。个人电脑可以运行 Client，也可以运行 Server。
• Server 不等于昂贵的服务器机器。普通电脑只要运行服务程序，也可以暂时充当 Server。

3. 一次网页访问的基本过程

以 HTTP/1.1 over TCP 的常见场景为主，可以先建立下面的链路：

用户输入 URL
  ↓
浏览器分析 URL
  ↓
寻找目标服务器
  ↓
建立网络连接
  ↓
发送 HTTP Request
  ↓
服务器接收并理解请求
  ↓
服务器生成 HTTP Response
  ↓
浏览器接收响应
  ↓
浏览器处理并显示内容

3.1 DNS 位于哪里

域名是便于人阅读的名称。浏览器需要通过 DNS 查询，把域名解析为一个或多个 IP 地址，才能寻找目标网络位置。

DNS 解决的是「这个域名对应哪里」，不是「网页内容是什么」。

3.2 TCP 位于哪里

在本阶段的典型 HTTP/1.1 场景中，浏览器和服务器先建立 TCP 连接。TCP 提供可靠、有序的字节流，HTTP 消息再通过这个字节流传输。

TCP 不理解 GET、路径和状态码。它只负责传输字节。

3.3 TLS 位于哪里

使用 HTTPS 时，通信双方还要经过 TLS 保护。TLS 提供加密和身份验证，之后 HTTP 消息在受保护的连接中传输。

在阶段 1.1 的链路中，TCP 提供传输通道，但 TCP 只交付字节，不理解 HTTP 的消息边界。阶段 1.2 继续解释这个过程：01-Web与前端/02-TCP、Socket与字节流基础。

后续阶段：00-总览/阶段1.2-TCP、Socket与字节流学习计划。

4. URL 的基本结构

示例：

https://example.com:443/articles?id=10#chapter-1

可以拆成：

4.1 URL、域名、IP 地址和文件路径

• URL 是资源地址的完整表达方式。
• 域名 是主机名的一种可读形式。
• IP 地址 是网络定位地址。
• 文件路径 是操作系统中的文件位置。

它们可能在一次访问中相互关联，但不是同一个东西。/articles 看起来像目录，却不代表服务器上一定存在名为 articles 的文件夹。

4.2 路径不一定是真实文件

服务器可能把路径交给程序路由：

/articles       → 查询数据库并生成文章列表
/users/42       → 根据 ID 查询用户
/api/health     → 返回服务健康状态

这些路径都可以没有对应的物理文件。

4.3 查询参数通常会发送给服务器

在示例中，?id=10 属于请求目标的一部分，服务器通常可以读取它，用于筛选、分页、搜索或定位资源。

查询参数会出现在请求中，但不代表服务器一定会使用它。最终行为由服务器程序决定。

4.4 片段通常由浏览器本地处理

#chapter-1 通常用于跳转到页面内部位置，或表示客户端路由状态。浏览器在发 HTTP Request 时通常不会把片段发送给服务器。

因此服务器通常能看到：

/articles?id=10

而看不到：

#chapter-1

4.5 默认端口

• HTTP 默认端口通常是 80。
• HTTPS 默认端口通常是 443。

写出 :443 可以明确指定端口；省略时，浏览器会根据协议使用默认端口。端口不是服务器本身，而是主机上区分不同网络服务的逻辑编号。

5. HTTP 是什么

HTTP（Hypertext Transfer Protocol）是一种应用层通信协议。它规定 Client 和 Server 如何表达请求、如何表达响应，以及消息中方法、状态码、Header 和 Body 的含义。

5.1 HTTP 不是这些东西

• HTTP 不是网页。网页是 HTTP 可以传输的一种内容。
• HTTP 不是服务器。服务器程序使用 HTTP 进行通信。
• HTTP 不是编程语言。它是一组通信约定。
• HTTP 也不是 TCP。HTTP 规定消息语义，TCP 可以负责传输字节。

5.2 为什么需要共同遵守协议

如果浏览器随意发送一种格式，服务器用另一种格式理解，双方就无法可靠通信。协议让双方约定：

请求从哪里开始
方法如何写
路径放在哪里
Header 如何表示
响应成功或失败如何表达
正文怎样区分

这就像寄信需要约定收件地址、信封和正文的结构。浏览器和服务器不需要由同一家公司开发，只要遵守同一协议，就能协作。

5.3 教学简化

本阶段先以容易观察的 HTTP/1.1 文本消息和 TCP 传输建立概念。真实 Web 还包括不同 HTTP 版本、代理、缓存、TLS、流式传输和更复杂的消息规则，后续逐步展开。

6. HTTP Request 的基本结构

示例：

GET /articles?id=10 HTTP/1.1
Host: example.com
Accept: text/html

一个 HTTP Request 通常可以理解为：

请求行
Headers
空行
Body（可选）

6.1 请求行

GET /articles?id=10 HTTP/1.1

请求行包含：

• Method：GET，表达请求意图。
• Request Target：/articles?id=10，本次请求的目标。
• HTTP Version：HTTP/1.1，说明使用的协议版本。

6.2 Headers

Host: example.com
Accept: text/html

Header 是一组描述请求的附加信息。示例中：

• Host 表示目标主机。
• Accept 表示 Client 希望接收的内容类型。

6.3 空行

Header 结束后需要有一个空行，用来告诉接收方：Header 部分到这里结束，后面的内容如果有，就是 Body。

6.4 Body

并非每个 Request 都有 Body：

• 简单 GET 请求通常没有 Body。
• POST、PUT、PATCH 经常把提交数据放在 Body 中。
• Body 可以是 JSON、表单、文本、图片或其他二进制数据。

不能根据 Method 名称绝对推断 Body 是否存在，最终要看实际请求和协议规则。

6.5 常见 Method

必须记住：

HTTP Method 表达请求意图，不等于数据库命令。
GET 不代表一定读取文件。
POST 不代表一定新增数据库记录。
DELETE 不代表一定删除数据库数据。
最终行为取决于服务器程序和 API 契约。

7. HTTP Response 的基本结构

示例：

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Content-Length: 13

Hello, world!

一个 HTTP Response 通常可以理解为：

状态行
Headers
空行
Body（可选）

7.1 状态行

HTTP/1.1 200 OK

状态行包含：

• HTTP Version：HTTP/1.1。
• Status Code：200，机器更适合根据它判断结果。
• Reason Phrase：OK，给人看的简短说明；实际程序应以状态码为准。

7.2 Response Body

并非每个 Response 都有 Body：

• 204 No Content 按定义不返回内容。
• 304 Not Modified 通常不包含响应内容，浏览器使用已有缓存。
• HEAD 请求的响应不返回消息内容。
• 某些错误响应可能有 Body，也可能没有。

7.3 状态码类别

7.4 常见状态码

状态码的最终使用应结合 HTTP 规范和具体 API 契约。不要只根据中文翻译猜测语义。

8. Header 与 Body

8.1 Header 是什么

Header 用于描述请求或响应的附加信息，例如：

• 内容是什么类型。
• 内容有多大。
• Client 能接受什么。
• 请求来自哪个主机。
• 是否携带认证信息。
• 内容应该如何缓存。

Request 和 Response 都可以有 Header。

8.2 Body 是什么

Body 用于承载主要数据，例如：

• HTML 文本。
• JSON 数据。
• 表单内容。
• 图片、音频和视频。
• 上传的二进制文件。

Request 和 Response 都可能有 Body，也都可能没有 Body。

8.3 常见 Header

Header 不是业务数据本身，但服务器会依据 Header 进行解析、协商、安全校验和缓存决策。敏感 Header 不能随意写入日志。

9. HTTP 如何传输不同内容

HTML、CSS、JavaScript、JSON、纯文本、图片、音频、视频和其他二进制文件，都可以放在 HTTP Response 的 Body 中传输。

区别主要体现在：

1. Body 中实际放了什么字节。
2. Content-Type 如何描述这些字节。
3. Client 收到后如何处理。

概念示例：

访问网页        → 通常返回 text/html
请求数据接口    → 通常返回 application/json
请求样式文件    → 通常返回 text/css
请求脚本文件    → 通常返回 text/javascript 或相应 JavaScript 类型
访问图片地址    → 通常返回 image/png、image/jpeg 等
下载二进制文件  → 根据内容和响应头处理下载或展示

服务器返回 JSON 和返回 HTML，本质上都是返回 HTTP Response。HTTP 不要求内容一定是网页。

Content-Type 是描述内容的线索，不是让任意内容自动变成安全内容的保证。生产系统仍需要正确的内容生成、校验和安全响应头。

10. HTTP 与 TCP 的关系

HTTP 是应用层协议
TCP 可以为 HTTP 提供可靠的字节流传输
TCP 不理解 GET、POST、路径和状态码
HTTP 消息最终需要转换为数据在网络中传输
服务器程序需要从接收到的数据中识别 HTTP 消息

两者不是同一个东西：

• HTTP 规定消息内容、请求意图、响应状态和语义。
• TCP 负责把字节可靠、有序地传输到连接另一端。

在 HTTP/1.1 over TCP 的教学场景中，可以想象：

HTTP Request / Response
  ↓ 编码为字节
TCP 字节流
  ↓ 经过网络传输
对端程序收到字节
  ↓ 按 HTTP 规则理解
HTTP Request / Response

需要留下的关键问题：

• 一次接收到的数据是否一定是完整请求？不一定。
• 一个请求是否可能分多次到达？可能。
• 多个数据片段应该如何组合？需要根据协议边界和消息长度判断。

这些是后续「TCP、Socket 与字节流」阶段的主题，本次不实现方法。

关联：00-总览/阶段1.2-TCP、Socket与字节流学习计划。

11. 静态内容与动态内容

11.1 静态内容

静态内容是服务器可以直接提供，通常不需要根据本次用户请求重新计算的内容，例如：

• HTML 文件。
• CSS 文件。
• JavaScript 文件。
• 图片。
• 字体。
• 已生成的下载文件。

「静态」不代表永远不变化。一个 CSS 文件可以在发布新版本时变化；关键是每次请求时通常不根据用户身份或实时数据重新生成。

11.2 动态内容

动态内容是服务器根据请求、用户、时间、数据库或外部服务生成的内容，例如：

• 根据用户信息生成的页面。
• 数据库查询结果。
• 实时状态数据。
• 个性化推荐。
• 当前库存和订单状态。

「动态」不代表网页里有动画。动画是界面表现；动态内容强调服务器或客户端在运行时计算、获取或组合数据。

同一个 URL 也可能采用缓存或预生成，因此「静态 / 动态」是对生成方式的描述，不是对 URL 外观的判断。

12. 路由的基础概念

Route 是服务器根据请求信息决定处理方式的规则。最基础的匹配条件是：

HTTP Method + Path

概念示例：

同一个 Path 可以因为 Method 不同而表示不同的处理方式。GET /articles 和 POST /articles 不能只看路径就认为是同一个动作。

不存在的路径通常返回 404 Not Found。路径存在但 Method 不支持时，通常更适合返回 405 Method Not Allowed。

路由是服务器程序的概念，不要求路径对应真实文件。它可以把请求交给文件读取、模板渲染、数据库查询或其他业务函数。

13. 核心术语表

14. 常见误区

localhost 是互联网中的公共地址

纠正：localhost 通常指当前设备自身的本机回环地址。它主要用于本地开发，不代表互联网上所有人都能访问。

端口就是服务器

纠正：端口是主机上区分网络服务的逻辑编号。服务器是程序或提供服务的一方，端口只是数据进入某个服务的入口编号。

域名就是 IP 地址

纠正：域名是便于阅读的名称，IP 地址是网络地址。DNS 可以把域名解析到一个或多个 IP，但两者不是同一个概念。

HTTP 就是 TCP

纠正：HTTP 是应用层消息和语义规则，TCP 是传输字节的协议。在常见 HTTP/1.1 场景中 HTTP 可以运行在 TCP 之上，但二者职责不同。

HTTP 就是网页

纠正：HTTP 是通信协议，网页只是 HTTP 可以传输的一类内容。JSON、图片、视频和纯文本也可以通过 HTTP 传输。

Web Server 就是一台物理机器

纠正：Web Server 通常指提供 Web 服务的软件，也可以泛指服务系统。物理机、虚拟机或普通电脑都可以运行 Web Server 软件。

URL 路径一定对应真实文件

纠正：路径可能由路由程序处理，/articles 可以对应数据库查询或动态页面，并不要求有同名文件夹。

404 代表服务器已经宕机

纠正：404 通常表示目标资源或路由找不到，服务器本身可能完全正常。

500 代表用户输入错误

纠正：500 通常表示服务器遇到未预期的内部错误。用户输入问题一般需要使用合适的 4xx 状态码。

每个请求都必须返回 HTML

纠正：请求可以返回 HTML、JSON、CSS、JavaScript、图片、视频、文件或其他内容。

每个 HTTP Request 都有 Body

纠正：Body 是可选的。常见简单 GET 通常没有 Body，提交数据的请求更经常带 Body。

每个 HTTP Response 都有 Body

纠正：Response Body 也是可选的，204、304 和 HEAD 响应等场景通常没有消息内容。

GET 请求永远不能携带任何数据

纠正：GET 通常通过 URL 的路径和查询参数表达查询条件；具体请求是否带 Body 还要看客户端和协议使用方式。不能把「通常不使用 Body」说成「绝对禁止所有数据」。

POST 就等于新增数据库数据

纠正：POST 表达向目标提交数据并请求服务器处理，可能创建资源，也可能触发其他业务动作。

动态内容就是网页动画

纠正：动态内容指运行时根据请求、用户或数据生成；网页动画是 UI 表现，两者不是一回事。

Node.js 只能用来写后端接口

纠正：Node.js 还可以用于命令行工具、构建工具、脚本、网络程序、桌面应用和自动化任务。它是一种运行时，不只对应一种应用类型。

15. 知识关系图

文字版可以这样记：

浏览器作为 Client
  ↓ 根据 URL 找到主机和端口
DNS 帮助找到 IP
  ↓ 在典型 HTTP/1.1 场景中通过 TCP 传输字节
Web Server 作为 Server
  ↓ 根据 Method + Path 进行路由
生成 HTTP Response
  ↓ Status Code + Headers + Body
浏览器根据 Body 类型处理 HTML、JSON 或媒体内容

16. 自测题

题目

1. 判断：Web Server 一定是一台专门的物理服务器。
2. 判断：HTTP 和 TCP 是同一个协议，只是名称不同。
3. 解释：为什么浏览器通常是 Client，而 Node.js Web Server 通常是 Server？
4. 排序：把「发送 HTTP Request、DNS 查询、浏览器显示内容、建立网络连接、生成 HTTP Response」按基本访问顺序排列。
5. 分析 URL：https://example.com:443/articles?id=10#chapter-1 中，协议、主机、端口、路径、查询参数和片段分别是什么？
6. 判断：URL 中的片段 #chapter-1 通常会被发送到服务器。
7. 阅读 Request：POST /login HTTP/1.1 表示服务器一定会新增一条用户数据吗？为什么？
8. 阅读 Response：HTTP/1.1 404 Not Found 是否说明服务器程序已经宕机？
9. 场景：用户已登录，但没有权限读取某篇私有文章，更适合考虑 401 还是 403？
10. 场景：请求方法是 POST，但路径存在且只允许 GET，更适合使用什么状态码？
11. 解释：Content-Type 和 Body 的关系是什么？
12. 判断：每个 HTTP Request 和 Response 都必须有 Body。
13. 判断：GET /articles?id=10 中的 id=10 是操作系统中的文件路径。
14. 场景：服务器成功创建了一个资源，通常可以考虑使用哪个状态码？如果没有需要返回的内容，哪个成功状态码可能更合适？
15. 解释：为什么同一个程序既可以是 Server，也可以是 Client？请举 Node.js 调用天气 API 的例子。

答案与原因

1. 错误。 Web Server 首先是提供 Web 服务的软件或服务系统，普通电脑、虚拟机和云主机都可以运行它。
2. 错误。 HTTP 规定请求与响应的语义和消息格式，TCP 负责可靠、有序地传输字节；在常见 HTTP/1.1 场景中 HTTP 可以运行在 TCP 上。
3. 浏览器主动请求网页或资源，因此在这次通信中扮演 Client；Web Server 等待请求并返回结果，因此扮演 Server。这是通信角色，不是设备名称。
4. DNS 查询 → 建立网络连接 → 发送 HTTP Request → 生成 HTTP Response → 浏览器显示内容。真实链路还可能包括缓存、代理和 TLS。
5. 协议是 https；主机是 example.com；端口是 443；路径是 /articles；查询参数是 id=10；片段是 chapter-1。
6. 通常不会。 片段通常由浏览器用于页面内部定位或客户端状态处理，发送 HTTP Request 时通常会被去掉。
7. 不一定。 POST 表达向目标提交数据并请求服务器处理，服务器可以创建资源，也可以执行登录、触发动作或其他业务逻辑。
8. 不说明。 404 一般表示请求的资源或路由不存在，服务器程序仍然可能正常运行。
9. 通常考虑 403。 用户已经通过身份认证，但没有访问权限；401 更常用于缺少或无效的身份认证凭据。
10. 405 Method Not Allowed。 路径存在，但当前 Method 不被允许。服务端通常还应说明允许的方法。
11. Body 承载数据，Content-Type 描述这些数据是什么媒体类型以及可能的字符编码，帮助接收方正确解析。
12. 错误。 Request 和 Response 的 Body 都是可选的。简单 GET、204、304 和 HEAD 等场景可能没有消息内容。
13. 错误。 id=10 是 URL 查询参数，不是操作系统文件路径。服务器可以把它用于筛选、分页或查询数据库。
14. 创建资源通常可以使用 201 Created；如果操作成功但不需要返回内容，可以考虑 204 No Content。
15. 因为角色取决于具体通信方向。Node.js 程序接收浏览器请求时是 Server；同一个 Node.js 程序主动调用天气 API 时，它又是天气 API 的 Client。

17. 资料来源

• Build Your Own Web Server From Scratch In Node.JS
• RFC 9110：HTTP Semantics
• RFC 9112：HTTP/1.1
• Node.js HTTP API
• Node.js Net API
• MDN：HTTP Overview

知识审核记录

• 审核日期：
• 本次整理范围：Introduction、HTTP Overview，以及与本阶段相关的 HTTP 基础概念。
• 已确认内容：Web Server、Client / Server 角色、URL 组成、HTTP Request / Response、Method、状态码类别、Header / Body、HTTP 与 TCP 的基础关系、静态 / 动态内容和路由。
• 教学简化：以 HTTP/1.1 over TCP 的常见场景帮助建立模型；没有把它说成所有 HTTP 版本都只能运行在 TCP 上。HTTP/2、HTTP/3、QUIC、完整 TLS 和代理链路留到后续。
• 仍需验证内容：实际实现中 TCP 字节片段的边界、HTTP Parser、Keep-Alive、Chunked Encoding 和请求体读取。
• 暂未展开内容：TCP Server 的具体实现、Promise 与 Event 的代码、HTTP Parser 实现、文件读取、Range Request、缓存、压缩、WebSocket、并发处理。
• 下一阶段：00-总览/阶段1.2-TCP、Socket与字节流学习计划。

[!note] 状态 阶段 1.1 是知识整理，不代表代码实验完成。Node.js Web Server 尚未实现，服务器尚未部署。