应用层

mindmap
  root((应用层))
    应用层架构模式
      客户端-服务器（Client-Server）
      对等网络（Peer-to-Peer, P2P）
      术语
    WWW 与 HTTP 协议
      核心组件
      URL
      HTTP
      Cookies
      HTTP 性能
      性能优化技术
    电子邮件系统
      协议体系
      邮件系统组成
      邮件投递的三个阶段
      SMTP
    域名解析系统（DNS）
      DNS 层次结构
      DNS 解析
      DNS 记录
      DNS 缓存
    文件传输协议（FTP）
    内容分发网络（CDN）

应用层架构模式

客户端-服务器（Client-Server）

• 客户端（client）
  • 可能有动态 IP 地址
  • 按需启动
  • 主动发起请求
  • 例如：浏览器、邮件客户端
• 服务器（server）：
  • 固定 IP 地址
  • 持续运行（作为守护进程 daemon 运行）
  • 响应请求
  • 例如：Web 服务器、邮件服务器

对等网络（Peer-to-Peer, P2P）

• 无中心服务器，节点兼具客户端和服务器功能
• 特性：自扩展性、节点动态变化（如 BitTorrent、Skype）
• 混合模式示例：Skype 使用中心服务器进行地址发现，通信时建立直接连接

术语

• 进程（process）：运行在主机上的程序

  • 在同一主机内，两个进程间使用进程间通信（Inter-Process Communication, IPC）机制，由操作系统提供
  • 在不同主机间，两个进程间使用应用层协议（App-layer protocol）进行通信

• 用户代理（user agent）：一个位于应用程序「上方」和网络「下方」的接口。

  • 实现了用户界面和应用层协议
  • Web 上的用户代理是浏览器，电子邮件中的用户代理是邮件客户端

WWW 与 HTTP 协议

核心组件

• 基础设施：
  • 客户端
  • 服务器（DNS, CDN, 数据中心）
• 内容：
  • URL(Uniform Resource Locator, 统一资源定位符)：标识资源位置
  • HTML(HyperText Markup Language, 超文本标记语言)：格式化文档

用于交换信息的协议：HTTP（HyperText Transfer Protocol, 超文本传输协议）

URL

URL 是统一资源定位符（Uniform Resource Locator）的缩写，是一个用于标识互联网上资源的地址。

URL 结构：<协议>://<主机>:<端口>/<路径>?<查询参数>

• 协议：用于传输或解释对象的方法，例如
  http、ftp、Gopher
• 主机：对象所在主机的 DNS 名称或 IP 地址
• 路径：包含对象的文件的路径名
• 查询参数：发送到服务器上应用程序的名称/值对

例如：http://www.nju.edu.cn:8080/somedir/page.htm

HTTP

客户端-服务器架构（Client-Server Architecture）：

• 服务器始终运行，且具有固定 IP 地址（广为人知）

• 客户端主动联系服务器，请求服务

• 同步请求/回复模式（Synchronous Request/Reply）：基于 TCP（默认端口 80）

• 无状态协议，通过 Cookie 维持会话状态

• 支持方法：GET、POST、PUT、DELETE 等

HTTP 请求/相应：

HTTP 方法：

• GET：请求获取 URL 的资源
• POST：提交数据给服务器处理
• PUT：上传文件
• DELETE：删除文件

HTTP 请求消息：

GET /index.html HTTP/1.1
Host: www.nju.edu.cn
User-Agent: Mozilla/5.0
Connection: keep-alive
Accept-Language: en-us
(blank line)

第一行是请求行（request line），GET 是请求方法，/index.html 是请求的 URL，HTTP/1.1 是协议版本。

后面是请求头字段（Header Fields），最后是一个空行。用 CRLF（回车换行）表示消息结束。

HTTP 响应消息：

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Content-Length: 6821
Content-Type: text/html
(blank line)
<data>

第一行是状态行，HTTP/1.1 是协议版本，200 是状态码，OK 是状态描述。

后面是响应头字段，最后是一个空行，之后是响应数据。

Cookies

