第6章传输层和高层协议

第6章

传输层和高层协议

韶关学院信息工程学院骆耀祖1内容提要本章描述传输层和TCP协议规范实现的一些方法，讨论了TCP/IP中最为常见的应用层协议：Telnet、FTP、小文件传输协议TFTP、简单邮件传输协议SMTP和HTTP协议，讨论这些协议与TCP和IP的关系、控制代码及特点以及典型应用实例。读者在读完本章后，应充分理解为何要使用这些协议以及这些协议是如何适应TCP/IP的。

6.1传输层和TCP协议规范

传输控制协议TCP(TransferControlProtocol)是一种面向连接的协议，该协议可以保证客户端和服务端的连接是可靠的、安全的，所以大多数程序采用TCP协议。用户数据报协议UDP(UserDatagramProtocol)是一种非面向连接的协议，它不能保证网络程序的连接是可靠的，但由于它速度快，在要求速度和效率的场合可能会使用UDP协议。6.1.1TCP协议规范TCP协议是面向连接的端到端的可靠协议。它支持多种网络应用程序。TCP假定下层只能提供不可靠的数据报服务，对下层服务没有多少要求，它可以在多种硬件构成的网络上运行。在层次式结构中，TCP的下层是IP协议，TCP可以根据IP协议提供的服务传送大小不定的数据，IP协议负责对数据进行分段和重组，在多种网络中传送。TCP的上层接口包括一系列类似于操作系统中断的调用。对于上层应用程序来说，TCP应该能够异步传送数据。为了在并不可靠的网络上实现面向连接的可靠的传送数据，TCP必须解决可靠性和流量控制的问题，必须能够为上层应用程序提供多个接口，同时为多个应用程序提供数据。同时，TCP是面向连接的，必须解决连接问题。最后，TCP也必须能够解决通信安全性的问题。主机上不同的协议有不同的端口号，一对进程通过这个端口号进行通信。网络上的计算机被看作包传送的源和目的节点。进程为了传送数据，将数据和相应的参数传送给TCP，通过将TCP包打包在IP包内在网络上传送到目的TCP。TCP会保证接收数据顺序的正确性。网关在接收到这个包后，会将包解开，看看是不是已经到目的地了，如果没有到，网关会根据下一个网络内的协议情况再次将TCP包打包传送。有时还需要把这个包分成几段再传送。这个落地检查的过程是一个耗时的过程。接收方TCP在接收到数据后与上层应用程序通信。具体过程可能还要复杂得多。在实现TCP的主机上，TCP可以被看成是一个模块，和文件系统区别不大，TCP也可以调用一些操作系统的功能。TCP不直接和网络打交道，TCP只是调用IP接口，IP向TCP提供所有TCP需要的服务。控制网络的任务由专门的设备驱动模块完成。TCP连接是可靠的，而且保证了所传送数据包的顺序，保证顺序是用一个序号来保证的。响应包内也包括一个序列号，表示接收方准备好这个序号的包。在TCP传送一个数据包时，它同时把这个数据包放入重发队列中，同时启动记数器，如果收到了关于这个包的确认信息，将此包从队列中删除，如果计时超时则需要重新发送此包。从TCP返回的确认信息并不保证最终接收者接收到数据，这个责任由接收方负责。1.TCP协议数据单元

urg如果设置紧急数据指针，则该位为1；

ack如果确认号正确，那么为1；

psh如果设置为1，那么接收方收到数据后，立即交给上一层程序；

rst为1的时候，表示请求重新连接；

syn为1的时候，表示请求建立连接；fin为1的时候，表示请求关闭连接；2.TCP接口

网络协议的分层结构决定了TCP有两个接口，向上的用户接口和与下层的接口。对下层协议接口依赖于下层协议，由下层协议来描述，但也会讨论到一些TCP要使用的参数。（1）用户/TCP接口(TCP用户命令)TCP的实现与具体的操作系统相关，因系统不同具体实现可能不同。不同的TCP实现可能有不同的用户接口，但是有一些功能是最基本的，本节讨论的都是调用的源语形式，其参数都支持TCP最低限度的子集。为了实现通信功能，TCP不能只会接收命令，而且能够返回消息给它服务的进程，这些消息包括：关于连接的通常消息，如中断，远程关闭等等；对用户命令做出应答，是成功还是失败。（2）TCP与下层接口

在互联网上，通常认为TCP的下层是IP协议。对TCP与下层(通常是IP，但不一定是)对话的模型却没有规定。TCP要求其下面的层定义通信的方式。TCP要调用下层服务才能在网络上传输数据。IP层提供一些例如服务类型和生存时间等的参数。通常假定TCP与网络层采用异步方式进行通信。如果下层是IP而且使用源地址路由，接口必须允许路由信息的通信。这对建立连接和进行路由是十分重要的。当然也可以不使用IP协议作为TCP的底层协议，但无论下层协议是什么，都必须提供源地址，目的地址和协议域，以及一些决定TCP长度的字段。总之，要能够提供类似于IP的功能。因为TCP是一种面向连接的协议，负责保证从源主机到目标主机的数据报端到端的传输，所以TCP必须接收从目标主机发送来的，确认数据报已经接收的通信信息。术语“虚电路”（virtualcircuit

）通常用来表示两边终端的通信，这些通信通常是简单的确认信息(接收的确认或传输失败的代码)以及数据报的序列号。

图6.2TCP提供了端到端的通信

（3）TCP与上层的通信

TCP必须与位于上层的应用程序和在下层的网络系统进行通信。TCP与上层的接口包括一系列类似于操作系统中断的调用。TCP与上层协议ULP(upper-layerprotocol)通信的方法由一组服务请求原语定义，

在ULP与TCP的通信中包含的原语如表6.1所示。

表6.1ULP与TCP通信中包含的原语6.1.2端口和套接字TCP/IP采用了协议端口号来区分使用TCP或UDP的各个应用程序。端口机制是指在一个给定主机上使用TCP或UDP的每一个应用程序都被指定一个逻辑地址，这些16比特的值用来标识不同的应用程序，在传输时保存在TCP或UDP报头中。因此，在主机上的三级寻址方式包括：端口号(PortNumber)──标识应用程序；协议号(ProtocolNumber)──所使用的传输层协议；IP地址(IPAddress)──进出主机的路径。1.套接字套接字（Socket）是分配给某运行在主机上特定进程的逻辑地址。它形成主机和客户机之间的虚拟连接。套接字使用IP地址、协议号和端口号的组合唯一标识，也称为三级寻址。一个连接由连接两端的套接字标识，本地的套接字可能和不同的外部套接字通信，这种通信是全双工的。2.端口号套接字的地址集成了主机的IP地址和与某进程有关的端口号(PortNumber)。TCP和UDP采用16位的端口号来识别应用程序。例如，对于每个TCP/IP实现来说，FTP服务器的TCP端口号都是21，每个Telnet服务器的TCP端口号都是23。又如，IP地址为7的Web服务器的Telnet服务的套接字地址为7：23，其中23是Telnet服务的标准端口号。换句话说，在安装之后，如果没有特别配置软件的话，Web服务器软件会假设任何进入端口号23的请求都是Telnet请求。注意，端口号被表示为IP地址后冒号后面的十进制数字。23并不被认为是套接字号中额外的十进制数，它只是该端口的一个指针。图6.3给出了使用TCP的端口号建立虚电路时的情况。图6.3使用TCP的端口号建立虚电路通过向本地端口发送OPEN命令及外部套接字参数建立连接，这个连接的信息保存在一个称为传输控制块TCB（TransmissionControlBlock）的数据结构中。TCP返回一个标记这个连接的名称，以后如果用户需要这个连接就可使用这个名称标记。OPEN命令还指定这个连接的建立是主动请求还是被动等待请求。任何TCP/IP实现所提供的服务都用众所周知的1－1023之间的端口号。这些端口号由Internet端口号分配机构IANA（InternetAssignedNumbersAuthority）管理。到1992年为止，人们所熟知的端口号介于1－255之间。256－1023之间的端口号通常都是由Unix系统占用，以提供一些只有Unix系统才有的，而其他操作系统可能不提供的服务。大多数的TCP/IP实现给临时端口分配的端口号在1024－5000之间。大于5000的端口号是为其他Internet上并不常用的服务预留的。表6.2给出了常用的TCP端口号。3.保留端口

