COMP5416 Week 03 应用层讲课总结

Posted on Edited on In , Word count in article: 8.7k Reading time ≈ 32 mins.
COMP5416 Week 03 应用层详解。应用架构 C/S 与 P2P 的对比、套接字与进程寻址、四类传输服务需求与 TCP/UDP 能力边界、HTTP 的持久与非持久连接及三种方式的 RTT 通用公式、HTTP/2 的分帧与 HOL 阻塞缓解、Cookie 的四组件、Web 缓存三方案完整算例与命中率敏感性分析、条件 GET，以及 FTP 双连接与 SMTP/POP3/IMAP 邮件协议族。

COMP5416 Week 03 讲课总结：Network Applications

课程：COMP5416/COMP4416 — Advanced Network Technologies，Semester 2 2026 讲师：Professor Vincent Gramoli 讲义：W3-Applications.pdf（67 页） 教材：Kurose & Ross, Computer Networking: A Top-Down Approach, 9th ed. —— 第 2 章，2.1 / 2.2 / 2.3 节

⚠️ Midterm quiz 在 Week 6，占 20%，20 道选择题。 ✅ 老师已说明：期中不考 Week 6 的内容，范围就是 Week 1–5。

本讲是考纲里概念密度最高的一周 —— 协议对比、端口号、状态性这类 MCQ 送分题全在这里。

第一部分：应用层与应用架构

一、为什么只需要写端系统的程序

写运行在（不同）端系统上、通过网络通信的程序。 不需要为网络核心设备写软件 —— 网络核心设备不运行用户应用。

这带来的好处：应用可以快速开发和推广（rapid app development, propagation）。

为什么这一点重要：这是互联网设计哲学的直接体现 —— 把智能放在边缘（end systems），把网络核心保持简单。 想推一个新应用，只要在两台主机上装软件即可，不需要说服全世界的路由器厂商升级设备。

讲义列举的网络应用：电子邮件、Web、即时消息、远程登录、P2P 文件共享、多人网游、流媒体视频（YouTube、Hulu、Netflix）、VoIP（Skype）、实时视频会议、社交网络、搜索。

二、两种应用架构

Client-Server P2P
服务器 always-on 主机，永久 IP 地址，用数据中心扩展 没有 always-on 服务器
端系统关系 客户之间不直接通信 任意端系统直接通信，对等方互相请求并提供服务
连接性 客户可能间歇连接，可能是动态 IP 对等方间歇连接且会换 IP
扩展性 靠加服务器 自扩展（self-scalability）
管理 相对简单 复杂

self-scalability 的含义（P2P 的标志性考点）

讲义原话：「新对等方带来新的服务能力，同时也带来新的服务需求。」

换句话说：新用户既是负担也是资源 —— 这是 C/S 架构完全没有的性质。 C/S 里每来一个用户，服务器负担就多一分；P2P 里每来一个用户，系统总上传能力也涨一分。

量化版本见 Week 04 的文件分发公式 —— P2P 的分母 随 N 增长，正是自扩展的数学表达。

第二部分：进程通信与寻址

三、进程与套接字

概念 定义
进程 主机上运行的程序
同一主机内的通信 操作系统定义的进程间通信（IPC）
不同主机间的通信 交换消息
角色 定义
客户进程 发起通信的进程
服务器进程 等待被联系的进程

讲义的旁注很重要：P2P 架构的应用里，同时存在客户进程和服务器进程。

也就是说：「客户/服务器」描述的是「进程角色」，不是「系统架构」。 一个 BitTorrent 节点在下载时是客户进程，在上传时是服务器进程 —— 同一台机器同时扮演两种角色。

四、套接字（Socket）

套接字类比一扇门：

  • 发送进程把消息推出门外
  • 发送进程依赖门外的传输基础设施把消息送到接收进程的套接字
发送进程                              接收进程
   │                                     │
┌──▼───┐                            ┌───▲──┐
│socket│  ← 门                门 →  │socket│
└──┬───┘                            └───▲──┘
   │        传输基础设施（TCP/UDP）        │
   └─────────────────────────────────────┘

这个比喻的精髓在「依赖」二字：发送方把消息推出门就管不着了， 后面能不能送到、按什么顺序送到，取决于门外那套基础设施是 TCP 还是 UDP。

五、进程寻址（高频 MCQ）

Q：主机的 IP 地址是否足以标识进程？ A：不能 —— 同一主机上可能运行很多进程。

标识符 = IP 地址 + 端口号。

端口号汇总

服务 端口 讲义是否点名
HTTP 80 ✓
SMTP（邮件服务器） 25 ✓
FTP 控制 21 ✓
FTP 数据 20 ✓
DNS 53 Week 4
POP3 110 补充
IMAP 143 补充

