[Computer Network notes] Chapter 2 应用层

Chapter 2 应用层

---

2.1 应用层协议原理

2.1.1 网络应用程序体系结构

1. 应用程序体系结构(application architecture)由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序，常用的两种主流体系结构为：客户-服务器体系结构或对等(P2P)体系结构

2. 客户-服务器体系结构(client-server architecture)

   (1) 有一个总是打开的主机称为server，它服务于来自许多其他称为client的主机的请求

   (2) 配备大量主机的数据中心常被用于创建强大的虚拟服务器

3. **P2P体系结构(**P2P architecture)

   (1) 不依赖于数据中心的服务器，应用程序在间接连接的主机对之间使用直接通信，这些主机对被称为对等方

   (2) 自扩展性(self-scalability)

   (3) 面临挑战：ISP友好、安全性、激励

2.1.2 进程通信

1. 进程(process)是运行在端系统中的一个程序，在不同端系统上的进程通过跨越计算机网络交换报文(message)而相互通信

2. 客户和服务器进程

   (1) 在每对通信进程中，包含client和server。对于Web而言，浏览器是客户进程，Web服务器是服务器进程；对于P2P文件共享，下载文件的对等方为客户，上传文件的对等方为服务器

   (2) 客户和服务器进程定义：在给定的一对进程之间的通信会话场景中，发起通信（即在该会话开始时发起与其他进程的联系）的进程被标识为客户，在会话开始时等待联系的进程是服务器

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

   (1) 进程通过一个称为套接字(socket)的软件接口向网络发送报文和从网络接收报文

   (2) 套接字是同一台主机内应用层与运输层之间的接口，套接字也称为应用程序和网络之间的应用程序编程接口(Application Programming Interface, API)

4. 进程寻址

   (1) 主机由其IP地址(IP address)标识

   (2) 端口号(port number)指定运行在接收机上的接收进程，即接受套接字

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

可靠数据传输、吞吐量、定时和安全性

1. 可靠数据传输

   (1) 如果一个协议提供了确保数据正确、完全地交付地服务，就认为提供了可靠数据传输(reliable data transfer)

   (2) 容忍丢失的应用(loss-tolerant application)：多媒体应用，如交谈式音频/视频，能承受一定量的数据丢失

2. 吞吐量

   (1) 具有吞吐量要求的应用程序称为带宽敏感的应用(bandwidth-sensitive application)，如因特网电话

   (2) 弹性应用(elastic application)能够根据情况或多或少地利用可供使用的吞吐量，如文件传输

   (3) 运输层协议能够以某种特定的速率提供确保的可用吞吐量

3. 定时

   运输层协议能提供定时保证，如发送方注入进套接字中的每个bit到达接收方的套接字不迟于100ms

4. 安全性

   运输协议能提供安全性服务，如在发送主机中加密由发送进程传输的所有数据，并在接收主机中将数据交付给接收进程之前解密这些数据

2.1.4 因特网提供的运输服务

两个运输层协议：UDP和TCP

1. TCP服务：包括面向连接服务和可靠数据传输服务

   (1) 面向连接的服务：在应用层数据报文流动前，TCP让client和server交换运输层控制消息，并建立起TCP连接

   (2) 可靠数据传送服务

   (3) 拥塞控制机制，当发送方和接收方之间的网络出现拥塞时，会抑制发送进程

   (4) 安全套接字层(Secure Sockets Layer, SSL)：TCP没有提供加密机制，而SSL能在TCP功能基础上，提供安全性服务，包括加密、数据完整性和端点鉴别

2. UDP服务

   (1) 不提供不必要服务的轻量级运输协议，仅提供最小服务

   (2) UDP是无连接的，提供一种不可靠数据传送服务

   (3) UDP没有包括拥塞控制机制

3. 因特网运输协议所不提供的服务

   TCP提供可靠数据传输，SSL加强后TCP可提供安全性，但不提供吞吐量和定时服务

