网络应用模型

2026 大纲 六（一）1 客户/服务器模型（C/S） 与 六（一）2 P2P 模型，两条子项由本篇合并承载。

速查

为什么先分体系结构	应用层协议定义"交换什么报文、语法、语义、何时发与怎样响应"，但在此之前必须先确定双方是不是对称的——它决定了谁先说话、谁得知道谁的地址、谁负责重试
🔴 应用 ≠ 应用层协议	万维网包含浏览器、服务器、文档格式标准和 HTTP；浏览器怎么渲染、服务器用多线程还是多进程都不属于 HTTP
C/S 的根	只有一方 7×24 在线：服务器"系统启动后一直运行、被动等待"，客户"被用户调用后才运行"
C/S 分发时间	$D_{\text{C/S}}=max\{NF/u_s,F/d_{min}\}$。$N$ 在分子上，时间随用户数线性发散且无上界——这才是"可扩展性差"
P2P 分发时间	$D_{\text{P2P}}=max\{F/u_s,F/d_{min},NF/(u_s+\sum u_i)\}$。服务器只需发一份；$N$ 同时在第三项的分子与分母上
🔴 自扩展性 = 有上界，不是越多越快	$D_{\text{P2P}}$ 对 $N$ 单调递增，只是收敛到与 $N$ 无关的 $max\{F/u_s,F/d_{min},F/u\}$。"节点越多总容量越大"（分母）对，"节点越多下载越快"（整个分式）错
🔴 P2P 本质仍是 C/S 机制	每次传输仍是一方请求、一方提供，区别只在角色不固定。"P2P 与 C/S 互斥"是错的
🔴 客户主动只约束连接建立	连接一旦建成通信就是双向的，服务器可以主动往这条连接上推数据
🔴 集中目录 ≠ 集中传输	Napster 的文件传输分散（P2P）、文件定位集中（C/S）。"混合式 P2P"的全部内容就是这句
🔴 固定 IP 约束的是对外地址	根域名服务器只有 13 个不同 IP 的域名，背后是上千台机器（任播分流）。"有固定 IP" ≠ "只有一台机器"
🔴 省服务器带宽 ≠ 对用户更省	P2P 省的是服务器的上行带宽，代价是占用用户自己的上行带宽、CPU 与磁盘 I/O

一、C/S 的三重不对称由一件事推出

"客户"和"服务器"指的是通信中的两个应用进程，描述的是"服务与被服务"的关系，不是两台机器——同一台机器上的进程完全可以这次当客户、下次当服务器（电子邮件的邮件服务器即是）。

每一环都被上一环逼出来：客户随时可能不在，服务器主动找它根本不知道它在不在、地址是多少，所以只能由客户发起；发起权在客户手上，客户就必须事先知道服务器地址，而服务器从请求报文里现取源 IP 和源端口就够了——这正是熟知端口（HTTP 80、FTP 21、SMTP 25、DNS 53）存在的理由；两个客户互相不知道对方地址、也都不长期在线，于是客户之间不能直连。

二、把"服务器是瓶颈"写成式子

场景：服务器把一个 $F$ 比特的文件分发给 $N$ 个客户，服务器上传速率 $u_s$，记最慢客户的下载速率为 $d_{min}$。边界先说清：假定瓶颈全在接入链路上，网络核心不拥塞、不丢包——这套结论在核心拥塞时不成立。

下界	从哪来
$D\ge NF/u_s$	文件只在服务器上，每个客户各要一份完整副本，至少 $N\cdot F$ 比特要从服务器上行链路挤出去
$D\ge F/d_{min}$	最慢的那个客户要收满 $F$ 比特，无论谁给它发

两条约束必须同时成立，取较大者；服务器按需分配上传带宽时这个较大者能取到，于是 $D_{\text{C/S}}=max\{NF/u_s,F/d_{min}\}$。只要 $N$ 大到让第一项超过第二项，分发时间就随客户数线性增长且没有上界——"服务器是瓶颈"说的不是"服务器会卡"，而是"总时长正比于用户数"。

三、P2P 的自扩展性说了什么

P2P 模型中没有（或只有极少数）固定的服务器，绝大多数交互在对等方之间直接进行。

同样的接入链路假设，再加一条：第 $i$ 个对等方的上传速率是 $u_i$。

下界	从哪来
$D\ge F/u_s$	文件一开始只有服务器有，它至少要完整发一次，否则系统里没有第二份副本可交换。分子上没有 $N$——与 C/S 的第一处分岔
$D\ge F/d_{min}$	与 C/S 完全一样
$D\ge NF/(u_s+\sum _i{u}_i)$	系统要"生产"出 $N\cdot F$ 比特下载量，能提供上传的总容量是服务器加全体对等方