Unix系统有保留端口号的概念。只有具有超级用户特权的进程才允许给它自己分配一个保留端口号。这些端口号介于1到1023之间，一些应用程序（如有名的Rlogin）将它作为客户与服务器之间身份认证的一部分。端口号可以是任何一个值。一些使用TCP/IP的软件（如Novell的GroupWise，以及HP的性能数据警报管理器）都可选择自己的默认端口号。常见TCP/IP服务的默认端口号一般小于255

。尽管不必记住每个端口号，但应该记住常见服务如Telnet、FIP、SNMP和HTTP等相关的端口号。了解这些端口号将有助于配置和调试TCP/IP网络服务。端口号的引入简化了TCP／IP通信。比如，当某客户机请求与某服务器通信，并指定端口23时，服务器会立即知道客户机希望进行Telnet会话。不再需要其他数据交换来定义会话类型，并且服务器可以立即初始化Telnet服务。服务器会连接到客户机的Telnet端口，默认值为23，并且建立虚拟线路。有一些标准的简单服务几乎每种实现都要提供。当使用TCP和UDP提供相同的服务时，一般选择相同的端口号。如果仔细检查这些标准的简单服务以及其他标准的TCP/IP服务（如Telnet，FTP，SMTP等）的端口号时，发现它们都是奇数。这是有历史原因的，因为这些端口号都是从NCP端口号派生出来的。（NCP，即网络控制协议，是ARPANET的传输层协议，是TCP的前身。NCP是单工的，不是全双工的，因此每个应用程序需要两个连接，需预留一对奇数和偶数端口号。当TCP和UDP成为标准的传输层协议时，每个应用程序只需要一个端口号，因此就使用了NCP中的奇数。大多数服务器维护一个可编辑的、基于文本的端口号和相关服务的文件。如有必要，可以通过软件来配置端口号。在通常的情况下，不应更改默认端口号，原因是违反了标准。当然，一些网络管理员为了安全原因也许会更改服务器端口号，以迷惑黑客。6.1.3TCP的连接

TCP通信建立在面向连接的基础上，实现了一种“虚电路”的概念。在进行实际数据传输前必须在信源端与信宿端建立一条连接，然后双方就可以在其上发送数据流。假如连接建立不成功，则信源端不会像UDP一样贸然向信宿端发送数据。此外，面向连接传输的每个报文都需要收端确认，未确认报文被认为是出错报文，以保证面向连接的可靠性。这种数据交换方式能提高效率，但事先建立连接和事后拆除连接需要开销。1.连接进程

TCP连接进程是通过一系列状态表示的，各个状态的意义如下：LISTEN-侦听来自远方TCP端口的连接请求；SYN-SENT-在发送连接请求后等待匹配的连接请求；

SYN-RECEIVED-在收到和发送一个连接请求后等待对连接请求的确认；

ESTABLISHED-代表一个打开的连接，数据可以传送给用户；FIN-WAIT-1-等待远程TCP的连接中断请求，或先前的连接中断请求的确认；FIN-WAIT-2-从远程TCP等待连接中断请求；CLOSE-WAIT-等待从本地用户发来的连接中断请求；CLOSING-等待远程TCP对连接中断的确认；LAST-ACK-等待原来发向远程TCP的连接中断请求的确认；TIME-WAIT-等待足够的时间以确保远程TCP接收到连接中断请求的确认；

CLOSED-没有任何连接状态；图6.4表示了TCP连接可能发生的状态及各种可能发生的变迁的有限状态机，但该图中没有包括错误的情况和错误处理。2.建立一个连接TCP的连接要分为几个步骤。通常把这个连接过程称为“三次握手”。目的是使数据段的发送和接收同步；告诉其

它主机其一次可接收的数据量，并建立虚连接。

三次握手的简单过程如图6.5所示，步骤如下：

(1)初始化主机通过一个同步标志置位的数据段发出会话请求。(2)接收主机发回具有以下项目的数据段表示回复：同步标志置位、即将发送的数据段的起始字节的顺序号、应答并带有将收到的下一个数据段的字节顺序号。

(3)请求主机再回送一个数据段，并带有确认顺序号和确认号。

建立连接时，如果双方同时都发送SYN，双方会发现这个SYN中没有确认，通常应该发送一个"reset"段来解决这种情况，减少了连接失败的可能性。图6.5三次握手使用三次握手的主要原因是为了防止使用过期的数据段。因此，必须引入新的控制消息RESET。如果接收TCP处理非同步状态，在接收到RESET后返回到LISTEN状态。如果TCP处理以下几种状态：ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK和TIME-WAIT时，放弃连接并通知用户。3.关闭连接由于是TCP的传输是全双工的，在CLOSE操作时的连接处理有些问题。TCP以一种简单的方式处理CLOSE，发送CLOSE的一方在接收到对方的CLOSED之前，还要继续接收数据。因此程序可以在一个CLOSE之后初始化几个SEND，然后开始RECEIVE，直到接收到对方的CLOSED而RECEIVE失败为止。假设TCP可以通知用户连接关闭，即使仍在RECEIVE也可以，这样用户就可以正常关闭了。这样，TCP就可以在连接关闭前可靠地发送数据。4.优先和安全TCP的操作必须在两个优先级相同的端口间进行。TCP使用的优先和安全参数在IP协议中定义。这里所说的安全/间隔就是指的IP中定义的优先、用户组和处理规定。如果不符合则发送RST。TCP在操作过程中也会检查接收数据段的优先级，还可以在操作中提高优先级。虽然运行在无安全环境中，主机也必须能够处理安全参数。6.2传输控制块和流控制由于TCP建立在不可靠的IP协议之上，所以TCP的可靠性完全由自己实现。TCP采用的最基本的可靠性技术是：确认与超时重传。流量控制也是保证可靠性的一个重要措施，假如没有流控，可能因接收缓冲区溢出而丢失大量数据，导致许多重传。TCP采用可变窗口进行流控。此外，TCP还要进行拥塞控制。6.2.1传输控制块TCB

TCP通过传输控制块TCB（TransmissionControlBlock）监视有关每个连接的有关信息。TCB包含的信息包括：本地和远程端口号（套接字）、发送和接收缓冲器指针等变量、安全性和优先权值以及队列中的当前段，此外，TCB还管理和发送接收序列号。TCB使用若干变量跟踪发送和接收状态，并控制信息流。这些变量如表6.3所示。

