传输层详解

传输层详解

①理解TCP的封装和工作原理

②理解UDP的封装和工作原理

③了解常用的TCP和UDP端口号

④对TCP和UDP首部能够进行分析

 

传输层的作用是什么?传输层实现端到端的连接，端到端是什么概念呢?打个比方说，一个人用QQ与朋友聊天，网络层识别IP地址，能够将信息送到正确的主机，而主机应该使用什么应用协议接收这个信息呢? 这个功能就需要传输层来完成，传输层实现进程到进程的连接。

 

掌握了传输层的协议的封装，对学习后续的操作系统、网络的高级应用以及安全等课程是非常必要的。

 

传输层主要有TCP和UDP协议，在本章中，将深入讨论这两个协议的工作原理和使用，并且能使用抓包工具对数据的封装进行分析。

 

13.1  传输层概述

本节主要包括以下两个内容：

 

◇传输层的功能

 

◇传输层的协议

 

1．传输层的功能

 

(1)网络层协议只提供了点到点的连接，而传输层协议提供一种端到端的服务，即应用进程之间的通信。

 

(2)网络层协议提供不可靠、无连接和尽力投递的服务，因此，如果对于可靠性要求很高的上层协议，就需要在传输层实现可靠性的保障。

-------------------------------------------------------------------------------

提示：

◇进程是程序的一次执行。比如每个IE 浏览器的窗口都是一个进程实例，它们都是IE浏览器程序的一次执行。

◇每台计算机上同一时刻有许多进程在工作，为使一端计算机发出的数据能够被另一端计算机正确的程序接收，引入了端口号。不同的端口号对应于不同的进程。

-------------------------------------------------------------------------------

 

2．传输层协议主要有两个

 

◇TCP(Transmission Control：Protocol)

◇UDP(User Datagram Protocol)

 

    TCP即传输控制协议，是一个可靠的、面向连接的协议。它允许网络间两台主机之间无差错的信息传输。TCP协议还进行流量控制，以避免发送过快而发生拥塞。不过这一切

对用户都是透明的。

 

UDP即用户数据报协议，它采用无连接的方式传送数据，也就是说发送端不关心发送的数据是否到达目标主机，数据是否出错等。收到数据的主机也不会告诉发送方是否收到了数据，它的可靠性由上层协议来保障。

 

    这两个协议针对不同网络环境实现数据传输，各有优缺点。面向连接的TCP协议效率较低，但可靠性高，适合于网络链路不好或可靠性要求高的环境；UDP面向非连接，不可靠，但因为不用传送许多与数据本身无关的信息，所以效率较高，常用于一些实时业务，也用于一些对差错不敏感的应用。这样就可以在不同的场合和要求下选用不同的协议，达到预期通信目标。下面分别对TCP和UDP进行详细介绍。

 

13.2  TCP协议

TCP协议是为了在主机间实现高可靠性数据交换的传输协议。TCP协议是面向连接的端到端的可靠协议。它支持多种网络应用程序。TCP对下层服务没有多少要求，它假定下层只能提供不可靠的数据包服务，它可以在多种硬件构成的网络上运行。

 

在本节中我们将详细讨论TCP协议，TCP是可靠的传输层协议，那么，TCP依靠什么来提供可靠的服务?

 

下面主要从以下几个方面讨论TCP的工作原理：

 

◇TCP的封装格式

◇连接与断开    

◇流量控制

◇拥塞控制

◇差错控制

◇计时器

 

13.2.1  TCP的封装格式

TCP是面向连接的可靠协议，TCP协议为实现可靠的数据传输而提供了一系列的方法  和手段。

首先，TCP的数据段采取编号的方式保证数据的正确顺序。TCP数据段被封装在IP数据包中来完成传输，而IP数据包经过的路径有可能不同，那么IP数据包到达时可能会失去原有顺序，因而到达的TCP数据段也可能会失序。为了解决这个问题，TCP对数据段进行编号。对接收到的数据进行重新排序，然后以正确的顺序交给应用层。

    其次，由于到达的IP数据包有可能会发生重复，所以TCP的接收端必须有丢弃重复数据的功能。

再次，TCP提供流量控制。

TCP连接的每一方都有固定大小的缓冲空间，这就要求TCP的发送端只酋黾发送接收端缓冲区能接收下的数据。这将防止较快的主机导致较慢的主机缓冲区溢出。