讲义给的完整例子：给 gaia.cs.umass.edu 的 Web 服务器发 HTTP 消息，需要 IP 地址 128.119.245.12 + 端口号 80。

💡 主机 IP 是 32 位（IPv6 是 128 位）。

六、应用层协议定义了什么

要素 内容
消息类型 如请求、响应
消息语法 有哪些字段、字段如何分隔
消息语义 字段中信息的含义
规则 进程何时、如何发送与响应消息
类型 特点 例子
开放协议 在 RFC 中定义，允许互操作性 HTTP、SMTP
专有协议 不公开 Skype

「开放 vs 专有」的实际意义：HTTP 是 RFC 定义的，所以任何人写的浏览器都能访问任何人写的服务器。 Skype 早期是专有协议，只能用官方客户端 —— 这就是互操作性的价值。

第三部分：传输服务需求与 TCP/UDP

七、应用需要什么样的传输服务（四个维度）

维度 说明
数据完整性 有些应用（文件传输、Web 事务）要求 100% 可靠；有些（音频）可容忍丢失
时延（timing） 网络电话、交互游戏要求低时延才「有效」
吞吐量 多媒体需要最低吞吐量；「弹性应用（elastic apps）」有多少用多少
安全 加密、数据完整性

八、常见应用的需求对照表（MCQ 常考）

应用 数据丢失 吞吐量 时间敏感
文件传输 不能丢 弹性 否
电子邮件 不能丢 弹性 否
Web 文档 不能丢 弹性 否
实时音视频 可容忍丢失 音频 5 kbps–1 Mbps
视频 10 kbps–5 Mbps		 是，100 毫秒级
存储音视频 可容忍丢失 同上 是，几秒级
交互游戏 可容忍丢失 几 kbps 起 是，100 毫秒级
文本消息 不能丢 弹性 是也不是

两组最容易被考的对比：

  1. 实时音视频（100 毫秒级）vs 存储音视频（几秒级） —— 存储视频可以缓冲，所以对时延宽容得多。
  2. 交互游戏的吞吐量要求很低（几 kbps）但时延要求极严（100 毫秒） —— 说明「吞吐量」和「时延」是两个独立的维度，不能混为一谈。

九、TCP vs UDP（必背）

服务 TCP UDP
可靠传输 ✅ ❌
流量控制 ✅ 发送方不会淹没接收方 ❌
拥塞控制 ✅ 网络过载时抑制发送方 ❌
面向连接 ✅ 需要建立 ❌ 无需连接建立
时延保证 ❌ ❌
最低吞吐量保证 ❌ ❌
安全 ❌ ❌

两个都不提供的三样东西：时延、最低吞吐量、安全。 这是 MCQ 的经典陷阱选项。

讲义在 UDP 那一栏后面直接抛了个问题： 「既然 UDP 什么都不保证，为什么还要有它（Why bother? Why is there a UDP）？」 答案要到 Week 05 才完整给出： 无连接建立时延、无连接状态、首部只有 8 字节、无拥塞控制（想多快发多快）。

十、常见应用用什么协议（高频 MCQ）

应用 应用层协议 传输层协议
电子邮件 SMTP [RFC 2821] TCP
远程终端 Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
文件传输 FTP [RFC 959] TCP
流媒体 HTTP（如 YouTube）、RTP [RFC 1889] TCP 或 UDP
网络电话 SIP、RTP、专有（如 Skype） TCP 或 UDP

记忆分界：前四个全是 TCP，后两个是「TCP 或 UDP」。

为什么后两个可以二选一：多媒体应用容忍丢包， 用 UDP 能避免重传带来的卡顿；但用 TCP 能穿过只放行 TCP 的防火墙 —— 所以实际部署中两种都有（YouTube 走 HTTP over TCP，Skype 优先 UDP）。

十一、保护 TCP：SSL

说明
TCP & UDP 本身 不加密；明文密码进入套接字后以明文穿越互联网
SSL 提供什么 加密的 TCP 连接、数据完整性、端点认证
SSL 在哪一层 SSL 在应用层 —— 应用使用 SSL 库，库再与 TCP「对话」
SSL 套接字 API 明文密码进入套接字后以加密形式穿越互联网

「SSL 位于应用层」是极易出错的 MCQ 点。

为什么容易错：SSL 提供的是「加密的 TCP 连接」，字面上看像传输层的东西。 但它的实现是一个应用可以链接的库 —— 应用调 SSL 库，SSL 库再调普通的 TCP 套接字。 传输层内核代码完全不知道 SSL 的存在。

💡 一个实测佐证：Week 04 的 Wireshark tutorial 里， HTTP Basic 认证的密码是 Base64 编码（不是加密）—— 抓包就能还原出明文。 这正是「TCP 不加密，需要 SSL」的直接演示。

第四部分：Web 与 HTTP