2.1.5 应用层协议

1. 应用层协议(application-layer protocol)定义了 运行在不同端系统上的应用程序进程如何相互传递报文，特别是应用层协议定义了：

   (1) 交换的报文类型，如请求报文和响应报文

   (2) 各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的

   (3) 字段的语义，即这些字段中包含的信息的含义

   (4) 一个进程何时以及如何发送报文，对报文进行响应的规则

2. 应用层协议是网络应用的一个重要部分

• 本书主要讨论的网络应用：Web、文件传输、电子邮件、目录服务和P2P

2.2 Web和HTTP

2.2.1 HTTP概况

1. 超文本传输协议(HyperText Transfer Protocol, HTTP)是Web的应用层协议

2. Web术语

   (1) Web页面(Web Page), 也叫文档，是由对象组成的

   (2) 一个对象(object)是一个文件，如HTML文件、JPEG图形、Java小程序或一个视频片段，且它们可通过一个URL地址寻址

   (3) 多数Web页面含有一个HTML基本文件以及几个引用对象

   (4) URL地址由存放对象的服务器主机名和对象的路径名组成

   (5) Web浏览器(Web browser)实现了HTTP的客户端；Web服务端(Web server)实现了HTTP的服务器端，用于存储Web对象

3. HTTP工作原理

   (1) HTTP使用TCP作为支撑运输协议。Web应用使用了客户-服务器应用程序体系结构。

   (2) HTTP定义了Web客户向Web服务器请求Web页面的方式，以及Web服务器向Web客户传送Web页面的方式
   (3) HTTP客户首先发起一个与服务器的TCP连接，一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP

   (4) 单用户请求一个Web页面时，浏览器向服务器发出对该页面中所包含对象的HTTP请求报文，服务器接收到请求并用包含这些对象的HTTP响应报文进行响应

   (5) HTTP是一个无状态协议(stateless protocol)。HTTP服务器并不保存关于客户的任何信息

2.2.2 非持续连接和持续连接

1. 每个请求/响应对是经一个单独的TCP连接发送，为非持续连接(non-persisitent connection)

   所有的请求及其响应经相同的TCP连接发送，为持续连接(persisitent conncetion)

   HTTP支持非持续连接和持续连接，默认方式为持续连接

2. 采用非持续连接的HTTP

   (1) 每个TCP连接在服务器发送一个对象后关闭

   (2) 可使用并行的TCP连接，以缩短响应时间

   (3) 往返时间(Round-Trip Time, RTT)：一个短分组从客户到服务器然后再返回客户所花费的时间。RTT包含分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延

   (4) 三次握手

   客户向服务器发送一个小TCP报文段，服务器用一个小TCP报文段作出确认和响应，最后客户向服务器返回确认，并结合该确认向TCP连接发送一个HTTP请求报文，一旦该请求报文到达服务器，服务器就在该TCP连接上发送HTML文件。
   
   请求并接收一个HTML文件所需时间=2×RTT+服务器传输HTML文件的时间(粗略)

3. 采用持续连接的HTTP

   (1) 非持续连接的缺点

   1) 必须为每一个请求的对象建立和维护一个全新的连接，对于每个这样的连接，在客户和服务器种都要分配TCP的缓冲区和保持TCP变量，这给Web服务器带来了严重的负担

   2) 每一个对象经受两倍RTT的交付时延，即一个RTT用于创建TCP，另一个RTT用于请求和接收一个对象

   (2) 采用持续连接时，一个完整的Web页面（如HTML基本文件加上多个图形）可用单个持续TCP连接进行传送，位于同一台服务器的多个Web页面发送给同一个客户时，也可在单个持续TCP连接上进行

   (3) 一条连接经过一定时间间隔仍未被使用，HTTP服务器就关闭该连接

2.2.3 HTTP报文格式

两种HTTP报文：请求报文和响应报文

1. HTTP请求报文