TCP使用这些变量控制两个套接字之间的信息流。图6.6给出了发送序列变量间的关系。图6.6发送序列变量间的关系这些变量的使用方式可用一个例子来说明。如果主机A希望将五个数据块发送到主机B，如果窗口的极限是七个块，主机A上的SND.UNA变量将指示有多少个块已经发送但未经确认(5)，而SND.NXT变量的值为序列的下一个块(6)。SND.WND变量的值

是2(可用7块，减去已经发送的5块)，因此只可以发送两个块而不会使窗口过载。主机B返回接收报文的数目后，窗口的（可用）极限将作出相应的调整。

6.2.2TCP定时器TCP使用几个定时器以确保在通信过程中不会发生过度延迟。这些计时器起到确保数据从一个连接正确发送到另一方的作用。1.重传计时器2.静态计时器3.持续计时器4.保活计时器和空闲计时器6.2.3确认与超时重传

在TCP连接中发送的字节都有一个序列号。可根据序列号对接收到的包进行确认。对序列号的确认是累积性的，也就是说，如果用户收到对X的确认信息，这表示在X以前的数据（不包括X）都收到了。在每个段中字节是这样安排的：第一个字节在包头后面，按这个顺序排列。实际的序列空间的范围是0到2的32次方减1。图6.7给出了TCP序列号及确认号的关系。

图

6.7TCP序列号及确认号1.序列号

（1）序列的比较和操作序列的比较和操作包括如下几种：①

决定一些发送了的但未确认的序列号；

②

决定所有的序列号都已经收到了；③

决定下一个段中应该包括的序列号。对于发送的数据TCP要接收确认，处理确认时必须进行下面的比较操作：SND.UNA=最老的确认了的序列号；SND.NXT=下一个要发送的序列号；SEG.ACK=接收TCP的确认，接收TCP期待的下一个序列号；

SEG.SEQ=一个数据段的第一个序列号；SEG.LEN=数据段中包括的字节数；SEG.SEQ+SEG.LEN-1=数据段的最后一个序列号。注意下面的关系：SND.UNA<SEG.ACK=<SND.NXT（2）接收数据时的比较操作如果一个数据段的序列号小于等于确认号的值，那么整个数据段就被确认了。而在接收数据时下面的比较操作是必须的：RCV.NXT=期待的序列号和接收窗口的最低沿；RCV.NXT+RCV.WND-1=最后一个序列号和接收窗口的最高沿；

SEG.SEQ=接收到的第一个序列号；SEG.SEQ+SEG.LEN-1=接收到的最后一个序列号；上面几个量有如下关系：RCV.NXT=<SEG.SEQ<RCV.NXT+RCV.WND或

RCV.NXT=<SEG.SEQ+SEG.LEN-1<RCV.NXT+RCV.WND图6.8TCP简单确认机制测试的第一部分是检查数据段的开始部分是否在接收窗口中，第二部分是检查数据段的结束部分是否也在接收窗口内；上面两个检查通过任何一个就说明它包括窗口要求的数据。实际中的情况会更复杂一些，因为有零窗口和零数据段长，所以有下面四种情况：

接收窗口的大小可以为零，在窗口为零时它只用来接收ACK信息，因此对于一个TCP来说，它可以使用零大小窗口在发送数据的同时接收数据。即使接收窗口的大小为零，TCP必须处理所有接收到信息的RST和URG域。也可应用计数的方式保护一些特定的控制信息，这是通过隐式地使用一些控制标记，使数据段能够可靠地重新发送（或确认）来达到的。控制信息并不在段数据空间中传送，因此，必须采用隐式指定序列号进行控制。SYN和FIN是需要保护的控制量，这两个控制量也只在连接打开和关闭时使用。SYN被认为是在第一个实际数据之间的数据，而FIN是最后一个实际数据之后的数据。段长度（SEG.LEN）包括数据和序列号空间，如果出现了SYN，那么SEG.SEQ是SYN的序列号。（3）初始序列号选择协议对于特定连接被重复使用没有什么限制。连接是由一对套接字定义的。新的连接实例被定义为连接的另一次恢复，这就带来了问题：TCP如何确定多个数据段是从以前连接的另一次恢复中取得的呢？这个问题在连接迅速打开和关闭，或因为内存原因被关闭然后又迅速建立后显得特别突出。为了避免混乱，用户必须避免因此恢复使用某一连接，而使序列号发生混乱。必须保证序列号的正确性，即使TCP失败，根本不知道以前的序列号是什么的情况下。也要保证序列号的正确性。当新的连接被创建时，产生一个新的初始序列号（ISN）产生子，它用来选择一个新的32位ISN。产生子和32位时钟的低位字节相关，低位字节的刷新频率大概是4微秒，因此ISN的循环时间大概是4.55小时。因此把网络包的最长生存时间（MSL）小于4.55小时，因此可以认为ISN是唯一的。每个连接都有发送序列号和接收序列号，初始发送序列号（ISS）由发送TCP选择，而初始接收序列号是在连接建立过程中产生的。对于将要连接或初始化的连接，两个TCP必须和对方的初始序列号同步。这通过交换一个控制位SYN和初始序列号完成。把带有SYN的数据段称为"SYNs"。同步的获得过程这里就不重复了，每方必须发送自己的序列号并返回对于对方序列号的确认。TCP的基本传输单元――段(Segment)是不定长的。可变长TCP段所采用的确认与超时重传机制是所谓的“累计确认”：TCP确认针对流中的字节，而不是段。一段情况下，接收方确认已正确收到的最长的连续的流前部(prefixofthestream)，每个确认指出下一个希望收到的字节。累计确认的优点之一是在变长段传输方式下不会产生二义性，累计确认另一个优点是确认丢失后不一定导致重传。假设收方当时正确收到第10号字节以前的流前部，将发送一报文确认第11号字节，紧跟着又收到第11、12号字节，又发送一个确认第13号字节的报文。确认第11号字节的报文丢失并不一定导致重传。因为假如确认第13号字节的报文在一定时间之内传到发送方，发送方将不进行重传。累计确认的缺点是发送方不能获得关于所有成功的段传输信息，假如前面尚有数据未收到，则后面所有成功传输的段都得不到确认，必须重传。2.超时重传

