计网学习笔记（2）

应用层

应用层协议原理

网络应用程序体系架构

应用程序体系结构（application architecture）由应用程序研发者设计，规定了如何在各种端系统上组织这个应用程序。

目前的现代网络应用程序中一般会选择两种主流架构：==客户-服务器体系结构和对等（P2P）体系结构==

客户-服务器体系结构

服务器是一个==总是处于开机状态==的主机，它服务于来自许多其他称为客户的主机的请求。

特征

1. 两个或多个客户之间是不会直接建立通信的；
2. 服务器具有固定的、周知的地址，即IP地址

   应用

Web、FTP（文件传输协议）、Telnet（一种远程登录的协议）、电子邮件……

其他你需要知道的

由于使用互联网的人很多，向服务器发送的请求也很多，想要一个服务器来服务所有请求是不现实的。

因此，数据中心的作用就体现出来了，它配备了大量的主机，用于创建一个强大的虚拟服务器。

它的应用想必都见过，例如搜索引擎baidu，谷歌；Internet商务亚马逊，阿里巴巴；社交网络Facebook、推特

P2P体系结构

这个结构对位于数据中心的专用服务器具有很少的依赖（有时候可以没有），选用这种结构的应用程序在==间断连接的主机对之间使用直接通信==，这些主机对被称为对等方。

:::info

对等方的一些解释可以参考参考上一章网络的网络部分

:::

特性

1. ==自扩展性==。P2P网络是由许多用户节点组成的，当有新的用户加入时，服务的需求虽然在增加，但是系统整体的资源和服务能力也随之扩充，能较大程度上满足用户的需求。在服务器组成的P2P网络中，只需增加服务器就能完成平滑的扩容。
2. 成本低。P2P网络或者应用程序一般是不需要庞大的服务器基础设施和服务器带宽（与客户-服务器相对）

进程通信

站在操作系统的角度，进行通信的实际上是进程而并非程序。

在两个不同端系统上的进程，通过跨越计算机网络交换报文来进行通信。

客户和服务器进程

网络应用程序==由成对的进程组成，这些进程通过网络相互发送报文==。

在这一对进程中，我们将其中之一标记为客户，另一个则是服务器了。

举个栗子

在Web的应用程序中，一个客户浏览器进程与一台服务器进程相互交换报文。此时浏览器就是客户进程，Web服务器就是服务器进程。

在P2P文件共享系统中，文件从一个对等方进程传输到另一个对等方进程。此时下载方被标识为客户，上传方则被标识为服务器。

如何定义客户进程与服务器进程

以下定义==基于一对进程之间的通信会话场景==中

客户：发起通话的进程。

服务器：在会话开始时等待联系的进程。

进程与计算机网络之间的接口

进程通过一个套接字的软件接口向网络发送报文和从网络接收报文

下图是两个通过因特网通信的进程之间的套接字通信

在这个图中，套接字是同一台主机内应用层与运输层的接口，也是建立网络应用程序的可编程接口，因此也被称为网络应用程序接口（Application Programming Interface，API）

应用程序开发者对套接字的管理

从开发者的角度看，他们能够==控制套接字在应用层上的一切==。

对运输层的套接字的控制几乎是手足无措的，仅限于

1. 选择运输层协议
2. 设定几个运输层参数，如最大报文长度

进程寻址

一台主机上运行的进程如果想要向另一台主机上运行的进程发送分组，则需要让接收进程有一个地址。

为了让接收进程被标识到，我们需要两种信息：

1. 主机的地址
2. 在目的主机中指定接收进程的标识符

在因特网中，==主机是由IP地址标识的==。

除了IP地址标识外，还需要==发送进程指定运行在接收主机的接收进程==。端口号的作用就在于此。

可供应用程序使用的运输服务

在多种多样的运输服务中，我们可以通过四个方面对应用程序服务进行分类：==可靠数据传输，吞吐量，定时，安全性==

可靠数据传输

如何判断