GET /somedir/page.html HTTP/1.1

Host: www.someschool.edu

Connection: close

User-agent: Mozilla/5.0

Accept-language: fr

​ (1) HTTP请求报文的首行为请求行(request line)，包括方法字段、URL字段和HTTP版本字段

​ 方法字段包含GET、POST、HEAD、PUT和DELETE

​ (2) 后继的行叫做首部行(header line)

​ Host: www.someschool.edu指明了对象所在的主机

​ Connection: close表示不适用持续连接

​ User-agent: Mozilla/5.0指明用户代理，即向服务器发送请求的浏览器的类型

​ Accept-language: fr用户想得到该对象的语言版本（没有则发送器默认版本）

​ (3) 请求报文的通用格式

​ (4) 请求行方法字段

​ 1) 实体主体(entity body)，在使用GET方法时为空，在使用POST方法时使用实体主体

​ 2) 用户提交表单时，HTTP客户常使用POST方法，但也可使用GET方法，如?monkeys&bananas

​ 3) HEAD方法类似于GET方法，服务器使用HTTP报文响应，但并不返回请求对象

​ 4) PUT方法允许用户上传对象到指定的Web服务器上的指定路径

​ 5) DELETE方法允许用户删除Web服务器上的对象

2. HTTP响应报文

HTTP/1.1 200 OK //状态行，包含协议版本字段、状态码和相应状态信息

Connection: close //首部行，非持续连接

Date: Tue, 09 Aug 2011 15:44:04 GMT //服务器产生并发送响应报文的日期和时间

Server: Apache/2.2.3 (centOS) //报文是由一台Apache Web服务器产生的

Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT //对象创建或最后修改的日期和时间

Content-Length: 6821 //被发送对象中的字节数

Content-Type: text/html //实体体中的对象类型为HTML文本

