TCP_可靠数据传输原理

引言

在网络通信中，TCP是确保数据可靠传输的关键协议。但在我们深入研究TCP拥塞控制技术之前，让我们先探索可靠数据传输的原理，特别是TCP头部中一些重要字段的作用。
网络层提供了点对点的通信服务，努力交付数据报，但并不保证可靠交付。这引出了运输层的角色，而TCP和UDP是两种截然不同的协议，其中UDP实现了运输层的基本职能，而TCP在此基础上实现了数据的可靠传输。

在这个庞大的网络中，我们如何确保数据在通信过程中能够可靠传输？有哪些技术和机制可以应对不同的通信问题，如比特差错、乱序、丢包等？
本文将基于《计算机网络*自顶向下方法》一书的第3.4节内容进行整理，介绍可靠数据传输不同版本的演进过程，对问题逐一进行解答。

构建可靠的数据传输协议

rdt: 可靠数据传输协议（reliable data transfer protocol）；
tcp是双向数据传输，简化场景，考虑单向数据传输可靠性如何来保障。从最简单的场景来逐步演化，得到一个可靠的数据传输协议。

rdt1.0：经完全可靠信道的可靠数据传输

这是一种最简单的场景，认为网络层的信道是可靠的，此时接收、发送方直接收发数据即可，无需额外的动作；
状态机：

报文格式：data

rdt2.0: 经具有比特差错信道的可靠数据传输

网络层保障数据的有序送达，但不保障原样交付，即数据可能会出错；
发送方需要增加冗余信息（即tcp头部中的校验和），
接收方需要来识别数据是否损坏（或者说被修改），并告知发送方识别结果；
接收方如果被告知数据损坏，需要进行重传。
此场景下，NAC或者ACK受损的情况。

状态机

报文格式。发送方：data+校验和；接收方应答：接收结果。

rdt2.1：经具有比特差错和乱序信道的可靠数据传输

网络层不会丢包，会保障数据的送达，但不保障有序性和原样交付；即在rdt2.0的基础上，增加了乱序的场景；
如何解决乱序问题，最简单的方案，增加编号。

状态机：

报文格式。发送方：data+校验和+序号；接收方应答：序号+接收结果。

rdt2.2：无NAK机制的rdt2.1实现

在rdt2.1的基础上进行了微调，去掉了显示的NAK应答，只回复ACK信息；通过对同一个分组连续的两个ACK来隐性实现NAK的效果；
状态机：

报文格式和rdt2.1的相同；

rdt3.0：经具有比特差错的丢包信道的可靠数据传输

网络层尽力而为的交付数据报，但不保证可靠交付，在rdt2.2的基础上，增加了丢包。此时网络模型贴合我们实际的环境，即乱序、丢包、受损均可能出现。
识别丢包，发送方需要增加超时机制，超时未收到应答需要重传。重传的引入，可能导致数据包重复接收/送达，接收方需要根据序号去重。

状态机：

和rdt2.2相比，发送方增加了超时处理机制，但对于接收方而言无感，故接收方的状态机和rdt2.2的相同；
报文格式和rdt2.2相同；

交互过程如下：

至此，可靠数据传输协议原理介绍完毕，它用到了校验和、序号、结果确认、定时器这些技术。

性能问题如何提升

rdt3.0保证了数据的可靠传输，但存在一个性能问题，即一次只能传输一个分组。
在千兆带宽、往返传播时延RTT为30ms，一个分组为1500字节的情况下，计算可得真实速率为400Kbps，带宽利用率为万分之四。
为了提高性能，我们需要提高发送数据量的大小、降低RTT，并提升带宽大小。发送数据量的增加和RTT的降低可以提高真实使用速率和带宽利用率。
然而，对于传输链路上的带宽，发送者并不知道它的具体情况。这引出了TCP的拥塞控制机制，它是如何解决这个问题的，我们将在后文中介绍。

流水线可靠数据传输协议

为了提高带宽利用率，我们引入了流水线作业的概念，允许在未收到ACK的情况下同时发送多个数据报。

相较于rdt3.0，流水线作业模式下需要做一些新的调整：

1. 增加序号范围： 由于多个分组同时在传输，需要有唯一的序号来区分，包括确认报文。

2. 增加缓存空间： 发送方需要存储已发送但未确认的数据，接收方需要存储已接收但未被上层应用读取的数据。

3. 异常处理： 在流水线作业中，乱序和丢包的异常处理需要考虑。有两种处理策略：回退N步和选择重传。

回退N步（Go-Back-N，GBN）

针对异常处理的一种策略，当出现丢包时，从丢包的位置开发，其后所有的分组全部重传。

选择重传（Selective Repeat，SR）

针对异常处理的另一种策略，当出现丢包时，发送方选择性的重传。

比较GBN和SR这两种策略，GBN相对简单，但可能会浪费带宽资源。例如，在传输10000个包的情况下，仅第1000个包丢失，后续的9000个包都需要全部重传，这会极大增加网络负载，可能导致拥塞。

而SR按需重传，可能会导致网络利用率较低。例如，连续10个包丢失，每个包依次等待超时重传，会阻塞后续包的传输。

TCP使用的SACK（Selective Acknowledgment）机制告知发送方接收到的失序报文段，从而使发送方更快地传输丢失的数据包。

基于这两种策略，我们可以对比TCP和UDP在传输大数据（如一个zip文件）的场景下的表现。
TCP采用类似SR策略，按需传输丢失的数据包，但由于握手和拥塞控制的影响，前期带宽利用率较低，可能会波动。
而UDP采用类似GBN策略，如果出现丢包，应用层需要重传整个数据，但网络带宽利用率不受影响。
在具体场景中，选择使用哪种协议将取决于需求和性能要求。

TCP报文格式回顾

根据前面介绍的知识点，回顾TCP报文格式中部分字段的含义。
Sequence Number：发送序列号；
Acknowledge Number：确认序列号；
Window：（作为接收方时的）窗口大小；
Checksum：数据校验和；
Options.type=5：SACK机制；用于对收到乱序数据包的场景进行部分确认的机制；
完整格式解读，参见《TCP_报文格式解读》

小结

TCP作为网络通信中的关键协议，在可靠数据传输方面经过多个版本的演进，逐步解决了不同的通信问题，如比特差错、乱序、丢包等。流水线作业的引入为提高带宽利用率提供了思路，而回退N步和选择重传这两种异常处理策略则为解决传输中的异常情况提供了灵活性选择。

在实际应用中，选择TCP或UDP取决于具体场景需求。TCP通过拥塞控制机制适应网络环境变化，而UDP则更适用于对时延和实时性要求较高的场景。对于性能优化，需要平衡发送数据量大小、RTT和带宽，以达到更高的真实速率和带宽利用率。接下来，我们将聚焦于另一个关键领域：TCP的拥塞控制技术。究竟是什么让TCP在网络中表现得如此出色？让我们一同揭开拥塞控制的面纱，深入理解其背后的原理与挑战。