二.应用层
导览
本章学习有关网络应用的原理和实现方面的知识,为此我们需要定义一些应用层概念,网络服务,客户端,服务器,进程,运输层接口,然后我们涉及开发运行在TCP和UDP上的网络应用程序,我们还将编写简单的客户-服务器应用程序
应用层协议原理
研发网络应用程序的核心是写出能运行在不同的端系统(Web应用程序中,一个运行在用户主机上的浏览器程序,另一个是运行在Web服务器主机上的程序,另一个例子是P2P2文件共享系统,在参与文件共享的社区中的每台主机中都有一个程序,这种情况下,各台主机的程序可能都是类似或相同的)和通过网络彼此通信的程序。
重要的是,我们不需要写在网络核心设备如路由器或者链路层交换机上运行的软件,这种设计方式即将应用程序限制在端系统的方法,促进了大量网络应用程序的迅速研发和部署。
网络应用程序体系结构
- 客户-服务器体系结构
典型的例子是Web应用程序,Web服务器总是打开来接受客户的请求。客户之间不直接通信;客户-服务器体系结构的另一个特征是该服务器具有固定的,周知的地址,该地址称为IP地址。
客户-服务器体系结构的著名应用有:Web、FTP、Telnet和电子邮件。
客户-服务器系统中服务器要接受大量客户请求的情况,为此,配备大量主机的数据中心常被用于创建强大的虚拟的服务器,一个数据中心可以有数十万台服务器,它们需要供电和维护,同时服务提供商还需要支付不断出现的互联和带宽费用,以及发送和接收到达/来自数据中心的数据;
- P2P体系结构
在P2P体系结构中,对位于数据中心的专用服务器有着最小(或者没有)依赖。应用程序在间断连接的主机对之间使用直接通信,这些主机被称为对等方。
P2P体系结构的著名应用有:文件共享(BitTorrent),协助下载(迅雷),因特网电话(Skype)
P2P 体系结构最引人入胜的特性之一就是它们的自扩展性。比如在文件共享应用中,对等方可能通过向文件的原始拥有者发出请求而产生工作量,但是对等方也有可能通过为其他对等方传送文件而为原始拥有者分担压力;P2P体系结构也是成本有效的,因为他通常不需要庞大的服务器基础设施和服务带宽

P2P也面临以下三个问题
1.ISP友好
大多数住宅 ISP 受制于非对称带宽应用,也就是下载比上传要多得多。但是 P2P 视频和文件分发应用改变了从服务器到住宅ISP的上载流量,因而给 ISP 带来压力。
2.安全性
因为其高度的分布和开放式,P2P应用也可能给安全带来挑战。
3.激励
如何说服用户资源向应用提供带宽、存储和计算资源?这是一个问题。
进程通信
在操作系统中,实际进行通信的是进程而不是应用程序;当进程运行在同一个端系统上时,它们使用进程间通信机制相互通信;而进程间通信的规则是由端系统上的操作系统确定的。当进程运行在不同的端系统上时,它们通过跨越计算机网络的报文相互通信;发送进程产生报文并且向网络中发送,接收进程接收报文并对此作出响应(不响应也是一种响应)。
- 客户和服务器进程
对每对通信进程,我们将这两个进程之一标识为客户,另一个为服务器。而对于P2P文件共享的某些应用中,一个进程既可以是客户又可以是服务器,为此,我们定义发起通信的进程被定义为客户,在会话开始时等待联系的进程为服务器。
- 进程与计算机网络之间的接口
在应用程序进程和计算机网络之间存在一个接口,该接口被称为套接字。更为准确的说,套接字是同一台主机内应用层和运输层之间的接口。由于该套接字是建立网络应用程序的可编程接口,因此套接字也被称为应用程序和网络之间的应用编程接口
应用程序开发者可以控制套接字在应用层的一切内容,但是对于运输层的相关部分,几乎没有控制权,可以做的有:1.选择传输层协议,2.设定几个传输层参数,比如最大缓存和最长传输层报文长度。
- 进程寻址
在一台主机上的进程为了向在另一台主机上运行的进程发送分组,接受进程需要有一个地址。接收进程需要有一个地址。为了标识该接收进程,需要定义两种信息:1.主机的地址(IP地址)。2.定义在目的主机中的接收进程的标识符(端口号)。

