ITN网络课程笔记（十四）

最新推荐文章于 2024-06-13 00:33:14 发布

qq_51996925

最新推荐文章于 2024-06-13 00:33:14 发布

阅读量2.4k

点赞数

分类专栏：网络文章标签： tcp/ip udp 思科网络协议

本文链接：https://blog.csdn.net/qq_51996925/article/details/121700505

版权

网络专栏收录该内容

17 篇文章 3 订阅

订阅专栏

十四、传输层

十四、传输层
1、数据传输
2、TCP概述
3、UDP概述
4、端口号
5、TCP通信过程
6、可靠性和流控制
7、UDP通信
8、单元检测

十四、传输层

欢迎来学习传输层！

顾名思义,传输层是将数据从一个主机传输到另一个主机的地方。这是您的网络真正开始动起来的地方! 传输层使用两个协议: TCP和UDP。可以把TCP看作是在邮件中收到一封挂号信。您必须先签收,然后邮递员才会给您。这会稍微减慢这个过程,但是发送者可以确定地知道您收到了这封信,以及您收到这封信的时间。UDP更像是一个普通的,盖了邮戳的信。它到达了您的邮箱（如果它到了的话）,它可能是给您的,但它实际上也可能是给其他不住在那里的人的。而且,它还可能根本就没有到达您的邮箱。发件人无法确定您已收到了信。尽管如此,有时还是需要像盖了邮戳的信件一样的UDP协议。本主题深入探讨 TCP和 UDP 在传输层中的工作方式。

模块目标: 比较各种传输层协议支持端到端通信的方式。

主题标题	主题目标
数据传输	说明传输层在端对端通信中管理数据传输的目的。
TCP 概述	说明 TCP 的特征
UDP 概述	说明UDP 的特征。
端口号	说明 TCP 和 UDP 如何使用端口号。
TCP 通信过程	说明 TCP 会话的建立和终止过程如何有助于实现可靠通信。
可靠性和流控制	说明如何通过发送和确认 TCP 协议数据单元来保证数据传输。
UDP 通信	比较各种传输层协议支持端到端通信的方式。

1、数据传输

1.1、传输层的应用

应用层程序生成必须在源主机和目的主机之间交换的数据。传输层负责在不同主机上运行的应用程序之间进行的逻辑通信。这可能包括在两个主机之间建立临时会话以及应用程序信息的可靠传输等服务。

如图所示，传输层将应用层与负责网络传输的下层连接起来。

传输层并不了解目标主机类型、数据必须经过的介质类型、数据使用的路径，链路拥塞情况或网络大小。

传输层包括两个协议：

传输控制协议 (TCP)
用户数据报协议 (UDP)

1.2、传输层的职责

跟踪各个会话

在传输层中，源应用和目的应用之间传输的每个数据集称为会话并分别进行跟踪。传输层负责维护并跟踪这些会话。

如图所示，每台主机上都可以有多个应用同时在网络上通信。

大多数网络对单个数据包能承载的数据量都有限制。因此，必须将数据分成可管理的部分。

数据分段和数据段重组

传输层负责将应用程序数据划分为适当大小的块。根据所使用的传输层协议，传输层块称为数据段或数据报。该图说明了使用不同块进行每个会话的传输层。

传输层将数据划分为更易于管理和传输的更小的块（即，数据段或数据报）。

添加报头信息

传输层协议还将包含二进制数据的报头信息添加到每个数据块中，这些数据被组织成几个字段。不同的传输层协议通过这些字段值在管理数据通信过程中执行各自的功能。

例如，接收主机使用报头信息将数据块重新组装为接收应用程序层程序的完整数据流。

传输层可以确保在设备上运行多个应用时，所有应用都能接收正确的数据。

标识应用

传输层必须能够划分和管理具有不同传输要求的多个通信。为了将数据流传递到适当的应用程序，传输层使用称为端口号的标识符来标识目标应用。如图所示，在每台主机中，每个需要访问网络的软件进程都将被分配一个唯一的端口号。

会话多路复用