(data data data data data …

​ (1) 响应报文的三个部分：1个初始状态行(status line)，6个首部行(header line)，实体体(entitiy body)

​ (2) 响应报文的通用格式​

​ (3) 状态码及对应短语

​ 200 OK：请求成功

​ 301 Moved Permanently：请求对象被永久转移，新的URL定义在响应报文的Location：首部行中

​ 400 Bad Request：通用差错代码

​ 404 Not Found：请求的文档不在服务器上

​ 505 HTTP Version Not Support：服务器不支持请求报文使用的HTTP协议版本

2.2.4 用户与服务器的交互: cookie

1. cookie技术的4个组件

   (1) HTTP响应报文中的cookie首部行

   (2) HTTP请求报文中的cookie首部行

   (3) 用户端系统中保留的cookie文件，由用户的浏览器进行管理

   (4) 位于Web站点的一个后端数据库

2. cookie跟踪用户状态
   

   (1) 请求报文首次到达Web服务器时，该Web站点产生一个唯一标识码(1678)，并以此为索引在其后端数据库中产生一个表项

   (2) Web服务器用一个包含首部行Set-cookie: 1678的HTTP响应报文进行响应

   (3) 浏览器收到响应报文，在其管理的cookie文件中添加一行，包含服务器的主机名和标识码，如Amazon:1678

   (4) 用户继续浏览该网站时，每请求一个Web页面，浏览器便会从cookie文件中获取对此网站的标识码，并放到HTTP请求报文的首部行中Cookie:1678

2.2.5 Web缓存

1. Web缓存器(Web cache)也叫代理服务器(proxy server)

   (1) 能够代表初始Web服务器满足HTTP请求的网络实体

   (2) 有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本

2. 工作原理

   (1) 浏览器建立一个到Web缓存器的TCP连接，向Web缓存器中的对象发送一个HTTP请求

   (2) Web缓存器检查本地是否存储了该对象副本，有则向客户浏览器用HTTP响应报文返回该对象

   (3) 如果Web缓存器没有该对象，建立与该对象的初始服务器的TCP连接，并发送HTTP请求

   (4) Web缓存器收到初始服务器返回的对象，在本地存储空间存储一份副本，并向客户浏览器用HTTP响应报文发送该副本

回顾：流量强度(traffic intensity)为 $\frac{La}{R}$

3. 通过使用内容分发网络(Content Distribution Network, CDN)，Web缓存器正起着越来越重要的作用

2.2.6 条件GET方法

1. 条件GET(conditional GET)方法：允许Web缓存器验证其对象是最新的HTTP协议机制

2. 条件GET请求报文

   (1) 请求报文使用GET方法

   (2) 请求报文中包含一个If-Modified-Since:首部行

3. example

   //缓存器发送条件GET执行最新检查
   GET /fruit/kiwi.gif HTTP/1.1
   HOST: www.exotiquecuisine.com
   If-Modified-Since: Wed, 7 Sep 2011 09:23:24
   

   //Web服务器向该缓存器发送一个响应报文
   HTTP/1.1 304 Not Modified
   Date: Sat, 15 Oct 2011 15:39:29
   Server: Apache/1.3.0
   
   (empty entity body)
   

   作为对条件GET方法的响应，Web服务器发送一个响应报文，但不包含所请求的对象，而是告诉缓存器可以使用该对象

2.3 文件传输协议：FTP

1. 过程
   
   用户提供远程主机的主机名，使本地主机的FTP客户进程建立一个到远程主机FTP服务器进程的TCP连接，接着提供用户标识和口令，作为FTP命令的一部分在该TCP连接上传送，服务器向用户授权后，用户可将存放在本地文件系统的一个或多个文件复制到远程文件系统，或从远程文件系统复制一个或多个文件到本地文件系统

2. FTP和HTTP的异同

   (1) 均为文件传输协议，都运行在TCP上

   (2) TCP使用两个并行的TCP连接传输文件，一个是控制连接(control connection)，一个是数据连接(data connection)

   1) 控制连接用于在两主机之间传输控制信息，如用户标识、口令、存放(put)、获取(get)文件的命令

   2) 数据连接用于实际发送一个文件

   3) FTP的控制信息是带外(out-of-band)传送的，HTTP是**带内(**in-band)发送控制信息的

   4) 对于FTP传输，控制连接贯穿了整个用户会话期间，而每一次文件传输都需要建立一个新的数据连接，数据连接是非持续的

   (3) FTP服务器必须在整个会话期间保留用户的状态(state)，特别是要追踪用户在远程目录树上的当前位置，而HTTP是无状态的

3. FTP命令和回答

   (1) 从客户到服务器的命令和从服务器到客户的回答，都是以7bit ASCII格式在控制连接上传送的

   (2) 常用命令：4个大写字母后跟可选参数

   - USER username：用于向服务器传送用户标识
   - PASS password：用于向服务器发送用户口令
   - LIST：用于请求服务器回送当前远程目录中的所有文件列表，该文件列表经一个新建数据连接传送
   - RETR filename：从服务器当前目录检索(get)文件，该命令引起远程主机发起数据连接并发送所请求的文件
   - STOR filename：用于在远程主机当前目录上存放(put)文件

   (3) 常用回答：3位的数字后跟可选信息

   - 331 Username OK, Password required
   - 125 Data connection already open; transfer starting
   - 425 Can’t open data connection
   - 452 Error writing file

2.4 因特网中的电子邮件

1. 电子邮件系统由用户代理(user agent)、邮件服务器(mail server)和简单邮件传输协议(Simple Mail Transfer Protocol, SMTP)组成。

2. 邮件发送过程：发送方的用户代理传输邮件到发送方的邮件服务器，再传输到接收方的邮件服务器，再分发到接收方的邮箱(mailbox)中

3. 若发送方的邮件服务器不能将邮件交付给接收方的邮件服务器，则在一个报文队列(message queue)中保持该报文并在以后尝试再次发送

2.4.1 SMTP