每个请求-响应独立处理：服务器无需保留状态

• 优点：
  • 提高了服务器端的可扩展性
  • 错误处理更简单
  • 能够处理更高频率的请求
  • 请求的顺序无关紧要
• 缺点：
  • 某些应用程序需要持久状态
  • 需要唯一标识用户或存储临时信息
  • 例如：购物车、用户资料、使用情况跟踪等…

如何让一个无状态协议维持会话状态？使用 Cookies。

• 客户端侧状态维护
  • 客户端代表服务器存储少量状态信息
  • 客户端在未来的请求中将状态信息发送给服务器
• 可用于提供身份验证

Cookies 例子：

HTTP 性能

往返时延（Round-Trip Time, RTT）：从客户端发送请求到服务器响应的时间

HTTP 历程：

响应时间：

• 1RTT 延迟：建立 TCP 连接
• 1RTT 延迟：发送 HTTP 请求和响应
• 传输时间

总计：2RTT + 传输时间

性能优化技术

在默认 HTTP/1.0 中，每个 HTML 文件需要 2RTT + 传输时间。同时反复做相同事情，效率低下。

解决方法：使用并行连接，并不一样要维持响应的顺序。

这样客户端很开心，（内容提供者也很开心），但是服务器不开心，因为服务器需要维持很多连接。

• 连接管理
  • 非持久连接：每个对象需 2RTT（HTTP/1.0 默认）
  • 持久连接：复用 TCP 连接（HTTP/1.1 默认）
  • 管道化请求：批量传输减少延迟

• 缓存机制
  • 条件 GET：If-Modified-Since 头字段（上面的例子也有）、Expires 头字段（表示资源可以被安全缓存的时间长度）、No-cache 头字段（忽略所有缓存；始终直接从服务器获取资源）
  • 缓存层级：浏览器缓存、代理缓存（正向/反向）、CDN

许多客户端传输相同的信息，产生不必要的服务器和网络负载，客户端经历不必要的延迟。

• 反向代理：在靠近服务器的位置缓存文档
  • 减少服务器负载
  • 由内容提供商实现
• 前向代理：在靠近客户端的位置缓存文档
  • 减少网络流量并降低延迟
  • 由互联网服务提供商（ISP）或企业实现

电子邮件系统

协议体系：

• SMTP：简单邮件传输协议（Simple Mail Transfer Protocol）
  • 简单文本消息的传递
• MIME：多用途互联网邮件扩展（Multipurpose Internet Mail Extensions）
  • 其他类型数据的传递，例如语音、图像、视频片段
• POP：邮局协议（Post Office Protocol）
  • 从服务器检索消息，包括授权和下载
• IMAP：互联网邮件访问协议（Internet Mail Access Protocol）
  • 对服务器上存储的消息进行操作

邮件系统组成

用户代理

• 撰写、编辑、阅读邮件
• 例如：Eudora、Outlook、Foxmail、Netscape Messenger
• 传出和传入的邮件存储在服务器上

邮件服务器（主机）

• 用户的邮箱包含传入的邮件
• 传出邮件的消息队列
• 邮件服务器之间使用 SMTP 协议发送邮件

邮件投递的三个阶段

• 第一阶段
  • 电子邮件从本地用户代理发送到本地 SMTP 服务器
  • 用户代理充当 SMTP 客户端
  • 本地服务器充当 SMTP 服务器
• 第二阶段
  • 电子邮件由本地服务器中继到远程 SMTP 服务器
  • 此时本地服务器充当 SMTP 客户端
• 第三阶段
  • 远程用户代理使用邮件访问协议访问远程服务器上的邮箱
  • 使用 POP3 或 IMAP4 协议

1. Alice 使用 UA（用户代理）撰写一封邮件并发送给 bob@someschool.edu。
2. Alice 的 UA 使用 SMTP 将邮件发送到她的邮件服务器，邮件被放置在消息队列中。
3. SMTP 的客户端部分与 Bob 的邮件服务器建立 TCP 连接。
4. SMTP 客户端通过该 TCP 连接将 Alice 的邮件发送出去。
5. Bob 的邮件服务器将邮件放置到 Bob 的邮箱中。
6. Bob 调用他的 UA（例如通过 Pop3）来读取邮件。

