一、协议概述

1、进程之间通信

从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。当网络边缘部分的两台主机使用网络核心部分的功能进行端到端的通信时，都要使用协议栈中的运输层，而网络核心部分中的路由器在转发分组时只用到下三层的功能。

下面通过下图的示意图来说明运输层的作用。设局域网LAN1上的主机 A 和局域网LAN2上的主机 B通过互连的广域网 WAN 进行通信。我们知道，IP 协议能够把源主机 A发送出的分组，按照首部中的目的地址，送交到目的主机B，那么，为什么还需要运输层呢?

从 IP层来说，通信的两端是两台主机。IP数据报的首部明确地标志了这两台主机的IP地址。但“两台主机之间的通信”这种说法还不够明确。真正进行通信的实体是在主机中的哪个构件呢?是主机中的应用进程，是一台主机中的应用进程和另一台主机中的应用进程在交换数据(即通信)。因此严格地讲，两台主机进行通信就是两台主机中的应用进程互相通信。IP协议虽然能把分组送到目的主机，但是这个分组还停留在主机的网络层而没有交付主机中的应用进程。通信的两端应当是两个主机中的应用进程。也就是说，端到端的通信是应用进程之间的通信。在一台主机中经常有多个应用进程同时分别和另一台主机中的多个应用进程通信。例如，某用户在使用浏览器查找某网站的信息时，其主机的应用层运行浏览器客户进程。如果在浏览网页的同时，还要用电子邮件给网站发送反馈意见，那么主机的应用层就还要运行电子邮件的客户进程。

在上图中，主机A的应用进程AP1和主机B的应用进程 AP3通信，而与此同时，应用进程AP2也和对方的应用进程AP4通信。这表明运输层有一个很重要的功能——复用(multiplexing)和分用(demultiplexing)。这里的“复用”是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据(当然需要加上适当的首部)，而“分用”是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。

上图中两个运输层之间有一个深色双向粗箭头，写明“运输层提供应用进程间的逻辑通信”。“逻辑通信”的意思是:从应用层来看，只要把应用层报文交给下面的运输层，运输层就可以把这报文传送到对方的运输层(哪怕双方相距很远，例如几千公里)，好像这种通信就是沿水平方向直接传送数据。但事实上这两个运输层之间并没有一条水平方向的物理连接数据的传送是沿着图中的虚线方向(经过多个层次)传送的。“逻辑通信”的意思是“好像是这样通信，但事实上并非真的这样通信”。

从这里可以看出网络层和运输层有明显的区别。网络层为主机之间的通信提供服务，而运输层则在网络层的基础上，为应用进程之间的通信提供服务。然而正如后面还要讨论的运输层还具有网络层无法代替的许多其他重要功能。

运输层还要对收到的报文进行差错检测。大家应当还记得，在网络层，IP数据报首部中的检验和字段，只检验首部是否出现差错而不检查数据部分。

根据应用程序的不同需求，运输层需要有两种不同的运输协议，即面向连接的TCP和无连接的 UDP，这两种协议就是本章要讨论的主要内容。

我们还应指出，运输层向高层用户屏蔽了下面网络核心的细节(如网络拓扑、所采用的路由选择协议等)，它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道，但这条逻辑通信信道对上层的表现却因运输层使用的不同协议而有很大的差别。当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的(只提供尽最大努力服务)，但这种逻辑通信信道就相当于一条全双工的可靠信道。但当运输层采用无连接的UDP协议时，这种逻辑通信信道仍然是一条不可靠信道。

2、运输层的两个主要协议

TCP/IP 运输层的两个主要协议都是互联网的正式标准，即:

• 用户数据报协议 UDP(User Datagram Protocol)[RFC 768,STD6]
• 传输控制协议 TCP(Transmission Control Protocol)[RFC 793,STD7]

按照OSI的术语，两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元TPDU (Transport Protocol Data Unit)。但在 TCP/P 体系中，则根据所使用的协议是 TCP 或UDP，分别称之为TCP报文段(segment)或UDP用户数据报。

UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到 UDP报文后，不需要给出任何确认。虽然 UDP不提供可靠交付，但由于UDP非常简单，在某些情况下UDP是一种最有效的工作方式。

TCP则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或多播服务。由于TCP要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，如确认、流量控制、计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多的处理机资源。

下图给出了一些应用和应用层协议主要使用的运输层协议(UDP或TCP)。

3、运输层的端口

应用层所有的应用进程都可以通过运输层再传送到IP层(网络层)，这就是复用。运输层从P层收到发送给各应用进程的数据后，必须分别交付指明的各应用进程，这就是分用。显然，给应用层的每个应用进程赋予一个非常明确的标志是至关重要的。

我们知道，在单个计算机中的进程是用进程标识符(一个不大的整数)来标志的。但是在互联网环境下，用计算机操作系统所指派的这种进程标识符来标志运行在应用层的各种应用进程则是不行的。这是因为在互联网上使用的计算机的操作系统种类很多，而不同的操作系统又使用不同格式的进程标识符。为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法(而这种方法必须与特定操作系统无关)对TCPIP体系的应用进程进行标志。

但是，把一个特定机器上运行的特定进程，指明为互联网上通信的最后终点是不可行的。这是因为进程的创建和撤销都是动态的，通信的一方几乎无法知道和识别对方机器上的进程。另外，我们往往需要利用目的主机提供的功能来识别终点，而不需要知道具体实现这个功能的进程是哪一个(例如，要和互联网上的某个邮件服务器联系，但并不一定要知道这个服务器功能是由目的主机上的哪个进程实现的)。

解决这个问题的方法很巧妙，就是在应用层和运输层之间的界面上，设置一个特殊的抽象的“门”。应用层中的应用进程要通过运输层发送到互联网，必须要通过这个门。而别的主机上的应用进程要寻找本主机中的某个应用进程，也必须通过这个门。这样，我们就可以把应用层和运输层的界面上这些“门”，设为通信的抽象终点。这些抽象终点的正式名称就是协议端口(protocol port)，一般就简称为端口(pot)。每一个端口用一个称为**端口号(pornumber)**的正整数来标志。主机的操作系统提供了接口机制，使得进程能够通过这种机制找到所要找的端口。

请注意，这种在协议栈层间的抽象的协议端口是软件端口，和路由器或交换机上的硬件端口是完全不同的概念。硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的地点。不同的系统具体实现端口的方法可以是不同的(取决于系统使用的操作系统)。

当应用层要发送数据时，应用进程就把数据发送到适当的端口，然后运输层从该端口读取数据，进行后续的处理(把数据发送到目的主机)。当运输层收到对方主机发来的数据时，就把数据发送到适当的端口，然后应用进程就从该端口读取这些数据。显然，端口必须有一定容量的缓存来暂时存放数据。

在后面将讲到的 UDP和TCP的首部格式中，都有源端口和目的端口这两个重要字段。这两个端口就是运输层和应用层进行交互的地点。

TCP/IP 的运输层用一个 16 位端口号来标志一个端口。但请注意，端口号只具有本地意义，它只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网不同计算机中，相同的端口号是没有关联的。16位的端口号可允许有65535个不同的端口号，这个数目对一个计算机来说是足够用的。

由此可见，两个计算机中的进程要互相通信，不仅必须知道对方的IP地址(为了找到对方的计算机)，而且要知道对方的端口号(为了找到对方计算机中的应用进程)。这和我们寄信的过程类似。当我们要给某人写信时，就必须在信封上写明他的通信地址(这是为了找到他的住所，相当于卫地址)，并且还要写上收件人的姓名(这是因为在同一住所中可能有好几个人，这相当于端口号)。在信封上还应写明自己的地址和姓名。当收信人回信时很容易在信封上找到发信人的地址和姓名。互联网上的计算机通信是采用客户-服务器方式客户在发起通信请求时，必须先知道对方服务器的IP地址(用来找到目的主机)和端口号(用来找到目的进程)。因此运输层的端口号分为下面的两大类。

1）服务器端使用的端口号