TCP采用“带重传的肯定确认”技术来实现传输的可靠性。简单的“带重传的肯定确认”是指与发送方通信的接收者，每接收一次数据，就送回一个确认报文，发送者对每个发出去的报文都留一份记录，等到收到确认之后再发出下一报文数据报。发送者发出一个报文数据报时，启动一个计时器，若计时器计数完毕，确认还未到达，则发送者重新送该报文数据报。TCP通过重新传送保证每个数据段到达对方，因为有了重新传送，所以对方可能接收到两个相同的包，那就必须根据内部的序列号来判断哪个数据段是可以接收的。发送方通过使用SND.NXT跟踪下一个要发送的数据段，而接收方则跟踪RCV.NXT来知道下一个要接收的数据段。发送方要还未确认的最老的序列号保存于SND.UNA。当发送方形成数据段并发送后SND.NXT增大；当接收方接收到数据段后RCV.NXT增大并发送确认；当发送方接收到确认后SND.UNA增大。它们三者在不同的时间增大是因为传送时延造成的。而增大多少则由数据段中数据的大小决定。连接进入ESTABLISHED状态后，所有的段必须包括当前的确认信息。而CLOSE用户操作的性质类似于推操作，这和在接收到的数据段中的FIN标记一样。因为网络中有不同类型的网络，而使用TCP的范围又很广，所以，重传超时必须动态决定。下面给出一个确定重传超时过程的例子，用两个变量说明时延的问题。一个是环路时间（RTT），它是由一个序列码得到的，这个序列码在发送时给出，在接收到确认时被覆盖；另一个平滑环路时间（SRTT）：SRTT=(ALPHA*SRTT)+((1-ALPHA)*RTT)通过上面的式子，可以得到重传超时RTO：RTO=min[UBOUND，max[LBOUND，(BETA*SRTT)]]其中UBOUND是超时的上界（如1分钟），LBOUND是超时的下界（如1秒钟），ALPHA是平滑因子（如0.8到0.9），BETA是延时变量（如1.3到2.0）。3.传送紧急消息

TCP的紧急机制允许发送者使接收者接收一些紧急消息，并让接收方在接收到这一消息后立刻通知用户。这种机制是在数据流是加入一个点，指出这是紧急数据的结束点，当接收方要接收到这个点之前，它会通知用户进入紧急状态，在接收到这个点的数据后，它会通知用户进入通常状态。如果这个紧急点在用户进入紧急状态时更新，这个更新必须对用户透明。应用一个紧急域的方法可以达到上述目的，而URG控制标记则指明紧急域是否被使用，而且在数据段中必须加入指示紧急点的序列号，如果没有这个标记则说明没有紧急点。如果需要发送紧急数据，发送方必须起码发送一个字节。6.2.4TCP的拥塞控制

在互联网中，拥塞是由于网关数据报超载而引起的严重延迟现象，一旦发生拥塞，网关将抛弃数据报，导致重传，而大量的重传会进一步加剧拥塞。因此，TCP必须进行拥塞控制。总的来说，TCP的拥塞控制是基于滑动窗口协议的。通过限制发送端向互联网注入报文的速率而达到控制拥塞的目的。滑动窗口的范围决定了发送方发送的但未被接收方确认的数据报的数量。各报文按序发送出去，但确认不一定按序返回，一旦窗口前面部分报文得到确认，则窗口向后滑动相应位置，落入窗口的后续报文又可连续发送。这种机制不需要对每个数据报都进行确认，提高了网络的吞吐量。TCP滑动窗口用于暂存两台主机间要传送的数据。

每个TCP/IP主机有两个滑动窗口：一个用于接收数据，另一个用于发送数据。

图6.9中发送滑动窗口的窗口大小为3，接收窗口的窗口大小为2。其中报文1、2、3已发送且1、2、3被确认后，发送报文4、5并正在确认。在接收端，窗口内的序号对应于允许接收的帧，窗口前的帧是已收到且已发出确认的帧，是不允许接收的，窗口后的帧要等待窗口滑动后才能接收。在TCP中，接收端会向发送端指示它可以发送的字节数，即它的接收窗口大小，发送方根据接收方所通告的窗口大小和发送端的拥塞窗口来决定发送窗口。发送窗口=

min（接收方通告窗口，拥塞窗口）在非拥塞状态下，拥塞窗口和接收方通告窗口大小相等，一旦发现拥塞，TCP将减小拥塞窗口。TCP发现拥塞的途径有两条，一是来自ICMP源抑制报文

，二是报文丢失的现象。TCP假定多数报文丢失都源于拥塞，为迅速抑制拥塞，TCP采取成倍递减拥塞窗口的策略：一旦发现报文丢失严重，立即将拥塞窗口大小减半。对于保留在发送窗口中的报文，根据Karn算法，按指数级延长重传定时器的定时。这样的结果是：拥塞窗口呈几何级数减小，而发送方发送报文的速度和重传率也呈几何级数减少，最终可能出现发送窗口为1。若此时继续出现重传，根据Karn算法，TCP将成倍增加重传超时。拥塞结束后，TCP又采取一种算术级窗口恢复策略，以避免迅速增加窗口大小造成的振荡，过程是，当在一条新连接或经过一定时间拥塞后开始恢复的连接上传输数据时，都要从大小为1的拥塞窗口开始，之后每收到一个确认，拥塞窗口大小增加1，直到恢复到正常窗口大小。另外，TCP还附加一条限制，当拥塞窗口增加到原来大小的一半时，进入“拥塞避免”状态，减缓增大窗口的速率。在拥塞避免状态，TCP在收到窗口中所有报文的确认后才将拥塞窗口增1。TCP中每个数据段都包括下一个希望接收到的序列号。窗口比较大会提高传送速度，如果传送过来的数据超过窗口大小，数据会被抛弃。这样会加重网络负担。对于健壮的TCP来说，最好不要自己缩小窗口，但要做要准备对方的TCP缩小窗口。6.3用户数据报协议UDP用户数据报协议UDP是定义用来在互连网络环境中提供包交换的计算机通信的协议。作为在传输层中的UDP协议是建立在IP协议基础之上的，默认认为IP协议是其下层协议。UDP协议提供了向另一用户程序发送信息的最简便的协议机制，它是面向操作的，未提供提交和复制保护。因此，UDP和IP协议一样是不可靠的数据报服务。如果应用程序要求可靠的数据传送应该使用传输控制协议（TCP）。6.3.1UDP概述UDP是一个简单的的传输层协议。所谓面向数据报，是指进程的每个输出操作都正好产生一个UDP数据报，并组装成一份待发送的IP数据报。这与如TCP等面向流字符的协议不同，应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系。UDP的数据报格式如图6.10所示：1.UDP数据报中的域信源端口(Sourceport)：是可选域，当其有意义时，它指的是发送进程的端口，说明在没有其它信息的情况下，返回信息应该向什么地方发送。如果不使用它，则在此域中填0。

信宿端口(Destinationport)：在有特定的目的网络地址时有意义。

长度(Length)：此用户数据报长度的八进制表示（最小的数据报长度是8）。

校验和(Checksum)：16位，是对IP头，UDP头和数据中信息包头的数位取反之和再取反得到的。这个校验过程与TCP中使用的过程一致。包头从概念上说是在UDP头信息之前的，它包括有源地址，目的地地址，所使用的协议和UDP长度。这些信息使信息不能被错误地接收。

UDP的校验域是可选的，如果校验码为零，意味着发送者未产生校验码。这表示对于数据段不使用校验，因为IP只是对IP头进行校验。2.UDP协议的接口（1）用户接口用户接口应该允许创建新的接收端口，在接收端口的接收操作有：应该返回一个八进制数说明源端口和源地址，允许数据报传送，指定数据，源和目标端口和目的地地址。（2）IP层接口UDP模块必须能够决定源和目标的网络地址，而且必须能够从包头中得知所使用的协议。一个可能的接口方式是返回整个数据报，包括接收操作返回的包头。这样的接口还应该允许UDP向IP传送完整的带包头的数据报用于传送。由IP来确定一致性并计算校验码。3.协议应用