可供应用程序使用的运输服务
传输层协议的特点大致可以从以下这四个方面考量:可靠数据传输、吞吐量、定时和安全性
- 可靠数据传输
分组在传输过程中可能会丢失。比如,分组因为路由器中的缓存溢出而被丢弃或者分组在传输的过程中发生了损坏等情况有些应用是不允许数据发生丢失的,比如电子邮件、文件传输、远程主机访问、Web文档传输以及金融应用等。为了支持这些应用,必须做一些工作以确保应用程序一段发送的数据正确、完全地交付给接收数据的进程。如果一个协议提供了这样得确保数据交付的服务,就认为该协提供了可靠数据传输。当应用程序使用可靠数据传输的传输层协议时,只要将要发送的数据传输进套接字就可以完全相信该数据可以完整无差错地到达接收方。
- 吞吐量
在一条网络路径上的两个进程之间的通信会话中,可用吞吐量就是指能够向接收进程交付比特的速率。因为会有其他会话共享该网络的路径的带宽,并且因为这些会话的到来和离开,可用吞吐量将发生变化;这就导致另一种自然的服务,即运输层协议能够提供确切的可用吞吐量。使用这种服务时,应用程序就能以明确的速度接收数据,并且运输层应当保证可用吞吐量必须总是至少为该速度。
- 定时
定时是对数据从发送到到达所需时间的要求,而吞吐量是对数据交付速度的要求
- 安全性
运输层协议可以提供一些安全服务,以防止传输的数据以某种方式在这两个进程之间被察觉到。这些安全服务包括:数据的加解密、数据的完整性和端点鉴别等。
因特网提供的运输服务
- TCP服务
1.面向连接的服务
在应用层数据报文开始流动之前,TCP会在客户端和服务器端相互交换传输层控制信息。这个握手过程将提示客户端和服务器端,让它们为即将到来的大量分组做好准备;握手阶段接收后将建立一个TCP连接。这条链接是全双工的,即连接双方使用该条链接可以同时进行报文的收发。这条连接将在通讯结束后拆除;
2.可靠的数据传输
应用程序使用TCP协议可实现无差错、按适当顺序交付所有发送的数据,没有字节的丢失和冗余
- UDP服务
UDP服务是一种不提供不必要服务的轻量级运输协议。它仅提供最小服务。UDP是无连接的也就是说通信之前没有握手;UDP不提供数据的可靠传输;UDP也没有拥塞控制机制。有些应用场景下,UDP协议将带来更多的便利和效率,比如DNS和一些因特网电话服务(为了避免拥塞控制协议的控制而使用UDP)
- 传输层无法提供的服务
从可靠数据传输、吞吐量、定时、安全性等四个角度来看运输层提供的服务,我们发现,运输层无法对吞吐量和定时做出保证。但是,今天的因特网能够为时间敏感的应用提供满意的服务,尽管它并不提供任何定时或者带宽保证
应用层协议
通过报文发送进套接字使网络进程实现相互通信。如何构造报文?这些报文各个字段的含义是什么?进程何时发送这些报文?这些问题将我们带进应用层协议的范围。应用层协议定义运行在不同端系统上的应用程序进程如何相互传递信息。涉及的内容包括:
- 交换的报文类型(请求或者响应)
- 报文中包含哪些字段
- 字段如何被解释
- 一个进程何时收发报文并如何对报文进行响应等内容
本篇涉及的网络应用
Web、文件传输、电子邮件、目录服务和P2P。
Web部分将介绍HTTP协议,它比较简单和易于理解;FTP则和HTTP形成了对照;电子邮件是比Web更为复杂的应用,因为它使用了多个应用层协议;大多数用户不会直接和DNS接触,但是DNS很好地说明了一种核心的网络功能是如何在应用层实现的。最后便是P2P应用的简单介绍了。
WEB和HTTP
HTTP概述
Web的应用层协议是HTTP协议,它是Web的核心。
Web页面是由对象组成的,一个对象是一个文件,它们通过一个URL地址进行寻址。客户和服务器交互的核心思想是客户通过HTTP请求对服务器发出对Web页面的请求报文,服务器收到该报文后将返回包含该对象的HTTP响应报文。URL地址由两部分组成:存放对象的服务器主机名和对象的路径名
HTTP使用TCP作为它的传输层协议;HTTP客户首先发起一个与服务器的TCP连接,需要注意的是,服务器根据请求作出响应,但是不存储任何关于该客户的状态信息;也正因为这样,HTTP被称为无状态协议。同时,Web使用了客户端-服务器的应用体系结构;其中web服务器总是开着的。
持续连接和非持续连接
RTT的定义:一个短分组从客户到服务器然后从服务器返回到客户所花时间。
- 非持续连接
使用非持续连接时,每个TCP连接在服务器发送一个对象后就会关闭,也就是每个TCP只传送一个请求报文和响应报文。
- 持续连接
如果使用持续连接,一个完整的Web页面 ( 上例中的 HTML 基本文件加上10个图形 ) 可以用单个持续 TCP 连接进行传送。更有甚者,同一台服务器上的多个页面也可以通过同一个连接发送。对对象的这些请求可以一个接一个地发出,而不必等待对未决请求的回答。
-
无流水(pipelining)的持久性连接:客户端只有收到前一个响应后才发送新的请求,每个被引用的对象耗时1个RTT。
-
带有流水机制的持久性连接:HTTP 1.1的默认选项,客户端只要遇到一个引用对象就尽快发出请求,理想情况下,收到所有的引用对象只需耗时约1个RTT
一般来说,如果一条连接在一定的时间间隔后没被使用的话,就会被关闭。HTTP默认使用的是带流水线的持续连接。
非持续连接缺点:第一、 必须为每一个请求的对象建立和维护一个全新的连接,而每个TCP连接将占用系统资源,包括缓冲区和变量等,这样服务器的负担就很重了。 第二,每一个对象经受两倍 RTT 的交付时延。
HTTP报文格式
- 请求报文