某个服务能够做一些工作来确保某应用程序的一端发送的数据正确，且能完全地交付给该应用程序的另一端。

其他你可能要知道的

1. 运输层协议能够潜在地向应用程序提供一种重要服务，这种服务是进程到进程的可靠数据传输。发送进程只要将其数据传递进套接字，就可以完全相信该数据能够无差错地到达接收进程。
2. 如果运输层不提供这种服务，那大概率会被依赖这种服务的应用所排斥，但可能会被容忍丢失的应用接受，如一些多媒体应用，它的部分数据丢失一般只会导致卡顿或者音频被干扰等问题，但问题不大

应用

电子邮件，文件传输，金融应用等等

吞吐量

单位： 比特/秒 => bit/s

带宽敏感的应用（bandwidth-sensitive application）：对吞吐量有要求的应用程序。

弹性应用（elastic application）：说白了，能够根据带宽状态动态调整吞吐量。

因特网提供的运输服务

因特网为应用程序提供了两个运输层协议，分别为==UDP和TCP==。

附：应用程序的服务要求

TCP服务

TCP服务的模型包括：==面向连接服务和可靠数据传输服务==

有拥塞控制机制

UDP服务

UDP仅提供最小的服务，是无连接的，因此在进行连接的时候没有握手过程，且并不能保证报文能到达接收进程，到了也有可能是乱序的

没有拥塞控制机制（不过有的时候，实际的端到端吞吐量可能小于选定的任意速率，因为中间链路的带宽可能会受限或者拥塞导致的）

因特网不提供的服务

运输层协议不提供吞吐量和定时保证的服务

下图是因特网应用所使用的协议

应用层协议

定义了运行在不同端系统上的应用程序进程如何相互传递报文。

1. 交换的报文类型，例如请求报文，响应报文
2. 各种类型报文的语法，例如报文中的字段和字段的描述
3. 字段的语义，即这些字段的信息的含义
4. 确定一个进程什么时候，怎么发送报文，对报文响应的规则

这一章涉及到的网络应用

Web、文件传输、电子邮件、目录服务、流式视频和P2P

Web和HTTP

HTTP概况

==超文本运输协议（HyperText Transfer Protocol, HTTP）==由客户程序和服务器程序实现，它们通过交换HTTP报文进行会话。同时，HTTP定义了==这些报文的结构以及客户和服务器进行报文交换的方式==。

==Web页面（Web page，也叫文档）由对象组成==，而对象只是一个文件，例如HTML文件，JPEG图形等等。其中，大多数Web页面都会含有一个HTML文件和几个引用对象，其对象数量就是引用对象的数量加上HTML文件数（说白了就是N+1个对象）

==Web服务器==实现了HTTP的客户端（所以在Web环境中经常会交替使用”浏览器“和”客户“两种术语），也实现了HTTP的服务器端（用于存储Web对象，每个对象由URL寻址）

:::info

HTML基本文件是通过对象的URL地址来引用页面的其他对象，形如http://www.example.com/path/to/sth都是URL地址，其中www.example.com是主机名，而/path/to/sth是路径名

:::

HTTP定义了Web客户向Web服务器请求Web页面的方式，以及服务器向客户传送Web页面的方式，基本思想如下图：

1. 用户请求一个Web页面；
2. 浏览器向服务器发出该页面中所包含对象的HTTP请求报文；
3. 服务器接收请求并用包含这些对象的HTTP响应报文进行相应

无状态协议

HTTP服务器不保存关于用户的任何信息，这里涉及到一个关于HTTP的现象：==服务器向客户发送被请求的文件，但是不存储任何关于用户的状态信息==。

:::info

Web使用的是客户-服务器应用程序体系架构，其实看了图示也差不多可以想到了

:::

非持续链接和持续链接

非持续连接（non-persistent connection）

==每一个请求/响应对经过一个单独的TCP连接发送==。

假设URL为http://www.example.com/path/to/sth，且其中包含一个HTML文件和N个JPEG图形文件，我们来看看服务端向客户传送一个Web页面的步骤：