将某些类型的数据（即视频流）作为完整的通信流在网络中发送，会使用所有可用带宽。这将阻止其他通信会话同时发生。而且也难以对损坏的数据开展错误恢复和重新传输的工作。

如图所示，传输层使用数据段和多路复用，使不同的通信会话在同一网络上交错。

可对数据段中的数据执行错误检查，以确定数据段在传输过程中是否发生了更改。

1.3、传输层协议

IP 只涉及数据包的结构、地址分配和路由。IP 不指定数据包的传送或传输方式。

传输层协议指定如何在主机之间传输消息，并负责管理会话的可靠性要求。传输层包括 TCP 和 UDP 协议。

不同的应用有不同的传输可靠性要求。因此，TCP/IP 提供了两个传输层协议，如图所示。

1.4、传输控制协议（TCP）

IP 只涉及从原始发送方到最终目的地的数据包的结构、编址和路由。IP不负责保证传递或确定发送方和接收方之间是否需要建立连接。

TCP 被认为是可靠且功能齐全的传输层协议，用于确保所有数据到达目的设备。TCP包含确保应用数据传递的字段。这些字段需要发送和接收的主机进行额外处理。

注意：TCP将数据分为若干个数据段。

TCP 传输类似于从源到目的地跟踪发送的数据包。如果快递订单分多个数据包，客户可以在线查看发货顺序。

TCP 使用以下基本操作提供可靠性和流量控制：

编号并跟踪从特定应用程序发送到特定主机的数据段。
确认收到数据
在一定时间段后重新传输未确认的数据
有顺序的数据可能以错误的顺序到达以接收方可以接受的有效速率* 发送数据

为了维护会话的状态并跟踪信息，TCP必须首先在发送方和接收方之间建立连接。这就是为什么TCP被称为是一种面向连接的协议。

1.5、用户数据报协议（UDP）

UDP是一种比TCP更简单的传输层协议。它不提供可靠性和流量控制，这意味着它需要更少的报头字段。由于发送方和接收方UDP进程不需要管理可靠性和流量控制，这意味着 UDP 数据报的处理速度比 TCP 数据段快。UDP 仅提供在相应应用之间传输数据报的基本功能，需要很少的开销和数据检查。

注意：UDP 将数据划分为数据报，也称为数据段。

UDP是一种无连接协议。由于 UDP 不提供可靠性或流量控制，因此不需要建立连接。由于 UDP 不跟踪客户端和服务器之间发送或接收的信息，因此UDP 也称为无状态协议。

UDP 也称为最大努力交付协议，因为在目的地接收到数据后没有确认消息。UDP 中没有通知发送方是否成功传输的传输层流程。

UDP 类似于邮寄未挂号的常规信件。发件人不知道收件人是否能够接收信件。邮局也不负责跟踪信件或在信件未到达最终目的地时通知发件人。

1.6、正确的应用程序使用正确的传输层协议

一些应用可以容忍在网络传输过程中丢失部分数据，但是不接受传输中出现延迟。由于需要的网络开销较少，对于这些应用，UDP 是更好的选择。UDP 是 IP 语音 (VoIP) 之类应用的首选。确认和重新发送会拖慢传输速度，并使语音会话不可接受。

UDP 也被“请求-回复”应用程序使用，其中数据最少，并且可以快速完成重新传输。例如，域名服务 (DNS) 为此类事务使用 UDP。客户端从DNS服务器请求已知域名的IPv4和IPv6地址。如果客户端在预定的时间内没有收到响应，它将再次发送请求。

例如，如果视频数据流中的一段或者两段数据未到达目的地，就会造成数据流的短暂中断。这可能表现为图像失真或声音失真，用户也许不会察觉。如果目的设备必须负责处理丢失的数据，则流可能在等待重新发送的过程中被推迟，从而导致图像或声音的质量大大降低。在这种情况下，最好利用接收到的分段呈现最佳媒体，并放弃可靠性。

对于其他应用程序，重要的是所有数据都应到达并且可以按适当的顺序对其进行处理。对于这些类型的应用程序，使用TCP 作为传输协议。例如，数据库、Web 浏览器和邮件客户端等应用，要求发送的所有数据都必须以原始形式到达目的地。任何数据的丢失都可能导致通信失败，要么不能完成通信，要么通信的信息不可读。例如，通过网页访问银行信息时，确保所有信息都正确发送和接收是非常重要的。