一个请求报文具有至少一行的内容。请求报文的第一行称为请求行(request line),其后继的各行被称为首部行(header lines)。请求行包含三个内容:方法字段、URL字段、HTTP版本;其中方法字段可为:GET、POST、PUT、DELETE、HEAD等。URL字段里可以传递请求对象的标志;
首部行 Host : www. someschool. edu 指明了对象所在的主机。Connection : close 浏览器告诉服务器使用非持续连接;浏览器版本是 Mozilla/5.0,即 Firefox 浏览器; Accept-language 首部行表示用户想得到该对象的法语版本。
在首部行之后一个空行,之后便是请求的“实体体”。该实体体可以在POST方法里传递Form表单内容或者传递其它一些二进制流数据等。值得注意的是,表单也不一定必须使用POST方法。如果使用get,实体体为空,会显示在url中。
Head类似于get方法,将会用一个http报文进行响应,但是不返回请求对象,经常用作调试跟踪。put方法允许用户上传对象到指定的Web服务器上指定的路径。Delete方法允许用户或应用程序删除Web服务器上的对象。
- 响应报文

响应报文总体上也分三个部分,第一部分是状态行(status line),包含HTTP版本、状态以及状态信息等内容;第二部分是首部行(header lines),包含发送日期、服务器类型、上一次修改请求资源的时间、内容的类型等内容。第三部分是实体体(entity body),实体体包含请求对象本身。
这里的Date是从文件系统中检索到该对象,插入到响应报文,并发送该响应报文的时间。
常见状态码
- 200:请求成功 处理方式:获得响应的内容,进行处理
- 301:请求到的资源都会分配一个永久的URL,这样就可以在将来 通过该URL来访问此资源 处理方式:重定向到分配的URL
- 400:非法请求 处理方式:丢弃
- 404:没有找到 处理方式:丢弃
- 505:服务器不支持请求报文使用的http版本
用户和服务器的交互
HTTP服务器是无状态的。有些Web站点希望能够识别用户,将其内容与用户联系起来。为此,HTTP使用了cookie。
cookie技术有四个组件:
- HTTP响应报文里增加一个关于Cookie的首部行
- HTTP请求报文里增加一个关于Cookie的首部行
- 用户端系统保留一个Cookie文件,由浏览器保存维护
- Web站点建立Cookie和用户身份的关联
我们通过一个例子来看看cookie的工作流程

