计算机网络—

本章讨论各种应用进程通过什么样的应用层协议来使用网络所提供的这些通信服务。

在上一章，我们已学习了运输层为应用进程提供了端到端的通信服务。但不同的网络应用的应用进程之间，还需要有不同的通信规则。因此在运输层协议之上，还需要有应用层协议(application layer protocol)。这是因为，每个应用层协议都是为了解决某一类应用问题，而问题的解决又必须通过位于不同主机中的多个应用进程之间的通信和协同工作来完成。应用进程之间的这种通信必须遵循严格的规则。应用层的具体内容就是精确定义这些通信规则。具体来说，应用层协议应当定义：

应用进程交换的报文类型，如请求报文和响应报文。
各种报文类型的语法，如报文中的各个字段及其详细描述。
字段的语义，即包含在字段中的信息的含义。
进程何时、如何发送报文，以及对报文进行响应的规则。

请注意，应用层协议与网络应用并不是同一个概念。应用层协议只是网络应用的一部分。例如，万维网应用是一种基于客户/服务器体系结构的网络应用。万维网应用包含很多部件，有万维网浏览器、万维网服务器、万维网文档的格式标准，以及一个应用层协议。万维网的应用层协议是HTTP，它定义了在万维网浏览器和万维网服务器之间传送的报文类型、格式和序列等规则。而万维网浏览器如何显示一个万维网页面，万维网服务器是用多线程还是用多进程来实现，则都不是HTTP所定义的内容。

应用层的许多协议都是基于客户服务器方式。即使是P2P对等通信方式，实质上也是一种特殊的客户服务器方式。这里再明确一下，客户(client)和服务器(server)都是指通信中所涉及的两个应用进程。客户服务器方式所描述的是进程之间服务和被服务的关系。这里最主要的特征就是：客户是服务请求方，服务器是服务提供方。

域名系统DNS

域名系统概述

域名系统DNS (Domain Name System)是互联网使用的命名系统，用来把便于人们使用的机器名字转换为IP地址。域名系统其实就是名字系统。为什么不叫“名字"而叫“域名"昵？这是因为在这种互联网的命名系统中使用了许多的“域"(domain)，因此就出现了“域名”这个名词。“域名系统”很明确地指明这种系统是用在互联网中的。

许多应用层软件经常直接使用域名系统DNS。虽然计算机的用户只是间接而不是直接使用域名系统，但DNS却为互联网的各种网络应用提供了核心服务。

用户与互联网上某台主机通信时，必须要知道对方的IP地址。然而用户很难记住长达32位的二进制主机地址。即使是点分十进制IP地址也并不太容易记忆。但在应用层为了便于用户记忆各种网络应用，连接在互联网上的主机不仅有IP地址，而且还有便于用户记忆的主机名字。域名系统DNS能够把互联网上的主机名字转换为IP地址。

互联网的域名系统DNS被设计成为一个联机分布式数据库系统，并釆用客户服务器方式。DNS使大多数名字都在本地进行解析(resolve)，仅少量解析需要在互联网上通信，因此DNS系统的效率很高。由于DNS是分布式系统，即使单个计算机出了故障，也不会妨碍整个DNS系统的正常运行。

域名到IP地址的解析是由分布在互联网上的许多域名服务器程序（可简称为域名服务器）共同完成的。域名服务器程序在专设的结点上运行，而人们也常把运行域名服务器程序的机器称为域名服务器。

域名到IP地址的解析过程的要点如下：当某一个应用进程需要把主机名解析为IP地址时，该应用进程就调用解析程序（resolver），并成为DNS的一个客户，把待解析的域名放在DNS请求报文中，以UDP用户数据报方式发给本地域名服务器（使用UDP是为了减少开销）。本地域名服务器在查找域名后，把对应的IP地址放在回答报文中返回。应用进程获得目的主机的IP地址后即可进行通信。

互联网的域名结构

早期的互联网使用了非等级的名字空间，其优点是名字简短。但当互联网上的用户数急剧增加时，用非等级的名字空间来管理一个很大的而且是经常变化的名字集合是非常困难的。因此，互联网后来就釆用了层次树状结构的命名方法，就像全球邮政系统和电话系统那样。釆用这种命名方法，任何一个连接在互联网上的主机或路由器，都有一个唯一的层次结构的名字，即域名(domain name)。这里，“域"(domain)是名字空间中一个可被管理的划分。域还可以划分为子域，而子域还可继续划分为子域的子域，这样就形成了顶级域、二级域、三级域，等等。

从语法上讲，每一个域名都由标号(label)序列组成，而各标号之间用点隔开(请注意，是小数点不是中文的句号“。“)。例如下面的域名

就是中央电视台用于收发电子邮件的计算机（即邮件服务器）的域名，它由三个标号组成，其中标号com是顶级域名，标号cctv是二级域名，标号mail是三级域名。

DNS规定，域名中的标号都由英文字母和数字组成，每一个标号不超过63个字符（但为了记忆方便，最好不要超过12个字符），也不区分大小写字母（例如，CCTV或cctv在域名中是等效的）。标号中除连字符（-）外不能使用其他的标点符号。级别最低的域名写在最左边，而级别最高的顶级域名则写在最右边。由多个标号组成的完整域名总共不超过255个字符。DNS既不规定一个域名需要包含多少个下级域名，也不规定每一级的域名代表什么意思。各级域名由其上一级的域名管理机构管理，而最高的顶级域名则由ICANN进行管理。用这种方法可使每一个域名在整个互联网范围内是唯一的，并且也容易设计出一种查找域名的机制。

需要注意的是，域名只是个逻辑概念，并不代表计算机所在的物理地点。变长的域名和使用有助记忆的字符串，是为了便于人使用。而IP地址是定长的32位二进制数字则非常便于机器进行处理。这里需要注意，域名中的“点”和点分十进制IP地址中的“点”并无一一对应的关系。点分十进制IP地址中一定是包含三个“点”，但每一个域名中“点"的数目则不一定正好是三个。

据2012年5月的统计［W-IANA-root］,现在顶级域名TLD （Top Level Domain）已有326个。原先的顶级域名共分为三大类：

国家顶级域名nTLD：釆用ISO 3166的规定。如:cn表示中国，us表示美国，uk表示英国，等等。国家顶级域名又常记为ccTLD （cc表示国家代码country-code）。到2012年5月为止，国家顶级域名总数己达296个。
通用顶级域名gTLD：到2006年12月为止，通用顶级域名的总数已经达到20个。最先确定的通用顶级域名有7个，即：com （公司企业），net （网络服务机构），org （非营利性组织），int （国际组织），edu（美国专用的教育机构）.gov （美国的政府部门），mil表示（美国的军事部门）。以后又陆续增加了 13个通用顶级域名：aero （航空运输企业），asia （亚太地区），biz （公司和企业）,cat （使用加泰隆人的语言和文化团体），coop （合作团体），info （各种情况）,jobs （人力资源管理者），mobi （移动产品与服务的用户和提供者），museum （博物馆），name （个人），pro （有证书的专业人员），tel （Telnic股份有限公司），travel （旅游业）。
基础结构域名（in&astructure domain）：这种顶级域名只有一个，即arpa，用于反向域名解析，因此又称为反向域名。

值得注意的是，ICANN于2011年6月20日在新加坡会议上正式批准新顶级域名（NewgTLD）,因此任何公司、机构都有权向ICANN申请新的顶级域。新顶级域名的后缀特点，使企业域名具有了显著的、强烈的标志特征。因此，新顶级域名被认为是真正的企业网络商标。新顶级域名是企业品牌战略发展的重要内容，其申请费很高（18万美元），并且在2013年开始启用。目前已有一些由两个汉字组成的中文的顶级域名出现了，例如，商城、公司、新闻等。到2016年，在ICANN注册的中文顶级域名已有60个［W-IANA-root］。

在国家顶级域名下注册的二级域名均由该国家自行确定。例如，顶级域名为jp的日本，将其教育和企业机构的二级域名定为ac和co，而不用edu和com。

我国把二级域名划分为“类别域名”和“行政区域名”两大类。“类别域名"共7个，分别为：ac （科研机构），com （工、商、金融等企业），edu（中国的教育机构），gov （中国的政府机构），mil （中国的国防机构），net （提供互联网络服务的机构），org （非营利性的组织）。“行政区域名"共34个，适用于我国的各省、自治区、直辖市。例如：bj （北京市），js （江苏省），等等。关于我国的互联网络发展现状以及各种规定（如申请域名的手续），均可在中国互联网网络信息中心CNNIC的网址上找到［W-CNNIC］。

用域名树来表示互联网的域名系统是最清楚的。图6-1是互联网域名空间的结构，它实际上是一个倒过来的树，在最上面的是根，但没有对应的名字。根下面一级的节点就是最高一级的顶级域名（由于根没有名字，所以在根下面一级的域名就叫做顶级域名）。顶级域名可往下划分子域，即二级域名。再往下划分就是三级域名、四级域名，等等。图6-1列举了一些域名作为例子。凡是在顶级域名com下注册的单位都获得了一个二级域名。图中给出的例子有：中央电视台cctv,以及IBM、华为等公司。在顶级域名cn （中国）下面举出了几个二级域名，如：bj, edu以及com。在某个二级域名下注册的单位就可以获得一个三级域名。图中给出的在edu下面的三级域名有：tsinghua （清华大学）和pku （北京大学）。
一旦某个单位拥有了一个域名，它就可以自己决定是否要进一步划分其下属的子域，并且不必由其上级机构批准。图中cctv （中央电视台）和tsinghua （清华大学）都分别划分了自己的下一级的域名mail和www （分别是三级域名和四级域名）气域名树的树叶就是单台计算机的名字，它不能再继续往下划分子域了。

域名服务器

上面讲述的域名体系是抽象的。但具体实现域名系统则是使用分布在各地的域名服务器。从理论上讲，可以让每一级的域名都有一个相对应的域名服务器，使所有的域名服务器构成和图6-1相对应的“域名服务器树”的结构。但这样做会使域名服务器的数量太多，使域名系统的运行效率降低。因此DNS就釆用划分区的办法来解决这个问题。

一个服务器所负责管辖的(或有权限的)范围叫做区(zone)。各单位根据具体情况来划分自己管辖范围的区。但在一个区中的所有节点必须是能够连通的。每一个区设置相应的权限域名服务器(authoritative name server)，用来保存该区中的所有主机的域名到IP地址的映射。总之，DNS服务器的管辖范围不是以“域”为单位，而是以“区”为单位。区是DNS服务器实际管辖的范围。区可能等于或小于域，但一定不能大于域。