1. HTTP客户进程在默认端口号80发起一个到服务器http://www.example.com的TCP连接，在客户与服务器上分别有一个套接字与该连接相关联；
2. HTTP客户经过自己的套接字向服务器发送一个HTTP请求报文，请求报文中包含了路径名/path/to/sth；
3. HTTP服务器进程经过自己的套接字接收该请求报文，从自己的存储器中检索对象http://www.example.com/path/to/sth，并将其封装到一个HTTP响应报文中；
4. HTTP服务器进程通知TCP断开TCP连接。（当然了，要等TCP确认客户已经收到完整的响应报文后，它才会断开连接）；
5. HTTP客户接收响应报文，TCP连接关闭。报文指出封装对象是一个HTML文件，客户从报文提取该文件，检查HTML文件后得到N个JPEG图形文件；
6. 对每一个引用的JPEG图形对象重复前4个步骤。

经过上述步骤，用户在请求该Web页面时，需要产生N+1个TCP连接

:::info 估算从请求到完全接收的时间

往返时间（RTT，Round-Trip Time）：指一个短分组从客户到服务器然后再返回客户所花费的时间

RTT包括分组传播时延、分组在中间路由器和交换机上的排队时延和分组处理时延。

（涉及到三次握手，这个后面再说）

1. 客户请求Web页面时，会先请求建立一个TCP连接。客户向服务器发送一个TCP报文段，服务器再向客户发送一个TCP报文段来作出请求与回应；（占用一个RTT）
2. 客户发送一个HTTP请求报文，报文到达服务器后，服务器就会发送响应报文（占用一个RTT）
3. 后面传输文件的事情就另算了

因此总的时间是2RTT + 传输文件的时间

:::

持续连接（persistent connection）

==所有的请求/响应对经过相同的TCP连接发送==。

相对地，在这个方式下，服务器在发送响应后并不会通知TCP关闭连接，而是保持打开状态，因此后续的请求和响应报文能通过相同的连接进行传送。

说白了，按照上一个连接的例子，需要用到的TCP连接数就会从N+1个变成1个

:::warning no-icon

非持续连接的缺点：

1. 该方式下，两端需要为每一个请求的对象建立和维护一个全新的连接；
2. 时间占用太多，每一个对象需要花费两倍RTT来创建TCP连接和请求接收。

:::

HTTP报文格式

请求报文

拿书上的例子说说：

第一行为请求行（request line），后面的全部为首部行（header line）。

上图可以看出，请求行有三个部分：方法字段、URL字段和HTTP版本字段。其中，请求方法有很多：==GET、POST、DELETE、PUT、HEAD==。

再来看看首部行：

1. Host：指明对象所在的主机；
2. Connection：close代表非持续连接，open代表持续连接（我记得是open吧）；
3. User-Agent：指明用户代理，也相当于指明发送请求的浏览器的类型；
4. Accept-language：表示用户想得到该对象的语言版本，服务器不存在这样的对象就发送默认语言版本

下图是请求报文的通用格式：

响应报文

接着拿书上的例子

响应报文有三个部分：一个初始状态行（status line），若干个首部行（header line），实体体（entity body）

状态行包含三个信息：协议版本字段，状态码，状态信息

首部行：

1. Connection：不赘述；
2. Date：服务器产生并发送报文的时间；
3. Server：表示报文是由某个服务器产生的；
4. Last-Modified：对象创建或者最后修改的日期和时间（这个后面再说）；
5. Content-Length：被发送对象中的字节数（应该是指实体体）；
6. Content-Type：指示实体体中的对象是什么类型的文本

实体体包含了请求的对象本身（data data data……）

状态码有点不想说，我直接把官方的文档放这了 -> click me

用户与服务器的交互：cookie

cookie==允许站点对用户进行追踪==。

至于有什么用，举个例子：我访问github.com，但我想访问之后直接到与我有关的界面，这样就可以省去登录步骤，这个时候cookie就发挥了作用，它会保持我在这个网站的登录状态，以防一些不必要的登录。