SMTP

传输的三个阶段

• 握手（问候）
• 一个或多个邮件数据的传输
• 关闭连接

命令/响应交互

• 命令：ASCII 文本
• 响应：状态码和短语

消息格式：

• 头部字段：
  • From: Bob@gmail.com
  • To: Alice@sina.com
  • Subject: Dinner tonight?
  • Date
• 消息体：邮件正文（仅 ASCII 文本）

邮件重点：<mailbox>@<server>

• mailbox：SMTP 服务器的邮箱名称
• server：SMTP 服务器 的 DNS 名称或 IP 地址

邮件访问协议

• SMTP：向接收方服务器的投递/存储
• 邮件访问协议：从服务器检索邮件
• POP：邮局协议
  • 认证（代理 <-> 服务器）和下载
• IMAP：互联网邮件访问协议
  • 更多功能，包括对服务器上存储邮件的操控
• HTTP：Gmail、Hotmail、Yahoo! 等

域名解析系统（DNS）

域名解析系统（Domain Name System, DNS）：将域名映射到 IP 地址的分布式数据库。

核心功能：映射类型

• 域名 $\to$ IP 地址（A 记录）
• 别名解析（CNAME 记录）
• 邮件服务器定位（MX 记录）

DNS 服务：

• 分布式数据库在许多名称服务器的层次结构中实现
• 应用层协议使主机和名称服务器能够通信以解析「域名」
• 负载均衡：一个服务器名对应一组 IP 地址

为什么不让 DNS 集中化？

• 单点故障
• 流量负载过大
• 远程集中式数据库延迟高
• 维护困难

目标：

• 唯一性：无命名冲突
• 可扩展性
  • 大量名称和频繁更新（次要需求）
• 分布式、自主管理
  • 能够更新我自己的（机器的）名称
  • 无需跟踪所有人的更新
• 高可用性
• 查询速度快
• 完全一致性并非目标

DNS 层次结构

• 划分命名空间
• 分配每个分区的管理
  • 自主更新我自己的（机器）名称
  • 无需跟踪每个人的更新
• 分配每个分区的名称解析

服务器类型：

• 根服务器（全球 13 组）
  • 当本地域名服务器无法解析名称时会进行联系。
• 顶级域服务器（Top Level Domains, TLD，如 .com、.edu）
  • 负责如 com、org、net、edu 等，以及所有顶级国家域名，例如 cn、uk、fr。
• 权威服务器（组织内部）
  • 组织的 DNS 服务器，提供权威的主机名到 IP 地址的映射。
• 本地 DNS 服务器（递归查询代理）
  • 由每个住宅 ISP、公司或大学维护。
  • 当主机发起 DNS 查询时，查询会被发送到其本地 DNS 服务器。

一个区域（zone）对应于一个行政管理机构，该机构负责层次结构的那部分。

• UMich（密歇根大学）控制名称：*.umich.edu
• EECS（电气工程与计算机科学学院）控制名称：*.eecs.umich.edu

DNS 解析

Bob（位于 cis.poly.edu）需要获取 Alice（位于 gaia.cs.umass.edu）的 IP 地址。

在计算机网络中，DNS（域名系统）解析是将域名转换为 IP 地址的过程。在这个过程中，有两种主要的查询方式：迭代查询和递归查询。它们的主要区别在于谁负责完成整个查询过程。

递归查询：客户端向 DNS 服务器发起请求后，DNS 服务器会代替客户端完成整个查询过程，并将最终结果返回给客户端。

• 客户端只需发送一次请求，后续的工作由 DNS 服务器完成。
• 如果目标 DNS 服务器无法直接解析域名，它会向其他 DNS 服务器继续查询，直到找到答案。
• 对客户端来说，操作简单，但对 DNS 服务器的负载较高。
• 适用场景: 通常用于本地 DNS 服务器与客户端之间的交互。