十二、基本概念

  • 网页由对象（objects）组成；对象可以是 HTML 文件、JPEG 图片、Java applet、音频文件
  • 网页由一个基础 HTML 文件 + 若干引用对象构成
  • 每个对象由 URL 寻址：
www.someschool.edu/someDept/pic.gif
└────────┬───────┘└──────┬──────┘
      主机名            路径名

十三、HTTP 概览

特性 说明
全称 HyperText Transfer Protocol
模型 客户/服务器
客户是谁 浏览器 —— 请求、接收、「显示」Web 对象
服务器是谁 Web 服务器 —— 响应请求发送对象
传输 TCP，端口 80
状态性 HTTP 是无状态的（stateless）

一次 HTTP 交互的四步

步骤 动作
1 客户发起到服务器 80 端口的 TCP 连接（创建套接字）
2 服务器接受来自客户的 TCP 连接
3 浏览器与 Web 服务器之间交换 HTTP 消息
4 TCP 连接关闭

为什么 HTTP 要设计成无状态（讲义的旁注）

「维护状态的协议很复杂！」

原因 说明
必须保存历史 服务器要为每个客户记住之前发生过什么
崩溃后不一致 若服务器/客户崩溃，双方对状态的看法可能不一致，还得协调修复

代价：要加状态就得另想办法 —— 这就是 Cookie 存在的理由（第十八节）。

十四、持久 vs 非持久 HTTP（核心考点）

非持久 HTTP 持久 HTTP
每条 TCP 连接 最多发送一个对象，然后连接关闭 可发送多个对象
多对象 需要多条连接 单条连接上完成
请求时机 逐个来回 客户一遇到引用对象就发请求

非持久 HTTP 的完整六步（讲义 p23）

场景：用户输入 www.someSchool.edu/someDepartment/home.index（含文本和 10 张 jpeg 的引用）

步骤 动作
1a 客户发起到 www.someSchool.edu 80 端口的 TCP 连接
1b 服务器在 80 端口等待，接受连接，通知客户
2 客户把 HTTP 请求消息（含 URL）送进套接字
3 服务器收到请求，构造含被请求对象的响应消息，送进套接字
4 服务器关闭 TCP 连接
5 客户收到响应，显示 HTML；解析 HTML，发现 10 个引用的 jpeg 对象
6 对这 10 个对象各重复一次步骤 1–5

注意步骤 4 的位置 —— 服务器在发完一个对象后就主动关连接， 所以取 10 张图要重新建 10 次 TCP 连接。这就是「非持久」的字面含义。

十五、响应时间公式（必背）

RTT 定义：一个小分组从客户到服务器再回来的时间。

非持久响应时间文件传输时间

三个组成部分的时间轴：

客户                                    服务器
 │                                        │
 ├──── 发起 TCP 连接 ────────────────────→ │  ┐
 │ ←─────────────────────── 连接确认 ─────┤  │ 1 个 RTT
 │                                        │  ┘
 ├──── 请求文件 ────────────────────────→ │  ┐
 │ ←─────────────── 响应的前几个字节 ─────┤  │ 1 个 RTT
 │                                        │  ┘
 │ ←═══════════ 文件的其余部分 ═══════════┤  ← 文件传输时间
 │                                        │
组成 用途
1 个 RTT 发起 TCP 连接
1 个 RTT HTTP 请求 + 响应的前几个字节返回
文件传输时间 传完整个文件

持久 HTTP：所有引用对象最少可以只用 1 个 RTT。

非持久 HTTP 的三个问题（讲义 p25）

# 问题
1 每个对象需要 2 个 RTT
2 每条 TCP 连接都有操作系统开销
3 浏览器常开并行 TCP 连接来抓取引用对象

三种方式的 RTT 通用公式（自己推的，考试直接套）

基础对象永远要 （建连 + 请求）。差别全在「 个引用对象要几个 RTT」：

方式 引用对象部分 总计
非持久·串行
非持久·并行（上限 条）
持久 + 并行（上限 条）
持久 + 流水线（无并行上限）

⚠️ 「持久」有两种口径，别混用：

口径 引用对象耗时 什么时候用
持久 + 流水线 所有对象共 1 个 RTT 题目说「persistent HTTP with pipelining」或没提并行上限
持久 + 并行上限 分 轮，每轮 1 个 RTT 题目给了「maximum of k parallel TCP connections」

本课程 tutorial 和 Kurose 交互题用的都是第二种（给了 ）。 时两者相同，所以小题看不出区别 —— 时才会分家。

代入不同的引用对象数 （并行上限 ）：

非持久串行 非持久并行 持久+并行 持久+流水线
0 2 RTT 2 RTT 2 RTT 2 RTT
1 4 RTT 4 RTT 3 RTT 3 RTT
3 8 RTT 4 RTT 3 RTT 3 RTT
5 12 RTT 4 RTT 3 RTT 3 RTT
10 22 RTT 6 RTT 4 RTT 3 RTT
20 42 RTT 10 RTT 6 RTT 3 RTT

