Chapter 2.2 Application Layer 2

本篇接续 Chapter 2.1 Application Layer 1 的 HTTP 基础，讨论跨请求状态、缓存和 HTTP/2–3，再介绍 FTP 与电子邮件。

2.2 Web 与 HTTP（续）

2.2.5 Cookie：在请求之间关联状态

无状态协议本身不会记住“这个请求来自刚才那个用户”。Cookie 让浏览器在后续请求中携带标识，使网站能够关联多个请求。

定义：HTTP Cookie

服务器通过响应的 Set-Cookie 首部向浏览器设置名称—值等信息；浏览器保存后，在符合域、路径等条件的后续请求中，通过 Cookie 首部携带相应值。

典型的服务端会话机制包含四个部分：响应中的 Set-Cookie、后续请求中的 Cookie、浏览器保存的 Cookie，以及服务器保存的关联记录。

1. 首次访问时，服务器生成标识，并建立相应记录。
2. 响应使用 Set-Cookie 让浏览器保存标识。
3. 后续请求携带 Cookie，服务器据此查找会话或用户相关数据。

Cookie 可以支持登录会话、购物车和个性化推荐。Cookie 中可以只是一个查表标识，不必把购物车或用户状态的全部内容都放进每个请求。

跨站追踪也可利用 Cookie 等标识关联访问行为。Cookie 是状态关联机制，本身不等于可靠的身份认证或通信加密。

2.2.6 Web 缓存与条件 GET

多个用户可能反复请求相同对象。缓存（cache）保留对象副本，在满足使用条件时直接响应，从而减少向源服务器请求和跨外网传输的数据。

代理缓存面对浏览器时扮演服务器，缓存未命中而向源服务器请求时又扮演客户端：

• 命中：可使用的副本已在缓存中，直接返回。
• 未命中：向源服务器请求对象，再向客户端交付，并按缓存规则保留副本。

缓存可以降低响应时间，减少机构接入链路的流量；链路利用率下降后，排队时延也可能显著降低。

例题：升级链路与安装缓存的差异

平均对象大小 $L=100000\text{ bit}$，请求率 $a=15\text{ 次/s}$，局域网速率为 10 Mbps，外网接入链路为 1.5 Mbps。机构路由器至源服务器的往返时延为 2 秒。

假设每次请求传送一个平均大小的对象，则对象流量为

$$La=100000\times 15=1.5\times 10^6\text{ bit/s}.$$

局域网利用率约为 $15\%$，接入链路利用率达到 $100\%$。在随机到达的模型中，接近饱和的接入链路会产生严重排队；仅凭利用率不能算出确切的等待分钟数。

若接入链路升级到 10 Mbps，利用率降为 $15\%$。另一种办法是在机构内安装缓存：若命中率为 $h=0.4$，且命中与未命中对象的平均大小相同，只有 $60\%$ 的对象流量经过接入链路，其利用率降为

$${\rho }_{\text{access}}=\frac{(1-h)La}{R}=\mathrm{0.6.}$$

若未命中请求的总时延近似为 $2+0.01=2.01\text{ s}$，命中请求只需毫秒级的 $T_{\text{hit}}$，则

$$\overline{T}=0.6\times 2.01+0.4T_{\text{hit}}\approx 1.206\text{ s}.$$

这里的 10 ms 是例子中采用的时延估计，不能仅从 $\rho =0.6$ 推出。缓存既让部分请求直接在本地完成，也缓解未命中请求面对的外网拥塞。

有副本还不够：若源对象已经更新，缓存需要验证版本。条件 GET（conditional GET）让缓存只在必要时下载对象正文：

• 缓存使用 If-Modified-Since: <date> 发送本地副本的时间条件。
• 如果此后对象未修改，服务器返回 304 Not Modified，不发送对象正文，缓存继续使用原副本。
• 如果对象已修改，服务器返回 200 OK 及新对象，缓存据此更新。

条件 GET 节省的是未变化对象的正文传输；它仍然可能需要一次与服务器的往返，不能直接等同于完全在本地命中的请求。

2.2.7 HTTP/2 与 HTTP/3