UDP协议的最主要的用途是DNS服务器和小文件传输协议TFTP(TrivialFileTransferProtocol)。在IP中使用它时，它的协议号是17（八进制中是21）。UDP不提供可靠性：它把应用程序传给IP层的数据发送出去，但是并不保证它们能到达目的地。由于缺乏可靠性，似乎觉得要避免使用UDP而使用一种可靠协议如TCP。下面讨论什么样的应用程序可以使用UDP。在TFTP及Internet名字服务器上都使用UDP协议。在伯克利的UNIX上，一些检查网络用户的命令（如rwho等）使用的也是UDP协议。SunMicrosystem公司开发的NFS也是在UDP上实现的。UDP由于协议简单，系统对网络的负载很轻，故有利于大量数据的传送。应用程序必须关心IP数据报的长度。如果它超过网络的MTU（最大传输单元），那么就要对IP数据报进行分片。如果需要，源端到目的端之间的每个网络都要进行分片，并不只是发送端主机连接第一个网络才这样做。6.3.2UDP端口号

一个UDP端口是一个可读可写的软件结构，内部有一个接收报文缓冲区。发送数据时，UDP软件构造一个数据报，然后把它交给IP软件，便完成所有的工作。接收数据时，UDP软件首先要判断接收数据报的信宿端口是否与当前正在使用的某端口匹配，假如是，则将数据报放入相应接收队列，否则，抛弃该数据报，并向信源端发送“端口不可到达”ICMP报文，虽然端口匹配成功，但如果相应端口队列已满，UDP也要抛弃该数据报。端口号表示发送进程和接收进程。TCP和UDP用目的端口号来分用来自IP层的数据。由于根据IP首部中协议字段值，IP层已经把IP数据报分配给TCP或UDP，因此TCP端口号由TCP来查看，而UDP端口号由UDP来查看。TCP端口号与UDP端口号是相互独立的。但是，如果TCP和UDP同时提供某种知名服务，尽管相互独立，两个协议通常选择相同的端口号。这纯粹是为了使用方便，而不是协议本身的要求。UDP长度字段指的是UDP首部和UDP数据的字节长度。该字段的最小值为8字节。这个UDP长度是有冗余的。IP数据报长度指的是数据报全长，因此UDP数据报长度是全长减去IP首部的长度（该值在首部长度字段中指定，）。6.3.3UDP校验和

UDP校验和覆盖UDP首部和UDP数据。回想IP首部的校验和，它只覆盖IP的首部，并不覆盖IP数据报中的任何数据。UDP和TCP在首部中都有覆盖它们首部和数据的校验和。UDP的校验和是可选的，而TCP的校验和是必需的。尽管UDP校验和的基本计算方法与IP首部校验和计算方法相类似（16bit字的二进制反码和），但是它们之间存在不同的地方。首先，UDP数据报的长度可以为奇数字节，但是校验和算法是把若干个16bit字相加。解决方法是必要时在最后增加填充字节0，这只是为了校验和的计算。（也就是说，可能增加的填充字节不被传送。）其次，UDP数据报和TCP段都包含一个12字节长的伪首部，它是为了计算校验和而设置的。伪首部中包含IP首部一些字段。其目的是让UDP两次检查数据是否已经正确到达目的地（例如，IP没有接受地址不是本主机的数据报，以及IP没有把应传给另一高层的数据报传给UDP）。如果校验和的计算结果为0，它存入的值为全1（65535），相当于它的算术二进制反码。如果传送的校验和为0，说明发送端没有计算校验和。如果发送端没有计算校验和，而接收端检测到校验和有差错，那么UDP数据报就要被悄悄地丢弃。不产生任何差错报文。（当IP层检测到IP首部校验和有差错时也这样做。）UDP校验和是一个端到端的校验和。它由发送端计算，然后由接收端验证。其目的是为了发现UDP首部和数据在发送端到接收端之间发生的任何改动。尽管UDP校验和是可选的，但应该始终使用它。在数据报通过路由器时，通过对链路层数据帧进行循环冗余检验（如以太网或令牌环数据帧）可以检测到大多数的差错，导致传输失败。在实际的网络上，路由器中也会存在软件和硬件差错，以致于修改数据报中的数据。如果关闭端到端的UDP校验和功能，那么这些差错在UDP数据报中就不能被检测出来。另外，一些数据链路层协议（如SLIP）没有任何形式的数据链路校验和。注意，TCP发生校验和差错的比例与UDP相比要高得多。这很可能是因为在该系统中的TCP连接经常是“远程”连接（经过许多路由器，网桥等中间设备），而UDP一般为本地通信。不要完全相信数据链路（如以太网，令牌环等）的CRC校验。应该始终打开端到端的校验和功能。如果数据很有价值，更不要完全相信UDP或TCP的校验和，因为这些都只是简单的校验和，不能检测出所有可能发生的差错。6.3.4最大UDP数据报长度

IP数据报理论上的最大长度是65535字节，这是由IP首部16位总长度字段所限制的。去除20字节的IP首部和8个字节的UDP首部，UDP数据报中用户数据的最大长度为65507字节。1.两个限制因素但是，大多数实现所提供的长度比上述的最大值小。因为有两个限制因素：(1)应用程序可能会受到其程序接口的限制。socketAPI提供了一个可供应用程序调用的函数，以设置接收和发送缓存的长度。对于UDPsocket，这个长度与应用程序可以读写的最大UDP数据报的长度直接相关的。现在的大部分系统都默认提供了可读写大于8192字节的UDP数据报。（使用这个默认值是因为8192是NFS读写用户数据数的默认值。）(2)TCP/IP的内核实现可能存在一些实现特性（或差错），使IP数据报长度小于65535字节。这个限制与源端和目的端的实现有关。在许多UDP应用程序的设计中，其应用程序数据被限制成512字节或更小。例如，路径信息协议总是发送每份数据报小于512字节的数据。在其它UDP应用程序如DNS，TFTP，BOOTP以及SNMP遇到这个限制。2.数据报截断

由于IP能够发送或接收特定长度的数据报并不意味着接收应用程序可以读取该长度的数据。因此，UDP编程接口允许应用程序指定每次返回的最大字节数。如果接收到的数据报长度大于应用程序所能处理的长度，该问题的答案取决于编程接口和实现。在讨论TCP时，发现它为应用程序提供连续的字节流，而没有任何信息边界。TCP以应用程序读操作时所要求的长度来传送数据，因此，在这个接口下，不会发生数据丢失。6.4

应用层协议

本节介绍TCP/IP中最为常见的应用层协议：Telnet、FTP、小文件传输协议TFTP、简单邮件传输协议SMTP和HTTP协议。本章只讨论这些协议与TCP和IP的关系、控制代码及特点以及典型应用实例。读者在读完本节后，应能充分理解为何要使用这些协议以及这些协议是如何适应TCP/IP的。6.4.1域名服务

在TCP/IP网络中，每一个节点都有一个唯一的IP地址，作为节点唯一的标志。当TCP/IP正式成为网络的新标准后，人们提出了使用容易记忆的主机名(HostName)代替IP方式的设想。它运行在TCP协议之上，负责实现IP与主机名的转换。这个过程就是域名解析，负责域名解析的机器称为域名服务器。1.主机名解析

