系统架构设计笔记（95）—— TCP 协议

最新推荐文章于 2024-04-22 13:40:38 发布

Deniro Lee

最新推荐文章于 2024-04-22 13:40:38 发布

阅读量1.2k

点赞数 1

分类专栏：系统架构设计文章标签：架构

本文链接：https://blog.csdn.net/deniro_li/article/details/108929024

版权

系统架构设计专栏收录该内容

116 篇文章 115 订阅

订阅专栏

传输控制协议（ TCP ， Transmission Control Protocol ）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的 RFC793 定义。

TCP 旨在适应支持多网络应用的分层协议层次结构。连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠 TCP 提供可靠的通信服务。 TCP 假设它可以从较低级别的协议获得简单的，可能不可靠的数据报服务。原则上， TCP 应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。

1 简介

传输控制协议（ TCP ， Transmission Control Protocol ）是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。

互联网络与单个网络有很大的不同，因为互联网络的不同部分可能有截然不同的拓扑结构、带宽、延迟、数据包大小和其他参数。 TCP 的设计目标是能够动态地适应互联网络的这些特性，而且具备面对各种故障时的健壮性。

不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是 IP 层不提供这样的流机制，而是提供不可靠的包交换。

应用层向 TCP 层发送用于网间传输的、用8位字节表示的数据流，然后 TCP 把数据流分区成适当长度的报文段（通常受该计算机连接的网络的数据链路层的最大传输单元（ MTU ）的限制）。之后 TCP 把结果包传给 IP 层，由它来通过网络将包传送给接收端实体的 TCP 层。 TCP 为了保证不发生丢包，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认（ ACK ）；如果发送端实体在合理的往返时延（ RTT ）内未收到确认，那么对应的数据包就被假设为已丢失将会被进行重传。 TCP 用一个校验和函数来检验数据是否有错误；在发送和接收时都要计算校验和。

IP 层并不保证数据报一定被正确地递交到接收方，也不指示数据报的发送速度有多快。正是 TCP 负责既要足够快地发送数据报，以便使用网络容量，但又不能引起网络拥塞：而且， TCP 超时后，要重传没有递交的数据报。即使被正确递交的数据报，也可能存在错序的问题，这也是 TCP 的责任，它必须把接收到的数据报重新装配成正确的顺序。简而言之， TCP 必须提供可靠性的良好性能，这正是大多数用户所期望的而 IP 又没有提供的功能。

2 主要功能

当应用层向 TCP 层发送用于网间传输的、用8位字节表示的数据流， TCP 则把数据流分割成适当长度的报文段，最大传输段大小（ MSS ）通常受该计算机连接的网络的数据链路层的最大传送单元（ MTU ）限制。之后 TCP 把数据包传给 IP 层，由它来通过网络将包传送给接收端实体的 TCP 层。

TCP 为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认（ ACK ）；如果发送端实体在合理的往返时延（ RTT ）内未收到确认，那么对应的数据（假设丢失了）将会被重传。

在数据正确性与合法性上， TCP 用一个校验和函数来检验数据是否有错误，在发送和接收时都要计算校验和；同时可以使用 md5 认证对数据进行加密。
在保证可靠性上，采用超时重传和捎带确认机制。
在流量控制上，采用滑动窗口协议，协议中规定，对于窗口内未经确认的分组需要重传。
在拥塞控制上，采用广受好评的 TCP 拥塞控制算法（也称 AIMD 算法）。

3 主要特点

TCP 是一种面向广域网的通信协议，目的是在跨越多个网络通信时，为两个通信端点之间提供一条具有下列特点的通信方式：

（1）基于流的方式；
（2）面向连接；
（3）可靠通信方式；
（4）在网络状况不佳的时候尽量降低系统由于重传带来的带宽开销；
（5）通信连接维护是面向通信的两个端点的，而不考虑中间网段和节点。

为满足 TCP 协议的这些特点， TCP 协议做了如下的规定：

① 数据分片：在发送端对用户数据进行分片，在接收端进行重组，由 TCP 确定分片的大小并控制分片和重组；

② 到达确认：接收端接收到分片数据时，根据分片数据序号向发送端发送一个确认；

③ 超时重发：发送方在发送分片时启动超时定时器，如果在定时器超时之后没有收到相应的确认，重发分片；

④ 滑动窗口： TCP 连接每一方的接收缓冲空间大小都固定，接收端只允许另一端发送接收端缓冲区所能接纳的数据， TCP 在滑动窗口的基础上提供流量控制，防止较快主机致使较慢主机的缓冲区溢出；

⑤ 失序处理：作为 IP 数据报来传输的 TCP 分片到达时可能会失序， TCP 将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层；

⑥ 重复处理：作为 IP 数据报来传输的 TCP 分片会发生重复， TCP 的接收端必须丢弃重复的数据；

⑦ 数据校验： TCP 将保持它首部和数据的检验和，这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到分片的检验和有差错， TCP 将丢弃这个分片。

4 可靠性实现

4.1 可靠性