不过呢，不同的浏览器cookie肯定是不同的，例如火狐登录了csdn，之后就可以省去登录步骤；IE没有登陆过，必须要登录

当然，咱之前玩的小游戏有需要存档的，也用到了cookie

下图表示cookie跟踪用户的状态

根据上图可以得知，cookie技术有四个组件：

1. HTTP响应报文的一个cookie首部行；
2. HTTP请求报文的一个cookie首部行；
3. 用户端系统中保留有一个cookie文件，由用户的浏览器管理；
4. Web站点的一个后端数据库

:::info

cookie可以标识一个用户。用户首次访问某个站点时可能需要提供一个用户标识（例如名字），在后面的对话中，浏览器会向服务器传递一个cookie首部，从而向服务器标识了这个用户。

因此，cookie可以在无状态HTTP之上建立一个会话层。

:::

Web缓存

Web缓存器（Web cache）也叫代理服务器（proxy server），它是能够代表初始Web服务器来满足HTTP请求的网络空间实体。

其中，Web缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。

还是拿书上的例子，看下图：

现在客户配置的浏览器都可以使他们的HTTP请求首先指向Web缓存器，以http://www.example.com/path/to/sth为例，现在浏览器正在请求该对象，来看看都发生了什么：

1. 浏览器创建了一个到Web缓存器的TCP连接，并向Web缓存器中的对象发送一个HTTP请求；
2. Web缓存器接收请求，并检查是否存在该对象的副本。如果有，Web缓存器就返回包含该对象的HTTP响应报文，没有就进行下一步；
3. Web缓存器打开一个与该对象的初始服务器（www.example.com）的TCP连接，然后在这个连接上发送一个关于该对象的HTTP请求。收到请求后，初始服务器向Web缓存器发送包含该对象的HTTP响应；
4. Web缓存器接收到该对象后，它在本地存储空间存储一份副本，并向客户的浏览器发送该副本的HTTP响应报文。

:::danger no-icon

在上述步骤中，Web缓存器既是客户，也是服务器。

:::

条件GET方法

和普通的GET方法有点区别，条件GET方法（conditional GET）在原先GET方法的基础上加了一个功能：==检查该对象是否是最新的==

如果一个请求报文中用到了GET方法，并且该报文的首部行还有包含If-Modified-Since，那么这个HTTP请求报文就是一个条件GET请求报文。

拿书上的例子简单举例，这个倒并不是很重要：

某个代理缓存器代表某个浏览器向某个Web服务器发送了一个请求报文

然后，Web服务器发送了包含该对象的HTTP响应报文

可以看出，缓存器接收了报文，也在本地存储了这个对象，同时也存储了该对象的最后修改日期。

一段时间后，另一个用户向这个缓存器请求同一个对象，由于该对象可能已经被修改，因此在用户请求后，该缓存器会向服务器发送一个条件GET请求来进行检查：

如果该对象没有修改，那么服务器就会向缓存器发送如下响应报文：

报文说明对象没有修改，缓存器可以使用这个对象，最后缓存器把这个对象的副本发送给用户

因特网中的电子邮件

这个简单说说就行，感觉不太重要

先上一个因特网电子邮件系统的总体概况图：

可以看到，电子邮件分为三个主要部分：==用户代理（user agent），邮件服务器（mail server），简单邮件传输协议（Simple Mail Transfer Protocol，SMTP）==。

SMTP

==SMTP是因特网电子邮件中的主要协议==。它使用TCP可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件。

跟许多应用层协议一样，SMTP也有两个部分：运行在发送方邮件服务器的客户端，运行在接收方服务器的服务器端。

上一个发送端向接收端发送一个邮件的过程图：