最简单的主机名解析方法是，使用HostName对照表将容易记忆的主机名代替不容易记忆的IP地址。在一个文件中记录所有主机名及与其对应的IP地址，并保证该文件中主机名的唯一性，通过检索文件就可以完成主机名的解析。主机名字最主要的工作就是IP到主机名字的转换（例如将03转换成），这样所形成的数据表就成为主机名表（HostTable），可直接使用人工方式维护。要测试HostTable的运作，可直接使用ping命令。2.域名系统

随着网络的不断发展，网络中的主机数量爆炸性地增加，使用主机文件作为域名解析的方法已经无法适应新的解析需要。在Internet上，采用域名系统DNS作为名字主机的另一种解决方案。DNS主要的功能也是处理IP与名字方面的转换，但DNS与主机名表最大的区别是DNS服务器采用动态的、分布式树状结构。在分布式的域名服务器体系中，每一台域名服务器负责解析属于自己的一部分主机的域名。一般说来，如果所处在公司或组织所拥有的主机并不多，通常可将域名的解析工作交给自己的ISP的域名服务器来完成。而如果所在组织拥有的主机比较多，就可以组建自己的域名服务器，负责解析所在组织的主机。（1）域名的层次树状结构DNS结构是一个树状结构，由最高的根域名往下扩展，每一个层都有其相应的属性。如第二层即属于分类、第三层即属于组织、第四层即属于主机名等。这样所组成的结构，称为域名的空间(NameSpace)，如图6.11所示。

（2）域名系统六大分类NIC机构定出域名系统最早的六大分类，如表6.4所示。由于DNS系统起初没有考虑跨国家的范围，随着Internet的崛起，美国NIC组织保留了六大分类并且将所有非美国的国家分布于第一层，例如中国为.cn，并将该国家的DNS系统交由该国家负责。

3.DNS的组成

DNS的主要目标是使资源有一个一致的名字空间。为了避免不同编码带来的问题，需要将网络标记、地址、路由或其它信息作为名字的一部分，要对名字所代表的资源类型有一个标记，要支持多协议访问。名字服务器的操作应独立于通信系统，能够使不同的机器、不同的方法都能够使用这一系统。为了要在获取数据的代价和数据准确性之间有一个平衡，DNS使用分布式的存储方式。DNS由下面三个部分组成：（1）域名空间和资源记录。域名空间是一个树状结构，资源记录是与名字相关的一些数据。每个节点和域名空间树的叶子节点都有一定的信息，而查询是要查询出一些与之相关的特定信息。（2）名字服务器。又称为DNS服务器，主要用来存放IP与主机名转换的数据库，并负责管理有关域名的事宜。（3）名字解释器是向名字服务器提出查询请求并将结果返回给客户的程序，它必须可以访问至少一个名字服务器，并将结果直接返回给用户或向别的名字服务器查询。它通常是用户可以访问的系统方法，在名字解释器和用户程序之间不需要协议。4.DNS三个部分组成之间的相互关系

下面通过三个不同的角度来看看它们的相互关系：（1）从用户的角度，域名系统可以通过简单的过程或操作系统调用来调用本地名字解释器进行查询。域名空间包括一个单独的树，用户可以从树中的任何一个部分查询信息。（2）从名字解释器的角度，域名系统由一些名字服务器组成，每个服务器有域树的整个或部分数据，名字解释器将这些数据库视为基本是静态的。（3）从名字服务器的角度，域名系统由称为区（zone）的本地数据集组成，名字服务器必须定期从主备份上更新自己区内的数据，它还必须处理从名字解释器传送来的查询请求。5.名字解释过程概述

名字解释是实现名字到地址的映射，将名字解释为IP地址的过程。DNS名字服务器可实现对向前的解释查询和逆向解释的查询。所谓向前的解释查询是将名字解释为IP地址的要求，而逆向解释查询则要求将IP地址解释成名字。名字服务器只能对它可进行认证(authority)的一个区域(Zone)进行查询。如果某个名字服务器不能得到某个查询结果，就将该查询传送的其它能够得到结果的名字服务器。名字服务器将查询结果存入高速缓冲区以减少网络上的DNS传送。（1）标准查询(向前查询)DNS服务使用client/server模型进行名字解释。在进行向前查询时，客户机将一个查询传送到本地名字服务器。本地名字服务器或者给出查询的解释或将查询请求传送到另一台名字服务器以得出结果。图6.12说明了某客户机向名字服务器查询的IP地址的过程。

图中的数字表示了如下的查询步骤：图6.12标准查询示例

①

客户机传送有关的一个向前查询到本地名字服务器。

②

本地名字服务器检查该向前查询的区域(zone)数据库文件以确定是否存在客户端所查询的名字到IP地址的映射。由于本地名字服务器没有关于

域的认证权限，就将该查询传送到DNS的一个根服务器，要求对主机名进行解释。③

根名字服务器返回一个对于com名字服务器的参照。

④

本地名字服务器向com名字服务器发出查询请求。⑤com名字服务器回应有关Microsoft名字服务器的信息。

⑥

本地名字服务器向Microsoft名字服务器发出查询请求，Microsoft名字服务器接收该请求。⑦

由于Microsoft名字服务器对于域名空间的该部分具有认证权限，它返回

的IP地址给本地名字服务器。

⑧

本地名字服务器将

的IP地址发送给客户机。

至此，名字解释完成，客户机可使用

的IP地址进行访问。

（2）名字服务器高速缓冲区为了加快查询速度，将常用域名暂时存放在高速缓冲区中。当客户端主机向DNS查询有关域名时，则DNS服务器会先到高速缓冲区寻找，如果有有关域名则传回给客户端，没有则到最近的DNS主机寻找。当一个名字服务器接收到一个查询结果，将执行下列动作：①

名字服务器在某存活时间段TTL中将查询结果存入高速缓冲区。TTL由提供查询的区域指定。可使用DNSsnap-in对TTL进行配置。默认值为60min。

②

每次将查询结果存入高速缓冲区，TTL即开始由原始值开始倒计数。

③TTL超时，名字服务器从高速缓冲中删除该查询结果。

（3）逆向查询请求逆向查询将IP地址映射到名字。实际的应用程序的安全实现，通常是基于连接到主机名而不是连接到IP地址。例如故障查找工具（如nslookup命令）可使用逆向查询返回有关主机名的报告。由于DNS分布式数据库是以名字为索引而不是以IP地址为索引的，逆向查询需要对每个域名的穷举搜索。要解决这个问题，建立了一种特殊的称为的第二层域。与域名空间一样，域遵守分层命名规则；但是它是基于IP地址的而不是基于域名的。域的构成遵守下面的规则：·子域以域名方式表示，位于点分十进制表示的IP地址之后。

·IP地址的octets顺序是逆向的。

·

域的公司管理的子域基于它们被指定的IP地址和子网掩码。

例如，某公司的IP地址范围是

到55子网掩码为

，具有对于16.254.169.域的认证权限。6.IN-ADDR-ARPA域名服务DNS通过使用名字数据库中的资源记录进行名字解释。

地址资源记录类型中的地址字段，使用一种称为IN-ADDR-ARPA的专用格式。这种格式允许地址和主机名之间的双向转换。为了更好地理解IN-ADDR-ARPA，有必要首先介绍标准格式的资源记录。如前所述，资源记录采用ASCII格式进行维护。资源记录的一种最简单类型用于地址（类型A）。下面是一个地址文件的摘录：