Web缓存

Web缓冲器又叫做代理服务器,它有自己的磁盘存储空间,并在存储空间保存最近请求过的副本。可以通过配置浏览器,将所有指向初始服务器的请求首先指向代理服务器。
当代理服务器收到一个HTTP请求后,它将检查本地是否缓存过该对象,如果所请求对象在缓存中,缓存返回对象,否则,缓存服务器向原始服务器发送HTTP请求,获取对象,然后返回给客户端并保存该对象。缓存既充当客户端,也充当服务器。
条件GET方法
高速缓存器的使用,带来很多好处,但是有一个问题就是代理服务器对缓存对象的管理:如何确保所请求的对象是最新的?其实HTTP提供了一种机制,允许缓存器证实其使用的对象是最新的,这种机制就是条件GET(conditional GET)方法。使用条件GET方法只需在使用GET方法的时候,增加一个If-Modified-Since首部行,其对应的内容是一个时间,如果所请求的资源在指定日期后被修改了,那么服务器将返回新的对象,否则服务器将返回一个包含空实体体的报文。这样代理服务器就可以确认缓存是否过期了。
文件传输协议:FTP
一个典型的FTP会话中会发生的:
用户坐在一台主机(本地主机)前面,向一台远程主机
传输(或接收来自远程主机的)文件 。 为使用户能访问它的远程账户,用户必须提供一个用户标识和口令 。 在提供了这种授权信息后,用户就能从本地文件系统向远程主机文件系统传送文件,反之亦然。如下图所示,用户通过一个FTP用户代理与FTP交互 。 该用户首先提供远程主机的主机名,使本地主机的FTP客户进程建立一个到远程主机FTP服务器进程的TCP连接。该用户接着提供用户标识和口令,作为FTP命令的一部分在该TCP连接上传送 。一旦该服务器向该用户授权,用户可以将存放在本地文件系统中的一个或者多个文件复制到远程文件系统(反之亦然)。

FTP使用两个并行的TCP连接来传输数据,一个是控制连接,一个是数据连接。顾名思义,控制连接用于两主机之间传输控制信息,如用户标识,口令,改变远程目录的命令等,数据连接用于实际发送一个文件。
FTP服务器在整个会话期间保留用户的状态
因特网中的电子邮件
因特网电子邮件系统有三个核心组件:用户代理(user agent)、 邮件服务器 (mail server)和简单邮件传输协议(Simple Mail Transfer Protocol,SMTP)
每个收发方在邮件服务器上拥有一个邮箱;一个典型的邮件发送过程是:从发送方的用户代理开始,传输到发送方的邮件服务器,再传输到接收方的邮件服务器,然后在这里被分发到接收方的邮箱中。