上面的每一个功能都是针对每一个问题而设计的，那么TCP协议是如何实现这些功能的呢? TCP协议的各种功能的实现依赖于它的首部数据结构。在TCP的首部中包含了许多TCP数据段的重要信息，图13.1显示了TCP首部的数据格式。如果不计任选字段，它通常是20个字节。下面就TCP的首部数据结构进行详细讲解。

 

                    

 

图13.1  TCP首部数据格式

 

◇0～15这16位称为源端口号；它是TCP数据段发送方进程对应的端口号，这个端口号是由发送方进程产生的随机数，它唯一地标识了发送端的一个进程。

 

◇16～31这16位是目标端口号，它对应的是接收端的进程，接收端收到数据段后，根据这个端口号来确定把数据送给哪个应用程序的进程。这样才能保证数据到达正确的地方。否则，发给A程序的数据有可能被送给B程序，那么整个数据传输秩序就会变得很混乱。

 

◇第2行是32位的序列号，它提供0～2^32-1范围内的一个数字。TCP从应用程序取得数据后，会根据实际传输能力把数据划分成不同的数据段。TCP用这个数字来给数据段打上标记，当数据到达目的地后，接收端会按照这个序列号把数据重新排列，保证数据的正确性。

 

◇第3行是32位的确认序列号，它提供0～2^32-1范围内的一个数字。被分成许多数据段的数据虽然被做了标记，但并不能保证这当中的所有段都会到达目的地。然而对接收端来讲，只要有一个段没有接收到，就不能保证数据的正确性。使用确认号可以很好地解决这个问题。确认号是对发送端的确认信息，用它来告诉发送端这个序号之前的数据段都收到了，比如确认号是X，就是表示前X-1个数据段都收到了。如果一个数据段一直没有被确认，它将会被要求重发。这样数据的完整性就得到了保证。

 

◇第4行分为4个部分。

  ·第1部分是4位首部长度，用它可以确定首部数据结构的字节长度。一般情况下TCP首部是20个字节，但当要扩展首部长度大小时可以使用这个字段，比如把这4个位都置为1就得到TCP首部长度的最大值60。4位的最大值是1111换算成十进制是l5，表示首部长度为l5行。而每行数据有32位即4个字节长，所以首部长度为15×4=60。

 

·第2部分是6个保留位。这部分保留位作为今后扩展功能用，现在还没有使用到。

 

  ·第3部分是6个控制位。这6位有很重要的作用，TCP的连接、传输和断开都是受这6个控制位的指挥。各位含义如下：

 

    URG：紧急指针有效位，它和第5行的16位紧急指针配合使用，当URG=1时，TCP根据16位紧急指针确定紧急数据的最后一个字节的位置。这样接收端就可以优先准确快速

地获取紧急数据，确保紧急数据的即时到达。

    ACK：只有当ACK=1时确认序列号字段才有效。当ACK=0时，确认号无效。

    PSH：标志位为1时要求接收方尽快将数据段送达应用层，这个标志位是为了加快特殊数据的处理速度。

      RST：值为1时通知重新建立TCP连接。

       SYN：同步序号位。TCP需要建立连接时将这个位置为1。

       FIN：发端完成发送任务位，当TCP完成数据传输需要断开连接时，提出断开连接的一方将这个位置为1。

 

·第4部分是1 6位的窗口大小，它说明本地可接收数据段的数目，这个值的大小是可变的，当网络通畅时这个窗口值变大以加快传输速度，当网络不稳定时减小这个值可保证网络数据的可靠传输，TCP协议中的流量控制机制就是依靠变化窗口的大小实现的。

 

◇第5行中的16位校验和是用来做差错控制的，在发送TCP数据段时，由发送端计算TCP数据段所有字节的校验和。当到达目的地时又进行一次校验和计算。若这两次的校验和一致则说明数据基本是正确的。否则将认为该数据已被破坏，接收端将抛弃该数据。

 

◇第5行中的16位紧急指针和URG配合使用，当URG=1时有效。用来说明紧急数据的末尾字节的位置。

 

◇第6行是可选项，只有当4位首部长度大于20时才有效，那时TCP的首部中会附加更多的信息，一般情况下没有可选项。

 