TPCI_HPWS1INA0TPCI_HPWS2INA1TPCI_HPWS3INA2TPCI_GATEWAYINA00INAMERLININASMALLWOODINA5文件的每一行表示一个资源记录。在上述情况下，每个资源记录都是简单的输入项。这些输入项包括主机的符号名（别名）、主机的类别（IN代表Internet），A表示是地址资源记录，后面紧跟着主机的IP地址。因为TPCI_GATEWAY主机是两个网络之间的网关，所以它的输入项有两个对应地址。网关在每个网络上有不同的地址，因此在同一个文件中有两个资源记录。采用上述文件类型可使主机到地址的转换十分简单。名字服务器只需查找应用程序所请求的符号名所在行，并在行的末返回IP地址。由于数据库索引按名称排列，所以查找过程非常迅速。

从地址查找对应的主机符号名比较复杂一些。如果资源记录文件比较小，手动查找的时间延迟并不明显。但是，对于大型区域，输入项可能有成千上万，使用符号名索引来查找地址是相当缓慢的。为了解决逆向变换问题，人们开发了IN-ADDR-ARPA，它采用主机地址作为主机资源记录信息索引。IN-ADDR-ARPA使用PTR资源记录类型(参看表6.2)，由地址指向名字。在每个名字服务器上都维护这种指针索引。下面是一个地址到名的转换文件：

43.IN-ADDR-ARPA.PTRTPCI_HPWS_4.TPCI.COM47.IN-ADDR-ARPA.PTRTPCI_SERVER.MERLIN.COM23.IN-ADDR-ARPA.PTRBEAST.BEAST.COM23.143.IN-ADDR-ARPAPTRMERLINGATEWAY.MERLIN.COM为了便于使用，Internet地址在IN-ADDR-ARPA文件中是倒写的。如上述样本文件所示，不必为网关指定完整的地址，因为域名可以提供足够的路由信息。

6.4.2WWW的核心——HTTP协议WWW服务器使用的主要协议是HTTP协议，即超文体传输协议。由于HTTP协议支持的服务不限于WWW，还可以是其它服务，因而HTTP协议允许用户在统一的界面下，采用不同的协议访问不同的服务，如FTP、Archie、SMTP、NNTP等。另外，HTTP协议还可用于名字服务器和分布式对象管理。

1.HTTP协议概述

超文本传输协议HTTP(HypertextTransferProtocol)是用于从WWW服务器传输超文本到本地浏览器的传送协议。它定义了浏览器与WWW服务器之间的通信交换机制、请求及响应消息的格式等，一个WWW客户机使用HTTP协议可以访问远程的WWW服务器上的资源。HTTP的服务被称为超文本传输协议守护进程httpd(HyperTextTransferProtocolDaemon)。HTTP使用了统一资源定位器URL(UniformResourceLocator)的概念，以标识Ineternet或者与Internet相连的主机上任何可用的数据对象。简单地说，URL就是文件在环球信息网上的“地址”。当在浏览器的地址框中输入一个URL或是单击一个超级链接时，URL就确定了要浏览的地址。浏览器通过超文本传输协议HTTP，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。（1）URL的组成在URL概念背后有一个基本思想，那就是在提供一定的信息条件下，应能在Internet上的任何一台机器上访问任何可用的公共数据。这些信息包括：所使用的访问协议、数据所在的机器、请求数据的数据源端口、通向数据的路径和包含了所需数据的文件的名称。这些信息组成了URL。

URL的标准格式如下：Protocol://machineaddress：port/path/filename例如：/china/index.htm。（2）HTTP协议的特点HTTP协议的主要特点可概括如下：①

支持客户/服务器模式。②

简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。③

灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。④

无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。⑤

无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。但是，在服务器不需要先前的信息时它的应答就较快。

（3）公共网关接口公共网关接口CGI（CommonGatewayInterface）是用于提供Web服务器一个外部程序的通道。它使服务器能够建立动态网页，与其它非HTTP服务器如数据库服务器连通。使用CGI技术建立的服务端应用程序，称为CGI程序。CGI程序就是一个标准的执行文件，可使用各种程序语言开发，如Java、VBScript等。2.多用途Internet邮件扩展MIME

多用途Internet邮件扩展MIME（MultipurposeInternetMailExtensions）技术规范提供了一种可以在邮件中附加多种不同编码文件的方法。现在MIME已经成为了HTTP协议标准的一个部分，可以在用来传送可以供浏览器识别的信息。在MIME出现以前，信件内容如果要包括声音和动画，就必须把它变为ASCII码或把二进制的信息变成可以传送的编码标准，而接收方必须经过解码才可以获得声音和图画信息。MIME提供了一种可以在邮件中附加多种不同编码文件的方法。MIME是服务器通知客户机传送文件是什么类型的主要方法，客户机浏览器也通过MIME告诉服务器它的参数。在网上，如果接收到的文件没有MIME首部，就默认它为HTML格式。但这样显示出来的内容就会很单调。用在电子邮件中或用在浏览器上的MIME首部的内容有所不同。在HTTP中传送MIME时，MIME首部要简单一些。在访问一个网页时，浏览器和服务器之间产生一个会话，作为请求内容的一部分，浏览器发送它能够理解的MIME类型的描述，即告诉服务器，浏览器除了网页外还可以支持什么，服务器对这个信息一般不作什么修改。看看下面这个首部：Content-type:text/html

在实现的时候，注意一定要在MIME首部后跟一个空行，否则该首部将被浏览器忽略，并将该首部当作文本显示出来。下面介绍一下标准MIME类型。

Text.文本，包括普通文本，PostScript和HTML；Multipart.多类型，指出此信息包括多种信息，不止一种类型；

Message.用于标记不同类型的消息；

Application.应用类型；

Image.图象，用于标明图形文件；

Audio.声音，用于标明声音文件；

Video.影象，用于标明动画文件。

每个MIME类型有不同的子类型。IANA规定了对45种类型/子类型的支持，也允许用户自定义自己的类型，用户自定义类型要以“X-”开始以示区别。HTTP协议是基于请求／响应模式的。一个客户机与服务器建立连接后，发送一个请求给服务器，请求的格式为：统一资源标识符、协议版本号，后边是MIME信息，包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理和服务器之间通过一个单独的连接来完成。在Internet上，HTTP通讯通常发生在TCP/IP连接之上。默认端口是TCP80。

HTTP通讯最简单的情况可能是在用户代理(UA)和源服务器(O)之间通过一个单独的连接来完成。当一个或多个中介出现在请求／响应链中时，情况就变得复杂一些。中介有三种：代理(Proxy)、网关(Gateway)和通道(Tunnel)。一个代理根据URL的绝对格式来接受请求，重写全部或部分消息，通过URL的标识把已格式化过的请求发送到服务器。网关是一个接收代理，作为一些其它服务器的上层，并且如果必须的话，可以把请求翻译给下层的服务器协议。一个通道作为不改变消息的两个连接之间的中继点。当通讯需要通过一个中介(例如：防火墙等)或者是中介不能识别消息的内容时，经常使用通道。