应用开发人员必须根据应用的需求，选择适合的传输层协议类型。视频可以通过 TCP 或 UDP 发送。存储音频和视频流的应用使用 TCP。应用程序使用 TCP 执行缓冲、带宽探测和拥塞控制，以便更好地控制用户体验。

实时视频和语音通常使用UDP，但也可能使用TCP，或同时使用UDP和TCP。视频会议应用程序默认情况下可能使用UDP，但由于许多防火墙阻止UDP，应用程序也可以通过TCP发送。

存储音频和视频流的应用使用 TCP。例如，如果您的网络突然不能支持观看一个点播电影所需的带宽，则应用使播放暂停。在暂停期间，您可能会看到一个“缓冲……”消息，这时，TCP 正在重建流。当所有的片段都井然有序且恢复最低限度的带宽时，您的 TCP 会话重新开始，电影恢复播放。

该图总结了UDP和TCP之间的差异。

2、TCP概述

2.1、TCP功能

在上一主题中，您了解了TCP和UDP是两个传输层协议。本主题提供了更多关于TCP的详细信息，以及何时使用它而不是UDP是明智的。

要了解 TCP 和 UDP 的差异，就必须了解每种协议如何实现特定的可靠性功能，以及每个协议如何跟踪会话。

除了支持数据分段和重组的基本功能之外，TCP 还提供以下服务：

建立会话 -TCP是一种面向连接的协议，在转发任何流量之前，在源设备和目的设备之间协商并建立永久连接（或会话）。通过建立会话，设备可以协商特定时间能够转发的流量，而且两个设备之间的通信数据可得到严格管理。
确保可靠的传递 -由于多种原因，数据段在网络传输过程中可能会损坏或者完全丢失。TCP确保从源设备发送的每个数据段都能够到达目的地。
提供相同顺序的传递 -由于网络可能提供了多条路由，每条路由又有不同的传输速率，所以可能导致数据抵达的顺序错乱。通过对数据段编号和排序，TCP 确保按正确的顺序重组这些数据段。
支持流量控制 -网络主机的资源有限（即，内存或处理能力）。当 TCP 发现这些资源超负荷运转时，它可以请求源应用程序降低数据流速。为此，TCP 会调整源设备传输的数据量。流量控制可避免当接收主机的资源不堪重负时，数据的重新传输。

有关 TCP 的更多信息，请在互联网上搜索 RFC 793。

2.2、TCP报头

TCP是有状态的协议，意味着它跟踪通信会话的状态。为了跟踪会话的状态，TCP 记录已发送的信息和已确认的信息。状态会话开始于会话建立时，结束于会话终止时。

在封装应用层数据时，TCP 数据段会增加 20 个字节（即 160 位）的开销。该图显示的是 TCP 报头中的字段。

TCP报头由一个20字节报头中的10个字段组成

该图显示的是 TCP 报头中的字段。

2.3、TCP报头字段

该表标识并描述了 TCP 报头中的十个字段。

TCP 报头字段	描述
源端口	一个16位字段, 用于通过端口号标识源应用程序。
目的端口	一个16位字段, 用于通过端口号标识目的应用程序。
序列号	一个32位字段, 用于数据重组。
确认号	一个32位的字段, 用于指示已接收到数据, 并且期望从源接收下一个字节。
报头长度	一个4位字段, 称为“数据偏移”, 表示 TCP数据段报头的长度。
保留	一个6位字段, 保留供将来使用。
控制位	一个6位字段, 包括位代码或标志, 指示 TCP段的目的和功能。
窗口大小	一个16位字段, 用于指示一次可以接受的字节数。
校验和	一个16位字段, 用于数据段报头和数据的错误检查。
紧急	一个 16 位字段, 用于指示包含的数据是否紧急。

2.4、使用TCP的应用程序