1. SMTP工作原理

   (1) 发送方通过用户代理撰写报文，提供接收方的邮件地址，指示用户代理发送该报文

   (2) 发送方用户代理将报文发给邮件服务器，报文被放在报文队列中

   (3) 发送方邮件服务器上的SMTP客户端发现报文队列中的报文，创建一个到运行在接收方的邮件服务器上的SMTP服务器的TCP连接

   (4) SMTP握手，SMTP客户端通过TCP向SMTP服务器发送报文

   (5) 接收方的邮件服务器上的SMTP服务器接受该报文，将该报文放入接收方的邮箱中

   (6) 接收方调用用户代理阅读报文

2. SMTP命令：通过telnet与SMTP服务器进行对话

2.4.2 与HTTP的对比

1. 相同点：TCP连接，持续连接，客户-服务端体系结构

2. 区别

   (1) HTTP是一个拉协议(pull protocol)，TCP连接是由想接收文件的极其发起的

   ​ SMTP是一个推协议(push protocol)，TCP连接是由要发送该文件的机器发起的

   (2) SMTP要求每个报文使用7bitASCII码格式，二进制数据(如图形文件)必须按照7bitASCII码格式进行编码，HTTP没有该限制

   (3) 处理一个既包含文本又包含图形或其他媒体类型的文档时，HTTP把每个对象封装到各自的HTTP响应报文中，SMTP则把所有报文对象放在一个报文之中

2.4.3 邮件报文格式和MIME

1. 邮件报文格式

   包含环境信息的首部(多个首部行)

   报文体

2. 每个首部必须含有一个From: 首部行和一个To: 首部行

   From: [email protected]

   To: [email protected]

   Subject: Searching for the meaning of life.

2.4.4 邮件访问协议

1. 接收方通过其用户代理获取其邮件服务器上的报文时，不能使用SMTP，因为取报文是一个拉操作，而SMTP是一个推协议

2. 常用的邮件访问协议：第三版邮局协议(Post Office Protocol-Version3, POP3)，因特网邮件访问协议(Internet Mail Access Protocol, IMAP)以及HTTP

3. POP3：特许、事务处理和更新

   (1) 特许(authorization)阶段，用户代理发送用户名和口令以鉴别用户

   用户代理打开到邮件服务器端口110上的TCP连接

   用户指令：user 、pass

   (2) 事务处理阶段，用户代理取回报文，对报文做删除标记或取消删除标记等

   用户指令：list、retr、dele、quit

   服务器回答: +OK、-ERR

   (3) 更新阶段：客户发出quit命令结束POP3绘画后，邮件服务器删除标记为删除的报文

   下载并删除

   下载并保留：用户代理下载邮件后，邮件服务器仍保留该报文

4. IMAP：用户可创建远程文件夹或为报文指派文件夹

   (1) IMAP服务器把每个报文与一个文件夹联系起来

   (2) IMAP协议为用户提供了创建文件夹，将邮件从一个文件夹移动到另一个文件夹的命令，在远程文件夹中查询邮件的命令

5. 基于Web的电子邮件

   (1) 用户代理是普通的浏览器

   (2) 收件人访问邮件使用HTTP协议，发送方将报文发送到邮件服务器使用HTTP协议

   (3) 发送方邮件服务器到接收方邮件服务器之间收发邮件，仍使用SMTP

2.5 DNS：因特网的目录服务

主机的两种识别方式：主机名(人们)、IP地址(路由器)

2.5.1 DNS提供的服务

1. 域名系统(Domain Name System, DNS)：能进行主机名到IP地址转换的目录服务

   (1) 一个由分层的DNS服务器(DNS server)实现的分布式数据库

   (2) 一个使得主机能够查询分布式数据库的应用层协议

   (3) DNS协议运行在UDP之上，使用53号端口