◇第7行是数据，它是由应用层的数据分段而得到的一部分数据，是TCP协议服务的对象。在传输前TCP协议会给这部分数据加上一个序号，来表示这个部分数据在数据整体中的位置。

 

    一个TCP连接不仅需要端口，还需要IP地址来确定通信的主机。故而IP首部中的发

送端IP地址加上发送端端口号就形成了连接的发送端；目标端IP地址再加上接收端端口号

就确定了连接的接收端。这样就唯一地确定了一个TCP连接。

    在TCP/IP协议中，TCP协议是基于IP协议的。IP协议是对应于网络层的协议，它是

一个不可靠的协议。TCP协议的可靠性保证给IP协议提供了可靠环境，从而使得IP协议可以不必考虑传输的可靠性，专注于网络层的功能。这也是协议分层的初衷。TCP被认为是一种流式传输层服务。它表示TCP发送端从应用程序接收到字符流，并从这个流中提取适当的长度创建数据段，然后将其发送到网络上。TCP接收端则接收数据段，从中提取数据，若没有按序号到达还要对其进行排序，并将其作为字符流交付给接收端应用程序。这样就完成了数据的传输。

    为了进行流式交付，发送TCP和接收TCP都要利用缓冲。发送TCP使用发送缓冲来

存储从发送应用程序截取的数据。发送应用程序交付数据的速率是它产生数据的速率。例如，

在使用网络登录、控制远程主机时，用户在键盘上输入的数据就是逐个字符地交付给TCP

的发送端的。

13.2.2  TCP的连接与断开

    TCP是一个面向连接的服务，也就是说在数据通信之前，发送端与接收端要先建立连接。等数据发送结束后，双方再断开连接。

1．TCP建立连接

    TCP在建立连接的时候使用端口号来完成与应用程序的对应。当一台计算机和其他计算

机进行连接、通信时使用IP地址和端口号。连接的每一方都是由一个IP地址和一个端口号

组成的。比如通过IE浏览器上网时，通过解析输入的URL地址可以得到IP地址，这时还有

一个隐含的端口号80。这样就构成了连接的服务器方。同样，连接的客户端也会有自己的

IP地址和端口号。

    在计算机上可以通过命令netstat -n来查看目前存在的连接进程。TCP建立连接的过

程称为3次握手。建立连接的过程如图13.2所示。

图13.2  TCP 3次握手示意

◇第1次握手是主机A通过将一个含有“同步序列号”(SYN)标志位的数据段发送给主机B而开始请求连接。通过该数据段，主机A告知主机B两点：主机A希望建立连接请求，主机B应答；主机A告诉主机B使用哪个序列号作为数据传输时数据段的起始号。

◇第2次握手是主机B用一个带有“确认应答”(ACK)和“同步序列号”(SYN)标志位的数据段响应主机A。它也有两个目的：发送ACK通知主机A收到了数据段；通知A从哪个序列号开始给数据段做标记。

◇第3次握手是主机A再次发送一个数据段，确认收到了主机B的数据段，并可以开始传送实际数据。

◇这样3次握手就全部完成了，数据将开始传输。

    3次握手有如下特点：

◇没有应用层数据。

◇SYN这个标志位只有TCP建立连接时才被置为1。

◇握手完成后SYN标志位被置为0。

2．TCP断开连接

TCP建立一个连接时进行了3次握手，而终止一个连接要经过4次。这是由TCP的半关闭(half-close)造成的。

什么是TCP的半关闭呢? 因为一个TCP连接是全双工的(即数据可在两个方向上同时传递)，所以进行关闭时每个方向必须单独地进行关闭。这个单方向的关闭都称为半关闭。关闭的方法是一方完成它的数据发送任务后，就发送一个FIN来向另一方通告将要终止这个方向连接。当一端收到一个FIN，它必须通知应用层TCP连接已经终止了那个方向的数据传送。发送FIN通常是应用层进行关闭的结果。

TCP的断开要经过4步，但后两步和前两步很相似，只是关闭连接的双方调换角色而已。

    (1)TCP连接的一端A将控制位FIN置为1，提出停止TCP连接的请求。

(2)对端B收到FIN后对其做出响应，确认这一方向上的TCP连接将关闭。

(3)由B端再提出反方向的关闭要求，将FIN置为1。

(4)由A端对B提出的关闭做出应答，双方向的关闭结束。