讲义的典型题：「一个页面含 1 个 HTML + 10 张图，非持久 HTTP 需要多少 RTT（忽略传输时间）？」 答案： 个 RTT。

注意 、 这一行：持久+并行是 4 个 RTT 而不是 3 —— 10 个对象要分 2 轮，每轮 1 个 RTT。这一行正是 Kurose 交互题的标准配置。

💡 和 Week 05 的 DNS tutorial 联动： 那道题在这几条公式前面再加一个 DNS 查询时延，形式完全一样。

十六、HTTP 请求消息

ASCII 格式（人类可读）。讲义给的实例：

GET /index.html HTTP/1.1\r\n                          ← 请求行
Host: www-net.cs.umass.edu\r\n                        ┐
User-Agent: Firefox/3.6.10\r\n                        │
Accept: text/html,application/xhtml+xml\r\n           │
Accept-Language: en-us,en;q=0.5\r\n                   │ 首部行
Accept-Encoding: gzip,deflate\r\n                     │
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n            │
Keep-Alive: 115\r\n                                   │
Connection: keep-alive\r\n                            ┘
\r\n                          ← 行首的回车换行表示首部结束

通用格式：

请求行:  方法 sp URL sp 版本 cr lf
首部行:  字段名: 值 cr lf
        字段名: 值 cr lf
        ...
        cr lf                    ← 空行标志首部结束
实体体:  (可选)

\r\n 是回车（CR）+ 换行（LF） —— 连续两个 \r\n 表示首部结束、实体体开始。 这个「空行分隔」的设计和邮件消息格式（RFC 822）是一样的。

十七、提交表单输入的两种方式

方式 做法 特点
POST 方法 输入放在实体体（entity body）中上传 数据不出现在 URL 里
URL 方法 用 GET 方法，输入放在请求行的 URL 字段里 数据出现在 URL 里

URL 方法的例子：

www.google.com.au/search?q=new&ie=utf-8
                        └────────┬──────┘
                          表单输入在 URL 中

十八、方法类型（按版本区分，易考）

版本 方法
HTTP/1.0 GET、POST、HEAD
HTTP/1.1 GET、POST、HEAD + PUT、DELETE
方法 作用
GET 请求对象
POST 在实体体中上传表单输入
HEAD 要求服务器在响应中「不要」包含被请求的对象（只回首部）
PUT 把实体体中的文件上传到 URL 指定的路径
DELETE 删除 URL 字段指定的文件

PUT 和 DELETE 是 1.1 才有的 —— 这是常考的版本区分点。

HEAD 的用途：想知道对象的元信息（大小、修改时间）但不想下载它 —— 比如爬虫检查链接是否有效、缓存检查对象是否变化。

十九、HTTP 响应消息与状态码

讲义给的实例：

HTTP/1.1 200 OK\r\n                                    ← 状态行
Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n                ┐
Server: Apache/2.0.52 (CentOS)\r\n                     │
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n       │
ETag: "17dc6-a5c-bf716880"\r\n                         │ 首部行
Accept-Ranges: bytes\r\n                               │
Content-Length: 2652\r\n                               │
Keep-Alive: timeout=10, max=100\r\n                    │
Connection: Keep-Alive\r\n                             │
Content-Type: text/html; charset=ISO-8859-1\r\n        ┘
\r\n
data data data data data ...                           ← 数据（请求的 HTML 文件）

状态码出现在服务器→客户响应消息的第一行。

状态码 含义
200 OK 请求成功，对象在本消息后面
301 Moved Permanently 对象已移动，新位置在本消息的 Location: 中
400 Bad Request 服务器无法理解该请求消息
404 Not Found 服务器上找不到该文档
505 HTTP Version Not Supported 不支持的 HTTP 版本
304 Not Modified 条件 GET 的响应 —— 缓存副本仍是最新的（见第二十三节）

状态码的首位数字是分类：2xx 成功、3xx 重定向、4xx 客户端错误、5xx 服务器错误。 讲义给的 5 个刚好覆盖了 2/3/4/5 四类。

二十、自己动手试 HTTP（讲义 p39）

telnet cis.poly.edu 80          # 打开到 80 端口的 TCP 连接

然后输入（敲两次回车）：

GET /~ross/ HTTP/1.1
Host: cis.poly.edu

「敲两次回车」正是因为需要那个空行来标志首部结束 —— 呼应第十六节的消息格式。 这个练习的价值：HTTP 是纯 ASCII 协议，人手就能敲出一个合法请求。

第五部分：HTTP/2

二十一、要解决什么

核心目标：降低多对象 HTTP 请求的时延（decreased delay in multi-object HTTP requests）。

HTTP/1.1 的问题：