2. 主机名到IP地址转换服务过程

   (1) 用户主机上运行着DNS应用的客户端

   (2) 请求页面时，浏览器从URL中抽取主机名，传给DNS应用的客户端

   (3) DNS客户向DNS服务器发送一个包含该主机名的请求

   (4) DNS客户收到回答报文，包含对应于该主机名的IP地址

   (5) 浏览器接收到来自DNS的该IP地址后，能够向位于该IP地址80端口的HTTP服务器进程发起TCP连接

3. 其他服务

   (1) 主机别名(host aliasing)，主机可以有1个规范主机名(canonical hostname)和多个主机别名，应用程序可调用DNS来获得主机别名对应的规范主机名以及主机的IP地址

   (2) 邮件服务器别名(mail server aliasing)，电子邮件应用程序可调用DNS获取邮件服务器别名对应的规范主机名及IP地址

   (3) 负载分配(load distribution)，DNS用于在冗余的服务器之间进行负载分配。一个站点被冗余地分布在多台服务器，其IP地址集合与同一个规范主机名相联系。

2.5.2 DNS工作机理概述

1. 单一DNS服务器的问题

   (1) 单点故障(a single point of failure)

   (2) 通信容量(traffic volume)

   (3) 远距离的集中式数据库(distant centralized database)，导致严重的时延

   (4) 维护(maintenance)，中央数据库非常庞大， 必须为解决每个新添加的主机而频繁更新

2. 分布式、层次数据库
   (1) 3种类型的DNS服务器

   1) 根DNS服务器，因特网上有13个根DNS服务器，每个服务器均为冗余配置

   2) 顶级域DNS服务器 (顶级域, Top-Level Domain, TLD)，负责顶级域名如com、org、net、edu、gov，以及所有国家的顶级域名如uk、fr、jp等

   3) 权威DNS服务器，具有公共可访问主机 (如Web服务器和邮件服务器) 的组织提供公共可访问的DNS记录，将主机名映射为IP地址，该DNS记录保存在权威DNS服务商

   4) 访问www.amazon.com的IP地址时，客户首先与根服务器之一联系，获得顶级域名com的TLD服务器的IP地址，然后与TLD服务器联系，获得amazon.com的权威服务器的IP地址，最后于amazon.com权威服务器联系，返回主机名为www.amazon.com的IP地址

   (2) 本地DNS服务器

   本地DNS服务器(local DNS server)，不属于DNS服务器的层次结构。请求主机首先向本地DNS服务器发送一个包含目的主机名的DNS查询报文，本地DNS服务器依次向根DNS服务器、TLD DNS服务器、(中间服务器)、权威DNS服务器发送查询报文，然后获得目的主机的IP地址并发送给请求主机

   (3) 递归查询(recursive query)与迭代查询(iterative query)

   一般从请求主机到本地DNS服务器的查询是递归查询，其余为迭代查询

3. DNS缓存(DNS caching)

   (1) 在一个请求链中，当某DNS服务器接收一个DNS回答(如包含主机名到IP地址的映射)时，将其该主机名/IP地址对缓存在本地存储器中

   (2) 当另一个对相同主机名的查询到达该DNS服务器时，直接提供所要求的IP地址

   (3) 主机名与IP地址的映射不是永久的，DNS服务器在一段时间后将丢弃缓存的信息

2.5.3 DNS记录和报文

1. 共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(Resource Record, RR)

2. 资源记录：(Name, Value, Type, TTL)

   (1) TTL为记录的生存时间，决定了资源记录应当从DNS缓存中删除的时间

   (2) 若Type=A，则Name为主机名，Value为对应的IP地址

   ​ 若Type=NS，则Name是域名，Value是知道如何获取该域中主机IP地址的权威DNS服务器的主机名

   ​ 若Type=CNAME，则Value是别名为Name的主机对应的规范主机名

   ​ 若Type=MX，则Value是别名为Name的邮件服务器的规范主机名

   通过使用MX记录，一个公司的邮件服务器和Web服务器可使用相同的别名，获取Web服务器规范主机名时请求MX记录，获取邮件服务器规范主机名时请求CNAME记录