这里又分为两类，最重要的一类叫作熟知端口号(well-known port number)或全球通用端口号，数值为 0~1023。这些熟知端口号最初公布在文档中[RFC 1700.STD2]，但后来因为互联网发展太快，这种标准文档无法随时更新，因此在 RFC3232 中就把 RFC 1700列为陈旧的，而当前最新的熟知端口号可在网址 www.iana.org 上查到IANA 把这些熟知端口号指派给了 TCPIP最重要的一些应用程序，让所有的用户都知道。当一种新的应用程序出现后，IANA 必须为它指派一个熟知端口，否则互联网上的其他应用进程就无法和它进行通信。和电话通信对比，熟知端口号相当于所有人都应知晓的重要电话号码，如报警电话110，急救电话120等。下图出了一些常用的熟知端口号。

另一类叫作登记端口号，数值为1024~49151。这类端口号是为没有熟知端口号的应用程序使用的。要使用这类端口号必须在IANA按照规定的手续登记，以防止重复。

2）客户端使用的端口号

数值为49152~65535。由于这类端口号仅在客户进程运行时才动态选择，因此又叫作短暂端口号。这类端口号就是临时端口号，留给客户进程选择临时使用。当服务器进程收到客户进程的报文时，就知道了客户进程所使用的端口号，因而可以把数据发送给客户进程。通信结束后，刚才已使用过的客户端口号就被系统收回，以便给其他客户进程使用。

下面将分别讨论 UDP和TCP。UDP比较简单，本章主要讨论TCP。

二、用户数据报协议 UDP

1、UDP 概述

用户数据报协议 UDP只在IP的数据报服务之上增加了很少一点的功能这就是复用和分用的功能以及差错检测的功能。UDP的主要特点是:

• UDP是无连接的，即发送数据之前不需要建立连接(当然，发送数据结束时也没有连接可释放)，因此减少了开销和发送数据之前的时延。
• UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表(这里面有许多参数)。
• UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这就是说，应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文，如下图所示。在接收方的UDP，对IP层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层的应用进程。也就是说，UDP一次交付一个完整的报文。因此，应用程序必须选择合适大小的报文。若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分片，这会降低 IP 层的效率。反之，若报文太短，UDP 把它交给 IP 层后，会使 IP 数据报的首部的相对长度太大，这也降低了IP层的效率。
  
• UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很多的实时应用(如IP电话、实时视频会议等)要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太大的时延UDP正好适合这种要求。
• UDP 支持一对一、一对多、多对一和多对多的交互通信。
• UDP的首部开销小，只有8个字节，比 TCP 的 20 个字节的首部要短。

2、案例分析

下面举例说明 UDP的通信和端口号的关系。

主机H1中有三个应用进程分别要和主机H2中的两个应用进程进行通信。通信双方的关系是:P1→P4,P2→P4,P3→P5。

主机 H1的操作系统为这三个进程分别指派了端口，其端口号分别为a.b和c。图中位于应用层和运输层之间的小方框代表端口。在端口小方框中间还画有队列，表示端口具有缓存的功能，可以把收到的数据暂时存储一下。

有时也可以把队列画成双向的，即分别表示存放来自应用层或运输层的数据。现在假定主机H,中的进程已经知道了对方进程P4和P5的端口号分别为x和y，于是在主机 H1的运输层就可以组装成需要发送的 UDP用户数据报，其中最重要的地址信息(源端口，目的端口)分别是(a,x)，(b,x)和(c,y)。

在下图中把运输层以下的都省略了。因此，进程之间的通信现在可以看成是两个端口之间的通信。

图中在两个运输层之间有一条虚线，表示在两个运输层之间可以进行通信，而不是一条连接。但这种通信是不可靠的通信，即所发送的报文在传输过程中有可能丢失，同时也不保证报文都能按照发送的先后顺序到达终点。这正是UDP通信的特点:简单方便，但不可靠。如果想要得到可靠的运输层通信，那就要使用后面要介绍的TCP进行通信。请注意，在两个运输层的 UDP 之间并没有建立连接。

上图的例子画出了多对一的通信(a→x,b→x)。如果改成 a→x,a→y，则是一对多的情况了。