问题 说明
流水线 GET HTTP/1.1 引入了单条 TCP 连接上的多个流水线 GET
FCFS 响应 服务器按先来先服务（first-come-first-served）顺序响应
队头阻塞 FCFS 导致小对象可能排在大对象后面等待 —— Head-of-Line (HOL) blocking
丢包放大 丢包恢复（重传丢失的 TCP 段）会阻塞对象传输

HOL 阻塞的量化示意

场景（讲义 p34）：客户请求 1 个大对象 O1 + 3 个小对象 O2/O3/O4。 假设 O1 需要 100 个时间单位，O2–O4 各需 1 个单位。

协议 O1 完成 O2 完成 O3 完成 O4 完成 小对象平均完成时刻
HTTP/1.1（FCFS） 100 101 102 103 102
HTTP/2（分帧交错） 103 1 2 3 2

代价与收益一目了然：

  • 小对象平均完成时刻从 102 降到 2 —— 快了约 51 倍
  • O1 只从 100 推迟到 103 —— 讲义原话「O1 slightly delayed」

这就是为什么分帧交错值得做：牺牲一点大对象的完成时间，换取所有小对象的大幅提前。

二十二、HTTP/2 的改进 [RFC 7540, 2015]

改进 说明
兼容性 方法、状态码、大多数首部字段与 HTTP/1.1 不变
传输顺序 按客户端指定的对象优先级传输，不必是 FCFS
服务器推送 主动推送客户未请求的对象
分帧 把对象切成帧，调度帧的发送以缓解 HOL 阻塞

帧与流（Frames and Streams）

概念 定义
Frame（帧） HTTP/2 的基本数据单元，取代 HTTP/1.1 的「首部 + 体」格式
二进制编码（更高效）
分 Header frames 和 Data frames
Stream（流） 传输帧的双向通道，取代 HTTP/1.1 的请求-响应模式

一句话记住整个架构：单条 TCP 连接承载多个流，每个流由多个帧组成。

HTTP/2 的两大变化：

  1. 二进制分帧（取代文本格式）
  2. 多路复用的流（取代一问一答）

服务器推送（Server Push）

HTTP/2 的 Server Push 机制允许服务器在「相信客户会需要」时主动发送资源， 而不必等待请求。

典型用法：客户请求 index.html，服务器知道这个页面必然会引用 style.css 和 app.js， 于是不等客户解析完 HTML 就把这两个文件推过去 —— 省掉一个 RTT。

第六部分：Cookie 与 Web 缓存

二十三、Cookie：给无状态的 HTTP 加状态

四个组成部分（考点）

# 组成
1 HTTP 响应消息中的 cookie 首部行（Set-cookie:）
2 下一个 HTTP 请求消息中的 cookie 首部行（cookie:）
3 保存在用户主机上的 cookie 文件，由用户的浏览器管理
4 网站后端的数据库

完整流程（讲义 p40–41 的 Amazon 例子）

客户                                          服务器（Amazon）
 │                                                 │
 ├── 普通 HTTP 请求 ─────────────────────────────→ │  创建 ID 1678
 │                                                 │  数据库建条目
 │ ←──── 普通 HTTP 响应 + set-cookie: 1678 ────────┤
 │  cookie 文件写入 amazon 1678                     │
 │                                                 │
 ├── 普通 HTTP 请求 + cookie: 1678 ───────────────→ │  cookie 特定动作
 │ ←──── 普通 HTTP 响应 ───────────────────────────┤
 │                                                 │
 │           ······  一周后  ······                  │
 │                                                 │
 ├── 普通 HTTP 请求 + cookie: 1678 ───────────────→ │  cookie 特定动作
 │ ←──── 普通 HTTP 响应 ───────────────────────────┤

注意 cookie 文件里可以同时存多个站点的条目（讲义画的是 ebay 8734 和 amazon 1678）—— 浏览器按域名分别管理，发请求时只带对应站点的那条。

用途与隐私

能用来做什么 隐私问题
授权（authorization） cookie 让站点能了解你很多信息
购物车 你可能会向站点提供姓名和邮箱
推荐
用户会话状态（Web 邮件）

讲义总结的两种保持状态的方式：

方式 说明
协议端点 在发送方/接收方跨多次事务维护状态
Cookie 由 HTTP 消息携带状态

HTTP 选了第二条路 —— 状态不在服务器的连接里，而在每次请求都带上的那个 ID 里。 这样服务器仍然是无状态的（不为连接保存上下文），状态被外置到了数据库。

二十四、Web 缓存（代理服务器）

工作方式

目标：在不惊动源服务器的情况下满足客户请求。

步骤 动作
1 用户设置浏览器：所有 HTTP 请求先发给缓存
2 若对象在缓存中 → 缓存直接返回
3 否则 → 缓存向源服务器请求，再返回给客户