这样一共经过4个步骤后，TCP全双工的双向连接都得到了正常的关闭。其关闭过程如图13.3所示。

图13.3  TCP断开连接

 

◇在数据传输阶段，主机A向主机B发送了序列号为100的数据段，主机B接收到后，发送了序列号为300、确认号为10l的确认数据段。这时，主机A与B之间已经完成了数据的传输。

 

◇主机A主动断开连接，向主机B发送序列号为101的数据段，其中将FIN标志位置为1，同时，确认前一个B发送来的数据段，确认号为301，并将ACK置1。

 

◇主机B接收到这个断连请求后，发送序列号为301、确认号为102的确认数据段，执行被动关闭。这时，完成了A→B的半关闭。

 

◇接着主机B向A发出了序列号为301、FIN置1的断连请求，要求断开B→A方向的连接。

 

◇主机A收到这个FIN，应答了一个确认号为302的确认序列，执行被动关闭。这时，完成了TCP的断开连接的工作。

 

------------------------------------------------------------------------------

提示： 在图13.3标出的第3步，主机B发送的断连请求中，序列号、确认号与上一个数据段相同。

------------------------------------------------------------------------------

 

TCP使用面向连接的通信方式，这大大地提高了数据传输的可靠性，使发送端和接收端在数据正式传输之前就有了交互，为数据正式传输打下了可靠的基础。但是单纯地连接并不能解决数据在传输过程中出现的问题，比如双方传输速度不协调、数据丢失、数据确认丢失等。对于这些问题，TCP使用流控制、差错控制、拥塞控制、计时器等手段来保证数据的可靠性。

 

下面将对TCP协议在传输数据的过程中可能出现的问题予以解决。

13.2.3  TCP的流控机制

为了解决发送与接收双方数据通信能力存在差异而带来的数据丢失问题，TCP引入了流量控制机制。TcP使用滑动窗口来实现流量控制，图13.4显示了滑动窗口的工作原理。

 

图13.4  滑动窗口的工作原理示意

 

◇在TCP建立连接的时候，主机A与B之间就进行了窗口大小的协商，主机A在发送连接建立请求的时候，就向主机B通告了自己发送窗口的大小，单位是字节(在本例中，为了讲解简单，使用简单的数字来举例)。

 

◇主机B缓冲区的大小为3，因此B向A发送确认的时候，宣告窗口大小为3。

 

◇主机A再次确认后，连接已经建立，开始发送数据。

 

◇主机A发送了3个数据段，主机B接收到数据后，缓冲区由空变为满，这时，应用程序读取了1个数据段，为缓冲区清空了大小为l的空间。

 

◇主机B向A确认收到的数据，并根据缓冲区空间的大小宣告窗口为l。如果B的缓冲区大小为O，B会向A宣告窗口大小为0，如果A接收到B窗口大小为0的确认，A会停止发送，等待B宣告一个非O的窗口时再发送数据。

 

◇主机A根据B宣告的窗口大小来发送数据。

 

13.2.4  TCP的拥塞控制

前面我们讨论了TCP的窗口机制，接收方可以根据其缓冲区的大小来指定窗口的大小，发送方遵守此窗口大小的限制，接收端不会发生缓；中区溢出的问题，但是有可能由于中间传输网络的带宽较小的原因，导致拥塞的发生，如图13.5所示，接收方和发送方的窗口大小为1O，中间链路的带宽比较大，不会产生拥塞，发送方可以按照窗口为10来发送数据。但是，如果中间链路的带宽比较小，实际发送数据时不能按照双方协商的窗口大小来传输数据，为了防止中间链路产生的拥塞，TCP引入了拥塞窗口(cwnd)的概念，实际发送数据的窗口采用发送方和接收方协商的窗口与拥塞窗口中的最小值。

图13.5  TCP的拥塞窗口

 

例如，如果通过一根胶皮管向一个水桶里灌水，水龙头的出水量很大，桶也很大，但是如果水管比较细，灌水的速度就不能取决于水龙头和水桶了，而是取决于水管的流量。

 

因此在TCP中，发送方要维护两个窗口来解决拥塞问题，一是接收方允许的窗口，二是拥塞窗口(cwnd)，这两个窗口的最小值将是发送方可以发送的窗口大小。如图13.6显示了TCP的拥塞控制。 

 

图13.6  TCP的拥塞控制

