【计算机网络】|| TCP是如何保证可靠的传输的

前言

Tcp 是 面向连接的 可靠的 流式服务
Udp 是 无连接 不可靠 数据报服务

Tcp 需要进行三次握手建立连接后，才可以传输用户数据，可靠性是通过应答确
认超时重传机制等保证，还有滑动窗口来进行流量控制。

实际选择哪种协议，要看需求，比如，视频传输，要求以恒定速率发送数据，udp可以做到。传输文件，要求可靠性，使用 tcp 好一些。

TCP，传输控制协议，和UDP的差别很大，它充分实现了数据传输时的各种控制功能：

• 针对发送端发出的数据包的确认应答信号ACK
• 针对数据包丢失或者出现定时器超时的超时重发机制
• 针对数据包到达接收端主机顺序乱掉的顺序控制
• 针对高效传输数据包的滑动窗口控制
• 针对避免网络拥堵时候的流量控制
• 针对刚开始启动的时候避免一下子发送大量数据包而导致网络瘫痪的慢启动算法和拥塞控制。

TCP作为一种面向有连接的控制传输协议，只有在确认对端主机存在时才会发送数据，从而可以控制通信流量的浪费。

【1】确认应答信号ACK与序列号

TCP传输时将每个字节的数据都进行了编号，这就是序列号。

确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。

【2】超时重发机制

在进行TCP传输时，由于确认应答与序列号机制，也就是说发送方发送一部分数据后，都会等待接收方发送的ACK报文，并解析ACK报文，判断数据是否传输成功。

问题：如果发送方发送完数据后，迟迟没有等到接收方的ACK报文，这该怎么办呢？没有收到ACK报文的原因可能是什么呢？

首先，发送方没有介绍到响应的ACK报文原因可能有两点：

1. 数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。
2. 接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了。

TCP在解决这个问题的时候引入了一个新的机制，叫做超时重传机制。

简单理解就是发送方在发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么对刚才发送的数据进行重新发送。
如果是第一个原因，接收方收到二次重发的数据后，便进行ACK应答。
如果是第二个原因，接收方发现接收的数据已存在（判断存在的根据就是序列号，所以上面说序列号还有去除重复数据的作用），那么直接丢弃，仍旧发送ACK应答。

超时重传时间的选择

问题：那么发送方发送完毕后等待的时间是多少呢？如果这个等待的时间过长，那么会影响TCP传输的整体效率，如果等待时间过短，又会导致频繁的发送重复的包。如何权衡？

tcp采用了一种自适应的算法，他记录一个报文的发出时间以及收到相应确认的时间。这两个时间查就是报文段的往返时间RTT。TCP保留了一个RTT的加权平均往返时间RTTS，没测量一个RTT样本值时，RTTS值就取为所测量的RTT样本的值，以后每测量一个RTT值，就按如下方法进行更新RTTS的值。

新的RTTS = (1-a) * (旧的RTTs)+a * (RTT样本)

其中0<=a<1，推荐值为0.125

超时重传时间RTO应该略微大于RTTS，计算方式如下：

RTO=RTTS+4*RTTD

RTTD是RTTs的偏差的加权平均值

RTTD=(1-b)*(旧的RTTD)+b * |RTTs-新的RTT样本|

其中b是小于1的系数，推荐值为0.25
问题：如何判断当前的确认报文段是开始发送的报文段的确认还是后来重传的时候发来的报文段的确认？

若收到的确认是对重传报文段的确认，但却被源主机当成是对原来的报文段的确认，则这样计算出的RTTs和超时重传时间RTO就会偏大。若后面再发送的报文段又是经过重传后才收到确认报文段，则按此方法得出的超时重传时间RTO就越来越长。同样，若收到的确认是对原来的报文段的确认，但被当成是对重传报文段的确认，则由此计算出的RTT和RTO都会偏小。这就必然导致报文段过多地重传。这样就有可能使RTO越来越短。

解决办法：在计算加权平均RTTS 时，只要报文段重传了，就不采用其往返时间样本。这样得出的加权平均RTTS和RTO就较准确。

但是，这又引起新的问题。设想出现这样的情况:报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据刚才的算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。

因此要对上边的算法进行修正。方法是:报文段每重传次，就把超时重传时间RTO增大些。典型的做法是取新的重传时间为旧的重传时间的2倍。当不再发生报文段的重传时，才根据上面给出的公式计算超时重传时间。实践证明，这种策略较为合理。

【3】滑动窗口实现流量控制

流量控制 就是让发送方不要发送的过快，让接收方能来得及接收

问题导入：接收端在接收到数据后，对其进行处理。如果发送端的发送速度太快，导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，继而导致丢包的一系列连锁反应，超时重传呀什么的。

TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。

TCP 利用滑动窗口实现流量控制的机制。

在TCP协议的报头信息当中，有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。
图中rwnd为窗口的大小

接收端会在确认应答发送ACK报文时，将自己的即时窗口大小rwnd填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。

如果接收到窗口大小的值为0，那么发送方将停止发送数据。并设有一个持续计时器定期的向接收端发送窗口探测数据段，如果TCP连接的一方收到了0窗口通知，就启动持续计时器定期发送一个零窗口探测报文段（仅仅携带一个字节的数据）让接收端把窗口大小告诉发送端。

【4】拥塞控制

拥塞控制：TCP 模块为了提高网络利用率，降低丢包率，并办证网络资源对每条数据流的公平性而采取的控制手段。
拥塞控制包含四部分内容：慢启动、拥塞避免、快重传、快速恢复。

慢启动

网络传输刚开始时，并不知道网络的实际情况，所以采取一种试探的方式控制数据的发送速率。慢启动阶段，数据的发送速率以指数方式增长，即就是拥塞窗口的增长，每次都是收到确认报文段数量的 2 倍。可以看出慢启动并不慢，拥塞窗口增长的速度很快。所以，为其设置了一个慢启动门限，当达到门限时，就进入到拥塞避免阶段。

拥塞避免

当拥塞窗口的大小采用慢启动方式增长到慢启动门限时，就进入拥塞避免阶段，拥塞避免阶段不再以指数形式增长拥塞窗口，而是每经过一个往返时间 RTT就将发送方的拥塞窗口+1， 使其增长速度减缓。按照线性方式增长。如果发生网络拥塞，比如丢包时，就将慢启动门限设为原来的一半，然后将拥塞窗口设置为 1，开始行慢启动算法。（较低的起点，指数级增长）。

快速重传

假设发送方发送的报文段分别为： M1,M2,M3,M4,M5,M6 , 当接收方收到 M1 和 M2 后，M3 报文段丢失，接着收到的 M4，M5，M6 都不做处理，而是没接收到一个报文段就对 M2 重复确认，发送方接收到重复的三次确认报文段，就对其后的报文段进行重新发送，而不需要等待超时时间到达。当快速重传后，立即进入到快速恢复阶段。

快速恢复

将慢启动门限设置为原来的一半，然后将拥塞窗口设置为现在的慢启动门限值，不再执行慢启动算法，而是直接进入拥塞避免阶段。使发送窗口成线性方式增大。