TCP 很好地说明了 TCP/IP 协议簇的不同层如何拥有特定角色。TCP 处理与将数据流划分为数据段、提供可靠性、控制数据流量和数据段重新排序相关的所有任务。TCP 使应用程序不用再管理这些任务。如图所示的应用程序只需要将数据流发送到传输层和使用 TCP 提供的服务。

3、UDP概述

3.1、UDP功能

本主题将介绍UDP、它的作用以及何时使用UDP代替TCP是一个好主意。UDP 是一种尽最大努力传输协议。UDP 是一种轻型传输协议，提供与 TCP 相同的数据分段和重组功能，但是没有 TCP 所提供的可靠性和流量控制。

UDP 协议非常简单，它通常被描述为与 TCP 比较所不提供的功能。

UDP的特点包括以下几种：

数据按照接收顺序重构。
丢失的任何数据段都不会重新发送。
不会建立会话。
不会告知发送者资源可用性。

有关 UDP 的更多信息，请在互联网上搜索 RFC。

3.2、UDP报头

UDP 是无状态协议，这意味着客户端和服务器都不会跟踪通信会话的状态。如果使用 UDP 作为传输协议时要求可靠性，必须由应用来处理可靠性。

通过网络传输实时视频和语音的一个最重要的要求是数据持续高速传输。实时视频和语音应用能够容忍具有极小或没有明显影响的一些数据丢失，非常适合于 UDP。

UDP 中的通信块称为数据报或数据段。这些数据报通过传输层协议尽力传送。

UDP报头比TCP报头简单得多，因为它只有四个字段，需要8个字节(即64位)。该图显示的是 UDP 报头中的字段。

3.3、UDP报头字段

该表标识并描述了 UDP 报头中的四个字段。

UDP 报头字段	描述
源端口	一个16位字段,用于通过端口号标识源应用程序。
目的端口	一个16位字段,用于通过端口号标识目的应用程序。
长度	一个16位字段,指示UDP数据报报头的长度。
校验和	一个16位字段,用于数据报报头和数据的错误检查。

3.4、使用UDP的应用程序

最适合采用 UDP 协议的三种应用程序包括：

实时视频和多媒体应用程序 - 这些应用可以容忍部分数据丢失但要求延迟极小或没有延迟的应用程序。示例包括 VoIP 和实时流传输视频。
简单请求和应答应用程序 - 处理简单事务的应用程序，其中主机发送请求，但不一定收到应答。示例包括 DNS 和 DHCP。
处理可靠性的应用程序 - 不要求进行流量控制、错误检测、确认和错误恢复，或这些功能由应用程序来执行的单向通信。示例包括 SNMP 和 TFTP。

该图标识了需要 UDP 的应用程序。

虽然 DNS 和 SNMP 默认使用 UDP，但它们都可以使用 TCP。如果 DNS 请求或 DNS 响应大于 512 字节，DNS 会使用 TCP，例如 DNS 响应包含许多域名解析时。同样，在某些情况下，网络管理员可以配置 SNMP 使用 TCP。

4、端口号

4.1、多个单独的通信

如您所知，在某些情况下TCP是适合该作业的协议，在其他情况下则应使用UDP。无论传输何种类型的数据，TCP和UDP都使用端口号。

TCP 和 UDP 传输层协议使用端口号来管理多个同时的对话。如图所示，TCP和UDP报头字段标识源和目的应用程序端口号。

源端口号与本地主机上的原始应用程序相关联，而目的端口号与远程主机上的目的应用程序相关联。

例如，假设一台主机正在向 Web 服务器发起网页请求。当主机发起网页请求时，主机会动态生成源端口号，以惟一地标识会话。由主机生成的每个请求将使用不同的动态创建的源端口号。这就使多个会话能够同时发生。

在请求中，目的端口号是标识目的Web服务器正在被请求的服务类型的端口号。例如，当客户端在目的端口中指定端口 80 时，接收该消息的服务器就知道请求的是 Web 服务。

服务器可同时提供多个服务，例如在端口 80 上提供 Web 服务，并同时在端口 21 上提供建立文件传输协议 (FTP) 连接的服务。

4.2、套接字对

