新手入门：了解网络应用与网络协议(图)

　　网络应用(network application)是计算机网络之所以存在的理由。要是我们设想不出任何有用的网络应用，那就没有必要设计支持它们的网络协议了。不过，过去30年内已有不少人设计出大量精妙的网络应用。这些应用既包括从20世纪80年代流行起来的基于文本的经典应用，例如远程计算机访问、电子邮件、文件传送、新闻组、聊天等;也包括近些年来所谓的多媒体应用，例如Web、因特网电话、视频会议、音频/视频点播等。

　　尽管网络应用品种繁多是有许多彼此交错的部件，其软件却几乎总处于核心地位。网络应用的软件分布于两个或以上的端系统(即主机)。例如，Web应用包括彼此通信的两部分软件：运行在用户的主机(PC机、MAC机、工作站等)中的浏览器软件，以及运行在Web服务器上的Web服务器软件。Telnet应用同样由分别运行于本地主机和远程主机中的两部分软件构成。至于多方视频会议，参与会议的每台主机上都运行着一部分软件。

　　用操作系统的行话来说，彼此通信的实际上不是软件部件(即程序)本身，而是进程。我们可以把进程看成是在端系统中运行着的程序。运行在同一个端系统上的进程彼此间通过使用进程间通信手段通信。进程间通信的具体规则由端系统的操作系统决定。本文不关心同一台主机内的进程间通信，而关心运行在不同主机(操作系统也可能不一样)的进程间的通信。运行在不同端系统上的进程通过网络交换消息彼此通信。发送进程创建消息并将之传入网络;接收进程收取这些消息，并可能发送消息作为响应，如下图所示。每个网络应用都有各自的应用层协议，它定义在进程间交流的消息的格式和顺序，以及在送出或收到消息时采取的行动。

　　图1：彼此通信的应用

　　应用层是我们着手研究协议的好地方。我们已经熟悉依赖于协议的许多应用。这将给我们一种似曾相识的感觉，知道协议的目的所在，有助于我们了解以后学习传输层协议、网络层协议和数据链路层协议时会碰到的许多同样的问题。

　　应用层协议

　　把网络应用和应用层协议区分开来相当重要。应用层协议仅仅是网络应用的一部分，让我们看几个例子。Web是一个允许用户从Web服务器按要求取得“文档”的网络应用，web应用由许多部件构成，包括—个文档格式的标准(即超文本标记语言HTML)、Web浏览器软件、Web服务器软件(例如Apache、IIS服务器)、一个应用层协议。Web的应用层协议是超文本传送协议（HTTP），它定义如何在浏览器和web服务器之间传递消息。因此HTTP仅仅是Web应用的一部分。另一个例于是电子邮件应用。电子邮件应用同样由许多部件构成，包括安置用户信箱的邮件服务器、让用户阅读和创建电子邮件消息的邮件阅读器、一个定义电子邮件消息结构的标推、一组定义如何在服务器之间以及服务器和阅读器之间传递电子邮件消息并解释其特定部分(例如信头)的应用层协议。电于邮件应用的首要应用层协议是简单邮件传输协议（SMTP）。因此SMTP也仅仅是电子邮件应用的一部分。

　　我们已经指出，应用层协议定义运行在不同端系统上的应用程序进程如何彼此传递消息。具体地说，一个应用层协议定义:

　　●所传递消息的类型，例如请求消息和响应消息。

　　●各种消息类型的语法，也就是消息中的各个字段以及它们如何定界。

　　●各个字段的语义，也就是各个字段中的信息的含义。

　　●确定一个进程何时以及如何发出消息或响应所收到消息的规则。

　　有些应用层协议是在RFC文档中详细说明的，也就是说它们处于可免费获取的公众域。例如，HTTP就可以作为RFC获取。浏览器软件开发者只要遵循该RFC中定义的规则，其浏览器就可以从同样遵循这些规则的任何web服务器取得Web页面。然而，其他许多应用层协议却是专属的，有意不放在公众域中。例如，许多现有的因特网电话产品使用专属的应用层协议。

　　客户和服务器

　　一个网络应用协议通常拥有客户端(client side)和服务器端(server side)这两个对等的“端”或实体，它们分别对应运行客户程序的客户进程(简称客户)和运行服务器程序的服务器进程(简称服务器)，如图2所示。处于一个端系统中的客户端与处于另一个端系统中的服务器端彼此通信。例如，web浏览器实现的是HTTP客户端，web服务器实现的是HTTP服务器端。在电子邮件应用中，发送邮件消息的邮件服务器扮演SMIP的客户端角色，接收邮件消息的邮件服务器扮演SMTP的服务器端角色。

　　图2：客户/服务器交互

