学习思维导图:
# 应用层
## 网络应用模型
- C/S模型
- P2P模型
## DNS系统
- 层次域名空间
- 域名服务器
- 域名解析过程
## FTP
- FTP协议的工作原理
- 控制连接和数据连接
## 电子邮件
- 电子邮件系统的组成结构
- 电子邮件格式和MIME
- SMTP协议与POP3协议
## WWW
- 概念和组成结构
- HTTP协议
学习思维导图:
# 应用层
## 网络应用模型
- C/S模型
- P2P模型
## DNS系统
- 层次域名空间
- 域名服务器
- 域名解析过程
## FTP
- FTP协议的工作原理
- 控制连接和数据连接
## 电子邮件
- 电子邮件系统的组成结构
- 电子邮件格式和MIME
- SMTP协议与POP3协议
## WWW
- 概念和组成结构
- HTTP协议
C/S(Client Server)模型:中心化、依赖服务器,适合稳定服务场景。
P2P(Peer to Peer):分布式、节点平等,适合资源共享和去中心化场景。
DNS 使用 层次域名空间 来组织域名,将域名划分为多个级别,每个级别之间以点(.)分隔。域名从右到左逐级递增,最右边是 顶级域名(TLD),然后是 二级域名, 三级域名,以此类推。
例如, www.example.com
中, .com
是顶级域名, example.com
是二级域名, www.example.com
是子域名。
DNS 层次域名空间 的设计使得域名分布在不同的管理区域中,每个管理区域负责管理其自己的域名空间。这种分层结构有助于提高可扩展性和效率。
在 DNS 体系结构中,服务器按照层级划分,每一层负责不同的职责。下面按照从最高层到最低层的顺序,对四类常见的域名服务器进行说明:
.com
, .org
, .net
等)。它们为下一级的域名(如 example.com
)提供有关权威名称服务器的信息。example.com
)提供详细的 DNS 记录信息(例如 A 记录、MX 记录等)。只有权威服务器才能为其负责的域名提供这些信息。域名解析分为 递归查询 和 迭代查询 两种。
在域名解析过程中,本地域名服务器 向根域名服务器发送的通常是迭代查询。
当 根域名服务器 收到查询请求后,不会代替本地域名服务器继续查询,而是返回结果中的两种情况之一:
随后,本地域名服务器根据指引,向对应的 顶级域名服务器 继续查询。顶级域名服务器的处理方式类似:
权限域名服务器的处理流程类似,这里不赘述了。最终,当本地域名服务器获得目标域名对应的 IP 地址后,会将结果返回给最初发起请求的主机。
sequenceDiagram participant Host as 主机 participant Local as 本地域名服务器 participant Root as 根域名服务器 participant TLD as 顶级域名服务器 (TLD) participant Auth as 权限域名服务器 (Authoritative) Host->>Local: 1) 查询 www.example.com Local->>Root: 2) 迭代查询(请求根服务器) Root-->>Local: 3) Referral: 指向对应的 TLD 服务器(例如 .com) Local->>TLD: 4) 迭代查询(请求 TLD 服务器) TLD-->>Local: 5) Referral: 指向该域的 权限域名服务器 Local->>Auth: 6) 迭代查询(请求权限域名服务器) Auth-->>Local: 7) 返回最终 IP 地址(例如 93.184.216.34) Local-->>Host: 8) 本地 DNS 将 IP 返回给主机 Note right of Local: 本地域名服务器可能会把结果缓存一段时间
递归查询的过程如上图所示,本地域名服务器只需向 根域名服务器查询一次(步骤 2),后面的几次查询都是 递归地 在其他几个域名服务器之间进行的(步骤 3-7)。在步骤 7 中,本地域名服务器从根域名服务器得到了所需的 IP 地址,最后在步骤 8 中,本地域名服务器把查询结果告诉发起查询的主机。
因为该方法给根域名服务器造成的负载过大,所以实际中几乎不使用。
sequenceDiagram participant Host as 主机 participant Local as 本地域名服务器 participant Root as 根域名服务器 participant TLD as 顶级域名服务器 (TLD) participant Auth as 权限域名服务器 (Authoritative) Host->>Local: 1) 查询 www.example.com Local->>Root: 2) 向根域名服务器发起递归查询 Root->>TLD: 3) 根服务器代为查询 TLD 服务器 TLD->>Auth: 4) TLD 服务器递归查询权限域名服务器 Auth-->>TLD: 5) 返回最终 IP 地址 TLD-->>Root: 6) TLD 把结果返回给根服务器 Root-->>Local: 7) 根服务器把最终 IP 地址交给本地 DNS Local-->>Host: 8) 本地 DNS 返回结果给主机
DNS 递归查询 和 迭代查询的不同点如下表所示:
特点 | 递归查询 | 迭代查询 |
---|---|---|
查询责任 | DNS 服务器负责查询所有结果 | 客户端逐级查询 |
查询复杂度 | 客户端简单,只需发起一次请求 | 客户端复杂,需要多次查询 |
使用场景 | 用户设备、本地 DNS 服务器 | DNS 服务器之间的交互 |
性能 | 服务器负担较大 | 服务器负担较小 |
无论是浏览器、操作系统,还是本地的递归 DNS 服务器,在接收到域名解析结果之后,都会将其暂时保存在本地 缓存 中。这样,如果同一个域名在短时间内被多次请求,就可以直接从 缓存 中获取结果,而不需要再次向外部服务器发送查询请求。
DNS 记录中包含一个名为 TTL(Time to Live)的字段,用于指定这条记录可以在缓存中 保存多久。比如 TTL 为 3600 表示记录在缓存中可保留 3600 秒(即一小时)。在这段时间内,只要有查询,就可以直接使用缓存的结果。当 TTL 到期后,缓存记录会被丢弃,下一次查询将重新走完整的解析流程。
FTP 的传输流程如下:
anonymous
)和邮箱地址作为密码进行访问。sequenceDiagram participant Client as 客户端 participant Server as 服务器 Note over Client,Server: 主动模式 (Active Mode) Client->>Server: 建立控制连接 (端口 21) Client->>Server: PORT 命令 (告知客户端开放的端口) Server-->>Client: 建立数据连接 (连接到客户端指定端口) Client->>Server: 发起数据传输请求 (如 LIST/RETR) Server-->>Client: 通过数据连接传输数据 Note over Client,Server: 被动模式 (Passive Mode) Client->>Server: 建立控制连接 (端口 21) Client->>Server: PASV 命令 (请求服务器开放数据端口) Server-->>Client: 返回数据端口号 Client->>Server: 连接到服务器指定端口(数据连接) Client->>Server: 发起数据传输请求 Server-->>Client: 通过数据连接传输数据
电子邮件系统由 用户代理、邮件服务器 以及 电子邮件协议 这三个核心组成部分协同工作,确保邮件的发送、接收和存储。
用户代理(UA, User Agent)是用户与电子邮件系统交互的接口,通常是邮件客户端软件(如 qq 邮箱网页界面、Outlook 等)。
功能:
邮件服务器(Mail Server)是电子邮件系统的核心,负责存储、转发和管理邮件。
功能:
SMTP(Simple Mail Transfer Protocol)是用于邮件发送的标准协议,负责在邮件服务器之间或从用户代理到邮件服务器传输邮件。
功能:
工作流程:
POP3 是用于从邮件服务器检索邮件的协议,允许用户将邮件下载到本地设备。
功能:
工作流程:
需要注意的是,SMTP 使用的是 “推送”(Push)方式进行通信。当用户代理发送邮件,或者邮件在邮件服务器之间传递时,SMTP 客户端会将邮件 主动推送 到 SMTP 服务器。
而 POP3 则采用 “拉取”(Pull)方式进行通信。当用户需要查看邮件时,用户代理会向邮件服务器发出请求,从服务器中 拉取 用户邮箱里的邮件。
一封电子邮件由 信封 和 内容 两部分组成,其中邮件 内容 又可分为 首部 和 主体。
邮件的 首部格式 由 RFC 标准定义,而 主体部分 则由用户自由撰写。
用户在填写完邮件首部后,系统会自动提取 信封 所需的信息,无需用户手动填写 信封 内容。
邮件首部由若干 首部行 组成,每行格式为:关键字: 值
。其中:
To
:必填,指定一个或多个收件人的电子邮件地址,格式为 用户名@域名
,如 abc@csgraduates.com
。用户名在所属域名下必须唯一,从而保证该邮箱地址在整个互联网上唯一。Subject
:可选,表示邮件主题,用于概括邮件内容。From
:必填,表示发件人邮箱地址,通常由邮件系统自动填写。首部和主体之间用一个空行分隔。以下是一个典型邮件内容示例:
From: sender@example.com
To: abc@cskaoyan.com
Subject: Meeting Schedule
Dear team,
Please find the meeting schedule attached.
MIME(Multipurpose Internet Mail Extensions,多用途互联网邮件扩展)是为了解决传统电子邮件格式的局限性而提出的一种扩展标准。
早期的电子邮件只能传输 纯文本(ASCII 码),不支持发送图片、音频、视频或非英语字符(如中文)。这严重限制了电子邮件的用途。MIME 的出现,就是为了解决这些问题。
MIME 主要包含以下三点 核心功能:
WWW,也称为 万维网(World Wide Web),是一个信息系统,在这个系统中,文档和其他资源通过 统一资源标识符(Uniform Resource Identifiers,或 URI,通常为 URL)进行标识和互相链接。用户可以使用 网络浏览器 访问 万维网 上的资源。
HTTP(超文本传输协议)是互联网上应用最为广泛的一种网络协议。它是一个属于 应用层 的协议,常基于 TCP/IP 协议通信。HTTP 用于 客户端 和 服务器 之间的数据传输,特别是在 万维网(WWW)中,用于传输网页(HTML 文件)以及与其关联的资源(如图片、音频、视频等)。
HTTP 本身不保持 无状态 信息,每个请求都是独立的,服务器无法识别是不是同一个用户发送的多个请求。这一点在现实中通常通过 Cookie 和 Session 技术来弥补。
以下首部字段可能在考试中被考察,需要了解一下:
长连接和短连接含义
HTTP 根据首部的 **keepalive**
选项是否被设置被分为 长连接 和 短连接。
**keepalive**
选项,可以在一个 TCP 连接 中发送多个 HTTP 请求。**keepalive**
选项,那么每一次发送 HTTP 请求都必须单独建立一个 TCP 连接。HTTP 不同版本中的 keepalive
**HTTP/1.0**
中,持久连接不是默认行为。要在 **HTTP/1.0**
中启用它,必须在请求头部添加 Connection: keep-alive
。**HTTP/1.1**
中及之后,持久连接是默认行为。如果想关闭它,必须在请求或响应头部添加 Connection: close
。HTTP 流水线和非流水线含义
HTTP 不同版本中的流水线支持
什么是 队头阻塞(了解即可)
当多个请求被排成队列时,如果第一个请求由于某种原因(如延迟、丢包或慢速响应)未能及时处理,那么后续的所有请求都必须等待第一个请求的响应完成才能被处理。
在 HTTP/2.0 之前,你只有在完成上一个 HTTP 请求后,才能发送下一个请求。但是在 HTTP/2.0 中,你可以并发地发送多个 HTTP 请求,这些请求被并发地处理。
HTTP 协议是 无状态 的,这意味着每个请求都是独立的,服务器 默认情况下无法知道两个请求是否来自同一客户端或用户。Cookie 的引入使得 服务器 能够跨多个请求“识别”和“记住”用户。
HTTP 服务器通过 Set-Cookie
首部字段来设置每一个客户端的 Cookie 值,相应的 HTTP 响应的部分内容如下所示:
HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Path=/; Secure; HttpOnly
当浏览器接收到带有 Set-Cookie
字段的 HTTP 响应时,就会在存储该 Cookie 字段,并在下次向对应的 服务器 发送 HTTP 请求时自动将 Cookie
字段添加在 HTTP 首部,之后的 HTTP 请求的部分内容如下所示:
GET /dashboard HTTP/1.1
Cookie: sessionId=abc123
当 HTTP 服务器 接收到带有 Cookie 的请求时,它就可以区分这个请求是来自于那个客户端的了。