1. Alice调用邮件代理程序并提供Bob的邮件地址，撰写报文后指示代理发送报文；
2. Alice用户代理发送报文到她的邮件服务器，报文被放在报文队列当中；
3. Alice的邮件服务器的SMTP客户端发现了报文队列中的这个报文，于是就创建一个到Bob的邮件服务器的SMTP服务器的TCP连接；
4. 经过初始的SMTP握手之后，SMTP客户通过该TCP连接发送Alice的报文；
5. Bob的邮件服务器上的SMTP的服务器接收该报文，然后该邮件服务器将报文放入Bob的邮箱中；
6. Bob调用用户代理阅读报文

:::info

几个注意的点：

1. SMTP一般不使用中间邮件服务器发送邮件；
2. 接收端的邮件服务器在没有运行的情况下，发送报文会被保留在发送端并等待进行新的尝试，不会在中间的服务器做停留。

:::

与HTTP的对比

相同点

1. HTTP和SMTP都是用于从一台主机向另一台主机传送文件；
2. 持续的HTTP和SMTP都使用持续连接（感觉像是废话……）

不同点

1. HTTP用于从Web服务器向Web客户（例如浏览器）传送对象（例如文件），而SMTP用于从一个邮件服务器向另一个邮件服务器传送文件；
2. HTTP主要是一种拉协议（pull protocol），在方便的时候，用户可以使用HTTP从某个Web服务器拉取一些被装载的信息；SMTP主要是一种推协议（push protocol），发送邮件的服务器把文件推向接收邮件的服务器，当二者需要建立TCP连接时，发送邮件的服务器必须为建立连接的发起者。
3. SMTP要求每个报文采用7比特ASCII码格式，HTTP则不受限制；
4. 在处理包含文本和图形的文档时，HTTP将每个对象封装到对应的不同响应报文中（就是一对一封装），SMTP将所有的对象放在一个报文中。

邮件报文格式

不赘述，看看图就行

From和To是必须要有的

后面可能只有一个Subject首部行，也可能有其他多个可选的首部行

邮件访问协议

目前流行的邮件访问协议：第三版邮局协议（Post Office Protocol–Version 3，POP3），因特网邮件访问协议（Internet Mail Access Protocol，IMAP），HTTP

DNS：因特网的目录服务

DNS提供的服务

主机识别有两种方式：主机名和IP地址。用户一般偏好主机名，而路由器则偏好IP地址。为了折中两种不同的偏好，域名系统应运而生。

域名系统（Domain Name System，DNS）：==一个由分层的DNS服务器实现的分布式数据库和一个使得主机能够查询分布式数据库的应用层协议。==DNS协议运行在UDP之上，使用53端口

以http://www.example.com/path/to/sth举例，看看用户主机如何获取URL的IP地址：

1. 某台用户主机上运行着DNS应用的客户端；
2. 浏览器从该URL抽出主机名www.example.com，并将其传递给DNS应用的客户端；
3. DNS客户向DNS服务器发送一个包含主机名的请求；
4. DNS客户最终收到一份回答报文，报文包含对应于主机名的IP地址；
5. 浏览器在接收到来自DNS的IP地址后，就向位于该IP地址80端口的HTTP服务器进程发起一个TCP连接

除了进行主机名向IP地址转换外，DNS还提供其他一些重要服务：

主机别名（host aliasing）

有的主机名长且复杂，原先的主机名叫规范主机名（canonical hostname）。为了方便记忆，这些主机都会有一个或多个主机别名。应用程序可以调用DNS来获得主机别名、对应的规范主机名和IP地址

邮件服务器别名（mail server aliasing）

跟主机别名差不多，不赘述。

负载分配（load distribution）

此时的DNS用于冗余的服务器之间的负载分配。某个繁忙的站点被分布在多台服务器上，每台服务器运行在不同的端系统上，每个端系统都有不同的IP地址。这些冗余的服务器让一个IP地址集合与同一个规范主机名相联系，同时DNS数据库存储着这些IP地址的集合，因此当客户对映射到某地址集合的名字发出DNS请求，该服务器就用IP地址的整个集合进行响应，不过不同IP之间在响应时是有顺序的。