源端口和目的端口都被置入分段内，然后分段封装于 IP 数据包内。IP 数据包中含有源 IP 地址和目的 IP 地址。源 IP 地址和源端口号的组合或者目的 IP 地址和目的端口号的组合，称为套接字。

在图中的示例中，PC 同时从目标服务器请求 FTP 和 Web 服务。

在该示例中，PC生成的FTP请求包括第2层MAC地址和第3层IP地址。请求还标识了源端口号 1305（即，由主机动态生成）和标识了FTP服务的目的端口21。主机还使用相同的第 2 层和第 3 层地址从服务器请求了一个网页。但是，它使用的是源端口号 1099（即，由主机动态生成）和标识了Web服务的目的端口80。

套接字用于标识客户端所请求的服务器和服务。客户端套接字可能如下所示，其中 1099 代表源端口号：192.168.1.5:1099

Web 服务器上的套接字则可能是192.168.1.7:80

这两个套接字组合在一起形成一个套接字对：192.168.1.5:1099，192.168.1.7:80

有了套接字，一台客户端上运行的多个进程便可彼此区分，它们与同一服务器进程建立的多个连接也可以彼此区分。

对于请求数据的应用而言，该源端口号就像是一个返回地址。传输层将跟踪此端口和发出该请求的应用，当返回响应时，传输层可以将其转发到正确的应用。

4.3、端口号组

互联网编号指派机构 (IANA) 是负责分配各种编址标准（包括端口号）的标准组织。用于标识源端口号和目的端口号的16位二进制提供了从0到65535的端口范围。

IANA 已将号码范围划分为以下三个端口组。

端口组	号码范围	描述
公认端口	0到1023	这些端口号保留用于常见或流行的服务和应用程序, 例如 Web浏览器, 电子邮件客户端和远程访问客户端。为常用的服务器应用程序定义的公认端口使客户端能够轻松识别所需的关联服务。
注册端口	1024到49151	IANA将这些端口号分配给请求实体, 以用于特定的进程或应用程序。这些进程主要是用户选择安装的单个应用程序, 而不是使用公认端口号的常见应用程序。例如, 思科已为其RADIUS服务器身份验证进程注册了端口1812。
私有和(或) 动态端口	49152 到 65535	这些端口也称为临时端口。客户端的操作系统通常在发起与服务的连接时动态分配端口号。之后即可在通信过程中使用动态端口识别客户端应用程序。

注意: 一些客户端操作系统在分配源端口时可能使用注册端口号而不是动态端口号。

该表显示了一些常用的公认端口号及其相关应用程序。

Well-Known Port Numbers

端口号	协议	应用层
20	TCP	文件传输协议 (FTP) - 数据
21	TCP	文件传输协议 (FTP) - 控制
22	TCP	安全 Shell (SSH)
23	TCP	Telnet
25	TCP	简单邮件传输协议 (SMTP)
53	UDP、TCP	域名服务 (DNS)
67	UDP	动态主机配置协议 (DHCP)- 服务器
68	UDP	动态主机配置协议-客户端
69	UDP	简单文件传输协议 (TFTP)
80	TCP	超文本传输协议 (HTTP)
110	TCP	邮局协议第 3 版 (POP3)
143	TCP	互联网消息访问协议 (IMAP)
161	UDP	简单网络管理协议 (SNMP)
443	TCP	安全超文本传输协议 (HTTPS)

一些应用程序可能既使用 TCP，又使用 UDP。例如，当客户端向 DNS 服务器发送请求时，DNS 使用 UDP。但是，两台 DNS 服务器之间的通信始终使用 TCP。

在IANA网站上搜索端口注册表，来查看端口号及相关应用的完整列表。

4.4、netstat 命令

不明的 TCP 连接可能造成重大的安全威胁。因为此类连接表示某程序或某人正连接到本地主机。有些时候，需要了解联网主机中启用并运行了哪些活动 TCP 连接。Netstat 是一种重要的网络实用程序，可用来检验此类连接。如下所示，输入命令 netstat可列出正在使用的协议、本地地址和端口号、外部地址和端口号以及连接的状态。