SMTP是因特网中电子邮件的主要应用层协议,它使用TCP可靠数据传输从发送方的邮件服务器向接收方的邮件服务器发送邮件;在每台邮件服务器上同时运行SMTP服务器和SMTP客户端。当邮件服务器接收其他邮件服务器的邮件时,它表现为SMTP服务器,当邮件服务器向其他邮件服务器发送邮件时,表现为SMTP客户端。
如果发送端不能将邮件发送个接受端的服务器,发送端的邮件服务器会在一个报文队列中保持该报文并在以后尝试再次发送。
SMTP
假设Alice想给Bob发送一封简单的ASCII报文
1.Alice 调用她的邮件代理程序并提供 Bob 的邮件地址,撰写报文, 然后指示用户代理发送该报文 。
2.Alice 的用户代理把报文发给她的邮件服务器,该报文被放在报文队列中。
3.运行在 Alice 的邮件服务器上的 SMTP 客户端发现了报文队列中的这个报文,创建一个到运行在 Bob 的邮件服务器上的 SMTP 服务器的 TCP 连接。
4.在经过一些初始 SMTP 握手后 , SMTP 客户发送 Alice 的报文。
在 Bob 的邮件服务器上,SMTP 的服务器端接收该报文。Bob 的邮件服务器然后将该报文放入 Bob 的邮箱中。
5.在 Bob 方便的时候 , 他调用用户代理阅读该报文。