第三项的分母里也有 $N$——每加入一个下载者，同时也加入一份上传能力，这就是自扩展性。设每个对等方上传速率都是 $u$，第三项即 $NF/(u_s+Nu)$：分子分母同增而分母有常数项 $u_s$ 拖着，故它对 $N$ 单调递增，$N\to \mathrm{\infty }$ 时收敛到 $F/u$。

分发时间随 N 的完整推演表（想亲手看清两条曲线怎么分岔时展开）

某文件 $F=300$ Mb。服务器上传速率 $u_s=30$ Mb/s；每个下载者下载速率都是 $d_{min}=10$ Mb/s、上传速率都是 $u_i=3$ Mb/s。

第 1 步：先算两个与 $N$ 无关的量。 它们在 P2P 公式里是常数项，先钉住，后面只需算随 $N$ 变化的那一项。

$$\frac{F}{u_s}=\frac{300}{30}=10\text{s},\frac{F}{d_{min}}=\frac{300}{10}=30\text{s}$$

第 2 步：C/S。 只有一项随 $N$ 变：$NF/u_s=300N/30=10N$ 秒，故 $D_{\text{C/S}}=max\{10N,30\}$。$N\ge 3$ 时服务器上行链路一定是瓶颈。

第 3 步：P2P 的第三项。 所有对等方上传速率相同，求和就是乘 $N$：

$$\frac{NF}{u_s+N{u}_i}=\frac{300N}{30+3N}=\frac{100N}{10+N}\text{s}$$

约分后分子分母同阶，所以这个量有极限。

第 4 步：逐个代入。

$N$	C/S	P2P 第三项	P2P 取 max 后	C/S ÷ P2P
1	30 s	9.09 s	30 s	1.0×
10	100 s	50.00 s	50 s	2.0×
100	1000 s	90.91 s	90.91 s	11.0×
1000	10000 s	99.01 s	99.01 s	101.0×

$N=1$ 这一格最值得停一下：P2P 的第三项 9.09 s 比 $F/d_{min}=30$ s 还小，被 max 挡掉了——P2P 在 $N=1$ 时并不比 C/S 快，两者都是 30 s。

第 5 步：取极限确认这不是巧合。

$$\underset{N\to \mathrm{\infty }}{lim}\frac{100N}{10+N}=100\text{s}=\frac{F}{u_i}=\frac{300}{3}$$

于是 $D_{\text{P2P}}$ 的上界是 $max\{10,30,100\}=100$ s，与 $N$ 无关；而 $D_{\text{C/S}}=10N$ 无上界。极限值恰好等于"一个对等方把整份文件上传出去所需的时间"$F/u_i$：当人足够多时，P2P 的总时长就等于每人各自上传一整份文件的时间。

一个反例：只下载不上传时，P2P 在数学上就是 C/S

仍取 $F=300$ Mb、$u_s=30$ Mb/s、$d_{min}=10$ Mb/s、$N=10$，但这 10 个对等方全部只下载不上传（$u_i=0$）：

$$D_{\text{P2P}}=max\{10,30,\frac{10\times 300}{30+0}\}=100\text{s},D_{\text{C/S}}=max\{100,30\}=100\text{s}$$

把 $\sum u_i$ 置 0，P2P 的第三项分母就退化成 $u_s$，与 C/S 的第一项完全相同。这解释了 BitTorrent 一类协议为什么必须内建"上传换下载"的激励机制——自扩展性来自 $\sum u_i$，不来自"P2P"这三个字母。

四、P2P 怎么找到资源：三种定位方式

传输可以分散，但"谁有这个文件"总得有人回答。三代 P2P 的差别几乎全在这里。

方式	代表	文件定位	文件传输	弱点
集中目录服务器	Napster	集中（向目录服务器查）	分散（P2P）	目录服务器是单点，既是可靠性弱点也是性能瓶颈
全分布式	Gnutella	分散（对等方之间洪泛查询）	分散（P2P）	洪泛通信量大；限制洪泛范围又损失命中率
分散定位 + 分散传输	BitTorrent	追踪器登记洪流成员，文件块列表由对等方交换	分散、按文件块并行	协议复杂；需激励机制防搭便车

BitTorrent 的两个术语解释了 P2P 为什么能真正跑起来：洪流（torrent） 是参与同一文件分发的全部对等方的集合；文件块（chunk） 是下载的数据单元，长度固定（典型 256 KB）。分块是自扩展性能落地的前提——新加入的对等方不必等整个文件下完就能开始上传；若不分块，所有人都得等第一个人下完整份才有第二个源，$\sum u_i$ 在很长时间里等于 0。

五、C/S 与 P2P 对比