DNS工作机理概述

这里就简单点说：

1. 用户主机的某应用程序需要将主机名转换为IP地址，调用DNS客户端，并指明需要被转换的主机名；
2. 用户主机的DNS接收后向网络发送一个DNS查询报文；
3. 经过一段时延后，用户主机上的DNS接收到一个提供希望映射的DNS回答报文；
4. 映射结果传递到调用DNS的应用程序

:::warning

所有的DNS请求和回答报文使用UDP数据报经过端口53发送

:::

DNS的分布式设计

单一的DNS服务器虽然简单，但是出现的问题很多，包括但不限于：

1. 单点故障（a single point of failure）：如果这个DNS服务器崩溃，那么整个因特网就会崩溃；
2. 通信容量（traffic volumn）：单个DNS服务器处理上亿个DNS查询显然不够；
3. 远距离的集中式数据库（distant centralized database）：单个DNS服务器是不可能位于所有用户的附近，若距离较远的用户向DNS服务器发送请求，那么可能会因为拥塞和低速的链路而导致很大的时延；
4. 维护（maintenance）：单个DNS服务必须要保留所有的因特网主机的记录，不仅会使数据库庞大，还需要为新主机的加入频繁更新。

因此，DNS的分布式设计应运而生。

分布式、层次数据库

为了解决扩展性问题，DNS使用了大量的DNS服务器，以层次方式组织，并且分布在全世界范围内。

这种方式一般有3种DNS服务器：==根DNS服务器，顶级域（Top-Level Domain，TLD）DNS服务器，权威DNS服务器。==

下图为部分DNS服务器的层次结构：

除了以上服务器之外，还有一类重要的DNS服务器称为本地DNS服务器（local DNS server），虽然它不属于层次结构里面的任何服务器，但是对层次结构十分重要。

一台主机如何得知另一台主机的IP地址呢？

举个例子：（请求主机设为A，目标主机设为B）

1. 主机A向它的本地DNS服务器发送一个DNS查询报文，报文包含了被转换的主机名B；
2. 本地DNS服务器将报文转发给根DNS服务器；
3. 根DNS服务器注意到主机A的edu前缀，然后向本地DNS服务器返回负责edu的TLD的IP地址列表；
4. 本地DNS服务器再次向指定的TLD服务器之一发送报文；
5. TLD服务器注意到umass.edu的前缀，用权威DNS服务器的IP地址进行响应；
6. 本地DNS服务器向权威DNS服务器重新发送报文；
7. 权威DNS服务器用主机B的IP地址进行响应；
8. 本地DNS服务器返回给主机A。

这个步骤中总共发送了8篇报文。

:::info

上述例子利用了递归查询（recursive query）和迭代查询（iterative query）。

从主机到本地DNS服务器是递归查询，其余的均为迭代查询，因为所有的响应都是返回给本地DNS服务器的。

递归查询的例子如下图：

这是不是就相当于之前学的递归呢，例如斐波那契额数列，调用函数本身，最终的结果是函数本身返回的值。

:::

DNS缓存

相当于在本地DNS服务器添加了一个DNS缓存器，用于存储每一个接收到的回答，可以绕过根服务器，便于请求主机在请求相同的地址时可以直接返回该IP地址，节省了时间，也节省了资源。

DNS记录和报文

资源记录（Resource Record，RR）

资源记录提供了主机名到IP地址的映射。每一个DNS回答报文包含了一条或多条资源记录。

资源记录包含了以下四元组：==（Name，Value，Type，TTL）==

TTL是记录的生存时间，它决定了资源记录应当从缓存中删除的时间。Name和Value取决于Type：

1. Type=A，则Name就是主机名，Value就是主机名对应的IP地址；
2. Type=NS，则Name就是域名（如example.com），Value就是权威DNS服务器的主机名（如dns.example.com）；
3. Type=CNAME，则Name就是域名，Value是与之对应的规范主机名；
4. Type=MX，则Name就是域名，Value是与之对应的邮件服务器的规范主机名