注意,SMTP一般不使用中间邮件服务器发送邮件
SMTP如何进行工作:
首先,客户SMTP(运行在发送邮件服务器上)在25号端口建立一个到服务器SMTP(运行在接收邮件服务器上)的TCP连接。如果服务器没有开机,客户会在稍后继续尝试连接。一旦连接建立,服务器和客户执行某些应用层的握手,就像人们在互相交流前先进行自我介绍一样。SMTP的客户和服务器在传输信息前先相互介绍。在SMTP握手的阶段,SMTP客户指示发送方的邮件地址(产生报文的那个人)和接收方的邮件地址。一旦该SMTP客户和服务器彼此介绍之后,客户发送该报文。SMTP能依赖TCP提供的可靠数据传输无差错地将邮件投递到服务器,该客户如果有另外的报文要发送到该服务器,就在该相同的TCP连接上重复这种处理;否则,它指示TCP关闭连接。
与HTTP的对比
- 相似之处
HTTP从Web服务器向Web客户端传送文件,SMTP从一个邮件服务器向另一个邮件服务传送文件。进行文件传送时,HTTP和SMTP都使用持续连接。
- 不同
HTTP被设计为一个Pull协议而SMTP被设计为一个Push协议。即用户通过HTTP主动向服务器请求内容,而SMTP则是客户将内容推向服务器端。HTTP传输的数据不一定是用ASCII字符,但是SMTP则只能使用ASCII字符;
第三个重要区别就是,HTTP将每个对象封装在自己的响应报文里,而SMTP则将所有的报文对象放到一个报文之中
邮件报文格式
报文由两部分组成:一个包含环境信息的首部和一个包含邮件内容的报文体;首部和报文体之间使用空行分开;首部行的格式为关键字跟冒号及其值;每个首部必须包含一个From和To首部行。首部也可以包含其它信息,比如Subject等。这与2.3.1中接触的SMTP命令不同,那节中的命令是握手协议的一部分;本节中研究的内容是邮件报文自身的一部分
一个典型的报文首部
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life.
邮件访问协议
SMTP是邮件服务器之间发送邮件报文的协议,并不是用户通过代理和邮件服务器之间通信的协议;用户代理使用邮件访问协议来从邮件服务器上获取邮件信息;目前常用的邮件访问协议有第三版的邮局协议(Post Office Protocol—Version 3,POP3)、因特网邮件访问协议(Internet Mail Access Protocol,IMAP)以及 HTTP。
- POP3
POP3是一个非常简单的协议,因为简单,所以功能有限;POP3使用端口110来建立TCP连接(SMTP使用端口25);POP3按照三个阶段进行工作:特许、事务处理和更新;在特许阶段,用户代理发送密码和用户名,进行身份鉴别;第二阶段,用户代理取回报文,同时还可以做删除、取消删除等标记或者统计邮件信息;第三个阶段是在用户退出后,POP3结束会话,删除被标记的邮件;
一个需要注意的是,POP3用户代理可以使用两种事务处理模式:一种是下载并删除,另一种是下载保留;下载并删除的方法存在的问题是,如果用户在一台设备上查看了邮件(下载了邮件)后,邮件将被删除,那么在其他设备上将无法查看邮件;这给用户带来一定的不便。使用下载保存方式,则用户下载邮件后,邮件还在服务器上。
- IMAP
POP3协议无法为用户提供邮件分类管理的功能,虽然用户可以通过将邮件下载到本地,然后由用户代理程序做分类管理,但是处理的结果是无法同步到其他查看设备上的。为了解决这一问题,IMAP诞生了。IMAP是一个邮件访问协议,比POP3要复杂的多,当然也就有更多的特色了。
IMAP将每一份邮件和一个文件夹联系起来,当报文第一次到达服务器时,它与收件人的INBOX相关联。收件人可以将邮件移到新创建的文件夹,阅读邮件,删除邮件等。IMAP允许用户在不同文件夹里移动邮件并且查询邮件。值得注意的是,IMAP服务器维护了IMAP会话的用户状态信息,但是POP3并不;IMAP协议还允许用户代理获取报文组件而不是报文整体。
- 基于Web的电子邮件
这种方式主要是指,用户使用HTTP协议和邮件服务器通信。用户代理就是普通的浏览器,但是,邮件服务器之间还是使用SMTP协议的。
DNS:因特网的目录服务
因特网上的主机用IP地址和主机名来标识。IP地址具有层次结构,当我们从左至右扫描它时,我们会得到越来越具体的关于主机位于因特网何处的信息。而主机名便于人们记忆和接受
DNS提供的服务
DNS主要服务:提供进行主机名到IP地址转换的服务
DNS还提供了其他服务:主机别名,邮件服务器别名,负载分配。
DNS是
1.一个分层的DNS服务器实现的分布式数据库
2.一个使主机能够查询分布式数据库的应用层协议。DNS服务器通常使运行BIND软件的UNIX机器。DNS运行在UDP之上,使用53号端口
DNS通常是由其他应用层协议所使用的,包括HTTP、SMTP和FTP,将用户提供的主机名解析为IP地址
举一个例子,考虑当某个用户主机上的一个浏览器(即一个HTTP
客户)请求URL www.someschool.edνindex.html页面时会发生什么现象。为了使用户的主机能够将一个HTTP请求报文发送到Web服务器www.someschool.edu,该用户主机必须
获得附www.someschool.edu的IP地址。其做法如下:
-
同一台用户主机上运行着DNS应用的客户端。
-
浏览器从上述URL中抽取出主机名www.someschool.edu,并将这台主机名传给DNS应用的客户端。
-
DNS客户向DNS服务器发送一个包含主机名的请求。
-
DNS客户最终会收到一份回答报文,其中含有对应于该主机名的IP地址。
-
一旦浏览器接收到来自DNS的该IP地址,它能够向位于该lP地址80端口的HTTP服务器进程发起一个TCP连接。
DNS工作原理概述
1.分布式,层次数据库
DNS采用分布式的设计方案是因为单一的DNS服务器存在单点故障、无法保证通信容量以及无法临近所有的查询主机和维护困难等问题。