◇主机A与主机B在建立连接时协商了窗口的大小为3。

 

◇主机A向B发送了3个数据段。

 

◇主机B只接收到一个数据段，发送了确认号为102的确认。

 

◇在重传计时器超时前(关于超时计时器的内容，在后面会有详细的讲解)，主机A没有收到来自B的确认，A认为数据段102和103丢失。

 

◇主机A根据接收到的确认将拥塞窗口cwnd减小。

 

-------------------------------------------------------------------------------

提示：  实际的数据传送过程中是以字节为单位而不是数据段，此处以数据段为单位是为了讨论的方便。

-------------------------------------------------------------------------------

 

13.2.5  TCP的差错控制

    前面提到TCP是一个端到端的连接，数据在传输的过程中经过了许多的网络路径，有可

能出现各种错误，所以TCP提供了差错控制来保证可靠性。

 

TCP的差错控制包括如下一些方面：检测受损数据段、丢失的数据段、失序的数据段和

重复的数据段。差错控制还包括检测出差错后的纠错机制。

 

    TCP中的差错检验是通过3种简单方式完成的：校验和、确认和超时。

 

◇校验和：每一个数据段都包含校验和字段，用来检测受损数据段。若数据段受到损伤，

就由目的TCP将其丢弃。

 

◇确认：TCP使用确认的方式来证实收到了某些数据段，它们已经无损伤地到达了目的

TCP。

 

◇超时：若一个报文在超时前未被确认，则被认为是受到损伤或已丢失。

 

1．受损数据段

    当一个受损数据段到达目标站点，它将被丢弃，而且目标站点不认为自己已收到该受损

数据段，故而会请求重新发送。

 

图13.7中数据段3受到损伤，因而重发。而且可以看出发送端的窗口大小由3变为了

2。

图13.7  损伤的数据段

 

2．丢失的数据段 

    对TCP而言，丢失的数据段和受损数据段情况完全一样。只不过受损数据段是被目的站

丢弃的，而丢失的数据段是被中间的节点丢弃的。TCP并不认为收到过这些数据段。

 

3．重复的数据段

    重复的数据段可能由发送端TCP产生。在超时截止期到了而确认还没有收到的情况下，

发送端会重发，重发后的数据段和先前的数据段可能都到达了，于是发生了重复发送的现象。

对目标TCP来说，处理重复的数据段是个简单的过程。目的TCP期望收到连续的字节流。当

含有同样序号的分组作为另一个收到的数据段到达时，目的TCP只要丢弃这个数据段就可以

了。

 

4．失序的数据段

    TCP使用IP的服务，而IP是不可靠的网络层协议。TCP数据段封装在IP数据包中。每

个IP数据包是独立实体。 路由器可以通过找到合适的路径自由地转发每一个数据包。一个

数据包可以沿着时延较短的路径走，另一个数据包可能沿着一个时延较长的路径走。若数据

包不按序到达，则封装在这种数据包中的TCP数据段也就不按序到达。处理失序数据段的方

法很简单：对失序的数据段不确认，直到收到所有它以前的数据段为止。当然，若确认晚了，

源TCP的失序数据段的计时器会到期而会重新发送该数据段。目标TCP就会丢弃重复的数据

段。

 

5．丢失的确认

    确认是由目的站发出的。在TCP确认机制中，丢失的确认甚至不会被源TCP发现。TCP

使用累计确认 系统，每一个确认证实由确认号指明的字节之前的所有字节都已经收到了。例

如，目标站点发送了两个ACK数据段的确认号，分别是1601和1801，1801的确认号证实了

字节1801以前的字节都收到了。1601确认号表示1601之前的字节都收到了。如果1601这

个确认号丢失了，而1801的确认号收到了。则系统会明白1801之前的字节流都收到了，1601

的确认号已变得没有意义了。

13.2.6  TCP的计时器

    为了保证实现可靠的传输，合理处理超时未到或未确认的数据，TCP协议设计了4种计

时器：

 

◇重传计时器

 

◇坚持计时器

 

◇保活计时器

 

◇时间等待计时器

 

1．重传计时器

    为了控制丢失的或丢弃的数据段，TCP使用处理重传时间的重传计时器。当TCP发送数

据段时，它就创建该特定数据段的重传计时器。可能发生以下两种情况：

 

◇若在计时器截止时间之前收到了对此数据段的确认，则撤销此计时器。

 