图6.14表明了在用户代理(UA)和源服务器(O)之间有三个中介(A、B和C)。尽管图6.14是线性的，每个参与者都可能从事多重的、并发的通讯。例如，B可能从许多客户机接收请求而不通过A，并且／或者不通过C把请求送到A，在同时它还可能处理A的请求。

图6.14用户代理和源服务器之间有三个中介

任何针对不作为通道的汇聚可能为处理请求启用一个内部缓存。缓存的效果是请求／响应链被缩短，条件是沿链的参与者之一具有一个缓存的响应作用于那个请求。图6.15说明结果链，其条件是针对一个未被UA或A加缓存的请求，B有一个经过C来自O的一个前期响应的缓存拷贝。3.HTTP协议的内部操作过程

基于HTTP协议的客户/服务器模式的信息交换过程包括：建立连接、发送请求信息、发送响应信息、关闭连接。当服务器上的HTTP守护进程接收到请求，在进行必要的操作后回送所要求的文件。(1)建立连接

连接的建立是通过申请套接字(Socket)实现的。服务器上有一个HTTP守护进程，用于响应用户请求。WWW服务器运行时，一直在TCP80端口(WWW的默认端口)监听，等待连接的出现。当客户浏览器中输入了一个URL或点击了一个超级链接时，浏览器就向服务器发送了HTTP连接请求，打开一个套接字并把它约束在一个端口上，如果成功，就相当于建立了一个虚拟文件。以后就可以在该虚拟文件上写数据并通过网络向外传送。(2)发送请求信息打开一个连接后，客户机把请求消息送到服务器的特定端口上，完成提出请求动作。HTTP/1.0请求消息的格式为：请求消息=请求行(通用信息|请求首部|实体首部)CRLF[实体内容]请求行=方法请求URL

HTTP版本号CRLF方法=GET|HEAD|POST|扩展方法URL=协议名称+宿主名+目录与文件名请求行中的方法描述指定资源中应该执行的动作，常用的方法有GET、HEAD和POST。不同的请求对象对应GET的结果是不同的，对应关系如下：对象GET的结果：文件文件的内容程序该程序的执行结果数据库查询查询结果HEAD——要求服务器查找某对象的元信息，而不是对象本身。POST——从客户机向服务器传送数据，在要求服务器和CGI做进一步处理时会用到POST方法。POST主要用于发送HTML文本中FORM的内容，让CGI程序处理。一个请求的例子为：GEThttp://WWW./home.htmlHTTP/1.0（3）发送响应消息服务器在处理完客户的请求之后，要向客户机发送响应消息。HTTP/1.0的响应消息格式如下：响应消息=状态行(通用信息首部|响应首部|实体首部)

CRLF〔实体内容〕状

态

行=HTTP版本号状态码原因叙述状态码表示响应类型响应首部的信息包括：服务程序名，通知客户请求的URL需要认证，请求的资源何时能使用。（4）关闭连接客户和服务器双方都可以通过关闭套接字来结束TCP/IP对话。4.HTTP连接观察实例

在HTTP协议中，服务端是指提供HTTP服务的部分，客户端是指使用的浏览器或者下载工具等等。在通讯时，由客户端发出请求连接，服务端建立连接；然后，客户端发出HTTP请求（Request），服务端返回响应信息（Respond），由此完成一个HTTP操作。与FTP（文件传输协议）不同，由于主要用于超文本传输，因此HTTP协议显得更简单一点。下面用Net

Vampire监测的一次HTTP连接，使用Net

Vampire

Pro

4.0来取得与HTTP服务器的通信Log，以显示和介绍HTTP协议的连接过程和HTTP/1.1的基本格式。

6.4.3其他常见的应用层协议

1.邮件服务协议SMTP/POP3

2.SMTP协议原理

3.POP3邮局协议

4.远程登录Telnet

5.文件传送协议FTP

1.邮件服务协议SMTP/POP3

简单邮件传输协议SMTP（SimpleMailTransferProtocol）的目标是可靠高效地传送邮件，它独立于传送子系统而且仅要求一条可以保证传送数据单元顺序的通道。SMTP的一个重要特点是它能够在传送中接力传送邮件，传送服务提供了进程间通信环境，此环境可以包括一个网络，几个网络或一个网络的子网。理解到传送系统（或进程间通信环境）不是一对一的是很重要的。进程可能直接和其它进程通过已知的IPCE通信。邮件是一个应用程序或进程间通信。邮件可以通过连接在不同IPCE上的进程跨网络进行邮件传送。更特别的是，邮件可以通过不同网络上的主机接力式传送。SMTP设计基于以下通信模型：针对用户的邮件请求，发送SMTP建立与接收SMTP之间建立一个双向传送通道。接收SMTP可以是最终接收者也可以是中间传送者。SMTP命令由发送SMTP发出，由接收SMTP接收，而应答则反方面传送。一旦传送通道建立，SMTP发送者发送MAIL命令指明邮件发送者。如果SMTP接收者可以接收邮件则返回OK应答。SMTP发送者再发出RCPT命令确认邮件是否接收到。如果SMTP接收者接收，则返回OK应答；如果不能接收到，则发出拒绝接收应答（但不中止整个邮件操作），双方将如此重复多次。当接收者收到全部邮件后会接收到特别的序列，如果接收者成功处理了邮件，则返回OK应答。图6.16示出了SMTP的通信模型。图6.16SMTP通信模型

SMTP提供传送邮件的机制，如果接收方与发送方连接在同一个传送服务下时，邮件可以直接由发送方主机传送到接收方主机；当两者不在同一个传送服务下时，通过中继SMTP服务器传送。为了对SMTP服务器提供中继能力，它必须拥有最终目的主机地址和邮箱名称。MAIL命令参数是回复路径，它指定邮件从何处来；而RCPT命令的参数是转发路径的，它指定邮件向何处去。向前路径是源路径，而回复路径是返回路径（它用于发生错误时返回邮件）。当同一个消息要发往不同的接收者时，SMTP遇到了向不同接收者发送同一份数据的复制品的问题，邮件命令和应答有一个比较奇怪的语法，应答也有一个数字代码。命令与应答对大小写不敏感，也就是说，命令和应答可以是大写，小写或两者的混合，而SMTP实现中将用户邮箱名称保留成初始时的样子，主机名称对大小写不敏感。2.SMTP协议原理

简单邮件传输协议SMTP是定义邮件传输的协议，它是基于TCP服务的应用层协议，由RFC0821所定义。SMPT协议规定的命令是以明文方式进行的。为了说明SMTP的工作原理，以向www.L发送邮件为实例进行说明。（1）接收和发送邮件的全过程在Linux环境下，使用telnet命令连接www.L的25号端口(SMTP的标准服务端口)；在windows下使用telnet程序，远程主机指定为www.L，而端口号指定为25，然后连接www.L：交互过程如下：其中顶格部分是输入的命令，其他内容是对方邮件服务器输出的状态信息。这里，HELO是客户向对方邮件服务器发出的标识自己的身份的命令，这里假设发送者为ideal；MAILFROM命令用来表示发送者的邮件地址；RCPTTO：标识接收者的邮件地址，这里表示希望发送邮件给ideal@L，如果邮件接收者不是本地用户，例如RCPTTO：ideal@，则说明希望对方邮件服务器为自己转发(Relay)邮件，若该机器允许转发这样的邮