C:\> netstat

Active Connections

  Proto  Local Address          Foreign Address            State
  TCP    192.168.1.124:3126     192.168.0.2:netbios-ssn    ESTABLISHED
  TCP    192.168.1.124:3158     207.138.126.152:http       ESTABLISHED
  TCP    192.168.1.124:3159     207.138.126.169:http       ESTABLISHED
  TCP    192.168.1.124:3160     207.138.126.169:http       ESTABLISHED
  TCP    192.168.1.124:3161     sc.msn.com:http            ESTABLISHED
  TCP    192.168.1.124:3166     www.cisco.com:http         ESTABLISHED
(output omitted)
C:\>

默认情况下，netstat命令会试图将 IP 地址解析为域名，将端口号解析为公认应用程序。使用**-n**选项能够以数字形式显示 IP 地址和端口号。

5、TCP通信过程

5.1、TCP服务器进程

您已经了解了 TCP 的基础知识。了解端口号的作用将帮助您掌握TCP通信过程的细节。在本主题中，您还将了解TCP三次握手和会话终止的过程。

在服务器上运行的每个应用程序进程都配置为使用一个端口号。端口号由系统管理员自动分配或手动配置。

在同一传输层服务中，单个服务器上不能同时存在具有相同端口号的两个不同服务。例如，主机同时运行 Web 服务器应用程序和文件传输应用程序时，不能为两个应用程序配置相同的端口（如 TCP 端口 80）。

分配有特定端口的活动服务器应用程序被认为是开放的，也就是说，传输层将接受并处理分配到该端口的数据段。所有发送到正确套接字地址的传入客户端请求都将被接受，数据将被传送到服务器应用。在同一服务器上可以同时开启很多端口，每个端口对应一个动态服务器应用。

发送TCP请求的客户端

客户端 1 正在请求 Web 服务，客户端 2 正在使用公认端口（即 Web 服务 = 端口 80，电子邮件服务 = 端口 25）请求电子邮件服务。

请求的目的端口

请求动态生成源端口号。在这种情况下，客户端 1 使用源端口 49152，客户端 2 使用源端口 51152。

请求的源端口

当服务器响应客户端请求时，它会反转发起请求的目的端口和源端口。

响应的目的端口

注意，服务器对web请求的响应现在具有目的端口49152，而电子邮件的响应现在具有目的端口51152。

响应的源端口

服务器响应中的源端口是发起请求中的原始目的端口。

5.2、TCP连接的建立

在一些文化中，两个人见面时常常通过握手来问好。双方都把握手的行为理解为友好问候的信号。网络中的连接是类似的。在 TCP 连接中，主机客户端使用三次握手过程与服务器建立连接。

第一步SYN

源客户端请求与服务器进行客户端-服务器通信会话。

第二步ACK和SYN

服务器确认客户端-服务器通信会话，并请求服务器-客户端通信会话。

第三步ACK

源客户端确认服务器-客户端通信会话。

三次握手验证目标主机是否可用来通信。在示例中，主机 A验证了主机 B可用。

5.3、会话终止

若要关闭连接，分段报头必须设置完成 (FIN) 控制标志。为终止每个单向 TCP 会话，需采用包含 FIN 分段和确认 (ACK) 分段的二次握手。因此，若要终止 TCP 支持的整个会话过程，需要实施四次交换，以终止两个双向会话。客户端或服务器都可以发起终止。

在本示例中，为了更容易理解，采用了客户端和服务器这两个术语进行说明。实际上，终止的过程可以由任意两台具有开放会话的主机发起。

第1步FIN

当客户端的数据流中没有其他要发送的数据时，它将发送带 FIN 标志设置的分段。

第2步ACK

服务器发送 ACK 信息，确认收到从客户端发出的请求终止会话的 FIN 信息。

第3步FIN

服务器向客户端发送FIN消息，终止从服务端到客户端的对话

第4步ACK

客户端发送 ACK 响应信息，确认收到从服务器发出的 FIN 信息。

当所有数据段得到确认后，会话关闭。

5.4、TCP三次握手分析