缓存既是客户又是服务器（高频 MCQ）

Q：缓存扮演客户还是服务器？ A：两者都是。

面向谁 扮演什么
最初发请求的客户 服务器
源服务器 客户

缓存通常由 ISP 安装（大学、公司、住宅 ISP）。

为什么要 Web 缓存

理由 说明
减少客户请求的响应时间 —
减少机构接入链路上的流量 这才是缓存最主要的经济价值
让「穷」内容提供者也能有效交付内容 💡 讲义补了一句：P2P 文件共享也有同样作用

二十五、完整算例（讲义 p46–49，必考）

假设条件

参数 值
平均对象大小 100 K bits
浏览器到源服务器的平均请求率 15 /秒
到浏览器的平均数据率 1.50 Mbps
机构路由器到任意源服务器的 RTT 2 秒
接入链路速率 1.54 Mbps
局域网 1 Gbps

数据率的来源：

三个方案的完整对照

方案 走接入链路的数据率 接入链路利用率 总时延 成本
① 原始配置 1.50 Mbps 99% 2 秒 + 数分钟 + 微秒 —
② 加粗到 154 Mbps 1.50 Mbps 约 1% 毫秒级 不便宜！
③ 装缓存（命中 0.4） 0.9 Mbps 0.58 约 1.2 秒 便宜

方案①：为什么会「数分钟」

总时延 = 互联网时延 + 接入时延 + LAN 时延 = 2 秒 + 数分钟 + 微秒

关键理解：接入链路利用率接近 100% 时，排队时延会爆炸。 这是排队论的基本结论 —— 利用率趋近 1 时排队时延趋于无穷。

💡 自己核算：，讲义写 99%（教材的取整口径），结论不变：接近饱和。

方案②：加粗链路

⚠️ 讲义 p47 标注的「9.9%」需要留意：

不是

Kurose 原书给的是约 0.99% —— 讲义上的 9.9% 极可能是 0.99% 的笔误（小数点错位）。 考试时按「利用率降到约 1%」理解即可。

方案③：装本地缓存（三步解题模板）

假设缓存命中率 ：

第一步 —— 算走接入链路的数据率：

数据率

第二步 —— 算利用率：

第三步 —— 算总时延：

源缓存毫秒秒

注意 2.01 这个数：2 秒 RTT + 0.01 秒接入链路时延（利用率 0.58 时排队时延已经很小）。

讲义的结论：比 154 Mbps 的链路时延更低，而且更便宜。

命中率的敏感性分析（自己算的，帮助理解）

命中率 接入链路利用率 总时延
0% 97.4% 2.01 s
20% 77.9% 1.61 s
40% 58.4% 1.21 s
60% 39.0% 0.80 s
80% 19.5% 0.40 s

规律：命中率每提高 0.2，利用率降约 19.5 个百分点，总时延降约 0.4 秒 —— 两者都是线性的（因为公式里 是一次项）。

二十六、条件 GET（Conditional GET）

目标：如果缓存已有最新版本，就不要再传对象。 好处：无对象传输时延、更低的链路利用率。

方向 内容
缓存 → 服务器 在 HTTP 请求中写明缓存副本的日期：If-modified-since: <date>
服务器 → 缓存（未修改） HTTP/1.0 304 Not Modified，响应不含对象
服务器 → 缓存（已修改） HTTP/1.0 200 OK + 数据 
缓存                                    服务器
 │                                        │
 ├── GET + If-modified-since: <date> ───→ │
 │ ←── HTTP/1.0 304 Not Modified ─────────┤   对象在 <date> 后未改
 │       （不含对象！）                     │
 │                                        │
 ├── GET + If-modified-since: <date> ───→ │
 │ ←── HTTP/1.0 200 OK + <data> ──────────┤   对象在 <date> 后改过

If-modified-since 与 304 Not Modified 这一对是必考组合。

💡 实测版本见 Week 04 笔记的 Wireshark tutorial —— 那里能看到第一次 GET 没有 If-modified-since、第二次有且服务器返回 304 的真实抓包。

第七部分：FTP

二十七、基本特性

特性 说明
功能 在远程主机之间传输文件
模型 客户/服务器
客户是谁 发起传输的一方（无论上传还是下载）
服务器是谁 远程主机
RFC RFC 959
端口 控制连接 21，数据连接 20

二十八、分离的控制与数据连接（核心考点）

FTP 客户                              FTP 服务器
   │                                      │
   ├══ TCP 控制连接（服务器端口 21）══════→ │   命令走这条，全程保持
   │                                      │
   ├── TCP 数据连接（服务器端口 20）─────→ │   传一个文件开一条，传完就关
   │                                      │
   ├── TCP 数据连接（服务器端口 20）─────→ │   传下一个文件再开一条