◇若在收到对此特定数据段的确认之前计时器截止期到，则重传此数据段，并将计时器复

位。设一次数据传输的往返时间为RTT，则重传时间=2×RTT。

 

-------------------------------------------------------------------------------

提示：  数据传输的往返时间RTT是利用发送端发送数据时产生的时间戳和当前时间计算得来的。时间戳存放在TCP数据首部的可选项中。

-------------------------------------------------------------------------------

 

2．坚持计时器

    假定接收端的TCP宣布了窗口大小为零，发送端的TCP将停止传送数据段，直到接收端

的TCP发送确认并宣布一个非零的窗口大小为止。但应该注意的一点是：在TCP中对确认是

不需要确认的。若确认丢失，接收端的TCP就认为它完成任务了，并等待发送端的TCP发送

更多的数据段。发送端的TCP由于没有收到确认，就等待对方发送确认来通知窗口的大小。

双方进入了死锁等待的情况。

 

    为了解开这个死锁，TCP为每个连接使用一个坚持计时器。当发送端收到一个窗口大小

为零的确认时，就启动坚持计时器。当坚持计时器期限到时，发送端的TCP就发送一个特殊

的数据段，称为探测数据段，这个数据段只有一个字节的数据。它有一个序号，但它的序号

永远不需要确认，它只是提醒接收端的TCP：确认已丢失，必须重传。

 

    坚持计时器的时间值设置是重传时间的数值。但若没有收到接收端来的响应，就需要发

送另一个探测数据段，并将坚持计时器的值加倍和复位，直到这个值增大到极限值(通常是

60秒)为止。在此之后，如果还没有得到响应，发送端每隔60秒就发送一个探测数据段，

直到窗口重新打开。

 

3．保活计时器

    保活计时器用来防止在两个TCP之间的连接长时间空闲。假定客户打开了到服务器的连

接，传送了一些数据，然后就保持沉默了，也许这个客户出现了故障。在这种情况下，这个

连接将永远地处于打开状态，白白地浪费了服务器宝贵的资源。

 

    要解决这个问题，TCP协议使用了保活计时器。每当服务器收到客户的信息就将保活计

时器复位。超时通常设为2小时。若服务器过了2小时还没有收到客户的信息，它就发送探

测数据段。若发送10个探测数据段(每个相隔75秒)还没有响应，就假定客户出了故障，因

而就中止该连接。

 

4．时间等待计时器

    如图13.8所示，TCP协议在断开连接的时候，如果A发送完最后一个，ACK后就立即关 

闭连接，而此时，如果这个ACK数据段丢失了，B无法判断是FIN丢失还是ACK丢失，因此

B会重传FIN数据段，而此时A已经关闭了连接，B永远也无法收到A的ACK字段了。

 

    因此TCP协议设置了一个时间等待计时器，A在发送了最后一个ACK报文后，并不立即

关闭连接，而是经过一个时间等待计时器的时间再关闭。这个时间可以保证A能收到重复的

FIN数据段。

 

 

图13.8  时间等待计时器

 

-------------------------------------------------------------------------------

提示：由于此时数据连接已经完成了建立和断开的生存周期，所以数据段的寿命期已经知道。

时间等待计时器的值通常设置为一个数据段寿命期的两倍。

-------------------------------------------------------------------------------

 

13.2.7  TCP的应用

    TCP在网络中的应用范围很广，主要用在对于数据传输可靠性要求高的环境，比如远程

登录程序TELNET。这时，客户端发出的每个命令都要在远程主机上执行，那么就希望数据

的传输是可靠的。如果有不可靠的数据到达了，希望能让发送端再发送一次，从而提高可靠

性。还有大家熟悉的网页浏览，它使用的HTTP协议就是依赖TCP提供可靠性的。在使用TCP

协议时，通信方对数据的可靠性要求高，即使因此降低了一点数据传输率也是可以接受的。

 

    这样的例子很多。下面将列出一些常用的端口号及其功能。以便进一步对TCP进行检测

和管理。表13-1列出了常用的TCP端口及应用。

 

表13-1  TCP端口及应用

 

 