TCP 提供一种面向连接的、可靠的字节流服务。面向连接意味着两个使用 TCP 的应用（通常是一个客户和一个服务器）在彼此交换数据包之前必须先建立一个 TCP 连接。这一过程与打电话很相似，先拨号振铃，等待对方摘机说 “ 喂 ” ，然后才说明是谁。在一个 TCP 连接中，仅有两方进行彼此通信。广播和多播不能用于 TCP 。

TCP通过下列方式来提供可靠性：

应用数据被分割成 TCP 认为最适合发送的数据块。这和 UDP 完全不同，应用程序产生的数据长度将保持不变。由 TCP 传递给 IP 的信息单位称为报文段或段（ segment ）。
当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。 TCP 有延迟确认的功能，在此功能没有打开，则是立即确认。功能打开，则由定时器触发确认时间点。
TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错， TCP 将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。
既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。如果必要， TCP 将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
既然 IP 数据报会发生重复， TCP 的接收端必须丢弃重复的数据。
TCP 还能提供流量控制。 TCP 连接的每一方都有固定大小的缓冲空间。 TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。

两个应用程序通过 TCP 连接交换 8bit 字节构成的字节流。 TCP 不在字节流中插入记录标识符。我们将这称为字节流服务（ byte stream service ）。如果一方的应用程序先传 10 字节，又传 20 字节，再传 50 字节，连接的另一方将无法了解发方每次发送了多少字节。只要自己的接收缓存没有塞满， TCP 接收方将有多少就收多少。一端将字节流放到 TCP 连接上，同样的字节流将出现在 TCP 连接的另一端。

另外， TCP 对字节流的内容不作任何解释。 TCP 不知道传输的数据字节流是二进制数据，还是 ASCⅡ 字符、EBCDIC 字符或者其他类型数据。对字节流的解释由 TCP 连接双方的应用层解释。

这种对字节流的处理方式与 Unix 操作系统对文件的处理方式很相似。 Unix 的内核对一个应用读或写的内容不作任何解释，而是交给应用程序处理。对 Unix 的内核来说，它无法区分一个二进制文件与一个文本文件。

4.2 重传策略

TCP 协议用于控制数据段是否需要重传的依据是设立重发定时器。在发送一个数据段的同时启动一个重传，如果在重传超时前收到确认（ Acknowlegement ）就关闭该重传，如果重传超时前没有收到确认，则重传该数据段。在选择重发时间的过程中， TCP 必须具有自适应性。它需要根据互联网当时的通信情况，给出合适的重发时间。

这种重传策略的关键是对定时器初值的设定。采用较多的算法是 Jacobson 于 1988 年提出的一种不断调整超时时间间隔的动态算法。其工作原理是：对每条连接 TCP 都保持一个变量 RTT （ Round Trip Time ），用于存放当前到目的端往返所需要时间最接近的估计值。当发送一个数据段时，同时启动连接的定时器，如果在定时器超时前确认到达，则记录所需要的时间（ M ），并修正 RTT 的值，如果定时器超时前没有收到确认，则将 RTT 的值增加1倍。通过测量一系列的 RTT （往返时间）值， TCP 协议可以估算数据包重发前需要等待的时间。在估计该连接所需的当前延迟时通常利用一些统计学的原理和算法（如 Karn 算法），从而得到 TCP 重发之前需要等待的时间值。

4.3 窗口确认

TCP 的一项功能就是确保每个数据段都能到达目的地。位于目的主机的 TCP 服务对接受到的数据进行确认，并向源应用程序发送确认信息。

使用数据报头序列号以及确认号来确认已收到包含在数据段的相关的数据字节。 TCP 在发回源设备的数据段中使用确认号，指示接收设备期待接收的下一字节。这个过程称为期待确认。

源主机在收到确认消息之前可以传输的数据的大小称为窗口大小。用于管理丢失数据和流量控制。

5 协议对比

TCP 是面向连接的传输控制协议，而 UDP 提供了无连接的数据报服务；

TCP 具有高可靠性，确保传输数据的正确性，不出现丢失或乱序； UDP 在传输数据前不建立连接，不对数据报进行检查与修改，无须等待对方的应答，所以会出现分组丢失、重复、乱序，应用程序需要负责传输可靠性方面的所有工作；

UDP 具有较好的实时性，工作效率较 TCP 协议高；

UDP 段结构比 TCP 的段结构简单，因此网络开销也小。

TCP 协议可以保证接收端毫无差错地接收到发送端发出的字节流，为应用程序提供可靠的通信服务。对可靠性要求高的通信系统往往使用 TCP 传输数据。比如 HTTP 运用 TCP 进行数据的传输。

6 滑动窗口协议

滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。

发送和接受方都会维护一个数据帧的序列，这个序列被称作窗口。发送方的窗口大小由接受方确定，目的在于控制发送速度，以免接受方的缓存不够大，而导致溢出，同时控制流量也可以避免网络拥塞。

上图中的4，5，6号数据帧已经被发送出去，但是还未收到关联的 ACK ，7，8， 9 帧则是等待发送。可以看出发送端的窗口大小为 6，这是由接受端确定并告知的。此时如果发送端收到4号 ACK ，则窗口的左边缘向右收缩，窗口的右边缘则向右扩展，此时窗口就向前 “ 滑动了 ” ，即数据帧 10 也可以被发送。