3. DNS报文：DNS查询报文和DNS回答报文
   (1) 首部区域：前12个字节

   (2) 问题区域：名字字段支出被查询的主机名字，类型字段(A\NS\CNAME\MX)

   (3) 回答区域：包含对最初请求的名字的资源记录，可包含多条RR

   (4) 权威区域：包含了其他权威服务器的记录

   (5) 附加区域

• cmd运行nslookup程序可向DNS服务器发送DNS查询报文

4. 在DNS数据库中插入记录

   (1) 在**注册登记机构(registrar)**注册公司网站的域名，向该机构提供权威DNS服务器的名字和IP地址

   (2) 注册登记机构确保将一个类型NS和一个类型A的记录输入TLD DNS服务器

   (networkutopia.com, dns1.networkutopia.com, NS)

   (dns1.networkutopia.com, 212.212.212.1, A)

2.6 P2P应用

2.6.1 P2P文件分发

1. P2P体系结构的扩展性

   (1) 客户-服务器体系结构分发时间(distribution time)
   $D_{\mathrm{cs}} \geqslant \max \left\{\frac{N F}{u_{s}}, \frac{F}{d_{\min }}\right\}$
   (2) P2P体系
   $D_{\mathrm{P} 2 \mathrm{P}} \geqslant \max \left\{\frac{F}{u_{s}}, \frac{F}{d_{\min }}, \frac{N F}{u_{s}+\sum_{i=1}^{N} u_{i}}\right\}$
   其中，系统整体的综上在能力 $u_{total}$为
   $u_{total} = u_{s}+\sum_{i=1}^{N} u_{i}$
   (3) 对于客户-服务器体系结构，随着对等方数量增加，分发时间呈线性增长且没有上界。对于P2P体系结构，对等方除了是比特的消费者还是其重新分发者，P2P体系结构的应用程序是自扩展的

2. BitTorrent

   (1) BitTorrent是一种用于文件分发的P2P协议

   (2) 参与一个特定文件分发的所有对等方的集合称为一个洪流(torrent)，在一个洪流中的对等方彼此下载等长度的文件块(chunk)，一个对等方首次加入洪流时没有块，但累计足够的块后，它在下载块时也为其他对等方上传块

   (3) 追踪器：每个洪流具有一个基础设施结点，称为追踪器(tracker)。一个对等方加入某洪流时，向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中

   (4) 邻近对等方：新的对等方x加入洪流时，tracker从参与对等方的集合选择一个子集，并将子集中对等方(x的邻近对等方)的IP地址形成的列表发给x，x将与列表中的所有对等方创建并进行TCP连接

   (5) 稀缺优先(rarest first)技术：针对x没有的块在其邻居对等方中决定最稀缺的块，即邻居对等方中副本数量最少的块，并首先请求最稀疏的块

2.6.2 分布式散列表

1. 在P2P网络中实现分布式数据库：每个对等方将保持键值对总体的一个小子集，允许任何对等方用一个键查询该分布式数据库；分布式数据库定位拥有该键值对的对等方，并向查询对等方返回该键值对；任何对等方可以在数据库中插入新的键值对，这样的分布式数据库称为分布式散列表(Distributed Hash Table, DHT)

2. DHT设计方法

   (1) 为每个对等方分配一个[0, $2^n-1$]范围内的整数作为标识符

   (2) 每个键也是同一个范围内的整数，可使用散列函数将非整数类型键转为整数类型，若键值大于该范围则使用模 $2^n$规则

   (3) 若键值恰好等于对等方标识符之一，则在匹配的对等方中存入键值对，若不匹配则在该键的最邻近后继对等方存入键值对