对比项	C/S 模型	P2P 模型
是否有固定服务器	有，始终在线	没有，或只有少数辅助节点（目录服务器/追踪器）
节点角色	分工固定	随每次传输切换，可同时兼任
谁能发起连接	只有客户	任意一方
地址知识	客户须事先知道服务器地址	需要一种定位机制
管理与内容控制	集中，易审计与鉴权	分散，难以集中管控
健壮性	服务器故障即中断	单点失效影响小
本机开销	客户端很轻	占用本机 CPU、内存、磁盘 I/O 与上行带宽
典型应用	Web、FTP、邮件、DNS	BitTorrent、P2P 音视频分发

"客户之间不直接通信"是 C/S 模型的约束，不是"网络不允许"——同样两台主机装上 P2P 软件就能直连。

本节小结

1. C/S 的一切特点由"只有一方 7×24 在线"推出：在线不对称 → 只能客户发起 → 客户须先知道服务器地址（熟知端口由此而来）→ 客户之间不能直连。"客户主动"只约束连接建立阶段。
2. 两个模型的差别可以量化：C/S 的式子里 $N$ 只在分子上，时间随用户数无上界地发散；P2P 的式子里服务器只需发一份，且 $N$ 同时出现在第三项的分子与分母上。
3. 自扩展性 = 时间有上界，不是人越多越快；上界 $max\{F/u_s,F/d_{min},F/u\}$ 与 $N$ 无关。$N=1$ 时 P2P 不占优，$\sum u_i=0$ 时 P2P 在数学上退化成 C/S——它来自对等方的上传能力，不来自模型的名字。

教材出处

• 谢希仁《计算机网络》（第 8 版）印刷 p11，1.3.1 节：「客户(client)和服务器(server)都是指通信中所涉及的两个应用进程。客户服务器方式所描述的是进程之间服务和被服务的关系……这里最主要的特征就是：客户是服务请求方，服务器是服务提供方。」——本篇"客户/服务器指的是进程不是机器"的依据。同页还逐条列出客户程序"被用户调用后运行"、服务器程序"系统启动后一直不断地运行着，被动地等待并接受来自各地的客户的通信请求"，以及"服务器程序不需要知道客户程序的地址"，是第一节那条推导链的原文出处。
• 印刷 p12，1.3.1 节：「对等连接方式从本质上看仍然使用客户服务器方式，只是对等连接中的每一台主机既是客户同时又是服务器。」——本篇"P2P 本质仍是 C/S 机制"的依据。
• 印刷 p260，第 6 章引言：「应用层的许多协议都是基于客户服务器方式。即使是 P2P 对等通信方式，实质上也是一种特殊的客户服务器方式。」同页还写明「应用层协议与网络应用并不是同一个概念。应用层协议只是网络应用的一部分」，并以万维网为例说明浏览器如何显示页面、服务器用多线程还是多进程都不是 HTTP 定义的内容。
• 印刷 p320，6.9 节：「所谓 P2P 体系结构就是在这样的网络应用中，没有（或只有极少数的）固定的服务器，而绝大多数的交互都是使用对等方式（P2P 方式）进行的。」
• 印刷 p321，6.9.1 节：「Napster 的文件传输是分散的（P2P 方式），但文件的定位则是集中的（客户-服务器方式）」，并指出「这种集中式目录服务器的最大缺点就是可靠性差，而且会成为其性能的瓶颈」——第四节那张三代对比表的依据。
• 印刷 p322，6.9.2 节：Gnutella「不使用集中式的目录服务器进行查询，而是使用洪泛法……为了不使查询的通信量过大，Gnutella 设计了一种有限范围的洪泛查询」；BitTorrent「把参与某个文件分发的所有对等方的集合称为一个洪流（torrent）」「把对等方下载文件的数据单元称为文件块（chunk），一个文件块的长度是固定不变的，例如，典型的数值是 256 KB」。

说明：第二、三节那两组 $max\{\cdot \}$ 下界式不是教材原文，是本篇按"瓶颈全在接入链路"这一假设从带宽守恒直接推出来的，写在这里是为了把"服务器是瓶颈""P2P 可扩展性好"这两句定性结论变成能自己重推的东西。教材只给到定性表述（p320「这种 P2P 文件分发方式解决了集中式媒体服务器可能出现的瓶颈问题」）。

相关知识

体系结构与参考模型｜TCP 与 UDP 对比｜DNS 域名系统｜WWW 万维网｜HTTP 协议｜FTP 与 DHCP

上一篇FTP 与 DHCP

相关文章

• DNS 域名系统
• WWW 万维网
• HTTP 协议
• 电子邮件系统
• FTP 与 DHCP

真题练习

相关真题（1题）

2019Q402分