网络传输可靠性技术
一、传输层功能
在IP分组网络中，主机在传输数据前无须与目的主机预先建立特定的“通路”，这属于一种“不可靠的”数据报传输机制，它不能保证数据报准确到达，并可能造成数据报的损坏、乱序和丢失。为了保证数据报传输的可靠性，将在网际层的上一层传输层引入传输控制协议（TCP，Transmission Control Protocol）和用户数据报协议（UDP，User Datagram Protocol）。
在TCP/IP模型中，传输层位于网际层与应用层之间。数据通信应由应用层中的用户进程发起，并通过网际层设备，如路由器和交换机等，将数据报从发送端主机传输到接收端主机。传输层协议工作在主机上，负责主机与用户进程间的数据传输。
如图3-31所示，网际层实现主机到主机之间的通信，传输层则进一步实现进程与进程之间的通信。
图3-31网际层和传输层的工作范围
传输层的功能：
在传输层向应用层提供服务时，屏蔽了网际层及以下层的细节内容，用户进程只需与传输层进行交互，而不必关心数据报所经网络的拓扑结构和采用的路由拓扑协议等。应用层中进程的QoS完全取决于传输层所使用的协议。例如，在采用TCP协议时，尽管网际层提供的服务是不可靠的，但传输层仍能向应用层提供可靠的数据传输服务；在采用UDP协议时，传输层只能向应用层提供不可靠的数据传输服务。
传输层还提供了复用和分用功能。
复用功能指传输层可以同时传输多个进程发送的数据，分用功能指传输层能对接收到的数据进行分类，并将数据准确交付给所属进程。一台主机上可以存在多个用户进程，每个进程都可能会产生通信需求。网际层仅负责通过IP地址将数据报从源主机传输到目标主机，不提供数据报的区分功能。传输层协议中引入了协议端口号的概念，用于标记属于不同用户进程的数据，简称为端口号。
网络中数据传输的复用功能可通过端口号和IP地址的组合来实现，TCP和UDP协议均在数据报的首部附加了两个端口字段：源端口和目的端口。源端口用于表示数据报发送端的用户进程，目的端口则用于表示接收端的用户进程。端口字段的长度为16位，可用的端口号范围为0~65535。如表3-9所示，端口号可分为3类。
表3-9 端口的划分
| 端口类别 | 端口号范围 | 应用 |
|---|---|---|
| 熟知 | 0 ~ 1023 | 由IANA分配给因特网上常用的应用层协议，例如HTTP、DNS和SMTP |
| 注册 | 1024 ~ 49151 | 由IANA分配给专有应用程序，例如Microsoft SQL Server和Oracle |
| 随机 | 49152 ~ 65535 | 由操作系统动态分配给用户进程 |
用户进程在进行通信时，应事先确定其所采用的端口号。源端口号一般均属于随机端口，而目的端口通常是熟知或注册端口。表3-10给出了常用的应用层协议所使用的端口号。
表3-10 常用协议的端口号
| 传输层协议 | 应用层协议 | 端口号 |
|---|---|---|
| TCP | HTTP | 80 |
| FTP | 21 | |
| POP3 | 110 | |
| SMTP | 25 | |
| SSH | 22 | |
| telnet | 23 | |
| UDP | DNS | 53 |
| SNMP | 161 | |
| TFTP | 69 |
如图3-32所示，在网络上有一台WWW服务器和两台主机。Web服务器的IP地址为192.168.1.2，主机PC1的IP地址为192.168.1.3，主机PC2的IP地址为192.168.1.4。假设PC1中有三个用户进程通过HTTP协议与Web服务器进行通信，PC2中有两个用户进程通过HTTP协议与Web服务器进行通信。根据传输层端口分配原则可知，在用户进程发送的数据报中，源端口号均在0~65535的范围中随机分配，且同一主机上不同进程所分配的源端口号不同。已知数据通信中使用的应用层协议只有HTTP协议，则由表3-10可知，所有数据报的目的端口号均为80。
在如图3-33所示的实例中，主机PC-A中有两个用户进程与服务器PC-B进行复用通信，服务器PC-B根据源端口号区分这两个进程。若主机PC-A在向服务器PC-B发送的数据报中，源端口号为50001，且目的端口号为23，则表明这个数据报用于远程登录，由telnet用户进程产生。若数据报的源端口号为50003，且目的端口号为80，则表明这个数据报属于HTTP应用，由浏览器进程产生。PC-B在包含远程登录应答信息的数据报中，将源端口号设为23，目的端口号设为50001；在回应HTTP请求的数据报中，将源端口号设为80，目的端口号设为50003。
图3-32浏览器访问实例
图3-33 传输层复用通信实例
二、UDP数据报服务
UDP是一种无连接的数据报协议，它提供“尽最大努力交付”的数据报传输服务。
当客户寄送邮件时，邮政系统并不能保证邮件顺利到达，若丢失，则发信方也不会从收信方得到任何反馈信息，也不会得到任何赔偿。UDP协议同样不关注数据报在传输过程中能否到达接收端，若上层的应用程序采用UDP协议，但又需要其可靠传输，则应用程序本身应该设置相应的机制来保证数据传输的可靠性。在应用对可靠性要求较低，实时性却要求较高时，适合采用UDP协议，如视频和音频传输等。
UDP协议是一种面向报文的协议。
UDP用户数据报可分为两部分：首部和数据部分。
UDP用户数据报首部可分为以下4个字段：
如图3-34所示，对应用层向下移交的数据，UDP协议不进行合并或拆分操作，仅在添加UDP首部后交给网际层进行处理。在IP数据报首部中，当协议字段为17时，代表数据部分为UDP用户数据报。
如图3-34所示，首部长度为8个字节，数据部分的长度则由应用层根据需要确定。
1.源端口字段，记录分配给数据报发送端用户程序的端口号，用于接收端返回应答信息。
2.目的端口字段，记录数据报的目的端口号，运行在接收端主机上的UDP协议根据这一端口号将数据报交付给用户进程。
3.长度字段，记录UDP用户数据报的长度，单位为字节，最小值为8。此时，数据报的数据部分为空。
4.校验和字段，用于检测UDP用户数据报在传输过程中是否发生差错。
图3-34 UDP数据报
三、TCP可靠传输服务
传输控制协议TCP是一种面向连接的，具有流量控制和可靠传输等功能的传输层协议。TCP协议规定，用户进程在数据开始传输前，必须通过“三次握手”建立TCP连接，并在数据传输结束后释放TCP连接。TCP通过使用自动重传请求的滑动窗口机制，提供流量控制和可靠传输功能。
TCP协议也是一种面向字节流的传输层协议，它不同于UDP协议，TCP对应用层向下移交的数据进行合并或拆分，以适应网络的传输要求。通过TCP协议传输的数据，在字节流层面保持不变，但数据分组可能会发生变化。合并或拆分后的数据在被添加到TCP首部后，交付给网际层进行处理。
TCP报文：
如图3-35所示，TCP首部包含20个字节的固定参数和长度不定的可选参数，可选参数部分的长度总是4个字节的整数倍。固定首部可分为以下字段：
1.源端口字段，记录分配给数据报发送端用户程序的端口号，用于接收端返回应答信息。
2.目的端口字段，记录数据报的目的端口号，运行在接收端主机上的TCP协议根据这一端口号将数据报交付给用户进程。
3.序号字段，记录数据部分在用户进程提交的字符流中的起始位置。
4.确认号字段，用于接收端给出期望接收的下一个分组的序号。
5.数据偏移字段，用于给出分组中TCP首部的长度。
6.保留字段，尚未定义功能。
7.URG-FIN字段，用于传输控制。
8.窗口字段，用于表示接收端接收窗口的大小。
9.校验和字段，用于检测UDP用户数据报在传输过程中是否发生了差错。
10.紧急指针字段，用于指出数据部分中紧急数据所占的字节数。
图3-35TCP报文
1．TCP三次握手
如图3-36所示，为了保证会话的可靠性，两台主机在进行TCP数据传输前，必须通过三次握手建立TCP连接。
图3-36TCP建立连接过程
1）主机PC1将一个SYN数据报发送到主机PC2，希望建立一个TCP连接。
2）主机PC2发送ACK数据报，确认收到了PC1的SYN数据报，并发送SYN数据报，等待PC1确认。
3）主机PC1发送ACK数据报，确认接收到了PC2发送的SYN+ACK数据报，表示TCP连接已成功建立。
2．滑动窗口
1）自动重传请求（ARQ，Automatic Repeat reQuest）
图3-37自动重传请求ARQ机制
在自动重传请求机制下，发送端在发送完分组后，保留的副本并停止数据发送，直到接收端确认已接收到了，发送端才清除的副本，并开始发送下一个报文段。若超过一定时间后，发送端仍没有接收到接收端对的确认，则发送端再利用的副本对进行重传。
如图3-37所示，发送端在发送完第一个分组后暂停，接收端顺利接收到并返回对的确认。发送端接收到确认后，开始发送第二个分组，在传输过程中出现了差错，接收端检测到这一差错，将丢弃。一定时间后，发送端因为等待超时，利用的副本对进行重传，接收端顺利接收到，并返回对的确认，传输继续进行。
上述ARQ机制中，由于每个分组在发送时都要求对上一分组进行确认，数据传输效率较低，连续ARQ机制可以解决该问题。连续ARQ中，引入了发送窗口的概念。如图3-38（a）和3-38（b）所示，深灰色部分为当前的发送窗口，发送窗口中的分组可连续发送，而不必等待接收端一一确认。在图3-42（a）中，发送窗口的左端位于1号分组，右端位于5号分组，发送端连续发送编号为1~5的分组后，停止数据传输并等待接收端的确认。接收端只对按序到达的分组中的最后一个进行确认，例如，接收端接收到的分组编号为1、2、3和5，则只对3号分组进行确认。如图3-42（b）所示，发送端接收到确认后，将发送窗口的左端移动到4号分组，右端移动到8号分组，并开始下一轮的数据传输。
图3-38连续ARQ机制
2）滑动窗口
在滑动窗口机制中，发送端发送窗口的大小不能超过接收端的接收窗口。因此，接收端可以通过接收窗口限制发送端的发送速率，进行流量控制。在图3-39（a）中，发送端的发送窗口包含编号为4~7的分组，接收端在接收到这些分组后，向发送端返回7号分组的确认信息，然后将接收窗口大小重新设置为2个分组并通知发送端，发送端在开始下一轮发送时，根据接收窗口的大小将发送窗口左端移动到8号分组，右端移动到9号分组，如图3-39（b）所示。
| （a） | （b） |
| （a） | （b） |
图3-39滑动窗口机制
通过滑动窗口机制可以动态地调整数据报的发送和接收数量，当接收端数据处理能力达到饱和时，可采用较小的窗口来降低发送端发送数据报的速度。此外，当网络拥塞时，也可以通过滑动窗口机制来避免数据报丢失。在网络拥塞解除后，可扩大窗口来提高链路的利用率。