主机维护状态，跟踪会话过程中的每个分段，并使用 TCP 报头信息交换已接收数据的相关信息。TCP 是全双工协议，每个连接都代表两个单向通信会话。若要建立连接，主机应执行三次握手。如图所示，TCP 报头中的控制位指出了连接的进度和状态。

这些是三次握手的功能：

确认目的设备存在于网络上。
确认目的设备有活动的服务，并且正在源客户端要使用的目的端口号上接受请求。
通知目的设备源客户端想要在该端口号上建立通信会话。

通信完成后，将关闭会话并终止连接。连接和会话机制保障了 TCP 的可靠性功能。

控制位字段

TCP 分段报头的控制位字段中的六位被称为标志。标志是设置为开启或关闭的位。

六个控制位标志如下：

URG - 紧急指针字段（重要）
ACK -用于建立连接和会话终止的确认标志
PSH - 推送功能
RST 在出现错误或超时时重置连接
SYN -同步建立连接中使用的序列号
FIN -没有更多来自发送方的数据，并用于会话终止

搜索互联网以了解 PSH 和 URG 标志的详细信息。

5.5、视频-TCP三次握手

略

6、可靠性和流控制

6.1、TCP可靠性-保证及按序传递

对某些应用程序来说，TCP更好，原因是，与 UDP 不同，它重新发送丢弃的数据包以及对数据包进行编号，以便在传递前指示其正确的顺序。TCP 还可以帮助维护数据包的流量，以避免设备过载。本主题详细介绍 TCP 的这些功能。

有时可能TCP数据段没有到达目的地。有时，TCP段可能会无序到达。因此，为了让接收方理解原始消息，必须接收所有数据，并重组这些数据段，使其恢复原有顺序。每个数据包中的数据段报头中都含有序列号，便于进行数据重组。序列号代表 TCP 分段的第一个数据字节在完整数据中的位置。

在会话建立过程中，将设置初始序列号 (ISN)。此 ISN 表示传输到接收应用的字节起始值。在会话过程中，每传送一定字节的数据，序列号就随之增加。通过这样的数据字节跟踪，可以唯一标识并确认每个分段，还可以标识丢失的分段。

ISN 并不是从 1 开始，而是随机的数字。这样做的目的是防止某些类型的恶意攻击。为简单起见，本章的示例中我们将使用 1 作为 ISN。

如图所示，数据段的序列号用于指示如何重组和重新排序收到的数据段。

在目的设备上对TCP数据段进行重新排序

接收方的 TCP 进程将数据段中的数据存入缓存区，然后数据段按照正确的序列顺序进行排列，重组后发送到应用层。对于序列号混乱的分段，将被保留以备后期处理。等缺失的分段到达后，再来按顺序处理这些分段。

6.2、视频-TCP可靠性-序列号和确认

TCP 的其中一项功能是确保每个数据段都能到达目的地。在目的主机上的 TCP 服务确认该源应用收到的数据。

视频略

6.3、TCP可靠性-数据丢失和重传

无论网络设计得有多好，数据丢失还是时有发生。TCP 提供了管理数据段丢失的方法。其中一个方法就是重新传输未确认的数据。

序列 (SEQ) 号和确认 (ACK) 号一起使用，以确认接收传输段中包含的数据字节。SEQ 编号标识正在传输的数据段中的第一个字节。TCP 使用发送回源代码的 ACK 编号来指示接收方希望接收的下一个字节。这称为期望确认。

在进行后续增强之前，TCP只能确认预期的下一个字节。例如，在图中，为简单起见，主机A使用数据段号向主机B发送段1到10。如果除段3和段4之外的所有数据段都已到达，主机B将应答并确认指定下一个预期的数据段是段3。主机A不知道其他数据段是否到达。因此，主机A将重新发送段3到段10。如果所有重新发送的数据段都成功到达，则段 5 到段10 将是重复的。这会导致延迟、拥塞和效率低下。