　　对于许多应用来说，它们的客户端和服务器端可以同时实现在单台主机上。就以主机A和主机B之间的一个Telnet会话为例。如果这个Telnet会话是由主机A发起的(即主机A上有一个用户登录到了主机B)，那么主机A运行的是该应用的客户端，主机B运行的是该应用的服务器端。相反，如果这个Telnet会话是由主机B发起的，那么主机B运行的是该应用的客户端。用于在两台主机之间传送文件的FTP提供了另外一个例子。两台主机之间一旦启动一个FTP会话，其中任何一台主机就可以在该会话结束之前向另一台主机传达文件。尽管如此，我们还是按照几乎所有网络应用的惯常情况，把发起会话的主机标为客户。另外，单台主机实际上可能同时作为某个给定应用的客户主机和服务器主机。例如，邮件服务器主机同时运行着SMlP客户端(用于发送邮件)和服务器端（用于接收邮件）。

　　进程间跨网络的通信

　　一个网络应用涉及两台不同主机中跨网络彼此通信的两个进程(当然，组播网络应用有可能涉及两台以上主机间的通信)。这两个进程通过经由各自的套接字(socket)发送和接收消息彼此通信。我们可以把套接字看作相应进程上的“门”:进程把消息发送到网络或从网络接收消息都得经过自身的套接字。当一个进程想给另一台主机中的另一个进程发送消息时，它就把该消息推出自家的门。该进程认定在这扇门的另一侧有一个传输设施会把这个消息传输到目的进程的门口。

　　图3展示了通过因特网彼此通信的两个进程间的套接字通信(本图假设底层的传输协议是TCP，不过UDP也可以同样使用)。可见套接字是单台主机内应用层和传输层之间的接口。套接字也用于指代应用程序和网络之间的应用程序接口(application program interface，简称API)，因为它又是用于构造因特网中的网络应用程序的编程接口。应用程序开发人员可以完全控制套接字的应用层一侧，对于套接字的传输层一侧却几乎无能为力。对于传输层一侧他们只能控制:(1)传输协议的选择;(2)诸如最大缓冲区大小和最大片段大小等有限几个传输层参数的调整。一旦选定某个可用的传输协议，就使用由该协议提供的传输层服务来构造应用程序。

　　图3：应用程序进程、套接字

　　进程寻址

　　要让一台主机中的进程给另一台主机中的进程发送消息，发送进程必须能够识别接收进程。用于标识接收进程的信息有两个:(1)接收主机的主机名或主机地址，(2)在接收主机内部识别接收进程的标识符。

　　让我们先考虑主机地址。在因特网应用中，接收主机是用其IP地址(1P addresse)标识的。现在，我们知道IP地址是惟一标识每个端系统的一个32位二进制数值(更准确地说，IP地址惟一地标识将各台主机连接到因特网的网络接口)，既然连接到公共因特网的任何端系统的IP地址必须全球惟一，IP地址的分配就必须仔细管理。ATM网络的寻址标准则不同于因特网。ITU—T已规定，在公共ATM网络中使用称为E.164地址(ITU1997)的类似电话号码的地址。

　　除了知道接收进程所在端系统的地址外，发送进程还得指定可让接收端系统把所传送消息定向到接收进程的信息。因特网中用于此目的的是接收进程的端口号(port number)。流行的应用层协议已被赋予特定的端口号。例如，使用HTTP协议的web服务器进程是以端口号80标识的，使用SMTP协议的邮件服务器是以端门号25标识的。RFC 1700列出了所有因特网标准协议众所周知的端口号。在开发新的网络应用程序时，必须赋予它一个新的端口号。

　　用户代理

　　再开始继续研究应用层协议之前，讨论一下用户代理(user agent)的概念也许有所裨益。用户代理是一个位于用户和网络应用之间的接口。例如，Web应用的用户代理是诸如Netscape Navigator和微软Internet Explore这样的浏览器。浏览器使得用严可以观看web页面、进行web冲浪、提供表单输入、与JAVA小应用程序交互，等等。浏览器还实现了HTTP协议的客户端。因此启动后的浏览器除给用户提供一个接口外，其进程还同时在经由一个套接字发送接收消息。另一个例子是关于电子邮件应用的。电子邮件应用的用户代理是“邮件阅读器”，它使得用户可以编写和阅读邮件消息。许多公司提供可运行在PC机、MAC机和工作站上的图形用户界面的邮件阅读器(例如Eudora，Netscape Messenger，Microsoft outlook)。运行在PC机上的邮件阅读器还实现了多个应用层协议的客户端，典型的有用于发送邮件的SMTP协议的客户端.以及用于检索邮件的某个邮件检索协议(例如POP3或IMAP)的客户端。

　　应用所需的服务

　　我们知道套接字是应用进程和传输协议之间的接口。发送端的应用进程通过这扇门送出消息。在门的另一侧，传输协议负责把这些消息跨网络传送到接收进程的门口。包括因特网在内的许多网络体系结构提供不止一个传输协议。在开发应用程序时，必须选择一个可用的传输协议。如何进行选择呢?最可能的情形是，先研究一下由可用的传输协议提供的服务，再选出其服务与应用程序的需求最为匹配的协议。这种情形类似于在两个城市之间旅行时选择乘火车还是乘飞机。