迭代查询：客户端向 DNS 服务器发起请求后，如果该服务器无法直接解析域名，它会返回一个指向其他 DNS 服务器的引用（即下一步查询的目标）。客户端需要根据这个引用继续向其他 DNS 服务器发起查询，直到获得最终结果。

• 客户端需要多次发起请求，逐步获取最终结果。
• DNS 服务器只提供自己知道的信息或推荐下一步查询的目标。
• 对客户端来说，操作复杂，但减轻了 DNS 服务器的负担。
• 适用场景: 通常用于 DNS 服务器之间的交互。

flowchart LR
    %% 递归查询
    subgraph RecursiveQuery["`**递归查询**`"]
        direction LR
        ClientR[客户端] -->|查询请求| LocalDNSServerR[本地 DNS 服务器]
        LocalDNSServerR -->|查询请求| RootServerR[根 DNS 服务器]
        RootServerR -->|返回 TLD 服务器地址| LocalDNSServerR
        LocalDNSServerR -->|查询请求| TLDServersR[TLD 服务器]
        TLDServersR -->|返回权威 DNS 服务器地址| LocalDNSServerR
        LocalDNSServerR -->|查询请求| AuthoritativeDNSServerR[权威 DNS 服务器]
        AuthoritativeDNSServerR -->|返回 IP 地址| LocalDNSServerR
        LocalDNSServerR -->|返回 IP 地址| ClientR
    end

    %% 迭代查询
    subgraph IterativeQuery["`**迭代查询**`"]
        direction LR
        ClientI[客户端] -->|查询请求| LocalDNSServerI[本地 DNS 服务器]
        LocalDNSServerI -->|返回根 DNS 服务器地址| ClientI
        ClientI -->|查询请求| RootServerI[根 DNS 服务器]
        RootServerI -->|返回 TLD 服务器地址| ClientI
        ClientI -->|查询请求| TLDServersI[TLD 服务器]
        TLDServersI -->|返回权威 DNS 服务器地址| ClientI
        ClientI -->|查询请求| AuthoritativeDNSServerI[权威 DNS 服务器]
        AuthoritativeDNSServerI -->|返回 IP 地址| ClientI
    end

特性	递归查询	迭代查询
查询主体	DNS 服务器负责完成整个查询过程	客户端负责完成整个查询过程
客户端工作量	少（只需一次请求）	多（需多次请求）
DNS 服务器负载	高（需处理多个查询请求）	低（仅提供已知信息或推荐下一步）
适用场景	客户端与本地 DNS 服务器之间	DNS 服务器之间的交互

DNS 记录

DNS 资源记录（Resource Record, RR）是 DNS 数据库中的一条记录，用于将域名映射到 IP 地址，格式为 <name, value, type, ttl>。

• Name：域名
• Value：与域名相关联的数据
• Type：记录类型（A、CNAME、MX 等）
  • A：将域名映射到 IP 地址
  • CNAME：别名记录，将一个域名映射到另一个域名
  • MX：邮件交换记录，指定邮件服务器的地址
• TTL：生存时间（Time To Live），记录在 DNS 缓存中的时间

DNS 缓存

原因：执行所有这些查询需要时间，在开始下载之前可能有长达 1 秒的延迟

而缓存可以大大减少开销：

• 顶级服务器很少发生变化
• 热门网站经常被访问
• 本地 DNS 服务器通常已经缓存了相关信息

DNS 缓存的工作原理：

• DNS 服务器会缓存查询的响应
• 响应中包含一个「生存时间」（TTL）字段
• 服务器在 TTL 过期后删除缓存的条目

文件传输协议（FTP）

FTP（File Transfer Protocol）：用于在网络上传输文件的标准协议。

使用 TCP 连接，端口 21（控制连接）和端口 20（数据连接）。

双连接模式

• 控制连接（端口 21）：认证与命令传输
• 数据连接（端口 20）：文件传输（主动/被动模式）

采用客户端/服务器模型，由客户端发起文件传输请求（无论是向远程主机发送文件还是从远程主机接收文件）。