步骤 动作
1 FTP 客户用 TCP 连接服务器的端口 21
2 客户在控制连接上完成授权
3 客户在控制连接上浏览远程目录、发送命令
4 服务器收到文件传输命令时，另开第 2 条 TCP 数据连接到客户
5 传完一个文件后，服务器关闭数据连接
6 要传下一个文件，服务器再开一条新的数据连接

两个必考结论

① 控制连接是「带外（out of band）」的

命令和数据走两条不同的 TCP 连接。 对比 HTTP：HTTP 是「带内（in band）」的 —— 请求和数据在同一条连接上。

② FTP 服务器维护状态

要记住：当前目录、之前的认证。 与无状态的 HTTP 形成鲜明对比 —— 这是本讲最常考的一组反差。

二十九、常用命令与返回码

命令以 ASCII 文本在控制通道发送：

命令 作用
USER username 用户名
PASS password 密码
LIST 返回当前目录的文件列表
RETR filename 取回（get）文件
STOR filename 存储（put）文件到远程主机

返回码是状态码 + 短语（与 HTTP 类似）：

返回码 含义
331 Username OK, password required 用户名对了，要密码
125 data connection already open; transfer starting 数据连接已开，开始传
425 Can't open data connection 打不开数据连接
452 Error writing file 写文件出错

第八部分：电子邮件

三十、三大组件

组件 说明
用户代理（User Agent） 又叫「邮件阅读器」；撰写、编辑、阅读邮件；如 Outlook、Thunderbird、iPhone 邮件客户端
收发的消息都存在服务器上
邮件服务器 邮箱（mailbox）存放该用户的收件
消息队列（message queue）存放待发邮件
SMTP 在邮件服务器之间发送邮件的协议

三十一、SMTP [RFC 2821]

特性 说明
传输 TCP，端口 25
传输方式 直接传输：发送方服务器 → 接收方服务器（中间不经过其他邮件服务器）
三个阶段 握手（greeting）→ 消息传输 → 关闭
交互 命令/响应（像 HTTP、FTP）；命令是 ASCII，响应是状态码 + 短语
编码限制 消息必须是 7 位 ASCII
连接 使用持久连接
消息结束标志 用 CRLF.CRLF 判断消息结束

Alice 发给 Bob 的六步（讲义 p59）

步骤 动作
1 Alice 用 UA 撰写发往 bob@someschool.edu 的邮件
2 Alice 的 UA 把消息发给她的邮件服务器，放入消息队列
3 SMTP 的客户端打开到 Bob 邮件服务器的 TCP 连接
4 SMTP 客户端通过该 TCP 连接发送 Alice 的消息
5 Bob 的邮件服务器把消息放入 Bob 的邮箱
6 Bob 调用他的用户代理阅读消息

注意步骤 3 的措辞：Alice 的邮件服务器此刻扮演「SMTP 客户端」 —— 这又是「客户/服务器是进程角色而非机器身份」的例子。

三十二、SMTP 会话样例（要能认出）

S: 220 hamburger.edu
C: HELO crepes.fr
S: 250  Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

命令顺序：HELO → MAIL FROM → RCPT TO → DATA → QUIT

注意那个单独一行的 . —— 这就是 CRLF.CRLF 结束标志的实际样子。

自己动手试（讲义 p61）：telnet servername 25，看到 220 回复后依次输入上面的命令 —— 这样就能不用邮件客户端发出一封邮件。

三十三、SMTP vs HTTP（超高频 MCQ）

维度 HTTP SMTP
推/拉 pull（拉） push（推）
对象封装 每个对象封装在自己的响应消息里 多个对象放在一条多部分（multipart）消息里
交互形式 ASCII 命令/响应 + 状态码 同左
编码限制 无 7 位限制 必须 7 位 ASCII
消息结束标志 Content-Length 等 CRLF.CRLF
连接 1.1 起用持久连接 持久连接

「HTTP 是 pull，SMTP 是 push」是最常考的一句。

怎么理解：HTTP 是「我去服务器拿东西」；SMTP 是「我把东西推到你的服务器上」。 方向不同，发起方也不同。

三十四、邮件消息格式（RFC 822）

To: bob@hamburger.edu           ┐
From: alice@crepes.fr           │ 首部行
Subject: Do you like ketchup?   ┘
                                  ← 空行
Do you like ketchup?            ┐
How about pickles?              ┘ 消息体（仅 ASCII 字符）

极易混淆的考点：

RFC 822 的 To: / From: 首部 ≠ SMTP 的 MAIL FROM: / RCPT TO: 命令！

属于什么 类比
To: / From: 消息内容的一部分 信纸上写的收件人
MAIL FROM: / RCPT TO: 协议层的信封 信封上写的地址

邮局按信封投递，不看信纸 —— 这就是为什么可以伪造 From: 首部（钓鱼邮件的原理）。

三十五、邮件访问协议