为了处理扩展性问题,DNS服务器采用层次式组织,并且分布在全世界范围内;大致来说,存在三种DNS服务器:根DNS服务器、顶级域(Top Level Domain, TLD)DNS服务器和权威DNS服务器。举例说明,假定一个 DNS 客户要获取主机名 www.amazon.com 的 IP 地址。客户首先与根服务器之一联系,它将返回顶级域名 com 的 TLD 服务器的 IP地址。 该客户与这些 TLD 服务器之一联系,它将为 amazon.com 返回权威服务器的 IP 地址。最后,客户与amazon.com 权威服务器之一联系,返回其 IP 地址。
- 根DNS服务器:因特网上有13个根DNS服务器,大部分分布在北美洲。
- 顶级域DNS服务器:负责顶级域名,如com,org,net,edu,gov以及各个国家的顶级域名的转换。
- 权威DNS服务器:组织的域名解析服务器,提供组织内部服务器的解析服务
还有另一类重要的DNS,称为本地DNS服务器,每个ISP(如一个大学,一个系,一个公司或一个居民区的ISP)都有一台本地DNS服务器。当某个主机与某个ISP连接时,该ISP提供一台主机的IP地址,该主机具有一台或多台其本地DNS服务器的IP地址。当主机发出DNS请求时,该请求被发往本地DNS服务器,它起代理的作用。
DNS查询有两种,一种是递归查询一种是迭代查询;实践中,查询通常满足这样的模式:从请求主机到本地DNS服务器的查询是递归的,其余查询是迭代的。
递归查询

迭代查询

2.DNS缓存
DNS缓存实际上是为了改善时延性能并且减少在因特网上传输的DNS报文数量而引入的。DNS缓存原理十分简单,每当DNS服务器发出请求后收到回答时,就将回答的内容缓存在它自己的主机空间上。这样,如果有相同的请求到达时,就不需要再去发出请求,直接使用缓存即可;因为有了缓存,本地DNS就可以直接提供一些经常被访问的主机名所对应的IP地址,而不需要询问根DNS服务器了。需要注意的是,缓存不可避免的一个问题:有效时间。如果缓存过时而未得到更新,那么就会导致一些请求失败。
DNS记录和报文
共同实现DNS分布数据库的所有DNS服务器存储了资源记录,资源记录是一份包含下列字段的四元组:(name,valuee,type,TTL)其中TTL是指该记录的生存时间,它决定了该条记录何时被删除。

DNS报文

DNS报文结构
DNS报文有两种,即查询报文和回答报文,并且两种报文有着相同的结构:
-
前12字节为首部区域。标识符是一个用来标记该查询的16比特数。该标志符会被复制到相应的回答报文里,以便匹配请求和回答;
-
标志字段有若干标志,用来指出报文的类型(请求还是响应)、查询类型(递归还是迭代)、是否是所请求名字的权威DNS服务器、以及4个有关
数量的字段,用来指示4类数据区域出现的数量; -
问题区域包含了正在进行的查询信息,包括名字字段、查询类型;
-
回答区域包含了对最初请求的名字的资源记录,回答报文的回答区域可以包含多条RR,因此一个主机名能有多个IP地址;
-
权威区域包含了其他权威服务器的信息;
-
附加区域包含了其它有帮助的记录,比如在对于一个MX类型的请求回答报文里,回答区域里指出了邮件服务器的规范主机名,而附加区域里就有可能包含一个类型为A的关于该规范主机名的的IP地址;
P2P应用
P2P文件分发
1.P2P体系结构的扩展性

问题 : 从一个服务器向N个节点分发一个文件需要多长时间?下面对比客户机/服务器 和 P2P 文件分发时间。
对于客户机/服务器模式下的文件分发:服务器串行地发送N个副本,用时 NF/us,客户机 i 需要 F/di 时间下载。则最小的分发时间 dcs = max{NF/us,F/min(di)}
对于 P2P 模式的文件分发:服务器必须发送一个副本,用户 F/us,客户机 i 需要F/di 时间下载,总共需要下载 NF 比特,最快的可能上传速率为 us + ui。则最小的文件分发时间 dP2P = max { F/us,F/min(di),NF/(us + ui)}


浙公网安备 33010602011771号