主机H1中的3个应用进程，把用户数据通过各自的端口传送到了运输层后，就共用一个网络层协议，把收到的 UDP用户数据报组装成不同的IP数据报，发送到互联网。这就是UDP的复用功能。主机H2的网络层收到3个IP数据报后，提取出数据部分(即 UDP用户数据报)，然后根据其首部中的目的端口号，分别传送到相应的端口，以便上层的应用进程到端口读取数据。这就是 UDP的分用功能。

虽然某些实时应用需要使用没有拥塞控制的UDP，但当很多的源主机同时都向网络发送高速率的实时视频流时，网络就有可能发生拥塞，结果大家都无法正常接收。因此，不使用拥塞控制功能的 UDP有可能会引起网络产生严重的拥塞问题。

还有一些使用UDP的实时应用，需要对UDP的不可靠的传输进行适当的改进，以减少数据的丢失。在这种情况下，应用进程本身可以在不影响应用的实时性的前提下，增加一些提高可靠性的措施，如采用前向纠错或重传已丢失的报文。

3、UDP的首部格式

用户数据报 UDP有两个字段：数据字段和首部字段。首部字段很简单，只有8个字节(如下图所示)，由4个字段组成，每个字段的长度都是2字节。各字段意义如下:

• 源端口：源端口号。在需要对方回信时选用。不需要时可用全0。
• 目的端口：目的端口号。这在终点交付报文时必须使用。
• 长度：UDP用户数据报的长度，其最小值是8(仅有首部)。
• 检验和：检测UDP用户数据报在传输中是否有错。有错就丢弃。
  
  如果接收方UDP发现收到的报文中的目的端口号不正确(即不存在对应于该端口号的应用进程)，就丢弃该报文，并由网际控制报文协议ICMP发送“端口不可达”差错报文给发送方。我们在之前“ICMP的应用举例”讨论 traceroute 时，就是让发送的 UDP用户数据报故意使用一个非法的 UDP 端口，结果ICMP 就返回“端口不可达”差错报文，因而达到了测试的目的。

UDP用户数据报首部中检验和的计算方法有些特殊。在计算检验和时，要在UDP用户数据报之前增加12个字节的伪首部。所谓“伪首部”是因为这种伪首部并不是UDP用户数据报真正的首部。只是在计算检验和时，临时添加在UDP用户数据报前面，得到一个临时的UDP用户数据报。检验和就是按照这个临时的UDP用户数据报来计算的。伪首部既不向下传送也不向上递交，而仅仅是为了计算检验和。上图的最上面给出了伪首部各字段的内容。

UDP计算检验和的方法和计算IP数据报首部检验和的方法相似。但不同的是:IP 数据报的检验和只检验IP数据报的首部，但 UDP的检验和是把首部和数据部分一起都检验。

在发送方，首先是先把全零放入检验和字段。再把伪首部以及UDP用户数据报看成是由许多16位的字串接起来的。若UDP用户数据报的数据部分不是偶数个字节，则要填入一个全零字节(但此字节不发送)。然后按二进制反码计算出这些16位字的和。将此和的二进制反码写入检验和字段后，就发送这样的UDP用户数据报。

在接收方，把收到的UDP用户数据报连同伪首部(以及可能的填充全零字节)一起，按二进制反码求这些16位字的和。

当无差错时其结果应为全1。否则就表明有差错出现，接收方就应丢弃这个UDP用户数据报(也可以上交给应用层，但附上出现了差错的警告)。

下图给出了一个计算UDP检验和的例子这里假定用户数据报的长度是15字节，因此要添加一个全0的字节。读者可以自己检验一下在接收端是怎样对检验和进行检验的。不难看出，这种简单的差错检验方法的检错能力并不强，但它的好处是简单，处理起来较快。

如上图所示，伪首部的第3字段是全零:第4字段是首部中的协议字段的值。以前曾讲过，对于UDP，此协议字段值为17:第5字段是UDP用户数据报的长度。因此，这样的检验和，既检查了UDP用户数据报的源端口号和目的端口号以及UDP用户数据报的数据部分，又检查了IP数据报的源IP地址和目的地址。