处理异构操作系统和文件系统。需要在远程文件系统上实施访问控制。

典型命令

• USER：认证
• LIST：目录列表
• RETR：下载
• STOR：上传

FTP 工作流程

FTP（文件传输协议）是一种用于在客户端和服务器之间传输文件的标准网络协议。其核心特点是使用双连接机制（控制连接 + 数据连接），以下是详细的工作流程：

1. 建立控制连接（Control Connection）
   • 端口：客户端通过 21 端口连接到服务器（默认）。
   • 协议：使用 TCP 协议建立可靠的连接。
   • 作用：传输命令（如 LIST, RETR, STOR）和服务器的响应（如状态码 200 OK）。
   • 示例：客户端输入 ftp example.com → 与服务器的 21 端口建立控制连接。
2. 身份验证（Authentication）
   • 明文传输：客户端发送用户名和密码（如 USER alice，PASS password123）。
   • 匿名登录：使用用户名 anonymous，密码可为空或任意值。
3. 选择传输模式（主动 vs. 被动）：FTP 的两种数据连接模式，解决客户端/服务器的防火墙/NAT 兼容性问题：
   • 主动模式（Active Mode）
     1. 客户端发送 PORT 命令，告知服务器自己的 IP 和随机端口（如 PORT 192,168,1,2,7,138，即 192.168.1.2:1930）。
     2. 服务器主动连接：服务器从 20 端口连接到客户端的指定端口。
     3. 问题：客户端防火墙可能阻止外部连接。
   • 被动模式（Passive Mode）
     1. 客户端发送 PASV 命令。
     2. 服务器回应：返回一个随机端口（如 227 Entering Passive Mode (192,168,1,1,15,100)，即 192.168.1.1:4004）。
     3. 客户端连接：客户端主动连接到该端口。
     4. 优势：适合客户端位于防火墙/NAT 后的场景。
4. 数据传输（Data Connection）
   • 命令示例：
     • 下载文件：RETR filename.txt
     • 上传文件：STOR filename.txt
     • 列目录：LIST
   • 传输模式：
     • ASCII 模式：文本文件（自动转换换行符）。
     • 二进制模式：非文本文件（如图片、视频）。
5. 关闭连接
   1. 数据连接：传输完成后立即关闭。
   2. 控制连接：保持打开，直到用户发送 QUIT 命令。

流程对比（主动 vs. 被动模式）

步骤	主动模式	被动模式
客户端命令	PORT + IP和端口	PASV
服务器响应	无	返回随机端口
数据连接发起方	服务器（20端口 → 客户端端口）	客户端（随机端口 → 服务器随机端口）
适用场景	服务器无防火墙限制	客户端位于防火墙/NAT后

实际案例演示

1. 连接服务器：

   ftp example.com
   Username: anonymous
   Password: (留空)

2. 切换被动模式：

   ftp> pass
   227 Entering Passive Mode (192,168,1,1,15,100).

3. 下载文件：

   ftp> get file.zip
   200 PORT command successful.
   150 Opening data connection.
   226 Transfer complete.

FTP 的局限性

• 安全性低：明文传输凭据和数据。
• 复杂配置：需处理多端口和防火墙规则。
• 替代方案：现代场景更推荐使用 SFTP（基于 SSH）或 HTTPS 文件传输。

内容分发网络（CDN）

内容分发网络（Content Delivery Network, CDN）：通过在全球范围内分布的服务器群提供内容，以提高性能和可靠性。

核心价值

• 减少延迟：通过地理位置接近的边缘节点
• 抗 DDoS^[1] 攻击：流量分散到多个节点

实现技术

1. DNS 重定向：将域名解析到最优 CDN 节点
2. 内容路由：基于网络延迟和负载动态选择节点
3. 缓存策略：主动预热（Warm-up）与 TTL 控制

---

1. DDoS（Distributed Denial of Service）：分布式拒绝服务攻击。是一种通过利用多个计算机对一个或多个目标发动攻击的方式，以使目标无法提供正常服务。 ↩︎