关键区分：

  • SMTP：投递/存储到接收方的服务器（push）
  • 邮件访问协议：从服务器取回（pull）
Alice 的 UA ──SMTP──→ Alice 的邮件服务器 ──SMTP──→ Bob 的邮件服务器
                                                        │
                                                   邮件访问协议
                                                   （POP / IMAP / HTTP）
                                                        │
                                                        ▼
                                                    Bob 的 UA
协议 RFC 特点
POP3 RFC 1939 授权 + 下载
IMAP RFC 1730 功能更多，包括在服务器上操作已存消息
HTTP — 用浏览器访问 webmail（如 https://webmail.sydney.edu.au）

POP3 协议的两个阶段

授权阶段：

客户命令 服务器响应
user bob +OK
pass hungry +OK user successfully logged on

服务器响应只有两种：+OK 和 -ERR。

事务阶段：

命令 作用
list 列出消息编号（和大小）
retr 按号取回消息
dele 删除
quit 结束

完整会话样例：

S: +OK POP3 server ready
C: user bob
S: +OK
C: pass hungry
S: +OK user successfully logged on
C: list
S: 1 498
S: 2 912
S: .
C: retr 1
S: <message 1 contents>
S: .
C: dele 1
C: retr 2
S: <message 2 contents>
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off

三十六、POP3 vs IMAP（必考对照）

POP3 IMAP
消息存放 下载到本地 全部保留在服务器一处
组织能力 无 允许用户用文件夹组织消息
跨会话状态 POP3 跨会话是无状态的 保留用户跨会话的状态：文件夹名、消息 ID 与文件夹的映射

POP3 的两种模式

模式 后果
「下载并删除」 换客户端后读不到旧邮件
「下载并保留」 不同客户端上都有副本

「POP3 下载并删除 ⇒ 换设备就读不到旧邮件」是经典 MCQ 情境题。

这也解释了为什么现代邮件几乎都用 IMAP —— 手机、平板、电脑要看到同一份邮箱， 就必须让服务器保存状态。

第九部分：MCQ 速查表

端口号（背熟）

协议 端口
HTTP 80
SMTP 25
FTP 控制 21
FTP 数据 20
DNS 53

状态性

协议 有无状态
HTTP 无状态
FTP 有状态（当前目录、认证）
POP3 跨会话无状态
IMAP 有状态（文件夹、映射）

层次归属

项 所在层
SSL 应用层（不是传输层！）
HTTP / FTP / SMTP / POP3 / IMAP / DNS 应用层

推 vs 拉

协议 方向
HTTP pull
SMTP push

带内 vs 带外

协议 控制信息
HTTP 带内（in band）
FTP 带外（out of band，独立控制连接）

计算题模板

题型 公式
非持久 HTTP（单对象） 传输时间
非持久·串行（n 个引用对象）
非持久·并行（上限 k）
持久 + 并行（上限 k）
持久 + 流水线（无上限）
缓存后的链路利用率 数据率链路速率
缓存后的总时延 源缓存

HTTP 版本区分

版本 新增
1.0 GET、POST、HEAD
1.1 + PUT、DELETE；+ 持久连接；+ 流水线 GET
2 + 二进制分帧；+ 多路复用的流；+ 优先级；+ 服务器推送

最容易错的 7 个点

  1. SSL 在应用层，不是传输层
  2. FTP 数据端口是 20，21 是控制
  3. FTP 有状态，HTTP 无状态 —— 常放在一起考
  4. RFC 822 的 To: ≠ SMTP 的 RCPT TO:（信纸 vs 信封）
  5. HTTP 是 pull，SMTP 是 push
  6. PUT / DELETE 是 HTTP/1.1 才有的
  7. 持久 HTTP 别一律套「3 个 RTT」 —— 题目给了并行上限 时是 个 RTT；只有「流水线、无并行上限」才是恒定 3 个

第十部分：本讲在考纲中的位置

Week 主题 笔记
1 Introduction Week 01
2 Performance Week 02
3 Applications 本文
4 DNS and P2P Week 04
5 Transport Week 05
6 TCP ⚠️ Canvas 未发布

本讲与前后的三条连接：

连接 说明
P2P 的 self-scalability 本讲只给了定性描述，Week 04 给出定量公式
「为什么要有 UDP」 本讲提了问题，Week 05 给出四点答案
HTTP 的 RTT 公式 Week 05 的 DNS tutorial 在此基础上加 DNS 查询时延

tutorial 与 lecture 的一周错位： 本讲的配套练习是 Week 4 模块里的 HTTP Wireshark tutorial —— 完整解析见 Week 04 笔记第四部分， 那里实测了条件 GET 的 304 响应和 Basic 认证的 Base64 明文密码。

配套练习：20 题期中模拟卷 的板块二（Q7–Q11）专测本讲内容。