今天的主机操作系统通常采用一种称为选择性确认 (SAK) 的可选 TCP 功能，在三次握手期间协商。如果两个主机都支持SACK，则接收方可以明确地确认接收了哪些数据段(字节)，包括任何不连续的段。因此，发送主机只需要重新传输丢失的数据。例如，在下图中，还是为简单起见，主机A使用数据段号向主机B发送段1到10。如果除段3和段4之外的所有数据段都已到达，主机B可以确认它已经接收了段1和段2 (ACK 3)，并有选择地确认段5到10 (SACK 5-10)。主机A只需要重新发送段3和段4。

注意：TCP通常会为每个其他数据包发送ACK，但是超出本主题范围的其他因素可能会改变这种行为。

TCP使用计时器来知道在重新发送一个数据段之前需要等待多长时间。

6.4、视频-TCP可靠性-数据丢失和重传

略

6.5、TCP流量控制-窗口大小和确认

TCP 还提供了流量控制机制。流量控制即目的主机能够可靠地接收并处理的数据量。流量控制可以调整给定会话中源和目的地之间的数据流速，有助于保持 TCP 传输的可靠性。为此，TCP 报头包括一个称为“窗口大小”的 16 位字段。

图中显示了一个窗口大小和确认的示例。

TCP窗口大小示例

窗口大小用于确定在获得确认前可以发送的字节数。确认号是指下一个预期字节的编号。

窗口大小是 TCP 会话的目的设备一次可以接受和处理的字节数。在本例中，PC B 用于 TCP 会话的初始窗口大小为 10000 字节。从第 1 个字节开始，字节数为 1，PC A 在不收到确认的前提下可以发送的最后一个字节为 10,000。这被称为PC A的发送窗口。每个 TCP 分段均包含窗口大小，那样目的设备可以根据缓冲区的可用性随时修改窗口大小。

初始窗口大小在三次握手期间建立 TCP 会话时确定。源设备必须根据目的设备的窗口大小限制发送到目的设备的字节数。只有源设备收到字节数已接收的确认之后，才能继续发送更多会话数据。通常情况下，目的设备不会等待其窗口大小的所有字节接收后才以确认应答。接收和处理字节时，目的设备就会发送确认，以告知源设备它可以继续发送更多字节。

例如，通常情况下，PC B 不会等待所有 10,000 字节都接收后才发送确认。这就意味着 PC A 可以在收到 PC B 的确认时调整其发送窗口。如图所示，当 PC A 收到确认号为 2,921 的确认消息时，它即是下一个预期的字节的编号。PC A 发送窗口将增加 2920 字节。这会将发送窗口从 10000 字节更改为 12920。现在只要 PC A 发送不超出其新的发送窗口 12920 的字节数，它就能够向 PC B 另外发送 10000 字节。

目的设备在处理接收的字节时发送确认并不断调整源设备的发送窗口大小被称为滑动窗口。在上一个示例中，PC A 的发送窗口会增加或滑动了 2921 个字节，从 10000 增到 12920。

如果目的设备缓冲区空间的可用性减小，它可以缩减窗口大小，通知源设备减少发送的字节数，而不需要接收确认。

注意：设备如今使用滑动窗口协议。接收方通常在每收到两个数据段之后发送确认。在确认之前收到的数据段的数量可能有所不同。滑动窗口的优势在于，只要接收方确认之前的数据段，就可以让发送方持续传输数据段。滑动窗口的详细信息不在本课程的讨论范围之内。

6.6、TCP流量控制-最大段大小（MSS）

如图所示，在每个TCP数据段内，源主机正在传输 1460 字节的数据。这通常是目的设备可接收的最大段大小 (MSS)。MSS 是 TCP 报头中选项字段的一部分，用于指定设备可以在单个 TCP数据段中接收的最大数据量（以字节为单位）。MSS 大小不包括 TCP 报头。MSS 通常包括在三次握手过程中。

使用 IPv4 时，常见的 MSS 为 1460 字节。主机会从以太网最大传输单位 (MTU) 中减去 IP 和 TCP 报头，从而确定其 MSS 字段的值。在以太网接口上，默认 MTU 为 1500 个字节。减去 20 个字节的 IPv4 报头和 20 个字节的 TCP 报头，默认 MSS 大小为 1460 个字节，如图所示