持续连接减少了建连次数，但 HTTP/1.1 流水线仍按请求顺序返回响应。前方大对象会使后续小对象等待，称为队头阻塞（head-of-line blocking，HOL blocking）。

HTTP/2 在同一连接中使用多条流（stream），把消息分成帧（frame）并交错发送。服务器可以调整调度，让小对象不必等大对象全部发完才开始返回；方法、状态码等基本语义仍然保留。

例子：一个大对象与三个小对象

客户端依次请求 $O_1,O_2,O_3,O_4$，其中 $O_1$ 很大。HTTP/1.1 流水线需要先完成 $O_1$ 的响应，再依序发送其他响应。

HTTP/2 可以在发送 $O_1$ 的部分帧后，穿插 $O_2,O_3,O_4$ 的帧，让小对象更早完成；代价可能是 $O_1$ 稍晚完成。改善的是对象完成的调度，不是凭空增加链路容量。

HTTP/2 的设计还包含优先级与服务器推送等机制，具体使用取决于实现。不过，多条 HTTP/2 流通常仍共享一条 TCP 字节流：前方 TCP 数据丢失时，后续已到达的字节可能都要等待恢复，这属于运输层的队头阻塞。

HTTP/3 使用基于 UDP 的 QUIC；QUIC 提供可靠多流传输，并集成 TLS 安全机制。不同流的按序交付相互独立，因此一条流的数据缺失不必阻塞其他流已完整到达的数据。

HTTP/3 并不是直接用“无可靠性的裸 UDP”传送 HTTP。流之间仍共享连接的网络容量与拥塞控制，独立交付也不表示丢包完全不会影响其他流的性能。

2.3 FTP：文件传输协议

HTTP 围绕资源的请求与响应组织通信，FTP（File Transfer Protocol）则专门支持远程文件上传、下载与目录操作，采用客户端—服务器结构。

2.3.1 控制连接与数据连接

FTP 把控制命令与文件内容放在不同 TCP 连接中，这与通过同一 HTTP 连接发送请求和对象的基本模型不同。

连接	作用	存续方式
控制连接	认证、切换目录、发送传输命令、接收状态响应	通常贯穿整个 FTP 会话，服务器端口为 21
数据连接	传送文件内容或目录列表等数据	按传输操作建立，完成后关闭

由于控制信息走独立于数据的通道，称为带外控制（out-of-band control）。传输下一个文件时可以建立新的数据连接，而不必重新建立整个控制会话。

FTP 服务器保留当前认证用户、工作目录等会话状态，因此是有状态（stateful）的协议。后续命令的含义可能依赖此前的登录或目录切换。

2.3.2 命令与响应

FTP 在控制连接中交换文本命令，以及由状态码和文字组成的响应；文件数据由数据连接传送。

命令	用途
USER username	提交用户名
PASS password	提交密码
LIST	请求目录中的文件列表
RETR filename	从服务器下载文件
STOR filename	向服务器上传文件

例如，331 表示用户名已接受、还需要密码；125 表示数据连接已经打开、即将开始传输；425 表示无法打开数据连接；452 表示写文件出错。

控制连接正常不代表数据连接一定能建立。分析 FTP 问题时，需要分别检查命令交互和实际数据传输。

2.4 电子邮件

邮件把“发送、暂存、跨服务器投递”和“用户读取”分开。接收者无需一直在线，接收方服务器可以先保存邮件，等待用户之后访问。

2.4.1 邮件系统的组成与传递过程

基本邮件系统包含用户代理、邮件服务器，以及负责邮件投递的协议。

组成	作用
用户代理（UA，User Agent）	写信、编辑、发送和阅读邮件，例如邮件客户端
邮件服务器（mail server）	保存用户收到的邮件，并排队处理待投递邮件
SMTP（Simple Mail Transfer Protocol）	在发送方与接收方邮件服务器之间传递邮件

邮件服务器中，邮箱（mailbox）存放用户已收到的邮件；发送队列（message queue）保存等待投递的邮件。两者对应传递流程中的不同阶段。

Alice 向 Bob 发邮件的基本过程是：