13.3  UDP协议

    TCP协议的数据传输比较可靠，但因此而付出的代价在某些时候显得不太合适。比如主机A想要给主机B发送一句话“你好”，这个数据传输仅仅为4个字节而已。但用TCP协议来封装、传输它，至少要加上一个20个字节的首部，还要为此建立一个3次握手的连接。并且在数据传输完毕后还要进行4次断开。这样看来似乎对于一些简短的数据传输可以设计一种简单的传输协议。忽略一些可靠性考虑，提高数据传输率。在这种背景下，传输层的另一个协议UDP产生了。

 

    UDP协议和TCP协议都是传输层的协议，UDP作为一个无连接的、不可靠的协议有什么

样的工作机制呢? 有何优缺点呢? 下面带着这些问题来分析UDP协议。

 

13.3.1  UDP的封装

    UDP是一个简单的面向数据包的传输层协议，进程的每个输出操作都恰好产生一个UDP

数据段，并组装成一份待发送的IP数据包。

 

    UDP不提供可靠性：它把应用程序传给IP层的数据发送出去，但是并不保证它们能到

达目的地。由于缺乏可靠性，似乎应该避免使用UDP而使用一种可靠的协议如TCP。可是在

小数据文件的传输中，UDP发挥了重要的作用。例如，当发送一个1O字节的短消息时；使

用TCP和UDP都可以。可是TCP会加上至少20字节的头部数据，而且还要使用确认，这样

数据的传输效率就较低。如果使用UDP则要加上的首部就缩减到8字节，并且没有确认。这

就使得数据传输率大幅度提高。当然，这样提高效率付出的代价是数据传输的可靠性得不到

保障。可见使用何种传输协议还要具体问题具体分析。

 

    UDP首部的各字段如图13.9所示。

图13.9  UDP首部的数据帧格式

 

    图13.9中第一行0～15位是源端口号，用来标识数据发送端的进程，这和TCP协议的

源端口号类似。16～31位是目标端口号，用来标识数据接收端的进程，这里的作用也可参

照TCP协议中的讲解。

 

    图13.9中第二行0～15位是16位的UDP长度，它来指出UDP数据段中所包含数据的大

小，通过这个值可以准确地计算出数据的结束位置。16～31位是16位UDP校验和，用来完

成对UDP数据的差错检验，这是UDP协议提供的唯一的可靠机制，它通过计算校验和来简单

判断一下到达数据的正确性，这一点保证使得UDP的实用性大为增加。UDP的校验和是可选

的。图13.9中第三行是数据，它来自应用程序，它的大小可由16位的UDP长度减去UDP

首部长度后得到。

 

13.3.2  UDP的应用

UDP协议由于其自身的特殊性——能高速地传输数据，因而在实际工作中应用范围也很广，而且在某些方面有着TCP协议不可比拟的优势。同时由于UDP协议的特点，也使传输层在处理数据传输的时候有更多的选择。可以根据数据传输过程中的要求和数据本身的特点选择，对于可靠性要求高的数据传输选择TCP方式；对于传输率高要求的数据传输使用UDP方式。二者相辅相成使得传输层的功能更完善。在互联网逐步进入到千家万户的今天，大家可能对QQ这个聊天工具不陌生。很多人接触网络就是从上网聊天开始的。QQ这个应用软件在处理发送短消息时就是使用了UDP的方式。大家不难想象，发送十几个字或几十个字的短消息使用TCP协议进行一系列的验证将导致传输率的大大下降。有谁愿意用一个“反应迟钝”的软件进行网络聊天呢?实际上大家在使用QQ的时候也不会感到数据传输的不可靠。在网络飞速发展的今天，网络技术日新月异，对于常用的简单数据传输来说，UDP不失为一个很好的选择。在网络服务中也有用到UDP协议的，比如DNS服务。

 

表12.2  列出了UDP使用的一些常见端口

 

DNS服务器支持TCP和UDP两种协议的查询方式，而且端口都是53。大多数的查询都是UDP查询的，一般需要TCP查询的有两种情况。

 

◇当查询数据较大以至于产生了数据分段，这时，需要利用TCP的分片能力来进行数据传输。

 

◇当主(master)服务器和辅(slave)服务器之间进行数据同步通信的时候。

 

UDP作为一个很小的不可靠的传输层协议，它没有流控机制，当来到的报文太多时，接收端可能会溢出。

 

除校验和外，UDP也没有差错控制机制，这就表示发送端并不知道数据是丢失了还是重复交付了。当接收端使用校验和检测出差错时，就会悄悄地将此用户数据丢掉。

 