图6-2是区的不同划分方法的举例。假定abc公司有下属部门x和y，部门x下面又分三个分部门u, v和w,而y下面还有其下属部门to图6-2(a)表示abc公司只设一个区abc.com。这时，区abc.com和域abc.com指的是同一件事。但图6-2(b)表示abc公司划分了两个区(大的公司可能要划分多个区)：abc.com和y.abc.como这两个区都隶属于域abc.com，都各设置了相应的权限域名服务器。不难看出，区是“域"的子集。

图6-3以图6-2(b)中公司abc划分的两个区为例，给出了 DNS域名服务器树状结构图。这种DNS域名服务器树状结构图可以更准确地反映出DNS的分布式结构。在图6-3中的每一个域名服务器都能够进行部分域名到IP地址的解析。当某个DNS服务器不能进行域名到IP地址的转换时，它就设法找互联网上别的域名服务器进行解析。

从图6-3可看出，互联网上的DNS域名服务器也是按照层次安排的。每一个域名服务器都只对域名体系中的一部分进行管辖。根据域名服务器所起的作用，可以把域名服务器划分为以下四种不同的类型：

根域名服务器(root name server)

根域名服务器是最高层次的域名服务器，也是最重要的域名服务器。所有的根域名服务器都知道所有的顶级域名服务器的域名和IP地址。根域名服务器是最重要的域名服务器，因为不管是哪一个本地域名服务器，若要对互联网上任何一个域名进行解析(即转换为IP地址)，只要自己无法解析，就首先要求助于根域名服服务器。

顶级域名服务器(即TLD服务器)

这些域名服务器负责管理在该顶级域名服务器注册的所有二级域名。当收到DNS査询请求时，就给出相应的回答（可能是最后的结果，也可能是下一步应当找的域名服务器的IP地址）。

权限域名服务器

这就是前面已经讲过的负责一个区的域名服务器。当一个权限域名服务器还不能给出最后的査询回答时，就会告诉发出查询请求的DNS客户，下一步应当找哪一个权限域名服务器。例如在图6-2(b)中，区abc.com和区y.abc.com各设有一个权限域名服务器。

本地域名服务器(local name server)

本地域名服务器并不属于图6-3所示的域名服务器层次结构，但它对域名系统非常重要。

当一台主机发出DNS査询请求时，这个査询请求报文就发送给本地域名服务器。由此可看出本地域名服务器的重要性。每一个互联网服务提供者ISP，或一个大学，甚至一个大学里的系，都可以拥有一个本地域名服务器，这种域名服务器有时也称为默认域名服务器。

本地域名服务器离用户较近，一般不超过几个路由器的距离。当所要査询的主机也属于同一个本地ISP时，该本地域名服务器立即就能将所查询的主机名转换为它的IP地址，而不需要再去询问其他的域名服务器。

下面简单讨论一下域名的解析过程。这里要注意两点。

第一，主机向本地域名服务器的查询一般都是采用递归查询(recursive quay)。（较少使用）

所谓递归查询就是：如果主机所询问的本地域名服务器不知道被査询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出査询请求报文(即替该主机继续査询)，而不是让该主机自己进行下一步的査询。因此，递归査询返回的査询结果或者是所要査询的IP地址，或者是报错，表示无法査询到所需的IP地址。

第二，本地域名服务器向根域名服务器的查询通常是釆用迭代查询(iterative query)。

迭代査询的特点是这样的：当根域名服务器收到本地域名服务器发出的迭代査询请求报文时，要么给出所要查询的IP地址，要么告诉本地域名服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地域名服务器进行后续的查询(而不是替本地域名服务器进行后续的查询)。根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的査询请求后，要么给出所要査询的IP地址，要么告诉本地域名服务器下一步应当向哪一个权限域名服务器进行査询，本地域名服务器就这样进行迭代査询。最后，知道了所要解析的
域名的IP地址，然后把这个结果返回给发起査询的主机。当然，本地域名服务器也可以釆用递归查询，这取决于最初的查询请求报文的设置是要求使用哪一种査询方式。

图6-5用例子说明了这两种査询的区别。

假定域名为rn.xyz.com的主机想知道另一台主机（域名为y.abc.com）的IP地址。例如，主机rn.xyz.com打算发送邮件给主机y.abc.com。这时就必须知道主机y.abc.com的IP地址。下面是图6-5（a）的几个査询步骤：

主机rn.xyz.com先向其本地域名服务器dns.xyz.com进行递归査询。
本地域名服务器采用迭代査询。它先向一个根域名服务器査询。
根域名服务器告诉本地域名服务器，下一次应査询的顶级域名服务器dns.com的IP地址。
本地域名服务器向顶级域名服务器dns.com进行査询。
顶级域名服务器dns.com告诉本地域名服务器，下一次应查询的权限域名服务器dns.abc.com 的 IP 地址。
本地域名服务器向权限域名服务器dns.abc.com进行査询。
权限域名服务器dns.abc.com告诉本地域名服务器，所查询的主机的IP地址。
本地域名服务器最后把査询结果告诉主机rn.xyz.como

我们注意到，这8个步骤总共要使用8个UDP用户数据报的报文。本地域名服务器经过三次迭代查询后，从权限域名服务器dns.abc.com得到了主机y.abc.com的IP地址，最后把结果返回给发起査询的主机rn.xyz.com 。

图6-5（b）是本地域名服务器釆用递归査询的情况。在这种情况下，本地域名服务器只需向根域名服务器查询一次，后面的几次査询都是在其他几个域名服务器之间进行的（步骤3至6）。只是在步骤7，本地域名服务器从根域名服务器得到了所需的IP地址。最后在步骤8，本地域名服务器把査询结果告诉主机m.xyz.como整个的査询也是使用8个UDP报文。

为了提高DNS查询效率，并减轻根域名服务器的负荷和减少互联网上的DNS査询报文数量，在域名服务器中广泛地使用了高速缓存（有时也称为高速缓存域名服务器）。高速缓存用来存放最近査询过的域名以及从何处获得域名映射信息的记录。

例如，在图6-5（a）的査询过程中，如果在不久前已经有用户査询过域名为y.abc.com的IP地址，那么本地域名服务器就不必向根域名服务器重新查询y.abc.com的IP地址，而是直接把高速缓存中存放的上次査询结果（即y.abc.com的IP地址）告诉用户。

假定本地域名服务器的缓存中并没有y.abc.com的IP地址，而是存放着顶级域名服务器dns.com的IP地址，那么本地域名服务器也可以不向根域名服务器进行査询，而是直接向com顶级域名服务器发送查询请求报文。这样不仅可以大大减轻根域名服务器的负荷，而且也能够使互联网上的DNS査询请求和回答报文的数量大为减少。

由于名字到地址的绑定并不经常改变，为保持高速缓存中的内容正确，域名服务器应为每项内容设置计时器并处理超过合理时间的项（例如，每个项目只存放两天）。当域名服务器己从缓存中删去某项信息后又被请求査询该项信息，就必须重新到授权管理该项的域名服务器获取绑定信息。

文件传送协议

FTP概述