DNS报文

以下是DNS报文格式：

先说说前12个字节首部区域：

1. 标识符是16比特的数，用于标识该查询。该标识符会被复制到对应的回答报文中，以便匹配发送的请求和收到的回答；
2. 标志字段有若干个标志，1比特的”查询/回答“标志位指出报文是查询（0）还是回答（1）；当请求的是权威DNS服务器时，1比特的”权威“标志位会置于回答报文中；
3. 如果客户在DNS服务器没有某记录时想要递归查询，那么报文就会设置1比特的“希望标志”位；
4. 如果DNS服务器支持递归查询，那么回答报文中把1比特的“递归可用”标志位进行置位；
5. 另外四个有关数量的字段，则指出了在首部后的4类数据区域出现的数量

再说说后面的数据区域：

1. 问题区域包含正在进行的查询信息，包括：（1）名字字段，包含正在被查询的主机名；（2）类型字段，指出有关该名字的正被询问的问题类型，例如是否与一个名字（A）或一个名字的邮件服务器（MX）相关联；
2. 回答区域包含了对最初请求的名字的资源记录（上面已经说过，不记得的可以去翻翻看）。在回答报文中的回答区域中可以包含多条RR，因此一个主机名能够有多个IP地址；
3. 权威区域包含了其他权威服务器的记录；
4. 附加区域包含了其他有帮助的记录。例如，一个MX请求的回答报文的回答区域包含了一条资源记录，该记录提供了邮件服务器的规范主机名。该附加区域包含一个类型A记录，该记录提供了用于该邮件服务器的规范主机名的IP地址。

:::info no-icon

nslookup程序能够做到让正在工作的主机直接向某些DNS服务器发送一个DNS查询报文。

:::

P2P文件分发

根据书上例子，假设服务器要将一个文件分发给一个固定的对等方集合，其中服务器与对等方使用接入链路与因特网相连，如下图所示

设u_s为服务器接入链路的上传速率，u_i表示第i个对等方接入链路的上传速率，d_i表示第i个对等方接入链路的下载速率，F表示被分发的文件长度（单位一般为bit），N表示对等方的数量，D_cs是客户-服务器体系结构的分发时间。

分发时间（distribution time）是所有N个对等方得到该文件的副本所需的时间。

为了排除影响，这里的环境假设为：因特网核心有足够的带宽（所以速率的瓶颈都在接入链路），服务器与客户没有参与任何其他网络应用（上传与下载的带宽能够全部用来发放该文件）

列出所求：

1. 由于服务器要传文件给N个对等方，因此上传文件的总量是NF bits，上传文件花费的总时间为NF / u_s；
2. 令d_min表示所有对等方中最小的下载速率，因此d_min = min{d₁,d₂,d₃,……,d_N}，这就导致有最小速率的对等方不能在F / d_min内获取一个完整的文件，因此分发时间至少为F / d_min；

因此可以得到：

​ ==D_cs >= max{NF / u_s,F / d_min}；==

不难看出，当N足够大时，客户-服务器分发时间就是由NF / u_s来决定的。

接下来看一下P2P体系结构，条件不变，列出所求：

1. 开始分发时，由于只有服务器有文件，因此服务器至少要上传该文件1次，因此分发时间至少为F / u_s（与前者有差别的是，服务器在分发一次文件后可以选择不用发送，因为该体系结构下可以通过其他对等方来分发该文件；
2. 跟前者一样的是，有最小速率的对等方不能在F / d_min内获取一个完整的文件，因此分发时间至少为F / d_min；
3. 在该体系结构下，系统整体的总上传能力等于服务器的上传速率加每个对等方的上传速率，即u_total = u₁ + u₂ + … + u_N;

综上，设D_P2P为P2P体系结构下的最小分发时间，得到

​ ==D_P2P = max{F / u_s,F / d_min,NF / (u_s + u_total)}==

下图是两个结构的分发时间的变化趋势