3. 环形DHT

   (1) 覆盖网络：由对等方和覆盖链路组成，一条覆盖链路通常使用了底层网络中的许多条物理链路和物理路由器

   (2) 环形DHT中，每个对等方只需知道其直接后继、直接前任 。为了找到负责的键，要平均发送N/2条报文

   (3) 以环形覆盖网络为基础，增加捷径。研究表明DHT能设计为每个对等方的邻居数量以及每个请求的报文数量均为O(log N)，N为对等方数量

4. 对等方扰动

   (1) P2P系统中，对等方能不加警示地到来和离去

   (2) 为处理对等方扰动，需要将每个对等方联系其第一个和第二个后继

   (3) 对等方退出及对等方加入的情况分析

2.7 套接字编程

1. 两类网络应用程序

   (1) 实现在协议标准中所定义的操作，该协议标准为人所公知

   (2) 专用的网络应用程序，应用层协议没有公开发布

2.7.1 UDP套接字编程

1. client

   from socket import *
   
   serverName = '127.0.0.1'
   serverPort = 12000
   clientSocket = socket(AF_INET, SOCK_DGRAM)    # AF_INET指示IPV4，SOCK_DGRAM指示UDP套接字
   message = input('Input lowercase sentence: ')
   message = message.encode(encoding="utf-8")
   clientSocket.sendto(message, (serverName, serverPort))
   modifiedMessage, serverAddress = clientSocket.recvfrom(2048)
   modifiedMessage = modifiedMessage.decode(encoding="utf-8")
   print(modifiedMessage)
   clientSocket.close()
   

2. server

   from socket import *
   
   serverPort = 12000
   serverSocket = socket(AF_INET, SOCK_DGRAM)
   serverSocket.bind(('127.0.0.1', serverPort))
   print("The server is ready to receive")
   while True:
       message, clientAddress = serverSocket.recvfrom(2048)
       modifiedMessage = message.decode(encoding="utf-8").upper()
       modifiedMessage = modifiedMessage.encode(encoding="utf-8")
       serverSocket.sendto(modifiedMessage, clientAddress)
   

3. 发送进程将数据分组推出发送套接字前，将目的地址附在分组上。分组到达接收套接字后，接收进程通过套接字取回分组

2.7.2 TCP套接字编程

1. 欢迎套接字：所有要与服务器通信的客户的起始接触点，客户进程与欢迎套接字进行三次握手

   连接套接字(connection Socket)：随后为域每个客户通信而生成的套接字
   

2. TCP client

   from socket import *
   serverName = '127.0.0.1'
   serverPort = 12000
   clientSocket = socket(AF_INET, SOCK_STREAM)     # SOCK_STREAM类型表明TCP套接字
   clientSocket.connect((serverName, serverPort))  # 三次握手，并在客户和服务期间创建一条TCP连接
   sentence = input("Input lowercase sentence: ")
   sentence = sentence.encode(encoding='utf-8')    # 无需显示地附上目的地址
   clientSocket.send(sentence)
   modifiedSentence = clientSocket.recv(1024).decode(encoding='utf-8')
   print("From Server: " + modifiedSentence)
   clientSocket.close()
   

3. TCP server

   from socket import *
   serverPort = 12000
   serverSocket = socket(AF_INET, SOCK_STREAM)     # SOCK_STREAM指示创建TCP套接字
   serverSocket.bind(('127.0.0.1', serverPort))    # serverSocket为欢迎套接字
   serverSocket.listen(1)                          # 等待客户，请求连接的最大数为1
   print("The server is ready to receive")
   while True:
       connectionSocket, addr = serverSocket.accept()
       sentence = connectionSocket.recv(1024).decode(encoding='utf-8')
       capitalizedSentence = sentence.upper().encode(encoding='utf-8')
       connectionSocket.send(capitalizedSentence)
       connectionSocket.close()
   
   

4. 客户程序创建其TCP套接字时，指定了服务器中欢迎套接字的地址。生成发送套接字后，客户发起三次握手并创建与服务器的一个TCP连接