文件传送协议FTP (File Transfer Protocol)是互联网上使用得最广泛的文件传送协议。FTP提供交互式的访问，允许客户指明文件的类型与格式(如指明是否使用ASCH码)，并允许文件具有存取权限(如访问文件的用户必须经过授权，并输入有效的口令FTP屏蔽了各计算机系统的细节，因而适合于在异构网络中任意计算机之间传送文件。

在互联网发展的早期阶段，用FTP传送文件约占整个互联网的通信量的三分之一，而由电子邮件和域名系统所产生的通信量还小于FTP所产生的通信量。只是到了 1995年，WWW的通信量才首次超过了 FTP。

文件共享协议中的另一大类是联机访问(on-line access)。联机访问意味着允许多个程序同时对一个文件进行存取。和数据库系统的不同之处是用户不需要调用一个特殊的客户进程，而是由操作系统提供对远地共享文件进行访问的服务，就如同对本地文件的访问一样。这就使用户可以用远地文件作为输入和输出来运行任何应用程序，而操作系统中的文件系统则提供对共享文件的透明存取。透明存取的优点是：将原来用于处理本地文件的应用程序用来处理远地文件时，不需要对该应用程序作明显的改动。

FTP的基本工作原理

网络环境中的一项基本应用就是将文件从一台计算机中复制到另一台可能相距很远的计算机中。初看起来，在两台主机之间传送文件是很简单的事情。其实这往往非常困难。原因是众多的计算机厂商研制出的文件系统多达数百种，且差别很大。经常遇到的问题是：

计算机存储数据的格式不同。
文件的目录结构和文件命名的规定不同。
对于相同的文件存取功能，操作系统使用的命令不同。
访问控制方法不同。

文件传送协议FTP只提供文件传送的一些基本的服务，它使用TCP可靠的运输服务。FTP的主要功能是减少或消除在不同操作系统下处理文件的不兼容性。

FTP使用客户服务器方式。一个FTP服务器进程可同时为多个客户进程提供服务。FTP的服务器进程由两大部分组成：一个主进程，负责接受新的请求；另外有若干个从属进程，负责处理单个请求。

主进程的工作步骤如下：

打开熟知端口(端口号为21)，使客户进程能够连接上。
等待客户进程发出连接请求。
启动从属进程处理客户进程发来的请求。从属进程对客户进程的请求处理完毕后即终止，但从属进程在运行期间根据需要还可能创建其他一些子进程。
回到等待状态，继续接受其他客户进程发来的请求。主进程与从属进程的处理是并发进行的。

FTP的工作情况如图6-6所示。图中的椭圆圈表示在系统中运行的进程。图中的服务器端有两个从属进程：控制进程和数据传送进程。为简单起见，服务器端的主进程没有画上。客户端除了控制进程和数据传送进程外，还有一个用户界面进程用来和用户接口。

在进行文件传输时，FTP的客户和服务器之间要建立两个并行的TCP连接：“控制连接"和“数据连接”。控制连接在整个会话期间一直保持打开，FTP客户所发出的传送请求，通过控制连接发送给服务器端的控制进程，但控制连接并不用来传送文件。实际用于传输文件的是“数据连接"。服务器端的控制进程在接收到FTP客户发送来的文件传输请求后就创建“数据传送进程"和“数据连接"，用来连接客户端和服务器端的数据传送进程。数据传送进程实际完成文件的传送，在传送完毕后关闭“数据传送连接”并结束运行。由于FTP使用了一个分离的控制连接，因此FTP的控制信息是带外(out of band)传送的。

当客户进程向服务器进程发出建立连接请求时，要寻找连接服务器进程的熟知端口 21，同时还要告诉服务器进程自己的另一个端口号码，用于建立数据传送连接。接着，服务器进程用自己传送数据的熟知端口 20与客户进程所提供的端口号建立数据传送连接。由于FTP使用了两个不同的端口号，所以数据连接与控制连接不会发生混乱。

使用两个独立的连接的主要好处是使协议更加简单和更容易实现，同时在传输文件时还可以利用控制连接对文件的传输进行控制。例如，客户发送“请求终止传输“。

FTP并非对所有的数据传输都是最佳的。例如，计算机A上运行的应用程序要在远地计算机B的一个很大的文件末尾添加一行信息。若使用FTP，则应先将此文件从计算机B传送到计算机A，添加上这一行信息后，再用FTP将此文件传送到计算机B，来回传送这样大的文件很花时间。实际上这种传送是不必要的，因为计算机A并没有使用该文件的内容。

然而网络文件系统NFS则釆用另一种思路。NFS允许应用进程打开一个远地文件，井能在该文件的某一个特定的位置上开始读写数据。这样，NFS可使用户只复制一个大文件中的一个很小的片段，而不需要复制整个大文件。对于上述例子，计算机A中的NFS客户软件，把要添加的数据和在文件后面写数据的请求一起发送到远地的计算机B中的NFS服务器，NFS服务器更新文件后返回应答信息。在网络上传送的只是少童的修改数据。

简单文件传送协议TFTP

TCP/IP协议族中还有一个简单文件传送协议TFTP (Trivial File Transfer Protocol)，它是一个很小且易于实现的文件传送协议。TFTP的版本2是互联网的正式标准［RFC 1350］。虽然TFTP也使用客户服务器方式，但它使用UDP数据报，因此TFTP需要有自己的差错改正措施。TFTP只支持文件传输而不支持交互。TFTP没有一个庞大的命令集，没有列目录的功能，也不能对用户进行身份鉴别。

TFTP的主要优点有两个：

第一，TFTP可用于UDP环境。例如，当需要将程序或文件同时向许多机器下载时就往往需要使用TFTPo

第二，TFTP代码所占的内存较小。这对较小的计算机或某些特殊用途的设备是很重要的。这些设备不需要硬盘，只需要固化了TFTP、UDP和IP的小容量只读存储器即可。当接通电源后，设备执行只读存储器中的代码，在网络上广播一个TFTP请求。网络上的TFTP服务器就发送响应，其中包括可执行二进制程序。设备收到此文件后将其放入内存，然后开始运行程序。这种方式增加了灵活性，也减少了开销。

TFTP的主要特点是：

每次传送的数据报文中有512字节的数据，但最后一次可不足512字节。
数据报文按序编号，从1开始。
支持ASCU码或二进制传送。
可对文件进行读或写。
使用很简单的首部。

TFTP的工作很像停止等待协议。发送完一个文件块后就等待对方的确认，确认时应指明所确认的块编号。发完数据后在规定时间内收不到确认就要重发数据PDU。发送确认PDU的一方若在规定时间内收不到下一个文件块，也要重发确认PDU。这样就可保证文件的传送不致因某一个数据报的丢失而告失败。

在一开始工作时。TFTP客户进程发送一个读请求报文或写请求报文给TFTP服务器进程，其熟知端口号码为69。TFTP服务器进程要选择一个新的端口和TFTP客户进程进行通信。若文件长度恰好为512字节的整数倍，则在文件传送完毕后，还必须在最后发送一个只含首部而无数据的数据报文。若文件长度不是512字节的整数倍，则最后传送数据报文中的数据字段一定不满512字节，这正好可作为文件结束的标志。

远程终端协议TELNET

TELNET是一个简单的远程终端协议[RFC 854]，它也是互联网的正式标准。

用户用TELNET就可在其所在地通过TCP连接注册(即登录)到远地的另一台主机上(使用主机名或IP地址)。TELNET能将用户的击键传到远地主机，同时也能将远地主机的输出通过TCP连接返回到用户屏幕。这种服务是透明的，因为用户感觉到好像键盘和显示器是直接连在远地主机上。因此，TELNET又称为终端仿真协议。

TELNET并不复杂，以前应用得很多。现在由于计算机的功能越来越强，用户已较少使用 TELNET 了。

TELNET也使用客户服务器方式。在本地系统运行TELNET客户进程，而在远地主机则运行TELNET服务器进程。和FTP的情况相似，服务器中的主进程等待新的请求，并产生从属进程来处理每一个连接。

TELNET能够适应许多计算机和操作系统的差异。为了适应这种差异，TELNET定义了数据和命令应怎样通过互联网。这些定义就是所谓的网络虚拟终端NVT (Network Virtual Terminal)。图6-7说明了 NVT的意义。客户软件把用户的击键和命令转换成NVT格式，并送交服务器。服务器软件把收到的数据和命令从NVT格式转换成远地系统所需的格式。向用户返回数据时，服务器把远地系统的格式转换为NVT格式，本地客户再从NVT格式转换到本地系统所需的格式。

NVT的格式定义很简单。所有的通信都使用8位一个字节。在运转时，NVT使用7位ASCU码传送数据，而当高位置1时用作控制命令。

万维网WWW

万维网概述

万维网WWW (World Wide Wbb)并非某种特殊的计算机网络。万维网是一个大规模的、联机式的信息储藏所，英文简称为Web。万维网用链接的方法能非常方便地从互联网上的一个站点访问另一个站点(也就是所谓的“链接到另一个站点”)，从而主动地按需获取丰富的信息。图6-8说明了万维网提供分布式服务的特点。

图6-8画出了五个万维网上的站点，它们可以相隔数千公里，但都必须连接在互联网上。每一个万维网站点都存放了许多文档。在这些文档中有一些地方的文字是用特殊方式显示的（例如用不同的颜色，或添加了下划线），而当我们将鼠标移动到这些地方时，鼠标的箭头就变成了一只手的形状。这就表明这些地方有一个链接（link）（这种链接有时也称为超链hyperlink）,如果我们在这些地方点击鼠标，就可以从这个文档链接到可能相隔很远的另一个文档。经过一定的时延(几秒钟、几分钟甚至更长，取决于所链接的文档的大小和网络的拥塞情况)，在我们的屏幕上就能将远方传送过来的文档显示出来。

万维网是一个分布式的超媒体(hypermedia)系统，它是超文本(hypertext)系统的扩充。所谓超文本是指包含指向其他文档的链接的文本(text)。也就是说，一个超文本由多个信息源链接成，而这些信息源可以分布在世界各地，并且数目也是不受限制的。利用一个链接可使用户找到远在异地的另一个文档，而这又可链接到其他的文档(依此类推)。这些文档可以位于世界上任何一个接在互联网上的超文本系统中。超文本是万维网的基础。

超媒体与超文本的区别是文档内容不同。超文本文档仅包含文本信息，而超媒体文档还包含其他表示方式的信息，如图形、图像、声音、动画以及视频图像等。

分布式的和非分布式的超媒体系统有很大区别。在非分布式系统中，各种信息都驻留在单个计算机的磁盘中。由于各种文档都可从本地获得，因此这些文档之间的链接可进行致性检査。所以，一个非分布式超媒体系统能够保证所有的链接都是有效的和一致的。

万维网把大量信息分布在整个互联网上。每台主机上的文档都独立进行管理。对这些文档的增加、修改、删除或重新命名都不需要(实际上也不可能)通知到互联网上成千上万的节点。这样，万维网文档之间的链接就经常会不一致。例如，主机A上的文档X本来包含了一个指向主机B上的文档Y的链接。若主机B的管理员在某日删除了文档Y，那么主机A的上述链接显然就失效了。

万维网以客户服务器方式工作。上面所说的浏览器就是在用户主机上的万维网客户程序。万维网文档所驻留的主机则运行服务器程序，因此这台主机也称为万维网服务器。客户程序向服务器程序发出请求，服务器程序向客户程序送回客户所要的万维网文档。在一个客户程序主窗口上显示出的万维网文档称为页面(page)。

从以上所述可以看出，万维网必须解决以下几个问题：

怎样标志分布在整个互联网上的万维网文档？
用什么样的协议来实现万维网上的各种链接？
怎样使不同作者创作的不同风格的万维网文档，都能在互联网上的各种主机上显示出来，同时使用户清楚地知道在什么地方存在着链接？
怎样使用户能够很方便地找到所需的信息？

为了解决第一个问题，万维网使用统一资源定位符URL (Uniform Resource Locator)来标志万维网上的各种文档，并使每一个文档在整个互联网的范围内具有唯一的标识符URL。

为了解决上述的第二个问题，就要使万维网客户程序与万维网服务器程序之间的交互遵守严格的协议，这就是超文本传送协议HTTP (HyperText Transfer Protocol)。HTTP是一个应用层协议，它使用TCP连接进行可靠的传送。

为了解决上述的第三个问题，万维网使用超文本标记语言HTML (HyperText Markup Language).使得万维网页面的设计者可以很方便地用链接从本页面的某处链接到互联网上的任何一个万维网页面，并且能够在自己的主机屏幕上将这些页面显示出来。最后，用户可使用搜索工具在万维网上方便地査找所需的信息。

统一资源定位符URL

URL格式

统一资源定位符URL是用来表示从互联网上得到的资源位置和访问这些资源的方法。URL给资源的位置提供一种抽象的识别方法，并用这种方法给资源定位。只要能够对资源定位，系统就可以对资源进行各种操作，如存取、更新、替换和查找其属性。由此可见，URL实际上就是在互联网上的资源的地址。只有知道了这个资源在互联网上的什么地方，才能对它进行操作。显然，互联网上的所有资源，都有一个唯一确定的URL。

这里所说的“资源”是指在互联网上可以被访问的任何对象，包括文件目录、文件、文档、图像、声音等，以及与互联网相连的任何形式的数据。"资源"还包括电子邮件的地址和USENET新闻组，或USENET新闻组中的报文。

URL相当于一个文件名在网络范围的扩展。因此，URL是与互联网相连的机器上的任何可访问对象的一个指针。由于访问不同对象所使用的协议不同，所以URL还指出读取某个对象时所使用的协议。URL的一般形式由以下四个部分组成：

<协议>//<主机>:<端口><路径>

URL的第一部分是最左边的<协议>。这里的<协议>就是指出使用什么协议来获取该万维网文档。现最常用的协议就是http （超文本传送协议HTTP），其次是ftp （文件传送协议 FTP）。

在<协议>后面的是规定的格式。它的左边是第二部分<主机>，它指出这个万维网文档是在哪一台主机上。这里的<主机>就是指该主机在互联网上的域名。再后面是第三和第四部分<端口>和<路径>，有时可省略。

现在有些浏览器为了方便用户，在输入URL时，可以把最前面的“http://”甚至把主机名最前面的“www”省略，然后浏览器替用户把省略的字符添上。

下面我们简单介绍使用得最多的一种URL。

使用HTTP的URL

对于万维网的网点的访问要使用HTTP协议。HTTP的URL的一般形式是：

http://<主机>:<端口>/<路径>

HTTP的默认端口号是80，通常可省略。若再省略文件的<路径>项，则URL就指到互联网上的某个主页(homepage)。主页是个很重要的概念，它可以是以下几种情况之一：

一个WWW服务器的最高级别的页面。
某一个组织或部门的一个定制的页面或目录。从这样的页面可链接到互联网上的与本组织或部门有关的其他站点。
由某一个人自己设计的描述他本人情况的www页面。
例如，要査有关清华大学的信息，就可先进入到清华大学的主页，其URL为：
http://www.tsinghua.edu.cn
这里省略了默认的端口号80。我们从清华大学的主页入手，就可以通过许多不同的链接找到所要査找的各种有关清华大学各个部门的信息。

更复杂一些的路径是指向层次结构的从属页面。例如：
http://www.tsinghua.edu.cn/publish/newthu/newthu_cnt/faculties/index.html

是清华大学的“院系设置”页面的URL。注意：上面的URL中使用了指向文件的路径，而文件名就是最后的mdex.htm。后缀htm (有时可写为html)表示这是一个用超文本标记语言HTML写出的文件。

URL里面的字母不分大小写，但为了便于阅读，有时故意使用一些大写字母。

用户使用URL并非仅仅能够访问万维网的页面，而且还能够通过URL使用其他的互联网应用程序，如FTP或USENET新闻组等。更重要的是，用户在使用这些应用程序时，只使用一个程序，即浏览器。这显然是非常方便的。

超文本传送协议HTTP

HTTP的操作过程

HTTP协议定义了浏览器(即万维网客户进程)怎样向万维网服务器请求万维网文档，以及服务器怎样把文档传送给浏览器。

从层次的角度看，HTTP是面向事务的(transaction-oriented) 应用层协议，它是万维网上能够可靠地交换文件(包括文本、声音、图像等各种多媒体文件)的重要基础。请注意，HTTP不仅传送完成超文本跳转所必需的信息，而且也传送任何可从互联网上得到的信息，如文本、超文本、声音和图像等。

万维网的大致工作过程如图6-9所示。

每个万维网网点都有一个服务器进程，它不断地监听TCP的端口 80，以便发现是否有浏览器（即万维网客户。请注意，浏览器和万维网客户是同义词）向它发出连接建立请求。一旦监听到连接建立请求并建立了 TCP连接之后，浏览器就向万维网服务器发出浏览某个页面的请求，服务器接着就返回所请求的页面作为响应。最后，TCP连接就被释放了。在浏览器和服务器之间的请求和响应的交互，必须按照规定的格式和遵循一定的规则。这些格式和规则就是超文本传送协议HTTP。

HTTP规定在HTTP客户与HTTP服务器之间的每次交互，都由一个ASII码串构成的请求和一个类似的通用互联网扩充，即“类MIME （MWE-like）”的响应组成。HTTP报文通常都使用TCP连接传送。

用户浏览页面的方法有两种。一种方法是在浏览器的地址窗口中键入所要找的页面的URL。另一种方法是在某一个页面中用鼠标点击一个可选部分，这时浏览器会自动在互联网上找到所要链接的页面。

HTTP使用了面向连接的TCP作为运输层协议，保证了数据的可靠传输。HTTP不必考虑数据在传输过程中被丢弃后又怎样被重传。但是，HTTP协议本身是无连接的。这就是说，虽然HTTP使用了 TCP连接，但通信的双方在交换HTTP报文之前不需要先建立HTTP连接。

HTTP协议是无状态的（stateless）。也就是说，同一个客户第二次访问同一个服务器上的页面时，服务器的响应与第一次被访问时的相同（假定现在服务器还没有把该页面更新），因为服务器并不记得曾经访问过的这个客户，也不记得为该客户曾经服务过多少次。HTTP的无状态特性简化了服务器的设计，使服务器更容易支持大量并发的HTTP请求。

下面我们粗略估算一下，从浏览器请求一个万维网文档到收到整个文档所需的时间（图6-10）。

用户在点击鼠标链接某个万维网文档时，HTTP协议首先要和服务器建立TCP连接。这需要使用三报文握手。当建立TCP连接的三报文握手的前两部分完成后（即经过了一个RTT时间后），万维网客户就把HTTP请求报文，作为建立TCP连接的三报文握手中的第三个报文的数据，发送给万维网服务器。服务器收到HTTP请求报文后，就把所请求的文档作为响应报文返回给客户。

从图6-10可看出，请求一个万维网文档所需的时间是该文档的传输时间（与文档大小成正比）加上两倍往返时间RTT（一个RTT用于连接TCP连接，另一个RTT用于请求和接收万维网文档。TCP建立连接的三报文握手的第三个报文段中的数据，就是客户对万维网文档的请求报文）。

HTTP/1.0的主要缺点，就是每请求一个文档就要有两倍RTT的开销。若一个主页上有很多链接的对象（如图片等）需要依次进行链接，那么每一次链接下载都导致2xRTT的开销。另一种开销就是万维网客户和服务器每一次建立新的TCP连接都要分配缓存和变量。特别是万维网服务器往往要同时服务于大量客户的请求，所以这种非持续连接会使万维网服务器的负担很重。好在浏览器都能够打开5~10个并行的TCP连接，而每一个TCP连接处理客户的一个请求。因此，使用并行TCP连接可以缩短响应时间。

HTTP/1.1协议较好地解决了这个问题，它使用了持续连接（persistent connection）。所谓持续连接就是万维网服务器在发送响应后仍然在一段时间内保持这条连接，使同一个客户（浏览器）和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。这并不局限于传送同一个页面上链接的文档，而是只要这些文档都在同一个服务器上就行。目前一些流行的浏览器（如IE 11.0）的默认设置就使用了 HTTP/1.1。如果用户不愿意使用持续连接的浏览器，可以选择IE浏览器上面的“工具” “Internet选项"一“高级"等项目，把“HTTP 1.1设置”的选择取消即可。

HTTP/1.1协议的持续连接有两种工作方式，即非流水线方式（without pipelining）和流水线方式（with pipelining）。

非流水线方式的特点，是客户在收到前一个响应后才能发出下一个请求。因此，在TCP连接已建立后，客户每访问一次对象都要用去一个往返时间RTT。这比非持续连接要用去两倍RTT的开销，节省了建立TCP连接所需的一个RTT时间。但非流水线方式还是有缺点的，因为服务器在发送完一个对象后，其TCP连接就处于空闲状态，浪费了服务器资源。

流水线方式的特点，是客户在收到HTTP的响应报文之前就能够接着发送新的请求报文。于是一个接一个的请求报文到达服务器后，服务器就可连续发回响应报文。因此，使用流水线方式时，客户访问所有的对象只需花费一个RTT时间。流水线工作方式使TCP连接中的空闲时间减少，提高了下载文档效率。

代理服务器

代理服务器(proxy server)是一种网络实体，它又称为万维网高速缓存(Web cache)。、

代理服务器把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时，若代理服务器发现这个请求与暂时存放的请求相同，就返回暂存的响应，而不需要按URL的地址再次去互联网访问该资源。代理服务器可在客户端或服务器端工作，也可在中间系统上工作。

下面我们用例子说明它的作用。

设图6-11(a)是校园网不使用代理服务器的情况。这时，校园网中所有的计算机都通过2Mbit/s专线链路(R1-R2)与互联网上的源点服务器建立TCP连接。因而校园网各计算机访问互联网的通信量往往会使这条2Mbit/s的链路过载，使得时延大大增加。

图6-11(b)是校园网使用代理服务器的情况。这时，访问互联网的过程是这样的：

校园网的计算机中的浏览器向互联网的服务器请求服务时，就先和校园网的代理服务器建立TCP连接，并向代理服务器发岀HTTP请求报文(见图6-11(b)中的①)。
若代理服务器己经存放了所请求的对象，代理服务器就把这个对象放入HTTP响应报文中返回给计算机的浏览器。
否则，代理服务器就代表发出请求的用户浏览器，与互联网上的源点服务器(originserver)建立TCP连接(如图6-11(b)中的②所示)，并发送HTTP请求报文。

源点服务器把所请求的对象放在HTTP响应报文中返回给校园网的代理服务器。
代理服务器收到这个对象后，先复制在自己的本地存储器中(留待以后用)，然后再把这个对象放在HTTP响应报文中，通过已建立的TCP连接(见图6-11(b)中的。)，返回给请求该对象的浏览器。

我们注意到，代理服务器有时是作为服务器（当接受浏览器的HTTP请求时），但有时却作为客户（当向互联网上的源点服务器发送HTTP请求时）。

在使用代理服务器的情况下，由于有相当大一部分通信量局限在校园网的内部，因此，2Mbit/s专线链路（R1-R2）上的通信量大大减少，因而减小了访问互联网的时延。

HTTP的报文结构

HTTP有两类报文：

请求报文——从客户向服务器发送请求报文，见图6 -12(a)。
响应报文——从服务器到客户的回答，见图6-12(b)。

由于HTTP是面向文本的(text-oriented)，因此在报文中的每一个字段都是一些ASCII码串，因而各个字段的长度都是不确定的。

HTTP请求报文和响应报文都是由三个部分组成的。可以看出，这两种报文格式的区别就是开始行不同。

开始行，用于区分是请求报文还是响应报文。在请求报文中的开始行叫做请求行(Request-Line)，而在响应报文中的开始行叫做状态行(Status-Line)。在开始行的三个字段之间都以空格分隔开，最后的“CR"和“LF”分别代表“回车”和“换行”。
首部行，用来说明浏览器、服务器或报文主体的一些信息。首部可以有好几行，但也可以不使用。在每一个首部行中都有首部字段名和它的值，每一行在结束的地方都要有“回车”和“换行”。整个首部行结束时，还有一空行将首部行和后面的实体主体分开。
实体主体(entity body)，在请求报文中一般都不用这个字段，而在响应报文中也可能没有这个字段。

下面先介绍HTTP请求报文的一些主要特点。

请求报文的第一行“请求行”只有三个内容，即方法，请求资源的URL，以及HTTP的版本。

所谓“方法”就是对所请求的对象进行的操作，这些方法实际上也就是一些命令。因此，请求报文的类型是由它所釆用的方法决定的。表6-1给出了请求报文中常用的几种方法。

下面是HTTP的请求报文的开始行（即请求行）的格式。请注意，在GET后面有一个空格，接着是某个完整的URL，其后面又有一个空格，最后是HTTP/1.1

GET http://www.xyz.edu.cn/dir/index.htm HTTP/1.1

下面是一个完整的HTTP请求报文的例子:

GET /dir/index.htm HTTP/1.1 ｛请求行使用了相对URL｝
Host: www.xyz.edu.cn ｛此行是首部行的开始。这行给出主机的域名｝
Connection: close ｛告诉服务器发送完请求的文档后就可释放连接｝
User-Agent: Mozilla/5.0 ｛表明用户代理是使用火狐浏览器Firefox）
Accept-Language: cn ｛表示用户希望优先得到中文版本的文档｝
｛请求报文的最后还有一个空行｝

在请求行使用了相对URL （即省略了主机的域名）是因为下面的首部行（第2行）给岀了主机的域名。第3行是告诉服务器不使用持续连接，表示浏览器希望服务器在传送完所请求的对象后即关闭TCP连接。这个请求报文没有实体主体。

再看一下HTTP响应报文的主要特点。

每一个请求报文发出后，都能收到一个响应报文。响应报文的第一行就是状态行。状态行包括三项内容，即HTTP的版本，状态码，以及解释状态码的简单短语。

状态码（Status-Code）都是三位数字的，分为5大类，这5大类的状态码都是以不同的数字开头的。

Ixx表示通知信息，如请求收到了或正在进行处理。
2xx表示成功，如接受或知道了。
3xx表示重定向，如要完成请求还必须釆取进一步的行动。
4xx表示客户的差错，如请求中有错误的语法或不能完成。
5xx表示服务器的差错，如服务器失效无法完成请求。

下面三种状态行在响应报文中是经常见到的。

HTTP/1.1 202 Accepted ｛接受｝
HTTP/1.1 400 Bad Request ｛错误的请求｝
HTTP/1.1 404 Not Found ｛找不到｝

若请求的网页从http://www.ee.xyz.edu/index.html转移到了一个个新的地址，则响应报文的状态行和一个首部行就是下面的形式：

HTTP/1.1 301 Moved Permanently ｛永久性地转移了｝
Location: http://www.xyz.edu/ee/index.html ｛新的URL｝

在服务器上存放用户的信息

在本节（6.4.3节）第1小节“HTTP的操作过程”中已经讲过，HTTP是无状态的。这样做虽然简化了服务器的设计，但在实际工作中，一些万维网站点却常常希望能够识别用户。例如，在网上购物时，一个顾客要购买多种物品。当他把选好的一件物品放入“购物车”后，他还要继续浏览和选购其他物品。因此，服务器需要记住用户的身份，使他接着选购的一些物品能够放入同一个“购物车"中，这样就便于集中结账。有时某些万维网站点也可能想限制某些用户的访问。要做到这点，可以在HTTP中使用Cookie。在RFC 6265中对Cookie进行了定义，规定万维网站点可以使用Cookie来跟踪用户。Cookie原意是“小甜饼”（广东人用方言音译为“曲奇"），目前尚无标准译名，在这里Cookie表示在HTTP服务器和客户之间传递的状态信息。现在很多网站都巳广泛使用Cookie。

Cookie是这样工作的。当用户A浏览某个使用Cookie的网站时，该网站的服务器就为A产生一个唯一的识别码，并以此作为索引在服务器的后端数据库中产生一个项目。接着在给A的HTTP响应报文中添加一个叫做Set-cookie的首部行。这里的“首部字段名"就是“Set-cookie”，而后面的“值”就是赋予该用户的“识别码”。例如这个首部行是这样的：

Set-cookie: 31d4d96e407aad42

当A收到这个响应时，其浏览器就在它管理的特定Cookie文件中添加一行，其中包括这个服务器的主机名和Set-cookie后面给出的识别码。当A继续浏览这个网站时，每发送一个HTTP请求报文，其浏览器就会从其Cookie文件中取出这个网站的识别码，并放到HTTP请求报文的Cookie首部行中：

Cookie: 31d4d96e407aad42

于是，这个网站就能够跟踪用户31d4d96e407aad42 （用户A）在该网站的活动。需要注意的是，服务器并不需要知道这个用户的真实姓名以及其他的信息。但服务器能够知道用户31d4d96e407aad42在什么时间访问了哪些页面，以及访问这些页面的顺序。

如果A在几天后再次访问这个网站，那么他的浏览器会在其HTTP请求报文中继续使用首部行Cookie: 31d4d96e407aad42，而这个网站服务器根据A过去的访问记录可以向他推荐商品。如果A己经在该网站登记过和使用过信用卡付费，那么这个网站就已经保存了 A的姓名、电子邮件地址、信用卡号码等信息。这样，当A继续在该网站购物时，只要还使用同一个电脑上网，由于浏览器产生的HTTP请求报文中都携带了同样的Cookie首部行，服务器就可利用Cookie来验证出这是用户A,因此以后A在这个网站购物时就不必
重新在键盘上输入姓名、信用卡号码等信息。这对顾客显然是很方便的。

尽管Cookie能够简化用户网上购物的过程，但Cookie的使用一直引起很多争议。有人认为Cookie会把计算机病毒带到用户的计算机中。其实这是对Cookie的误解。Cookie只是一个小小的文本文件，不是计算机的可执行程序，因此不可能传播计算机病毒，也不可能用来获取用户计算机硬盘中的信息。对于Cookie的另一个争议，是关于用户隐私的保护问题。例如，网站服务器知道了A的一些信息，就有可能把这些信息出卖给第三方。Cookie还可用来收集用户在万维网网站上的行为。这些都属于用户个人的隐私。有些网站为了使顾客放心，就公开声明他们会保护顾客的隐私，绝对不会把顾客的识别码或个人信息出售或转
移给其他厂商。

万维网的文档

超文本标记语言HTML

要使任何一台计算机都能显示出任何一个万维网服务器上的页面，就必须解决页面制作的标准化问题。超文本标记语言HTML （HyperText Markup Language）就是一种制作万维网页面的标准语言，它消除了不同计算机之间信息交流的障碍。但请注意，HTML并不是应用层的协议，它只是万维网浏览器使用的一种语言。由于HTML非常易于掌握且实施简单，因此它很快就成为万维网的重要基础。官方的HTML标准由万维网联盟W3C （即 WWW Consortium）负责制定。

HTML定义了许多用于排版的命令，即“标签”（tag）气例如，＜I＞表示后面开始用斜体字排版，而＜/I＞则表示斜体字排版到此结束。HTML把各种标签嵌入到万维网的页面中，这样就构成了所谓的HTML文档。HTML文档是一种可以用任何文本编辑器（例如，Windows的记事本Notepad）创建的ASCII码文件。但应注意，仅当HTML文档是以.html或.htm为后缀时，浏览器才对这样的HTML文档的各种标签进行解释。如果HTML文档改为以.txt为其后缀，则HTML解释程序就不对标签进行解释，而浏览器只能看见原来的文本文件。

并非所有的浏览器都支持所有的HTML标签。若某一个浏览器不支持某一个HTML标签，则浏览器将忽略此标签，但在一对不能识别的标签之间的文本仍然会被显示出来。

下面是一个简单例子，用来说明HTML文档中标签的用法。在每一个语句后面的花括号中的字是给读者看的注释，在实际的HTML文档中并没有这种注释。

HTML还规定了链接的设置方法。每个链接都有一个起点和终点。
远程链接：超链的终点是其他网点上的页面。
本地链接：超链指向本计算机中的某个文件。

XML (Extensible Markup Language) 是可扩展标记语言，它和 HTML 很相似。
但 XML 的设计宗旨是传输数据，而不是显示数据（HTML 是为了在浏览器上显示数据）。
XML 不是要替换 HTML，而是对 HTML 的补充。

XHTML (Extensible HTML) 是可扩展超文本标记语言，它与 HTML 4.01 几乎是相同的。
但 XHTML 是更严格的 HTML 版本，也是一个 W3C 标准（2000年1月），是作为一种 XML 应用被重新定义的 HTML，并将逐渐取代 HTML。
新的浏览器都支持 XHTML。

CSS (Cascading Style Sheets) 是层叠样式表，它是一种样式表语言，用于为 HTML 文档定义布局。
CSS 与 HTML 的区别就是：HTML 用于结构化内容，而 CSS 则用于格式化结构化的内容。

动态万维网文档

上面所讨论的万维网文档只是万维网文档中最基本的一种，即所谓的静态文档(staticdocument)，静态文档在文档创作完毕后就存放在万维网服务器中，在被用户浏览的过程中，内容不会改变。由于这种文档的内容不会改变，因此用户对静态文档的每次读取所得到的返回结果都是相同的。

静态文档的最大优点是简单。由于HTML是一种排版语言，因此静态文档可以由不懂程序设计的人员来创建。但静态文档的缺点是不够灵活。当信息变化时就要由文档的作者手工对文档进行修改。可见，变化频繁的文档不适于做成静态文档。

动态文档(dynamic document)是指文档的内容是在浏览器访问万维网服务器时才由应用程序动态创建的。当浏览器请求到达时，万维网服务器要运行另一个应用程序，并把控制转移到此应用程序。接着，该应用程序对浏览器发来的数据进行处理，并输出HTTP格式的文档，万维网服务器把应用程序的输出作为对浏览器的响应。由于对浏览器每次请求的响应都是临时生成的，因此用户通过动态文档所看到的内容是不断变化的。动态文档的主要优点是具有报告当前最新信息的能力。例如，动态文档可用来报告股市行情、天气预报或民航售票情况等内容。但动态文档的创建难度比静态文档的高，因为动态文档的开发不是直接编写文档本身，而是编写用于生成文档的应用程序，这就要求动态文档的开发人员必须会编程，而
所编写的程序还要通过大范围的测试，以保证输入的有效性。

动态文档和静态文档之间的主要差别体现在服务器一端。这主要是文档内容的生成方法不同。而从浏览器的角度看，这两种文档并没有区别。动态文档和静态文档的内容都遵循HTML所规定的格式，浏览器仅根据在屏幕上看到的内容无法判定服务器送来的是哪一种文档，只有文档的开发者才知道。从以上所述可以看出，要实现动态文档就必须在以下两个方面对万维网服务器的功能进行扩充：

应増加另一个应用程序，用来处理浏览器发来的数据，并创建动态文档。
应增加一个机制，用来使万维网服务器将浏览器发来的数据传送给这个应用程序，然后万维网服务器能够解释这个应用程序的输出，并向浏览器返回HTML文档。

图6-14是扩充了功能的万维网服务器的示意图。这里增加了一个机制，叫做通用网关接口 CGI (Common Gateway Internee)。CGI是一种标准，它定义了动态文档应如何创建，输入数据应如何提供给应用程序，以及输出结果应如何使用。

在万维网服务器中新增加的应用程序叫做CGI程序。

CGI程序的正式名字是CGI脚本(script)。按照计算机科学的一般概念，“脚本"①指的是一个程序，它被另一个程序(解释程序)而不是计算机的处理机来解释或执行。有一些语言专门作为脚本语言(script language)，如Peri,，REXX (在IBM主机上使用)，JavaScript以及Tcl/Tk等。脚本也可用一些常用的编程语言写出，如C, C++等。使用脚本语言可更容易和更快地进行编码，这对一些有限功能的小程序是很合适的。但一个脚本运行起来比一般的编译程序要慢，因为它的每一条指令先要被另一个程序来处理(这就要一些附加的指令)，而不是直接被指令处理器来处理。脚本不一定是一个独立的程序，它可以是一个动态装入的库，甚至是服务器的一个子程序。

CGI程序又称为cgi-bin脚本，这是因为在许多万维网服务器上，为便于找到CGI程序，就将CGI程序放在/cgi-bin的目录下。

活动万维网文档

随着HTTP和万维网浏览器的发展，上一节所述的动态文档已明显地不能满足发展的需要。这是因为，动态文档一旦建立，它所包含的信息内容也就固定下来而无法及时刷新屏幕。另外，像动画之类的显示效果，动态文档也无法提供。

有两种技术可用于浏览器屏幕显示的连续更新。一种技术称为服务器推送(serverpush)，这种技术是将所有的工作都交给服务器。服务器不断地运行与动态文档相关联的应用程序，定期更新信息，并发送更新过的文档。

尽管从用户的角度看，这样做可达到连续更新的目的，但这也有很大的缺点。首先，为了满足很多客户的请求，服务器就要运行很多服务器推送程序。这将造成过多的服务器开销。其次，服务器推送技术要求服务器为每一个浏览器客户维持一个不释放的TCP连接。随着TCP连接的数目增加，每一个连接所能分配到的网络带宽就下降，这就导致网络传输时延的增大。

另一种提供屏幕连续更新的技术是活动文档(active document)o这种技术是把所有的工作都转移给浏览器端。每当浏览器请求一个活动文档时，服务器就返回一段活动文档程序副本，使该程序副本在浏览器端运行。这时，活动文档程序可与用户直接交互，并可连续地改变屏幕的显示。只要用户运行活动文档程序，活动文档的内容就可以连续地改变。由于活动文档技术不需要服务器的连续更新传送，对网络带宽的要求也不会太高。

从传送的角度看，浏览器和服务器都把活动文档看成是静态文档。在服务器上的活动文档的内容是不变的，这点和动态文档是不同的。浏览器可在本地缓存一份活动文档的副本。活动文档还可处理成压缩形式，以便于存储和传送。另一点要注意的是，活动文档本身并不包括其运行所需的全部软件，大部分的支持软件是事先存放在浏览器中的。图6-15说明了活动文档的创建过程。

由美国SUN公司开发的Java语言是一项用于创建和运行活动文档的技术。在Java技
术中使用了一个新的名词“小应用程序”（applet）①来描述活动文档程序。当用户从万维网服
务器下载一个嵌入了 Java小应用程序的HTML文档后，用户可在浏览器的显示屏幕上点击
某个图像，然后就可看到动画的效果；或是在某个下拉式菜单中点击某个项目，即可看到根
据用户键入的数据所得到的计算结果。实际上，Java技术是活动文档技术的一部分。限于
篇幅，有关Java技术的进一步讨论这里从略。

动态主机配置协议DHCP

**为了把协议软件做成通用的和便于移植的，协议软件的编写者不会把所有的细节都固定在源代码中。相反，他们把协议软件参数化。**这就使得在很多台计算机上有可能使用同一个经过编译的二进制代码。一台计算机和另一台计算机的许多区别，都可以通过一些不同的参数来体现。在协议软件运行之前，必须给每一个参数赋值。

在协议软件中给这些参数赋值的动作叫做协议配置。一个协议软件在使用之前必须是已正确配置的。具体的配置信息有哪些则取决于协议栈。

例如，连接到互联网的计算机的协议软件需要配置的项目包括：

IP地址；
子网掩码；
默认路由器的IP地址；
域名服务器的IP地址。

为了省去给计算机配置IP地址的麻烦，我们能否在计算机的生产过程中，事先给每一台计算机配置好一个唯一的IP地址呢(如同每一个以太网适配器拥有一个唯一的硬件地址)？这显然是不行的。这是因为IP地址不仅包括了主机号，而且还包括了网络号。一个IP地址指岀了一台计算机连接在哪一个网络上。当计算机还在生产时，无法知道它在出厂后将被连接到哪一个网络上。因此，需要连接到互联网的计算机，必须对IP地址等项目进行协议配置。

用人工进行协议配置很不方便，而且容易出错。因此，应当采用自动协议配置的方法。

互联网现在广泛使用的是动态主机配置协议DHCP (Dynamic Host ConfigurationProtocol)，它提供了一种机制，称为即插即用连网(plug-and-play netwoiking)。这种机制允许一台计算机加入新的网络和获取IP地址而不用手工参与。

DHCP对运行客户软件和服务器软件的计算机都适用。当运行客户软件的计算机移至一个新的网络时，就可使用DHCP获取其配置信息而不需要手工干预。DHCP给运行服务器软件而位置固定的计算机指派一个永久地址，而当这计算机重新启动时其地址不改变。

DHCP使用客户服务器方式。需要IP地址的主机在启动时就向DHCP服务器广播发送发现报文(DHCPDISCOVER)(将目的IP地址置为全1，即255.255.255.255)，这时该主机就成为DHCP客户。发送广播报文是因为现在还不知道DHCP服务器在什么地方，因此要发现(DISCOVER) DHCP服务器的IP地址。这台主机目前还没有自己的IP地址，因此它将IP数据报的源IP地址设为全0。这样，在本地网络上的所有主机都能够收到这个广播报文，但只有DHCP服务器才对此广播报文进行回答。DHCP服务器先在其数据库中査找该计算机的配置信息。若找到，则返回找到的信息。若找不到，则从服务器的IP地址池(address pool)中取一个地址分配给该计算机。DHCP服务器的回答报文叫做提供报文(DHCPOFFER)，表示“提供"了 IP地址等配置信息。

但是我们并不愿意在每一个网络上都设置一个DHCP服务器，因为这样会使DHCP服务器的数量太多。因此现在是使每一个网络至少有一个DHCP中继代理(relay agent)(通常是一台路由器，见图6-19)，它配置了 DHCP服务器的IP地址信息。当DHCP中继代理收到主机A以广播形式发送的发现报文后，就以单播方式向DHCP服务器转发此报文，并等待其回答。收到DHCP服务器回答的提供报文后，DHCP中继代理再把此提供报文发回给主机A。需要注意的是，图6-19只是个示意图。实际上，DHCP报文只是UDP用户数据报的数据，它还要加上UDP首部、IP数据报首部，以及以太网的MAC帧的首部和尾部后，才能在链路上传送。

DHCP服务器分配给DHCP客户的IP地址是临时的，因此DHCP客户只能在一段有限的时间内使用这个分配到的IP地址。DHCP协议称这段时间为租用期(lease period)，但并没有具体规定租用期应取为多长或至少为多长，这个数值应由DHCP服务器自己决定。例如，一个校园网的DHCP服务器可将租用期设定为1小时。DHCP服务器在给DHCP发送的提供报文的选项中给出租用期的数值。按照RFC 2132的规定，租用期用4字节的二进制数字表示，单位是秒。因此可供选择的租用期范围从1秒到136年。DHCP客户也可在自己发送的报文中(例如，发现报文)提出对租用期的要求。

DHCP的详细工作过程如图6-20所示。DHCP客户使用的UDP端口是68，而DHCP服务器使用的UDP端口是67。这两个UDP端口都是熟知端口。

下面按照图6-20中的注释编号（1~9）进行简单的解释。

DHCP服务器被动打开UDP端口 67，等待客户端发来的报文。
DHCP客户从UDP端口68发送DHCP发现报文。
凡收到DHCP发现报文的DHCP服务器都发出DHCP提供报文，因此DHCP客户可能收到多个DHCP提供报文。
DHCP客户从几个DHCP服务器中选择其中的一个，并向所选择的DHCP服务器发送DHCP请求报文。
被选择的DHCP服务器发送确认报文DHCPACK。从这时起，DHCP客户就可以使用这个IP地址了。这种状态叫做已绑定状态，因为在DHCP客户端的IP地址和硬件地址已经完成绑定，并且可以开始使用得到的临时IP地址了。DHCP客户现在要根据服务器提供的租用期T设置两个计时器T1和T2，它们的超时时间分别是0.5T和0.875T。当超时时间到了就要请求更新租用期。
租用期过了一半（T1时间到），DHCP发送请求报文DHCPREQUEST要求更新租用期。
DHCP服务器若同意，则发回确认报文DHCPACKo DHCP客户得到了新的租用期，重新设置计时器。
DHCP服务器若不同意，则发回否认报文DHCPNACKo这时DHCP客户必须立即停止使用原来的IP地址，而必须重新申请IP地址（回到步骤2）。若DHCP服务器不响应步骤6的请求报文DHCPREQUEST,则在租用期过了87.5%时（T2时间到），DHCP客户必须重新发送请求报文DHCPREQUEST （重复
步骤。），然后又继续后面的步骤。
DHCP客户可以随时提前终止服务器所提供的租用期，这时只需向DHCP服务器发送释放报文DHCPRELEASE即可。

DHCP很适合于经常移动位置的计算机。当计算机使用Windows操作系统时，点击“控制面板”的“网络”图标就可以找到某个连接中的“网络”下面的菜单，找到TCP/IP协议后点击其“属性"按钮，若选择“自动获得IP地址"和“自动获得DNS服务器地址"，就表示是使用DHCP协议。

简单网络管理协议SNMP

网络管理的基本概念

虽然网络管理还没有精确定义，但它的内容可归纳为：

网络管理包括对硬件、软件和人力的使用、综合与协调，以便对网络资源进行监视、测试、配置、分析、评价和控制，这样就能以合理的价格满足网络的一些需求，如实时运行性能' 服务质量等。网络管理常简称为网管。

我们可以看到，网络管理并不是指对网络进行行政上的管理。

网络是一个非常复杂的分布式系统。这是因为网络上有很多不同厂家生产的、运行着多种协议的结点（主要是路由器），而这些结点还在相互通信和交换信息。网络的状态总是不断地变化着。可见，我们必须使用一种机制来读取这些结点上的状态信息，有时还要把一些新的状态信息写入到这些结点上。

下面简单介绍网络管理模型中的主要构件（见图6-21 ）。

管理站又称为管理器，是整个网络管理系统的核心，它通常是个有着良好图形界面的高性能的工作站，并由网络管理员直接操作和控制。所有向被管设备发送的命令都是从管理站发出的。管理站的所在部门也常称为网络运行中心NOC (Network Operations Center)。管
理站中的关键构件是管理程序(如图6-21中有字母M的椭圆形图标所示)。管理程序在运行时就成为管理进程。管理站(硬件)或管理程序(软件)都可称为管理者(manager)或管理器，所以这里的manager不是指人而是指机器或软件。网络管理员(administrator)才是指人。大型网络往往实行多级管理，因而有多个管理者，而一个管理者一般只管理本地网络的设备。

在被管网络中有很多的被管设备（包括设备中的软件）。被管设备可以是主机、路由器、打印机、集线器、网桥或调制解调器等。在每一个被管设备中可能有许多被管对象（Managed Object）。被管对象可以是被管设备中的某个硬件（例如，一块网络接口卡），也可以是某些硬件或软件（例如，路由选择协议）的配置参数的集合。

被管设备有时可称为网络元素或简称为网元。在被管设备中也会有一些不能被管的对象（在下面的6.7.2节将会讲到对象命名树，所谓不能被管的对象就是不在对象命名树上的对象）。

在每一个被管设备中都要运行一个程序以便和管理站中的管理程序进行通信。这些运行着的程序叫做网络管理代理程序，或简称为代理（agent）（如图6-22中有字母A的几个椭圆形图标所示）。代理程序在管理程序的命令和控制下，在被管设备上釆取本地的行动。

在图6-22中还有一个重要构件就是网络管理协议，简称为网管协议。

简单网络管理协议SNMP（Simple Network Management Protocol）中的管理程序和代理程序按客户服务器方式工作。管理程序运行SNMP客户程序，而代理程序运行SNMP服务器程序。在被管对象上运行的SNMP服务器程序不停地监听来自管理站的SNMP客户程序的请求（或命令）。一旦发现了，就立即返回管理站所需的信息，或执行某个动作（例如，把某个参数的设置进行更新）。在网管系统中往往是一个（或少数几个）客户程序与很多的服务器程序进行交互。

关于网络管理有一个基本原理，这就是：若要管理某个对象，就必然会给该对象添加一些软件或硬件，但这种"添加”对原有对象的影响必须尽量小些。

SNMP正是按照这样的基本原理来设计的。

SNMP发布于1988年。OSI虽然在这之前就已制定出许多的网络管理标准，但当时（到现在也很少）却没有符合OSI网管标准的产品。SNMP最重要的指导思想就是要尽可能简单。SNMP的基本功能包括监视网络性能、检测分析网络差错和配置网络设备等。在网络正常工作时，SNMP可实现统计、配置和测试等功能。当网络出故障时，可实现各种差错检测和恢复功能。

SNMP的网络管理由三个部分组成，即SNMP本身、管理信息结构SMI （Structure ofManagement Information）和管理信息库 MIB （Management Infonnation Base）。

下面简述这三部分的作用。

SNMP定义了管理站和代理之间所交换的分组格式。所交换的分组包含各代理中的对象（变量）名及其状态（值）。SNMP负责读取和改变这些数值。

SMI定义了命名对象和定义对象类型（包括范围和长度）的通用规则，以及把对象和对象的值进行编码的规则。这样做是为了确保网络管理数据的语法和语义无二义性。但从SMI的名称并不能看出它的功能。请注意，SMI并不定义一个实体应管理的对象数目，也不定义被管对象名以及对象名及其值之间的关联。

MIB在被管理的实体中创建了命名对象，并规定了其类型。

为了更好地理解上述的几个组成部分，可以把它们和程序设计进行一下对比。我们在编程时要使用某种语言，而这种语言就是用来定义编程的规则。

例如，一个变量名必须从字母开始而后面接着是字母数字。在网络管理中，这些规则由SMI来定义。在程序设计中必须对变量进行说明。例如，int counter,表示变量是整数类型。MIB在网络管理中就做这样的事情。MIB给每个对象命名，并定义对象的类型。在编程中的说明语句之后，程序需要写出一些语句用来存储变量的值，并在需要时改变这些变量的值。SNMP在网络管理中完成这件任务。SNMP按照SMI定义的规则，存储、改变和解释这些已由MIB说明的对象的值。

总之，SMI建立规则，MIB对变量进行说明，而SNMP完成网管的动作。

管理信息结构SMI

管理信息结构SMI是SNMP的重要组成部分。根据6.7.1节所讲的，SMI的功能应当有三个，即规定：

被管对象应怎样命名；
用来存储被管对象的数据类型有哪些；
在网络上传送的管理数据应如何编码。

被管对象的命名

SMI规定，所有的被管对象都必须处在对象命名树(object naming tree)上。图6-22给出了对象命名树的一部分。对象命名树的根没有名字，它的下面有三个顶级对象，都是世界上著名的标准制定单位，即ITU-T （过去叫做CCITT）, ISO，以及这两个组织的联合体，它们的标号分别是0到2。

图中的对象名习惯上用英文小写表示。在ISO的下面的一个标号为3的节点是ISO认同的的组织成员org。在其下面有一个美国国防部dod 的子树（标号为6），再下面就是internet （标号为1）。在只讨论internet中的对象时，可只画出internet以下的子树，并在internet节点旁边写上对象标识符136.1即可。

在internet节点下面的标号为2的节点是mgmt （管理）。再下面只有一个节点，即管理信息库mib-2,其对象标识符为1.3.6.121。在mib-2下面包含了所有被SNMP管理的对象（见下面6.7.3节的讨论）。

被管对象的数据类型

SMI使用基本的抽象语法记法1 （即ISO制定的ASN.1）来定义数据类型，但又增加了一些新的定义。因此SMI既是ASN.1的子集，又是ASN.1的超集。ASN.1的记法很严格，它使得数据的含义不存在任何可能的二义性。例如，使用ASN.1时不能简单地说“一个具有整数值的变量”，而必须说明该变量的准确格式和整数取值的范围。当网络中的计算机对数据项并不都使用相同的表示时，采用这种精确的记法就尤其重要。

我们知道，任何数据都具有两种重要的属性，即值（value）与类型（type）。这里“值”是某个值集合中的一个元素，而“类型"则是值集合的名字。如果给定一种类型，则这种类型的一个值就是该类型的一个具体实例。

SMI把数据类型分为两大类：简单类型和结构化类型。简单类型是最基本的、直接使用ASN.1定义的类型。表6-4给出了最主要的几种简单类型。

编码方法

SMI使用ASN.1制定的基本编码规则BER(Basic Encoding Rule)进行数据的编码。BER指明了每种数据的类型和值。在发送端用BER编码，可把用ASN.1所表述的报文转换成唯一的比特序列。在接收端用BER进行解码，就可得到该比特序列所表示的ASN.1报文。

初看起来，或许用两个字段就能表示类型和值。但由于表示值可能需要多个字节，因此还需要一个指出“要用多少字节表示值”的长度字段。因此ASN.1把所有的数据元素都表示为T-L-V三个字段组成的序列(见图6-23)。T字段(Tag)定义数据的类型，L字段(Length)定义V字段的长度，而V字段(Slue)定义数据的值。

T字段又叫做标记字段，占1字节。T字段比较复杂，因为它要定义的数据类型较多。T字段又再分为以下三个子字段：
- 类别(2位)共四种：通用类(00)，即ASN.1定义的类型；应用类(01)，即SMI定义的类型；上下文类(10)，即上下文所定义的类型；专用类(11)，保留为特定厂商定义的类型。
- 格式(1位)共两种，指出数据类型的种类：简单数据类型(0)，结构化数据类型(1)。
- 编号(5位)用来标志不同的数据类型。编号的范围一般为0~30。当编号大于30时，T字段就要扩展为多个字节（这种情况很少用到，可参考ITU-T X.209,这里从略）。
L字段又叫做长度字段（单字节或多字节）。

当L字段为单字节时，其最高位为0,后面的7位定义V字段的长度。当L字段为多个字节时，其最高位为1，而后面的7位定义后续字节的字节数（用二进制整数表示）。这时，所有的后续字节并置起来的二进制整数定义V字段的长度。图6-24给出了 L字段的格式。
V字段又叫做值字段，用于定义数据元素的值。

根据以上所述，我们给出两个用十六进制表示的编码例子。

例如，INTEGER 15，其T字段是02，再根据表6-4 INTEGER类型要用4字节编码。最后得出TLV编码为 02 04 00 00 00 OFo。又如 IPAddress 192.1.2.3，IPAddress 的 T 字段是 40，V 字段需要 4字节表示，因此 IPAddress 192.1.23 的 TLV 编码是 40 04 C0 01 02 03。

TLV方法中的V字段还可嵌套其他数据元素的TLV字段，并可多重嵌套。

管理信息库MIB

所谓“管理信息”就是指在互联网的网管框架中被管对象的集合。被管对象必须维持可供管理程序读写的若干控制和状态信息。

这些被管对象构成了一个虚拟的信息存储器，所以才称为管理信息库MIB。管理程序就使用MIB中这些信息的值对网络进行管理(如读取或重新设置这些值)。只有在MIB中的对象才是SNMP所能够管理的。

例如，路由器应当维持各网络接口的状态、入分组和出分组的流量、丢弃的分组和有差错的报文的统计信息，而调制解调器则应当维持发送和接收的字符数、码元传输速率和接受的呼叫等统计信息。因此在MIB中就必须有上面这样一些信息。

我们再看一下图6-22，可以找到节点mib-2下面的部分是MIB子树。表6-6给出了节点mib-2所包含的前八个信息类别代表的意思（在后面还有好几个类别）。

我们可以用个简单例子进一步说明MIB的意义。例如，从图6-22可以看出，对象ip的标号是4。因此，所有与IP有关的对象都从前缀1.3.6.1.2.1.4开始。

在节点ip下面有个名为ipInReceives的MIB变量(见图6-22)，表示收到的IP数据报数。这个变量的标号是 3,变量的名字是：iso.org.dod.intemet.mgmt.mib.ip.ipInReceives,而相应的数值表示是：1.3.6.12143。
当SNMP在报文中使用MIB变量时，对于简单类型的变量，后缀0指具有该名字的变量的实例。因此，当这个变量出现在发送给路由器的报文中时，ipInReceives的数值表示(即变量的一个实例)就是：1.3.6.1.2.143.0。
请注意，对于分配给一个MIB变量的数值或后缀是完全没有办法进行推算的，必须査找已发布的标准。

SNMP的协议数据单元和报文

实际上，SNMP的操作只有两种基本的管理功能，即：

"读”操作，用Get报文来检测各被管对象的状况；
“写”操作，用Set报文来改变各被管对象的状况。

SNMP的这些功能通过探询操作来实现，即SNMP管理进程定时向被管理设备周期性地发送探询信息。上述时间间隔可通过SNMP的管理信息库MIB来建立。探询的好处是：

第一，可使系统相对简单；

第二，能限制通过网络所产生的管理信息的通信量。但探询管理协议不够灵活，而且所能管理的设备数目不能太多。探询系统的开销也较大。如探询频繁而并未得到有用的报告，则通信线路和计算机的CPU周期就被浪费了。

但SNMP不是完全的探询协议，它允许不经过询问就能发送某些信息。这种信息称为陷阱（trap），表示它能够捕捉“事件”。但这种陷阱信息的参数是受限制的。

当被管对象的代理检测到有事件发生时，就检査其门限值。代理只向管理进程报告达到某些门限值的事件（这就叫做过滤）。这种方法的好处是：

第一，仅在严重事件发生时才发送陷阱；

第二，陷阱信息很简单且所需字节数很少。

总之，使用探询（至少是周期性地）以维持对网络资源的实时监视，同时也釆用陷阱机制报告特殊事件，使得SNMP成为一种有效的网络管理协议。

SNMP使用无连接的UDP，因此在网络上传送SNMP报文的开销较小。但UDP是不保证可靠交付的。这里还要指出，SNMP使用UDP的方法有些特殊。在运行代理程序的服务器端用熟知端口 161来接收Get或Set报文和发送响应报文（与熟知端口通信的客户端使用临时端口），但运行管理程序的客户端则使用熟知端口 162来接收来自各代理的trap报文。

和大多数TCP/IP协议不一样，SNMP报文没有固定的字段。相反，它们使用标准ASN.1编码。因此，SNMP报文用人工进行编码和理解时都比较困难。为此，在图6-25中给出了 SNMPv1的报文格式。可以看出，一个SNMP报文共由四个部分组成，即版本、首部、安全参数和SNMP报文的数据部分。

版本现在已是版本3。首部包括报文标识(messageidentification)、最大报文长度、报文标志(message flag)。报文标志占1字节，其中的每一位定义安全类型或其他信息。安全参数用来产生报文摘要(见下一章的7.4节)。

从图6-25可看出，在SNMP PDU前面还有两个有关加密信息的字段。这是当数据部分需要加密时才使用的两个字段。与网络管理直接相关的是后面的SNMP PDU部分。

对于表6-8给出的前四种PDU的格式都是相同的，即由PDU类型、请求ID、差错状态、差错索引以及变量绑定这几个字段组成。PDU的各种类型以及类型的编号和T字段的编码巳在表6-8中给出。下面简单介绍一下其他字段的作用。

请求标识符(request ID)由管理进程设置的4字节整数值。代理进程在发送响应报文时也要返回此请求标识符。由于管理进程可同时向许多代理发出请求读取变量值的报文，因此设置了请求标识符可使管理进程能够识别返回的响应是对应于哪一个请求报文。
差错状态(error status) 在请求报文中，这个字段是零。当代理进程响应时，就填入0~18中的一个数字。

例如0表示noError (一切正常)，1表示tooBig (代理无法把回答装入到一个SNMP报文之中)，2表示noSuchName (操作指明了一个不存在的变量)，3表示badWlue (无效值或无效语法。
差错索引(error index) 在请求报文中，这个字段是零。当代理进程响应时，若出现noSuchName, badValue或readonly的差错，代理进程就设置一个整数，指明有差错的变量在变量列表中的偏移。
变置绑定(variable-bindings) 指明一个或多个变量的名和对应的值。在请求报文中，变置的值应忽略(类型是NULL).

应用进程跨越网络的通信

在这以前我们已经讨论了互联网使用的几种常用的应用层协议，这些应用协议使广大用户可以更加方便地利用互联网的资源。

现在的问题是：如果我们还有一些特定的应用需要互联网的支持，但这些应用又不能直接使用己经标准化的互联网应用协议，那么我们应当做哪些工作？要回答这个问题，实际上就是要了解下面要介绍的系统调用和应用编程接口。这些问题实际上需要一门专门的课程来学习，我们在这里只能给出一些初步的概念。

系统调用和应用编程接口

大多数操作系统使用系统调用(system call)的机制在应用程序和操作系统之间传递控制权。对程序员来说，系统调用和一般程序设计中的函数调用非常相似，只是系统调用是将控制权传递给了操作系统。图6-27说明了多个应用进程使用系统调用的机制。

当某个应用进程启动系统调用时，控制权就从应用进程传递给了系统调用接口。
此接口再将控制权传递给计算机的操作系统。操作系统将此调用转给某个内部过程，并执行所请求的操作。
内部过程一旦执行完毕，控制权就又通过系统调用接口返回给应用进程。
系统调用接口实际上就是应用进程的控制权和操作系统的控制权进行转换的一个接口，即应用编程接口 API (Application Programming Interface)

当应用进程需要使用网络进行通信时就发出系统调用，请求操作系统为其创建“套接字”，以便把网络通信所需要的系统资源分配给该应用进程。
操作系统为这些资源的总和用一个叫做套接字描述符的号码来表示，并把此号码返回给应用进程。应用进程所进行的网络操作都必须使用这个号码。
通信完毕后，应用进程通过一个关闭套接字的系统调用通知操作系统回收与该“号码”相关的所有资源。

几种常用系统的调用

连接建立阶段

当套接字被创建后，它的端口号和 IP 地址都是空的，因此应用进程要调用 bind（绑定）来指明套接字的本地地址。在服务器端调用 bind 时就是把熟知端口号和本地 IP 地址填写到已创建的套接字中。这就叫做把本地地址绑定到套接字。
服务器在调用 bind 后，还必须调用 listen（收听）把套接字设置为被动方式，以便随时接受客户的服务请求。UDP 服务器由于只提供无连接服务，不使用 listen 系统调用。
服务器紧接着就调用 accept（接受），以便把远地客户进程发来的连接请求提取出来。系统调用 accept 的一个变量就是要指明从哪一个套接字发起的连接。

传送阶段

客户和服务器都在 TCP 连接上使用 send 系统调用传送数据，使用 recv 系统调用接收数据。
通常客户使用 send 发送请求，而服务器使用 send 发送回答。
服务器使用 recv 接收客户用 send 调用发送的请求。客户在发完请求后用 recv 接收回答。

连接释放阶段

一旦客户或服务器结束使用套接字，就把套接字撤消。这时就调用 close 释放连接和撤销套接字

图&31画出了上述的一些系统调用的使用顺序，有些系统调用在一个TCP连接中可能会循环使用。

P2P应用

我们在第1章的1.3.1节中已经简单地介绍了 P2P应用的概念。现在我们将进一步讨论P2P应用的若干工作原理。

P2P应用就是指具有P2P体系结构的网络应用。所谓P2P体系结构就是在这样的网络应用中，没有（或只有极少数的）固定的服务器，而绝大多数的交互都是使用对等方式（P2P方式）进行的。

P2P应用的范围很广，例如，文件分发、实时音频或视频会议、数据库系统、网络服务支持（如P2P打车软件、P2P理财等）。限于篇幅，下面只介绍最常用的P2P文件分发的工作原理。

P2P文件分发不需要使用集中式的媒体服务器，而所有的音频/视频文件都是在普通的互联网用户之间传输的。这其实是相当于有很多（有时达到上百万个）分散在各地的媒体服务器（由普通用户的计算机充当这种媒体服务器）向其他用户提供所要下载的音频/视频文件。这种P2P文件分发方式解决了集中式媒体服务器可能出现的瓶颈问题。

目前在互联网流量中，P2P工作方式下的文件分发己占据了最大的份额，比万维网应用所占的比例大得多。因此单纯从流量的角度看，P2P文件分发应当是互联网上最重要的应用。现在P2P文件分发不仅传送音频文件MP3,而且还传送视频文件（10〜1000 MB,或更大）、各种软件和图像文件。

具有集中目录服务器的P2P工作方式

最早出现的 P2P 技术，可提供免费下载 MP3 音乐。
Napster 能够搜索音乐文件，能够提供检索功能。所有的音乐文件地址集中存放在一个 Napster 目录服务器中。使用者可很方便地下载需要的 MP3 文件。
用户要及时向 Napster 的目录服务器报告自己存有的音乐文件。当用户想下载某个 MP3 文件时，就向目录服务器发出询问。目录服务器检索出结果后向用户返回存放此文件的 PC 机的 IP 地址。Napster 的文件传输是分散的，但文件的定位则是集中的。
这种集中式目录服务器的缺点就是可靠性差。Napster 被判决属于“间接侵害版权”，因此在 2000 年 7 月底 Napster 网站就被迫关闭了。

全分布式结构的 P2PGnutella

Gnutella 是第二代 P2P 文件共享程序，采用全分布方法定位内容的 P2P 文件共享应用程序。
Gnutella 与 Napster 最大的区别就是不使用集中式的目录服务器，而是使用洪泛法在大量 Gnutella 用户之间进行查询。
为了不使查询的通信量过大，Gnutella 设计了一种有限范围的洪泛查询。这样可以减少倾注到互联网的查询流量，但由于查询的范围受限，因而这也影响到查询定位的准确性。

计算机网络——应用层