缺少流控制和差错控制就表示使用UDP的进程必须要提供这些机制。例如TFTP协议提供分块传输、分块确认的机制，保证数据传输的可靠性。关于TFTP协议，将在后面介绍详细讨论。

 

13.4  使用Sniffer（或Ethereal）抓包实例

 sniffer是一个常用的网络协议分析工具，可以捕获网络流量进行分析，使用专家分析器诊断网络故障，以及实时监测网络活动等。

 

在如图13．10所示的网络环境中，在主机192.168.2.86通过IE浏览器访问Internet，其中192.168.1.3是代理服务器，在主机192.168.2.86访问网络的同时，使用Sniffer进行抓包。

 

抓包结束后，在Sniffer中查看分析TCP首部，查看TCP建立连接和断开连接的过程。

图13.10抓包实验拓扑

 

1．Sniffer协议分析软件的使用

如果主机连接在一个广播网段上，那么Sniffer抓到的包会含大量的与主机操作无关的数据包，这使得期望看到的数据包会淹没在大量的无关数据中，这对协议分析造成一定的困难，因此，首先要在Sniffer上设置过滤，如图13.11所示。

图13.11  Sniffer的菜单

 

单击“Define Filter”命令，进入过滤设置菜单，如图13.12所示:

图13.12  配置Sniffer的过滤

 

配置将要观察的两台PC的ip add，这样Sniffer就只获取192.168.2.86和192.168.1.3这两台主机之间发送的数据。在“Advanced”选项卡中，可以对协议进行选择。

 

单击“Profiles”，可设置过滤名，如图13.13所示。

图13.13  配置Sniffer的过滤名

 

新建一个过滤名或覆盖原来的，Default是系统默认的。然后单击“Done”按钮。

 

2．捕获数据

单击图13.14所示界面中左上角 
 图标开始捕获数据。

 

然后，在192.168.2.86这台机器上使用浏览器连接Internet，192.168.1.3是登录Internet的代理服务器。

 

查看某网页后，关闭浏览器。

图13.14-1  开始捕获

 

图13.14-2  PC发起访问www.baidu.com

 

单击左上角的 
 图标或在菜单中单击“Capture”→“Stop and Display”命令结束捕获，如图13.15所示。

 

图13.15  停止捕获

 

3．查看TCP的连接建立过程

在Sniffer中单击下面的“DECODE”标签，会出现捕获到的数据列表和每个数据包的包头信息，如图13.16所示。可以看到图13.16中第11个被捕获的数据段是192.168.2.86向192.168.1.3发起TCP连接建立的请求。其中，序列号为3042697805，SYN标志位为1。

13.16 查看TCP的连接建立过程(1)

 

图13.17所示的阴影部分为192.168.1.3应答192.168.2.86的数据段，其中，序列号为1093837408，确认序号为3042697806，是192.168.2.86发起连接时使用序列号的值加1。标志位ACK和SYN置1。

13.17  查看TCP的连接建立过程(2)

 

    图13.18所示的阴影部分为192.168.2.86应答192.168.1.3的确认数据段，序列号为

3042697806，与对方上一次发来的确认序号相同，确认号为1093837409，为对方上一次发来的序列号加1，窗口大小为17520。此时，3次握手的过程结束，双方建立了TCP连接。

 

13.18  查看TCP的连接建立过程(3)

 

4．查看TCP断开连接的过程

图13.19所示阴影部分为192.168.2.86[司192.168.1.3发出的断开连接请求，在这个数据段中包含两个内容，一是确认上一个数据段，二是请求断开连接。因此ACK与FIN置1。

 

 

 

图13.19  查看TCP的连接断开过程(1)

图13.20阴影部分为192.168.1.3应答192.168.2.86断开连接请求的数据段，ACK置1。

 

 

 

图13.20  查看TCP的连接断开过程(2)

 

图13.21所示阴影部分为192.168.1.3主动向。192.168.2.86发出的断开连接请求的数据段，同时确认上面的数据段，因此FIN与ACK置1。

图13.21  查看TCP的连接断开过程(3)

 

    图13.22所示阴影部分为192.168.2.86给192.168.1.3的断连请求发出的确认。此时，

双方已经断开连接。

 

 

 

图13.22  查看TCP的连接断开过程(4)