1. Alice 用用户代理编写邮件，填写 Bob 的收件地址。
2. 用户代理将邮件提交给 Alice 的邮件服务器，放入发送队列。
3. 发送方邮件服务器作为 SMTP 客户端，与接收方邮件服务器建立 TCP 连接。
4. 通过 SMTP 投递邮件，接收方服务器将其放入 Bob 的邮箱。
5. Bob 使用用户代理访问自己的邮箱并阅读邮件。

这里的客户端／服务器是一次交互中的角色。Alice 的邮件服务器对用户提供服务，但向 Bob 的服务器投递时，它是 SMTP 客户端。

2.4.2 SMTP 的交互与状态

SMTP 主要负责把邮件推送到目标邮件服务器，服务器间的基本投递使用 TCP 25 端口。

一次 SMTP 会话分为三个阶段：握手与问候、传输邮件、关闭会话。交互由文本命令和状态响应组成；一条持续 TCP 连接可用于传送多封邮件。

基本 SMTP 模型使用 7-bit ASCII 传送消息；表示二进制附件、非 ASCII 内容时可结合 MIME 编码，现代 SMTP 扩展也可放宽部分限制。传统数据阶段使用 \r\n.\r\n（CRLF、句点、CRLF）标记邮件数据结束，即正文后的独立一行句点。

比较项	获取 Web 对象的 HTTP 交互	SMTP 邮件投递
谁推动内容传输	客户端请求取得内容，通常是 pull	发送方主动向接收服务器投递，属于 push
交互方式	请求与响应状态	命令与状态响应
多个对象如何组织	通常为不同资源分别请求、响应	一封 MIME 邮件可包含正文与多个附件

SMTP 把邮件送到接收方服务器，不等于已经把邮件呈现在接收者屏幕上；后者还需要邮件访问机制。

2.4.3 MIME：传送多媒体邮件

电子邮件不仅包含普通文本，还可能包含图片、音频和附件。MIME 为这些内容补充类型说明与编码规则，使接收方知道怎样解释邮件。

定义：MIME（Multipurpose Internet Mail Extensions）

多用途 Internet 邮件扩展。通过邮件首部等信息声明内容类型、传输编码及多部分消息结构，使邮件能够表示非 ASCII 文本和多媒体内容。

几个重要字段是：

• MIME-Version：MIME 版本。
• Content-Type：内容的类型、子类型及必要参数，例如 image/jpeg。
• Content-Transfer-Encoding：正文采用的传输编码，例如 base64。

例子：图片如何成为可解释的邮件内容

From: alice@example.org
To: bob@example.net
Subject: Photo
MIME-Version: 1.0
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
 
（经过 Base64 编码的图片数据）

接收方依据类型字段识别 JPEG 图片，依据编码字段恢复原始字节。Base64 是编码，不是加密。

同一封邮件若要同时放文字与附件，可使用 multipart 内容类型，把不同部分及其各自的首部组织在一起。

2.4.4 POP3、IMAP 与 Web 邮箱

邮件到达服务器后，用户代理还要访问邮箱。SMTP 负责投递，POP3 和 IMAP 主要解决读取与管理已存储邮件的问题。

方式	主要模型	多客户端使用时的特点
POP3（Post Office Protocol version 3）	认证后从服务器下载邮件	可选择下载后删除或保留；更偏向下载到本地
IMAP（Internet Message Access Protocol）	以服务器邮箱为中心，访问和管理邮件	在服务器保存文件夹等状态，便于多个客户端保持一致视图
Web 邮箱	浏览器经 HTTP/HTTPS 访问邮件服务的 Web 应用	用户通过网页读写邮件，后端仍需完成实际投递与存储

POP3 的“下载并删除”模式使服务器上的邮件被移除，换一台尚未下载过的设备就无法再从服务器取得这些邮件；“下载并保留”允许其他设备继续下载，但不同本地副本的组织状态未必同步。

POP3 所说的跨会话无状态，主要是指它不提供 IMAP 式的跨会话邮箱组织与同步状态，不表示服务器完全不保存邮件。

IMAP 将邮件集中保存在服务器，并支持文件夹、邮件与文件夹之间的映射等持久状态。客户端可以访问和操作这一共同邮箱，而不是只维护各自独立的下载副本。